libstdc++-v3/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">N2612=08-0122</td>
  16 </tr>
  17 <tr>
  18 <td align="left">Date:</td>
  19 <td align="left">2008-05-18</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 R56)</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>R56:
  98 2008-05-16 pre-Sophia Antipolis mailing.
  99 <ul>
 100 <li><b>Summary:</b><ul>
 101 <li>191 open issues, up by 24.</li>
 102 <li>647 closed issues, up by 1.</li>
 103 <li>838 issues total, up by 25.</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#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#826">826</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#831">831</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#838">838</a>.</li>
 107 <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>.</li>
 108 </ul></li>
 109 </ul>
 110 </li>
 111 <li>R55:
 112 2008-03-14 post-Bellevue mailing.
 113 <ul>
 114 <li><b>Summary:</b><ul>
 115 <li>167 open issues, down by 39.</li>
 116 <li>646 closed issues, up by 65.</li>
 117 <li>813 issues total, up by 26.</li>
 118 </ul></li>
 119 <li><b>Details:</b><ul>
 120 <li>Added the following Dup issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a>.</li>
 121 <li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#790">790</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#791">791</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#796">796</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#797">797</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#799">799</a>.</li>
 122 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>.</li>
 123 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#801">801</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a>.</li>
 124 <li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#798">798</a>.</li>
 125 <li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>.</li>
 126 <li>Changed the following issues from NAD Future to NAD: <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#323">323</a>.</li>
 127 <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>.</li>
 128 <li>Changed the following issues from Open to NAD: <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#462">462</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>.</li>
 129 <li>Changed the following issues from NAD Future to NAD Editorial: <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#390">390</a>.</li>
 130 <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li>
 131 <li>Changed the following issues from Review to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>.</li>
 132 <li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a>.</li>
 133 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#617">617</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#724">724</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#734">734</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#747">747</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#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>.</li>
 134 <li>Changed the following issues from Ready to Open: <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#688">688</a>.</li>
 135 <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#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li>
 136 <li>Changed the following issues from Open to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#625">625</a>.</li>
 137 <li>Changed the following issues from New to Ready: <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#715">715</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#740">740</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#746">746</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#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#783">783</a>.</li>
 138 <li>Changed the following issues from Open to Ready: <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-active.html#471">471</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#612">612</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#673">673</a>.</li>
 139 <li>Changed the following issues from Review to Ready: <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#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#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#685">685</a>.</li>
 140 <li>Changed the following issues from New to Review: <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-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>.</li>
 141 <li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>.</li>
 142 <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li>
 143 <li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>.</li>
 144 </ul></li>
 145 </ul>
 146 </li>
 147 <li>R54:
 148 2008-02-01 pre-Bellevue mailing.
 149 <ul>
 150 <li><b>Summary:</b><ul>
 151 <li>206 open issues, up by 23.</li>
 152 <li>581 closed issues, up by 0.</li>
 153 <li>787 issues total, up by 23.</li>
 154 </ul></li>
 155 <li><b>Details:</b><ul>
 156 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>.</li>
 157 <li>Changed the following issues from NAD Future to Dup: <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#348">348</a>.</li>
 158 <li>Changed the following issues from NAD Future to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>.</li>
 159 <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#697">697</a>.</li>
 160 <li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>.</li>
 161 <li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>.</li>
 162 </ul></li>
 163 </ul>
 164 </li>
 165 <li>R53:
 166 2007-12-09 mid-term mailing.
 167 <ul>
 168 <li><b>Summary:</b><ul>
 169 <li>183 open issues, up by 11.</li>
 170 <li>581 closed issues, down by 1.</li>
 171 <li>764 issues total, up by 10.</li>
 172 </ul></li>
 173 <li><b>Details:</b><ul>
 174 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>.</li>
 175 <li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>.</li>
 176 <li>Changed the following issues from Pending WP to 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>
 177 </ul></li>
 178 </ul>
 179 </li>
 180 <li>R52:
 181 2007-10-19 post-Kona mailing.
 182 <ul>
 183 <li><b>Summary:</b><ul>
 184 <li>172 open issues, up by 4.</li>
 185 <li>582 closed issues, up by 27.</li>
 186 <li>754 issues total, up by 31.</li>
 187 </ul></li>
 188 <li><b>Details:</b><ul>
 189 <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-closed.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-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.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-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.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-closed.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-closed.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-closed.html#754">754</a>.</li>
 190 <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>
 191 <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>
 192 <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>
 193 <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-closed.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-closed.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-closed.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-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li>
 194 <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>
 195 <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>
 196 <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li>
 197 <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>.</li>
 198 <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-closed.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-closed.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>
 199 <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>
 200 <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>
 201 <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>
 202 </ul></li>
 203 </ul>
 204 </li>
 205 <li>R51:
 206 2007-09-09 pre-Kona mailing.
 207 <ul>
 208 <li><b>Summary:</b><ul>
 209 <li>168 open issues, up by 15.</li>
 210 <li>555 closed issues, up by 0.</li>
 211 <li>723 issues total, up by 15.</li>
 212 </ul></li>
 213 <li><b>Details:</b><ul>
 214 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.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>
 215 </ul></li>
 216 </ul>
 217 </li>
 218 <li>R50:
 219 2007-08-05 post-Toronto mailing.
 220 <ul>
 221 <li><b>Summary:</b><ul>
 222 <li>153 open issues, down by 5.</li>
 223 <li>555 closed issues, up by 17.</li>
 224 <li>708 issues total, up by 12.</li>
 225 </ul></li>
 226 <li><b>Details:</b><ul>
 227 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.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-defects.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-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li>
 228 <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>
 229 <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>
 230 <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>
 231 <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>
 232 <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>
 233 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.html#680">680</a>.</li>
 234 <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>
 235 <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>
 236 <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>
 237 <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>
 238 <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>
 239 <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>
 240 <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>
 241 <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>
 242 </ul></li>
 243 </ul>
 244 </li>
 245 <li>R49:
 246 2007-06-23 pre-Toronto mailing.
 247 <ul>
 248 <li><b>Summary:</b><ul>
 249 <li>158 open issues, up by 13.</li>
 250 <li>538 closed issues, up by 7.</li>
 251 <li>696 issues total, up by 20.</li>
 252 </ul></li>
 253 <li><b>Details:</b><ul>
 254 <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-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.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-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.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-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li>
 255 <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>
 256 <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>
 257 <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>
 258 <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>
 259 </ul></li>
 260 </ul>
 261 </li>
 262 <li>R48:
 263 2007-05-06 post-Oxford mailing.
 264 <ul>
 265 <li><b>Summary:</b><ul>
 266 <li>145 open issues, down by 33.</li>
 267 <li>531 closed issues, up by 53.</li>
 268 <li>676 issues total, up by 20.</li>
 269 </ul></li>
 270 <li><b>Details:</b><ul>
 271 <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-defects.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-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.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>
 272 <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>
 273 <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-active.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>
 274 <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>
 275 <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>
 276 <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-active.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-active.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-active.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>
 277 <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>
 278 <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>
 279 <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>
 280 <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>
 281 <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>
 282 <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>
 283 <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>
 284 <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>
 285 <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>
 286 </ul></li>
 287 </ul>
 288 </li>
 289 <li>R47:
 290 2007-03-09 pre-Oxford mailing.
 291 <ul>
 292 <li><b>Summary:</b><ul>
 293 <li>178 open issues, up by 37.</li>
 294 <li>478 closed issues, up by 0.</li>
 295 <li>656 issues total, up by 37.</li>
 296 </ul></li>
 297 <li><b>Details:</b><ul>
 298 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.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-closed.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>
 299 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li>
 300 <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>
 301 <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>
 302 <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-active.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>
 303 <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>
 304 </ul></li>
 305 </ul>
 306 </li>
 307 <li>R46:
 308 2007-01-12 mid-term mailing.
 309 <ul>
 310 <li><b>Summary:</b><ul>
 311 <li>141 open issues, up by 11.</li>
 312 <li>478 closed issues, down by 1.</li>
 313 <li>619 issues total, up by 10.</li>
 314 </ul></li>
 315 <li><b>Details:</b><ul>
 316 <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>
 317 </ul></li>
 318 </ul>
 319 </li>
 320 <li>R45:
 321 2006-11-03 post-Portland mailing.
 322 <ul>
 323 <li><b>Summary:</b><ul>
 324 <li>130 open issues, up by 0.</li>
 325 <li>479 closed issues, up by 17.</li>
 326 <li>609 issues total, up by 17.</li>
 327 </ul></li>
 328 <li><b>Details:</b><ul>
 329 <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>
 330 <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>
 331 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Dup.</li>
 332 <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-closed.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>
 333 <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>
 334 <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>
 335 <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>
 336 </ul></li>
 337 </ul>
 338 </li>
 339 <li>R44:
 340 2006-09-08 pre-Portland mailing.
 341 <ul>
 342 <li><b>Summary:</b><ul>
 343 <li>130 open issues, up by 6.</li>
 344 <li>462 closed issues, down by 1.</li>
 345 <li>592 issues total, up by 5.</li>
 346 </ul></li>
 347 <li><b>Details:</b><ul>
 348 <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>
 349 </ul></li>
 350 </ul>
 351 </li>
 352 <li>R43:
 353 2006-06-23 mid-term mailing.
 354 <ul>
 355 <li><b>Summary:</b><ul>
 356 <li>124 open issues, up by 14.</li>
 357 <li>463 closed issues, down by 1.</li>
 358 <li>587 issues total, up by 13.</li>
 359 </ul></li>
 360 <li><b>Details:</b><ul>
 361 <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>
 362 <li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#255">255</a>.</li>
 363 <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>
 364 </ul></li>
 365 </ul>
 366 </li>
 367 <li>R42:
 368 2006-04-21 post-Berlin mailing.
 369 <ul>
 370 <li><b>Summary:</b><ul>
 371 <li>110 open issues, down by 16.</li>
 372 <li>464 closed issues, up by 24.</li>
 373 <li>574 issues total, up by 8.</li>
 374 </ul></li>
 375 <li><b>Details:</b><ul>
 376 <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
 377 <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>
 378 <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-closed.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>
 379 <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>
 380 <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>
 381 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li>
 382 </ul></li>
 383 </ul>
 384 </li>
 385 <li>R41:
 386 2006-02-24 pre-Berlin mailing.
 387 <ul>
 388 <li><b>Summary:</b><ul>
 389 <li>126 open issues, up by 31.</li>
 390 <li>440 closed issues, up by 0.</li>
 391 <li>566 issues total, up by 31.</li>
 392 </ul></li>
 393 <li><b>Details:</b><ul>
 394 <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>
 395 <li>Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a> from Ready to Open.</li>
 396 <li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309">309</a>.</li>
 397 </ul></li>
 398 </ul>
 399 </li>
 400 <li>R40:
 401 2005-12-16 mid-term mailing.
 402 <ul>
 403 <li><b>Summary:</b><ul>
 404 <li>95 open issues.</li>
 405 <li>440 closed issues.</li>
 406 <li>535 issues total.</li>
 407 </ul></li>
 408 <li><b>Details:</b><ul>
 409 <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>.</li>
 410 </ul></li>
 411 </ul>
 412 </li>
 413 <li>R39:
 414 2005-10-14 post-Mont Tremblant mailing.
 415 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>.
 416 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.
 417 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.
 418 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.
 419 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.
 420 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
 421 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a> from New to Review.
 422 </li>
 423 <li>R38:
 424 2005-07-03 pre-Mont Tremblant mailing.
 425 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>.
 426 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>
 427 </li>
 428 <li>R37:
 429 2005-06 mid-term mailing.
 430 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>.
 431 </li>
 432 <li>R36:
 433 2005-04 post-Lillehammer mailing. All issues in "ready" status except
 434 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
 435 previously in "DR" status were moved to "WP".
 436 </li>
 437 <li>R35:
 438 2005-03 pre-Lillehammer mailing.
 439 </li>
 440 <li>R34:
 441 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>.
 442 </li>
 443 <li>R33:
 444 2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
 445 </li>
 446 <li>R32:
 447 2004-09 pre-Redmond mailing: reflects new proposed resolutions and
 448 new issues received after the 2004-07 mailing.  Added
 449 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>.
 450 </li>
 451 <li>R31:
 452 2004-07 mid-term mailing: reflects new proposed resolutions and
 453 new issues received after the post-Sydney mailing.  Added
 454 new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>.
 455 </li>
 456 <li>R30:
 457 Post-Sydney mailing: reflects decisions made at the Sydney meeting.
 458 Voted all "Ready" issues from R29 into the working paper.
 459 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-closed.html#462">462</a>.
 460 </li>
 461 <li>R29:
 462 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>.
 463 </li>
 464 <li>R28:
 465 Post-Kona mailing: reflects decisions made at the Kona meeting.
 466 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>.
 467 </li>
 468 <li>R27:
 469 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>.
 470 </li>
 471 <li>R26:
 472 Post-Oxford mailing: reflects decisions made at the Oxford meeting.
 473 All issues in Ready status were voted into DR status.  All issues in
 474 DR status were voted into WP status.
 475 </li>
 476 <li>R25:
 477 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>.
 478 </li>
 479 <li>R24:
 480 Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
 481 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
 482 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
 483 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
 484 concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
 485 </li>
 486 <li>R23:
 487 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>.
 488 Moved issues in the TC to TC status.
 489 </li>
 490 <li>R22:
 491 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>.
 492 </li>
 493 <li>R21:
 494 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>.
 495 </li>
 496 <li>R20:
 497 Post-Redmond mailing; reflects actions taken in Redmond.  Added
 498 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
 499 <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
 500 not discussed at the meeting.
 501
 502 All Ready issues were moved to DR status, with the exception of issues
 503 <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>.
 504
 505 Noteworthy issues discussed at Redmond include
 506 <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>,
 507 <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>.
 508 </li>
 509 <li>R19:
 510 Pre-Redmond mailing.  Added new issues
 511 <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>.
 512 </li>
 513 <li>R18:
 514 Post-Copenhagen mailing; reflects actions taken in Copenhagen.
 515 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
 516 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>.
 517
 518 Changed status of issues
 519 <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>
 520 <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>
 521 <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>
 522 <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>
 523 <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>
 524 <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>
 525 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>
 526 to DR.
 527
 528 Changed status of issues
 529 <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>
 530 <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>
 531 <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>
 532 <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>
 533 <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>
 534 <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>
 535 <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>
 536 <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>
 537 <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>
 538 to Ready.
 539
 540 Closed issues
 541 <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>
 542 <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>
 543 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
 544 as NAD.
 545
 546 </li>
 547 <li>R17:
 548 Pre-Copenhagen mailing.  Converted issues list to XML.  Added proposed
 549 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>.
 550 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>.
 551 </li>
 552 <li>R16:
 553 post-Toronto mailing; reflects actions taken in Toronto. Added new
 554 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
 555 <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>,
 556 <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>,
 557 <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>,
 558 <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>,
 559 <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>,
 560 <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>,
 561 <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>,
 562 <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>,
 563 <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>,
 564 <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>,
 565 <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>,
 566 <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>,
 567 <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
 568 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
 569 <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
 570 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
 571 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
 572 the bug in enough places.
 573 </li>
 574 <li>R15:
 575 pre-Toronto mailing. Added issues
 576 <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
 577 changes so that we pass Weblint tests.
 578 </li>
 579 <li>R14:
 580 post-Tokyo II mailing; reflects committee actions taken in
 581 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)
 582 </li>
 583 <li>R13:
 584 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>.
 585 </li>
 586 <li>R12:
 587 pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to
 588 <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
 589 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>.  Add further rationale to issue
 590 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>.
 591 </li>
 592 <li>R11:
 593 post-Kona mailing: Updated to reflect LWG and full committee actions
 594 in Kona (99-0048/N1224). Note changed resolution of issues
 595 <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>
 596 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
 597 "closed" documents.  Changed the proposed resolution of issue
 598 <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
 599 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>.
 600 </li>
 601 <li>R10:
 602 pre-Kona updated.  Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
 603 <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>,
 604 <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-active.html#190">190</a> to
 605 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
 606 </li>
 607 <li>R9:
 608 pre-Kona mailing.  Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to
 609 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
 610 "closed" documents. (99-0030/N1206, 25 Aug 99)
 611 </li>
 612 <li>R8:
 613 post-Dublin mailing. Updated to reflect LWG and full committee actions
 614 in Dublin. (99-0016/N1193, 21 Apr 99)
 615 </li>
 616 <li>R7:
 617 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>,
 618 <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>,
 619 <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>,
 620 <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)
 621 </li>
 622 <li>R6:
 623 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-active.html#128">128</a>,
 624 and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>.  (99-0007/N1194, 22 Feb 99)
 625 </li>
 626 <li>R5:
 627 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
 628 <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
 629 for making list public. (30 Dec 98)
 630 </li>
 631 <li>R4:
 632 post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
 633 <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
 634 issues corrected. (22 Oct 98)
 635 </li>
 636 <li>R3:
 637 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>
 638 added, many issues updated to reflect LWG consensus (12 Oct 98)
 639 </li>
 640 <li>R2:
 641 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,
 642 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98)
 643 </li>
 644 <li>R1:
 645 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
 646 format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98)
 647 </li>
 648 </ul>
 649
 650 <h2><a name="Status"></a>Issue Status</h2>
 651
 652   <p><b><a name="New">New</a></b> - The issue has not yet been
 653   reviewed by the LWG. Any <b>Proposed Resolution</b> is purely a
 654   suggestion from the issue submitter, and should not be construed as
 655   the view of LWG.</p>
 656
 657   <p><b><a name="Open">Open</a></b> - The LWG has discussed the issue
 658   but is not yet ready to move the issue forward. There are several
 659   possible reasons for open status:</p>
 660      <ul>
 661         <li>Consensus may have not yet have been reached as to how to deal
 662             with the issue.</li>
 663         <li>Informal consensus may have been reached, but the LWG awaits
 664             exact <b>Proposed Resolution</b> wording for review.</li>
 665         <li>The LWG wishes to consult additional technical experts before
 666             proceeding.</li>
 667         <li>The issue may require further study.</li>
 668      </ul>
 669
 670   <p>A <b>Proposed Resolution</b> for an open issue is still not be
 671   construed as the view of LWG. Comments on the current state of
 672   discussions are often given at the end of open issues in an italic
 673   font. Such comments are for information only and should not be given
 674   undue importance.</p>
 675
 676   <p><b><a name="Dup">Dup</a></b> - The LWG has reached consensus that
 677   the issue is a duplicate of another issue, and will not be further
 678   dealt with. A <b>Rationale</b> identifies the duplicated issue's
 679   issue number.  </p>
 680
 681   <p><b><a name="NAD">NAD</a></b> - The LWG has reached consensus that
 682   the issue is not a defect in the Standard.</p>
 683
 684   <p><b><a name="NAD Editorial">NAD Editorial</a></b> - The LWG has reached consensus that
 685   the issue can either be handled editorially, or is handled by a paper (usually
 686   linked to in the rationale).</p>
 687
 688   <p><b><a name="NAD Future">NAD Future</a></b> - In addition to the regular
 689   status, the LWG believes that this issue should be revisited at the
 690   next revision of the standard.</p>
 691
 692   <p><b><a name="Review">Review</a></b> - Exact wording of a
 693   <b>Proposed Resolution</b> is now available for review on an issue
 694   for which the LWG previously reached informal consensus.</p>
 695
 696   <p><b><a name="Tentatively Ready">Tentatively Ready</a></b> - The issue has
 697   been reviewed online, but not in a meeting, and some support has been formed
 698   for the proposed resolution.  Tentatively Ready issues may be moved to Ready
 699   and forwarded to full committee within the same meeting.  Unlike Ready issues
 700   they will be reviewed in subcommittee prior to forwarding to full committee.</p>
 701
 702   <p><b><a name="Ready">Ready</a></b> - The LWG has reached consensus
 703   that the issue is a defect in the Standard, the <b>Proposed
 704   Resolution</b> is correct, and the issue is ready to forward to the
 705   full committee for further action as a Defect Report (DR).</p>
 706
 707   <p><b><a name="DR">DR</a></b> - (Defect Report) - The full J16
 708   committee has voted to forward the issue to the Project Editor to be
 709   processed as a Potential Defect Report. The Project Editor reviews
 710   the issue, and then forwards it to the WG21 Convenor, who returns it
 711   to the full committee for final disposition. This issues list
 712   accords the status of DR to all these Defect Reports regardless of
 713   where they are in that process.</p>
 714
 715   <p><b><a name="TC">TC</a></b> - (Technical Corrigenda) - The full
 716   WG21 committee has voted to accept the Defect Report's Proposed
 717   Resolution as a Technical Corrigenda.  Action on this issue is thus
 718   complete and no further action is possible under ISO rules.</p>
 719
 720   <p><b><a name="TRDec">TRDec</a></b> - (Decimal TR defect) - The
 721   LWG has voted to accept the Defect Report's Proposed
 722   Resolution into the Decimal TR.  Action on this issue is thus
 723   complete and no further action is expected.</p>
 724
 725   <p><b><a name="WP">WP</a></b> - (Working Paper) - The proposed
 726   resolution has not been accepted as a Technical Corrigendum, but
 727   the full WG21 committee has voted to apply the Defect Report's Proposed
 728   Resolution to the working paper.</p>
 729
 730   <p><b>Pending</b> - This is a <i>status qualifier</i>.  When prepended to
 731   a status this indicates the issue has been
 732   processed by the committee, and a decision has been made to move the issue to
 733   the associated unqualified status.  However for logistical reasons the indicated
 734   outcome of the issue has not yet appeared in the latest working paper.
 735
 736   </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
 737   they first appear on the issues list. They may progress to
 738   <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
 739   is actively working on them. When the LWG has reached consensus on
 740   the disposition of an issue, the status will then change to
 741   <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
 742   <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
 743   forward Ready issues to the Project Editor, they are given the
 744   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
 745   become the basis for Technical Corrigenda (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>),
 746   or are closed without action other than a Record of Response
 747   (<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
 748   only issues which are truly defects in the Standard move to the
 749   formal ISO DR status.
 750   </p>
 751
 752
 753 <h2>Active Issues</h2>
 754 <hr>
 755 <h3><a name="23"></a>23. Num_get overflow result</h3>
 756 <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>
 757  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
 758 <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>
 759 <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>
 760 <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>
 761 <p><b>Discussion:</b></p>
 762 <p>The current description of numeric input does not account for the
 763 possibility of overflow. This is an implicit result of changing the
 764 description to rely on the definition of scanf() (which fails to
 765 report overflow), and conflicts with the documented behavior of
 766 traditional and current implementations. </p>
 767
 768 <p>Users expect, when reading a character sequence that results in a
 769 value unrepresentable in the specified type, to have an error
 770 reported. The standard as written does not permit this. </p>
 771
 772 <p><b>Further comments from Dietmar:</b></p>
 773
 774 <p>
 775 I don't feel comfortable with the proposed resolution to issue 23: It
 776 kind of simplifies the issue to much. Here is what is going on:
 777 </p>
 778
 779 <p>
 780 Currently, the behavior of numeric overflow is rather counter intuitive
 781 and hard to trace, so I will describe it briefly:
 782 </p>
 783
 784 <ul>
 785   <li>
 786     According to 22.2.2.1.2 [facet.num.get.virtuals]
 787     paragraph 11 <tt>failbit</tt> is set if <tt>scanf()</tt> would
 788     return an input error; otherwise a value is converted to the rules
 789     of <tt>scanf</tt>.
 790   </li>
 791   <li>
 792     <tt>scanf()</tt> is defined in terms of <tt>fscanf()</tt>.
 793   </li>
 794   <li>
 795     <tt>fscanf()</tt> returns an input failure if during conversion no
 796     character matching the conversion specification could be extracted
 797     before reaching EOF. This is the only reason for <tt>fscanf()</tt>
 798     to fail due to an input error and clearly does not apply to the case
 799     of overflow.
 800   </li>
 801   <li>
 802     Thus, the conversion is performed according to the rules of
 803     <tt>fscanf()</tt> which basically says that <tt>strtod</tt>,
 804     <tt>strtol()</tt>, etc. are to be used for the conversion.
 805   </li>
 806   <li>
 807     The <tt>strtod()</tt>, <tt>strtol()</tt>, etc. functions consume as
 808     many matching characters as there are and on overflow continue to
 809     consume matching characters but also return a value identical to
 810     the maximum (or minimum for signed types if there was a leading minus)
 811     value of the corresponding type and set <tt>errno</tt> to <tt>ERANGE</tt>.
 812   </li>
 813   <li>
 814     Thus, according to the current wording in the standard, overflows
 815     can be detected! All what is to be done is to check <tt>errno</tt>
 816     after reading an element and, of course, clearing <tt>errno</tt>
 817     before trying a conversion. With the current wording, it can be
 818     detected whether the overflow was due to a positive or negative
 819     number for signed types.
 820   </li>
 821 </ul>
 822
 823 <p><b>Further discussion from Redmond:</b></p>
 824
 825 <p>The basic problem is that we've defined our behavior,
 826 including our error-reporting behavior, in terms of C90.  However,
 827 C90's method of reporting overflow in scanf is not technically an
 828 "input error".  The <tt>strto_*</tt> functions are more precise.</p>
 829
 830 <p>There was general consensus that <tt>failbit</tt> should be set
 831 upon overflow.  We considered three options based on this:</p>
 832 <ol>
 833 <li>Set failbit upon conversion error (including overflow), and
 834     don't store any value.</li>
 835 <li>Set failbit upon conversion error, and also set <tt>errno</tt> to
 836     indicated the precise nature of the error.</li>
 837 <li>Set failbit upon conversion error.  If the error was due to
 838     overflow, store +-numeric_limits&lt;T&gt;::max() as an
 839     overflow indication.</li>
 840 </ol>
 841
 842 <p>Straw poll: (1) 5; (2) 0; (3) 8.</p>
 843
 844
 845 <p>Discussed at Lillehammer.  General outline of what we want the
 846   solution to look like: we want to say that overflow is an error, and
 847   provide a way to distinguish overflow from other kinds of errors.
 848   Choose candidate field the same way scanf does, but don't describe
 849   the rest of the process in terms of format.  If a finite input field
 850   is too large (positive or negative) to be represented as a finite
 851   value, then set failbit and assign the nearest representable value.
 852   Bill will provide wording.</p>
 853
 854 <p>
 855 Discussed at Toronto:
 856 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2327.pdf">N2327</a>
 857 is in alignment with the direction we wanted to go with in Lillehammer.  Bill
 858 to work on.
 859 </p>
 860
 861
 862
 863 <p><b>Proposed resolution:</b></p>
 864
 865 <p>
 866 Change 22.2.2.1.2 [facet.num.get.virtuals], end of p3:
 867 </p>
 868
 869 <blockquote>
 870 <p>
 871 <b>Stage 3:</b> <del>The result of stage 2 processing can be one of</del>
 872 <ins>The sequence of <tt>char</tt>s accumulated in stage 2 (the field) is
 873 converted to a numeric value by the rules of one of the functions declared
 874 in the header <tt>&lt;cstdlib&gt;</tt>:</ins>
 875 </p>
 876 <ul>
 877 <li>
 878 <del>A sequence of <tt>char</tt>s has been accumulated in stage 2 that is
 879 converted (according to the rules of <tt>scanf</tt>) to a value of the
 880 type of <i>val</i>. This value is stored in <i>val</i> and <tt>ios_base::goodbit</tt> is
 881 stored in <i>err</i>.</del>
 882 <ins>For a signed integer value, the function <tt>strtoll</tt>.</ins>
 883 </li>
 884 <li>
 885 <del>The sequence of <tt>char</tt>s accumulated in stage 2 would have caused
 886 <tt>scanf</tt> to report an input failure. <tt>ios_base::failbit</tt> is
 887 assigned to <i>err</i>.</del>
 888 <ins>For an unsigned integer value, the function <tt>strtoull</tt>.</ins>
 889 </li>
 890 <li>
 891 <ins>For a floating-point value, the function <tt>strtold</tt>.</ins>
 892 </li>
 893 </ul>
 894 <p>
 895 <ins>The numeric value to be stored can be one of:</ins>
 896 </p>
 897 <ul>
 898 <li><ins>zero, if the conversion function fails to convert the entire field.
 899 <tt>ios_base::failbit</tt> is assigned to err.</ins></li>
 900 <li><ins>the most positive representable value, if the field represents a value
 901 too large positive to be represented in <i>val</i>. <tt>ios_base::failbit</tt> is assigned
 902 to <i>err</i>.</ins></li>
 903 <li><ins>the most negative representable value (zero for unsigned integer), if
 904 the field represents a value too large negative to be represented in <i>val</i>.
 905 <tt>ios_base::failbit</tt> is assigned to <i>err</i>.</ins></li>
 906 <li><ins>the converted value, otherwise.</ins></li>
 907 </ul>
 908
 909 <p><ins>
 910 The resultant numeric value is stored in <i>val</i>.
 911 </ins></p>
 912 </blockquote>
 913
 914 <p>
 915 Change 22.2.2.1.2 [facet.num.get.virtuals], p6-p7:
 916 </p>
 917
 918 <blockquote>
 919 <pre>iter_type do_get(iter_type <i>in</i>, iter_type <i>end</i>, ios_base&amp; <i>str</i>,
 920                  ios_base::iostate&amp; <i>err</i>, bool&amp; <i>val</i>) const;
 921 </pre>
 922 <blockquote>
 923 <p>
 924 -6- <i>Effects:</i> If
 925 <tt>(<i>str</i>.flags()&amp;ios_base::boolalpha)==0</tt> then input
 926 proceeds as it would for a <tt>long</tt> except that if a value is being
 927 stored into <i>val</i>, the value is determined according to the
 928 following: If the value to be stored is 0 then <tt>false</tt> is stored.
 929 If the value is 1 then <tt>true</tt> is stored. Otherwise
 930 <del><tt><i>err</i>|=ios_base::failbit</tt> is performed and no value</del> <ins><tt>true</tt></ins> is
 931 stored<del>.</del> <ins>and <tt>ios_base::failbit</tt> is assigned to <i>err</i>.</ins>
 932 </p>
 933 <p>
 934 -7- Otherwise target sequences are determined "as if" by calling the
 935 members <tt>falsename()</tt> and <tt>truename()</tt> of the facet
 936 obtained by <tt>use_facet&lt;numpunct&lt;charT&gt;
 937 &gt;(<i>str</i>.getloc())</tt>. Successive characters in the range
 938 <tt>[<i>in</i>,<i>end</i>)</tt> (see 23.1.1) are obtained and matched
 939 against corresponding positions in the target sequences only as
 940 necessary to identify a unique match. The input iterator <i>in</i> is
 941 compared to <i>end</i> only when necessary to obtain a character. If <del>and
 942 only if</del> a target sequence is uniquely matched, <i>val</i> is set to the
 943 corresponding value. <ins>Otherwise <tt>false</tt> is stored and <tt>ios_base::failbit</tt>
 944 is assigned to <i>err</i>.</ins>
 945 </p>
 946 </blockquote>
 947 </blockquote>
 948
 949
 950
 951
 952
 953 <hr>
 954 <h3><a name="96"></a>96. Vector&lt;bool&gt; is not a container</h3>
 955 <p><b>Section:</b> 23.2.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
 956  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
 957 <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>
 958 <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>
 959 <p><b>Discussion:</b></p>
 960 <p><tt>vector&lt;bool&gt;</tt> is not a container as its reference and
 961 pointer types are not references and pointers. </p>
 962
 963 <p>Also it forces everyone to have a space optimization instead of a
 964 speed one.</p>
 965
 966 <p><b>See also:</b> 99-0008 == N1185 Vector&lt;bool&gt; is
 967 Nonconforming, Forces Optimization Choice.</p>
 968
 969 <p><i>[In Santa Cruz the LWG felt that this was Not A Defect.]</i></p>
 970
 971
 972 <p><i>[In Dublin many present felt that failure to meet Container
 973 requirements was a defect. There was disagreement as to whether
 974 or not the optimization requirements constituted a defect.]</i></p>
 975
 976
 977 <p><i>[The LWG looked at the following resolutions in some detail:
 978 <br>
 979 &nbsp;&nbsp;&nbsp;&nbsp; * Not A Defect.<br>
 980 &nbsp;&nbsp;&nbsp;&nbsp; * Add a note explaining that vector&lt;bool&gt; does not meet
 981 Container requirements.<br>
 982 &nbsp;&nbsp;&nbsp;&nbsp; * Remove vector&lt;bool&gt;.<br>
 983 &nbsp;&nbsp;&nbsp;&nbsp; * Add a new category of container requirements which
 984 vector&lt;bool&gt; would meet.<br>
 985 &nbsp;&nbsp;&nbsp;&nbsp; * Rename vector&lt;bool&gt;.<br>
 986 <br>
 987 No alternative had strong, wide-spread, support and every alternative
 988 had at least one "over my dead body" response.<br>
 989 <br>
 990 There was also mention of a transition scheme something like (1) add
 991 vector_bool and deprecate vector&lt;bool&gt; in the next standard. (2)
 992 Remove vector&lt;bool&gt; in the following standard.]</i></p>
 993
 994
 995 <p><i>[Modifying container requirements to permit returning proxies
 996 (thus allowing container requirements conforming vector&lt;bool&gt;)
 997 was also discussed.]</i></p>
 998
 999
1000 <p><i>[It was also noted that there is a partial but ugly workaround in
1001 that vector&lt;bool&gt; may be further specialized with a customer
1002 allocator.]</i></p>
1003
1004
1005 <p><i>[Kona: Herb Sutter presented his paper J16/99-0035==WG21/N1211,
1006 vector&lt;bool&gt;: More Problems, Better Solutions. Much discussion
1007 of a two step approach: a) deprecate, b) provide replacement under a
1008 new name.  LWG straw vote on that: 1-favor, 11-could live with, 2-over
1009 my dead body.  This resolution was mentioned in the LWG report to the
1010 full committee, where several additional committee members indicated
1011 over-my-dead-body positions.]</i></p>
1012
1013
1014 <p>Discussed at Lillehammer.  General agreement that we should
1015   deprecate vector&lt;bool&gt; and introduce this functionality under
1016   a different name, e.g. bit_vector.  This might make it possible to
1017   remove the vector&lt;bool&gt; specialization in the standard that comes
1018   after C++0x. There was also a suggestion that
1019   in C++0x we could additional say that it's implementation defined
1020   whether vector&lt;bool&gt; refers to the specialization or to the
1021   primary template, but there wasn't general agreement that this was a
1022   good idea.</p>
1023
1024 <p>We need a paper for the new bit_vector class.</p>
1025
1026
1027
1028
1029 <p><b>Proposed resolution:</b></p>
1030 <p>
1031 We now have:
1032 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2050.pdf">N2050</a>
1033 and
1034 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2160.html">N2160</a>.
1035 </p>
1036
1037 <p><i>[
1038 Batavia: The LWG feels we need something closer to SGI's <tt>bitvector</tt> to ease migration
1039 from <tt>vector&lt;bool&gt;</tt>.  Although some of the funcitonality from
1040 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2050.pdf">N2050</a>
1041 could well be used in such a template.  The concern is easing the API migration for those
1042 users who want to continue using a bit-packed container.  Alan and Beman to work.
1043 ]</i></p>
1044
1045
1046
1047
1048
1049
1050 <hr>
1051 <h3><a name="128"></a>128. Need open_mode() function for file stream, string streams, file buffers, and string&nbsp; buffers</h3>
1052 <p><b>Section:</b> 27.7 [string.streams], 27.8 [file.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
1053  <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-02-22</p>
1054 <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>
1055 <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>
1056 <p><b>Discussion:</b></p>
1057 <p>The following question came from Thorsten Herlemann:</p>
1058
1059 <blockquote>
1060   <p>You can set a mode when constructing or opening a file-stream or
1061   filebuf, e.g.  ios::in, ios::out, ios::binary, ... But how can I get
1062   that mode later on, e.g. in my own operator &lt;&lt; or operator
1063   &gt;&gt; or when I want to check whether a file-stream or
1064   file-buffer object passed as parameter is opened for input or output
1065   or binary? Is there no possibility? Is this a design-error in the
1066   standard C++ library? </p>
1067 </blockquote>
1068
1069 <p>It is indeed impossible to find out what a stream's or stream
1070 buffer's open mode is, and without that knowledge you don't know
1071 how certain operations behave. Just think of the append mode. </p>
1072
1073 <p>Both streams and stream buffers should have a <tt>mode()</tt> function that returns the
1074 current open mode setting. </p>
1075
1076 <p><i>[
1077 post Bellevue:  Alisdair requested to re-Open.
1078 ]</i></p>
1079
1080
1081
1082
1083 <p><b>Proposed resolution:</b></p>
1084 <p>For stream buffers, add a function to the base class as a non-virtual function
1085 qualified as const to 27.5.2 [streambuf]:</p>
1086
1087 <p>&nbsp;&nbsp;&nbsp;&nbsp;<tt>openmode mode() const</tt>;</p>
1088
1089 <p><b>&nbsp;&nbsp;&nbsp; Returns</b> the current open mode.</p>
1090
1091 <p>With streams, I'm not sure what to suggest. In principle, the mode
1092 could already be returned by <tt>ios_base</tt>, but the mode is only
1093 initialized for file and string stream objects, unless I'm overlooking
1094 anything. For this reason it should be added to the most derived
1095 stream classes. Alternatively, it could be added to <tt>basic_ios</tt>
1096 and would be default initialized in <tt>basic_ios&lt;&gt;::init()</tt>.</p>
1097
1098
1099 <p><b>Rationale:</b></p>
1100 <p>This might be an interesting extension for some future, but it is
1101 not a defect in the current standard. The Proposed Resolution is
1102 retained for future reference.</p>
1103
1104
1105
1106
1107
1108 <hr>
1109 <h3><a name="180"></a>180. Container member iterator arguments constness has unintended consequences</h3>
1110 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
1111  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 1999-07-01</p>
1112 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p>
1113 <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>
1114 <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>
1115 <p><b>Discussion:</b></p>
1116 <p>It is the constness of the container which should control whether
1117 it can be modified through a member function such as erase(), not the
1118 constness of the iterators. The iterators only serve to give
1119 positioning information.</p>
1120
1121 <p>Here's a simple and typical example problem which is currently very
1122 difficult or impossible to solve without the change proposed
1123 below.</p>
1124
1125 <p>Wrap a standard container C in a class W which allows clients to
1126 find and read (but not modify) a subrange of (C.begin(), C.end()]. The
1127 only modification clients are allowed to make to elements in this
1128 subrange is to erase them from C through the use of a member function
1129 of W.</p>
1130
1131 <p><i>[
1132 post Bellevue, Alisdair adds:
1133 ]</i></p>
1134
1135
1136 <blockquote>
1137 <p>
1138 This issue was implemented by
1139 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2350.pdf">N2350</a>
1140 for everything but <tt>basic_string</tt>.
1141 </p>
1142
1143 <p>
1144 Note that the specific example in this issue (<tt>basic_string</tt>) is the one place
1145 we forgot to amend in
1146 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2350.pdf">N2350</a>,
1147 so we might open this issue for that
1148 single container?
1149 </p>
1150 </blockquote>
1151
1152
1153
1154 <p><b>Proposed resolution:</b></p>
1155 <p>Change all non-const iterator parameters of standard library
1156 container member functions to accept const_iterator parameters.
1157 Note that this change applies to all library clauses, including
1158 strings.</p>
1159
1160 <p>For example, in   21.3.5.5  change:<br>
1161 <br>
1162 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>iterator erase(iterator p);</tt><br>
1163 <br>
1164 to:<br>
1165 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>iterator erase(const_iterator p);</tt>
1166 </p>
1167
1168
1169 <p><b>Rationale:</b></p>
1170 <p>The issue was discussed at length. It was generally agreed that 1)
1171 There is no major technical argument against the change (although
1172 there is a minor argument that some obscure programs may break), and
1173 2) Such a change would not break const correctness. The concerns about
1174 making the change were 1) it is user detectable (although only in
1175 boundary cases), 2) it changes a large number of signatures, and 3) it
1176 seems more of a design issue that an out-and-out defect.</p>
1177
1178 <p>The LWG believes that this issue should be considered as part of a
1179 general review of const issues for the next revision of the
1180 standard. Also see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>.</p>
1181
1182
1183
1184
1185 <hr>
1186 <h3><a name="190"></a>190. min() and max() functions should be std::binary_functions</h3>
1187 <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#Open">Open</a>
1188  <b>Submitter:</b> Mark Rintoul <b>Date:</b> 1999-08-26</p>
1189 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.min.max">active issues</a> in [alg.min.max].</p>
1190 <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>
1191 <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>
1192 <p><b>Discussion:</b></p>
1193 <p>Both std::min and std::max are defined as template functions.  This
1194 is very different than the definition of std::plus (and similar
1195 structs) which are defined as function objects which inherit
1196 std::binary_function.<br>
1197 <br>
1198         This lack of inheritance leaves std::min and std::max somewhat useless in standard library algorithms which require
1199 a function object that inherits std::binary_function.</p>
1200
1201 <p><i>[
1202 post Bellevue:  Alisdair requested to re-Open.
1203 ]</i></p>
1204
1205
1206
1207
1208 <p><b>Rationale:</b></p>
1209 <p>Although perhaps an unfortunate design decision, the omission is not a defect
1210 in the current standard.&nbsp; A future standard may wish to consider additional
1211 function objects.</p>
1212
1213
1214
1215
1216 <hr>
1217 <h3><a name="255"></a>255. Why do <tt>basic_streambuf&lt;&gt;::pbump()</tt> and <tt>gbump()</tt> take an int?</h3>
1218 <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>
1219  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-08-12</p>
1220 <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>
1221 <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>
1222 <p><b>Discussion:</b></p>
1223 <p>
1224 The basic_streambuf members gbump() and pbump() are specified to take an
1225 int argument. This requirement prevents the functions from effectively
1226 manipulating buffers larger than std::numeric_limits&lt;int&gt;::max()
1227 characters. It also makes the common use case for these functions
1228 somewhat difficult as many compilers will issue a warning when an
1229 argument of type larger than int (such as ptrdiff_t on LLP64
1230 architectures) is passed to either of the function. Since it's often the
1231 result of the subtraction of two pointers that is passed to the
1232 functions, a cast is necessary to silence such warnings. Finally, the
1233 usage of a native type in the functions signatures is inconsistent with
1234 other member functions (such as sgetn() and sputn()) that manipulate the
1235 underlying character buffer. Those functions take a streamsize argument.
1236 </p>
1237
1238
1239 <p><b>Proposed resolution:</b></p>
1240 <p>
1241 Change the signatures of these functions in the synopsis of template
1242 class basic_streambuf (27.5.2) and in their descriptions (27.5.2.3.1, p4
1243 and 27.5.2.3.2, p4) to take a streamsize argument.
1244 </p>
1245
1246 <p>
1247 Although this change has the potential of changing the ABI of the
1248 library, the change will affect only platforms where int is different
1249 than the definition of streamsize. However, since both functions are
1250 typically inline (they are on all known implementations), even on such
1251 platforms the change will not affect any user code unless it explicitly
1252 relies on the existing type of the functions (e.g., by taking their
1253 address). Such a possibility is IMO quite remote.
1254 </p>
1255
1256 <p>
1257 Alternate Suggestion from Howard Hinnant, c++std-lib-7780:
1258 </p>
1259
1260 <p>
1261 This is something of a nit, but I'm wondering if streamoff wouldn't be a
1262 better choice than streamsize.  The argument to pbump and gbump MUST be
1263 signed.  But the standard has this to say about streamsize
1264 (27.4.1/2/Footnote):
1265 </p>
1266
1267 <blockquote><p>
1268      [Footnote: streamsize is used in most places where ISO C would use
1269      size_t.  Most of the uses of streamsize could use size_t, except for
1270      the strstreambuf constructors, which require negative values. It
1271      should probably be the signed type corresponding to size_t (which is
1272      what Posix.2 calls ssize_t). --- end footnote]
1273 </p></blockquote>
1274
1275 <p>
1276 This seems a little weak for the argument to pbump and gbump.  Should we
1277 ever really get rid of strstream, this footnote might go with it, along
1278 with the reason to make streamsize signed.
1279 </p>
1280
1281
1282 <p><b>Rationale:</b></p>
1283 <p>The LWG believes this change is too big for now.  We may wish to
1284 reconsider this for a future revision of the standard.  One
1285 possibility is overloading pbump, rather than changing the
1286 signature.</p>
1287 <p><i>[
1288 [2006-05-04: Reopened at the request of Chris (Krzysztof ?elechowski)]
1289 ]</i></p>
1290
1291
1292
1293
1294
1295 <hr>
1296 <h3><a name="290"></a>290. Requirements to for_each and its function object</h3>
1297 <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>
1298  <b>Submitter:</b> Angelika Langer <b>Date:</b> 2001-01-03</p>
1299 <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>
1300 <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>
1301 <p><b>Discussion:</b></p>
1302 <p>The specification of the for_each algorithm does not have a
1303 "Requires" section, which means that there are no
1304 restrictions imposed on the function object whatsoever. In essence it
1305 means that I can provide any function object with arbitrary side
1306 effects and I can still expect a predictable result. In particular I
1307 can expect that the function object is applied exactly last - first
1308 times, which is promised in the "Complexity" section.
1309 </p>
1310
1311 <p>I don't see how any implementation can give such a guarantee
1312 without imposing requirements on the function object.
1313 </p>
1314
1315 <p>Just as an example: consider a function object that removes
1316 elements from the input sequence.  In that case, what does the
1317 complexity guarantee (applies f exactly last - first times) mean?
1318 </p>
1319
1320 <p>One can argue that this is obviously a nonsensical application and
1321 a theoretical case, which unfortunately it isn't.  I have seen
1322 programmers shooting themselves in the foot this way, and they did not
1323 understand that there are restrictions even if the description of the
1324 algorithm does not say so.
1325 </p>
1326 <p><i>[Lillehammer: This is more general than for_each.  We don't want
1327   the function object in transform invalidiating iterators
1328   either. There should be a note somewhere in clause 17 (17, not 25)
1329   saying that user code operating on a range may not invalidate
1330   iterators unless otherwise specified.  Bill will provide wording.]</i></p>
1331
1332
1333
1334 <p><b>Proposed resolution:</b></p>
1335
1336
1337
1338
1339
1340
1341 <hr>
1342 <h3><a name="299"></a>299. Incorrect return types for iterator dereference</h3>
1343 <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>
1344  <b>Submitter:</b> John Potter <b>Date:</b> 2001-01-22</p>
1345 <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>
1346 <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>
1347 <p><b>Discussion:</b></p>
1348 <p>
1349 In section 24.1.4 [bidirectional.iterators],
1350 Table 75 gives the return type of *r-- as convertible to T.  This is
1351 not consistent with Table 74 which gives the return type of *r++ as
1352 T&amp;.  *r++ = t is valid while *r-- = t is invalid.
1353 </p>
1354
1355 <p>
1356 In section 24.1.5 [random.access.iterators],
1357 Table 76 gives the return type of a[n] as convertible to T.  This is
1358 not consistent with the semantics of *(a + n) which returns T&amp; by
1359 Table 74.  *(a + n) = t is valid while a[n] = t is invalid.
1360 </p>
1361
1362 <p>
1363 Discussion from the Copenhagen meeting: the first part is
1364 uncontroversial.  The second part, operator[] for Random Access
1365 Iterators, requires more thought.  There are reasonable arguments on
1366 both sides.  Return by value from operator[] enables some potentially
1367 useful iterators, e.g. a random access "iota iterator" (a.k.a
1368 "counting iterator" or "int iterator").  There isn't any obvious way
1369 to do this with return-by-reference, since the reference would be to a
1370 temporary.  On the other hand, <tt>reverse_iterator</tt> takes an
1371 arbitrary Random Access Iterator as template argument, and its
1372 operator[] returns by reference.  If we decided that the return type
1373 in Table 76 was correct, we would have to change
1374 <tt>reverse_iterator</tt>.  This change would probably affect user
1375 code.
1376 </p>
1377
1378 <p>
1379 History: the contradiction between <tt>reverse_iterator</tt> and the
1380 Random Access Iterator requirements has been present from an early
1381 stage.  In both the STL proposal adopted by the committee
1382 (N0527==94-0140) and the STL technical report (HPL-95-11 (R.1), by
1383 Stepanov and Lee), the Random Access Iterator requirements say that
1384 operator[]'s return value is "convertible to T".  In N0527
1385 reverse_iterator's operator[] returns by value, but in HPL-95-11
1386 (R.1), and in the STL implementation that HP released to the public,
1387 reverse_iterator's operator[] returns by reference.  In 1995, the
1388 standard was amended to reflect the contents of HPL-95-11 (R.1).  The
1389 original intent for operator[] is unclear.
1390 </p>
1391
1392 <p>
1393 In the long term it may be desirable to add more fine-grained
1394 iterator requirements, so that access method and traversal strategy
1395 can be decoupled.  (See "Improved Iterator Categories and
1396 Requirements", N1297 = 01-0011, by Jeremy Siek.)  Any decisions
1397 about issue 299 should keep this possibility in mind.
1398 </p>
1399
1400 <p>Further discussion: I propose a compromise between John Potter's
1401 resolution, which requires <tt>T&amp;</tt> as the return type of
1402 <tt>a[n]</tt>, and the current wording, which requires convertible to
1403 <tt>T</tt>. The compromise is to keep the convertible to <tt>T</tt>
1404 for the return type of the expression <tt>a[n]</tt>, but to also add
1405 <tt>a[n] = t</tt> as a valid expression. This compromise "saves" the
1406 common case uses of random access iterators, while at the same time
1407 allowing iterators such as counting iterator and caching file
1408 iterators to remain random access iterators (iterators where the
1409 lifetime of the object returned by <tt>operator*()</tt> is tied to the
1410 lifetime of the iterator).
1411 </p>
1412
1413 <p>
1414 Note that the compromise resolution necessitates a change to
1415 <tt>reverse_iterator</tt>. It would need to use a proxy to support
1416 <tt>a[n] = t</tt>.
1417 </p>
1418
1419 <p>
1420 Note also there is one kind of mutable random access iterator that
1421 will no longer meet the new requirements. Currently, iterators that
1422 return an r-value from <tt>operator[]</tt> meet the requirements for a
1423 mutable random access iterartor, even though the expression <tt>a[n] =
1424 t</tt> will only modify a temporary that goes away. With this proposed
1425 resolution, <tt>a[n] = t</tt> will be required to have the same
1426 operational semantics as <tt>*(a + n) = t</tt>.
1427 </p>
1428
1429
1430
1431 <p><b>Proposed resolution:</b></p>
1432
1433 <p>
1434 In section 24.1.4 [lib.bidirectdional.iterators], change the return
1435 type in table 75 from "convertible to <tt>T</tt>" to
1436 <tt>T&amp;</tt>.
1437 </p>
1438
1439 <p>
1440 In section 24.1.5 [lib.random.access.iterators], change the
1441 operational semantics for <tt>a[n]</tt> to " the r-value of
1442 <tt>a[n]</tt> is equivalent to the r-value of <tt>*(a +
1443 n)</tt>". Add a new row in the table for the expression <tt>a[n] = t</tt>
1444 with a return type of convertible to <tt>T</tt> and operational semantics of
1445 <tt>*(a + n) = t</tt>.
1446 </p>
1447
1448 <p><i>[Lillehammer: Real problem, but should be addressed as part of
1449   iterator redesign]</i></p>
1450
1451
1452
1453
1454
1455
1456
1457
1458 <hr>
1459 <h3><a name="309"></a>309. Does sentry catch exceptions?</h3>
1460 <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>
1461  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-03-19</p>
1462 <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>
1463 <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>
1464 <p><b>Discussion:</b></p>
1465 <p>
1466 The descriptions of the constructors of basic_istream&lt;&gt;::sentry
1467 (27.6.1.1.3 [istream::sentry]) and basic_ostream&lt;&gt;::sentry
1468 (27.6.2.4 [ostream::sentry]) do not explain what the functions do in
1469 case an exception is thrown while they execute. Some current
1470 implementations allow all exceptions to propagate, others catch them
1471 and set ios_base::badbit instead, still others catch some but let
1472 others propagate.
1473 </p>
1474
1475 <p>
1476 The text also mentions that the functions may call setstate(failbit)
1477 (without actually saying on what object, but presumably the stream
1478 argument is meant).  That may have been fine for
1479 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
1480 the function performs an input operation which may fail. However,
1481 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
1482 clarify that the function should actually call setstate(failbit |
1483 eofbit), so the sentence in p3 is redundant or even somewhat
1484 contradictory.
1485 </p>
1486
1487 <p>
1488 The same sentence that appears in 27.6.2.4 [ostream::sentry], p3
1489 doesn't seem to be very meaningful for basic_istream&lt;&gt;::sentry
1490 which performs no input. It is actually rather misleading since it
1491 would appear to guide library implementers to calling
1492 setstate(failbit) when os.tie()-&gt;flush(), the only called function,
1493 throws an exception (typically, it's badbit that's set in response to
1494 such an event).
1495 </p>
1496
1497 <p><b>Additional comments from Martin, who isn't comfortable with the
1498     current proposed resolution</b> (see c++std-lib-11530)</p>
1499
1500 <p>
1501 The istream::sentry ctor says nothing about how the function
1502 deals with exemptions (27.6.1.1.2, p1 says that the class is
1503 responsible for doing "exception safe"(*) prefix and suffix
1504 operations but it doesn't explain what level of exception
1505 safety the class promises to provide). The mockup example
1506 of a "typical implementation of the sentry ctor" given in
1507 27.6.1.1.2, p6, removed in ISO/IEC 14882:2003, doesn't show
1508 exception handling, either. Since the ctor is not classified
1509 as a formatted or unformatted input function, the text in
1510 27.6.1.1, p1 through p4 does not apply. All this would seem
1511 to suggest that the sentry ctor should not catch or in any
1512 way handle exceptions thrown from any functions it may call.
1513 Thus, the typical implementation of an istream extractor may
1514 look something like [1].
1515 </p>
1516
1517 <p>
1518 The problem with [1] is that while it correctly sets ios::badbit
1519 if an exception is thrown from one of the functions called from
1520 the sentry ctor, if the sentry ctor reaches EOF while extracting
1521 whitespace from a stream that has eofbit or failbit set in
1522 exceptions(), it will cause an ios::failure to be thrown, which
1523 will in turn cause the extractor to set ios::badbit.
1524 </p>
1525
1526 <p>
1527 The only straightforward way to prevent this behavior is to
1528 move the definition of the sentry object in the extractor
1529 above the try block (as suggested by the example in 22.2.8,
1530 p9 and also indirectly supported by 27.6.1.3, p1). See [2].
1531 But such an implementation will allow exceptions thrown from
1532 functions called from the ctor to freely propagate to the
1533 caller regardless of the setting of ios::badbit in the stream
1534 object's exceptions().
1535 </p>
1536
1537 <p>
1538 So since neither [1] nor [2] behaves as expected, the only
1539 possible solution is to have the sentry ctor catch exceptions
1540 thrown from called functions, set badbit, and propagate those
1541 exceptions if badbit is also set in exceptions(). (Another
1542 solution exists that deals with both kinds of sentries, but
1543 the code is non-obvious and cumbersome -- see [3].)
1544 </p>
1545
1546 <p>
1547 Please note that, as the issue points out, current libraries
1548 do not behave consistently, suggesting  that implementors are
1549 not quite clear on the exception handling in istream::sentry,
1550 despite the fact that some LWG members might feel otherwise.
1551 (As documented by the parenthetical comment here:
1552 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1480.html#309)
1553 </p>
1554
1555 <p>
1556 Also please note that those LWG members who in Copenhagen
1557 felt that "a sentry's constructor should not catch exceptions,
1558 because sentries should only be used within (un)formatted input
1559 functions and that exception handling is the responsibility of
1560 those functions, not of the sentries," as noted here
1561 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1310.html#309
1562 would in effect be either arguing for the behavior described
1563 in [1] or for extractors implemented along the lines of [3].
1564 </p>
1565
1566 <p>
1567 The original proposed resolution (Revision 25 of the issues
1568 list) clarifies the role of the sentry ctor WRT exception
1569 handling by making it clear that extractors (both library
1570 or user-defined) should be implemented along the lines of
1571 [2] (as opposed to [1]) and that no exception thrown from
1572 the callees should propagate out of either function unless
1573 badbit is also set in exceptions().
1574 </p>
1575
1576
1577 <p>[1] Extractor that catches exceptions thrown from sentry:</p>
1578
1579 <blockquote>
1580 <pre>struct S { long i; };
1581
1582 istream&amp; operator&gt;&gt; (istream &amp;strm, S &amp;s)
1583 {
1584     ios::iostate err = ios::goodbit;
1585     try {
1586         const istream::sentry guard (strm, false);
1587         if (guard) {
1588             use_facet&lt;num_get&lt;char&gt; &gt;(strm.getloc ())
1589                 .get (istreambuf_iterator&lt;char&gt;(strm),
1590                       istreambuf_iterator&lt;char&gt;(),
1591                       strm, err, s.i);
1592         }
1593     }
1594     catch (...) {
1595         bool rethrow;
1596         try {
1597             strm.setstate (ios::badbit);
1598             rethrow = false;
1599         }
1600         catch (...) {
1601             rethrow = true;
1602         }
1603         if (rethrow)
1604             throw;
1605     }
1606     if (err)
1607         strm.setstate (err);
1608     return strm;
1609 }
1610 </pre>
1611 </blockquote>
1612
1613 <p>[2] Extractor that propagates exceptions thrown from sentry:</p>
1614
1615 <blockquote>
1616 <pre>istream&amp; operator&gt;&gt; (istream &amp;strm, S &amp;s)
1617 {
1618     istream::sentry guard (strm, false);
1619     if (guard) {
1620         ios::iostate err = ios::goodbit;
1621         try {
1622             use_facet&lt;num_get&lt;char&gt; &gt;(strm.getloc ())
1623                 .get (istreambuf_iterator&lt;char&gt;(strm),
1624                       istreambuf_iterator&lt;char&gt;(),
1625                       strm, err, s.i);
1626         }
1627         catch (...) {
1628             bool rethrow;
1629             try {
1630                 strm.setstate (ios::badbit);
1631                 rethrow = false;
1632             }
1633             catch (...) {
1634                 rethrow = true;
1635             }
1636             if (rethrow)
1637                 throw;
1638         }
1639         if (err)
1640             strm.setstate (err);
1641     }
1642     return strm;
1643 }
1644 </pre>
1645 </blockquote>
1646
1647 <p>
1648 [3] Extractor that catches exceptions thrown from sentry
1649 but doesn't set badbit if the exception was thrown as a
1650 result of a call to strm.clear().
1651 </p>
1652
1653 <blockquote>
1654 <pre>istream&amp; operator&gt;&gt; (istream &amp;strm, S &amp;s)
1655 {
1656     const ios::iostate state = strm.rdstate ();
1657     const ios::iostate except = strm.exceptions ();
1658     ios::iostate err = std::ios::goodbit;
1659     bool thrown = true;
1660     try {
1661         const istream::sentry guard (strm, false);
1662         thrown = false;
1663         if (guard) {
1664             use_facet&lt;num_get&lt;char&gt; &gt;(strm.getloc ())
1665                 .get (istreambuf_iterator&lt;char&gt;(strm),
1666                       istreambuf_iterator&lt;char&gt;(),
1667                       strm, err, s.i);
1668         }
1669     }
1670     catch (...) {
1671         if (thrown &amp;&amp; state &amp; except)
1672             throw;
1673         try {
1674             strm.setstate (ios::badbit);
1675             thrown = false;
1676         }
1677         catch (...) {
1678             thrown = true;
1679         }
1680         if (thrown)
1681             throw;
1682     }
1683     if (err)
1684         strm.setstate (err);
1685
1686     return strm;
1687 }
1688 </pre>
1689 </blockquote>
1690
1691 <p>
1692 [Pre-Berlin] Reopened at the request of Paolo Carlini and Steve Clamage.
1693 </p>
1694
1695 <p>
1696 [Pre-Portland] A relevant newsgroup post:
1697 </p>
1698
1699 <p>
1700 The current proposed resolution of issue #309
1701 (http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309)  is
1702 unacceptable.   I write commerical software and coding around this
1703 makes my code ugly, non-intuitive, and requires comments referring
1704 people to this very issue.   Following is the full explanation of my
1705 experience.
1706 </p>
1707 <p>
1708 In the course of writing software for commercial use, I constructed
1709 std::ifstream's based on user-supplied pathnames on typical POSIX
1710 systems.
1711 </p>
1712 <p>
1713 It was expected that some files that opened successfully might not read
1714 successfully -- such as a pathname which actually refered to a
1715 directory.   Intuitively, I expected the streambuffer underflow() code
1716 to throw an exception in this situation, and recent implementations of
1717 libstdc++'s basic_filebuf do just that (as well as many of my own
1718 custom streambufs).
1719 </p>
1720 <p>
1721 I also intuitively expected that the istream code would convert these
1722 exceptions to the "badbit' set on the stream object, because I had not
1723 requested exceptions.    I refer to 27.6.1.1. P4.
1724 </p>
1725 <p>
1726 However, this was not the case on at least two implementations -- if
1727 the first thing I did with an istream was call operator&gt;&gt;( T&amp; ) for T
1728 among the basic arithmetic types and std::string.   Looking further I
1729 found that the sentry's constructor was invoking the exception when it
1730 pre-scanned for whitespace, and the extractor function (operator&gt;&gt;())
1731 was not catching exceptions in this situation.
1732 </p>
1733 <p>
1734 So, I was in a situation where setting 'noskipws' would change the
1735 istream's behavior even though no characters (whitespace or not) could
1736 ever be successfully read.
1737 </p>
1738 <p>
1739 Also, calling .peek() on the istream before calling the extractor()
1740 changed the behavior (.peek() had the effect of setting the badbit
1741 ahead of time).
1742 </p>
1743 <p>
1744 I found this all to be so inconsistent and inconvenient for me and my
1745 code design, that I filed a bugzilla entry for libstdc++.   I was then
1746 told that the bug cannot be fixed until issue #309 is resolved by the
1747 committee.
1748 </p>
1749
1750
1751
1752 <p><b>Proposed resolution:</b></p>
1753
1754
1755 <p><b>Rationale:</b></p>
1756 <p>The LWG agrees there is minor variation between implementations,
1757   but believes that it doesn't matter. This is a rarely used corner
1758   case. There is no evidence that this has any commercial importance
1759   or that it causes actual portability problems for customers trying
1760   to write code that runs on multiple implementations.</p>
1761
1762
1763
1764
1765
1766 <hr>
1767 <h3><a name="342"></a>342. seek and eofbit</h3>
1768 <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>
1769  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2001-10-09</p>
1770 <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>
1771 <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>
1772 <p><b>Discussion:</b></p>
1773 <p>I think we have a defect.</p>
1774
1775 <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
1776 description of seekg in 27.6.1.3 [istream.unformatted] paragraph 38 now looks
1777 like:</p>
1778
1779 <blockquote><p>
1780 Behaves as an unformatted input function (as described in 27.6.1.3,
1781 paragraph 1), except that it does not count the number of characters
1782 extracted and does not affect the value returned by subsequent calls to
1783 gcount(). After constructing a sentry object, if fail() != true,
1784 executes rdbuf()-&gt;pubseekpos( pos).
1785 </p></blockquote>
1786
1787 <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,
1788 27.6.1.3, paragraph 1 looks like:</p>
1789
1790 <blockquote><p>
1791 Each unformatted input function begins execution by constructing an
1792 object of class sentry with the default argument noskipws (second)
1793 argument true. If the sentry object returns true, when converted to a
1794 value of type bool, the function endeavors to obtain the requested
1795 input.  Otherwise, if the sentry constructor exits by throwing an
1796 exception or if the sentry object returns false, when converted to a
1797 value of type bool, the function returns without attempting to obtain
1798 any input. In either case the number of extracted characters is set to
1799 0; unformatted input functions taking a character array of non-zero
1800 size as an argument shall also store a null character (using charT())
1801 in the first location of the array. If an exception is thrown during
1802 input then ios::badbit is turned on in *this'ss error state. If
1803 (exception()&amp;badbit)!= 0 then the exception is rethrown. It also counts
1804 the number of characters extracted. If no exception has been thrown it
1805 ends by storing the count in a member object and returning the value
1806 specified. In any event the sentry object is destroyed before leaving
1807 the unformatted input function.
1808 </p></blockquote>
1809
1810 <p>And finally 27.6.1.1.2/5 says this about sentry:</p>
1811
1812 <blockquote><p>
1813 If, after any preparation is completed, is.good() is true, ok_ != false
1814 otherwise, ok_ == false.
1815 </p></blockquote>
1816
1817 <p>
1818 So although the seekg paragraph says that the operation proceeds if
1819 !fail(), the behavior of unformatted functions says the operation
1820 proceeds only if good().  The two statements are contradictory when only
1821 eofbit is set.  I don't think the current text is clear which condition
1822 should be respected.
1823 </p>
1824
1825 <p><b>Further discussion from Redmond:</b></p>
1826
1827 <p>PJP: It doesn't seem quite right to say that <tt>seekg</tt> is
1828 "unformatted". That makes specific claims about sentry that
1829 aren't quite appropriate for seeking, which has less fragile failure
1830 modes than actual input.  If we do really mean that it's unformatted
1831 input, it should behave the same way as other unformatted input.  On
1832 the other hand, "principle of least surprise" is that seeking from EOF
1833 ought to be OK.</p>
1834
1835 <p>
1836 Pre-Berlin:  Paolo points out several problems with the proposed resolution in
1837 Ready state:
1838 </p>
1839
1840 <ul>
1841 <li>It should apply to both overloads of seekg.</li>
1842 <li>tellg has similar issues, except that it should not call clear().</li>
1843 <li>The point about clear() seems to apply to seekp().</li>
1844 <li>Depending on the outcome of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#419">419</a>
1845 if the sentry
1846 sets <tt>failbit</tt> when it finds <tt>eofbit</tt> already set, then
1847 you can never seek away from the end of stream.</li>
1848 </ul>
1849
1850
1851
1852 <p><b>Proposed resolution:</b></p>
1853
1854 <p>Change 27.6.1.3 [istream.unformatted] to:</p>
1855 <blockquote><p>
1856 Behaves as an unformatted input function (as described in 27.6.1.3,
1857 paragraph 1), except that it does not count the number of characters
1858 extracted, does not affect the value returned by subsequent calls to
1859 gcount(), and does not examine the value returned by the sentry
1860 object. After constructing a sentry object, if <tt>fail() !=
1861 true</tt>, executes <tt>rdbuf()-&gt;pubseekpos(pos)</tt>.  In
1862 case of success, the function calls clear().
1863 In case of failure, the function calls <tt>setstate(failbit)</tt>
1864 (which may throw <tt>ios_base::failure</tt>).
1865 </p></blockquote>
1866
1867 <p><i>[Lillehammer: Matt provided wording.]</i></p>
1868
1869
1870
1871
1872 <p><b>Rationale:</b></p>
1873 <p>In C, fseek does clear EOF.  This is probably what most users would
1874   expect.  We agree that having eofbit set should not deter a seek,
1875   and that a successful seek should clear eofbit. Note
1876   that <tt>fail()</tt> is true only if <tt>failbit</tt>
1877   or <tt>badbit</tt> is set, so using <tt>!fail()</tt>, rather
1878   than <tt>good()</tt>, satisfies this goal.</p>
1879
1880
1881
1882
1883
1884 <hr>
1885 <h3><a name="343"></a>343. Unspecified library header dependencies</h3>
1886 <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>
1887  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-10-09</p>
1888 <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>
1889 <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>
1890 <p><b>Discussion:</b></p>
1891 <p>
1892 The synopses of the C++ library headers clearly show which names are
1893 required to be defined in each header. Since in order to implement the
1894 classes and templates defined in these headers declarations of other
1895 templates (but not necessarily their definitions) are typically
1896 necessary the standard in 17.4.4, p1 permits library implementers to
1897 include any headers needed to implement the definitions in each header.
1898 </p>
1899
1900 <p>
1901 For instance, although it is not explicitly specified in the synopsis of
1902 &lt;string&gt;, at the point of definition of the std::basic_string template
1903 the declaration of the std::allocator template must be in scope. All
1904 current implementations simply include &lt;memory&gt; from within &lt;string&gt;,
1905 either directly or indirectly, to bring the declaration of
1906 std::allocator into scope.
1907 </p>
1908
1909 <p>
1910 Additionally, however, some implementation also include &lt;istream&gt; and
1911 &lt;ostream&gt; at the top of &lt;string&gt; to bring the declarations of
1912 std::basic_istream and std::basic_ostream into scope (which are needed
1913 in order to implement the string inserter and extractor operators
1914 (21.3.7.9 [lib.string.io])). Other implementations only include
1915 &lt;iosfwd&gt;, since strictly speaking, only the declarations and not the
1916 full definitions are necessary.
1917 </p>
1918
1919 <p>
1920 Obviously, it is possible to implement &lt;string&gt; without actually
1921 providing the full definitions of all the templates std::basic_string
1922 uses (std::allocator, std::basic_istream, and std::basic_ostream).
1923 Furthermore, not only is it possible, doing so is likely to have a
1924 positive effect on compile-time efficiency.
1925 </p>
1926
1927 <p>
1928 But while it may seem perfectly reasonable to expect a program that uses
1929 the std::basic_string insertion and extraction operators to also
1930 explicitly include &lt;istream&gt; or &lt;ostream&gt;, respectively, it doesn't seem
1931 reasonable to also expect it to explicitly include &lt;memory&gt;. Since
1932 what's reasonable and what isn't is highly subjective one would expect
1933 the standard to specify what can and what cannot be assumed.
1934 Unfortunately, that isn't the case.
1935 </p>
1936
1937 <p>The examples below demonstrate the issue.</p>
1938
1939 <p>Example 1:</p>
1940
1941 <p>It is not clear whether the following program is complete:</p>
1942
1943 <pre>#include &lt;string&gt;
1944
1945 extern std::basic_ostream&lt;char&gt; &amp;strm;
1946
1947 int main () {
1948     strm &lt;&lt; std::string ("Hello, World!\n");
1949 }
1950 </pre>
1951
1952 <p>or whether one must explicitly include &lt;memory&gt; or
1953 &lt;ostream&gt; (or both) in addition to &lt;string&gt; in order for
1954 the program to compile.</p>
1955
1956
1957 <p>Example 2:</p>
1958
1959 <p>Similarly, it is unclear whether the following program is complete:</p>
1960
1961 <pre>#include &lt;istream&gt;
1962
1963 extern std::basic_iostream&lt;char&gt; &amp;strm;
1964
1965 int main () {
1966     strm &lt;&lt; "Hello, World!\n";
1967 }
1968 </pre>
1969
1970 <p>
1971 or whether one needs to explicitly include &lt;ostream&gt;, and
1972 perhaps even other headers containing the definitions of other
1973 required templates:</p>
1974
1975 <pre>#include &lt;ios&gt;
1976 #include &lt;istream&gt;
1977 #include &lt;ostream&gt;
1978 #include &lt;streambuf&gt;
1979
1980 extern std::basic_iostream&lt;char&gt; &amp;strm;
1981
1982 int main () {
1983     strm &lt;&lt; "Hello, World!\n";
1984 }
1985 </pre>
1986
1987 <p>Example 3:</p>
1988
1989 <p>Likewise, it seems unclear whether the program below is complete:</p>
1990 <pre>#include &lt;iterator&gt;
1991
1992 bool foo (std::istream_iterator&lt;int&gt; a, std::istream_iterator&lt;int&gt; b)
1993 {
1994     return a == b;
1995 }
1996
1997 int main () { }
1998 </pre>
1999
2000 <p>or whether one should be required to include &lt;istream&gt;.</p>
2001
2002 <p>There are many more examples that demonstrate this lack of a
2003 requirement.  I believe that in a good number of cases it would be
2004 unreasonable to require that a program explicitly include all the
2005 headers necessary for a particular template to be specialized, but I
2006 think that there are cases such as some of those above where it would
2007 be desirable to allow implementations to include only as much as
2008 necessary and not more.</p>
2009
2010 <p><i>[
2011 post Bellevue:
2012 ]</i></p>
2013
2014
2015 <blockquote>
2016 Position taken in prior reviews is that the idea of a table of header
2017 dependencies is a good one. Our view is that a full paper is needed to
2018 do justice to this, and we've made that recommendation to the issue
2019 author.
2020 </blockquote>
2021
2022
2023
2024 <p><b>Proposed resolution:</b></p>
2025 <p>
2026 For every C++ library header, supply a minimum set of other C++ library
2027 headers that are required to be included by that header. The proposed
2028 list is below (C++ headers for C Library Facilities, table 12 in
2029 17.4.1.2, p3, are omitted):
2030 </p>
2031
2032 <pre>+------------+--------------------+
2033 | C++ header |required to include |
2034 +============+====================+
2035 |&lt;algorithm&gt; |                    |
2036 +------------+--------------------+
2037 |&lt;bitset&gt;    |                    |
2038 +------------+--------------------+
2039 |&lt;complex&gt;   |                    |
2040 +------------+--------------------+
2041 |&lt;deque&gt;     |&lt;memory&gt;            |
2042 +------------+--------------------+
2043 |&lt;exception&gt; |                    |
2044 +------------+--------------------+
2045 |&lt;fstream&gt;   |&lt;ios&gt;               |
2046 +------------+--------------------+
2047 |&lt;functional&gt;|                    |
2048 +------------+--------------------+
2049 |&lt;iomanip&gt;   |&lt;ios&gt;               |
2050 +------------+--------------------+
2051 |&lt;ios&gt;       |&lt;streambuf&gt;         |
2052 +------------+--------------------+
2053 |&lt;iosfwd&gt;    |                    |
2054 +------------+--------------------+
2055 |&lt;iostream&gt;  |&lt;istream&gt;, &lt;ostream&gt;|
2056 +------------+--------------------+
2057 |&lt;istream&gt;   |&lt;ios&gt;               |
2058 +------------+--------------------+
2059 |&lt;iterator&gt;  |                    |
2060 +------------+--------------------+
2061 |&lt;limits&gt;    |                    |
2062 +------------+--------------------+
2063 |&lt;list&gt;      |&lt;memory&gt;            |
2064 +------------+--------------------+
2065 |&lt;locale&gt;    |                    |
2066 +------------+--------------------+
2067 |&lt;map&gt;       |&lt;memory&gt;            |
2068 +------------+--------------------+
2069 |&lt;memory&gt;    |                    |
2070 +------------+--------------------+
2071 |&lt;new&gt;       |&lt;exception&gt;         |
2072 +------------+--------------------+
2073 |&lt;numeric&gt;   |                    |
2074 +------------+--------------------+
2075 |&lt;ostream&gt;   |&lt;ios&gt;               |
2076 +------------+--------------------+
2077 |&lt;queue&gt;     |&lt;deque&gt;             |
2078 +------------+--------------------+
2079 |&lt;set&gt;       |&lt;memory&gt;            |
2080 +------------+--------------------+
2081 |&lt;sstream&gt;   |&lt;ios&gt;, &lt;string&gt;     |
2082 +------------+--------------------+
2083 |&lt;stack&gt;     |&lt;deque&gt;             |
2084 +------------+--------------------+
2085 |&lt;stdexcept&gt; |                    |
2086 +------------+--------------------+
2087 |&lt;streambuf&gt; |&lt;ios&gt;               |
2088 +------------+--------------------+
2089 |&lt;string&gt;    |&lt;memory&gt;            |
2090 +------------+--------------------+
2091 |&lt;strstream&gt; |                    |
2092 +------------+--------------------+
2093 |&lt;typeinfo&gt;  |&lt;exception&gt;         |
2094 +------------+--------------------+
2095 |&lt;utility&gt;   |                    |
2096 +------------+--------------------+
2097 |&lt;valarray&gt;  |                    |
2098 +------------+--------------------+
2099 |&lt;vector&gt;    |&lt;memory&gt;            |
2100 +------------+--------------------+
2101 </pre>
2102
2103
2104 <p><b>Rationale:</b></p>
2105 <p>The portability problem is real.  A program that works correctly on
2106 one implementation might fail on another, because of different header
2107 dependencies.  This problem was understood before the standard was
2108 completed, and it was a conscious design choice.</p>
2109 <p>One possible way to deal with this, as a library extension, would
2110 be an &lt;all&gt; header.</p>
2111
2112 <p>
2113 Hinnant:  It's time we dealt with this issue for C++0X.  Reopened.
2114 </p>
2115
2116
2117
2118
2119
2120
2121
2122 <hr>
2123 <h3><a name="382"></a>382. codecvt do_in/out result</h3>
2124 <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>
2125  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-08-30</p>
2126 <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>
2127 <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>
2128 <p><b>Discussion:</b></p>
2129 <p>
2130 It seems that the descriptions of codecvt do_in() and do_out() leave
2131 sufficient room for interpretation so that two implementations of
2132 codecvt may not work correctly with the same filebuf. Specifically,
2133 the following seems less than adequately specified:
2134 </p>
2135
2136 <ol>
2137 <li>
2138   the conditions under which the functions terminate
2139 </li>
2140 <li>
2141   precisely when the functions return ok
2142 </li>
2143 <li>
2144   precisely when the functions return partial
2145 </li>
2146 <li>
2147   the full set of conditions when the functions return error
2148 </li>
2149 </ol>
2150
2151 <ol>
2152 <li>
2153    22.2.1.4.2 [locale.codecvt.virtuals], p2 says this about the effects of the
2154    function: ...Stops if it encounters a character it cannot
2155    convert...  This assumes that there *is* a character to
2156    convert. What happens when there is a sequence that doesn't form a
2157    valid source character, such as an unassigned or invalid UNICODE
2158    character, or a sequence that cannot possibly form a character
2159    (e.g., the sequence "\xc0\xff" in UTF-8)?
2160 </li>
2161 <li>
2162    Table 53 says that the function returns codecvt_base::ok
2163    to indicate that the function(s) "completed the conversion."
2164    Suppose that the source sequence is "\xc0\x80" in UTF-8,
2165    with from pointing to '\xc0' and (from_end==from + 1).
2166    It is not clear whether the return value should be ok
2167    or partial (see below).
2168 </li>
2169 <li>
2170    Table 53 says that the function returns codecvt_base::partial
2171    if "not all source characters converted." With the from pointers
2172    set up the same way as above, it is not clear whether the return
2173    value should be partial or ok (see above).
2174 </li>
2175 <li>
2176    Table 53, in the row describing the meaning of error mistakenly
2177    refers to a "from_type" character, without the symbol from_type
2178    having been defined. Most likely, the word "source" character
2179    is intended, although that is not sufficient. The functions
2180    may also fail when they encounter an invalid source sequence
2181    that cannot possibly form a valid source character (e.g., as
2182    explained in bullet 1 above).
2183 </li>
2184 </ol>
2185 <p>
2186 Finally, the conditions described at the end of 22.2.1.4.2 [locale.codecvt.virtuals], p4 don't seem to be possible:
2187 </p>
2188 <blockquote><p>
2189     "A return value of partial, if (from_next == from_end),
2190     indicates that either the destination sequence has not
2191     absorbed all the available destination elements, or that
2192     additional source elements are needed before another
2193     destination element can be produced."
2194 </p></blockquote>
2195 <p>
2196 If the value is partial, it's not clear to me that (from_next
2197 ==from_end) could ever hold if there isn't enough room
2198 in the destination buffer. In order for (from_next==from_end) to
2199 hold, all characters in that range must have been successfully
2200 converted (according to 22.2.1.4.2 [locale.codecvt.virtuals], p2) and since there are no
2201 further source characters to convert, no more room in the
2202 destination buffer can be needed.
2203 </p>
2204 <p>
2205 It's also not clear to me that (from_next==from_end) could ever
2206 hold if additional source elements are needed to produce another
2207 destination character (not element as incorrectly stated in the
2208 text). partial is returned if "not all source characters have
2209 been converted" according to Table 53, which also implies that
2210 (from_next==from) does NOT hold.
2211 </p>
2212 <p>
2213 Could it be that the intended qualifying condition was actually
2214 (from_next != from_end), i.e., that the sentence was supposed
2215 to read
2216 </p>
2217 <blockquote><p>
2218     "A return value of partial, if (from_next != from_end),..."
2219 </p></blockquote>
2220 <p>
2221 which would make perfect sense, since, as far as I understand it,
2222 partial can only occur if (from_next != from_end)?
2223 </p>
2224 <p><i>[Lillehammer: Defer for the moment, but this really needs to be
2225   fixed. Right now, the description of codecvt is too vague for it to
2226   be a useful contract between providers and clients of codecvt
2227   facets.  (Note that both vendors and users can be both providers and
2228   clients of codecvt facets.) The major philosophical issue is whether
2229   the standard should only describe mappings that take a single wide
2230   character to multiple narrow characters (and vice versa), or whether
2231   it should describe fully general N-to-M conversions. When the
2232   original standard was written only the former was contemplated, but
2233   today, in light of the popularity of utf8 and utf16, that doesn't
2234   seem sufficient for C++0x. Bill supports general N-to-M conversions;
2235   we need to make sure Martin and Howard agree.]</i></p>
2236
2237
2238
2239 <p><b>Proposed resolution:</b></p>
2240
2241
2242
2243
2244 <hr>
2245 <h3><a name="387"></a>387. std::complex over-encapsulated</h3>
2246 <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#Ready">Ready</a>
2247  <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2002-11-08</p>
2248 <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>
2249 <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>
2250 <p><b>Discussion:</b></p>
2251 <p>
2252 The absence of explicit description of std::complex&lt;T&gt; layout
2253 makes it imposible to reuse existing software developed in traditional
2254 languages like Fortran or C with unambigous and commonly accepted
2255 layout assumptions.  There ought to be a way for practitioners to
2256 predict with confidence the layout of std::complex&lt;T&gt; whenever T
2257 is a numerical datatype.  The absence of ways to access individual
2258 parts of a std::complex&lt;T&gt; object as lvalues unduly promotes
2259 severe pessimizations. For example, the only way to change,
2260 independently, the real and imaginary parts is to write something like
2261 </p>
2262
2263 <pre>complex&lt;T&gt; z;
2264 // ...
2265 // set the real part to r
2266 z = complex&lt;T&gt;(r, z.imag());
2267 // ...
2268 // set the imaginary part to i
2269 z = complex&lt;T&gt;(z.real(), i);
2270 </pre>
2271
2272 <p>
2273 At this point, it seems appropriate to recall that a complex number
2274 is, in effect, just a pair of numbers with no particular invariant to
2275 maintain.  Existing practice in numerical computations has it that a
2276 complex number datatype is usually represented by Cartesian
2277 coordinates. Therefore the over-encapsulation put in the specification
2278 of std::complex&lt;&gt; is not justified.
2279 </p>
2280
2281
2282
2283 <p><b>Proposed resolution:</b></p>
2284 <p>Add the following requirements to 26.3 [complex.numbers] as 26.3/4:</p>
2285 <blockquote>
2286 <p>If z is an lvalue expression of type cv std::complex&lt;T&gt; then</p>
2287
2288 <ul>
2289 <li>the expression reinterpret_cast&lt;cv T(&amp;)[2]&gt;(z)
2290 is well-formed; and</li>
2291 <li>reinterpret_cast&lt;cv T(&amp;)[2]&gt;(z)[0]designates the
2292 real part of z; and</li>
2293 <li>reinterpret_cast&lt;cv T(&amp;)[2]&gt;(z)[1]designates the
2294 imaginary part of z.</li>
2295 </ul>
2296
2297 <p>
2298 Moreover, if a is an expression of pointer type cv complex&lt;T&gt;*
2299 and the expression a[i] is well-defined for an integer expression
2300 i then:
2301 </p>
2302
2303 <ul>
2304 <li>reinterpret_cast&lt;cv T*&gt;(a)[2*i] designates the real
2305 part of a[i]; and</li>
2306 <li>reinterpret_cast&lt;cv T*&gt;(a)[2*i+1] designates the
2307 imaginary part of a[i].</li>
2308 </ul>
2309 </blockquote>
2310
2311 <p>
2312 In 26.3.2 [complex] Add the member functions
2313 </p>
2314
2315 <blockquote><pre>void real(T);
2316 void imag(T);
2317 </pre></blockquote>
2318
2319 <p>
2320 Add to 26.3.4 [complex.members]
2321 </p>
2322
2323 <blockquote>
2324 <pre>T real() const;
2325 </pre>
2326 <blockquote>
2327 <i>Returns:</i> the value of the real component
2328 </blockquote>
2329 <pre>void real(T val);
2330 </pre>
2331 <blockquote>
2332 Assigns val to the real component.
2333 </blockquote>
2334 <pre>T imag() const;
2335 </pre>
2336 <blockquote>
2337 <i>Returns:</i> the value of the imaginary component
2338 </blockquote>
2339 <pre>void imag(T val);
2340 </pre>
2341 <blockquote>
2342 Assigns val to the imaginary component.
2343 </blockquote>
2344 </blockquote>
2345
2346 <p><i>[Kona: The layout guarantee is absolutely necessary for C
2347   compatibility.  However, there was disagreement about the other part
2348   of this proposal: retrieving elements of the complex number as
2349   lvalues.  An alternative: continue to have real() and imag() return
2350   rvalues, but add set_real() and set_imag().  Straw poll: return
2351   lvalues - 2, add setter functions - 5.  Related issue: do we want
2352   reinterpret_cast as the interface for converting a complex to an
2353   array of two reals, or do we want to provide a more explicit way of
2354   doing it?  Howard will try to resolve this issue for the next
2355   meeting.]</i></p>
2356
2357
2358 <p><i>[pre-Sydney: Howard summarized the options in n1589.]</i></p>
2359
2360
2361 <p><i>[
2362 Bellevue:
2363 ]</i></p>
2364
2365
2366 <blockquote>
2367 Second half of proposed wording replaced and moved to Ready.
2368 </blockquote>
2369
2370
2371 <p><b>Rationale:</b></p>
2372 <p>The LWG believes that C99 compatibility would be enough
2373 justification for this change even without other considerations.  All
2374 existing implementations already have the layout proposed here.</p>
2375
2376
2377
2378
2379
2380 <hr>
2381 <h3><a name="394"></a>394. behavior of formatted output on failure</h3>
2382 <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>
2383  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-12-27</p>
2384 <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>
2385 <p><b>Discussion:</b></p>
2386 <p>
2387 There is a contradiction in Formatted output about what bit is
2388 supposed to be set if the formatting fails. On sentence says it's
2389 badbit and another that it's failbit.
2390 </p>
2391 <p>
2392 27.6.2.5.1, p1 says in the Common Requirements on Formatted output
2393 functions:
2394 </p>
2395 <pre>     ... If the generation fails, then the formatted output function
2396      does setstate(ios::failbit), which might throw an exception.
2397 </pre>
2398 <p>
2399 27.6.2.5.2, p1 goes on to say this about Arithmetic Inserters:
2400 </p>
2401 <p>
2402      ... The formatting conversion occurs as if it performed the
2403      following code fragment:
2404 </p>
2405 <pre>     bool failed =
2406          use_facet&lt;num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt;
2407          &gt; &gt;
2408          (getloc()).put(*this, *this, fill(), val). failed();
2409
2410      ... If failed is true then does setstate(badbit) ...
2411 </pre>
2412 <p>
2413 The original intent of the text, according to Jerry Schwarz (see
2414 c++std-lib-10500), is captured in the following paragraph:
2415 </p>
2416 <p>
2417 In general "badbit" should mean that the stream is unusable because
2418 of some underlying failure, such as disk full or socket closure;
2419 "failbit" should mean that the requested formatting wasn't possible
2420 because of some inconsistency such as negative widths.  So typically
2421 if you clear badbit and try to output something else you'll fail
2422 again, but if you clear failbit and try to output something else
2423 you'll succeed.
2424 </p>
2425 <p>
2426 In the case of the arithmetic inserters, since num_put cannot
2427 report failure by any means other than exceptions (in response
2428 to which the stream must set badbit, which prevents the kind of
2429 recoverable error reporting mentioned above), the only other
2430 detectable failure is if the iterator returned from num_put
2431 returns true from failed().
2432 </p>
2433 <p>
2434 Since that can only happen (at least with the required iostream
2435 specializations) under such conditions as the underlying failure
2436 referred to above (e.g., disk full), setting badbit would seem
2437 to be the appropriate response (indeed, it is required in
2438 27.6.2.5.2, p1). It follows that failbit can never be directly
2439 set by the arithmetic (it can only be set by the sentry object
2440 under some unspecified conditions).
2441 </p>
2442 <p>
2443 The situation is different for other formatted output functions
2444 which can fail as a result of the streambuf functions failing
2445 (they may do so by means other than exceptions), and which are
2446 then required to set failbit.
2447 </p>
2448 <p>
2449 The contradiction, then, is that ostream::operator&lt;&lt;(int) will
2450 set badbit if the disk is full, while operator&lt;&lt;(ostream&amp;,
2451 char) will set failbit under the same conditions. To make the behavior
2452 consistent, the Common requirements sections for the Formatted output
2453 functions should be changed as proposed below.
2454 </p>
2455 <p><i>[Kona: There's agreement that this is a real issue.  What we
2456   decided at Kona: 1. An error from the buffer (which can be detected
2457   either directly from streambuf's member functions or by examining a
2458   streambuf_iterator) should always result in badbit getting set.
2459   2. There should never be a circumstance where failbit gets set.
2460   That represents a formatting error, and there are no circumstances
2461   under which the output facets are specified as signaling a
2462   formatting error. (Even more so for string output that for numeric
2463   because there's nothing to format.)  If we ever decide to make it
2464   possible for formatting errors to exist then the facets can signal
2465   the error directly, and that should go in clause 22, not clause 27.
2466   3. The phrase "if generation fails" is unclear and should be
2467   eliminated.  It's not clear whether it's intended to mean a buffer
2468   error (e.g. a full disk), a formatting error, or something else.
2469   Most people thought it was supposed to refer to buffer errors; if
2470   so, we should say so.  Martin will provide wording.]</i></p>
2471
2472
2473
2474
2475 <p><b>Proposed resolution:</b></p>
2476
2477
2478 <p><b>Rationale:</b></p>
2479
2480
2481
2482
2483
2484
2485 <hr>
2486 <h3><a name="396"></a>396. what are characters zero and one</h3>
2487 <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>
2488  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-01-05</p>
2489 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#bitset.cons">active issues</a> in [bitset.cons].</p>
2490 <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>
2491 <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>
2492 <p><b>Discussion:</b></p>
2493     <p>
2494 23.3.5.1, p6 [lib.bitset.cons] talks about a generic character
2495 having the value of 0 or 1 but there is no definition of what
2496 that means for charT other than char and wchar_t. And even for
2497 those two types, the values 0 and 1 are not actually what is
2498 intended -- the values '0' and '1' are. This, along with the
2499 converse problem in the description of to_string() in 23.3.5.2,
2500 p33, looks like a defect remotely related to DR 303.
2501     </p>
2502     <p>
2503 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#303
2504     </p>
2505     <pre>23.3.5.1:
2506   -6-  An element of the constructed string has value zero if the
2507        corresponding character in str, beginning at position pos,
2508        is 0. Otherwise, the element has the value one.
2509     </pre>
2510     <pre>23.3.5.2:
2511   -33-  Effects: Constructs a string object of the appropriate
2512         type and initializes it to a string of length N characters.
2513         Each character is determined by the value of its
2514         corresponding bit position in *this. Character position N
2515         ?- 1 corresponds to bit position zero. Subsequent decreasing
2516         character positions correspond to increasing bit positions.
2517         Bit value zero becomes the character 0, bit value one becomes
2518         the character 1.
2519     </pre>
2520     <p>
2521 Also note the typo in 23.3.5.1, p6: the object under construction
2522 is a bitset, not a string.
2523     </p>
2524
2525
2526 <p><b>Proposed resolution:</b></p>
2527 <p>Change the constructor's function declaration immediately before
2528 23.3.5.1 [bitset.cons] p3 to:</p>
2529 <pre>    template &lt;class charT, class traits, class Allocator&gt;
2530     explicit
2531     bitset(const basic_string&lt;charT, traits, Allocator&gt;&amp; str,
2532            typename basic_string&lt;charT, traits, Allocator&gt;::size_type pos = 0,
2533            typename basic_string&lt;charT, traits, Allocator&gt;::size_type n =
2534              basic_string&lt;charT, traits, Allocator&gt;::npos,
2535            charT zero = charT('0'), charT one = charT('1'))
2536 </pre>
2537 <p>Change the first two sentences of 23.3.5.1 [bitset.cons] p6 to: "An
2538 element of the constructed string has value 0 if the corresponding
2539 character in <i>str</i>, beginning at position <i>pos</i>,
2540 is <i>zero</i>. Otherwise, the element has the value 1.</p>
2541
2542 <p>Change the text of the second sentence in 23.3.5.1, p5 to read:
2543     "The function then throws invalid_argument if any of the rlen
2544     characters in str beginning at position pos is other than <i>zero</i>
2545     or <i>one</i>. The function uses traits::eq() to compare the character
2546     values."
2547 </p>
2548
2549 <p>Change the declaration of the <tt>to_string</tt> member function
2550   immediately before 23.3.5.2 [bitset.members] p33 to:</p>
2551 <pre>    template &lt;class charT, class traits, class Allocator&gt;
2552     basic_string&lt;charT, traits, Allocator&gt;
2553     to_string(charT zero = charT('0'), charT one = charT('1')) const;
2554 </pre>
2555 <p>Change the last sentence of 23.3.5.2 [bitset.members] p33 to: "Bit
2556   value 0 becomes the character <tt><i>zero</i></tt>, bit value 1 becomes the
2557   character <tt><i>one</i></tt>.</p>
2558 <p>Change 23.3.5.3 [bitset.operators] p8 to:</p>
2559 <p><b>Returns</b>:</p>
2560 <pre>  os &lt;&lt; x.template to_string&lt;charT,traits,allocator&lt;charT&gt; &gt;(
2561       use_facet&lt;ctype&lt;charT&gt; &gt;(<i>os</i>.getloc()).widen('0'),
2562       use_facet&lt;ctype&lt;charT&gt; &gt;(<i>os</i>.getloc()).widen('1'));
2563 </pre>
2564
2565
2566 <p><b>Rationale:</b></p>
2567 <p>There is a real problem here: we need the character values of '0'
2568   and '1', and we have no way to get them since strings don't have
2569   imbued locales. In principle the "right" solution would be to
2570   provide an extra object, either a ctype facet or a full locale,
2571   which would be used to widen '0' and '1'. However, there was some
2572   discomfort about using such a heavyweight mechanism.  The proposed
2573   resolution allows those users who care about this issue to get it
2574   right.</p>
2575 <p>We fix the inserter to use the new arguments.  Note that we already
2576   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>
2577
2578
2579
2580 <p><i>[
2581 post Bellevue:
2582 ]</i></p>
2583
2584
2585 <blockquote>
2586 We are happy with the resolution as proposed, and we move this to Ready.
2587 </blockquote>
2588
2589
2590
2591
2592 <hr>
2593 <h3><a name="397"></a>397. ostream::sentry dtor throws exceptions</h3>
2594 <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>
2595  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-01-05</p>
2596 <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>
2597 <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>
2598 <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>
2599 <p><b>Discussion:</b></p>
2600     <p>
2601 17.4.4.8, p3 prohibits library dtors from throwing exceptions.
2602     </p>
2603     <p>
2604 27.6.2.3, p4 says this about the ostream::sentry dtor:
2605     </p>
2606     <pre>    -4- If ((os.flags() &amp; ios_base::unitbuf) &amp;&amp; !uncaught_exception())
2607         is true, calls os.flush().
2608     </pre>
2609     <p>
2610 27.6.2.6, p7 that describes ostream::flush() says:
2611     </p>
2612     <pre>    -7- If rdbuf() is not a null pointer, calls rdbuf()-&gt;pubsync().
2613         If that function returns ?-1 calls setstate(badbit) (which
2614         may throw ios_base::failure (27.4.4.3)).
2615     </pre>
2616     <p>
2617 That seems like a defect, since both pubsync() and setstate() can
2618 throw an exception.
2619     </p>
2620 <p><i>[
2621 The contradiction is real.  Clause 17 says destructors may never
2622 throw exceptions, and clause 27 specifies a destructor that does
2623 throw.  In principle we might change either one.  We're leaning
2624 toward changing clause 17: putting in an "unless otherwise specified"
2625 clause, and then putting in a footnote saying the sentry destructor
2626 is the only one that can throw.  PJP suggests specifying that
2627 sentry::~sentry() should internally catch any exceptions it might cause.
2628 ]</i></p>
2629
2630
2631 <p><i>[
2632 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-defects.html#622">622</a> for related issues.
2633 ]</i></p>
2634
2635
2636
2637
2638 <p><b>Proposed resolution:</b></p>
2639
2640
2641
2642
2643
2644 <hr>
2645 <h3><a name="398"></a>398. effects of end-of-file on unformatted input functions</h3>
2646 <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>
2647  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-01-05</p>
2648 <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>
2649 <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>
2650 <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>
2651 <p><b>Discussion:</b></p>
2652     <p>
2653 While reviewing unformatted input member functions of istream
2654 for their behavior when they encounter end-of-file during input
2655 I found that the requirements vary, sometimes unexpectedly, and
2656 in more than one case even contradict established practice (GNU
2657 libstdc++ 3.2, IBM VAC++ 6.0, STLPort 4.5, SunPro 5.3, HP aCC
2658 5.38, Rogue Wave libstd 3.1, and Classic Iostreams).
2659     </p>
2660     <p>
2661 The following unformatted input member functions set eofbit if they
2662 encounter an end-of-file (this is the expected behavior, and also
2663 the behavior of all major implementations):
2664     </p>
2665     <pre>    basic_istream&lt;charT, traits&gt;&amp;
2666     get (char_type*, streamsize, char_type);
2667     </pre>
2668     <p>
2669     Also sets failbit if it fails to extract any characters.
2670     </p>
2671     <pre>    basic_istream&lt;charT, traits&gt;&amp;
2672     get (char_type*, streamsize);
2673     </pre>
2674     <p>
2675     Also sets failbit if it fails to extract any characters.
2676     </p>
2677     <pre>    basic_istream&lt;charT, traits&gt;&amp;
2678     getline (char_type*, streamsize, char_type);
2679     </pre>
2680     <p>
2681     Also sets failbit if it fails to extract any characters.
2682     </p>
2683     <pre>    basic_istream&lt;charT, traits&gt;&amp;
2684     getline (char_type*, streamsize);
2685     </pre>
2686     <p>
2687     Also sets failbit if it fails to extract any characters.
2688     </p>
2689     <pre>    basic_istream&lt;charT, traits&gt;&amp;
2690     ignore (int, int_type);
2691     </pre>
2692     <pre>    basic_istream&lt;charT, traits&gt;&amp;
2693     read (char_type*, streamsize);
2694     </pre>
2695     <p>
2696     Also sets failbit if it encounters end-of-file.
2697     </p>
2698     <pre>    streamsize readsome (char_type*, streamsize);
2699     </pre>
2700
2701     <p>
2702 The following unformated input member functions set failbit but
2703 not eofbit if they encounter an end-of-file (I find this odd
2704 since the functions make it impossible to distinguish a general
2705 failure from a failure due to end-of-file; the requirement is
2706 also in conflict with all major implementation which set both
2707 eofbit and failbit):
2708     </p>
2709     <pre>    int_type get();
2710     </pre>
2711     <pre>    basic_istream&lt;charT, traits&gt;&amp;
2712     get (char_type&amp;);
2713     </pre>
2714     <p>
2715 These functions only set failbit of they extract no characters,
2716 otherwise they don't set any bits, even on failure (I find this
2717 inconsistency quite unexpected; the requirement is also in
2718 conflict with all major implementations which set eofbit
2719 whenever they encounter end-of-file):
2720     </p>
2721     <pre>    basic_istream&lt;charT, traits&gt;&amp;
2722     get (basic_streambuf&lt;charT, traits&gt;&amp;, char_type);
2723     </pre>
2724     <pre>    basic_istream&lt;charT, traits&gt;&amp;
2725     get (basic_streambuf&lt;charT, traits&gt;&amp;);
2726     </pre>
2727     <p>
2728 This function sets no bits (all implementations except for
2729 STLport and Classic Iostreams set eofbit when they encounter
2730 end-of-file):
2731     </p>
2732     <pre>    int_type peek ();
2733     </pre>
2734 <p>Informally, what we want is a global statement of intent saying
2735   that eofbit gets set if we trip across EOF, and then we can take
2736   away the specific wording for individual functions.  A full review
2737   is necessary.  The wording currently in the standard is a mishmash,
2738   and changing it on an individual basis wouldn't make things better.
2739   Dietmar will do this work.</p>
2740
2741
2742 <p><b>Proposed resolution:</b></p>
2743
2744
2745
2746
2747 <hr>
2748 <h3><a name="408"></a>408. Is vector&lt;reverse_iterator&lt;char*&gt; &gt; forbidden?</h3>
2749 <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>
2750  <b>Submitter:</b> Nathan Myers <b>Date:</b> 2003-06-03</p>
2751 <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>
2752 <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>
2753 <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>
2754 <p><b>Discussion:</b></p>
2755 <p>
2756 I've been discussing iterator semantics with Dave Abrahams, and a
2757 surprise has popped up.  I don't think this has been discussed before.
2758 </p>
2759
2760 <p>
2761 24.1 [iterator.requirements] says that the only operation that can be performed on "singular"
2762 iterator values is to assign a non-singular value to them.  (It
2763 doesn't say they can be destroyed, and that's probably a defect.)
2764 Some implementations have taken this to imply that there is no need
2765 to initialize the data member of a reverse_iterator&lt;&gt; in the default
2766 constructor.  As a result, code like
2767 </p>
2768 <blockquote><pre>  std::vector&lt;std::reverse_iterator&lt;char*&gt; &gt; v(7);
2769   v.reserve(1000);
2770 </pre></blockquote>
2771 <p>
2772 invokes undefined behavior, because it must default-initialize the
2773 vector elements, and then copy them to other storage.  Of course many
2774 other vector operations on these adapters are also left undefined,
2775 and which those are is not reliably deducible from the standard.
2776 </p>
2777
2778 <p>
2779 I don't think that 24.1 was meant to make standard-library iterator
2780 types unsafe.  Rather, it was meant to restrict what operations may
2781 be performed by functions which take general user- and standard
2782 iterators as arguments, so that raw pointers would qualify as
2783 iterators.  However, this is not clear in the text, others have come
2784 to the opposite conclusion.
2785 </p>
2786
2787 <p>
2788 One question is whether the standard iterator adaptors have defined
2789 copy semantics.  Another is whether they have defined destructor
2790 semantics: is
2791 </p>
2792 <blockquote><pre>  { std::vector&lt;std::reverse_iterator&lt;char*&gt; &gt;  v(7); }
2793 </pre></blockquote>
2794 <p>
2795 undefined too?
2796 </p>
2797
2798 <p>
2799 Note this is not a question of whether algorithms are allowed to
2800 rely on copy semantics for arbitrary iterators, just whether the
2801 types we actually supply support those operations.  I believe the
2802 resolution must be expressed in terms of the semantics of the
2803 adapter's argument type.  It should make clear that, e.g., the
2804 reverse_iterator&lt;T&gt; constructor is actually required to execute
2805 T(), and so copying is defined if the result of T() is copyable.
2806 </p>
2807
2808 <p>
2809 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, which defines reverse_iterator's default
2810 constructor more precisely, has some relevance to this issue.
2811 However, it is not the whole story.
2812 </p>
2813
2814 <p>
2815 The issue was whether
2816 </p>
2817 <blockquote><pre>  reverse_iterator() { }
2818 </pre></blockquote>
2819 <p>
2820 is allowed, vs.
2821 </p>
2822 <blockquote><pre>  reverse_iterator() : current() { }
2823 </pre></blockquote>
2824
2825 <p>
2826 The difference is when T is char*, where the first leaves the member
2827 uninitialized, and possibly equal to an existing pointer value, or
2828 (on some targets) may result in a hardware trap when copied.
2829 </p>
2830
2831 <p>
2832 8.5 paragraph 5 seems to make clear that the second is required to
2833 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
2834 types.
2835 </p>
2836
2837 <p>
2838 But that only takes care of reverse_iterator, and doesn't establish
2839 a policy for all iterators.  (The reverse iterator adapter was just
2840 an example.)  In particular, does my function
2841 </p>
2842 <blockquote><pre>  template &lt;typename Iterator&gt;
2843     void f() { std::vector&lt;Iterator&gt;  v(7); }
2844 </pre></blockquote>
2845 <p>
2846 evoke undefined behavior for some conforming iterator definitions?
2847 I think it does, now, because vector&lt;&gt; will destroy those singular
2848 iterator values, and that's explicitly disallowed.
2849 </p>
2850
2851 <p>
2852 24.1 shouldn't give blanket permission to copy all singular iterators,
2853 because then pointers wouldn't qualify as iterators.  However, it
2854 should allow copying of that subset of singular iterator values that
2855 are default-initialized, and it should explicitly allow destroying any
2856 iterator value, singular or not, default-initialized or not.
2857 </p>
2858
2859 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#407">407</a></p>
2860 <p><i>[
2861 We don't want to require all singular iterators to be copyable,
2862 because that is not the case for pointers.  However, default
2863 construction may be a special case.  Issue: is it really default
2864 construction we want to talk about, or is it something like value
2865 initialization?  We need to check with core to see whether default
2866 constructed pointers are required to be copyable; if not, it would be
2867 wrong to impose so strict a requirement for iterators.
2868 ]</i></p>
2869
2870
2871
2872
2873 <p><b>Proposed resolution:</b></p>
2874
2875
2876
2877
2878
2879 <hr>
2880 <h3><a name="417"></a>417. what does ctype::do_widen() return on failure</h3>
2881 <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>
2882  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
2883 <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>
2884 <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>
2885 <p><b>Discussion:</b></p>
2886 <p>
2887 The Effects and Returns clauses of the do_widen() member function of
2888 the ctype facet fail to specify the behavior of the function on failure.
2889 That the function may not be able to simply cast the narrow character
2890 argument to the type of the result since doing so may yield the wrong value
2891 for some wchar_t encodings. Popular implementations of ctype&lt;wchar_t&gt; that
2892 use mbtowc() and UTF-8 as the native encoding (e.g., GNU glibc) will fail
2893 when the argument's MSB is set. There is no way for the the rest of locale
2894 and iostream to reliably detect this failure.
2895 </p>
2896 <p><i>[Kona: This is a real problem.  Widening can fail.  It's unclear
2897   what the solution should be.  Returning WEOF works for the wchar_t
2898   specialization, but not in general.  One option might be to add a
2899   default, like <i>narrow</i>.  But that's an incompatible change.
2900   Using <i>traits::eof</i> might seem like a good idea, but facets
2901   don't have access to traits (a recurring problem).  We could
2902   have <i>widen</i> throw an exception, but that's a scary option;
2903   existing library components aren't written with the assumption
2904   that <i>widen</i> can throw.]</i></p>
2905
2906
2907
2908 <p><b>Proposed resolution:</b></p>
2909
2910
2911
2912
2913 <hr>
2914 <h3><a name="418"></a>418. exceptions thrown during iostream cleanup</h3>
2915 <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>
2916  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
2917 <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>
2918 <p><b>Discussion:</b></p>
2919 <p>
2920 The dtor of the ios_base::Init object is supposed to call flush() on the
2921 6 standard iostream objects cout, cerr, clog, wcout, wcerr, and wclog.
2922 This call may cause an exception to be thrown.
2923 </p>
2924
2925 <p>
2926 17.4.4.8, p3 prohibits all library destructors from throwing exceptions.
2927 </p>
2928
2929 <p>
2930 The question is: What should this dtor do if one or more of these calls
2931 to flush() ends up throwing an exception? This can happen quite easily
2932 if one of the facets installed in the locale imbued in the iostream
2933 object throws.
2934 </p>
2935 <p><i>[Kona: We probably can't do much better than what we've got, so
2936   the LWG is leaning toward NAD.  At the point where the standard
2937   stream objects are being cleaned up, the usual error reporting
2938   mechanism are all unavailable.  And exception from flush at this
2939   point will definitely cause problems.  A quality implementation
2940   might reasonably swallow the exception, or call abort, or do
2941   something even more drastic.]</i></p>
2942
2943
2944 <p><i>[
2945 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-defects.html#622">622</a> for related issues.
2946 ]</i></p>
2947
2948
2949
2950
2951 <p><b>Proposed resolution:</b></p>
2952
2953
2954
2955
2956 <hr>
2957 <h3><a name="419"></a>419. istream extractors not setting failbit if eofbit is already set</h3>
2958 <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>
2959  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
2960 <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>
2961 <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>
2962 <p><b>Discussion:</b></p>
2963         <p>
2964
2965 27.6.1.1.3 [istream::sentry], p2 says that istream::sentry ctor prepares for input if is.good()
2966 is true. p4 then goes on to say that the ctor sets the sentry::ok_ member to
2967 true if the stream state is good after any preparation. 27.6.1.2.1 [istream.formatted.reqmts], p1 then
2968 says that a formatted input function endeavors to obtain the requested input
2969 if the sentry's operator bool() returns true.
2970
2971 Given these requirements, no formatted extractor should ever set failbit if
2972 the initial stream rdstate() == eofbit. That is contrary to the behavior of
2973 all implementations I tested. The program below prints out
2974
2975 eof = 1, fail = 0
2976 eof = 1, fail = 1
2977
2978 on all of them.
2979         </p>
2980 <pre>
2981 #include &lt;sstream&gt;
2982 #include &lt;cstdio&gt;
2983
2984 int main()
2985 {
2986     std::istringstream strm ("1");
2987
2988     int i = 0;
2989
2990     strm &gt;&gt; i;
2991
2992     std::printf ("eof = %d, fail = %d\n",
2993                  !!strm.eof (), !!strm.fail ());
2994
2995     strm &gt;&gt; i;
2996
2997     std::printf ("eof = %d, fail = %d\n",
2998                  !!strm.eof (), !!strm.fail ());
2999 }
3000
3001 </pre>
3002         <p>
3003 <br>
3004
3005 Comments from Jerry Schwarz (c++std-lib-11373):
3006 <br>
3007
3008 Jerry Schwarz wrote:
3009 <br>
3010
3011 I don't know where (if anywhere) it says it in the standard, but the
3012 formatted extractors are supposed to set failbit if they don't extract
3013 any characters. If they didn't then simple loops like
3014 <br>
3015
3016 while (cin &gt;&gt; x);
3017 <br>
3018
3019 would loop forever.
3020 <br>
3021
3022 Further comments from Martin Sebor:
3023 <br>
3024
3025 The question is which part of the extraction should prevent this from happening
3026 by setting failbit when eofbit is already set. It could either be the sentry
3027 object or the extractor. It seems that most implementations have chosen to
3028 set failbit in the sentry [...] so that's the text that will need to be
3029 corrected.
3030
3031         </p>
3032 <p>
3033 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
3034 sets <tt>failbit</tt> when it finds <tt>eofbit</tt> already set, then
3035 you can never seek away from the end of stream.
3036 </p>
3037 <p>Kona: Possibly NAD.  If eofbit is set then good() will return false.  We
3038   then set <i>ok</i> to false.  We believe that the sentry's
3039   constructor should always set failbit when <i>ok</i> is false, and
3040   we also think the standard already says that.  Possibly it could be
3041   clearer.</p>
3042
3043
3044
3045 <p><b>Proposed resolution:</b></p>
3046 <p>
3047 Change 27.6.1.1.3 [istream::sentry], p2 to:
3048 </p>
3049
3050 <blockquote>
3051 <pre>explicit sentry(basic_istream&lt;charT,traits&gt;&amp; <i>is</i> , bool <i>noskipws</i> = false);</pre>
3052 <p>
3053 -2- <i>Effects:</i> If <tt>is.good()</tt> is <del><tt>true</tt></del>
3054 <ins><tt>false</tt></ins>, <ins>calls <tt>is.setstate(failbit)</tt>.
3055 Otherwise</ins> prepares for formatted or unformatted input. ...
3056 </p>
3057 </blockquote>
3058
3059
3060
3061
3062
3063
3064 <hr>
3065 <h3><a name="421"></a>421. is basic_streambuf copy-constructible?</h3>
3066 <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>
3067  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
3068 <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>
3069 <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>
3070 <p><b>Discussion:</b></p>
3071 <p>
3072 The reflector thread starting with c++std-lib-11346 notes that the class
3073 template basic_streambuf, along with basic_stringbuf and basic_filebuf,
3074 is copy-constructible but that the semantics of the copy constructors
3075 are not defined anywhere. Further, different implementations behave
3076 differently in this respect: some prevent copy construction of objects
3077 of these types by declaring their copy ctors and assignment operators
3078 private, others exhibit undefined behavior, while others still give
3079 these operations well-defined semantics.
3080 </p>
3081
3082 <p>
3083 Note that this problem doesn't seem to be isolated to just the three
3084 types mentioned above. A number of other types in the library section
3085 of the standard provide a compiler-generated copy ctor and assignment
3086 operator yet fail to specify their semantics.  It's believed that the
3087 only types for which this is actually a problem (i.e. types where the
3088 compiler-generated default may be inappropriate and may not have been
3089 intended) are locale facets.  See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#439">439</a>.
3090 </p>
3091
3092
3093 <p><b>Proposed resolution:</b></p>
3094 <p>
3095 27.5.2 [lib.streambuf]:  Add into the synopsis, public section, just above the destructor declaration:
3096 </p>
3097
3098 <blockquote>
3099 <pre>basic_streambuf(const basic_streambuf&amp; sb);
3100 basic_streambuf&amp; operator=(const basic_streambuf&amp; sb);
3101 </pre>
3102 </blockquote>
3103
3104 <p>Insert after 27.5.2.1, paragraph 2:</p>
3105 <blockquote>
3106 <pre>basic_streambuf(const basic_streambuf&amp; sb);
3107 </pre>
3108
3109 <p>Constructs a copy of sb.</p>
3110 <p>Postcondtions:</p>
3111 <pre>                eback() == sb.eback()
3112                 gptr()  == sb.gptr()
3113                 egptr() == sb.egptr()
3114                 pbase() == sb.pbase()
3115                 pptr()  == sb.pptr()
3116                 epptr() == sb.epptr()
3117                 getloc() == sb.getloc()
3118 </pre>
3119
3120 <pre>basic_streambuf&amp; operator=(const basic_streambuf&amp; sb);
3121 </pre>
3122
3123 <p>Assigns the data members of sb to this.</p>
3124
3125 <p>Postcondtions:</p>
3126 <pre>                eback() == sb.eback()
3127                 gptr()  == sb.gptr()
3128                 egptr() == sb.egptr()
3129                 pbase() == sb.pbase()
3130                 pptr()  == sb.pptr()
3131                 epptr() == sb.epptr()
3132                 getloc() == sb.getloc()
3133 </pre>
3134
3135 <p>Returns: *this.</p>
3136 </blockquote>
3137
3138 <p>27.7.1 [lib.stringbuf]:</p>
3139
3140 <p><b>Option A:</b></p>
3141
3142 <blockquote>
3143 <p>Insert into the basic_stringbuf synopsis in the private section:</p>
3144
3145 <pre>basic_stringbuf(const basic_stringbuf&amp;);             // not defined
3146 basic_stringbuf&amp; operator=(const basic_stringbuf&amp;);  // not defined
3147 </pre>
3148 </blockquote>
3149
3150 <p><b>Option B:</b></p>
3151
3152 <blockquote>
3153 <p>Insert into the basic_stringbuf synopsis in the public section:</p>
3154
3155 <pre>basic_stringbuf(const basic_stringbuf&amp; sb);
3156 basic_stringbuf&amp; operator=(const basic_stringbuf&amp; sb);
3157 </pre>
3158
3159 <p>27.7.1.1, insert after paragraph 4:</p>
3160
3161 <pre>basic_stringbuf(const basic_stringbuf&amp; sb);</pre>
3162
3163 <p>
3164 Constructs an independent copy of sb as if with sb.str(), and with the openmode that sb was constructed with.
3165 </p>
3166
3167 <p>Postcondtions: </p>
3168 <pre>               str() == sb.str()
3169                gptr()  - eback() == sb.gptr()  - sb.eback()
3170                egptr() - eback() == sb.egptr() - sb.eback()
3171                pptr()  - pbase() == sb.pptr()  - sb.pbase()
3172                getloc() == sb.getloc()
3173 </pre>
3174
3175 <p>
3176 Note: The only requirement on epptr() is that it point beyond the
3177 initialized range if an output sequence exists. There is no requirement
3178 that epptr() - pbase() == sb.epptr() - sb.pbase().
3179 </p>
3180
3181 <pre>basic_stringbuf&amp; operator=(const basic_stringbuf&amp; sb);</pre>
3182 <p>After assignment the basic_stringbuf has the same state as if it
3183 were initially copy constructed from sb, except that the
3184 basic_stringbuf is allowed to retain any excess capacity it might have,
3185 which may in turn effect the value of epptr().
3186 </p>
3187 </blockquote>
3188
3189 <p>27.8.1.1 [lib.filebuf]</p>
3190
3191 <p>Insert at the bottom of the basic_filebuf synopsis:</p>
3192
3193 <blockquote>
3194 <pre>private:
3195   basic_filebuf(const basic_filebuf&amp;);             // not defined
3196   basic_filebuf&amp; operator=(const basic_filebuf&amp;);  // not defined
3197 </pre>
3198 </blockquote>
3199 <p><i>[Kona: this is an issue for basic_streambuf itself and for its
3200   derived classes.  We are leaning toward allowing basic_streambuf to
3201   be copyable, and specifying its precise semantics.  (Probably the
3202   obvious: copying the buffer pointers.)  We are less sure whether
3203   the streambuf derived classes should be copyable.  Howard will
3204   write up a proposal.]</i></p>
3205
3206
3207 <p><i>[Sydney: Dietmar presented a new argument against basic_streambuf
3208   being copyable: it can lead to an encapsulation violation. Filebuf
3209   inherits from streambuf. Now suppose you inhert a my_hijacking_buf
3210   from streambuf. You can copy the streambuf portion of a filebuf to a
3211   my_hijacking_buf, giving you access to the pointers into the
3212   filebuf's internal buffer. Perhaps not a very strong argument, but
3213   it was strong enough to make people nervous. There was weak
3214   preference for having streambuf not be copyable. There was weak
3215   preference for having stringbuf not be copyable even if streambuf
3216   is. Move this issue to open for now.
3217 ]</i></p>
3218
3219
3220 <p><i>[
3221 2007-01-12, Howard:
3222 <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>
3223 recommends protected copy constructor and assignment for <tt>basic_streambuf</tt> with the same semantics
3224 as would be generated by the compiler.  These members aid in derived classes implementing move semantics.
3225 A protected copy constructor and copy assignment operator do not expose encapsulation more so than it is
3226 today as each data member of a <tt>basic_streambuf</tt> is already both readable and writable by derived
3227 classes via various get/set protected member functions (<tt>eback()</tt>, <tt>setp()</tt>, etc.).  Rather
3228 a protected copy constructor and copy assignment operator simply make the job of derived classes implementing
3229 move semantics less tedious and error prone.
3230 ]</i></p>
3231
3232
3233
3234
3235 <p><b>Rationale:</b></p>
3236 <p>
3237 27.5.2 [lib.streambuf]: The proposed basic_streambuf copy constructor
3238 and assignment operator are the same as currently implied by the lack
3239 of declarations: public and simply copies the data members.  This
3240 resolution is not a change but a clarification of the current
3241 standard.
3242 </p>
3243
3244 <p>
3245 27.7.1 [lib.stringbuf]: There are two reasonable options: A) Make
3246 basic_stringbuf not copyable.  This is likely the status-quo of
3247 current implementations.  B) Reasonable copy semantics of
3248 basic_stringbuf can be defined and implemented.  A copyable
3249 basic_streambuf is arguably more useful than a non-copyable one.  This
3250 should be considered as new functionality and not the fixing of a
3251 defect.  If option B is chosen, ramifications from issue 432 are taken
3252 into account.
3253 </p>
3254
3255 <p>
3256 27.8.1.1 [lib.filebuf]: There are no reasonable copy semantics for
3257 basic_filebuf.
3258 </p>
3259
3260
3261
3262
3263
3264
3265 <hr>
3266 <h3><a name="423"></a>423. effects of negative streamsize in iostreams</h3>
3267 <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>
3268  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
3269 <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>
3270 <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>
3271 <p><b>Discussion:</b></p>
3272
3273 <p>
3274 A third party test suite tries to exercise istream::ignore(N) with
3275 a negative value of N and expects that the implementation will treat
3276 N as if it were 0. Our implementation asserts that (N &gt;= 0) holds and
3277 aborts the test.
3278 </p>
3279
3280 <p>
3281 I can't find anything in section 27 that prohibits such values but I don't
3282 see what the effects of such calls should be, either (this applies to
3283 a number of unformatted input functions as well as some member functions
3284 of the basic_streambuf template).
3285 </p>
3286
3287
3288 <p><b>Proposed resolution:</b></p>
3289 <p>
3290 I propose that we add to each function in clause 27 that takes an argument,
3291 say N, of type streamsize a Requires clause saying that "N &gt;= 0." The intent
3292 is to allow negative streamsize values in calls to precision() and width()
3293 but disallow it in calls to streambuf::sgetn(), istream::ignore(), or
3294 ostream::write().
3295 </p>
3296
3297 <p><i>[Kona: The LWG agreed that this is probably what we want.  However, we
3298   need a review to find all places where functions in clause 27 take
3299   arguments of type streamsize that shouldn't be allowed to go
3300   negative.  Martin will do that review.]</i></p>
3301
3302
3303
3304
3305
3306
3307 <hr>
3308 <h3><a name="427"></a>427. stage 2 and rationale of DR 221</h3>
3309 <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>
3310  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
3311 <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>
3312 <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>
3313 <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>
3314 <p><b>Discussion:</b></p>
3315 <p>
3316 The requirements specified in Stage 2 and reiterated in the rationale
3317 of DR 221 (and echoed again in DR 303) specify that num_get&lt;charT&gt;::
3318 do_get() compares characters on the stream against the widened elements
3319 of "012...abc...ABCX+-"
3320 </p>
3321
3322 <p>
3323 An implementation is required to allow programs to instantiate the num_get
3324 template on any charT that satisfies the requirements on a user-defined
3325 character type. These requirements do not include the ability of the
3326 character type to be equality comparable (the char_traits template must
3327 be used to perform tests for equality). Hence, the num_get template cannot
3328 be implemented to support any arbitrary character type. The num_get template
3329 must either make the assumption that the character type is equality-comparable
3330 (as some popular implementations do), or it may use char_traits&lt;charT&gt; to do
3331 the comparisons (some other popular implementations do that). This diversity
3332 of approaches makes it difficult to write portable programs that attempt to
3333 instantiate the num_get template on user-defined types.
3334 </p>
3335
3336 <p><i>[Kona: the heart of the problem is that we're theoretically
3337   supposed to use traits classes for all fundamental character
3338   operations like assignment and comparison, but facets don't have
3339   traits parameters.  This is a fundamental design flaw and it
3340   appears all over the place, not just in this one place.  It's not
3341   clear what the correct solution is, but a thorough review of facets
3342   and traits is in order.  The LWG considered and rejected the
3343   possibility of changing numeric facets to use narrowing instead of
3344   widening.  This may be a good idea for other reasons (see issue
3345   <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
3346   issue.  Whether we use widen or narrow the <tt>num_get</tt> facet
3347   still has no idea which traits class the user wants to use for
3348   the comparison, because only streams, not facets, are passed traits
3349   classes.   The standard does not require that two different
3350   traits classes with the same <tt>char_type</tt> must necessarily
3351   have the same behavior.]</i></p>
3352
3353
3354 <p>Informally, one possibility: require that some of the basic
3355 character operations, such as <tt>eq</tt>, <tt>lt</tt>,
3356 and <tt>assign</tt>, must behave the same way for all traits classes
3357 with the same <tt>char_type</tt>.  If we accept that limitation on
3358 traits classes, then the facet could reasonably be required to
3359 use <tt>char_traits&lt;charT&gt;</tt>.</p>
3360
3361
3362 <p><b>Proposed resolution:</b></p>
3363
3364
3365
3366
3367 <hr>
3368 <h3><a name="430"></a>430. valarray subset operations</h3>
3369 <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>
3370  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
3371 <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>
3372 <p><b>Discussion:</b></p>
3373 <p>
3374 The standard fails to specify the behavior of valarray::operator[](slice)
3375 and other valarray subset operations when they are passed an "invalid"
3376 slice object, i.e., either a slice that doesn't make sense at all (e.g.,
3377 slice (0, 1, 0) or one that doesn't specify a valid subset of the valarray
3378 object (e.g., slice (2, 1, 1) for a valarray of size 1).
3379 </p>
3380 <p><i>[Kona: the LWG believes that invalid slices should invoke
3381   undefined behavior.  Valarrays are supposed to be designed for high
3382   performance, so we don't want to require specific checking.  We
3383   need wording to express this decision.]</i></p>
3384
3385
3386 <p><i>[
3387 Bellevue:
3388 ]</i></p>
3389
3390
3391 <blockquote>
3392 Please note that the standard also fails to specify the behavior of
3393 slice_array and gslice_array in the valid case. Bill Plauger will
3394 endeavor to provide revised wording for slice_array and gslice_array.
3395 </blockquote>
3396
3397 <p><i>[
3398 post-Bellevue:  Bill provided wording.
3399 ]</i></p>
3400
3401
3402
3403 <p><b>Proposed resolution:</b></p>
3404 <p>
3405 Insert after 26.5.2.4 [valarray.sub], paragraph 1:
3406 </p>
3407
3408 <blockquote>
3409 <p>
3410 The member operator is overloaded to provide several ways to select
3411 sequences
3412 of elements from among those controlled by <tt>*this</tt>. The first group of five
3413 member operators work in conjunction with various overloads of <tt>operator=</tt>
3414 (and other assigning operators) to allow selective replacement (slicing) of
3415 the controlled sequence. The selected elements must exist.
3416 </p>
3417 <p>
3418 The first member operator selects element off. For example:
3419 </p>
3420
3421 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
3422 v0[3] = 'A';
3423 // v0 == valarray&lt;char&gt;("abcAefghijklmnop", 16)
3424 </pre></blockquote>
3425
3426 <p>
3427 The second member operator selects those elements of the controlled sequence
3428 designated by <tt>slicearr</tt>. For example:
3429 </p>
3430
3431 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
3432 valarray&lt;char&gt; v1("ABCDE", 5);
3433 v0[slice(2, 5, 3)] = v1;
3434 // v0 == valarray&lt;char&gt;("abAdeBghCjkDmnEp", 16)
3435 </pre></blockquote>
3436
3437 <p>
3438 The third member operator selects those elements of the controlled sequence
3439 designated by <tt>gslicearr</tt>. For example:
3440 </p>
3441
3442 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
3443 valarray&lt;char&gt; v1("ABCDEF", 6);
3444 const size_t lv[] = {2, 3};
3445 const size_t dv[] = {7, 2};
3446 const valarray&lt;size_t&gt; len(lv, 2), str(dv, 2);
3447 v0[gslice(3, len, str)] = v1;
3448 // v0 == valarray&lt;char&gt;("abcAeBgCijDlEnFp", 16)
3449 </pre></blockquote>
3450
3451 <p>
3452 The fourth member operator selects those elements of the controlled sequence
3453 designated by <tt>boolarr</tt>. For example:
3454 </p>
3455
3456 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
3457 valarray&lt;char&gt; v1("ABC", 3);
3458 const bool vb[] = {false, false, true, true, false, true};
3459 v0[valarray&lt;bool&gt;(vb, 6)] = v1;
3460 // v0 == valarray&lt;char&gt;("abABeCghijklmnop", 16)
3461 </pre></blockquote>
3462
3463 <p>
3464 The fifth member operator selects those elements of the controlled sequence
3465 designated by indarr. For example:
3466 </p>
3467
3468 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
3469 valarray&lt;char&gt; v1("ABCDE", 5);
3470 const size_t vi[] = {7, 5, 2, 3, 8};
3471 v0[valarray&lt;size_t&gt;(vi, 5)] = v1;
3472 // v0 == valarray&lt;char&gt;("abCDeBgAEjklmnop", 16)
3473 </pre></blockquote>
3474
3475 <p>
3476 The second group of five member operators each construct an object that
3477 represents the value(s) selected. The selected elements must exist.
3478 </p>
3479
3480 <p>
3481 The sixth member operator returns the value of element off. For example:
3482 </p>
3483
3484 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
3485 // v0[3] returns 'd'
3486 </pre></blockquote>
3487
3488 <p>
3489 The seventh member operator returns an object of class <tt>valarray&lt;Ty&gt;</tt>
3490 containing those elements of the controlled sequence designated by <tt>slicearr</tt>.
3491 For example:
3492 </p>
3493
3494 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
3495 // v0[slice(2, 5, 3)] returns valarray&lt;char&gt;("cfilo", 5)
3496 </pre></blockquote>
3497
3498 <p>
3499 The eighth member operator selects those elements of the controlled sequence
3500 designated by <tt>gslicearr</tt>. For example:
3501 </p>
3502
3503 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
3504 const size_t lv[] = {2, 3};
3505 const size_t dv[] = {7, 2};
3506 const valarray&lt;size_t&gt; len(lv, 2), str(dv, 2);
3507 // v0[gslice(3, len, str)] returns
3508 // &nbsp;&nbsp;&nbsp;valarray&lt;char&gt;("dfhkmo", 6)
3509 </pre></blockquote>
3510
3511 <p>
3512 The ninth member operator selects those elements of the controlled sequence
3513 designated by <tt>boolarr</tt>. For example:
3514 </p>
3515
3516 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
3517 const bool vb[] = {false, false, true, true, false, true};
3518 // v0[valarray&lt;bool&gt;(vb, 6)] returns
3519 // &nbsp;&nbsp;&nbsp;valarray&lt;char&gt;("cdf", 3)
3520 </pre></blockquote>
3521
3522 <p>
3523 The last member operator selects those elements of the controlled sequence
3524 designated by <tt>indarr</tt>. For example:
3525 </p>
3526
3527 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
3528 const size_t vi[] = {7, 5, 2, 3, 8};
3529 // v0[valarray&lt;size_t&gt;(vi, 5)] returns
3530 //    valarray&lt;char&gt;("hfcdi", 5)
3531 </pre></blockquote>
3532
3533 </blockquote>
3534
3535
3536
3537
3538
3539 <hr>
3540 <h3><a name="431"></a>431. Swapping containers with unequal allocators</h3>
3541 <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>
3542  <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-09-20</p>
3543 <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>
3544 <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>
3545 <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>
3546 <p><b>Discussion:</b></p>
3547 <p>Clause 20.1.2 [allocator.requirements] paragraph 4 says that implementations
3548   are permitted to supply containers that are unable to cope with
3549   allocator instances and that container implementations may assume
3550   that all instances of an allocator type compare equal.  We gave
3551   implementers this latitude as a temporary hack, and eventually we
3552   want to get rid of it.  What happens when we're dealing with
3553   allocators that <i>don't</i> compare equal?
3554 </p>
3555
3556 <p>In particular: suppose that <tt>v1</tt> and <tt>v2</tt> are both
3557   objects of type <tt>vector&lt;int, my_alloc&gt;</tt> and that
3558   <tt>v1.get_allocator() != v2.get_allocator()</tt>.  What happens if
3559   we write <tt>v1.swap(v2)</tt>?  Informally, three possibilities:</p>
3560
3561 <p>1. This operation is illegal.  Perhaps we could say that an
3562   implementation is required to check and to throw an exception, or
3563   perhaps we could say it's undefined behavior.</p>
3564 <p>2. The operation performs a slow swap (i.e. using three
3565   invocations of <tt>operator=</tt>, leaving each allocator with its
3566   original container.  This would be an O(N) operation.</p>
3567 <p>3. The operation swaps both the vectors' contents and their
3568   allocators.  This would be an O(1) operation. That is:</p>
3569   <blockquote>
3570   <pre>    my_alloc a1(...);
3571     my_alloc a2(...);
3572     assert(a1 != a2);
3573
3574     vector&lt;int, my_alloc&gt; v1(a1);
3575     vector&lt;int, my_alloc&gt; v2(a2);
3576     assert(a1 == v1.get_allocator());
3577     assert(a2 == v2.get_allocator());
3578
3579     v1.swap(v2);
3580     assert(a1 == v2.get_allocator());
3581     assert(a2 == v1.get_allocator());
3582   </pre>
3583   </blockquote>
3584
3585 <p><i>[Kona: This is part of a general problem.  We need a paper
3586   saying how to deal with unequal allocators in general.]</i></p>
3587
3588
3589 <p><i>[pre-Sydney: Howard argues for option 3 in
3590 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1599.html">N1599</a>.
3591 ]</i></p>
3592
3593
3594 <p><i>[
3595 2007-01-12, Howard:  This issue will now tend to come up more often with move constructors
3596 and move assignment operators.  For containers, these members transfer resources (i.e.
3597 the allocated memory) just like swap.
3598 ]</i></p>
3599
3600
3601 <p><i>[
3602 Batavia:  There is agreement to overload the container <tt>swap</tt> on the allocator's Swappable
3603 requirement using concepts.  If the allocator supports Swappable, then container's swap will
3604 swap allocators, else it will perform a "slow swap" using copy construction and copy assignment.
3605 ]</i></p>
3606
3607
3608
3609
3610 <p><b>Proposed resolution:</b></p>
3611
3612
3613
3614
3615
3616 <hr>
3617 <h3><a name="446"></a>446. Iterator equality between different containers</h3>
3618 <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>
3619  <b>Submitter:</b> Andy Koenig <b>Date:</b> 2003-12-16</p>
3620 <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>
3621 <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>
3622 <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>
3623 <p><b>Discussion:</b></p>
3624 <p>
3625 What requirements does the standard place on equality comparisons between
3626 iterators that refer to elements of different containers.  For example, if
3627 v1 and v2 are empty vectors, is v1.end() == v2.end() allowed to yield true?
3628 Is it allowed to throw an exception?
3629 </p>
3630
3631 <p>
3632 The standard appears to be silent on both questions.
3633 </p>
3634 <p><i>[Sydney: The intention is that comparing two iterators from
3635 different containers is undefined, but it's not clear if we say that,
3636 or even whether it's something we should be saying in clause 23 or in
3637 clause 24.  Intuitively we might want to say that equality is defined
3638 only if one iterator is reachable from another, but figuring out how
3639 to say it in any sensible way is a bit tricky: reachability is defined
3640 in terms of equality, so we can't also define equality in terms of
3641 reachability.
3642 ]</i></p>
3643
3644
3645
3646
3647 <p><b>Proposed resolution:</b></p>
3648
3649
3650
3651
3652
3653
3654 <hr>
3655 <h3><a name="454"></a>454. basic_filebuf::open should accept wchar_t names</h3>
3656 <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>
3657  <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
3658 <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>
3659 <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>
3660 <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>
3661 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a></p>
3662 <p><b>Discussion:</b></p>
3663 <pre>    basic_filebuf *basic_filebuf::open(const char *, ios_base::open_mode);
3664 </pre>
3665
3666 <p>should be supplemented with the overload:</p>
3667
3668 <pre>    basic_filebuf *basic_filebuf::open(const wchar_t *, ios_base::open_mode);
3669 </pre>
3670
3671 <p>
3672 Depending on the operating system, one of these forms is fundamental and
3673 the other requires an implementation-defined mapping to determine the
3674 actual filename.
3675 </p>
3676
3677 <p><i>[Sydney: Yes, we want to allow wchar_t filenames.  Bill will
3678   provide wording.]</i></p>
3679
3680
3681 <p><i>[
3682 In Toronto we noted that this is issue 5 from
3683 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1569.htm">N1569</a>.
3684 ]</i></p>
3685
3686 <p>
3687 How does this interact with the newly-defined character types, and how
3688 do we avoid interface explosion considering <tt>std::string</tt> overloads that
3689 were added? Propose another solution that is different than the
3690 suggestion proposed by PJP.
3691 </p>
3692 <p>
3693 Suggestion is to make a member template function for <tt>basic_string</tt> (for
3694 <tt>char</tt>, <tt>wchar_t</tt>, <tt>u16char</tt>, <tt>u32char</tt> instantiations), and then just keep a
3695 <tt>const char*</tt> member.
3696 </p>
3697 <p>
3698 Goal is to do implicit conversion between character string literals to
3699 appropriate <tt>basic_string</tt> type. Not quite sure if this is possible.
3700 </p>
3701 <p>
3702 Implementors are free to add specific overloads for non-char character
3703 types.
3704 </p>
3705
3706
3707
3708 <p><b>Proposed resolution:</b></p>
3709
3710 <p>Change from:</p>
3711 <blockquote>
3712 <pre>basic_filebuf&lt;charT,traits&gt;* open(
3713         const char* s,
3714         ios_base::openmode mode );
3715 </pre>
3716
3717 <p>
3718 Effects: If is_open() != false, returns a null pointer.
3719 Otherwise, initializes the filebuf as required. It then
3720 opens a file, if possible, whose name is the NTBS s ("as if"
3721 by calling std::fopen(s,modstr)).</p>
3722 </blockquote>
3723
3724 <p>to:</p>
3725
3726 <blockquote>
3727 <pre>basic_filebuf&lt;charT,traits&gt;* open(
3728         const char* s,
3729         ios_base::openmode mode );
3730
3731 basic_filebuf&lt;charT,traits&gt;* open(
3732         const wchar_t* ws,
3733         ios_base::openmode mode );
3734 </pre>
3735
3736 <p>
3737 Effects: If is_open() != false, returns a null pointer.
3738 Otherwise, initializes the filebuf as required. It then
3739 opens a file, if possible, whose name is the NTBS s ("as if"
3740 by calling std::fopen(s,modstr)).
3741 For the second signature, the NTBS s is determined from the
3742 WCBS ws in an implementation-defined manner.
3743 </p>
3744
3745 <p>
3746 (NOTE: For a system that "naturally" represents a filename
3747 as a WCBS, the NTBS s in the first signature may instead
3748 be mapped to a WCBS; if so, it follows the same mapping
3749 rules as the first argument to open.)
3750 </p>
3751 </blockquote>
3752
3753
3754
3755 <p><b>Rationale:</b></p>
3756 <p>
3757 Slightly controversial, but by a 7-1 straw poll the LWG agreed to move
3758 this to Ready.  The controversy was because the mapping between wide
3759 names and files in a filesystem is implementation defined.  The
3760 counterargument, which most but not all LWG members accepted, is that
3761 the mapping between narrow files names and files is also
3762 implemenation defined.</p>
3763
3764 <p><i>[Lillehammer: Moved back to "open" status, at Beman's urging.
3765 (1) Why just basic_filebuf, instead of also basic_fstream (and
3766 possibly other things too). (2) Why not also constructors that take
3767 std::basic_string? (3) We might want to wait until we see Beman's
3768 filesystem library; we might decide that it obviates this.]</i></p>
3769
3770
3771 <p><i>[
3772 post Bellevue:
3773 ]</i></p>
3774
3775
3776 <blockquote>
3777 <p>
3778 Move again to Ready.
3779 </p>
3780 <p>
3781 There is a timing issue here. Since the filesystem library will not be
3782 in C++0x, this should be brought forward. This solution would remain
3783 valid in the context of the proposed filesystem.
3784 </p>
3785 <p>
3786 This issue has been kicking around for a while, and the wchar_t addition
3787 alone would help many users. Thus, we suggest putting this on the
3788 reflector list with an invitation for someone to produce proposed
3789 wording that covers basic_fstream. In the meantime, we suggest that the
3790 proposed wording be adopted as-is.
3791 </p>
3792 <p>
3793 If more of the Lillehammer questions come back, they should be
3794 introduced as separate issues.
3795 </p>
3796 </blockquote>
3797
3798
3799
3800
3801
3802
3803
3804
3805 <hr>
3806 <h3><a name="458"></a>458. 24.1.5 contains unintented limitation for operator-</h3>
3807 <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>
3808  <b>Submitter:</b> Daniel Frey <b>Date:</b> 2004-02-27</p>
3809 <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>
3810 <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>
3811 <p><b>Discussion:</b></p>
3812 <p>
3813 In 24.1.5 [lib.random.access.iterators], table 76 the operational
3814 semantics for the expression "r -= n" are defined as "return r += -n".
3815 This means, that the expression -n must be valid, which is not the case
3816 for unsigned types.
3817 </p>
3818
3819 <p><i>[
3820 Sydney: Possibly not a real problem, since difference type is required
3821 to be a signed integer type. However, the wording in the standard may
3822 be less clear than we would like.
3823 ]</i></p>
3824
3825
3826
3827
3828 <p><b>Proposed resolution:</b></p>
3829 <p>
3830 To remove this limitation, I suggest to change the
3831 operational semantics for this column to:
3832 </p>
3833 <blockquote><pre>    { Distance m = n;
3834       if (m &gt;= 0)
3835         while (m--) --r;
3836       else
3837         while (m++) ++r;
3838       return r; }
3839 </pre></blockquote>
3840
3841
3842
3843
3844
3845
3846 <hr>
3847 <h3><a name="459"></a>459. Requirement for widening in stage 2 is overspecification</h3>
3848 <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>
3849  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-03-16</p>
3850 <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>
3851 <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>
3852 <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>
3853 <p><b>Discussion:</b></p>
3854 <p>When parsing strings of wide-character digits, the standard
3855   requires the library to widen narrow-character "atoms" and compare
3856   the widened atoms against the characters that are being parsed.
3857   Simply narrowing the wide characters would be far simpler, and
3858   probably more efficient.  The two choices are equivalent except in
3859   convoluted test cases, and many implementations already ignore the
3860   standard and use narrow instead of widen.</p>
3861
3862 <p>
3863 First, I disagree that using narrow() instead of widen() would
3864 necessarily have unfortunate performance implications. A possible
3865 implementation of narrow() that allows num_get to be implemented
3866 in a much simpler and arguably comparably efficient way as calling
3867 widen() allows, i.e. without making a virtual call to do_narrow every
3868 time, is as follows:
3869 </p>
3870
3871 <pre>  inline char ctype&lt;wchar_t&gt;::narrow (wchar_t wc, char dflt) const
3872   {
3873       const unsigned wi = unsigned (wc);
3874
3875       if (wi &gt; UCHAR_MAX)
3876           return typeid (*this) == typeid (ctype&lt;wchar_t&gt;) ?
3877                  dflt : do_narrow (wc, dflt);
3878
3879       if (narrow_ [wi] &lt; 0) {
3880          const char nc = do_narrow (wc, dflt);
3881          if (nc == dflt)
3882              return dflt;
3883          narrow_ [wi] = nc;
3884       }
3885
3886       return char (narrow_ [wi]);
3887   }
3888 </pre>
3889
3890 <p>
3891 Second, I don't think the change proposed in the issue (i.e., to use
3892 narrow() instead of widen() during Stage 2) would be at all
3893 drastic. Existing implementations with the exception of libstdc++
3894 currently already use narrow() so the impact of the change on programs
3895 would presumably be isolated to just a single implementation. Further,
3896 since narrow() is not required to translate alternate wide digit
3897 representations such as those mentioned in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a>
3898 to
3899 their narrow equivalents (i.e., the portable source characters '0'
3900 through '9'), the change does not necessarily imply that these
3901 alternate digits would be treated as ordinary digits and accepted as
3902 part of numbers during parsing. In fact, the requirement in 22.2.1.1.2
3903 [locale.ctype.virtuals], p13 forbids narrow() to translate an alternate
3904 digit character, wc, to an ordinary digit in the basic source
3905 character set unless the expression
3906 (ctype&lt;charT&gt;::is(ctype_base::digit, wc) == true) holds. This in
3907 turn is prohibited by the C standard (7.25.2.1.5, 7.25.2.1.5, and
3908 5.2.1, respectively) for charT of either char or wchar_t.
3909 </p>
3910
3911 <p><i>[Sydney: To a large extent this is a nonproblem. As long as
3912 you're only trafficking in char and wchar_t we're only dealing with a
3913 stable character set, so you don't really need either 'widen' or
3914 'narrow': can just use literals. Finally, it's not even clear whether
3915 widen-vs-narrow is the right question; arguably we should be using
3916 codecvt instead.]</i></p>
3917
3918
3919
3920
3921 <p><b>Proposed resolution:</b></p>
3922 <p>Change stage 2 so that implementations are permitted to use either
3923 technique to perform the comparison:</p>
3924 <ol>
3925   <li> call widen on the atoms and compare (either by using
3926       operator== or char_traits&lt;charT&gt;::eq) the input with
3927       the widened atoms, or</li>
3928   <li> call narrow on the input and compare the narrow input
3929       with the atoms</li>
3930   <li> do (1) or (2) only if charT is not char or wchar_t,
3931       respectively; i.e., avoid calling widen or narrow
3932       if it the source and destination types are the same</li>
3933 </ol>
3934
3935
3936
3937
3938
3939 <hr>
3940 <h3><a name="463"></a>463. auto_ptr usability issues</h3>
3941 <p><b>Section:</b> D.9.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
3942  <b>Submitter:</b> Rani Sharoni <b>Date:</b> 2003-12-07</p>
3943 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#auto.ptr">issues</a> in [auto.ptr].</p>
3944 <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>
3945 <p><b>Discussion:</b></p>
3946
3947 <p>
3948 TC1 CWG DR #84 effectively made the template&lt;class Y&gt; operator auto_ptr&lt;Y&gt;()
3949 member of auto_ptr (20.4.5.3/4) obsolete.
3950 </p>
3951
3952 <p>
3953 The sole purpose of this obsolete conversion member is to enable copy
3954 initialization base from r-value derived (or any convertible types like
3955 cv-types) case:
3956 </p>
3957 <pre>#include &lt;memory&gt;
3958 using std::auto_ptr;
3959
3960 struct B {};
3961 struct D : B {};
3962
3963 auto_ptr&lt;D&gt; source();
3964 int sink(auto_ptr&lt;B&gt;);
3965 int x1 = sink( source() ); // #1 EDG - no suitable copy constructor
3966 </pre>
3967
3968 <p>
3969 The excellent analysis of conversion operations that was given in the final
3970 auto_ptr proposal
3971 (http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/1997/N1128.pdf)
3972 explicitly specifies this case analysis (case 4). DR #84 makes the analysis
3973 wrong and actually comes to forbid the loophole that was exploited by the
3974 auto_ptr designers.
3975 </p>
3976
3977 <p>
3978 I didn't encounter any compliant compiler (e.g. EDG, GCC, BCC and VC) that
3979 ever allowed this case. This is probably because it requires 3 user defined
3980 conversions and in fact current compilers conform to DR #84.
3981 </p>
3982
3983 <p>
3984 I was surprised to discover that the obsolete conversion member actually has
3985 negative impact of the copy initialization base from l-value derived
3986 case:</p>
3987 <pre>auto_ptr&lt;D&gt; dp;
3988 int x2 = sink(dp); // #2 EDG - more than one user-defined conversion applies
3989 </pre>
3990
3991 <p>
3992 I'm sure that the original intention was allowing this initialization using
3993 the template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;&amp; a) constructor (20.4.5.1/4) but
3994 since in this copy initialization it's merely user defined conversion (UDC)
3995 and the obsolete conversion member is UDC with the same rank (for the early
3996 overloading stage) there is an ambiguity between them.
3997 </p>
3998
3999 <p>
4000 Removing the obsolete member will have impact on code that explicitly
4001 invokes it:
4002 </p>
4003 <pre>int y = sink(source().operator auto_ptr&lt;B&gt;());
4004 </pre>
4005
4006 <p>
4007 IMHO no one ever wrote such awkward code and the reasonable workaround for
4008 #1 is:
4009 </p>
4010 <pre>int y = sink( auto_ptr&lt;B&gt;(source()) );
4011 </pre>
4012
4013 <p>
4014 I was even more surprised to find out that after removing the obsolete
4015 conversion member the initialization was still ill-formed:
4016 int x3 = sink(dp); // #3 EDG - no suitable copy constructor
4017 </p>
4018
4019 <p>
4020 This copy initialization semantically requires copy constructor which means
4021 that both template conversion constructor and the auto_ptr_ref conversion
4022 member (20.4.5.3/3) are required which is what was explicitly forbidden in
4023 DR #84. This is a bit amusing case in which removing ambiguity results with
4024 no candidates.
4025 </p>
4026
4027 <p>
4028 I also found exception safety issue with auto_ptr related to auto_ptr_ref:
4029 </p>
4030 <pre>int f(auto_ptr&lt;B&gt;, std::string);
4031 auto_ptr&lt;B&gt; source2();
4032
4033 // string constructor throws while auto_ptr_ref
4034 // "holds" the pointer
4035 int x4 = f(source2(), "xyz"); // #4
4036 </pre>
4037
4038 <p>
4039 The theoretic execution sequence that will cause a leak:
4040 </p>
4041 <ol>
4042 <li>call auto_ptr&lt;B&gt;::operator auto_ptr_ref&lt;B&gt;()</li>
4043 <li>call string::string(char const*) and throw</li>
4044 </ol>
4045
4046 <p>
4047 According to 20.4.5.3/3 and 20.4.5/2 the auto_ptr_ref conversion member
4048 returns auto_ptr_ref&lt;Y&gt; that holds *this and this is another defect since
4049 the type of *this is auto_ptr&lt;X&gt; where X might be different from Y. Several
4050 library vendors (e.g. SGI) implement auto_ptr_ref&lt;Y&gt; with Y* as member which
4051 is much more reasonable. Other vendor implemented auto_ptr_ref as
4052 defectively required and it results with awkward and catastrophic code:
4053 int oops = sink(auto_ptr&lt;B&gt;(source())); // warning recursive on all control
4054 paths
4055 </p>
4056
4057 <p>
4058 Dave Abrahams noticed that there is no specification saying that
4059 auto_ptr_ref copy constructor can't throw.
4060 </p>
4061
4062 <p>
4063 My proposal comes to solve all the above issues and significantly simplify
4064 auto_ptr implementation. One of the fundamental requirements from auto_ptr
4065 is that it can be constructed in an intuitive manner (i.e. like ordinary
4066 pointers) but with strict ownership semantics which yield that source
4067 auto_ptr in initialization must be non-const. My idea is to add additional
4068 constructor template with sole propose to generate ill-formed, diagnostic
4069 required, instance for const auto_ptr arguments during instantiation of
4070 declaration. This special constructor will not be instantiated for other
4071 types which is achievable using 14.8.2/2 (SFINAE). Having this constructor
4072 in hand makes the constructor template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp;)
4073 legitimate since the actual argument can't be const yet non const r-value
4074 are acceptable.
4075 </p>
4076
4077 <p>
4078 This implementation technique makes the "private auxiliary class"
4079 auto_ptr_ref obsolete and I found out that modern C++ compilers (e.g. EDG,
4080 GCC and VC) consume the new implementation as expected and allow all
4081 intuitive initialization and assignment cases while rejecting illegal cases
4082 that involve const auto_ptr arguments.
4083 </p>
4084
4085 <p>The proposed auto_ptr interface:</p>
4086
4087 <pre>namespace std {
4088     template&lt;class X&gt; class auto_ptr {
4089     public:
4090         typedef X element_type;
4091
4092         // 20.4.5.1 construct/copy/destroy:
4093         explicit auto_ptr(X* p=0) throw();
4094         auto_ptr(auto_ptr&amp;) throw();
4095         template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp;) throw();
4096         auto_ptr&amp; operator=(auto_ptr&amp;) throw();
4097         template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;) throw();
4098         ~auto_ptr() throw();
4099
4100         // 20.4.5.2 members:
4101         X&amp; operator*() const throw();
4102         X* operator-&gt;() const throw();
4103         X* get() const throw();
4104         X* release() throw();
4105         void reset(X* p=0) throw();
4106
4107     private:
4108         template&lt;class U&gt;
4109         auto_ptr(U&amp; rhs, typename
4110 unspecified_error_on_const_auto_ptr&lt;U&gt;::type = 0);
4111     };
4112 }
4113 </pre>
4114
4115 <p>
4116 One compliant technique to implement the unspecified_error_on_const_auto_ptr
4117 helper class is using additional private auto_ptr member class template like
4118 the following:
4119 </p>
4120 <pre>template&lt;typename T&gt; struct unspecified_error_on_const_auto_ptr;
4121
4122 template&lt;typename T&gt;
4123 struct unspecified_error_on_const_auto_ptr&lt;auto_ptr&lt;T&gt; const&gt;
4124 { typedef typename auto_ptr&lt;T&gt;::const_auto_ptr_is_not_allowed type; };
4125 </pre>
4126
4127 <p>
4128 There are other techniques to implement this helper class that might work
4129 better for different compliers (i.e. better diagnostics) and therefore I
4130 suggest defining its semantic behavior without mandating any specific
4131 implementation. IMO, and I didn't found any compiler that thinks otherwise,
4132 14.7.1/5 doesn't theoretically defeat the suggested technique but I suggest
4133 verifying this with core language experts.
4134 </p>
4135
4136 <p><b>Further changes in standard text:</b></p>
4137 <p>Remove section 20.4.5.3</p>
4138
4139 <p>Change 20.4.5/2 to read something like:
4140 Initializing auto_ptr&lt;X&gt; from const auto_ptr&lt;Y&gt; will result with unspecified
4141 ill-formed declaration that will require unspecified diagnostic.</p>
4142
4143 <p>Change 20.4.5.1/4,5,6 to read:</p>
4144
4145 <pre>template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp; a) throw();</pre>
4146 <p> 4 Requires: Y* can be implicitly converted to X*.</p>
4147 <p> 5 Effects: Calls const_cast&lt;auto_ptr&lt;Y&gt;&amp;&gt;(a).release().</p>
4148 <p> 6 Postconditions: *this holds the pointer returned from a.release().</p>
4149
4150 <p>Change 20.4.5.1/10</p>
4151 <pre>template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt; a) throw();
4152 </pre>
4153 <p>
4154 10 Requires: Y* can be implicitly converted to X*. The expression delete
4155 get() is well formed.
4156 </p>
4157
4158 <p>LWG TC DR #127 is obsolete.</p>
4159
4160 <p>
4161 Notice that the copy constructor and copy assignment operator should remain
4162 as before and accept non-const auto_ptr&amp; since they have effect on the form
4163 of the implicitly declared copy constructor and copy assignment operator of
4164 class that contains auto_ptr as member per 12.8/5,10:
4165 </p>
4166 <pre>struct X {
4167     // implicit X(X&amp;)
4168     // implicit X&amp; operator=(X&amp;)
4169     auto_ptr&lt;D&gt; aptr_;
4170 };
4171 </pre>
4172
4173 <p>
4174 In most cases this indicates about sloppy programming but preserves the
4175 current auto_ptr behavior.
4176 </p>
4177
4178 <p>
4179 Dave Abrahams encouraged me to suggest fallback implementation in case that
4180 my suggestion that involves removing of auto_ptr_ref will not be accepted.
4181 In this case removing the obsolete conversion member to auto_ptr&lt;Y&gt; and
4182 20.4.5.3/4,5 is still required in order to eliminate ambiguity in legal
4183 cases. The two constructors that I suggested will co exist with the current
4184 members but will make auto_ptr_ref obsolete in initialization contexts.
4185 auto_ptr_ref will be effective in assignment contexts as suggested in DR
4186 #127 and I can't see any serious exception safety issues in those cases
4187 (although it's possible to synthesize such). auto_ptr_ref&lt;X&gt; semantics will
4188 have to be revised to say that it strictly holds pointer of type X and not
4189 reference to an auto_ptr for the favor of cases in which auto_ptr_ref&lt;Y&gt; is
4190 constructed from auto_ptr&lt;X&gt; in which X is different from Y (i.e. assignment
4191 from r-value derived to base).
4192 </p>
4193
4194 <p><i>[Redmond: punt for the moment. We haven't decided yet whether we
4195   want to fix auto_ptr for C++-0x, or remove it and replace it with
4196   move_ptr and unique_ptr.]</i></p>
4197
4198
4199 <p><i>[
4200 Oxford 2007: Recommend NAD.  We're just going to deprecate it.  It still works for simple use cases
4201 and people know how to deal with it.  Going forward <tt>unique_ptr</tt> is the recommended
4202 tool.
4203 ]</i></p>
4204
4205
4206 <p><i>[
4207 2007-11-09: Reopened at the request of David Abrahams, Alisdair Meredith and Gabriel Dos Reis.
4208 ]</i></p>
4209
4210
4211
4212
4213 <p><b>Proposed resolution:</b></p>
4214 <p>
4215 Change the synopsis in D.9.1 [auto.ptr]:
4216 </p>
4217
4218 <blockquote><pre>namespace std {
4219   <del>template &lt;class Y&gt; struct auto_ptr_ref {};</del>
4220
4221   <ins>// exposition only</ins>
4222   <ins>template &lt;class T&gt; struct constant_object;</ins>
4223
4224   <ins>// exposition only</ins>
4225   <ins>template &lt;class T&gt;</ins>
4226   <ins>struct cannot_transfer_ownership_from</ins>
4227     <ins>: constant_object&lt;T&gt; {};</ins>
4228
4229   template &lt;class X&gt; class auto_ptr {
4230   public:
4231     typedef X element_type;
4232
4233     // D.9.1.1 construct/copy/destroy:
4234     explicit auto_ptr(X* p =0) throw();
4235     auto_ptr(auto_ptr&amp;) throw();
4236     template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;<ins> const</ins>&amp;) throw();
4237     auto_ptr&amp; operator=(auto_ptr&amp;) throw();
4238     template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del>) throw();
4239     <del>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw();</del>
4240     ~auto_ptr() throw();
4241
4242     // D.9.1.2 members:
4243     X&amp; operator*() const throw();
4244     X* operator-&gt;() const throw();
4245     X* get() const throw();
4246     X* release() throw();
4247     void reset(X* p =0) throw();
4248
4249     <del>// D.9.1.3 conversions:</del>
4250     <del>auto_ptr(auto_ptr_ref&lt;X&gt;) throw();</del>
4251     <del>template&lt;class Y&gt; operator auto_ptr_ref&lt;Y&gt;() throw();</del>
4252     <del>template&lt;class Y&gt; operator auto_ptr&lt;Y&gt;() throw();</del>
4253
4254     <ins>// exposition only</ins>
4255     <ins>template&lt;class U&gt;</ins>
4256     <ins>auto_ptr(U&amp; rhs, typename cannot_transfer_ownership_from&lt;U&gt;::error = 0);</ins>
4257   };
4258
4259   template &lt;&gt; class auto_ptr&lt;void&gt;
4260   {
4261   public:
4262     typedef void element_type;
4263   };
4264
4265 }
4266 </pre></blockquote>
4267
4268 <p>
4269 Remove D.9.1.3 [auto.ptr.conv].
4270 </p>
4271
4272 <p>
4273 Change D.9.1 [auto.ptr], p3:
4274 </p>
4275
4276 <blockquote>
4277 The <tt>auto_ptr</tt> provides a semantics of strict ownership. An
4278 <tt>auto_ptr</tt> owns the object it holds a pointer to. Copying an
4279 <tt>auto_ptr</tt> copies the pointer and transfers ownership to the
4280 destination. If more than one <tt>auto_ptr</tt> owns the same object at
4281 the same time the behavior of the program is undefined. <ins>Templates
4282 <tt>constant_object</tt> and <tt>cannot_transfer_ownership_from</tt>,
4283 and the final constructor of <tt>auto_ptr</tt> are for exposition only.
4284 For any types <tt>X</tt> and <tt>Y</tt>, initializing
4285 <tt>auto_ptr&lt;X&gt;</tt> from <tt>const auto_ptr&lt;Y&gt;</tt> is
4286 ill-formed, diagnostic required.</ins> [<i>Note:</i> The uses of
4287 <tt>auto_ptr</tt> include providing temporary exception-safety for
4288 dynamically allocated memory, passing ownership of dynamically allocated
4289 memory to a function, and returning dynamically allocated memory from a
4290 function. <tt>auto_ptr</tt> does not meet the <tt>CopyConstructible</tt>
4291 and <tt>Assignable</tt> requirements for Standard Library container
4292 elements and thus instantiating a Standard Library container with an
4293 <tt>auto_ptr</tt> results in undefined behavior. <i>-- end note</i>]
4294 </blockquote>
4295
4296 <p>
4297 Change D.9.1.1 [auto.ptr.cons], p5:
4298 </p>
4299
4300 <blockquote>
4301 <pre>template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;<ins> const</ins>&amp; a) throw();
4302 </pre>
4303 <blockquote>
4304 <p>
4305 <i>Requires:</i> <tt>Y*</tt> can be implicitly converted to <tt>X*</tt>.
4306 </p>
4307 <p>
4308 <i>Effects:</i> Calls <ins><tt>const_cast&lt;auto_ptr&lt;Y&gt;&amp;&gt;(</tt></ins><tt>a</tt><ins><tt>)</tt></ins><tt>.release()</tt>.
4309 </p>
4310 <p>
4311 <i>Postconditions:</i> <tt>*this</tt> holds the pointer returned from <tt>a.release()</tt>.
4312 </p>
4313 </blockquote>
4314 </blockquote>
4315
4316 <p>
4317 Change D.9.1.1 [auto.ptr.cons], p10:
4318 </p>
4319
4320 <blockquote>
4321 <pre>template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del> a) throw();
4322 </pre>
4323 <blockquote>
4324 <p>
4325 <i>Requires:</i> <tt>Y*</tt> can be implicitly converted to <tt>X*</tt>.
4326 The expression <tt>delete get()</tt> is well formed.
4327 </p>
4328 <p>
4329 <i>Effects:</i> Calls <tt>reset(a.release())</tt>.
4330 </p>
4331 <p>
4332 <i>Returns:</i> <tt>*this</tt>.
4333 </p>
4334 </blockquote>
4335 </blockquote>
4336
4337
4338
4339
4340
4341
4342 <hr>
4343 <h3><a name="471"></a>471. result of what() implementation-defined</h3>
4344 <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#Ready">Ready</a>
4345  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-28</p>
4346 <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>
4347 <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>
4348 <p><b>Discussion:</b></p>
4349
4350 <p>[lib.exception] specifies the following:</p>
4351 <pre>    exception (const exception&amp;) throw();
4352     exception&amp; operator= (const exception&amp;) throw();
4353
4354     -4- Effects: Copies an exception object.
4355     -5- Notes: The effects of calling what() after assignment
4356         are implementation-defined.
4357 </pre>
4358
4359 <p>
4360 First, does the Note only apply to the assignment operator? If so,
4361 what are the effects of calling what() on a copy of an object? Is
4362 the returned pointer supposed to point to an identical copy of
4363 the NTBS returned by what() called on the original object or not?
4364 </p>
4365
4366 <p>
4367 Second, is this Note intended to extend to all the derived classes
4368 in section 19? I.e., does the standard provide any guarantee for
4369 the effects of what() called on a copy of any of the derived class
4370 described in section 19?
4371 </p>
4372
4373 <p>
4374 Finally, if the answer to the first question is no, I believe it
4375 constitutes a defect since throwing an exception object typically
4376 implies invoking the copy ctor on the object. If the answer is yes,
4377 then I believe the standard ought to be clarified to spell out
4378 exactly what the effects are on the copy (i.e., after the copy
4379 ctor was called).
4380 </p>
4381
4382 <p><i>[Redmond: Yes, this is fuzzy.  The issue of derived classes is
4383   fuzzy too.]</i></p>
4384
4385
4386 <p><i>[
4387 Batavia: Howard provided wording.
4388 ]</i></p>
4389
4390
4391 <p><i>[
4392 Bellevue:
4393 ]</i></p>
4394
4395
4396 <blockquote>
4397 <p>
4398 Eric concerned this is unimplementable, due to nothrow guarantees.
4399 Suggested implementation would involve reference counting.
4400 </p>
4401 <p>
4402 Is the implied reference counting subtle enough to call out a note on
4403 implementation? Probably not.
4404 </p>
4405 <p>
4406 If reference counting required, could we tighten specification further
4407 to require same pointer value? Probably an overspecification, especially
4408 if exception classes defer evalutation of final string to calls to
4409 what().
4410 </p>
4411 <p>
4412 Remember issue moved open and not resolved at Batavia, but cannot
4413 remember who objected to canvas a disenting opinion - please speak up if
4414 you disagree while reading these minutes!
4415 </p>
4416 <p>
4417 Move to Ready as we are accepting words unmodified.
4418 </p>
4419 </blockquote>
4420
4421
4422
4423 <p><b>Proposed resolution:</b></p>
4424
4425 <p>
4426 Change 18.7.1 [exception] to:
4427 </p>
4428
4429 <blockquote>
4430 <pre>exception(const exception&amp; <ins><i>e</i></ins>) throw();
4431 exception&amp; operator=(const exception&amp; <ins><i>e</i></ins>) throw();</pre>
4432 <blockquote>
4433 <p>
4434 -4- <i>Effects:</i> Copies an exception object.
4435 </p>
4436 <p>
4437 <del> -5- <i>Remarks:</i> The effects of calling what() after assignment are implementation-defined.</del>
4438 </p>
4439 <p>
4440 <ins>-5- <i>Throws:</i> Nothing.  This also applies
4441 to all standard library-defined classes that derive from <tt>exception</tt>.</ins>
4442 </p>
4443 <p>
4444 <ins>-7- <i>Postcondition:</i> <tt>strcmp(what(), <i>e</i>.what()) == 0</tt>.  This also applies
4445 to all standard library-defined classes that derive from <tt>exception</tt>.</ins>
4446 </p>
4447
4448 </blockquote>
4449 </blockquote>
4450
4451
4452
4453
4454 <hr>
4455 <h3><a name="473"></a>473. underspecified ctype calls</h3>
4456 <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>
4457  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-07-01</p>
4458 <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>
4459 <p><b>Discussion:</b></p>
4460 <p>
4461 Most ctype member functions come in two forms: one that operates
4462 on a single character at a time and another form that operates
4463 on a range of characters. Both forms are typically described by
4464 a single Effects and/or Returns clause.
4465 </p>
4466 <p>
4467 The Returns clause of each of the single-character non-virtual forms
4468 suggests that the function calls the corresponding single character
4469 virtual function, and that the array form calls the corresponding
4470 virtual array form. Neither of the two forms of each virtual member
4471 function is required to be implemented in terms of the other.
4472 </p>
4473 <p>
4474 There are three problems:
4475 </p>
4476 <p>
4477 1. One is that while the standard does suggest that each non-virtual
4478 member function calls the corresponding form of the virtual function,
4479 it doesn't actually explicitly require it.
4480 </p>
4481 <p>
4482 Implementations that cache results from some of the virtual member
4483 functions for some or all values of their arguments might want to
4484 call the array form from the non-array form the first time to fill
4485 the cache and avoid any or most subsequent virtual calls. Programs
4486 that rely on each form of the virtual function being called from
4487 the corresponding non-virtual function will see unexpected behavior
4488 when using such implementations.
4489 </p>
4490 <p>
4491 2. The second problem is that either form of each of the virtual
4492 functions can be overridden by a user-defined function in a derived
4493 class to return a value that is different from the one produced by
4494 the virtual function of the alternate form that has not been
4495 overriden.
4496 </p>
4497 <p>
4498 Thus, it might be possible for, say, ctype::widen(c) to return one
4499 value, while for ctype::widen(&amp;c, &amp;c + 1, &amp;wc) to set
4500 wc to another value. This is almost certainly not intended. Both
4501 forms of every function should be required to return the same result
4502 for the same character, otherwise the same program using an
4503 implementation that calls one form of the functions will behave
4504 differently than when using another implementation that calls the
4505 other form of the function "under the hood."
4506 </p>
4507 <p>
4508 3. The last problem is that the standard text fails to specify whether
4509 one form of any of the virtual functions is permitted to be implemented
4510 in terms of the other form or not, and if so, whether it is required
4511 or permitted to call the overridden virtual function or not.
4512 </p>
4513 <p>
4514 Thus, a program that overrides one of the virtual functions so that
4515 it calls the other form which then calls the base member might end
4516 up in an infinite loop if the called form of the base implementation
4517 of the function in turn calls the other form.
4518 </p>
4519 <p>
4520 Lillehammer: Part of this isn't a real problem. We already talk about
4521 caching. 22.1.1/6 But part is a real problem. ctype virtuals may call
4522 each other, so users don't know which ones to override to avoid avoid
4523 infinite loops.</p>
4524
4525 <p>This is a problem for all facet virtuals, not just ctype virtuals,
4526 so we probably want a blanket statement in clause 22 for all
4527 facets. The LWG is leaning toward a blanket prohibition, that a
4528 facet's virtuals may never call each other. We might want to do that
4529 in clause 27 too, for that matter. A review is necessary.  Bill will
4530 provide wording.</p>
4531
4532
4533 <p><b>Proposed resolution:</b></p>
4534
4535
4536
4537
4538 <hr>
4539 <h3><a name="484"></a>484. Convertible to T</h3>
4540 <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>
4541  <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2004-09-16</p>
4542 <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>
4543 <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>
4544 <p><b>Discussion:</b></p>
4545 <p>From comp.std.c++:</p>
4546
4547 <p>
4548 I note that given an input iterator a for type T,
4549 then *a only has to be "convertable to T", not actually of type T.
4550 </p>
4551
4552 <p>Firstly, I can't seem to find an exact definition of "convertable to T".
4553 While I assume it is the obvious definition (an implicit conversion), I
4554 can't find an exact definition. Is there one?</p>
4555
4556 <p>Slightly more worryingly, there doesn't seem to be any restriction on
4557 the this type, other than it is "convertable to T". Consider two input
4558 iterators a and b. I would personally assume that most people would
4559 expect *a==*b would perform T(*a)==T(*b), however it doesn't seem that
4560 the standard requires that, and that whatever type *a is (call it U)
4561 could have == defined on it with totally different symantics and still
4562 be a valid inputer iterator.</p>
4563
4564 <p>Is this a correct reading? When using input iterators should I write
4565 T(*a) all over the place to be sure that the object i'm using is the
4566 class I expect?</p>
4567
4568 <p>This is especially a nuisance for operations that are defined to be
4569   "convertible to bool".  (This is probably allowed so that
4570   implementations could return say an int and avoid an unnessary
4571   conversion. However all implementations I have seen simply return a
4572   bool anyway.  Typical implemtations of STL algorithms just write
4573   things like <tt>while(a!=b &amp;&amp; *a!=0)</tt>.  But strictly
4574   speaking, there are lots of types that are convertible to T but
4575   that also overload the appropriate operators so this doesn't behave
4576   as expected.</p>
4577
4578 <p>If we want to make code like this legal (which most people seem to
4579   expect), then we'll need to tighten up what we mean by "convertible
4580   to T".</p>
4581
4582 <p><i>[Lillehammer: The first part is NAD, since "convertible" is
4583  well-defined in core. The second part is basically about pathological
4584  overloads. It's a minor problem but a real one. So leave open for
4585  now, hope we solve it as part of iterator redesign.]</i></p>
4586
4587
4588
4589 <p><b>Proposed resolution:</b></p>
4590
4591
4592
4593
4594
4595 <hr>
4596 <h3><a name="485"></a>485. output iterator insufficently constrained</h3>
4597 <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>
4598  <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2004-10-13</p>
4599 <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>
4600 <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>
4601 <p><b>Discussion:</b></p>
4602 <p>
4603 The note on 24.1.2 Output iterators insufficently limits what can be
4604 performed on output iterators. While it requires that each iterator is
4605 progressed through only once and that each iterator is written to only
4606 once, it does not require the following things:</p>
4607
4608 <p>Note: Here it is assumed that x is an output iterator of type X which
4609 has not yet been assigned to.</p>
4610
4611 <p>a) That each value of the output iterator is written to:
4612 The standard allows:
4613 ++x; ++x; ++x;
4614 </p>
4615
4616 <p>
4617 b) That assignments to the output iterator are made in order
4618 X a(x); ++a; *a=1; *x=2; is allowed
4619 </p>
4620
4621 <p>
4622 c) Chains of output iterators cannot be constructed:
4623 X a(x); ++a; X b(a); ++b; X c(b); ++c; is allowed, and under the current
4624 wording (I believe) x,a,b,c could be written to in any order.
4625 </p>
4626
4627 <p>I do not believe this was the intension of the standard?</p>
4628 <p><i>[Lillehammer: Real issue.  There are lots of constraints we
4629   intended but didn't specify.  Should be solved as part of iterator
4630   redesign.]</i></p>
4631
4632
4633
4634 <p><b>Proposed resolution:</b></p>
4635
4636
4637
4638
4639
4640 <hr>
4641 <h3><a name="492"></a>492. Invalid iterator arithmetic expressions</h3>
4642 <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>
4643  <b>Submitter:</b> Thomas Mang <b>Date:</b> 2004-12-12</p>
4644 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p>
4645 <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>
4646 <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>
4647 <p><b>Discussion:</b></p>
4648 <p>Various clauses other than clause 25 make use of iterator arithmetic not
4649 supported by the iterator category in question.
4650 Algorithms in clause 25 are exceptional because of 25 [lib.algorithms],
4651 paragraph 9, but this paragraph does not provide semantics to the
4652 expression "iterator - n", where n denotes a value of a distance type
4653 between iterators.</p>
4654
4655 <p>1) Examples of current wording:</p>
4656
4657 <p>Current wording outside clause 25:</p>
4658
4659 <p>
4660 23.2.2.4 [lib.list.ops], paragraphs 19-21: "first + 1", "(i - 1)",
4661 "(last - first)"
4662 23.3.1.1 [lib.map.cons], paragraph 4: "last - first"
4663 23.3.2.1 [lib.multimap.cons], paragraph 4: "last - first"
4664 23.3.3.1 [lib.set.cons], paragraph 4: "last - first"
4665 23.3.4.1 [lib.multiset.cons], paragraph 4: "last - first"
4666 24.4.1 [lib.reverse.iterators], paragraph 1: "(i - 1)"
4667 </p>
4668
4669 <p>
4670 [Important note: The list is not complete, just an illustration. The
4671 same issue might well apply to other paragraphs not listed here.]</p>
4672
4673 <p>None of these expressions is valid for the corresponding iterator
4674 category.</p>
4675
4676 <p>Current wording in clause 25:</p>
4677
4678 <p>
4679 25.1.1 [lib.alg.foreach], paragraph 1: "last - 1"
4680 25.1.3 [lib.alg.find.end], paragraph 2: "[first1, last1 -
4681 (last2-first2))"
4682 25.2.8 [lib.alg.unique], paragraph 1: "(i - 1)"
4683 25.2.8 [lib.alg.unique], paragraph 5: "(i - 1)"
4684 </p>
4685
4686 <p>
4687 However, current wording of 25 [lib.algorithms], paragraph 9 covers
4688 neither of these four cases:</p>
4689
4690 <p>Current wording of 25 [lib.algorithms], paragraph 9:</p>
4691
4692 <p>
4693 "In the description of the algorithms operator + and - are used for some
4694 of the iterator categories for which they do not have to be defined. In
4695 these cases the semantics of a+n is the same as that of</p>
4696 <pre>{X tmp = a;
4697 advance(tmp, n);
4698 return tmp;
4699 }
4700 </pre>
4701 <p>and that of b-a is the same as of return distance(a, b)"</p>
4702
4703 <p>
4704 This paragrpah does not take the expression "iterator - n" into account,
4705 where n denotes a value of a distance type between two iterators [Note:
4706 According to current wording, the expression "iterator - n" would be
4707 resolved as equivalent to "return distance(n, iterator)"]. Even if the
4708 expression "iterator - n" were to be reinterpreted as equivalent to
4709 "iterator + -n" [Note: This would imply that "a" and "b" were
4710 interpreted implicitly as values of iterator types, and "n" as value of
4711 a distance type], then 24.3.4/2 interfers because it says: "Requires: n
4712 may be negative only for random access and bidirectional iterators.",
4713 and none of the paragraphs quoted above requires the iterators on which
4714 the algorithms operate to be of random access or bidirectional category.
4715 </p>
4716
4717 <p>2) Description of intended behavior:</p>
4718
4719 <p>
4720 For the rest of this Defect Report, it is assumed that the expression
4721 "iterator1 + n" and "iterator1 - iterator2" has the semantics as
4722 described in current 25 [lib.algorithms], paragraph 9, but applying to
4723 all clauses. The expression "iterator1 - n" is equivalent to an
4724 result-iterator for which the expression "result-iterator + n" yields an
4725 iterator denoting the same position as iterator1 does. The terms
4726 "iterator1", "iterator2" and "result-iterator" shall denote the value of
4727 an iterator type, and the term "n" shall denote a value of a distance
4728 type between two iterators.</p>
4729
4730 <p>
4731 All implementations known to the author of this Defect Report comply
4732 with these assumptions.
4733 No impact on current code is expected.</p>
4734
4735 <p>3) Proposed fixes:</p>
4736
4737
4738 <p>Change 25 [lib.algorithms], paragraph 9 to:</p>
4739
4740 <p>
4741 "In the description of the algorithms operator + and - are used for some
4742 of the iterator categories for which they do not have to be defined. In
4743 this paragraph, a and b denote values of an iterator type, and n denotes
4744 a value of a distance type between two iterators. In these cases the
4745 semantics of a+n is the same as that of</p>
4746 <pre>{X tmp = a;
4747 advance(tmp, n);
4748 return tmp;
4749 }
4750 </pre>
4751 <p>,the semantics of a-n denotes the value of an iterator i for which the
4752 following condition holds:
4753 advance(i, n) == a,
4754 and that of b-a is the same as of
4755 return distance(a, b)".
4756 </p>
4757
4758 <p>Comments to the new wording:</p>
4759
4760 <p>
4761 a) The wording " In this paragraph, a and b denote values of an iterator
4762 type, and n denotes a value of a distance type between two iterators."
4763 was added so the expressions "b-a" and "a-n" are distinguished regarding
4764 the types of the values on which they operate.
4765 b) The wording ",the semantics of a-n denotes the value of an iterator i
4766 for which the following condition holds: advance(i, n) == a" was added
4767 to cover the expression 'iterator - n'. The wording "advance(i, n) == a"
4768 was used to avoid a dependency on the semantics of a+n, as the wording
4769 "i + n == a" would have implied. However, such a dependency might well
4770 be deserved.
4771 c) DR 225 is not considered in the new wording.
4772 </p>
4773
4774 <p>
4775 Proposed fixes regarding invalid iterator arithmetic expressions outside
4776 clause 25:</p>
4777
4778 <p>
4779 Either
4780 a) Move modified 25 [lib.algorithms], paragraph 9 (as proposed above)
4781 before any current invalid iterator arithmetic expression. In that case,
4782 the first sentence of 25 [lib.algorithms], paragraph 9, need also to be
4783 modified and could read: "For the rest of this International Standard,
4784 ...." / "In the description of the following clauses including this
4785 ...." / "In the description of the text below ..." etc. - anyways
4786 substituting the wording "algorithms", which is a straight reference to
4787 clause 25.
4788 In that case, 25 [lib.algorithms] paragraph 9 will certainly become
4789 obsolete.
4790 Alternatively,
4791 b) Add an appropiate paragraph similar to resolved 25 [lib.algorithms],
4792 paragraph 9, to the beginning of each clause containing invalid iterator
4793 arithmetic expressions.
4794 Alternatively,
4795 c) Fix each paragraph (both current wording and possible resolutions of
4796 DRs) containing invalid iterator arithmetic expressions separately.
4797 </p>
4798
4799 <p>5) References to other DRs:</p>
4800
4801 <p>
4802 See DR 225.
4803 See DR 237. The resolution could then also read "Linear in last -
4804 first".
4805 </p>
4806
4807 <p><i>[
4808 Bellevue:
4809 ]</i></p>
4810
4811
4812 <blockquote>
4813 Keep open and ask Bill to provide wording.
4814 </blockquote>
4815
4816
4817 <p><b>Proposed resolution:</b></p>
4818
4819 <p><i>[Lillehammer: Minor issue, but real. We have a blanket statement
4820 about this in 25/11. But (a) it should be in 17, not 25; and (b) it's
4821 not quite broad enough, because there are some arithmetic expressions
4822 it doesn't cover. Bill will provide wording.]</i></p>
4823
4824
4825
4826
4827
4828
4829
4830 <hr>
4831 <h3><a name="498"></a>498. Requirements for partition() and stable_partition() too strong</h3>
4832 <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>
4833  <b>Submitter:</b> Sean Parent, Joe Gottman <b>Date:</b> 2005-05-04</p>
4834 <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>
4835 <p><b>Discussion:</b></p>
4836 <p>
4837 Problem:
4838 The iterator requirements for partition() and stable_partition() [25.2.12]
4839 are listed as BidirectionalIterator, however, there are efficient algorithms
4840 for these functions that only require ForwardIterator that have been known
4841 since before the standard existed. The SGI implementation includes these (see
4842 <a href="http://www.sgi.com/tech/stl/partition.html">http://www.sgi.com/tech/stl/partition.html</a>
4843 and
4844 <a href="http://www.sgi.com/tech/stl/stable_partition.html">http://www.sgi.com/tech/stl/stable_partition.html</a>).
4845 </p>
4846
4847
4848 <p><b>Proposed resolution:</b></p>
4849 <p>
4850 Change 25.2.12 from </p>
4851 <blockquote><pre>template&lt;class BidirectionalIterator, class Predicate&gt;
4852 BidirectionalIterator partition(BidirectionalIterato r first,
4853                                 BidirectionalIterator last,
4854                                 Predicate pred);
4855 </pre></blockquote>
4856 <p>to </p>
4857 <blockquote><pre>template&lt;class ForwardIterator, class Predicate&gt;
4858 ForwardIterator partition(ForwardIterator first,
4859                           ForwardIterator last,
4860                           Predicate pred);
4861 </pre></blockquote>
4862 <p>Change the complexity from </p>
4863
4864 <blockquote><p>
4865 At most (last - first)/2 swaps are done. Exactly (last - first)
4866 applications of the predicate are done.
4867 </p></blockquote>
4868
4869 <p>to </p>
4870
4871 <blockquote><p>
4872 If ForwardIterator is a bidirectional_iterator, at most (last - first)/2
4873 swaps are done; otherwise at most (last - first) swaps are done. Exactly
4874 (last - first) applications of the predicate are done.
4875 </p></blockquote>
4876
4877
4878
4879 <p><b>Rationale:</b></p>
4880 <p>
4881 Partition is a "foundation" algorithm useful in many contexts (like sorting
4882 as just one example) - my motivation for extending it to include forward
4883 iterators is slist - without this extension you can't partition an slist
4884 (without writing your own partition). Holes like this in the standard
4885 library weaken the argument for generic programming (ideally I'd be able
4886 to provide a library that would refine std::partition() to other concepts
4887 without fear of conflicting with other libraries doing the same - but
4888 that is a digression). I consider the fact that partition isn't defined
4889 to work for ForwardIterator a minor embarrassment.
4890 </p>
4891
4892 <p><i>[Mont Tremblant: Moved to Open, request motivation and use cases
4893 by next meeting. Sean provided further rationale by post-meeting
4894 mailing.]</i></p>
4895
4896
4897
4898
4899
4900
4901
4902 <hr>
4903 <h3><a name="502"></a>502. Proposition: Clarification of the interaction between a facet and an iterator</h3>
4904 <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>
4905  <b>Submitter:</b> Christopher Conrade Zseleghovski <b>Date:</b> 2005-06-07</p>
4906 <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>
4907 <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>
4908 <p><b>Discussion:</b></p>
4909 <p>
4910 Motivation:
4911 </p>
4912
4913 <p>
4914 This requirement seems obvious to me, it is the essence of code modularity.
4915 I have complained to Mr. Plauger that the Dinkumware library does not
4916 observe this principle but he objected that this behaviour is not covered in
4917 the standard.
4918 </p>
4919
4920
4921 <p><b>Proposed resolution:</b></p>
4922 <p>
4923 Append the following point to 22.1.1.1.1:
4924 </p>
4925
4926 <p>
4927 6. The implementation of a facet of Table 52 parametrized with an
4928 InputIterator/OutputIterator should use that iterator only as character
4929 source/sink respectively.
4930 For a *_get facet, it means that the value received depends only on the
4931 sequence of input characters and not on how they are accessed.
4932 For a *_put facet, it means that the sequence of characters output depends
4933 only on the value to be formatted and not of how the characters are stored.
4934 </p>
4935
4936 <p><i>[
4937 Berlin:  Moved to Open, Need to clean up this area to make it clear
4938 locales don't have to contain open ended sets of facets. Jack, Howard,
4939 Bill.
4940 ]</i></p>
4941
4942
4943
4944
4945
4946
4947
4948 <hr>
4949 <h3><a name="503"></a>503. more on locales</h3>
4950 <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>
4951  <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2005-06-20</p>
4952 <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>
4953 <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>
4954 <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>
4955 <p><b>Discussion:</b></p>
4956 <p>
4957 a) In 22.2.1.1 para. 2 we refer to "the instantiations required in Table
4958 51" to refer to the facet *objects* associated with a locale. And we
4959 almost certainly mean just those associated with the default or "C"
4960 locale. Otherwise, you can't switch to a locale that enforces a different
4961 mapping between narrow and wide characters, or that defines additional
4962 uppercase characters.
4963 </p>
4964
4965 <p>
4966 b) 22.2.1.5 para. 3 (codecvt) has the same issues.
4967 </p>
4968
4969 <p>
4970 c) 22.2.1.5.2 (do_unshift) is even worse. It *forbids* the generation of
4971 a homing sequence for the basic character set, which might very well need
4972 one.
4973 </p>
4974
4975 <p>
4976 d) 22.2.1.5.2 (do_length) likewise dictates that the default mapping
4977 between wide and narrow characters be taken as one-for-one.
4978 </p>
4979
4980 <p>
4981 e) 22.2.2 para. 2 (num_get/put) is both muddled and vacuous, as far as
4982 I can tell. The muddle is, as before, calling Table 51 a list of
4983 instantiations. But the constraint it applies seems to me to cover
4984 *all* defined uses of num_get/put, so why bother to say so?
4985 </p>
4986
4987 <p>
4988 f) 22.2.3.1.2 para. 1(do_decimal_point) says "The required instantiations
4989 return '.' or L'.'.) Presumably this means "as appropriate for the
4990 character type. But given the vague definition of "required" earlier,
4991 this overrules *any* change of decimal point for non "C" locales.
4992 Surely we don't want to do that.
4993 </p>
4994
4995 <p>
4996 g) 22.2.3.1.2 para. 2 (do_thousands_sep) says "The required instantiations
4997 return ',' or L','.) As above, this probably means "as appropriate for the
4998 character type. But this overrules the "C" locale, which requires *no*
4999 character ('\0') for the thousands separator. Even if we agree that we
5000 don't mean to block changes in decimal point or thousands separator,
5001 we should also eliminate this clear incompatibility with C.
5002 </p>
5003
5004 <p>
5005 h) 22.2.3.1.2 para. 2 (do_grouping) says "The required instantiations
5006 return the empty string, indicating no grouping." Same considerations
5007 as for do_decimal_point.
5008 </p>
5009
5010 <p>
5011 i) 22.2.4.1 para. 1 (collate) refers to "instantiations required in Table
5012 51". Same bad jargon.
5013 </p>
5014
5015 <p>
5016 j) 22.2.4.1.2 para. 1 (do_compare) refers to "instantiations required
5017 in Table 51". Same bad jargon.
5018 </p>
5019
5020 <p>
5021 k) 22.2.5 para. 1 (time_get/put) uses the same muddled and vacuous
5022 as num_get/put.
5023 </p>
5024
5025 <p>
5026 l) 22.2.6 para. 2 (money_get/put) uses the same muddled and vacuous
5027 as num_get/put.
5028 </p>
5029
5030 <p>
5031 m) 22.2.6.3.2 (do_pos/neg_format) says "The instantiations required
5032 in Table 51 ... return an object of type pattern initialized to
5033 {symbol, sign, none, value}." This once again *overrides* the "C"
5034 locale, as well as any other locale."
5035 </p>
5036
5037 <p>
5038 3) We constrain the use_facet calls that can be made by num_get/put,
5039 so why don't we do the same for money_get/put? Or for any of the
5040 other facets, for that matter?
5041 </p>
5042
5043 <p>
5044 4) As an almost aside, we spell out when a facet needs to use the ctype
5045 facet, but several also need to use a codecvt facet and we don't say so.
5046 </p>
5047 <p><i>[
5048 Berlin: Bill to provide wording.
5049 ]</i></p>
5050
5051
5052
5053 <p><b>Proposed resolution:</b></p>
5054 <p>
5055 </p>
5056
5057
5058
5059
5060
5061 <hr>
5062 <h3><a name="518"></a>518. Are insert and erase stable for unordered_multiset and unordered_multimap?</h3>
5063 <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#Ready">Ready</a>
5064  <b>Submitter:</b> Matt Austern <b>Date:</b> 2005-07-03</p>
5065 <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>
5066 <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>
5067 <p><b>Discussion:</b></p>
5068 <p>
5069 Issue 371 deals with stability of multiset/multimap under insert and erase
5070 (i.e. do they preserve the relative order in ranges of equal elements).
5071 The same issue applies to unordered_multiset and unordered_multimap.
5072 </p>
5073 <p><i>[
5074 Moved to open (from review):  There is no resolution.
5075 ]</i></p>
5076
5077
5078 <p><i>[
5079 Toronto:  We have a resolution now.  Moved to Review.  Some concern was noted
5080 as to whether this conflicted with existing practice or not.  An additional
5081 concern was in specifying (partial) ordering for an unordered container.
5082 ]</i></p>
5083
5084
5085
5086
5087 <p><b>Proposed resolution:</b></p>
5088 <p>
5089 Wording for the proposed resolution is taken from the equivalent text for associative containers.
5090 </p>
5091
5092 <p>
5093 Change 23.1.3 [unord.req], Unordered associative containers, paragraph 6 to:
5094 </p>
5095
5096 <blockquote><p>
5097 An unordered associative container supports <i>unique</i> keys if it may
5098 contain at most one element for each key. Otherwise, it supports <i>equivalent
5099 keys</i>. <tt>unordered_set</tt> and <tt>unordered_map</tt> support
5100 unique keys. <tt>unordered_multiset</tt> and <tt>unordered_multimap</tt>
5101 support equivalent keys. In containers that support equivalent keys, elements
5102 with equivalent keys are adjacent to each other. <ins>For
5103 <tt>unordered_multiset</tt>
5104 and <tt>unordered_multimap</tt>,<tt> insert</tt> and <tt>erase</tt>
5105 preserve the relative ordering of equivalent elements.</ins>
5106 </p></blockquote>
5107
5108 <p>
5109 Change 23.1.3 [unord.req], Unordered associative containers, paragraph 8 to:
5110 </p>
5111
5112 <blockquote>
5113 <p>The elements of an unordered associative container are organized into <i>
5114 buckets</i>. Keys with the same hash code appear in the same bucket. The number
5115 of buckets is automatically increased as elements are added to an unordered
5116 associative container, so that the average number of elements per bucket is kept
5117 below a bound. Rehashing invalidates iterators, changes ordering between
5118 elements, and changes which buckets elements appear in, but does not invalidate
5119 pointers or references to elements. <ins>For <tt>unordered_multiset</tt>
5120 and <tt>unordered_multimap</tt>, rehashing
5121 preserves the relative ordering of equivalent elements.</ins></p>
5122 </blockquote>
5123
5124
5125
5126
5127
5128
5129 <hr>
5130 <h3><a name="522"></a>522. Tuple doesn't define swap</h3>
5131 <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>
5132  <b>Submitter:</b> Andy Koenig <b>Date:</b> 2005-07-03</p>
5133 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple">active issues</a> in [tuple].</p>
5134 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple">issues</a> in [tuple].</p>
5135 <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>
5136 <p><b>Discussion:</b></p>
5137 <p>
5138 Tuple doesn't define swap().  It should.
5139 </p>
5140 <p><i>[
5141 Berlin: Doug to provide wording.
5142 ]</i></p>
5143
5144 <p><i>[
5145 Batavia: Howard to provide wording.
5146 ]</i></p>
5147
5148 <p><i>[
5149 Toronto: Howard to provide wording (really this time).
5150 ]</i></p>
5151
5152
5153 <p><i>[
5154 Bellevue:  Alisdair provided wording.
5155 ]</i></p>
5156
5157
5158
5159
5160 <p><b>Proposed resolution:</b></p>
5161
5162 <p>
5163 Add these signatures to 20.3 [tuple]
5164 </p>
5165
5166 <blockquote><pre>template &lt;class... Types&gt;
5167   void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp; y);
5168 template &lt;class... Types&gt;
5169   void swap(tuple&lt;Types...&gt;&amp;&amp; x, tuple&lt;Types...&gt;&amp; y);
5170 template &lt;class... Types&gt;
5171   void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp;&amp; y);
5172 </pre></blockquote>
5173
5174 <p>
5175 Add this signature to 20.3.1 [tuple.tuple]
5176 </p>
5177
5178 <blockquote><pre>void swap(tuple&amp;&amp;);
5179 </pre></blockquote>
5180
5181 <p>
5182 Add the following two sections to the end of the tuple clauses
5183 </p>
5184
5185 <blockquote>
5186 <p>
5187 20.3.1.7 tuple swap [tuple.swap]
5188 </p>
5189
5190 <pre>void swap(tuple&amp;&amp; rhs);
5191 </pre>
5192
5193 <blockquote>
5194 <p>
5195 <i>Requires:</i> Each type in <tt>Types</tt> shall be <tt>Swappable</tt>.
5196 </p>
5197 <p>
5198 <i>Effects:</i> Calls <tt>swap</tt> for each element in <tt>*this</tt> and its corresponding element
5199 in <tt>rhs</tt>.
5200 </p>
5201 <p>
5202 <i>Throws:</i> Nothing, unless one of the element-wise <tt>swap</tt> calls throw an
5203 exception.
5204 </p>
5205 </blockquote>
5206
5207 <p>
5208 20.3.1.8 tuple specialized algorithms [tuple.special]
5209 </p>
5210
5211 <pre>template &lt;class... Types&gt;
5212   void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp; y);
5213 template &lt;class... Types&gt;
5214   void swap(tuple&lt;Types...&gt;&amp;&amp; x, tuple&lt;Types...&gt;&amp; y);
5215 template &lt;class... Types&gt;
5216   void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp;&amp; y);
5217 </pre>
5218
5219 <blockquote>
5220 <p>
5221 <i>Effects:</i> x.swap(y)
5222 </p>
5223 </blockquote>
5224 </blockquote>
5225
5226
5227
5228
5229
5230
5231 <hr>
5232 <h3><a name="523"></a>523. regex case-insensitive character ranges are unimplementable as specified</h3>
5233 <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>
5234  <b>Submitter:</b> Eric Niebler <b>Date:</b> 2005-07-01</p>
5235 <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>
5236 <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>
5237 <p><b>Discussion:</b></p>
5238 <p>
5239 A problem with TR1 regex is currently being discussed on the Boost
5240 developers list. It involves the handling of case-insensitive matching
5241 of character ranges such as [Z-a]. The proper behavior (according to the
5242 ECMAScript standard) is unimplementable given the current specification
5243 of the TR1 regex_traits&lt;&gt; class template. John Maddock, the author of
5244 the TR1 regex proposal, agrees there is a problem. The full discussion
5245 can be found at http://lists.boost.org/boost/2005/06/28850.php (first
5246 message copied below). We don't have any recommendations as yet.
5247 </p>
5248 <p>
5249 -- Begin original message --
5250 </p>
5251 <p>
5252 The situation of interest is described in the ECMAScript specification
5253 (ECMA-262), section 15.10.2.15:
5254 </p>
5255 <p>
5256 "Even if the pattern ignores case, the case of the two ends of a range
5257 is significant in determining which characters belong to the range.
5258 Thus, for example, the pattern /[E-F]/i matches only the letters E, F,
5259 e, and f, while the pattern /[E-f]/i matches all upper and lower-case
5260 ASCII letters as well as the symbols [, \, ], ^, _, and `."
5261 </p>
5262 <p>
5263 A more interesting case is what should happen when doing a
5264 case-insentitive match on a range such as [Z-a]. It should match z, Z,
5265 a, A and the symbols [, \, ], ^, _, and `. This is not what happens with
5266 Boost.Regex (it throws an exception from the regex constructor).
5267 </p>
5268 <p>
5269 The tough pill to swallow is that, given the specification in TR1, I
5270 don't think there is any effective way to handle this situation.
5271 According to the spec, case-insensitivity is handled with
5272 regex_traits&lt;&gt;::translate_nocase(CharT) -- two characters are equivalent
5273 if they compare equal after both are sent through the translate_nocase
5274 function. But I don't see any way of using this translation function to
5275 make character ranges case-insensitive. Consider the difficulty of
5276 detecting whether "z" is in the range [Z-a]. Applying the transformation
5277 to "z" has no effect (it is essentially std::tolower). And we're not
5278 allowed to apply the transformation to the ends of the range, because as
5279 ECMA-262 says, "the case of the two ends of a range is significant."
5280 </p>
5281 <p>
5282 So AFAICT, TR1 regex is just broken, as is Boost.Regex. One possible fix
5283 is to redefine translate_nocase to return a string_type containing all
5284 the characters that should compare equal to the specified character. But
5285 this function is hard to implement for Unicode, and it doesn't play nice
5286 with the existing ctype facet. What a mess!
5287 </p>
5288 <p>
5289 -- End original message --
5290 </p>
5291
5292 <p><i>[
5293 John Maddock adds:
5294 ]</i></p>
5295
5296
5297 <p>
5298 One small correction, I have since found that ICU's regex package does
5299 implement this correctly, using a similar mechanism to the current
5300 TR1.Regex.
5301 </p>
5302 <p>
5303 Given an expression [c1-c2] that is compiled as case insensitive it:
5304 </p>
5305 <p>
5306 Enumerates every character in the range c1 to c2 and converts it to it's
5307 case folded equivalent.  That case folded character is then used a key to a
5308 table of equivalence classes, and each member of the class is added to the
5309 list of possible matches supported by the character-class.  This second step
5310 isn't possible with our current traits class design, but isn't necessary if
5311 the input text is also converted to a case-folded equivalent on the fly.
5312 </p>
5313 <p>
5314 ICU applies similar brute force mechanisms to character classes such as
5315 [[:lower:]] and [[:word:]], however these are at least cached, so the impact
5316 is less noticeable in this case.
5317 </p>
5318 <p>
5319 Quick and dirty performance comparisons show that expressions such as
5320 "[X-\\x{fff0}]+" are indeed very slow to compile with ICU (about 200 times
5321 slower than a "normal" expression).  For an application that uses a lot of
5322 regexes this could have a noticeable performance impact.  ICU also has an
5323 advantage in that it knows the range of valid characters codes: code points
5324 outside that range are assumed not to require enumeration, as they can not
5325 be part of any equivalence class.  I presume that if we want the TR1.Regex
5326 to work with arbitrarily large character sets enumeration really does become
5327 impractical.
5328 </p>
5329 <p>
5330 Finally note that Unicode has:
5331 </p>
5332 <p>
5333 Three cases (upper, lower and title).
5334 One to many, and many to one case transformations.
5335 Character that have context sensitive case translations - for example an
5336 uppercase sigma has two different lowercase forms  - the form chosen depends
5337 on context(is it end of a word or not), a caseless match for an upper case
5338 sigma should match either of the lower case forms, which is why case folding
5339 is often approximated by tolower(toupper(c)).
5340 </p>
5341 <p>
5342 Probably we need some way to enumerate character equivalence classes,
5343 including digraphs (either as a result or an input), and some way to tell
5344 whether the next character pair is a valid digraph in the current locale.
5345 </p>
5346 <p>
5347 Hoping this doesn't make this even more complex that it was already,
5348 </p>
5349
5350 <p><i>[
5351 Portland:  Alisdair: Detect as invalid, throw an exception.
5352 Pete: Possible general problem with case insensitive ranges.
5353 ]</i></p>
5354
5355
5356
5357
5358 <p><b>Proposed resolution:</b></p>
5359
5360
5361
5362
5363
5364 <hr>
5365 <h3><a name="539"></a>539. partial_sum and adjacent_difference should mention requirements</h3>
5366 <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#Review">Review</a>
5367  <b>Submitter:</b> Marc Schoolderman <b>Date:</b> 2006-02-06</p>
5368 <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>
5369 <p><b>Discussion:</b></p>
5370 <p>
5371 There are some problems in the definition of partial_sum and
5372 adjacent_difference in 26.4 [lib.numeric.ops]
5373 </p>
5374
5375 <p>
5376 Unlike <tt>accumulate</tt> and <tt>inner_product</tt>, these functions are not
5377 parametrized on a "type T", instead, 26.4.3 [lib.partial.sum] simply
5378 specifies the effects clause as;
5379 </p>
5380
5381 <blockquote><p>
5382 Assigns to every element referred to by iterator <tt>i</tt> in the range
5383 <tt>[result,result + (last - first))</tt> a value correspondingly equal to
5384 </p>
5385 <blockquote><pre>((...(* first + *( first + 1)) + ...) + *( first + ( i - result )))
5386 </pre></blockquote>
5387 </blockquote>
5388
5389 <p>
5390 And similarly for BinaryOperation. Using just this definition, it seems
5391 logical to expect that:
5392 </p>
5393
5394
5395 <blockquote><pre>char i_array[4] = { 100, 100, 100, 100 };
5396 int  o_array[4];
5397
5398 std::partial_sum(i_array, i_array+4, o_array);
5399 </pre></blockquote>
5400
5401 <p>
5402 Is equivalent to
5403 </p>
5404
5405 <blockquote><pre>int o_array[4] = { 100, 100+100, 100+100+100, 100+100+100+100 };
5406 </pre></blockquote>
5407
5408 <p>
5409 i.e. 100, 200, 300, 400, with addition happening in the <tt>result type</tt>,
5410 <tt>int</tt>.
5411 </p>
5412
5413 <p>
5414 Yet all implementations I have tested produce 100, -56, 44, -112,
5415 because they are using an accumulator of the <tt>InputIterator</tt>'s
5416 <tt>value_type</tt>, which in this case is <tt>char</tt>, not <tt>int</tt>.
5417 </p>
5418
5419 <p>
5420 The issue becomes more noticeable when the result of the expression <tt>*i +
5421 *(i+1)</tt> or <tt>binary_op(*i, *i-1)</tt> can't be converted to the
5422 <tt>value_type</tt>. In a contrived example:
5423 </p>
5424
5425 <blockquote><pre>enum not_int { x = 1, y = 2 };
5426 ...
5427 not_int e_array[4] = { x, x, y, y };
5428 std::partial_sum(e_array, e_array+4, o_array);
5429 </pre></blockquote>
5430
5431 <p>
5432 Is it the intent that the operations happen in the <tt>input type</tt>, or in
5433 the <tt>result type</tt>?
5434 </p>
5435
5436 <p>
5437 If the intent is that operations happen in the <tt>result type</tt>, something
5438 like this should be added to the "Requires" clause of 26.4.3/4
5439 [lib.partial.sum]:
5440 </p>
5441
5442 <blockquote><p>
5443 The type of <tt>*i + *(i+1)</tt> or <tt>binary_op(*i, *(i+1))</tt> shall meet the
5444 requirements of <tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt>
5445 (23.1) types.
5446 </p></blockquote>
5447
5448 <p>
5449 (As also required for <tt>T</tt> in 26.4.1 [lib.accumulate] and 26.4.2
5450 [lib.inner.product].)
5451 </p>
5452
5453 <p>
5454 The "auto initializer" feature proposed in
5455 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1894.pdf">N1894</a>
5456 is not required to
5457 implement <tt>partial_sum</tt> this way. The 'narrowing' behaviour can still be
5458 obtained by using the <tt>std::plus&lt;&gt;</tt> function object.
5459 </p>
5460
5461 <p>
5462 If the intent is that operations happen in the <tt>input type</tt>, then
5463 something like this should be added instead;
5464 </p>
5465
5466 <blockquote><p>
5467 The type of *first shall meet the requirements of
5468 <tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt> (23.1) types.
5469 The result of <tt>*i + *(i+1)</tt> or <tt>binary_op(*i, *(i+1))</tt> shall be
5470 convertible to this type.
5471 </p></blockquote>
5472
5473 <p>
5474 The 'widening' behaviour can then be obtained by writing a custom proxy
5475 iterator, which is somewhat involved.
5476 </p>
5477
5478 <p>
5479 In both cases, the semantics should probably be clarified.
5480 </p>
5481
5482 <p>
5483 26.4.4 [lib.adjacent.difference] is similarly underspecified, although
5484 all implementations seem to perform operations in the 'result' type:
5485 </p>
5486
5487 <blockquote><pre>unsigned char i_array[4] = { 4, 3, 2, 1 };
5488 int o_array[4];
5489
5490 std::adjacent_difference(i_array, i_array+4, o_array);
5491 </pre></blockquote>
5492
5493 <p>
5494 o_array is 4, -1, -1, -1 as expected, not 4, 255, 255, 255.
5495 </p>
5496
5497 <p>
5498 In any case, <tt>adjacent_difference</tt> doesn't mention the requirements on the
5499 <tt>value_type</tt>; it can be brought in line with the rest of 26.4
5500 [lib.numeric.ops] by adding the following to 26.4.4/2
5501 [lib.adjacent.difference]:
5502 </p>
5503
5504 <blockquote><p>
5505 The type of <tt>*first</tt> shall meet the requirements of
5506 <tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt> (23.1) types."
5507 </p></blockquote>
5508 <p><i>[
5509 Berlin: Giving output iterator's value_types very controversial. Suggestion of
5510 adding signatures to allow user to specify "accumulator".
5511 ]</i></p>
5512
5513
5514 <p><i>[
5515 Bellevue:
5516 ]</i></p>
5517
5518
5519 <blockquote>
5520 The intent of the algorithms is to perform their calculations using the type of the input iterator.
5521 Proposed wording provided.
5522 </blockquote>
5523
5524
5525 <p><b>Proposed resolution:</b></p>
5526 <p>
5527 Add to section 26.6.3 [partial.sum] paragraph 4 the following two sentences:
5528 </p>
5529
5530 <blockquote>
5531 The type of <tt>*first</tt> shall meet the requirements of <tt>CopyConstructible</tt>?
5532 (20.1.3?) and <tt>Assignable</tt> (23.1?) types. The result of <tt>*i + *(i+1)</tt> or
5533 <tt>binary_op(*i, *(i+1))</tt> shall be convertible to this type.
5534 </blockquote>
5535
5536 <p>
5537 Add to section 26.6.4 [adjacent.difference] paragraph 2 the following sentence:
5538 </p>
5539
5540 <blockquote>
5541 The type of <tt>*first</tt> shall meet the requirements of <tt>CopyConstructible</tt>?
5542 (20.1.3) and <tt>Assignable</tt> (23.1) types.
5543 </blockquote>
5544
5545
5546
5547
5548
5549
5550 <hr>
5551 <h3><a name="546"></a>546. _Longlong and _ULonglong are integer types</h3>
5552 <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>
5553  <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p>
5554 <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>
5555 <p><b>Discussion:</b></p>
5556 <p>
5557 The TR sneaks in two new integer types, _Longlong and _Ulonglong, in [tr.c99].
5558 The rest of the TR should use that type.  I believe this affects two places.
5559 First, the random number requirements, 5.1.1/10-11, lists all of the types with
5560 which template parameters named IntType and UIntType may be instantiated.
5561 _Longlong (or "long long", assuming it is added to C++0x) should be added to the
5562 IntType list, and UIntType (again, or "unsigned long long") should be added to
5563 the UIntType list.  Second, 6.3.2 lists the types for which hash&lt;&gt; is
5564 required to be instantiable. _Longlong and _Ulonglong should be added to that
5565 list, so that people may use long long as a hash key.
5566 </p>
5567
5568
5569 <p><b>Proposed resolution:</b></p>
5570 <p>
5571 </p>
5572
5573
5574
5575
5576
5577 <hr>
5578 <h3><a name="550"></a>550. What should the return type of pow(float,int) be?</h3>
5579 <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#Ready">Ready</a>
5580  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-01-12</p>
5581 <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>
5582 <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>
5583 <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>
5584 <p><b>Discussion:</b></p>
5585 <p>
5586 Assuming we adopt the
5587 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">C
5588 compatibility package from C99</a>  what should be the return type of the
5589 following signature be:
5590 </p>
5591 <blockquote><pre>?  pow(float, int);
5592 </pre></blockquote>
5593 <p>
5594 C++03 says that the return type should be <tt>float</tt>.
5595 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">
5596 TR1</a> and C90/99 say the return type should be <tt>double</tt>.  This can put
5597 clients into a situation where C++03 provides answers that are not as high
5598 quality as C90/C99/TR1.  For example:
5599 </p>
5600 <blockquote><pre>#include &lt;math.h&gt;
5601
5602 int main()
5603 {
5604     float x = 2080703.375F;
5605     double y = pow(x, 2);
5606 }
5607 </pre></blockquote>
5608 <p>
5609 Assuming an IEEE 32 bit float and IEEE 64 bit double, C90/C99/TR1 all suggest:
5610 </p>
5611
5612 <blockquote><pre>y = 4329326534736.390625
5613 </pre></blockquote>
5614
5615 <p>
5616 which is exactly right.  While C++98/C++03 demands:
5617 </p>
5618
5619 <blockquote><pre>y = 4329326510080.
5620 </pre></blockquote>
5621
5622 <p>
5623 which is only approximately right.
5624 </p>
5625
5626 <p>
5627 I recommend that C++0X adopt the mixed mode arithmetic already adopted by
5628 Fortran, C and TR1 and make the return type of <tt>pow(float,int)</tt> be
5629 <tt>double</tt>.
5630 </p>
5631
5632 <p><i>[
5633 Kona (2007): Other functions that are affected by this issue include
5634 <tt>ldexp</tt>, <tt>scalbln</tt>, and <tt>scalbn</tt>. We also believe that there is a typo in
5635 26.7/10: <tt>float nexttoward(float, long double);</tt> [sic] should be <tt>float
5636 nexttoward(float, float);</tt> Proposed Disposition: Review (the proposed
5637 resolution appears above, rather than below, the heading "Proposed
5638 resolution")
5639 ]</i></p>
5640
5641
5642 <p><i>[
5643 <p>
5644 Howard, post Kona:
5645 </p>
5646 <blockquote>
5647 <p>
5648 Unfortunately I strongly disagree with a part of the resolution
5649 from Kona.  I am moving from New to Open instead of to Review because I do not believe
5650 we have consensus on the intent of the resolution.
5651 </p>
5652 <p>
5653 This issue does not include <tt>ldexp</tt>, <tt>scalbln</tt>, and <tt>scalbn</tt> because
5654 the second integral parameter in each of these signatures (from C99) is <b>not</b> a
5655 <i>generic parameter</i> according to C99 7.22p2.  The corresponding C++ overloads are
5656 intended (as far as I know) to correspond directly to C99's definition of <i>generic parameter</i>.
5657 </p>
5658 <p>
5659 For similar reasons, I do not believe that the second <tt>long double</tt> parameter of
5660 <tt>nexttoward</tt>, nor the return type of this function, is in error.  I believe the
5661 correct signature is:
5662 </p>
5663 <blockquote>
5664 <pre>float nexttoward(float, long double);
5665 </pre>
5666 </blockquote>
5667 <p>
5668 which is what both the C++0X working paper and C99 state (as far as I currently understand).
5669 </p>
5670 <p>
5671 This is really <b>only</b> about <tt>pow(float, int)</tt>.  And this is because C++98 took one
5672 route (with <tt>pow</tt> only) and C99 took another (with many math functions in <tt>&lt;tgmath.h&gt;</tt>.
5673 The proposed resolution basically says: C++98 got it wrong and C99 got it right; let's go with C99.
5674 </p>
5675 </blockquote>
5676 ]</i></p>
5677
5678
5679 <p><i>[
5680 Bellevue:
5681 ]</i></p>
5682
5683
5684 <blockquote>
5685 This signature was not picked up from C99. Instead, if one types
5686 pow(2.0f,2), the promotion rules will invoke "double pow(double,
5687 double)", which generally gives special treatment for integral
5688 exponents, preserving full accuracy of the result.  New proposed
5689 wording provided.
5690 </blockquote>
5691
5692
5693 <p><b>Proposed resolution:</b></p>
5694 <p>
5695 Change 26.7 [c.math] p10:
5696 </p>
5697
5698 <blockquote>
5699 <p>
5700 The added signatures are:
5701 </p>
5702 <blockquote><pre>...
5703 <del>float pow(float, int);</del>
5704 ...
5705 <del>double pow(double, int);</del>
5706 ...
5707 <del>long double pow(long double, int);</del>
5708 </pre></blockquote>
5709 </blockquote>
5710
5711
5712
5713
5714
5715
5716 <hr>
5717 <h3><a name="556"></a>556. is Compare a BinaryPredicate?</h3>
5718 <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>
5719  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-05</p>
5720 <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>
5721 <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>
5722 <p><b>Discussion:</b></p>
5723 <p>
5724 In 25, p8 we allow BinaryPredicates to return a type that's convertible
5725 to bool but need not actually be bool. That allows predicates to return
5726 things like proxies and requires that implementations be careful about
5727 what kinds of expressions they use the result of the predicate in (e.g.,
5728 the expression in if (!pred(a, b)) need not be well-formed since the
5729 negation operator may be inaccessible or return a type that's not
5730 convertible to bool).
5731 </p>
5732 <p>
5733 Here's the text for reference:
5734 </p>
5735 <blockquote><p>
5736   ...if an algorithm takes BinaryPredicate binary_pred as its argument
5737  and first1 and first2 as its iterator arguments, it should work
5738  correctly in the construct if (binary_pred(*first1, first2)){...}.
5739 </p></blockquote>
5740
5741 <p>
5742 In 25.3, p2 we require that the Compare function object return true
5743 of false, which would seem to preclude such proxies. The relevant text
5744 is here:
5745 </p>
5746 <blockquote><p>
5747   Compare is used as a function object which returns true if the first
5748   argument is less than the second, and false otherwise...
5749 </p></blockquote>
5750
5751
5752 <p><b>Proposed resolution:</b></p>
5753 <p>
5754 I think we could fix this by rewording 25.3, p2 to read somthing like:
5755 </p>
5756 <blockquote><p>
5757 -2- <tt>Compare</tt> is <del>used as a function object which returns
5758 <tt>true</tt> if the first argument</del> <ins>a <tt>BinaryPredicate</tt>. The
5759 return value of the function call operator applied to an object of type
5760 <tt>Compare</tt>, when converted to type <tt>bool</tt>, yields <tt>true</tt>
5761 if the first argument of the call</ins> is less than the second, and
5762 <tt>false</tt> otherwise. <tt>Compare <i>comp</i></tt> is used throughout for
5763 algorithms assuming an ordering relation. It is assumed that <tt><i>comp</i></tt>
5764 will not apply any non-constant function through the dereferenced iterator.
5765 </p></blockquote>
5766
5767
5768 <p><i>[
5769 Portland:  Jack to define "convertible to bool" such that short circuiting isn't
5770 destroyed.
5771 ]</i></p>
5772
5773
5774
5775
5776
5777 <hr>
5778 <h3><a name="564"></a>564. stringbuf seekpos underspecified</h3>
5779 <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>
5780  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
5781 <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>
5782 <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>
5783 <p><b>Discussion:</b></p>
5784 <p>
5785 The   effects  of  the   <code>seekpos()</code>  member   function  of
5786 <code>basic_stringbuf</code>  simply say  that the  function positions
5787 the  input and/or  output  sequences  but fail  to  spell out  exactly
5788 how. This is in contrast  to the detail in which <code>seekoff()</code>
5789 is described.
5790 </p>
5791
5792
5793 <p><b>Proposed resolution:</b></p>
5794         <p>
5795
5796 Change 27.7.1.3, p13 to read:
5797
5798         </p>
5799 <blockquote>
5800 <p>
5801 -13- <i>Effects:</i> <ins>Same as <tt>seekoff(off_type(<i>sp</i>), ios_base::beg,
5802 <i>which</i>)</tt>.</ins> <del>Alters the stream position within the controlled sequences,
5803 if possible, to correspond to the stream position stored in <tt><i>sp</i></tt>
5804 (as described below).</del>
5805 </p>
5806 <ul>
5807 <li><del>If <tt>(<i>which</i> &amp; ios_base::in) != 0</tt>, positions the input sequence.</del></li>
5808 <li><del>If <tt>(<i>which</i> &amp; ios_base::out) != 0</tt>, positions the output sequence.</del></li>
5809 <li><del>If <tt><i>sp</i></tt> is an invalid stream position, or if the function
5810 positions neither sequence, the positioning operation fails. If <tt><i>sp</i></tt>
5811 has not been obtained by a previous successful call to one of the positioning
5812 functions (<tt>seekoff</tt>, <tt>seekpos</tt>, <tt>tellg</tt>, <tt>tellp</tt>)
5813 the effect is undefined.</del></li>
5814 </ul>
5815 </blockquote>
5816
5817
5818 <p><i>[
5819 Kona (2007): A <tt>pos_type</tt> is a position in a stream by
5820 definition, so there is no ambiguity as to what it means. Proposed
5821 Disposition: NAD
5822 ]</i></p>
5823
5824
5825 <p><i>[
5826 Post-Kona Martin adds:
5827 I'm afraid I disagree
5828 with the Kona '07 rationale for marking it NAD. The only text
5829 that describes precisely what it means to position the input
5830 or output sequence is in <tt>seekoff()</tt>. The <tt>seekpos()</tt> Effects
5831 clause is inadequate in comparison and the proposed resolution
5832 plugs the hole by specifying <tt>seekpos()</tt> in terms of <tt>seekoff()</tt>.
5833 ]</i></p>
5834
5835
5836
5837
5838
5839 <hr>
5840 <h3><a name="565"></a>565. xsputn inefficient</h3>
5841 <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>
5842  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
5843 <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>
5844 <p><b>Discussion:</b></p>
5845         <p>
5846
5847 <tt>streambuf::xsputn()</tt>  is  specified  to  have  the  effect  of
5848 "writing up to  <tt>n</tt> characters to the output  sequence as if by
5849 repeated calls to <tt>sputc(c)</tt>."
5850
5851         </p>
5852         <p>
5853
5854 Since  <tt>sputc()</tt> is required  to call  <tt>overflow()</tt> when
5855 <tt>(pptr()    ==   epptr())</tt>    is   true,    strictly   speaking
5856 <tt>xsputn()</tt>  should do  the same.   However, doing  so  would be
5857 suboptimal in  some interesting cases,  such as in unbuffered  mode or
5858 when the buffer is <tt>basic_stringbuf</tt>.
5859
5860         </p>
5861         <p>
5862
5863 Assuming  calling <tt>overflow()</tt>  is  not really  intended to  be
5864 required  and the  wording is  simply  meant to  describe the  general
5865 effect of appending to the end  of the sequence it would be worthwhile
5866 to  mention in  <tt>xsputn()</tt> that  the function  is  not actually
5867 required to cause a call to <tt>overflow()</tt>.
5868
5869         </p>
5870
5871
5872 <p><b>Proposed resolution:</b></p>
5873         <p>
5874
5875 Add the following sentence  to the <tt>xsputn()</tt> Effects clause in
5876 27.5.2.4.5, p1 (N1804):
5877
5878         </p>
5879         <blockquote>
5880             <p>
5881 -1- <i>Effects:</i> Writes up to <tt><i>n</i></tt> characters to the output
5882 sequence as if by repeated calls to <tt>sputc(<i>c</i>)</tt>. The characters
5883 written are obtained from successive elements of the array whose first element
5884 is designated by <tt><i>s</i></tt>. Writing stops when either <tt><i>n</i></tt>
5885 characters have been written or a call to <tt>sputc(<i>c</i>)</tt> would return
5886 <tt>traits::eof()</tt>. <ins>It is  uspecified whether the function  calls
5887 <tt>overflow()</tt> when <tt>(pptr() ==  epptr())</tt> becomes true or whether
5888 it achieves the same effects by other means.</ins>
5889             </p>
5890         </blockquote>
5891         <p>
5892
5893 In addition,  I suggest to  add a footnote  to this function  with the
5894 same text as Footnote 292 to  make it extra clear that derived classes
5895 are permitted to override <tt>xsputn()</tt> for efficiency.
5896
5897         </p>
5898
5899
5900 <p><i>[
5901 Kona (2007): We want to permit a <tt>streambuf</tt> that streams output directly
5902 to a device without making calls to <tt>sputc</tt> or <tt>overflow</tt>. We believe that
5903 has always been the intention of the committee. We believe that the
5904 proposed wording doesn't accomplish that. Proposed Disposition: Open
5905 ]</i></p>
5906
5907
5908
5909
5910
5911 <hr>
5912 <h3><a name="568"></a>568. log2 overloads missing</h3>
5913 <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>
5914  <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-03-07</p>
5915 <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>
5916 <p><b>Discussion:</b></p>
5917 <p>
5918 <tt>log2</tt> is missing from the list of "additional overloads" in TR1 8.16.4 [tr.c99.cmath.over] p1.
5919 </p>
5920
5921 <p>
5922 Hinnant:  This is a TR1 issue only.  It is fixed in the current (N2135) WD.
5923 </p>
5924
5925
5926 <p><b>Proposed resolution:</b></p>
5927 <p>
5928 Add <tt>log2</tt> to the list of functions in TR1 8.16.4 [tr.c99.cmath.over] p1.
5929 </p>
5930
5931
5932
5933
5934
5935 <hr>
5936 <h3><a name="570"></a>570. Request adding additional explicit specializations of char_traits</h3>
5937 <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>
5938  <b>Submitter:</b> Jack Reeves <b>Date:</b> 2006-04-06</p>
5939 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#char.traits">active issues</a> in [char.traits].</p>
5940 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits">issues</a> in [char.traits].</p>
5941 <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>
5942 <p><b>Discussion:</b></p>
5943 <p>
5944 Currently, the Standard Library specifies only a declaration for template class
5945 char_traits&lt;&gt; and requires the implementation provide two explicit
5946 specializations: char_traits&lt;char&gt; and char_traits&lt;wchar_t&gt;. I feel the Standard
5947 should require explicit specializations for all built-in character types, i.e.
5948 char, wchar_t, unsigned char, and signed char.
5949 </p>
5950 <p>
5951 I have put together a paper
5952 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1985.htm">N1985</a>)
5953 that describes this in more detail and
5954 includes all the necessary wording.
5955 </p>
5956 <p><i>[
5957 Portland: Jack will rewrite
5958 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1985.htm">N1985</a>
5959 to propose a primary template that will work with other integral types.
5960 ]</i></p>
5961
5962 <p><i>[
5963 Toronto: issue has grown with addition of <tt>char16_t</tt> and <tt>char32_t</tt>.
5964 ]</i></p>
5965
5966
5967 <p><i>[
5968 post Bellevue:
5969 ]</i></p>
5970
5971
5972 <blockquote>
5973 <p>
5974 We suggest that Jack be asked about the status of his paper, and if it
5975 is not forthcoming, the work-item be assigned to someone else. If no one
5976 steps forward to do the paper before the next meeting, we propose to
5977 make this NAD without further discussion. We leave this Open for now,
5978 but our recommendation is NAD.
5979 </p>
5980 <p>
5981 Note: the issue statement should be updated, as the Toronto comment has
5982 already been resolved. E.g., char_traits specializations for char16_t
5983 and char32_t are now in the working paper.
5984 </p>
5985 </blockquote>
5986
5987
5988
5989 <p><b>Proposed resolution:</b></p>
5990
5991
5992
5993
5994
5995 <hr>
5996 <h3><a name="573"></a>573. C++0x file positioning should handle modern file sizes</h3>
5997 <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>
5998  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-04-12</p>
5999 <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>
6000 <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>
6001 <p><b>Discussion:</b></p>
6002 <p>
6003 There are two deficiencies related to file sizes:
6004 </p>
6005 <ol>
6006 <li>It doesn't appear that the Standard Library is specified in
6007       a way that handles modern file sizes, which are often too
6008       large to be represented by an unsigned long.</li>
6009
6010 <li>The std::fpos class does not currently have the ability to
6011       set/get file positions.</li>
6012 </ol>
6013 <p>
6014 The Dinkumware implementation of the Standard Library as shipped with the Microsoft compiler copes with these issues by:
6015 </p>
6016 <ol type="A">
6017 <li>Defining fpos_t be long long, which is large enough to
6018       represent any file position likely in the foreseeable future.</li>
6019
6020 <li>Adding member functions to class fpos. For example,
6021 <blockquote><pre>fpos_t seekpos() const;
6022 </pre></blockquote>
6023 </li>
6024 </ol>
6025 <p>
6026 Because there are so many types relating to file positions and offsets (fpos_t,
6027 fpos, pos_type, off_type, streamoff, streamsize, streampos, wstreampos, and
6028 perhaps more), it is difficult to know if the Dinkumware extensions are
6029 sufficient. But they seem a useful starting place for discussions, and they do
6030 represent existing practice.
6031 </p>
6032
6033 <p><i>[
6034 Kona (2007): We need a paper. It would be nice if someone proposed
6035 clarifications to the definitions of <tt>pos_type</tt> and <tt>off_type</tt>. Currently
6036 these definitions are horrible. Proposed Disposition: Open
6037 ]</i></p>
6038
6039
6040
6041 <p><b>Proposed resolution:</b></p>
6042 <p>
6043 </p>
6044
6045
6046
6047
6048
6049 <hr>
6050 <h3><a name="574"></a>574. DR 369 Contradicts Text</h3>
6051 <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#Ready">Ready</a>
6052  <b>Submitter:</b> Pete Becker <b>Date:</b> 2006-04-18</p>
6053 <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>
6054 <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>
6055 <p><b>Discussion:</b></p>
6056 <p>
6057 lib.iostream.objects requires that the standard stream objects are never
6058 destroyed, and it requires that they be destroyed.
6059 </p>
6060 <p>
6061 DR 369 adds words to say that we really mean for ios_base::Init objects to force
6062 construction of standard stream objects. It ends, though, with the phrase "these
6063 stream objects shall be destroyed after the destruction of dynamically ...".
6064 However, the rule for destruction is stated in the standard: "The objects are
6065 not destroyed during program execution."
6066 </p>
6067
6068
6069 <p><b>Proposed resolution:</b></p>
6070 <p>
6071 Change 27.3 [iostream.objects]/1:
6072 </p>
6073
6074 <blockquote>
6075 <p>
6076 -2- The objects are constructed and the associations are established at
6077 some time prior to or during the first time an object of class
6078 <tt>ios_base::Init</tt> is constructed, and in any case before the body of main
6079 begins execution.<sup>290)</sup> The objects are not destroyed during program
6080 execution.<sup>291)</sup> If a translation unit includes <tt>&lt;iostream&amp;t;</tt> or explicitly
6081 constructs an <tt>ios_base::Init</tt> object, these stream objects shall be
6082 constructed before dynamic initialization of non-local objects defined
6083 later in that translation unit<del>, and these stream objects shall be
6084 destroyed after the destruction of dynamically initialized non-local
6085 objects defined later in that translation unit</del>.
6086 </p>
6087 </blockquote>
6088
6089
6090 <p><i>[
6091 Kona (2007): From 27.3 [iostream.objects]/2, strike the words "...and these stream objects
6092 shall be destroyed after the destruction of dynamically initialized
6093 non-local objects defined later in that translation unit." Proposed
6094 Disposition: Review
6095 ]</i></p>
6096
6097
6098
6099
6100
6101 <hr>
6102 <h3><a name="580"></a>580. unused allocator members</h3>
6103 <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>
6104  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-14</p>
6105 <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>
6106 <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>
6107 <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>
6108 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a></p>
6109 <p><b>Discussion:</b></p>
6110         <p>
6111
6112 C++ Standard Library  templates that take an allocator  as an argument
6113 are    required    to    call    the    <code>allocate()</code>    and
6114 <code>deallocate()</code>  members of the  allocator object  to obtain
6115 storage.  However, they do not appear to be required to call any other
6116 allocator      members      such     as      <code>construct()</code>,
6117 <code>destroy()</code>,           <code>address()</code>,          and
6118 <code>max_size()</code>.  This makes these allocator members less than
6119 useful in portable programs.
6120
6121         </p>
6122         <p>
6123
6124 It's unclear to me whether the absence of the requirement to use these
6125 allocator  members  is  an  unintentional  omission  or  a  deliberate
6126 choice. However,  since the functions exist in  the standard allocator
6127 and  since  they are  required  to  be  provided by  any  user-defined
6128 allocator I  believe the standard  ought to be clarified  to explictly
6129 specify  whether programs  should or  should not  be able  to  rely on
6130 standard containers calling the functions.
6131
6132         </p>
6133         <p>
6134
6135 I  propose  that all  containers  be required  to  make  use of  these
6136 functions.
6137
6138         </p>
6139 <p><i>[
6140 Batavia:  We support this resolution.  Martin to provide wording.
6141 ]</i></p>
6142
6143 <p><i>[
6144 pre-Oxford:  Martin provided wording.
6145 ]</i></p>
6146
6147
6148
6149     <p><b>Proposed resolution:</b></p>
6150        <p>
6151
6152 Specifically, I propose to change 23.1 [container.requirements],
6153 p9 as follows:
6154
6155        </p>
6156            <blockquote>
6157 <p>
6158 -9- Copy constructors  for all container types defined  in this clause
6159 <ins>that   are  parametrized  on   <code>Allocator</code></ins>  copy
6160 <del>an</del><ins>the</ins>  allocator argument from  their respective
6161 first parameters.
6162
6163 All other  constructors for  these container types  take a<del>n</del>
6164 <ins>const</ins>  <code>Allocator&amp;</code>  argument  (20.1.6),  an
6165 allocator whose <code>value_type</code> is the same as the container's
6166 <code>value_type</code>.
6167
6168 A copy of this  argument <del>is</del><ins>shall be</ins> used for any
6169 memory  allocation <ins> and  deallocation</ins> performed<del>,</del>
6170 by these  constructors and by all  member functions<del>,</del> during
6171 the  lifetime  of each  container  object.   <ins>Allocation shall  be
6172 performed  "as  if"  by  calling  the  <code>allocate()</code>  member
6173 function on  a copy  of the allocator  object of the  appropriate type
6174 <sup>New  Footnote)</sup>,   and  deallocation  "as   if"  by  calling
6175 <code>deallocate()</code> on  a copy of  the same allocator  object of
6176 the corresponding type.</ins>
6177
6178 <ins>A  copy of  this argument  shall also  be used  to  construct and
6179 destroy objects whose lifetime  is managed by the container, including
6180 but not  limited to those of  the container's <code>value_type</code>,
6181 and  to  obtain  their  address.   All  objects  residing  in  storage
6182 allocated by a  container's allocator shall be constructed  "as if" by
6183 calling the <code>construct()</code> member  function on a copy of the
6184 allocator object of  the appropriate type.  The same  objects shall be
6185 destroyed "as if"  by calling <code>destroy()</code> on a  copy of the
6186 same allocator object  of the same type.  The  address of such objects
6187 shall be obtained "as if" by calling the <code>address()</code> member
6188 function  on  a  copy  of  the allocator  object  of  the  appropriate
6189 type.</ins>
6190
6191 <ins>Finally, a copy  of this argument shall be  used by its container
6192 object to determine  the maximum number of objects  of the container's
6193 <code>value_type</code> the container may  store at the same time. The
6194 container  member function <code>max_size()</code> obtains  this number
6195 from      the      value      returned      by     a      call      to
6196 <code>get_allocator().max_size()</code>.</ins>
6197
6198 In   all  container   types  defined   in  this   clause <ins>that  are
6199 parametrized     on    <code>Allocator</code></ins>,     the    member
6200 <code>get_allocator()</code>     returns     a     copy     of     the
6201 <code>Allocator</code>     object     used     to    construct     the
6202 container.<sup>258)</sup>
6203 </p>
6204 <p>
6205 New Footnote: This type  may be different from <code>Allocator</code>:
6206 it     may    be     derived    from     <code>Allocator</code>    via
6207 <code>Allocator::rebind&lt;U&gt;::other</code>   for  the  appropriate
6208 type <code>U</code>.
6209 </p>
6210            </blockquote>
6211        <p>
6212
6213 The proposed wording seems cumbersome but I couldn't think of a better
6214 way   to  describe   the   requirement  that   containers  use   their
6215 <code>Allocator</code>  to manage  only objects  (regardless  of their
6216 type)  that  persist  over  their  lifetimes  and  not,  for  example,
6217 temporaries  created on the  stack. That  is, containers  shouldn't be
6218 required  to  call  <code>Allocator::construct(Allocator::allocate(1),
6219 elem)</code>  just to  construct a  temporary copy  of an  element, or
6220 <code>Allocator::destroy(Allocator::address(temp),     1)</code>    to
6221 destroy temporaries.
6222
6223        </p>
6224
6225
6226 <p><i>[
6227 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>.
6228 ]</i></p>
6229
6230
6231 <p><i>[
6232 post Oxford:  This would be rendered NAD Editorial by acceptance of
6233 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
6234 ]</i></p>
6235
6236
6237
6238
6239
6240 <hr>
6241 <h3><a name="582"></a>582. specialized algorithms and volatile storage</h3>
6242 <p><b>Section:</b> 20.6.10.1 [uninitialized.copy] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
6243  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-14</p>
6244 <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>
6245 <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>
6246 <p><b>Discussion:</b></p>
6247         <p>
6248
6249 The specialized  algorithms [lib.specialized.algorithms] are specified
6250 as having the general effect of invoking the following expression:
6251
6252         </p>
6253             <pre>
6254 new (static_cast&lt;void*&gt;(&amp;*i))
6255     typename iterator_traits&lt;ForwardIterator&gt;::value_type (x)
6256
6257             </pre>
6258         <p>
6259
6260 This  expression is  ill-formed  when the  type  of the  subexpression
6261 <code>&amp;*i</code> is some volatile-qualified <code>T</code>.
6262
6263         </p>
6264
6265 <p><i>[
6266 Batavia:  Lack of support for proposed resolution but agree there is a
6267 defect.  Howard to look at wording.  Concern that move semantics
6268 properly expressed if iterator returns rvalue.
6269 ]</i></p>
6270
6271
6272
6273
6274     <p><b>Proposed resolution:</b></p>
6275         <p>
6276
6277 In order  to allow these algorithms  to operate on  volatile storage I
6278 propose to change the expression so as to make it well-formed even for
6279 pointers  to volatile  types.  Specifically,  I propose  the following
6280 changes to clauses 20 and 24. Change 20.6.4.1, p1 to read:
6281
6282         </p>
6283             <pre>
6284 <i>Effects</i>:
6285
6286 typedef typename iterator_traits&lt;ForwardIterator&gt;::pointer    pointer;
6287 typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type value_type;
6288
6289 for (; first != last; ++result, ++first)
6290     new (static_cast&lt;void*&gt;(const_cast&lt;pointer&gt;(&amp;*result))
6291         value_type (*first);
6292
6293             </pre>
6294         <p>
6295
6296 change 20.6.4.2, p1 to read
6297
6298         </p>
6299             <pre>
6300 <i>Effects</i>:
6301
6302 typedef typename iterator_traits&lt;ForwardIterator&gt;::pointer    pointer;
6303 typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type value_type;
6304
6305 for (; first != last; ++result, ++first)
6306     new (static_cast&lt;void*&gt;(const_cast&lt;pointer&gt;(&amp;*first))
6307         value_type (*x);
6308
6309             </pre>
6310         <p>
6311
6312 and change 20.6.4.3, p1 to read
6313
6314         </p>
6315             <pre>
6316 <i>Effects</i>:
6317
6318 typedef typename iterator_traits&lt;ForwardIterator&gt;::pointer    pointer;
6319 typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type value_type;
6320
6321 for (; n--; ++first)
6322     new (static_cast&lt;void*&gt;(const_cast&lt;pointer&gt;(&amp;*first))
6323         value_type (*x);
6324
6325             </pre>
6326         <p>
6327
6328 In   addition,  since   there   is  no   partial  specialization   for
6329 <code>iterator_traits&lt;volatile T*&gt;</code>  I propose to  add one
6330 to parallel such specialization  for &lt;const T*&gt;. Specifically, I
6331 propose to add the following text to the end of 24.3.1, p3:
6332
6333         </p>
6334         <p>
6335
6336 and for pointers to volatile as
6337
6338         </p>
6339             <pre>
6340 namespace std {
6341 template&lt;class T&gt; struct iterator_traits&lt;volatile T*&gt; {
6342 typedef ptrdiff_t difference_type;
6343 typedef T value_type;
6344 typedef volatile T* pointer;
6345 typedef volatile T&amp; reference;
6346 typedef random_access_iterator_tag iterator_category;
6347 };
6348 }
6349
6350             </pre>
6351         <p>
6352
6353 Note that  the change to  <code>iterator_traits</code> isn't necessary
6354 in order to implement the  specialized algorithms in a way that allows
6355 them to operate on volatile  strorage. It is only necesassary in order
6356 to specify  their effects in terms  of <code>iterator_traits</code> as
6357 is  done here.   Implementations can  (and some  do) achieve  the same
6358 effect by means of function template overloading.
6359
6360         </p>
6361
6362
6363
6364
6365 <hr>
6366 <h3><a name="585"></a>585. facet error reporting</h3>
6367 <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>
6368  <b>Submitter:</b> Martin Sebor, Paolo Carlini <b>Date:</b> 2006-06-22</p>
6369 <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>
6370 <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>
6371 <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>
6372 <p><b>Discussion:</b></p>
6373         <p>
6374
6375 Section  22.2, paragraph 2  requires facet  <code>get()</code> members
6376 that    take    an    <code>ios_base::iostate&amp;</code>    argument,
6377 <code><i>err</i></code>,  to   ignore  the  (initial)   value  of  the
6378 argument, but to set it to <code>ios_base::failbit</code> in case of a
6379 parse error.
6380
6381         </p>
6382         <p>
6383
6384 We  believe  there  are  a   few  minor  problems  with  this  blanket
6385 requirement  in   conjunction  with   the  wording  specific   to  each
6386 <code>get()</code> member function.
6387
6388         </p>
6389         <p>
6390
6391 First,  besides <code>get()</code>  there are  other  member functions
6392 with     a      slightly     different     name      (for     example,
6393 <code>get_date()</code>). It's not completely clear that the intent of
6394 the  paragraph  is  to  include  those  as  well,  and  at  least  one
6395 implementation has interpreted the requirement literally.
6396
6397         </p>
6398         <p>
6399
6400 Second,    the     requirement    to    "set     the    argument    to
6401 <code>ios_base::failbit</code>  suggests that  the  functions are  not
6402 permitted    to   set    it   to    any   other    value    (such   as
6403 <code>ios_base::eofbit</code>,   or   even  <code>ios_base::eofbit   |
6404 ios_base::failbit</code>).
6405
6406         </p>
6407         <p>
6408
6409 However, 22.2.2.1.2, p5 (Stage  3 of <code>num_get</code> parsing) and
6410 p6 (<code>bool</code> parsing)  specifies that the <code>do_get</code>
6411 functions  perform <code><i>err</i> |=  ios_base::eofbit</code>, which
6412 contradicts  the earlier  requirement to  ignore  <i>err</i>'s initial
6413 value.
6414
6415         </p>
6416         <p>
6417
6418 22.2.6.1.2,  p1  (the  Effects  clause of  the  <code>money_get</code>
6419 facet's  <code>do_get</code>  member  functions) also  specifies  that
6420 <code><i>err</i></code>'s initial  value be used to  compute the final
6421 value  by  ORing  it  with  either  <code>ios_base::failbit</code>  or
6422 with<code>ios_base::eofbit | ios_base::failbit</code>.
6423
6424         </p>
6425
6426
6427     <p><b>Proposed resolution:</b></p>
6428         <p>
6429
6430 We believe the  intent is for all facet member  functions that take an
6431 <code>ios_base::iostate&amp;</code> argument to:
6432
6433         </p>
6434             <ul>
6435                 <li>
6436
6437 ignore the initial value of the <code><i>err</i></code> argument,
6438
6439                 </li>
6440                 <li>
6441
6442 reset <code><i>err</i></code>  to <code>ios_base::goodbit</code> prior
6443 to any further processing,
6444
6445                 </li>
6446                 <li>
6447
6448 and       set      either       <code>ios_base::eofbit</code>,      or
6449 <code>ios_base::failbit</code>, or both in <code><i>err</i></code>, as
6450 appropriate,  in response  to  reaching the  end-of-file  or on  parse
6451 error, or both.
6452
6453                 </li>
6454             </ul>
6455         <p>
6456
6457 To that effect we propose to change 22.2, p2 as follows:
6458
6459         </p>
6460         <p>
6461
6462 The  <i>put</i><del>()</del>  members  make  no  provision  for  error
6463 reporting.   (Any  failures of  the  OutputIterator  argument must  be
6464 extracted   from  the   returned  iterator.)    <ins>Unless  otherwise
6465 specified, </ins>the <i>get</i><del>()</del>  members  <ins>that</ins>
6466 take an  <code>ios_base::iostate&amp;</code> argument <del>whose value
6467 they  ignore,  but  set  to  ios_base::failbit  in  case  of  a  parse
6468 error.</del><ins>,   <code><i>err</i></code>,   start  by   evaluating
6469 <code>err  =   ios_base::goodbit</code>,  and  may   subsequently  set
6470 <i>err</i>     to     either     <code>ios_base::eofbit</code>,     or
6471 <code>ios_base::failbit</code>,     or     <code>ios_base::eofbit    |
6472 ios_base::failbit</code> in response to reaching the end-of-file or in
6473 case of a parse error, or both, respectively.</ins>
6474
6475         </p>
6476
6477
6478 <p><i>[
6479 Kona (2007): We need to change the proposed wording to clarify that the
6480 phrase "the get members" actually denotes <tt>get()</tt>, <tt>get_date()</tt>, etc.
6481 Proposed Disposition: Open
6482 ]</i></p>
6483
6484
6485
6486
6487 <hr>
6488 <h3><a name="588"></a>588. requirements on zero sized tr1::arrays and other details</h3>
6489 <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>
6490  <b>Submitter:</b> Gennaro Prota <b>Date:</b> 2006-07-18</p>
6491 <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>
6492 <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>
6493 <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>
6494 <p><b>Discussion:</b></p>
6495 <p>
6496 The wording used for section 23.2.1 [lib.array] seems to be subtly
6497 ambiguous about zero sized arrays (N==0). Specifically:
6498 </p>
6499 <p>
6500 * "An instance of array&lt;T, N&gt; stores N elements of type T, so that
6501 [...]"
6502 </p>
6503 <p>
6504 Does this imply that a zero sized array object stores 0 elements, i.e.
6505 that it cannot store any element of type T? The next point clarifies
6506 the rationale behind this question, basically how to implement begin()
6507 and end():
6508 </p>
6509 <p>
6510 * 23.2.1.5 [lib.array.zero], p2: "In the case that N == 0, begin() ==
6511 end() == unique value."
6512 </p>
6513 <p>
6514 What does "unique" mean in this context? Let's consider the following
6515 possible implementations, all relying on a partial specialization:
6516 </p>
6517 <blockquote><pre>a)
6518     template&lt; typename T &gt;
6519     class array&lt; T, 0 &gt; {
6520
6521         ....
6522
6523         iterator begin()
6524         { return iterator( reinterpret_cast&lt; T * &gt;( this ) ); }
6525         ....
6526
6527     };
6528 </pre></blockquote>
6529 <p>
6530 This has been used in boost, probably intending that the return value
6531 had to be unique to the specific array object and that array couldn't
6532 store any T. Note that, besides relying on a reinterpret_cast, has
6533 (more than potential) alignment problems.
6534 </p>
6535 <blockquote><pre>b)
6536     template&lt; typename T &gt;
6537     class array&lt; T, 0 &gt; {
6538
6539         T t;
6540
6541         iterator begin()
6542         { return iterator( &amp;t ); }
6543         ....
6544
6545     };
6546 </pre></blockquote>
6547 <p>
6548 This provides a value which is unique to the object and to the type of
6549 the array, but requires storing a T. Also, it would allow the user to
6550 mistakenly provide an initializer list with one element.
6551 </p>
6552 <p>
6553 A slight variant could be returning *the* null pointer of type T
6554 </p>
6555 <blockquote><pre>    return static_cast&lt;T*&gt;(0);
6556 </pre></blockquote>
6557 <p>
6558 In this case the value would be unique to the type array&lt;T, 0&gt; but not
6559 to the objects (all objects of type array&lt;T, 0&gt; with the same value
6560 for T would yield the same pointer value).
6561 </p>
6562 <p>
6563 Furthermore this is inconsistent with what the standard requires from
6564 allocation functions (see library issue 9).
6565 </p>
6566 <p>
6567 c) same as above but with t being a static data member; again, the
6568 value would be unique to the type, not to the object.
6569 </p>
6570 <p>
6571 d) to avoid storing a T *directly* while disallowing the possibility
6572 to use a one-element initializer list a non-aggregate nested class
6573 could be defined
6574 </p>
6575 <blockquote><pre>    struct holder { holder() {} T t; } h;
6576 </pre></blockquote>
6577 <p>
6578 and then begin be defined as
6579 </p>
6580 <blockquote><pre> iterator begin() { return &amp;h.t; }
6581 </pre></blockquote>
6582 <p>
6583 But then, it's arguable whether the array stores a T or not.
6584 Indirectly it does.
6585 </p>
6586 <p>
6587 -----------------------------------------------------
6588 </p>
6589 <p>
6590 Now, on different issues:
6591 </p>
6592 <p>
6593 * what's the effect of calling assign(T&amp;) on a zero-sized array? There
6594 seems to be only mention of front() and back(), in 23.2.1 [lib.array]
6595 p4 (I would also suggest to move that bullet to section 23.2.1.5
6596 [lib.array.zero], for locality of reference)
6597 </p>
6598 <p>
6599 * (minor) the opening paragraph of 23.2.1 [lib.array] wording is a bit
6600 inconsistent with that of other sequences: that's not a problem in
6601 itself, but compare it for instance with "A vector is a kind of
6602 sequence that supports random access iterators"; though the intent is
6603 obvious one might argue that the wording used for arrays doesn't tell
6604 what an array is, and relies on the reader to infer that it is what
6605 the &lt;array&gt; header defines.
6606 </p>
6607 <p>
6608 * it would be desiderable to have a static const data member of type
6609 std::size_t, with value N, for usage as integral constant expression
6610 </p>
6611 <p>
6612 * section 23.1 [lib.container.requirements] seem not to consider
6613 fixed-size containers at all, as it says: "[containers] control
6614 allocation and deallocation of these objects [the contained objects]
6615 through constructors, destructors, *insert and erase* operations"
6616 </p>
6617 <p>
6618 * max_size() isn't specified: the result is obvious but, technically,
6619 it relies on table 80: "size() of the largest possible container"
6620 which, again, doesn't seem to consider fixed size containers
6621 </p>
6622
6623
6624 <p><b>Proposed resolution:</b></p>
6625 <p>
6626 </p>
6627
6628
6629 <p><i>[
6630 Kona (2007): requirements on zero sized <tt>tr1::array</tt>s and other details
6631 Issue 617: <tt>std::array</tt> is a sequence that doesn't satisfy the sequence
6632 requirements? Alisdair will prepare a paper. Proposed Disposition: Open
6633 ]</i></p>
6634
6635
6636
6637
6638
6639 <hr>
6640 <h3><a name="595"></a>595. TR1/C++0x: fabs(complex&lt;T&gt;) redundant / wrongly specified</h3>
6641 <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>
6642  <b>Submitter:</b> Stefan Große Pawig <b>Date:</b> 2006-09-24</p>
6643 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#complex.value.ops">active issues</a> in [complex.value.ops].</p>
6644 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.value.ops">issues</a> in [complex.value.ops].</p>
6645 <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>
6646 <p><b>Discussion:</b></p>
6647 <p>
6648 TR1 introduced, in the C compatibility chapter, the function
6649 fabs(complex&lt;T&gt;):
6650 </p>
6651 <blockquote><pre>----- SNIP -----
6652 8.1.1 Synopsis                                [tr.c99.cmplx.syn]
6653
6654   namespace std {
6655   namespace tr1 {
6656 [...]
6657   template&lt;class T&gt; complex&lt;T&gt; fabs(const complex&lt;T&gt;&amp; x);
6658   } // namespace tr1
6659   } // namespace std
6660
6661 [...]
6662
6663 8.1.8 Function fabs                          [tr.c99.cmplx.fabs]
6664
6665 1 Effects: Behaves the same as C99 function cabs, defined in
6666   subclause 7.3.8.1.
6667 ----- SNIP -----
6668 </pre></blockquote>
6669
6670 <p>
6671 The current C++0X draft document (n2009.pdf) adopted this
6672 definition in chapter 26.3.1 (under the comment // 26.3.7 values)
6673 and 26.3.7/7.
6674 </p>
6675 <p>
6676 But in C99 (ISO/IEC 9899:1999 as well as the 9899:TC2 draft document
6677 n1124), the referenced subclause reads
6678 </p>
6679
6680 <blockquote><pre>----- SNIP -----
6681 7.3.8.1 The cabs functions
6682
6683   Synopsis
6684
6685 1 #include &lt;complex.h&gt;
6686   double cabs(double complex z);
6687   float cabsf(float complex z);
6688   long double cabsl(long double z);
6689
6690   Description
6691
6692 2 The cabs functions compute the complex absolute value (also called
6693   norm, modulus, or magnitude) of z.
6694
6695   Returns
6696
6697 3 The cabs functions return the complex absolute value.
6698 ----- SNIP -----
6699 </pre></blockquote>
6700
6701 <p>
6702 Note that the return type of the cabs*() functions is not a complex
6703 type.  Thus, they are equivalent to the already well established
6704   template&lt;class T&gt; T abs(const complex&lt;T&gt;&amp; x);
6705 (26.2.7/2 in ISO/IEC 14882:1998, 26.3.7/2 in the current draft
6706 document n2009.pdf).
6707 </p>
6708 <p>
6709 So either the return value of fabs() is specified wrongly, or fabs()
6710 does not behave the same as C99's cabs*().
6711 </p>
6712
6713 <b>Possible Resolutions</b>
6714
6715 <p>
6716 This depends on the intention behind the introduction of fabs().
6717 </p>
6718 <p>
6719 If the intention was to provide a /complex/ valued function that
6720 calculates the magnitude of its argument, this should be
6721 explicitly specified.  In TR1, the categorization under "C
6722 compatibility" is definitely wrong, since C99 does not provide
6723 such a complex valued function.
6724 </p>
6725 <p>
6726 Also, it remains questionable if such a complex valued function
6727 is really needed, since complex&lt;T&gt; supports construction and
6728 assignment from real valued arguments.  There is no difference
6729 in observable behaviour between
6730 </p>
6731 <blockquote><pre>  complex&lt;double&gt; x, y;
6732   y = fabs(x);
6733   complex&lt;double&gt; z(fabs(x));
6734 </pre></blockquote>
6735 <p>
6736 and
6737 </p>
6738 <blockquote><pre>  complex&lt;double&gt; x, y;
6739   y = abs(x);
6740   complex&lt;double&gt; z(abs(x));
6741 </pre></blockquote>
6742 <p>
6743 If on the other hand the intention was to provide the intended
6744 functionality of C99, fabs() should be either declared deprecated
6745 or (for C++0X) removed from the standard, since the functionality
6746 is already provided by the corresponding overloads of abs().
6747 </p>
6748
6749 <p><i>[
6750 Bellevue:
6751 ]</i></p>
6752
6753
6754 <blockquote>
6755 Bill believes that abs() is a suitable overload. We should remove fabs().
6756 </blockquote>
6757
6758
6759 <p><b>Proposed resolution:</b></p>
6760
6761 <p>
6762 Change the synopsis in 26.3.1 [complex.synopsis]:
6763 </p>
6764
6765 <blockquote><pre><del>template&lt;class T&gt; complex&lt;T&gt; fabs(const complex&lt;T&gt;&amp;);</del>
6766 </pre></blockquote>
6767
6768 <p>
6769 Remove 26.3.7 [complex.value.ops], p7:
6770 </p>
6771
6772 <blockquote>
6773 <pre><del>template&lt;class T&gt; complex&lt;T&gt; fabs(const complex&lt;T&gt;&amp; <i>x</i>);</del>
6774 </pre>
6775 <blockquote>
6776 <p>
6777 <del>-7- <i>Effects:</i> Behaves the same as C99 function <tt>cabs</tt>, defined in subclause 7.3.8.1.</del>
6778 </p>
6779 </blockquote>
6780 </blockquote>
6781
6782
6783
6784 <p><i>[
6785 Kona (2007): Change the return type of <tt>fabs(complex)</tt> to <tt>T</tt>.
6786 Proposed Disposition: Ready
6787 ]</i></p>
6788
6789
6790
6791
6792
6793 <hr>
6794 <h3><a name="596"></a>596. 27.8.1.3 Table 112 omits "a+" and "a+b" modes</h3>
6795 <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#Ready">Ready</a>
6796  <b>Submitter:</b> Thomas Plum <b>Date:</b> 2006-09-26</p>
6797 <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>
6798 <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>
6799 <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>
6800 <p><b>Discussion:</b></p>
6801 <p>
6802 In testing 27.8.1.4 [filebuf.members], Table 112 (in the latest N2009 draft), we invoke
6803 </p>
6804 <blockquote><pre>   ostr.open("somename", ios_base::out | ios_base::in | ios_base::app)
6805 </pre></blockquote>
6806 <p>
6807 and we expect the open to fail, because out|in|app is not listed in
6808 Table 92, and just before the table we see very specific words:
6809 </p>
6810 <blockquote><p>
6811   If mode is not some combination of flags shown in the table
6812   then the open fails.
6813 </p></blockquote>
6814 <p>
6815 But the corresponding table in the C standard, 7.19.5.3, provides two
6816 modes "a+" and "a+b", to which the C++ modes out|in|app and
6817 out|in|app|binary would presumably apply.
6818 </p>
6819 <p>
6820 We would like to argue that the intent of Table 112 was to match the
6821 semantics of 7.19.5.3 and that the omission of "a+" and "a+b" was
6822 unintentional.  (Otherwise there would be valid and useful behaviors
6823 available in C file I/O which are unavailable using C++, for no
6824 valid functional reason.)
6825 </p>
6826 <p>
6827 We further request that the missing modes be explicitly restored to
6828 the WP, for inclusion in C++0x.
6829 </p>
6830
6831 <p><i>[
6832 Martin adds:
6833 ]</i></p>
6834
6835
6836 <p>
6837 ...besides "a+" and "a+b" the C++ table is also missing a row
6838 for a lone app bit which in at least two current implementation
6839 as well as in Classic Iostreams corresponds to the C stdio "a"
6840 mode and has been traditionally documented as implying ios::out.
6841 Which means the table should also have a row for in|app meaning
6842 the same thing as "a+" already proposed in the issue.
6843 </p>
6844
6845
6846 <p><b>Proposed resolution:</b></p>
6847 <p>
6848 Add to the table "File open modes" in 27.8.1.4 [filebuf.members]:
6849 </p>
6850
6851 <blockquote>
6852 <table border="1">
6853 <caption> File open modes</caption>
6854 <tbody><tr>
6855 <th colspan="5"><tt>ios_base</tt> Flag combination</th>
6856 <th><tt>stdio</tt> equivalent</th>
6857 </tr>
6858 <tr>
6859 <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>
6860 </tr>
6861
6862 <tr>
6863 <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"w"</tt></td>
6864 </tr>
6865 <tr>
6866 <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>"a"</tt></td>
6867 </tr>
6868 <tr>
6869 <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>
6870 </tr>
6871 <tr>
6872 <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"w"</tt></td>
6873 </tr>
6874 <tr>
6875 <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"r"</tt></td>
6876 </tr>
6877 <tr>
6878 <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"r+"</tt></td>
6879 </tr>
6880 <tr>
6881 <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"w+"</tt></td>
6882 </tr>
6883 <tr>
6884 <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>
6885 </tr>
6886 <tr>
6887 <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>
6888 </tr>
6889
6890 <tr>
6891 <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"wb"</tt></td>
6892 </tr>
6893 <tr>
6894 <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>"ab"</tt></td>
6895 </tr>
6896 <tr>
6897 <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>
6898 </tr>
6899 <tr>
6900 <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"wb"</tt></td>
6901 </tr>
6902 <tr>
6903 <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"rb"</tt></td>
6904 </tr>
6905 <tr>
6906 <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"r+b"</tt></td>
6907 </tr>
6908 <tr>
6909 <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>
6910 </tr><tr>
6911 <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>
6912 </tr>
6913 <tr>
6914 <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>
6915 </tr>
6916
6917
6918 </tbody></table>
6919 </blockquote>
6920
6921
6922
6923 <p><i>[
6924 Kona (2007) Added proposed wording and moved to Review.
6925 ]</i></p>
6926
6927
6928
6929
6930
6931 <hr>
6932 <h3><a name="597"></a>597. Decimal: The notion of 'promotion' cannot be emulated by user-defined types.</h3>
6933 <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>
6934  <b>Submitter:</b> Daveed Vandevoorde <b>Date:</b> 2006-04-05</p>
6935 <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>
6936 <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>
6937 <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>
6938 <p><b>Discussion:</b></p>
6939 <p>
6940 In a private email, Daveed writes:
6941 </p>
6942 <blockquote>
6943 <p>
6944 I am not familiar with the C TR, but my guess is that the
6945 class type approach still won't match a built-in type
6946 approach because the notion of "promotion" cannot be
6947 emulated by user-defined types.
6948 </p>
6949 <p>
6950 Here is an example:
6951 </p>
6952 </blockquote>
6953 <pre>
6954                  struct S {
6955                    S(_Decimal32 const&amp;);  // Converting constructor
6956                  };
6957                  void f(S);
6958
6959                  void f(_Decimal64);
6960
6961                  void g(_Decimal32 d) {
6962                    f(d);
6963                  }
6964 </pre>
6965
6966 <blockquote>
6967 <p>
6968 If _Decimal32 is a built-in type, the call f(d) will likely
6969 resolve to f(_Decimal64) because that requires only a
6970 promotion, whereas f(S) requires a user-defined conversion.
6971 </p>
6972 <p>
6973 If _Decimal32 is a class type, I think the call f(d) will be
6974 ambiguous because both the conversion to _Decimal64 and the
6975 conversion to S will be user-defined conversions with neither
6976 better than the other.
6977 </p>
6978 </blockquote>
6979 <p>
6980 Robert comments:
6981 </p>
6982 <p>
6983 In general, a library of arithmetic types cannot exactly emulate the
6984 behavior of the intrinsic numeric types. There are several ways to tell
6985 whether an implementation of the decimal types uses compiler
6986 intrinisics or a library. For example:
6987 </p>
6988 <pre>                 _Decimal32 d1;
6989                  d1.operator+=(5);  // If d1 is a builtin type, this won't compile.
6990 </pre>
6991 <p>
6992 In preparing the decimal TR, we have three options:
6993 </p>
6994 <ol>
6995 <li>require that the decimal types be class types</li>
6996 <li>require that the decimal types be builtin types, like float and double</li>
6997 <li>specify a library of class types, but allow enough implementor
6998 latitude that a conforming implementation could instead provide builtin
6999 types</li>
7000 </ol>
7001 <p>
7002 We decided as a group to pursue option #3, but that approach implies
7003 that implementations may not agree on the semantics of certain use
7004 cases (first example, above), or on whether certain other cases are
7005 well-formed (second example). Another potentially important problem is
7006 that, under the present definition of POD, the decimal classes are not
7007 POD types, but builtins will be.
7008 </p>
7009 <p>Note that neither example above implies any problems with respect to
7010 C-to-C++ compatibility, since neither example can be expressed in C.
7011 </p>
7012
7013
7014 <p><b>Proposed resolution:</b></p>
7015
7016
7017
7018
7019
7020 <hr>
7021 <h3><a name="606"></a>606. Decimal: allow narrowing conversions</h3>
7022 <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>
7023  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-15</p>
7024 <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>
7025 <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>
7026 <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>
7027 <p><b>Discussion:</b></p>
7028 <p>
7029 In c++std-lib-17205, Martin writes:
7030 </p>
7031 <blockquote><p>...was it a deliberate design choice to make narrowing
7032 assignments ill-formed while permitting narrowing compound assignments?
7033 For instance:
7034 </p></blockquote>
7035 <pre>      decimal32 d32;
7036       decimal64 d64;
7037
7038       d32 = 64;     // error
7039       d32 += 64;    // okay
7040 </pre>
7041 <p>
7042 In c++std-lib-17229, Robert responds:
7043 </p>
7044 <blockquote><p>It is a vestige of an old idea that I forgot to remove
7045 from the paper. Narrowing assignments should be permitted. The bug is
7046 that the converting constructors that cause narrowing should not be
7047 explicit. Thanks for pointing this out.
7048 </p></blockquote>
7049
7050 <p><b>Proposed resolution:</b></p>
7051 <p>
7052 1.  In "3.2.2 Class <code>decimal32</code>" synopsis, remove the <code>explicit</code> specifier from the narrowing conversions:
7053 </p>
7054 <pre>                // <i>3.2.2.2 conversion from floating-point type:</i>
7055                 <del>explicit</del> decimal32(decimal64 <i>d64</i>);
7056                 <del>explicit</del> decimal32(decimal128 <i>d128</i>);
7057 </pre>
7058 <p>
7059 2.  Do the same thing in "3.2.2.2. Conversion from floating-point type."
7060 </p>
7061 <p>
7062 3.  In "3.2.3 Class <code>decimal64</code>" synopsis, remove the <code>explicit</code> specifier from the narrowing conversion:
7063 </p>
7064 <pre>                // <i>3.2.3.2 conversion from floating-point type:</i>
7065                 <del>explicit</del> decimal64(decimal128 <i>d128</i>);
7066 </pre>
7067 <p>
7068 4.  Do the same thing in "3.2.3.2. Conversion from floating-point type."
7069 </p>
7070
7071 <p><i>[
7072 Redmond: We prefer explicit conversions for narrowing and implicit for widening.
7073 ]</i></p>
7074
7075
7076
7077
7078
7079
7080 <hr>
7081 <h3><a name="612"></a>612. numeric_limits::is_modulo insufficiently defined</h3>
7082 <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#Ready">Ready</a>
7083  <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2006-11-10</p>
7084 <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>
7085 <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>
7086 <p><b>Discussion:</b></p>
7087 <p>
7088 18.2.1.2 55 states that "A type is modulo if it is possible to add two
7089 positive numbers together and have a result that wraps around to a
7090 third number that is less".
7091 This seems insufficient for the following reasons:
7092 </p>
7093
7094 <ol>
7095 <li>Doesn't define what that value received is.</li>
7096 <li>Doesn't state the result is repeatable</li>
7097 <li> Doesn't require that doing addition, subtraction and other
7098 operations on all values is defined behaviour.</li>
7099 </ol>
7100
7101 <p><i>[
7102 Batavia: Related to
7103 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2144.pdf">N2144</a>.
7104 Pete: is there an ISO definition of modulo?  Underflow on signed behavior is undefined.
7105 ]</i></p>
7106
7107
7108 <p><i>[
7109 Bellevue:  accept resolution, move to ready status.
7110 Does this mandate that is_modulo be true on platforms for which int
7111 happens to b modulo? A: the standard already seems to require that.
7112 ]</i></p>
7113
7114
7115
7116 <p><b>Proposed resolution:</b></p>
7117 <p>
7118 Suggest 18.2.1.2 [numeric.limits.members[numeric.limits.members], paragraph 57 is amended to:
7119 </p>
7120
7121 <blockquote><p>
7122 A type is modulo if<ins>,</ins> <del>it is possible to add two positive numbers
7123 and have a result that wraps around to a third number that is less.</del>
7124 <ins>given any operation involving +,- or * on values of that type whose value
7125 would fall outside the range <tt>[min(), max()]</tt>, then the value returned
7126 differs from the true value by an integer multiple of <tt>(max() - min() +
7127 1)</tt>.</ins>
7128 </p></blockquote>
7129
7130
7131
7132
7133
7134
7135 <hr>
7136 <h3><a name="614"></a>614. std::string allocator requirements still inconsistent</h3>
7137 <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>
7138  <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-05</p>
7139 <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>
7140 <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>
7141 <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>
7142 <p><b>Discussion:</b></p>
7143 <p>
7144 This is based on N2134, where 21.3.1/2 states:
7145 "... The Allocator object used shall be a copy of the Allocator object
7146 passed to the basic_string object's constructor or, if the constructor does
7147 not take an Allocator argument, a copy of a default-constructed Allocator
7148 object."
7149 </p>
7150 <p>
7151 Section 21.3.2/1 lists two constructors:
7152 </p>
7153 <blockquote><pre>basic_string(const basic_string&lt;charT,traits,Allocator&gt;&amp; str );
7154
7155 basic_string(const basic_string&lt;charT,traits,Allocator&gt;&amp; str ,
7156              size_type pos , size_type n = npos,
7157              const Allocator&amp; a = Allocator());
7158 </pre></blockquote>
7159 <p>
7160 and then says "In the first form, the Allocator value used is copied from
7161 str.get_allocator().", which isn't an option according to 21.3.1.
7162 </p>
7163 <p><i>[
7164 Batavia:  We need blanket statement to the effect of:
7165 ]</i></p>
7166
7167
7168 <ol>
7169 <li>If an allocator is passed in, use it, or,</li>
7170 <li>If a string is passed in, use its allocator.</li>
7171 </ol>
7172 <p><i>[
7173 Review constructors and functions that return a string; make sure we follow these
7174 rules (substr, operator+, etc.).  Howard to supply wording.
7175 ]</i></p>
7176
7177
7178 <p><i>[
7179 Bo adds:  The new container constructor which takes only a <tt>size_type</tt> is not
7180 consistent with 23.1 [container.requirements], p9 which says in part:
7181
7182 <blockquote>
7183 All other constructors for these container types take an
7184 <tt>Allocator&amp;</tt> argument (20.1.2), an allocator whose value type
7185 is the same as the container's value type. A copy of this argument is
7186 used for any memory allocation performed, by these constructors and by
7187 all member functions, during the lifetime of each container object.
7188 </blockquote>
7189 ]</i></p>
7190
7191
7192 <p><i>[
7193 post Bellevue: We re-confirm that the issue is real. Pablo will provide wording.
7194 ]</i></p>
7195
7196
7197
7198
7199 <p><b>Proposed resolution:</b></p>
7200 <p>
7201 </p>
7202
7203
7204
7205
7206
7207 <hr>
7208 <h3><a name="617"></a>617. std::array is a sequence that doesn't satisfy the sequence requirements?</h3>
7209 <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>
7210  <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-30</p>
7211 <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>
7212 <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>
7213 <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>
7214 <p><b>Discussion:</b></p>
7215 <p>
7216 The <tt>&lt;array&gt;</tt> header is given under 23.2 [sequences].
7217 23.2.1 [array]/paragraph 3 says:
7218 </p>
7219 <blockquote><p>
7220 "Unless otherwise specified, all array operations are as described in
7221 23.1 [container.requirements]".
7222 </p></blockquote>
7223 <p>
7224 However, array isn't mentioned at all in section 23.1 [container.requirements].
7225 In particular, Table 82 "Sequence requirements" lists several operations (insert, erase, clear)
7226 that std::array does not have in 23.2.1 [array].
7227 </p>
7228 <p>
7229 Also, Table 83 "Optional sequence operations" lists several operations that
7230 std::array does have, but array isn't mentioned.
7231 </p>
7232
7233
7234 <p><b>Proposed resolution:</b></p>
7235 <p>
7236 </p>
7237
7238
7239
7240
7241
7242 <hr>
7243 <h3><a name="618"></a>618. valarray::cshift() effects on empty array</h3>
7244 <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#Ready">Ready</a>
7245  <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2007-01-10</p>
7246 <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>
7247 <p><b>Discussion:</b></p>
7248 <p>
7249 I would respectfully request an issue be opened with the intention to
7250 clarify the wording for <tt>size() == 0</tt> for <tt>cshift</tt>.
7251 </p>
7252
7253
7254 <p><b>Proposed resolution:</b></p>
7255 <p>
7256 Change 26.5.2.7 [valarray.members], paragraph 10:
7257 </p>
7258
7259 <blockquote>
7260
7261 <pre>valarray&lt;T&gt; cshift(int <i>n</i>) const;
7262 </pre>
7263
7264 <blockquote>
7265 <p>
7266 This function returns an object of class <tt>valarray&lt;T&gt;</tt>, of
7267 length <tt>size()</tt>, <del>each of whose elements <tt>I</tt> is
7268 <tt>(*this)[(I + n ) % size()]</tt>. Thus, if element zero is taken as
7269 the leftmost element, a positive value of <i>n</i> shifts the elements
7270 circularly left <i>n</i> places.</del> <ins>that is a circular shift of <tt>*this</tt>. If
7271 element zero is taken as the leftmost element, a non-negative value of
7272 <i>n</i> shifts the elements circularly left <i>n</i> places and a
7273 negative value of <i>n</i> shifts the elements circularly right
7274 -<i>n</i> places.</ins>
7275 </p>
7276 </blockquote>
7277 </blockquote>
7278
7279
7280
7281 <p><b>Rationale:</b></p>
7282 <p>
7283 We do not believe that there is any real ambiguity about what happens
7284 when <tt>size() == 0</tt>, but we do believe that spelling this out as a C++
7285 expression causes more trouble that it solves. The expression is
7286 certainly wrong when <tt>n &lt; 0</tt>, since the sign of % with negative arguments
7287 is implementation defined.
7288 </p>
7289
7290
7291 <p><i>[
7292 Kona (2007) Changed proposed wording, added rationale and set to Review.
7293 ]</i></p>
7294
7295
7296
7297
7298
7299 <hr>
7300 <h3><a name="629"></a>629. complex<t> insertion and locale dependence</t></h3>
7301 <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#Ready">Ready</a>
7302  <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2007-01-28</p>
7303 <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>
7304 <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>
7305 <p><b>Discussion:</b></p>
7306 <p>
7307 is there an issue opened for (0,3) as complex number with
7308 the French local?  With the English local, the above parses as an
7309 imaginery complex number.  With the French locale it parses as a
7310 real complex number.
7311 </p>
7312
7313 <p>
7314 Further notes/ideas from the lib-reflector, messages 17982-17984:
7315 </p>
7316
7317 <blockquote>
7318 <p>
7319 Add additional entries in num_punct to cover the complex separator (French would be ';').
7320 </p>
7321 <p>
7322 Insert a space before the comma, which should eliminate the ambiguity.
7323 </p>
7324 <p>
7325 Solve the problem for ordered sequences in general, perhaps with a
7326 dedicated facet.  Then complex should use that solution.
7327 </p>
7328 </blockquote>
7329
7330 <p><i>[
7331 Bellevue:
7332 ]</i></p>
7333
7334
7335 <blockquote>
7336 <p>
7337 After much discussion, we agreed on the following: Add a footnote:
7338 </p>
7339 <p>
7340 [In a locale in which comma is being used as a decimal point character,
7341 inserting "showbase" into the output stream forces all outputs to show
7342 an explicit decimal point character; then all inserted complex sequences
7343 will extract unambiguously.]
7344 </p>
7345 <p>
7346 And move this to READY status.
7347 </p>
7348 </blockquote>
7349
7350
7351 <p><b>Proposed resolution:</b></p>
7352 <p>
7353 Add a footnote to 26.3.6 [complex.ops] p16:
7354 </p>
7355
7356 <blockquote>
7357 [In a locale in which comma is being used as a decimal point character,
7358 inserting "showbase" into the output stream forces all outputs to show
7359 an explicit decimal point character; then all inserted complex sequences
7360 will extract unambiguously.]
7361 </blockquote>
7362
7363
7364
7365
7366
7367 <hr>
7368 <h3><a name="630"></a>630. arrays of valarray</h3>
7369 <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>
7370  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-28</p>
7371 <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>
7372 <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>
7373 <p><b>Discussion:</b></p>
7374         <p>
7375
7376 Section 26.1 [numeric.requirements], p1     suggests     that     a
7377 <code>valarray</code>  specialization on  a  type <code>T</code>  that
7378 satisfies  the requirements enumerated  in the  paragraph is  itself a
7379 valid  type   on  which  <code>valarray</code>   may  be  instantiated
7380 (Footnote       269        makes       this       clear).        I.e.,
7381 <code>valarray&lt;valarray&lt;T&gt;  &gt;</code> is  valid as  long as
7382 <code>T</code>   is   valid.    However,  since   implementations   of
7383 <code>valarray</code> are permitted to initialize storage allocated by
7384 the class by  invoking the default ctor of  <code>T</code> followed by
7385 the    copy    assignment    operator,   such    implementations    of
7386 <code>valarray</code>   wouldn't  work  with   (perhaps  user-defined)
7387 specializations of <code>valarray</code> whose assignment operator had
7388 undefined behavior when the size of its argument didn't match the size
7389 of <code>*this</code>.  By <i>"wouldn't work"</i> I mean that it would
7390 be  impossible  to resize  such  an array  of  arrays  by calling  the
7391 <code>resize()</code> member  function on it if the  function used the
7392 copy  assignment operator  after constructing  all elements  using the
7393 default  ctor (e.g.,  by invoking  <code>new  value_type[N]</code>) to
7394 obtain default-initialized storage) as it's permitted to do.
7395
7396         </p>
7397         <p>
7398
7399 Stated      more     generally,      the      problem     is      that
7400 <code>valarray&lt;valarray&lt;T&gt;  &gt;::resize(size_t)</code> isn't
7401 required or  guaranteed to have well-defined semantics  for every type
7402 <code>T</code>     that      satisfies     all     requirements     in
7403 26.1 [numeric.requirements].
7404
7405         </p>
7406         <p>
7407
7408 I  believe  this  problem  was  introduced  by  the  adoption  of  the
7409 resolution                outlined                in                <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0857.asc">N0857</a>,
7410 <i>Assignment  of  valarrays</i>,  from  1996.   The  copy  assignment
7411 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>,
7412 as      well       as      the      one       proposed      in      <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0308.asc">N0308</a>
7413 (both  from 1993), had  well-defined semantics  for arrays  of unequal
7414 size (the  latter explicitly  only when <code>*this</code>  was empty;
7415 assignment of non empty arrays of unequal size was a runtime error).
7416
7417         </p>
7418         <p>
7419
7420 The  justification for  the  change given  in  N0857 was the "loss  of
7421 performance [deemed]  only significant  for very simple  operations on
7422 small arrays or for architectures with very few registers."
7423
7424         </p>
7425         <p>
7426
7427 Since tiny  arrays on a  limited subset of hardware  architectures are
7428 likely  to  be  an   exceedingly  rare  case  (despite  the  continued
7429 popularity of  x86) I  propose to revert  the resolution and  make the
7430 behavior    of   all   <code>valarray</code>    assignment   operators
7431 well-defined even  for non-conformal  arrays (i.e., arrays  of unequal
7432 size).   I have implemented  this change  and measured  no significant
7433 degradation  in performance in  the common  case (non-empty  arrays of
7434 equal size).  I  have measured a 50% (and in  some cases even greater)
7435 speedup  in the  case of  assignments to  empty arrays  versus calling
7436 <code>resize()</code>  first followed  by  an invocation  of the  copy
7437 assignment operator.
7438
7439         </p>
7440
7441 <p><i>[
7442 Bellevue:
7443 ]</i></p>
7444
7445
7446 <blockquote>
7447 If no proposed wording by June meeting, this issue should be closed NAD.
7448 </blockquote>
7449
7450
7451
7452 <p><b>Proposed resolution:</b></p>
7453         <p>
7454
7455 Change 26.5.2.2 [valarray.assign], p1 as follows:
7456
7457         </p>
7458         <blockquote>
7459             <p>
7460                 <code>
7461
7462 valarray&lt;T&gt;&amp; operator=(const valarray&lt;T&gt;&amp;<ins> x</ins>);
7463
7464                 </code>
7465             </p>
7466             <p>
7467
7468 -1- Each element of the <code>*this</code> array is assigned the value
7469 of  the  corresponding  element   of  the  argument  array.   <del>The
7470 resulting behavior is undefined if </del><ins>When </ins>the length of
7471 the  argument  array  is  not   equal  to  the  length  of  the  *this
7472 array<del>.</del><ins>  resizes  <code>*this</code>  to make  the  two
7473 arrays     the      same     length,     as      if     by     calling
7474 <code>resize(x.size())</code>, before performing the assignment.</ins>
7475
7476             </p>
7477         </blockquote>
7478         <p>
7479
7480 And  add a new  paragraph just  below paragraph  1 with  the following
7481 text:
7482
7483         </p>
7484         <blockquote>
7485             <p>
7486
7487 <ins>-2- <i>Postcondition</i>: <code>size() == x.size()</code>.</ins>
7488
7489             </p>
7490         </blockquote>
7491         <p>
7492
7493 Also add the following paragraph to 26.5.2.2 [valarray.assign], immediately after p4:
7494
7495         </p>
7496         <blockquote>
7497             <p>
7498
7499 <ins>-?- When the length,  <i><code>N</code></i> of the array referred
7500 to by the  argument is not equal to  the length of <code>*this</code>,
7501 the  operator resizes <code>*this</code>  to make  the two  arrays the
7502 same  length, as if  by calling  <code>resize(<i>N</i>)</code>, before
7503 performing the assignment.</ins>
7504
7505             </p>
7506         </blockquote>
7507
7508
7509 <p><i>[
7510 Kona (2007): Gaby to propose wording for an alternative resolution in
7511 which you can assign to a <tt>valarray</tt> of size 0, but not to any other
7512 <tt>valarray</tt> whose size is unequal to the right hand side of the assignment.
7513 ]</i></p>
7514
7515
7516
7517
7518
7519 <hr>
7520 <h3><a name="631"></a>631. conflicting requirements for <tt>BinaryPredicate</tt></h3>
7521 <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>
7522  <b>Submitter:</b> James Kanze <b>Date:</b> 2007-01-31</p>
7523 <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>
7524 <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>
7525 <p><b>Discussion:</b></p>
7526 <p>
7527 The general requirements for <tt><tt>BinaryPredicate</tt></tt> (in 25 [algorithms]/8) contradict the implied specific requirements for
7528 some functions. In particular, it says that:
7529 </p>
7530
7531 <blockquote><p>
7532 [...] if an algorithm takes <tt>BinaryPredicate <i>binary_pred</i></tt>
7533 as its argument and <tt><i>first1</i></tt> and <i>first2</i> as its
7534 iterator arguments, it should work correctly in the construct <tt>if
7535 (binary_pred (*<i>first1</i> , *<i>first2</i> )){...}</tt>.
7536 <tt>BinaryPredicate</tt> always takes the first iterator type as its
7537 first argument, that is, in those cases when <tt>T <i>value</i></tt> is
7538 part of the signature, it should work correctly in the context of <tt>if
7539 (binary_pred (*<i>first1</i> , <i>value</i>)){...}</tt>.
7540 </p></blockquote>
7541
7542 <p>
7543 In the description of <tt>upper_bound</tt> (25.3.3.2 [upper.bound]/2), however, the use is described as
7544 "<tt>!comp(<i>value</i>, <i>e</i>)</tt>", where <tt><i>e</i></tt> is an
7545 element of the sequence (a result of dereferencing
7546 <tt>*<i>first</i></tt>).
7547 </p>
7548
7549 <p>
7550 In the description of <tt>lexicographical_compare</tt>, we have both
7551 "<tt>*<i>first1</i> &lt; *<i>first2</i></tt>" and "<tt>*<i>first2</i>
7552 &lt; *<i>first1</i></tt>" (which presumably implies "<tt>comp(
7553 *<i>first1</i>, *<i>first2</i> )</tt>" and "<tt>comp( *<i>first2</i>,
7554 *<i>first1</i> )</tt>".
7555 </p>
7556
7557 <p><i>[
7558 Toronto:  Moved to Open.  ConceptGCC seems to get <tt>lower_bound</tt>
7559 and <tt>upper_bound</tt> to work withoutt these changes.
7560 ]</i></p>
7561
7562
7563
7564
7565 <p><b>Proposed resolution:</b></p>
7566 <p>
7567 Logically, the <tt>BinaryPredicate</tt> is used as an ordering
7568 relationship, with the semantics of "less than".  Depending on the
7569 function, it may be used to determine equality, or any of the inequality
7570 relationships; doing this requires being able to use it with either
7571 parameter first.  I would thus suggest that the requirement be:
7572 </p>
7573
7574 <blockquote><p>
7575 [...] <tt>BinaryPredicate</tt> always takes the first iterator
7576 <tt>value_type</tt> as one of its arguments, it is unspecified which. If
7577 an algorithm takes <tt>BinaryPredicate <i>binary_pred</i></tt> as its
7578 argument and <tt><i><i>first1</i></i></tt> and <i>first2</i> as its
7579 iterator arguments, it should work correctly both in the construct
7580 <tt>if (binary_pred (*<i>first1</i> , *<i>first2</i> )){...}</tt> and
7581 <tt>if (binary_pred (*<i>first2</i>, *<i>first1</i>)){...}</tt>.  In
7582 those cases when <tt>T <i>value</i></tt> is part of the signature, it
7583 should work correctly in the context of <tt>if (binary_pred
7584 (*<i>first1</i> , <i>value</i>)){...}</tt> and of <tt>if (binary_pred
7585 (<i>value</i>, *<i>first1</i>)){...}</tt>. [<i>Note:</i> if the two
7586 types are not identical, and neither is convertable to the other, this
7587 may require that the <tt>BinaryPredicate</tt> be a functional object
7588 with two overloaded <tt>operator()()</tt> functions. <i>--end note</i>]
7589 </p></blockquote>
7590
7591 <p>
7592 Alternatively, one could specify an order for each function. IMHO, this
7593 would be more work for the committee, more work for the implementors,
7594 and of no real advantage for the user: some functions, such as
7595 <tt>lexicographical_compare</tt> or <tt>equal_range</tt>, will still require both
7596 functions, and it seems like a much easier rule to teach that both
7597 functions are always required, rather than to have a complicated list of
7598 when you only need one, and which one.
7599 </p>
7600
7601
7602
7603
7604
7605 <hr>
7606 <h3><a name="632"></a>632. Time complexity of size() for std::set</h3>
7607 <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>
7608  <b>Submitter:</b> Lionel B <b>Date:</b> 2007-02-01</p>
7609 <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>
7610 <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>
7611 <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>
7612 <p><b>Discussion:</b></p>
7613 <p>
7614 A recent news group discussion:
7615 </p>
7616 <blockquote>
7617 <p>
7618 Anyone know if the Standard has anything to say about the time complexity
7619 of size() for std::set?   I need to access a set's size (/not/ to know if it is empty!) heavily
7620 during an algorithm and was thus wondering whether I'd be better off
7621 tracking the size "manually" or whether that'd be pointless.
7622 </p>
7623 <p>
7624 That would be pointless. size() is O(1).
7625 </p>
7626 <p>
7627 Nit: the standard says "should" have constant time. Implementations may take
7628 license to do worse. I know that some do this for <tt>std::list&lt;&gt;</tt> as a part of
7629 some trade-off with other operation.
7630 </p>
7631
7632 <p>
7633 I was aware of that, hence my reluctance to use size() for std::set.
7634 </p>
7635 <p>
7636 However, this reason would not apply to <tt>std::set&lt;&gt;</tt> as far as I can see.
7637 </p>
7638 <p>
7639 Ok, I guess the only option is to try it and see...
7640 </p>
7641 </blockquote>
7642
7643 <p>
7644 If I have any recommendation to the C++ Standards Committee it is that
7645 implementations must (not "should"!) document clearly[1], where known, the
7646 time complexity of *all* container access operations.
7647 </p>
7648 <p>
7649 [1] In my case (gcc 4.1.1) I can't swear that the time complexity of size()
7650 for std::set is not documented... but if it is it's certainly well hidden
7651 away.
7652 </p>
7653
7654
7655
7656 <p><b>Proposed resolution:</b></p>
7657 <p>
7658 </p>
7659
7660
7661 <p><i>[
7662 Kona (2007): This issue affects all the containers. We'd love to see a
7663 paper dealing with the broad issue. We think that the complexity of the
7664 <tt>size()</tt> member of every container -- except possibly <tt>list</tt> -- should be
7665 O(1). Alan has volunteered to provide wording.
7666 ]</i></p>
7667
7668
7669 <p><i>[
7670 Bellevue:
7671 ]</i></p>
7672
7673
7674 <blockquote>
7675 Mandating O(1) size will not fly, too many implementations would be
7676 invalidated. Alan to provide wording that toughens wording, but that
7677 does not absolutely mandate O(1).
7678 </blockquote>
7679
7680
7681
7682
7683 <hr>
7684 <h3><a name="635"></a>635. domain of <tt>allocator::address</tt></h3>
7685 <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>
7686  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-02-08</p>
7687 <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>
7688 <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>
7689 <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>
7690 <p><b>Discussion:</b></p>
7691 <p>
7692 The table of allocator requirements in 20.1.2 [allocator.requirements] describes
7693 <tt>allocator::address</tt> as:
7694 </p>
7695 <blockquote><pre>a.address(r)
7696 a.address(s)
7697 </pre></blockquote>
7698 <p>
7699 where <tt>r</tt> and <tt>s</tt> are described as:
7700 </p>
7701 <blockquote><p>
7702 a value of type <tt>X::reference</tt> obtained by the expression <tt>*p</tt>.
7703 </p></blockquote>
7704
7705 <p>
7706 and <tt>p</tt> is
7707 </p>
7708
7709 <blockquote><p>
7710 a value of type <tt>X::pointer</tt>, obtained by calling <tt>a1.allocate</tt>,
7711 where <tt>a1 == a</tt>
7712 </p></blockquote>
7713
7714 <p>
7715 This all implies that to get the address of some value of type <tt>T</tt> that
7716 value must have been allocated by this allocator or a copy of it.
7717 </p>
7718
7719 <p>
7720 However sometimes container code needs to compare the address of an external value of
7721 type <tt>T</tt> with an internal value.  For example <tt>list::remove(const T&amp; t)</tt>
7722 may want to compare the address of the external value <tt>t</tt> with that of a value
7723 stored within the list.  Similarly <tt>vector</tt> or <tt>deque insert</tt> may
7724 want to make similar comparisons (to check for self-referencing calls).
7725 </p>
7726
7727 <p>
7728 Mandating that <tt>allocator::address</tt> can only be called for values which the
7729 allocator allocated seems overly restrictive.
7730 </p>
7731
7732
7733
7734 <p><b>Proposed resolution:</b></p>
7735 <p>
7736 Change 20.1.2 [allocator.requirements]:
7737 </p>
7738
7739 <blockquote>
7740 <p>
7741 <tt>r</tt> : a value of type <tt>X::reference</tt> <del>obtained by the expression *p</del>.
7742 </p>
7743 <p>
7744 <tt>s</tt> : a value of type <tt>X::const_reference</tt> <del>obtained by the
7745 expression <tt>*q</tt> or by conversion from a value <tt>r</tt></del>.
7746 </p>
7747 </blockquote>
7748
7749 <p><i>[
7750 post Oxford:  This would be rendered NAD Editorial by acceptance of
7751 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
7752 ]</i></p>
7753
7754
7755 <p><i>[
7756 Kona (2007):  This issue is section 8 of N2387.  There was some discussion of it but
7757 no resolution to this issue was recorded.  Moved to Open.
7758 ]</i></p>
7759
7760
7761
7762
7763
7764
7765
7766 <hr>
7767 <h3><a name="638"></a>638. deque end invalidation during erase</h3>
7768 <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#Ready">Ready</a>
7769  <b>Submitter:</b> Steve LoBasso <b>Date:</b> 2007-02-17</p>
7770 <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>
7771 <p><b>Discussion:</b></p>
7772 <p>
7773 The standard states at 23.2.2.3 [deque.modifiers]/4:
7774 </p>
7775 <blockquote><pre>deque erase(...)
7776 </pre>
7777  <p>
7778 <i>Effects:</i> ... An erase at either end of the deque invalidates only
7779 the iterators and the references to the erased elements.
7780 </p>
7781 </blockquote>
7782 <p>
7783 This does not state that iterators to end will be invalidated.
7784 It needs to be amended in such a way as to account for end invalidation.
7785 </p>
7786 <p>
7787 Something like:
7788 </p>
7789 <blockquote><p>
7790 Any time the last element is erased, iterators to end are invalidated.
7791 </p></blockquote>
7792
7793 <p>
7794 This would handle situations like:
7795 </p>
7796 <blockquote><pre>erase(begin(), end())
7797 erase(end() - 1)
7798 pop_back()
7799 resize(n, ...) where n &lt; size()
7800 pop_front() with size() == 1
7801
7802 </pre></blockquote>
7803
7804 <p><i>[
7805 Post Kona, Steve LoBasso notes:
7806 ]</i></p>
7807
7808
7809 <blockquote>
7810 My only issue with the proposed resolution is that it might not be clear
7811 that <tt>pop_front()</tt> [where <tt>size() == 1</tt>] can invalidate past-the-end
7812 iterators.
7813 </blockquote>
7814
7815
7816
7817 <p><b>Proposed resolution:</b></p>
7818 <p>
7819 Change 23.2.2.3 [deque.modifiers], p4:
7820 </p>
7821
7822 <blockquote>
7823 <pre>iterator erase(const_iterator position);
7824 iterator erase(const_iterator first, const_iterator last);
7825 </pre>
7826
7827 <blockquote>
7828 <p>
7829 -4- <i>Effects:</i> An erase in the middle of the <tt>deque</tt>
7830 invalidates all the iterators and references to elements of the
7831 <tt>deque</tt> <ins>and the past-the-end iterator</ins>. An erase at
7832 either end of the <tt>deque</tt> invalidates only the iterators and the
7833 references to the erased elements<ins>, except that erasing at the end
7834 also invalidates the past-the-end iterator</ins>.
7835 </p>
7836 </blockquote>
7837 </blockquote>
7838
7839
7840
7841 <p><i>[
7842 Kona (2007): Proposed wording added and moved to Review.
7843 ]</i></p>
7844
7845
7846 <p><i>[
7847 Bellevue:
7848 ]</i></p>
7849
7850
7851 <blockquote>
7852 Note that there is existing code that relies on iterators not being
7853 invalidated, but there are also existing implementations that do
7854 invalidate iterators. Thus, such code is not portable in any case. There
7855 is a pop_front() note, which should possibly be a separate issue. Mike
7856 Spertus to evaluate and, if need be, file an issue.
7857 </blockquote>
7858
7859
7860
7861
7862 <hr>
7863 <h3><a name="659"></a>659. istreambuf_iterator should have an operator-&gt;()</h3>
7864 <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>
7865  <b>Submitter:</b> Niels Dekker <b>Date:</b> 2007-03-25</p>
7866 <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>
7867 <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>
7868 <p><b>Discussion:</b></p>
7869 <p>
7870 Greg Herlihy has clearly demonstrated that a user defined input
7871 iterator should have an operator-&gt;(), even if its
7872 value type is a built-in type (comp.std.c++, "Re: Should any iterator
7873 have an operator-&gt;() in C++0x?", March 2007).  And as Howard
7874 Hinnant remarked in the same thread that the input iterator
7875 <tt>istreambuf_iterator</tt> doesn't have one, this must be a
7876 defect!
7877 </p>
7878 <p>
7879 Based on Greg's example, the following code demonstrates the issue:
7880 </p><pre> #include &lt;iostream&gt;
7881  #include &lt;fstream&gt;
7882  #include &lt;streambuf&gt;
7883
7884  typedef char C;
7885  int main ()
7886  {
7887    std::ifstream s("filename", std::ios::in);
7888    std::istreambuf_iterator&lt;char&gt; i(s);
7889
7890    (*i).~C();  // This is well-formed...
7891    i-&gt;~C();  // ... so this should be supported!
7892  }
7893 </pre>
7894
7895 <p>
7896 Of course, operator-&gt; is also needed when the value_type of
7897 istreambuf_iterator is a class.
7898 </p>
7899 <p>
7900 The operator-&gt; could be implemented in various ways.  For instance,
7901 by storing the current value inside the iterator, and returning its
7902 address.  Or by returning a proxy, like operator_arrow_proxy, from
7903 <a href="http://www.boost.org/boost/iterator/iterator_facade.hpp">http://www.boost.org/boost/iterator/iterator_facade.hpp</a>
7904 </p>
7905 <p>
7906 I hope that the resolution of this issue will contribute to getting a
7907 clear and consistent definition of iterator concepts.
7908 </p>
7909
7910
7911 <p><b>Proposed resolution:</b></p>
7912 <p>
7913 Add to the synopsis in 24.5.3 [istreambuf.iterator]:
7914 </p>
7915
7916 <blockquote><pre>charT operator*() const;
7917 <ins>pointer operator-&gt;() const;</ins>
7918 istreambuf_iterator&lt;charT,traits&gt;&amp; operator++();
7919 </pre></blockquote>
7920
7921 <p>
7922 Change 24.5.3 [istreambuf.iterator], p1:
7923 </p>
7924
7925 <blockquote><p>
7926 The class template <tt>istreambuf_iterator</tt> reads successive
7927 characters from the <tt>streambuf</tt> for which it was constructed.
7928 <tt>operator*</tt> provides access to the current input character, if
7929 any. <ins><tt>operator-&gt;</tt> may return a proxy.</ins> Each time
7930 <tt>operator++</tt> is evaluated, the iterator advances to the next
7931 input character. If the end of stream is reached
7932 (<tt>streambuf_type::sgetc()</tt> returns <tt>traits::eof()</tt>), the
7933 iterator becomes equal to the end of stream iterator value. The default
7934 constructor <tt>istreambuf_iterator()</tt> and the constructor
7935 <tt>istreambuf_iterator(0)</tt> both construct an end of stream iterator
7936 object suitable for use as an end-of-range.
7937 </p></blockquote>
7938
7939
7940
7941 <p><i>[
7942 Kona (2007): The proposed resolution is inconsistent because the return
7943 type of <tt>istreambuf_iterator::operator-&gt;()</tt> is specified to be <tt>pointer</tt>,
7944 but the proposed text also states that "<tt>operator-&gt;</tt> may return a proxy."
7945 ]</i></p>
7946
7947
7948 <p><i>[
7949 Niels Dekker (mailed to Howard Hinnant):
7950 ]</i></p>
7951
7952 <blockquote>
7953 <p>
7954 The proposed resolution does
7955 not seem inconsistent to me. <tt>istreambuf_iterator::operator-&gt;()</tt> should
7956 have <tt>istreambuf_iterator::pointer</tt> as return type, and this return type
7957 may in fact be a proxy.
7958 </p>
7959 <p>
7960 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>
7961 unspecified for some iterator categories") implies that for any iterator
7962 class <tt>Iter</tt>, the return type of <tt>operator-&gt;()</tt> is <tt>Iter::pointer</tt>, by
7963 definition.  I don't think <tt>Iter::pointer</tt> needs to be a raw pointer.
7964 </p>
7965 <p>
7966 Still I wouldn't mind if the text "<tt>operator-&gt;</tt> may return a proxy" would
7967 be removed from the resolution. I think it's up to the library
7968 implementation, how to implement <tt>istreambuf_iterator::operator-&gt;()</tt>.  As
7969 longs as it behaves as expected: <tt>i-&gt;m</tt> should have the same effect as
7970 <tt>(*i).m</tt>. Even for an explicit destructor call, <tt>i-&gt;~C()</tt>.  The main issue
7971 is just: <tt>istreambuf_iterator</tt> should have an <tt>operator-&gt;()</tt>!
7972 </p>
7973 </blockquote>
7974
7975
7976
7977
7978 <hr>
7979 <h3><a name="667"></a>667. <tt>money_get</tt>'s widened minus sign</h3>
7980 <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>
7981  <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
7982 <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>
7983 <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>
7984 <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>
7985 <p><b>Discussion:</b></p>
7986 <p>
7987 22.2.6.1.2 [locale.money.get.virtuals], para 1 says:
7988 </p>
7989
7990 <blockquote><p>
7991 The result is returned as an integral value
7992 stored in <tt>units</tt> or as a sequence of digits possibly preceded by a
7993 minus sign (as produced by <tt>ct.widen(c)</tt> where <tt>c</tt> is '-' or in the range
7994 from '0' through '9', inclusive) stored in <tt>digits</tt>.
7995 </p></blockquote>
7996
7997 <p>
7998 The following
7999 objection has been raised:
8000 </p>
8001
8002 <blockquote><p>
8003 Some implementations interpret this to mean that a facet derived from
8004 <tt>ctype&lt;wchar_t&gt;</tt> can provide its own member <tt>do_widen(char)</tt>
8005 which produces e.g. <tt>L'@'</tt> for the "widened" minus sign, and that the
8006 <tt>'@'</tt> symbol will appear in the resulting sequence of digits.  Other
8007 implementations have assumed that one or more places in the standard permit the
8008 implementation to "hard-wire" <tt>L'-'</tt> as the "widened" minus sign.  Are
8009 both interpretations permissible, or only  one?
8010 </p></blockquote>
8011
8012 <p>
8013 [Plum ref _222612Y14]
8014 </p>
8015
8016 <p>
8017 Furthermore: if <tt>ct.widen('9')</tt> produces <tt>L'X'</tt> (a non-digit), does a
8018 parse fail if a <tt>'9'</tt> appears in the subject string? [Plum ref _22263Y33]
8019 </p>
8020
8021 <p><i>[
8022 Kona (2007): Bill and Dietmar to provide proposed wording.
8023 ]</i></p>
8024
8025
8026 <p><i>[
8027 post Bellevue: Bill adds:
8028 ]</i></p>
8029
8030
8031 <blockquote>
8032 The Standard is clear that the minus sign stored in <tt>digits</tt> is <tt>ct.widen('-')</tt>.
8033 The subject string must contain characters <tt>c</tt> in the set <tt>[-0123456789]</tt>
8034 which are translated by <tt>ct.widen(c)</tt> calls before being stored in <tt>digits</tt>;
8035 the widened characters are not relevant to the parsing of the subject string.
8036 </blockquote>
8037
8038
8039 <p><b>Proposed resolution:</b></p>
8040 <p>
8041 </p>
8042
8043
8044
8045
8046
8047 <hr>
8048 <h3><a name="668"></a>668. <tt>money_get</tt>'s empty minus sign</h3>
8049 <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>
8050  <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
8051 <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>
8052 <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>
8053 <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>
8054 <p><b>Discussion:</b></p>
8055 <p>
8056 22.2.6.1.2 [locale.money.get.virtuals], para 3 says:
8057 </p>
8058
8059 <blockquote><p>
8060 If <tt>pos</tt> or <tt>neg</tt> is empty, the sign component is
8061 optional, and if no sign is detected, the result is given the sign
8062 that corresponds to the source of the empty string.
8063 </p></blockquote>
8064
8065 <p>
8066 The following
8067 objection has been raised:
8068 </p>
8069
8070 <blockquote><p>
8071 A <tt>negative_sign</tt> of "" means "there is no
8072 way to write a negative sign" not "any null sequence is a negative
8073 sign, so it's always there when you look for it".
8074 </p></blockquote>
8075
8076 <p>
8077 [Plum ref _222612Y32]
8078 </p>
8079
8080 <p><i>[
8081 Kona (2007): Bill to provide proposed wording and interpretation of existing wording.
8082 ]</i></p>
8083
8084
8085
8086
8087 <p><b>Proposed resolution:</b></p>
8088 <p>
8089 </p>
8090
8091
8092
8093
8094
8095 <hr>
8096 <h3><a name="669"></a>669. Equivalent postive and negative signs in <tt>money_get</tt></h3>
8097 <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>
8098  <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
8099 <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>
8100 <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>
8101 <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>
8102 <p><b>Discussion:</b></p>
8103 <p>
8104 22.2.6.1.2 [locale.money.get.virtuals], para 3 sentence 4 says:
8105 </p>
8106
8107 <blockquote><p>
8108 If the first character of <tt>pos</tt> is equal to the first character of <tt>neg</tt>,
8109 or if both strings are empty, the result is given a positive sign.
8110 </p></blockquote>
8111
8112 <p>
8113 One interpretation is that an input sequence must match either the
8114 positive pattern or the negative pattern, and then in either event it
8115 is interpreted as positive.  The following objections has been raised:
8116 </p>
8117
8118 <blockquote><p>
8119 The input can successfully match only a positive sign, so the negative
8120 pattern is an unsuccessful match.
8121 </p></blockquote>
8122
8123 <p>
8124 [Plum ref _222612Y34, 222612Y51b]
8125 </p>
8126
8127 <p><i>[
8128 Bill to provide proposed wording and interpretation of existing wording.
8129 ]</i></p>
8130
8131
8132
8133
8134 <p><b>Proposed resolution:</b></p>
8135 <p>
8136 </p>
8137
8138
8139
8140
8141
8142 <hr>
8143 <h3><a name="670"></a>670. <tt>money_base::pattern</tt> and <tt>space</tt></h3>
8144 <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>
8145  <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
8146 <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>
8147 <p><b>Discussion:</b></p>
8148 <p>
8149 22.2.6.3 [locale.moneypunct], para 2 says:
8150 </p>
8151
8152 <blockquote><p>
8153 The value <tt>space</tt> indicates that at least one space is required at
8154 that position.
8155 </p></blockquote>
8156
8157 <p>
8158 The following objection has been raised:
8159 </p>
8160
8161 <blockquote><p>
8162 Whitespace is optional when matching space. (See 22.2.6.1.2 [locale.money.get.virtuals], para 2.)
8163 </p></blockquote>
8164
8165 <p>
8166 [Plum ref _22263Y22]
8167 </p>
8168
8169 <p><i>[
8170 Kona (2007): Bill to provide proposed wording. We agree that C++03 is
8171 ambiguous, and that we want C++0X to say "space" means 0 or more
8172 whitespace characters on input.
8173 ]</i></p>
8174
8175
8176
8177
8178 <p><b>Proposed resolution:</b></p>
8179 <p>
8180 </p>
8181
8182
8183
8184
8185
8186 <hr>
8187 <h3><a name="671"></a>671. precision of hexfloat</h3>
8188 <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>
8189  <b>Submitter:</b> John Salmon <b>Date:</b> 2007-04-20</p>
8190 <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>
8191 <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>
8192 <p><b>Discussion:</b></p>
8193 <p>
8194 I am trying to understand how TR1 supports hex float (%a) output.
8195 </p>
8196 <p>
8197 As far as I can tell, it does so via the following:
8198 </p>
8199 <p>
8200 8.15 Additions to header &lt;locale&gt; [tr.c99.locale]
8201 </p>
8202 <p>
8203 In subclause 22.2.2.2.2 [facet.num.put.virtuals], Table 58 Floating-point conversions, after
8204 the line:
8205 floatfield == ios_base::scientific %E
8206 </p>
8207 <p>
8208 add the two lines:
8209 </p>
8210 <blockquote><pre>floatfield == ios_base::fixed | ios_base::scientific &amp;&amp; !uppercase %a
8211 floatfield == ios_base::fixed | ios_base::scientific %A 2
8212 </pre></blockquote>
8213 <p>
8214 [Note: The additional requirements on print and scan functions, later
8215 in this clause, ensure that the print functions generate hexadecimal
8216 floating-point fields with a %a or %A conversion specifier, and that
8217 the scan functions match hexadecimal floating-point fields with a %g
8218 conversion specifier. &nbsp;end note]
8219 </p>
8220 <p>
8221 Following the thread, in 22.2.2.2.2 [facet.num.put.virtuals], we find:
8222 </p>
8223 <p>
8224 For conversion from a floating-point type, if (flags &amp; fixed) != 0 or
8225 if str.precision() &gt; 0, then str.precision() is specified in the
8226 conversion specification.
8227 </p>
8228 <p>
8229 This would seem to imply that when floatfield == fixed|scientific, the
8230 precision of the conversion specifier is to be taken from
8231 str.precision(). &nbsp;Is this really what's intended? &nbsp;I sincerely hope
8232 that I'm either missing something or this is an oversight. &nbsp;Please
8233 tell me that the committee did not intend to mandate that hex floats
8234 (and doubles) should by default be printed as if by %.6a.
8235 </p>
8236
8237 <p><i>[
8238 Howard: I think the fundamental issue we overlooked was that with %f,
8239 %e, %g, the default precision was always 6. &nbsp;With %a the default
8240 precision is not 6, it is infinity. &nbsp;So for the first time, we need to
8241 distinguish between the default value of precision, and the precision
8242 value 6.
8243 ]</i></p>
8244
8245
8246
8247
8248 <p><b>Proposed resolution:</b></p>
8249 <p>
8250 </p>
8251
8252
8253 <p><i>[
8254 Kona (2007): Robert volunteers to propose wording.
8255 ]</i></p>
8256
8257
8258
8259
8260
8261 <hr>
8262 <h3><a name="672"></a>672. Swappable requirements need updating</h3>
8263 <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#Ready">Ready</a>
8264  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-04</p>
8265 <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>
8266 <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>
8267 <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>
8268 <p><b>Discussion:</b></p>
8269 <p>
8270 The current <tt>Swappable</tt> is:
8271 </p>
8272
8273 <blockquote>
8274 <table border="1">
8275 <caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
8276 <tbody><tr><th>expression</th><th>return type</th><th>post-condition</th></tr>
8277 <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
8278 held by <tt>t</tt></td></tr>
8279 <tr><td colspan="3">
8280 <p>
8281 The Swappable requirement is met by satisfying one or more of the following conditions:
8282 </p>
8283 <ul>
8284 <li>
8285 <tt>T</tt> is Swappable if <tt>T</tt> satisfies the <tt>CopyConstructible</tt> requirements (Table 34)
8286 and the <tt>CopyAssignable</tt> requirements (Table 36);
8287 </li>
8288 <li>
8289 <tt>T</tt> is Swappable if a namespace scope function named <tt>swap</tt> exists in the same
8290 namespace as the definition of <tt>T</tt>, such that the expression <tt>swap(t,u)</tt> is valid
8291 and has the semantics described in this table.
8292 </li>
8293 </ul>
8294 </td></tr>
8295 </tbody></table>
8296 </blockquote>
8297
8298 <p>
8299 With the passage of rvalue reference into the language, <tt>Swappable</tt> needs to be updated to
8300 require only <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.  This is a minimum.
8301 </p>
8302
8303 <p>
8304 Additionally we may want to support proxy references such that the following code is acceptable:
8305 </p>
8306
8307 <blockquote><pre>namespace Mine {
8308
8309 template &lt;class T&gt;
8310 struct proxy {...};
8311
8312 template &lt;class T&gt;
8313 struct proxied_iterator
8314 {
8315    typedef T value_type;
8316    typedef proxy&lt;T&gt; reference;
8317    reference operator*() const;
8318    ...
8319 };
8320
8321 struct A
8322 {
8323    // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
8324    void swap(A&amp;);
8325    ...
8326 };
8327
8328 void swap(A&amp;, A&amp;);
8329 void swap(proxy&lt;A&gt;, A&amp;);
8330 void swap(A&amp;, proxy&lt;A&gt;);
8331 void swap(proxy&lt;A&gt;, proxy&lt;A&gt;);
8332
8333 }  // Mine
8334
8335 ...
8336
8337 Mine::proxied_iterator&lt;Mine::A&gt; i(...)
8338 Mine::A a;
8339 swap(*i1, a);
8340 </pre></blockquote>
8341
8342 <p>
8343 I.e. here is a call to <tt>swap</tt> which the user enables swapping between a proxy to a class and the class
8344 itself.  We do not need to anything in terms of implementation except not block their way with overly
8345 constrained concepts.  That is, the <tt>Swappable</tt> concept should be expanded to allow swapping
8346 between two different types for the case that one is binding to a user-defined <tt>swap</tt>.
8347 </p>
8348
8349
8350
8351 <p><b>Proposed resolution:</b></p>
8352
8353 <p>
8354 Change 20.1.1 [utility.arg.requirements]:
8355 </p>
8356
8357 <blockquote>
8358
8359 <p>
8360 -1- The template definitions in the C++ Standard Library refer to various
8361 named requirements whose details are set out in tables 31-38. In these
8362 tables, <tt>T</tt> is a type to be supplied by a C++ program
8363 instantiating a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
8364 values of type <tt>const T</tt>; <tt>s</tt> and <tt>t</tt> are modifiable
8365 lvalues of type <tt>T</tt>; <tt>u</tt> is a value of type (possibly
8366 <tt>const</tt>) <tt>T</tt>; and <tt>rv</tt> is a non-<tt>const</tt>
8367 rvalue of type <tt>T</tt>.
8368 </p>
8369
8370 <table border="1">
8371 <caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
8372 <tbody><tr><th>expression</th><th>return type</th><th>post-condition</th></tr>
8373 <tr><td><tt>swap(s,t)</tt></td><td><tt>void</tt></td>
8374 <td><tt>t</tt> has the value originally
8375 held by <tt>u</tt>, and
8376 <tt>u</tt> has the value originally held
8377 by <tt>t</tt></td></tr>
8378 <tr><td colspan="3">
8379 <p>
8380 The <tt>Swappable</tt> requirement is met by satisfying one or more of the following conditions:
8381 </p>
8382 <ul>
8383 <li>
8384 <tt>T</tt> is <tt>Swappable</tt> if <tt>T</tt> satisfies the
8385 <del><tt>CopyConstructible</tt></del> <ins>MoveConstructible</ins>
8386 requirements (Table <del>34</del> <ins>33</ins>) and the <del><tt>CopyAssignable</tt></del> <ins>MoveAssignable</ins>
8387 requirements (Table <del>36</del> <ins>35</ins>);
8388 </li>
8389 <li>
8390 <tt>T</tt> is <tt>Swappable</tt> if a namespace scope function named
8391 <tt>swap</tt> exists in the same namespace as the definition of
8392 <tt>T</tt>, such that the expression
8393 <tt>swap(t,u)</tt> is valid and has the
8394 semantics described in this table.
8395 </li>
8396 </ul>
8397 </td></tr>
8398 </tbody></table>
8399 </blockquote>
8400
8401
8402
8403 <p><i>[
8404 Kona (2007): We like the change to the <tt>Swappable</tt> requirements to use
8405 move semantics. The issue relating to the support of proxies is
8406 separable from the one relating to move semantics, and it's bigger than
8407 just swap. We'd like to address only the move semantics changes under
8408 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
8409 may be a third issue, in that the current definition of <tt>Swappable</tt> does
8410 not permit rvalues to be operands to a swap operation, and Howard's
8411 proposed resolution would allow the right-most operand to be an rvalue,
8412 but it would not allow the left-most operand to be an rvalue (some swap
8413 functions in the library have been overloaded to permit left operands to
8414 swap to be rvalues).
8415 ]</i></p>
8416
8417
8418
8419
8420
8421 <hr>
8422 <h3><a name="673"></a>673. <tt>unique_ptr</tt> update</h3>
8423 <p><b>Section:</b> 20.6.11 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
8424  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-04</p>
8425 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr">active issues</a> in [unique.ptr].</p>
8426 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr">issues</a> in [unique.ptr].</p>
8427 <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>
8428 <p><b>Discussion:</b></p>
8429 <p>
8430 Since the publication of
8431 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a>
8432 there have been a few small but significant advances which should be included into
8433 <tt>unique_ptr</tt>.  There exists a
8434 <a href="http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html">example implmenation</a>
8435 for all of these changes.
8436 </p>
8437
8438 <ul>
8439
8440 <li>
8441 <p>
8442 Even though <tt>unique_ptr&lt;void&gt;</tt> is not a valid use case (unlike for <tt>shared_ptr&lt;void&gt;</tt>),
8443 unexpected cases to crop up which require the instantiation of the interface of <tt>unique_ptr&lt;void&gt;</tt>
8444 even if it is never used.  For example see
8445 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">LWG 541</a> for how this accidently
8446 happened to <tt>auto_ptr</tt>.  I believe the most robust way to protect <tt>unique_ptr</tt> against this
8447 type of failure is to augment the return type of <tt>unique_ptr&lt;T&gt;:operator*()</tt> with
8448 <tt>add_lvalue_reference&lt;T&gt;::type</tt>.  This means that given an instantiated <tt>unique_ptr&lt;void&gt;</tt>
8449 the act of dereferencing it will simply return <tt>void</tt> instead of causing a compile time failure.
8450 This is simpler than creating a <tt>unique_ptr&lt;void&gt;</tt> specialization which isn't robust in the
8451 face of <tt><i>cv-</i></tt>qualified <tt>void</tt> types.
8452 </p>
8453
8454 <p>
8455 This resolution also supports instantiations such as <tt>unique_ptr&lt;void, free_deleter&gt;</tt>
8456 which could be very useful to the client.
8457 </p>
8458
8459 </li>
8460
8461 <li>
8462 <p>
8463 Efforts have been made to better support containers and smart pointers in shared
8464 memory contexts.  One of the key hurdles in such support is not assuming that a
8465 pointer type is actually a <tt>T*</tt>.  This can easily be accomplished
8466 for <tt>unique_ptr</tt> by having the deleter define the pointer type:
8467 <tt>D::pointer</tt>.  Furthermore this type can easily be defaulted to
8468 <tt>T*</tt> should the deleter <tt>D</tt> choose not to define a pointer
8469 type (example implementation
8470 <a href="http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html">here</a>).
8471 This change has no run time overhead.  It has no interface overhead on
8472 authors of custom delter types.  It simply allows (but not requires)
8473 authors of custom deleter types to define a smart pointer for the
8474 storage type of <tt>unique_ptr</tt> if they find such functionality
8475 useful.  <tt>std::default_delete</tt> is an example of a deleter which
8476 defaults <tt>pointer</tt> to <tt>T*</tt> by simply ignoring this issue
8477 and not including a <tt>pointer typedef</tt>.
8478 </p>
8479 </li>
8480
8481 <li>
8482 <p>
8483 When the deleter type is a function pointer then it is unsafe to construct
8484 a <tt>unique_ptr</tt> without specifying the function pointer in the constructor.
8485 This case is easy to check for with a <tt>static_assert</tt> assuring that the
8486 deleter is not a pointer type in those constructors which do not accept deleters.
8487 </p>
8488
8489 <blockquote><pre>unique_ptr&lt;A, void(*)(void*)&gt; p(new A);  // error, no function given to delete the pointer!
8490 </pre></blockquote>
8491
8492 </li>
8493
8494 </ul>
8495
8496 <p><i>[
8497 Kona (2007): We don't like the solution given to the first bullet in
8498 light of concepts. The second bullet solves the problem of supporting
8499 fancy pointers for one library component only. The full LWG needs to
8500 decide whether to solve the problem of supporting fancy pointers
8501 piecemeal, or whether a paper addressing the whole library is needed. We
8502 think that the third bullet is correct.
8503 ]</i></p>
8504
8505
8506 <p><i>[
8507 Post Kona: Howard adds example user code related to the first bullet:
8508 ]</i></p>
8509
8510
8511 <blockquote>
8512 <pre>void legacy_code(void*, std::size_t);
8513
8514 void foo(std::size_t N)
8515 {
8516     std::unique_ptr&lt;void, void(*)(void*)&gt; ptr(std::malloc(N), std::free);
8517     legacy_code(ptr.get(), N);
8518 }   // unique_ptr used for exception safety purposes
8519 </pre>
8520 </blockquote>
8521
8522 <p>
8523 I.e. <tt>unique_ptr&lt;void&gt;</tt> <i>is</i> a useful tool that we don't want
8524 to disable with concepts.  The only part of <tt>unique_ptr&lt;void&gt;</tt> we
8525 want to disable (with concepts or by other means) are the two member functions:
8526 </p>
8527
8528 <blockquote><pre>T&amp; operator*() const;
8529 T* operator-&gt;() const;
8530 </pre></blockquote>
8531
8532
8533
8534 <p><b>Proposed resolution:</b></p>
8535
8536 <p><i>[
8537 I am grateful for the generous aid of Peter Dimov and Ion Gaztañaga in helping formulate and review
8538 the proposed resolutions below.
8539 ]</i></p>
8540
8541
8542 <ul>
8543 <li>
8544
8545 <p>
8546 Change 20.6.11.2 [unique.ptr.single]:
8547 </p>
8548
8549 <blockquote><pre>template &lt;class T, class D = default_delete&lt;T&gt;&gt; class unique_ptr {
8550    ...
8551    <del>T&amp;</del> <ins>typename add_lvalue_reference&lt;T&gt;::type</ins> operator*() const;
8552    ...
8553 };
8554 </pre></blockquote>
8555
8556 <p>
8557 Change 20.6.11.2.4 [unique.ptr.single.observers]:
8558 </p>
8559
8560 <blockquote><pre><del>T&amp;</del> <ins>typename add_lvalue_reference&lt;T&gt;::type</ins> operator*() const;
8561 </pre></blockquote>
8562
8563 </li>
8564
8565 <li>
8566 <p>
8567 Change 20.6.11.2 [unique.ptr.single]:
8568 </p>
8569
8570 <blockquote><pre>template &lt;class T, class D = default_delete&lt;T&gt;&gt; class unique_ptr {
8571 public:
8572   <ins>typedef <i>implementation (see description below)</i> pointer;</ins>
8573    ...
8574    explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p);
8575    ...
8576    unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined (see description below)</i> d);
8577    unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined (see description below)</i> d);
8578    ...
8579    <del>T*</del> <ins>pointer</ins> operator-&gt;() const;
8580    <del>T*</del> <ins>pointer</ins> get() const;
8581    ...
8582    <del>T*</del> <ins>pointer</ins> release();
8583    void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
8584 };
8585 </pre></blockquote>
8586
8587 <p>
8588 <ins>
8589 -3- If the type <tt>remove_reference&lt;D&gt;::type::pointer</tt>
8590 exists, then <tt>unique_ptr&lt;T, D&gt;::pointer</tt> is a typedef to
8591 <tt>remove_reference&lt;D&gt;::type::pointer</tt>.  Otherwise
8592 <tt>unique_ptr&lt;T, D&gt;::pointer</tt> is a typedef to <tt>T*</tt>.
8593 The type <tt>unique_ptr&lt;T, D&gt;::pointer</tt> shall be <tt>CopyConstructible</tt>
8594 and <tt>CopyAssignable</tt>.
8595 </ins>
8596 </p>
8597
8598 <p>
8599 Change 20.6.11.2.1 [unique.ptr.single.ctor]:
8600 </p>
8601
8602 <blockquote><pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);
8603 ...
8604 unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
8605 unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
8606 ...
8607 unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A&amp; d);
8608 unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&amp;&amp; d);
8609 ...
8610 unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&amp; d);
8611 unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&amp;&amp; d);
8612 ...
8613 unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A&amp; d);
8614 unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A&amp;&amp; d);
8615 ...
8616 </pre></blockquote>
8617
8618 <p>
8619 -23- <i>Requires:</i> If <tt>D</tt> is not a reference type,
8620 construction of the deleter <tt>D</tt> from an rvalue of type <tt>E</tt>
8621 <del>must</del> <ins>shall</ins> be well formed and not throw an exception. If <tt>D</tt> is a
8622 reference type, then <tt>E</tt> <del>must</del> <ins>shall</ins> be the same type as <tt>D</tt>
8623 (diagnostic required). <del><tt>U*</tt></del> <ins><tt>unique_ptr&lt;U,E&gt;::pointer</tt></ins>
8624 <del>must</del> <ins>shall</ins> be implicitly convertible to <del><tt>T*</tt></del>
8625 <ins>pointer</ins>.
8626 </p>
8627
8628 <p>
8629 -25- <i>Postconditions:</i> <tt>get() == value u.get()</tt> had before
8630 the construction, modulo any required offset adjustments resulting from
8631 the cast from <del><tt>U*</tt></del>
8632 <ins><tt>unique_ptr&lt;U,E&gt;::pointer</tt></ins> to <del><tt>T*</tt></del>
8633 <ins>pointer</ins>. <tt>get_deleter()</tt> returns a reference to the
8634 internally stored deleter which was constructed from
8635 <tt>u.get_deleter()</tt>.
8636 </p>
8637
8638 <p>
8639 Change 20.6.11.2.3 [unique.ptr.single.asgn]:
8640 </p>
8641
8642 <blockquote>
8643 <p>
8644 -8- <i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
8645 <tt>D</tt> <del>must</del> <ins>shall</ins> not throw an exception. <del><tt>U*</tt></del>
8646 <ins><tt>unique_ptr&lt;U,E&gt;::pointer</tt></ins> <del>must</del> <ins>shall</ins> be implicitly
8647 convertible to <del><tt>T*</tt></del> <ins>pointer</ins>.
8648 </p>
8649 </blockquote>
8650
8651 <p>
8652 Change 20.6.11.2.4 [unique.ptr.single.observers]:
8653 </p>
8654
8655 <blockquote>
8656 <pre><del>T*</del> <ins>pointer</ins> operator-&gt;() const;</pre>
8657 ...
8658 <pre><del>T*</del> <ins>pointer</ins> get() const;</pre>
8659 </blockquote>
8660
8661 <p>
8662 Change 20.6.11.2.5 [unique.ptr.single.modifiers]:
8663 </p>
8664
8665 <blockquote>
8666 <pre><del>T*</del> <ins>pointer</ins> release();</pre>
8667 ...
8668 <pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);</pre>
8669 </blockquote>
8670
8671 <p>
8672 Change 20.6.11.3 [unique.ptr.runtime]:
8673 </p>
8674
8675 <blockquote><pre>template &lt;class T, class D&gt; class unique_ptr&lt;T[], D&gt; {
8676 public:
8677   <ins>typedef <i>implementation</i> pointer;</ins>
8678    ...
8679    explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p);
8680    ...
8681    unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
8682    unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
8683    ...
8684    <del>T*</del> <ins>pointer</ins> get() const;
8685    ...
8686    <del>T*</del> <ins>pointer</ins> release();
8687    void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
8688 };
8689 </pre></blockquote>
8690
8691 <p>
8692 Change 20.6.11.3.1 [unique.ptr.runtime.ctor]:
8693 </p>
8694
8695 <blockquote>
8696 <pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);
8697 unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
8698 unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
8699 </pre>
8700
8701 <p>
8702 These constructors behave the same as in the primary template except
8703 that they do not accept pointer types which are convertible to
8704 <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins>. [<i>Note:</i> One
8705 implementation technique is to create private templated overloads of
8706 these members. <i>-- end note</i>]
8707 </p>
8708 </blockquote>
8709
8710 <p>
8711 Change 20.6.11.3.3 [unique.ptr.runtime.modifiers]:
8712 </p>
8713
8714 <blockquote>
8715 <pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
8716 </pre>
8717
8718 <p>
8719 -1- <i>Requires:</i> Does not accept pointer types which are convertible
8720 to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (diagnostic
8721 required). [<i>Note:</i> One implementation technique is to create a private
8722 templated overload. <i>-- end note</i>]
8723 </p>
8724 </blockquote>
8725
8726 </li>
8727
8728 <li>
8729
8730 <p>
8731 Change 20.6.11.2.1 [unique.ptr.single.ctor]:
8732 </p>
8733
8734 <blockquote>
8735 <pre>unique_ptr();</pre>
8736 <blockquote>
8737 <p>
8738 <i>Requires:</i> <tt>D</tt> <del>must</del> <ins>shall</ins> be default constructible, and that
8739 construction <del>must</del> <ins>shall</ins> not throw an exception. <tt>D</tt> <del>must</del> <ins>shall</ins> not be a
8740 reference type <ins>or pointer type (diagnostic required)</ins>.
8741 </p>
8742 </blockquote>
8743 <pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);</pre>
8744 <blockquote>
8745 <p>
8746 <i>Requires:</i>  The expression <tt>D()(p)</tt> <del>must</del> <ins>shall</ins> be well formed.
8747 The default constructor of <tt>D</tt> <del>must</del> <ins>shall</ins> not throw an exception.
8748 <tt>D</tt> <del>must</del> <ins>shall</ins> not be a reference type <ins>or pointer type (diagnostic
8749 required)</ins>.
8750 </p>
8751 </blockquote>
8752 </blockquote>
8753
8754 <p>
8755 Change 20.6.11.2.1 [unique.ptr.single.ctor]:
8756 </p>
8757
8758 <blockquote>
8759 <pre>unique_ptr();</pre>
8760 <blockquote>
8761 <p>
8762 <i>Requires:</i> <tt>D</tt> <del>must</del> <ins>shall</ins> be default constructible, and that
8763 construction <del>must</del> <ins>shall</ins> not throw an exception. <tt>D</tt> <del>must</del> <ins>shall</ins> not be a
8764 reference type <ins>or pointer type (diagnostic required)</ins>.
8765 </p>
8766 </blockquote>
8767 <pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);</pre>
8768 <blockquote>
8769 <p>
8770 <i>Requires:</i>  The expression <tt>D()(p)</tt> <del>must</del> <ins>shall</ins> be well formed.
8771 The default constructor of <tt>D</tt> <del>must</del> <ins>shall</ins> not throw an exception.
8772 <tt>D</tt> <del>must</del> <ins>shall</ins> not be a reference type <ins>or pointer type (diagnostic
8773 required)</ins>.
8774 </p>
8775 </blockquote>
8776 </blockquote>
8777
8778 </li>
8779
8780 </ul>
8781
8782
8783
8784
8785
8786
8787 <hr>
8788 <h3><a name="675"></a>675. Move assignment of containers</h3>
8789 <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>
8790  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-05</p>
8791 <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>
8792 <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>
8793 <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>
8794 <p><b>Discussion:</b></p>
8795 <p>
8796 James Hopkin pointed out to me that if <tt>vector&lt;T&gt;</tt> move assignment is O(1)
8797 (just a <tt>swap</tt>) then containers such as <tt>vector&lt;shared_ptr&lt;ostream&gt;&gt;</tt> might have
8798 the wrong semantics under move assignment when the source is not truly an rvalue, but a
8799 moved-from lvalue (destructors could run late).
8800 </p>
8801
8802 <blockquote><pre><tt>vector&lt;shared_ptr&lt;ostream&gt;&gt;</tt> v1;
8803 <tt>vector&lt;shared_ptr&lt;ostream&gt;&gt;</tt> v2;
8804 ...
8805 v1 = v2;               // #1
8806 v1 = std::move(v2);    // #2
8807 </pre></blockquote>
8808
8809 <p>
8810 Move semantics means not caring what happens to the source (<tt>v2</tt> in this example).
8811 It doesn't mean not caring what happens to the target (<tt>v1</tt>).  In the above example
8812 both assignments should have the same effect on <tt>v1</tt>.  Any non-shared <tt>ostream</tt>'s
8813 <tt>v1</tt> owns before the assignment should be closed, whether <tt>v1</tt> is undergoing
8814 copy assignment or move assignment.
8815 </p>
8816
8817 <p>
8818 This implies that the semantics of move assignment of a generic container should be
8819 <tt>clear, swap</tt> instead of just swap.  An alternative which could achieve the same
8820 effect would be to move assign each element.  In either case, the complexity of move
8821 assignment needs to be relaxed to <tt>O(v1.size())</tt>.
8822 </p>
8823
8824 <p>
8825 The performance hit of this change is not nearly as drastic as it sounds.
8826 In practice, the target of a move assignment has always just been move constructed
8827 or move assigned <i>from</i>.  Therefore under <tt>clear, swap</tt> semantics (in
8828 this common use case) we are still achieving O(1) complexity.
8829 </p>
8830
8831
8832
8833 <p><b>Proposed resolution:</b></p>
8834 <p>
8835 Change 23.1 [container.requirements]:
8836 </p>
8837
8838 <blockquote>
8839 <table border="1">
8840 <caption>Table 86: Container requirements</caption>
8841 <tbody><tr>
8842 <th>expression</th><th>return type</th><th>operational semantics</th>
8843 <th>assertion/note pre/post-condition</th><th>complexity</th>
8844 </tr>
8845 <tr>
8846 <td><tt>a = rv;</tt></td><td><tt>X&amp;</tt></td>
8847 <td><ins>All existing elements of <tt>a</tt> are either move assigned or destructed</ins></td>
8848 <td><tt>a</tt> shall be equal to the
8849 value that <tt>rv</tt> had
8850 before this construction
8851 </td>
8852 <td><del>constant</del> <ins>linear in <tt>a.size()</tt></ins></td>
8853 </tr>
8854 </tbody></table>
8855 </blockquote>
8856
8857
8858
8859 <p><i>[
8860 post Bellevute Howard adds:
8861 ]</i></p>
8862
8863
8864 <blockquote>
8865 <p>
8866 This issue was voted to WP in Bellevue, but accidently got stepped on by
8867 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>
8868 which was voted to WP simulataneously.  Moving back to Open for the purpose of getting
8869 the wording right.  The intent of this issue and N2525 are not in conflict.
8870 </p>
8871 </blockquote>
8872
8873
8874
8875
8876 <hr>
8877 <h3><a name="676"></a>676. Moving the unordered containers</h3>
8878 <p><b>Section:</b> 23.4 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
8879  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-05</p>
8880 <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>
8881 <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>
8882 <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>
8883 <p><b>Discussion:</b></p>
8884 <p>
8885 Move semantics are missing from the <tt>unordered</tt> containers.  The proposed
8886 resolution below adds move-support consistent with
8887 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1858.html">N1858</a>
8888 and the current working draft.
8889 </p>
8890
8891 <p>
8892 The current proposed resolution simply lists the requirements for each function.
8893 These might better be hoisted into the requirements table for unordered associative containers.
8894 Futhermore a mild reorganization of the container requirements could well be in order.
8895 This defect report is purposefully ignoring these larger issues and just focusing
8896 on getting the unordered containers "moved".
8897 </p>
8898
8899
8900
8901 <p><b>Proposed resolution:</b></p>
8902
8903 <p>
8904 Add to 23.4 [unord]:
8905 </p>
8906
8907 <blockquote><pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8908   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
8909             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
8910
8911 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8912   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
8913             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
8914
8915 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8916   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
8917             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
8918
8919 template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8920   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
8921             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
8922
8923 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8924   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
8925             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
8926
8927 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8928   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
8929             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
8930
8931 ...
8932
8933 template &lt;class Value, class Hash, class Pred, class Alloc&gt;
8934   void swap(unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; x,
8935             unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; y);
8936
8937 <ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt;
8938   void swap(unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; x,
8939             unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
8940
8941 <ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt;
8942   void swap(unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; x,
8943             unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; y);</ins>
8944
8945 template &lt;class Value, class Hash, class Pred, class Alloc&gt;
8946   void swap(unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; x,
8947             unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; y);
8948
8949 <ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt;
8950   void swap(unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; x,
8951             unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
8952
8953 <ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt;
8954   void swap(unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; x,
8955             unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; y);</ins>
8956 </pre></blockquote>
8957
8958 <p><b><tt>unordered_map</tt></b></p>
8959
8960 <p>
8961 Change 23.4.1 [unord.map]:
8962 </p>
8963
8964 <blockquote><pre>class unordered_map
8965 {
8966     ...
8967     unordered_map(const unordered_map&amp;);
8968     <ins>unordered_map(unordered_map&amp;&amp;);</ins>
8969     ~unordered_map();
8970     unordered_map&amp; operator=(const unordered_map&amp;);
8971     <ins>unordered_map&amp; operator=(unordered_map&amp;&amp;);</ins>
8972     ...
8973     // modifiers
8974     <del>std::</del>pair&lt;iterator, bool&gt; insert(const value_type&amp; obj);
8975     <ins>template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(P&amp;&amp; obj);</ins>
8976     iterator       insert(iterator hint, const value_type&amp; obj);
8977     <ins>template &lt;class P&gt; iterator       insert(iterator hint, P&amp;&amp; obj);</ins>
8978     const_iterator insert(const_iterator hint, const value_type&amp; obj);
8979     <ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; obj);</ins>
8980     ...
8981     void swap(unordered_map&amp;<ins>&amp;</ins>);
8982     ...
8983     mapped_type&amp; operator[](const key_type&amp; k);
8984     <ins>mapped_type&amp; operator[](key_type&amp;&amp; k);</ins>
8985     ...
8986 };
8987
8988 template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8989   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
8990             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
8991
8992 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8993   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
8994             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
8995
8996 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8997   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
8998             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
8999 </pre></blockquote>
9000
9001 <p>
9002 Add to 23.4.1.1 [unord.map.cnstr]:
9003 </p>
9004
9005 <blockquote>
9006 <pre>template &lt;class InputIterator&gt;
9007   unordered_map(InputIterator f, InputIterator l,
9008                 size_type n = <i>implementation-defined</i>,
9009                 const hasher&amp; hf = hasher(),
9010                 const key_equal&amp; eql = key_equal(),
9011                 const allocator_type&amp; a = allocator_type());
9012 </pre>
9013
9014 <blockquote><p>
9015 <ins>
9016 <i>Requires:</i> If the iterator's dereference operator returns an
9017 lvalue or a const rvalue <tt>pair&lt;key_type, mapped_type&gt;</tt>,
9018 then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be
9019 <tt>CopyConstructible</tt>.
9020 </ins>
9021 </p></blockquote>
9022 </blockquote>
9023
9024 <p>
9025 Add to 23.4.1.2 [unord.map.elem]:
9026 </p>
9027
9028 <blockquote>
9029
9030 <pre>mapped_type&amp; operator[](const key_type&amp; k);</pre>
9031
9032 <blockquote>
9033 <p>...</p>
9034 <p><ins>
9035 <i>Requires:</i> <tt>key_type</tt> shall be <tt>CopyConstructible</tt>
9036 and <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>.
9037 </ins></p>
9038 </blockquote>
9039
9040 <pre><ins>mapped_type&amp; operator[](key_type&amp;&amp; k);</ins></pre>
9041
9042 <blockquote>
9043 <p><ins>
9044 <i>Effects:</i> If the <tt>unordered_map</tt> does not already contain an
9045 element whose key is equivalent to <tt>k</tt> , inserts the value
9046 <tt>std::pair&lt;const key_type, mapped_type&gt;(std::move(k), mapped_type())</tt>.
9047 </ins></p>
9048
9049 <p><ins>
9050 <i>Requires:</i> <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>.
9051 </ins></p>
9052
9053 <p><ins>
9054 <i>Returns:</i> A reference to <tt>x.second</tt>, where <tt>x</tt> is the
9055 (unique) element whose key is equivalent to <tt>k</tt>.
9056 </ins></p>
9057
9058 </blockquote>
9059
9060 </blockquote>
9061
9062 <p>
9063 Add new section [unord.map.modifiers]:
9064 </p>
9065
9066 <blockquote>
9067 <pre><ins>pair&lt;iterator, bool&gt; insert(const value_type&amp; x);</ins>
9068 <ins>template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(P&amp;&amp; x);</ins>
9069 <ins>iterator       insert(iterator hint, const value_type&amp; x);</ins>
9070 <ins>template &lt;class P&gt; iterator       insert(iterator hint, P&amp;&amp; x);</ins>
9071 <ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
9072 <ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; x);</ins>
9073 <ins>template &lt;class InputIterator&gt;
9074   void insert(InputIterator first, InputIterator last);</ins>
9075 </pre>
9076
9077 <blockquote>
9078 <p><ins>
9079 <i>Requires:</i> Those signatures taking a <tt>const value_type&amp;</tt> parameter
9080 requires both the <tt>key_type</tt> and the <tt>mapped_type</tt> to be
9081 <tt>CopyConstructible</tt>.
9082 </ins></p>
9083
9084 <p><ins>
9085 <tt>P</tt> shall be convertible to <tt>value_type</tt>.
9086  If <tt>P</tt> is instantiated as a reference
9087 type, then the argument <tt>x</tt> is copied from. Otherwise <tt>x</tt>
9088 is considered to be an rvalue as it is converted to <tt>value_type</tt>
9089 and inserted into the <tt>unordered_map</tt>. Specifically, in such
9090 cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or
9091 <tt>mapped_type</tt> unless the conversion from <tt>P</tt> specifically
9092 requires it (e.g. if <tt>P</tt> is a <tt>tuple&lt;const key_type,
9093 mapped_type&gt;</tt>, then <tt>key_type</tt> must be
9094 <tt>CopyConstructible</tt>).
9095 </ins></p>
9096
9097 <p><ins>
9098 The signature taking <tt>InputIterator</tt>
9099 parameters requires <tt>CopyConstructible</tt> of both
9100 <tt>key_type</tt> and <tt>mapped_type</tt> if the dereferenced
9101 <tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
9102 <tt>value_type</tt>.
9103 </ins></p>
9104
9105 </blockquote>
9106
9107 </blockquote>
9108
9109 <p>
9110 Add to 23.4.1.3 [unord.map.swap]:
9111 </p>
9112
9113 <blockquote>
9114 <pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
9115   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
9116             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
9117 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
9118   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
9119             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
9120 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
9121   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
9122             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
9123 </pre>
9124 </blockquote>
9125
9126 <p><b><tt>unordered_multimap</tt></b></p>
9127
9128 <p>
9129 Change 23.4.2 [unord.multimap]:
9130 </p>
9131
9132 <blockquote><pre>class unordered_multimap
9133 {
9134     ...
9135     unordered_multimap(const unordered_multimap&amp;);
9136     <ins>unordered_multimap(unordered_multimap&amp;&amp;);</ins>
9137     ~unordered_multimap();
9138     unordered_multimap&amp; operator=(const unordered_multimap&amp;);
9139     <ins>unordered_multimap&amp; operator=(unordered_multimap&amp;&amp;);</ins>
9140     ...
9141     // modifiers
9142     iterator insert(const value_type&amp; obj);
9143     <ins>template &lt;class P&gt; iterator insert(P&amp;&amp; obj);</ins>
9144     iterator       insert(iterator hint, const value_type&amp; obj);
9145     <ins>template &lt;class P&gt; iterator       insert(iterator hint, P&amp;&amp; obj);</ins>
9146     const_iterator insert(const_iterator hint, const value_type&amp; obj);
9147     <ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; obj);</ins>
9148     ...
9149     void swap(unordered_multimap&amp;<ins>&amp;</ins>);
9150     ...
9151 };
9152
9153 template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
9154   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
9155             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
9156
9157 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
9158   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
9159             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
9160
9161 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
9162   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
9163             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
9164 </pre></blockquote>
9165
9166 <p>
9167 Add to 23.4.2.1 [unord.multimap.cnstr]:
9168 </p>
9169
9170 <blockquote>
9171 <pre>template &lt;class InputIterator&gt;
9172   unordered_multimap(InputIterator f, InputIterator l,
9173                 size_type n = <i>implementation-defined</i>,
9174                 const hasher&amp; hf = hasher(),
9175                 const key_equal&amp; eql = key_equal(),
9176                 const allocator_type&amp; a = allocator_type());
9177 </pre>
9178
9179 <blockquote><p>
9180 <ins>
9181 <i>Requires:</i> If the iterator's dereference operator returns an
9182 lvalue or a const rvalue <tt>pair&lt;key_type, mapped_type&gt;</tt>,
9183 then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be
9184 <tt>CopyConstructible</tt>.
9185 </ins>
9186 </p></blockquote>
9187 </blockquote>
9188
9189 <p>
9190 Add new section [unord.multimap.modifiers]:
9191 </p>
9192
9193 <blockquote>
9194 <pre><ins>iterator insert(const value_type&amp; x);</ins>
9195 <ins>template &lt;class P&gt; iterator       insert(P&amp;&amp; x);</ins>
9196 <ins>iterator       insert(iterator hint, const value_type&amp; x);</ins>
9197 <ins>template &lt;class P&gt; iterator       insert(iterator hint, P&amp;&amp; x);</ins>
9198 <ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
9199 <ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; x);</ins>
9200 <ins>template &lt;class InputIterator&gt;
9201   void insert(InputIterator first, InputIterator last);</ins>
9202 </pre>
9203
9204 <blockquote>
9205 <p><ins>
9206 <i>Requires:</i> Those signatures taking a <tt>const value_type&amp;</tt> parameter
9207 requires both the <tt>key_type</tt> and the <tt>mapped_type</tt> to be
9208 <tt>CopyConstructible</tt>.
9209 </ins></p>
9210
9211 <p><ins>
9212 <tt>P</tt> shall be convertible to <tt>value_type</tt>.
9213  If <tt>P</tt> is instantiated as a reference
9214 type, then the argument <tt>x</tt> is copied from. Otherwise <tt>x</tt>
9215 is considered to be an rvalue as it is converted to <tt>value_type</tt>
9216 and inserted into the <tt>unordered_multimap</tt>. Specifically, in such
9217 cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or
9218 <tt>mapped_type</tt> unless the conversion from <tt>P</tt> specifically
9219 requires it (e.g. if <tt>P</tt> is a <tt>tuple&lt;const key_type,
9220 mapped_type&gt;</tt>, then <tt>key_type</tt> must be
9221 <tt>CopyConstructible</tt>).
9222 </ins></p>
9223
9224 <p><ins>
9225 The signature taking <tt>InputIterator</tt>
9226 parameters requires <tt>CopyConstructible</tt> of both
9227 <tt>key_type</tt> and <tt>mapped_type</tt> if the dereferenced
9228 <tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
9229 <tt>value_type</tt>.
9230 </ins></p>
9231 </blockquote>
9232
9233 </blockquote>
9234
9235 <p>
9236 Add to 23.4.2.2 [unord.multimap.swap]:
9237 </p>
9238
9239 <blockquote>
9240 <pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
9241   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
9242             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
9243 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
9244   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
9245             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
9246 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
9247   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
9248             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
9249 </pre>
9250 </blockquote>
9251
9252 <p><b><tt>unordered_set</tt></b></p>
9253
9254 <p>
9255 Change 23.4.3 [unord.set]:
9256 </p>
9257
9258 <blockquote><pre>class unordered_set
9259 {
9260     ...
9261     unordered_set(const unordered_set&amp;);
9262     <ins>unordered_set(unordered_set&amp;&amp;);</ins>
9263     ~unordered_set();
9264     unordered_set&amp; operator=(const unordered_set&amp;);
9265     <ins>unordered_set&amp; operator=(unordered_set&amp;&amp;);</ins>
9266     ...
9267     // modifiers
9268     <del>std::</del>pair&lt;iterator, bool&gt; insert(const value_type&amp; obj);
9269     <ins>pair&lt;iterator, bool&gt; insert(value_type&amp;&amp; obj);</ins>
9270     iterator       insert(iterator hint, const value_type&amp; obj);
9271     <ins>iterator       insert(iterator hint, value_type&amp;&amp; obj);</ins>
9272     const_iterator insert(const_iterator hint, const value_type&amp; obj);
9273     <ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; obj);</ins>
9274     ...
9275     void swap(unordered_set&amp;<ins>&amp;</ins>);
9276     ...
9277 };
9278
9279 template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
9280   void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
9281             unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
9282
9283 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
9284   void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
9285             unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
9286
9287 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
9288   void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
9289             unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
9290 </pre></blockquote>
9291
9292 <p>
9293 Add to 23.4.3.1 [unord.set.cnstr]:
9294 </p>
9295
9296 <blockquote>
9297 <pre>template &lt;class InputIterator&gt;
9298   unordered_set(InputIterator f, InputIterator l,
9299                 size_type n = <i>implementation-defined</i>,
9300                 const hasher&amp; hf = hasher(),
9301                 const key_equal&amp; eql = key_equal(),
9302                 const allocator_type&amp; a = allocator_type());
9303 </pre>
9304
9305 <blockquote><p>
9306 <ins>
9307 <i>Requires:</i> If the iterator's dereference operator returns an
9308 lvalue or a const rvalue <tt>value_type</tt>, then the
9309 <tt>value_type</tt> shall be <tt>CopyConstructible</tt>.
9310 </ins>
9311 </p></blockquote>
9312 </blockquote>
9313
9314 <p>
9315 Add new section [unord.set.modifiers]:
9316 </p>
9317
9318 <blockquote>
9319 <pre><ins>pair&lt;iterator, bool&gt; insert(const value_type&amp; x);</ins>
9320 <ins>pair&lt;iterator, bool&gt; insert(value_type&amp;&amp; x);</ins>
9321 <ins>iterator       insert(iterator hint, const value_type&amp; x);</ins>
9322 <ins>iterator       insert(iterator hint, value_type&amp;&amp; x);</ins>
9323 <ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
9324 <ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; x);</ins>
9325 <ins>template &lt;class InputIterator&gt;
9326   void insert(InputIterator first, InputIterator last);</ins>
9327 </pre>
9328
9329 <blockquote>
9330
9331 <p><ins>
9332 <i>Requires:</i> Those signatures taking a <tt>const
9333 value_type&amp;</tt> parameter requires the <tt>value_type</tt> to
9334 be <tt>CopyConstructible</tt>.
9335 </ins></p>
9336
9337 <p><ins>
9338 The signature taking <tt>InputIterator</tt> parameters requires
9339 <tt>CopyConstructible</tt> of <tt>value_type</tt> if the dereferenced
9340 <tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
9341 <tt>value_type</tt>.
9342 </ins></p>
9343
9344 </blockquote>
9345
9346 </blockquote>
9347
9348 <p>
9349 Add to 23.4.3.2 [unord.set.swap]:
9350 </p>
9351
9352 <blockquote>
9353 <pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
9354   void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
9355             unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
9356 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
9357   void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
9358             unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
9359 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
9360   void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
9361             unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
9362 </pre>
9363 </blockquote>
9364
9365 <p><b><tt>unordered_multiset</tt></b></p>
9366
9367 <p>
9368 Change 23.4.4 [unord.multiset]:
9369 </p>
9370
9371 <blockquote><pre>class unordered_multiset
9372 {
9373     ...
9374     unordered_multiset(const unordered_multiset&amp;);
9375     <ins>unordered_multiset(unordered_multiset&amp;&amp;);</ins>
9376     ~unordered_multiset();
9377     unordered_multiset&amp; operator=(const unordered_multiset&amp;);
9378     <ins>unordered_multiset&amp; operator=(unordered_multiset&amp;&amp;);</ins>
9379     ...
9380     // modifiers
9381     iterator insert(const value_type&amp; obj);
9382     <ins>iterator insert(value_type&amp;&amp; obj);</ins>
9383     iterator       insert(iterator hint, const value_type&amp; obj);
9384     <ins>iterator       insert(iterator hint, value_type&amp;&amp; obj);</ins>
9385     const_iterator insert(const_iterator hint, const value_type&amp; obj);
9386     <ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; obj);</ins>
9387     ...
9388     void swap(unordered_multiset&amp;<ins>&amp;</ins>);
9389     ...
9390 };
9391
9392 template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
9393   void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
9394             unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
9395
9396 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
9397   void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
9398             unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
9399
9400 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
9401   void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
9402             unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
9403 </pre></blockquote>
9404
9405 <p>
9406 Add to 23.4.4.1 [unord.multiset.cnstr]:
9407 </p>
9408
9409 <blockquote>
9410 <pre>template &lt;class InputIterator&gt;
9411   unordered_multiset(InputIterator f, InputIterator l,
9412                 size_type n = <i>implementation-defined</i>,
9413                 const hasher&amp; hf = hasher(),
9414                 const key_equal&amp; eql = key_equal(),
9415                 const allocator_type&amp; a = allocator_type());
9416 </pre>
9417
9418 <blockquote><p>
9419 <ins>
9420 <i>Requires:</i> If the iterator's dereference operator returns an
9421 lvalue or a const rvalue <tt>value_type</tt>, then the
9422 <tt>value_type</tt> shall be <tt>CopyConstructible</tt>.
9423 </ins>
9424 </p></blockquote>
9425 </blockquote>
9426
9427 <p>
9428 Add new section [unord.multiset.modifiers]:
9429 </p>
9430
9431 <blockquote>
9432 <pre><ins>iterator insert(const value_type&amp; x);</ins>
9433 <ins>iterator insert(value_type&amp;&amp; x);</ins>
9434 <ins>iterator       insert(iterator hint, const value_type&amp; x);</ins>
9435 <ins>iterator       insert(iterator hint, value_type&amp;&amp; x);</ins>
9436 <ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
9437 <ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; x);</ins>
9438 <ins>template &lt;class InputIterator&gt;
9439   void insert(InputIterator first, InputIterator last);</ins>
9440 </pre>
9441
9442 <blockquote>
9443
9444 <p><ins>
9445 <i>Requires:</i> Those signatures taking a <tt>const
9446 value_type&amp;</tt> parameter requires the <tt>value_type</tt> to
9447 be <tt>CopyConstructible</tt>.
9448 </ins></p>
9449
9450 <p><ins>
9451 The signature taking <tt>InputIterator</tt> parameters requires
9452 <tt>CopyConstructible</tt> of <tt>value_type</tt> if the dereferenced
9453 <tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
9454 <tt>value_type</tt>.
9455 </ins></p>
9456
9457 </blockquote>
9458
9459 </blockquote>
9460
9461 <p>
9462 Add to 23.4.4.2 [unord.multiset.swap]:
9463 </p>
9464
9465 <blockquote>
9466 <pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
9467   void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
9468             unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
9469 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
9470   void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
9471             unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
9472 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
9473   void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
9474             unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
9475 </pre>
9476 </blockquote>
9477
9478
9479
9480 <p><i>[
9481 Voted to WP in Bellevue.
9482 ]</i></p>
9483
9484
9485 <p><i>[
9486 post Bellevue, Pete notes:
9487 ]</i></p>
9488
9489
9490 <blockquote>
9491 <p>
9492 Please remind people who are reviewing issues to check that the text
9493 modifications match the current draft. Issue 676, for example, adds two
9494 overloads for unordered_map::insert taking a hint. One takes a
9495 const_iterator and returns a const_iterator, and the other takes an
9496 iterator and returns an iterator. This was correct at the time the issue
9497 was written, but was changed in Toronto so there is only one hint
9498 overload, taking a const_iterator and returning an iterator.
9499 </p>
9500 <p>
9501 This issue is not ready. In addition to the relatively minor signature
9502 problem I mentioned earlier, it puts requirements in the wrong places.
9503 Instead of duplicating requirements throughout the template
9504 specifications, it should put them in the front matter that talks about
9505 requirements for unordered containers in general. This presentation
9506 problem is editorial, but I'm not willing to do the extensive rewrite
9507 that it requires. Please put it back into Open status.
9508 </p>
9509 </blockquote>
9510
9511
9512
9513
9514 <hr>
9515 <h3><a name="685"></a>685. reverse_iterator/move_iterator difference has invalid signatures</h3>
9516 <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#Ready">Ready</a>
9517  <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-06-10</p>
9518 <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>
9519 <p><b>Discussion:</b></p>
9520 <p>
9521 In C++03 the difference between two <tt>reverse_iterators</tt>
9522 </p>
9523 <blockquote><pre>ri1 - ri2
9524 </pre></blockquote>
9525 <p>
9526 is possible to compute only if both iterators have the same base
9527 iterator. The result type is the <tt>difference_type</tt> of the base iterator.
9528 </p>
9529 <p>
9530 In the current draft, the operator is defined as 24.4.1.3.19 [reverse.iter.opdiff]
9531 </p>
9532 <blockquote><pre>template&lt;class Iterator1, class Iterator2&gt;
9533 typename reverse_iterator&lt;Iterator&gt;::difference_type
9534    operator-(const reverse_iterator&lt;Iterator1&gt;&amp; x,
9535                     const reverse_iterator&lt;Iterator2&gt;&amp; y);
9536 </pre></blockquote>
9537 <p>
9538 The return type is the same as the C++03 one, based on the no longer
9539 present <tt>Iterator</tt> template parameter.
9540 </p>
9541 <p>
9542 Besides being slightly invalid, should this operator work only when
9543 <tt>Iterator1</tt> and <tt>Iterator2</tt> has the same <tt>difference_type</tt>? Or should the
9544 implementation choose one of them? Which one?
9545 </p>
9546 <p>
9547 The same problem now also appears in <tt>operator-()</tt> for <tt>move_iterator</tt>
9548 24.4.3.3.14 [move.iter.nonmember].
9549 </p>
9550
9551
9552 <p><b>Proposed resolution:</b></p>
9553 <p>
9554 Change the synopsis in 24.4.1.1 [reverse.iterator]:
9555 </p>
9556
9557 <blockquote>
9558 <pre>template &lt;class Iterator1, class Iterator2&gt;
9559   <del>typename reverse_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-(
9560     const reverse_iterator&lt;Iterator1&gt;&amp; x,
9561     const reverse_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(y.current - x.current)</ins>;
9562 </pre>
9563 </blockquote>
9564
9565 <p>
9566 Change 24.4.1.3.19 [reverse.iter.opdiff]:
9567 </p>
9568
9569 <blockquote>
9570 <pre>template &lt;class Iterator1, class Iterator2&gt;
9571   <del>typename reverse_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-(
9572     const reverse_iterator&lt;Iterator1&gt;&amp; x,
9573     const reverse_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(y.current - x.current)</ins>;
9574 </pre>
9575 <blockquote>
9576 <p>
9577 <i>Returns:</i> <tt>y.current - x.current</tt>.
9578 </p>
9579 </blockquote>
9580 </blockquote>
9581
9582
9583 <p>
9584 Change the synopsis in 24.4.3.1 [move.iterator]:
9585 </p>
9586
9587 <blockquote>
9588 <pre>template &lt;class Iterator1, class Iterator2&gt;
9589   <del>typename move_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-(
9590     const move_iterator&lt;Iterator1&gt;&amp; x,
9591     const move_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(x.base() - y.base())</ins>;
9592 </pre>
9593 </blockquote>
9594
9595 <p>
9596 Change 24.4.3.3.14 [move.iter.nonmember]:
9597 </p>
9598
9599 <blockquote>
9600 <pre>template &lt;class Iterator1, class Iterator2&gt;
9601   <del>typename move_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-(
9602     const move_iterator&lt;Iterator1&gt;&amp; x,
9603     const move_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(x.base() - y.base())</ins>;
9604 </pre>
9605 <blockquote>
9606 <p>
9607 <i>Returns:</i> <tt>x.base() - y.base()</tt>.
9608 </p>
9609 </blockquote>
9610 </blockquote>
9611
9612 <p><i>[
9613 Pre Bellevue:  This issue needs to wait until the <tt>auto -&gt; return</tt> language feature
9614 goes in.
9615 ]</i></p>
9616
9617
9618
9619
9620
9621
9622
9623 <hr>
9624 <h3><a name="688"></a>688. reference_wrapper, cref unsafe, allow binding to rvalues</h3>
9625 <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#Open">Open</a>
9626  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</p>
9627 <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>
9628 <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>
9629 <p><b>Discussion:</b></p>
9630 <p>
9631 A <tt>reference_wrapper</tt> can be constructed from an rvalue, either by using
9632 the constructor, or via <tt>cref</tt> (and <tt>ref</tt> in some corner cases). This leads
9633 to a dangling reference being stored into the <tt>reference_wrapper</tt> object.
9634 Now that we have a mechanism to detect an rvalue, we can fix them to
9635 disallow this source of undefined behavior.
9636 </p>
9637
9638 <p>
9639 Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
9640 </p>
9641
9642
9643
9644 <p><b>Proposed resolution:</b></p>
9645 <p>
9646 In 20.5 [function.objects], add the following two signatures to the synopsis:
9647 </p>
9648
9649 <blockquote><pre>template &lt;class T&gt; void ref(const T&amp;&amp; t) = delete;
9650 template &lt;class T&gt; void cref(const T&amp;&amp; t) = delete;
9651 </pre></blockquote>
9652
9653
9654
9655 <p><i>[
9656 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2292.html">N2292</a>
9657 addresses the first part of the resolution but not the second.
9658 ]</i></p>
9659
9660
9661 <p><i>[
9662 Bellevue:  Doug noticed problems with the current wording.
9663 ]</i></p>
9664
9665
9666 <p><i>[
9667 post Bellevue:  Howard and Peter provided revised wording.
9668 ]</i></p>
9669
9670
9671 <p><i>[
9672 This resolution depends on a "favorable" resolution of CWG 606:  that is,
9673 the "special deduction rule" is disabled with the const T&amp;&amp; pattern.
9674 ]</i></p>
9675
9676
9677
9678
9679
9680 <hr>
9681 <h3><a name="691"></a>691. const_local_iterator cbegin, cend missing from TR1</h3>
9682 <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>
9683  <b>Submitter:</b> Joaquín M López Muñoz <b>Date:</b> 2007-06-14</p>
9684 <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>
9685 <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>
9686 <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>
9687 <p><b>Discussion:</b></p>
9688 <p>
9689 The last version of TR1 does not include the following member
9690 functions
9691 for unordered containers:
9692 </p>
9693
9694 <blockquote><pre>const_local_iterator cbegin(size_type n) const;
9695 const_local_iterator cend(size_type n) const;
9696 </pre></blockquote>
9697
9698 <p>
9699 which looks like an oversight to me. I've checked th TR1 issues lists
9700 and the latest working draft of the C++0x std (N2284) and haven't
9701 found any mention to these menfuns or to their absence.
9702 </p>
9703 <p>
9704 Is this really an oversight, or am I missing something?
9705 </p>
9706
9707
9708
9709 <p><b>Proposed resolution:</b></p>
9710 <p>
9711 Add the following two rows to table 93 (unordered associative container
9712 requirements) in section 23.1.3 [unord.req]:
9713 </p>
9714
9715 <blockquote>
9716 <table border="1">
9717 <caption>Unordered associative container requirements (in addition to container)</caption>
9718 <tbody><tr>
9719 <th>expression</th> <th>return type</th> <th>assertion/note pre/post-condition</th> <th>complexity</th>
9720 </tr>
9721 <tr>
9722 <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>
9723 </tr>
9724 <tr>
9725 <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>
9726 </tr>
9727 </tbody></table>
9728 </blockquote>
9729
9730 <p>
9731 Add to the synopsis in 23.4.1 [unord.map]:
9732 </p>
9733
9734 <blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
9735 const_local_iterator cend(size_type n) const;</ins>
9736 </pre></blockquote>
9737
9738 <p>
9739 Add to the synopsis in 23.4.2 [unord.multimap]:
9740 </p>
9741
9742 <blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
9743 const_local_iterator cend(size_type n) const;</ins>
9744 </pre></blockquote>
9745
9746 <p>
9747 Add to the synopsis in 23.4.3 [unord.set]:
9748 </p>
9749
9750 <blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
9751 const_local_iterator cend(size_type n) const;</ins>
9752 </pre></blockquote>
9753
9754 <p>
9755 Add to the synopsis in 23.4.4 [unord.multiset]:
9756 </p>
9757
9758 <blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
9759 const_local_iterator cend(size_type n) const;</ins>
9760 </pre></blockquote>
9761
9762
9763
9764
9765
9766
9767 <hr>
9768 <h3><a name="692"></a>692. <code>get_money</code> and <code>put_money</code> should be formatted I/O functions</h3>
9769 <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>
9770  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p>
9771 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ext.manip">active issues</a> in [ext.manip].</p>
9772 <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>
9773 <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>
9774 <p><b>Discussion:</b></p>
9775 <p>
9776 In a private email Bill Plauger notes:
9777 </p>
9778 <blockquote><p>
9779 I  believe that  the function  that  implements <code>get_money</code>
9780 [from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2072.html">N2072</a>]
9781 should behave  as a  formatted input function,  and the  function that
9782 implements <code>put_money</code> should  behave as a formatted output
9783 function. This  has implications regarding the  skipping of whitespace
9784 and the handling of errors, among other things.
9785 </p>
9786 <p>
9787 The words  don't say that  right now and  I'm far from  convinced that
9788 such a change is editorial.
9789 </p></blockquote>
9790 <p>
9791 Martin's response:
9792 </p>
9793 <blockquote><p>
9794 I agree that the manipulators should handle exceptions the same way as
9795 formatted I/O functions do. The text in N2072 assumes so but the
9796 <i>Returns</i> clause explicitly omits exception handling for the sake
9797 of brevity. The spec should be clarified to that effect.
9798 </p>
9799 <p>
9800 As for dealing  with whitespace, I also agree it  would make sense for
9801 the extractors  and inserters involving the new  manipulators to treat
9802 it the same way as formatted I/O.
9803 </p></blockquote>
9804
9805
9806 <p><b>Proposed resolution:</b></p>
9807 <p>
9808 Add  a new  paragraph immediately  above  p4 of 27.6.4 [ext.manip] with  the
9809 following text:
9810 </p>
9811 <blockquote><p>
9812 <i>Effects</i>:  The   expression  <code><i>in</i> &gt;&gt; get_money(mon, intl)</code>
9813 described below behaves as a formatted input function (as
9814 described in 27.6.1.2.1 [istream.formatted.reqmts]).
9815 </p></blockquote>
9816 <p>
9817 Also change p4 of 27.6.4 [ext.manip] as follows:
9818 </p>
9819 <blockquote><p>
9820 <i>Returns</i>: An object <code>s</code> of unspecified type such that
9821 if <code>in</code> is  an object of type <code>basic_istream&lt;charT,
9822 traits&gt;</code>    then    the    expression   <code><i>in</i> &gt;&gt; get_money(mon, intl)</code> behaves as <ins>a formatted input function
9823 that    calls    </ins><code>f(in, mon, intl)</code><del>    were
9824 called</del>. The function <code>f</code> can be defined as...
9825 </p></blockquote>
9826
9827
9828 <p><i>[
9829 post Bellevue:
9830 ]</i></p>
9831
9832
9833 <blockquote>
9834 We recommend moving immediately to Review. We've looked at the issue and
9835 have a consensus that the proposed resolution is correct, but want an
9836 iostream expert to sign off. Alisdair has taken the action item to putt
9837 this up on the reflector for possible movement by Howard to Tenatively
9838 Ready.
9839 </blockquote>
9840
9841
9842
9843
9844 <hr>
9845 <h3><a name="696"></a>696. <code>istream::operator&gt;&gt;(int&amp;)</code> broken</h3>
9846 <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>
9847  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-23</p>
9848 <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>
9849 <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>
9850 <p><b>Discussion:</b></p>
9851 <p>
9852 From message c++std-lib-17897:
9853 </p>
9854 <p>
9855 The  code  shown  in  27.6.1.2.2 [istream.formatted.arithmetic] as  the  "as  if"
9856 implementation  of the  two arithmetic  extractors that  don't  have a
9857 corresponding     <code>num_get</code>     interface    (i.e.,     the
9858 <code>short</code> and <code>int</code>  overloads) is subtly buggy in
9859 how  it  deals  with  <code>EOF</code>, overflow,  and  other  similar
9860 conditions (in addition to containing a few typos).
9861 </p>
9862 <p>
9863 One  problem is  that if  <code>num_get::get()</code> reaches  the EOF
9864 after reading in  an otherwise valid value that  exceeds the limits of
9865 the    narrower    type     (but    not    <code>LONG_MIN</code>    or
9866 <code>LONG_MAX</code>),   it  will   set   <code><i>err</i></code>  to
9867 <code>eofbit</code>.   Because   of  the  if   condition  testing  for
9868 <code>(<i>err</i> == 0)</code>,    the   extractor    won't   set
9869 <code>failbit</code>  (and presumably,  return  a bogus  value to  the
9870 caller).
9871 </p>
9872 <p>
9873 Another  problem with  the code  is that  it never  actually  sets the
9874 argument to  the extracted  value. It can't  happen after the  call to
9875 <code>setstate()</code> since  the function may  throw, so we  need to
9876 show when  and how it's done (we  can't just punt as  say: "it happens
9877 afterwards"). However, it  turns out that showing how  it's done isn't
9878 quite so  easy since  the argument is  normally left unchanged  by the
9879 facet on error  except when the error is due  to a misplaced thousands
9880 separator,  which causes  <code>failbit</code> to  be set  but doesn't
9881 prevent the facet from storing the value.
9882 </p>
9883
9884
9885 <p><b>Proposed resolution:</b></p>
9886 <p>
9887 </p>
9888
9889
9890
9891
9892
9893 <hr>
9894 <h3><a name="698"></a>698. Some system_error issues</h3>
9895 <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>
9896  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-06-24</p>
9897 <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>
9898 <p><b>Discussion:</b></p>
9899 <p>
9900 In 19.4.5.1 [syserr.syserr.overview] we have the class definition of
9901 <tt>std::system_error</tt>. In contrast to all exception classes, which
9902 are constructible with a <tt>what_arg string</tt> (see 19.1 [std.exceptions],
9903 or <tt>ios_base::failure</tt> in 27.4.2.1.1 [ios::failure]), only overloads with with
9904 <tt>const string&amp;</tt> are possible. For consistency with the re-designed
9905 remaining exception classes this class should also provide
9906 c'tors which accept a const <tt>char* what_arg</tt> string.
9907 </p>
9908 <p>
9909 Please note that this proposed addition makes sense even
9910 considering the given implementation hint for <tt>what()</tt>, because
9911 <tt>what_arg</tt> is required to be set as <tt>what_arg</tt> of the base class
9912 <tt>runtime_error</tt>, which now has the additional c'tor overload
9913 accepting a <tt>const char*</tt>.
9914 </p>
9915
9916
9917 <p><b>Proposed resolution:</b></p>
9918 <p>
9919 </p>
9920
9921
9922
9923
9924
9925 <hr>
9926 <h3><a name="701"></a>701. assoc laguerre poly's</h3>
9927 <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>
9928  <b>Submitter:</b> Christopher Crawford <b>Date:</b> 2007-06-30</p>
9929 <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>
9930 <p><b>Discussion:</b></p>
9931 <p>
9932 I see that the definition the associated Laguerre
9933 polynomials TR1 5.2.1.1 [tr.num.sf.Lnm] has been corrected since
9934 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1687.pdf">N1687</a>.
9935 However, the draft standard only specifies ranks of integer value <tt>m</tt>,
9936 while the associated Laguerre polynomials are actually valid for real
9937 values of <tt>m &gt; -1</tt>.  In the case of non-integer values of <tt>m</tt>, the
9938 definition  <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>
9939 must be used, which also holds for integer values of <tt>m</tt>.  See
9940 Abramowitz &amp; Stegun, 22.11.6 for the general case, and 22.5.16-17 for
9941 the integer case.  In fact fractional values are most commonly used in
9942 physics, for example to <tt>m = +/- 1/2</tt> to describe the harmonic
9943 oscillator in 1 dimension, and <tt>1/2, 3/2, 5/2, ...</tt> in 3
9944 dimensions.
9945 </p>
9946 <p>
9947 If I am correct, the calculation of the more general case is no
9948 more difficult, and is in fact the function implemented in the GNU
9949 Scientific Library.  I would urge you to consider upgrading the
9950 standard, either adding extra functions for real <tt>m</tt> or switching the
9951 current ones to <tt>double</tt>.
9952 </p>
9953
9954
9955 <p><b>Proposed resolution:</b></p>
9956 <p>
9957 </p>
9958
9959
9960
9961
9962
9963 <hr>
9964 <h3><a name="702"></a>702. Restriction in associated Legendre functions</h3>
9965 <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>
9966  <b>Submitter:</b> Christopher Crawford <b>Date:</b> 2007-06-30</p>
9967 <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>
9968 <p><b>Discussion:</b></p>
9969 <p>
9970 One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should  be
9971 <tt>|x| &lt;= 1</tt>, not <tt>x &gt;= 0</tt>.</p>
9972
9973
9974 <p><b>Proposed resolution:</b></p>
9975 <p>
9976 </p>
9977
9978
9979
9980
9981
9982 <hr>
9983 <h3><a name="704"></a>704. MoveAssignable requirement for container value type overly strict</h3>
9984 <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>
9985  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-20</p>
9986 <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>
9987 <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>
9988 <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>
9989 <p><b>Discussion:</b></p>
9990 <p>
9991 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>.
9992 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
9993 most of the member functions of node-based containers.  But the move-related changes
9994 unnecessarily introduced the <tt>MoveAssignable</tt> requirement for those members which used to
9995 require <tt>CopyAssignable</tt>.
9996 </p>
9997
9998 <p>
9999 We also discussed (c++std-lib-18722) the possibility of dropping <tt>MoveAssignable</tt>
10000 from some of the sequence requirements.  Additionally the <i>in-place</i> construction
10001 work may further reduce requirements.  For purposes of an easy reference, here are the
10002 minimum sequence requirements as I currently understand them.  Those items in requirements
10003 table in the working draft which do not appear below have been purposefully omitted for
10004 brevity as they do not have any requirements of this nature.  Some items which do not
10005 have any requirements of this nature are included below just to confirm that they were
10006 not omitted by mistake.
10007 </p>
10008
10009 <table border="1">
10010 <caption>Container Requirements</caption>
10011 <tbody><tr><td><tt>X u(a)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
10012 <tr><td><tt>X u(rv)</tt></td><td><tt>array</tt> requires <tt>value_type</tt> to be <tt>MoveConstructible</tt></td></tr>
10013 <tr><td><tt>a = u</tt></td><td>Sequences require <tt>value_type</tt> to be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.
10014                                Associative containers require <tt>value_type</tt> to be <tt>CopyConstructible</tt>.</td></tr>
10015 <tr><td><tt>a = rv</tt></td><td><tt>array</tt> requires <tt>value_type</tt> to be <tt>MoveAssignable</tt>.
10016                                 Sequences with non-<tt>Swappable</tt> allocators require <tt>value_type</tt> to be <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.
10017                                 Associative containers with non-<tt>Swappable</tt> allocators require <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
10018 <tr><td><tt>swap(a,u)</tt></td><td><tt>array</tt> requires <tt>value_type</tt> to be <tt>Swappable</tt>.
10019                                 Sequences with non-<tt>Swappable</tt> allocators require <tt>value_type</tt> to be <tt>Swappable</tt>, <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.
10020                                 Associative containers with non-<tt>Swappable</tt> allocators require <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
10021 </tbody></table>
10022
10023 <p>
10024 </p>
10025
10026 <table border="1">
10027 <caption>Sequence Requirements</caption>
10028 <tbody><tr><td><tt>X(n)</tt></td><td><tt>value_type</tt> must be <tt>DefaultConstructible</tt></td></tr>
10029 <tr><td><tt>X(n, t)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
10030 <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>.
10031                                  If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
10032 <tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
10033                                         The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
10034 <tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
10035                                         The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
10036 <tr><td><tt>a.insert(p, n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
10037                                         The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
10038 <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>.
10039                                         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.
10040                                         If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
10041                                         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>
10042 <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>
10043 <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>
10044 <tr><td><tt>a.clear()</tt></td><td></td></tr>
10045 <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>.
10046                                         If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.</td></tr>
10047 <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>
10048 <tr><td><tt>a.resize(n)</tt></td><td>The <tt>value_type</tt> must be <tt>DefaultConstructible</tt>.
10049                                      The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
10050 <tr><td><tt>a.resize(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
10051 </tbody></table>
10052
10053 <p>
10054 </p>
10055
10056 <table border="1">
10057 <caption>Optional Sequence Requirements</caption>
10058 <tbody><tr><td><tt>a.front()</tt></td><td></td></tr>
10059 <tr><td><tt>a.back()</tt></td><td></td></tr>
10060 <tr><td><tt>a.push_front(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
10061 <tr><td><tt>a.push_front(rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
10062 <tr><td><tt>a.push_back(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
10063 <tr><td><tt>a.push_back(rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
10064 <tr><td><tt>a.pop_front()</tt></td><td></td></tr>
10065 <tr><td><tt>a.pop_back()</tt></td><td></td></tr>
10066 <tr><td><tt>a[n]</tt></td><td></td></tr>
10067 <tr><td><tt>a.at[n]</tt></td><td></td></tr>
10068 </tbody></table>
10069
10070 <p>
10071 </p>
10072
10073 <table border="1">
10074 <caption>Associative Container Requirements</caption>
10075 <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>.
10076                                  If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
10077 <tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
10078 <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>
10079 <tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
10080 <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>
10081 <tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
10082 <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>
10083 <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>.
10084                                         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>
10085 </tbody></table>
10086
10087 <p>
10088 </p>
10089
10090 <table border="1">
10091 <caption>Unordered Associative Container Requirements</caption>
10092 <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>.
10093                                  If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
10094 <tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
10095 <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>
10096 <tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
10097 <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>
10098 <tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
10099 <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>
10100 <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>.
10101                                         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>
10102 </tbody></table>
10103
10104 <p>
10105 </p>
10106
10107 <table border="1">
10108 <caption>Miscellaneous Requirements</caption>
10109 <tbody><tr><td><tt>map[lvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>CopyConstructible</tt>.
10110                                          The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr>
10111 <tr><td><tt>map[rvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>MoveConstructible</tt>.
10112                                          The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr>
10113 </tbody></table>
10114
10115 <p><i>[
10116 Kona (2007): Howard and Alan to update requirements table in issue with emplace signatures.
10117 ]</i></p>
10118
10119
10120 <p><i>[
10121 Bellevue: This should be handled as part of the concepts work.
10122 ]</i></p>
10123
10124
10125
10126
10127 <p><b>Proposed resolution:</b></p>
10128
10129
10130
10131
10132
10133
10134 <hr>
10135 <h3><a name="708"></a>708. Locales need to be per thread and updated for POSIX changes</h3>
10136 <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>
10137  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-07-28</p>
10138 <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>
10139 <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>
10140 <p><b>Discussion:</b></p>
10141 <p>
10142 The POSIX "Extended API Set Part 4,"
10143 </p>
10144 <blockquote><p>
10145 <a href="http://www.opengroup.org/sib/details.tpl?id=C065">http://www.opengroup.org/sib/details.tpl?id=C065</a>
10146 </p></blockquote>
10147 <p>
10148 introduces extensions to the C locale mechanism that
10149 allow multiple concurrent locales to be used in the same application
10150 by introducing a type <tt>locale_t</tt> that is very similar to
10151 <tt>std::locale</tt>, and a number of <tt>_l</tt> functions that make use of it.
10152 </p>
10153 <p>
10154 The global locale (set by setlocale) is now specified to be per-
10155 process. If a thread does not call <tt>uselocale</tt>, the global locale is
10156 in effect for that thread. It can install a per-thread locale by
10157 using <tt>uselocale</tt>.
10158 </p>
10159 <p>
10160 There is also a nice <tt>querylocale</tt> mechanism by which one can obtain
10161 the name (such as "de_DE") for a specific <tt>facet</tt>, even for combined
10162 locales, with no <tt>std::locale</tt> equivalent.
10163 </p>
10164 <p>
10165 <tt>std::locale</tt> should be harmonized with the new POSIX <tt>locale_t</tt>
10166 mechanism and provide equivalents for <tt>uselocale</tt> and <tt>querylocale</tt>.
10167 </p>
10168
10169 <p><i>[
10170 Kona (2007): Bill and Nick to provide wording.
10171 ]</i></p>
10172
10173
10174
10175
10176 <p><b>Proposed resolution:</b></p>
10177 <p>
10178 </p>
10179
10180
10181
10182
10183
10184 <hr>
10185 <h3><a name="710"></a>710. Missing postconditions</h3>
10186 <p><b>Section:</b> 20.6.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
10187  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-08-24</p>
10188 <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>
10189 <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>
10190 <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>
10191 <p><b>Discussion:</b></p>
10192 <p>
10193 A discussion on
10194 <a href="http://groups.google.com/group/comp.std.c++/browse_frm/thread/8e89dceb35cd7971">comp.std.c++</a>
10195 has identified a contradiction in the <tt>shared_ptr</tt> specification.
10196 The <tt>shared_ptr</tt> move constructor and the cast functions are
10197 missing postconditions for the <tt>get()</tt> accessor.
10198 </p>
10199
10200 <p><i>[
10201 Bellevue:
10202 ]</i></p>
10203
10204
10205 <blockquote>
10206 <p>
10207 Move to "ready", adopting the first (Peter's) proposed resolution.
10208 </p>
10209 <p>
10210 Note to the project editor: there is an editorial issue here. The
10211 wording for the postconditions of the casts is slightly awkward, and the
10212 editor should consider rewording "If w is the return value...", e. g. as
10213 "For a return value w...".
10214 </p>
10215 </blockquote>
10216
10217
10218 <p><b>Proposed resolution:</b></p>
10219 <p>
10220 Add to 20.6.12.2.1 [util.smartptr.shared.const]:
10221 </p>
10222
10223 <blockquote>
10224 <pre>shared_ptr(shared_ptr&amp;&amp; r);
10225 template&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt;&amp;&amp; r);
10226 </pre>
10227 <blockquote>
10228 <p>
10229 <i>Postconditions:</i>  <tt>*this</tt> shall contain the old value of <tt>r</tt>. <tt>r</tt>
10230 shall be empty. <ins><tt>r.get() == 0</tt>.</ins>
10231 </p>
10232 </blockquote>
10233 </blockquote>
10234
10235 <p>
10236 Add to 20.6.12.2.10 [util.smartptr.shared.cast]:
10237 </p>
10238
10239 <blockquote>
10240 <pre>template&lt;class T, class U&gt; shared_ptr&lt;T&gt; static_pointer_cast(shared_ptr&lt;U&gt; const&amp; r);
10241 </pre>
10242 <blockquote>
10243 <p>
10244 <ins><i>Postconditions:</i> If <tt>w</tt> is the return value,
10245 <tt>w.get() == static_cast&lt;T*&gt;(r.get()) &amp;&amp; w.use_count() == r.use_count()</tt>.</ins>
10246 </p>
10247 </blockquote>
10248 </blockquote>
10249
10250 <blockquote>
10251 <pre>template&lt;class T, class U&gt; shared_ptr&lt;T&gt; dynamic_pointer_cast(shared_ptr&lt;U&gt; const&amp; r);
10252 </pre>
10253 <blockquote>
10254 <p>
10255 <ins><i>Postconditions:</i> If <tt>w</tt> is the return value, <tt>w.get() == dynamic_cast&lt;T*&gt;(r.get())</tt>.</ins>
10256 </p>
10257 </blockquote>
10258 </blockquote>
10259
10260 <blockquote>
10261 <pre>template&lt;class T, class U&gt; shared_ptr&lt;T&gt; const_pointer_cast(shared_ptr&lt;U&gt; const&amp; r);
10262 </pre>
10263 <blockquote>
10264 <p>
10265 <ins><i>Postconditions:</i> If <tt>w</tt> is the return value,
10266 <tt>w.get() == const_cast&lt;T*&gt;(r.get()) &amp;&amp; w.use_count() == r.use_count()</tt>.</ins>
10267 </p>
10268 </blockquote>
10269 </blockquote>
10270
10271 <p>
10272 Alberto Ganesh Barbati has written an
10273 <a href="http://barbati.net/c++/shared_ptr.pdf">alternative proposal</a>
10274 where he suggests (among other things) that the casts be respecified in terms of
10275 the aliasing constructor as follows:
10276 </p>
10277
10278 <p>
10279 Change 20.6.12.2.10 [util.smartptr.shared.cast]:
10280 </p>
10281
10282 <blockquote>
10283 <p>
10284 -2- <i>Returns:</i> <del>If <tt>r</tt> is empty, an <tt>empty
10285 shared_ptr&lt;T&gt;;</tt> otherwise, a <tt>shared_ptr&lt;T&gt;</tt>
10286 object that stores <tt>static_cast&lt;T*&gt;(r.get())</tt> and shares ownership with
10287 <tt>r</tt>.</del> <ins><tt>shared_ptr&lt;T&gt;(r, static_cast&lt;T*&gt;(r.get())</tt>.</ins>
10288 </p>
10289 </blockquote>
10290
10291 <blockquote>
10292 <p>
10293 -6- <i>Returns:</i>
10294 </p>
10295 <ul>
10296 <li><del>When <tt>dynamic_cast&lt;T*&gt;(r.get())</tt> returns a nonzero value,
10297 a <tt>shared_ptr&lt;T&gt;</tt> object that stores a copy
10298 of it and <i>shares ownership</i> with <tt>r</tt>;</del></li>
10299 <li><del>Otherwise, an <i>empty</i> <tt>shared_ptr&lt;T&gt;</tt> object.</del></li>
10300 <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>
10301 <li><ins>Otherwise, <tt>shared_ptr&lt;T&gt;()</tt>.</ins></li>
10302 </ul>
10303 </blockquote>
10304
10305 <blockquote>
10306 <p>
10307 -10- <i>Returns:</i> <del>If <tt>r</tt> is empty, an <tt>empty
10308 shared_ptr&lt;T&gt;;</tt> otherwise, a <tt>shared_ptr&lt;T&gt;</tt>
10309 object that stores <tt>const_cast&lt;T*&gt;(r.get())</tt> and shares ownership with
10310 <tt>r</tt>.</del> <ins><tt>shared_ptr&lt;T&gt;(r, const_cast&lt;T*&gt;(r.get())</tt>.</ins>
10311 </p>
10312 </blockquote>
10313
10314 <p>
10315 This takes care of the missing postconditions for the casts by bringing
10316 in the aliasing constructor postcondition "by reference".
10317 </p>
10318
10319
10320
10321
10322
10323
10324 <hr>
10325 <h3><a name="711"></a>711. Contradiction in empty <tt>shared_ptr</tt></h3>
10326 <p><b>Section:</b> 20.6.12.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
10327  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-08-24</p>
10328 <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>
10329 <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>
10330 <p><b>Discussion:</b></p>
10331 <p>
10332 A discussion on
10333 <a href="http://groups.google.com/group/comp.std.c++/browse_frm/thread/8e89dceb35cd7971">comp.std.c++</a>
10334 has identified a contradiction in the <tt>shared_ptr</tt> specification.
10335 The note:
10336 </p>
10337
10338 <blockquote><p>
10339 [ <i>Note:</i> this constructor allows creation of an empty shared_ptr instance with a non-NULL stored pointer.
10340 -end note ]
10341 </p></blockquote>
10342
10343 <p>
10344 after the aliasing constructor
10345 </p>
10346
10347 <blockquote><pre>template&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt; const&amp; r, T *p);
10348 </pre></blockquote>
10349
10350 <p>
10351 reflects the intent of
10352 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm">N2351</a>
10353 to, well, allow the creation of an empty <tt>shared_ptr</tt>
10354 with a non-NULL stored pointer.
10355 </p>
10356
10357 <p>
10358 This is contradicted by the second sentence in the Returns clause of 20.6.12.2.5 [util.smartptr.shared.obs]:
10359 </p>
10360
10361 <blockquote>
10362 <pre>T* get() const;
10363 </pre>
10364 <blockquote><p>
10365 <i>Returns:</i> the stored pointer. Returns a null pointer if <tt>*this</tt> is empty.
10366 </p></blockquote>
10367 </blockquote>
10368
10369 <p><i>[
10370 Bellevue:
10371 ]</i></p>
10372
10373
10374 <blockquote>
10375 <p>
10376 Adopt option 1 and move to review, not ready.
10377 </p>
10378 <p>
10379 There was a lot of confusion about what an empty <tt>shared_ptr</tt> is (the term
10380 isn't defined anywhere), and whether we have a good mental model for how
10381 one behaves. We think it might be possible to deduce what the definition
10382 should be, but the words just aren't there. We need to open an issue on
10383 the use of this undefined term. (The resolution of that issue might
10384 affect the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>.)
10385 </p>
10386 <p>
10387 The LWG is getting more uncomfortable with the aliasing proposal (N2351)
10388 now that we realize some of its implications, and we need to keep an eye
10389 on it, but there isn't support for removing this feature at this time.
10390 </p>
10391 </blockquote>
10392
10393
10394 <p><b>Proposed resolution:</b></p>
10395 <p>
10396 In keeping the N2351 spirit and obviously my preference, change 20.6.12.2.5 [util.smartptr.shared.obs]:
10397 </p>
10398
10399 <blockquote>
10400 <pre>T* get() const;
10401 </pre>
10402 <blockquote><p>
10403 <i>Returns:</i> the stored pointer. <del>Returns a null pointer if <tt>*this</tt> is empty.</del>
10404 </p></blockquote>
10405 </blockquote>
10406
10407 <p>
10408 Alternative proposed resolution: (I won't be happy if we do this, but it's possible):
10409 </p>
10410
10411 <p>
10412 Change 20.6.12.2.1 [util.smartptr.shared.const]:
10413 </p>
10414
10415 <blockquote>
10416 <pre>template&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt; const&amp; r, T *p);
10417 </pre>
10418 <blockquote>
10419 <p>
10420 <ins><i>Requires:</i> If <tt>r</tt> is empty, <tt>p</tt> shall be <tt>0</tt>.</ins>
10421 </p>
10422 <p>
10423 <del>[ <i>Note:</i> this constructor allows creation of an empty <tt>shared_ptr</tt>
10424 instance with a non-NULL stored pointer.
10425 -- <i>end note</i> ]</del>
10426 </p>
10427 </blockquote>
10428 </blockquote>
10429
10430
10431
10432
10433
10434
10435 <hr>
10436 <h3><a name="713"></a>713. <tt>sort()</tt> complexity is too lax</h3>
10437 <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>
10438  <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-30</p>
10439 <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>
10440 <p><b>Discussion:</b></p>
10441 <p>
10442 The complexity of <tt>sort()</tt> is specified as "Approximately <tt>N
10443 log(N)</tt> (where <tt>N == last - first</tt> ) comparisons on the
10444 average", with no worst case complicity specified. The intention was to
10445 allow a median-of-three quicksort implementation, which is usually <tt>O(N
10446 log N)</tt> but can be quadratic for pathological inputs. However, there is
10447 no longer any reason to allow implementers the freedom to have a
10448 worst-cast-quadratic sort algorithm. Implementers who want to use
10449 quicksort can use a variant like David Musser's "Introsort" (Software
10450 Practice and Experience 27:983-993, 1997), which is guaranteed to be <tt>O(N
10451 log N)</tt> in the worst case without incurring additional overhead in the
10452 average case. Most C++ library implementers already do this, and there
10453 is no reason not to guarantee it in the standard.
10454 </p>
10455
10456
10457 <p><b>Proposed resolution:</b></p>
10458 <p>
10459 In 25.3.1.1 [sort], change the complexity to "O(N log N)", and remove footnote 266:
10460 </p>
10461
10462 <blockquote>
10463 <p>
10464 <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> )
10465 </del>comparisons<del> on the average</del>.<del><sup>266)</sup></del>
10466 </p>
10467 <p>
10468 <del><sup>266)</sup>
10469 If the worst case behavior is important <tt>stable_sort()</tt> (25.3.1.2) or <tt>partial_sort()</tt>
10470 (25.3.1.3) should be used.</del>
10471 </p>
10472 </blockquote>
10473
10474
10475
10476
10477
10478
10479 <hr>
10480 <h3><a name="714"></a>714. <tt>search_n</tt> complexity is too lax</h3>
10481 <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>
10482  <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-30</p>
10483 <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>
10484 <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>
10485 <p><b>Discussion:</b></p>
10486 <p>
10487 The complexity for <tt>search_n</tt> (25.1.9 [alg.search] par 7) is specified as "At most
10488 (last - first ) * count applications of the corresponding predicate if
10489 count is positive, or 0 otherwise." This is unnecessarily pessimistic.
10490 Regardless of the value of count, there is no reason to examine any
10491 element in the range more than once.
10492 </p>
10493
10494
10495 <p><b>Proposed resolution:</b></p>
10496 <p>
10497 Change the complexity to "At most (last - first) applications of the corresponding predicate".
10498 </p>
10499
10500 <blockquote>
10501 <pre>template&lt;class ForwardIterator, class Size, class T&gt;
10502   ForwardIterator
10503     search_n(ForwardIterator first , ForwardIterator last , Size count ,
10504              const T&amp; value );
10505
10506 template&lt;class ForwardIterator, class Size, class T,
10507          class BinaryPredicate&gt;
10508   ForwardIterator
10509     search_n(ForwardIterator first , ForwardIterator last , Size count ,
10510              const T&amp; value , BinaryPredicate pred );
10511 </pre>
10512 <blockquote>
10513 <p>
10514 <i>Complexity:</i> At most <tt>(last - first ) <del>* count</del></tt> applications of the corresponding predicate
10515 <del>if <tt>count</tt> is positive, or 0 otherwise</del>.
10516 </p>
10517 </blockquote>
10518 </blockquote>
10519
10520
10521
10522
10523
10524
10525 <hr>
10526 <h3><a name="715"></a>715. <tt>minmax_element</tt> complexity is too lax</h3>
10527 <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#Ready">Ready</a>
10528  <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-30</p>
10529 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.min.max">active issues</a> in [alg.min.max].</p>
10530 <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>
10531 <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>
10532 <p><b>Discussion:</b></p>
10533 <p>
10534 The complexity for <tt>minmax_element</tt> (25.3.7 [alg.min.max] par 16) says "At most <tt>max(2 *
10535 (last - first ) - 2, 0)</tt> applications of the corresponding comparisons",
10536 i.e. the worst case complexity is no better than calling <tt>min_element</tt> and
10537 <tt>max_element</tt> separately. This is gratuitously inefficient. There is a
10538 well known technique that does better: see section 9.1 of CLRS
10539 (Introduction to Algorithms, by Cormen, Leiserson, Rivest, and Stein).
10540 </p>
10541
10542
10543 <p><b>Proposed resolution:</b></p>
10544 <p>
10545 Change 25.3.7 [alg.min.max] to:
10546 </p>
10547
10548 <blockquote>
10549 <pre>template&lt;class ForwardIterator&gt;
10550   pair&lt;ForwardIterator, ForwardIterator&gt;
10551     minmax_element(ForwardIterator first , ForwardIterator last);
10552 template&lt;class ForwardIterator, class Compare&gt;
10553   pair&lt;ForwardIterator, ForwardIterator&gt;
10554     minmax_element(ForwardIterator first , ForwardIterator last , Compare comp);
10555 </pre>
10556 <blockquote>
10557 <p>
10558 <i>Returns:</i> <tt>make_pair(m, M)</tt>, where <tt>m</tt> is
10559 <del><tt>min_element(first, last)</tt> or <tt>min_element(first, last,
10560 comp)</tt></del> <ins>the first iterator in <tt>[first,
10561 last)</tt> such that no iterator in the range refers to a smaller element,</ins> and
10562 <ins>where</ins> <tt>M</tt> is <del><tt>max_element(first, last)</tt> or
10563 <tt>max_element(first, last, comp)</tt></del> <ins>the last iterator
10564 in <tt>[first, last)</tt> such that no iterator in the range refers to a larger element</ins>.
10565 </p>
10566 <p>
10567 <i>Complexity:</i> At most <del><tt>max(2 * (last - first ) - 2, 0)</tt></del>
10568 <ins><tt>max(&#8970;(3/2) (N-1)&#8971;, 0)</tt></ins> applications of the
10569 corresponding <del>comparisons</del> <ins>predicate, where <tt>N</tt> is <tt>distance(first, last)</tt></ins>.
10570 </p>
10571 </blockquote>
10572 </blockquote>
10573
10574
10575
10576
10577
10578
10579 <hr>
10580 <h3><a name="716"></a>716. Production in [re.grammar] not actually modified</h3>
10581 <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>
10582  <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2007-08-31</p>
10583 <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>
10584 <p><b>Discussion:</b></p>
10585 <p>
10586 TR1 7.13 [tr.re.grammar]/3 and C++0x WP 28.13 [re.grammar]/3 say:
10587 </p>
10588
10589 <blockquote>
10590 <p>
10591 The following productions within the ECMAScript grammar are modified as follows:
10592 </p>
10593
10594 <blockquote><pre>CharacterClass ::
10595 [ [lookahead &#8713; {^}] ClassRanges ]
10596 [ ^ ClassRanges ]
10597 </pre></blockquote>
10598
10599 </blockquote>
10600
10601 <p>
10602 This definition for <tt>CharacterClass</tt> appears to be exactly identical to that in ECMA-262.
10603 </p>
10604
10605 <p>
10606 Was an actual modification intended here and accidentally omitted, or was this production accidentally included?
10607 </p>
10608
10609
10610 <p><b>Proposed resolution:</b></p>
10611 <p>
10612 Remove this mention of the CharacterClass production.
10613 </p>
10614
10615 <blockquote><pre><del>CharacterClass ::
10616 [ [lookahead &#8713; {^}] ClassRanges ]
10617 [ ^ ClassRanges ]</del>
10618 </pre></blockquote>
10619
10620
10621
10622
10623
10624
10625 <hr>
10626 <h3><a name="718"></a>718. <tt>basic_string</tt> is not a sequence</h3>
10627 <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>
10628  <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-18</p>
10629 <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>
10630 <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>
10631 <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>
10632 <p><b>Discussion:</b></p>
10633 <p>
10634 Paragraph 21.3 [basic.string]/3 states:
10635 </p>
10636
10637 <blockquote>
10638 <p>
10639 The class template <tt>basic_string</tt> conforms to the requirements for a
10640 Sequence (23.1.1) and for a Reversible Container (23.1).
10641 </p>
10642 </blockquote>
10643
10644 <p>
10645 First of all, 23.1.1 [sequence.reqmts] is no longer "Sequence" but "Sequence container".
10646 Secondly, after the resent changes to containers (<tt>emplace</tt>, <tt>push_back</tt>,
10647 <tt>const_iterator</tt> parameters to <tt>insert</tt> and <tt>erase</tt>), <tt>basic_string</tt> is not
10648 even close to conform to the current requirements.
10649 </p>
10650
10651 <p><i>[
10652 Bellevue:
10653 ]</i></p>
10654
10655
10656 <blockquote>
10657 <ul>
10658 <li>emplace, for example, may not make sense for strings. Is also likely suboptimal</li>
10659 <li>with concepts do we need to maintain string as sequence container?</li>
10660 <li>One approach might be to say something like: string is a sequence except it doesn't have these functions</li>
10661 </ul>
10662 <ul>
10663 <li>basic_string already has push_back</li>
10664 <li>const_iterator parameters to insert and erase should be added to basic_string</li>
10665 <li>this leaves emplace to handle -- we have the following options:
10666 <ul>
10667 <li>option 1: add it to string even though it's optional</li>
10668 <li>option 2: make emplace optional to sequences (move from table 89 to 90)</li>
10669 <li>option 3: say string not sequence (the proposal),</li>
10670 <li>option 4: add an exception to basic string wording.</li>
10671 </ul>
10672 </li>
10673 </ul>
10674 General consensus is to suggest option 2.
10675 </blockquote>
10676
10677
10678
10679 <p><b>Proposed resolution:</b></p>
10680 <p>
10681 Remove this sentence, in recognition of the fact that <tt>basic_string</tt> is
10682 not just a <tt>vector</tt>-light for literal types, but something quite
10683 different, a string abstraction in its own right.
10684 </p>
10685
10686
10687
10688
10689
10690 <hr>
10691 <h3><a name="719"></a>719. <tt>std::is_literal</tt> type traits should be provided</h3>
10692 <p><b>Section:</b> 20.4 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
10693  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-25</p>
10694 <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>
10695 <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>
10696 <p><b>Discussion:</b></p>
10697 <p>
10698 Since the inclusion of <tt>constexpr</tt> in the standard draft N2369 we have
10699 a new type category "literal", which is defined in 3.9 [basic.types]/p.11:
10700 </p>
10701
10702 <blockquote>
10703 <p>
10704 -11- A type is a <i>literal</i> type if it is:
10705 </p>
10706 <ul>
10707 <li>a scalar type; or</li>
10708 <li><p>a class type (clause 9) with</p>
10709 <ul>
10710 <li>a trivial copy constructor,</li>
10711 <li>a trivial destructor,</li>
10712 <li>at least one constexpr constructor other than the copy constructor,</li>
10713 <li>no virtual base classes, and</li>
10714 <li>all non-static data members and base classes of literal types; or</li>
10715 </ul>
10716 </li>
10717 <li>an array of literal type.</li>
10718 </ul>
10719 </blockquote>
10720
10721 <p>
10722 I strongly suggest that the standard provides a type traits for
10723 literal types in 20.4.4.3 [meta.unary.prop] for several reasons:
10724 </p>
10725
10726 <ol type="a">
10727 <li>To keep the traits in sync with existing types.</li>
10728 <li>I see many reasons for programmers to use this trait in template
10729    code to provide optimized template definitions for these types,
10730    see below.</li>
10731 <li>A user-provided definition of this trait is practically impossible
10732 to write portably.</li>
10733 </ol>
10734
10735 <p>
10736 The special problem of reason (c) is that I don't see currently a
10737 way to portably test the condition for literal class types:
10738 </p>
10739
10740 <blockquote>
10741 <ul>
10742 <li>at least one constexpr constructor other than the copy constructor,</li>
10743 </ul>
10744 </blockquote>
10745
10746 <p>
10747 Here follows a simply example to demonstrate it's usefulness:
10748 </p>
10749
10750 <blockquote><pre>template &lt;typename T&gt;
10751 constexpr typename std::enable_if&lt;std::is_literal&lt;T&gt;::value, T&gt;::type
10752 abs(T x) {
10753   return x &lt; T() ? -x : x;
10754 }
10755
10756 template &lt;typename T&gt;
10757 typename std::enable_if&lt;!std::is_literal&lt;T&gt;::value, T&gt;::type
10758 abs(const T&amp; x) {
10759   return x &lt; T() ? -x : x;
10760 }
10761 </pre></blockquote>
10762
10763 <p>
10764 Here we have the possibility to provide a general <tt>abs</tt> function
10765 template that can be used in ICE's if it's argument is a literal
10766 type which's value is a constant expression, otherwise we
10767 have an optimized version for arguments which are expensive
10768 to copy and therefore need the usage of arguments of
10769 reference type (instead of <tt>const T&amp;</tt> we could decide to
10770 use <tt>T&amp;&amp;</tt>, but that is another issue).
10771 </p>
10772
10773 <p><i>[
10774 Alisdair is considering preparing a paper listing a number of missing
10775 type traits, and feels that it might be useful to handle them all
10776 together rather than piecemeal. This would affect issue 719 and 750.
10777 These two issues should move to OPEN pending AM paper on type traits.
10778 ]</i></p>
10779
10780
10781
10782
10783 <p><b>Proposed resolution:</b></p>
10784 <p>
10785 In 20.4.2 [meta.type.synop] in the group "type properties",
10786 just below the line
10787 </p>
10788
10789 <blockquote><pre>template &lt;class T&gt; struct is_pod;
10790 </pre></blockquote>
10791
10792 <p>
10793 add a new one:
10794 </p>
10795
10796 <blockquote><pre>template &lt;class T&gt; struct is_literal;
10797 </pre></blockquote>
10798
10799 <p>
10800 In 20.4.4.3 [meta.unary.prop], table Type Property Predicates, just
10801 below the line for the <tt>is_pod</tt> property add a new line:
10802 </p>
10803
10804 <table border="1">
10805 <tbody><tr>
10806 <th>Template</th><th>Condition</th><th>Preconditions</th>
10807 </tr>
10808 <tr>
10809 <td><tt>template &lt;class T&gt; struct is_literal;</tt></td>
10810 <td><tt>T</tt> is a literal type (3.9)</td>
10811 <td><tt>T</tt> shall be a complete type, an
10812 array of unknown bound, or
10813 (possibly cv-qualified) <tt>void</tt>.</td>
10814 </tr>
10815 </tbody></table>
10816
10817
10818
10819
10820
10821
10822 <hr>
10823 <h3><a name="720"></a>720. Omissions in constexpr usages</h3>
10824 <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#Open">Open</a>
10825  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-25</p>
10826 <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>
10827 <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>
10828 <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>
10829 <p><b>Discussion:</b></p>
10830 <ol>
10831 <li>
10832 The member function <tt>bool array&lt;T,N&gt;::empty() const</tt> should be a
10833 <tt>constexpr</tt> because this is easily to proof and to implement following it's operational
10834 semantics defined by Table 87 (Container requirements) which says: <tt>a.size() == 0</tt>.
10835 </li>
10836 <li>
10837 The member function <tt>bool bitset&lt;N&gt;::test() const</tt> must be a
10838 <tt>constexpr</tt> (otherwise it would violate the specification of <tt>constexpr
10839 bitset&lt;N&gt;::operator[](size_t) const</tt>, because it's return clause delegates to <tt>test()</tt>).
10840 </li>
10841 <li>
10842 I wonder how the constructor <tt>bitset&lt;N&gt;::bitset(unsigned long)</tt> can
10843 be declared as a <tt>constexpr</tt>. Current implementations usually have no such <tt>bitset</tt>
10844 c'tor which would fulfill the requirements of a <tt>constexpr</tt> c'tor because they have a
10845 non-empty c'tor body that typically contains for-loops or <tt>memcpy</tt> to compute the
10846 initialisation. What have I overlooked here?
10847 </li>
10848 </ol>
10849
10850
10851 <p><b>Proposed resolution:</b></p>
10852 <ol>
10853 <li>
10854 <p>In the class template definition of 23.2.1 [array]/p. 3 change</p>
10855 <blockquote><pre><ins>constexpr</ins> bool empty() const;
10856 </pre></blockquote>
10857 </li>
10858
10859 <li>
10860 <p>In the class template definition of 23.3.5 [template.bitset]/p. 1 change</p>
10861 <blockquote><pre><ins>constexpr</ins> bool test(size_t pos ) const;
10862 </pre></blockquote>
10863
10864 <p>
10865 and in 23.3.5.2 [bitset.members] change
10866 </p>
10867
10868 <blockquote><pre><ins>constexpr</ins> bool test(size_t pos ) const;
10869 </pre></blockquote>
10870
10871 </li>
10872 </ol>
10873
10874
10875
10876
10877
10878 <hr>
10879 <h3><a name="721"></a>721. <tt>wstring_convert</tt> inconsistensies</h3>
10880 <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>
10881  <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-27</p>
10882 <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>
10883 <p><b>Discussion:</b></p>
10884 <p>
10885 Paragraph 3 says that the <tt>Codecvt</tt> template parameter shall meet the
10886 requirements of <tt>std::codecvt</tt>, even though <tt>std::codecvt</tt> itself cannot
10887 be used (because of a protected destructor).
10888 </p>
10889
10890 <p>
10891 How are we going to explain this code to beginning programmers?
10892 </p>
10893
10894 <blockquote><pre>template&lt;class I, class E, class S&gt;
10895 struct codecvt : std::codecvt&lt;I, E, S&gt;
10896 {
10897     ~codecvt()
10898     { }
10899 };
10900
10901 void main()
10902 {
10903     std::wstring_convert&lt;codecvt&lt;wchar_t, char, std::mbstate_t&gt; &gt; compiles_ok;
10904
10905     std::wstring_convert&lt;std::codecvt&lt;wchar_t, char, std::mbstate_t&gt; &gt;   not_ok;
10906 }
10907 </pre></blockquote>
10908
10909
10910
10911 <p><b>Proposed resolution:</b></p>
10912 <p>
10913 </p>
10914
10915
10916
10917
10918
10919 <hr>
10920 <h3><a name="722"></a>722. Missing [c.math] functions <tt>nanf</tt> and <tt>nanl</tt></h3>
10921 <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#Ready">Ready</a>
10922  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-27</p>
10923 <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>
10924 <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>
10925 <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>
10926 <p><b>Discussion:</b></p>
10927 <p>
10928 In the listing of 26.7 [c.math], table 108: Header <tt>&lt;cmath&gt;</tt> synopsis I miss
10929 the following C99 functions (from 7.12.11.2):
10930 </p>
10931
10932 <blockquote><pre>float nanf(const char *tagp);
10933 long double nanl(const char *tagp);
10934 </pre></blockquote>
10935
10936 <p>
10937 (Note: These functions cannot be overloaded and they are also not
10938 listed anywhere else)
10939 </p>
10940
10941
10942 <p><b>Proposed resolution:</b></p>
10943 <p>
10944 In 26.7 [c.math], table 108, section "Functions", add <tt>nanf</tt> and <tt>nanl</tt>
10945 just after the existing entry <tt>nan</tt>.
10946 </p>
10947
10948
10949
10950
10951
10952 <hr>
10953 <h3><a name="723"></a>723. <tt>basic_regex</tt> should be moveable</h3>
10954 <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>
10955  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-29</p>
10956 <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>
10957 <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>
10958 <p><b>Discussion:</b></p>
10959 <p>
10960 According to the current state of the standard draft, the class
10961 template <tt>basic_regex</tt>, as described in 28.8 [re.regex]/3, is
10962 neither <tt>MoveConstructible</tt> nor <tt>MoveAssignable</tt>.
10963 IMO it should be, because typical regex state machines tend
10964 to have a rather large data quantum and I have seen several
10965 use cases, where a factory function returns regex values,
10966 which would take advantage of moveabilities.
10967 </p>
10968
10969
10970 <p><b>Proposed resolution:</b></p>
10971 <ol type="a">
10972 <li>
10973 <p>
10974 In the header <tt>&lt;regex&gt;</tt> synopsis 28.4 [re.syn], just below the function
10975 template <tt>swap</tt> add two further overloads:
10976 </p>
10977 <blockquote><pre>template &lt;class charT, class traits&gt;
10978   void swap(basic_regex&lt;charT, traits&gt;&amp; e1,  basic_regex&lt;charT, traits&gt;&amp; e2);
10979 <ins>template &lt;class charT, class traits&gt;
10980   void swap(basic_regex&lt;charT, traits&gt;&amp;&amp; e1, basic_regex&lt;charT, traits&gt;&amp; e2);
10981 template &lt;class charT, class traits&gt;
10982   void swap(basic_regex&lt;charT, traits&gt;&amp; e1,  basic_regex&lt;charT, traits&gt;&amp;&amp; e2);</ins>
10983 </pre></blockquote>
10984 <p>
10985 In the class definition of <tt>basic_regex</tt>, just below 28.8 [re.regex]/3,
10986 perform the following changes:
10987 </p>
10988 </li>
10989
10990 <li>
10991 <p>Just after the copy c'tor:</p>
10992 <blockquote><pre>basic_regex(basic_regex&amp;&amp;);
10993 </pre></blockquote>
10994 </li>
10995
10996 <li>
10997 <p>Just after the copy-assignment op.:</p>
10998 <blockquote><pre>basic_regex&amp; operator=(basic_regex&amp;&amp;);
10999 </pre></blockquote>
11000 </li>
11001
11002 <li>
11003 <p>Just after the first <tt>assign</tt> overload insert:</p>
11004 <blockquote><pre>basic_regex&amp; assign(basic_regex&amp;&amp; that);
11005 </pre></blockquote>
11006 </li>
11007
11008 <li>
11009 <p>Change the current <tt>swap</tt> function to read:</p>
11010 <blockquote><pre>void swap(basic_regex&amp;&amp;);
11011 </pre></blockquote>
11012 </li>
11013
11014 <li>
11015 <p>In 28.8.2 [re.regex.construct], just below the copy c'tor add a
11016 corresponding member definition of:</p>
11017 <blockquote><pre>basic_regex(basic_regex&amp;&amp;);
11018 </pre></blockquote>
11019 </li>
11020
11021 <li>
11022 <p>Also in 28.8.2 [re.regex.construct], just below the copy assignment
11023 c'tor add a corresponding member definition of:</p>
11024 <blockquote><pre>basic_regex&amp; operator=(basic_regex&amp;&amp;);
11025 </pre></blockquote>
11026 </li>
11027
11028 <li>
11029 <p>In 28.8.3 [re.regex.assign], just below the first <tt>assign</tt> overload add
11030 a corresponding member definition of:</p>
11031 <blockquote><pre>basic_regex&amp; assign(basic_regex&amp;&amp; that);
11032 </pre></blockquote>
11033 </li>
11034
11035 <li>
11036 <p>In 28.8.6 [re.regex.swap], change the signature of <tt>swap</tt> to
11037 say:</p>
11038 <blockquote><pre>void swap(basic_regex&amp;&amp; e);
11039 </pre></blockquote>
11040 </li>
11041
11042 <li>
11043 <p>In 28.8.7.1 [re.regex.nmswap], just below the single binary <tt>swap</tt>
11044 function, add the two missing overloads:</p>
11045 <blockquote><pre>template &lt;class charT, class traits&gt;
11046   void swap(basic_regex&lt;charT, traits&gt;&amp;&amp; e1, basic_regex&lt;charT, traits&gt;&amp; e2);
11047 template &lt;class charT, class traits&gt;
11048   void swap(basic_regex&lt;charT, traits&gt;&amp; e1, basic_regex&lt;charT, traits&gt;&amp;&amp; e2);
11049 </pre></blockquote>
11050 </li>
11051 </ol>
11052
11053 <p>
11054 Of course there would be need of corresponding proper standardese
11055 to describe these additions.
11056 </p>
11057
11058
11059
11060
11061
11062
11063 <hr>
11064 <h3><a name="724"></a>724. <tt>DefaultConstructible</tt> is not defined</h3>
11065 <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#Open">Open</a>
11066  <b>Submitter:</b> Pablo Halpern <b>Date:</b> 2007-09-12</p>
11067 <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>
11068 <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>
11069 <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>
11070 <p><b>Discussion:</b></p>
11071 <p>
11072 The <tt>DefaultConstructible</tt> requirement is referenced in
11073 several places in the August 2007 working draft
11074 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2369.pdf">N2369</a>,
11075 but is not defined anywhere.
11076 </p>
11077
11078 <p><i>[
11079 Bellevue:
11080 ]</i></p>
11081
11082
11083 <blockquote>
11084 <p>
11085 Walking into the default/value-initialization mess...
11086 </p>
11087 <p>
11088 Why two lines? Because we need both expressions to be valid.
11089 </p>
11090 <p>
11091 AJM not sure what the phrase "default constructed" means. This is
11092 unfortunate, as the phrase is already used 24 times in the library!
11093 </p>
11094 <p>
11095 Example: const int would not accept first line, but will accept the second.
11096 </p>
11097 <p>
11098 This is an issue that must be solved by concepts, but we might need to solve it independantly first.
11099 </p>
11100 <p>
11101 It seems that the requirements are the syntax in the proposed first
11102 column is valid, but not clear what semantics we need.
11103 </p>
11104 <p>
11105 A table where there is no post-condition seems odd, but appears to sum up our position best.
11106 </p>
11107 <p>
11108 At a minimum an object is declared and is destuctible.
11109 </p>
11110 <p>
11111 Move to open, as no-one happy to produce wording on the fly.
11112 </p>
11113 </blockquote>
11114
11115
11116 <p><b>Proposed resolution:</b></p>
11117 <p>
11118 In section 20.1.1 [utility.arg.requirements], before table 33, add the
11119 following table:
11120 </p>
11121
11122 <p style="text-align: center;" align="center">Table 33: <tt>DefaultConstructible</tt> requirements</p>
11123
11124 <div align="center">
11125
11126 <table style="border-collapse: collapse;" border="0" cellpadding="0" cellspacing="0">
11127  <tbody><tr>
11128   <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">
11129   <p style="margin: 0in 0in 0.0001pt; text-align: center;" align="center">expression</p>
11130   </td>
11131   <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">
11132   <p style="margin: 0in 0in 0.0001pt; text-align: center;" align="center">post-condition</p>
11133   </td>
11134  </tr>
11135  <tr>
11136   <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">
11137   <p style="margin: 0in 0in 0.0001pt;"><tt>T
11138   t;</tt><br>
11139   <tt>T()</tt></p>
11140   </td>
11141   <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">
11142   <p style="margin: 0in 0in 0.0001pt;"><tt>T</tt>
11143   is <i>default constructed.</i></p>
11144   </td>
11145  </tr>
11146 </tbody></table>
11147
11148 </div>
11149
11150
11151
11152
11153
11154
11155 <hr>
11156 <h3><a name="726"></a>726. Missing <tt>regex_replace()</tt> overloads</h3>
11157 <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>
11158  <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2007-09-22</p>
11159 <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>
11160 <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>
11161 <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>
11162 <p><b>Discussion:</b></p>
11163 <p>
11164 Two overloads of <tt>regex_replace()</tt> are currently provided:
11165 </p>
11166
11167 <blockquote><pre>template &lt;class OutputIterator, class BidirectionalIterator,
11168     class traits, class charT&gt;
11169   OutputIterator
11170   regex_replace(OutputIterator out,
11171                 BidirectionalIterator first, BidirectionalIterator last,
11172                 const basic_regex&lt;charT, traits&gt;&amp; e,
11173                 const basic_string&lt;charT&gt;&amp; fmt,
11174                 regex_constants::match_flag_type flags =
11175                   regex_constants::match_default);
11176
11177 template &lt;class traits, class charT&gt;
11178   basic_string&lt;charT&gt;
11179   regex_replace(const basic_string&lt;charT&gt;&amp; s,
11180                 const basic_regex&lt;charT, traits&gt;&amp; e,
11181                 const basic_string&lt;charT&gt;&amp; fmt,
11182                 regex_constants::match_flag_type flags =
11183                   regex_constants::match_default);
11184 </pre></blockquote>
11185
11186 <ol>
11187 <li>Overloads taking <tt>const charT *</tt> are provided for <tt>regex_match()</tt> and
11188 <tt>regex_search()</tt>, but not <tt>regex_replace()</tt>.  This is inconsistent.</li>
11189 <li>
11190 <p>The absence of <tt>const charT *</tt> overloads prevents ordinary-looking code from compiling, such as:</p>
11191
11192 <blockquote><pre>const string s("kitten");
11193 const regex r("en");
11194 cout &lt;&lt; regex_replace(s, r, "y") &lt;&lt; endl;
11195 </pre></blockquote>
11196
11197 <p>
11198 The compiler error message will be something like "could not deduce
11199 template argument for 'const std::basic_string&lt;_Elem&gt; &amp;' from 'const
11200 char[1]'".
11201 </p>
11202
11203 <p>
11204 Users expect that anything taking a <tt>basic_string&lt;charT&gt;</tt> can also take a
11205 <tt>const charT *</tt>.  In their own code, when they write a function taking
11206 <tt>std::string</tt> (or <tt>std::wstring</tt>), they can pass a <tt>const char *</tt> (or <tt>const
11207 wchar_t *</tt>), thanks to <tt>basic_string</tt>'s implicit constructor.  Because the
11208 regex algorithms are templated on <tt>charT</tt>, they can't rely on
11209 <tt>basic_string</tt>'s implicit constructor (as the compiler error message
11210 indicates, template argument deduction fails first).
11211 </p>
11212
11213 <p>
11214 If a user figures out what the compiler error message means, workarounds
11215 are available - but they are all verbose.  Explicit template arguments
11216 could be given to <tt>regex_replace()</tt>, allowing <tt>basic_string</tt>'s implicit
11217 constructor to be invoked - but <tt>charT</tt> is the last template argument, not
11218 the first, so this would be extremely verbose.  Therefore, constructing
11219 a <tt>basic_string</tt> from each C string is the simplest workaround.
11220 </p>
11221 </li>
11222
11223 <li>
11224 There is an efficiency consideration: constructing <tt>basic_string</tt>s can
11225 impose performance costs that could be avoided by a library
11226 implementation taking C strings and dealing with them directly.
11227 (Currently, for replacement sources, C strings can be converted into
11228 iterator pairs at the cost of verbosity, but for format strings, there
11229 is no way to avoid constructing a <tt>basic_string</tt>.)
11230 </li>
11231 </ol>
11232
11233
11234
11235 <p><b>Proposed resolution:</b></p>
11236 <p>
11237 Provide additional overloads for <tt>regex_replace()</tt>: one additional
11238 overload of the iterator-based form (taking <tt>const charT* fmt</tt>), and three
11239 additional overloads of the convenience form (one taking <tt>const charT*
11240 str</tt>, another taking <tt>const charT* fmt</tt>, and the third taking both <tt>const
11241 charT* str</tt> and <tt>const charT* fmt</tt>).  28.11.4 [re.alg.replace]:
11242 </p>
11243
11244 <blockquote>
11245 <pre>template &lt;class OutputIterator, class BidirectionalIterator,
11246     class traits, class charT&gt;
11247   OutputIterator
11248   regex_replace(OutputIterator out,
11249                 BidirectionalIterator first, BidirectionalIterator last,
11250                 const basic_regex&lt;charT, traits&gt;&amp; e,
11251                 const basic_string&lt;charT&gt;&amp; fmt,
11252                 regex_constants::match_flag_type flags =
11253                   regex_constants::match_default);
11254
11255 <ins>template &lt;class OutputIterator, class BidirectionalIterator,
11256     class traits, class charT&gt;
11257   OutputIterator
11258   regex_replace(OutputIterator out,
11259                 BidirectionalIterator first, BidirectionalIterator last,
11260                 const basic_regex&lt;charT, traits&gt;&amp; e,
11261                 const charT* fmt,
11262                 regex_constants::match_flag_type flags =
11263                   regex_constants::match_default);</ins>
11264 </pre>
11265 <p>...</p>
11266 <pre>template &lt;class traits, class charT&gt;
11267   basic_string&lt;charT&gt;
11268   regex_replace(const basic_string&lt;charT&gt;&amp; s,
11269                 const basic_regex&lt;charT, traits&gt;&amp; e,
11270                 const basic_string&lt;charT&gt;&amp; fmt,
11271                 regex_constants::match_flag_type flags =
11272                   regex_constants::match_default);
11273
11274 <ins>template &lt;class traits, class charT&gt;
11275   basic_string&lt;charT&gt;
11276   regex_replace(const basic_string&lt;charT&gt;&amp; s,
11277                 const basic_regex&lt;charT, traits&gt;&amp; e,
11278                 const charT* fmt,
11279                 regex_constants::match_flag_type flags =
11280                   regex_constants::match_default);</ins>
11281
11282 <ins>template &lt;class traits, class charT&gt;
11283   basic_string&lt;charT&gt;
11284   regex_replace(const charT* s,
11285                 const basic_regex&lt;charT, traits&gt;&amp; e,
11286                 const basic_string&lt;charT&gt;&amp; fmt,
11287                 regex_constants::match_flag_type flags =
11288                   regex_constants::match_default);</ins>
11289
11290 <ins>template &lt;class traits, class charT&gt;
11291   basic_string&lt;charT&gt;
11292   regex_replace(const charT* s,
11293                 const basic_regex&lt;charT, traits&gt;&amp; e,
11294                 const charT* fmt,
11295                 regex_constants::match_flag_type flags =
11296                   regex_constants::match_default);</ins>
11297 </pre>
11298 </blockquote>
11299
11300
11301
11302
11303
11304
11305 <hr>
11306 <h3><a name="727"></a>727. <tt>regex_replace()</tt> doesn't accept <tt>basic_string</tt>s with custom traits and allocators</h3>
11307 <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>
11308  <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2007-09-22</p>
11309 <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>
11310 <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>
11311 <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>
11312 <p><b>Discussion:</b></p>
11313 <p>
11314 <tt>regex_match()</tt> and <tt>regex_search()</tt> take <tt>const basic_string&lt;charT, ST,
11315 SA&gt;&amp;</tt>.  <tt>regex_replace()</tt> takes <tt>const basic_string&lt;charT&gt;&amp;</tt>.  This prevents
11316 <tt>regex_replace()</tt> from accepting <tt>basic_string</tt>s with custom traits and
11317 allocators.
11318 </p>
11319
11320
11321 <p><b>Proposed resolution:</b></p>
11322 <p>
11323 Overloads of <tt>regex_replace()</tt> taking <tt>basic_string</tt> should be additionally
11324 templated on <tt>class ST, class SA</tt> and take <tt>const basic_string&lt;charT, ST,
11325 SA&gt;&amp;</tt>.  Consistency with <tt>regex_match()</tt> and <tt>regex_search()</tt> would place
11326 <tt>class ST, class SA</tt> as the first template arguments; compatibility with
11327 existing code using TR1 and giving explicit template arguments to
11328 <tt>regex_replace()</tt> would place <tt>class ST, class SA</tt> as the last template
11329 arguments.
11330 </p>
11331
11332
11333
11334
11335
11336 <hr>
11337 <h3><a name="728"></a>728. Problem in [rand.eng.mers]/6</h3>
11338 <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#Review">Review</a>
11339  <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
11340 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng.mers">issues</a> in [rand.eng.mers].</p>
11341 <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>
11342 <p><b>Discussion:</b></p>
11343 <p>
11344 The <tt>mersenne_twister_engine</tt> is required to use a seeding method that is given
11345 as an algorithm parameterized over the number of bits <tt>W</tt>. I doubt whether the given generalization
11346 of an algorithm that was originally developed only for unsigned 32-bit integers is appropriate
11347 for other bit widths. For instance, <tt>W</tt> could be theoretically 16 and <tt>UIntType</tt> a 16-bit integer, in
11348 which case the given multiplier would not fit into the <tt>UIntType</tt>. Moreover, T. Nishimura and M.
11349 Matsumoto have chosen a dif ferent multiplier for their 64 bit Mersenne Twister
11350 [<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/VERSIONS/C-LANG/mt19937-64.c">reference</a>].
11351 </p>
11352
11353 <p>
11354 I see two possible resolutions:
11355 </p>
11356
11357 <ol type="a">
11358 <li>Restrict the parameter <tt>W</tt> of the <tt>mersenne_twister_template</tt> to values of 32 or 64 and use the
11359 multiplier from [the above reference] for the 64-bit case (my preference)</li>
11360 <li>Interpret the state array for any <tt>W</tt> as a 32-bit array of appropriate length (and a specified byte
11361 order) and always employ the 32-bit algorithm for seeding
11362 </li>
11363 </ol>
11364
11365 <p>
11366 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
11367 for further discussion.
11368 </p>
11369
11370 <p><i>[
11371 Bellevue:
11372 ]</i></p>
11373
11374
11375 <blockquote>
11376 <p>
11377 Stephan Tolksdorf has additional comments on N2424. He comments: "there
11378 is a typo in the required behaviour for mt19937_64: It should be the
11379 10000th (not 100000th) invocation whose value is given, and the value
11380 should be 9981545732273789042 (not 14002232017267485025)." These values
11381 need checking.
11382 </p>
11383 <p>
11384 Take the proposed recommendation in N2424 and move to REVIEW.
11385 </p>
11386 </blockquote>
11387
11388
11389
11390
11391 <p><b>Proposed resolution:</b></p>
11392
11393 <p>
11394 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
11395 for the proposed resolution.
11396 </p>
11397
11398 <p><i>[
11399 Stephan Tolksdorf adds pre-Bellevue:
11400 ]</i></p>
11401
11402
11403 <blockquote>
11404 I support the proposed resolution in
11405 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>,
11406 but there is a typo in the
11407 required behaviour for <tt>mt19937_64</tt>: It should be the 10000<sup>th</sup> (not
11408 100000<sup>th</sup>) invocation whose value is given, and the value should be
11409 9981545732273789042 (not 14002232017267485025). The change to para. 8
11410 proposed by Charles Karney should also be included in the proposed
11411 wording.
11412 </blockquote>
11413
11414
11415
11416
11417
11418
11419 <hr>
11420 <h3><a name="732"></a>732. Defect in [rand.dist.samp.genpdf]</h3>
11421 <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#Open">Open</a>
11422  <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
11423 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.genpdf">issues</a> in [rand.dist.samp.genpdf].</p>
11424 <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>
11425 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a></p>
11426 <p><b>Discussion:</b></p>
11427 <p>
11428 26.4.8.5.3 [rand.dist.samp.genpdf] describes the interface for a distribution template that is
11429 meant to simulate random numbers from any general distribution given only the density and the
11430 support of the distribution. I'm not aware of any general purpose algorithm that would be capable
11431 of correctly and efficiently implementing the described functionality. From what I know, this is
11432 essentially an unsolved research problem. Existing algorithms either require more knowledge
11433 about the distribution and the problem domain or work only under very limited circumstances.
11434 Even the state of the art special purpose library UNU.RAN does not solve the problem in full
11435 generality, and in any case, testing and customer support for such a library feature would be a
11436 nightmare.
11437 </p>
11438
11439 <p>
11440 <b>Possible resolution:</b> For these reasons, I propose to delete section 26.4.8.5.3 [rand.dist.samp.genpdf].
11441 </p>
11442
11443 <p><i>[
11444 Bellevue:
11445 ]</i></p>
11446
11447
11448 <blockquote>
11449 <p>
11450 Disagreement persists.
11451 </p>
11452 <p>
11453 Objection to this issue is that this function takes a general functor.
11454 The general approach would be to normalize this function, integrate it,
11455 and take the inverse of the integral, which is not possible in general.
11456 An example function is sin(1+n*x) -- for any spatial frequency that the
11457 implementor chooses, there is a value of n that renders that choice
11458 arbitrarily erroneous.
11459 </p>
11460 <p>
11461 Correction: The formula above should instead read 1+sin(n*x).
11462 </p>
11463 <p>
11464 Objector proposes the following possible compromise positions:
11465 </p>
11466 <ul>
11467 <li>
11468 rand.dist.samp.genpdf takes an number of points so that implementor need not guess.
11469 </li>
11470 <li>replace rand.disk.samp.genpdf with an extension to either or both
11471 of the discrete functions to take arguments that take a functor and
11472 number of points in place of the list of probabilities. Reference
11473 issues 793 and 794.
11474 </li>
11475 </ul>
11476 </blockquote>
11477
11478
11479
11480 <p><b>Proposed resolution:</b></p>
11481 <p>
11482 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
11483 for the proposed resolution.
11484 </p>
11485
11486
11487
11488
11489
11490 <hr>
11491 <h3><a name="734"></a>734. Unnecessary restriction in [rand.dist.norm.chisq]</h3>
11492 <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#Open">Open</a>
11493  <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
11494 <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>
11495 <p><b>Discussion:</b></p>
11496 <p>
11497 <tt>chi_squared_distribution</tt>, <tt>fisher_f_distribution</tt> and <tt>student_t_distribution</tt>
11498 have parameters for the "degrees of freedom" <tt>n</tt> and <tt>m</tt> that are specified as integers. For the
11499 following two reasons this is an unnecessary restriction: First, in many applications such as
11500 Bayesian inference or Monte Carlo simulations it is more convenient to treat the respective param-
11501 eters as continuous variables. Second, the standard non-naive algorithms (i.e.
11502 O(1) algorithms)
11503 for simulating from these distributions work with floating-point parameters anyway (all three
11504 distributions could be easily implemented using the Gamma distribution, for instance).
11505 </p>
11506
11507 <p>
11508 Similar arguments could in principle be made for the parameters <tt>t</tt> and <tt>k</tt> of the discrete
11509 <tt>binomial_distribution</tt> and <tt>negative_binomial_distribution</tt>, though in both cases continuous
11510 parameters are less frequently used in practice and in case of the <tt>binomial_distribution</tt>
11511 the implementation would be significantly complicated by a non-discrete parameter (in most
11512 implementations one would need an approximation of the log-gamma function instead of just the
11513 log-factorial function).
11514 </p>
11515
11516 <p>
11517 <b>Possible resolution:</b> For these reasons, I propose to change the type of the respective parameters
11518 to double.
11519 </p>
11520
11521 <p><i>[
11522 Bellevue:
11523 ]</i></p>
11524
11525
11526 <blockquote>
11527 In N2424. Not wildly enthusiastic, not really felt necessary. Less
11528 frequently used in practice. Not terribly bad either. Move to OPEN.
11529 </blockquote>
11530
11531
11532 <p><b>Proposed resolution:</b></p>
11533 <p>
11534 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
11535 for the proposed resolution.
11536 </p>
11537
11538 <p><i>[
11539 Stephan Tolksdorf adds pre-Bellevue:
11540 ]</i></p>
11541
11542
11543 <blockquote>
11544 <p>
11545 In 26.4.8.4.3 [rand.dist.norm.chisq]:
11546 </p>
11547
11548 <blockquote>
11549 <p>
11550 Delete ", where <tt>n</tt> is a positive integer" in the first paragraph.
11551 </p>
11552
11553 <p>
11554 Replace both occurrences of "<tt>explicit chi_squared_distribution(int n = 1);</tt>"
11555 with "<tt>explicit chi_squared_distribution(RealType n = 1);</tt>".
11556 </p>
11557
11558 <p>
11559 Replace both occurrences of "<tt>int n() const;</tt>" with "<tt>RealType n() const;</tt>".
11560 </p>
11561
11562 </blockquote>
11563
11564 <p>
11565 In 26.4.8.4.5 [rand.dist.norm.f]:
11566 </p>
11567 <blockquote>
11568 <p>
11569 Delete ", where <tt>m</tt> and <tt>n</tt> are positive integers" in the first paragraph.
11570 </p>
11571
11572 <p>
11573 Replace both occurrences of
11574 </p>
11575 <blockquote><pre>explicit fisher_f_distribution(int m = 1, int n = 1);
11576 </pre></blockquote>
11577 <p>
11578 with
11579 </p>
11580 <blockquote><pre>explicit fisher_f_distribution(RealType m = 1, RealType n = 1);
11581 </pre></blockquote>
11582
11583 <p>
11584 Replace both occurrences of "<tt>int m() const;" with "RealType m() const;</tt>".
11585 </p>
11586
11587 <p>
11588 Replace both occurrences of "<tt>int n() const;" with "RealType n() const;</tt>".
11589 </p>
11590 </blockquote>
11591
11592 <p>
11593 In 26.4.8.4.6 [rand.dist.norm.t]:
11594 </p>
11595
11596 <blockquote>
11597 <p>
11598 Delete ", where <tt>n</tt> is a positive integer" in the first paragraph.
11599 </p>
11600
11601 <p>
11602 Replace both occurrences of "<tt>explicit student_t_distribution(int n = 1);</tt>"
11603 with "<tt>explicit student_t_distribution(RealType n = 1);</tt>".
11604 </p>
11605
11606 <p>
11607 Replace both occurrences of "<tt>int n() const;</tt>" with "<tt>RealType n() const;</tt>".
11608 </p>
11609 </blockquote>
11610
11611 </blockquote>
11612
11613
11614
11615
11616
11617 <hr>
11618 <h3><a name="740"></a>740. Please remove <tt>*_ptr&lt;T[N]&gt;</tt></h3>
11619 <p><b>Section:</b> 20.6.11.4 [unique.ptr.compiletime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
11620  <b>Submitter:</b> Herb Sutter <b>Date:</b> 2007-10-04</p>
11621 <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>
11622 <p><b>Discussion:</b></p>
11623 <p>
11624 Please don't provide <tt>*_ptr&lt;T[N]&gt;</tt>. It doesn't enable any useful
11625 bounds-checking (e.g., you could imagine that doing <tt>op++</tt> on a
11626 <tt>shared_ptr&lt;T[N]&gt;</tt> yields a <tt>shared_ptr&lt;T[N-1]&gt;</tt>, but that promising path
11627 immediately falters on <tt>op--</tt> which can't reliably dereference because we
11628 don't know the lower bound). Also, most buffers you'd want to point to
11629 don't have a compile-time known size.
11630 </p>
11631
11632 <p>
11633 To enable any bounds-checking would require run-time information, with
11634 the usual triplet: base (lower bound), current offset, and max offset
11635 (upper  bound). And I can sympathize with the point of view that you
11636 wouldn't want to require this on <tt>*_ptr</tt> itself. But please let's not
11637 follow the <tt>&lt;T[N]&gt;</tt> path, especially not with additional functions to
11638 query the bounds etc., because this sets wrong user expectations by
11639 embarking on a path that doesn't go all the way to bounds checking as it
11640 seems to imply.
11641 </p>
11642
11643 <p>
11644 If bounds checking is desired, consider a <tt>checked_*_ptr</tt> instead (e.g.,
11645 <tt>checked_shared_ptr</tt>). And make the interfaces otherwise identical so that
11646 user code could easily <tt>#define/typedef</tt> between prepending <tt>checked_</tt> on
11647 debug builds and not doing so on release builds (for example).
11648 </p>
11649
11650 <p>
11651 Note that some may object that <tt>checked_*_ptr</tt> may seem to make the smart
11652 pointer more like <tt>vector</tt>, and we don't want two ways to spell <tt>vector</tt>. I
11653 don't agree, but if that were true that would be another reason to
11654 remove <tt>*_ptr&lt;T[N]&gt;</tt> which equally makes the smart pointer more like
11655 <tt>std::array.</tt> :-)
11656 </p>
11657
11658 <p><i>[
11659 Bellevue:
11660 ]</i></p>
11661
11662
11663 <blockquote>
11664 <p>Suggestion that fixed-size array instantiations are going to fail at
11665 compile time anyway (if we remove specialization) due to pointer decay,
11666 at least that appears to be result from available compilers.
11667 </p>
11668 <p>
11669 So concerns about about requiring static_assert seem unfounded.
11670 </p>
11671 <p>After a little more experimentation with compiler, it appears that
11672 fixed size arrays would only work at all if we supply these explicit
11673 specialization. So removing them appears less breaking than originally
11674 thought.
11675 </p>
11676 <p>
11677 straw poll unanimous move to Ready.
11678 </p>
11679 </blockquote>
11680
11681
11682
11683 <p><b>Proposed resolution:</b></p>
11684 <p>
11685 Change the synopsis under 20.6.11 [unique.ptr] p2:
11686 </p>
11687
11688 <blockquote><pre>...
11689 template&lt;class T&gt; struct default_delete;
11690 template&lt;class T&gt; struct default_delete&lt;T[]&gt;;
11691 <del>template&lt;class T, size_t N&gt; struct default_delete&lt;T[N]&gt;;</del>
11692
11693 template&lt;class T, class D = default_delete&lt;T&gt;&gt; class unique_ptr;
11694 template&lt;class T, class D&gt; class unique_ptr&lt;T[], D&gt;;
11695 <del>template&lt;class T, class D, size_t N&gt; class unique_ptr&lt;T[N], D&gt;;</del>
11696 ...
11697 </pre></blockquote>
11698
11699 <p>
11700 Remove the entire section 20.6.11.1.3 [unique.ptr.dltr.dflt2] <b><tt>default_delete&lt;T[N]&gt;</tt></b>.
11701 </p>
11702
11703 <p>
11704 Remove the entire section 20.6.11.4 [unique.ptr.compiletime] <b><tt>unique_ptr</tt> for array objects with a compile time length</b>
11705 and its subsections: 20.6.11.4.1 [unique.ptr.compiletime.dtor], 20.6.11.4.2 [unique.ptr.compiletime.observers],
11706 20.6.11.4.3 [unique.ptr.compiletime.modifiers].
11707 </p>
11708
11709
11710
11711
11712
11713
11714 <hr>
11715 <h3><a name="742"></a>742. Enabling <tt>swap</tt> for proxy iterators</h3>
11716 <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#Open">Open</a>
11717  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-10-10</p>
11718 <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>
11719 <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>
11720 <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>
11721 <p><b>Discussion:</b></p>
11722 <p>
11723 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
11724 deals with changing the requirements of <tt>T</tt> in the <tt>Swappable</tt>
11725 requirement from <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt> to
11726 <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.
11727 </p>
11728
11729 <p>
11730 This issue seeks to widen the <tt>Swappable</tt> requirement to support proxy iterators.  Here
11731 is example code:
11732 </p>
11733
11734 <blockquote><pre>namespace Mine {
11735
11736 template &lt;class T&gt;
11737 struct proxy {...};
11738
11739 template &lt;class T&gt;
11740 struct proxied_iterator
11741 {
11742    typedef T value_type;
11743    typedef proxy&lt;T&gt; reference;
11744    reference operator*() const;
11745    ...
11746 };
11747
11748 struct A
11749 {
11750    // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
11751    void swap(A&amp;);
11752    ...
11753 };
11754
11755 void swap(A&amp;, A&amp;);
11756 void swap(proxy&lt;A&gt;, A&amp;);
11757 void swap(A&amp;, proxy&lt;A&gt;);
11758 void swap(proxy&lt;A&gt;, proxy&lt;A&gt;);
11759
11760 }  // Mine
11761
11762 ...
11763
11764 Mine::proxied_iterator&lt;Mine::A&gt; i(...)
11765 Mine::A a;
11766 <b>swap(*i1, a);</b>
11767 </pre></blockquote>
11768
11769 <p>
11770 The key point to note in the above code is that in the call to <tt>swap</tt>, <tt>*i1</tt>
11771 and <tt>a</tt> are different types (currently types can only be <tt>Swappable</tt> with the
11772 same type).  A secondary point is that to support proxies, one must be able to pass rvalues
11773 to <tt>swap</tt>.  But note that I am not stating that the general purpose <tt>std::swap</tt>
11774 should accept rvalues!  Only that overloaded <tt>swap</tt>s, as in the example above, be allowed
11775 to take rvalues.
11776 </p>
11777
11778 <p>
11779 That is, no standard library code needs to change.  We simply need to have a more flexible
11780 definition of <tt>Swappable</tt>.
11781 </p>
11782
11783 <p><i>[
11784 Bellevue:
11785 ]</i></p>
11786
11787
11788 <blockquote>
11789 <p>
11790 While we believe Concepts work will define a swappable concept, we
11791 should still resolve this issue if possible to give guidance to the
11792 Concepts work.
11793 </p>
11794 <p>
11795 Would an ambiguous swap function in two namespaces found by ADL break
11796 this wording? Suggest that the phrase "valid expression" means such a
11797 pair of types would still not be swappable.
11798 </p>
11799 <p>
11800 Motivation is proxy-iterators, but facility is considerably more
11801 general. Are we happy going so far?
11802 </p>
11803 <p>
11804 We think this wording is probably correct and probably an improvement on
11805 what's there in the WP. On the other hand, what's already there in the
11806 WP is awfully complicated. Why do we need the two bullet points? They're
11807 too implementation-centric. They don't add anything to the semantics of
11808 what swap() means, which is there in the post-condition. What's wrong
11809 with saying that types are swappable if you can call swap() and it
11810 satisfies the semantics of swapping?
11811 </p>
11812 </blockquote>
11813
11814
11815
11816 <p><b>Proposed resolution:</b></p>
11817 <p>
11818 Change 20.1.1 [utility.arg.requirements]:
11819 </p>
11820
11821 <blockquote>
11822
11823 <p>
11824 -1- The template definitions in the C++ Standard Library refer to various
11825 named requirements whose details are set out in tables 31-38. In these
11826 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
11827 instantiating a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
11828 values of type <tt>const T</tt>; <tt>s</tt> and <tt>t</tt> are modifiable
11829 lvalues of type <tt>T</tt>; <tt>u</tt> is a value of type (possibly
11830 <tt>const</tt>) <tt>T</tt>; <del>and</del> <tt>rv</tt> is a non-<tt>const</tt>
11831 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>.
11832 </p>
11833
11834 <table border="1">
11835 <caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
11836 <tbody><tr><th>expression</th><th>return type</th><th>post-condition</th></tr>
11837 <tr><td><tt>swap(<del>s</del><ins>w</ins>,<del>t</del><ins>v</ins>)</tt></td><td><tt>void</tt></td>
11838 <td><del><tt>t</tt></del><ins><tt>w</tt></ins> has the value originally
11839 held by <del><tt>u</tt></del><ins><tt>v</tt></ins>, and
11840 <del><tt>u</tt></del><ins><tt>v</tt></ins> has the value originally held
11841 by <del><tt>t</tt></del><ins><tt>w</tt></ins></td></tr>
11842 <tr><td colspan="3">
11843 <p>
11844 The <tt>Swappable</tt> requirement is met by satisfying one or more of the following conditions:
11845 </p>
11846 <ul>
11847 <li>
11848 <tt>T</tt> is <tt>Swappable</tt> if <ins><tt>T</tt> and <tt>V</tt> are
11849 the same type and </ins> <tt>T</tt> satisfies the
11850 <del><tt>CopyConstructible</tt></del>
11851 <ins><tt>MoveConstructible</tt></ins> requirements (Table <del>34</del>
11852 <ins>33</ins>) and the <del><tt>CopyAssignable</tt></del>
11853 <ins><tt>MoveAssignable</tt></ins> requirements (Table <del>36</del>
11854 <ins>35</ins>);
11855 </li>
11856 <li>
11857 <tt>T</tt> is <tt>Swappable</tt> <ins>with <tt>V</tt></ins> if a namespace scope function named
11858 <tt>swap</tt> exists in the same namespace as the definition of
11859 <tt>T</tt> <ins>or <tt>V</tt></ins>, such that the expression
11860 <tt>swap(<del>t</del><ins>w</ins>,<del>u</del> <ins>v</ins>)</tt> is valid and has the
11861 semantics described in this table.
11862 </li>
11863 </ul>
11864 </td></tr>
11865 </tbody></table>
11866 </blockquote>
11867
11868
11869
11870
11871
11872
11873 <hr>
11874 <h3><a name="743"></a>743. rvalue <tt>swap</tt> for <tt>shared_ptr</tt></h3>
11875 <p><b>Section:</b> 20.6.12.2.9 [util.smartptr.shared.spec] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
11876  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-10-10</p>
11877 <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>
11878 <p><b>Discussion:</b></p>
11879 <p>
11880 When the LWG looked at <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a> in Kona the following note was made:
11881 </p>
11882
11883 <blockquote><p>
11884 We may need to open an issue to deal with the question of
11885 whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>.
11886 </p></blockquote>
11887
11888 <p>
11889 This issue was opened in response to that note.
11890 </p>
11891
11892 <p>
11893 I believe allowing rvalue <tt>shared_ptr</tt>s to <tt>swap</tt> is both
11894 appropriate, and consistent with how other library components are currently specified.
11895 </p>
11896
11897 <p><i>[
11898 Bellevue:
11899 ]</i></p>
11900
11901
11902 <blockquote>
11903 <p>
11904 Concern that the three signatures for swap is needlessly complicated,
11905 but this issue merely brings shared_ptr into equal complexity with the
11906 rest of the library. Will open a new issue for concern about triplicate
11907 signatures.
11908 </p>
11909 <p>
11910 Adopt issue as written.
11911 </p>
11912 </blockquote>
11913
11914
11915 <p><b>Proposed resolution:</b></p>
11916 <p>
11917 Change the synopsis in 20.6.12.2 [util.smartptr.shared]:
11918 </p>
11919
11920 <blockquote><pre>void swap(shared_ptr&amp;<ins>&amp;</ins> r);
11921 ...
11922 template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp; b);
11923 <ins>template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp;&amp; a, shared_ptr&lt;T&gt;&amp; b);
11924 template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp;&amp; b);</ins>
11925 </pre></blockquote>
11926
11927 <p>
11928 Change 20.6.12.2.4 [util.smartptr.shared.mod]:
11929 </p>
11930
11931 <blockquote><pre>void swap(shared_ptr&amp;<ins>&amp;</ins> r);
11932 </pre></blockquote>
11933
11934 <p>
11935 Change 20.6.12.2.9 [util.smartptr.shared.spec]:
11936 </p>
11937
11938 <blockquote><pre>template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp; b);
11939 <ins>template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp;&amp; a, shared_ptr&lt;T&gt;&amp; b);
11940 template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp;&amp; b);</ins>
11941 </pre></blockquote>
11942
11943
11944
11945
11946
11947 <hr>
11948 <h3><a name="744"></a>744. What is the lifetime of an exception pointed to by an exception_ptr?</h3>
11949 <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#Ready">Ready</a>
11950  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
11951 <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>
11952 <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>
11953 <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>
11954 <p><b>Discussion:</b></p>
11955 <p>
11956 Without some lifetime guarantee, it is hard to know how this type can be
11957 used.  Very specifically, I don't see how the current wording would
11958 guarantee and exception_ptr caught at the end of one thread could be safely
11959 stored and rethrown in another thread - the original motivation for this
11960 API.
11961 </p>
11962 <p>
11963 (Peter Dimov agreed it should be clearer, maybe a non-normative note to
11964 explain?)
11965 </p>
11966
11967 <p><i>[
11968 Bellevue:
11969 ]</i></p>
11970
11971
11972 <blockquote>
11973 <p>
11974 Agree the issue is real.
11975 </p>
11976 <p>
11977 Intent is lifetime is similar to a shared_ptr (and we might even want to
11978 consider explicitly saying that it is a shared_ptr&lt; unspecified type &gt;).
11979 </p>
11980 <p>
11981 We expect that most implementations will use shared_ptr, and the
11982 standard should be clear that the exception_ptr type is intended to be
11983 something whose semantics are smart-pointer-like so that the user does
11984 not need to worry about lifetime management. We still need someone to
11985 draught those words - suggest emailing Peter Dimov.
11986 </p>
11987 <p>
11988 Move to Open.
11989 </p>
11990 </blockquote>
11991
11992
11993 <p><b>Proposed resolution:</b></p>
11994 <p>
11995 Change 18.7.5 [propagation]/7:
11996 </p>
11997
11998 <blockquote>
11999 -7- Returns: An <tt>exception_ptr</tt> object that refers to the currently
12000 handled exception or a copy of the currently handled exception, or a
12001 null <tt>exception_ptr</tt> object if no exception is being handled.
12002 <ins>The referenced object remains valid at least as long as there is an
12003 <tt>exception_ptr</tt> that refers to it.</ins>
12004 If the function needs to allocate memory and the attempt
12005 fails, it returns an <tt>exception_ptr</tt> object that refers to an instance of
12006 <tt>bad_alloc</tt>. It is unspecified whether the return values of two successive
12007 calls to <tt>current_exception</tt> refer to the same exception object. [<i>Note:</i>
12008 that is, it is unspecified whether <tt>current_exception</tt> creates a new copy
12009 each time it is called. <i>--end note</i>]
12010 </blockquote>
12011
12012
12013
12014
12015
12016 <hr>
12017 <h3><a name="746"></a>746. current_exception may fail with bad_alloc</h3>
12018 <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#Ready">Ready</a>
12019  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
12020 <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>
12021 <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>
12022 <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>
12023 <p><b>Discussion:</b></p>
12024 <p>
12025 I understand that the attempt to copy an exception may run out of memory,
12026 but I believe this is the only part of the standard that mandates failure
12027 with specifically <tt>bad_alloc</tt>, as opposed to allowing an
12028 implementation-defined type derived from <tt>bad_alloc</tt>.  For instance, the Core
12029 language for a failed new expression is:
12030 </p>
12031 <blockquote>
12032 <p>
12033 Any other allocation function that fails to allocate storage shall indicate
12034 failure only by throwing an exception of a type that would match a handler
12035 (15.3) of type <tt>std::bad_alloc</tt> (18.5.2.1).
12036 </p>
12037 </blockquote>
12038 <p>
12039 I think we should allow similar freedom here (or add a blanket
12040 compatible-exception freedom paragraph in 17)
12041 </p>
12042 <p>
12043 I prefer the clause 17 approach myself, and maybe clean up any outstanding
12044 wording that could also rely on it.
12045 </p>
12046 <p>
12047 Although filed against a specific case, this issue is a problem throughout
12048 the library.
12049 </p>
12050
12051 <p><i>[
12052 Bellevue:
12053 ]</i></p>
12054
12055
12056 <blockquote>
12057 <p>
12058 Is issue bigger than library?
12059 </p>
12060 <p>
12061 No - Core are already very clear about their wording, which is inspiration for the issue.
12062 </p>
12063 <p>
12064 While not sold on the original 18.7.5 use case, the generalised 17.4.4.8 wording is the real issue.
12065 </p>
12066 <p>
12067 Accept the broad view and move to ready
12068 </p>
12069 </blockquote>
12070
12071
12072 <p><b>Proposed resolution:</b></p>
12073 <p>
12074 Add the following exemption clause to 17.4.4.8 [res.on.exception.handling]:
12075 </p>
12076
12077 <blockquote>
12078 A function may throw a type not listed in its <i>Throws</i> clause so long as it is
12079 derived from a class named in the <i>Throws</i> clause, and would be caught by an
12080 exception handler for the base type.
12081 </blockquote>
12082
12083
12084
12085
12086
12087 <hr>
12088 <h3><a name="747"></a>747. We have 3 separate type traits to identify classes supporting no-throw operations</h3>
12089 <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#Open">Open</a>
12090  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
12091 <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>
12092 <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>
12093 <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>
12094 <p><b>Discussion:</b></p>
12095 <p>
12096 We have 3 separate type traits to identify classes supporting no-throw
12097 operations, which are very useful when trying to provide exception safety
12098 guarantees.  However, I'm not entirely clear on what the current wording
12099 requires of a conforming implementation.  To quote from
12100 <tt>has_nothrow_default_constructor</tt>:
12101 </p>
12102 <blockquote><p>
12103 or <tt>T</tt> is a class type with a default constructor that is known not to throw
12104 any exceptions
12105 </p></blockquote>
12106 <p>
12107 What level of magic do we expect to deduce if this is known?
12108 </p>
12109 <p>
12110 E.g.
12111 </p>
12112
12113 <blockquote><pre>struct test{
12114  int x;
12115  test() : x() {}
12116 };
12117 </pre></blockquote>
12118 <p>
12119 Should I expect a conforming compiler to
12120  <tt>assert( has_nothrow_constructor&lt;test&gt;::value )</tt>
12121 </p>
12122 <p>
12123 Is this a QoI issue?
12124 </p>
12125 <p>
12126 Should I expect to 'know' only if-and-only-if there is an inline definition
12127 available?
12128 </p>
12129 <p>
12130 Should I never expect that to be true, and insist that the user supplies an
12131 empty throw spec if they want to assert the no-throw guarantee?
12132 </p>
12133 <p>
12134 It would be helpful to maybe have a footnote explaining what is required,
12135 but right now I don't know what to suggest putting in the footnote.
12136 </p>
12137 <p>
12138 (agreement since is that trivial ops and explicit no-throws are required.
12139 Open if QoI should be allowed to detect further)
12140 </p>
12141
12142 <p><i>[
12143 Bellevue:
12144 ]</i></p>
12145
12146
12147 <blockquote>
12148 This looks like a QoI issue.
12149 In the case of trivial and nothrow it is known. Static analysis of the program is definitely into QoI.
12150 Move to OPEN. Need to talk to Core about this.
12151 </blockquote>
12152
12153
12154 <p><b>Proposed resolution:</b></p>
12155 <p>
12156 </p>
12157
12158
12159
12160
12161
12162 <hr>
12163 <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>
12164 <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#Ready">Ready</a>
12165  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
12166 <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>
12167 <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>
12168 <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>
12169 <p><b>Discussion:</b></p>
12170 <p>
12171 Unfortunately a class can have multiple copy constructors, and I believe to
12172 be useful this trait should only return true is ALL copy constructors are
12173 no-throw.
12174 </p>
12175 <p>
12176 For instance:
12177 </p>
12178 <blockquote>
12179 <pre>struct awkward {
12180  awkward( const awkward &amp; ) throw() {}
12181  awkward( awkward &amp; ) { throw "oops"; } };
12182 </pre>
12183 </blockquote>
12184
12185
12186 <p><b>Proposed resolution:</b></p>
12187 <p>
12188 Change 20.4.4.3 [meta.unary.prop]:
12189 </p>
12190
12191 <blockquote>
12192 <pre>has_trivial_copy_constructor</pre>
12193 <blockquote>
12194 <tt>T</tt> is a trivial type (3.9) or a reference type or a class type <del>with a trivial copy constructor</del>
12195 <ins>where all copy constructors are trivial</ins> (12.8).
12196 </blockquote>
12197 </blockquote>
12198
12199 <blockquote>
12200 <pre>has_trivial_assign</pre>
12201 <blockquote>
12202 <tt>T</tt> is neither <tt>const</tt> nor a reference type, and <tt>T</tt> is a trivial type (3.9)
12203 or a class type <del>with a trivial copy assignment operator</del> <ins>where all copy assignment operators are trivial</ins> (12.8).
12204 </blockquote>
12205 </blockquote>
12206
12207 <blockquote>
12208 <pre>has_nothrow_copy_constructor</pre>
12209 <blockquote>
12210 <tt>has_trivial_copy_constructor&lt;T&gt;::value</tt> is <tt>true</tt> or <tt>T</tt> is a class type <del>with
12211 a</del> <ins>where all</ins> copy constructor<ins>s</ins> <del>that is</del> <ins>are</ins>
12212 known not to throw any exceptions or <tt>T</tt> is an
12213 array of such a class type
12214 </blockquote>
12215 </blockquote>
12216
12217 <blockquote>
12218 <pre>has_nothrow_assign</pre>
12219 <blockquote>
12220 <tt>T</tt> is neither <tt>const</tt> nor a reference type, and
12221 <tt>has_trivial_assign&lt;T&gt;::value</tt> is <tt>true</tt> or <tt>T</tt> is a class type <del>with a</del>
12222 <ins>where all</ins> copy
12223 assignment operator<ins>s</ins> tak<ins>e</ins><del>ing</del> an lvalue of type <tt>T</tt> that is known not to
12224 throw any exceptions or <tt>T</tt> is an array of such a class type.
12225 </blockquote>
12226 </blockquote>
12227
12228
12229
12230
12231
12232
12233 <hr>
12234 <h3><a name="750"></a>750. The current definition for <tt>is_convertible</tt> requires that the type be
12235 implicitly convertible, so explicit constructors are ignored.</h3>
12236 <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#Open">Open</a>
12237  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
12238 <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>
12239 <p><b>Discussion:</b></p>
12240 <p>
12241 With the pending arrival of explicit conversion functions though, I'm
12242 wondering if we want an additional trait, <tt>is_explictly_convertible</tt>?
12243 </p>
12244
12245 <p><i>[
12246 Bellevue:
12247 ]</i></p>
12248
12249
12250 <blockquote>
12251 Alisdair is considering preparing a paper listing a number of missing
12252 type traits, and feels that it might be useful to handle them all
12253 together rather than piecemeal. This would affect issue 719 and 750.
12254 These two issues should move to OPEN pending AM paper on type traits.
12255 </blockquote>
12256
12257
12258 <p><b>Proposed resolution:</b></p>
12259 <p>
12260 </p>
12261
12262
12263
12264
12265
12266 <hr>
12267 <h3><a name="751"></a>751. change pass-by-reference members of <tt>vector&lt;bool&gt;</tt> to pass-by-value?</h3>
12268 <p><b>Section:</b> 23.2.7 [vector.bool] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
12269  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
12270 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#vector.bool">active issues</a> in [vector.bool].</p>
12271 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.bool">issues</a> in [vector.bool].</p>
12272 <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>
12273 <p><b>Discussion:</b></p>
12274 <p>
12275 A number of vector&lt;bool&gt; members take const bool&amp; as arguments.
12276 Is there any chance we could change them to pass-by-value or would I
12277 be wasting everyone's time if wrote up an issue?
12278 </p>
12279
12280 <p><i>[
12281 post Bellevue:
12282 ]</i></p>
12283
12284
12285 <blockquote>
12286 <p>
12287 As we understand it, the original requester (Martin Sebor) would like
12288 for implementations to be permitted to pass-by-value. Alisdair suggests
12289 that if this is to be resolved, it should be resolved more generally,
12290 e.g. in other containers as well.
12291 </p>
12292 <p>
12293 We note that this would break ABI. However, we also suspect that this
12294 might be covered under the "as-if" rule in section 1.9.
12295 </p>
12296 <p>
12297 Many in the group feel that for vector&lt;bool&gt;, this is a "don't care",
12298 and that at this point in the process it's not worth the bandwidth.
12299 </p>
12300 <p>
12301 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a> -- which was in ready status pre-Bellevue and is
12302 now in the working paper -- is related to this, though not a duplicate.
12303 </p>
12304 <p>
12305 Moving to Open with a task for Alisdair to craft a informative note to
12306 be put whereever appropriate in the WP. This note would clarify places
12307 where pass-by-const-ref can be transformed to pass-by-value under the
12308 as-if rule.
12309 </p>
12310 </blockquote>
12311
12312
12313
12314 <p><b>Proposed resolution:</b></p>
12315 <p>
12316 </p>
12317
12318
12319
12320
12321
12322 <hr>
12323 <h3><a name="752"></a>752. Allocator complexity requirement</h3>
12324 <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>
12325  <b>Submitter:</b> Hans Boehm <b>Date:</b> 2007-10-11</p>
12326 <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>
12327 <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>
12328 <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>
12329 <p><b>Discussion:</b></p>
12330 <p>
12331 Did LWG recently discuss 20.1.2 [allocator.requirements]-2, which states that "All the operations
12332 on the allocators are expected to be amortized constant time."?
12333 </p>
12334 <p>
12335 As I think I pointed out earlier, this is currently fiction for
12336 <tt>allocate()</tt> if it has to obtain memory from the OS, and it's unclear to
12337 me how to interpret this for <tt>construct()</tt> and <tt>destroy()</tt> if they deal with
12338 large objects. &nbsp;Would it be controversial to officially let these take
12339 time linear in the size of the object, as they already do in real life?
12340 </p>
12341 <p>
12342 <tt>Allocate()</tt> more blatantly takes time proportional to the size of the
12343 object if you mix in GC. &nbsp;But it's not really a new problem, and I think
12344 we'd be confusing things by leaving the bogus requirements there. &nbsp;The
12345 current requirement on <tt>allocate()</tt> is generally not important anyway,
12346 since it takes O(size) to construct objects in the resulting space.
12347 There are real performance issues here, but they're all concerned with
12348 the constants, not the asymptotic complexity.
12349 </p>
12350
12351
12352 <p><b>Proposed resolution:</b></p>
12353 <p>
12354 Change 20.1.2 [allocator.requirements]/2:
12355 </p>
12356
12357 <blockquote>
12358 <p>
12359 -2- Table 39 describes the requirements on types manipulated through
12360 allocators. All the operations on the allocators are expected to be
12361 amortized constant time<ins>, except that <tt>allocate</tt> and
12362 <tt>construct</tt> may require time proportional to the size of the
12363 object allocated or constructed</ins>. Table 40 describes the
12364 requirements on allocator types.
12365 </p>
12366 </blockquote>
12367
12368
12369
12370
12371
12372 <hr>
12373 <h3><a name="753"></a>753. Move constructor in draft</h3>
12374 <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#Open">Open</a>
12375  <b>Submitter:</b> Yechezkel Mett <b>Date:</b> 2007-10-14</p>
12376 <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>
12377 <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>
12378 <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>
12379 <p><b>Discussion:</b></p>
12380 <p>
12381 The draft standard n2369 uses the term <i>move constructor</i> in a few
12382 places, but doesn't seem to define it.
12383 </p>
12384
12385 <p>
12386 <tt>MoveConstructible</tt> requirements are defined in Table 33 in 20.1.1 [utility.arg.requirements] as
12387 follows:
12388 </p>
12389
12390 <blockquote>
12391 <table border="1">
12392 <caption><tt>MoveConstructible</tt> requirements</caption>
12393 <tbody><tr>
12394 <th>expression</th> <th>post-condition</th>
12395 </tr>
12396 <tr>
12397 <td><tt>T t = rv</tt></td> <td><tt>t</tt> is equivalent to the value of <tt>rv</tt> before the construction</td>
12398 </tr>
12399 <tr>
12400 <td colspan="2">[<i>Note:</i> There is no requirement on the value of <tt>rv</tt> after the
12401 construction. <i>-- end note</i>]</td>
12402 </tr>
12403 </tbody></table>
12404 </blockquote>
12405
12406 <p>
12407 (where <tt>rv</tt> is a non-const rvalue of type <tt>T</tt>).
12408 </p>
12409
12410 <p>
12411 So I assume the move constructor is the constructor that would be used
12412 in filling the above requirement.
12413 </p>
12414
12415 <p>
12416 For <tt>vector::reserve</tt>, <tt>vector::resize</tt> and the <tt>vector</tt> modifiers given in
12417 23.2.6.4 [vector.modifiers] we have
12418 </p>
12419
12420 <blockquote>
12421 <i>Requires:</i> If <tt>value_type</tt> has a move constructor, that constructor shall
12422 not throw any exceptions.
12423 </blockquote>
12424
12425 <p>
12426 Firstly "If <tt>value_type</tt> has a move constructor" is superfluous; every
12427 type which can be put into a <tt>vector</tt> has a move constructor (a copy
12428 constructor is also a move constructor). Secondly it means that for
12429 any <tt>value_type</tt> which has a throwing copy constructor and no other move
12430 constructor these functions cannot be used -- which I think will come
12431 as a shock to people who have been using such types in <tt>vector</tt> until
12432 now!
12433 </p>
12434
12435 <p>
12436 I can see two ways to correct this. The simpler, which is presumably
12437 what was intended, is to say "If <tt>value_type</tt> has a move constructor and
12438 no copy constructor, the move constructor shall not throw any
12439 exceptions" or "If <tt>value_type</tt> has a move constructor which changes the
12440 value of its parameter,".
12441 </p>
12442
12443 <p>
12444 The other alternative is add to <tt>MoveConstructible</tt> the requirement that
12445 the expression does not throw. This would mean that not every type
12446 that satisfies the <tt>CopyConstructible</tt> requirements also satisfies the
12447 <tt>MoveConstructible</tt> requirements. It would mean changing requirements in
12448 various places in the draft to allow either <tt>MoveConstructible</tt> or
12449 <tt>CopyConstructible</tt>, but I think the result would be clearer and
12450 possibly more concise too.
12451 </p>
12452
12453
12454 <p><b>Proposed resolution:</b></p>
12455 <p>
12456 Add new defintions to 17.1 [definitions]:
12457 </p>
12458
12459 <blockquote>
12460 <p>
12461 <b>move constructor</b>
12462 </p>
12463 <p>
12464 a constructor which accepts only rvalue arguments of that type, and modifies the rvalue as a
12465 side effect during the construction.
12466 </p>
12467 <p>
12468 <b>move assignment operator</b>
12469 </p>
12470 <p>
12471 an assignment operator which accepts only rvalue arguments of that type, and modifies the rvalue as a
12472 side effect during the assignment.
12473 </p>
12474 <p>
12475 <b>move assignment</b>
12476 </p>
12477 <p>
12478 use of the move assignment operator.
12479 </p>
12480 </blockquote>
12481
12482 <p><i>[
12483 Howard adds post-Bellevue:
12484 ]</i></p>
12485
12486
12487 <blockquote>
12488 <p>
12489 Unfortunately I believe the wording recommended by the LWG in Bellevue is incorrect.  <tt>reserve</tt> et. al. will use a move constructor
12490 if one is available, else it will use a copy constructor.  A type may have both.  If the move constructor is
12491 used, it must not throw.  If the copy constructor is used, it can throw.  The sentence in the proposed wording
12492 is correct without the recommended insertion.  The Bellevue LWG recommended moving this issue to Ready.  I am
12493 unfortunately pulling it back to Open.  But I'm drafting wording to atone for this egregious action. :-)
12494 </p>
12495 </blockquote>
12496
12497
12498
12499
12500
12501
12502 <hr>
12503 <h3><a name="755"></a>755. <tt>std::vector</tt> and <tt>std:string</tt> lack explicit shrink-to-fit operations</h3>
12504 <p><b>Section:</b> 23.2.6.2 [vector.capacity], 21.3.4 [string.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
12505  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2007-10-31</p>
12506 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p>
12507 <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>
12508 <p><b>Discussion:</b></p>
12509 <p>
12510 A <tt>std::vector</tt> can be shrunk-to-fit via the swap idiom:
12511 </p>
12512
12513 <blockquote><pre>vector&lt;int&gt; v;
12514 ...
12515 v.swap(vector&lt;int&gt;(v));  // shrink to fit
12516 </pre>
12517 <blockquote><p>
12518 or:
12519 </p></blockquote>
12520 <pre>vector&lt;int&gt;(v).swap(v);  // shrink to fit
12521 </pre>
12522 <blockquote><p>
12523 or:
12524 </p></blockquote>
12525 <pre>swap(v, vector&lt;int&gt;(v));  // shrink to fit
12526 </pre>
12527 </blockquote>
12528
12529 <p>
12530 A non-binding request for shrink-to-fit can be made to a <tt>std::string</tt> via:
12531 </p>
12532
12533 <blockquote><pre>string s;
12534 ...
12535 s.reserve(0);
12536 </pre></blockquote>
12537
12538 <p>
12539 Neither of these is at all obvious to beginners, and even some
12540 experienced C++ programmers are not aware that shrink-to-fit is
12541 trivially available.
12542 </p>
12543 <p>
12544 Lack of explicit functions to perform these commonly requested
12545 operations makes vector and string less usable for non-experts. Because
12546 the idioms are somewhat obscure, code readability is impaired. It is
12547 also unfortunate that two similar vector-like containers use different
12548 syntax for the same operation.
12549 </p>
12550 <p>
12551 The proposed resolution addresses these concerns. The proposed function
12552 takes no arguments to keep the solution simple and focused.
12553 </p>
12554
12555
12556 <p><b>Proposed resolution:</b></p>
12557 <p>
12558 To Class template basic_string 21.3 [basic.string] synopsis,
12559 Class template vector 23.2.6 [vector] synopsis, and Class
12560 vector&lt;bool&gt; 23.2.7 [vector.bool] synopsis, add:
12561 </p>
12562
12563 <blockquote><pre>
12564 void shrink_to_fit();
12565 </pre></blockquote>
12566
12567 <p>
12568 To basic_string capacity 21.3.4 [string.capacity] and vector
12569 capacity 23.2.6.2 [vector.capacity], add:
12570 </p>
12571
12572 <blockquote>
12573 <pre>void shrink_to_fit();
12574 </pre>
12575 <blockquote>
12576 <i>Remarks:</i> <tt>shrink_to_fit</tt> is a non-binding request to reduce
12577 <tt>capacity()</tt> to <tt>size()</tt>. [<i>Note:</i> The request is non-binding to
12578 allow latitude for implementation-specific optimizations.
12579 <i>-- end note</i>]
12580 </blockquote>
12581 </blockquote>
12582
12583
12584
12585
12586
12587 <hr>
12588 <h3><a name="756"></a>756. Container adaptors push</h3>
12589 <p><b>Section:</b> 23.2.5 [container.adaptors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
12590  <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2007-10-31</p>
12591 <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>
12592 <p><b>Discussion:</b></p>
12593 <p>
12594 After n2369 we have a single <tt>push_back</tt> overload in the sequence containers,
12595 of the "emplace" type. At variance with that, still in n2461, we have
12596 two separate overloads, the C++03 one + one taking an rvalue reference
12597 in the container adaptors. Therefore, simply from a consistency point of
12598 view, I was wondering whether the container adaptors should be aligned
12599 with the specifications of the sequence container themselves: thus have
12600 a single <tt>push</tt> along the lines:
12601 </p>
12602
12603 <blockquote><pre>template&lt;typename... _Args&gt;
12604 void
12605 push(_Args&amp;&amp;... __args)
12606   { c.push_back(std::forward&lt;_Args&gt;(__args)...); }
12607 </pre></blockquote>
12608
12609 <p><i>[
12610 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#767">767</a>
12611 ]</i></p>
12612
12613
12614
12615 <p><b>Proposed resolution:</b></p>
12616 <p>
12617 Change 23.2.5.1.1 [queue.defn]:
12618 </p>
12619
12620 <blockquote><pre><del>void push(const value_type&amp; x) { c.push_back(x); }</del>
12621 <del>void push(value_type&amp;&amp; x) { c.push_back(std::move(x)); }</del>
12622 <ins>template&lt;class... Args&gt; void push(Args&amp;&amp;... args) { c.push_back(std::forward&lt;Args&gt;(args)...); }</ins>
12623 </pre></blockquote>
12624
12625 <p>
12626 Change 23.2.5.2 [priority.queue]:
12627 </p>
12628
12629 <blockquote><pre><del>void push(const value_type&amp; x) { c.push_back(x); }</del>
12630 <del>void push(value_type&amp;&amp; x) { c.push_back(std::move(x)); }</del>
12631 <ins>template&lt;class... Args&gt; void push(Args&amp;&amp;... args) { c.push_back(std::forward&lt;Args&gt;(args)...); }</ins>
12632 </pre></blockquote>
12633
12634 <p>
12635 Change 23.2.5.2.2 [priqueue.members]:
12636 </p>
12637
12638 <blockquote>
12639 <pre><del>void push(const value_type&amp; x);</del>
12640 </pre>
12641 <blockquote>
12642 <p>
12643 <del><i>Effects:</i></del>
12644 </p>
12645 <blockquote><pre><del>c.push_back(x);</del>
12646 <del>push_heap(c.begin(), c.end(), comp);</del>
12647 </pre></blockquote>
12648 </blockquote>
12649
12650 <pre><ins>template&lt;class... Args&gt;</ins> void push(<del>value_type</del> <ins>Args</ins>&amp;&amp;<ins>...</ins> <del>x</del> <ins>args</ins>);
12651 </pre>
12652 <blockquote>
12653 <p>
12654 <i>Effects:</i>
12655 </p>
12656 <blockquote><pre>c.push_back(std::<del>move</del><ins>forward&lt;Args&gt;</ins>(<del>x</del> <ins>args</ins>)<ins>...</ins>);
12657 push_heap(c.begin(), c.end(), comp);
12658 </pre></blockquote>
12659 </blockquote>
12660 </blockquote>
12661
12662 <p>
12663 Change 23.2.5.3.1 [stack.defn]:
12664 </p>
12665
12666 <blockquote><pre><del>void push(const value_type&amp; x) { c.push_back(x); }</del>
12667 <del>void push(value_type&amp;&amp; x) { c.push_back(std::move(x)); }</del>
12668 <ins>template&lt;class... Args&gt; void push(Args&amp;&amp;... args) { c.push_back(std::forward&lt;Args&gt;(args)...); }</ins>
12669 </pre></blockquote>
12670
12671
12672
12673
12674
12675
12676 <hr>
12677 <h3><a name="758"></a>758. <tt>shared_ptr</tt> and <tt>nullptr</tt></h3>
12678 <p><b>Section:</b> 20.6.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
12679  <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-10-31</p>
12680 <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>
12681 <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>
12682 <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>
12683 <p><b>Discussion:</b></p>
12684 <p>
12685 Consider the following program:
12686 </p>
12687
12688 <blockquote><pre>int main() {
12689    shared_ptr&lt;int&gt; p(nullptr);
12690    return 0;
12691 }
12692 </pre></blockquote>
12693
12694 <p>
12695 This program will fail to compile because <tt>shared_ptr</tt> uses the following
12696 template constructor to construct itself from pointers:
12697 </p>
12698
12699 <blockquote><pre>template &lt;class Y&gt; shared_ptr(Y *);
12700 </pre></blockquote>
12701
12702 <p>
12703 According
12704 to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf">N2431</a>,
12705 the conversion from <tt>nullptr_t</tt> to <tt>Y *</tt> is not
12706 deducible, so the above constructor will not be found.  There are similar problems with the
12707 constructors that take a pointer and a <tt>deleter</tt> or a
12708 pointer, a <tt>deleter</tt> and an allocator, as well as the
12709 corresponding forms of <tt>reset()</tt>. Note that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2435.htm">N2435</a>
12710 will solve this problem for constructing from just <tt>nullptr</tt>, but not for constructors that use
12711 <tt>deleters</tt> or allocators or for <tt>reset()</tt>.
12712 </p>
12713
12714 <p>
12715 In the case of the functions that take deleters, there is the additional
12716 question of what argument should be passed to the deleter when it is
12717 eventually called.  There are two reasonable possibilities: <tt>nullptr</tt> or
12718 <tt>static_cast&lt;T *&gt;(0)</tt>, where <tt>T</tt> is the template argument of the
12719 <tt>shared_ptr</tt>.  It is not immediately clear which of these is better.  If
12720 <tt>D::operator()</tt> is a template function similar to <tt>shared_ptr</tt>'s
12721 constructor, then <tt>d(static_cast&lt;T*&gt;(0))</tt> will compile and <tt>d(nullptr)</tt>
12722 will not.  On the other hand, if <tt>D::operator()()</tt> takes a parameter that
12723 is a pointer to some type other that <tt>T</tt> (for instance <tt>U*</tt> where <tt>U</tt> derives
12724 from <tt>T</tt>) then <tt>d(nullptr)</tt> will compile and <tt>d(static_cast&lt;T *&gt;(0))</tt> may not.
12725 </p>
12726
12727 <p><i>[
12728 Bellevue:
12729 ]</i></p>
12730
12731
12732 <blockquote>
12733 <p>
12734 The general idea is right, we need to be able to pass a nullptr to a
12735 shared_ptr, but there are a few borderline editorial issues here. (For
12736 example, the single-argument nullptr_t constructor in the class synopsis
12737 isn't marked explicit, but it is marked explicit in the proposed wording
12738 for 20.6.6.2.1. There is a missing empty parenthesis in the form that
12739 takes a nullptr_t, a deleter, and an allocator.)
12740 </p>
12741 <p>
12742 More seriously: this issue says that a shared_ptr constructed from a
12743 nullptr is empty. Since "empty" is undefined, it's hard to know whether
12744 that's right. This issue is pending on handling that term better.
12745 </p>
12746 <p>
12747 Peter suggests definition of empty should be "does not own anything"
12748 </p>
12749 <p>
12750 Is there an editorial issue that post-conditions should refer to get() =
12751 nullptr, rather than get() = 0?
12752 </p>
12753 <p>
12754 No strong feeling towards accept or NAD, but prefer to make a decision than leave it open.
12755 </p>
12756 <p>
12757 Seems there are no technical merits between NAD and Ready, comes down to
12758 "Do we intentially want to allow/disallow null pointers with these
12759 functions". Staw Poll - support null pointers 5 - No null pointers 0
12760 </p>
12761 <p>
12762 Move to Ready, modulo editorial comments
12763 </p>
12764 </blockquote>
12765
12766 <p><i>[
12767 post Bellevue Peter adds:
12768 ]</i></p>
12769
12770
12771 <blockquote>
12772 <p>
12773 The following wording changes are less intrusive:
12774 </p>
12775
12776 <p>
12777 In 20.6.12.2.1 [util.smartptr.shared.const], add:
12778 </p>
12779
12780 <blockquote><pre>shared_ptr(nullptr_t);
12781 </pre></blockquote>
12782
12783 <p>
12784 after:
12785 </p>
12786
12787 <blockquote><pre>shared_ptr();
12788 </pre></blockquote>
12789
12790 <p>
12791 (Absence of explicit intentional.)
12792 </p>
12793
12794 <p>
12795 <tt>px.reset( nullptr )</tt> seems a somewhat contrived way to write <tt>px.reset()</tt>, so
12796 I'm not convinced of its utility.
12797 </p>
12798 <p>
12799 It's similarly not clear to me whether the deleter constructors need to be
12800 extended to take <tt>nullptr</tt>, but if they need to:
12801 </p>
12802 <p>
12803 Add
12804 </p>
12805
12806 <blockquote><pre>template&lt;class D&gt; shared_ptr(nullptr_t p, D d);
12807 template&lt;class D, class A&gt; shared_ptr(nullptr_t p, D d, A a);
12808 </pre></blockquote>
12809
12810 <p>
12811 after
12812 </p>
12813
12814 <blockquote><pre>template&lt;class Y, class D&gt; shared_ptr(Y* p, D d);
12815 template&lt;class Y, class D, class A&gt; shared_ptr(Y* p, D d, A a);
12816 </pre></blockquote>
12817
12818 <p>
12819 Note that this changes the semantics of the new constructors such that they
12820 consistently call <tt>d(p)</tt> instead of <tt>d((T*)0)</tt> when <tt>p</tt> is <tt>nullptr</tt>.
12821 </p>
12822 <p>
12823 The ability to be able to pass <tt>0/NULL</tt> to a function that takes a <tt>shared_ptr</tt>
12824 has repeatedly been requested by users, but the other additions that the
12825 proposed resolution makes are not supported by real world demand or
12826 motivating examples.
12827 </p>
12828 <p>
12829 It might be useful to split the obvious and non-controversial <tt>nullptr_t</tt>
12830 constructor into a separate issue. Waiting for "empty" to be clarified is
12831 unnecessary; this is effectively an alias for the default constructor.
12832 </p>
12833 </blockquote>
12834
12835
12836
12837 <p><b>Proposed resolution:</b></p>
12838 <p>
12839 Add the following constructors to 20.6.12.2 [util.smartptr.shared]:
12840 </p>
12841
12842 <blockquote><pre>shared_ptr(nullptr_t);
12843 template &lt;class D&gt; shared_ptr(nullptr_t, D d);
12844 template &lt;class D, class A&gt; shared_ptr(nullptr_t, D d, A a);
12845 </pre></blockquote>
12846
12847 <p>
12848 Add the following methods to 20.6.12.2 [util.smartptr.shared]:
12849 </p>
12850
12851 <blockquote><pre>void reset(nullptr_t);
12852 template &lt;class D&gt; void reset(nullptr_t, D d);
12853 template &lt;class D, class A&gt; void reset(nullptr_t, D d, A a);
12854 </pre></blockquote>
12855
12856 <p>
12857 Add the following constructor definitions to 20.6.12.2.1 [util.smartptr.shared.const]:
12858 </p>
12859
12860 <blockquote>
12861 <pre> explicit shared_ptr(nullptr_t);
12862 </pre>
12863 <blockquote>
12864 <p>
12865 <i>Effects:</i> Constructs an empty shared_ptr object.
12866 </p>
12867 <p>
12868 <i>Postconditions:</i> <tt>use_count() == 0 &amp;&amp; get() == 0</tt>.
12869 </p>
12870 <p>
12871 <i>Throws:</i> nothing.
12872 </p>
12873 </blockquote>
12874 </blockquote>
12875
12876 <blockquote>
12877 <pre>template &lt;class D&gt; shared_ptr(nullptr_t, D d);
12878 template &lt;class D, class A&gt; shared_ptr&lt;nullptr_t, D d, A a);
12879 </pre>
12880 <blockquote>
12881 <p>
12882 <i>Requires:</i> <tt>D</tt> shall be <tt>CopyConstructible</tt>. The copy constructor and
12883 destructor of <tt>D</tt> shall not throw exceptions. The expression
12884 <tt>d(static_cast&lt;T *&gt;(0))</tt> shall be well-formed, shall have well defined behavior,
12885 and shall not throw exceptions. <tt>A</tt> shall be an allocator (20.1.2 [allocator.requirements]).
12886 The copy constructor and destructor of <tt>A</tt> shall not throw
12887 exceptions.
12888 </p>
12889 <p>
12890 <i>Effects:</i> Constructs a <tt>shared_ptr</tt> object that owns a null pointer of type <tt>T *</tt>
12891 and  deleter <tt>d</tt>.  The
12892 second constructor shall use a copy of <tt>a</tt> to allocate memory for
12893 internal use.
12894 </p>
12895 <p>
12896 <i>Postconditions:</i> <tt>use_count() == 1</tt> and <tt>get() == 0</tt>.
12897 </p>
12898 <p>
12899 <i>Throws:</i> <tt>bad_alloc</tt>, or an implementation-defined exception when a
12900 resource other than memory could not be obtained.
12901 </p>
12902 <p>
12903 <i>Exception safety:</i> If an exception is thrown, <tt>d(static_cast&lt;Y *&gt;(nullptr))</tt> is called.
12904 </p>
12905 </blockquote>
12906 </blockquote>
12907
12908 <p>
12909 Add the following method definitions to 20.6.12.2.4 [util.smartptr.shared.mod]:
12910 </p>
12911
12912 <blockquote>
12913 <pre>void reset(nullptr_t);
12914 </pre>
12915 <blockquote>
12916 <p>
12917 <i>Effects:</i> Equivalent to <tt>shared_ptr(nullptr).swap(*this)</tt>.
12918 </p>
12919 </blockquote>
12920 </blockquote>
12921
12922 <blockquote>
12923 <pre>template &lt;class D&gt; void reset(nullptr_t, const D d)
12924 </pre>
12925 <blockquote>
12926 <p>
12927 <i>Effects:</i> Equivalent to <tt>shared_ptr(nullptr, d).swap(*this)</tt>.
12928 </p>
12929 </blockquote>
12930 </blockquote>
12931
12932 <blockquote>
12933 <pre>template &lt;class D, class A&gt; void reset(nullptr_t, D d, A a);
12934 </pre>
12935 <blockquote>
12936 <p>
12937 <i>Effects:</i> Equivalent to <tt>shared_ptr(nullptr, d, a).swap(*this)</tt>.
12938 </p>
12939 </blockquote>
12940 </blockquote>
12941
12942
12943
12944
12945
12946
12947 <hr>
12948 <h3><a name="759"></a>759. A reference is not an object</h3>
12949 <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>
12950  <b>Submitter:</b> Jens Maurer <b>Date:</b> 2007-11-06</p>
12951 <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>
12952 <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>
12953 <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>
12954 <p><b>Discussion:</b></p>
12955 <p>
12956 23.1 [container.requirements] says:
12957 </p>
12958
12959 <blockquote>
12960 -12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No
12961 diagnostic required.
12962 </blockquote>
12963
12964 <p>
12965 A reference is not an object, but this sentence appears to claim so.
12966 </p>
12967
12968 <p>
12969 What is probably meant here:
12970 </p>
12971 <blockquote>
12972 An object bound to an rvalue
12973 reference parameter of a member function of a container shall not be
12974 an element of that container; no diagnostic required.
12975 </blockquote>
12976
12977
12978
12979 <p><b>Proposed resolution:</b></p>
12980 <p>
12981 Change 23.1 [container.requirements]:
12982 </p>
12983
12984 <blockquote>
12985 -12- <del>Objects passed to member functions of a container as rvalue references shall not be elements</del>
12986 <ins>An object bound to an rvalue
12987 reference parameter of a member function of a container shall not be
12988 an element</ins>
12989 of that container<del>.</del><ins>;</ins> <del>N</del><ins>n</ins>o
12990 diagnostic required.
12991 </blockquote>
12992
12993
12994
12995
12996
12997
12998 <hr>
12999 <h3><a name="760"></a>760. The emplace issue</h3>
13000 <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>
13001  <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2007-11-11</p>
13002 <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>
13003 <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>
13004 <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>
13005 <p><b>Discussion:</b></p>
13006 <p>
13007 In an emplace member function the function parameter pack may be bound
13008 to a priori unlimited number of objects: some or all of them can be
13009 elements of the container itself. Apparently, in order to conform to the
13010 blanket statement 23.1 [container.requirements]/11, the implementation must check all of them for
13011 that possibility. A possible solution can involve extending the
13012 exception in 23.1 [container.requirements]/12 also to the emplace member. As a side note, the
13013 <tt>push_back</tt> and <tt>push_front</tt> member functions are luckily not affected by
13014 this problem, can be efficiently implemented anyway
13015 </p>
13016
13017 <p><i>[
13018 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#767">767</a>
13019 ]</i></p>
13020
13021
13022 <p><i>[
13023 Bellevue:
13024 ]</i></p>
13025
13026
13027 <blockquote>
13028 <p>
13029 The proposed addition (13) is partially redundant with the existing
13030 paragraph 12. Why was the qualifier "rvalues" added to paragraph 12? Why
13031 does it not cover subelements and pointers?
13032 </p>
13033 <p>
13034 Resolution: Alan Talbot to rework language, then set state to Review.
13035 </p>
13036 </blockquote>
13037
13038
13039
13040 <p><b>Proposed resolution:</b></p>
13041 <p>
13042 Add after 23.1 [container.requirements]/12:
13043 </p>
13044
13045 <blockquote>
13046 <p>
13047 -12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No
13048 diagnostic required.
13049 </p>
13050 <p>
13051 <ins>
13052 -13- Objects bound to the function parameter pack of the <tt>emplace</tt> member function shall not be elements or
13053 sub-objects of elements of the container. No diagnostic required.
13054 </ins>
13055 </p>
13056
13057 </blockquote>
13058
13059
13060
13061
13062
13063
13064 <hr>
13065 <h3><a name="761"></a>761. <tt>unordered_map</tt> needs an <tt>at()</tt> member function</h3>
13066 <p><b>Section:</b> 23.4.1.2 [unord.map.elem] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
13067  <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-11-15</p>
13068 <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>
13069 <p><b>Discussion:</b></p>
13070 <p>
13071 The new member function <tt>at()</tt> was recently added to <tt>std::map()</tt>.  It acts
13072 like <tt>operator[]()</tt>, except it throws an exception when the input key is
13073 not found.  It is useful when the <tt>map</tt> is <tt>const</tt>, the <tt>value_type</tt> of the
13074 key doesn't have  a default constructor, it is an error if the key is
13075 not found, or the user wants to avoid accidentally adding an element to
13076 the map.  For exactly these same reasons, <tt>at()</tt> would be equally useful
13077 in <tt>std::unordered_map</tt>.
13078 </p>
13079
13080
13081 <p><b>Proposed resolution:</b></p>
13082 <p>
13083 Add the following functions to the definition of <tt>unordered_map</tt> under "lookup" (23.4.1 [unord.map]):
13084 </p>
13085
13086 <blockquote><pre>mapped_type&amp; at(const key_type&amp; k);
13087 const mapped_type &amp;at(const key_type &amp;k) const;
13088 </pre></blockquote>
13089
13090 <p>
13091 Add the following definitions to 23.4.1.2 [unord.map.elem]:
13092 </p>
13093
13094 <blockquote>
13095 <pre>mapped_type&amp; at(const key_type&amp; k);
13096 const mapped_type &amp;at(const key_type &amp;k) const;
13097 </pre>
13098 <blockquote>
13099 <p>
13100 <i>Returns:</i> A reference to <tt>x.second</tt>, where <tt>x</tt> is the (unique) element
13101 whose key is equivalent to <tt>k</tt>.
13102 </p>
13103 <p>
13104 <i>Throws:</i> An exception object of type <tt>out_of_range</tt> if no such element
13105 is present.
13106 </p>
13107 </blockquote>
13108 </blockquote>
13109
13110 <p><i>[
13111 Bellevue:  Editorial note: the "(unique)" differs from map.
13112 ]</i></p>
13113
13114
13115
13116
13117
13118
13119
13120 <hr>
13121 <h3><a name="762"></a>762. <tt>std::unique_ptr</tt> requires complete type?</h3>
13122 <p><b>Section:</b> 20.6.11 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
13123  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-11-30</p>
13124 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr">active issues</a> in [unique.ptr].</p>
13125 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr">issues</a> in [unique.ptr].</p>
13126 <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>
13127 <p><b>Discussion:</b></p>
13128 <p>
13129 In contrast to the proposed <tt>std::shared_ptr</tt>, <tt>std::unique_ptr</tt>
13130 does currently not support incomplete types, because it
13131 gives no explicit grant - thus instantiating <tt>unique_ptr</tt> with
13132 an incomplete pointee type <tt>T</tt> automatically belongs to
13133 undefined behaviour according to 17.4.3.7 [res.on.functions]/2, last
13134 bullet. This is an unnecessary restriction and prevents
13135 many well-established patterns - like the bridge pattern -
13136 for <tt>std::unique_ptr</tt>.
13137 </p>
13138
13139 <p><i>[
13140 Bellevue:
13141 ]</i></p>
13142
13143
13144 <blockquote>
13145 Move to open. The LWG is comfortable with the intent of allowing
13146 incomplete types and making <tt>unique_ptr</tt> more like <tt>shared_ptr</tt>, but we are
13147 not comfortable with the wording. The specification for <tt>unique_ptr</tt>
13148 should be more like that of <tt>shared_ptr</tt>. We need to know, for individual
13149 member functions, which ones require their types to be complete. The
13150 <tt>shared_ptr</tt> specification is careful to say that for each function, and
13151 we need the same level of care here. We also aren't comfortable with the
13152 "part of the operational semantic" language; it's not used elsewhere in
13153 the standard, and it's not clear what it means. We need a volunteer to
13154 produce new wording.
13155 </blockquote>
13156
13157
13158 <p><b>Proposed resolution:</b></p>
13159 <p>
13160 The proposed changes in the following revision refers to the current state of
13161 N2521 including the assumption that 20.6.11.4 [unique.ptr.compiletime] will be removed
13162 according to the current state of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#740">740</a>.
13163 </p>
13164 <p>
13165 The specialization <tt>unique_ptr&lt;T[]&gt;</tt> has some more restrictive constraints on
13166 type-completeness on <tt>T</tt> than <tt>unique_ptr&lt;T&gt;</tt>. The following proposed wordings
13167 try to cope with that. If the committee sees less usefulness on relaxed
13168 constraints on <tt>unique_ptr&lt;T[]&gt;</tt>, the alternative would be to stop this relaxation
13169 e.g. by adding one further bullet to 20.6.11.3 [unique.ptr.runtime]/1:
13170 "<tt>T</tt> shall be a complete type, if used as template argument of
13171 <tt>unique_ptr&lt;T[], D&gt;</tt>
13172 </p>
13173 <p>
13174 This issue has some overlap with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a>, but it seems not to cause any
13175 problems with this one,
13176 because <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a> adds only optional requirements on <tt>D</tt> that do not conflict
13177 with the here discussed
13178 ones, provided that <tt>D::pointer</tt>'s operations (including default
13179 construction, copy construction/assignment,
13180 and pointer conversion) are specified <em>not</em> to throw, otherwise this
13181 would have impact on the
13182 current specification of <tt>unique_ptr</tt>.
13183 </p>
13184
13185 <ol>
13186 <li>
13187 <p>
13188 In 20.6.11 [unique.ptr]/2 add as the last sentence to the existing para:
13189 </p>
13190
13191 <blockquote>
13192 The <tt>unique_ptr</tt> provides a semantics of strict ownership. A
13193 <tt>unique_ptr</tt> owns the object it holds a pointer to. A
13194 <tt>unique_ptr</tt> is not <tt>CopyConstructible</tt>, nor
13195 <tt>CopyAssignable</tt>, however it is <tt>MoveConstructible</tt> and
13196 <tt>MoveAssignable</tt>. <ins>The template parameter <tt>T</tt> of
13197 <tt>unique_ptr</tt> may be an incomplete type.</ins> [ <i>Note:</i> The
13198 uses of <tt>unique_ptr</tt> include providing exception safety for
13199 dynamically allcoated memory, passing ownership of dynamically allocated
13200 memory to a function, and returning dynamically allocated memory from a
13201 function. -- <i>end note</i> ]
13202 </blockquote>
13203 </li>
13204
13205 <li>
13206 <p>
13207 20.6.11.2.1 [unique.ptr.single.ctor]/1: No changes necessary.
13208 </p>
13209
13210 <blockquote>
13211 <p><i>[
13212 N.B.: We only need the requirement that <tt>D</tt> is <tt>DefaultConstructible</tt>.
13213 The current wording says just this.
13214 ]</i></p>
13215
13216 </blockquote>
13217 </li>
13218
13219 <li>
13220 <p>
13221 In 20.6.11.2.1 [unique.ptr.single.ctor]/5 change the requires clause to say:
13222 </p>
13223
13224 <blockquote>
13225 <p>
13226 <i>Requires:</i> <del>The expression <tt>D()(p)</tt> shall be well formed. The default constructor
13227 of <tt>D</tt> shall not throw an exception.</del>
13228 <tt>D</tt> <del>must</del> <ins>shall</ins> not be a reference type.
13229 <ins>
13230 <tt>D</tt> shall be default constructible, and that construction
13231 shall not throw an exception.
13232 </ins>
13233 </p>
13234 <p><i>[
13235 N.B.: There is no need that the expression <tt>D()(p)</tt> is well-formed at
13236 this point. I assume that the current wording is based on the
13237 corresponding <tt>shared_ptr</tt> wording. In case of <tt>shared_ptr</tt> this
13238 requirement is necessary, because the corresponding c'tor *can* fail
13239 and must invoke delete <tt>p/d(p)</tt> in this case. <tt>Unique_ptr</tt> is simpler in
13240 this regard. The *only* functions that must insist on well-formedness
13241 and well-definedness of the expression <tt>get_deleter()(get())</tt> are (1)
13242 the destructor and (2) <tt>reset</tt>. The reasoning for the wording change to
13243 explicitly require <tt>DefaultConstructible</tt> of <tt>D</tt> is to guarantee that
13244 invocation of
13245 <tt>D</tt>'s default c'tor is both well-formed and well-defined. Note also that
13246 we do *not* need the
13247 requirement that <tt>T</tt> must be complete, also in contrast to <tt>shared_ptr</tt>.
13248 <tt>Shared_ptr</tt> needs this, because it's c'tor is a template c'tor which
13249 potentially requires <tt>Convertible&lt;Y*, X*&gt;</tt>, which
13250 again requires Completeness of <tt>Y</tt>, if <tt>!SameType&lt;X, Y&gt;</tt>
13251 ]</i></p>
13252
13253 </blockquote>
13254 </li>
13255
13256 <li>
13257 <p>
13258 Merge 20.6.11.2.1 [unique.ptr.single.ctor]/12+13 thereby removing the sentence
13259 of 12, but transferring the "requires" to 13:
13260 </p>
13261
13262 <blockquote>
13263 <p>
13264 <i>Requires:</i> If <tt>D</tt> is not an lvalue-reference type then[..]
13265 </p>
13266 <p><i>[
13267 N.B.: For the same reasons as for (3), there is no need that <tt>d(p)</tt> is
13268 well-formed/well-defined at this point. The current wording guarantees
13269 all what we need, namely that the initialization of both the <tt>T*</tt>
13270 pointer and the <tt>D</tt> deleter are well-formed and well-defined.
13271 ]</i></p>
13272
13273 </blockquote>
13274 </li>
13275
13276 <li>
13277 20.6.11.2.1 [unique.ptr.single.ctor]/17: No changes necessary.
13278 </li>
13279 <li>
13280 <p>20.6.11.2.1 [unique.ptr.single.ctor]/21: No changes necessary.</p>
13281
13282 <p><i>[
13283 N.B.: The current wording of 21 already implicitly guarantees that <tt>U</tt>
13284 is completely defined, because it requires that <tt>Convertible&lt;U*, T*&gt;</tt> is
13285 true. If the committee wishes this explicit requirement can be added,
13286 e.g. "<tt>U</tt> shall be a complete type."
13287 ]</i></p>
13288
13289 </li>
13290
13291 <li>
13292 <p>
13293 20.6.11.2.2 [unique.ptr.single.dtor]: Just before p1 add a new paragraph:
13294 </p>
13295 <blockquote>
13296 <p>
13297 <i>Requires:</i> The expression <tt>get_deleter()(get())</tt> shall be well-formed,
13298 shall have well-defined behavior, and shall not throw exceptions.
13299 </p>
13300 <p><i>[
13301 N.B.: This requirement ensures that the whole responsibility on
13302 type-completeness of <tt>T</tt> is delegated to this expression.
13303 ]</i></p>
13304
13305 </blockquote>
13306 </li>
13307
13308 <li>
13309 <p>
13310 20.6.11.2.3 [unique.ptr.single.asgn]/1: No changes necessary, except the
13311 current editorial issue, that "must shall" has to be changed to
13312 "shall", but this change is not a special part of this resolution.
13313 </p>
13314
13315 <p><i>[
13316 N.B. The current wording is sufficient, because we can delegate all
13317 further requirements on the requirements of the effects clause
13318 ]</i></p>
13319
13320 </li>
13321
13322 <li>
13323 <p>
13324 20.6.11.2.3 [unique.ptr.single.asgn]/6: No changes necessary.
13325 </p>
13326 <p><i>[
13327 N.B.: The current wording of p. 6 already implicitly guarantees that
13328 <tt>U</tt> is completely defined, because it requires that <tt>Convertible&lt;U*, T*&gt;</tt>
13329 is true, see (6)+(8).
13330 ]</i></p>
13331
13332 </li>
13333
13334 <li>
13335 <p>
13336 20.6.11.2.3 [unique.ptr.single.asgn]/11: No changes necessary.
13337 </p>
13338 <p><i>[
13339 N.B.: Delegation to requirements of effects clause is sufficient.
13340 ]</i></p>
13341
13342 </li>
13343
13344 <li>
13345 20.6.11.2.4 [unique.ptr.single.observers]/1+4+7+9+11: No changes necessary.
13346 </li>
13347
13348 <li>
13349 20.6.11.2.5 [unique.ptr.single.modifiers]/1: No changes necessary.
13350 </li>
13351
13352 <li>
13353 <p>
13354 20.6.11.2.5 [unique.ptr.single.modifiers]/4: Just before p. 4 add a new paragraph:
13355 </p>
13356 <blockquote>
13357 <i>Requires:</i> The expression <tt>get_deleter()(get())</tt> shall be well-formed,
13358 shall have well-defined behavior, and shall not throw exceptions.
13359 </blockquote>
13360 </li>
13361
13362 <li>
13363 20.6.11.2.5 [unique.ptr.single.modifiers]/7: No changes necessary.
13364 </li>
13365
13366 <li>
13367 <p>
13368 20.6.11.3.1 [unique.ptr.runtime.ctor]: Add one additional paragraph just
13369 before the current one:
13370 </p>
13371
13372 <blockquote>
13373 <p>
13374 <i>Requires:</i> <tt>T</tt> shall be a complete type.
13375 </p>
13376 <p><i>[
13377 N.B.: We need this requirement, because otherwise it is not
13378 guaranteed that the c'tors can fulfill their requirements to reject
13379 any type that is convertible to <tt>T*</tt>.
13380 ]</i></p>
13381
13382 </blockquote>
13383 </li>
13384
13385 <li>
13386 20.6.11.3.2 [unique.ptr.runtime.observers]/1: Change the clause to says:
13387 </li>
13388
13389 <blockquote>
13390 <i>Requires:</i> <tt>i &lt;</tt> the size of the array to which the stored pointer
13391 points. <tt>T</tt> shall be a complete type.
13392 </blockquote>
13393
13394 <li>
13395 <p>
13396 20.6.11.3.3 [unique.ptr.runtime.modifiers]/1: Change the first sentence of the
13397 paragraph to say:
13398 </p>
13399 <blockquote>
13400 <p>
13401 <i>Requires:</i> <tt>T</tt> shall be a complete type. Does not accept pointer types
13402 which are convertible to <tt>T*</tt> (diagnostic required). [ Note: ...]
13403 </p>
13404 <p><i>[
13405 N.B. Similar to (15) we need this requirement such that <tt>reset</tt> can
13406 reject types which are convertible to <tt>T*</tt>
13407 ]</i></p>
13408
13409 </blockquote>
13410
13411 </li>
13412 </ol>
13413
13414 <p><i>[
13415 post Bellevue: Daniel provided revised wording.
13416 ]</i></p>
13417
13418
13419
13420
13421
13422
13423
13424 <hr>
13425 <h3><a name="765"></a>765. more on iterator validity</h3>
13426 <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#New">New</a>
13427  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-12-14</p>
13428 <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>
13429 <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>
13430 <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>
13431 <p><b>Discussion:</b></p>
13432        <p>
13433
13434 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a>
13435 defines the meaning of the term "invalid iterator" as one that may be
13436 singular.
13437
13438        </p>
13439        <p>
13440
13441 Consider the following code:
13442
13443        </p>
13444        <pre>   std::deque&lt;int&gt; x, y;
13445    std::deque&lt;int&gt;::iterator i = x.end(), j = y.end();
13446    x.swap(y);
13447        </pre>
13448        <p>
13449
13450 Given that <code>swap()</code> is required not to invalidate iterators
13451 and using the definition above, what should be the expected result of
13452 comparing <code>i</code> and <code>j</code> to <code>x.end()</code>
13453 and <code>y.end()</code>, respectively, after the <code>swap()</code>?
13454
13455        </p>
13456        <p>
13457
13458 I.e., is the expression below required to evaluate
13459 to <code>true</code>?
13460
13461        </p>
13462        <pre>   i == y.end() &amp;&amp; j == x.end()
13463        </pre>
13464        <p>
13465
13466 (There are at least two implementations where the expression
13467 returns <code>false</code>.)
13468
13469        </p>
13470        <p>
13471
13472 More generally, is the definition introduced in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a> meant to
13473 make any guarantees about whether iterators actually point to the same
13474 elements or be associated with the same containers after a
13475 non-invalidating operation as they did before?
13476
13477        </p>
13478        <p>
13479
13480 Here's a motivating example intended to demonstrate the importance of
13481 the question:
13482
13483        </p>
13484        <pre>   Container x, y ({ 1, 2});   // pseudocode to initialize y with { 1, 2 }
13485    Container::iterator i = y.begin() + 1;
13486    Container::iterator j = y.end();
13487    std::swap(x, y);
13488    std::find(i, j, 3);
13489        </pre>
13490        <p>
13491
13492 <code>swap()</code> guarantees that <code>i</code> and <code>j</code>
13493 continue to be valid. Unless the spec says that even though they are
13494 valid they may no longer denote a valid range the code above must be
13495 well-defined. Expert opinions on this differ as does the behavior of
13496 popular implementations for some standard <code>Containers</code>.
13497
13498        </p>
13499
13500
13501 <p><b>Proposed resolution:</b></p>
13502 <p>
13503 </p>
13504
13505
13506
13507
13508
13509 <hr>
13510 <h3><a name="766"></a>766. Inconsistent exception guarantees between ordered and unordered associative containers</h3>
13511 <p><b>Section:</b> 23.1 [container.requirements], 23.1.3.1 [unord.req.except] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
13512  <b>Submitter:</b> Ion Gaztañaga <b>Date:</b> 2007-12-22</p>
13513 <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>
13514 <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>
13515 <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>
13516 <p><b>Discussion:</b></p>
13517 <p>
13518 23.1 [container.requirements]p10 states:
13519 </p>
13520
13521 <blockquote>
13522 <p>
13523 Unless otherwise specified (see 23.2.2.3 and 23.2.5.4) all container types defined in this clause meet the following
13524 additional requirements:
13525 </p>
13526 <ul>
13527
13528 <li>[...]</li>
13529
13530 <li>no <tt>erase()</tt>, <tt>pop_back()</tt> or <tt>pop_front()</tt> function throws an exception.</li>
13531
13532 </ul>
13533 </blockquote>
13534
13535 <p>
13536 23.2.2.3 [deque.modifiers] and 23.2.6.4 [vector.modifiers] offer
13537 additional guarantees for <tt>deque</tt>/<tt>vector insert()</tt> and
13538 <tt>erase()</tt> members. However, 23.1 [container.requirements]p10
13539 does not mention 23.1.3.1 [unord.req.except] that specifies exception
13540 safety guarantees
13541 for unordered containers. In addition, 23.1.3.1 [unord.req.except]p1
13542 offers the following guaratee for
13543 <tt>erase()</tt>:
13544 </p>
13545
13546 <blockquote>
13547 No <tt>erase()</tt> function throws an exception unless that exception
13548 is thrown by the container's Hash or Pred object (if any).
13549 </blockquote>
13550
13551 <p>
13552 Summary:
13553 </p>
13554
13555 <p>
13556 According to 23.1 [container.requirements]p10 no
13557 <tt>erase()</tt> function should throw an exception unless otherwise
13558 specified. Although does not explicitly mention 23.1.3.1 [unord.req.except], this section offers additional guarantees
13559 for unordered containers, allowing <tt>erase()</tt> to throw if
13560 predicate or hash function throws.
13561 </p>
13562
13563 <p>
13564 In contrast, associative containers have no exception safety guarantees
13565 section so no <tt>erase()</tt> function should throw, <em>including
13566 <tt>erase(k)</tt></em> that needs to use the predicate function to
13567 perform its work. This means that the predicate of an associative
13568 container is not allowed to throw.
13569 </p>
13570
13571 <p>
13572 So:
13573 </p>
13574
13575 <ol>
13576 <li>
13577 <tt>erase(k)</tt> for associative containers is not allowed to throw. On
13578 the other hand, <tt>erase(k)</tt> for unordered associative containers
13579 is allowed to throw.
13580 </li>
13581 <li>
13582 <tt>erase(q)</tt> for associative containers is not allowed to throw. On
13583 the other hand, <tt>erase(q)</tt> for unordered associative containers
13584 is allowed to throw if it uses the hash or predicate.
13585 </li>
13586 <li>
13587 To fulfill 1), predicates of associative containers are not allowed to throw.
13588 Predicates of unordered associative containers are allowed to throw.
13589 </li>
13590 <li>
13591 2) breaks a widely used programming pattern (flyweight pattern) for
13592 unordered containers, where objects are registered in a global map in
13593 their constructors and unregistered in their destructors. If <tt>erase(q)</tt> is
13594 allowed to throw, the destructor of the object would need to rethrow the
13595 exception or swallow it, leaving the object registered.
13596 </li>
13597 </ol>
13598
13599
13600 <p><b>Proposed resolution:</b></p>
13601 <p>
13602 Create a new sub-section of 23.1.2 [associative.reqmts] (perhaps [associative.req.except]) titled "Exception
13603 safety guarantees".
13604 </p>
13605
13606 <blockquote>
13607 <p>
13608 1 For associative containers, no <tt>clear()</tt> function throws an exception.
13609 <tt>erase(k)</tt> does not throw an exception unless that exception is thrown by
13610 the container's Pred object (if any).
13611 </p>
13612
13613 <p>
13614 2 For associative containers, if an exception is thrown by any operation
13615 from within an <tt>insert()</tt> function inserting a single element, the
13616 <tt>insert()</tt> function has no effect.
13617 </p>
13618
13619 <p>
13620 3 For associative containers, no <tt>swap</tt> function throws an exception
13621 unless that exception is thrown by the copy constructor or copy
13622 assignment operator of the container's Pred object (if any).
13623 </p>
13624 </blockquote>
13625
13626 <p>
13627 Change 23.1.3.1 [unord.req.except]p1:
13628 </p>
13629
13630 <blockquote>
13631 For unordered associative containers, no <tt>clear()</tt> function
13632 throws an exception. <del>No</del> <tt>erase(<ins>k</ins>)</tt>
13633 <del>function</del> <ins>does not</ins> throw<del>s</del> an exception
13634 unless that exception is thrown by the container's Hash or Pred object
13635 (if any).
13636 </blockquote>
13637
13638 <p>
13639 Change 23.1 [container.requirements]p10 to add references to new sections:
13640 </p>
13641
13642 <blockquote>
13643 Unless otherwise specified (see [deque.modifiers]<ins>,</ins>
13644 <del>and</del> [vector.modifiers]<ins>, [associative.req.except],
13645 [unord.req.except]</ins>) all container types defined in this clause meet
13646 the following additional requirements:
13647 </blockquote>
13648
13649 <p>
13650 Change 23.1 [container.requirements]p10 referring to <tt>swap</tt>:
13651 </p>
13652
13653 <blockquote>
13654 <ul>
13655 <li>
13656 no <tt>swap()</tt> function throws an exception<del> unless that exception is thrown
13657 by the copy constructor or assignment operator of the container's
13658 Compare object (if any; see [associative.reqmts])</del>.
13659 </li>
13660 </ul>
13661 </blockquote>
13662
13663
13664
13665
13666
13667
13668 <hr>
13669 <h3><a name="767"></a>767. Forwarding and backward compatibility</h3>
13670 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
13671  <b>Submitter:</b> Sylvain Pion <b>Date:</b> 2007-12-28</p>
13672 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p>
13673 <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>
13674 <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>
13675 <p><b>Discussion:</b></p>
13676 <p>
13677 Playing with g++'s C++0X mode, I noticed that the following
13678 code, which used to compile:
13679 </p>
13680
13681 <blockquote><pre>#include &lt;vector&gt;
13682
13683 int main()
13684 {
13685     std::vector&lt;char *&gt; v;
13686     v.push_back(0);
13687 }
13688 </pre></blockquote>
13689
13690 <p>
13691 now fails with the following error message:
13692 </p>
13693
13694 <blockquote>.../include/c++/4.3.0/ext/new_allocator.h: In member
13695 function 'void __gnu_cxx::new_allocator&lt;_Tp&gt;::construct(_Tp*,
13696 _Args&amp;&amp; ...) [with _Args = int, _Tp = char*]':
13697 .../include/c++/4.3.0/bits/stl_vector.h:707: instantiated from 'void
13698 std::vector&lt;_Tp, _Alloc&gt;::push_back(_Args&amp;&amp; ...) [with
13699 _Args = int, _Tp = char*, _Alloc = std::allocator&lt;char*&gt;]'
13700 test.cpp:6: instantiated from here
13701 .../include/c++/4.3.0/ext/new_allocator.h:114: error: invalid
13702 conversion from 'int' to 'char*'
13703 </blockquote>
13704
13705 <p>
13706 As far as I know, g++ follows the current draft here.
13707 </p>
13708 <p>
13709 Does the committee really intend to break compatibility for such cases?
13710 </p>
13711
13712 <p><i>[
13713 Sylvain adds:
13714 ]</i></p>
13715
13716
13717 <blockquote>
13718 <p>
13719 I just noticed that <tt>std::pair</tt> has the same issue.
13720 The following now fails with GCC's -std=c++0x mode:
13721 </p>
13722
13723 <blockquote><pre>#include &lt;utility&gt;
13724
13725 int main()
13726 {
13727    std::pair&lt;char *, char *&gt; p (0,0);
13728 }
13729 </pre></blockquote>
13730
13731 <p>
13732 I have not made any general audit for such problems elsewhere.
13733 </p>
13734 </blockquote>
13735
13736 <p><i>[
13737 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#756">756</a>
13738 ]</i></p>
13739
13740
13741 <p><i>[
13742 Bellevue:
13743 ]</i></p>
13744
13745
13746 <blockquote>
13747 <p>
13748 Motivation is to handle the old-style int-zero-valued NULL pointers.
13749 Problem: this solution requires concepts in some cases, which some users
13750 will be slow to adopt. Some discussion of alternatives involving
13751 prohibiting variadic forms and additional library-implementation
13752 complexity.
13753 </p>
13754 <p>
13755 Discussion of "perfect world" solutions, the only such solution put
13756 forward being to retroactively prohibit use of the integer zero for a
13757 NULL pointer. This approach was deemed unacceptable given the large
13758 bodies of pre-existing code that do use integer zero for a NULL pointer.
13759 </p>
13760 <p>
13761 Another approach is to change the member names. Yet another approach is
13762 to forbid the extension in absence of concepts.
13763 </p>
13764 <p>
13765 Resolution: These issues (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>) will be subsumed into a
13766 paper to be produced by Alan Talbot in time for review at the 2008
13767 meeting in France. Once this paper is produced, these issues will be
13768 moved to NAD.
13769 </p>
13770 </blockquote>
13771
13772
13773
13774 <p><b>Proposed resolution:</b></p>
13775 <p>
13776 Add the following rows to Table 90 "Optional sequence container operations", 23.1.1 [sequence.reqmts]:
13777 </p>
13778
13779 <blockquote>
13780 <table border="1">
13781 <tbody><tr>
13782 <th>expression</th> <th>return type</th> <th>assertion/note<br>pre-/post-condition</th> <th>container</th>
13783 </tr>
13784
13785 <tr>
13786 <td>
13787 <tt>a.push_front(t)</tt>
13788 </td>
13789 <td>
13790 <tt>void</tt>
13791 </td>
13792 <td>
13793 <tt>a.insert(a.begin(), t)</tt><br>
13794 <i>Requires:</i> <tt>T</tt> shall be <tt>CopyConstructible</tt>.
13795 </td>
13796 <td>
13797 <tt>list, deque</tt>
13798 </td>
13799 </tr>
13800
13801 <tr>
13802 <td>
13803 <tt>a.push_front(rv)</tt>
13804 </td>
13805 <td>
13806 <tt>void</tt>
13807 </td>
13808 <td>
13809 <tt>a.insert(a.begin(), rv)</tt><br>
13810 <i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt>.
13811 </td>
13812 <td>
13813 <tt>list, deque</tt>
13814 </td>
13815 </tr>
13816
13817 <tr>
13818 <td>
13819 <tt>a.push_back(t)</tt>
13820 </td>
13821 <td>
13822 <tt>void</tt>
13823 </td>
13824 <td>
13825 <tt>a.insert(a.end(), t)</tt><br>
13826 <i>Requires:</i> <tt>T</tt> shall be <tt>CopyConstructible</tt>.
13827 </td>
13828 <td>
13829 <tt>list, deque, vector, basic_string</tt>
13830 </td>
13831 </tr>
13832
13833 <tr>
13834 <td>
13835 <tt>a.push_back(rv)</tt>
13836 </td>
13837 <td>
13838 <tt>void</tt>
13839 </td>
13840 <td>
13841 <tt>a.insert(a.end(), rv)</tt><br>
13842 <i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt>.
13843 </td>
13844 <td>
13845 <tt>list, deque, vector, basic_string</tt>
13846 </td>
13847 </tr>
13848
13849 </tbody></table>
13850 </blockquote>
13851
13852 <p>
13853 Change the synopsis in 23.2.2 [deque]:
13854 </p>
13855
13856 <blockquote><pre><ins>void push_front(const T&amp; x);</ins>
13857 <ins>void push_front(T&amp;&amp; x);</ins>
13858 <ins>void push_back(const T&amp; x);</ins>
13859 <ins>void push_back(T&amp;&amp; x);</ins>
13860 template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_front(Args&amp;&amp;... args);
13861 template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
13862 </pre></blockquote>
13863
13864 <p>
13865 Change 23.2.2.3 [deque.modifiers]:
13866 </p>
13867
13868 <blockquote><pre><ins>void push_front(const T&amp; x);</ins>
13869 <ins>void push_front(T&amp;&amp; x);</ins>
13870 <ins>void push_back(const T&amp; x);</ins>
13871 <ins>void push_back(T&amp;&amp; x);</ins>
13872 template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_front(Args&amp;&amp;... args);
13873 template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
13874 </pre></blockquote>
13875
13876 <p>
13877 Change the synopsis in 23.2.4 [list]:
13878 </p>
13879
13880 <blockquote><pre><ins>void push_front(const T&amp; x);</ins>
13881 <ins>void push_front(T&amp;&amp; x);</ins>
13882 <ins>void push_back(const T&amp; x);</ins>
13883 <ins>void push_back(T&amp;&amp; x);</ins>
13884 template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_front(Args&amp;&amp;... args);
13885 template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
13886 </pre></blockquote>
13887
13888 <p>
13889 Change 23.2.4.3 [list.modifiers]:
13890 </p>
13891
13892 <blockquote><pre><ins>void push_front(const T&amp; x);</ins>
13893 <ins>void push_front(T&amp;&amp; x);</ins>
13894 <ins>void push_back(const T&amp; x);</ins>
13895 <ins>void push_back(T&amp;&amp; x);</ins>
13896 template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_front(Args&amp;&amp;... args);
13897 template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
13898 </pre></blockquote>
13899
13900 <p>
13901 Change the synopsis in 23.2.6 [vector]:
13902 </p>
13903
13904 <blockquote><pre><ins>void push_back(const T&amp; x);</ins>
13905 <ins>void push_back(T&amp;&amp; x);</ins>
13906 template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
13907 </pre></blockquote>
13908
13909 <p>
13910 Change 23.2.6.4 [vector.modifiers]:
13911 </p>
13912
13913 <blockquote><pre><ins>void push_back(const T&amp; x);</ins>
13914 <ins>void push_back(T&amp;&amp; x);</ins>
13915 template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
13916 </pre></blockquote>
13917
13918
13919
13920
13921
13922
13923
13924 <hr>
13925 <h3><a name="768"></a>768. Typos in [atomics]?</h3>
13926 <p><b>Section:</b> 29.4.3 [atomics.types.generic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
13927  <b>Submitter:</b> Alberto Ganesh Barbati <b>Date:</b> 2007-12-28</p>
13928 <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>
13929 <p><b>Discussion:</b></p>
13930 <p>
13931 in the latest publicly available draft, paper
13932 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">N2641</a>,
13933 in section 29.4.3 [atomics.types.generic], the following specialization of the template
13934 <tt>atomic&lt;&gt;</tt> is provided for pointers:
13935 </p>
13936
13937 <blockquote><pre>template &lt;class T&gt; struct atomic&lt;T*&gt; : atomic_address {
13938   T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile;
13939   T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile;
13940
13941   atomic() = default;
13942   constexpr explicit atomic(T);
13943   atomic(const atomic&amp;) = delete;
13944   atomic&amp; operator=(const atomic&amp;) = delete;
13945
13946   T* operator=(T*) volatile;
13947   T* operator++(int) volatile;
13948   T* operator--(int) volatile;
13949   T* operator++() volatile;
13950   T* operator--() volatile;
13951   T* operator+=(ptrdiff_t) volatile;
13952   T* operator-=(ptrdiff_t) volatile;
13953 };
13954 </pre></blockquote>
13955
13956 <p>
13957 First of all, there is a typo in the non-default constructor which
13958 should take a <tt>T*</tt> rather than a <tt>T</tt>.
13959 </p>
13960
13961 <p>
13962 As you can see, the specialization redefine and therefore hide a few
13963 methods from the base class <tt>atomic_address</tt>, namely <tt>fetch_add</tt>, <tt>fetch_sub</tt>,
13964 <tt>operator=</tt>, <tt>operator+=</tt> and <tt>operator-=</tt>. That's good, but... what happened
13965 to the other methods, in particular these ones:
13966 </p>
13967
13968 <blockquote><pre>void store(T*, memory_order = memory_order_seq_cst) volatile;
13969 T* load( memory_order = memory_order_seq_cst ) volatile;
13970 T* swap( T*, memory_order = memory_order_seq_cst ) volatile;
13971 bool compare_swap( T*&amp;, T*, memory_order, memory_order ) volatile;
13972 bool compare_swap( T*&amp;, T*, memory_order = memory_order_seq_cst ) volatile;
13973 </pre></blockquote>
13974
13975 <p>
13976 By reading paper
13977 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html">N2427 "C++ Atomic Types and Operations"</a>,
13978 I see that the
13979 definition of the specialization <tt>atomic&lt;T*&gt;</tt> matches the one in the
13980 draft, but in the example implementation the methods <tt>load()</tt>, <tt>swap()</tt>
13981 and <tt>compare_swap()</tt> are indeed present.
13982 </p>
13983
13984 <p>
13985 Strangely, the example implementation does not redefine the method
13986 <tt>store()</tt>. It's true that a <tt>T*</tt> is always convertible to <tt>void*</tt>, but not
13987 hiding the <tt>void*</tt> signature from the base class makes the class
13988 error-prone to say the least: it lets you assign pointers of any type to
13989 a <tt>T*</tt>, without any hint from the compiler.
13990 </p>
13991
13992 <p>
13993 Is there a true intent to remove them from the specialization or are
13994 they just missing from the definition because of a mistake?
13995 </p>
13996
13997 <p><i>[
13998 Bellevue:
13999 ]</i></p>
14000
14001
14002 <blockquote>
14003 <p>
14004 The proposed revisions are accepted.
14005 </p>
14006 <p>
14007 Further discussion: why is the ctor labeled "constexpr"? Lawrence said
14008 this permits the object to be statically initialized, and that's
14009 important because otherwise there would be a race condition on
14010 initialization.
14011 </p>
14012 </blockquote>
14013
14014
14015 <p><b>Proposed resolution:</b></p>
14016 <p>
14017 Change the synopsis in 29.4.3 [atomics.types.generic]:
14018 </p>
14019
14020 <blockquote><pre>template &lt;class T&gt; struct atomic&lt;T*&gt; : atomic_address {
14021   <ins>void store(T*, memory_order = memory_order_seq_cst) volatile;</ins>
14022   <ins>T* load( memory_order = memory_order_seq_cst ) volatile;</ins>
14023   <ins>T* swap( T*, memory_order = memory_order_seq_cst ) volatile;</ins>
14024   <ins>bool compare_swap( T*&amp;, T*, memory_order, memory_order ) volatile;</ins>
14025   <ins>bool compare_swap( T*&amp;, T*, memory_order = memory_order_seq_cst ) volatile;</ins>
14026
14027   T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile;
14028   T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile;
14029
14030   atomic() = default;
14031   constexpr explicit atomic(T<ins>*</ins>);
14032   atomic(const atomic&amp;) = delete;
14033   atomic&amp; operator=(const atomic&amp;) = delete;
14034
14035   T* operator=(T*) volatile;
14036   T* operator++(int) volatile;
14037   T* operator--(int) volatile;
14038   T* operator++() volatile;
14039   T* operator--() volatile;
14040   T* operator+=(ptrdiff_t) volatile;
14041   T* operator-=(ptrdiff_t) volatile;
14042 };
14043 </pre></blockquote>
14044
14045
14046
14047
14048
14049
14050 <hr>
14051 <h3><a name="769"></a>769. std::function should use nullptr_t instead of "unspecified-null-pointer-type"</h3>
14052 <p><b>Section:</b> 20.5.15.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
14053  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-10</p>
14054 <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>
14055 <p><b>Discussion:</b></p>
14056 <p>
14057 N2461 already replaced in 20.5.15.2 [func.wrap.func] it's originally proposed
14058 (implicit) conversion operator to "unspecified-bool-type" by the new
14059 explicit bool conversion, but the inverse conversion should also
14060 use the new <tt>std::nullptr_t</tt> type instead of "unspecified-null-pointer-
14061 type".
14062 </p>
14063
14064
14065 <p><b>Proposed resolution:</b></p>
14066
14067 <p>
14068 In 20.5 [function.objects], header <tt>&lt;functional&gt;</tt> synopsis replace:
14069 </p>
14070
14071 <blockquote><pre>template&lt;class R, class... ArgTypes&gt;
14072   bool operator==(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
14073 template&lt;class R, class... ArgTypes&gt;
14074   bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
14075 template&lt;class R, class... ArgTypes&gt;
14076   bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
14077 template&lt;class R, class... ArgTypes&gt;
14078   bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
14079 </pre></blockquote>
14080
14081 <p>
14082 In the class function synopsis of 20.5.15.2 [func.wrap.func] replace
14083 </p>
14084
14085 <blockquote><pre>function(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
14086 ...
14087 function&amp; operator=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
14088 </pre></blockquote>
14089
14090 <p>
14091 In 20.5.15.2 [func.wrap.func], "Null pointer comparisons" replace:
14092 </p>
14093
14094 <blockquote><pre>template &lt;class R, class... ArgTypes&gt;
14095   bool operator==(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
14096 template &lt;class R, class... ArgTypes&gt;
14097   bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
14098 template &lt;class R, class... ArgTypes&gt;
14099   bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
14100 template &lt;class R, class... ArgTypes&gt;
14101   bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
14102 </pre></blockquote>
14103
14104 <p>
14105 In 20.5.15.2.1 [func.wrap.func.con], replace
14106 </p>
14107
14108 <blockquote><pre>function(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
14109 ...
14110 function&amp; operator=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
14111 </pre></blockquote>
14112
14113 <p>
14114 In 20.5.15.2.6 [func.wrap.func.nullptr], replace
14115 </p>
14116
14117 <blockquote><pre>template &lt;class R, class... ArgTypes&gt;
14118   bool operator==(const function&lt;R(ArgTypes...)&gt;&amp; f, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
14119 template &lt;class R, class... ArgTypes&gt;
14120   bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp; f);
14121 </pre></blockquote>
14122
14123 <p>
14124 and replace
14125 </p>
14126
14127 <blockquote><pre>template &lt;class R, class... ArgTypes&gt;
14128   bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp; f, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
14129 template &lt;class R, class... ArgTypes&gt;
14130   bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp; f);
14131 </pre></blockquote>
14132
14133
14134
14135
14136
14137
14138 <hr>
14139 <h3><a name="770"></a>770. std::function should use rvalue swap</h3>
14140 <p><b>Section:</b> 20.5.15 [func.wrap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
14141  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-10</p>
14142 <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>
14143 <p><b>Discussion:</b></p>
14144 <p>
14145 It is expected that typical implementations of <tt>std::function</tt> will
14146 use dynamic memory allocations at least under given conditions,
14147 so it seems appropriate to change the current lvalue swappabilty of
14148 this class to rvalue swappability.
14149 </p>
14150
14151
14152 <p><b>Proposed resolution:</b></p>
14153 <p>
14154 In 20.5 [function.objects], header <tt>&lt;functional&gt;</tt> synopsis, just below of
14155 </p>
14156
14157 <blockquote><pre>template&lt;class R, class... ArgTypes&gt;
14158   void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
14159 <ins>template&lt;class R, class... ArgTypes&gt;
14160   void swap(function&lt;R(ArgTypes...)&gt;&amp;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
14161 template&lt;class R, class... ArgTypes&gt;
14162   void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;&amp;);</ins>
14163 </pre></blockquote>
14164
14165 <p>
14166 In 20.5.15.2 [func.wrap.func] class <tt>function</tt> definition, change
14167 </p>
14168
14169 <blockquote><pre>void swap(function&amp;<ins>&amp;</ins>);
14170 </pre></blockquote>
14171
14172 <p>
14173 In 20.5.15.2 [func.wrap.func], just below of
14174 </p>
14175
14176 <blockquote><pre>template &lt;class R, class... ArgTypes&gt;
14177   void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
14178 <ins>template &lt;class R, class... ArgTypes&gt;
14179   void swap(function&lt;R(ArgTypes...)&gt;&amp;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
14180 template &lt;class R, class... ArgTypes&gt;
14181   void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;&amp;);</ins>
14182 </pre></blockquote>
14183
14184 <p>
14185 In 20.5.15.2.2 [func.wrap.func.mod] change
14186 </p>
14187
14188 <blockquote><pre>void swap(function&amp;<ins>&amp;</ins> other);
14189 </pre></blockquote>
14190
14191 <p>
14192 In 20.5.15.2.7 [func.wrap.func.alg] add the two overloads
14193 </p>
14194
14195 <blockquote><pre><ins>template&lt;class R, class... ArgTypes&gt;
14196   void swap(function&lt;R(ArgTypes...)&gt;&amp;&amp; f1, function&lt;R(ArgTypes...)&gt;&amp; f2);
14197 template&lt;class R, class... ArgTypes&gt;
14198   void swap(function&lt;R(ArgTypes...)&gt;&amp; f1, function&lt;R(ArgTypes...)&gt;&amp;&amp; f2);</ins>
14199 </pre></blockquote>
14200
14201
14202
14203
14204
14205
14206 <hr>
14207 <h3><a name="771"></a>771. Impossible throws clause in [string.conversions]</h3>
14208 <p><b>Section:</b> 21.4 [string.conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
14209  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-13</p>
14210 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#string.conversions">active issues</a> in [string.conversions].</p>
14211 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.conversions">issues</a> in [string.conversions].</p>
14212 <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>
14213 <p><b>Discussion:</b></p>
14214 <p>
14215 The new <tt>to_string</tt> and <tt>to_wstring</tt> functions described in 21.4 [string.conversions]
14216 have throws clauses (paragraphs 8 and 16) which say:
14217 </p>
14218
14219 <blockquote>
14220 <i>Throws:</i> nothing
14221 </blockquote>
14222
14223 <p>
14224 Since all overloads return either a <tt>std::string</tt> or a <tt>std::wstring</tt> by value
14225 this throws clause is impossible to realize in general, since the <tt>basic_string</tt>
14226 constructors can fail due to out-of-memory conditions. Either these throws
14227 clauses should be removed or should be more detailled like:
14228 </p>
14229
14230 <blockquote>
14231 <i>Throws:</i> Nothing if the string construction throws nothing
14232 </blockquote>
14233
14234 <p>
14235 Further there is an editorial issue in p. 14: All three <tt>to_wstring</tt>
14236 overloads return a <tt>string</tt>, which should be <tt>wstring</tt> instead (The
14237 header <tt>&lt;string&gt;</tt> synopsis of 21.2 [string.classes] is correct in this
14238 regard).
14239 </p>
14240
14241
14242
14243 <p><b>Proposed resolution:</b></p>
14244 <p>
14245 In 21.4 [string.conversions], remove the paragraphs 8 and 16.
14246 </p>
14247
14248 <blockquote>
14249 <pre>string to_string(long long val);
14250 string to_string(unsigned long long val);
14251 string to_string(long double val);
14252 </pre>
14253 <blockquote>
14254 <del><i>Throws:</i> nothing</del>
14255 </blockquote>
14256 </blockquote>
14257
14258 <blockquote>
14259 <pre><ins>w</ins>string to_wstring(long long val);
14260 <ins>w</ins>string to_wstring(unsigned long long val);
14261 <ins>w</ins>string to_wstring(long double val);
14262 </pre>
14263 <blockquote>
14264 <del><i>Throws:</i> nothing</del>
14265 </blockquote>
14266 </blockquote>
14267
14268
14269
14270
14271
14272
14273 <hr>
14274 <h3><a name="772"></a>772.  Impossible return clause in [string.conversions]</h3>
14275 <p><b>Section:</b> 21.4 [string.conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
14276  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-13</p>
14277 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#string.conversions">active issues</a> in [string.conversions].</p>
14278 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.conversions">issues</a> in [string.conversions].</p>
14279 <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>
14280 <p><b>Discussion:</b></p>
14281 <p>
14282 The return clause 21.4 [string.conversions]/paragraph 15 of the new <tt>to_wstring</tt>
14283 overloads says:
14284 </p>
14285
14286 <blockquote>
14287 <i>Returns:</i> each function returns a <tt>wstring</tt> object holding the character
14288 representation of the value of its argument that would be generated by
14289 calling <tt>wsprintf(buf, fmt, val)</tt> with a format specifier of <tt>L"%lld"</tt>, <tt>L"%ulld"</tt>,
14290 or <tt>L"%f"</tt>, respectively.
14291 </blockquote>
14292
14293 <p>
14294 Problem is: There does not exist any <tt>wsprintf</tt> function in C99 (I checked
14295 the 2nd edition of ISO 9899, and the first and the second corrigenda from
14296 2001-09-01 and 2004-11-15). What probably meant here is the function
14297 <tt>swprintf</tt> from <tt>&lt;wchar.h&gt;/&lt;cwchar&gt;</tt>, but this has the non-equivalent
14298 declaration:
14299 </p>
14300
14301 <blockquote><pre>int swprintf(wchar_t * restrict s, size_t n,
14302 const wchar_t * restrict format, ...);
14303 </pre></blockquote>
14304
14305 <p>
14306 therefore the paragraph needs to mention the <tt>size_t</tt> parameter <tt>n</tt>.
14307 </p>
14308
14309
14310
14311 <p><b>Proposed resolution:</b></p>
14312 <p>
14313 Change the current wording of 21.4 [string.conversions]/p. 15 to:
14314 </p>
14315
14316 <blockquote>
14317 <i>Returns:</i> <del>e</del><ins>E</ins>ach function returns a
14318 <tt>wstring</tt> object holding the character representation of the
14319 value of its argument that would be generated by calling
14320 <tt><del>ws</del><ins>sw</ins>printf(buf, <ins>bufsz,</ins> fmt,
14321 val)</tt> with a format specifier <ins><tt>fmt</tt></ins> of <tt>L"%lld"</tt>,
14322 <tt>L"%ulld"</tt>, or <tt>L"%f"</tt>, respectively<ins>, where <tt>buf</tt>
14323 designates an internal character buffer of sufficient size <tt>bufsz</tt></ins>.
14324 </blockquote>
14325
14326 <p>
14327 [Hint to the editor: The resolution also adds to mention the name of
14328 the format specifier "fmt"]
14329 </p>
14330
14331 <p>
14332 I also would like to remark that the current wording of it's equivalent
14333 paragraph 7 should also mention the meaning of <tt>buf</tt> and <tt>fmt</tt>.
14334 </p>
14335
14336 <p>
14337 Change the current wording of 21.4 [string.conversions]/p. 7 to:
14338 </p>
14339
14340 <blockquote>
14341 <i>Returns:</i> <del>e</del><ins>E</ins>ach function returns a string object holding the
14342 character representation of the value of its argument that would be
14343 generated by calling <tt>sprintf(buf, fmt, val)</tt> with a format specifier <ins><tt>fmt</tt></ins> of
14344 <tt>"%lld"</tt>, <tt>"%ulld"</tt>, or <tt>"%f"</tt>, respectively<ins>, where <tt>buf</tt> designates an internal
14345 character buffer of sufficient size</ins>.
14346 </blockquote>
14347
14348
14349
14350
14351
14352
14353 <hr>
14354 <h3><a name="774"></a>774. Member swap undefined for most containers</h3>
14355 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
14356  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-01-14</p>
14357 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p>
14358 <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>
14359 <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>
14360 <p><b>Discussion:</b></p>
14361 <p>
14362 It appears most containers declare but do not define a member-swap
14363 function.
14364 </p>
14365
14366 <p>
14367 This is unfortunate, as all overload the <tt>swap</tt> algorithm to call the
14368 member-swap function!
14369 (required for <tt>swappable</tt> guarantees [Table 37] and Container Requirements
14370 [Table 87])
14371 </p>
14372
14373 <p>
14374 Note in particular that Table 87 gives semantics of <tt>a.swap(b)</tt> as <tt>swap(a,b)</tt>,
14375 yet for all containers we define <tt>swap(a,b)</tt> to call <tt>a.swap(b)</tt> - a circular
14376 definition.
14377 </p>
14378
14379 <p>
14380 A quick survey of clause 23 shows that the following containers provide a
14381 definition for member-swap:
14382 </p>
14383
14384 <blockquote><pre>array
14385 queue
14386 stack
14387 vector
14388 </pre></blockquote>
14389
14390 <p>
14391 Whereas the following declare it, but do not define the semantics:
14392 </p>
14393
14394 <blockquote><pre>deque
14395 list
14396 map
14397 multimap
14398 multiset
14399 priority_queue
14400 set
14401 unordered_map
14402 unordered_multi_map
14403 unordered_multi_set
14404 unordered_set
14405 </pre></blockquote>
14406
14407 <p>
14408 Suggested resolution:
14409 </p>
14410 <blockquote>
14411 Provide a definition for each of the affected containers...
14412 </blockquote>
14413
14414 <p><i>[
14415 Bellevue:
14416 ]</i></p>
14417
14418
14419 <blockquote>
14420 Move to Open and ask Alisdair to provide wording.
14421 </blockquote>
14422
14423
14424 <p><b>Proposed resolution:</b></p>
14425 <p>
14426 Wording provided in
14427 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2590.pdf">N2590</a>.
14428 </p>
14429
14430
14431
14432
14433
14434 <hr>
14435 <h3><a name="775"></a>775. Tuple indexing should be unsigned?</h3>
14436 <p><b>Section:</b> 20.3.1.4 [tuple.helper] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
14437  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-01-16</p>
14438 <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>
14439 <p><b>Discussion:</b></p>
14440 <p>
14441 The tuple element access API identifies the element in the sequence
14442 using signed integers, and then goes on to enforce the requirement that
14443 I be &gt;= 0.  There is a much easier way to do this - declare I as
14444 <tt>unsigned</tt>.
14445 </p>
14446 <p>
14447 In fact the proposal is to use <code>std::size_t</code>, matching the type used in the <tt>tuple_size</tt> API.
14448 </p>
14449 <p>
14450 A second suggestion is that it is hard to imagine an API that deduces
14451 and index at compile time and returns a reference throwing an exception.
14452 Add a specific <em>Throws:</em> Nothing paragraph to each element
14453 access API.
14454 </p>
14455 <p>
14456 In addition to <code>tuple</code>, update the API applies to
14457 <code>pair</code> and <code>array</code>, and should be updated
14458 accordingly.
14459 </p>
14460
14461 <p>
14462 A third observation is that the return type of the <code>get</code>
14463 functions for <code>std::pair</code> is pseudo-code, but it is not
14464 clearly marked as such.  There is actually no need for pseudo-code as
14465 the return type can be specified precisely with a call to
14466 <code>tuple_element</code>.  This is already done for
14467 <code>std::tuple</code>, and <code>std::array</code> does not have a
14468 problem as all elements are of type <code>T</code>.
14469 </p>
14470
14471
14472 <p><b>Proposed resolution:</b></p>
14473 <p>
14474 Update header &lt;utility&gt; synopsis in 20.2 [utility]
14475 </p>
14476 <pre><em>// 20.2.3, tuple-like access to pair:</em>
14477 template &lt;class T&gt; class tuple_size;
14478 template &lt;<del>int</del><ins>size_t</ins> I, class T&gt; class tuple_element;
14479
14480 template &lt;class T1, class T2&gt; struct tuple_size&lt;std::pair&lt;T1, T2&gt; &gt;;
14481 template &lt;class T1, class T2&gt; struct tuple_element&lt;0, std::pair&lt;T1, T2&gt; &gt;;
14482 template &lt;class T1, class T2&gt; struct tuple_element&lt;1, std::pair&lt;T1, T2&gt; &gt;;
14483
14484 template&lt;<del>int</del><ins>size_t</ins> I, class T1, class T2&gt;
14485   <del>P</del><ins>typename tuple_element&lt;I, std::pair&lt;T1, T2&gt; &gt;::type </ins>&amp; get(std::pair&lt;T1, T2&gt;&amp;);
14486 template&lt;<del>int</del><ins>size_t</ins> I, class T1, class T2&gt;
14487   const <del>P</del><ins>typename tuple_element&lt;I, std::pair&lt;T1, T2&gt; &gt;::type </ins>&amp; get(const std::pair&lt;T1, T2&gt;&amp;);
14488 </pre>
14489 <p>
14490 Update <strong>20.2.3 [pairs] Pairs</strong>
14491 </p>
14492 <pre>template&lt;<del>int</del><ins>size_t</ins> I, class T1, class T2&gt;
14493   <del>P</del><ins>typename tuple_element&lt;I, std::pair&lt;T1, T2&gt; &gt;::type </ins>&amp; get(pair&lt;T1, T2&gt;&amp;);
14494 template&lt;<del>int</del><ins>size_t</ins> I, class T1, class T2&gt;
14495   const <del>P</del><ins>typename tuple_element&lt;I, std::pair&lt;T1, T2&gt; &gt;::type </ins>&amp; get(const pair&lt;T1, T2&gt;&amp;);
14496 </pre>
14497 <p>
14498 <del>24 <em>Return type:</em> If <code>I == 0</code> then <code>P</code> is <code>T1</code>, if <code>I == 1</code> then <code>P</code> is <code>T2</code>, and otherwise the program is ill-formed.</del>
14499 </p>
14500 <p>
14501 25 <em>Returns:</em> If <code>I == 0</code> returns <code>p.first</code>, <del>otherwise</del> <ins>if <code>I == 1</code></ins> returns <code>p.second</code><ins>, and otherwise the program is ill-formed</ins>.
14502 </p>
14503 <p>
14504 <ins><em>Throws:</em> Nothing.</ins>
14505 </p>
14506
14507
14508 <p>
14509 Update header &lt;tuple&gt; synopsis in 20.3 [tuple] with a APIs as below:
14510 </p>
14511 <pre>template &lt;<del>int</del><ins>size_t</ins> I, class T&gt; class tuple_element; <em>// undefined</em>
14512 template &lt;<del>int</del><ins>size_t</ins> I, class... Types&gt; class tuple_element&lt;I, tuple&lt;Types...&gt; &gt;;
14513
14514 <em>// 20.3.1.4, element access:</em>
14515 template &lt;<del>int</del><ins>size_t</ins> I, class... Types&gt;
14516   typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type&amp; get(tuple&lt;Types...&gt;&amp;);
14517 template &lt;<del>int</del><ins>size_t</ins> I, class ... types&gt;
14518   typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type const&amp; get(const tuple&lt;Types...&gt;&amp;);
14519 </pre>
14520
14521 <p>
14522 Update <strong>20.3.1.4 [tuple.helper] Tuple helper classes</strong>
14523 </p>
14524 <pre>template &lt;<del>int</del><ins>size_t</ins> I, class... Types&gt;
14525 class tuple_element&lt;I, tuple&lt;Types...&gt; &gt; {
14526 public:
14527   typedef TI type;
14528 };</pre>
14529 <p>
14530 1 <em>Requires:</em> <code><del>0 &lt;= I and </del>I &lt; sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds.
14531 </p>
14532 <p>
14533 2 <em>Type:</em> <code>TI</code> is the type of the <code>I</code>th element of <code>Types</code>, where indexing is zero-based.
14534 </p>
14535 <p>
14536 Update <strong>20.3.1.5 [tuple.elem] Element access</strong>
14537 </p>
14538 <pre>template &lt;<del>int</del><ins>size_t</ins> I, class... types &gt;
14539 typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type&amp; get(tuple&lt;Types...&gt;&amp; t);
14540 </pre>
14541 1 <em>Requires:</em> <code><del>0 &lt;= I and </del>I &lt; sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds.
14542 <p>
14543 2 <em>Returns:</em> A reference to the <code>I</code>th element of <code>t</code>, where indexing is zero-based.
14544 </p>
14545 <ins><em>Throws:</em> Nothing.</ins>
14546 <pre>template &lt;<del>int</del><ins>size_t</ins> I, class... types&gt;
14547 typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type const&amp; get(const tuple&lt;Types...&gt;&amp; t);
14548 </pre>
14549 <p>
14550 3 <em>Requires:</em> <code><del>0 &lt;= I and </del>I &lt; sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds.
14551 </p>
14552 <p>
14553 4 <em>Returns:</em> A const reference to the <code>I</code>th element of <code>t</code>, where indexing is zero-based.
14554 </p>
14555 <p>
14556 <ins><em>Throws:</em> Nothing.</ins>
14557 </p>
14558
14559
14560 <p>
14561 Update header &lt;array&gt; synopsis in 20.2 [utility]
14562 </p>
14563 <pre>template &lt;class T&gt; class tuple_size; <em>// forward declaration</em>
14564 template &lt;<del>int</del><ins>size_t</ins> I, class T&gt; class tuple_element; <em>// forward declaration</em>
14565 template &lt;class T, size_t N&gt;
14566   struct tuple_size&lt;array&lt;T, N&gt; &gt;;
14567 template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt;
14568   struct tuple_element&lt;I, array&lt;T, N&gt; &gt;;
14569 template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt;
14570   T&amp; get(array&lt;T, N&gt;&amp;);
14571 template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt;
14572   const T&amp; get(const array&lt;T, N&gt;&amp;);
14573 </pre>
14574
14575 <p>
14576 Update <strong>23.2.1.6 [array.tuple] Tuple interface to class template array</strong>
14577 </p>
14578 <pre>tuple_element&lt;<ins>size_t </ins>I, array&lt;T, N&gt; &gt;::type
14579 </pre>
14580 <p>
14581 3 <em>Requires:</em> <code><del>0 &lt;= </del>I &lt; N.</code> The program is ill-formed if <code>I</code> is out of bounds.
14582 </p>
14583 <p>
14584 4 <em>Value:</em> The type <code>T</code>.
14585 </p>
14586 <pre>template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt; T&amp; get(array&lt;T, N&gt;&amp; a);
14587 </pre>
14588 <p>
14589 5 <em>Requires:</em> <code><del>0 &lt;= </del>I &lt; N</code>. The program is ill-formed if <code>I</code> is out of bounds.
14590 </p>
14591 <p>
14592 <em>Returns:</em> A reference to the <code>I</code>th element of <code>a</code>, where indexing is zero-based.
14593 </p>
14594 <p>
14595 <ins><em>Throws:</em> Nothing.</ins>
14596 </p>
14597 <pre>template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt; const T&amp; get(const array&lt;T, N&gt;&amp; a);
14598 </pre>
14599 <p>
14600 6 <em>Requires:</em> <code><del>0 &lt;= </del>I &lt; N</code>. The program is ill-formed if <code>I</code> is out of bounds.
14601 </p>
14602 <p>
14603 7 <em>Returns:</em> A const reference to the <code>I</code>th element of <code>a</code>, where indexing is zero-based.
14604 </p>
14605 <p>
14606 <ins><em>Throws:</em> Nothing.</ins>
14607 </p>
14608
14609
14610 <p><i>[
14611 Bellevue: Note also that the phrase "The program is ill-formed if I is
14612 out of bounds" in the requires clauses are probably unnecessary, and
14613 could be removed at the editor's discretion. Also std:: qualification
14614 for pair is also unnecessary.
14615 ]</i></p>
14616
14617
14618
14619
14620 <hr>
14621 <h3><a name="776"></a>776. Undescribed assign function of std::array</h3>
14622 <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#Review">Review</a>
14623  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-20</p>
14624 <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>
14625 <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>
14626 <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>
14627 <p><b>Discussion:</b></p>
14628 <p>
14629 The class template array synopsis in 23.2.1 [array]/3 declares a member
14630 function
14631 </p>
14632
14633 <blockquote><pre>void assign(const T&amp; u);
14634 </pre></blockquote>
14635
14636 <p>
14637 which's semantic is no-where described. Since this signature is
14638 not part of the container requirements, such a semantic cannot
14639 be derived by those.
14640 </p>
14641
14642 <p>
14643 I found only one reference to this function in the issue list,
14644 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a> where the question is raised:
14645 </p>
14646
14647 <blockquote>
14648 what's the effect of calling <tt>assign(T&amp;)</tt> on a zero-sized array?
14649 </blockquote>
14650
14651 <p>
14652 which does not answer the basic question of this issue.
14653 </p>
14654
14655 <p>
14656 If this function shall be part of the <tt>std::array</tt>, it's probable
14657 semantic should correspond to that of <tt>boost::array</tt>, but of
14658 course such wording must be added.
14659 </p>
14660
14661
14662 <p><b>Proposed resolution:</b></p>
14663 <p>
14664 Just after the section 23.2.1.4 [array.data] add the following new section:
14665 </p>
14666
14667 <p>
14668 23.2.1.5 array::fill [array.fill]
14669 </p>
14670
14671 <blockquote>
14672 <pre>void fill(const T&amp; u);
14673 </pre>
14674
14675 <p>
14676 1: <i>Effects:</i> <tt>fill_n(begin(), N, u)</tt>
14677 </p>
14678 </blockquote>
14679
14680 <p>
14681 [N.B: I wonder, why class <tt>array</tt> does not have a "modifiers"
14682 section. If it had, then <tt>assign</tt> would naturally belong to it]
14683 </p>
14684
14685 <p>
14686 Change the synopsis in 23.2.1 [array]/3:
14687 </p>
14688
14689 <blockquote><pre>template &lt;class T, size_t N&gt;
14690 struct array {
14691   ...
14692   void <del>assign</del> <ins>fill</ins>(const T&amp; u);
14693   ...
14694 </pre></blockquote>
14695
14696
14697 <p><i>[
14698 Bellevue:
14699 ]</i></p>
14700
14701
14702 <blockquote>
14703 <p>
14704 Suggest substituting "fill" instead of "assign".
14705 </p>
14706 <p>
14707 Set state to Review given substitution of "fill" for "assign".
14708 </p>
14709 </blockquote>
14710
14711
14712
14713
14714 <hr>
14715 <h3><a name="777"></a>777. Atomics Library Issue</h3>
14716 <p><b>Section:</b> 29.4.4 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
14717  <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-01-21</p>
14718 <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>
14719 <p><b>Discussion:</b></p>
14720 <p>
14721 The load functions are defined as
14722 </p>
14723
14724 <blockquote><pre>C atomic_load(volatile A* object);
14725 C atomic_load_explicit(volatile A* object, memory_order);
14726 C A::load(memory_order order = memory_order_seq_cst) volatile;
14727 </pre></blockquote>
14728
14729 <p>
14730 which prevents their use in <tt>const</tt> contexts.
14731 </p>
14732
14733 <p><i>[
14734 post Bellevue Peter adds:
14735 ]</i></p>
14736
14737
14738 <blockquote>
14739 <p>
14740 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#777">777</a> suggests making <tt>atomic_load</tt> operate on <tt>const</tt> objects. There is a
14741 subtle point here. Atomic loads do not generally write to the object, except
14742 potentially for the <tt>memory_order_seq_cst</tt> constraint. Depending on the
14743 architecture, a dummy write with the same value may be required to be issued
14744 by the atomic load to maintain sequential consistency. This, in turn, may
14745 make the following code:
14746 </p>
14747
14748 <blockquote><pre>const atomic_int x{};
14749
14750 int main()
14751 {
14752   x.load();
14753 }
14754 </pre></blockquote>
14755
14756 <p>
14757 dump core under a straightforward implementation that puts const objects in
14758 a read-only section.
14759 </p>
14760 <p>
14761 There are ways to sidestep the problem, but it needs to be considered.
14762 </p>
14763 <p>
14764 The tradeoff is between making the data member of the atomic types
14765 mutable and requiring the user to explicitly mark atomic members as
14766 mutable, as is already the case with mutexes.
14767 </p>
14768 </blockquote>
14769
14770
14771
14772 <p><b>Proposed resolution:</b></p>
14773 <p>
14774 Add the <tt>const</tt> qualifier to <tt>*object</tt> and <tt>*this</tt>.
14775 </p>
14776
14777 <blockquote><pre>C atomic_load(<ins>const</ins> volatile A* object);
14778 C atomic_load_explicit(<ins>const</ins> volatile A* object, memory_order);
14779 C A::load(memory_order order = memory_order_seq_cst) <ins>const</ins> volatile;
14780 </pre></blockquote>
14781
14782
14783
14784
14785
14786
14787 <hr>
14788 <h3><a name="778"></a>778. std::bitset does not have any constructor taking a string literal</h3>
14789 <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#Ready">Ready</a>
14790  <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2008-01-24</p>
14791 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#bitset.cons">active issues</a> in [bitset.cons].</p>
14792 <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>
14793 <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>
14794 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a></p>
14795 <p><b>Discussion:</b></p>
14796 <p>
14797 A small issue with <tt>std::bitset</tt>: it does not have any constructor
14798 taking a string literal, which is clumsy and looks like an oversigt when
14799 we tried to enable uniform use of <tt>string</tt> and <tt>const char*</tt> in the library.
14800 </p>
14801
14802 <p>
14803 Suggestion: Add
14804 </p>
14805
14806 <blockquote><pre>explicit bitset( const char* str );
14807 </pre></blockquote>
14808
14809 <p>
14810 to std::bitset.
14811 </p>
14812
14813
14814 <p><b>Proposed resolution:</b></p>
14815 <p>
14816 Add to synopsis in 23.3.5 [template.bitset]
14817 </p>
14818
14819 <blockquote><pre>explicit bitset( const char* str );
14820 </pre></blockquote>
14821
14822 <p>
14823 Add to synopsis in 23.3.5.1 [bitset.cons]
14824 </p>
14825
14826 <blockquote><pre>explicit bitset( const char* str );
14827 </pre>
14828 <p>
14829 <i>Effects:</i> Constructs a <tt>bitset</tt> as if <tt>bitset(string(str))</tt>.
14830 </p>
14831 </blockquote>
14832
14833
14834
14835
14836
14837
14838 <hr>
14839 <h3><a name="779"></a>779. Resolution of #283 incomplete</h3>
14840 <p><b>Section:</b> 25.2.8 [alg.remove] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
14841  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-25</p>
14842 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.remove">issues</a> in [alg.remove].</p>
14843 <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>
14844 <p><b>Discussion:</b></p>
14845 <p>
14846 The resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a> did not resolve similar necessary changes for algorithm
14847 <tt>remove_copy[_if]</tt>,
14848 which seems to be an oversight.
14849 </p>
14850
14851
14852 <p><b>Proposed resolution:</b></p>
14853 <p>
14854 In 25.2.8 [alg.remove]/p.6, replace the N2461 requires clause with one of:
14855 </p>
14856
14857 <blockquote>
14858 <i>Requires:</i> <del>Type <tt>T</tt> is <tt>EqualityComparable</tt> (31).</del> The ranges <tt>[first,last)</tt>
14859 and <tt>[result,result + (last - first))</tt> shall not overlap. <ins>The expression <tt>*result = *first</tt> shall be
14860 valid.</ins>
14861 </blockquote>
14862
14863 <p>
14864 or
14865 </p>
14866
14867 <blockquote>
14868 <i>Requires:</i> <del>Type <tt>T</tt> is <tt>EqualityComparable</tt> (31).</del> The ranges <tt>[first,last)</tt>
14869 and <tt>[result,result + (last - first))</tt> shall not overlap.
14870 <ins>The result of the expression <tt>*first</tt> shall
14871 be writable to the output iterator.</ins>
14872 </blockquote>
14873
14874
14875
14876
14877
14878
14879 <hr>
14880 <h3><a name="780"></a>780. <tt>std::merge()</tt> specification incorrect/insufficient</h3>
14881 <p><b>Section:</b> 25.3.4 [alg.merge] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
14882  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-25</p>
14883 <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>
14884 <p><b>Discussion:</b></p>
14885 <p>
14886 Though issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a> has fixed many open issues, it seems that some are still open:
14887 </p>
14888
14889 <p>
14890 Both 25.3.4 [lib.alg.merge] in 14882:2003 and 25.3.4 [alg.merge] in N2461
14891 have no Requires element and the Effects element contains some requirements,
14892 which is probably editorial. Worse is that:
14893 </p>
14894
14895 <ul>
14896 <li>
14897 no assignment requirements are specified (neither implicit nor explicit).
14898 </li>
14899
14900 <li>
14901 the effects clause just speaks of "merges", which is badly worded
14902 near to a circular definition.
14903 </li>
14904
14905 <li>
14906 p. 2 mentions a range <tt>[first, last)</tt>, which is not defined by the
14907 function arguments or otherwise.
14908 </li>
14909
14910 <li>
14911 p. 2 says "according to the ordering defined by comp" which is both
14912 incomplete (because
14913 this excludes the first variant with &lt;) and redundant (because the
14914 following subordinate
14915 clause mentions comp again)
14916 </li>
14917 </ul>
14918
14919
14920
14921 <p><b>Proposed resolution:</b></p>
14922 <p>
14923 In 25.3.4 [alg.merge] replace p.1+ 2:
14924 </p>
14925
14926 <blockquote>
14927 <p>
14928 <i>Effects:</i> <del>Merges</del> <ins>Copies all the elements of the</ins> two sorted ranges <tt>[first1,last1)</tt> and
14929 <tt>[first2,last2)</tt> into the range
14930 <del><tt>[result,result + (last1 - first1) + (last2 - first2))</tt></del>
14931 <ins><tt>[result, last)</tt> (where <tt>last</tt> is equal to <tt>result + (last1
14932 - first1) + (last2 - first2))</tt>, such that resulting range will be
14933 sorted in non-decreasing order; that is, for every iterator <tt>i</tt> in
14934 <tt>[result,last)</tt> other than <tt>result</tt>, the condition <tt>*i &lt; *(i - 1)</tt> or,
14935 respectively, <tt>comp(*i, *(i - 1))</tt> will be false</ins>.
14936 </p>
14937
14938 <p>
14939 <ins><i>Requires:</i></ins> The resulting range shall not overlap with either of the original ranges. <del>The list will be sorted in non-decreasing
14940 order according to the ordering defined by <tt>comp</tt>; that is, for every iterator <tt>i</tt> in
14941 <tt>[first,last)</tt> other than <tt>first</tt>, the condition <tt>*i &lt; *(i - 1)</tt> or
14942 <tt>comp(*i, *(i - 1))</tt> will be false.</del> <ins>The results of the expressions <tt>*first1</tt> and <tt>*first2</tt>
14943 shall be writable to the output iterator.</ins>
14944 </p>
14945 </blockquote>
14946
14947 <p>
14948 [N.B.: I attempted to reuse the wording style of <tt>inplace_merge</tt>,
14949 therefore proposing to
14950 insert ", respectively," between both predicate tests. This is no
14951 strictly necessary as
14952 other parts of <tt>&lt;algorithm&gt;</tt> show, just a matter of consistency]
14953 </p>
14954
14955
14956
14957
14958
14959
14960 <hr>
14961 <h3><a name="781"></a>781. <tt>std::complex</tt> should add missing C99 functions</h3>
14962 <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>
14963  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-26</p>
14964 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#complex.value.ops">active issues</a> in [complex.value.ops].</p>
14965 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.value.ops">issues</a> in [complex.value.ops].</p>
14966 <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>
14967 <p><b>Discussion:</b></p>
14968 <p>
14969 A comparision of the N2461 header <tt>&lt;complex&gt;</tt> synopsis ([complex.synopsis])
14970 with the C99 standard (ISO 9899, 2nd edition and the two corrigenda) show
14971 some complex functions that are missing in C++. These are:
14972 </p>
14973
14974 <ol>
14975 <li>
14976 7.3.9.4: (required elements of the C99 library)<br>
14977 The <tt>cproj</tt> functions
14978 </li>
14979 <li>
14980 7.26.1: (optional elements of the C99 library)<br>
14981 <pre>cerf    cerfc    cexp2
14982 cexpm1  clog10   clog1p
14983 clog2   clgamma  ctgamma
14984 </pre>
14985 </li>
14986 </ol>
14987
14988 <p>
14989 I propose that at least the required <tt>cproj</tt> overloads are provided as equivalent
14990 C++ functions. This addition is easy to do in one sentence (delegation to C99
14991 function).
14992 </p>
14993
14994 <p>
14995 Please note also that the current entry <tt>polar</tt>
14996 in 26.3.9 [cmplx.over]/1
14997 should be removed from the mentioned overload list. It does not make sense to require that a
14998 function already expecting <em>scalar</em> arguments
14999 should cast these arguments into corresponding
15000 <tt>complex&lt;T&gt;</tt> arguments, which are not accepted by
15001 this function.
15002 </p>
15003
15004
15005 <p><b>Proposed resolution:</b></p>
15006 <p>
15007 In 26.3.1 [complex.synopsis] add just between the declaration of <tt>conj</tt> and <tt>fabs</tt>:
15008 </p>
15009
15010 <blockquote><pre>template&lt;class T&gt; complex&lt;T&gt; conj(const complex&lt;T&gt;&amp;);
15011 <ins>template&lt;class T&gt; complex&lt;T&gt; proj(const complex&lt;T&gt;&amp;);</ins>
15012 template&lt;class T&gt; complex&lt;T&gt; fabs(const complex&lt;T&gt;&amp;);
15013 </pre></blockquote>
15014
15015 <p>
15016 In 26.3.7 [complex.value.ops] just after p.6 (return clause of <tt>conj</tt>) add:
15017 </p>
15018
15019 <blockquote>
15020 <pre>template&lt;class T&gt; complex&lt;T&gt; proj(const complex&lt;T&gt;&amp; x);
15021 </pre>
15022 <blockquote>
15023
15024 <i>Effects:</i> Behaves the same as C99 function <tt>cproj</tt>, defined in
15025 subclause 7.3.9.4."
15026 </blockquote>
15027 </blockquote>
15028
15029 <p>
15030 In 26.3.9 [cmplx.over]/1, add one further entry <tt>proj</tt> to
15031 the overload list.
15032 </p>
15033
15034 <blockquote>
15035 <p>
15036 The following function templates shall have additional overloads:
15037 </p>
15038 <blockquote><pre>arg           norm
15039 conj          <del>polar</del> <ins>proj</ins>
15040 imag          real
15041 </pre></blockquote>
15042 </blockquote>
15043
15044
15045
15046
15047
15048
15049 <hr>
15050 <h3><a name="782"></a>782. Extended <tt>seed_seq</tt> constructor is useless</h3>
15051 <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#Ready">Ready</a>
15052  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-27</p>
15053 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p>
15054 <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>
15055 <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>
15056 <p><b>Discussion:</b></p>
15057 <p>
15058 Part of the resolution of n2423, issue 8 was the proposal to
15059 extend the <tt>seed_seq</tt> constructor accepting an input range
15060 as follows (which is now part of N2461):
15061 </p>
15062
15063 <blockquote><pre>template&lt;class InputIterator,
15064 size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits&gt;
15065 seed_seq(InputIterator begin, InputIterator end);
15066 </pre></blockquote>
15067
15068 <p>
15069 First, the expression <tt>iterator_traits&lt;InputIterator&gt;::value_type</tt>
15070 is invalid due to missing <tt>typename</tt> keyword, which is easy to
15071 fix.
15072 </p>
15073
15074 <p>
15075 Second (and worse), while the language now supports default
15076 template arguments of function templates, this customization
15077 point via the second <tt>size_t</tt> template parameter is of no advantage,
15078 because <tt>u</tt> can never be deduced, and worse - because it is a
15079 constructor function template - it can also never be explicitly
15080 provided (14.8.1 [temp.arg.explicit]/7).
15081 </p>
15082
15083 <p>
15084 The question arises, which advantages result from a compile-time
15085 knowledge of <tt>u</tt> versus a run time knowledge? If run time knowledge
15086 suffices, this parameter should be provided as normal function
15087 default argument [Resolution marked (A)], if compile-time knowledge
15088 is important, this could be done via a tagging template or more
15089 user-friendly via a standardized helper generator function
15090 (<tt>make_seed_seq</tt>), which allows this [Resolution marked (B)].
15091 </p>
15092
15093 <p><i>[
15094 Bellevue:
15095 ]</i></p>
15096
15097
15098 <blockquote>
15099 <p>
15100 Fermilab does not have a strong opinion. Would prefer to go with
15101 solution A. Bill agrees that solution A is a lot simpler and does the
15102 job.
15103 </p>
15104 <p>
15105 Proposed Resolution: Accept Solution A.
15106 </p>
15107 </blockquote>
15108
15109 <p>
15110 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a> claims to make this issue moot.
15111 </p>
15112
15113
15114
15115 <p><b>Proposed resolution:</b></p>
15116 <ol type="A">
15117 <li>
15118 <p>
15119 In 26.4.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis replace:
15120 </p>
15121
15122 <blockquote><pre>class seed_seq
15123 {
15124 public:
15125    ...
15126    template&lt;class InputIterator<del>,
15127       size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</del>&gt;
15128           seed_seq(InputIterator begin, InputIterator end<ins>,
15129           size_t u = numeric_limits&lt;typename iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</ins>);
15130    ...
15131 };
15132 </pre></blockquote>
15133
15134 <p>
15135 and do a similar replacement in the member description between
15136 p.3 and p.4.
15137 </p>
15138 </li>
15139
15140 <li>
15141 <p>
15142 In 26.4.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis <em>and</em> in the
15143 member description between p.3 and p.4 replace:
15144 </p>
15145
15146 <blockquote><pre>template&lt;class InputIterator<del>,
15147   size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</del>&gt;
15148           seed_seq(InputIterator begin, InputIterator end);
15149 <ins>template&lt;class InputIterator, size_t u&gt;
15150 seed_seq(InputIterator begin, InputIterator end, <i>implementation-defined</i> s);</ins>
15151 </pre></blockquote>
15152
15153 <p>
15154 In 26.4.2 [rand.synopsis], header <tt>&lt;random&gt;</tt> synopsis, immediately after the
15155 class <tt>seed_seq</tt> declaration <em>and</em> in 26.4.7.1 [rand.util.seedseq]/2, immediately
15156 after the class <tt>seed_seq</tt> definition add:
15157 </p>
15158
15159 <blockquote><pre>template&lt;size_t u, class InputIterator&gt;
15160   seed_seq make_seed_seq(InputIterator begin, InputIterator end);
15161 </pre></blockquote>
15162
15163 <p>
15164 In 26.4.7.1 [rand.util.seedseq], just before p.5 insert two paragraphs:
15165 </p>
15166
15167 <blockquote>
15168 <p>
15169 The first constructor behaves as if it would provide an
15170 integral constant expression <tt>u</tt> of type <tt>size_t</tt> of value
15171 <tt>numeric_limits&lt;typename iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</tt>.
15172 </p>
15173 <p>
15174 The second constructor uses an implementation-defined mechanism
15175 to provide an integral constant expression <tt>u</tt> of type <tt>size_t</tt> and
15176 is called by the function <tt>make_seed_seq</tt>.
15177 </p>
15178 </blockquote>
15179
15180 <p>
15181 In 26.4.7.1 [rand.util.seedseq], just after the last paragraph add:
15182 </p>
15183
15184 <blockquote>
15185 <pre>template&lt;size_t u, class InputIterator&gt;
15186    seed_seq make_seed_seq(InputIterator begin, InputIterator end);
15187 </pre>
15188 <blockquote>
15189 <p>
15190 where <tt>u</tt> is used to construct an object <tt>s</tt> of implementation-defined type.
15191 </p>
15192 <p>
15193 <i>Returns:</i> <tt>seed_seq(begin, end, s)</tt>;
15194 </p>
15195 </blockquote>
15196 </blockquote>
15197
15198 </li>
15199 </ol>
15200
15201
15202
15203
15204
15205
15206 <hr>
15207 <h3><a name="783"></a>783. <tt>thread::id</tt> reuse</h3>
15208 <p><b>Section:</b> 30.2.1.1 [thread.thread.id] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
15209  <b>Submitter:</b> Hans Boehm <b>Date:</b> 2008-02-01</p>
15210 <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>
15211 <p><b>Discussion:</b></p>
15212 <p>
15213 The current working paper
15214 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2497.html">N2497</a>,
15215 integrated just before Bellevue) is
15216 not completely clear whether a given <tt>thread::id</tt> value may be reused once
15217 a thread has exited and has been joined or detached.  Posix allows
15218 thread ids (<tt>pthread_t</tt> values) to be reused in this case.  Although it is
15219 not completely clear whether this originally was the right decision, it
15220 is clearly the established practice, and we believe it was always the
15221 intent of the C++ threads API to follow Posix and allow this.  Howard
15222 Hinnant's example implementation implicitly relies on allowing reuse
15223 of ids, since it uses Posix thread ids directly.
15224 </p>
15225
15226 <p>
15227 It is important to be clear on this point, since it the reuse of thread
15228 ids often requires extra care in client code, which would not be
15229 necessary if thread ids were unique across all time.  For example, a
15230 hash table indexed by thread id may have to be careful not to associate
15231 data values from an old thread with a new one that happens to reuse the
15232 id.  Simply removing the old entry after joining a thread may not be
15233 sufficient, if it creates a visible window between the join and removal
15234 during which a new thread with the same id could have been created and
15235 added to the table.
15236 </p>
15237
15238 <p><i>[
15239 post Bellevue Peter adds:
15240 ]</i></p>
15241
15242
15243 <blockquote>
15244 <p>
15245 There is a real issue with <tt>thread::id</tt> reuse, but I urge the LWG to
15246 reconsider fixing this by disallowing reuse, rather than explicitly allowing
15247 it. Dealing with thread id reuse is an incredibly painful exercise that
15248 would just force the world to reimplement a non-conflicting <tt>thread::id</tt> over
15249 and over.
15250 </p>
15251 <p>
15252 In addition, it would be nice if a <tt>thread::id</tt> could be manipulated
15253 atomically in a lock-free manner, as motivated by the recursive lock
15254 example:
15255 </p>
15256
15257 <p>
15258 <a href="http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html">http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html</a>
15259 </p>
15260 </blockquote>
15261
15262
15263
15264 <p><b>Proposed resolution:</b></p>
15265 <p>
15266 Add a sentence to 30.2.1.1 [thread.thread.id]/p1:
15267 </p>
15268
15269 <blockquote>
15270 <p>
15271 An object of type <code>thread::id</code> provides
15272 a unique identifier for each thread of execution
15273 and a single distinct value for all thread objects
15274 that do not represent a thread of execution ([thread.threads.class]).
15275 Each thread of execution has a <code>thread::id</code>
15276 that is not equal to the <code>thread::id</code>
15277 of other threads of execution
15278 and that is not equal to
15279 the <code>thread::id</code> of <code>std::thread</code> objects
15280 that do not represent threads of execution.
15281 <ins>The library may reuse the value of a <code>thread::id</code> of a
15282 terminated thread that can no longer be joined.</ins>
15283 </p>
15284 </blockquote>
15285
15286
15287
15288
15289
15290 <hr>
15291 <h3><a name="785"></a>785. Random Number Requirements in TR1</h3>
15292 <p><b>Section:</b> TR1 5.1.4.5 [tr.rand.eng.disc], TR1 5.1.4.6 [tr.rand.eng.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
15293  <b>Submitter:</b> John Maddock <b>Date:</b> 2008-01-15</p>
15294 <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>
15295 <p><b>Discussion:</b></p>
15296 <p>
15297 Table 16 of TR1 requires that all Pseudo Random Number generators have a
15298 </p>
15299
15300 <blockquote><pre>seed(integer-type s)
15301 </pre></blockquote>
15302
15303 <p>
15304 member function that is equivalent to:
15305 </p>
15306
15307 <blockquote><pre>mygen = Generator(s)
15308 </pre></blockquote>
15309
15310 <p>
15311 But the generators <tt>xor_combine</tt> and <tt>discard_block</tt> have no such seed member, only the
15312 </p>
15313
15314 <blockquote><pre>template &lt;class Gen&gt;
15315 seed(Gen&amp;);
15316 </pre></blockquote>
15317
15318 <p>
15319 member, which will not accept an integer literal as an argument: something that appears to violate the intent of Table 16.
15320 </p>
15321
15322 <p>
15323 So... is this a bug in TR1?
15324 </p>
15325
15326 <p>This is a real issue BTW, since the Boost implementation does adhere
15327 to the requirements of Table 16, while at least one commercial
15328 implementation does not and follows a strict adherence to sections
15329 5.1.4.5 and 5.1.4.6 instead.
15330 </p>
15331
15332 <p><i>[
15333 Jens adds:
15334 ]</i></p>
15335
15336
15337 <blockquote>
15338 Both engines do have the necessary
15339 constructor, therefore the omission of the <tt>seed()</tt> member
15340 functions appears to be an oversight.
15341 </blockquote>
15342
15343
15344
15345 <p><b>Proposed resolution:</b></p>
15346 <p>
15347 </p>
15348
15349
15350
15351
15352
15353 <hr>
15354 <h3><a name="786"></a>786. Thread library timed waits, UTC and monotonic clocks</h3>
15355 <p><b>Section:</b> X [datetime.system] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
15356  <b>Submitter:</b> Christopher Kohlhoff, Jeff Garland <b>Date:</b> 2008-02-03</p>
15357 <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>
15358 <p><b>Discussion:</b></p>
15359 <p>
15360 The draft C++0x thread library requires that the time points of type
15361 <tt>system_time</tt> and returned by <tt>get_system_time()</tt> represent Coordinated
15362 Universal Time (UTC) (section X [datetime.system]). This can lead to
15363 surprising behavior when a library user performs a duration-based wait,
15364 such as <tt>condition_variable::timed_wait()</tt>. A complete explanation of the
15365 problem may be found in the
15366 <a href="http://www.opengroup.org/onlinepubs/009695399/xrat/xsh_chap02.html#tag_03_02_08_19">Rationale for the Monotonic Clock</a>
15367 section in POSIX, but in summary:
15368 </p>
15369
15370 <ul>
15371 <li>
15372 Operations such as <tt>condition_variable::timed_wait()</tt> (and its POSIX
15373 equivalent, <tt>pthread_cond_timedwait()</tt>) are specified using absolute times
15374 to address the problem of spurious wakeups.
15375 </li>
15376
15377 <li>
15378 The typical use of the timed wait operations is to perform a relative
15379 wait. This may be achieved by first calculating an absolute time as the
15380 sum of the current time and the desired duration. In fact, the C++0x
15381 thread library includes duration-based overloads of
15382 <tt>condition_variable::timed_wait()</tt> that behave as if by calling the
15383 corresponding absolute time overload with a time point value of
15384 <tt>get_system_time() + rel_time</tt>.
15385 </li>
15386
15387 <li>
15388 A UTC clock may be affected by changes to the system time, such as
15389 synchronization with an external source, leap seconds, or manual changes
15390 to the clock.
15391 </li>
15392
15393 <li>
15394 Should the clock change during a timed wait operation, the actual
15395 duration of the wait will not be the expected length. For example, a
15396 user may intend a timed wait of one second duration but, due to an
15397 adjustment of the system clock backwards by a minute, the wait instead
15398 takes 61 seconds.
15399 </li>
15400 </ul>
15401
15402 <p>
15403 POSIX solves the problem by introducing a new monotonic clock, which is
15404 unaffected by changes to the system time. When a condition variable is
15405 initialized, the user may specify whether the monotonic clock is to be
15406 used. (It is worth noting that on POSIX systems it is not possible to
15407 use <tt>condition_variable::native_handle()</tt> to access this facility, since
15408 the desired clock type must be specified during construction of the
15409 condition variable object.)
15410 </p>
15411
15412 <p>
15413 In the context of the C++0x thread library, there are added dimensions
15414 to the problem due to the need to support platforms other than POSIX:
15415 </p>
15416
15417 <ul>
15418 <li>
15419 Some environments (such as embedded systems) do not have a UTC clock, but do have a monotonic clock.
15420 </li>
15421
15422 <li>
15423 Some environments do not have a monotonic clock, but do have a UTC clock.
15424 </li>
15425
15426 <li>
15427 The Microsoft Windows API's synchronization functions use relative
15428 timeouts based on an implied monotonic clock. A program that switches
15429 from the Windows API to the C++0x thread library will now find itself
15430 susceptible to clock changes.
15431 </li>
15432 </ul>
15433
15434 <p>
15435 One possible minimal solution:
15436 </p>
15437
15438 <ul>
15439 <li>
15440 Strike normative references to UTC and an epoch based on 1970-01-01.
15441 </li>
15442
15443 <li>
15444 Make the semantics of <tt>system_time</tt> and <tt>get_system_time()</tt>
15445 implementation-defined (i.e standard library implementors may choose the
15446 appropriate underlying clock based on the capabilities of the target
15447 platform).
15448 </li>
15449
15450 <li>
15451 Add a non-normative note encouraging use of a monotonic clock.
15452 </li>
15453
15454 <li>
15455 Remove <tt>system_time::seconds_since_epoch()</tt>.
15456 </li>
15457
15458 <li>
15459 Change the constructor <tt>explicit system_time(time_t secs, nanoseconds ns
15460 = 0)</tt> to <tt>explicit system_time(nanoseconds ns)</tt>.
15461 </li>
15462 </ul>
15463
15464
15465
15466 <p><b>Proposed resolution:</b></p>
15467 <p>
15468 </p>
15469
15470
15471
15472
15473
15474 <hr>
15475 <h3><a name="787"></a>787. complexity of <tt>binary_search</tt></h3>
15476 <p><b>Section:</b> 25.3.3.4 [binary.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
15477  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-09-08</p>
15478 <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>
15479 <p><b>Discussion:</b></p>
15480 <p>
15481 In 25.3.3.4 [binary.search]/3 the complexity of <tt>binary_search</tt> is described as
15482 </p>
15483
15484 <blockquote>
15485 At most <tt>log(last - first) + 2</tt> comparisons.
15486 </blockquote>
15487
15488 <p>
15489 This should be precised and brought in line with the nomenclature used for
15490 <tt>lower_bound</tt>, <tt>upper_bound</tt>, and <tt>equal_range</tt>.
15491 </p>
15492
15493 <p>
15494 All existing libraries I'm aware of, delegate to
15495 <tt>lower_bound</tt> (+ one further comparison). Since
15496 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>
15497 has now WP status, the resolution of #787 should
15498 be brought in-line with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a> by changing the <tt>+ 2</tt>
15499 to <tt>+ O(1)</tt>.
15500 </p>
15501
15502
15503 <p><b>Proposed resolution:</b></p>
15504 <p>
15505 Change 25.3.3.4 [binary.search]/3
15506 </p>
15507
15508 <blockquote>
15509 <i>Complexity:</i> At most <tt>log<ins><sub>2</sub></ins>(last - first) + <del>2</del> <ins><i>O</i>(1)</ins></tt> comparisons.
15510 </blockquote>
15511
15512
15513
15514
15515
15516 <hr>
15517 <h3><a name="788"></a>788. ambiguity in [istream.iterator]</h3>
15518 <p><b>Section:</b> 24.5.1 [istream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
15519  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-02-06</p>
15520 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.iterator">active issues</a> in [istream.iterator].</p>
15521 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator">issues</a> in [istream.iterator].</p>
15522 <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>
15523 <p><b>Discussion:</b></p>
15524 <p>
15525 The description of how an istream_iterator object becomes an
15526 end-of-stream iterator is a) ambiguous and b) out of date WRT
15527 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>:
15528 </p>
15529
15530 <blockquote>
15531 <tt>istream_iterator</tt> reads (using <tt>operator&gt;&gt;</tt>) successive elements from the
15532 input stream for which it was constructed. After it is constructed, and
15533 every time <tt>++</tt> is used, the iterator reads and stores a value of <tt>T</tt>. If
15534 the end of stream is reached (<tt>operator void*()</tt> on the stream returns
15535 <tt>false</tt>), the iterator becomes equal to the <i>end-of-stream</i> iterator value.
15536 The constructor with no arguments <tt>istream_iterator()</tt> always constructs
15537 an end of stream input iterator object, which is the only legitimate
15538 iterator to be used for the end condition. The result of <tt>operator*</tt> on an
15539 end of stream is not defined. For any other iterator value a <tt>const T&amp;</tt> is
15540 returned. The result of <tt>operator-&gt;</tt> on an end of stream is not defined.
15541 For any other iterator value a <tt>const T*</tt> is returned. It is impossible to
15542 store things into istream iterators. The main peculiarity of the istream
15543 iterators is the fact that <tt>++</tt> operators are not equality preserving,
15544 that is, <tt>i == j</tt> does not guarantee at all that <tt>++i == ++j</tt>. Every time <tt>++</tt>
15545 is used a new value is read.
15546 </blockquote>
15547
15548 <p>
15549 <tt>istream::operator void*()</tt> returns null if <tt>istream::fail()</tt> is <tt>true</tt>,
15550 otherwise non-null. <tt>istream::fail()</tt> returns <tt>true</tt> if <tt>failbit</tt> or
15551 <tt>badbit</tt> is set in <tt>rdstate()</tt>. Reaching the end of stream doesn't
15552 necessarily imply that <tt>failbit</tt> or <tt>badbit</tt> is set (e.g., after
15553 extracting an <tt>int</tt> from <tt>stringstream("123")</tt> the stream object will
15554 have reached the end of stream but <tt>fail()</tt> is <tt>false</tt> and <tt>operator
15555 void*()</tt> will return a non-null value).
15556 </p>
15557
15558 <p>
15559 Also I would prefer to be explicit about calling <tt>fail()</tt> here
15560 (there is no <tt>operator void*()</tt> anymore.)
15561 </p>
15562
15563
15564 <p><b>Proposed resolution:</b></p>
15565 <p>
15566 Change 24.5.1 [istream.iterator]/1:
15567 </p>
15568
15569 <blockquote>
15570 <tt>istream_iterator</tt> reads (using <tt>operator&gt;&gt;</tt>) successive elements from the
15571 input stream for which it was constructed. After it is constructed, and
15572 every time <tt>++</tt> is used, the iterator reads and stores a value of <tt>T</tt>. If
15573 <del>the end of stream is reached</del> <ins>the iterator fails to read and store a value of <tt>T</tt></ins>
15574 (<tt><del>operator void*()</del> <ins>fail()</ins></tt> on the stream returns
15575 <tt><del>false</del> <ins>true</ins></tt>), the iterator becomes equal to the <i>end-of-stream</i> iterator value.
15576 The constructor with no arguments <tt>istream_iterator()</tt> always constructs
15577 an end of stream input iterator object, which is the only legitimate
15578 iterator to be used for the end condition. The result of <tt>operator*</tt> on an
15579 end of stream is not defined. For any other iterator value a <tt>const T&amp;</tt> is
15580 returned. The result of <tt>operator-&gt;</tt> on an end of stream is not defined.
15581 For any other iterator value a <tt>const T*</tt> is returned. It is impossible to
15582 store things into istream iterators. The main peculiarity of the istream
15583 iterators is the fact that <tt>++</tt> operators are not equality preserving,
15584 that is, <tt>i == j</tt> does not guarantee at all that <tt>++i == ++j</tt>. Every time <tt>++</tt>
15585 is used a new value is read.
15586 </blockquote>
15587
15588
15589
15590
15591
15592 <hr>
15593 <h3><a name="789"></a>789. <tt>xor_combine_engine(result_type)</tt> should be explicit</h3>
15594 <p><b>Section:</b> 26.4.4.4 [rand.adapt.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
15595  <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
15596 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.adapt.xor">issues</a> in [rand.adapt.xor].</p>
15597 <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>
15598 <p><b>Discussion:</b></p>
15599 <p>
15600 <tt>xor_combine_engine(result_type)</tt> should be <tt>explicit</tt>. (Obvious oversight.)
15601 </p>
15602
15603 <p><i>[
15604 Bellevue:
15605 ]</i></p>
15606
15607
15608 <blockquote>
15609 Non-controversial. Bill is right, but Fermilab believes that this is
15610 easy to use badly and hard to use right, and so it should be removed
15611 entirely. Got into TR1 by well defined route, do we have permission to
15612 remove stuff? Should probably check with Jens, as it is believed he is
15613 the originator. Broad consensus that this is not a robust engine
15614 adapter.
15615 </blockquote>
15616
15617
15618 <p><b>Proposed resolution:</b></p>
15619 <p>
15620 Remove xor_combine_engine from synopsis of 26.4.2 [rand.synopsis].
15621 </p>
15622 <p>
15623 Remove 26.4.4.4 [rand.adapt.xor] <tt>xor_combine_engine</tt>.
15624 </p>
15625
15626
15627
15628
15629
15630 <hr>
15631 <h3><a name="792"></a>792. <tt>piecewise_constant_distribution</tt> is undefined for a range with just one endpoint</h3>
15632 <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#Ready">Ready</a>
15633  <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
15634 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.pconst">active issues</a> in [rand.dist.samp.pconst].</p>
15635 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p>
15636 <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>
15637 <p><b>Discussion:</b></p>
15638 <p>
15639 <tt>piecewise_constant_distribution</tt> is undefined for a range with just one
15640 endpoint. (Probably should be the same as an empty range.)
15641 </p>
15642
15643
15644 <p><b>Proposed resolution:</b></p>
15645 <p>
15646 Change 26.4.8.5.2 [rand.dist.samp.pconst] paragraph 3b:
15647 </p>
15648
15649 <blockquote>
15650 b) If <tt>firstB == lastB</tt> <ins>or the sequence <tt>w</tt> has the length zero</ins>,
15651 </blockquote>
15652
15653
15654
15655
15656
15657 <hr>
15658 <h3><a name="793"></a>793. <tt>discrete_distribution</tt> missing constructor</h3>
15659 <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#Open">Open</a>
15660  <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
15661 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.discrete">issues</a> in [rand.dist.samp.discrete].</p>
15662 <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>
15663 <p><b>Discussion:</b></p>
15664 <p>
15665 <tt>discrete_distribution</tt> should have a constructor like:
15666 </p>
15667
15668 <blockquote><pre>template&lt;class _Fn&gt;
15669   discrete_distribution(result_type _Count, double _Low, double _High,
15670                         _Fn&amp; _Func);
15671 </pre></blockquote>
15672
15673 <p>
15674 (Makes it easier to fill a histogram with function vaues over a range.)
15675 </p>
15676
15677 <p><i>[
15678 Bellevue:
15679 ]</i></p>
15680
15681
15682 <blockquote>
15683 How do you specify the function so that it does not return negative
15684 values? If you do it is a bad construction. This requirement is already
15685 there. Where in each bin does one evaluate the function? In the middle.
15686 Need to revisit tomorrow.
15687 </blockquote>
15688
15689
15690 <p><b>Proposed resolution:</b></p>
15691
15692
15693
15694
15695
15696 <hr>
15697 <h3><a name="794"></a>794. <tt>piecewise_constant_distribution</tt> missing constructor</h3>
15698 <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>
15699  <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
15700 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.pconst">active issues</a> in [rand.dist.samp.pconst].</p>
15701 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p>
15702 <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>
15703 <p><b>Discussion:</b></p>
15704 <p>
15705 <tt>piecewise_constant_distribution</tt> should have a constructor like:
15706 </p>
15707
15708 <blockquote><pre>template&lt;class _Fn&gt;
15709    piecewise_constant_distribution(size_t _Count,
15710             _Ty _Low, _Ty _High, _Fn&amp; _Func);
15711 </pre></blockquote>
15712
15713 <p>
15714 (Makes it easier to fill a histogram with function vaues over a range.
15715 The two (reference <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>) make a sensible replacement for
15716 <tt>general_pdf_distribution</tt>.)
15717 </p>
15718
15719
15720 <p><b>Proposed resolution:</b></p>
15721
15722
15723
15724
15725
15726 <hr>
15727 <h3><a name="798"></a>798. Refactoring of binders lead to interface breakage</h3>
15728 <p><b>Section:</b> D.8 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
15729  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-02-14</p>
15730 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.lib.binders">issues</a> in [depr.lib.binders].</p>
15731 <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>
15732 <p><b>Discussion:</b></p>
15733 <p>
15734 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2521.pdf">N2521</a>
15735 and its earlier predecessors have moved the old binders from
15736 [lib.binders] to D.8 [depr.lib.binders] thereby introducing some renaming
15737 of the template parameter names (<tt>Operation -&gt; Fn</tt>). During this
15738 renaming process the <em>protected</em> data member <tt>op</tt> was also renamed to
15739 <tt>fn</tt>, which seems as an unnecessary interface breakage to me - even if
15740 this user access point is probably rarely used.
15741 </p>
15742
15743
15744 <p><b>Proposed resolution:</b></p>
15745 <p>
15746 Change D.8.1 [depr.lib.binder.1st]:
15747 </p>
15748
15749 <blockquote>
15750 <pre>template &lt;class Fn&gt;
15751 class binder1st
15752   : public unary_function&lt;typename Fn::second_argument_type,
15753                           typename Fn::result_type&gt; {
15754 protected:
15755   Fn <del>fn</del> <ins>op</ins>;
15756   typename Fn::first_argument_type value;
15757 public:
15758   binder1st(const Fn&amp; x,
15759             const typename Fn::first_argument_type&amp; y);
15760   typename Fn::result_type
15761     operator()(const typename Fn::second_argument_type&amp; x) const;
15762   typename Fn::result_type
15763     operator()(typename Fn::second_argument_type&amp; x) const;
15764 };
15765 </pre>
15766
15767 <blockquote>
15768 <p>
15769 -1- The constructor initializes <del><tt>fn</tt></del> <ins><tt>op</tt></ins> with <tt>x</tt> and <tt>value</tt> with <tt>y</tt>.
15770 </p>
15771 <p>
15772 -2- <tt>operator()</tt> returns <tt><del>fn</del><ins>op</ins>(value,x)</tt>.
15773 </p>
15774 </blockquote>
15775 </blockquote>
15776
15777 <p>
15778 Change D.8.3 [depr.lib.binder.2nd]:
15779 </p>
15780
15781 <blockquote>
15782 <pre>template &lt;class Fn&gt;
15783 class binder2nd
15784   : public unary_function&lt;typename Fn::first_argument_type,
15785                           typename Fn::result_type&gt; {
15786 protected:
15787   Fn <del>fn</del> <ins>op</ins>;
15788   typename Fn::second_argument_type value;
15789 public:
15790   binder2nd(const Fn&amp; x,
15791             const typename Fn::second_argument_type&amp; y);
15792   typename Fn::result_type
15793     operator()(const typename Fn::first_argument_type&amp; x) const;
15794   typename Fn::result_type
15795     operator()(typename Fn::first_argument_type&amp; x) const;
15796 };
15797 </pre>
15798
15799 <blockquote>
15800 <p>
15801 -1- The constructor initializes <del><tt>fn</tt></del> <ins><tt>op</tt></ins> with <tt>x</tt> and <tt>value</tt> with <tt>y</tt>.
15802 </p>
15803 <p>
15804 -2- <tt>operator()</tt> returns <tt><del>fn</del><ins>op</ins>(value,x)</tt>.
15805 </p>
15806 </blockquote>
15807 </blockquote>
15808
15809
15810
15811
15812
15813
15814 <hr>
15815 <h3><a name="800"></a>800. Issues in 26.4.7.1 [rand.util.seedseq](6)</h3>
15816 <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#Open">Open</a>
15817  <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2008-02-18</p>
15818 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p>
15819 <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>
15820 <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>
15821 <p><b>Discussion:</b></p>
15822 <p>
15823 The for-loop in the algorithm specification has <tt>n</tt> iterations, where <tt>n</tt> is
15824 defined to be <tt>end - begin</tt>, i.e. the number of supplied w-bit quantities.
15825 Previous versions of this algorithm and the general logic behind it
15826 suggest that this is an oversight and that in the context of the
15827 for-loop <tt>n</tt> should be the number of full 32-bit quantities in <tt>b</tt> (rounded
15828 upwards). If <tt>w</tt> is 64, the current algorithm throws away half of all bits
15829 in <tt>b</tt>. If <tt>w</tt> is 16, the current algorithm sets half of all elements in <tt>v</tt>
15830 to 0.
15831 </p>
15832
15833 <p>
15834 There are two more minor issues:
15835 </p>
15836
15837 <ul>
15838 <li>
15839 Strictly speaking <tt>end - begin</tt> is not defined since
15840 <tt>InputIterator</tt> is not required to be a random access iterator.
15841 </li>
15842 <li>
15843 Currently all integral types are allowed as input to the <tt>seed_seq</tt>
15844 constructor, including <tt>bool</tt>. IMHO allowing <tt>bool</tt>s unnecessarily
15845 complicates the implementation without any real benefit to the user.
15846 I'd suggest to exclude <tt>bool</tt>s as input.
15847 </li>
15848 </ul>
15849
15850 <p><i>[
15851 Bellevue:
15852 ]</i></p>
15853
15854
15855 <blockquote>
15856 Move to OPEN Bill will try to propose a resolution by the next meeting.
15857 </blockquote>
15858
15859 <p><i>[
15860 post Bellevue:  Bill provided wording.
15861 ]</i></p>
15862
15863
15864 <p>
15865 This issue is made moot if <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a> is accepted.
15866 </p>
15867
15868
15869
15870 <p><b>Proposed resolution:</b></p>
15871 <p>
15872 Replace 26.4.7.1 [rand.util.seedseq] paragraph 6 with:
15873 </p>
15874
15875 <blockquote>
15876 <p>
15877 <i>Effects:</i> Constructs a <tt>seed_seq</tt> object by effectively concatenating the
15878 low-order <tt>u</tt> bits of each of the elements of the supplied sequence <tt>[begin,
15879 end)</tt>
15880 in ascending order of significance to make a (possibly very large) unsigned
15881 binary number <tt>b</tt> having a total of <tt>n</tt> bits, and then carrying out the
15882 following
15883 algorithm:
15884 </p>
15885
15886 <blockquote><pre>for( v.clear(); n &gt; 0; n -= 32 )
15887    v.push_back(b mod 2<sup>32</sup>), b /= 2<sup>32</sup>;
15888 </pre></blockquote>
15889 </blockquote>
15890
15891
15892
15893
15894
15895 <hr>
15896 <h3><a name="801"></a>801. <tt>tuple</tt> and <tt>pair</tt> trivial members</h3>
15897 <p><b>Section:</b> 20.3 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
15898  <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-02-18</p>
15899 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple">active issues</a> in [tuple].</p>
15900 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple">issues</a> in [tuple].</p>
15901 <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>
15902 <p><b>Discussion:</b></p>
15903 <p>
15904 Classes with trivial special member functions are inherently more
15905 efficient than classes without such functions.  This efficiency is
15906 particularly pronounced on modern ABIs that can pass small classes
15907 in registers.  Examples include value classes such as complex numbers
15908 and floating-point intervals.  Perhaps more important, though, are
15909 classes that are simple collections, like <tt>pair</tt> and <tt>tuple</tt>.  When the
15910 parameter types of these classes are trivial, the <tt>pair</tt>s and <tt>tuple</tt>s
15911 themselves can be trivial, leading to substantial performance wins.
15912 </p>
15913 <p>
15914 The current working draft make specification of trivial functions
15915 (where possible) much easer through <tt>default</tt>ed and <tt>delete</tt>d functions.
15916 As long as the semantics of defaulted and deleted functions match
15917 the intended semantics, specification of defaulted and deleted
15918 functions will yield more efficient programs.
15919 </p>
15920 <p>
15921 There are at least two cases where specification of an explicitly
15922 defaulted function may be desirable.
15923 </p>
15924 <p>
15925 First, the <tt>std::pair</tt> template has a non-trivial default constructor,
15926 which prevents static initialization of the pair even when the
15927 types are statically initializable.  Changing the definition to
15928 </p>
15929
15930 <blockquote><pre>pair() = default;
15931 </pre></blockquote>
15932
15933 <p>
15934 would enable such initialization.  Unfortunately, the change is
15935 not semantically neutral in that the current definition effectively
15936 forces value initialization whereas the change would not value
15937 initialize in some contexts.
15938 </p>
15939
15940 <p>
15941 ** Does the committee confirm that forced value initialization
15942 was the intent?  If not, does the committee wish to change the
15943 behavior of <tt>std::pair</tt> in C++0x?
15944 </p>
15945 <p>
15946 Second, the same default constructor issue applies to <tt>std::tuple</tt>.
15947 Furthermore, the <tt>tuple</tt> copy constructor is current non-trivial,
15948 which effectively prevents passing it in registers.  To enable
15949 passing <tt>tuples</tt> in registers, the copy constructor should be
15950 make explicitly <tt>default</tt>ed.  The new declarations are:
15951 </p>
15952
15953 <blockquote><pre>tuple() = default;
15954 tuple(const tuple&amp;) = default;
15955 </pre></blockquote>
15956
15957 <p>
15958 This changes is not implementation neutral.  In particular, it
15959 prevents implementations based on pointers to the parameter
15960 types.  It does however, permit implementations using the
15961 parameter types as bases.
15962 </p>
15963 <p>
15964 ** How does the committee wish to trade implementation
15965 efficiency versus implementation flexibility?
15966 </p>
15967
15968 <p><i>[
15969 Bellevue:
15970 ]</i></p>
15971
15972
15973 <blockquote>
15974 <p>
15975 General agreement; the first half of the issue is NAD.
15976 </p>
15977 <p>
15978 Before voting on the second half, it was agreed that a "Strongly Favor"
15979 vote meant support for trivial tuples (assuming usual requirements met),
15980 even at the expense of other desired qualities. A "Weakly Favor" vote
15981 meant support only if not at the expense of other desired qualities.
15982 </p>
15983 <p>
15984 Concensus: Go forward, but not at expense of other desired qualities.
15985 </p>
15986 <p>
15987 It was agreed to Alisdair should fold this work in with his other
15988 pair/tuple action items, above, and that issue 801 should be "open", but
15989 tabled until Alisdair's proposals are disposed of.
15990 </p>
15991 </blockquote>
15992
15993
15994 <p><b>Proposed resolution:</b></p>
15995 <p>
15996 </p>
15997
15998
15999
16000
16001
16002 <hr>
16003 <h3><a name="803"></a>803. Simplification of <tt>seed_seq::seq_seq</tt></h3>
16004 <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#Open">Open</a>
16005  <b>Submitter:</b> Charles Karney <b>Date:</b> 2008-02-22</p>
16006 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p>
16007 <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>
16008 <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>
16009 <p><b>Discussion:</b></p>
16010 <p>
16011 <tt>seed_seq(InputIterator begin, InputIterator end);</tt> constructs a <tt>seed_seq</tt>
16012 object repacking the bits of supplied sequence <tt>[begin, end)</tt> into a
16013 32-bit vector.
16014 </p>
16015 <p>
16016 This repacking triggers several problems:
16017 </p>
16018 <ol>
16019 <li>
16020 Distinctness of the output of <tt>seed_seq::generate</tt> required the
16021 introduction of the initial "<tt>if (w &lt; 32) v.push_back(n);</tt>"  (Otherwise
16022 the unsigned short vectors [1, 0] and [1] generate the same sequence.)
16023 </li>
16024 <li>
16025 Portability demanded the introduction of the template parameter <tt>u</tt>.
16026 (Otherwise some sequences could not be obtained on computers where no
16027 integer types are exactly 32-bits wide.)
16028 </li>
16029 <li>
16030 The description and algorithm have become unduly complicated.
16031 </li>
16032 </ol>
16033 <p>
16034 I propose simplifying this <tt>seed_seq</tt> constructor to be "32-bit only".
16035 Despite it's being simpler, there is NO loss of functionality (see
16036 below).
16037 </p>
16038 <p>
16039 Here's how the description would read
16040 </p>
16041 <blockquote>
16042 <p>
16043 26.4.7.1 [rand.util.seedseq] Class <tt>seed_seq</tt>
16044 </p>
16045
16046 <blockquote>
16047 <pre>template&lt;class InputIterator&gt;
16048   seed_seq(InputIterator begin, InputIterator end);
16049 </pre>
16050 <blockquote>
16051 <p>
16052 5 <i>Requires:</i> NO CHANGE
16053 </p>
16054 <p>
16055 6 <i>Effects:</i> Constructs a <tt>seed_seq</tt> object by
16056 </p>
16057 <blockquote>
16058 <pre>for (InputIterator s = begin; s != end; ++s)
16059    v.push_back((*s) mod 2^32);
16060 </pre>
16061 </blockquote>
16062 </blockquote>
16063 </blockquote>
16064 </blockquote>
16065
16066 <p>
16067 Discussion:
16068 </p>
16069 <p>
16070 The chief virtues here are simplicity, portability, and generality.
16071 </p>
16072 <ul>
16073 <li>
16074 Simplicity -- compare the above specification with the
16075 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a> proposal.
16076 </li>
16077 <li>
16078 Portability -- with <tt>iterator_traits&lt;InputIterator&gt;::value_type =
16079 uint_least32_t</tt> the user is guaranteed to get the same behavior across
16080 platforms.
16081 </li>
16082 <li>
16083 Generality -- any behavior that the
16084 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
16085 proposal can achieve can be
16086 obtained with this simpler proposal (albeit with a shuffling of bits
16087 in the input sequence).
16088 </li>
16089 </ul>
16090 <p>
16091 Arguments (and counter-arguments) against making this change (and
16092 retaining the
16093 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
16094 behavior) are:
16095 </p>
16096 <ul>
16097 <li>
16098 <p>
16099 The user can pass an array of <tt>unsigned char</tt> and <tt>seed_seq</tt> will nicely
16100  repack it.
16101 </p>
16102 <p>
16103  Response: So what?  Consider the seed string "ABC".  The
16104  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
16105  proposal results in
16106 </p>
16107 <blockquote><pre>v = { 0x3, 0x434241 };
16108 </pre></blockquote>
16109 <p>
16110 while the simplified proposal yields
16111 </p>
16112 <blockquote><pre>v = { 0x41, 0x42, 0x43 };
16113 </pre></blockquote>
16114 <p>
16115 The results produced by <tt>seed_seq::generate</tt> with the two inputs are
16116 different but nevertheless equivalently "mixed up" and this remains
16117 true even if the seed string is long.
16118 </p>
16119 </li>
16120 <li>
16121 <p>
16122 With long strings (e.g., with bit-length comparable to the number of
16123  bits in the state), <tt>v</tt> is longer (by a factor of 4) with the simplified
16124  proposal and <tt>seed_seq::generate</tt> will be slower.
16125 </p>
16126 <p>
16127 Response: It's unlikely that the efficiency of <tt>seed_seq::generate</tt> will
16128  be a big issue.  If it is, the user is free to repack the seed vector
16129  before constructing <tt>seed_seq</tt>.
16130 </p>
16131 </li>
16132 <li>
16133 <p>
16134 A user can pass an array of 64-bit integers and all the bits will be
16135  used.
16136 </p>
16137 <p>
16138  Response: Indeed.  However, there are many instances in the
16139  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
16140  where integers are silently coerced to a narrower width and this
16141  should just be a case of the user needing to read the documentation.
16142  The user can of course get equivalent behavior by repacking his seed
16143  into 32-bit pieces.  Furthermore, the unportability of the
16144  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
16145  proposal with
16146 </p>
16147 <blockquote><pre>unsigned long s[] = {1, 2, 3, 4};
16148 seed_seq q(s, s+4);
16149 </pre></blockquote>
16150 <p>
16151  which typically results in <tt>v = {1, 2, 3, 4}</tt> on 32-bit machines and in
16152 <tt>v = {1, 0, 2, 0, 3, 0, 4, 0}</tt> on 64-bit machines is a major pitfall for
16153  unsuspecting users.
16154 </p>
16155 </li>
16156 </ul>
16157
16158 <p>
16159 Note: this proposal renders moot issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#782">782</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>.
16160 </p>
16161
16162 <p><i>[
16163 Bellevue:
16164 ]</i></p>
16165
16166
16167 <blockquote>
16168 Walter needs to ask Fermilab for guidance. Defer till tomorrow. Bill likes the proposed resolution.
16169 </blockquote>
16170
16171
16172 <p><b>Proposed resolution:</b></p>
16173 <p>
16174 Change 26.4.7.1 [rand.util.seedseq]:
16175 </p>
16176
16177 <blockquote>
16178 <pre>template&lt;class InputIterator<del>,
16179   size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</del>&gt;
16180   seed_seq(InputIterator begin, InputIterator end);
16181 </pre>
16182 <blockquote>
16183 <p>
16184 -5- <i>Requires:</i> <tt>InputIterator</tt> shall satisfy the requirements of an input iterator (24.1.1)
16185 such that <tt>iterator_traits&lt;InputIterator&gt;::value_type</tt> shall denote an integral type.
16186 </p>
16187 <p>
16188 -6- Constructs a <tt>seed_seq</tt> object by <del>rearranging some or all of the bits of the supplied sequence
16189 <tt>[begin,end)</tt> of w-bit quantities into 32-bit units, as if by the following: </del>
16190 </p>
16191 <p>
16192 <del>First extract the rightmost <tt>u</tt> bits from each of the <tt>n = end
16193 - begin</tt> elements of the supplied sequence and concatenate all the
16194 extracted bits to initialize a single (possibly very large) unsigned
16195 binary number, <tt>b = &#8721;<sup>n-1</sup><sub>i=0</sub> (begin[i]
16196 mod 2<sup>u</sup>) · 2<sup>w·i</sup></tt> (in which the bits of each <tt>begin[i]</tt>
16197 are treated as denoting an unsigned quantity). Then carry out
16198 the following algorithm:</del>
16199 </p>
16200 <blockquote><pre><del>
16201 v.clear();
16202 if ($w$ &lt; 32)
16203   v.push_back($n$);
16204 for( ; $n$ &gt; 0; --$n$)
16205   v.push_back(b mod 2<sup>32</sup>), b /= 2<sup>32</sup>;
16206 </del></pre></blockquote>
16207 <blockquote>
16208 <pre><ins>
16209 for (InputIterator s = begin; s != end; ++s)
16210    v.push_back((*s) mod 2<sup>32</sup>);
16211 </ins></pre>
16212 </blockquote>
16213 </blockquote>
16214 </blockquote>
16215
16216
16217
16218
16219
16220 <hr>
16221 <h3><a name="804"></a>804. Some problems with classes <tt>error_code</tt>/<tt>error_condition</tt></h3>
16222 <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>
16223  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-02-24</p>
16224 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#syserr">active issues</a> in [syserr].</p>
16225 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p>
16226 <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>
16227 <p><b>Discussion:</b></p>
16228 <ol type="A">
16229 <li>
16230 <p>
16231 19.4.2.1 [syserr.errcode.overview]/1, class <tt>error_code</tt> and
16232 19.4.3.1 [syserr.errcondition.overview]/, class <tt>error_condition</tt> synopses
16233 declare an expository data member <tt>cat_</tt>:
16234 </p>
16235 <blockquote><pre>const error_category&amp; cat_; // exposition only
16236 </pre></blockquote>
16237 <p>
16238 which is used to define the semantics of several members. The decision
16239 to use a member of reference type lead to several problems:
16240 </p>
16241 <ol>
16242 <li>
16243 The classes are not <tt>(Copy)Assignable</tt>, which is probably not the intent.
16244 </li>
16245 <li>
16246 The post conditions of all modifiers from
16247 19.4.2.3 [syserr.errcode.modifiers] and 19.4.3.3 [syserr.errcondition.modifiers], resp.,
16248 cannot be fulfilled.
16249 </li>
16250 </ol>
16251 <p>
16252 The simple fix would be to replace the reference by a pointer member.
16253 </p>
16254 </li>
16255
16256 <li>
16257 I would like to give the editorial remark that in both classes the
16258 constrained <tt>operator=</tt>
16259 overload (template with <tt>ErrorCodeEnum</tt> argument) makes in invalid
16260 usage of <tt>std::enable_if</tt>: By using the default value for the second <tt>enable_if</tt>
16261 parameter the return type would be defined to be <tt>void&amp;</tt> even in otherwise
16262 valid circumstances - this return type must be explicitly provided (In
16263 <tt>error_condition</tt> the first declaration uses an explicit value, but of wrong
16264 type).
16265 </li>
16266
16267 <li>
16268 The member function <tt>message</tt> throws clauses (
16269 19.4.1.2 [syserr.errcat.virtuals]/10, 19.4.2.4 [syserr.errcode.observers]/8, and
16270 19.4.3.4 [syserr.errcondition.observers]/6) guarantee "throws nothing",
16271 although
16272 they return a <tt>std::string</tt> by value, which might throw in out-of-memory
16273 conditions (see related issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>).
16274 </li>
16275 </ol>
16276
16277
16278 <p><b>Proposed resolution:</b></p>
16279 <p>
16280 In 19.4.1.2 [syserr.errcat.virtuals], remove the throws clause p. 10.
16281 </p>
16282
16283 <blockquote>
16284 <pre>virtual string message(int ev) const = 0;
16285 </pre>
16286
16287 <blockquote>
16288 <p>
16289 <i>Returns:</i> A string that describes the error condition denoted by <tt>ev</tt>.
16290 </p>
16291 <p>
16292 <del><i>Throws:</i> Nothing.</del>
16293 </p>
16294 </blockquote>
16295 </blockquote>
16296
16297 <p>
16298 In 19.4.2.1 [syserr.errcode.overview]/1, class <tt>error_code</tt> synopsis, modifiers section,
16299 replace the current <tt>operator=</tt> overload by the following:
16300 </p>
16301
16302 <blockquote>
16303 <pre>template &lt;class ErrorCodeEnum&gt;
16304   typename enable_if&lt;is_error_code_enum&lt;ErrorCodeEnum&gt;::value<ins>, error_code</ins>&gt;::type&amp;
16305     operator=(ErrorCodeEnum e);
16306 </pre>
16307 </blockquote>
16308
16309 <p>
16310 In the private section of the same class replace the current
16311 data member <tt>cat_</tt> definition by:
16312 </p>
16313
16314 <blockquote>
16315 const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
16316 </blockquote>
16317
16318 <p>
16319 In 19.4.2.2 [syserr.errcode.constructors], change p. 2 to read:
16320 </p>
16321
16322 <blockquote>
16323 <pre>error_code();
16324 </pre>
16325 <blockquote>
16326 <p>
16327 </p><p>...</p>
16328
16329 <p>
16330 <i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&amp;</ins>system_category</tt>.
16331 </p>
16332 </blockquote>
16333 </blockquote>
16334
16335 <p>
16336 Change 19.4.2.2 [syserr.errcode.constructors] p. 5 to read:
16337 </p>
16338
16339 <blockquote>
16340 <pre>error_code(int val, const error_category&amp; cat);
16341 </pre>
16342 <blockquote>
16343 <p>...</p>
16344 <p>
16345 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
16346 </p>
16347 </blockquote>
16348 </blockquote>
16349
16350 <p>
16351 In 19.4.2.3 [syserr.errcode.modifiers], change p. 1 to read:
16352 </p>
16353
16354 <blockquote>
16355 <pre>void assign(int val, const error_category&amp; cat);
16356 </pre>
16357 <blockquote>
16358 <p>
16359 </p><p>...</p>
16360
16361 <p>
16362 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
16363 </p>
16364 </blockquote>
16365 </blockquote>
16366
16367 <p>
16368 In 19.4.2.3 [syserr.errcode.modifiers], change the <tt>operator=</tt> signature to read:
16369 </p>
16370
16371 <blockquote>
16372 <pre>template &lt;class ErrorCodeEnum&gt;
16373   typename enable_if&lt;is_error_code_enum&lt;ErrorCodeEnum&gt;::value<ins>, error_code</ins>&gt;::type&amp;
16374     operator=(ErrorCodeEnum e);
16375 </pre>
16376 </blockquote>
16377
16378 <p>
16379 In 19.4.2.4 [syserr.errcode.observers], change p. 3 to read:
16380 </p>
16381
16382 <blockquote>
16383 <pre>const error_category&amp; category() const;
16384 </pre>
16385 <blockquote>
16386 <p>
16387 </p><p>...</p>
16388
16389 <p>
16390 <i>Returns:</i> <tt><ins>*</ins>cat_</tt>.
16391 </p>
16392 </blockquote>
16393 </blockquote>
16394
16395 <p>
16396 In 19.4.2.4 [syserr.errcode.observers], remove the throws clause p. 8.
16397 </p>
16398
16399 <blockquote>
16400 <pre>string message() const;
16401 </pre>
16402 <blockquote>
16403 <p>
16404 </p><p>...</p>
16405
16406 <p>
16407 <del><i>Throws:</i> Nothing.</del>
16408 </p>
16409 </blockquote>
16410 </blockquote>
16411
16412 <p>
16413 In 19.4.3.1 [syserr.errcondition.overview]/1, class <tt>error_condition</tt>
16414 synopsis, constructors section, replace the template constructor
16415 overload declaration by one with an added "::value"
16416 </p>
16417
16418 <blockquote>
16419 <pre>template &lt;class ErrorConditionEnum&gt;
16420   error_condition(ErrorConditionEnum e,
16421     typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;<ins>::value</ins>&gt;::type* = 0);
16422 </pre>
16423 </blockquote>
16424
16425 <p>
16426 In 19.4.3.1 [syserr.errcondition.overview]/1, class <tt>error_condition</tt> synopsis,
16427 modifiers section,
16428 replace the <tt>operator=</tt> overload declaration by:
16429 </p>
16430
16431 <blockquote>
16432 <pre>template&lt;typename ErrorConditionEnum&gt;
16433   typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;<ins>::value</ins>, <del>error_code</del> <ins>error_condition</ins>&gt;::type &amp;
16434      operator=( ErrorConditionEnum e );
16435 </pre>
16436 </blockquote>
16437
16438 <p>
16439 In the private section of the same class replace the current
16440 data member <tt>cat_</tt> definition by:
16441 </p>
16442
16443 <blockquote><pre>const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
16444 </pre></blockquote>
16445
16446 <p>
16447 In 19.4.3.2 [syserr.errcondition.constructors], change p. 2 to read:
16448 </p>
16449
16450 <blockquote>
16451 <pre>error_condition();
16452 </pre>
16453 <blockquote>
16454 <p>
16455 </p><p>...</p>
16456
16457 <p>
16458 <i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&amp;</ins>posix_category</tt>.
16459 </p>
16460 </blockquote>
16461 </blockquote>
16462
16463 <p>
16464 In the same section, change p. 5 to read:
16465 </p>
16466
16467 <blockquote>
16468 <pre>error_condition(int val, const error_category&amp; cat);
16469 </pre>
16470 <blockquote>
16471 <p>
16472 </p><p>...</p>
16473
16474 <p>
16475 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
16476 </p>
16477 </blockquote>
16478 </blockquote>
16479
16480 <p>
16481 In 19.4.3.3 [syserr.errcondition.modifiers], change p. 1 to read:
16482 </p>
16483
16484 <blockquote>
16485 <pre>void assign(int val, const error_category&amp; cat);
16486 </pre>
16487 <blockquote>
16488 <p>
16489 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
16490 </p>
16491 </blockquote>
16492 </blockquote>
16493
16494 <p>
16495 In the same section replace the current <tt>operator=</tt> overload declaration by:
16496 </p>
16497
16498 <blockquote>
16499 <pre>template &lt;class ErrorConditionEnum&gt;
16500   typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;::value<ins>, error_condition</ins>&gt;::type&amp;
16501     operator=(ErrorConditionEnum e);
16502 </pre></blockquote>
16503
16504 <p>
16505 In 19.4.3.4 [syserr.errcondition.observers], change p. 3 to read:
16506 </p>
16507
16508 <blockquote>
16509 <pre>const error_category&amp; category() const;
16510 </pre>
16511 <blockquote>
16512 <p>
16513 <i>Returns:</i> <tt><ins>*</ins>cat_</tt>.
16514 </p>
16515 </blockquote>
16516 </blockquote>
16517
16518 <p>
16519 In 19.4.3.4 [syserr.errcondition.observers], remove the throws clause p. 6.
16520 </p>
16521
16522 <blockquote>
16523 <pre>string message() const;
16524 </pre>
16525 <blockquote>
16526 <p>
16527 </p><p>...</p>
16528
16529 <p>
16530 <del><i>Throws:</i> Nothing.</del>
16531 </p>
16532 </blockquote>
16533 </blockquote>
16534
16535
16536
16537
16538
16539
16540
16541 <hr>
16542 <h3><a name="805"></a>805. <tt>posix_error::posix_errno</tt> concerns</h3>
16543 <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>
16544  <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-02-24</p>
16545 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#syserr">active issues</a> in [syserr].</p>
16546 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p>
16547 <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>
16548 <p><b>Discussion:</b></p>
16549 <p>
16550 19.4 [syserr]
16551 </p>
16552
16553 <blockquote><pre>namespace posix_error {
16554   enum posix_errno {
16555     address_family_not_supported, // EAFNOSUPPORT
16556     ...
16557 </pre></blockquote>
16558
16559 <p>
16560 should rather use the new scoped-enum  facility (7.2 [dcl.enum]),
16561 which would avoid the necessity for a new <tt>posix_error</tt>
16562 namespace, if I understand correctly.
16563 </p>
16564
16565 <p><i>[
16566 Further discussion:
16567 ]</i></p>
16568
16569
16570 <blockquote>
16571 <p>
16572 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf">N2347</a>,
16573 Strongly Typed Enums, since renamed Scoped Enums.
16574 </p>
16575 <p>
16576 Alberto Ganesh Barbati also raised this issue in private email, and also proposed the scoped-enum solution.
16577 </p>
16578 <p>
16579 Nick Stoughton asked in Bellevue that <tt>posix_error</tt> and <tt>posix_errno</tt> not be used as names. The LWG agreed.
16580 </p>
16581 <p>
16582 The wording for the Proposed resolution was provided by Beman Dawes.
16583 </p>
16584 </blockquote>
16585
16586
16587 <p><b>Proposed resolution:</b></p>
16588 <p>
16589 Change System error support 19.4 [syserr] as indicated:
16590 </p>
16591
16592 <blockquote><pre><del>namespace posix_error {</del>
16593   enum <del>posix_errno</del> <ins>class errc</ins> {
16594     address_family_not_supported, // EAFNOSUPPORT
16595     ...
16596     wrong_protocol_type, // EPROTOTYPE
16597   };
16598 <del>} // namespace posix_error</del>
16599
16600 template &lt;&gt; struct is_error_condition_enum&lt;<del>posix_error::posix_errno</del> <ins>errc</ins>&gt;
16601   : public true_type {}
16602
16603 <del>namespace posix_error {</del>
16604   error_code make_error_code(<del>posix_errno</del> <ins>errc</ins> e);
16605   error_condition make_error_condition(<del>posix_errno</del> <ins>errc</ins> e);
16606 <del>} // namespace posix_error</del>
16607 </pre></blockquote>
16608
16609 <p>
16610 Change System error support 19.4 [syserr] :
16611 </p>
16612
16613 <blockquote>
16614 <del>The <tt>is_error_code_enum</tt> and <tt>is_error_condition_enum</tt> templates may be
16615 specialized for user-defined types to indicate that such a type is
16616 eligible for class <tt>error_code</tt> and class <tt>error_condition</tt> automatic
16617 conversions, respectively.</del>
16618 </blockquote>
16619
16620 <p>
16621 Change System error support 19.4 [syserr] and its subsections:
16622 </p>
16623
16624 <blockquote>
16625 <ul>
16626 <li>
16627 remove all occurrences of <tt>posix_error::</tt>
16628 </li>
16629 <li>
16630 change all instances of <tt>posix_errno</tt> to <tt>errc</tt>
16631 </li>
16632 <li>
16633 change all instances of <tt>posix_category</tt> to <tt>generic_category</tt>
16634 </li>
16635 <li>
16636 change all instances of <tt>get_posix_category</tt> to <tt>get_generic_category</tt>
16637 </li>
16638 </ul>
16639 </blockquote>
16640
16641 <p>
16642 Change Error category objects 19.4.1.5 [syserr.errcat.objects], paragraph 2:
16643 </p>
16644
16645 <blockquote>
16646 <i>Remarks:</i> The object's <tt>default_error_condition</tt> and equivalent virtual
16647 functions shall behave as specified for the class <tt>error_category</tt>. The
16648 object's name virtual function shall return a pointer to the string
16649 <del>"POSIX"</del> <ins>"GENERIC"</ins>.
16650 </blockquote>
16651
16652 <p>
16653 Change 19.4.2.5 [syserr.errcode.nonmembers] Class <tt>error_code</tt> non-member functions as indicated:
16654 </p>
16655
16656 <blockquote>
16657 <pre>error_code make_error_code(<del>posix_errno</del> <ins>errc</ins> e);
16658 </pre>
16659
16660 <blockquote>
16661 <i>Returns:</i> <tt>error_code(<ins>static_cast&lt;int&gt;(</ins>e<ins>)</ins>, <del>posix</del><ins>generic</ins>_category)</tt>.
16662 </blockquote>
16663 </blockquote>
16664
16665 <p>
16666 Change 19.4.3.5 [syserr.errcondition.nonmembers] Class <tt>error_condition</tt> non-member functions as indicated:
16667 </p>
16668
16669 <blockquote>
16670 <pre>error_condition make_error_condition(<del>posix_errno</del> <ins>errc</ins> e);
16671 </pre>
16672
16673 <blockquote>
16674 <i>Returns:</i> <tt>error_condition(<ins>static_cast&lt;int&gt;(</ins>e<ins>)</ins>, <del>posix</del><ins>generic</ins>_category)</tt>.
16675 </blockquote>
16676 </blockquote>
16677
16678
16679
16680 <p><b>Rationale:</b></p>
16681 <table border="1">
16682 <tbody><tr>
16683 <th colspan="2">Names Considered</th>
16684 </tr>
16685
16686 <tr>
16687 <td><tt>portable</tt></td>
16688 <td>
16689 Too non-specific. Did not wish to reserve such a common word in
16690 namespace std. Not quite the right meaning, either.
16691 </td>
16692 </tr>
16693
16694 <tr>
16695 <td><tt>portable_error</tt></td>
16696 <td>
16697 Too long. Explicit qualification is always required for scoped enums, so
16698 a short name is desirable. Not quite the right meaning, either. May be
16699 misleading because <tt>*_error</tt> in the std lib is usually an exception class
16700 name.
16701 </td>
16702 </tr>
16703
16704 <tr>
16705 <td><tt>std_error</tt></td>
16706 <td>
16707 Fairly short, yet explicit. But in fully qualified names like
16708 <tt>std::std_error::not_enough_memory</tt>, the std_ would be unfortunate. Not
16709 quite the right meaning, either. May be misleading because <tt>*_error</tt> in
16710 the std lib is usually an exception class name.
16711 </td>
16712 </tr>
16713
16714 <tr>
16715 <td><tt>generic</tt></td>
16716 <td>
16717 Short enough. The category could be <tt>generic_category</tt>. Fully qualified
16718 names like <tt>std::generic::not_enough_memory</tt> read well. Reserving in
16719 namespace std seems dicey.
16720 </td>
16721 </tr>
16722
16723 <tr>
16724 <td><tt>generic_error</tt></td>
16725 <td>
16726 Longish. The category could be <tt>generic_category</tt>. Fully qualified names
16727 like <tt>std::generic_error::not_enough_memory</tt> read well. Misleading because
16728 <tt>*_error</tt> in the std lib is usually an exception class name.
16729 </td>
16730 </tr>
16731
16732 <tr>
16733 <td><tt>generic_err</tt></td>
16734 <td>
16735 A bit less longish. The category could be <tt>generic_category</tt>. Fully
16736 qualified names like <tt>std::generic_err::not_enough_memory</tt> read well.
16737 </td>
16738 </tr>
16739
16740 <tr>
16741 <td><tt>gen_err</tt></td>
16742 <td>
16743 Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
16744 names like <tt>std::gen_err::not_enough_memory</tt> read well.
16745 </td>
16746 </tr>
16747
16748 <tr>
16749 <td><tt>generr</tt></td>
16750 <td>
16751 Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
16752 names like <tt>std::generr::not_enough_memory</tt> read well.
16753 </td>
16754 </tr>
16755
16756 <tr>
16757 <td><tt>error</tt></td>
16758 <td>
16759 Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
16760 names like <tt>std::error::not_enough_memory</tt> read well. Do we want to use
16761 this general a name?
16762 </td>
16763 </tr>
16764
16765 <tr>
16766 <td><tt>err</tt></td>
16767 <td>
16768 Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
16769 names like <tt>std::err::not_enough_memory</tt> read well. Although alone it
16770 looks odd as a name, given the existing <tt>errno</tt> and <tt>namespace std</tt> names,
16771 it seems fairly intuitive.
16772 Problem: <tt>err</tt> is used throughout the standard library as an argument name
16773 and in examples as a variable name; it seems too confusing to add yet
16774 another use of the name.
16775 </td>
16776 </tr>
16777
16778 <tr>
16779 <td><tt>errc</tt></td>
16780 <td>
16781 Short enough. The "c" stands for "constant". The category could be
16782 <tt>generic_category</tt>. Fully qualified names like
16783 <tt>std::errc::not_enough_memory</tt> read well. Although alone it looks odd as a
16784 name, given the existing <tt>errno</tt> and <tt>namespace std</tt> names, it seems fairly
16785 intuitive. There are no uses of <tt>errc</tt> in the current C++ standard.
16786 </td>
16787 </tr>
16788 </tbody></table>
16789
16790
16791
16792
16793
16794 <hr>
16795 <h3><a name="806"></a>806. <tt>unique_ptr::reset</tt> effects incorrect, too permissive</h3>
16796 <p><b>Section:</b> 20.6.11.2.5 [unique.ptr.single.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
16797  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-03-13</p>
16798 <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>
16799 <p><b>Discussion:</b></p>
16800 <p>
16801 <tt>void unique_ptr::reset(T* p = 0)</tt> is currently specified as:
16802 </p>
16803
16804 <blockquote>
16805 <i>Effects:</i> If <tt>p == get()</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
16806 </blockquote>
16807
16808 <p>
16809 There are two problems with this. One, if <tt>get() == 0</tt> and <tt>p != 0</tt>, the
16810 deleter is called with a NULL pointer, and this is probably not what's
16811 intended (the destructor avoids calling the deleter with 0.)
16812 </p>
16813
16814 <p>
16815 Two, the special check for <tt>get() == p</tt> is generally not needed and such a
16816 situation usually indicates an error in the client code, which is being
16817 masked. As a data point, <tt>boost::shared_ptr</tt> was changed to assert on such
16818 self-resets in 2001 and there were no complaints.
16819 </p>
16820
16821 <p>
16822 One might think that self-resets are necessary for operator= to work; it's specified to perform
16823 </p>
16824
16825 <blockquote><pre>reset( u.release() );
16826 </pre></blockquote>
16827
16828 <p>
16829 and the self-assignment
16830 </p>
16831
16832 <blockquote><pre>p = move(p);
16833 </pre></blockquote>
16834
16835 <p>
16836 might appear to result in a self-reset. But it doesn't; the <tt>release()</tt> is
16837 performed first, zeroing the stored pointer. In other words, <tt>p.reset(
16838 q.release() )</tt> works even when <tt>p</tt> and <tt>q</tt> are the same <tt>unique_ptr</tt>, and there
16839 is no need to special-case <tt>p.reset( q.get() )</tt> to work in a similar
16840 scenario, as it definitely doesn't when <tt>p</tt> and <tt>q</tt> are separate.
16841 </p>
16842
16843
16844
16845 <p><b>Proposed resolution:</b></p>
16846
16847 <p>
16848 Change 20.6.11.2.5 [unique.ptr.single.modifiers]:
16849 </p>
16850
16851 <blockquote>
16852 <pre>void reset(T* p = 0);
16853 </pre>
16854 <blockquote>
16855 -4- <i>Effects:</i> If <tt><del>p ==</del> get()<ins> == 0</ins></tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
16856 </blockquote>
16857 </blockquote>
16858
16859 <p>
16860 Change 20.6.11.3.3 [unique.ptr.runtime.modifiers]:
16861 </p>
16862
16863 <blockquote>
16864 <pre>void reset(T* p = 0);
16865 </pre>
16866 <blockquote>
16867 <p>...</p>
16868 <p>
16869 -2- <i>Effects:</i> If <tt><del>p ==</del> get()<ins> == 0</ins></tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
16870 </p>
16871 </blockquote>
16872 </blockquote>
16873
16874
16875
16876
16877
16878
16879 <hr>
16880 <h3><a name="807"></a>807. <tt>tuple</tt> construction should not fail unless its element's construction fails</h3>
16881 <p><b>Section:</b> 20.3.1.2 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
16882  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-03-13</p>
16883 <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>
16884 <p><b>Discussion:</b></p>
16885 <p>
16886 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> Added a throws clause to <tt>bind</tt> constructors.  I believe the same throws clause
16887 should be added to <tt>tuple</tt> except it ought to take into account move constructors as well.
16888 </p>
16889
16890
16891 <p><b>Proposed resolution:</b></p>
16892 <p>
16893 Add to 20.3.1.2 [tuple.cnstr]:
16894 </p>
16895
16896 <blockquote>
16897 <p>
16898 For each <tt>tuple</tt> constructor and assignment operator, an exception is thrown only if the construction
16899 or assignment of one of the types in <tt>Types</tt> throws an exception.
16900 </p>
16901 </blockquote>
16902
16903
16904
16905
16906
16907 <hr>
16908 <h3><a name="808"></a>808. [forward] incorrect redundant specification</h3>
16909 <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#New">New</a>
16910  <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-03-13</p>
16911 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forward">active issues</a> in [forward].</p>
16912 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward">issues</a> in [forward].</p>
16913 <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>
16914 <p><b>Discussion:</b></p>
16915 <p>
16916 p4 (forward) says:
16917 </p>
16918 <blockquote>
16919 <i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue.
16920 </blockquote>
16921
16922 <p>
16923 First of all, lvalue-ness and rvalue-ness are properties of an expression,
16924 not of a type (see 3.10 [basic.lval]).  Thus, the phrasing "Return type" is wrong.
16925 Second, the phrase says exactly what the core language wording says for
16926 folding references in 14.3.1 [temp.arg.type]/p4  and for function return values
16927 in 5.2.2 [expr.call]/p10.  (If we feel the wording should be retained, it should
16928 at most be a note with cross-references to those sections.)
16929 </p>
16930 <p>
16931 The prose after the example talks about "forwarding as an <tt>int&amp;</tt> (an lvalue)" etc.
16932 In my opinion, this is a category error:  "<tt>int&amp;</tt>" is a type, "lvalue" is a
16933 property of an expression, orthogonal to its type.  (Btw, expressions cannot
16934 have reference type, ever.)
16935 </p>
16936 <p>
16937 Similar with move:
16938 </p>
16939 <blockquote>
16940 Return type: an rvalue.
16941 </blockquote>
16942 <p>
16943 is just wrong and also redundant.
16944 </p>
16945
16946
16947 <p><b>Proposed resolution:</b></p>
16948 <p>
16949 Change 20.2.2 [forward] as indicated:
16950 </p>
16951
16952 <blockquote>
16953 <pre>template &lt;class T&gt; T&amp;&amp; forward(typename identity&lt;T&gt;::type&amp;&amp; t);
16954 </pre>
16955
16956 <blockquote>
16957 <p>...</p>
16958 <p>
16959 <del><i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue.</del>
16960 </p>
16961 <p>...</p>
16962 <p>
16963 -7- In the first call to <tt>factory</tt>, <tt>A1</tt> is deduced as <tt>int</tt>, so 2 is forwarded to <tt>A</tt>'s constructor
16964 as <del>an <tt>int&amp;&amp;</tt> (</del>an rvalue<del>)</del>. In the second call to factory, <tt>A1</tt> is deduced
16965 as <tt>int&amp;</tt>, so <tt>i</tt> is forwarded to <tt>A</tt>'s constructor as <del>an <tt>int&amp;</tt> (</del>an lvalue<del>)</del>.
16966 In both cases, <tt>A2</tt> is deduced as double, so 1.414 is forwarded to <tt>A</tt>'s constructor as
16967 <del><tt>double&amp;&amp;</tt> (</del>an rvalue<del>)</del>.
16968 </p>
16969 </blockquote>
16970
16971 <pre>template &lt;class T&gt; typename remove_reference&lt;T&gt;::type&amp;&amp; move(T&amp;&amp; t);
16972 </pre>
16973
16974 <blockquote>
16975 <p>...</p>
16976 <p>
16977 <del><i>Return type:</i>  an rvalue.</del>
16978 </p>
16979 </blockquote>
16980
16981 </blockquote>
16982
16983
16984
16985
16986
16987
16988 <hr>
16989 <h3><a name="809"></a>809. std::swap should be overloaded for array types</h3>
16990 <p><b>Section:</b> 25.2.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
16991  <b>Submitter:</b> Niels Dekker <b>Date:</b> 2008-02-28</p>
16992 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.swap">issues</a> in [alg.swap].</p>
16993 <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>
16994 <p><b>Discussion:</b></p>
16995 <p>
16996 For the sake of generic programming, the header <code>&lt;algorithm&gt;</code> should provide an
16997 overload of <code>std::swap</code> for array types:
16998 </p><pre>template&lt;class T, size_t N&gt; void swap(T (&amp;a)[N], T (&amp;b)[N]);
16999 </pre>
17000
17001
17002 <p>
17003 It became apparent to me that this overload is missing, when I considered how to write a swap
17004 function for a generic wrapper class template.
17005 (Actually I was thinking of Boost's <a href="http://www.boost.org/libs/utility/value_init.htm">value_initialized</a>.)
17006 Please look at the following template, <code>W</code>, and suppose that is intended to be a very
17007 <em>generic</em> wrapper:
17008 </p><pre>template&lt;class T&gt; class W {
17009 public:
17010    T data;
17011 };
17012 </pre>
17013 Clearly <code>W&lt;T&gt;</code> is <em>CopyConstructible and CopyAssignable</em>, and therefore
17014 <em>Swappable</em>, whenever <code>T</code> is <em>CopyConstructible and CopyAssignable</em>.
17015 Moreover, <code>W&lt;T&gt;</code> is <em>also</em> Swappable when <code>T</code> is an array type
17016 whose element type is CopyConstructible and CopyAssignable.
17017 Still it is recommended to add a <em>custom</em> swap function template to such a class template,
17018 for the sake of efficiency and exception safety.
17019 (E.g., <em>Scott Meyers, Effective C++, Third Edition, item 25: Consider support for a non-throwing
17020 swap</em>.)
17021 This function template is typically written as follows:
17022 <pre>template&lt;class T&gt; void swap(W&lt;T&gt;&amp; x, W&lt;T&gt;&amp; y) {
17023   using std::swap;
17024   swap(x.data, y.data);
17025 }
17026 </pre>
17027 Unfortunately, this will introduce an undesirable inconsistency, when <code>T</code> is an array.
17028 For instance, <code>W&lt;std::string[8]&gt;</code> is Swappable, but the current Standard does not
17029 allow calling the custom swap function that was especially written for <code>W</code>!
17030 <pre>W&lt;std::string[8]&gt; w1, w2;  // Two objects of a Swappable type.
17031 std::swap(w1, w2);  // Well-defined, but inefficient.
17032 using std::swap;
17033 swap(w1, w2);  // Ill-formed, just because ADL finds W's swap function!!!
17034 </pre>
17035
17036 <code>W</code>'s <code>swap</code> function would try to call <code>std::swap</code> for an array,
17037 <code>std::string[8]</code>, which is not supported by the Standard Library.
17038 This issue is easily solved by providing an overload of <code>std::swap</code> for array types.
17039 This swap function should be implemented in terms of swapping the elements of the arrays, so that
17040 it would be non-throwing for arrays whose element types have a non-throwing swap.
17041
17042
17043 <p>
17044 Note that such an overload of <code>std::swap</code> should also support <em>multi-dimensional</em>
17045 arrays. Fortunately that isn't really an issue, because it would do so <i>automatically</i>, by
17046 means of recursion.
17047 </p>
17048
17049 <p>
17050 For your information, there was a discussion on this issue at comp.lang.c++.moderated: <a href="http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/9341ebd3635c9c74">[Standard
17051 Library] Shouldn't std::swap be overloaded for C-style arrays?</a>
17052 </p>
17053
17054
17055 <p><b>Proposed resolution:</b></p>
17056 <p>
17057 Add an extra condition to the definition of Swappable requirements [swappable] in 20.1.1 [utility.arg.requirements]:
17058 </p>
17059 <blockquote>
17060 - <tt>T</tt> is <tt>Swappable</tt> if <tt>T</tt> is an array type whose element type is <tt>Swappable</tt>.
17061 </blockquote>
17062 <p>
17063 Add the following to 25.2.3 [alg.swap]:
17064 </p>
17065 <blockquote>
17066 <pre>template&lt;class T, size_t N&gt; void swap(T (&amp;a)[N], T (&amp;b)[N]);
17067 </pre>
17068 <blockquote>
17069 <i>Requires:</i> Type <code>T</code> shall be <tt>Swappable</tt>.
17070 </blockquote>
17071 <blockquote>
17072 <i>Effects:</i> <code>swap_ranges(a, a + N, b);</code>
17073 </blockquote>
17074 </blockquote>
17075
17076
17077
17078
17079
17080 <hr>
17081 <h3><a name="810"></a>810. Missing traits dependencies in operational semantics of extended manipulators</h3>
17082 <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>
17083  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-03-01</p>
17084 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ext.manip">active issues</a> in [ext.manip].</p>
17085 <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>
17086 <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>
17087 <p><b>Discussion:</b></p>
17088 <p>
17089 The recent draft (as well as the original proposal n2072) uses an
17090 operational semantic
17091 for <tt>get_money</tt> ([ext.manip]/3) and <tt>put_money</tt> ([ext.manip]/5), which uses
17092 </p>
17093
17094 <blockquote><pre>istreambuf_iterator&lt;charT&gt;
17095 </pre></blockquote>
17096
17097 <p>
17098 and
17099 </p>
17100
17101 <blockquote><pre>ostreambuf_iterator&lt;charT&gt;
17102 </pre></blockquote>
17103
17104 <p>
17105 resp, instead of the iterator instances, with explicitly provided
17106 traits argument (The operational semantic defined by <tt>f</tt> is also traits
17107 dependent). This is an obvious oversight because both <tt>*stream_buf</tt>
17108 c'tors expect a <tt>basic_streambuf&lt;charT,traits&gt;</tt> as argument.
17109 </p>
17110 <p>
17111 The same problem occurs within the <tt>get_time</tt> and <tt>put_time</tt> semantic (p.
17112 7 and p. 9)
17113 of n2071 incorporated in N2521, where additional to the problem we
17114 have an editorial issue in <tt>get_time</tt> (<tt>streambuf_iterator</tt> instead of
17115 <tt>istreambuf_iterator</tt>).
17116 </p>
17117
17118
17119 <p><b>Proposed resolution:</b></p>
17120 <p>
17121 In 27.6.4 [ext.manip]/3 within function <tt>f</tt> replace the first line
17122 </p>
17123
17124 <blockquote><pre>template &lt;class charT, class traits, class moneyT&gt;
17125 void f(basic_ios&lt;charT, traits&gt;&amp; str, moneyT&amp; mon, bool intl) {
17126    typedef istreambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
17127    ...
17128 </pre></blockquote>
17129
17130 <p>
17131 In 27.6.4 [ext.manip]/4 remove the first template <tt>charT</tt> parameter:
17132 </p>
17133
17134 <blockquote><pre>template &lt;<del>class charT, </del>class moneyT&gt; unspecified put_money(const moneyT&amp; mon, bool intl = false<ins>)</ins>;
17135 </pre></blockquote>
17136
17137 <p>
17138 In 27.6.4 [ext.manip]/5 within function <tt>f</tt> replace the first line
17139 </p>
17140
17141 <blockquote><pre>template &lt;class charT, class traits, class moneyT&gt;
17142 void f(basic_ios&lt;charT, traits&gt;&amp; str, const moneyT&amp; mon, bool intl) {
17143   typedef ostreambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
17144   ...
17145 </pre></blockquote>
17146
17147 <p>
17148 In 27.6.4 [ext.manip]/7 within function <tt>f</tt> replace the first line
17149 </p>
17150
17151 <blockquote><pre>template &lt;class charT, class traits&gt;
17152 void f(basic_ios&lt;charT, traits&gt;&amp; str, struct tm *tmb, const charT *fmt) {
17153   typedef <ins>i</ins>streambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
17154   ...
17155 </pre></blockquote>
17156
17157 <p>
17158 In 27.6.4 [ext.manip]/8 add const:
17159 </p>
17160
17161 <blockquote><pre>template &lt;class charT&gt; unspecified put_time(<ins>const</ins> struct tm *tmb, const charT *fmt);
17162 </pre></blockquote>
17163
17164 <p>
17165 In 27.6.4 [ext.manip]/9 within function <tt>f</tt> replace the first line
17166 </p>
17167
17168 <blockquote><pre>template &lt;class charT, class traits&gt;
17169 void f(basic_ios&lt;charT, traits&gt;&amp; str, const struct tm *tmb, const charT *fmt) {
17170   typedef ostreambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
17171   ...
17172 </pre></blockquote>
17173
17174 <p>
17175 Add to the <tt>&lt;iomanip&gt;</tt> synopsis in 27.6 [iostream.format]
17176 </p>
17177
17178 <blockquote><pre>template &lt;class moneyT&gt; unspecified get_money(moneyT&amp; mon, bool intl = false);
17179 template &lt;class moneyT&gt; unspecified put_money(const moneyT&amp; mon, bool intl = false);
17180 template &lt;class charT&gt; unspecified get_time(struct tm *tmb, const charT *fmt);
17181 template &lt;class charT&gt; unspecified put_time(const struct tm *tmb, const charT *fmt);
17182 </pre></blockquote>
17183
17184
17185
17186
17187
17188
17189 <hr>
17190 <h3><a name="811"></a>811. <tt>pair</tt> of pointers no longer works with literal 0</h3>
17191 <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#New">New</a>
17192  <b>Submitter:</b> Doug Gregor <b>Date:</b> 2008-03-14</p>
17193 <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>
17194 <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>
17195 <p><b>Discussion:</b></p>
17196 <blockquote><pre>#include &lt;utility&gt;
17197
17198 int main()
17199 {
17200    std::pair&lt;char *, char *&gt; p (0,0);
17201 }
17202 </pre></blockquote>
17203
17204 <p>
17205 I just got a bug report about that, because it's valid C++03, but not
17206 C++0x. The important realization, for me, is that the emplace
17207 proposal---which made <tt>push_back</tt> variadic, causing the <tt>push_back(0)</tt>
17208 issue---didn't cause this break in backward compatibility. The break
17209 actually happened when we added this pair constructor as part of adding
17210 rvalue references into the language, long before variadic templates or
17211 emplace came along:
17212 </p>
17213
17214 <blockquote><pre>template&lt;class U, class V&gt; pair(U&amp;&amp; x, V&amp;&amp; y);
17215 </pre></blockquote>
17216
17217 <p>
17218 Now, concepts will address this issue by constraining that <tt>pair</tt>
17219 constructor to only <tt>U</tt>'s and <tt>V</tt>'s that can properly construct "first" and
17220 "second", e.g. (from
17221 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2322.pdf">N2322</a>):
17222 </p>
17223
17224 <blockquote><pre>template&lt;class U , class V &gt;
17225 requires Constructible&lt;T1, U&amp;&amp;&gt; &amp;&amp; Constructible&lt;T2, V&amp;&amp;&gt;
17226 pair(U&amp;&amp; x , V&amp;&amp; y );
17227 </pre></blockquote>
17228
17229
17230
17231 <p><b>Proposed resolution:</b></p>
17232 <p>
17233 </p>
17234
17235
17236
17237
17238
17239 <hr>
17240 <h3><a name="812"></a>812. unsolicited multithreading considered harmful?</h3>
17241 <p><b>Section:</b> 25.3.1 [alg.sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17242  <b>Submitter:</b> Paul McKenney <b>Date:</b> 2008-02-27</p>
17243 <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>
17244 <p><b>Discussion:</b></p>
17245 <p>
17246 Multi-threading is a good thing, but unsolicited multi-threading can
17247 potentially be harmful.  For example, <tt>sort()</tt> performance might be
17248 greatly increased via a multithreaded implementation.  However, such
17249 a multithreaded implementation could result in concurrent invocations
17250 of the user-supplied comparator.  This would in turn result in problems
17251 given a caching comparator that might be written for complex sort keys.
17252 Please note that this is not a theoretical issue, as multithreaded
17253 implementations of <tt>sort()</tt> already exist.
17254 </p>
17255 <p>
17256 Having a multithreaded <tt>sort()</tt> available is good, but it should not
17257 be the default for programs that are not explicitly multithreaded.
17258 Users should not be forced to deal with concurrency unless they have
17259 asked for it.
17260 </p>
17261
17262 <p><i>[
17263 This may be covered by
17264 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2410.html">N2410</a>
17265 Thread-Safety in the Standard Library (Rev 1).
17266 ]</i></p>
17267
17268
17269
17270 <p><b>Proposed resolution:</b></p>
17271 <p>
17272 </p>
17273
17274
17275
17276
17277
17278 <hr>
17279 <h3><a name="813"></a>813. "empty" undefined for <tt>shared_ptr</tt></h3>
17280 <p><b>Section:</b> 20.6.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17281  <b>Submitter:</b> Matt Austern <b>Date:</b> 2008-02-26</p>
17282 <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>
17283 <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>
17284 <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>
17285 <p><b>Discussion:</b></p>
17286 <p>
17287 Several places in 20.6.12.2 [util.smartptr.shared] refer to an "empty" <tt>shared_ptr</tt>.
17288 However, that term is nowhere defined. The closest thing we have to a
17289 definition is that the default constructor creates an empty <tt>shared_ptr</tt>
17290 and that a copy of a default-constructed <tt>shared_ptr</tt> is empty. Are any
17291 other <tt>shared_ptr</tt>s empty? For example, is <tt>shared_ptr((T*) 0)</tt> empty? What
17292 are the properties of an empty <tt>shared_ptr</tt>? We should either clarify this
17293 term or stop using it.
17294 </p><p>
17295 </p>
17296 One reason it's not good enough to leave this term up to the reader's
17297 intuition is that, in light of
17298 <a href="http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2007/n2351.htm">N2351</a>
17299 and issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, most readers'
17300 intuitive understanding is likely to be wrong. Intuitively one might
17301 expect that an empty <tt>shared_ptr</tt> is one that doesn't store a pointer,
17302 but, whatever the definition is, that isn't it.
17303
17304
17305 <p><i>[
17306 Peter adds:
17307 ]</i></p>
17308
17309
17310 <blockquote>
17311 <p>
17312 Or, what is an "empty" <tt>shared_ptr</tt>?
17313 </p>
17314
17315 <ul>
17316 <li>
17317 <p>
17318 Are any other <tt>shared_ptrs</tt> empty?
17319 </p>
17320 <p>
17321 Yes. Whether a given <tt>shared_ptr</tt> instance is empty or not is (*)
17322 completely specified by the last mutating operation on that instance.
17323 Give me an example and I'll tell you whether the <tt>shared_ptr</tt> is empty or
17324 not.
17325 </p>
17326 <blockquote>
17327 (*) If it isn't, this is a legitimate defect.
17328 </blockquote>
17329 </li>
17330
17331 <li>
17332 <p>
17333 For example, is <tt>shared_ptr((T*) 0)</tt> empty?
17334 </p>
17335 <p>
17336 No. If it were empty, it would have a <tt>use_count()</tt> of 0, whereas it is
17337 specified to have an <tt>use_count()</tt> of 1.
17338 </p>
17339 </li>
17340
17341 <li>
17342 <p>
17343 What are the properties of an empty <tt>shared_ptr</tt>?
17344 </p>
17345 <p>
17346 The properties of an empty <tt>shared_ptr</tt> can be derived from the
17347 specification. One example is that its destructor is a no-op. Another is
17348 that its <tt>use_count()</tt> returns 0. I can enumerate the full list if you
17349 really like.
17350 </p>
17351 </li>
17352
17353 <li>
17354 <p>
17355 We should either clarify this term or stop using it.
17356 </p>
17357 <p>
17358 I don't agree with the imperative tone
17359 </p>
17360 <p>
17361 A clarification would be either a no-op - if it doesn't contradict the
17362 existing wording - or a big mistake if it does.
17363 </p>
17364 <p>
17365 I agree that a clarification that is formally a no-op may add value.
17366 </p>
17367 </li>
17368
17369 <li>
17370 <p>
17371 However, that term is nowhere defined.
17372 </p>
17373 <p>
17374 Terms can be useful without a definition. Consider the following
17375 simplistic example. We have a type <tt>X</tt> with the following operations
17376 defined:
17377 </p>
17378 <blockquote><pre>X x;
17379 X x2(x);
17380 X f(X x);
17381 X g(X x1, X x2);
17382 </pre></blockquote>
17383 <p>
17384 A default-constructed value is green.<br>
17385 A copy has the same color as the original.<br>
17386 <tt>f(x)</tt> returns a red value if the argument is green, a green value otherwise.<br>
17387 <tt>g(x1,x2)</tt> returns a green value if the arguments are of the same color, a red value otherwise.
17388 </p>
17389
17390 <p>
17391 Given these definitions, you can determine the color of every instance
17392 of type <tt>X</tt>, even if you have absolutely no idea what green and red mean.
17393 </p>
17394
17395 <p>
17396 Green and red are "nowhere defined" and completely defined at the same time.
17397 </p>
17398 </li>
17399 </ul>
17400
17401 <p>
17402 Alisdair's wording is fine.
17403 </p>
17404 </blockquote>
17405
17406
17407 <p><b>Proposed resolution:</b></p>
17408 <p>
17409 Append the following sentance to 20.6.12.2 [util.smartptr.shared]
17410 </p>
17411 <blockquote>
17412 The <code>shared_ptr</code> class template stores a pointer, usually obtained
17413 via <code>new</code>. <code>shared_ptr</code> implements semantics of
17414 shared ownership; the last remaining owner of the pointer is responsible for
17415 destroying the object, or otherwise releasing  the resources associated with
17416 the stored pointer. <ins>A <code>shared_ptr</code> object that does not own
17417 a pointer is said to be <i>empty</i>.</ins>
17418 </blockquote>
17419
17420
17421
17422
17423
17424 <hr>
17425 <h3><a name="814"></a>814. <tt>vector&lt;bool&gt;::swap(reference, reference)</tt> not defined</h3>
17426 <p><b>Section:</b> 23.2.7 [vector.bool] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17427  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-17</p>
17428 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#vector.bool">active issues</a> in [vector.bool].</p>
17429 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.bool">issues</a> in [vector.bool].</p>
17430 <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>
17431 <p><b>Discussion:</b></p>
17432 <p>
17433 <tt>vector&lt;bool&gt;::swap(reference, reference)</tt> has no definition.
17434 </p>
17435
17436
17437 <p><b>Proposed resolution:</b></p>
17438 <p>
17439 </p>
17440
17441
17442
17443
17444
17445 <hr>
17446 <h3><a name="815"></a>815. <tt>std::function</tt> and <tt>reference_closure</tt> do not use perfect forwarding</h3>
17447 <p><b>Section:</b> 20.5.15.2.4 [func.wrap.func.inv] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17448  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-16</p>
17449 <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>
17450 <p><b>Discussion:</b></p>
17451 <p>
17452 <tt>std::function</tt> and <tt>reference_closure</tt> should use "perfect forwarding" as
17453 described in the rvalue core proposal.
17454 </p>
17455
17456
17457 <p><b>Proposed resolution:</b></p>
17458 <p>
17459 </p>
17460
17461
17462
17463
17464
17465 <hr>
17466 <h3><a name="816"></a>816. Should <tt>bind()</tt>'s returned functor have a nofail copy ctor when <tt>bind()</tt> is nofail?</h3>
17467 <p><b>Section:</b> 20.5.11.1.3 [func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17468  <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2008-02-08</p>
17469 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.bind.bind">active issues</a> in [func.bind.bind].</p>
17470 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p>
17471 <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>
17472 <p><b>Discussion:</b></p>
17473 <p>
17474 Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> notes that <tt>bind(f, t1, ..., tN)</tt>
17475 should be nofail when <tt>f, t1, ..., tN</tt> have nofail copy ctors.
17476 </p>
17477 <p>
17478 However, no guarantees are provided for the copy ctor of the functor
17479 returned by <tt>bind()</tt>.  (It's guaranteed to have a copy ctor, which can
17480 throw implementation-defined exceptions: <tt>bind()</tt> returns a forwarding
17481 call wrapper, TR1 3.6.3/2.  A forwarding call wrapper is a call wrapper,
17482 TR1 3.3/4.  Every call wrapper shall be CopyConstructible, TR1 3.3/4.
17483 Everything without an exception-specification may throw
17484 implementation-defined exceptions unless otherwise specified, C++03
17485 17.4.4.8/3.)
17486 </p>
17487 <p>
17488 Should the nofail guarantee requested by Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> be extended
17489 to cover both calling <tt>bind()</tt> and copying the returned functor?
17490 </p>
17491
17492 <p><i>[
17493 Howard adds:
17494 ]</i></p>
17495
17496
17497 <blockquote>
17498 <tt>tuple</tt> construction should probably have a similar guarantee.
17499 </blockquote>
17500
17501
17502
17503 <p><b>Proposed resolution:</b></p>
17504 <p>
17505 </p>
17506
17507
17508
17509
17510
17511 <hr>
17512 <h3><a name="817"></a>817. <tt>bind</tt> needs to be moved</h3>
17513 <p><b>Section:</b> 20.5.11.1.3 [func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17514  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-03-17</p>
17515 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.bind.bind">active issues</a> in [func.bind.bind].</p>
17516 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p>
17517 <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>
17518 <p><b>Discussion:</b></p>
17519 <p>
17520 The functor retureed by <tt>bind()</tt> should have a move constructor that
17521 requires only move construction of its contained functor and bound arguments.
17522 That way move-only functors can be passed to objects such as <tt>thread</tt>.
17523 </p>
17524 <p>
17525 This issue is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>.
17526 </p>
17527
17528
17529 <p><b>Proposed resolution:</b></p>
17530 <p>
17531 </p>
17532
17533
17534
17535
17536
17537 <hr>
17538 <h3><a name="818"></a>818. wording for memory ordering</h3>
17539 <p><b>Section:</b> 29.1 [atomics.order] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17540  <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-03-22</p>
17541 <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>
17542 <p><b>Discussion:</b></p>
17543 <p>
17544 29.1 [atomics.order] p1 says in the table that
17545 </p>
17546
17547 <blockquote>
17548 <table border="1">
17549 <tbody><tr>
17550 <th>Element</th><th>Meaning</th>
17551 </tr>
17552 <tr>
17553 <td><tt>memory_order_acq_rel</tt></td>
17554 <td>the operation has both acquire and release semantics</td>
17555 </tr>
17556 </tbody></table>
17557 </blockquote>
17558
17559 <p>
17560 To my naked eye, that seems to imply that even an atomic read has both
17561 acquire and release semantics.
17562 </p>
17563
17564 <p>
17565 Then, p1 says in the table:
17566 </p>
17567
17568 <blockquote>
17569 <table border="1">
17570 <tbody><tr>
17571 <th>Element</th><th>Meaning</th>
17572 </tr>
17573 <tr>
17574 <td><tt>memory_order_seq_cst</tt></td>
17575 <td>the operation has both acquire and release semantics,
17576     and, in addition, has sequentially-consistent operation ordering</td>
17577 </tr>
17578 </tbody></table>
17579 </blockquote>
17580
17581 <p>
17582 So that seems to be "the same thing" as <tt>memory_order_acq_rel</tt>, with additional
17583 constraints.
17584 </p>
17585
17586 <p>
17587 I'm then reading p2, where it says:
17588 </p>
17589
17590 <blockquote>
17591 The <tt>memory_order_seq_cst</tt> operations that load a value are acquire operations
17592 on the affected locations. The <tt>memory_order_seq_cst</tt> operations that store a value
17593 are release operations on the affected locations.
17594 </blockquote>
17595
17596 <p>
17597 That seems to imply that atomic reads only have acquire semantics.  If that
17598 is intended, does this also apply to <tt>memory_order_acq_rel</tt> and the individual
17599 load/store operations as well?
17600 </p>
17601
17602 <p>
17603 Also, the table in p1 contains phrases with "thus" that seem to indicate
17604 consequences of normative wording in 1.10 [intro.multithread].  That shouldn't be in
17605 normative text, for the fear of redundant or inconsistent specification with
17606 the other normative text.
17607 </p>
17608
17609 <p>
17610 Double-check 29.4.4 [atomics.types.operations] that each
17611 operation clearly says whether it's a load or a store operation, or
17612 both.  (It could be clearer, IMO.  Solution not in current proposed resolution.)
17613 </p>
17614
17615 <p>
17616 29.1 [atomics.order] p2:  What's a "consistent execution"?  It's not defined in
17617 1.10 [intro.multithread], it's just used in notes there.
17618 </p>
17619
17620 <p>
17621 And why does 29.4.4 [atomics.types.operations] p9 for "load" say:
17622 </p>
17623
17624
17625 <blockquote>
17626 <i>Requires:</i> The order argument shall not be <tt>memory_order_acquire</tt>
17627 nor <tt>memory_order_acq_rel</tt>.
17628 </blockquote>
17629
17630 <p>
17631 (Since this is exactly the same restriction as for "store", it seems to be a typo.)
17632 </p>
17633
17634 <p>
17635 And then: 29.4.4 [atomics.types.operations] p12:
17636 </p>
17637
17638 <blockquote>
17639 These operations are read-modify-write operations in the sense of the
17640 "synchronizes with" definition (1.10 [intro.multithread]), so both such an operation and the
17641 evaluation that produced the input value synchronize with any evaluation
17642 that reads the updated value.
17643 </blockquote>
17644
17645 <p>
17646 This is redundant with 1.10 [intro.multithread], see above for the reasoning.
17647 </p>
17648
17649
17650 <p><b>Proposed resolution:</b></p>
17651 <p>
17652 Replace the cross-reference in p1 to refer to 1.1 [intro.scope] instead of
17653 1.7 [intro.memory].
17654 Rephrase the table in as follows (maybe don't use a table):
17655 </p>
17656
17657 <blockquote>
17658 <p>
17659 For <tt>memory_order_relaxed</tt>, no operation orders memory.
17660 </p>
17661
17662 <p>
17663 For <tt>memory_order_release</tt>, <tt>memory_order_acq_rel</tt>, and <tt>memory_order_seq_cst</tt>,
17664 a store operation performs a release operation on the affected memory location.
17665 </p>
17666
17667 <p>
17668 For <tt>memory_order_acquire</tt>, <tt>memory_order_acq_rel</tt>, and <tt>memory_order_seq_cst</tt>,
17669 a load operation performs an acquire operation on the affected memory location.
17670 </p>
17671 </blockquote>
17672
17673 <p>
17674 Rephrase 29.1 [atomics.order] p2:
17675 </p>
17676
17677 <blockquote>
17678 <del>The <tt>memory_order_seq_cst</tt> operations that load a value are
17679 acquire operations on the affected locations. The
17680 <tt>memory_order_seq_cst</tt> operations that store a value are release
17681 operations on the affected locations.</del>
17682 <del>In addition, in a consistent
17683 execution, t</del><ins>T</ins>here <del>must be</del> <ins>is</ins> a single
17684 total order <tt>S</tt> on all
17685 <tt>memory_order_seq_cst</tt> operations, consistent with the happens before
17686 order and modification orders for all affected locations, such that each
17687 <tt>memory_order_seq_cst</tt> operation observes either the last preceding
17688 modification according to this order <tt>S</tt>, or the result of an operation
17689 that is not <tt>memory_order_seq_cst</tt>. [<i>Note:</i> Although it is not explicitly
17690 required that <tt>S</tt> include locks, it can always be extended to an order
17691 that does include lock and unlock operations, since the ordering between
17692 those is already included in the happens before ordering. <i>-- end note</i>]
17693 </blockquote>
17694
17695 <p>
17696 Rephrase 29.4.4 [atomics.types.operations] p12 as:
17697 </p>
17698
17699 <blockquote>
17700 <i>Effects:</i> Atomically replaces the value pointed to by object or by
17701 this with desired. Memory is affected according to the value of order.
17702 These operations are read-modify-write operations <del>in the sense of the
17703 "synchronizes with" definition</del> (1.10 [intro.multithread])<del>, so both such an operation and the
17704 evaluation that produced the input value synchronize with any evaluation
17705 that reads the updated value</del>.
17706 </blockquote>
17707
17708 <p>
17709 Same in p15, p20, p22.
17710 </p>
17711
17712
17713
17714
17715
17716
17717 <hr>
17718 <h3><a name="819"></a>819. rethrow_if_nested</h3>
17719 <p><b>Section:</b> 18.7.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17720  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-25</p>
17721 <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>
17722 <p><b>Discussion:</b></p>
17723 <p>
17724 Looking at the wording I submitted for <tt>rethrow_if_nested</tt>, I don't think I
17725 got it quite right.
17726 </p>
17727
17728 <p>
17729 The current wording says:
17730 </p>
17731
17732 <blockquote>
17733 <pre>template &lt;class E&gt; void rethrow_if_nested(const E&amp; e);
17734 </pre>
17735 <blockquote>
17736 <p>
17737 <i>Effects:</i> Calls <tt>e.rethrow_nested()</tt> only if <tt>e</tt>
17738 is publicly derived from <tt>nested_exception</tt>.
17739 </p>
17740 </blockquote>
17741 </blockquote>
17742
17743 <p>
17744 This is trying to be a bit subtle, by requiring <tt>e</tt> (not <tt>E</tt>) to be publicly
17745 derived from <tt>nested_exception</tt> the idea is that a <tt>dynamic_cast</tt> would be
17746 required to be sure.  Unfortunately, if <tt>e</tt> is dynamically but not statically
17747 derived from <tt>nested_exception</tt>, <tt>e.rethrow_nested()</tt> is ill-formed.
17748 </p>
17749
17750
17751 <p><b>Proposed resolution:</b></p>
17752
17753
17754
17755
17756
17757 <hr>
17758 <h3><a name="820"></a>820. <tt>current_exception()</tt>'s interaction with throwing copy ctors</h3>
17759 <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>
17760  <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2008-03-26</p>
17761 <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>
17762 <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>
17763 <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>
17764 <p><b>Discussion:</b></p>
17765 <p>
17766 As of N2521, the Working Paper appears to be silent about what
17767 <tt>current_exception()</tt> should do if it tries to copy the currently handled
17768 exception and its copy constructor throws.  18.7.5 [propagation]/7 says "If the
17769 function needs to allocate memory and the attempt fails, it returns an
17770 <tt>exception_ptr</tt> object that refers to an instance of <tt>bad_alloc</tt>.", but
17771 doesn't say anything about what should happen if memory allocation
17772 succeeds but the actual copying fails.
17773 </p>
17774
17775 <p>
17776 I see three alternatives: (1) return an <tt>exception_ptr</tt> object that refers
17777 to an instance of some fixed exception type, (2) return an <tt>exception_ptr</tt>
17778 object that refers to an instance of the copy ctor's thrown exception
17779 (but if that has a throwing copy ctor, an infinite loop can occur), or
17780 (3) call <tt>terminate()</tt>.
17781 </p>
17782
17783 <p>
17784 I believe that <tt>terminate()</tt> is the most reasonable course of action, but
17785 before we go implement that, I wanted to raise this issue.
17786 </p>
17787
17788 <p><i>[
17789 Peter's summary:
17790 ]</i></p>
17791
17792
17793 <blockquote>
17794 <p>
17795 The current practice is to not have throwing copy constructors in
17796 exception classes, because this can lead to <tt>terminate()</tt> as described in
17797 15.5.1 [except.terminate]. Thus calling <tt>terminate()</tt> in this situation seems
17798 consistent and does not introduce any new problems.
17799 </p>
17800
17801 <p>
17802 However, the resolution of core issue 475 may relax this requirement:
17803 </p>
17804
17805 <blockquote>
17806 The CWG agreed with the position that <tt>std::uncaught_exception()</tt> should
17807 return <tt>false</tt> during the copy to the exception object and that <tt>std::terminate()</tt>
17808 should not be called if that constructor exits with an exception.
17809 </blockquote>
17810
17811 <p>
17812 Since throwing copy constructors will no longer call <tt>terminate()</tt>, option
17813 (3) doesn't seem reasonable as it is deemed too drastic a response in a
17814 recoverable situation.
17815 </p>
17816
17817 <p>
17818 Option (2) cannot be adopted by itself, because a potential infinite
17819 recursion will need to be terminated by one of the other options.
17820 </p>
17821
17822 </blockquote>
17823
17824
17825 <p><b>Proposed resolution:</b></p>
17826 <p>
17827 Add the following paragraph after 18.7.5 [propagation]/7:
17828 </p>
17829
17830 <blockquote>
17831 <p>
17832 <i>Returns (continued):</i> If the attempt to copy the current exception
17833 object throws an exception, the function returns an <tt>exception_ptr</tt> that
17834 refers to the thrown exception or, if this is not possible, to an
17835 instance of <tt>bad_exception</tt>.
17836 </p>
17837 <p>
17838 [<i>Note:</i> The copy constructor of the thrown exception may also fail, so
17839 the implementation is allowed to substitute a <tt>bad_exception</tt> to avoid
17840 infinite recursion. <i>-- end note.</i>]
17841 </p>
17842 </blockquote>
17843
17844
17845
17846
17847
17848
17849 <hr>
17850 <h3><a name="821"></a>821. Minor cleanup : <tt>unique_ptr</tt></h3>
17851 <p><b>Section:</b> 20.6.11.3.3 [unique.ptr.runtime.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17852  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-30</p>
17853 <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>
17854 <p><b>Discussion:</b></p>
17855 <p>
17856 Reading resolution of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a> I noticed the following:
17857 </p>
17858
17859 <blockquote>
17860 <pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
17861 </pre>
17862
17863 <p>
17864 -1- <i>Requires:</i> Does not accept pointer types which are convertible
17865 to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (diagnostic
17866 required). [<i>Note:</i> One implementation technique is to create a private
17867 templated overload. <i>-- end note</i>]
17868 </p>
17869 </blockquote>
17870
17871 <p>
17872 This could be cleaned up by mandating the overload as a public deleted
17873 function.  In addition, we should probably overload <tt>reset</tt> on <tt>nullptr_t</tt>
17874 to be a stronger match than the deleted overload. Words...
17875 </p>
17876
17877
17878 <p><b>Proposed resolution:</b></p>
17879 <p>
17880 Add to class template definition in 20.6.11.3 [unique.ptr.runtime]
17881 </p>
17882
17883 <blockquote>
17884 <pre>// modifiers
17885 T* release();
17886 void reset(T* p = 0);
17887 <ins>void reset( nullptr_t );</ins>
17888 <ins>template&lt; typename T &gt; void reset( T ) = delete;</ins>
17889 void swap(unique_ptr&amp;&amp; u);
17890 </pre>
17891 </blockquote>
17892
17893 <p>
17894 Update 20.6.11.3.3 [unique.ptr.runtime.modifiers]
17895 </p>
17896
17897 <blockquote>
17898 <pre>void reset(pointer p = pointer());
17899 <ins>void reset(nullptr_t);</ins>
17900 </pre>
17901
17902 <p>
17903 <del>-1- <i>Requires:</i> Does not accept pointer types which are convertible
17904 to <tt>pointer</tt> (diagnostic
17905 required). [<i>Note:</i> One implementation technique is to create a private
17906 templated overload. <i>-- end note</i>]</del>
17907 </p>
17908 <p>
17909 <i>Effects:</i> If <tt>get() == nullptr</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
17910 </p>
17911 <p>...</p>
17912 </blockquote>
17913
17914 <p><i>[
17915 Note this wording incorporates resolutions for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a> (New) and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a> (Ready).
17916 ]</i></p>
17917
17918
17919
17920
17921
17922
17923 <hr>
17924 <h3><a name="822"></a>822. Object with explicit copy constructor no longer <tt>CopyConstructible</tt></h3>
17925 <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>
17926  <b>Submitter:</b> James Kanze <b>Date:</b> 2008-04-01</p>
17927 <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>
17928 <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>
17929 <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>
17930 <p><b>Discussion:</b></p>
17931 <p>
17932 I just noticed that the following program is legal in C++03, but
17933 is forbidden in the current draft:
17934 </p>
17935
17936 <blockquote><pre>#include &lt;vector&gt;
17937 #include &lt;iostream&gt;
17938
17939 class Toto
17940 {
17941 public:
17942     Toto() {}
17943     explicit Toto( Toto const&amp; ) {}
17944 } ;
17945
17946 int
17947 main()
17948 {
17949     std::vector&lt; Toto &gt; v( 10 ) ;
17950     return 0 ;
17951 }
17952 </pre></blockquote>
17953
17954 <p>
17955 Is this change intentional?  (And if so, what is the
17956 justification?  I wouldn't call such code good, but I don't see
17957 any reason to break it unless we get something else in return.)
17958 </p>
17959
17960
17961
17962 <p><b>Proposed resolution:</b></p>
17963 <p>
17964 In 20.1.1 [utility.arg.requirements] change Table 33: <tt>MoveConstructible</tt> requirements [moveconstructible]:
17965 </p>
17966
17967 <blockquote>
17968 <table border="1">
17969 <tbody><tr>
17970 <th>expression</th><th>post-condition</th>
17971 </tr>
17972 <tr>
17973 <td><tt>T t<ins>(rv)</ins><del> = rv</del></tt></td><td><tt>t</tt> is equivalent to the value of <tt>rv</tt> before the construction</td>
17974 </tr>
17975 <tr>
17976 <td colspan="2" align="center">...</td>
17977 </tr>
17978 </tbody></table>
17979 </blockquote>
17980
17981 <p>
17982 In 20.1.1 [utility.arg.requirements] change Table 34: <tt>CopyConstructible</tt> requirements [copyconstructible]:
17983 </p>
17984
17985 <blockquote>
17986 <table border="1">
17987 <tbody><tr>
17988 <th>expression</th><th>post-condition</th>
17989 </tr>
17990 <tr>
17991 <td><tt>T t<ins>(u)</ins><del> = u</del></tt></td><td>the value of <tt>u</tt> is unchanged and is equivalent to <tt>t</tt></td>
17992 </tr>
17993 <tr>
17994 <td colspan="2" align="center">...</td>
17995 </tr>
17996 </tbody></table>
17997 </blockquote>
17998
17999
18000
18001
18002
18003 <hr>
18004 <h3><a name="823"></a>823. <tt>identity&lt;void&gt;</tt> seems broken</h3>
18005 <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#New">New</a>
18006  <b>Submitter:</b> Walter Brown <b>Date:</b> 2008-04-09</p>
18007 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forward">active issues</a> in [forward].</p>
18008 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward">issues</a> in [forward].</p>
18009 <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>
18010 <p><b>Discussion:</b></p>
18011 <p>
18012 N2588 seems to have added an <tt>operator()</tt> member function to the
18013 <tt>identity&lt;&gt;</tt> helper in 20.2.2 [forward].  I believe this change makes it no
18014 longer possible to instantiate <tt>identity&lt;void&gt;</tt>, as it would require
18015 forming a reference-to-<tt>void</tt> type as this <tt>operator()</tt>'s parameter type.
18016 </p>
18017
18018 <p>
18019 Suggested resolution:  Specialize <tt>identity&lt;void&gt;</tt> so as not to require
18020 the member function's presence.
18021 </p>
18022
18023
18024 <p><b>Proposed resolution:</b></p>
18025 <p>
18026 </p>
18027
18028
18029
18030
18031
18032 <hr>
18033 <h3><a name="824"></a>824. rvalue ref issue with <tt>basic_string</tt> inserter</h3>
18034 <p><b>Section:</b> 21.3.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
18035  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-04-10</p>
18036 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</p>
18037 <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>
18038 <p><b>Discussion:</b></p>
18039 <p>
18040 In the current working paper, the <tt>&lt;string&gt;</tt> header synopsis at the end of
18041 21.2 [string.classes] lists a single <tt>operator&lt;&lt;</tt> overload
18042 for <tt>basic_string</tt>.
18043 </p>
18044
18045 <blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
18046  basic_ostream&lt;charT, traits&gt;&amp;
18047    operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os,
18048               const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
18049 </pre></blockquote>
18050
18051 <p>
18052 The definition in 21.3.8.9 [string.io] lists two:
18053 </p>
18054
18055 <blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
18056  basic_ostream&lt;charT, traits&gt;&amp;
18057    operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os,
18058               const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
18059
18060 template&lt;class charT, class traits, class Allocator&gt;
18061  basic_ostream&lt;charT, traits&gt;&amp;
18062    operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os,
18063               const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
18064 </pre></blockquote>
18065
18066 <p>
18067 I believe the synopsis in 21.2 [string.classes] is correct, and the first of the two
18068 signatures in 21.3.8.9 [string.io] should be deleted.
18069 </p>
18070
18071
18072 <p><b>Proposed resolution:</b></p>
18073 <p>
18074 </p>
18075
18076
18077
18078
18079
18080 <hr>
18081 <h3><a name="825"></a>825. Missing rvalues reference stream insert/extract operators?</h3>
18082 <p><b>Section:</b> 19.4.2.1 [syserr.errcode.overview], 20.6.12.2.8
18083 [util.smartptr.shared.io], 22.2.8 [facets.examples], 23.3.5.3
18084 [bitset.operators], 26.3.6 [complex.ops], 27.5 [stream.buffers], 28.9
18085 [re.submatch] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
18086  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-04-10</p>
18087 <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>
18088 <p><b>Discussion:</b></p>
18089 <p>
18090 Should the following use rvalues references to stream in insert/extract
18091 operators?
18092 </p>
18093
18094 <ul>
18095 <li>19.4.2.1 [syserr.errcode.overview]</li>
18096 <li>20.6.12.2.8 [util.smartptr.shared.io]</li>
18097 <li>22.2.8 [facets.examples]</li>
18098 <li>23.3.5.3 [bitset.operators]</li>
18099 <li>26.3.6 [complex.ops]</li>
18100 <li>Doubled signatures in 27.5 [stream.buffers] for character inserters
18101 (ref 27.6.2.6.4 [ostream.inserters.character])
18102 + definition 27.6.2.6.4 [ostream.inserters.character]</li>
18103 <li>28.9 [re.submatch]</li>
18104 </ul>
18105
18106
18107 <p><b>Proposed resolution:</b></p>
18108 <p>
18109 </p>
18110
18111
18112
18113
18114
18115 <hr>
18116 <h3><a name="826"></a>826. Equivalent of <tt>%'d</tt>, or rather, lack thereof?</h3>
18117 <p><b>Section:</b> 22.2.2.2 [locale.nm.put] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
18118  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-04-07</p>
18119 <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>
18120 <p><b>Discussion:</b></p>
18121 <p>
18122 In the spirit of <tt>printf vs iostream</tt>...
18123 </p>
18124
18125 <p>
18126 POSIX <tt>printf</tt> says that <tt>%'d</tt> should insert grouping characters (and the
18127 implication is that in the absence of <tt>'</tt> no grouping characters are
18128 inserted). The <tt>num_put</tt> facet, on the other hand, seems to always insert
18129 grouping characters. Can this be considered a defect worth fixing for
18130 C++0x? Maybe <tt>ios_base</tt> needs an additional flag?
18131 </p>
18132
18133 <p><i>[
18134 Pablo Halpern:
18135 ]</i></p>
18136
18137
18138 <blockquote>
18139 I'm not sure it constitutes a defect, but I would be in favor of adding
18140 another flag (and corresponding manipulator).
18141 </blockquote>
18142
18143 <p><i>[
18144 Martin Sebor:
18145 ]</i></p>
18146
18147
18148 <blockquote>
18149 I don't know if it qualifies as a defect but I agree that there
18150 should be an easy way to control whether the thousands separator
18151 should or shouldn't be inserted. A new flag would be in line with
18152 the current design of iostreams (like <tt>boolalpha</tt>, <tt>showpos</tt>, or
18153 <tt>showbase</tt>).
18154 </blockquote>
18155
18156
18157 <p><b>Proposed resolution:</b></p>
18158 <p>
18159 </p>
18160
18161
18162
18163
18164
18165 <hr>
18166 <h3><a name="827"></a>827. <tt>constexpr shared_ptr::shared_ptr()?</tt></h3>
18167 <p><b>Section:</b> 20.6.12.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
18168  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-04-11</p>
18169 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
18170 <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>
18171 <p><b>Discussion:</b></p>
18172 <p>
18173 Would anyone object to making the default constructor of <tt>shared_ptr</tt> (and
18174 <tt>weak_ptr</tt> and <tt>enable_shared_from_this) constexpr</tt>? This would enable
18175 static initialization for <tt>shared_ptr</tt> variables, eliminating another
18176 unfair advantage of raw pointers.
18177 </p>
18178
18179
18180 <p><b>Proposed resolution:</b></p>
18181 <p>
18182 </p>
18183
18184
18185
18186
18187
18188 <hr>
18189 <h3><a name="828"></a>828. Static initialization for <tt>std::mutex</tt>?</h3>
18190 <p><b>Section:</b> 30.3.1.1 [thread.mutex.class] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
18191  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-04-18</p>
18192 <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>
18193 <p><b>Discussion:</b></p>
18194 <p>
18195 [Note: I'm assuming here that 3.6.2 [basic.start.init]/1 will be fixed.]
18196 </p>
18197 <p>
18198 Currently <tt>std::mutex</tt> doesn't support static initialization. This is a
18199 regression with respect to <tt>pthread_mutex_t</tt>, which does. I believe that
18200 we should strive to eliminate such regressions in expressive power where
18201 possible, both to ease migration and to not provide incentives to (or
18202 force) people to forego the C++ primitives in favor of pthreads.
18203 </p>
18204
18205
18206 <p><b>Proposed resolution:</b></p>
18207 <p>
18208 </p>
18209
18210
18211
18212
18213
18214 <hr>
18215 <h3><a name="829"></a>829. current_exception wording unclear about exception type</h3>
18216 <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>
18217  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-04-20</p>
18218 <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>
18219 <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>
18220 <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>
18221 <p><b>Discussion:</b></p>
18222 <p>Consider this code:</p>
18223
18224 <blockquote>
18225 <pre>exception_ptr xp;</pre>
18226 <pre>try {do_something(); }
18227
18228 catch (const runtime_error&amp; ) {xp = current_exception();}
18229
18230 ...
18231
18232 rethrow_exception(xp);</pre>
18233 </blockquote>
18234
18235 <p>
18236 Say <code>do_something()</code> throws an exception object of type <code>
18237 range_error</code>. What is the type of the exception object thrown by <code>
18238 rethrow_exception(xp)</code> above? It must have a type of <code>range_error</code>;
18239 if it were of type <code>runtime_error</code> it still isn't possible to
18240 propagate an exception and the exception_ptr/current_exception/rethrow_exception
18241 machinery serves no useful purpose.
18242 </p>
18243
18244 <p>
18245 Unfortunately, the current wording does not explicitly say that. Different
18246 people read the current wording and come to different conclusions. While it may
18247 be possible to deduce the correct type from the current wording, it would be
18248 much clearer to come right out and explicitly say what the type of the referred
18249 to exception is.
18250 </p>
18251
18252 <p><i>[
18253 Peter adds:
18254 ]</i></p>
18255
18256
18257 <blockquote>
18258 <p>
18259 I don't like the proposed resolution of 829. The normative text is
18260 unambiguous that the <tt>exception_ptr</tt> refers to the <em>currently handled
18261 exception</em>. This term has a standard meaning, see 15.3 [except.handle]/8; this is the
18262 exception that <tt>throw;</tt> would rethrow, see 15.1 [except.throw]/7.
18263 </p>
18264 <p>
18265 A better way to address this is to simply add the non-normative example
18266 in question as a clarification. The term <i>currently handled exception</i>
18267 should be italicized and cross-referenced. A [<i>Note:</i> the currently
18268 handled exception is the exception that a throw expression without an
18269 operand (15.1 [except.throw]/7) would rethrow. <i>--end note</i>] is also an option.
18270 </p>
18271 </blockquote>
18272
18273
18274
18275 <p><b>Proposed resolution:</b></p>
18276
18277 <p>
18278 After 18.7.5 [propagation] , paragraph 7, add the indicated text:
18279 </p>
18280
18281 <blockquote>
18282 <pre>exception_ptr current_exception();</pre>
18283
18284 <blockquote>
18285 <p>
18286 <i>Returns:</i> <code>exception_ptr</code> object that refers
18287 to the currently handled exception or a copy of the currently handled
18288 exception, or a null <code>exception_ptr</code> object if no exception is being handled. If
18289 the function needs to allocate memory and the attempt fails, it returns an
18290 <code>exception_ptr</code> object that refers to an instance of <code>bad_alloc</code>.
18291 It is unspecified whether the return values of two successive calls to
18292 <code>current_exception</code> refer to the same exception object.
18293 [<i>Note:</i> that is, it
18294 is unspecified whether <code>current_exception</code>
18295 creates a new copy each time it is called.
18296 <i>-- end note</i>]
18297 </p>
18298
18299 <p>
18300 <ins><i>Remarks:</i> The type of the exception object
18301 referred to by the returned <code>exception_ptr</code> is the most-derived
18302 type of the currently handled exception.</ins>
18303 </p>
18304
18305 <p>
18306 <i>Throws:</i> nothing.
18307 </p>
18308
18309 </blockquote>
18310 </blockquote>
18311
18312
18313
18314
18315
18316
18317 <hr>
18318 <h3><a name="830"></a>830. Incomplete list of char_traits specializations</h3>
18319 <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#New">New</a>
18320  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2008-04-23</p>
18321 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#char.traits">active issues</a> in [char.traits].</p>
18322 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits">issues</a> in [char.traits].</p>
18323 <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>
18324 <p><b>Discussion:</b></p>
18325 <p>
18326   Paragraph 4 of 21.1 [char.traits] mentions that this
18327   section specifies two specializations (<code>char_traits&lt;char&gt;</code>
18328   and (<code>char_traits&lt;wchar_t&gt;</code>). However, there are actually
18329   four specializations provided, i.e. in addition to the two above also
18330   <code>char_traits&lt;char16_t&gt;</code> and <code>char_traits&lt;char32_t&gt;</code>).
18331   I guess this was just an oversight and there is nothing wrong with just
18332   fixing this.
18333 </p>
18334
18335 <p><i>[
18336 Alisdair adds:
18337 ]</i></p>
18338
18339 <blockquote>
18340 <tt>char_traits&lt; char16/32_t &gt;</tt>
18341 should also be added to <tt>&lt;ios_fwd&gt;</tt> in 27.2 [iostream.forward], and all the specializations
18342 taking a <tt>char_traits</tt> parameter in that header.
18343 </blockquote>
18344
18345
18346 <p><b>Proposed resolution:</b></p>
18347 <p>
18348   Replace paragraph 4 of 21.1 [char.traits] by:
18349 </p>
18350 <blockquote>
18351 <p>
18352   This subclause specifies a struct template, <code>char_traits&lt;charT&gt;</code>,
18353   and four explicit specializations of it, <code>char_traits&lt;char&gt;</code>,
18354   <code>char_traits&lt;char16_t&gt;</code>, <code>char_traits&lt;char32_t&gt;</code>, and
18355   <code>char_traits&lt;wchar_t&gt;</code>, all of which appear in the header
18356   &lt;string&gt; and satisfy the requirements below.
18357 </p>
18358 </blockquote>
18359
18360
18361
18362
18363
18364 <hr>
18365 <h3><a name="831"></a>831. wrong type for not_eof()</h3>
18366 <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>
18367  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2008-04-23</p>
18368 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits.specializations">issues</a> in [char.traits.specializations].</p>
18369 <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>
18370 <p><b>Discussion:</b></p>
18371 <p>
18372   In Table 56 (Traits requirements) the <tt>not_eof()</tt> member function
18373   is using an argument of type <i>e</i> which denotes an object of
18374   type <code>X::int_type</code>. However, the specializations in
18375   21.1.3 [char.traits.specializations] all use <code>char_type</code>.
18376   This would effectively mean that the argument type actually can't
18377   represent EOF in the first place. I'm pretty sure that the type used
18378   to be <code>int_type</code> which is quite obviously the only sensible
18379   argument.
18380 </p>
18381 <p>
18382   This issue is close to being editorial. I suspect that the proposal
18383   changing this section to include the specializations for <code>char16_t</code>
18384   and <code>char32_t</code> accidentally used the wrong type.
18385 </p>
18386
18387
18388 <p><b>Proposed resolution:</b></p>
18389 <p>
18390   In 21.1.3.1 [char.traits.specializations.char],
18391   21.1.3.2 [char.traits.specializations.char16_t],
18392   21.1.3.3 [char.traits.specializations.char32_t], and
18393    [char.traits.specializations.wchar_t] correct the
18394   argument type from <code>char_type</code> to <code>int_type</code>.
18395 </p>
18396
18397
18398
18399
18400
18401 <hr>
18402 <h3><a name="832"></a>832. Applying constexpr to System error support</h3>
18403 <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>
18404  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-05-14</p>
18405 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#syserr">active issues</a> in [syserr].</p>
18406 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p>
18407 <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>
18408 <p><b>Discussion:</b></p>
18409 <p>
18410 Initialization of objects of class <tt>error_code</tt>
18411 (19.4.2 [syserr.errcode]) and class
18412 <tt>error_condition</tt> (19.4.3 [syserr.errcondition]) can be made simpler and more reliable by use of
18413 the new <tt>constexpr</tt> feature
18414 [<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2349.pdf">N2349</a>]
18415 of C++0x. Less code will need to be
18416 generated for both library implementations and user programs when
18417 manipulating constant objects of these types.
18418 </p>
18419
18420 <p>
18421 This was not proposed originally because the constant expressions
18422 proposal was moving into the standard at about the same time as the
18423 Diagnostics Enhancements proposal
18424 [<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html">N2241</a>],
18425 and it wasn't desirable to
18426 make the later depend on the former. There were also technical concerns
18427 as to how <tt>constexpr</tt> would apply to references. Those concerns are now
18428 resolved; <tt>constexpr</tt> can't be used for references, and that fact is
18429 reflected in the proposed resolution.
18430 </p>
18431
18432 <p>
18433 Thanks to Jens Maurer, Gabriel Dos Reis, and Bjarne Stroustrup for clarification of <tt>constexpr</tt> requirements.
18434 </p>
18435
18436 <p>
18437 LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a> is related in that it raises the question of whether the
18438 exposition only member <tt>cat_</tt> of class <tt>error_code</tt> (19.4.2 [syserr.errcode]) and class
18439 <tt>error_condition</tt> (19.4.3 [syserr.errcondition]) should be presented as a reference or pointer.
18440 While in the context of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a> that is arguably an editorial question,
18441 presenting it as a pointer becomes more or less required with this
18442 proposal, given <tt>constexpr</tt> does not play well with references. The
18443 proposed resolution thus changes the private member to a pointer, which
18444 also brings it in sync with real implementations.
18445 </p>
18446
18447
18448 <p><b>Proposed resolution:</b></p>
18449 <p>
18450 The proposed wording assumes the LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a> proposed wording has been
18451 applied to the WP, resulting in the former <tt>posix_category</tt> being renamed
18452 <tt>generic_category</tt>. If <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a> has not been applied, the names in this
18453 proposal must be adjusted accordingly.
18454 </p>
18455
18456 <p>
18457 Change 19.4.1.1 [syserr.errcat.overview] Class
18458 <tt>error_category</tt> overview <tt>error_category</tt> synopsis  as
18459 indicated:
18460 </p>
18461
18462 <blockquote><pre><del>const error_category&amp; get_generic_category();</del>
18463 <del>const error_category&amp; get_system_category();</del>
18464
18465 <del>static</del> <ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> generic_category<del> = get_generic_category()</del>;
18466 <del>static</del> <ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> <del>native_category</del> system_category<del> = get_system_category()</del>;
18467 </pre></blockquote>
18468
18469 <p>
18470 Change 19.4.1.5 [syserr.errcat.objects] Error category objects as indicated:
18471 </p>
18472
18473 <blockquote>
18474 <pre><ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> <del>get_</del>generic_category<del>()</del>;
18475 </pre>
18476 <p>
18477 <del><i>Returns:</i> A reference</del> <ins><tt>generic_category</tt> shall point</ins>
18478 to <del>an</del> <ins>a statically initialized</ins> object of a type derived from
18479 class <tt>error_category</tt>.
18480 </p>
18481
18482 <p>
18483 <del><i>Remarks:</i></del> The object's <tt>default_error_condition</tt> and <tt>equivalent</tt> virtual
18484 functions shall behave as specified for the class <tt>error_category</tt>. The
18485 object's <tt>name</tt> virtual function shall return a pointer to the string
18486 <tt>"GENERIC"</tt>.
18487 </p>
18488
18489 <pre><ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> <del>get_</del>system_category<del>()</del>;
18490 </pre>
18491
18492 <p>
18493 <del><i>Returns:</i> A reference</del> <ins><tt>system_category</tt> shall point</ins>
18494 to <del>an</del> <ins>a statically
18495 initialized</ins> object of a type derived from class <tt>error_category</tt>.
18496 </p>
18497
18498 <p>
18499 <del><i>Remarks:</i></del>  The object's <tt>equivalent</tt> virtual functions shall behave as
18500 specified for class <tt>error_category</tt>. The object's <tt>name</tt> virtual function
18501 shall return a pointer to the string <tt>"system"</tt>. The object's
18502 <tt>default_error_condition</tt> virtual function shall behave as follows:
18503 </p>
18504
18505 <p>
18506 If the argument <tt>ev</tt> corresponds to a POSIX <tt>errno</tt> value <tt>posv</tt>, the function
18507 shall return <tt>error_condition(posv, generic_category)</tt>. Otherwise, the
18508 function shall return <tt>error_condition(ev, system_category)</tt>. What
18509 constitutes correspondence for any given operating system is
18510 unspecified. [<i>Note:</i> The number of potential system error codes is large
18511 and unbounded, and some may not correspond to any POSIX <tt>errno</tt> value.
18512 Thus implementations are given latitude in determining correspondence.
18513 <i>-- end note</i>]
18514 </p>
18515 </blockquote>
18516
18517 <p>
18518 Change 19.4.2.1 [syserr.errcode.overview] Class <tt>error_code</tt> overview as indicated:
18519 </p>
18520
18521 <blockquote><pre>class error_code {
18522 public:
18523   ...;
18524   <ins>constexpr</ins> error_code(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
18525   ...
18526   void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
18527   ...
18528   const error_category<del>&amp;</del><ins>*</ins> category() const;
18529   ...
18530 private:
18531   int val_;                    // exposition only
18532   const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
18533 </pre></blockquote>
18534
18535 <p>
18536 Change 19.4.2.2 [syserr.errcode.constructors] Class <tt>error_code</tt> constructors as indicated:
18537 </p>
18538
18539 <blockquote>
18540 <pre><ins>constexpr</ins> error_code(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
18541 </pre>
18542 <p>
18543 <i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
18544 </p>
18545 <p>
18546 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
18547 </p>
18548 <p>
18549 <i>Throws:</i> Nothing.
18550 </p>
18551 </blockquote>
18552
18553 <p>
18554 Change 19.4.2.3 [syserr.errcode.modifiers] Class <tt>error_code</tt> modifiers  as indicated:
18555 </p>
18556
18557 <blockquote>
18558 <pre>void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
18559 </pre>
18560 <p>
18561 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
18562 </p>
18563 <p>
18564 <i>Throws:</i> Nothing.
18565 </p>
18566 </blockquote>
18567
18568 <p>
18569 Change 19.4.2.4 [syserr.errcode.observers] Class <tt>error_code</tt> observers  as indicated:
18570 </p>
18571
18572 <blockquote>
18573 <pre>const error_category<del>&amp;</del><ins>*</ins> category() const;
18574 </pre>
18575
18576 <p>
18577 <i>Returns:</i> <tt>cat_</tt>.
18578 </p>
18579 <p>
18580 <i>Throws:</i> Nothing.
18581 </p>
18582 </blockquote>
18583
18584 <p>
18585 Change 19.4.3.1 [syserr.errcondition.overview] Class <tt>error_condition</tt> overview   as indicated:
18586 </p>
18587
18588 <blockquote>
18589 <pre>class error_condition {
18590 public:
18591   ...;
18592   <ins>constexpr</ins> error_condition(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
18593   ...
18594   void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
18595   ...
18596   const error_category<del>&amp;</del><ins>*</ins> category() const;
18597   ...
18598 private:
18599   int val_;                    // exposition only
18600   const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
18601 </pre>
18602 </blockquote>
18603
18604 <p>
18605 Change 19.4.3.2 [syserr.errcondition.constructors] Class <tt>error_condition</tt> constructors as indicated:
18606 </p>
18607
18608 <blockquote>
18609 <pre>constexpr error_condition(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
18610 </pre>
18611 <p>
18612 <i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
18613 </p>
18614 <p>
18615 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
18616 </p>
18617 <p>
18618 <i>Throws:</i> Nothing.
18619 </p>
18620 </blockquote>
18621
18622 <p>
18623 Change 19.4.3.3 [syserr.errcondition.modifiers] Class <tt>error_condition</tt> modifiers as indicated:
18624 </p>
18625
18626 <blockquote>
18627 <pre>void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
18628 </pre>
18629 <p>
18630 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
18631 </p>
18632 <p>
18633 <i>Throws:</i> Nothing.
18634 </p>
18635 </blockquote>
18636
18637 <p>
18638 Change 19.4.3.4 [syserr.errcondition.observers] Class <tt>error_condition</tt> observers as indicated:
18639 </p>
18640
18641 <blockquote>
18642 <pre>const error_category<del>&amp;</del><ins>*</ins> category() const;
18643 </pre>
18644 <p>
18645 <i>Returns:</i> <tt>cat_</tt>.
18646 </p>
18647 <p>
18648 <i>Throws:</i> Nothing.
18649 </p>
18650 </blockquote>
18651
18652 <p>
18653 Throughout 19.4 [syserr] System error support, change "<tt>category().</tt>"  to "<tt>category()-&gt;</tt>".
18654 Appears approximately six times.
18655 </p>
18656
18657 <p>
18658 <i>[Partially Editorial]</i> In 19.4.4 [syserr.compare] Comparison operators,
18659 paragraphs 2 and 4, change "<tt>category.equivalent(</tt>"  to
18660 "<tt>category()-&gt;equivalent(</tt>".
18661 </p>
18662
18663
18664
18665
18666
18667 <hr>
18668 <h3><a name="833"></a>833. Freestanding implementations header list needs review for C++0x</h3>
18669 <p><b>Section:</b> 17.4.1.3 [compliance] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
18670  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-05-14</p>
18671 <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>
18672 <p><b>Discussion:</b></p>
18673 <p>
18674 Once the C++0x standard library is feature complete, the LWG needs to
18675 review 17.4.1.3 [compliance] Freestanding implementations header list to
18676 ensure it reflects LWG consensus.
18677 </p>
18678
18679
18680 <p><b>Proposed resolution:</b></p>
18681
18682
18683
18684
18685
18686 <hr>
18687 <h3><a name="834"></a>834. Unique_ptr::pointer requirements underspecified</h3>
18688 <p><b>Section:</b> 20.6.11.2 [unique.ptr.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
18689  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-05-14</p>
18690 <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>
18691 <p><b>Discussion:</b></p>
18692 <p>
18693 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a> (including recent updates by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#821">821</a>) proposes a useful
18694 extension point for <tt>unique_ptr</tt> by granting support for an optional
18695 <tt>deleter_type::pointer</tt> to act as pointer-like replacement for <tt>element_type*</tt>
18696 (In the following: <tt>pointer</tt>).
18697 </p>
18698 <p>
18699 Unfortunately no requirements are specified for the type <tt>pointer</tt> which has
18700 impact on at least two key features of <tt>unique_ptr</tt>:
18701 </p>
18702
18703 <ol>
18704 <li>Operational fail-safety.</li>
18705 <li>(Well-)Definedness of expressions.</li>
18706 </ol>
18707
18708 <p>
18709 <tt>Unique_ptr</tt> specification makes great efforts to require that essentially *all*
18710 operations cannot throw and therefore adds proper wording to the affected
18711 operations of the deleter as well. If user-provided <tt>pointer</tt>-emulating types
18712 ("smart pointers") will be allowed, either *all* throw-nothing clauses have to
18713 be replaced by weaker "An exception is thrown only if <tt>pointer</tt>'s {op} throws
18714 an exception"-clauses or it has to be said explicitly that all used
18715 operations of
18716 <tt>pointer</tt> are required *not* to throw. I understand the main focus of <tt>unique_ptr</tt>
18717 to be as near as possible to the advantages of native pointers which cannot
18718 fail and thus strongly favor the second choice. Also, the alternative position
18719 would make it much harder to write safe and simple template code for
18720 <tt>unique_ptr</tt>. Additionally, I assume that a general statement need to be given
18721 that all of the expressions of <tt>pointer</tt> used to define semantics are required to
18722 be well-formed and well-defined (also as back-end for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>).
18723 </p>
18724
18725
18726 <p><b>Proposed resolution:</b></p>
18727 <p>
18728 Add the following sentence just at the end of the newly proposed
18729 20.6.11.2 [unique.ptr.single]/p. 3:
18730 </p>
18731
18732 <blockquote>
18733 <tt>unique_ptr&lt;T, D&gt;::pointer</tt>'s operations shall be well-formed, shall have well
18734 defined behavior, and shall not throw exceptions.
18735 </blockquote>
18736
18737
18738
18739
18740
18741 <hr>
18742 <h3><a name="835"></a>835. tying two streams together (correction to DR 581)</h3>
18743 <p><b>Section:</b> 27.4.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
18744  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
18745 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p>
18746 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
18747 <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>
18748 <p><b>Discussion:</b></p>
18749        <p>
18750
18751 The fix for
18752 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>,
18753 now integrated into the working paper, overlooks a couple of minor
18754 problems.
18755
18756        </p>
18757        <p>
18758
18759 First, being an unformatted function once again, <code>flush()</code>
18760 is required to create a sentry object whose constructor must, among
18761 other things, flush the tied stream. When two streams are tied
18762 together, either directly or through another intermediate stream
18763 object, flushing one will also cause a call to <code>flush()</code> on
18764 the other tied stream(s) and vice versa, ad infinitum. The program
18765 below demonstrates the problem.
18766
18767        </p>
18768        <p>
18769
18770 Second, as Bo Persson notes in his
18771 comp.lang.c++.moderated <a href="http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/f2187794e9cc036d/305df31dc583054a">post</a>,
18772 for streams with the <code>unitbuf</code> flag set such
18773 as <code>std::stderr</code>, the destructor of the sentry object will
18774 again call <code>flush()</code>. This seems to create an infinite
18775 recursion for <code>std::cerr &lt;&lt; std::flush;</code>
18776
18777        </p>
18778        <blockquote>
18779            <pre>#include &lt;iostream&gt;
18780
18781 int main ()
18782 {
18783    std::cout.tie (&amp;std::cerr);
18784    std::cerr.tie (&amp;std::cout);
18785    std::cout &lt;&lt; "cout\n";
18786    std::cerr &lt;&lt; "cerr\n";
18787 }
18788            </pre>
18789        </blockquote>
18790
18791    <p><b>Proposed resolution:</b></p>
18792        <p>
18793
18794 I think an easy way to plug the first hole is to add a requires clause
18795 to <code>ostream::tie(ostream *tiestr)</code> requiring the this
18796 pointer not be equal to any pointer on the list starting
18797 with <code>tiestr-&gt;tie()</code>
18798 through <code>tiestr()-&gt;tie()-&gt;tie()</code> and so on. I am not
18799 proposing that we require implementations to traverse this list,
18800 although I think we could since the list is unlikely to be very long.
18801
18802        </p>
18803        <p>
18804
18805 Add a <i>Requires</i> clause to 27.4.4.2 [basic.ios.members] withethe following
18806 text:
18807
18808        </p>
18809        <blockquote>
18810
18811 <i>Requires:</i> If <code>(tiestr != 0)</code> is
18812 true, <code>tiestr</code> must not be reachable by traversing the
18813 linked list of tied stream objects starting
18814 from <code>tiestr-&gt;tie()</code>.
18815
18816        </blockquote>
18817        <p>
18818
18819 In addition, to prevent the infinite recursion that Bo writes about in
18820 his comp.lang.c++.moderated post, I propose to change
18821 27.6.2.4 [ostream::sentry], p2 like so:
18822
18823        </p>
18824        <blockquote>
18825
18826 If <code>((os.flags() &amp; ios_base::unitbuf) &amp;&amp;
18827 !uncaught_exception())</code> is true,
18828 calls <del>os.flush()</del> <ins><code>os.rdbuf()-&gt;pubsync()</code></ins>.
18829
18830        </blockquote>
18831
18832
18833
18834
18835 <hr>
18836 <h3><a name="836"></a>836.
18837        effects of <code>money_base::space</code> and
18838        <code>money_base::none</code> on <code>money_get</code>
18839    </h3>
18840 <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#New">New</a>
18841  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
18842 <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>
18843 <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>
18844 <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>
18845 <p><b>Discussion:</b></p>
18846        <p>
18847
18848 In paragraph 2, 22.2.6.1.2 [locale.money.get.virtuals] specifies the following:
18849
18850        </p>
18851        <blockquote>
18852
18853 Where <code>space</code> or <code>none</code> appears in the format
18854 pattern, except at the end, optional white space (as recognized
18855 by <code>ct.is</code>) is consumed after any required space.
18856
18857        </blockquote>
18858        <p>
18859
18860 This requirement can be (and has been) interpreted two mutually
18861 exclusive ways by different readers. One possible interpretation
18862 is that:
18863
18864        </p>
18865        <blockquote>
18866            <ol>
18867                <li>
18868
18869 where <code>money_base::space</code> appears in the format, at least
18870 one space is required, and
18871
18872                </li>
18873                <li>
18874
18875 where <code>money_base::none</code> appears in the format, space is
18876 allowed but not required.
18877
18878                </li>
18879            </ol>
18880        </blockquote>
18881        <p>
18882
18883 The other is that:
18884
18885        </p>
18886        <blockquote>
18887
18888 where either <code>money_base::space</code> or <code>money_base::none</code> appears in the format, white space is optional.
18889
18890        </blockquote>
18891
18892
18893    <p><b>Proposed resolution:</b></p>
18894        <p>
18895
18896 I propose to change the text to make it clear that the first
18897 interpretation is intended, that is, to make following change to
18898 22.2.6.1.2 [locale.money.get.virtuals], p2:
18899
18900        </p>
18901
18902        <blockquote>
18903
18904 When <code><ins>money_base::</ins>space</code>
18905 or <code><ins>money_base::</ins>none</code> appears <ins>as the last
18906 element </ins>in the format pattern, <del>except at the end, optional
18907 white space (as recognized by <code>ct.is</code>) is consumed after
18908 any required space.</del> <ins>no white space is consumed. Otherwise,
18909 where <code>money_base::space</code> appears in any of the initial
18910 elements of the format pattern, at least one white space character is
18911 required. Where <code>money_base::none</code> appears in any of the
18912 initial elements of the format pattern, white space is allowed but not
18913 required. In either case, any required followed by all optional white
18914 space (as recognized by <code>ct.is()</code>) is consumed.</ins>
18915 If <code>(str.flags() &amp; str.showbase)</code> is <code>false</code>, ...
18916
18917        </blockquote>
18918
18919
18920
18921
18922 <hr>
18923 <h3><a name="837"></a>837.
18924    <code>basic_ios::copyfmt()</code> overly loosely specified
18925  </h3>
18926 <p><b>Section:</b> 27.4.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
18927  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
18928 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p>
18929 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
18930 <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>
18931 <p><b>Discussion:</b></p>
18932    <p>
18933
18934 The <code>basic_ios::copyfmt()</code> member function is specified in 27.4.4.2 [basic.ios.members] to have the following effects:
18935
18936    </p>
18937    <blockquote>
18938
18939 <i>Effects</i>: If <code>(this == &amp;rhs)</code> does
18940 nothing. Otherwise assigns to the member objects of <code>*this</code>
18941 the corresponding member objects of <code>rhs</code>, except that
18942
18943      <ul>
18944        <li>
18945
18946 <code>rdstate()</code> and <code>rdbuf()</code> are left unchanged;
18947
18948        </li>
18949        <li>
18950
18951 <code>exceptions()</code> is altered last by
18952 calling <code>exceptions(rhs.except)</code>
18953
18954        </li>
18955        <li>
18956
18957 the contents of arrays pointed at by <code>pword</code>
18958 and <code>iword</code> are copied not the pointers themselves
18959
18960        </li>
18961      </ul>
18962    </blockquote>
18963    <p>
18964
18965 Since the rest of the text doesn't specify what the member objects
18966 of <code>basic_ios</code> are this seems a little too loose.
18967
18968    </p>
18969
18970
18971  <p><b>Proposed resolution:</b></p>
18972    <p>
18973
18974 I propose to tighten things up by adding a <i>Postcondition</i> clause
18975 to the function like so:
18976
18977    </p>
18978    <blockquote>
18979      <i>Postconditions:</i>
18980
18981      <table border="1">
18982        <thead>
18983          <tr>
18984            <th colspan="2"><code>copyfmt()</code> postconditions</th>
18985          </tr>
18986          <tr>
18987            <th>Element</th>
18988            <th>Value</th>
18989          </tr>
18990        </thead>
18991        <tbody>
18992          <tr>
18993            <td><code>rdbuf()</code></td>
18994            <td><i>unchanged</i></td>
18995          </tr>
18996          <tr>
18997            <td><code>tie()</code></td>
18998            <td><code>rhs.tie()</code></td>
18999          </tr>
19000          <tr>
19001            <td><code>rdstate()</code></td>
19002            <td><i>unchanged</i></td>
19003          </tr>
19004          <tr>
19005            <td><code>exceptions()</code></td>
19006            <td><code>rhs.exceptions()</code></td>
19007          </tr>
19008          <tr>
19009            <td><code>flags()</code></td>
19010            <td><code>rhs.flags()</code></td>
19011          </tr>
19012          <tr>
19013            <td><code>width()</code></td>
19014            <td><code>rhs.width()</code></td>
19015          </tr>
19016          <tr>
19017            <td><code>precision()</code></td>
19018            <td><code>rhs.precision()</code></td>
19019          </tr>
19020          <tr>
19021            <td><code>fill()</code></td>
19022            <td><code>rhs.fill()</code></td>
19023          </tr>
19024          <tr>
19025            <td><code>getloc()</code></td>
19026            <td><code>rhs.getloc()</code></td>
19027          </tr>
19028        </tbody>
19029      </table>
19030    </blockquote>
19031    <p>
19032
19033 The format of the table follows Table 117 (as
19034 of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2588.pdf">N2588</a>): <code>basic_ios::init()</code>
19035 effects.
19036
19037    </p>
19038    <p>
19039
19040 The intent of the new table is not to impose any new requirements or
19041 change existing ones, just to be more explicit about what I believe is
19042 already there.
19043
19044    </p>
19045
19046
19047
19048
19049 <hr>
19050 <h3><a name="838"></a>838.
19051    can an <i>end-of-stream</i> iterator become a <i>non-end-of-stream</i> one?
19052  </h3>
19053 <p><b>Section:</b> 24.5.1 [istream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
19054  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
19055 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.iterator">active issues</a> in [istream.iterator].</p>
19056 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator">issues</a> in [istream.iterator].</p>
19057 <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>
19058 <p><b>Discussion:</b></p>
19059    <p>
19060
19061 From message c++std-lib-20003...
19062
19063    </p>
19064    <p>
19065
19066 The description of <code>istream_iterator</code> in
19067 24.5.1 [istream.iterator], p1 specifies that objects of the
19068 class become the <i>end-of-stream</i> (EOS) iterators under the
19069 following condition (see also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a> another problem
19070 with this paragraph):
19071
19072    </p>
19073    <blockquote>
19074
19075 If the end of stream is reached (<code>operator void*()</code> on the
19076 stream returns <code>false</code>), the iterator becomes equal to
19077 the <i>end-of-stream</i> iterator value.
19078
19079    </blockquote>
19080    <p>
19081
19082 One possible implementation approach that has been used in practice is
19083 for the iterator to set its <code>in_stream</code> pointer to 0 when
19084 it reaches the end of the stream, just like the default ctor does on
19085 initialization. The problem with this approach is that
19086 the <i>Effects</i> clause for <code>operator++()</code> says the
19087 iterator unconditionally extracts the next value from the stream by
19088 evaluating <code>*in_stream &gt;&gt; value</code>, without checking
19089 for <code>(in_stream == 0)</code>.
19090
19091    </p>
19092    <p>
19093
19094 Conformance to the requirement outlined in the <i>Effects</i> clause
19095 can easily be verified in programs by setting <code>eofbit</code>
19096 or <code>failbit</code> in <code>exceptions()</code> of the associated
19097 stream and attempting to iterate past the end of the stream: each
19098 past-the-end access should trigger an exception. This suggests that
19099 some other, more elaborate technique might be intended.
19100
19101    </p>
19102    <p>
19103
19104 Another approach, one that allows <code>operator++()</code> to attempt
19105 to extract the value even for EOS iterators (just as long
19106 as <code>in_stream</code> is non-0) is for the iterator to maintain a
19107 flag indicating whether it has reached the end of the stream. This
19108 technique would satisfy the presumed requirement implied by
19109 the <i>Effects</i> clause mentioned above, but it isn't supported by
19110 the exposition-only members of the class (no such flag is shown). This
19111 approach is also found in existing practice.
19112
19113    </p>
19114    <p>
19115
19116 The inconsistency between existing implementations raises the question
19117 of whether the intent of the specification is that a non-EOS iterator
19118 that has reached the EOS become a non-EOS one again after the
19119 stream's <code>eofbit</code> flag has been cleared? That is, are the
19120 assertions in the program below expected to pass?
19121
19122    </p>
19123    <blockquote>
19124      <pre>   sstream strm ("1 ");
19125    istream_iterator eos;
19126    istream_iterator it (strm);
19127    int i;
19128    i = *it++
19129    assert (it == eos);
19130    strm.clear ();
19131    strm &lt;&lt; "2 3 ";
19132    assert (it != eos);
19133    i = *++it;
19134    assert (3 == i);
19135      </pre>
19136    </blockquote>
19137    <p>
19138
19139 Or is it intended that once an iterator becomes EOS it stays EOS until
19140 the end of its lifetime?
19141
19142    </p>
19143
19144
19145  <p><b>Proposed resolution:</b></p>
19146    <p>
19147
19148 The discussion of this issue on the reflector suggests that the intent
19149 of the standard is for an <code>istreambuf_iterator</code> that has
19150 reached the EOS to remain in the EOS state until the end of its
19151 lifetime. Implementations that permit EOS iterators to return to a
19152 non-EOS state may only do so as an extension, and only as a result of
19153 calling <code>istream_iterator</code> member functions on EOS
19154 iterators whose behavior is in this case undefined.
19155
19156    </p>
19157    <p>
19158
19159 To this end we propose to change 24.5.1 [istream.iterator], p1,
19160 as follows:
19161
19162    </p>
19163    <blockquote>
19164
19165 The result of operator-&gt; on an end<ins>-</ins>of<ins>-</ins>stream
19166 is not defined. For any other iterator value a <code>const T*</code>
19167 is returned.<ins> Invoking <code>operator++()</code> on
19168 an <i>end-of-stream</i> iterator is undefined.</ins> It is impossible
19169 to store things into istream iterators...
19170
19171    </blockquote>
19172    <p>
19173
19174 Add pre/postconditions to the member function descriptions of <code>istream_iterator</code> like so:
19175
19176    </p>
19177    <blockquote>
19178
19179 <pre>istream_iterator();</pre>
19180
19181 <i>Effects</i>: Constructs the <i>end-of-stream</i> iterator.<br>
19182 <ins><i>Postcondition</i>: <code>in_stream == 0</code>.</ins>
19183
19184 <pre>istream_iterator(istream_type &amp;s);</pre>
19185
19186 <i>Effects</i>: Initializes <code>in_stream</code> with &amp;s. value
19187 may be initialized during construction or the first time it is
19188 referenced.<br>
19189 <ins><i>Postcondition</i>: <code>in_stream == &amp;s</code>.</ins>
19190
19191 <pre>istream_iterator(const istream_iterator &amp;x);</pre>
19192
19193 <i>Effects</i>: Constructs a copy of <code>x</code>.<br>
19194 <ins><i>Postcondition</i>: <code>in_stream == x.in_stream</code>.</ins>
19195
19196 <pre>istream_iterator&amp; operator++();</pre>
19197
19198 <ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br>
19199 <i>Effects</i>: <code>*in_stream &gt;&gt; value</code>.
19200
19201 <pre>istream_iterator&amp; operator++(int);</pre>
19202
19203 <ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br>
19204 <i>Effects</i>:
19205    <blockquote><pre>istream_iterator tmp (*this);
19206 *in_stream &gt;&gt; value;
19207 return tmp;
19208      </pre>
19209      </blockquote>
19210    </blockquote>
19211
19212
19213
19214
19215
19216 </body></html>