l4/pkg/libstdc++-v3/contrib/libstdc++-v3-4.4/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>
   3 <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
   4
   5
   6 <title>C++ Standard Library Active Issues List</title>
   7 <style type="text/css">
   8 p {text-align:justify}
   9 li {text-align:justify}
  10 ins {background-color:#A0FFA0}
  11 del {background-color:#FFA0A0}
  12 </style>
  13 </head><body>
  14 <table>
  15 <tbody><tr>
  16 <td align="left">Doc. no.</td>
  17 <td align="left">N2727=08-0237</td>
  18 </tr>
  19 <tr>
  20 <td align="left">Date:</td>
  21 <td align="left">2008-08-24</td>
  22 </tr>
  23 <tr>
  24 <td align="left">Project:</td>
  25 <td align="left">Programming Language C++</td>
  26 </tr>
  27 <tr>
  28 <td align="left">Reply to:</td>
  29 <td align="left">Howard Hinnant &lt;<a href="mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>&gt;</td>
  30 </tr>
  31 </tbody></table>
  32 <h1>C++ Standard Library Active Issues List (Revision R59)</h1>
  33
  34   <p>Reference ISO/IEC IS 14882:1998(E)</p>
  35   <p>Also see:</p>
  36   <ul>
  37       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html">Table of Contents</a> for all library issues.</li>
  38       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html">Index by Section</a> for all library issues.</li>
  39       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html">Index by Status</a> for all library issues.</li>
  40       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a></li>
  41       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a></li>
  42   </ul>
  43   <p>The purpose of this document is to record the status of issues
  44   which have come before the Library Working Group (LWG) of the ANSI
  45   (J16) and ISO (WG21) C++ Standards Committee. Issues represent
  46   potential defects in the ISO/IEC IS 14882:1998(E) document.  Issues
  47   are not to be used to request new features. </p>
  48
  49   <p>This document contains only library issues which are actively being
  50   considered by the Library Working Group. That is, issues which have a
  51   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>,
  52   <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
  53   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a> for issues considered defects and
  54   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a> for issues considered closed.</p>
  55
  56   <p>The issues in these lists are not necessarily formal ISO Defect
  57   Reports (DR's). While some issues will eventually be elevated to
  58   official Defect Report status, other issues will be disposed of in
  59   other ways. See <a href="#Status">Issue Status</a>.</p>
  60
  61   <p>This document is in an experimental format designed for both
  62   viewing via a world-wide web browser and hard-copy printing. It
  63   is available as an HTML file for browsing or PDF file for
  64   printing.</p>
  65
  66   <p>Prior to Revision 14, library issues lists existed in two slightly
  67   different versions; a Committee Version and a Public
  68   Version. Beginning with Revision 14 the two versions were combined
  69   into a single version.</p>
  70
  71   <p>This document includes <i>[bracketed italicized notes]</i> as a
  72   reminder to the LWG of current progress on issues. Such notes are
  73   strictly unofficial and should be read with caution as they may be
  74   incomplete or incorrect. Be aware that LWG support for a particular
  75   resolution can quickly change if new viewpoints or killer examples are
  76   presented in subsequent discussions.</p>
  77
  78   <p>For the most current official version of this document see
  79   <a href="http://www.open-std.org/jtc1/sc22/wg21/">http://www.open-std.org/jtc1/sc22/wg21/</a>.
  80   Requests for further information about this document should include
  81   the document number above, reference ISO/IEC 14882:1998(E), and be
  82   submitted to Information Technology Industry Council (ITI), 1250 Eye
  83   Street NW, Washington, DC 20005.</p>
  84
  85   <p>Public information as to how to obtain a copy of the C++ Standard,
  86   join the standards committee, submit an issue, or comment on an issue
  87   can be found in the comp.std.c++ FAQ.
  88   Public discussion of C++ Standard related issues occurs on <a href="news:comp.std.c++">news:comp.std.c++</a>.
  89   </p>
  90
  91  <p>For committee members, files available on the committee's private
  92   web site include the HTML version of the Standard itself. HTML
  93   hyperlinks from this issues list to those files will only work for
  94   committee members who have downloaded them into the same disk
  95   directory as the issues list files.  </p>
  96
  97 <h2>Revision History</h2>
  98 <ul>
  99 <li>R59:
 100 2008-08-22 pre-San Francisco mailing.
 101 <ul>
 102 <li><b>Summary:</b><ul>
 103 <li>192 open issues, up by 9.</li>
 104 <li>686 closed issues, up by 0.</li>
 105 <li>878 issues total, up by 9.</li>
 106 </ul></li>
 107 <li><b>Details:</b><ul>
 108 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#871">871</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#872">872</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#875">875</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#877">877</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>.</li>
 109 </ul></li>
 110 </ul>
 111 </li>
 112 <li>R58:
 113 2008-07-28 mid-term mailing.
 114 <ul>
 115 <li><b>Summary:</b><ul>
 116 <li>183 open issues, up by 12.</li>
 117 <li>686 closed issues, down by 4.</li>
 118 <li>869 issues total, up by 8.</li>
 119 </ul></li>
 120 <li><b>Details:</b><ul>
 121 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#864">864</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#869">869</a>.</li>
 122 <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#393">393</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#592">592</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>
 123 <li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>.</li>
 124 <li>Changed the following issues from WP 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#629">629</a>.</li>
 125 <li>Changed the following issues from Pending NAD Editorial to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>.</li>
 126 </ul></li>
 127 </ul>
 128 </li>
 129 <li>R57:
 130 2008-06-27 post-Sophia Antipolis mailing.
 131 <ul>
 132 <li><b>Summary:</b><ul>
 133 <li>171 open issues, down by 20.</li>
 134 <li>690 closed issues, up by 43.</li>
 135 <li>861 issues total, up by 23.</li>
 136 </ul></li>
 137 <li><b>Details:</b><ul>
 138 <li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#840">840</a>.</li>
 139 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#858">858</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#861">861</a>.</li>
 140 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#839">839</a>.</li>
 141 <li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#852">852</a>.</li>
 142 <li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#851">851</a>.</li>
 143 <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>.</li>
 144 <li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>.</li>
 145 <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>.</li>
 146 <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>.</li>
 147 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</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#794">794</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#825">825</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#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>.</li>
 148 <li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>.</li>
 149 <li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>.</li>
 150 <li>Changed the following issues from New to Ready: <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#769">769</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-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</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#813">813</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#829">829</a>.</li>
 151 <li>Changed the following issues from Open to Ready: <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#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>.</li>
 152 <li>Changed the following issues from Review to Ready: <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#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>
 153 <li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#698">698</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#804">804</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#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>.</li>
 154 <li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#23">23</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#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a>.</li>
 155 <li>Changed the following issues from Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>.</li>
 156 <li>Changed the following issues from Ready to WP: <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#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</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-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li>
 157 </ul></li>
 158 </ul>
 159 </li>
 160 <li>R56:
 161 2008-05-16 pre-Sophia Antipolis mailing.
 162 <ul>
 163 <li><b>Summary:</b><ul>
 164 <li>191 open issues, up by 24.</li>
 165 <li>647 closed issues, up by 1.</li>
 166 <li>838 issues total, up by 25.</li>
 167 </ul></li>
 168 <li><b>Details:</b><ul>
 169 <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-closed.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-closed.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>
 170 <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>
 171 </ul></li>
 172 </ul>
 173 </li>
 174 <li>R55:
 175 2008-03-14 post-Bellevue mailing.
 176 <ul>
 177 <li><b>Summary:</b><ul>
 178 <li>167 open issues, down by 39.</li>
 179 <li>646 closed issues, up by 65.</li>
 180 <li>813 issues total, up by 26.</li>
 181 </ul></li>
 182 <li><b>Details:</b><ul>
 183 <li>Added the following Dup issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a>.</li>
 184 <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>
 185 <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>
 186 <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>
 187 <li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li>
 188 <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>
 189 <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>
 190 <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>
 191 <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>
 192 <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>
 193 <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>
 194 <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>
 195 <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>
 196 <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-closed.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-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>.</li>
 197 <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>
 198 <li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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>
 199 <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>
 200 <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>.</li>
 201 <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-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#673">673</a>.</li>
 202 <li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>.</li>
 203 <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>
 204 <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>
 205 <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>
 206 <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>
 207 </ul></li>
 208 </ul>
 209 </li>
 210 <li>R54:
 211 2008-02-01 pre-Bellevue mailing.
 212 <ul>
 213 <li><b>Summary:</b><ul>
 214 <li>206 open issues, up by 23.</li>
 215 <li>581 closed issues, up by 0.</li>
 216 <li>787 issues total, up by 23.</li>
 217 </ul></li>
 218 <li><b>Details:</b><ul>
 219 <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-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.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-defects.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-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>.</li>
 220 <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>
 221 <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>
 222 <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>
 223 <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>
 224 <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>
 225 </ul></li>
 226 </ul>
 227 </li>
 228 <li>R53:
 229 2007-12-09 mid-term mailing.
 230 <ul>
 231 <li><b>Summary:</b><ul>
 232 <li>183 open issues, up by 11.</li>
 233 <li>581 closed issues, down by 1.</li>
 234 <li>764 issues total, up by 10.</li>
 235 </ul></li>
 236 <li><b>Details:</b><ul>
 237 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.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-defects.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>
 238 <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>
 239 <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>
 240 </ul></li>
 241 </ul>
 242 </li>
 243 <li>R52:
 244 2007-10-19 post-Kona mailing.
 245 <ul>
 246 <li><b>Summary:</b><ul>
 247 <li>172 open issues, up by 4.</li>
 248 <li>582 closed issues, up by 27.</li>
 249 <li>754 issues total, up by 31.</li>
 250 </ul></li>
 251 <li><b>Details:</b><ul>
 252 <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-defects.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-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.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-defects.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>
 253 <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>
 254 <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>
 255 <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>
 256 <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-defects.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-defects.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>
 257 <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>
 258 <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>
 259 <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-defects.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>
 260 <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>
 261 <li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.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-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>.</li>
 262 <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>
 263 <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>
 264 <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>
 265 </ul></li>
 266 </ul>
 267 </li>
 268 <li>R51:
 269 2007-09-09 pre-Kona mailing.
 270 <ul>
 271 <li><b>Summary:</b><ul>
 272 <li>168 open issues, up by 15.</li>
 273 <li>555 closed issues, up by 0.</li>
 274 <li>723 issues total, up by 15.</li>
 275 </ul></li>
 276 <li><b>Details:</b><ul>
 277 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.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-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>.</li>
 278 </ul></li>
 279 </ul>
 280 </li>
 281 <li>R50:
 282 2007-08-05 post-Toronto mailing.
 283 <ul>
 284 <li><b>Summary:</b><ul>
 285 <li>153 open issues, down by 5.</li>
 286 <li>555 closed issues, up by 17.</li>
 287 <li>708 issues total, up by 12.</li>
 288 </ul></li>
 289 <li><b>Details:</b><ul>
 290 <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>
 291 <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>
 292 <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>
 293 <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>
 294 <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>
 295 <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>
 296 <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>
 297 <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>
 298 <li>Changed the following issues from Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>.</li>
 299 <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>
 300 <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>
 301 <li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>.</li>
 302 <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>
 303 <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>
 304 <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>
 305 </ul></li>
 306 </ul>
 307 </li>
 308 <li>R49:
 309 2007-06-23 pre-Toronto mailing.
 310 <ul>
 311 <li><b>Summary:</b><ul>
 312 <li>158 open issues, up by 13.</li>
 313 <li>538 closed issues, up by 7.</li>
 314 <li>696 issues total, up by 20.</li>
 315 </ul></li>
 316 <li><b>Details:</b><ul>
 317 <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-defects.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>
 318 <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>
 319 <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>
 320 <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>
 321 <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>
 322 </ul></li>
 323 </ul>
 324 </li>
 325 <li>R48:
 326 2007-05-06 post-Oxford mailing.
 327 <ul>
 328 <li><b>Summary:</b><ul>
 329 <li>145 open issues, down by 33.</li>
 330 <li>531 closed issues, up by 53.</li>
 331 <li>676 issues total, up by 20.</li>
 332 </ul></li>
 333 <li><b>Details:</b><ul>
 334 <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-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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>
 335 <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>
 336 <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>
 337 <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>
 338 <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>
 339 <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>
 340 <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>
 341 <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>
 342 <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>
 343 <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>
 344 <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-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>.</li>
 345 <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>
 346 <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>
 347 <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>
 348 <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>
 349 </ul></li>
 350 </ul>
 351 </li>
 352 <li>R47:
 353 2007-03-09 pre-Oxford mailing.
 354 <ul>
 355 <li><b>Summary:</b><ul>
 356 <li>178 open issues, up by 37.</li>
 357 <li>478 closed issues, up by 0.</li>
 358 <li>656 issues total, up by 37.</li>
 359 </ul></li>
 360 <li><b>Details:</b><ul>
 361 <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-defects.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-active.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>
 362 <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>
 363 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#614">614</a>.</li>
 364 <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>
 365 <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>
 366 <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>
 367 </ul></li>
 368 </ul>
 369 </li>
 370 <li>R46:
 371 2007-01-12 mid-term mailing.
 372 <ul>
 373 <li><b>Summary:</b><ul>
 374 <li>141 open issues, up by 11.</li>
 375 <li>478 closed issues, down by 1.</li>
 376 <li>619 issues total, up by 10.</li>
 377 </ul></li>
 378 <li><b>Details:</b><ul>
 379 <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>
 380 </ul></li>
 381 </ul>
 382 </li>
 383 <li>R45:
 384 2006-11-03 post-Portland mailing.
 385 <ul>
 386 <li><b>Summary:</b><ul>
 387 <li>130 open issues, up by 0.</li>
 388 <li>479 closed issues, up by 17.</li>
 389 <li>609 issues total, up by 17.</li>
 390 </ul></li>
 391 <li><b>Details:</b><ul>
 392 <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>
 393 <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>
 394 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Dup.</li>
 395 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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>
 396 <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>
 397 <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>
 398 <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>
 399 </ul></li>
 400 </ul>
 401 </li>
 402 <li>R44:
 403 2006-09-08 pre-Portland mailing.
 404 <ul>
 405 <li><b>Summary:</b><ul>
 406 <li>130 open issues, up by 6.</li>
 407 <li>462 closed issues, down by 1.</li>
 408 <li>592 issues total, up by 5.</li>
 409 </ul></li>
 410 <li><b>Details:</b><ul>
 411 <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>
 412 </ul></li>
 413 </ul>
 414 </li>
 415 <li>R43:
 416 2006-06-23 mid-term mailing.
 417 <ul>
 418 <li><b>Summary:</b><ul>
 419 <li>124 open issues, up by 14.</li>
 420 <li>463 closed issues, down by 1.</li>
 421 <li>587 issues total, up by 13.</li>
 422 </ul></li>
 423 <li><b>Details:</b><ul>
 424 <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>
 425 <li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#255">255</a>.</li>
 426 <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>
 427 </ul></li>
 428 </ul>
 429 </li>
 430 <li>R42:
 431 2006-04-21 post-Berlin mailing.
 432 <ul>
 433 <li><b>Summary:</b><ul>
 434 <li>110 open issues, down by 16.</li>
 435 <li>464 closed issues, up by 24.</li>
 436 <li>574 issues total, up by 8.</li>
 437 </ul></li>
 438 <li><b>Details:</b><ul>
 439 <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>
 440 <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>
 441 <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>
 442 <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>
 443 <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>
 444 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li>
 445 </ul></li>
 446 </ul>
 447 </li>
 448 <li>R41:
 449 2006-02-24 pre-Berlin mailing.
 450 <ul>
 451 <li><b>Summary:</b><ul>
 452 <li>126 open issues, up by 31.</li>
 453 <li>440 closed issues, up by 0.</li>
 454 <li>566 issues total, up by 31.</li>
 455 </ul></li>
 456 <li><b>Details:</b><ul>
 457 <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>
 458 <li>Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a> from Ready to Open.</li>
 459 <li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309">309</a>.</li>
 460 </ul></li>
 461 </ul>
 462 </li>
 463 <li>R40:
 464 2005-12-16 mid-term mailing.
 465 <ul>
 466 <li><b>Summary:</b><ul>
 467 <li>95 open issues.</li>
 468 <li>440 closed issues.</li>
 469 <li>535 issues total.</li>
 470 </ul></li>
 471 <li><b>Details:</b><ul>
 472 <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>
 473 </ul></li>
 474 </ul>
 475 </li>
 476 <li>R39:
 477 2005-10-14 post-Mont Tremblant mailing.
 478 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>.
 479 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.
 480 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.
 481 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.
 482 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.
 483 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
 484 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a> from New to Review.
 485 </li>
 486 <li>R38:
 487 2005-07-03 pre-Mont Tremblant mailing.
 488 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>.
 489 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>
 490 </li>
 491 <li>R37:
 492 2005-06 mid-term mailing.
 493 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>.
 494 </li>
 495 <li>R36:
 496 2005-04 post-Lillehammer mailing. All issues in "ready" status except
 497 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
 498 previously in "DR" status were moved to "WP".
 499 </li>
 500 <li>R35:
 501 2005-03 pre-Lillehammer mailing.
 502 </li>
 503 <li>R34:
 504 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>.
 505 </li>
 506 <li>R33:
 507 2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
 508 </li>
 509 <li>R32:
 510 2004-09 pre-Redmond mailing: reflects new proposed resolutions and
 511 new issues received after the 2004-07 mailing.  Added
 512 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>.
 513 </li>
 514 <li>R31:
 515 2004-07 mid-term mailing: reflects new proposed resolutions and
 516 new issues received after the post-Sydney mailing.  Added
 517 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>.
 518 </li>
 519 <li>R30:
 520 Post-Sydney mailing: reflects decisions made at the Sydney meeting.
 521 Voted all "Ready" issues from R29 into the working paper.
 522 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>.
 523 </li>
 524 <li>R29:
 525 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>.
 526 </li>
 527 <li>R28:
 528 Post-Kona mailing: reflects decisions made at the Kona meeting.
 529 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>.
 530 </li>
 531 <li>R27:
 532 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>.
 533 </li>
 534 <li>R26:
 535 Post-Oxford mailing: reflects decisions made at the Oxford meeting.
 536 All issues in Ready status were voted into DR status.  All issues in
 537 DR status were voted into WP status.
 538 </li>
 539 <li>R25:
 540 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>.
 541 </li>
 542 <li>R24:
 543 Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
 544 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
 545 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
 546 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
 547 concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
 548 </li>
 549 <li>R23:
 550 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>.
 551 Moved issues in the TC to TC status.
 552 </li>
 553 <li>R22:
 554 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>.
 555 </li>
 556 <li>R21:
 557 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>.
 558 </li>
 559 <li>R20:
 560 Post-Redmond mailing; reflects actions taken in Redmond.  Added
 561 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
 562 <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
 563 not discussed at the meeting.
 564
 565 All Ready issues were moved to DR status, with the exception of issues
 566 <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>.
 567
 568 Noteworthy issues discussed at Redmond include
 569 <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>,
 570 <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>.
 571 </li>
 572 <li>R19:
 573 Pre-Redmond mailing.  Added new issues
 574 <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>.
 575 </li>
 576 <li>R18:
 577 Post-Copenhagen mailing; reflects actions taken in Copenhagen.
 578 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
 579 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>.
 580
 581 Changed status of issues
 582 <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>
 583 <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>
 584 <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>
 585 <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>
 586 <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>
 587 <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>
 588 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>
 589 to DR.
 590
 591 Changed status of issues
 592 <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>
 593 <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>
 594 <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>
 595 <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>
 596 <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>
 597 <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>
 598 <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>
 599 <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>
 600 <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>
 601 to Ready.
 602
 603 Closed issues
 604 <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>
 605 <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>
 606 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
 607 as NAD.
 608
 609 </li>
 610 <li>R17:
 611 Pre-Copenhagen mailing.  Converted issues list to XML.  Added proposed
 612 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>.
 613 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>.
 614 </li>
 615 <li>R16:
 616 post-Toronto mailing; reflects actions taken in Toronto. Added new
 617 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
 618 <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>,
 619 <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>,
 620 <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>,
 621 <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>,
 622 <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>,
 623 <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>,
 624 <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>,
 625 <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>,
 626 <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>,
 627 <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>,
 628 <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>,
 629 <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>,
 630 <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
 631 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
 632 <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
 633 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
 634 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
 635 the bug in enough places.
 636 </li>
 637 <li>R15:
 638 pre-Toronto mailing. Added issues
 639 <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
 640 changes so that we pass Weblint tests.
 641 </li>
 642 <li>R14:
 643 post-Tokyo II mailing; reflects committee actions taken in
 644 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)
 645 </li>
 646 <li>R13:
 647 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>.
 648 </li>
 649 <li>R12:
 650 pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to
 651 <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
 652 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>.  Add further rationale to issue
 653 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>.
 654 </li>
 655 <li>R11:
 656 post-Kona mailing: Updated to reflect LWG and full committee actions
 657 in Kona (99-0048/N1224). Note changed resolution of issues
 658 <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>
 659 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
 660 "closed" documents.  Changed the proposed resolution of issue
 661 <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
 662 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>.
 663 </li>
 664 <li>R10:
 665 pre-Kona updated.  Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
 666 <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>,
 667 <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
 668 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
 669 </li>
 670 <li>R9:
 671 pre-Kona mailing.  Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to
 672 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
 673 "closed" documents. (99-0030/N1206, 25 Aug 99)
 674 </li>
 675 <li>R8:
 676 post-Dublin mailing. Updated to reflect LWG and full committee actions
 677 in Dublin. (99-0016/N1193, 21 Apr 99)
 678 </li>
 679 <li>R7:
 680 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>,
 681 <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>,
 682 <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>,
 683 <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)
 684 </li>
 685 <li>R6:
 686 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>,
 687 and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>.  (99-0007/N1194, 22 Feb 99)
 688 </li>
 689 <li>R5:
 690 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
 691 <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
 692 for making list public. (30 Dec 98)
 693 </li>
 694 <li>R4:
 695 post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
 696 <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
 697 issues corrected. (22 Oct 98)
 698 </li>
 699 <li>R3:
 700 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>
 701 added, many issues updated to reflect LWG consensus (12 Oct 98)
 702 </li>
 703 <li>R2:
 704 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,
 705 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98)
 706 </li>
 707 <li>R1:
 708 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
 709 format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98)
 710 </li>
 711 </ul>
 712
 713 <h2><a name="Status"></a>Issue Status</h2>
 714
 715   <p><b><a name="New">New</a></b> - The issue has not yet been
 716   reviewed by the LWG. Any <b>Proposed Resolution</b> is purely a
 717   suggestion from the issue submitter, and should not be construed as
 718   the view of LWG.</p>
 719
 720   <p><b><a name="Open">Open</a></b> - The LWG has discussed the issue
 721   but is not yet ready to move the issue forward. There are several
 722   possible reasons for open status:</p>
 723      <ul>
 724         <li>Consensus may have not yet have been reached as to how to deal
 725             with the issue.</li>
 726         <li>Informal consensus may have been reached, but the LWG awaits
 727             exact <b>Proposed Resolution</b> wording for review.</li>
 728         <li>The LWG wishes to consult additional technical experts before
 729             proceeding.</li>
 730         <li>The issue may require further study.</li>
 731      </ul>
 732
 733   <p>A <b>Proposed Resolution</b> for an open issue is still not be
 734   construed as the view of LWG. Comments on the current state of
 735   discussions are often given at the end of open issues in an italic
 736   font. Such comments are for information only and should not be given
 737   undue importance.</p>
 738
 739   <p><b><a name="Dup">Dup</a></b> - The LWG has reached consensus that
 740   the issue is a duplicate of another issue, and will not be further
 741   dealt with. A <b>Rationale</b> identifies the duplicated issue's
 742   issue number.  </p>
 743
 744   <p><b><a name="NAD">NAD</a></b> - The LWG has reached consensus that
 745   the issue is not a defect in the Standard.</p>
 746
 747   <p><b><a name="NAD Editorial">NAD Editorial</a></b> - The LWG has reached consensus that
 748   the issue can either be handled editorially, or is handled by a paper (usually
 749   linked to in the rationale).</p>
 750
 751   <p><b><a name="NAD Future">NAD Future</a></b> - In addition to the regular
 752   status, the LWG believes that this issue should be revisited at the
 753   next revision of the standard.</p>
 754
 755   <p><b><a name="Review">Review</a></b> - Exact wording of a
 756   <b>Proposed Resolution</b> is now available for review on an issue
 757   for which the LWG previously reached informal consensus.</p>
 758
 759   <p><b><a name="Tentatively Ready">Tentatively Ready</a></b> - The issue has
 760   been reviewed online, but not in a meeting, and some support has been formed
 761   for the proposed resolution.  Tentatively Ready issues may be moved to Ready
 762   and forwarded to full committee within the same meeting.  Unlike Ready issues
 763   they will be reviewed in subcommittee prior to forwarding to full committee.</p>
 764
 765   <p><b><a name="Ready">Ready</a></b> - The LWG has reached consensus
 766   that the issue is a defect in the Standard, the <b>Proposed
 767   Resolution</b> is correct, and the issue is ready to forward to the
 768   full committee for further action as a Defect Report (DR).</p>
 769
 770   <p><b><a name="DR">DR</a></b> - (Defect Report) - The full J16
 771   committee has voted to forward the issue to the Project Editor to be
 772   processed as a Potential Defect Report. The Project Editor reviews
 773   the issue, and then forwards it to the WG21 Convenor, who returns it
 774   to the full committee for final disposition. This issues list
 775   accords the status of DR to all these Defect Reports regardless of
 776   where they are in that process.</p>
 777
 778   <p><b><a name="TC">TC</a></b> - (Technical Corrigenda) - The full
 779   WG21 committee has voted to accept the Defect Report's Proposed
 780   Resolution as a Technical Corrigenda.  Action on this issue is thus
 781   complete and no further action is possible under ISO rules.</p>
 782
 783   <p><b><a name="TRDec">TRDec</a></b> - (Decimal TR defect) - The
 784   LWG has voted to accept the Defect Report's Proposed
 785   Resolution into the Decimal TR.  Action on this issue is thus
 786   complete and no further action is expected.</p>
 787
 788   <p><b><a name="WP">WP</a></b> - (Working Paper) - The proposed
 789   resolution has not been accepted as a Technical Corrigendum, but
 790   the full WG21 committee has voted to apply the Defect Report's Proposed
 791   Resolution to the working paper.</p>
 792
 793   <p><b>Pending</b> - This is a <i>status qualifier</i>.  When prepended to
 794   a status this indicates the issue has been
 795   processed by the committee, and a decision has been made to move the issue to
 796   the associated unqualified status.  However for logistical reasons the indicated
 797   outcome of the issue has not yet appeared in the latest working paper.
 798
 799   </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
 800   they first appear on the issues list. They may progress to
 801   <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
 802   is actively working on them. When the LWG has reached consensus on
 803   the disposition of an issue, the status will then change to
 804   <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
 805   <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
 806   forward Ready issues to the Project Editor, they are given the
 807   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
 808   become the basis for Technical Corrigenda (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>),
 809   or are closed without action other than a Record of Response
 810   (<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
 811   only issues which are truly defects in the Standard move to the
 812   formal ISO DR status.
 813   </p>
 814
 815
 816 <h2>Active Issues</h2>
 817 <hr>
 818 <h3><a name="23"></a>23. Num_get overflow result</h3>
 819 <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#Review">Review</a>
 820  <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
 821 <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>
 822 <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>
 823 <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>
 824 <p><b>Discussion:</b></p>
 825 <p>The current description of numeric input does not account for the
 826 possibility of overflow. This is an implicit result of changing the
 827 description to rely on the definition of scanf() (which fails to
 828 report overflow), and conflicts with the documented behavior of
 829 traditional and current implementations. </p>
 830
 831 <p>Users expect, when reading a character sequence that results in a
 832 value unrepresentable in the specified type, to have an error
 833 reported. The standard as written does not permit this. </p>
 834
 835 <p><b>Further comments from Dietmar:</b></p>
 836
 837 <p>
 838 I don't feel comfortable with the proposed resolution to issue 23: It
 839 kind of simplifies the issue to much. Here is what is going on:
 840 </p>
 841
 842 <p>
 843 Currently, the behavior of numeric overflow is rather counter intuitive
 844 and hard to trace, so I will describe it briefly:
 845 </p>
 846
 847 <ul>
 848   <li>
 849     According to 22.2.2.1.2 [facet.num.get.virtuals]
 850     paragraph 11 <tt>failbit</tt> is set if <tt>scanf()</tt> would
 851     return an input error; otherwise a value is converted to the rules
 852     of <tt>scanf</tt>.
 853   </li>
 854   <li>
 855     <tt>scanf()</tt> is defined in terms of <tt>fscanf()</tt>.
 856   </li>
 857   <li>
 858     <tt>fscanf()</tt> returns an input failure if during conversion no
 859     character matching the conversion specification could be extracted
 860     before reaching EOF. This is the only reason for <tt>fscanf()</tt>
 861     to fail due to an input error and clearly does not apply to the case
 862     of overflow.
 863   </li>
 864   <li>
 865     Thus, the conversion is performed according to the rules of
 866     <tt>fscanf()</tt> which basically says that <tt>strtod</tt>,
 867     <tt>strtol()</tt>, etc. are to be used for the conversion.
 868   </li>
 869   <li>
 870     The <tt>strtod()</tt>, <tt>strtol()</tt>, etc. functions consume as
 871     many matching characters as there are and on overflow continue to
 872     consume matching characters but also return a value identical to
 873     the maximum (or minimum for signed types if there was a leading minus)
 874     value of the corresponding type and set <tt>errno</tt> to <tt>ERANGE</tt>.
 875   </li>
 876   <li>
 877     Thus, according to the current wording in the standard, overflows
 878     can be detected! All what is to be done is to check <tt>errno</tt>
 879     after reading an element and, of course, clearing <tt>errno</tt>
 880     before trying a conversion. With the current wording, it can be
 881     detected whether the overflow was due to a positive or negative
 882     number for signed types.
 883   </li>
 884 </ul>
 885
 886 <p><b>Further discussion from Redmond:</b></p>
 887
 888 <p>The basic problem is that we've defined our behavior,
 889 including our error-reporting behavior, in terms of C90.  However,
 890 C90's method of reporting overflow in scanf is not technically an
 891 "input error".  The <tt>strto_*</tt> functions are more precise.</p>
 892
 893 <p>There was general consensus that <tt>failbit</tt> should be set
 894 upon overflow.  We considered three options based on this:</p>
 895 <ol>
 896 <li>Set failbit upon conversion error (including overflow), and
 897     don't store any value.</li>
 898 <li>Set failbit upon conversion error, and also set <tt>errno</tt> to
 899     indicated the precise nature of the error.</li>
 900 <li>Set failbit upon conversion error.  If the error was due to
 901     overflow, store +-numeric_limits&lt;T&gt;::max() as an
 902     overflow indication.</li>
 903 </ol>
 904
 905 <p>Straw poll: (1) 5; (2) 0; (3) 8.</p>
 906
 907
 908 <p>Discussed at Lillehammer.  General outline of what we want the
 909   solution to look like: we want to say that overflow is an error, and
 910   provide a way to distinguish overflow from other kinds of errors.
 911   Choose candidate field the same way scanf does, but don't describe
 912   the rest of the process in terms of format.  If a finite input field
 913   is too large (positive or negative) to be represented as a finite
 914   value, then set failbit and assign the nearest representable value.
 915   Bill will provide wording.</p>
 916
 917 <p>
 918 Discussed at Toronto:
 919 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2327.pdf">N2327</a>
 920 is in alignment with the direction we wanted to go with in Lillehammer.  Bill
 921 to work on.
 922 </p>
 923
 924
 925
 926 <p><b>Proposed resolution:</b></p>
 927
 928 <p>
 929 Change 22.2.2.1.2 [facet.num.get.virtuals], end of p3:
 930 </p>
 931
 932 <blockquote>
 933 <p>
 934 <b>Stage 3:</b> <del>The result of stage 2 processing can be one of</del>
 935 <ins>The sequence of <tt>char</tt>s accumulated in stage 2 (the field) is
 936 converted to a numeric value by the rules of one of the functions declared
 937 in the header <tt>&lt;cstdlib&gt;</tt>:</ins>
 938 </p>
 939 <ul>
 940 <li>
 941 <del>A sequence of <tt>char</tt>s has been accumulated in stage 2 that is
 942 converted (according to the rules of <tt>scanf</tt>) to a value of the
 943 type of <i>val</i>. This value is stored in <i>val</i> and <tt>ios_base::goodbit</tt> is
 944 stored in <i>err</i>.</del>
 945 <ins>For a signed integer value, the function <tt>strtoll</tt>.</ins>
 946 </li>
 947 <li>
 948 <del>The sequence of <tt>char</tt>s accumulated in stage 2 would have caused
 949 <tt>scanf</tt> to report an input failure. <tt>ios_base::failbit</tt> is
 950 assigned to <i>err</i>.</del>
 951 <ins>For an unsigned integer value, the function <tt>strtoull</tt>.</ins>
 952 </li>
 953 <li>
 954 <ins>For a floating-point value, the function <tt>strtold</tt>.</ins>
 955 </li>
 956 </ul>
 957 <p>
 958 <ins>The numeric value to be stored can be one of:</ins>
 959 </p>
 960 <ul>
 961 <li><ins>zero, if the conversion function fails to convert the entire field.
 962 <tt>ios_base::failbit</tt> is assigned to err.</ins></li>
 963 <li><ins>the most positive representable value, if the field represents a value
 964 too large positive to be represented in <i>val</i>. <tt>ios_base::failbit</tt> is assigned
 965 to <i>err</i>.</ins></li>
 966 <li><ins>the most negative representable value (zero for unsigned integer), if
 967 the field represents a value too large negative to be represented in <i>val</i>.
 968 <tt>ios_base::failbit</tt> is assigned to <i>err</i>.</ins></li>
 969 <li><ins>the converted value, otherwise.</ins></li>
 970 </ul>
 971
 972 <p><ins>
 973 The resultant numeric value is stored in <i>val</i>.
 974 </ins></p>
 975 </blockquote>
 976
 977 <p>
 978 Change 22.2.2.1.2 [facet.num.get.virtuals], p6-p7:
 979 </p>
 980
 981 <blockquote>
 982 <pre>iter_type do_get(iter_type <i>in</i>, iter_type <i>end</i>, ios_base&amp; <i>str</i>,
 983                  ios_base::iostate&amp; <i>err</i>, bool&amp; <i>val</i>) const;
 984 </pre>
 985 <blockquote>
 986 <p>
 987 -6- <i>Effects:</i> If
 988 <tt>(<i>str</i>.flags()&amp;ios_base::boolalpha)==0</tt> then input
 989 proceeds as it would for a <tt>long</tt> except that if a value is being
 990 stored into <i>val</i>, the value is determined according to the
 991 following: If the value to be stored is 0 then <tt>false</tt> is stored.
 992 If the value is 1 then <tt>true</tt> is stored. Otherwise
 993 <del><tt><i>err</i>|=ios_base::failbit</tt> is performed and no value</del> <ins><tt>true</tt></ins> is
 994 stored<del>.</del> <ins>and <tt>ios_base::failbit</tt> is assigned to <i>err</i>.</ins>
 995 </p>
 996 <p>
 997 -7- Otherwise target sequences are determined "as if" by calling the
 998 members <tt>falsename()</tt> and <tt>truename()</tt> of the facet
 999 obtained by <tt>use_facet&lt;numpunct&lt;charT&gt;
1000 &gt;(<i>str</i>.getloc())</tt>. Successive characters in the range
1001 <tt>[<i>in</i>,<i>end</i>)</tt> (see 23.1.1) are obtained and matched
1002 against corresponding positions in the target sequences only as
1003 necessary to identify a unique match. The input iterator <i>in</i> is
1004 compared to <i>end</i> only when necessary to obtain a character. If <del>and
1005 only if</del> a target sequence is uniquely matched, <i>val</i> is set to the
1006 corresponding value. <ins>Otherwise <tt>false</tt> is stored and <tt>ios_base::failbit</tt>
1007 is assigned to <i>err</i>.</ins>
1008 </p>
1009 </blockquote>
1010 </blockquote>
1011
1012
1013
1014
1015
1016 <hr>
1017 <h3><a name="96"></a>96. Vector&lt;bool&gt; is not a container</h3>
1018 <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>
1019  <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
1020 <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>
1021 <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>
1022 <p><b>Discussion:</b></p>
1023 <p><tt>vector&lt;bool&gt;</tt> is not a container as its reference and
1024 pointer types are not references and pointers. </p>
1025
1026 <p>Also it forces everyone to have a space optimization instead of a
1027 speed one.</p>
1028
1029 <p><b>See also:</b> 99-0008 == N1185 Vector&lt;bool&gt; is
1030 Nonconforming, Forces Optimization Choice.</p>
1031
1032 <p><i>[In Santa Cruz the LWG felt that this was Not A Defect.]</i></p>
1033
1034
1035 <p><i>[In Dublin many present felt that failure to meet Container
1036 requirements was a defect. There was disagreement as to whether
1037 or not the optimization requirements constituted a defect.]</i></p>
1038
1039
1040 <p><i>[The LWG looked at the following resolutions in some detail:
1041 <br>
1042 &nbsp;&nbsp;&nbsp;&nbsp; * Not A Defect.<br>
1043 &nbsp;&nbsp;&nbsp;&nbsp; * Add a note explaining that vector&lt;bool&gt; does not meet
1044 Container requirements.<br>
1045 &nbsp;&nbsp;&nbsp;&nbsp; * Remove vector&lt;bool&gt;.<br>
1046 &nbsp;&nbsp;&nbsp;&nbsp; * Add a new category of container requirements which
1047 vector&lt;bool&gt; would meet.<br>
1048 &nbsp;&nbsp;&nbsp;&nbsp; * Rename vector&lt;bool&gt;.<br>
1049 <br>
1050 No alternative had strong, wide-spread, support and every alternative
1051 had at least one "over my dead body" response.<br>
1052 <br>
1053 There was also mention of a transition scheme something like (1) add
1054 vector_bool and deprecate vector&lt;bool&gt; in the next standard. (2)
1055 Remove vector&lt;bool&gt; in the following standard.]</i></p>
1056
1057
1058 <p><i>[Modifying container requirements to permit returning proxies
1059 (thus allowing container requirements conforming vector&lt;bool&gt;)
1060 was also discussed.]</i></p>
1061
1062
1063 <p><i>[It was also noted that there is a partial but ugly workaround in
1064 that vector&lt;bool&gt; may be further specialized with a customer
1065 allocator.]</i></p>
1066
1067
1068 <p><i>[Kona: Herb Sutter presented his paper J16/99-0035==WG21/N1211,
1069 vector&lt;bool&gt;: More Problems, Better Solutions. Much discussion
1070 of a two step approach: a) deprecate, b) provide replacement under a
1071 new name.  LWG straw vote on that: 1-favor, 11-could live with, 2-over
1072 my dead body.  This resolution was mentioned in the LWG report to the
1073 full committee, where several additional committee members indicated
1074 over-my-dead-body positions.]</i></p>
1075
1076
1077 <p>Discussed at Lillehammer.  General agreement that we should
1078   deprecate vector&lt;bool&gt; and introduce this functionality under
1079   a different name, e.g. bit_vector.  This might make it possible to
1080   remove the vector&lt;bool&gt; specialization in the standard that comes
1081   after C++0x. There was also a suggestion that
1082   in C++0x we could additional say that it's implementation defined
1083   whether vector&lt;bool&gt; refers to the specialization or to the
1084   primary template, but there wasn't general agreement that this was a
1085   good idea.</p>
1086
1087 <p>We need a paper for the new bit_vector class.</p>
1088
1089
1090
1091
1092 <p><b>Proposed resolution:</b></p>
1093 <p>
1094 We now have:
1095 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2050.pdf">N2050</a>
1096 and
1097 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2160.html">N2160</a>.
1098 </p>
1099
1100 <p><i>[
1101 Batavia: The LWG feels we need something closer to SGI's <tt>bitvector</tt> to ease migration
1102 from <tt>vector&lt;bool&gt;</tt>.  Although some of the funcitonality from
1103 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2050.pdf">N2050</a>
1104 could well be used in such a template.  The concern is easing the API migration for those
1105 users who want to continue using a bit-packed container.  Alan and Beman to work.
1106 ]</i></p>
1107
1108
1109
1110
1111
1112
1113 <hr>
1114 <h3><a name="128"></a>128. Need open_mode() function for file stream, string streams, file buffers, and string&nbsp; buffers</h3>
1115 <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>
1116  <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-02-22</p>
1117 <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>
1118 <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>
1119 <p><b>Discussion:</b></p>
1120 <p>The following question came from Thorsten Herlemann:</p>
1121
1122 <blockquote>
1123   <p>You can set a mode when constructing or opening a file-stream or
1124   filebuf, e.g.  ios::in, ios::out, ios::binary, ... But how can I get
1125   that mode later on, e.g. in my own operator &lt;&lt; or operator
1126   &gt;&gt; or when I want to check whether a file-stream or
1127   file-buffer object passed as parameter is opened for input or output
1128   or binary? Is there no possibility? Is this a design-error in the
1129   standard C++ library? </p>
1130 </blockquote>
1131
1132 <p>It is indeed impossible to find out what a stream's or stream
1133 buffer's open mode is, and without that knowledge you don't know
1134 how certain operations behave. Just think of the append mode. </p>
1135
1136 <p>Both streams and stream buffers should have a <tt>mode()</tt> function that returns the
1137 current open mode setting. </p>
1138
1139 <p><i>[
1140 post Bellevue:  Alisdair requested to re-Open.
1141 ]</i></p>
1142
1143
1144
1145
1146 <p><b>Proposed resolution:</b></p>
1147 <p>For stream buffers, add a function to the base class as a non-virtual function
1148 qualified as const to 27.5.2 [streambuf]:</p>
1149
1150 <p>&nbsp;&nbsp;&nbsp;&nbsp;<tt>openmode mode() const</tt>;</p>
1151
1152 <p><b>&nbsp;&nbsp;&nbsp; Returns</b> the current open mode.</p>
1153
1154 <p>With streams, I'm not sure what to suggest. In principle, the mode
1155 could already be returned by <tt>ios_base</tt>, but the mode is only
1156 initialized for file and string stream objects, unless I'm overlooking
1157 anything. For this reason it should be added to the most derived
1158 stream classes. Alternatively, it could be added to <tt>basic_ios</tt>
1159 and would be default initialized in <tt>basic_ios&lt;&gt;::init()</tt>.</p>
1160
1161
1162 <p><b>Rationale:</b></p>
1163 <p>This might be an interesting extension for some future, but it is
1164 not a defect in the current standard. The Proposed Resolution is
1165 retained for future reference.</p>
1166
1167
1168
1169
1170
1171 <hr>
1172 <h3><a name="180"></a>180. Container member iterator arguments constness has unintended consequences</h3>
1173 <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#Ready">Ready</a>
1174  <b>Submitter:</b> Dave Abrahams <b>Date:</b> 1999-07-01</p>
1175 <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>
1176 <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>
1177 <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>
1178 <p><b>Discussion:</b></p>
1179 <p>It is the constness of the container which should control whether
1180 it can be modified through a member function such as erase(), not the
1181 constness of the iterators. The iterators only serve to give
1182 positioning information.</p>
1183
1184 <p>Here's a simple and typical example problem which is currently very
1185 difficult or impossible to solve without the change proposed
1186 below.</p>
1187
1188 <p>Wrap a standard container C in a class W which allows clients to
1189 find and read (but not modify) a subrange of (C.begin(), C.end()]. The
1190 only modification clients are allowed to make to elements in this
1191 subrange is to erase them from C through the use of a member function
1192 of W.</p>
1193
1194 <p><i>[
1195 post Bellevue, Alisdair adds:
1196 ]</i></p>
1197
1198
1199 <blockquote>
1200 <p>
1201 This issue was implemented by
1202 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2350.pdf">N2350</a>
1203 for everything but <tt>basic_string</tt>.
1204 </p>
1205
1206 <p>
1207 Note that the specific example in this issue (<tt>basic_string</tt>) is the one place
1208 we forgot to amend in
1209 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2350.pdf">N2350</a>,
1210 so we might open this issue for that
1211 single container?
1212 </p>
1213 </blockquote>
1214
1215 <p><i>[
1216 Sophia Antipolis:
1217 ]</i></p>
1218
1219
1220 <blockquote>
1221 <p>
1222 This was a fix that was intended for all standard library containers,
1223 and has been done for other containers, but string was missed.
1224 </p>
1225 <p>
1226 The wording updated.
1227 </p>
1228 <p>
1229 We did not make the change in <tt>replace</tt>, because this change would affect
1230 the implementation because the string may be written into. This is an
1231 issue that should be taken up by concepts.
1232 </p>
1233 <p>
1234 We note that the supplied wording addresses the initializer list provided in
1235 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2679.pdf">N2679</a>.
1236 </p>
1237 </blockquote>
1238
1239
1240
1241 <p><b>Proposed resolution:</b></p>
1242 <p>
1243 Update the following signature in the <tt>basic_string</tt> class template definition in
1244 21.3 [basic.string], p5:
1245 </p>
1246 <blockquote><pre>namespace std {
1247   template&lt;class charT, class traits = char_traits&lt;charT&gt;,
1248     class Allocator = allocator&lt;charT&gt; &gt;
1249   class basic_string {
1250
1251     ...
1252
1253     iterator insert(<ins>const_</ins>iterator p, charT c);
1254     void insert(<ins>const_</ins>iterator p, size_type n, charT c);
1255     template&lt;class InputIterator&gt;
1256       void insert(<ins>const_</ins>iterator p, InputIterator first, InputIterator last);
1257     void insert(<ins>const_</ins>iterator <ins>p</ins>, initializer_list&lt;charT&gt;);
1258
1259     ...
1260
1261     iterator erase(<ins>const_</ins>iterator <ins>const_</ins>position);
1262     iterator erase(<ins>const_</ins>iterator first, <ins>const_</ins>iterator last);
1263
1264     ...
1265
1266   };
1267 }
1268 </pre></blockquote>
1269
1270 <p>
1271 Update the following signatures in 21.3.6.4 [string::insert]:
1272 </p>
1273
1274 <blockquote><pre>iterator insert(<ins>const_</ins>iterator p, charT c);
1275 void insert(<ins>const_</ins>iterator p, size_type n, charT c);
1276 template&lt;class InputIterator&gt;
1277   void insert(<ins>const_</ins>iterator p, InputIterator first, InputIterator last);
1278 void insert(<ins>const_</ins>iterator <ins>p</ins>, initializer_list&lt;charT&gt;);
1279 </pre></blockquote>
1280
1281 <p>
1282 Update the following signatures in 21.3.6.5 [string::erase]:
1283 </p>
1284
1285 <blockquote><pre>iterator erase(<ins>const_</ins>iterator <ins>const_</ins>position);
1286 iterator erase(<ins>const_</ins>iterator first, <ins>const_</ins>iterator last);
1287 </pre></blockquote>
1288
1289
1290
1291 <p><b>Rationale:</b></p>
1292 <p>The issue was discussed at length. It was generally agreed that 1)
1293 There is no major technical argument against the change (although
1294 there is a minor argument that some obscure programs may break), and
1295 2) Such a change would not break const correctness. The concerns about
1296 making the change were 1) it is user detectable (although only in
1297 boundary cases), 2) it changes a large number of signatures, and 3) it
1298 seems more of a design issue that an out-and-out defect.</p>
1299
1300 <p>The LWG believes that this issue should be considered as part of a
1301 general review of const issues for the next revision of the
1302 standard. Also see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>.</p>
1303
1304
1305
1306
1307 <hr>
1308 <h3><a name="190"></a>190. min() and max() functions should be std::binary_functions</h3>
1309 <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>
1310  <b>Submitter:</b> Mark Rintoul <b>Date:</b> 1999-08-26</p>
1311 <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>
1312 <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>
1313 <p><b>Discussion:</b></p>
1314 <p>Both std::min and std::max are defined as template functions.  This
1315 is very different than the definition of std::plus (and similar
1316 structs) which are defined as function objects which inherit
1317 std::binary_function.<br>
1318 <br>
1319         This lack of inheritance leaves std::min and std::max somewhat useless in standard library algorithms which require
1320 a function object that inherits std::binary_function.</p>
1321
1322 <p><i>[
1323 post Bellevue:  Alisdair requested to re-Open.
1324 ]</i></p>
1325
1326
1327
1328
1329 <p><b>Rationale:</b></p>
1330 <p>Although perhaps an unfortunate design decision, the omission is not a defect
1331 in the current standard.&nbsp; A future standard may wish to consider additional
1332 function objects.</p>
1333
1334
1335
1336
1337 <hr>
1338 <h3><a name="255"></a>255. Why do <tt>basic_streambuf&lt;&gt;::pbump()</tt> and <tt>gbump()</tt> take an int?</h3>
1339 <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>
1340  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-08-12</p>
1341 <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>
1342 <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>
1343 <p><b>Discussion:</b></p>
1344 <p>
1345 The basic_streambuf members gbump() and pbump() are specified to take an
1346 int argument. This requirement prevents the functions from effectively
1347 manipulating buffers larger than std::numeric_limits&lt;int&gt;::max()
1348 characters. It also makes the common use case for these functions
1349 somewhat difficult as many compilers will issue a warning when an
1350 argument of type larger than int (such as ptrdiff_t on LLP64
1351 architectures) is passed to either of the function. Since it's often the
1352 result of the subtraction of two pointers that is passed to the
1353 functions, a cast is necessary to silence such warnings. Finally, the
1354 usage of a native type in the functions signatures is inconsistent with
1355 other member functions (such as sgetn() and sputn()) that manipulate the
1356 underlying character buffer. Those functions take a streamsize argument.
1357 </p>
1358
1359
1360 <p><b>Proposed resolution:</b></p>
1361 <p>
1362 Change the signatures of these functions in the synopsis of template
1363 class basic_streambuf (27.5.2) and in their descriptions (27.5.2.3.1, p4
1364 and 27.5.2.3.2, p4) to take a streamsize argument.
1365 </p>
1366
1367 <p>
1368 Although this change has the potential of changing the ABI of the
1369 library, the change will affect only platforms where int is different
1370 than the definition of streamsize. However, since both functions are
1371 typically inline (they are on all known implementations), even on such
1372 platforms the change will not affect any user code unless it explicitly
1373 relies on the existing type of the functions (e.g., by taking their
1374 address). Such a possibility is IMO quite remote.
1375 </p>
1376
1377 <p>
1378 Alternate Suggestion from Howard Hinnant, c++std-lib-7780:
1379 </p>
1380
1381 <p>
1382 This is something of a nit, but I'm wondering if streamoff wouldn't be a
1383 better choice than streamsize.  The argument to pbump and gbump MUST be
1384 signed.  But the standard has this to say about streamsize
1385 (27.4.1/2/Footnote):
1386 </p>
1387
1388 <blockquote><p>
1389      [Footnote: streamsize is used in most places where ISO C would use
1390      size_t.  Most of the uses of streamsize could use size_t, except for
1391      the strstreambuf constructors, which require negative values. It
1392      should probably be the signed type corresponding to size_t (which is
1393      what Posix.2 calls ssize_t). --- end footnote]
1394 </p></blockquote>
1395
1396 <p>
1397 This seems a little weak for the argument to pbump and gbump.  Should we
1398 ever really get rid of strstream, this footnote might go with it, along
1399 with the reason to make streamsize signed.
1400 </p>
1401
1402
1403 <p><b>Rationale:</b></p>
1404 <p>The LWG believes this change is too big for now.  We may wish to
1405 reconsider this for a future revision of the standard.  One
1406 possibility is overloading pbump, rather than changing the
1407 signature.</p>
1408 <p><i>[
1409 [2006-05-04: Reopened at the request of Chris (Krzysztof ?elechowski)]
1410 ]</i></p>
1411
1412
1413
1414
1415
1416 <hr>
1417 <h3><a name="290"></a>290. Requirements to for_each and its function object</h3>
1418 <p><b>Section:</b> 25.1.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
1419  <b>Submitter:</b> Angelika Langer <b>Date:</b> 2001-01-03</p>
1420 <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>
1421 <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>
1422 <p><b>Discussion:</b></p>
1423 <p>The specification of the for_each algorithm does not have a
1424 "Requires" section, which means that there are no
1425 restrictions imposed on the function object whatsoever. In essence it
1426 means that I can provide any function object with arbitrary side
1427 effects and I can still expect a predictable result. In particular I
1428 can expect that the function object is applied exactly last - first
1429 times, which is promised in the "Complexity" section.
1430 </p>
1431
1432 <p>I don't see how any implementation can give such a guarantee
1433 without imposing requirements on the function object.
1434 </p>
1435
1436 <p>Just as an example: consider a function object that removes
1437 elements from the input sequence.  In that case, what does the
1438 complexity guarantee (applies f exactly last - first times) mean?
1439 </p>
1440
1441 <p>One can argue that this is obviously a nonsensical application and
1442 a theoretical case, which unfortunately it isn't.  I have seen
1443 programmers shooting themselves in the foot this way, and they did not
1444 understand that there are restrictions even if the description of the
1445 algorithm does not say so.
1446 </p>
1447 <p><i>[Lillehammer: This is more general than for_each.  We don't want
1448   the function object in transform invalidiating iterators
1449   either. There should be a note somewhere in clause 17 (17, not 25)
1450   saying that user code operating on a range may not invalidate
1451   iterators unless otherwise specified.  Bill will provide wording.]</i></p>
1452
1453
1454
1455 <p><b>Proposed resolution:</b></p>
1456
1457
1458
1459
1460
1461
1462 <hr>
1463 <h3><a name="299"></a>299. Incorrect return types for iterator dereference</h3>
1464 <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>
1465  <b>Submitter:</b> John Potter <b>Date:</b> 2001-01-22</p>
1466 <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>
1467 <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>
1468 <p><b>Discussion:</b></p>
1469 <p>
1470 In section 24.1.4 [bidirectional.iterators],
1471 Table 75 gives the return type of *r-- as convertible to T.  This is
1472 not consistent with Table 74 which gives the return type of *r++ as
1473 T&amp;.  *r++ = t is valid while *r-- = t is invalid.
1474 </p>
1475
1476 <p>
1477 In section 24.1.5 [random.access.iterators],
1478 Table 76 gives the return type of a[n] as convertible to T.  This is
1479 not consistent with the semantics of *(a + n) which returns T&amp; by
1480 Table 74.  *(a + n) = t is valid while a[n] = t is invalid.
1481 </p>
1482
1483 <p>
1484 Discussion from the Copenhagen meeting: the first part is
1485 uncontroversial.  The second part, operator[] for Random Access
1486 Iterators, requires more thought.  There are reasonable arguments on
1487 both sides.  Return by value from operator[] enables some potentially
1488 useful iterators, e.g. a random access "iota iterator" (a.k.a
1489 "counting iterator" or "int iterator").  There isn't any obvious way
1490 to do this with return-by-reference, since the reference would be to a
1491 temporary.  On the other hand, <tt>reverse_iterator</tt> takes an
1492 arbitrary Random Access Iterator as template argument, and its
1493 operator[] returns by reference.  If we decided that the return type
1494 in Table 76 was correct, we would have to change
1495 <tt>reverse_iterator</tt>.  This change would probably affect user
1496 code.
1497 </p>
1498
1499 <p>
1500 History: the contradiction between <tt>reverse_iterator</tt> and the
1501 Random Access Iterator requirements has been present from an early
1502 stage.  In both the STL proposal adopted by the committee
1503 (N0527==94-0140) and the STL technical report (HPL-95-11 (R.1), by
1504 Stepanov and Lee), the Random Access Iterator requirements say that
1505 operator[]'s return value is "convertible to T".  In N0527
1506 reverse_iterator's operator[] returns by value, but in HPL-95-11
1507 (R.1), and in the STL implementation that HP released to the public,
1508 reverse_iterator's operator[] returns by reference.  In 1995, the
1509 standard was amended to reflect the contents of HPL-95-11 (R.1).  The
1510 original intent for operator[] is unclear.
1511 </p>
1512
1513 <p>
1514 In the long term it may be desirable to add more fine-grained
1515 iterator requirements, so that access method and traversal strategy
1516 can be decoupled.  (See "Improved Iterator Categories and
1517 Requirements", N1297 = 01-0011, by Jeremy Siek.)  Any decisions
1518 about issue 299 should keep this possibility in mind.
1519 </p>
1520
1521 <p>Further discussion: I propose a compromise between John Potter's
1522 resolution, which requires <tt>T&amp;</tt> as the return type of
1523 <tt>a[n]</tt>, and the current wording, which requires convertible to
1524 <tt>T</tt>. The compromise is to keep the convertible to <tt>T</tt>
1525 for the return type of the expression <tt>a[n]</tt>, but to also add
1526 <tt>a[n] = t</tt> as a valid expression. This compromise "saves" the
1527 common case uses of random access iterators, while at the same time
1528 allowing iterators such as counting iterator and caching file
1529 iterators to remain random access iterators (iterators where the
1530 lifetime of the object returned by <tt>operator*()</tt> is tied to the
1531 lifetime of the iterator).
1532 </p>
1533
1534 <p>
1535 Note that the compromise resolution necessitates a change to
1536 <tt>reverse_iterator</tt>. It would need to use a proxy to support
1537 <tt>a[n] = t</tt>.
1538 </p>
1539
1540 <p>
1541 Note also there is one kind of mutable random access iterator that
1542 will no longer meet the new requirements. Currently, iterators that
1543 return an r-value from <tt>operator[]</tt> meet the requirements for a
1544 mutable random access iterartor, even though the expression <tt>a[n] =
1545 t</tt> will only modify a temporary that goes away. With this proposed
1546 resolution, <tt>a[n] = t</tt> will be required to have the same
1547 operational semantics as <tt>*(a + n) = t</tt>.
1548 </p>
1549
1550
1551
1552 <p><b>Proposed resolution:</b></p>
1553
1554 <p>
1555 In section 24.1.4 [lib.bidirectdional.iterators], change the return
1556 type in table 75 from "convertible to <tt>T</tt>" to
1557 <tt>T&amp;</tt>.
1558 </p>
1559
1560 <p>
1561 In section 24.1.5 [lib.random.access.iterators], change the
1562 operational semantics for <tt>a[n]</tt> to " the r-value of
1563 <tt>a[n]</tt> is equivalent to the r-value of <tt>*(a +
1564 n)</tt>". Add a new row in the table for the expression <tt>a[n] = t</tt>
1565 with a return type of convertible to <tt>T</tt> and operational semantics of
1566 <tt>*(a + n) = t</tt>.
1567 </p>
1568
1569 <p><i>[Lillehammer: Real problem, but should be addressed as part of
1570   iterator redesign]</i></p>
1571
1572
1573
1574
1575
1576
1577
1578
1579 <hr>
1580 <h3><a name="309"></a>309. Does sentry catch exceptions?</h3>
1581 <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>
1582  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-03-19</p>
1583 <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>
1584 <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>
1585 <p><b>Discussion:</b></p>
1586 <p>
1587 The descriptions of the constructors of basic_istream&lt;&gt;::sentry
1588 (27.6.1.1.3 [istream::sentry]) and basic_ostream&lt;&gt;::sentry
1589 (27.6.2.4 [ostream::sentry]) do not explain what the functions do in
1590 case an exception is thrown while they execute. Some current
1591 implementations allow all exceptions to propagate, others catch them
1592 and set ios_base::badbit instead, still others catch some but let
1593 others propagate.
1594 </p>
1595
1596 <p>
1597 The text also mentions that the functions may call setstate(failbit)
1598 (without actually saying on what object, but presumably the stream
1599 argument is meant).  That may have been fine for
1600 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
1601 the function performs an input operation which may fail. However,
1602 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
1603 clarify that the function should actually call setstate(failbit |
1604 eofbit), so the sentence in p3 is redundant or even somewhat
1605 contradictory.
1606 </p>
1607
1608 <p>
1609 The same sentence that appears in 27.6.2.4 [ostream::sentry], p3
1610 doesn't seem to be very meaningful for basic_istream&lt;&gt;::sentry
1611 which performs no input. It is actually rather misleading since it
1612 would appear to guide library implementers to calling
1613 setstate(failbit) when os.tie()-&gt;flush(), the only called function,
1614 throws an exception (typically, it's badbit that's set in response to
1615 such an event).
1616 </p>
1617
1618 <p><b>Additional comments from Martin, who isn't comfortable with the
1619     current proposed resolution</b> (see c++std-lib-11530)</p>
1620
1621 <p>
1622 The istream::sentry ctor says nothing about how the function
1623 deals with exemptions (27.6.1.1.2, p1 says that the class is
1624 responsible for doing "exception safe"(*) prefix and suffix
1625 operations but it doesn't explain what level of exception
1626 safety the class promises to provide). The mockup example
1627 of a "typical implementation of the sentry ctor" given in
1628 27.6.1.1.2, p6, removed in ISO/IEC 14882:2003, doesn't show
1629 exception handling, either. Since the ctor is not classified
1630 as a formatted or unformatted input function, the text in
1631 27.6.1.1, p1 through p4 does not apply. All this would seem
1632 to suggest that the sentry ctor should not catch or in any
1633 way handle exceptions thrown from any functions it may call.
1634 Thus, the typical implementation of an istream extractor may
1635 look something like [1].
1636 </p>
1637
1638 <p>
1639 The problem with [1] is that while it correctly sets ios::badbit
1640 if an exception is thrown from one of the functions called from
1641 the sentry ctor, if the sentry ctor reaches EOF while extracting
1642 whitespace from a stream that has eofbit or failbit set in
1643 exceptions(), it will cause an ios::failure to be thrown, which
1644 will in turn cause the extractor to set ios::badbit.
1645 </p>
1646
1647 <p>
1648 The only straightforward way to prevent this behavior is to
1649 move the definition of the sentry object in the extractor
1650 above the try block (as suggested by the example in 22.2.8,
1651 p9 and also indirectly supported by 27.6.1.3, p1). See [2].
1652 But such an implementation will allow exceptions thrown from
1653 functions called from the ctor to freely propagate to the
1654 caller regardless of the setting of ios::badbit in the stream
1655 object's exceptions().
1656 </p>
1657
1658 <p>
1659 So since neither [1] nor [2] behaves as expected, the only
1660 possible solution is to have the sentry ctor catch exceptions
1661 thrown from called functions, set badbit, and propagate those
1662 exceptions if badbit is also set in exceptions(). (Another
1663 solution exists that deals with both kinds of sentries, but
1664 the code is non-obvious and cumbersome -- see [3].)
1665 </p>
1666
1667 <p>
1668 Please note that, as the issue points out, current libraries
1669 do not behave consistently, suggesting  that implementors are
1670 not quite clear on the exception handling in istream::sentry,
1671 despite the fact that some LWG members might feel otherwise.
1672 (As documented by the parenthetical comment here:
1673 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1480.html#309)
1674 </p>
1675
1676 <p>
1677 Also please note that those LWG members who in Copenhagen
1678 felt that "a sentry's constructor should not catch exceptions,
1679 because sentries should only be used within (un)formatted input
1680 functions and that exception handling is the responsibility of
1681 those functions, not of the sentries," as noted here
1682 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1310.html#309
1683 would in effect be either arguing for the behavior described
1684 in [1] or for extractors implemented along the lines of [3].
1685 </p>
1686
1687 <p>
1688 The original proposed resolution (Revision 25 of the issues
1689 list) clarifies the role of the sentry ctor WRT exception
1690 handling by making it clear that extractors (both library
1691 or user-defined) should be implemented along the lines of
1692 [2] (as opposed to [1]) and that no exception thrown from
1693 the callees should propagate out of either function unless
1694 badbit is also set in exceptions().
1695 </p>
1696
1697
1698 <p>[1] Extractor that catches exceptions thrown from sentry:</p>
1699
1700 <blockquote>
1701 <pre>struct S { long i; };
1702
1703 istream&amp; operator&gt;&gt; (istream &amp;strm, S &amp;s)
1704 {
1705     ios::iostate err = ios::goodbit;
1706     try {
1707         const istream::sentry guard (strm, false);
1708         if (guard) {
1709             use_facet&lt;num_get&lt;char&gt; &gt;(strm.getloc ())
1710                 .get (istreambuf_iterator&lt;char&gt;(strm),
1711                       istreambuf_iterator&lt;char&gt;(),
1712                       strm, err, s.i);
1713         }
1714     }
1715     catch (...) {
1716         bool rethrow;
1717         try {
1718             strm.setstate (ios::badbit);
1719             rethrow = false;
1720         }
1721         catch (...) {
1722             rethrow = true;
1723         }
1724         if (rethrow)
1725             throw;
1726     }
1727     if (err)
1728         strm.setstate (err);
1729     return strm;
1730 }
1731 </pre>
1732 </blockquote>
1733
1734 <p>[2] Extractor that propagates exceptions thrown from sentry:</p>
1735
1736 <blockquote>
1737 <pre>istream&amp; operator&gt;&gt; (istream &amp;strm, S &amp;s)
1738 {
1739     istream::sentry guard (strm, false);
1740     if (guard) {
1741         ios::iostate err = ios::goodbit;
1742         try {
1743             use_facet&lt;num_get&lt;char&gt; &gt;(strm.getloc ())
1744                 .get (istreambuf_iterator&lt;char&gt;(strm),
1745                       istreambuf_iterator&lt;char&gt;(),
1746                       strm, err, s.i);
1747         }
1748         catch (...) {
1749             bool rethrow;
1750             try {
1751                 strm.setstate (ios::badbit);
1752                 rethrow = false;
1753             }
1754             catch (...) {
1755                 rethrow = true;
1756             }
1757             if (rethrow)
1758                 throw;
1759         }
1760         if (err)
1761             strm.setstate (err);
1762     }
1763     return strm;
1764 }
1765 </pre>
1766 </blockquote>
1767
1768 <p>
1769 [3] Extractor that catches exceptions thrown from sentry
1770 but doesn't set badbit if the exception was thrown as a
1771 result of a call to strm.clear().
1772 </p>
1773
1774 <blockquote>
1775 <pre>istream&amp; operator&gt;&gt; (istream &amp;strm, S &amp;s)
1776 {
1777     const ios::iostate state = strm.rdstate ();
1778     const ios::iostate except = strm.exceptions ();
1779     ios::iostate err = std::ios::goodbit;
1780     bool thrown = true;
1781     try {
1782         const istream::sentry guard (strm, false);
1783         thrown = false;
1784         if (guard) {
1785             use_facet&lt;num_get&lt;char&gt; &gt;(strm.getloc ())
1786                 .get (istreambuf_iterator&lt;char&gt;(strm),
1787                       istreambuf_iterator&lt;char&gt;(),
1788                       strm, err, s.i);
1789         }
1790     }
1791     catch (...) {
1792         if (thrown &amp;&amp; state &amp; except)
1793             throw;
1794         try {
1795             strm.setstate (ios::badbit);
1796             thrown = false;
1797         }
1798         catch (...) {
1799             thrown = true;
1800         }
1801         if (thrown)
1802             throw;
1803     }
1804     if (err)
1805         strm.setstate (err);
1806
1807     return strm;
1808 }
1809 </pre>
1810 </blockquote>
1811
1812 <p>
1813 [Pre-Berlin] Reopened at the request of Paolo Carlini and Steve Clamage.
1814 </p>
1815
1816 <p>
1817 [Pre-Portland] A relevant newsgroup post:
1818 </p>
1819
1820 <p>
1821 The current proposed resolution of issue #309
1822 (http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309)  is
1823 unacceptable.   I write commerical software and coding around this
1824 makes my code ugly, non-intuitive, and requires comments referring
1825 people to this very issue.   Following is the full explanation of my
1826 experience.
1827 </p>
1828 <p>
1829 In the course of writing software for commercial use, I constructed
1830 std::ifstream's based on user-supplied pathnames on typical POSIX
1831 systems.
1832 </p>
1833 <p>
1834 It was expected that some files that opened successfully might not read
1835 successfully -- such as a pathname which actually refered to a
1836 directory.   Intuitively, I expected the streambuffer underflow() code
1837 to throw an exception in this situation, and recent implementations of
1838 libstdc++'s basic_filebuf do just that (as well as many of my own
1839 custom streambufs).
1840 </p>
1841 <p>
1842 I also intuitively expected that the istream code would convert these
1843 exceptions to the "badbit' set on the stream object, because I had not
1844 requested exceptions.    I refer to 27.6.1.1. P4.
1845 </p>
1846 <p>
1847 However, this was not the case on at least two implementations -- if
1848 the first thing I did with an istream was call operator&gt;&gt;( T&amp; ) for T
1849 among the basic arithmetic types and std::string.   Looking further I
1850 found that the sentry's constructor was invoking the exception when it
1851 pre-scanned for whitespace, and the extractor function (operator&gt;&gt;())
1852 was not catching exceptions in this situation.
1853 </p>
1854 <p>
1855 So, I was in a situation where setting 'noskipws' would change the
1856 istream's behavior even though no characters (whitespace or not) could
1857 ever be successfully read.
1858 </p>
1859 <p>
1860 Also, calling .peek() on the istream before calling the extractor()
1861 changed the behavior (.peek() had the effect of setting the badbit
1862 ahead of time).
1863 </p>
1864 <p>
1865 I found this all to be so inconsistent and inconvenient for me and my
1866 code design, that I filed a bugzilla entry for libstdc++.   I was then
1867 told that the bug cannot be fixed until issue #309 is resolved by the
1868 committee.
1869 </p>
1870
1871
1872
1873 <p><b>Proposed resolution:</b></p>
1874
1875
1876 <p><b>Rationale:</b></p>
1877 <p>The LWG agrees there is minor variation between implementations,
1878   but believes that it doesn't matter. This is a rarely used corner
1879   case. There is no evidence that this has any commercial importance
1880   or that it causes actual portability problems for customers trying
1881   to write code that runs on multiple implementations.</p>
1882
1883
1884
1885
1886
1887 <hr>
1888 <h3><a name="342"></a>342. seek and eofbit</h3>
1889 <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>
1890  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2001-10-09</p>
1891 <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>
1892 <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>
1893 <p><b>Discussion:</b></p>
1894 <p>I think we have a defect.</p>
1895
1896 <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
1897 description of seekg in 27.6.1.3 [istream.unformatted] paragraph 38 now looks
1898 like:</p>
1899
1900 <blockquote><p>
1901 Behaves as an unformatted input function (as described in 27.6.1.3,
1902 paragraph 1), except that it does not count the number of characters
1903 extracted and does not affect the value returned by subsequent calls to
1904 gcount(). After constructing a sentry object, if fail() != true,
1905 executes rdbuf()-&gt;pubseekpos( pos).
1906 </p></blockquote>
1907
1908 <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,
1909 27.6.1.3, paragraph 1 looks like:</p>
1910
1911 <blockquote><p>
1912 Each unformatted input function begins execution by constructing an
1913 object of class sentry with the default argument noskipws (second)
1914 argument true. If the sentry object returns true, when converted to a
1915 value of type bool, the function endeavors to obtain the requested
1916 input.  Otherwise, if the sentry constructor exits by throwing an
1917 exception or if the sentry object returns false, when converted to a
1918 value of type bool, the function returns without attempting to obtain
1919 any input. In either case the number of extracted characters is set to
1920 0; unformatted input functions taking a character array of non-zero
1921 size as an argument shall also store a null character (using charT())
1922 in the first location of the array. If an exception is thrown during
1923 input then ios::badbit is turned on in *this'ss error state. If
1924 (exception()&amp;badbit)!= 0 then the exception is rethrown. It also counts
1925 the number of characters extracted. If no exception has been thrown it
1926 ends by storing the count in a member object and returning the value
1927 specified. In any event the sentry object is destroyed before leaving
1928 the unformatted input function.
1929 </p></blockquote>
1930
1931 <p>And finally 27.6.1.1.2/5 says this about sentry:</p>
1932
1933 <blockquote><p>
1934 If, after any preparation is completed, is.good() is true, ok_ != false
1935 otherwise, ok_ == false.
1936 </p></blockquote>
1937
1938 <p>
1939 So although the seekg paragraph says that the operation proceeds if
1940 !fail(), the behavior of unformatted functions says the operation
1941 proceeds only if good().  The two statements are contradictory when only
1942 eofbit is set.  I don't think the current text is clear which condition
1943 should be respected.
1944 </p>
1945
1946 <p><b>Further discussion from Redmond:</b></p>
1947
1948 <p>PJP: It doesn't seem quite right to say that <tt>seekg</tt> is
1949 "unformatted". That makes specific claims about sentry that
1950 aren't quite appropriate for seeking, which has less fragile failure
1951 modes than actual input.  If we do really mean that it's unformatted
1952 input, it should behave the same way as other unformatted input.  On
1953 the other hand, "principle of least surprise" is that seeking from EOF
1954 ought to be OK.</p>
1955
1956 <p>
1957 Pre-Berlin:  Paolo points out several problems with the proposed resolution in
1958 Ready state:
1959 </p>
1960
1961 <ul>
1962 <li>It should apply to both overloads of seekg.</li>
1963 <li>tellg has similar issues, except that it should not call clear().</li>
1964 <li>The point about clear() seems to apply to seekp().</li>
1965 <li>Depending on the outcome of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#419">419</a>
1966 if the sentry
1967 sets <tt>failbit</tt> when it finds <tt>eofbit</tt> already set, then
1968 you can never seek away from the end of stream.</li>
1969 </ul>
1970
1971
1972
1973 <p><b>Proposed resolution:</b></p>
1974
1975 <p>Change 27.6.1.3 [istream.unformatted] to:</p>
1976 <blockquote><p>
1977 Behaves as an unformatted input function (as described in 27.6.1.3,
1978 paragraph 1), except that it does not count the number of characters
1979 extracted, does not affect the value returned by subsequent calls to
1980 gcount(), and does not examine the value returned by the sentry
1981 object. After constructing a sentry object, if <tt>fail() !=
1982 true</tt>, executes <tt>rdbuf()-&gt;pubseekpos(pos)</tt>.  In
1983 case of success, the function calls clear().
1984 In case of failure, the function calls <tt>setstate(failbit)</tt>
1985 (which may throw <tt>ios_base::failure</tt>).
1986 </p></blockquote>
1987
1988 <p><i>[Lillehammer: Matt provided wording.]</i></p>
1989
1990
1991
1992
1993 <p><b>Rationale:</b></p>
1994 <p>In C, fseek does clear EOF.  This is probably what most users would
1995   expect.  We agree that having eofbit set should not deter a seek,
1996   and that a successful seek should clear eofbit. Note
1997   that <tt>fail()</tt> is true only if <tt>failbit</tt>
1998   or <tt>badbit</tt> is set, so using <tt>!fail()</tt>, rather
1999   than <tt>good()</tt>, satisfies this goal.</p>
2000
2001
2002
2003
2004
2005 <hr>
2006 <h3><a name="343"></a>343. Unspecified library header dependencies</h3>
2007 <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>
2008  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-10-09</p>
2009 <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>
2010 <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>
2011 <p><b>Discussion:</b></p>
2012 <p>
2013 The synopses of the C++ library headers clearly show which names are
2014 required to be defined in each header. Since in order to implement the
2015 classes and templates defined in these headers declarations of other
2016 templates (but not necessarily their definitions) are typically
2017 necessary the standard in 17.4.4, p1 permits library implementers to
2018 include any headers needed to implement the definitions in each header.
2019 </p>
2020
2021 <p>
2022 For instance, although it is not explicitly specified in the synopsis of
2023 &lt;string&gt;, at the point of definition of the std::basic_string template
2024 the declaration of the std::allocator template must be in scope. All
2025 current implementations simply include &lt;memory&gt; from within &lt;string&gt;,
2026 either directly or indirectly, to bring the declaration of
2027 std::allocator into scope.
2028 </p>
2029
2030 <p>
2031 Additionally, however, some implementation also include &lt;istream&gt; and
2032 &lt;ostream&gt; at the top of &lt;string&gt; to bring the declarations of
2033 std::basic_istream and std::basic_ostream into scope (which are needed
2034 in order to implement the string inserter and extractor operators
2035 (21.3.7.9 [lib.string.io])). Other implementations only include
2036 &lt;iosfwd&gt;, since strictly speaking, only the declarations and not the
2037 full definitions are necessary.
2038 </p>
2039
2040 <p>
2041 Obviously, it is possible to implement &lt;string&gt; without actually
2042 providing the full definitions of all the templates std::basic_string
2043 uses (std::allocator, std::basic_istream, and std::basic_ostream).
2044 Furthermore, not only is it possible, doing so is likely to have a
2045 positive effect on compile-time efficiency.
2046 </p>
2047
2048 <p>
2049 But while it may seem perfectly reasonable to expect a program that uses
2050 the std::basic_string insertion and extraction operators to also
2051 explicitly include &lt;istream&gt; or &lt;ostream&gt;, respectively, it doesn't seem
2052 reasonable to also expect it to explicitly include &lt;memory&gt;. Since
2053 what's reasonable and what isn't is highly subjective one would expect
2054 the standard to specify what can and what cannot be assumed.
2055 Unfortunately, that isn't the case.
2056 </p>
2057
2058 <p>The examples below demonstrate the issue.</p>
2059
2060 <p>Example 1:</p>
2061
2062 <p>It is not clear whether the following program is complete:</p>
2063
2064 <pre>#include &lt;string&gt;
2065
2066 extern std::basic_ostream&lt;char&gt; &amp;strm;
2067
2068 int main () {
2069     strm &lt;&lt; std::string ("Hello, World!\n");
2070 }
2071 </pre>
2072
2073 <p>or whether one must explicitly include &lt;memory&gt; or
2074 &lt;ostream&gt; (or both) in addition to &lt;string&gt; in order for
2075 the program to compile.</p>
2076
2077
2078 <p>Example 2:</p>
2079
2080 <p>Similarly, it is unclear whether the following program is complete:</p>
2081
2082 <pre>#include &lt;istream&gt;
2083
2084 extern std::basic_iostream&lt;char&gt; &amp;strm;
2085
2086 int main () {
2087     strm &lt;&lt; "Hello, World!\n";
2088 }
2089 </pre>
2090
2091 <p>
2092 or whether one needs to explicitly include &lt;ostream&gt;, and
2093 perhaps even other headers containing the definitions of other
2094 required templates:</p>
2095
2096 <pre>#include &lt;ios&gt;
2097 #include &lt;istream&gt;
2098 #include &lt;ostream&gt;
2099 #include &lt;streambuf&gt;
2100
2101 extern std::basic_iostream&lt;char&gt; &amp;strm;
2102
2103 int main () {
2104     strm &lt;&lt; "Hello, World!\n";
2105 }
2106 </pre>
2107
2108 <p>Example 3:</p>
2109
2110 <p>Likewise, it seems unclear whether the program below is complete:</p>
2111 <pre>#include &lt;iterator&gt;
2112
2113 bool foo (std::istream_iterator&lt;int&gt; a, std::istream_iterator&lt;int&gt; b)
2114 {
2115     return a == b;
2116 }
2117
2118 int main () { }
2119 </pre>
2120
2121 <p>or whether one should be required to include &lt;istream&gt;.</p>
2122
2123 <p>There are many more examples that demonstrate this lack of a
2124 requirement.  I believe that in a good number of cases it would be
2125 unreasonable to require that a program explicitly include all the
2126 headers necessary for a particular template to be specialized, but I
2127 think that there are cases such as some of those above where it would
2128 be desirable to allow implementations to include only as much as
2129 necessary and not more.</p>
2130
2131 <p><i>[
2132 post Bellevue:
2133 ]</i></p>
2134
2135
2136 <blockquote>
2137 Position taken in prior reviews is that the idea of a table of header
2138 dependencies is a good one. Our view is that a full paper is needed to
2139 do justice to this, and we've made that recommendation to the issue
2140 author.
2141 </blockquote>
2142
2143
2144
2145 <p><b>Proposed resolution:</b></p>
2146 <p>
2147 For every C++ library header, supply a minimum set of other C++ library
2148 headers that are required to be included by that header. The proposed
2149 list is below (C++ headers for C Library Facilities, table 12 in
2150 17.4.1.2, p3, are omitted):
2151 </p>
2152
2153 <pre>+------------+--------------------+
2154 | C++ header |required to include |
2155 +============+====================+
2156 |&lt;algorithm&gt; |                    |
2157 +------------+--------------------+
2158 |&lt;bitset&gt;    |                    |
2159 +------------+--------------------+
2160 |&lt;complex&gt;   |                    |
2161 +------------+--------------------+
2162 |&lt;deque&gt;     |&lt;memory&gt;            |
2163 +------------+--------------------+
2164 |&lt;exception&gt; |                    |
2165 +------------+--------------------+
2166 |&lt;fstream&gt;   |&lt;ios&gt;               |
2167 +------------+--------------------+
2168 |&lt;functional&gt;|                    |
2169 +------------+--------------------+
2170 |&lt;iomanip&gt;   |&lt;ios&gt;               |
2171 +------------+--------------------+
2172 |&lt;ios&gt;       |&lt;streambuf&gt;         |
2173 +------------+--------------------+
2174 |&lt;iosfwd&gt;    |                    |
2175 +------------+--------------------+
2176 |&lt;iostream&gt;  |&lt;istream&gt;, &lt;ostream&gt;|
2177 +------------+--------------------+
2178 |&lt;istream&gt;   |&lt;ios&gt;               |
2179 +------------+--------------------+
2180 |&lt;iterator&gt;  |                    |
2181 +------------+--------------------+
2182 |&lt;limits&gt;    |                    |
2183 +------------+--------------------+
2184 |&lt;list&gt;      |&lt;memory&gt;            |
2185 +------------+--------------------+
2186 |&lt;locale&gt;    |                    |
2187 +------------+--------------------+
2188 |&lt;map&gt;       |&lt;memory&gt;            |
2189 +------------+--------------------+
2190 |&lt;memory&gt;    |                    |
2191 +------------+--------------------+
2192 |&lt;new&gt;       |&lt;exception&gt;         |
2193 +------------+--------------------+
2194 |&lt;numeric&gt;   |                    |
2195 +------------+--------------------+
2196 |&lt;ostream&gt;   |&lt;ios&gt;               |
2197 +------------+--------------------+
2198 |&lt;queue&gt;     |&lt;deque&gt;             |
2199 +------------+--------------------+
2200 |&lt;set&gt;       |&lt;memory&gt;            |
2201 +------------+--------------------+
2202 |&lt;sstream&gt;   |&lt;ios&gt;, &lt;string&gt;     |
2203 +------------+--------------------+
2204 |&lt;stack&gt;     |&lt;deque&gt;             |
2205 +------------+--------------------+
2206 |&lt;stdexcept&gt; |                    |
2207 +------------+--------------------+
2208 |&lt;streambuf&gt; |&lt;ios&gt;               |
2209 +------------+--------------------+
2210 |&lt;string&gt;    |&lt;memory&gt;            |
2211 +------------+--------------------+
2212 |&lt;strstream&gt; |                    |
2213 +------------+--------------------+
2214 |&lt;typeinfo&gt;  |&lt;exception&gt;         |
2215 +------------+--------------------+
2216 |&lt;utility&gt;   |                    |
2217 +------------+--------------------+
2218 |&lt;valarray&gt;  |                    |
2219 +------------+--------------------+
2220 |&lt;vector&gt;    |&lt;memory&gt;            |
2221 +------------+--------------------+
2222 </pre>
2223
2224
2225 <p><b>Rationale:</b></p>
2226 <p>The portability problem is real.  A program that works correctly on
2227 one implementation might fail on another, because of different header
2228 dependencies.  This problem was understood before the standard was
2229 completed, and it was a conscious design choice.</p>
2230 <p>One possible way to deal with this, as a library extension, would
2231 be an &lt;all&gt; header.</p>
2232
2233 <p>
2234 Hinnant:  It's time we dealt with this issue for C++0X.  Reopened.
2235 </p>
2236
2237
2238
2239
2240
2241
2242
2243 <hr>
2244 <h3><a name="382"></a>382. codecvt do_in/out result</h3>
2245 <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>
2246  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-08-30</p>
2247 <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>
2248 <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>
2249 <p><b>Discussion:</b></p>
2250 <p>
2251 It seems that the descriptions of codecvt do_in() and do_out() leave
2252 sufficient room for interpretation so that two implementations of
2253 codecvt may not work correctly with the same filebuf. Specifically,
2254 the following seems less than adequately specified:
2255 </p>
2256
2257 <ol>
2258 <li>
2259   the conditions under which the functions terminate
2260 </li>
2261 <li>
2262   precisely when the functions return ok
2263 </li>
2264 <li>
2265   precisely when the functions return partial
2266 </li>
2267 <li>
2268   the full set of conditions when the functions return error
2269 </li>
2270 </ol>
2271
2272 <ol>
2273 <li>
2274    22.2.1.4.2 [locale.codecvt.virtuals], p2 says this about the effects of the
2275    function: ...Stops if it encounters a character it cannot
2276    convert...  This assumes that there *is* a character to
2277    convert. What happens when there is a sequence that doesn't form a
2278    valid source character, such as an unassigned or invalid UNICODE
2279    character, or a sequence that cannot possibly form a character
2280    (e.g., the sequence "\xc0\xff" in UTF-8)?
2281 </li>
2282 <li>
2283    Table 53 says that the function returns codecvt_base::ok
2284    to indicate that the function(s) "completed the conversion."
2285    Suppose that the source sequence is "\xc0\x80" in UTF-8,
2286    with from pointing to '\xc0' and (from_end==from + 1).
2287    It is not clear whether the return value should be ok
2288    or partial (see below).
2289 </li>
2290 <li>
2291    Table 53 says that the function returns codecvt_base::partial
2292    if "not all source characters converted." With the from pointers
2293    set up the same way as above, it is not clear whether the return
2294    value should be partial or ok (see above).
2295 </li>
2296 <li>
2297    Table 53, in the row describing the meaning of error mistakenly
2298    refers to a "from_type" character, without the symbol from_type
2299    having been defined. Most likely, the word "source" character
2300    is intended, although that is not sufficient. The functions
2301    may also fail when they encounter an invalid source sequence
2302    that cannot possibly form a valid source character (e.g., as
2303    explained in bullet 1 above).
2304 </li>
2305 </ol>
2306 <p>
2307 Finally, the conditions described at the end of 22.2.1.4.2 [locale.codecvt.virtuals], p4 don't seem to be possible:
2308 </p>
2309 <blockquote><p>
2310     "A return value of partial, if (from_next == from_end),
2311     indicates that either the destination sequence has not
2312     absorbed all the available destination elements, or that
2313     additional source elements are needed before another
2314     destination element can be produced."
2315 </p></blockquote>
2316 <p>
2317 If the value is partial, it's not clear to me that (from_next
2318 ==from_end) could ever hold if there isn't enough room
2319 in the destination buffer. In order for (from_next==from_end) to
2320 hold, all characters in that range must have been successfully
2321 converted (according to 22.2.1.4.2 [locale.codecvt.virtuals], p2) and since there are no
2322 further source characters to convert, no more room in the
2323 destination buffer can be needed.
2324 </p>
2325 <p>
2326 It's also not clear to me that (from_next==from_end) could ever
2327 hold if additional source elements are needed to produce another
2328 destination character (not element as incorrectly stated in the
2329 text). partial is returned if "not all source characters have
2330 been converted" according to Table 53, which also implies that
2331 (from_next==from) does NOT hold.
2332 </p>
2333 <p>
2334 Could it be that the intended qualifying condition was actually
2335 (from_next != from_end), i.e., that the sentence was supposed
2336 to read
2337 </p>
2338 <blockquote><p>
2339     "A return value of partial, if (from_next != from_end),..."
2340 </p></blockquote>
2341 <p>
2342 which would make perfect sense, since, as far as I understand it,
2343 partial can only occur if (from_next != from_end)?
2344 </p>
2345 <p><i>[Lillehammer: Defer for the moment, but this really needs to be
2346   fixed. Right now, the description of codecvt is too vague for it to
2347   be a useful contract between providers and clients of codecvt
2348   facets.  (Note that both vendors and users can be both providers and
2349   clients of codecvt facets.) The major philosophical issue is whether
2350   the standard should only describe mappings that take a single wide
2351   character to multiple narrow characters (and vice versa), or whether
2352   it should describe fully general N-to-M conversions. When the
2353   original standard was written only the former was contemplated, but
2354   today, in light of the popularity of utf8 and utf16, that doesn't
2355   seem sufficient for C++0x. Bill supports general N-to-M conversions;
2356   we need to make sure Martin and Howard agree.]</i></p>
2357
2358
2359
2360 <p><b>Proposed resolution:</b></p>
2361
2362
2363
2364
2365 <hr>
2366 <h3><a name="387"></a>387. std::complex over-encapsulated</h3>
2367 <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>
2368  <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2002-11-08</p>
2369 <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>
2370 <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>
2371 <p><b>Discussion:</b></p>
2372 <p>
2373 The absence of explicit description of std::complex&lt;T&gt; layout
2374 makes it imposible to reuse existing software developed in traditional
2375 languages like Fortran or C with unambigous and commonly accepted
2376 layout assumptions.  There ought to be a way for practitioners to
2377 predict with confidence the layout of std::complex&lt;T&gt; whenever T
2378 is a numerical datatype.  The absence of ways to access individual
2379 parts of a std::complex&lt;T&gt; object as lvalues unduly promotes
2380 severe pessimizations. For example, the only way to change,
2381 independently, the real and imaginary parts is to write something like
2382 </p>
2383
2384 <pre>complex&lt;T&gt; z;
2385 // ...
2386 // set the real part to r
2387 z = complex&lt;T&gt;(r, z.imag());
2388 // ...
2389 // set the imaginary part to i
2390 z = complex&lt;T&gt;(z.real(), i);
2391 </pre>
2392
2393 <p>
2394 At this point, it seems appropriate to recall that a complex number
2395 is, in effect, just a pair of numbers with no particular invariant to
2396 maintain.  Existing practice in numerical computations has it that a
2397 complex number datatype is usually represented by Cartesian
2398 coordinates. Therefore the over-encapsulation put in the specification
2399 of std::complex&lt;&gt; is not justified.
2400 </p>
2401
2402
2403
2404 <p><b>Proposed resolution:</b></p>
2405 <p>Add the following requirements to 26.3 [complex.numbers] as 26.3/4:</p>
2406 <blockquote>
2407 <p>If z is an lvalue expression of type cv std::complex&lt;T&gt; then</p>
2408
2409 <ul>
2410 <li>the expression reinterpret_cast&lt;cv T(&amp;)[2]&gt;(z)
2411 is well-formed; and</li>
2412 <li>reinterpret_cast&lt;cv T(&amp;)[2]&gt;(z)[0]designates the
2413 real part of z; and</li>
2414 <li>reinterpret_cast&lt;cv T(&amp;)[2]&gt;(z)[1]designates the
2415 imaginary part of z.</li>
2416 </ul>
2417
2418 <p>
2419 Moreover, if a is an expression of pointer type cv complex&lt;T&gt;*
2420 and the expression a[i] is well-defined for an integer expression
2421 i then:
2422 </p>
2423
2424 <ul>
2425 <li>reinterpret_cast&lt;cv T*&gt;(a)[2*i] designates the real
2426 part of a[i]; and</li>
2427 <li>reinterpret_cast&lt;cv T*&gt;(a)[2*i+1] designates the
2428 imaginary part of a[i].</li>
2429 </ul>
2430 </blockquote>
2431
2432 <p>
2433 In 26.3.2 [complex] and 26.3.3 [complex.special] add the following member functions
2434 (changing <tt>T</tt> to concrete types as appropriate for the specializations).
2435 </p>
2436
2437 <blockquote><pre>void real(T);
2438 void imag(T);
2439 </pre></blockquote>
2440
2441 <p>
2442 Add to 26.3.4 [complex.members]
2443 </p>
2444
2445 <blockquote>
2446 <pre>T real() const;
2447 </pre>
2448 <blockquote>
2449 <i>Returns:</i> the value of the real component
2450 </blockquote>
2451 <pre>void real(T val);
2452 </pre>
2453 <blockquote>
2454 Assigns val to the real component.
2455 </blockquote>
2456 <pre>T imag() const;
2457 </pre>
2458 <blockquote>
2459 <i>Returns:</i> the value of the imaginary component
2460 </blockquote>
2461 <pre>void imag(T val);
2462 </pre>
2463 <blockquote>
2464 Assigns val to the imaginary component.
2465 </blockquote>
2466 </blockquote>
2467
2468 <p><i>[Kona: The layout guarantee is absolutely necessary for C
2469   compatibility.  However, there was disagreement about the other part
2470   of this proposal: retrieving elements of the complex number as
2471   lvalues.  An alternative: continue to have real() and imag() return
2472   rvalues, but add set_real() and set_imag().  Straw poll: return
2473   lvalues - 2, add setter functions - 5.  Related issue: do we want
2474   reinterpret_cast as the interface for converting a complex to an
2475   array of two reals, or do we want to provide a more explicit way of
2476   doing it?  Howard will try to resolve this issue for the next
2477   meeting.]</i></p>
2478
2479
2480 <p><i>[pre-Sydney: Howard summarized the options in n1589.]</i></p>
2481
2482
2483 <p><i>[
2484 Bellevue:
2485 ]</i></p>
2486
2487
2488 <blockquote>
2489 Second half of proposed wording replaced and moved to Ready.
2490 </blockquote>
2491
2492 <p><i>[
2493 Pre-Sophia Antipolis, Howard adds:
2494 ]</i></p>
2495
2496
2497 <blockquote>
2498 Added the members to 26.3.3 [complex.special] and changed from Ready to Review.
2499 </blockquote>
2500
2501 <p><i>[
2502 Post-Sophia Antipolis:
2503 ]</i></p>
2504
2505
2506 <blockquote>
2507 Moved from WP back to Ready so that the "and 26.3.3 [complex.special]" in the proposed
2508 resolution can be officially applied.
2509 </blockquote>
2510
2511
2512
2513 <p><b>Rationale:</b></p>
2514 <p>The LWG believes that C99 compatibility would be enough
2515 justification for this change even without other considerations.  All
2516 existing implementations already have the layout proposed here.</p>
2517
2518
2519
2520
2521
2522 <hr>
2523 <h3><a name="394"></a>394. behavior of formatted output on failure</h3>
2524 <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>
2525  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-12-27</p>
2526 <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>
2527 <p><b>Discussion:</b></p>
2528 <p>
2529 There is a contradiction in Formatted output about what bit is
2530 supposed to be set if the formatting fails. On sentence says it's
2531 badbit and another that it's failbit.
2532 </p>
2533 <p>
2534 27.6.2.5.1, p1 says in the Common Requirements on Formatted output
2535 functions:
2536 </p>
2537 <pre>     ... If the generation fails, then the formatted output function
2538      does setstate(ios::failbit), which might throw an exception.
2539 </pre>
2540 <p>
2541 27.6.2.5.2, p1 goes on to say this about Arithmetic Inserters:
2542 </p>
2543 <p>
2544      ... The formatting conversion occurs as if it performed the
2545      following code fragment:
2546 </p>
2547 <pre>     bool failed =
2548          use_facet&lt;num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt;
2549          &gt; &gt;
2550          (getloc()).put(*this, *this, fill(), val). failed();
2551
2552      ... If failed is true then does setstate(badbit) ...
2553 </pre>
2554 <p>
2555 The original intent of the text, according to Jerry Schwarz (see
2556 c++std-lib-10500), is captured in the following paragraph:
2557 </p>
2558 <p>
2559 In general "badbit" should mean that the stream is unusable because
2560 of some underlying failure, such as disk full or socket closure;
2561 "failbit" should mean that the requested formatting wasn't possible
2562 because of some inconsistency such as negative widths.  So typically
2563 if you clear badbit and try to output something else you'll fail
2564 again, but if you clear failbit and try to output something else
2565 you'll succeed.
2566 </p>
2567 <p>
2568 In the case of the arithmetic inserters, since num_put cannot
2569 report failure by any means other than exceptions (in response
2570 to which the stream must set badbit, which prevents the kind of
2571 recoverable error reporting mentioned above), the only other
2572 detectable failure is if the iterator returned from num_put
2573 returns true from failed().
2574 </p>
2575 <p>
2576 Since that can only happen (at least with the required iostream
2577 specializations) under such conditions as the underlying failure
2578 referred to above (e.g., disk full), setting badbit would seem
2579 to be the appropriate response (indeed, it is required in
2580 27.6.2.5.2, p1). It follows that failbit can never be directly
2581 set by the arithmetic (it can only be set by the sentry object
2582 under some unspecified conditions).
2583 </p>
2584 <p>
2585 The situation is different for other formatted output functions
2586 which can fail as a result of the streambuf functions failing
2587 (they may do so by means other than exceptions), and which are
2588 then required to set failbit.
2589 </p>
2590 <p>
2591 The contradiction, then, is that ostream::operator&lt;&lt;(int) will
2592 set badbit if the disk is full, while operator&lt;&lt;(ostream&amp;,
2593 char) will set failbit under the same conditions. To make the behavior
2594 consistent, the Common requirements sections for the Formatted output
2595 functions should be changed as proposed below.
2596 </p>
2597 <p><i>[Kona: There's agreement that this is a real issue.  What we
2598   decided at Kona: 1. An error from the buffer (which can be detected
2599   either directly from streambuf's member functions or by examining a
2600   streambuf_iterator) should always result in badbit getting set.
2601   2. There should never be a circumstance where failbit gets set.
2602   That represents a formatting error, and there are no circumstances
2603   under which the output facets are specified as signaling a
2604   formatting error. (Even more so for string output that for numeric
2605   because there's nothing to format.)  If we ever decide to make it
2606   possible for formatting errors to exist then the facets can signal
2607   the error directly, and that should go in clause 22, not clause 27.
2608   3. The phrase "if generation fails" is unclear and should be
2609   eliminated.  It's not clear whether it's intended to mean a buffer
2610   error (e.g. a full disk), a formatting error, or something else.
2611   Most people thought it was supposed to refer to buffer errors; if
2612   so, we should say so.  Martin will provide wording.]</i></p>
2613
2614
2615
2616
2617 <p><b>Proposed resolution:</b></p>
2618
2619
2620 <p><b>Rationale:</b></p>
2621
2622
2623
2624
2625
2626
2627 <hr>
2628 <h3><a name="396"></a>396. what are characters zero and one</h3>
2629 <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>
2630  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-01-05</p>
2631 <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>
2632 <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>
2633 <p><b>Discussion:</b></p>
2634     <p>
2635 23.3.5.1, p6 [lib.bitset.cons] talks about a generic character
2636 having the value of 0 or 1 but there is no definition of what
2637 that means for charT other than char and wchar_t. And even for
2638 those two types, the values 0 and 1 are not actually what is
2639 intended -- the values '0' and '1' are. This, along with the
2640 converse problem in the description of to_string() in 23.3.5.2,
2641 p33, looks like a defect remotely related to DR 303.
2642     </p>
2643     <p>
2644 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#303
2645     </p>
2646     <pre>23.3.5.1:
2647   -6-  An element of the constructed string has value zero if the
2648        corresponding character in str, beginning at position pos,
2649        is 0. Otherwise, the element has the value one.
2650     </pre>
2651     <pre>23.3.5.2:
2652   -33-  Effects: Constructs a string object of the appropriate
2653         type and initializes it to a string of length N characters.
2654         Each character is determined by the value of its
2655         corresponding bit position in *this. Character position N
2656         ?- 1 corresponds to bit position zero. Subsequent decreasing
2657         character positions correspond to increasing bit positions.
2658         Bit value zero becomes the character 0, bit value one becomes
2659         the character 1.
2660     </pre>
2661     <p>
2662 Also note the typo in 23.3.5.1, p6: the object under construction
2663 is a bitset, not a string.
2664     </p>
2665
2666 <p><i>[
2667 Sophia Antipolis:
2668 ]</i></p>
2669
2670
2671 <blockquote>
2672 <p>
2673 We note that <tt>bitset</tt> has been moved from section 23 to section 20, by
2674 another issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#842">842</a>) previously resolved at this meeting.
2675 </p>
2676 <p>
2677 Disposition: move to ready.
2678 </p>
2679 <p>
2680 We request that Howard submit a separate issue regarding the three to_string overloads.
2681 </p>
2682 </blockquote>
2683
2684
2685
2686 <p><b>Proposed resolution:</b></p>
2687 <p>Change the constructor's function declaration immediately before
2688 23.3.5.1 [bitset.cons] p3 to:</p>
2689 <pre>    template &lt;class charT, class traits, class Allocator&gt;
2690     explicit
2691     bitset(const basic_string&lt;charT, traits, Allocator&gt;&amp; str,
2692            typename basic_string&lt;charT, traits, Allocator&gt;::size_type pos = 0,
2693            typename basic_string&lt;charT, traits, Allocator&gt;::size_type n =
2694              basic_string&lt;charT, traits, Allocator&gt;::npos,
2695            charT zero = charT('0'), charT one = charT('1'))
2696 </pre>
2697 <p>Change the first two sentences of 23.3.5.1 [bitset.cons] p6 to: "An
2698 element of the constructed string has value 0 if the corresponding
2699 character in <i>str</i>, beginning at position <i>pos</i>,
2700 is <i>zero</i>. Otherwise, the element has the value 1.</p>
2701
2702 <p>Change the text of the second sentence in 23.3.5.1, p5 to read:
2703     "The function then throws invalid_argument if any of the rlen
2704     characters in str beginning at position pos is other than <i>zero</i>
2705     or <i>one</i>. The function uses traits::eq() to compare the character
2706     values."
2707 </p>
2708
2709 <p>Change the declaration of the <tt>to_string</tt> member function
2710   immediately before 23.3.5.2 [bitset.members] p33 to:</p>
2711 <pre>    template &lt;class charT, class traits, class Allocator&gt;
2712     basic_string&lt;charT, traits, Allocator&gt;
2713     to_string(charT zero = charT('0'), charT one = charT('1')) const;
2714 </pre>
2715 <p>Change the last sentence of 23.3.5.2 [bitset.members] p33 to: "Bit
2716   value 0 becomes the character <tt><i>zero</i></tt>, bit value 1 becomes the
2717   character <tt><i>one</i></tt>.</p>
2718 <p>Change 23.3.5.3 [bitset.operators] p8 to:</p>
2719 <p><b>Returns</b>:</p>
2720 <pre>  os &lt;&lt; x.template to_string&lt;charT,traits,allocator&lt;charT&gt; &gt;(
2721       use_facet&lt;ctype&lt;charT&gt; &gt;(<i>os</i>.getloc()).widen('0'),
2722       use_facet&lt;ctype&lt;charT&gt; &gt;(<i>os</i>.getloc()).widen('1'));
2723 </pre>
2724
2725
2726 <p><b>Rationale:</b></p>
2727 <p>There is a real problem here: we need the character values of '0'
2728   and '1', and we have no way to get them since strings don't have
2729   imbued locales. In principle the "right" solution would be to
2730   provide an extra object, either a ctype facet or a full locale,
2731   which would be used to widen '0' and '1'. However, there was some
2732   discomfort about using such a heavyweight mechanism.  The proposed
2733   resolution allows those users who care about this issue to get it
2734   right.</p>
2735 <p>We fix the inserter to use the new arguments.  Note that we already
2736   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>
2737
2738
2739
2740 <p><i>[
2741 post Bellevue:
2742 ]</i></p>
2743
2744
2745 <blockquote>
2746 We are happy with the resolution as proposed, and we move this to Ready.
2747 </blockquote>
2748
2749 <p><i>[
2750 Howard adds:
2751 ]</i></p>
2752
2753
2754 <blockquote>
2755 The proposed wording neglects the 3 newer to_string overloads.
2756 </blockquote>
2757
2758
2759
2760
2761 <hr>
2762 <h3><a name="397"></a>397. ostream::sentry dtor throws exceptions</h3>
2763 <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>
2764  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-01-05</p>
2765 <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>
2766 <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>
2767 <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>
2768 <p><b>Discussion:</b></p>
2769     <p>
2770 17.4.4.8, p3 prohibits library dtors from throwing exceptions.
2771     </p>
2772     <p>
2773 27.6.2.3, p4 says this about the ostream::sentry dtor:
2774     </p>
2775     <pre>    -4- If ((os.flags() &amp; ios_base::unitbuf) &amp;&amp; !uncaught_exception())
2776         is true, calls os.flush().
2777     </pre>
2778     <p>
2779 27.6.2.6, p7 that describes ostream::flush() says:
2780     </p>
2781     <pre>    -7- If rdbuf() is not a null pointer, calls rdbuf()-&gt;pubsync().
2782         If that function returns ?-1 calls setstate(badbit) (which
2783         may throw ios_base::failure (27.4.4.3)).
2784     </pre>
2785     <p>
2786 That seems like a defect, since both pubsync() and setstate() can
2787 throw an exception.
2788     </p>
2789 <p><i>[
2790 The contradiction is real.  Clause 17 says destructors may never
2791 throw exceptions, and clause 27 specifies a destructor that does
2792 throw.  In principle we might change either one.  We're leaning
2793 toward changing clause 17: putting in an "unless otherwise specified"
2794 clause, and then putting in a footnote saying the sentry destructor
2795 is the only one that can throw.  PJP suggests specifying that
2796 sentry::~sentry() should internally catch any exceptions it might cause.
2797 ]</i></p>
2798
2799
2800 <p><i>[
2801 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.
2802 ]</i></p>
2803
2804
2805
2806
2807 <p><b>Proposed resolution:</b></p>
2808
2809
2810
2811
2812
2813 <hr>
2814 <h3><a name="398"></a>398. effects of end-of-file on unformatted input functions</h3>
2815 <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>
2816  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-01-05</p>
2817 <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>
2818 <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>
2819 <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>
2820 <p><b>Discussion:</b></p>
2821     <p>
2822 While reviewing unformatted input member functions of istream
2823 for their behavior when they encounter end-of-file during input
2824 I found that the requirements vary, sometimes unexpectedly, and
2825 in more than one case even contradict established practice (GNU
2826 libstdc++ 3.2, IBM VAC++ 6.0, STLPort 4.5, SunPro 5.3, HP aCC
2827 5.38, Rogue Wave libstd 3.1, and Classic Iostreams).
2828     </p>
2829     <p>
2830 The following unformatted input member functions set eofbit if they
2831 encounter an end-of-file (this is the expected behavior, and also
2832 the behavior of all major implementations):
2833     </p>
2834     <pre>    basic_istream&lt;charT, traits&gt;&amp;
2835     get (char_type*, streamsize, char_type);
2836     </pre>
2837     <p>
2838     Also sets failbit if it fails to extract any characters.
2839     </p>
2840     <pre>    basic_istream&lt;charT, traits&gt;&amp;
2841     get (char_type*, streamsize);
2842     </pre>
2843     <p>
2844     Also sets failbit if it fails to extract any characters.
2845     </p>
2846     <pre>    basic_istream&lt;charT, traits&gt;&amp;
2847     getline (char_type*, streamsize, char_type);
2848     </pre>
2849     <p>
2850     Also sets failbit if it fails to extract any characters.
2851     </p>
2852     <pre>    basic_istream&lt;charT, traits&gt;&amp;
2853     getline (char_type*, streamsize);
2854     </pre>
2855     <p>
2856     Also sets failbit if it fails to extract any characters.
2857     </p>
2858     <pre>    basic_istream&lt;charT, traits&gt;&amp;
2859     ignore (int, int_type);
2860     </pre>
2861     <pre>    basic_istream&lt;charT, traits&gt;&amp;
2862     read (char_type*, streamsize);
2863     </pre>
2864     <p>
2865     Also sets failbit if it encounters end-of-file.
2866     </p>
2867     <pre>    streamsize readsome (char_type*, streamsize);
2868     </pre>
2869
2870     <p>
2871 The following unformated input member functions set failbit but
2872 not eofbit if they encounter an end-of-file (I find this odd
2873 since the functions make it impossible to distinguish a general
2874 failure from a failure due to end-of-file; the requirement is
2875 also in conflict with all major implementation which set both
2876 eofbit and failbit):
2877     </p>
2878     <pre>    int_type get();
2879     </pre>
2880     <pre>    basic_istream&lt;charT, traits&gt;&amp;
2881     get (char_type&amp;);
2882     </pre>
2883     <p>
2884 These functions only set failbit of they extract no characters,
2885 otherwise they don't set any bits, even on failure (I find this
2886 inconsistency quite unexpected; the requirement is also in
2887 conflict with all major implementations which set eofbit
2888 whenever they encounter end-of-file):
2889     </p>
2890     <pre>    basic_istream&lt;charT, traits&gt;&amp;
2891     get (basic_streambuf&lt;charT, traits&gt;&amp;, char_type);
2892     </pre>
2893     <pre>    basic_istream&lt;charT, traits&gt;&amp;
2894     get (basic_streambuf&lt;charT, traits&gt;&amp;);
2895     </pre>
2896     <p>
2897 This function sets no bits (all implementations except for
2898 STLport and Classic Iostreams set eofbit when they encounter
2899 end-of-file):
2900     </p>
2901     <pre>    int_type peek ();
2902     </pre>
2903 <p>Informally, what we want is a global statement of intent saying
2904   that eofbit gets set if we trip across EOF, and then we can take
2905   away the specific wording for individual functions.  A full review
2906   is necessary.  The wording currently in the standard is a mishmash,
2907   and changing it on an individual basis wouldn't make things better.
2908   Dietmar will do this work.</p>
2909
2910
2911 <p><b>Proposed resolution:</b></p>
2912
2913
2914
2915
2916 <hr>
2917 <h3><a name="408"></a>408. Is vector&lt;reverse_iterator&lt;char*&gt; &gt; forbidden?</h3>
2918 <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>
2919  <b>Submitter:</b> Nathan Myers <b>Date:</b> 2003-06-03</p>
2920 <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>
2921 <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>
2922 <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>
2923 <p><b>Discussion:</b></p>
2924 <p>
2925 I've been discussing iterator semantics with Dave Abrahams, and a
2926 surprise has popped up.  I don't think this has been discussed before.
2927 </p>
2928
2929 <p>
2930 24.1 [iterator.requirements] says that the only operation that can be performed on "singular"
2931 iterator values is to assign a non-singular value to them.  (It
2932 doesn't say they can be destroyed, and that's probably a defect.)
2933 Some implementations have taken this to imply that there is no need
2934 to initialize the data member of a reverse_iterator&lt;&gt; in the default
2935 constructor.  As a result, code like
2936 </p>
2937 <blockquote><pre>  std::vector&lt;std::reverse_iterator&lt;char*&gt; &gt; v(7);
2938   v.reserve(1000);
2939 </pre></blockquote>
2940 <p>
2941 invokes undefined behavior, because it must default-initialize the
2942 vector elements, and then copy them to other storage.  Of course many
2943 other vector operations on these adapters are also left undefined,
2944 and which those are is not reliably deducible from the standard.
2945 </p>
2946
2947 <p>
2948 I don't think that 24.1 was meant to make standard-library iterator
2949 types unsafe.  Rather, it was meant to restrict what operations may
2950 be performed by functions which take general user- and standard
2951 iterators as arguments, so that raw pointers would qualify as
2952 iterators.  However, this is not clear in the text, others have come
2953 to the opposite conclusion.
2954 </p>
2955
2956 <p>
2957 One question is whether the standard iterator adaptors have defined
2958 copy semantics.  Another is whether they have defined destructor
2959 semantics: is
2960 </p>
2961 <blockquote><pre>  { std::vector&lt;std::reverse_iterator&lt;char*&gt; &gt;  v(7); }
2962 </pre></blockquote>
2963 <p>
2964 undefined too?
2965 </p>
2966
2967 <p>
2968 Note this is not a question of whether algorithms are allowed to
2969 rely on copy semantics for arbitrary iterators, just whether the
2970 types we actually supply support those operations.  I believe the
2971 resolution must be expressed in terms of the semantics of the
2972 adapter's argument type.  It should make clear that, e.g., the
2973 reverse_iterator&lt;T&gt; constructor is actually required to execute
2974 T(), and so copying is defined if the result of T() is copyable.
2975 </p>
2976
2977 <p>
2978 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, which defines reverse_iterator's default
2979 constructor more precisely, has some relevance to this issue.
2980 However, it is not the whole story.
2981 </p>
2982
2983 <p>
2984 The issue was whether
2985 </p>
2986 <blockquote><pre>  reverse_iterator() { }
2987 </pre></blockquote>
2988 <p>
2989 is allowed, vs.
2990 </p>
2991 <blockquote><pre>  reverse_iterator() : current() { }
2992 </pre></blockquote>
2993
2994 <p>
2995 The difference is when T is char*, where the first leaves the member
2996 uninitialized, and possibly equal to an existing pointer value, or
2997 (on some targets) may result in a hardware trap when copied.
2998 </p>
2999
3000 <p>
3001 8.5 paragraph 5 seems to make clear that the second is required to
3002 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
3003 types.
3004 </p>
3005
3006 <p>
3007 But that only takes care of reverse_iterator, and doesn't establish
3008 a policy for all iterators.  (The reverse iterator adapter was just
3009 an example.)  In particular, does my function
3010 </p>
3011 <blockquote><pre>  template &lt;typename Iterator&gt;
3012     void f() { std::vector&lt;Iterator&gt;  v(7); }
3013 </pre></blockquote>
3014 <p>
3015 evoke undefined behavior for some conforming iterator definitions?
3016 I think it does, now, because vector&lt;&gt; will destroy those singular
3017 iterator values, and that's explicitly disallowed.
3018 </p>
3019
3020 <p>
3021 24.1 shouldn't give blanket permission to copy all singular iterators,
3022 because then pointers wouldn't qualify as iterators.  However, it
3023 should allow copying of that subset of singular iterator values that
3024 are default-initialized, and it should explicitly allow destroying any
3025 iterator value, singular or not, default-initialized or not.
3026 </p>
3027
3028 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#407">407</a></p>
3029 <p><i>[
3030 We don't want to require all singular iterators to be copyable,
3031 because that is not the case for pointers.  However, default
3032 construction may be a special case.  Issue: is it really default
3033 construction we want to talk about, or is it something like value
3034 initialization?  We need to check with core to see whether default
3035 constructed pointers are required to be copyable; if not, it would be
3036 wrong to impose so strict a requirement for iterators.
3037 ]</i></p>
3038
3039
3040
3041
3042 <p><b>Proposed resolution:</b></p>
3043
3044
3045
3046
3047
3048 <hr>
3049 <h3><a name="417"></a>417. what does ctype::do_widen() return on failure</h3>
3050 <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>
3051  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
3052 <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>
3053 <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>
3054 <p><b>Discussion:</b></p>
3055 <p>
3056 The Effects and Returns clauses of the do_widen() member function of
3057 the ctype facet fail to specify the behavior of the function on failure.
3058 That the function may not be able to simply cast the narrow character
3059 argument to the type of the result since doing so may yield the wrong value
3060 for some wchar_t encodings. Popular implementations of ctype&lt;wchar_t&gt; that
3061 use mbtowc() and UTF-8 as the native encoding (e.g., GNU glibc) will fail
3062 when the argument's MSB is set. There is no way for the the rest of locale
3063 and iostream to reliably detect this failure.
3064 </p>
3065 <p><i>[Kona: This is a real problem.  Widening can fail.  It's unclear
3066   what the solution should be.  Returning WEOF works for the wchar_t
3067   specialization, but not in general.  One option might be to add a
3068   default, like <i>narrow</i>.  But that's an incompatible change.
3069   Using <i>traits::eof</i> might seem like a good idea, but facets
3070   don't have access to traits (a recurring problem).  We could
3071   have <i>widen</i> throw an exception, but that's a scary option;
3072   existing library components aren't written with the assumption
3073   that <i>widen</i> can throw.]</i></p>
3074
3075
3076
3077 <p><b>Proposed resolution:</b></p>
3078
3079
3080
3081
3082 <hr>
3083 <h3><a name="418"></a>418. exceptions thrown during iostream cleanup</h3>
3084 <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>
3085  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
3086 <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>
3087 <p><b>Discussion:</b></p>
3088 <p>
3089 The dtor of the ios_base::Init object is supposed to call flush() on the
3090 6 standard iostream objects cout, cerr, clog, wcout, wcerr, and wclog.
3091 This call may cause an exception to be thrown.
3092 </p>
3093
3094 <p>
3095 17.4.4.8, p3 prohibits all library destructors from throwing exceptions.
3096 </p>
3097
3098 <p>
3099 The question is: What should this dtor do if one or more of these calls
3100 to flush() ends up throwing an exception? This can happen quite easily
3101 if one of the facets installed in the locale imbued in the iostream
3102 object throws.
3103 </p>
3104 <p><i>[Kona: We probably can't do much better than what we've got, so
3105   the LWG is leaning toward NAD.  At the point where the standard
3106   stream objects are being cleaned up, the usual error reporting
3107   mechanism are all unavailable.  And exception from flush at this
3108   point will definitely cause problems.  A quality implementation
3109   might reasonably swallow the exception, or call abort, or do
3110   something even more drastic.]</i></p>
3111
3112
3113 <p><i>[
3114 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.
3115 ]</i></p>
3116
3117
3118
3119
3120 <p><b>Proposed resolution:</b></p>
3121
3122
3123
3124
3125 <hr>
3126 <h3><a name="419"></a>419. istream extractors not setting failbit if eofbit is already set</h3>
3127 <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>
3128  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
3129 <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>
3130 <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>
3131 <p><b>Discussion:</b></p>
3132         <p>
3133
3134 27.6.1.1.3 [istream::sentry], p2 says that istream::sentry ctor prepares for input if is.good()
3135 is true. p4 then goes on to say that the ctor sets the sentry::ok_ member to
3136 true if the stream state is good after any preparation. 27.6.1.2.1 [istream.formatted.reqmts], p1 then
3137 says that a formatted input function endeavors to obtain the requested input
3138 if the sentry's operator bool() returns true.
3139
3140 Given these requirements, no formatted extractor should ever set failbit if
3141 the initial stream rdstate() == eofbit. That is contrary to the behavior of
3142 all implementations I tested. The program below prints out
3143
3144 eof = 1, fail = 0
3145 eof = 1, fail = 1
3146
3147 on all of them.
3148         </p>
3149 <pre>
3150 #include &lt;sstream&gt;
3151 #include &lt;cstdio&gt;
3152
3153 int main()
3154 {
3155     std::istringstream strm ("1");
3156
3157     int i = 0;
3158
3159     strm &gt;&gt; i;
3160
3161     std::printf ("eof = %d, fail = %d\n",
3162                  !!strm.eof (), !!strm.fail ());
3163
3164     strm &gt;&gt; i;
3165
3166     std::printf ("eof = %d, fail = %d\n",
3167                  !!strm.eof (), !!strm.fail ());
3168 }
3169
3170 </pre>
3171         <p>
3172 <br>
3173
3174 Comments from Jerry Schwarz (c++std-lib-11373):
3175 <br>
3176
3177 Jerry Schwarz wrote:
3178 <br>
3179
3180 I don't know where (if anywhere) it says it in the standard, but the
3181 formatted extractors are supposed to set failbit if they don't extract
3182 any characters. If they didn't then simple loops like
3183 <br>
3184
3185 while (cin &gt;&gt; x);
3186 <br>
3187
3188 would loop forever.
3189 <br>
3190
3191 Further comments from Martin Sebor:
3192 <br>
3193
3194 The question is which part of the extraction should prevent this from happening
3195 by setting failbit when eofbit is already set. It could either be the sentry
3196 object or the extractor. It seems that most implementations have chosen to
3197 set failbit in the sentry [...] so that's the text that will need to be
3198 corrected.
3199
3200         </p>
3201 <p>
3202 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
3203 sets <tt>failbit</tt> when it finds <tt>eofbit</tt> already set, then
3204 you can never seek away from the end of stream.
3205 </p>
3206 <p>Kona: Possibly NAD.  If eofbit is set then good() will return false.  We
3207   then set <i>ok</i> to false.  We believe that the sentry's
3208   constructor should always set failbit when <i>ok</i> is false, and
3209   we also think the standard already says that.  Possibly it could be
3210   clearer.</p>
3211
3212
3213
3214 <p><b>Proposed resolution:</b></p>
3215 <p>
3216 Change 27.6.1.1.3 [istream::sentry], p2 to:
3217 </p>
3218
3219 <blockquote>
3220 <pre>explicit sentry(basic_istream&lt;charT,traits&gt;&amp; <i>is</i> , bool <i>noskipws</i> = false);</pre>
3221 <p>
3222 -2- <i>Effects:</i> If <tt>is.good()</tt> is <del><tt>true</tt></del>
3223 <ins><tt>false</tt></ins>, <ins>calls <tt>is.setstate(failbit)</tt>.
3224 Otherwise</ins> prepares for formatted or unformatted input. ...
3225 </p>
3226 </blockquote>
3227
3228
3229
3230
3231
3232
3233 <hr>
3234 <h3><a name="421"></a>421. is basic_streambuf copy-constructible?</h3>
3235 <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>
3236  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
3237 <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>
3238 <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>
3239 <p><b>Discussion:</b></p>
3240 <p>
3241 The reflector thread starting with c++std-lib-11346 notes that the class
3242 template basic_streambuf, along with basic_stringbuf and basic_filebuf,
3243 is copy-constructible but that the semantics of the copy constructors
3244 are not defined anywhere. Further, different implementations behave
3245 differently in this respect: some prevent copy construction of objects
3246 of these types by declaring their copy ctors and assignment operators
3247 private, others exhibit undefined behavior, while others still give
3248 these operations well-defined semantics.
3249 </p>
3250
3251 <p>
3252 Note that this problem doesn't seem to be isolated to just the three
3253 types mentioned above. A number of other types in the library section
3254 of the standard provide a compiler-generated copy ctor and assignment
3255 operator yet fail to specify their semantics.  It's believed that the
3256 only types for which this is actually a problem (i.e. types where the
3257 compiler-generated default may be inappropriate and may not have been
3258 intended) are locale facets.  See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#439">439</a>.
3259 </p>
3260
3261
3262 <p><b>Proposed resolution:</b></p>
3263 <p>
3264 27.5.2 [lib.streambuf]:  Add into the synopsis, public section, just above the destructor declaration:
3265 </p>
3266
3267 <blockquote>
3268 <pre>basic_streambuf(const basic_streambuf&amp; sb);
3269 basic_streambuf&amp; operator=(const basic_streambuf&amp; sb);
3270 </pre>
3271 </blockquote>
3272
3273 <p>Insert after 27.5.2.1, paragraph 2:</p>
3274 <blockquote>
3275 <pre>basic_streambuf(const basic_streambuf&amp; sb);
3276 </pre>
3277
3278 <p>Constructs a copy of sb.</p>
3279 <p>Postcondtions:</p>
3280 <pre>                eback() == sb.eback()
3281                 gptr()  == sb.gptr()
3282                 egptr() == sb.egptr()
3283                 pbase() == sb.pbase()
3284                 pptr()  == sb.pptr()
3285                 epptr() == sb.epptr()
3286                 getloc() == sb.getloc()
3287 </pre>
3288
3289 <pre>basic_streambuf&amp; operator=(const basic_streambuf&amp; sb);
3290 </pre>
3291
3292 <p>Assigns the data members of sb to this.</p>
3293
3294 <p>Postcondtions:</p>
3295 <pre>                eback() == sb.eback()
3296                 gptr()  == sb.gptr()
3297                 egptr() == sb.egptr()
3298                 pbase() == sb.pbase()
3299                 pptr()  == sb.pptr()
3300                 epptr() == sb.epptr()
3301                 getloc() == sb.getloc()
3302 </pre>
3303
3304 <p>Returns: *this.</p>
3305 </blockquote>
3306
3307 <p>27.7.1 [lib.stringbuf]:</p>
3308
3309 <p><b>Option A:</b></p>
3310
3311 <blockquote>
3312 <p>Insert into the basic_stringbuf synopsis in the private section:</p>
3313
3314 <pre>basic_stringbuf(const basic_stringbuf&amp;);             // not defined
3315 basic_stringbuf&amp; operator=(const basic_stringbuf&amp;);  // not defined
3316 </pre>
3317 </blockquote>
3318
3319 <p><b>Option B:</b></p>
3320
3321 <blockquote>
3322 <p>Insert into the basic_stringbuf synopsis in the public section:</p>
3323
3324 <pre>basic_stringbuf(const basic_stringbuf&amp; sb);
3325 basic_stringbuf&amp; operator=(const basic_stringbuf&amp; sb);
3326 </pre>
3327
3328 <p>27.7.1.1, insert after paragraph 4:</p>
3329
3330 <pre>basic_stringbuf(const basic_stringbuf&amp; sb);</pre>
3331
3332 <p>
3333 Constructs an independent copy of sb as if with sb.str(), and with the openmode that sb was constructed with.
3334 </p>
3335
3336 <p>Postcondtions: </p>
3337 <pre>               str() == sb.str()
3338                gptr()  - eback() == sb.gptr()  - sb.eback()
3339                egptr() - eback() == sb.egptr() - sb.eback()
3340                pptr()  - pbase() == sb.pptr()  - sb.pbase()
3341                getloc() == sb.getloc()
3342 </pre>
3343
3344 <p>
3345 Note: The only requirement on epptr() is that it point beyond the
3346 initialized range if an output sequence exists. There is no requirement
3347 that epptr() - pbase() == sb.epptr() - sb.pbase().
3348 </p>
3349
3350 <pre>basic_stringbuf&amp; operator=(const basic_stringbuf&amp; sb);</pre>
3351 <p>After assignment the basic_stringbuf has the same state as if it
3352 were initially copy constructed from sb, except that the
3353 basic_stringbuf is allowed to retain any excess capacity it might have,
3354 which may in turn effect the value of epptr().
3355 </p>
3356 </blockquote>
3357
3358 <p>27.8.1.1 [lib.filebuf]</p>
3359
3360 <p>Insert at the bottom of the basic_filebuf synopsis:</p>
3361
3362 <blockquote>
3363 <pre>private:
3364   basic_filebuf(const basic_filebuf&amp;);             // not defined
3365   basic_filebuf&amp; operator=(const basic_filebuf&amp;);  // not defined
3366 </pre>
3367 </blockquote>
3368 <p><i>[Kona: this is an issue for basic_streambuf itself and for its
3369   derived classes.  We are leaning toward allowing basic_streambuf to
3370   be copyable, and specifying its precise semantics.  (Probably the
3371   obvious: copying the buffer pointers.)  We are less sure whether
3372   the streambuf derived classes should be copyable.  Howard will
3373   write up a proposal.]</i></p>
3374
3375
3376 <p><i>[Sydney: Dietmar presented a new argument against basic_streambuf
3377   being copyable: it can lead to an encapsulation violation. Filebuf
3378   inherits from streambuf. Now suppose you inhert a my_hijacking_buf
3379   from streambuf. You can copy the streambuf portion of a filebuf to a
3380   my_hijacking_buf, giving you access to the pointers into the
3381   filebuf's internal buffer. Perhaps not a very strong argument, but
3382   it was strong enough to make people nervous. There was weak
3383   preference for having streambuf not be copyable. There was weak
3384   preference for having stringbuf not be copyable even if streambuf
3385   is. Move this issue to open for now.
3386 ]</i></p>
3387
3388
3389 <p><i>[
3390 2007-01-12, Howard:
3391 <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>
3392 recommends protected copy constructor and assignment for <tt>basic_streambuf</tt> with the same semantics
3393 as would be generated by the compiler.  These members aid in derived classes implementing move semantics.
3394 A protected copy constructor and copy assignment operator do not expose encapsulation more so than it is
3395 today as each data member of a <tt>basic_streambuf</tt> is already both readable and writable by derived
3396 classes via various get/set protected member functions (<tt>eback()</tt>, <tt>setp()</tt>, etc.).  Rather
3397 a protected copy constructor and copy assignment operator simply make the job of derived classes implementing
3398 move semantics less tedious and error prone.
3399 ]</i></p>
3400
3401
3402
3403
3404 <p><b>Rationale:</b></p>
3405 <p>
3406 27.5.2 [lib.streambuf]: The proposed basic_streambuf copy constructor
3407 and assignment operator are the same as currently implied by the lack
3408 of declarations: public and simply copies the data members.  This
3409 resolution is not a change but a clarification of the current
3410 standard.
3411 </p>
3412
3413 <p>
3414 27.7.1 [lib.stringbuf]: There are two reasonable options: A) Make
3415 basic_stringbuf not copyable.  This is likely the status-quo of
3416 current implementations.  B) Reasonable copy semantics of
3417 basic_stringbuf can be defined and implemented.  A copyable
3418 basic_streambuf is arguably more useful than a non-copyable one.  This
3419 should be considered as new functionality and not the fixing of a
3420 defect.  If option B is chosen, ramifications from issue 432 are taken
3421 into account.
3422 </p>
3423
3424 <p>
3425 27.8.1.1 [lib.filebuf]: There are no reasonable copy semantics for
3426 basic_filebuf.
3427 </p>
3428
3429
3430
3431
3432
3433
3434 <hr>
3435 <h3><a name="423"></a>423. effects of negative streamsize in iostreams</h3>
3436 <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>
3437  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
3438 <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>
3439 <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>
3440 <p><b>Discussion:</b></p>
3441
3442 <p>
3443 A third party test suite tries to exercise istream::ignore(N) with
3444 a negative value of N and expects that the implementation will treat
3445 N as if it were 0. Our implementation asserts that (N &gt;= 0) holds and
3446 aborts the test.
3447 </p>
3448
3449 <p>
3450 I can't find anything in section 27 that prohibits such values but I don't
3451 see what the effects of such calls should be, either (this applies to
3452 a number of unformatted input functions as well as some member functions
3453 of the basic_streambuf template).
3454 </p>
3455
3456
3457 <p><b>Proposed resolution:</b></p>
3458 <p>
3459 I propose that we add to each function in clause 27 that takes an argument,
3460 say N, of type streamsize a Requires clause saying that "N &gt;= 0." The intent
3461 is to allow negative streamsize values in calls to precision() and width()
3462 but disallow it in calls to streambuf::sgetn(), istream::ignore(), or
3463 ostream::write().
3464 </p>
3465
3466 <p><i>[Kona: The LWG agreed that this is probably what we want.  However, we
3467   need a review to find all places where functions in clause 27 take
3468   arguments of type streamsize that shouldn't be allowed to go
3469   negative.  Martin will do that review.]</i></p>
3470
3471
3472
3473
3474
3475
3476 <hr>
3477 <h3><a name="427"></a>427. stage 2 and rationale of DR 221</h3>
3478 <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>
3479  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
3480 <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>
3481 <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>
3482 <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>
3483 <p><b>Discussion:</b></p>
3484 <p>
3485 The requirements specified in Stage 2 and reiterated in the rationale
3486 of DR 221 (and echoed again in DR 303) specify that num_get&lt;charT&gt;::
3487 do_get() compares characters on the stream against the widened elements
3488 of "012...abc...ABCX+-"
3489 </p>
3490
3491 <p>
3492 An implementation is required to allow programs to instantiate the num_get
3493 template on any charT that satisfies the requirements on a user-defined
3494 character type. These requirements do not include the ability of the
3495 character type to be equality comparable (the char_traits template must
3496 be used to perform tests for equality). Hence, the num_get template cannot
3497 be implemented to support any arbitrary character type. The num_get template
3498 must either make the assumption that the character type is equality-comparable
3499 (as some popular implementations do), or it may use char_traits&lt;charT&gt; to do
3500 the comparisons (some other popular implementations do that). This diversity
3501 of approaches makes it difficult to write portable programs that attempt to
3502 instantiate the num_get template on user-defined types.
3503 </p>
3504
3505 <p><i>[Kona: the heart of the problem is that we're theoretically
3506   supposed to use traits classes for all fundamental character
3507   operations like assignment and comparison, but facets don't have
3508   traits parameters.  This is a fundamental design flaw and it
3509   appears all over the place, not just in this one place.  It's not
3510   clear what the correct solution is, but a thorough review of facets
3511   and traits is in order.  The LWG considered and rejected the
3512   possibility of changing numeric facets to use narrowing instead of
3513   widening.  This may be a good idea for other reasons (see issue
3514   <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
3515   issue.  Whether we use widen or narrow the <tt>num_get</tt> facet
3516   still has no idea which traits class the user wants to use for
3517   the comparison, because only streams, not facets, are passed traits
3518   classes.   The standard does not require that two different
3519   traits classes with the same <tt>char_type</tt> must necessarily
3520   have the same behavior.]</i></p>
3521
3522
3523 <p>Informally, one possibility: require that some of the basic
3524 character operations, such as <tt>eq</tt>, <tt>lt</tt>,
3525 and <tt>assign</tt>, must behave the same way for all traits classes
3526 with the same <tt>char_type</tt>.  If we accept that limitation on
3527 traits classes, then the facet could reasonably be required to
3528 use <tt>char_traits&lt;charT&gt;</tt>.</p>
3529
3530
3531 <p><b>Proposed resolution:</b></p>
3532
3533
3534
3535
3536 <hr>
3537 <h3><a name="430"></a>430. valarray subset operations</h3>
3538 <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>
3539  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
3540 <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>
3541 <p><b>Discussion:</b></p>
3542 <p>
3543 The standard fails to specify the behavior of valarray::operator[](slice)
3544 and other valarray subset operations when they are passed an "invalid"
3545 slice object, i.e., either a slice that doesn't make sense at all (e.g.,
3546 slice (0, 1, 0) or one that doesn't specify a valid subset of the valarray
3547 object (e.g., slice (2, 1, 1) for a valarray of size 1).
3548 </p>
3549 <p><i>[Kona: the LWG believes that invalid slices should invoke
3550   undefined behavior.  Valarrays are supposed to be designed for high
3551   performance, so we don't want to require specific checking.  We
3552   need wording to express this decision.]</i></p>
3553
3554
3555 <p><i>[
3556 Bellevue:
3557 ]</i></p>
3558
3559
3560 <blockquote>
3561 Please note that the standard also fails to specify the behavior of
3562 slice_array and gslice_array in the valid case. Bill Plauger will
3563 endeavor to provide revised wording for slice_array and gslice_array.
3564 </blockquote>
3565
3566 <p><i>[
3567 post-Bellevue:  Bill provided wording.
3568 ]</i></p>
3569
3570
3571
3572 <p><b>Proposed resolution:</b></p>
3573 <p>
3574 Insert after 26.5.2.4 [valarray.sub], paragraph 1:
3575 </p>
3576
3577 <blockquote>
3578 <p>
3579 The member operator is overloaded to provide several ways to select
3580 sequences
3581 of elements from among those controlled by <tt>*this</tt>. The first group of five
3582 member operators work in conjunction with various overloads of <tt>operator=</tt>
3583 (and other assigning operators) to allow selective replacement (slicing) of
3584 the controlled sequence. The selected elements must exist.
3585 </p>
3586 <p>
3587 The first member operator selects element off. For example:
3588 </p>
3589
3590 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
3591 v0[3] = 'A';
3592 // v0 == valarray&lt;char&gt;("abcAefghijklmnop", 16)
3593 </pre></blockquote>
3594
3595 <p>
3596 The second member operator selects those elements of the controlled sequence
3597 designated by <tt>slicearr</tt>. For example:
3598 </p>
3599
3600 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
3601 valarray&lt;char&gt; v1("ABCDE", 5);
3602 v0[slice(2, 5, 3)] = v1;
3603 // v0 == valarray&lt;char&gt;("abAdeBghCjkDmnEp", 16)
3604 </pre></blockquote>
3605
3606 <p>
3607 The third member operator selects those elements of the controlled sequence
3608 designated by <tt>gslicearr</tt>. For example:
3609 </p>
3610
3611 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
3612 valarray&lt;char&gt; v1("ABCDEF", 6);
3613 const size_t lv[] = {2, 3};
3614 const size_t dv[] = {7, 2};
3615 const valarray&lt;size_t&gt; len(lv, 2), str(dv, 2);
3616 v0[gslice(3, len, str)] = v1;
3617 // v0 == valarray&lt;char&gt;("abcAeBgCijDlEnFp", 16)
3618 </pre></blockquote>
3619
3620 <p>
3621 The fourth member operator selects those elements of the controlled sequence
3622 designated by <tt>boolarr</tt>. For example:
3623 </p>
3624
3625 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
3626 valarray&lt;char&gt; v1("ABC", 3);
3627 const bool vb[] = {false, false, true, true, false, true};
3628 v0[valarray&lt;bool&gt;(vb, 6)] = v1;
3629 // v0 == valarray&lt;char&gt;("abABeCghijklmnop", 16)
3630 </pre></blockquote>
3631
3632 <p>
3633 The fifth member operator selects those elements of the controlled sequence
3634 designated by indarr. For example:
3635 </p>
3636
3637 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
3638 valarray&lt;char&gt; v1("ABCDE", 5);
3639 const size_t vi[] = {7, 5, 2, 3, 8};
3640 v0[valarray&lt;size_t&gt;(vi, 5)] = v1;
3641 // v0 == valarray&lt;char&gt;("abCDeBgAEjklmnop", 16)
3642 </pre></blockquote>
3643
3644 <p>
3645 The second group of five member operators each construct an object that
3646 represents the value(s) selected. The selected elements must exist.
3647 </p>
3648
3649 <p>
3650 The sixth member operator returns the value of element off. For example:
3651 </p>
3652
3653 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
3654 // v0[3] returns 'd'
3655 </pre></blockquote>
3656
3657 <p>
3658 The seventh member operator returns an object of class <tt>valarray&lt;Ty&gt;</tt>
3659 containing those elements of the controlled sequence designated by <tt>slicearr</tt>.
3660 For example:
3661 </p>
3662
3663 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
3664 // v0[slice(2, 5, 3)] returns valarray&lt;char&gt;("cfilo", 5)
3665 </pre></blockquote>
3666
3667 <p>
3668 The eighth member operator selects those elements of the controlled sequence
3669 designated by <tt>gslicearr</tt>. For example:
3670 </p>
3671
3672 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
3673 const size_t lv[] = {2, 3};
3674 const size_t dv[] = {7, 2};
3675 const valarray&lt;size_t&gt; len(lv, 2), str(dv, 2);
3676 // v0[gslice(3, len, str)] returns
3677 // &nbsp;&nbsp;&nbsp;valarray&lt;char&gt;("dfhkmo", 6)
3678 </pre></blockquote>
3679
3680 <p>
3681 The ninth member operator selects those elements of the controlled sequence
3682 designated by <tt>boolarr</tt>. For example:
3683 </p>
3684
3685 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
3686 const bool vb[] = {false, false, true, true, false, true};
3687 // v0[valarray&lt;bool&gt;(vb, 6)] returns
3688 // &nbsp;&nbsp;&nbsp;valarray&lt;char&gt;("cdf", 3)
3689 </pre></blockquote>
3690
3691 <p>
3692 The last member operator selects those elements of the controlled sequence
3693 designated by <tt>indarr</tt>. For example:
3694 </p>
3695
3696 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
3697 const size_t vi[] = {7, 5, 2, 3, 8};
3698 // v0[valarray&lt;size_t&gt;(vi, 5)] returns
3699 //    valarray&lt;char&gt;("hfcdi", 5)
3700 </pre></blockquote>
3701
3702 </blockquote>
3703
3704
3705
3706
3707
3708 <hr>
3709 <h3><a name="431"></a>431. Swapping containers with unequal allocators</h3>
3710 <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>
3711  <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-09-20</p>
3712 <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>
3713 <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>
3714 <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>
3715 <p><b>Discussion:</b></p>
3716 <p>Clause 20.1.2 [allocator.requirements] paragraph 4 says that implementations
3717   are permitted to supply containers that are unable to cope with
3718   allocator instances and that container implementations may assume
3719   that all instances of an allocator type compare equal.  We gave
3720   implementers this latitude as a temporary hack, and eventually we
3721   want to get rid of it.  What happens when we're dealing with
3722   allocators that <i>don't</i> compare equal?
3723 </p>
3724
3725 <p>In particular: suppose that <tt>v1</tt> and <tt>v2</tt> are both
3726   objects of type <tt>vector&lt;int, my_alloc&gt;</tt> and that
3727   <tt>v1.get_allocator() != v2.get_allocator()</tt>.  What happens if
3728   we write <tt>v1.swap(v2)</tt>?  Informally, three possibilities:</p>
3729
3730 <p>1. This operation is illegal.  Perhaps we could say that an
3731   implementation is required to check and to throw an exception, or
3732   perhaps we could say it's undefined behavior.</p>
3733 <p>2. The operation performs a slow swap (i.e. using three
3734   invocations of <tt>operator=</tt>, leaving each allocator with its
3735   original container.  This would be an O(N) operation.</p>
3736 <p>3. The operation swaps both the vectors' contents and their
3737   allocators.  This would be an O(1) operation. That is:</p>
3738   <blockquote>
3739   <pre>    my_alloc a1(...);
3740     my_alloc a2(...);
3741     assert(a1 != a2);
3742
3743     vector&lt;int, my_alloc&gt; v1(a1);
3744     vector&lt;int, my_alloc&gt; v2(a2);
3745     assert(a1 == v1.get_allocator());
3746     assert(a2 == v2.get_allocator());
3747
3748     v1.swap(v2);
3749     assert(a1 == v2.get_allocator());
3750     assert(a2 == v1.get_allocator());
3751   </pre>
3752   </blockquote>
3753
3754 <p><i>[Kona: This is part of a general problem.  We need a paper
3755   saying how to deal with unequal allocators in general.]</i></p>
3756
3757
3758 <p><i>[pre-Sydney: Howard argues for option 3 in
3759 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1599.html">N1599</a>.
3760 ]</i></p>
3761
3762
3763 <p><i>[
3764 2007-01-12, Howard:  This issue will now tend to come up more often with move constructors
3765 and move assignment operators.  For containers, these members transfer resources (i.e.
3766 the allocated memory) just like swap.
3767 ]</i></p>
3768
3769
3770 <p><i>[
3771 Batavia:  There is agreement to overload the container <tt>swap</tt> on the allocator's Swappable
3772 requirement using concepts.  If the allocator supports Swappable, then container's swap will
3773 swap allocators, else it will perform a "slow swap" using copy construction and copy assignment.
3774 ]</i></p>
3775
3776
3777
3778
3779 <p><b>Proposed resolution:</b></p>
3780
3781
3782
3783
3784
3785 <hr>
3786 <h3><a name="446"></a>446. Iterator equality between different containers</h3>
3787 <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>
3788  <b>Submitter:</b> Andy Koenig <b>Date:</b> 2003-12-16</p>
3789 <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>
3790 <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>
3791 <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>
3792 <p><b>Discussion:</b></p>
3793 <p>
3794 What requirements does the standard place on equality comparisons between
3795 iterators that refer to elements of different containers.  For example, if
3796 v1 and v2 are empty vectors, is v1.end() == v2.end() allowed to yield true?
3797 Is it allowed to throw an exception?
3798 </p>
3799
3800 <p>
3801 The standard appears to be silent on both questions.
3802 </p>
3803 <p><i>[Sydney: The intention is that comparing two iterators from
3804 different containers is undefined, but it's not clear if we say that,
3805 or even whether it's something we should be saying in clause 23 or in
3806 clause 24.  Intuitively we might want to say that equality is defined
3807 only if one iterator is reachable from another, but figuring out how
3808 to say it in any sensible way is a bit tricky: reachability is defined
3809 in terms of equality, so we can't also define equality in terms of
3810 reachability.
3811 ]</i></p>
3812
3813
3814
3815
3816 <p><b>Proposed resolution:</b></p>
3817
3818
3819
3820
3821
3822
3823 <hr>
3824 <h3><a name="454"></a>454. basic_filebuf::open should accept wchar_t names</h3>
3825 <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>
3826  <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
3827 <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>
3828 <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>
3829 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a></p>
3830 <p><b>Discussion:</b></p>
3831 <pre>    basic_filebuf *basic_filebuf::open(const char *, ios_base::open_mode);
3832 </pre>
3833
3834 <p>should be supplemented with the overload:</p>
3835
3836 <pre>    basic_filebuf *basic_filebuf::open(const wchar_t *, ios_base::open_mode);
3837 </pre>
3838
3839 <p>
3840 Depending on the operating system, one of these forms is fundamental and
3841 the other requires an implementation-defined mapping to determine the
3842 actual filename.
3843 </p>
3844
3845 <p><i>[Sydney: Yes, we want to allow wchar_t filenames.  Bill will
3846   provide wording.]</i></p>
3847
3848
3849 <p><i>[
3850 In Toronto we noted that this is issue 5 from
3851 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1569.htm">N1569</a>.
3852 ]</i></p>
3853
3854 <p>
3855 How does this interact with the newly-defined character types, and how
3856 do we avoid interface explosion considering <tt>std::string</tt> overloads that
3857 were added? Propose another solution that is different than the
3858 suggestion proposed by PJP.
3859 </p>
3860 <p>
3861 Suggestion is to make a member template function for <tt>basic_string</tt> (for
3862 <tt>char</tt>, <tt>wchar_t</tt>, <tt>u16char</tt>, <tt>u32char</tt> instantiations), and then just keep a
3863 <tt>const char*</tt> member.
3864 </p>
3865 <p>
3866 Goal is to do implicit conversion between character string literals to
3867 appropriate <tt>basic_string</tt> type. Not quite sure if this is possible.
3868 </p>
3869 <p>
3870 Implementors are free to add specific overloads for non-char character
3871 types.
3872 </p>
3873
3874 <p><i>[
3875 Martin adds pre-Sophia Antipolis:
3876 ]</i></p>
3877
3878
3879 <blockquote>
3880 Please see <a href="http://wiki.dinkumware.com/twiki/pub/Wg21sophiaAntipolis/LibraryWorkingGroup/issue-454.html">issue 454: problems and solutions</a>.
3881 </blockquote>
3882
3883 <p><i>[
3884 Sophia Antipolis:
3885 ]</i></p>
3886
3887
3888 <blockquote>
3889 <p>
3890 Beman is concerned that making these changes to <tt>basic_filebuf</tt> is not
3891 usefully changed unless <tt>fstream</tt> is also changed; this also only handles
3892 <tt>wchar_t</tt> and not other character types.
3893 </p>
3894 <p>
3895 The TR2 filesystem library is a more complete solution, but is not available soon.
3896 </p>
3897 </blockquote>
3898
3899 <p><i>[
3900 Martin adds:  please reference
3901 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2683.html">N2683</a> for
3902 problems and solutions.
3903 ]</i></p>
3904
3905
3906
3907
3908 <p><b>Proposed resolution:</b></p>
3909
3910 <p>Change from:</p>
3911 <blockquote>
3912 <pre>basic_filebuf&lt;charT,traits&gt;* open(
3913         const char* s,
3914         ios_base::openmode mode );
3915 </pre>
3916
3917 <p>
3918 Effects: If is_open() != false, returns a null pointer.
3919 Otherwise, initializes the filebuf as required. It then
3920 opens a file, if possible, whose name is the NTBS s ("as if"
3921 by calling std::fopen(s,modstr)).</p>
3922 </blockquote>
3923
3924 <p>to:</p>
3925
3926 <blockquote>
3927 <pre>basic_filebuf&lt;charT,traits&gt;* open(
3928         const char* s,
3929         ios_base::openmode mode );
3930
3931 basic_filebuf&lt;charT,traits&gt;* open(
3932         const wchar_t* ws,
3933         ios_base::openmode mode );
3934 </pre>
3935
3936 <p>
3937 Effects: If is_open() != false, returns a null pointer.
3938 Otherwise, initializes the filebuf as required. It then
3939 opens a file, if possible, whose name is the NTBS s ("as if"
3940 by calling std::fopen(s,modstr)).
3941 For the second signature, the NTBS s is determined from the
3942 WCBS ws in an implementation-defined manner.
3943 </p>
3944
3945 <p>
3946 (NOTE: For a system that "naturally" represents a filename
3947 as a WCBS, the NTBS s in the first signature may instead
3948 be mapped to a WCBS; if so, it follows the same mapping
3949 rules as the first argument to open.)
3950 </p>
3951 </blockquote>
3952
3953
3954
3955 <p><b>Rationale:</b></p>
3956 <p>
3957 Slightly controversial, but by a 7-1 straw poll the LWG agreed to move
3958 this to Ready.  The controversy was because the mapping between wide
3959 names and files in a filesystem is implementation defined.  The
3960 counterargument, which most but not all LWG members accepted, is that
3961 the mapping between narrow files names and files is also
3962 implemenation defined.</p>
3963
3964 <p><i>[Lillehammer: Moved back to "open" status, at Beman's urging.
3965 (1) Why just basic_filebuf, instead of also basic_fstream (and
3966 possibly other things too). (2) Why not also constructors that take
3967 std::basic_string? (3) We might want to wait until we see Beman's
3968 filesystem library; we might decide that it obviates this.]</i></p>
3969
3970
3971 <p><i>[
3972 post Bellevue:
3973 ]</i></p>
3974
3975
3976 <blockquote>
3977 <p>
3978 Move again to Ready.
3979 </p>
3980 <p>
3981 There is a timing issue here. Since the filesystem library will not be
3982 in C++0x, this should be brought forward. This solution would remain
3983 valid in the context of the proposed filesystem.
3984 </p>
3985 <p>
3986 This issue has been kicking around for a while, and the wchar_t addition
3987 alone would help many users. Thus, we suggest putting this on the
3988 reflector list with an invitation for someone to produce proposed
3989 wording that covers basic_fstream. In the meantime, we suggest that the
3990 proposed wording be adopted as-is.
3991 </p>
3992 <p>
3993 If more of the Lillehammer questions come back, they should be
3994 introduced as separate issues.
3995 </p>
3996 </blockquote>
3997
3998
3999
4000
4001
4002
4003
4004
4005 <hr>
4006 <h3><a name="458"></a>458. 24.1.5 contains unintented limitation for operator-</h3>
4007 <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>
4008  <b>Submitter:</b> Daniel Frey <b>Date:</b> 2004-02-27</p>
4009 <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>
4010 <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>
4011 <p><b>Discussion:</b></p>
4012 <p>
4013 In 24.1.5 [lib.random.access.iterators], table 76 the operational
4014 semantics for the expression "r -= n" are defined as "return r += -n".
4015 This means, that the expression -n must be valid, which is not the case
4016 for unsigned types.
4017 </p>
4018
4019 <p><i>[
4020 Sydney: Possibly not a real problem, since difference type is required
4021 to be a signed integer type. However, the wording in the standard may
4022 be less clear than we would like.
4023 ]</i></p>
4024
4025
4026
4027
4028 <p><b>Proposed resolution:</b></p>
4029 <p>
4030 To remove this limitation, I suggest to change the
4031 operational semantics for this column to:
4032 </p>
4033 <blockquote><pre>    { Distance m = n;
4034       if (m &gt;= 0)
4035         while (m--) --r;
4036       else
4037         while (m++) ++r;
4038       return r; }
4039 </pre></blockquote>
4040
4041
4042
4043
4044
4045
4046 <hr>
4047 <h3><a name="459"></a>459. Requirement for widening in stage 2 is overspecification</h3>
4048 <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>
4049  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-03-16</p>
4050 <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>
4051 <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>
4052 <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>
4053 <p><b>Discussion:</b></p>
4054 <p>When parsing strings of wide-character digits, the standard
4055   requires the library to widen narrow-character "atoms" and compare
4056   the widened atoms against the characters that are being parsed.
4057   Simply narrowing the wide characters would be far simpler, and
4058   probably more efficient.  The two choices are equivalent except in
4059   convoluted test cases, and many implementations already ignore the
4060   standard and use narrow instead of widen.</p>
4061
4062 <p>
4063 First, I disagree that using narrow() instead of widen() would
4064 necessarily have unfortunate performance implications. A possible
4065 implementation of narrow() that allows num_get to be implemented
4066 in a much simpler and arguably comparably efficient way as calling
4067 widen() allows, i.e. without making a virtual call to do_narrow every
4068 time, is as follows:
4069 </p>
4070
4071 <pre>  inline char ctype&lt;wchar_t&gt;::narrow (wchar_t wc, char dflt) const
4072   {
4073       const unsigned wi = unsigned (wc);
4074
4075       if (wi &gt; UCHAR_MAX)
4076           return typeid (*this) == typeid (ctype&lt;wchar_t&gt;) ?
4077                  dflt : do_narrow (wc, dflt);
4078
4079       if (narrow_ [wi] &lt; 0) {
4080          const char nc = do_narrow (wc, dflt);
4081          if (nc == dflt)
4082              return dflt;
4083          narrow_ [wi] = nc;
4084       }
4085
4086       return char (narrow_ [wi]);
4087   }
4088 </pre>
4089
4090 <p>
4091 Second, I don't think the change proposed in the issue (i.e., to use
4092 narrow() instead of widen() during Stage 2) would be at all
4093 drastic. Existing implementations with the exception of libstdc++
4094 currently already use narrow() so the impact of the change on programs
4095 would presumably be isolated to just a single implementation. Further,
4096 since narrow() is not required to translate alternate wide digit
4097 representations such as those mentioned in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a>
4098 to
4099 their narrow equivalents (i.e., the portable source characters '0'
4100 through '9'), the change does not necessarily imply that these
4101 alternate digits would be treated as ordinary digits and accepted as
4102 part of numbers during parsing. In fact, the requirement in 22.2.1.1.2
4103 [locale.ctype.virtuals], p13 forbids narrow() to translate an alternate
4104 digit character, wc, to an ordinary digit in the basic source
4105 character set unless the expression
4106 (ctype&lt;charT&gt;::is(ctype_base::digit, wc) == true) holds. This in
4107 turn is prohibited by the C standard (7.25.2.1.5, 7.25.2.1.5, and
4108 5.2.1, respectively) for charT of either char or wchar_t.
4109 </p>
4110
4111 <p><i>[Sydney: To a large extent this is a nonproblem. As long as
4112 you're only trafficking in char and wchar_t we're only dealing with a
4113 stable character set, so you don't really need either 'widen' or
4114 'narrow': can just use literals. Finally, it's not even clear whether
4115 widen-vs-narrow is the right question; arguably we should be using
4116 codecvt instead.]</i></p>
4117
4118
4119
4120
4121 <p><b>Proposed resolution:</b></p>
4122 <p>Change stage 2 so that implementations are permitted to use either
4123 technique to perform the comparison:</p>
4124 <ol>
4125   <li> call widen on the atoms and compare (either by using
4126       operator== or char_traits&lt;charT&gt;::eq) the input with
4127       the widened atoms, or</li>
4128   <li> call narrow on the input and compare the narrow input
4129       with the atoms</li>
4130   <li> do (1) or (2) only if charT is not char or wchar_t,
4131       respectively; i.e., avoid calling widen or narrow
4132       if it the source and destination types are the same</li>
4133 </ol>
4134
4135
4136
4137
4138
4139 <hr>
4140 <h3><a name="463"></a>463. auto_ptr usability issues</h3>
4141 <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>
4142  <b>Submitter:</b> Rani Sharoni <b>Date:</b> 2003-12-07</p>
4143 <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>
4144 <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>
4145 <p><b>Discussion:</b></p>
4146
4147 <p>
4148 TC1 CWG DR #84 effectively made the template&lt;class Y&gt; operator auto_ptr&lt;Y&gt;()
4149 member of auto_ptr (20.4.5.3/4) obsolete.
4150 </p>
4151
4152 <p>
4153 The sole purpose of this obsolete conversion member is to enable copy
4154 initialization base from r-value derived (or any convertible types like
4155 cv-types) case:
4156 </p>
4157 <pre>#include &lt;memory&gt;
4158 using std::auto_ptr;
4159
4160 struct B {};
4161 struct D : B {};
4162
4163 auto_ptr&lt;D&gt; source();
4164 int sink(auto_ptr&lt;B&gt;);
4165 int x1 = sink( source() ); // #1 EDG - no suitable copy constructor
4166 </pre>
4167
4168 <p>
4169 The excellent analysis of conversion operations that was given in the final
4170 auto_ptr proposal
4171 (http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/1997/N1128.pdf)
4172 explicitly specifies this case analysis (case 4). DR #84 makes the analysis
4173 wrong and actually comes to forbid the loophole that was exploited by the
4174 auto_ptr designers.
4175 </p>
4176
4177 <p>
4178 I didn't encounter any compliant compiler (e.g. EDG, GCC, BCC and VC) that
4179 ever allowed this case. This is probably because it requires 3 user defined
4180 conversions and in fact current compilers conform to DR #84.
4181 </p>
4182
4183 <p>
4184 I was surprised to discover that the obsolete conversion member actually has
4185 negative impact of the copy initialization base from l-value derived
4186 case:</p>
4187 <pre>auto_ptr&lt;D&gt; dp;
4188 int x2 = sink(dp); // #2 EDG - more than one user-defined conversion applies
4189 </pre>
4190
4191 <p>
4192 I'm sure that the original intention was allowing this initialization using
4193 the template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;&amp; a) constructor (20.4.5.1/4) but
4194 since in this copy initialization it's merely user defined conversion (UDC)
4195 and the obsolete conversion member is UDC with the same rank (for the early
4196 overloading stage) there is an ambiguity between them.
4197 </p>
4198
4199 <p>
4200 Removing the obsolete member will have impact on code that explicitly
4201 invokes it:
4202 </p>
4203 <pre>int y = sink(source().operator auto_ptr&lt;B&gt;());
4204 </pre>
4205
4206 <p>
4207 IMHO no one ever wrote such awkward code and the reasonable workaround for
4208 #1 is:
4209 </p>
4210 <pre>int y = sink( auto_ptr&lt;B&gt;(source()) );
4211 </pre>
4212
4213 <p>
4214 I was even more surprised to find out that after removing the obsolete
4215 conversion member the initialization was still ill-formed:
4216 int x3 = sink(dp); // #3 EDG - no suitable copy constructor
4217 </p>
4218
4219 <p>
4220 This copy initialization semantically requires copy constructor which means
4221 that both template conversion constructor and the auto_ptr_ref conversion
4222 member (20.4.5.3/3) are required which is what was explicitly forbidden in
4223 DR #84. This is a bit amusing case in which removing ambiguity results with
4224 no candidates.
4225 </p>
4226
4227 <p>
4228 I also found exception safety issue with auto_ptr related to auto_ptr_ref:
4229 </p>
4230 <pre>int f(auto_ptr&lt;B&gt;, std::string);
4231 auto_ptr&lt;B&gt; source2();
4232
4233 // string constructor throws while auto_ptr_ref
4234 // "holds" the pointer
4235 int x4 = f(source2(), "xyz"); // #4
4236 </pre>
4237
4238 <p>
4239 The theoretic execution sequence that will cause a leak:
4240 </p>
4241 <ol>
4242 <li>call auto_ptr&lt;B&gt;::operator auto_ptr_ref&lt;B&gt;()</li>
4243 <li>call string::string(char const*) and throw</li>
4244 </ol>
4245
4246 <p>
4247 According to 20.4.5.3/3 and 20.4.5/2 the auto_ptr_ref conversion member
4248 returns auto_ptr_ref&lt;Y&gt; that holds *this and this is another defect since
4249 the type of *this is auto_ptr&lt;X&gt; where X might be different from Y. Several
4250 library vendors (e.g. SGI) implement auto_ptr_ref&lt;Y&gt; with Y* as member which
4251 is much more reasonable. Other vendor implemented auto_ptr_ref as
4252 defectively required and it results with awkward and catastrophic code:
4253 int oops = sink(auto_ptr&lt;B&gt;(source())); // warning recursive on all control
4254 paths
4255 </p>
4256
4257 <p>
4258 Dave Abrahams noticed that there is no specification saying that
4259 auto_ptr_ref copy constructor can't throw.
4260 </p>
4261
4262 <p>
4263 My proposal comes to solve all the above issues and significantly simplify
4264 auto_ptr implementation. One of the fundamental requirements from auto_ptr
4265 is that it can be constructed in an intuitive manner (i.e. like ordinary
4266 pointers) but with strict ownership semantics which yield that source
4267 auto_ptr in initialization must be non-const. My idea is to add additional
4268 constructor template with sole propose to generate ill-formed, diagnostic
4269 required, instance for const auto_ptr arguments during instantiation of
4270 declaration. This special constructor will not be instantiated for other
4271 types which is achievable using 14.8.2/2 (SFINAE). Having this constructor
4272 in hand makes the constructor template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp;)
4273 legitimate since the actual argument can't be const yet non const r-value
4274 are acceptable.
4275 </p>
4276
4277 <p>
4278 This implementation technique makes the "private auxiliary class"
4279 auto_ptr_ref obsolete and I found out that modern C++ compilers (e.g. EDG,
4280 GCC and VC) consume the new implementation as expected and allow all
4281 intuitive initialization and assignment cases while rejecting illegal cases
4282 that involve const auto_ptr arguments.
4283 </p>
4284
4285 <p>The proposed auto_ptr interface:</p>
4286
4287 <pre>namespace std {
4288     template&lt;class X&gt; class auto_ptr {
4289     public:
4290         typedef X element_type;
4291
4292         // 20.4.5.1 construct/copy/destroy:
4293         explicit auto_ptr(X* p=0) throw();
4294         auto_ptr(auto_ptr&amp;) throw();
4295         template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp;) throw();
4296         auto_ptr&amp; operator=(auto_ptr&amp;) throw();
4297         template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;) throw();
4298         ~auto_ptr() throw();
4299
4300         // 20.4.5.2 members:
4301         X&amp; operator*() const throw();
4302         X* operator-&gt;() const throw();
4303         X* get() const throw();
4304         X* release() throw();
4305         void reset(X* p=0) throw();
4306
4307     private:
4308         template&lt;class U&gt;
4309         auto_ptr(U&amp; rhs, typename
4310 unspecified_error_on_const_auto_ptr&lt;U&gt;::type = 0);
4311     };
4312 }
4313 </pre>
4314
4315 <p>
4316 One compliant technique to implement the unspecified_error_on_const_auto_ptr
4317 helper class is using additional private auto_ptr member class template like
4318 the following:
4319 </p>
4320 <pre>template&lt;typename T&gt; struct unspecified_error_on_const_auto_ptr;
4321
4322 template&lt;typename T&gt;
4323 struct unspecified_error_on_const_auto_ptr&lt;auto_ptr&lt;T&gt; const&gt;
4324 { typedef typename auto_ptr&lt;T&gt;::const_auto_ptr_is_not_allowed type; };
4325 </pre>
4326
4327 <p>
4328 There are other techniques to implement this helper class that might work
4329 better for different compliers (i.e. better diagnostics) and therefore I
4330 suggest defining its semantic behavior without mandating any specific
4331 implementation. IMO, and I didn't found any compiler that thinks otherwise,
4332 14.7.1/5 doesn't theoretically defeat the suggested technique but I suggest
4333 verifying this with core language experts.
4334 </p>
4335
4336 <p><b>Further changes in standard text:</b></p>
4337 <p>Remove section 20.4.5.3</p>
4338
4339 <p>Change 20.4.5/2 to read something like:
4340 Initializing auto_ptr&lt;X&gt; from const auto_ptr&lt;Y&gt; will result with unspecified
4341 ill-formed declaration that will require unspecified diagnostic.</p>
4342
4343 <p>Change 20.4.5.1/4,5,6 to read:</p>
4344
4345 <pre>template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp; a) throw();</pre>
4346 <p> 4 Requires: Y* can be implicitly converted to X*.</p>
4347 <p> 5 Effects: Calls const_cast&lt;auto_ptr&lt;Y&gt;&amp;&gt;(a).release().</p>
4348 <p> 6 Postconditions: *this holds the pointer returned from a.release().</p>
4349
4350 <p>Change 20.4.5.1/10</p>
4351 <pre>template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt; a) throw();
4352 </pre>
4353 <p>
4354 10 Requires: Y* can be implicitly converted to X*. The expression delete
4355 get() is well formed.
4356 </p>
4357
4358 <p>LWG TC DR #127 is obsolete.</p>
4359
4360 <p>
4361 Notice that the copy constructor and copy assignment operator should remain
4362 as before and accept non-const auto_ptr&amp; since they have effect on the form
4363 of the implicitly declared copy constructor and copy assignment operator of
4364 class that contains auto_ptr as member per 12.8/5,10:
4365 </p>
4366 <pre>struct X {
4367     // implicit X(X&amp;)
4368     // implicit X&amp; operator=(X&amp;)
4369     auto_ptr&lt;D&gt; aptr_;
4370 };
4371 </pre>
4372
4373 <p>
4374 In most cases this indicates about sloppy programming but preserves the
4375 current auto_ptr behavior.
4376 </p>
4377
4378 <p>
4379 Dave Abrahams encouraged me to suggest fallback implementation in case that
4380 my suggestion that involves removing of auto_ptr_ref will not be accepted.
4381 In this case removing the obsolete conversion member to auto_ptr&lt;Y&gt; and
4382 20.4.5.3/4,5 is still required in order to eliminate ambiguity in legal
4383 cases. The two constructors that I suggested will co exist with the current
4384 members but will make auto_ptr_ref obsolete in initialization contexts.
4385 auto_ptr_ref will be effective in assignment contexts as suggested in DR
4386 #127 and I can't see any serious exception safety issues in those cases
4387 (although it's possible to synthesize such). auto_ptr_ref&lt;X&gt; semantics will
4388 have to be revised to say that it strictly holds pointer of type X and not
4389 reference to an auto_ptr for the favor of cases in which auto_ptr_ref&lt;Y&gt; is
4390 constructed from auto_ptr&lt;X&gt; in which X is different from Y (i.e. assignment
4391 from r-value derived to base).
4392 </p>
4393
4394 <p><i>[Redmond: punt for the moment. We haven't decided yet whether we
4395   want to fix auto_ptr for C++-0x, or remove it and replace it with
4396   move_ptr and unique_ptr.]</i></p>
4397
4398
4399 <p><i>[
4400 Oxford 2007: Recommend NAD.  We're just going to deprecate it.  It still works for simple use cases
4401 and people know how to deal with it.  Going forward <tt>unique_ptr</tt> is the recommended
4402 tool.
4403 ]</i></p>
4404
4405
4406 <p><i>[
4407 2007-11-09: Reopened at the request of David Abrahams, Alisdair Meredith and Gabriel Dos Reis.
4408 ]</i></p>
4409
4410
4411
4412
4413 <p><b>Proposed resolution:</b></p>
4414 <p>
4415 Change the synopsis in D.9.1 [auto.ptr]:
4416 </p>
4417
4418 <blockquote><pre>namespace std {
4419   <del>template &lt;class Y&gt; struct auto_ptr_ref {};</del>
4420
4421   <ins>// exposition only</ins>
4422   <ins>template &lt;class T&gt; struct constant_object;</ins>
4423
4424   <ins>// exposition only</ins>
4425   <ins>template &lt;class T&gt;</ins>
4426   <ins>struct cannot_transfer_ownership_from</ins>
4427     <ins>: constant_object&lt;T&gt; {};</ins>
4428
4429   template &lt;class X&gt; class auto_ptr {
4430   public:
4431     typedef X element_type;
4432
4433     // D.9.1.1 construct/copy/destroy:
4434     explicit auto_ptr(X* p =0) throw();
4435     auto_ptr(auto_ptr&amp;) throw();
4436     template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;<ins> const</ins>&amp;) throw();
4437     auto_ptr&amp; operator=(auto_ptr&amp;) throw();
4438     template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del>) throw();
4439     <del>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw();</del>
4440     ~auto_ptr() throw();
4441
4442     // D.9.1.2 members:
4443     X&amp; operator*() const throw();
4444     X* operator-&gt;() const throw();
4445     X* get() const throw();
4446     X* release() throw();
4447     void reset(X* p =0) throw();
4448
4449     <del>// D.9.1.3 conversions:</del>
4450     <del>auto_ptr(auto_ptr_ref&lt;X&gt;) throw();</del>
4451     <del>template&lt;class Y&gt; operator auto_ptr_ref&lt;Y&gt;() throw();</del>
4452     <del>template&lt;class Y&gt; operator auto_ptr&lt;Y&gt;() throw();</del>
4453
4454     <ins>// exposition only</ins>
4455     <ins>template&lt;class U&gt;</ins>
4456     <ins>auto_ptr(U&amp; rhs, typename cannot_transfer_ownership_from&lt;U&gt;::error = 0);</ins>
4457   };
4458
4459   template &lt;&gt; class auto_ptr&lt;void&gt;
4460   {
4461   public:
4462     typedef void element_type;
4463   };
4464
4465 }
4466 </pre></blockquote>
4467
4468 <p>
4469 Remove D.9.1.3 [auto.ptr.conv].
4470 </p>
4471
4472 <p>
4473 Change D.9.1 [auto.ptr], p3:
4474 </p>
4475
4476 <blockquote>
4477 The <tt>auto_ptr</tt> provides a semantics of strict ownership. An
4478 <tt>auto_ptr</tt> owns the object it holds a pointer to. Copying an
4479 <tt>auto_ptr</tt> copies the pointer and transfers ownership to the
4480 destination. If more than one <tt>auto_ptr</tt> owns the same object at
4481 the same time the behavior of the program is undefined. <ins>Templates
4482 <tt>constant_object</tt> and <tt>cannot_transfer_ownership_from</tt>,
4483 and the final constructor of <tt>auto_ptr</tt> are for exposition only.
4484 For any types <tt>X</tt> and <tt>Y</tt>, initializing
4485 <tt>auto_ptr&lt;X&gt;</tt> from <tt>const auto_ptr&lt;Y&gt;</tt> is
4486 ill-formed, diagnostic required.</ins> [<i>Note:</i> The uses of
4487 <tt>auto_ptr</tt> include providing temporary exception-safety for
4488 dynamically allocated memory, passing ownership of dynamically allocated
4489 memory to a function, and returning dynamically allocated memory from a
4490 function. <tt>auto_ptr</tt> does not meet the <tt>CopyConstructible</tt>
4491 and <tt>Assignable</tt> requirements for Standard Library container
4492 elements and thus instantiating a Standard Library container with an
4493 <tt>auto_ptr</tt> results in undefined behavior. <i>-- end note</i>]
4494 </blockquote>
4495
4496 <p>
4497 Change D.9.1.1 [auto.ptr.cons], p5:
4498 </p>
4499
4500 <blockquote>
4501 <pre>template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;<ins> const</ins>&amp; a) throw();
4502 </pre>
4503 <blockquote>
4504 <p>
4505 <i>Requires:</i> <tt>Y*</tt> can be implicitly converted to <tt>X*</tt>.
4506 </p>
4507 <p>
4508 <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>.
4509 </p>
4510 <p>
4511 <i>Postconditions:</i> <tt>*this</tt> holds the pointer returned from <tt>a.release()</tt>.
4512 </p>
4513 </blockquote>
4514 </blockquote>
4515
4516 <p>
4517 Change D.9.1.1 [auto.ptr.cons], p10:
4518 </p>
4519
4520 <blockquote>
4521 <pre>template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del> a) throw();
4522 </pre>
4523 <blockquote>
4524 <p>
4525 <i>Requires:</i> <tt>Y*</tt> can be implicitly converted to <tt>X*</tt>.
4526 The expression <tt>delete get()</tt> is well formed.
4527 </p>
4528 <p>
4529 <i>Effects:</i> Calls <tt>reset(a.release())</tt>.
4530 </p>
4531 <p>
4532 <i>Returns:</i> <tt>*this</tt>.
4533 </p>
4534 </blockquote>
4535 </blockquote>
4536
4537
4538
4539
4540
4541
4542 <hr>
4543 <h3><a name="471"></a>471. result of what() implementation-defined</h3>
4544 <p><b>Section:</b> 18.6.1 [type.info] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
4545  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-28</p>
4546 <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>
4547 <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>
4548 <p><b>Discussion:</b></p>
4549
4550 <p>[lib.exception] specifies the following:</p>
4551 <pre>    exception (const exception&amp;) throw();
4552     exception&amp; operator= (const exception&amp;) throw();
4553
4554     -4- Effects: Copies an exception object.
4555     -5- Notes: The effects of calling what() after assignment
4556         are implementation-defined.
4557 </pre>
4558
4559 <p>
4560 First, does the Note only apply to the assignment operator? If so,
4561 what are the effects of calling what() on a copy of an object? Is
4562 the returned pointer supposed to point to an identical copy of
4563 the NTBS returned by what() called on the original object or not?
4564 </p>
4565
4566 <p>
4567 Second, is this Note intended to extend to all the derived classes
4568 in section 19? I.e., does the standard provide any guarantee for
4569 the effects of what() called on a copy of any of the derived class
4570 described in section 19?
4571 </p>
4572
4573 <p>
4574 Finally, if the answer to the first question is no, I believe it
4575 constitutes a defect since throwing an exception object typically
4576 implies invoking the copy ctor on the object. If the answer is yes,
4577 then I believe the standard ought to be clarified to spell out
4578 exactly what the effects are on the copy (i.e., after the copy
4579 ctor was called).
4580 </p>
4581
4582 <p><i>[Redmond: Yes, this is fuzzy.  The issue of derived classes is
4583   fuzzy too.]</i></p>
4584
4585
4586 <p><i>[
4587 Batavia: Howard provided wording.
4588 ]</i></p>
4589
4590
4591 <p><i>[
4592 Bellevue:
4593 ]</i></p>
4594
4595
4596 <blockquote>
4597 <p>
4598 Eric concerned this is unimplementable, due to nothrow guarantees.
4599 Suggested implementation would involve reference counting.
4600 </p>
4601 <p>
4602 Is the implied reference counting subtle enough to call out a note on
4603 implementation? Probably not.
4604 </p>
4605 <p>
4606 If reference counting required, could we tighten specification further
4607 to require same pointer value? Probably an overspecification, especially
4608 if exception classes defer evalutation of final string to calls to
4609 what().
4610 </p>
4611 <p>
4612 Remember issue moved open and not resolved at Batavia, but cannot
4613 remember who objected to canvas a disenting opinion - please speak up if
4614 you disagree while reading these minutes!
4615 </p>
4616 <p>
4617 Move to Ready as we are accepting words unmodified.
4618 </p>
4619 </blockquote>
4620
4621 <p><i>[
4622 Sophia Antipolis:
4623 ]</i></p>
4624
4625
4626 <blockquote>
4627 The issue was pulled from Ready.  It needs to make clear that only homogenous copying
4628 is intended to be supported.  Not coping from a dervied to a base.
4629 </blockquote>
4630
4631
4632
4633
4634 <p><b>Proposed resolution:</b></p>
4635
4636 <p>
4637 Change 18.7.1 [exception] to:
4638 </p>
4639
4640 <blockquote>
4641 <pre>exception(const exception&amp; <ins><i>e</i></ins>) throw();
4642 exception&amp; operator=(const exception&amp; <ins><i>e</i></ins>) throw();</pre>
4643 <blockquote>
4644 <p>
4645 -4- <i>Effects:</i> Copies an exception object.
4646 </p>
4647 <p>
4648 <del> -5- <i>Remarks:</i> The effects of calling what() after assignment are implementation-defined.</del>
4649 </p>
4650 <p>
4651 <ins>-5- <i>Throws:</i> Nothing.  This also applies
4652 to all standard library-defined classes that derive from <tt>exception</tt>.</ins>
4653 </p>
4654 <p>
4655 <ins>-7- <i>Postcondition:</i> <tt>strcmp(what(), <i>e</i>.what()) == 0</tt>.  This also applies
4656 to all standard library-defined classes that derive from <tt>exception</tt>.</ins>
4657 </p>
4658
4659 </blockquote>
4660 </blockquote>
4661
4662
4663
4664
4665 <hr>
4666 <h3><a name="473"></a>473. underspecified ctype calls</h3>
4667 <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>
4668  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-07-01</p>
4669 <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>
4670 <p><b>Discussion:</b></p>
4671 <p>
4672 Most ctype member functions come in two forms: one that operates
4673 on a single character at a time and another form that operates
4674 on a range of characters. Both forms are typically described by
4675 a single Effects and/or Returns clause.
4676 </p>
4677 <p>
4678 The Returns clause of each of the single-character non-virtual forms
4679 suggests that the function calls the corresponding single character
4680 virtual function, and that the array form calls the corresponding
4681 virtual array form. Neither of the two forms of each virtual member
4682 function is required to be implemented in terms of the other.
4683 </p>
4684 <p>
4685 There are three problems:
4686 </p>
4687 <p>
4688 1. One is that while the standard does suggest that each non-virtual
4689 member function calls the corresponding form of the virtual function,
4690 it doesn't actually explicitly require it.
4691 </p>
4692 <p>
4693 Implementations that cache results from some of the virtual member
4694 functions for some or all values of their arguments might want to
4695 call the array form from the non-array form the first time to fill
4696 the cache and avoid any or most subsequent virtual calls. Programs
4697 that rely on each form of the virtual function being called from
4698 the corresponding non-virtual function will see unexpected behavior
4699 when using such implementations.
4700 </p>
4701 <p>
4702 2. The second problem is that either form of each of the virtual
4703 functions can be overridden by a user-defined function in a derived
4704 class to return a value that is different from the one produced by
4705 the virtual function of the alternate form that has not been
4706 overriden.
4707 </p>
4708 <p>
4709 Thus, it might be possible for, say, ctype::widen(c) to return one
4710 value, while for ctype::widen(&amp;c, &amp;c + 1, &amp;wc) to set
4711 wc to another value. This is almost certainly not intended. Both
4712 forms of every function should be required to return the same result
4713 for the same character, otherwise the same program using an
4714 implementation that calls one form of the functions will behave
4715 differently than when using another implementation that calls the
4716 other form of the function "under the hood."
4717 </p>
4718 <p>
4719 3. The last problem is that the standard text fails to specify whether
4720 one form of any of the virtual functions is permitted to be implemented
4721 in terms of the other form or not, and if so, whether it is required
4722 or permitted to call the overridden virtual function or not.
4723 </p>
4724 <p>
4725 Thus, a program that overrides one of the virtual functions so that
4726 it calls the other form which then calls the base member might end
4727 up in an infinite loop if the called form of the base implementation
4728 of the function in turn calls the other form.
4729 </p>
4730 <p>
4731 Lillehammer: Part of this isn't a real problem. We already talk about
4732 caching. 22.1.1/6 But part is a real problem. ctype virtuals may call
4733 each other, so users don't know which ones to override to avoid avoid
4734 infinite loops.</p>
4735
4736 <p>This is a problem for all facet virtuals, not just ctype virtuals,
4737 so we probably want a blanket statement in clause 22 for all
4738 facets. The LWG is leaning toward a blanket prohibition, that a
4739 facet's virtuals may never call each other. We might want to do that
4740 in clause 27 too, for that matter. A review is necessary.  Bill will
4741 provide wording.</p>
4742
4743
4744 <p><b>Proposed resolution:</b></p>
4745
4746
4747
4748
4749 <hr>
4750 <h3><a name="484"></a>484. Convertible to T</h3>
4751 <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>
4752  <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2004-09-16</p>
4753 <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>
4754 <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>
4755 <p><b>Discussion:</b></p>
4756 <p>From comp.std.c++:</p>
4757
4758 <p>
4759 I note that given an input iterator a for type T,
4760 then *a only has to be "convertable to T", not actually of type T.
4761 </p>
4762
4763 <p>Firstly, I can't seem to find an exact definition of "convertable to T".
4764 While I assume it is the obvious definition (an implicit conversion), I
4765 can't find an exact definition. Is there one?</p>
4766
4767 <p>Slightly more worryingly, there doesn't seem to be any restriction on
4768 the this type, other than it is "convertable to T". Consider two input
4769 iterators a and b. I would personally assume that most people would
4770 expect *a==*b would perform T(*a)==T(*b), however it doesn't seem that
4771 the standard requires that, and that whatever type *a is (call it U)
4772 could have == defined on it with totally different symantics and still
4773 be a valid inputer iterator.</p>
4774
4775 <p>Is this a correct reading? When using input iterators should I write
4776 T(*a) all over the place to be sure that the object i'm using is the
4777 class I expect?</p>
4778
4779 <p>This is especially a nuisance for operations that are defined to be
4780   "convertible to bool".  (This is probably allowed so that
4781   implementations could return say an int and avoid an unnessary
4782   conversion. However all implementations I have seen simply return a
4783   bool anyway.  Typical implemtations of STL algorithms just write
4784   things like <tt>while(a!=b &amp;&amp; *a!=0)</tt>.  But strictly
4785   speaking, there are lots of types that are convertible to T but
4786   that also overload the appropriate operators so this doesn't behave
4787   as expected.</p>
4788
4789 <p>If we want to make code like this legal (which most people seem to
4790   expect), then we'll need to tighten up what we mean by "convertible
4791   to T".</p>
4792
4793 <p><i>[Lillehammer: The first part is NAD, since "convertible" is
4794  well-defined in core. The second part is basically about pathological
4795  overloads. It's a minor problem but a real one. So leave open for
4796  now, hope we solve it as part of iterator redesign.]</i></p>
4797
4798
4799
4800 <p><b>Proposed resolution:</b></p>
4801
4802
4803
4804
4805
4806 <hr>
4807 <h3><a name="485"></a>485. output iterator insufficently constrained</h3>
4808 <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>
4809  <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2004-10-13</p>
4810 <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>
4811 <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>
4812 <p><b>Discussion:</b></p>
4813 <p>
4814 The note on 24.1.2 Output iterators insufficently limits what can be
4815 performed on output iterators. While it requires that each iterator is
4816 progressed through only once and that each iterator is written to only
4817 once, it does not require the following things:</p>
4818
4819 <p>Note: Here it is assumed that x is an output iterator of type X which
4820 has not yet been assigned to.</p>
4821
4822 <p>a) That each value of the output iterator is written to:
4823 The standard allows:
4824 ++x; ++x; ++x;
4825 </p>
4826
4827 <p>
4828 b) That assignments to the output iterator are made in order
4829 X a(x); ++a; *a=1; *x=2; is allowed
4830 </p>
4831
4832 <p>
4833 c) Chains of output iterators cannot be constructed:
4834 X a(x); ++a; X b(a); ++b; X c(b); ++c; is allowed, and under the current
4835 wording (I believe) x,a,b,c could be written to in any order.
4836 </p>
4837
4838 <p>I do not believe this was the intension of the standard?</p>
4839 <p><i>[Lillehammer: Real issue.  There are lots of constraints we
4840   intended but didn't specify.  Should be solved as part of iterator
4841   redesign.]</i></p>
4842
4843
4844
4845 <p><b>Proposed resolution:</b></p>
4846
4847
4848
4849
4850
4851 <hr>
4852 <h3><a name="492"></a>492. Invalid iterator arithmetic expressions</h3>
4853 <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>
4854  <b>Submitter:</b> Thomas Mang <b>Date:</b> 2004-12-12</p>
4855 <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>
4856 <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>
4857 <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>
4858 <p><b>Discussion:</b></p>
4859 <p>Various clauses other than clause 25 make use of iterator arithmetic not
4860 supported by the iterator category in question.
4861 Algorithms in clause 25 are exceptional because of 25 [lib.algorithms],
4862 paragraph 9, but this paragraph does not provide semantics to the
4863 expression "iterator - n", where n denotes a value of a distance type
4864 between iterators.</p>
4865
4866 <p>1) Examples of current wording:</p>
4867
4868 <p>Current wording outside clause 25:</p>
4869
4870 <p>
4871 23.2.2.4 [lib.list.ops], paragraphs 19-21: "first + 1", "(i - 1)",
4872 "(last - first)"
4873 23.3.1.1 [lib.map.cons], paragraph 4: "last - first"
4874 23.3.2.1 [lib.multimap.cons], paragraph 4: "last - first"
4875 23.3.3.1 [lib.set.cons], paragraph 4: "last - first"
4876 23.3.4.1 [lib.multiset.cons], paragraph 4: "last - first"
4877 24.4.1 [lib.reverse.iterators], paragraph 1: "(i - 1)"
4878 </p>
4879
4880 <p>
4881 [Important note: The list is not complete, just an illustration. The
4882 same issue might well apply to other paragraphs not listed here.]</p>
4883
4884 <p>None of these expressions is valid for the corresponding iterator
4885 category.</p>
4886
4887 <p>Current wording in clause 25:</p>
4888
4889 <p>
4890 25.1.1 [lib.alg.foreach], paragraph 1: "last - 1"
4891 25.1.3 [lib.alg.find.end], paragraph 2: "[first1, last1 -
4892 (last2-first2))"
4893 25.2.8 [lib.alg.unique], paragraph 1: "(i - 1)"
4894 25.2.8 [lib.alg.unique], paragraph 5: "(i - 1)"
4895 </p>
4896
4897 <p>
4898 However, current wording of 25 [lib.algorithms], paragraph 9 covers
4899 neither of these four cases:</p>
4900
4901 <p>Current wording of 25 [lib.algorithms], paragraph 9:</p>
4902
4903 <p>
4904 "In the description of the algorithms operator + and - are used for some
4905 of the iterator categories for which they do not have to be defined. In
4906 these cases the semantics of a+n is the same as that of</p>
4907 <pre>{X tmp = a;
4908 advance(tmp, n);
4909 return tmp;
4910 }
4911 </pre>
4912 <p>and that of b-a is the same as of return distance(a, b)"</p>
4913
4914 <p>
4915 This paragrpah does not take the expression "iterator - n" into account,
4916 where n denotes a value of a distance type between two iterators [Note:
4917 According to current wording, the expression "iterator - n" would be
4918 resolved as equivalent to "return distance(n, iterator)"]. Even if the
4919 expression "iterator - n" were to be reinterpreted as equivalent to
4920 "iterator + -n" [Note: This would imply that "a" and "b" were
4921 interpreted implicitly as values of iterator types, and "n" as value of
4922 a distance type], then 24.3.4/2 interfers because it says: "Requires: n
4923 may be negative only for random access and bidirectional iterators.",
4924 and none of the paragraphs quoted above requires the iterators on which
4925 the algorithms operate to be of random access or bidirectional category.
4926 </p>
4927
4928 <p>2) Description of intended behavior:</p>
4929
4930 <p>
4931 For the rest of this Defect Report, it is assumed that the expression
4932 "iterator1 + n" and "iterator1 - iterator2" has the semantics as
4933 described in current 25 [lib.algorithms], paragraph 9, but applying to
4934 all clauses. The expression "iterator1 - n" is equivalent to an
4935 result-iterator for which the expression "result-iterator + n" yields an
4936 iterator denoting the same position as iterator1 does. The terms
4937 "iterator1", "iterator2" and "result-iterator" shall denote the value of
4938 an iterator type, and the term "n" shall denote a value of a distance
4939 type between two iterators.</p>
4940
4941 <p>
4942 All implementations known to the author of this Defect Report comply
4943 with these assumptions.
4944 No impact on current code is expected.</p>
4945
4946 <p>3) Proposed fixes:</p>
4947
4948
4949 <p>Change 25 [lib.algorithms], paragraph 9 to:</p>
4950
4951 <p>
4952 "In the description of the algorithms operator + and - are used for some
4953 of the iterator categories for which they do not have to be defined. In
4954 this paragraph, a and b denote values of an iterator type, and n denotes
4955 a value of a distance type between two iterators. In these cases the
4956 semantics of a+n is the same as that of</p>
4957 <pre>{X tmp = a;
4958 advance(tmp, n);
4959 return tmp;
4960 }
4961 </pre>
4962 <p>,the semantics of a-n denotes the value of an iterator i for which the
4963 following condition holds:
4964 advance(i, n) == a,
4965 and that of b-a is the same as of
4966 return distance(a, b)".
4967 </p>
4968
4969 <p>Comments to the new wording:</p>
4970
4971 <p>
4972 a) The wording " In this paragraph, a and b denote values of an iterator
4973 type, and n denotes a value of a distance type between two iterators."
4974 was added so the expressions "b-a" and "a-n" are distinguished regarding
4975 the types of the values on which they operate.
4976 b) The wording ",the semantics of a-n denotes the value of an iterator i
4977 for which the following condition holds: advance(i, n) == a" was added
4978 to cover the expression 'iterator - n'. The wording "advance(i, n) == a"
4979 was used to avoid a dependency on the semantics of a+n, as the wording
4980 "i + n == a" would have implied. However, such a dependency might well
4981 be deserved.
4982 c) DR 225 is not considered in the new wording.
4983 </p>
4984
4985 <p>
4986 Proposed fixes regarding invalid iterator arithmetic expressions outside
4987 clause 25:</p>
4988
4989 <p>
4990 Either
4991 a) Move modified 25 [lib.algorithms], paragraph 9 (as proposed above)
4992 before any current invalid iterator arithmetic expression. In that case,
4993 the first sentence of 25 [lib.algorithms], paragraph 9, need also to be
4994 modified and could read: "For the rest of this International Standard,
4995 ...." / "In the description of the following clauses including this
4996 ...." / "In the description of the text below ..." etc. - anyways
4997 substituting the wording "algorithms", which is a straight reference to
4998 clause 25.
4999 In that case, 25 [lib.algorithms] paragraph 9 will certainly become
5000 obsolete.
5001 Alternatively,
5002 b) Add an appropiate paragraph similar to resolved 25 [lib.algorithms],
5003 paragraph 9, to the beginning of each clause containing invalid iterator
5004 arithmetic expressions.
5005 Alternatively,
5006 c) Fix each paragraph (both current wording and possible resolutions of
5007 DRs) containing invalid iterator arithmetic expressions separately.
5008 </p>
5009
5010 <p>5) References to other DRs:</p>
5011
5012 <p>
5013 See DR 225.
5014 See DR 237. The resolution could then also read "Linear in last -
5015 first".
5016 </p>
5017
5018 <p><i>[
5019 Bellevue:
5020 ]</i></p>
5021
5022
5023 <blockquote>
5024 Keep open and ask Bill to provide wording.
5025 </blockquote>
5026
5027
5028 <p><b>Proposed resolution:</b></p>
5029
5030 <p><i>[Lillehammer: Minor issue, but real. We have a blanket statement
5031 about this in 25/11. But (a) it should be in 17, not 25; and (b) it's
5032 not quite broad enough, because there are some arithmetic expressions
5033 it doesn't cover. Bill will provide wording.]</i></p>
5034
5035
5036
5037
5038
5039
5040
5041 <hr>
5042 <h3><a name="498"></a>498. Requirements for partition() and stable_partition() too strong</h3>
5043 <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>
5044  <b>Submitter:</b> Sean Parent, Joe Gottman <b>Date:</b> 2005-05-04</p>
5045 <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>
5046 <p><b>Discussion:</b></p>
5047 <p>
5048 Problem:
5049 The iterator requirements for partition() and stable_partition() [25.2.12]
5050 are listed as BidirectionalIterator, however, there are efficient algorithms
5051 for these functions that only require ForwardIterator that have been known
5052 since before the standard existed. The SGI implementation includes these (see
5053 <a href="http://www.sgi.com/tech/stl/partition.html">http://www.sgi.com/tech/stl/partition.html</a>
5054 and
5055 <a href="http://www.sgi.com/tech/stl/stable_partition.html">http://www.sgi.com/tech/stl/stable_partition.html</a>).
5056 </p>
5057
5058
5059 <p><b>Proposed resolution:</b></p>
5060 <p>
5061 Change 25.2.12 from </p>
5062 <blockquote><pre>template&lt;class BidirectionalIterator, class Predicate&gt;
5063 BidirectionalIterator partition(BidirectionalIterato r first,
5064                                 BidirectionalIterator last,
5065                                 Predicate pred);
5066 </pre></blockquote>
5067 <p>to </p>
5068 <blockquote><pre>template&lt;class ForwardIterator, class Predicate&gt;
5069 ForwardIterator partition(ForwardIterator first,
5070                           ForwardIterator last,
5071                           Predicate pred);
5072 </pre></blockquote>
5073 <p>Change the complexity from </p>
5074
5075 <blockquote><p>
5076 At most (last - first)/2 swaps are done. Exactly (last - first)
5077 applications of the predicate are done.
5078 </p></blockquote>
5079
5080 <p>to </p>
5081
5082 <blockquote><p>
5083 If ForwardIterator is a bidirectional_iterator, at most (last - first)/2
5084 swaps are done; otherwise at most (last - first) swaps are done. Exactly
5085 (last - first) applications of the predicate are done.
5086 </p></blockquote>
5087
5088
5089
5090 <p><b>Rationale:</b></p>
5091 <p>
5092 Partition is a "foundation" algorithm useful in many contexts (like sorting
5093 as just one example) - my motivation for extending it to include forward
5094 iterators is slist - without this extension you can't partition an slist
5095 (without writing your own partition). Holes like this in the standard
5096 library weaken the argument for generic programming (ideally I'd be able
5097 to provide a library that would refine std::partition() to other concepts
5098 without fear of conflicting with other libraries doing the same - but
5099 that is a digression). I consider the fact that partition isn't defined
5100 to work for ForwardIterator a minor embarrassment.
5101 </p>
5102
5103 <p><i>[Mont Tremblant: Moved to Open, request motivation and use cases
5104 by next meeting. Sean provided further rationale by post-meeting
5105 mailing.]</i></p>
5106
5107
5108
5109
5110
5111
5112
5113 <hr>
5114 <h3><a name="502"></a>502. Proposition: Clarification of the interaction between a facet and an iterator</h3>
5115 <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>
5116  <b>Submitter:</b> Christopher Conrade Zseleghovski <b>Date:</b> 2005-06-07</p>
5117 <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>
5118 <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>
5119 <p><b>Discussion:</b></p>
5120 <p>
5121 Motivation:
5122 </p>
5123
5124 <p>
5125 This requirement seems obvious to me, it is the essence of code modularity.
5126 I have complained to Mr. Plauger that the Dinkumware library does not
5127 observe this principle but he objected that this behaviour is not covered in
5128 the standard.
5129 </p>
5130
5131
5132 <p><b>Proposed resolution:</b></p>
5133 <p>
5134 Append the following point to 22.1.1.1.1:
5135 </p>
5136
5137 <p>
5138 6. The implementation of a facet of Table 52 parametrized with an
5139 InputIterator/OutputIterator should use that iterator only as character
5140 source/sink respectively.
5141 For a *_get facet, it means that the value received depends only on the
5142 sequence of input characters and not on how they are accessed.
5143 For a *_put facet, it means that the sequence of characters output depends
5144 only on the value to be formatted and not of how the characters are stored.
5145 </p>
5146
5147 <p><i>[
5148 Berlin:  Moved to Open, Need to clean up this area to make it clear
5149 locales don't have to contain open ended sets of facets. Jack, Howard,
5150 Bill.
5151 ]</i></p>
5152
5153
5154
5155
5156
5157
5158
5159 <hr>
5160 <h3><a name="503"></a>503. more on locales</h3>
5161 <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>
5162  <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2005-06-20</p>
5163 <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>
5164 <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>
5165 <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>
5166 <p><b>Discussion:</b></p>
5167 <p>
5168 a) In 22.2.1.1 para. 2 we refer to "the instantiations required in Table
5169 51" to refer to the facet *objects* associated with a locale. And we
5170 almost certainly mean just those associated with the default or "C"
5171 locale. Otherwise, you can't switch to a locale that enforces a different
5172 mapping between narrow and wide characters, or that defines additional
5173 uppercase characters.
5174 </p>
5175
5176 <p>
5177 b) 22.2.1.5 para. 3 (codecvt) has the same issues.
5178 </p>
5179
5180 <p>
5181 c) 22.2.1.5.2 (do_unshift) is even worse. It *forbids* the generation of
5182 a homing sequence for the basic character set, which might very well need
5183 one.
5184 </p>
5185
5186 <p>
5187 d) 22.2.1.5.2 (do_length) likewise dictates that the default mapping
5188 between wide and narrow characters be taken as one-for-one.
5189 </p>
5190
5191 <p>
5192 e) 22.2.2 para. 2 (num_get/put) is both muddled and vacuous, as far as
5193 I can tell. The muddle is, as before, calling Table 51 a list of
5194 instantiations. But the constraint it applies seems to me to cover
5195 *all* defined uses of num_get/put, so why bother to say so?
5196 </p>
5197
5198 <p>
5199 f) 22.2.3.1.2 para. 1(do_decimal_point) says "The required instantiations
5200 return '.' or L'.'.) Presumably this means "as appropriate for the
5201 character type. But given the vague definition of "required" earlier,
5202 this overrules *any* change of decimal point for non "C" locales.
5203 Surely we don't want to do that.
5204 </p>
5205
5206 <p>
5207 g) 22.2.3.1.2 para. 2 (do_thousands_sep) says "The required instantiations
5208 return ',' or L','.) As above, this probably means "as appropriate for the
5209 character type. But this overrules the "C" locale, which requires *no*
5210 character ('\0') for the thousands separator. Even if we agree that we
5211 don't mean to block changes in decimal point or thousands separator,
5212 we should also eliminate this clear incompatibility with C.
5213 </p>
5214
5215 <p>
5216 h) 22.2.3.1.2 para. 2 (do_grouping) says "The required instantiations
5217 return the empty string, indicating no grouping." Same considerations
5218 as for do_decimal_point.
5219 </p>
5220
5221 <p>
5222 i) 22.2.4.1 para. 1 (collate) refers to "instantiations required in Table
5223 51". Same bad jargon.
5224 </p>
5225
5226 <p>
5227 j) 22.2.4.1.2 para. 1 (do_compare) refers to "instantiations required
5228 in Table 51". Same bad jargon.
5229 </p>
5230
5231 <p>
5232 k) 22.2.5 para. 1 (time_get/put) uses the same muddled and vacuous
5233 as num_get/put.
5234 </p>
5235
5236 <p>
5237 l) 22.2.6 para. 2 (money_get/put) uses the same muddled and vacuous
5238 as num_get/put.
5239 </p>
5240
5241 <p>
5242 m) 22.2.6.3.2 (do_pos/neg_format) says "The instantiations required
5243 in Table 51 ... return an object of type pattern initialized to
5244 {symbol, sign, none, value}." This once again *overrides* the "C"
5245 locale, as well as any other locale."
5246 </p>
5247
5248 <p>
5249 3) We constrain the use_facet calls that can be made by num_get/put,
5250 so why don't we do the same for money_get/put? Or for any of the
5251 other facets, for that matter?
5252 </p>
5253
5254 <p>
5255 4) As an almost aside, we spell out when a facet needs to use the ctype
5256 facet, but several also need to use a codecvt facet and we don't say so.
5257 </p>
5258 <p><i>[
5259 Berlin: Bill to provide wording.
5260 ]</i></p>
5261
5262
5263
5264 <p><b>Proposed resolution:</b></p>
5265 <p>
5266 </p>
5267
5268
5269
5270
5271
5272 <hr>
5273 <h3><a name="522"></a>522. Tuple doesn't define swap</h3>
5274 <p><b>Section:</b> 20.4 [tuple], TR1 6.1 [tr.tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
5275  <b>Submitter:</b> Andy Koenig <b>Date:</b> 2005-07-03</p>
5276 <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>
5277 <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>
5278 <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>
5279 <p><b>Discussion:</b></p>
5280 <p>
5281 Tuple doesn't define swap().  It should.
5282 </p>
5283 <p><i>[
5284 Berlin: Doug to provide wording.
5285 ]</i></p>
5286
5287 <p><i>[
5288 Batavia: Howard to provide wording.
5289 ]</i></p>
5290
5291 <p><i>[
5292 Toronto: Howard to provide wording (really this time).
5293 ]</i></p>
5294
5295
5296 <p><i>[
5297 Bellevue:  Alisdair provided wording.
5298 ]</i></p>
5299
5300
5301
5302
5303 <p><b>Proposed resolution:</b></p>
5304
5305 <p>
5306 Add these signatures to 20.4 [tuple]
5307 </p>
5308
5309 <blockquote><pre>template &lt;class... Types&gt;
5310   void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp; y);
5311 template &lt;class... Types&gt;
5312   void swap(tuple&lt;Types...&gt;&amp;&amp; x, tuple&lt;Types...&gt;&amp; y);
5313 template &lt;class... Types&gt;
5314   void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp;&amp; y);
5315 </pre></blockquote>
5316
5317 <p>
5318 Add this signature to 20.4.1 [tuple.tuple]
5319 </p>
5320
5321 <blockquote><pre>void swap(tuple&amp;&amp;);
5322 </pre></blockquote>
5323
5324 <p>
5325 Add the following two sections to the end of the tuple clauses
5326 </p>
5327
5328 <blockquote>
5329 <p>
5330 20.3.1.7 tuple swap [tuple.swap]
5331 </p>
5332
5333 <pre>void swap(tuple&amp;&amp; rhs);
5334 </pre>
5335
5336 <blockquote>
5337 <p>
5338 <i>Requires:</i> Each type in <tt>Types</tt> shall be <tt>Swappable</tt>.
5339 </p>
5340 <p>
5341 <i>Effects:</i> Calls <tt>swap</tt> for each element in <tt>*this</tt> and its corresponding element
5342 in <tt>rhs</tt>.
5343 </p>
5344 <p>
5345 <i>Throws:</i> Nothing, unless one of the element-wise <tt>swap</tt> calls throw an
5346 exception.
5347 </p>
5348 </blockquote>
5349
5350 <p>
5351 20.3.1.8 tuple specialized algorithms [tuple.special]
5352 </p>
5353
5354 <pre>template &lt;class... Types&gt;
5355   void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp; y);
5356 template &lt;class... Types&gt;
5357   void swap(tuple&lt;Types...&gt;&amp;&amp; x, tuple&lt;Types...&gt;&amp; y);
5358 template &lt;class... Types&gt;
5359   void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp;&amp; y);
5360 </pre>
5361
5362 <blockquote>
5363 <p>
5364 <i>Effects:</i> x.swap(y)
5365 </p>
5366 </blockquote>
5367 </blockquote>
5368
5369
5370
5371
5372
5373
5374 <hr>
5375 <h3><a name="523"></a>523. regex case-insensitive character ranges are unimplementable as specified</h3>
5376 <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>
5377  <b>Submitter:</b> Eric Niebler <b>Date:</b> 2005-07-01</p>
5378 <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>
5379 <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>
5380 <p><b>Discussion:</b></p>
5381 <p>
5382 A problem with TR1 regex is currently being discussed on the Boost
5383 developers list. It involves the handling of case-insensitive matching
5384 of character ranges such as [Z-a]. The proper behavior (according to the
5385 ECMAScript standard) is unimplementable given the current specification
5386 of the TR1 regex_traits&lt;&gt; class template. John Maddock, the author of
5387 the TR1 regex proposal, agrees there is a problem. The full discussion
5388 can be found at http://lists.boost.org/boost/2005/06/28850.php (first
5389 message copied below). We don't have any recommendations as yet.
5390 </p>
5391 <p>
5392 -- Begin original message --
5393 </p>
5394 <p>
5395 The situation of interest is described in the ECMAScript specification
5396 (ECMA-262), section 15.10.2.15:
5397 </p>
5398 <p>
5399 "Even if the pattern ignores case, the case of the two ends of a range
5400 is significant in determining which characters belong to the range.
5401 Thus, for example, the pattern /[E-F]/i matches only the letters E, F,
5402 e, and f, while the pattern /[E-f]/i matches all upper and lower-case
5403 ASCII letters as well as the symbols [, \, ], ^, _, and `."
5404 </p>
5405 <p>
5406 A more interesting case is what should happen when doing a
5407 case-insentitive match on a range such as [Z-a]. It should match z, Z,
5408 a, A and the symbols [, \, ], ^, _, and `. This is not what happens with
5409 Boost.Regex (it throws an exception from the regex constructor).
5410 </p>
5411 <p>
5412 The tough pill to swallow is that, given the specification in TR1, I
5413 don't think there is any effective way to handle this situation.
5414 According to the spec, case-insensitivity is handled with
5415 regex_traits&lt;&gt;::translate_nocase(CharT) -- two characters are equivalent
5416 if they compare equal after both are sent through the translate_nocase
5417 function. But I don't see any way of using this translation function to
5418 make character ranges case-insensitive. Consider the difficulty of
5419 detecting whether "z" is in the range [Z-a]. Applying the transformation
5420 to "z" has no effect (it is essentially std::tolower). And we're not
5421 allowed to apply the transformation to the ends of the range, because as
5422 ECMA-262 says, "the case of the two ends of a range is significant."
5423 </p>
5424 <p>
5425 So AFAICT, TR1 regex is just broken, as is Boost.Regex. One possible fix
5426 is to redefine translate_nocase to return a string_type containing all
5427 the characters that should compare equal to the specified character. But
5428 this function is hard to implement for Unicode, and it doesn't play nice
5429 with the existing ctype facet. What a mess!
5430 </p>
5431 <p>
5432 -- End original message --
5433 </p>
5434
5435 <p><i>[
5436 John Maddock adds:
5437 ]</i></p>
5438
5439
5440 <p>
5441 One small correction, I have since found that ICU's regex package does
5442 implement this correctly, using a similar mechanism to the current
5443 TR1.Regex.
5444 </p>
5445 <p>
5446 Given an expression [c1-c2] that is compiled as case insensitive it:
5447 </p>
5448 <p>
5449 Enumerates every character in the range c1 to c2 and converts it to it's
5450 case folded equivalent.  That case folded character is then used a key to a
5451 table of equivalence classes, and each member of the class is added to the
5452 list of possible matches supported by the character-class.  This second step
5453 isn't possible with our current traits class design, but isn't necessary if
5454 the input text is also converted to a case-folded equivalent on the fly.
5455 </p>
5456 <p>
5457 ICU applies similar brute force mechanisms to character classes such as
5458 [[:lower:]] and [[:word:]], however these are at least cached, so the impact
5459 is less noticeable in this case.
5460 </p>
5461 <p>
5462 Quick and dirty performance comparisons show that expressions such as
5463 "[X-\\x{fff0}]+" are indeed very slow to compile with ICU (about 200 times
5464 slower than a "normal" expression).  For an application that uses a lot of
5465 regexes this could have a noticeable performance impact.  ICU also has an
5466 advantage in that it knows the range of valid characters codes: code points
5467 outside that range are assumed not to require enumeration, as they can not
5468 be part of any equivalence class.  I presume that if we want the TR1.Regex
5469 to work with arbitrarily large character sets enumeration really does become
5470 impractical.
5471 </p>
5472 <p>
5473 Finally note that Unicode has:
5474 </p>
5475 <p>
5476 Three cases (upper, lower and title).
5477 One to many, and many to one case transformations.
5478 Character that have context sensitive case translations - for example an
5479 uppercase sigma has two different lowercase forms  - the form chosen depends
5480 on context(is it end of a word or not), a caseless match for an upper case
5481 sigma should match either of the lower case forms, which is why case folding
5482 is often approximated by tolower(toupper(c)).
5483 </p>
5484 <p>
5485 Probably we need some way to enumerate character equivalence classes,
5486 including digraphs (either as a result or an input), and some way to tell
5487 whether the next character pair is a valid digraph in the current locale.
5488 </p>
5489 <p>
5490 Hoping this doesn't make this even more complex that it was already,
5491 </p>
5492
5493 <p><i>[
5494 Portland:  Alisdair: Detect as invalid, throw an exception.
5495 Pete: Possible general problem with case insensitive ranges.
5496 ]</i></p>
5497
5498
5499
5500
5501 <p><b>Proposed resolution:</b></p>
5502
5503
5504
5505
5506
5507 <hr>
5508 <h3><a name="539"></a>539. partial_sum and adjacent_difference should mention requirements</h3>
5509 <p><b>Section:</b> 26.6.3 [partial.sum] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
5510  <b>Submitter:</b> Marc Schoolderman <b>Date:</b> 2006-02-06</p>
5511 <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>
5512 <p><b>Discussion:</b></p>
5513 <p>
5514 There are some problems in the definition of partial_sum and
5515 adjacent_difference in 26.4 [lib.numeric.ops]
5516 </p>
5517
5518 <p>
5519 Unlike <tt>accumulate</tt> and <tt>inner_product</tt>, these functions are not
5520 parametrized on a "type T", instead, 26.4.3 [lib.partial.sum] simply
5521 specifies the effects clause as;
5522 </p>
5523
5524 <blockquote><p>
5525 Assigns to every element referred to by iterator <tt>i</tt> in the range
5526 <tt>[result,result + (last - first))</tt> a value correspondingly equal to
5527 </p>
5528 <blockquote><pre>((...(* first + *( first + 1)) + ...) + *( first + ( i - result )))
5529 </pre></blockquote>
5530 </blockquote>
5531
5532 <p>
5533 And similarly for BinaryOperation. Using just this definition, it seems
5534 logical to expect that:
5535 </p>
5536
5537
5538 <blockquote><pre>char i_array[4] = { 100, 100, 100, 100 };
5539 int  o_array[4];
5540
5541 std::partial_sum(i_array, i_array+4, o_array);
5542 </pre></blockquote>
5543
5544 <p>
5545 Is equivalent to
5546 </p>
5547
5548 <blockquote><pre>int o_array[4] = { 100, 100+100, 100+100+100, 100+100+100+100 };
5549 </pre></blockquote>
5550
5551 <p>
5552 i.e. 100, 200, 300, 400, with addition happening in the <tt>result type</tt>,
5553 <tt>int</tt>.
5554 </p>
5555
5556 <p>
5557 Yet all implementations I have tested produce 100, -56, 44, -112,
5558 because they are using an accumulator of the <tt>InputIterator</tt>'s
5559 <tt>value_type</tt>, which in this case is <tt>char</tt>, not <tt>int</tt>.
5560 </p>
5561
5562 <p>
5563 The issue becomes more noticeable when the result of the expression <tt>*i +
5564 *(i+1)</tt> or <tt>binary_op(*i, *i-1)</tt> can't be converted to the
5565 <tt>value_type</tt>. In a contrived example:
5566 </p>
5567
5568 <blockquote><pre>enum not_int { x = 1, y = 2 };
5569 ...
5570 not_int e_array[4] = { x, x, y, y };
5571 std::partial_sum(e_array, e_array+4, o_array);
5572 </pre></blockquote>
5573
5574 <p>
5575 Is it the intent that the operations happen in the <tt>input type</tt>, or in
5576 the <tt>result type</tt>?
5577 </p>
5578
5579 <p>
5580 If the intent is that operations happen in the <tt>result type</tt>, something
5581 like this should be added to the "Requires" clause of 26.4.3/4
5582 [lib.partial.sum]:
5583 </p>
5584
5585 <blockquote><p>
5586 The type of <tt>*i + *(i+1)</tt> or <tt>binary_op(*i, *(i+1))</tt> shall meet the
5587 requirements of <tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt>
5588 (23.1) types.
5589 </p></blockquote>
5590
5591 <p>
5592 (As also required for <tt>T</tt> in 26.4.1 [lib.accumulate] and 26.4.2
5593 [lib.inner.product].)
5594 </p>
5595
5596 <p>
5597 The "auto initializer" feature proposed in
5598 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1894.pdf">N1894</a>
5599 is not required to
5600 implement <tt>partial_sum</tt> this way. The 'narrowing' behaviour can still be
5601 obtained by using the <tt>std::plus&lt;&gt;</tt> function object.
5602 </p>
5603
5604 <p>
5605 If the intent is that operations happen in the <tt>input type</tt>, then
5606 something like this should be added instead;
5607 </p>
5608
5609 <blockquote><p>
5610 The type of *first shall meet the requirements of
5611 <tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt> (23.1) types.
5612 The result of <tt>*i + *(i+1)</tt> or <tt>binary_op(*i, *(i+1))</tt> shall be
5613 convertible to this type.
5614 </p></blockquote>
5615
5616 <p>
5617 The 'widening' behaviour can then be obtained by writing a custom proxy
5618 iterator, which is somewhat involved.
5619 </p>
5620
5621 <p>
5622 In both cases, the semantics should probably be clarified.
5623 </p>
5624
5625 <p>
5626 26.4.4 [lib.adjacent.difference] is similarly underspecified, although
5627 all implementations seem to perform operations in the 'result' type:
5628 </p>
5629
5630 <blockquote><pre>unsigned char i_array[4] = { 4, 3, 2, 1 };
5631 int o_array[4];
5632
5633 std::adjacent_difference(i_array, i_array+4, o_array);
5634 </pre></blockquote>
5635
5636 <p>
5637 o_array is 4, -1, -1, -1 as expected, not 4, 255, 255, 255.
5638 </p>
5639
5640 <p>
5641 In any case, <tt>adjacent_difference</tt> doesn't mention the requirements on the
5642 <tt>value_type</tt>; it can be brought in line with the rest of 26.4
5643 [lib.numeric.ops] by adding the following to 26.4.4/2
5644 [lib.adjacent.difference]:
5645 </p>
5646
5647 <blockquote><p>
5648 The type of <tt>*first</tt> shall meet the requirements of
5649 <tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt> (23.1) types."
5650 </p></blockquote>
5651 <p><i>[
5652 Berlin: Giving output iterator's value_types very controversial. Suggestion of
5653 adding signatures to allow user to specify "accumulator".
5654 ]</i></p>
5655
5656
5657 <p><i>[
5658 Bellevue:
5659 ]</i></p>
5660
5661
5662 <blockquote>
5663 The intent of the algorithms is to perform their calculations using the type of the input iterator.
5664 Proposed wording provided.
5665 </blockquote>
5666
5667 <p><i>[
5668 Sophia Antipolis:
5669 ]</i></p>
5670
5671
5672 <blockquote>
5673 We did not agree that the proposed resolution was correct. For example,
5674 when the arguments are types <tt>(float*, float*, double*)</tt>, the
5675 highest-quality solution would use double as the type of the
5676 accumulator. If the intent of the wording is to require that the type of
5677 the accumulator must be the <tt>input_iterator</tt>'s <tt>value_type</tt>, the wording
5678 should specify it.
5679 </blockquote>
5680
5681
5682
5683 <p><b>Proposed resolution:</b></p>
5684 <p>
5685 Add to section 26.6.3 [partial.sum] paragraph 4 the following two sentences:
5686 </p>
5687
5688 <blockquote>
5689 The type of <tt>*first</tt> shall meet the requirements of <tt>CopyConstructible</tt>?
5690 (20.1.3?) and <tt>Assignable</tt> (23.1?) types. The result of <tt>*i + *(i+1)</tt> or
5691 <tt>binary_op(*i, *(i+1))</tt> shall be convertible to this type.
5692 </blockquote>
5693
5694 <p>
5695 Add to section 26.6.4 [adjacent.difference] paragraph 2 the following sentence:
5696 </p>
5697
5698 <blockquote>
5699 The type of <tt>*first</tt> shall meet the requirements of <tt>CopyConstructible</tt>?
5700 (20.1.3) and <tt>Assignable</tt> (23.1) types.
5701 </blockquote>
5702
5703
5704
5705
5706
5707
5708 <hr>
5709 <h3><a name="546"></a>546. _Longlong and _ULonglong are integer types</h3>
5710 <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>
5711  <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p>
5712 <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>
5713 <p><b>Discussion:</b></p>
5714 <p>
5715 The TR sneaks in two new integer types, _Longlong and _Ulonglong, in [tr.c99].
5716 The rest of the TR should use that type.  I believe this affects two places.
5717 First, the random number requirements, 5.1.1/10-11, lists all of the types with
5718 which template parameters named IntType and UIntType may be instantiated.
5719 _Longlong (or "long long", assuming it is added to C++0x) should be added to the
5720 IntType list, and UIntType (again, or "unsigned long long") should be added to
5721 the UIntType list.  Second, 6.3.2 lists the types for which hash&lt;&gt; is
5722 required to be instantiable. _Longlong and _Ulonglong should be added to that
5723 list, so that people may use long long as a hash key.
5724 </p>
5725
5726
5727 <p><b>Proposed resolution:</b></p>
5728 <p>
5729 </p>
5730
5731
5732
5733
5734
5735 <hr>
5736 <h3><a name="556"></a>556. is Compare a BinaryPredicate?</h3>
5737 <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>
5738  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-05</p>
5739 <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>
5740 <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>
5741 <p><b>Discussion:</b></p>
5742 <p>
5743 In 25, p8 we allow BinaryPredicates to return a type that's convertible
5744 to bool but need not actually be bool. That allows predicates to return
5745 things like proxies and requires that implementations be careful about
5746 what kinds of expressions they use the result of the predicate in (e.g.,
5747 the expression in if (!pred(a, b)) need not be well-formed since the
5748 negation operator may be inaccessible or return a type that's not
5749 convertible to bool).
5750 </p>
5751 <p>
5752 Here's the text for reference:
5753 </p>
5754 <blockquote><p>
5755   ...if an algorithm takes BinaryPredicate binary_pred as its argument
5756  and first1 and first2 as its iterator arguments, it should work
5757  correctly in the construct if (binary_pred(*first1, first2)){...}.
5758 </p></blockquote>
5759
5760 <p>
5761 In 25.3, p2 we require that the Compare function object return true
5762 of false, which would seem to preclude such proxies. The relevant text
5763 is here:
5764 </p>
5765 <blockquote><p>
5766   Compare is used as a function object which returns true if the first
5767   argument is less than the second, and false otherwise...
5768 </p></blockquote>
5769
5770
5771 <p><b>Proposed resolution:</b></p>
5772 <p>
5773 I think we could fix this by rewording 25.3, p2 to read somthing like:
5774 </p>
5775 <blockquote><p>
5776 -2- <tt>Compare</tt> is <del>used as a function object which returns
5777 <tt>true</tt> if the first argument</del> <ins>a <tt>BinaryPredicate</tt>. The
5778 return value of the function call operator applied to an object of type
5779 <tt>Compare</tt>, when converted to type <tt>bool</tt>, yields <tt>true</tt>
5780 if the first argument of the call</ins> is less than the second, and
5781 <tt>false</tt> otherwise. <tt>Compare <i>comp</i></tt> is used throughout for
5782 algorithms assuming an ordering relation. It is assumed that <tt><i>comp</i></tt>
5783 will not apply any non-constant function through the dereferenced iterator.
5784 </p></blockquote>
5785
5786
5787 <p><i>[
5788 Portland:  Jack to define "convertible to bool" such that short circuiting isn't
5789 destroyed.
5790 ]</i></p>
5791
5792
5793
5794
5795
5796 <hr>
5797 <h3><a name="564"></a>564. stringbuf seekpos underspecified</h3>
5798 <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>
5799  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
5800 <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>
5801 <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>
5802 <p><b>Discussion:</b></p>
5803 <p>
5804 The   effects  of  the   <code>seekpos()</code>  member   function  of
5805 <code>basic_stringbuf</code>  simply say  that the  function positions
5806 the  input and/or  output  sequences  but fail  to  spell out  exactly
5807 how. This is in contrast  to the detail in which <code>seekoff()</code>
5808 is described.
5809 </p>
5810
5811
5812 <p><b>Proposed resolution:</b></p>
5813         <p>
5814
5815 Change 27.7.1.3, p13 to read:
5816
5817         </p>
5818 <blockquote>
5819 <p>
5820 -13- <i>Effects:</i> <ins>Same as <tt>seekoff(off_type(<i>sp</i>), ios_base::beg,
5821 <i>which</i>)</tt>.</ins> <del>Alters the stream position within the controlled sequences,
5822 if possible, to correspond to the stream position stored in <tt><i>sp</i></tt>
5823 (as described below).</del>
5824 </p>
5825 <ul>
5826 <li><del>If <tt>(<i>which</i> &amp; ios_base::in) != 0</tt>, positions the input sequence.</del></li>
5827 <li><del>If <tt>(<i>which</i> &amp; ios_base::out) != 0</tt>, positions the output sequence.</del></li>
5828 <li><del>If <tt><i>sp</i></tt> is an invalid stream position, or if the function
5829 positions neither sequence, the positioning operation fails. If <tt><i>sp</i></tt>
5830 has not been obtained by a previous successful call to one of the positioning
5831 functions (<tt>seekoff</tt>, <tt>seekpos</tt>, <tt>tellg</tt>, <tt>tellp</tt>)
5832 the effect is undefined.</del></li>
5833 </ul>
5834 </blockquote>
5835
5836
5837 <p><i>[
5838 Kona (2007): A <tt>pos_type</tt> is a position in a stream by
5839 definition, so there is no ambiguity as to what it means. Proposed
5840 Disposition: NAD
5841 ]</i></p>
5842
5843
5844 <p><i>[
5845 Post-Kona Martin adds:
5846 I'm afraid I disagree
5847 with the Kona '07 rationale for marking it NAD. The only text
5848 that describes precisely what it means to position the input
5849 or output sequence is in <tt>seekoff()</tt>. The <tt>seekpos()</tt> Effects
5850 clause is inadequate in comparison and the proposed resolution
5851 plugs the hole by specifying <tt>seekpos()</tt> in terms of <tt>seekoff()</tt>.
5852 ]</i></p>
5853
5854
5855
5856
5857
5858 <hr>
5859 <h3><a name="565"></a>565. xsputn inefficient</h3>
5860 <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>
5861  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
5862 <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>
5863 <p><b>Discussion:</b></p>
5864         <p>
5865
5866 <tt>streambuf::xsputn()</tt>  is  specified  to  have  the  effect  of
5867 "writing up to  <tt>n</tt> characters to the output  sequence as if by
5868 repeated calls to <tt>sputc(c)</tt>."
5869
5870         </p>
5871         <p>
5872
5873 Since  <tt>sputc()</tt> is required  to call  <tt>overflow()</tt> when
5874 <tt>(pptr()    ==   epptr())</tt>    is   true,    strictly   speaking
5875 <tt>xsputn()</tt>  should do  the same.   However, doing  so  would be
5876 suboptimal in  some interesting cases,  such as in unbuffered  mode or
5877 when the buffer is <tt>basic_stringbuf</tt>.
5878
5879         </p>
5880         <p>
5881
5882 Assuming  calling <tt>overflow()</tt>  is  not really  intended to  be
5883 required  and the  wording is  simply  meant to  describe the  general
5884 effect of appending to the end  of the sequence it would be worthwhile
5885 to  mention in  <tt>xsputn()</tt> that  the function  is  not actually
5886 required to cause a call to <tt>overflow()</tt>.
5887
5888         </p>
5889
5890
5891 <p><b>Proposed resolution:</b></p>
5892         <p>
5893
5894 Add the following sentence  to the <tt>xsputn()</tt> Effects clause in
5895 27.5.2.4.5, p1 (N1804):
5896
5897         </p>
5898         <blockquote>
5899             <p>
5900 -1- <i>Effects:</i> Writes up to <tt><i>n</i></tt> characters to the output
5901 sequence as if by repeated calls to <tt>sputc(<i>c</i>)</tt>. The characters
5902 written are obtained from successive elements of the array whose first element
5903 is designated by <tt><i>s</i></tt>. Writing stops when either <tt><i>n</i></tt>
5904 characters have been written or a call to <tt>sputc(<i>c</i>)</tt> would return
5905 <tt>traits::eof()</tt>. <ins>It is  uspecified whether the function  calls
5906 <tt>overflow()</tt> when <tt>(pptr() ==  epptr())</tt> becomes true or whether
5907 it achieves the same effects by other means.</ins>
5908             </p>
5909         </blockquote>
5910         <p>
5911
5912 In addition,  I suggest to  add a footnote  to this function  with the
5913 same text as Footnote 292 to  make it extra clear that derived classes
5914 are permitted to override <tt>xsputn()</tt> for efficiency.
5915
5916         </p>
5917
5918
5919 <p><i>[
5920 Kona (2007): We want to permit a <tt>streambuf</tt> that streams output directly
5921 to a device without making calls to <tt>sputc</tt> or <tt>overflow</tt>. We believe that
5922 has always been the intention of the committee. We believe that the
5923 proposed wording doesn't accomplish that. Proposed Disposition: Open
5924 ]</i></p>
5925
5926
5927
5928
5929
5930 <hr>
5931 <h3><a name="568"></a>568. log2 overloads missing</h3>
5932 <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>
5933  <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-03-07</p>
5934 <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>
5935 <p><b>Discussion:</b></p>
5936 <p>
5937 <tt>log2</tt> is missing from the list of "additional overloads" in TR1 8.16.4 [tr.c99.cmath.over] p1.
5938 </p>
5939
5940 <p>
5941 Hinnant:  This is a TR1 issue only.  It is fixed in the current (N2135) WD.
5942 </p>
5943
5944
5945 <p><b>Proposed resolution:</b></p>
5946 <p>
5947 Add <tt>log2</tt> to the list of functions in TR1 8.16.4 [tr.c99.cmath.over] p1.
5948 </p>
5949
5950
5951
5952
5953
5954 <hr>
5955 <h3><a name="573"></a>573. C++0x file positioning should handle modern file sizes</h3>
5956 <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>
5957  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-04-12</p>
5958 <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>
5959 <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>
5960 <p><b>Discussion:</b></p>
5961 <p>
5962 There are two deficiencies related to file sizes:
5963 </p>
5964 <ol>
5965 <li>It doesn't appear that the Standard Library is specified in
5966       a way that handles modern file sizes, which are often too
5967       large to be represented by an unsigned long.</li>
5968
5969 <li>The std::fpos class does not currently have the ability to
5970       set/get file positions.</li>
5971 </ol>
5972 <p>
5973 The Dinkumware implementation of the Standard Library as shipped with the Microsoft compiler copes with these issues by:
5974 </p>
5975 <ol type="A">
5976 <li>Defining fpos_t be long long, which is large enough to
5977       represent any file position likely in the foreseeable future.</li>
5978
5979 <li>Adding member functions to class fpos. For example,
5980 <blockquote><pre>fpos_t seekpos() const;
5981 </pre></blockquote>
5982 </li>
5983 </ol>
5984 <p>
5985 Because there are so many types relating to file positions and offsets (fpos_t,
5986 fpos, pos_type, off_type, streamoff, streamsize, streampos, wstreampos, and
5987 perhaps more), it is difficult to know if the Dinkumware extensions are
5988 sufficient. But they seem a useful starting place for discussions, and they do
5989 represent existing practice.
5990 </p>
5991
5992 <p><i>[
5993 Kona (2007): We need a paper. It would be nice if someone proposed
5994 clarifications to the definitions of <tt>pos_type</tt> and <tt>off_type</tt>. Currently
5995 these definitions are horrible. Proposed Disposition: Open
5996 ]</i></p>
5997
5998
5999
6000 <p><b>Proposed resolution:</b></p>
6001 <p>
6002 </p>
6003
6004
6005
6006
6007
6008 <hr>
6009 <h3><a name="580"></a>580. unused allocator members</h3>
6010 <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>
6011  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-14</p>
6012 <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>
6013 <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>
6014 <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>
6015 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a></p>
6016 <p><b>Discussion:</b></p>
6017         <p>
6018
6019 C++ Standard Library  templates that take an allocator  as an argument
6020 are    required    to    call    the    <code>allocate()</code>    and
6021 <code>deallocate()</code>  members of the  allocator object  to obtain
6022 storage.  However, they do not appear to be required to call any other
6023 allocator      members      such     as      <code>construct()</code>,
6024 <code>destroy()</code>,           <code>address()</code>,          and
6025 <code>max_size()</code>.  This makes these allocator members less than
6026 useful in portable programs.
6027
6028         </p>
6029         <p>
6030
6031 It's unclear to me whether the absence of the requirement to use these
6032 allocator  members  is  an  unintentional  omission  or  a  deliberate
6033 choice. However,  since the functions exist in  the standard allocator
6034 and  since  they are  required  to  be  provided by  any  user-defined
6035 allocator I  believe the standard  ought to be clarified  to explictly
6036 specify  whether programs  should or  should not  be able  to  rely on
6037 standard containers calling the functions.
6038
6039         </p>
6040         <p>
6041
6042 I  propose  that all  containers  be required  to  make  use of  these
6043 functions.
6044
6045         </p>
6046 <p><i>[
6047 Batavia:  We support this resolution.  Martin to provide wording.
6048 ]</i></p>
6049
6050 <p><i>[
6051 pre-Oxford:  Martin provided wording.
6052 ]</i></p>
6053
6054
6055
6056     <p><b>Proposed resolution:</b></p>
6057        <p>
6058
6059 Specifically, I propose to change 23.1 [container.requirements],
6060 p9 as follows:
6061
6062        </p>
6063            <blockquote>
6064 <p>
6065 -9- Copy constructors  for all container types defined  in this clause
6066 <ins>that   are  parametrized  on   <code>Allocator</code></ins>  copy
6067 <del>an</del><ins>the</ins>  allocator argument from  their respective
6068 first parameters.
6069
6070 All other  constructors for  these container types  take a<del>n</del>
6071 <ins>const</ins>  <code>Allocator&amp;</code>  argument  (20.1.6),  an
6072 allocator whose <code>value_type</code> is the same as the container's
6073 <code>value_type</code>.
6074
6075 A copy of this  argument <del>is</del><ins>shall be</ins> used for any
6076 memory  allocation <ins> and  deallocation</ins> performed<del>,</del>
6077 by these  constructors and by all  member functions<del>,</del> during
6078 the  lifetime  of each  container  object.   <ins>Allocation shall  be
6079 performed  "as  if"  by  calling  the  <code>allocate()</code>  member
6080 function on  a copy  of the allocator  object of the  appropriate type
6081 <sup>New  Footnote)</sup>,   and  deallocation  "as   if"  by  calling
6082 <code>deallocate()</code> on  a copy of  the same allocator  object of
6083 the corresponding type.</ins>
6084
6085 <ins>A  copy of  this argument  shall also  be used  to  construct and
6086 destroy objects whose lifetime  is managed by the container, including
6087 but not  limited to those of  the container's <code>value_type</code>,
6088 and  to  obtain  their  address.   All  objects  residing  in  storage
6089 allocated by a  container's allocator shall be constructed  "as if" by
6090 calling the <code>construct()</code> member  function on a copy of the
6091 allocator object of  the appropriate type.  The same  objects shall be
6092 destroyed "as if"  by calling <code>destroy()</code> on a  copy of the
6093 same allocator object  of the same type.  The  address of such objects
6094 shall be obtained "as if" by calling the <code>address()</code> member
6095 function  on  a  copy  of  the allocator  object  of  the  appropriate
6096 type.</ins>
6097
6098 <ins>Finally, a copy  of this argument shall be  used by its container
6099 object to determine  the maximum number of objects  of the container's
6100 <code>value_type</code> the container may  store at the same time. The
6101 container  member function <code>max_size()</code> obtains  this number
6102 from      the      value      returned      by     a      call      to
6103 <code>get_allocator().max_size()</code>.</ins>
6104
6105 In   all  container   types  defined   in  this   clause <ins>that  are
6106 parametrized     on    <code>Allocator</code></ins>,     the    member
6107 <code>get_allocator()</code>     returns     a     copy     of     the
6108 <code>Allocator</code>     object     used     to    construct     the
6109 container.<sup>258)</sup>
6110 </p>
6111 <p>
6112 New Footnote: This type  may be different from <code>Allocator</code>:
6113 it     may    be     derived    from     <code>Allocator</code>    via
6114 <code>Allocator::rebind&lt;U&gt;::other</code>   for  the  appropriate
6115 type <code>U</code>.
6116 </p>
6117            </blockquote>
6118        <p>
6119
6120 The proposed wording seems cumbersome but I couldn't think of a better
6121 way   to  describe   the   requirement  that   containers  use   their
6122 <code>Allocator</code>  to manage  only objects  (regardless  of their
6123 type)  that  persist  over  their  lifetimes  and  not,  for  example,
6124 temporaries  created on the  stack. That  is, containers  shouldn't be
6125 required  to  call  <code>Allocator::construct(Allocator::allocate(1),
6126 elem)</code>  just to  construct a  temporary copy  of an  element, or
6127 <code>Allocator::destroy(Allocator::address(temp),     1)</code>    to
6128 destroy temporaries.
6129
6130        </p>
6131
6132
6133 <p><i>[
6134 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>.
6135 ]</i></p>
6136
6137
6138 <p><i>[
6139 post Oxford:  This would be rendered NAD Editorial by acceptance of
6140 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
6141 ]</i></p>
6142
6143
6144
6145
6146
6147 <hr>
6148 <h3><a name="582"></a>582. specialized algorithms and volatile storage</h3>
6149 <p><b>Section:</b> 20.7.10.1 [uninitialized.copy] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
6150  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-14</p>
6151 <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>
6152 <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>
6153 <p><b>Discussion:</b></p>
6154         <p>
6155
6156 The specialized  algorithms [lib.specialized.algorithms] are specified
6157 as having the general effect of invoking the following expression:
6158
6159         </p>
6160             <pre>
6161 new (static_cast&lt;void*&gt;(&amp;*i))
6162     typename iterator_traits&lt;ForwardIterator&gt;::value_type (x)
6163
6164             </pre>
6165         <p>
6166
6167 This  expression is  ill-formed  when the  type  of the  subexpression
6168 <code>&amp;*i</code> is some volatile-qualified <code>T</code>.
6169
6170         </p>
6171
6172 <p><i>[
6173 Batavia:  Lack of support for proposed resolution but agree there is a
6174 defect.  Howard to look at wording.  Concern that move semantics
6175 properly expressed if iterator returns rvalue.
6176 ]</i></p>
6177
6178
6179
6180
6181     <p><b>Proposed resolution:</b></p>
6182         <p>
6183
6184 In order  to allow these algorithms  to operate on  volatile storage I
6185 propose to change the expression so as to make it well-formed even for
6186 pointers  to volatile  types.  Specifically,  I propose  the following
6187 changes to clauses 20 and 24. Change 20.6.4.1, p1 to read:
6188
6189         </p>
6190             <pre>
6191 <i>Effects</i>:
6192
6193 typedef typename iterator_traits&lt;ForwardIterator&gt;::pointer    pointer;
6194 typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type value_type;
6195
6196 for (; first != last; ++result, ++first)
6197     new (static_cast&lt;void*&gt;(const_cast&lt;pointer&gt;(&amp;*result))
6198         value_type (*first);
6199
6200             </pre>
6201         <p>
6202
6203 change 20.6.4.2, p1 to read
6204
6205         </p>
6206             <pre>
6207 <i>Effects</i>:
6208
6209 typedef typename iterator_traits&lt;ForwardIterator&gt;::pointer    pointer;
6210 typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type value_type;
6211
6212 for (; first != last; ++result, ++first)
6213     new (static_cast&lt;void*&gt;(const_cast&lt;pointer&gt;(&amp;*first))
6214         value_type (*x);
6215
6216             </pre>
6217         <p>
6218
6219 and change 20.6.4.3, p1 to read
6220
6221         </p>
6222             <pre>
6223 <i>Effects</i>:
6224
6225 typedef typename iterator_traits&lt;ForwardIterator&gt;::pointer    pointer;
6226 typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type value_type;
6227
6228 for (; n--; ++first)
6229     new (static_cast&lt;void*&gt;(const_cast&lt;pointer&gt;(&amp;*first))
6230         value_type (*x);
6231
6232             </pre>
6233         <p>
6234
6235 In   addition,  since   there   is  no   partial  specialization   for
6236 <code>iterator_traits&lt;volatile T*&gt;</code>  I propose to  add one
6237 to parallel such specialization  for &lt;const T*&gt;. Specifically, I
6238 propose to add the following text to the end of 24.3.1, p3:
6239
6240         </p>
6241         <p>
6242
6243 and for pointers to volatile as
6244
6245         </p>
6246             <pre>
6247 namespace std {
6248 template&lt;class T&gt; struct iterator_traits&lt;volatile T*&gt; {
6249 typedef ptrdiff_t difference_type;
6250 typedef T value_type;
6251 typedef volatile T* pointer;
6252 typedef volatile T&amp; reference;
6253 typedef random_access_iterator_tag iterator_category;
6254 };
6255 }
6256
6257             </pre>
6258         <p>
6259
6260 Note that  the change to  <code>iterator_traits</code> isn't necessary
6261 in order to implement the  specialized algorithms in a way that allows
6262 them to operate on volatile  strorage. It is only necesassary in order
6263 to specify  their effects in terms  of <code>iterator_traits</code> as
6264 is  done here.   Implementations can  (and some  do) achieve  the same
6265 effect by means of function template overloading.
6266
6267         </p>
6268
6269
6270
6271
6272 <hr>
6273 <h3><a name="585"></a>585. facet error reporting</h3>
6274 <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>
6275  <b>Submitter:</b> Martin Sebor, Paolo Carlini <b>Date:</b> 2006-06-22</p>
6276 <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>
6277 <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>
6278 <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>
6279 <p><b>Discussion:</b></p>
6280         <p>
6281
6282 Section  22.2, paragraph 2  requires facet  <code>get()</code> members
6283 that    take    an    <code>ios_base::iostate&amp;</code>    argument,
6284 <code><i>err</i></code>,  to   ignore  the  (initial)   value  of  the
6285 argument, but to set it to <code>ios_base::failbit</code> in case of a
6286 parse error.
6287
6288         </p>
6289         <p>
6290
6291 We  believe  there  are  a   few  minor  problems  with  this  blanket
6292 requirement  in   conjunction  with   the  wording  specific   to  each
6293 <code>get()</code> member function.
6294
6295         </p>
6296         <p>
6297
6298 First,  besides <code>get()</code>  there are  other  member functions
6299 with     a      slightly     different     name      (for     example,
6300 <code>get_date()</code>). It's not completely clear that the intent of
6301 the  paragraph  is  to  include  those  as  well,  and  at  least  one
6302 implementation has interpreted the requirement literally.
6303
6304         </p>
6305         <p>
6306
6307 Second,    the     requirement    to    "set     the    argument    to
6308 <code>ios_base::failbit</code>  suggests that  the  functions are  not
6309 permitted    to   set    it   to    any   other    value    (such   as
6310 <code>ios_base::eofbit</code>,   or   even  <code>ios_base::eofbit   |
6311 ios_base::failbit</code>).
6312
6313         </p>
6314         <p>
6315
6316 However, 22.2.2.1.2, p5 (Stage  3 of <code>num_get</code> parsing) and
6317 p6 (<code>bool</code> parsing)  specifies that the <code>do_get</code>
6318 functions  perform <code><i>err</i> |=  ios_base::eofbit</code>, which
6319 contradicts  the earlier  requirement to  ignore  <i>err</i>'s initial
6320 value.
6321
6322         </p>
6323         <p>
6324
6325 22.2.6.1.2,  p1  (the  Effects  clause of  the  <code>money_get</code>
6326 facet's  <code>do_get</code>  member  functions) also  specifies  that
6327 <code><i>err</i></code>'s initial  value be used to  compute the final
6328 value  by  ORing  it  with  either  <code>ios_base::failbit</code>  or
6329 with<code>ios_base::eofbit | ios_base::failbit</code>.
6330
6331         </p>
6332
6333
6334     <p><b>Proposed resolution:</b></p>
6335         <p>
6336
6337 We believe the  intent is for all facet member  functions that take an
6338 <code>ios_base::iostate&amp;</code> argument to:
6339
6340         </p>
6341             <ul>
6342                 <li>
6343
6344 ignore the initial value of the <code><i>err</i></code> argument,
6345
6346                 </li>
6347                 <li>
6348
6349 reset <code><i>err</i></code>  to <code>ios_base::goodbit</code> prior
6350 to any further processing,
6351
6352                 </li>
6353                 <li>
6354
6355 and       set      either       <code>ios_base::eofbit</code>,      or
6356 <code>ios_base::failbit</code>, or both in <code><i>err</i></code>, as
6357 appropriate,  in response  to  reaching the  end-of-file  or on  parse
6358 error, or both.
6359
6360                 </li>
6361             </ul>
6362         <p>
6363
6364 To that effect we propose to change 22.2, p2 as follows:
6365
6366         </p>
6367         <p>
6368
6369 The  <i>put</i><del>()</del>  members  make  no  provision  for  error
6370 reporting.   (Any  failures of  the  OutputIterator  argument must  be
6371 extracted   from  the   returned  iterator.)    <ins>Unless  otherwise
6372 specified, </ins>the <i>get</i><del>()</del>  members  <ins>that</ins>
6373 take an  <code>ios_base::iostate&amp;</code> argument <del>whose value
6374 they  ignore,  but  set  to  ios_base::failbit  in  case  of  a  parse
6375 error.</del><ins>,   <code><i>err</i></code>,   start  by   evaluating
6376 <code>err  =   ios_base::goodbit</code>,  and  may   subsequently  set
6377 <i>err</i>     to     either     <code>ios_base::eofbit</code>,     or
6378 <code>ios_base::failbit</code>,     or     <code>ios_base::eofbit    |
6379 ios_base::failbit</code> in response to reaching the end-of-file or in
6380 case of a parse error, or both, respectively.</ins>
6381
6382         </p>
6383
6384
6385 <p><i>[
6386 Kona (2007): We need to change the proposed wording to clarify that the
6387 phrase "the get members" actually denotes <tt>get()</tt>, <tt>get_date()</tt>, etc.
6388 Proposed Disposition: Open
6389 ]</i></p>
6390
6391
6392
6393
6394 <hr>
6395 <h3><a name="588"></a>588. requirements on zero sized tr1::arrays and other details</h3>
6396 <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>
6397  <b>Submitter:</b> Gennaro Prota <b>Date:</b> 2006-07-18</p>
6398 <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>
6399 <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>
6400 <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>
6401 <p><b>Discussion:</b></p>
6402 <p>
6403 The wording used for section 23.2.1 [lib.array] seems to be subtly
6404 ambiguous about zero sized arrays (N==0). Specifically:
6405 </p>
6406 <p>
6407 * "An instance of array&lt;T, N&gt; stores N elements of type T, so that
6408 [...]"
6409 </p>
6410 <p>
6411 Does this imply that a zero sized array object stores 0 elements, i.e.
6412 that it cannot store any element of type T? The next point clarifies
6413 the rationale behind this question, basically how to implement begin()
6414 and end():
6415 </p>
6416 <p>
6417 * 23.2.1.5 [lib.array.zero], p2: "In the case that N == 0, begin() ==
6418 end() == unique value."
6419 </p>
6420 <p>
6421 What does "unique" mean in this context? Let's consider the following
6422 possible implementations, all relying on a partial specialization:
6423 </p>
6424 <blockquote><pre>a)
6425     template&lt; typename T &gt;
6426     class array&lt; T, 0 &gt; {
6427
6428         ....
6429
6430         iterator begin()
6431         { return iterator( reinterpret_cast&lt; T * &gt;( this ) ); }
6432         ....
6433
6434     };
6435 </pre></blockquote>
6436 <p>
6437 This has been used in boost, probably intending that the return value
6438 had to be unique to the specific array object and that array couldn't
6439 store any T. Note that, besides relying on a reinterpret_cast, has
6440 (more than potential) alignment problems.
6441 </p>
6442 <blockquote><pre>b)
6443     template&lt; typename T &gt;
6444     class array&lt; T, 0 &gt; {
6445
6446         T t;
6447
6448         iterator begin()
6449         { return iterator( &amp;t ); }
6450         ....
6451
6452     };
6453 </pre></blockquote>
6454 <p>
6455 This provides a value which is unique to the object and to the type of
6456 the array, but requires storing a T. Also, it would allow the user to
6457 mistakenly provide an initializer list with one element.
6458 </p>
6459 <p>
6460 A slight variant could be returning *the* null pointer of type T
6461 </p>
6462 <blockquote><pre>    return static_cast&lt;T*&gt;(0);
6463 </pre></blockquote>
6464 <p>
6465 In this case the value would be unique to the type array&lt;T, 0&gt; but not
6466 to the objects (all objects of type array&lt;T, 0&gt; with the same value
6467 for T would yield the same pointer value).
6468 </p>
6469 <p>
6470 Furthermore this is inconsistent with what the standard requires from
6471 allocation functions (see library issue 9).
6472 </p>
6473 <p>
6474 c) same as above but with t being a static data member; again, the
6475 value would be unique to the type, not to the object.
6476 </p>
6477 <p>
6478 d) to avoid storing a T *directly* while disallowing the possibility
6479 to use a one-element initializer list a non-aggregate nested class
6480 could be defined
6481 </p>
6482 <blockquote><pre>    struct holder { holder() {} T t; } h;
6483 </pre></blockquote>
6484 <p>
6485 and then begin be defined as
6486 </p>
6487 <blockquote><pre> iterator begin() { return &amp;h.t; }
6488 </pre></blockquote>
6489 <p>
6490 But then, it's arguable whether the array stores a T or not.
6491 Indirectly it does.
6492 </p>
6493 <p>
6494 -----------------------------------------------------
6495 </p>
6496 <p>
6497 Now, on different issues:
6498 </p>
6499 <p>
6500 * what's the effect of calling assign(T&amp;) on a zero-sized array? There
6501 seems to be only mention of front() and back(), in 23.2.1 [lib.array]
6502 p4 (I would also suggest to move that bullet to section 23.2.1.5
6503 [lib.array.zero], for locality of reference)
6504 </p>
6505 <p>
6506 * (minor) the opening paragraph of 23.2.1 [lib.array] wording is a bit
6507 inconsistent with that of other sequences: that's not a problem in
6508 itself, but compare it for instance with "A vector is a kind of
6509 sequence that supports random access iterators"; though the intent is
6510 obvious one might argue that the wording used for arrays doesn't tell
6511 what an array is, and relies on the reader to infer that it is what
6512 the &lt;array&gt; header defines.
6513 </p>
6514 <p>
6515 * it would be desiderable to have a static const data member of type
6516 std::size_t, with value N, for usage as integral constant expression
6517 </p>
6518 <p>
6519 * section 23.1 [lib.container.requirements] seem not to consider
6520 fixed-size containers at all, as it says: "[containers] control
6521 allocation and deallocation of these objects [the contained objects]
6522 through constructors, destructors, *insert and erase* operations"
6523 </p>
6524 <p>
6525 * max_size() isn't specified: the result is obvious but, technically,
6526 it relies on table 80: "size() of the largest possible container"
6527 which, again, doesn't seem to consider fixed size containers
6528 </p>
6529
6530
6531 <p><b>Proposed resolution:</b></p>
6532 <p>
6533 </p>
6534
6535
6536 <p><i>[
6537 Kona (2007): requirements on zero sized <tt>tr1::array</tt>s and other details
6538 Issue 617: <tt>std::array</tt> is a sequence that doesn't satisfy the sequence
6539 requirements? Alisdair will prepare a paper. Proposed Disposition: Open
6540 ]</i></p>
6541
6542
6543
6544
6545
6546 <hr>
6547 <h3><a name="597"></a>597. Decimal: The notion of 'promotion' cannot be emulated by user-defined types.</h3>
6548 <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>
6549  <b>Submitter:</b> Daveed Vandevoorde <b>Date:</b> 2006-04-05</p>
6550 <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>
6551 <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>
6552 <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>
6553 <p><b>Discussion:</b></p>
6554 <p>
6555 In a private email, Daveed writes:
6556 </p>
6557 <blockquote>
6558 <p>
6559 I am not familiar with the C TR, but my guess is that the
6560 class type approach still won't match a built-in type
6561 approach because the notion of "promotion" cannot be
6562 emulated by user-defined types.
6563 </p>
6564 <p>
6565 Here is an example:
6566 </p>
6567 </blockquote>
6568 <pre>
6569                  struct S {
6570                    S(_Decimal32 const&amp;);  // Converting constructor
6571                  };
6572                  void f(S);
6573
6574                  void f(_Decimal64);
6575
6576                  void g(_Decimal32 d) {
6577                    f(d);
6578                  }
6579 </pre>
6580
6581 <blockquote>
6582 <p>
6583 If _Decimal32 is a built-in type, the call f(d) will likely
6584 resolve to f(_Decimal64) because that requires only a
6585 promotion, whereas f(S) requires a user-defined conversion.
6586 </p>
6587 <p>
6588 If _Decimal32 is a class type, I think the call f(d) will be
6589 ambiguous because both the conversion to _Decimal64 and the
6590 conversion to S will be user-defined conversions with neither
6591 better than the other.
6592 </p>
6593 </blockquote>
6594 <p>
6595 Robert comments:
6596 </p>
6597 <p>
6598 In general, a library of arithmetic types cannot exactly emulate the
6599 behavior of the intrinsic numeric types. There are several ways to tell
6600 whether an implementation of the decimal types uses compiler
6601 intrinisics or a library. For example:
6602 </p>
6603 <pre>                 _Decimal32 d1;
6604                  d1.operator+=(5);  // If d1 is a builtin type, this won't compile.
6605 </pre>
6606 <p>
6607 In preparing the decimal TR, we have three options:
6608 </p>
6609 <ol>
6610 <li>require that the decimal types be class types</li>
6611 <li>require that the decimal types be builtin types, like float and double</li>
6612 <li>specify a library of class types, but allow enough implementor
6613 latitude that a conforming implementation could instead provide builtin
6614 types</li>
6615 </ol>
6616 <p>
6617 We decided as a group to pursue option #3, but that approach implies
6618 that implementations may not agree on the semantics of certain use
6619 cases (first example, above), or on whether certain other cases are
6620 well-formed (second example). Another potentially important problem is
6621 that, under the present definition of POD, the decimal classes are not
6622 POD types, but builtins will be.
6623 </p>
6624 <p>Note that neither example above implies any problems with respect to
6625 C-to-C++ compatibility, since neither example can be expressed in C.
6626 </p>
6627
6628
6629 <p><b>Proposed resolution:</b></p>
6630
6631
6632
6633
6634
6635 <hr>
6636 <h3><a name="606"></a>606. Decimal: allow narrowing conversions</h3>
6637 <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>
6638  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-15</p>
6639 <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>
6640 <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>
6641 <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>
6642 <p><b>Discussion:</b></p>
6643 <p>
6644 In c++std-lib-17205, Martin writes:
6645 </p>
6646 <blockquote><p>...was it a deliberate design choice to make narrowing
6647 assignments ill-formed while permitting narrowing compound assignments?
6648 For instance:
6649 </p></blockquote>
6650 <pre>      decimal32 d32;
6651       decimal64 d64;
6652
6653       d32 = 64;     // error
6654       d32 += 64;    // okay
6655 </pre>
6656 <p>
6657 In c++std-lib-17229, Robert responds:
6658 </p>
6659 <blockquote><p>It is a vestige of an old idea that I forgot to remove
6660 from the paper. Narrowing assignments should be permitted. The bug is
6661 that the converting constructors that cause narrowing should not be
6662 explicit. Thanks for pointing this out.
6663 </p></blockquote>
6664
6665 <p><b>Proposed resolution:</b></p>
6666 <p>
6667 1.  In "3.2.2 Class <code>decimal32</code>" synopsis, remove the <code>explicit</code> specifier from the narrowing conversions:
6668 </p>
6669 <pre>                // <i>3.2.2.2 conversion from floating-point type:</i>
6670                 <del>explicit</del> decimal32(decimal64 <i>d64</i>);
6671                 <del>explicit</del> decimal32(decimal128 <i>d128</i>);
6672 </pre>
6673 <p>
6674 2.  Do the same thing in "3.2.2.2. Conversion from floating-point type."
6675 </p>
6676 <p>
6677 3.  In "3.2.3 Class <code>decimal64</code>" synopsis, remove the <code>explicit</code> specifier from the narrowing conversion:
6678 </p>
6679 <pre>                // <i>3.2.3.2 conversion from floating-point type:</i>
6680                 <del>explicit</del> decimal64(decimal128 <i>d128</i>);
6681 </pre>
6682 <p>
6683 4.  Do the same thing in "3.2.3.2. Conversion from floating-point type."
6684 </p>
6685
6686 <p><i>[
6687 Redmond: We prefer explicit conversions for narrowing and implicit for widening.
6688 ]</i></p>
6689
6690
6691
6692
6693
6694
6695 <hr>
6696 <h3><a name="614"></a>614. std::string allocator requirements still inconsistent</h3>
6697 <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>
6698  <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-05</p>
6699 <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>
6700 <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>
6701 <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>
6702 <p><b>Discussion:</b></p>
6703 <p>
6704 This is based on N2134, where 21.3.1/2 states:
6705 "... The Allocator object used shall be a copy of the Allocator object
6706 passed to the basic_string object's constructor or, if the constructor does
6707 not take an Allocator argument, a copy of a default-constructed Allocator
6708 object."
6709 </p>
6710 <p>
6711 Section 21.3.2/1 lists two constructors:
6712 </p>
6713 <blockquote><pre>basic_string(const basic_string&lt;charT,traits,Allocator&gt;&amp; str );
6714
6715 basic_string(const basic_string&lt;charT,traits,Allocator&gt;&amp; str ,
6716              size_type pos , size_type n = npos,
6717              const Allocator&amp; a = Allocator());
6718 </pre></blockquote>
6719 <p>
6720 and then says "In the first form, the Allocator value used is copied from
6721 str.get_allocator().", which isn't an option according to 21.3.1.
6722 </p>
6723 <p><i>[
6724 Batavia:  We need blanket statement to the effect of:
6725 ]</i></p>
6726
6727
6728 <ol>
6729 <li>If an allocator is passed in, use it, or,</li>
6730 <li>If a string is passed in, use its allocator.</li>
6731 </ol>
6732 <p><i>[
6733 Review constructors and functions that return a string; make sure we follow these
6734 rules (substr, operator+, etc.).  Howard to supply wording.
6735 ]</i></p>
6736
6737
6738 <p><i>[
6739 Bo adds:  The new container constructor which takes only a <tt>size_type</tt> is not
6740 consistent with 23.1 [container.requirements], p9 which says in part:
6741
6742 <blockquote>
6743 All other constructors for these container types take an
6744 <tt>Allocator&amp;</tt> argument (20.1.2), an allocator whose value type
6745 is the same as the container's value type. A copy of this argument is
6746 used for any memory allocation performed, by these constructors and by
6747 all member functions, during the lifetime of each container object.
6748 </blockquote>
6749 ]</i></p>
6750
6751
6752 <p><i>[
6753 post Bellevue: We re-confirm that the issue is real. Pablo will provide wording.
6754 ]</i></p>
6755
6756
6757
6758
6759 <p><b>Proposed resolution:</b></p>
6760 <p>
6761 </p>
6762
6763
6764
6765
6766
6767 <hr>
6768 <h3><a name="617"></a>617. std::array is a sequence that doesn't satisfy the sequence requirements?</h3>
6769 <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>
6770  <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-30</p>
6771 <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>
6772 <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>
6773 <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>
6774 <p><b>Discussion:</b></p>
6775 <p>
6776 The <tt>&lt;array&gt;</tt> header is given under 23.2 [sequences].
6777 23.2.1 [array]/paragraph 3 says:
6778 </p>
6779 <blockquote><p>
6780 "Unless otherwise specified, all array operations are as described in
6781 23.1 [container.requirements]".
6782 </p></blockquote>
6783 <p>
6784 However, array isn't mentioned at all in section 23.1 [container.requirements].
6785 In particular, Table 82 "Sequence requirements" lists several operations (insert, erase, clear)
6786 that std::array does not have in 23.2.1 [array].
6787 </p>
6788 <p>
6789 Also, Table 83 "Optional sequence operations" lists several operations that
6790 std::array does have, but array isn't mentioned.
6791 </p>
6792
6793
6794 <p><b>Proposed resolution:</b></p>
6795 <p>
6796 </p>
6797
6798
6799
6800
6801
6802 <hr>
6803 <h3><a name="629"></a>629. complex<t> insertion and locale dependence</t></h3>
6804 <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>
6805  <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2007-01-28</p>
6806 <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>
6807 <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>
6808 <p><b>Discussion:</b></p>
6809 <p>
6810 is there an issue opened for (0,3) as complex number with
6811 the French local?  With the English local, the above parses as an
6812 imaginery complex number.  With the French locale it parses as a
6813 real complex number.
6814 </p>
6815
6816 <p>
6817 Further notes/ideas from the lib-reflector, messages 17982-17984:
6818 </p>
6819
6820 <blockquote>
6821 <p>
6822 Add additional entries in num_punct to cover the complex separator (French would be ';').
6823 </p>
6824 <p>
6825 Insert a space before the comma, which should eliminate the ambiguity.
6826 </p>
6827 <p>
6828 Solve the problem for ordered sequences in general, perhaps with a
6829 dedicated facet.  Then complex should use that solution.
6830 </p>
6831 </blockquote>
6832
6833 <p><i>[
6834 Bellevue:
6835 ]</i></p>
6836
6837
6838 <blockquote>
6839 <p>
6840 After much discussion, we agreed on the following: Add a footnote:
6841 </p>
6842 <p>
6843 [In a locale in which comma is being used as a decimal point character,
6844 inserting "showbase" into the output stream forces all outputs to show
6845 an explicit decimal point character; then all inserted complex sequences
6846 will extract unambiguously.]
6847 </p>
6848 <p>
6849 And move this to READY status.
6850 </p>
6851 </blockquote>
6852
6853 <p><i>[
6854 Pre-Sophia Antipolis, Howard adds:
6855 ]</i></p>
6856
6857
6858 <blockquote>
6859 Changed "showbase" to "showpoint" and changed from Ready to Review.
6860 </blockquote>
6861
6862 <p><i>[
6863 Post-Sophia Antipolis:
6864 ]</i></p>
6865
6866
6867 <blockquote>
6868 <p>
6869 I neglected to pull this issue from the formal motions page after the "showbase" to "showpoint" change.
6870 In Sophia Antipolis this change was reviewed by the LWG and the issue was set to Ready.  We subsequently
6871 voted the footnote into the WP with "showbase".
6872 </p>
6873 <p>
6874 I'm changing from WP back to Ready to pick up the "showbase" to "showpoint" change.
6875 </p>
6876 </blockquote>
6877
6878
6879
6880 <p><b>Proposed resolution:</b></p>
6881 <p>
6882 Add a footnote to 26.3.6 [complex.ops] p16:
6883 </p>
6884
6885 <blockquote>
6886 [In a locale in which comma is being used as a decimal point character,
6887 inserting <tt>showpoint</tt> into the output stream forces all outputs to show
6888 an explicit decimal point character; then all inserted complex sequences
6889 will extract unambiguously.]
6890 </blockquote>
6891
6892
6893
6894
6895
6896 <hr>
6897 <h3><a name="630"></a>630. arrays of valarray</h3>
6898 <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>
6899  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-28</p>
6900 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#valarray.cons">active issues</a> in [valarray.cons].</p>
6901 <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>
6902 <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>
6903 <p><b>Discussion:</b></p>
6904         <p>
6905
6906 Section 26.1 [numeric.requirements], p1     suggests     that     a
6907 <code>valarray</code>  specialization on  a  type <code>T</code>  that
6908 satisfies  the requirements enumerated  in the  paragraph is  itself a
6909 valid  type   on  which  <code>valarray</code>   may  be  instantiated
6910 (Footnote       269        makes       this       clear).        I.e.,
6911 <code>valarray&lt;valarray&lt;T&gt;  &gt;</code> is  valid as  long as
6912 <code>T</code>   is   valid.    However,  since   implementations   of
6913 <code>valarray</code> are permitted to initialize storage allocated by
6914 the class by  invoking the default ctor of  <code>T</code> followed by
6915 the    copy    assignment    operator,   such    implementations    of
6916 <code>valarray</code>   wouldn't  work  with   (perhaps  user-defined)
6917 specializations of <code>valarray</code> whose assignment operator had
6918 undefined behavior when the size of its argument didn't match the size
6919 of <code>*this</code>.  By <i>"wouldn't work"</i> I mean that it would
6920 be  impossible  to resize  such  an array  of  arrays  by calling  the
6921 <code>resize()</code> member  function on it if the  function used the
6922 copy  assignment operator  after constructing  all elements  using the
6923 default  ctor (e.g.,  by invoking  <code>new  value_type[N]</code>) to
6924 obtain default-initialized storage) as it's permitted to do.
6925
6926         </p>
6927         <p>
6928
6929 Stated      more     generally,      the      problem     is      that
6930 <code>valarray&lt;valarray&lt;T&gt;  &gt;::resize(size_t)</code> isn't
6931 required or  guaranteed to have well-defined semantics  for every type
6932 <code>T</code>     that      satisfies     all     requirements     in
6933 26.1 [numeric.requirements].
6934
6935         </p>
6936         <p>
6937
6938 I  believe  this  problem  was  introduced  by  the  adoption  of  the
6939 resolution                outlined                in                <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0857.asc">N0857</a>,
6940 <i>Assignment  of  valarrays</i>,  from  1996.   The  copy  assignment
6941 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>,
6942 as      well       as      the      one       proposed      in      <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0308.asc">N0308</a>
6943 (both  from 1993), had  well-defined semantics  for arrays  of unequal
6944 size (the  latter explicitly  only when <code>*this</code>  was empty;
6945 assignment of non empty arrays of unequal size was a runtime error).
6946
6947         </p>
6948         <p>
6949
6950 The  justification for  the  change given  in  N0857 was the "loss  of
6951 performance [deemed]  only significant  for very simple  operations on
6952 small arrays or for architectures with very few registers."
6953
6954         </p>
6955         <p>
6956
6957 Since tiny  arrays on a  limited subset of hardware  architectures are
6958 likely  to  be  an   exceedingly  rare  case  (despite  the  continued
6959 popularity of  x86) I  propose to revert  the resolution and  make the
6960 behavior    of   all   <code>valarray</code>    assignment   operators
6961 well-defined even  for non-conformal  arrays (i.e., arrays  of unequal
6962 size).   I have implemented  this change  and measured  no significant
6963 degradation  in performance in  the common  case (non-empty  arrays of
6964 equal size).  I  have measured a 50% (and in  some cases even greater)
6965 speedup  in the  case of  assignments to  empty arrays  versus calling
6966 <code>resize()</code>  first followed  by  an invocation  of the  copy
6967 assignment operator.
6968
6969         </p>
6970
6971 <p><i>[
6972 Bellevue:
6973 ]</i></p>
6974
6975
6976 <blockquote>
6977 If no proposed wording by June meeting, this issue should be closed NAD.
6978 </blockquote>
6979
6980
6981
6982 <p><b>Proposed resolution:</b></p>
6983         <p>
6984
6985 Change 26.5.2.2 [valarray.assign], p1 as follows:
6986
6987         </p>
6988         <blockquote>
6989             <p>
6990                 <code>
6991
6992 valarray&lt;T&gt;&amp; operator=(const valarray&lt;T&gt;&amp;<ins> x</ins>);
6993
6994                 </code>
6995             </p>
6996             <p>
6997
6998 -1- Each element of the <code>*this</code> array is assigned the value
6999 of  the  corresponding  element   of  the  argument  array.   <del>The
7000 resulting behavior is undefined if </del><ins>When </ins>the length of
7001 the  argument  array  is  not   equal  to  the  length  of  the  *this
7002 array<del>.</del><ins>  resizes  <code>*this</code>  to make  the  two
7003 arrays     the      same     length,     as      if     by     calling
7004 <code>resize(x.size())</code>, before performing the assignment.</ins>
7005
7006             </p>
7007         </blockquote>
7008         <p>
7009
7010 And  add a new  paragraph just  below paragraph  1 with  the following
7011 text:
7012
7013         </p>
7014         <blockquote>
7015             <p>
7016
7017 <ins>-2- <i>Postcondition</i>: <code>size() == x.size()</code>.</ins>
7018
7019             </p>
7020         </blockquote>
7021         <p>
7022
7023 Also add the following paragraph to 26.5.2.2 [valarray.assign], immediately after p4:
7024
7025         </p>
7026         <blockquote>
7027             <p>
7028
7029 <ins>-?- When the length,  <i><code>N</code></i> of the array referred
7030 to by the  argument is not equal to  the length of <code>*this</code>,
7031 the  operator resizes <code>*this</code>  to make  the two  arrays the
7032 same  length, as if  by calling  <code>resize(<i>N</i>)</code>, before
7033 performing the assignment.</ins>
7034
7035             </p>
7036         </blockquote>
7037
7038 <p><i>[
7039 pre-Sophia Antipolis, Martin adds the following compromise wording, but
7040 prefers the original proposed resolution:
7041 ]</i></p>
7042
7043
7044 <p>
7045 Change 26.5.2.2 [valarray.assign], p1 as follows:
7046 </p>
7047
7048 <blockquote>
7049 <p>
7050  -1- <i>Requires:</i> <tt>size() == 0 || size() == x.size()</tt>.
7051 </p>
7052 <p>
7053  -2- <i>Effects:</i> If <tt>size() == 0</tt> calls <tt>x.resize(x.size())</tt> first.
7054      Each element of the <tt>*this</tt> array is assigned the value of the
7055      corresponding element of the argument array.
7056 </p>
7057 <p>
7058  -3- <i>Postcondition:</i> <tt>size() == x.size()</tt>.
7059 </p>
7060 </blockquote>
7061
7062 <p>
7063 Add the following paragraph to 26.5.2.2 [valarray.assign], immediately after
7064 p4:
7065 </p>
7066
7067 <blockquote>
7068 <p>
7069  -?- When <tt>size() == 0</tt> and the length, <tt>N</tt> of the array referred to by
7070      the argument is not equal to the length of <tt>*this</tt>, the operator
7071      resizes <tt>*this</tt> to make the two arrays the same length, as if by
7072      calling <tt>resize(N)</tt>, before performing the assignment. Otherwise,
7073      when <tt>size() &gt; 0</tt> and <tt>size() != N</tt>, the behavior is undefined.
7074 </p>
7075 </blockquote>
7076
7077
7078
7079 <p><i>[
7080 Kona (2007): Gaby to propose wording for an alternative resolution in
7081 which you can assign to a <tt>valarray</tt> of size 0, but not to any other
7082 <tt>valarray</tt> whose size is unequal to the right hand side of the assignment.
7083 ]</i></p>
7084
7085
7086
7087
7088
7089 <hr>
7090 <h3><a name="631"></a>631. conflicting requirements for <tt>BinaryPredicate</tt></h3>
7091 <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>
7092  <b>Submitter:</b> James Kanze <b>Date:</b> 2007-01-31</p>
7093 <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>
7094 <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>
7095 <p><b>Discussion:</b></p>
7096 <p>
7097 The general requirements for <tt><tt>BinaryPredicate</tt></tt> (in 25 [algorithms]/8) contradict the implied specific requirements for
7098 some functions. In particular, it says that:
7099 </p>
7100
7101 <blockquote><p>
7102 [...] if an algorithm takes <tt>BinaryPredicate <i>binary_pred</i></tt>
7103 as its argument and <tt><i>first1</i></tt> and <i>first2</i> as its
7104 iterator arguments, it should work correctly in the construct <tt>if
7105 (binary_pred (*<i>first1</i> , *<i>first2</i> )){...}</tt>.
7106 <tt>BinaryPredicate</tt> always takes the first iterator type as its
7107 first argument, that is, in those cases when <tt>T <i>value</i></tt> is
7108 part of the signature, it should work correctly in the context of <tt>if
7109 (binary_pred (*<i>first1</i> , <i>value</i>)){...}</tt>.
7110 </p></blockquote>
7111
7112 <p>
7113 In the description of <tt>upper_bound</tt> (25.3.3.2 [upper.bound]/2), however, the use is described as
7114 "<tt>!comp(<i>value</i>, <i>e</i>)</tt>", where <tt><i>e</i></tt> is an
7115 element of the sequence (a result of dereferencing
7116 <tt>*<i>first</i></tt>).
7117 </p>
7118
7119 <p>
7120 In the description of <tt>lexicographical_compare</tt>, we have both
7121 "<tt>*<i>first1</i> &lt; *<i>first2</i></tt>" and "<tt>*<i>first2</i>
7122 &lt; *<i>first1</i></tt>" (which presumably implies "<tt>comp(
7123 *<i>first1</i>, *<i>first2</i> )</tt>" and "<tt>comp( *<i>first2</i>,
7124 *<i>first1</i> )</tt>".
7125 </p>
7126
7127 <p><i>[
7128 Toronto:  Moved to Open.  ConceptGCC seems to get <tt>lower_bound</tt>
7129 and <tt>upper_bound</tt> to work withoutt these changes.
7130 ]</i></p>
7131
7132
7133
7134
7135 <p><b>Proposed resolution:</b></p>
7136 <p>
7137 Logically, the <tt>BinaryPredicate</tt> is used as an ordering
7138 relationship, with the semantics of "less than".  Depending on the
7139 function, it may be used to determine equality, or any of the inequality
7140 relationships; doing this requires being able to use it with either
7141 parameter first.  I would thus suggest that the requirement be:
7142 </p>
7143
7144 <blockquote><p>
7145 [...] <tt>BinaryPredicate</tt> always takes the first iterator
7146 <tt>value_type</tt> as one of its arguments, it is unspecified which. If
7147 an algorithm takes <tt>BinaryPredicate <i>binary_pred</i></tt> as its
7148 argument and <tt><i><i>first1</i></i></tt> and <i>first2</i> as its
7149 iterator arguments, it should work correctly both in the construct
7150 <tt>if (binary_pred (*<i>first1</i> , *<i>first2</i> )){...}</tt> and
7151 <tt>if (binary_pred (*<i>first2</i>, *<i>first1</i>)){...}</tt>.  In
7152 those cases when <tt>T <i>value</i></tt> is part of the signature, it
7153 should work correctly in the context of <tt>if (binary_pred
7154 (*<i>first1</i> , <i>value</i>)){...}</tt> and of <tt>if (binary_pred
7155 (<i>value</i>, *<i>first1</i>)){...}</tt>. [<i>Note:</i> if the two
7156 types are not identical, and neither is convertable to the other, this
7157 may require that the <tt>BinaryPredicate</tt> be a functional object
7158 with two overloaded <tt>operator()()</tt> functions. <i>--end note</i>]
7159 </p></blockquote>
7160
7161 <p>
7162 Alternatively, one could specify an order for each function. IMHO, this
7163 would be more work for the committee, more work for the implementors,
7164 and of no real advantage for the user: some functions, such as
7165 <tt>lexicographical_compare</tt> or <tt>equal_range</tt>, will still require both
7166 functions, and it seems like a much easier rule to teach that both
7167 functions are always required, rather than to have a complicated list of
7168 when you only need one, and which one.
7169 </p>
7170
7171
7172
7173
7174
7175 <hr>
7176 <h3><a name="632"></a>632. Time complexity of size() for std::set</h3>
7177 <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>
7178  <b>Submitter:</b> Lionel B <b>Date:</b> 2007-02-01</p>
7179 <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>
7180 <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>
7181 <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>
7182 <p><b>Discussion:</b></p>
7183 <p>
7184 A recent news group discussion:
7185 </p>
7186 <blockquote>
7187 <p>
7188 Anyone know if the Standard has anything to say about the time complexity
7189 of size() for std::set?   I need to access a set's size (/not/ to know if it is empty!) heavily
7190 during an algorithm and was thus wondering whether I'd be better off
7191 tracking the size "manually" or whether that'd be pointless.
7192 </p>
7193 <p>
7194 That would be pointless. size() is O(1).
7195 </p>
7196 <p>
7197 Nit: the standard says "should" have constant time. Implementations may take
7198 license to do worse. I know that some do this for <tt>std::list&lt;&gt;</tt> as a part of
7199 some trade-off with other operation.
7200 </p>
7201
7202 <p>
7203 I was aware of that, hence my reluctance to use size() for std::set.
7204 </p>
7205 <p>
7206 However, this reason would not apply to <tt>std::set&lt;&gt;</tt> as far as I can see.
7207 </p>
7208 <p>
7209 Ok, I guess the only option is to try it and see...
7210 </p>
7211 </blockquote>
7212
7213 <p>
7214 If I have any recommendation to the C++ Standards Committee it is that
7215 implementations must (not "should"!) document clearly[1], where known, the
7216 time complexity of *all* container access operations.
7217 </p>
7218 <p>
7219 [1] In my case (gcc 4.1.1) I can't swear that the time complexity of size()
7220 for std::set is not documented... but if it is it's certainly well hidden
7221 away.
7222 </p>
7223
7224
7225
7226 <p><b>Proposed resolution:</b></p>
7227 <p>
7228 </p>
7229
7230
7231 <p><i>[
7232 Kona (2007): This issue affects all the containers. We'd love to see a
7233 paper dealing with the broad issue. We think that the complexity of the
7234 <tt>size()</tt> member of every container -- except possibly <tt>list</tt> -- should be
7235 O(1). Alan has volunteered to provide wording.
7236 ]</i></p>
7237
7238
7239 <p><i>[
7240 Bellevue:
7241 ]</i></p>
7242
7243
7244 <blockquote>
7245 Mandating O(1) size will not fly, too many implementations would be
7246 invalidated. Alan to provide wording that toughens wording, but that
7247 does not absolutely mandate O(1).
7248 </blockquote>
7249
7250
7251
7252
7253 <hr>
7254 <h3><a name="635"></a>635. domain of <tt>allocator::address</tt></h3>
7255 <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>
7256  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-02-08</p>
7257 <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>
7258 <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>
7259 <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>
7260 <p><b>Discussion:</b></p>
7261 <p>
7262 The table of allocator requirements in 20.1.2 [allocator.requirements] describes
7263 <tt>allocator::address</tt> as:
7264 </p>
7265 <blockquote><pre>a.address(r)
7266 a.address(s)
7267 </pre></blockquote>
7268 <p>
7269 where <tt>r</tt> and <tt>s</tt> are described as:
7270 </p>
7271 <blockquote><p>
7272 a value of type <tt>X::reference</tt> obtained by the expression <tt>*p</tt>.
7273 </p></blockquote>
7274
7275 <p>
7276 and <tt>p</tt> is
7277 </p>
7278
7279 <blockquote><p>
7280 a value of type <tt>X::pointer</tt>, obtained by calling <tt>a1.allocate</tt>,
7281 where <tt>a1 == a</tt>
7282 </p></blockquote>
7283
7284 <p>
7285 This all implies that to get the address of some value of type <tt>T</tt> that
7286 value must have been allocated by this allocator or a copy of it.
7287 </p>
7288
7289 <p>
7290 However sometimes container code needs to compare the address of an external value of
7291 type <tt>T</tt> with an internal value.  For example <tt>list::remove(const T&amp; t)</tt>
7292 may want to compare the address of the external value <tt>t</tt> with that of a value
7293 stored within the list.  Similarly <tt>vector</tt> or <tt>deque insert</tt> may
7294 want to make similar comparisons (to check for self-referencing calls).
7295 </p>
7296
7297 <p>
7298 Mandating that <tt>allocator::address</tt> can only be called for values which the
7299 allocator allocated seems overly restrictive.
7300 </p>
7301
7302
7303
7304 <p><b>Proposed resolution:</b></p>
7305 <p>
7306 Change 20.1.2 [allocator.requirements]:
7307 </p>
7308
7309 <blockquote>
7310 <p>
7311 <tt>r</tt> : a value of type <tt>X::reference</tt> <del>obtained by the expression *p</del>.
7312 </p>
7313 <p>
7314 <tt>s</tt> : a value of type <tt>X::const_reference</tt> <del>obtained by the
7315 expression <tt>*q</tt> or by conversion from a value <tt>r</tt></del>.
7316 </p>
7317 </blockquote>
7318
7319 <p><i>[
7320 post Oxford:  This would be rendered NAD Editorial by acceptance of
7321 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
7322 ]</i></p>
7323
7324
7325 <p><i>[
7326 Kona (2007):  This issue is section 8 of N2387.  There was some discussion of it but
7327 no resolution to this issue was recorded.  Moved to Open.
7328 ]</i></p>
7329
7330
7331
7332
7333
7334
7335
7336 <hr>
7337 <h3><a name="644"></a>644. Possible typos in 'function' description</h3>
7338 <p><b>Section:</b> X [func.wrap.func.undef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
7339  <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-02-25</p>
7340 <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>
7341 <p><b>Discussion:</b></p>
7342 <p>
7343 X [func.wrap.func.undef]
7344 </p>
7345 <p>
7346 The note in paragraph 2 refers to 'undefined void operators', while the
7347 section declares a pair of operators returning bool.
7348 </p>
7349
7350 <p><i>[
7351 Post-Sophia Antipolis:
7352 ]</i></p>
7353
7354
7355 <blockquote>
7356 Changed from Pending WP to Open.  This issue was voted to WP at the same time the operators were
7357 changed from private to deleted.  The two issues stepped on each other.  What do we want the return
7358 type of these deleted functions to be?
7359 </blockquote>
7360
7361
7362
7363 <p><b>Proposed resolution:</b></p>
7364 <p>
7365 Change 20.6.15.2 [func.wrap.func]
7366 </p>
7367
7368 <blockquote><pre>...
7369 private:
7370    // X [func.wrap.func.undef], undefined operators:
7371    template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator==(const function&lt;Function2&gt;&amp;);
7372    template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator!=(const function&lt;Function2&gt;&amp;);
7373 };
7374 </pre></blockquote>
7375
7376 <p>
7377 Change X [func.wrap.func.undef]
7378 </p>
7379
7380 <blockquote><pre>template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator==(const function&lt;Function2&gt;&amp;);
7381 template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator!=(const function&lt;Function2&gt;&amp;);
7382 </pre></blockquote>
7383
7384
7385
7386
7387
7388 <hr>
7389 <h3><a name="659"></a>659. istreambuf_iterator should have an operator-&gt;()</h3>
7390 <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>
7391  <b>Submitter:</b> Niels Dekker <b>Date:</b> 2007-03-25</p>
7392 <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>
7393 <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>
7394 <p><b>Discussion:</b></p>
7395 <p>
7396 Greg Herlihy has clearly demonstrated that a user defined input
7397 iterator should have an operator-&gt;(), even if its
7398 value type is a built-in type (comp.std.c++, "Re: Should any iterator
7399 have an operator-&gt;() in C++0x?", March 2007).  And as Howard
7400 Hinnant remarked in the same thread that the input iterator
7401 <tt>istreambuf_iterator</tt> doesn't have one, this must be a
7402 defect!
7403 </p>
7404 <p>
7405 Based on Greg's example, the following code demonstrates the issue:
7406 </p><pre> #include &lt;iostream&gt;
7407  #include &lt;fstream&gt;
7408  #include &lt;streambuf&gt;
7409
7410  typedef char C;
7411  int main ()
7412  {
7413    std::ifstream s("filename", std::ios::in);
7414    std::istreambuf_iterator&lt;char&gt; i(s);
7415
7416    (*i).~C();  // This is well-formed...
7417    i-&gt;~C();  // ... so this should be supported!
7418  }
7419 </pre>
7420
7421 <p>
7422 Of course, operator-&gt; is also needed when the value_type of
7423 istreambuf_iterator is a class.
7424 </p>
7425 <p>
7426 The operator-&gt; could be implemented in various ways.  For instance,
7427 by storing the current value inside the iterator, and returning its
7428 address.  Or by returning a proxy, like operator_arrow_proxy, from
7429 <a href="http://www.boost.org/boost/iterator/iterator_facade.hpp">http://www.boost.org/boost/iterator/iterator_facade.hpp</a>
7430 </p>
7431 <p>
7432 I hope that the resolution of this issue will contribute to getting a
7433 clear and consistent definition of iterator concepts.
7434 </p>
7435
7436
7437 <p><b>Proposed resolution:</b></p>
7438 <p>
7439 Add to the synopsis in 24.5.3 [istreambuf.iterator]:
7440 </p>
7441
7442 <blockquote><pre>charT operator*() const;
7443 <ins>pointer operator-&gt;() const;</ins>
7444 istreambuf_iterator&lt;charT,traits&gt;&amp; operator++();
7445 </pre></blockquote>
7446
7447 <p>
7448 Change 24.5.3 [istreambuf.iterator], p1:
7449 </p>
7450
7451 <blockquote><p>
7452 The class template <tt>istreambuf_iterator</tt> reads successive
7453 characters from the <tt>streambuf</tt> for which it was constructed.
7454 <tt>operator*</tt> provides access to the current input character, if
7455 any. <ins><tt>operator-&gt;</tt> may return a proxy.</ins> Each time
7456 <tt>operator++</tt> is evaluated, the iterator advances to the next
7457 input character. If the end of stream is reached
7458 (<tt>streambuf_type::sgetc()</tt> returns <tt>traits::eof()</tt>), the
7459 iterator becomes equal to the end of stream iterator value. The default
7460 constructor <tt>istreambuf_iterator()</tt> and the constructor
7461 <tt>istreambuf_iterator(0)</tt> both construct an end of stream iterator
7462 object suitable for use as an end-of-range.
7463 </p></blockquote>
7464
7465
7466
7467 <p><i>[
7468 Kona (2007): The proposed resolution is inconsistent because the return
7469 type of <tt>istreambuf_iterator::operator-&gt;()</tt> is specified to be <tt>pointer</tt>,
7470 but the proposed text also states that "<tt>operator-&gt;</tt> may return a proxy."
7471 ]</i></p>
7472
7473
7474 <p><i>[
7475 Niels Dekker (mailed to Howard Hinnant):
7476 ]</i></p>
7477
7478 <blockquote>
7479 <p>
7480 The proposed resolution does
7481 not seem inconsistent to me. <tt>istreambuf_iterator::operator-&gt;()</tt> should
7482 have <tt>istreambuf_iterator::pointer</tt> as return type, and this return type
7483 may in fact be a proxy.
7484 </p>
7485 <p>
7486 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>
7487 unspecified for some iterator categories") implies that for any iterator
7488 class <tt>Iter</tt>, the return type of <tt>operator-&gt;()</tt> is <tt>Iter::pointer</tt>, by
7489 definition.  I don't think <tt>Iter::pointer</tt> needs to be a raw pointer.
7490 </p>
7491 <p>
7492 Still I wouldn't mind if the text "<tt>operator-&gt;</tt> may return a proxy" would
7493 be removed from the resolution. I think it's up to the library
7494 implementation, how to implement <tt>istreambuf_iterator::operator-&gt;()</tt>.  As
7495 longs as it behaves as expected: <tt>i-&gt;m</tt> should have the same effect as
7496 <tt>(*i).m</tt>. Even for an explicit destructor call, <tt>i-&gt;~C()</tt>.  The main issue
7497 is just: <tt>istreambuf_iterator</tt> should have an <tt>operator-&gt;()</tt>!
7498 </p>
7499 </blockquote>
7500
7501
7502
7503
7504 <hr>
7505 <h3><a name="667"></a>667. <tt>money_get</tt>'s widened minus sign</h3>
7506 <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>
7507  <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
7508 <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>
7509 <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>
7510 <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>
7511 <p><b>Discussion:</b></p>
7512 <p>
7513 22.2.6.1.2 [locale.money.get.virtuals], para 1 says:
7514 </p>
7515
7516 <blockquote><p>
7517 The result is returned as an integral value
7518 stored in <tt>units</tt> or as a sequence of digits possibly preceded by a
7519 minus sign (as produced by <tt>ct.widen(c)</tt> where <tt>c</tt> is '-' or in the range
7520 from '0' through '9', inclusive) stored in <tt>digits</tt>.
7521 </p></blockquote>
7522
7523 <p>
7524 The following
7525 objection has been raised:
7526 </p>
7527
7528 <blockquote><p>
7529 Some implementations interpret this to mean that a facet derived from
7530 <tt>ctype&lt;wchar_t&gt;</tt> can provide its own member <tt>do_widen(char)</tt>
7531 which produces e.g. <tt>L'@'</tt> for the "widened" minus sign, and that the
7532 <tt>'@'</tt> symbol will appear in the resulting sequence of digits.  Other
7533 implementations have assumed that one or more places in the standard permit the
7534 implementation to "hard-wire" <tt>L'-'</tt> as the "widened" minus sign.  Are
7535 both interpretations permissible, or only  one?
7536 </p></blockquote>
7537
7538 <p>
7539 [Plum ref _222612Y14]
7540 </p>
7541
7542 <p>
7543 Furthermore: if <tt>ct.widen('9')</tt> produces <tt>L'X'</tt> (a non-digit), does a
7544 parse fail if a <tt>'9'</tt> appears in the subject string? [Plum ref _22263Y33]
7545 </p>
7546
7547 <p><i>[
7548 Kona (2007): Bill and Dietmar to provide proposed wording.
7549 ]</i></p>
7550
7551
7552 <p><i>[
7553 post Bellevue: Bill adds:
7554 ]</i></p>
7555
7556
7557 <blockquote>
7558 The Standard is clear that the minus sign stored in <tt>digits</tt> is <tt>ct.widen('-')</tt>.
7559 The subject string must contain characters <tt>c</tt> in the set <tt>[-0123456789]</tt>
7560 which are translated by <tt>ct.widen(c)</tt> calls before being stored in <tt>digits</tt>;
7561 the widened characters are not relevant to the parsing of the subject string.
7562 </blockquote>
7563
7564
7565 <p><b>Proposed resolution:</b></p>
7566 <p>
7567 </p>
7568
7569
7570
7571
7572
7573 <hr>
7574 <h3><a name="668"></a>668. <tt>money_get</tt>'s empty minus sign</h3>
7575 <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>
7576  <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
7577 <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>
7578 <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>
7579 <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>
7580 <p><b>Discussion:</b></p>
7581 <p>
7582 22.2.6.1.2 [locale.money.get.virtuals], para 3 says:
7583 </p>
7584
7585 <blockquote><p>
7586 If <tt>pos</tt> or <tt>neg</tt> is empty, the sign component is
7587 optional, and if no sign is detected, the result is given the sign
7588 that corresponds to the source of the empty string.
7589 </p></blockquote>
7590
7591 <p>
7592 The following
7593 objection has been raised:
7594 </p>
7595
7596 <blockquote><p>
7597 A <tt>negative_sign</tt> of "" means "there is no
7598 way to write a negative sign" not "any null sequence is a negative
7599 sign, so it's always there when you look for it".
7600 </p></blockquote>
7601
7602 <p>
7603 [Plum ref _222612Y32]
7604 </p>
7605
7606 <p><i>[
7607 Kona (2007): Bill to provide proposed wording and interpretation of existing wording.
7608 ]</i></p>
7609
7610
7611
7612
7613 <p><b>Proposed resolution:</b></p>
7614 <p>
7615 </p>
7616
7617
7618
7619
7620
7621 <hr>
7622 <h3><a name="669"></a>669. Equivalent postive and negative signs in <tt>money_get</tt></h3>
7623 <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>
7624  <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
7625 <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>
7626 <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>
7627 <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>
7628 <p><b>Discussion:</b></p>
7629 <p>
7630 22.2.6.1.2 [locale.money.get.virtuals], para 3 sentence 4 says:
7631 </p>
7632
7633 <blockquote><p>
7634 If the first character of <tt>pos</tt> is equal to the first character of <tt>neg</tt>,
7635 or if both strings are empty, the result is given a positive sign.
7636 </p></blockquote>
7637
7638 <p>
7639 One interpretation is that an input sequence must match either the
7640 positive pattern or the negative pattern, and then in either event it
7641 is interpreted as positive.  The following objections has been raised:
7642 </p>
7643
7644 <blockquote><p>
7645 The input can successfully match only a positive sign, so the negative
7646 pattern is an unsuccessful match.
7647 </p></blockquote>
7648
7649 <p>
7650 [Plum ref _222612Y34, 222612Y51b]
7651 </p>
7652
7653 <p><i>[
7654 Bill to provide proposed wording and interpretation of existing wording.
7655 ]</i></p>
7656
7657
7658
7659
7660 <p><b>Proposed resolution:</b></p>
7661 <p>
7662 </p>
7663
7664
7665
7666
7667
7668 <hr>
7669 <h3><a name="670"></a>670. <tt>money_base::pattern</tt> and <tt>space</tt></h3>
7670 <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>
7671  <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
7672 <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>
7673 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a></p>
7674 <p><b>Discussion:</b></p>
7675
7676
7677 <p>
7678 22.2.6.3 [locale.moneypunct], para 2 says:
7679 </p>
7680
7681 <blockquote><p>
7682 The value <tt>space</tt> indicates that at least one space is required at
7683 that position.
7684 </p></blockquote>
7685
7686 <p>
7687 The following objection has been raised:
7688 </p>
7689
7690 <blockquote><p>
7691 Whitespace is optional when matching space. (See 22.2.6.1.2 [locale.money.get.virtuals], para 2.)
7692 </p></blockquote>
7693
7694 <p>
7695 [Plum ref _22263Y22]
7696 </p>
7697
7698 <p><i>[
7699 Kona (2007): Bill to provide proposed wording. We agree that C++03 is
7700 ambiguous, and that we want C++0X to say "space" means 0 or more
7701 whitespace characters on input.
7702 ]</i></p>
7703
7704
7705
7706
7707 <p><b>Proposed resolution:</b></p>
7708 <p>
7709 </p>
7710
7711
7712
7713
7714
7715 <hr>
7716 <h3><a name="671"></a>671. precision of hexfloat</h3>
7717 <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>
7718  <b>Submitter:</b> John Salmon <b>Date:</b> 2007-04-20</p>
7719 <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>
7720 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
7721 <p><b>Discussion:</b></p>
7722 <p>
7723 I am trying to understand how TR1 supports hex float (%a) output.
7724 </p>
7725 <p>
7726 As far as I can tell, it does so via the following:
7727 </p>
7728 <p>
7729 8.15 Additions to header &lt;locale&gt; [tr.c99.locale]
7730 </p>
7731 <p>
7732 In subclause 22.2.2.2.2 [facet.num.put.virtuals], Table 58 Floating-point conversions, after
7733 the line:
7734 floatfield == ios_base::scientific %E
7735 </p>
7736 <p>
7737 add the two lines:
7738 </p>
7739 <blockquote><pre>floatfield == ios_base::fixed | ios_base::scientific &amp;&amp; !uppercase %a
7740 floatfield == ios_base::fixed | ios_base::scientific %A 2
7741 </pre></blockquote>
7742 <p>
7743 [Note: The additional requirements on print and scan functions, later
7744 in this clause, ensure that the print functions generate hexadecimal
7745 floating-point fields with a %a or %A conversion specifier, and that
7746 the scan functions match hexadecimal floating-point fields with a %g
7747 conversion specifier. &nbsp;end note]
7748 </p>
7749 <p>
7750 Following the thread, in 22.2.2.2.2 [facet.num.put.virtuals], we find:
7751 </p>
7752 <p>
7753 For conversion from a floating-point type, if (flags &amp; fixed) != 0 or
7754 if str.precision() &gt; 0, then str.precision() is specified in the
7755 conversion specification.
7756 </p>
7757 <p>
7758 This would seem to imply that when floatfield == fixed|scientific, the
7759 precision of the conversion specifier is to be taken from
7760 str.precision(). &nbsp;Is this really what's intended? &nbsp;I sincerely hope
7761 that I'm either missing something or this is an oversight. &nbsp;Please
7762 tell me that the committee did not intend to mandate that hex floats
7763 (and doubles) should by default be printed as if by %.6a.
7764 </p>
7765
7766 <p><i>[
7767 Howard: I think the fundamental issue we overlooked was that with %f,
7768 %e, %g, the default precision was always 6. &nbsp;With %a the default
7769 precision is not 6, it is infinity. &nbsp;So for the first time, we need to
7770 distinguish between the default value of precision, and the precision
7771 value 6.
7772 ]</i></p>
7773
7774
7775
7776
7777 <p><b>Proposed resolution:</b></p>
7778 <p>
7779 </p>
7780
7781
7782 <p><i>[
7783 Kona (2007): Robert volunteers to propose wording.
7784 ]</i></p>
7785
7786
7787
7788
7789
7790 <hr>
7791 <h3><a name="675"></a>675. Move assignment of containers</h3>
7792 <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#Review">Review</a>
7793  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-05</p>
7794 <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>
7795 <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>
7796 <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>
7797 <p><b>Discussion:</b></p>
7798 <p>
7799 James Hopkin pointed out to me that if <tt>vector&lt;T&gt;</tt> move assignment is O(1)
7800 (just a <tt>swap</tt>) then containers such as <tt>vector&lt;shared_ptr&lt;ostream&gt;&gt;</tt> might have
7801 the wrong semantics under move assignment when the source is not truly an rvalue, but a
7802 moved-from lvalue (destructors could run late).
7803 </p>
7804
7805 <blockquote><pre><tt>vector&lt;shared_ptr&lt;ostream&gt;&gt;</tt> v1;
7806 <tt>vector&lt;shared_ptr&lt;ostream&gt;&gt;</tt> v2;
7807 ...
7808 v1 = v2;               // #1
7809 v1 = std::move(v2);    // #2
7810 </pre></blockquote>
7811
7812 <p>
7813 Move semantics means not caring what happens to the source (<tt>v2</tt> in this example).
7814 It doesn't mean not caring what happens to the target (<tt>v1</tt>).  In the above example
7815 both assignments should have the same effect on <tt>v1</tt>.  Any non-shared <tt>ostream</tt>'s
7816 <tt>v1</tt> owns before the assignment should be closed, whether <tt>v1</tt> is undergoing
7817 copy assignment or move assignment.
7818 </p>
7819
7820 <p>
7821 This implies that the semantics of move assignment of a generic container should be
7822 <tt>clear, swap</tt> instead of just swap.  An alternative which could achieve the same
7823 effect would be to move assign each element.  In either case, the complexity of move
7824 assignment needs to be relaxed to <tt>O(v1.size())</tt>.
7825 </p>
7826
7827 <p>
7828 The performance hit of this change is not nearly as drastic as it sounds.
7829 In practice, the target of a move assignment has always just been move constructed
7830 or move assigned <i>from</i>.  Therefore under <tt>clear, swap</tt> semantics (in
7831 this common use case) we are still achieving O(1) complexity.
7832 </p>
7833
7834
7835
7836 <p><b>Proposed resolution:</b></p>
7837 <p>
7838 Change 23.1 [container.requirements]:
7839 </p>
7840
7841 <blockquote>
7842 <table border="1">
7843 <caption>Table 89: Container requirements</caption>
7844 <tbody><tr>
7845 <th>expression</th><th>return type</th><th>operational semantics</th>
7846 <th>assertion/note pre/post-condition</th><th>complexity</th>
7847 </tr>
7848 <tr>
7849 <td><tt>a = rv;</tt></td><td><tt>X&amp;</tt></td>
7850 <td>All existing elements of <tt>a</tt> are either move assigned or destructed</td>
7851 <td><tt>a</tt> shall be equal to the
7852 value that <tt>rv</tt> had
7853 before this construction
7854 </td>
7855 <td><del>(Note C)</del> <ins>linear</ins></td>
7856 </tr>
7857 </tbody></table>
7858
7859 <p>
7860 Notes: the algorithms <tt>swap()</tt>, <tt>equal()</tt> and
7861 <tt>lexicographical_compare()</tt> are defined in clause 25. Those
7862 entries marked "(Note A)" should have constant complexity. Those entries
7863 marked "(Note B)" have constant complexity unless
7864 <tt>allocator_propagate_never&lt;X::allocator_type&gt;::value</tt> is
7865 <tt>true</tt>, in which case they have linear complexity.
7866 <del>Those entries
7867 marked "(Note C)" have constant complexity if <tt>a.get_allocator() ==
7868 rv.get_allocator()</tt> or if either
7869 <tt>allocator_propagate_on_move_assignment&lt;X::allocator_type&gt;::value</tt>
7870 is <tt>true</tt> or
7871 <tt>allocator_propagate_on_copy_assignment&lt;X::allocator_type&gt;::value</tt>
7872 is <tt>true</tt> and linear complexity otherwise.</del>
7873 </p>
7874 </blockquote>
7875
7876
7877
7878 <p><i>[
7879 post Bellevue Howard adds:
7880 ]</i></p>
7881
7882
7883 <blockquote>
7884 <p>
7885 This issue was voted to WP in Bellevue, but accidently got stepped on by
7886 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>
7887 which was voted to WP simulataneously.  Moving back to Open for the purpose of getting
7888 the wording right.  The intent of this issue and N2525 are not in conflict.
7889 </p>
7890 </blockquote>
7891
7892 <p><i>[
7893 post Sophia Antipolis Howard updated proposed wording:
7894 ]</i></p>
7895
7896
7897
7898
7899
7900 <hr>
7901 <h3><a name="676"></a>676. Moving the unordered containers</h3>
7902 <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>
7903  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-05</p>
7904 <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>
7905 <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>
7906 <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>
7907 <p><b>Discussion:</b></p>
7908 <p>
7909 Move semantics are missing from the <tt>unordered</tt> containers.  The proposed
7910 resolution below adds move-support consistent with
7911 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1858.html">N1858</a>
7912 and the current working draft.
7913 </p>
7914
7915 <p>
7916 The current proposed resolution simply lists the requirements for each function.
7917 These might better be hoisted into the requirements table for unordered associative containers.
7918 Futhermore a mild reorganization of the container requirements could well be in order.
7919 This defect report is purposefully ignoring these larger issues and just focusing
7920 on getting the unordered containers "moved".
7921 </p>
7922
7923
7924
7925 <p><b>Proposed resolution:</b></p>
7926
7927 <p>
7928 Add to 23.4 [unord]:
7929 </p>
7930
7931 <blockquote><pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
7932   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
7933             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
7934
7935 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
7936   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
7937             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
7938
7939 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
7940   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
7941             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
7942
7943 template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
7944   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
7945             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
7946
7947 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
7948   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
7949             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
7950
7951 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
7952   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
7953             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
7954
7955 ...
7956
7957 template &lt;class Value, class Hash, class Pred, class Alloc&gt;
7958   void swap(unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; x,
7959             unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; y);
7960
7961 <ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt;
7962   void swap(unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; x,
7963             unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
7964
7965 <ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt;
7966   void swap(unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; x,
7967             unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; y);</ins>
7968
7969 template &lt;class Value, class Hash, class Pred, class Alloc&gt;
7970   void swap(unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; x,
7971             unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; y);
7972
7973 <ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt;
7974   void swap(unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; x,
7975             unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
7976
7977 <ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt;
7978   void swap(unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; x,
7979             unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; y);</ins>
7980 </pre></blockquote>
7981
7982 <p><b><tt>unordered_map</tt></b></p>
7983
7984 <p>
7985 Change 23.4.1 [unord.map]:
7986 </p>
7987
7988 <blockquote><pre>class unordered_map
7989 {
7990     ...
7991     unordered_map(const unordered_map&amp;);
7992     <ins>unordered_map(unordered_map&amp;&amp;);</ins>
7993     ~unordered_map();
7994     unordered_map&amp; operator=(const unordered_map&amp;);
7995     <ins>unordered_map&amp; operator=(unordered_map&amp;&amp;);</ins>
7996     ...
7997     // modifiers
7998     <del>std::</del>pair&lt;iterator, bool&gt; insert(const value_type&amp; obj);
7999     <ins>template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(P&amp;&amp; obj);</ins>
8000     iterator       insert(iterator hint, const value_type&amp; obj);
8001     <ins>template &lt;class P&gt; iterator       insert(iterator hint, P&amp;&amp; obj);</ins>
8002     const_iterator insert(const_iterator hint, const value_type&amp; obj);
8003     <ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; obj);</ins>
8004     ...
8005     void swap(unordered_map&amp;<ins>&amp;</ins>);
8006     ...
8007     mapped_type&amp; operator[](const key_type&amp; k);
8008     <ins>mapped_type&amp; operator[](key_type&amp;&amp; k);</ins>
8009     ...
8010 };
8011
8012 template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8013   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
8014             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
8015
8016 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8017   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
8018             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
8019
8020 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8021   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
8022             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
8023 </pre></blockquote>
8024
8025 <p>
8026 Add to 23.4.1.1 [unord.map.cnstr]:
8027 </p>
8028
8029 <blockquote>
8030 <pre>template &lt;class InputIterator&gt;
8031   unordered_map(InputIterator f, InputIterator l,
8032                 size_type n = <i>implementation-defined</i>,
8033                 const hasher&amp; hf = hasher(),
8034                 const key_equal&amp; eql = key_equal(),
8035                 const allocator_type&amp; a = allocator_type());
8036 </pre>
8037
8038 <blockquote><p>
8039 <ins>
8040 <i>Requires:</i> If the iterator's dereference operator returns an
8041 lvalue or a const rvalue <tt>pair&lt;key_type, mapped_type&gt;</tt>,
8042 then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be
8043 <tt>CopyConstructible</tt>.
8044 </ins>
8045 </p></blockquote>
8046 </blockquote>
8047
8048 <p>
8049 Add to 23.4.1.2 [unord.map.elem]:
8050 </p>
8051
8052 <blockquote>
8053
8054 <pre>mapped_type&amp; operator[](const key_type&amp; k);</pre>
8055
8056 <blockquote>
8057 <p>...</p>
8058 <p><ins>
8059 <i>Requires:</i> <tt>key_type</tt> shall be <tt>CopyConstructible</tt>
8060 and <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>.
8061 </ins></p>
8062 </blockquote>
8063
8064 <pre><ins>mapped_type&amp; operator[](key_type&amp;&amp; k);</ins></pre>
8065
8066 <blockquote>
8067 <p><ins>
8068 <i>Effects:</i> If the <tt>unordered_map</tt> does not already contain an
8069 element whose key is equivalent to <tt>k</tt> , inserts the value
8070 <tt>std::pair&lt;const key_type, mapped_type&gt;(std::move(k), mapped_type())</tt>.
8071 </ins></p>
8072
8073 <p><ins>
8074 <i>Requires:</i> <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>.
8075 </ins></p>
8076
8077 <p><ins>
8078 <i>Returns:</i> A reference to <tt>x.second</tt>, where <tt>x</tt> is the
8079 (unique) element whose key is equivalent to <tt>k</tt>.
8080 </ins></p>
8081
8082 </blockquote>
8083
8084 </blockquote>
8085
8086 <p>
8087 Add new section [unord.map.modifiers]:
8088 </p>
8089
8090 <blockquote>
8091 <pre><ins>pair&lt;iterator, bool&gt; insert(const value_type&amp; x);</ins>
8092 <ins>template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(P&amp;&amp; x);</ins>
8093 <ins>iterator       insert(iterator hint, const value_type&amp; x);</ins>
8094 <ins>template &lt;class P&gt; iterator       insert(iterator hint, P&amp;&amp; x);</ins>
8095 <ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
8096 <ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; x);</ins>
8097 <ins>template &lt;class InputIterator&gt;
8098   void insert(InputIterator first, InputIterator last);</ins>
8099 </pre>
8100
8101 <blockquote>
8102 <p><ins>
8103 <i>Requires:</i> Those signatures taking a <tt>const value_type&amp;</tt> parameter
8104 requires both the <tt>key_type</tt> and the <tt>mapped_type</tt> to be
8105 <tt>CopyConstructible</tt>.
8106 </ins></p>
8107
8108 <p><ins>
8109 <tt>P</tt> shall be convertible to <tt>value_type</tt>.
8110  If <tt>P</tt> is instantiated as a reference
8111 type, then the argument <tt>x</tt> is copied from. Otherwise <tt>x</tt>
8112 is considered to be an rvalue as it is converted to <tt>value_type</tt>
8113 and inserted into the <tt>unordered_map</tt>. Specifically, in such
8114 cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or
8115 <tt>mapped_type</tt> unless the conversion from <tt>P</tt> specifically
8116 requires it (e.g. if <tt>P</tt> is a <tt>tuple&lt;const key_type,
8117 mapped_type&gt;</tt>, then <tt>key_type</tt> must be
8118 <tt>CopyConstructible</tt>).
8119 </ins></p>
8120
8121 <p><ins>
8122 The signature taking <tt>InputIterator</tt>
8123 parameters requires <tt>CopyConstructible</tt> of both
8124 <tt>key_type</tt> and <tt>mapped_type</tt> if the dereferenced
8125 <tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
8126 <tt>value_type</tt>.
8127 </ins></p>
8128
8129 </blockquote>
8130
8131 </blockquote>
8132
8133 <p>
8134 Add to 23.4.1.3 [unord.map.swap]:
8135 </p>
8136
8137 <blockquote>
8138 <pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8139   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
8140             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
8141 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8142   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
8143             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
8144 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8145   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
8146             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
8147 </pre>
8148 </blockquote>
8149
8150 <p><b><tt>unordered_multimap</tt></b></p>
8151
8152 <p>
8153 Change 23.4.2 [unord.multimap]:
8154 </p>
8155
8156 <blockquote><pre>class unordered_multimap
8157 {
8158     ...
8159     unordered_multimap(const unordered_multimap&amp;);
8160     <ins>unordered_multimap(unordered_multimap&amp;&amp;);</ins>
8161     ~unordered_multimap();
8162     unordered_multimap&amp; operator=(const unordered_multimap&amp;);
8163     <ins>unordered_multimap&amp; operator=(unordered_multimap&amp;&amp;);</ins>
8164     ...
8165     // modifiers
8166     iterator insert(const value_type&amp; obj);
8167     <ins>template &lt;class P&gt; iterator insert(P&amp;&amp; obj);</ins>
8168     iterator       insert(iterator hint, const value_type&amp; obj);
8169     <ins>template &lt;class P&gt; iterator       insert(iterator hint, P&amp;&amp; obj);</ins>
8170     const_iterator insert(const_iterator hint, const value_type&amp; obj);
8171     <ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; obj);</ins>
8172     ...
8173     void swap(unordered_multimap&amp;<ins>&amp;</ins>);
8174     ...
8175 };
8176
8177 template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8178   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
8179             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
8180
8181 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8182   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
8183             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
8184
8185 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8186   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
8187             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
8188 </pre></blockquote>
8189
8190 <p>
8191 Add to 23.4.2.1 [unord.multimap.cnstr]:
8192 </p>
8193
8194 <blockquote>
8195 <pre>template &lt;class InputIterator&gt;
8196   unordered_multimap(InputIterator f, InputIterator l,
8197                 size_type n = <i>implementation-defined</i>,
8198                 const hasher&amp; hf = hasher(),
8199                 const key_equal&amp; eql = key_equal(),
8200                 const allocator_type&amp; a = allocator_type());
8201 </pre>
8202
8203 <blockquote><p>
8204 <ins>
8205 <i>Requires:</i> If the iterator's dereference operator returns an
8206 lvalue or a const rvalue <tt>pair&lt;key_type, mapped_type&gt;</tt>,
8207 then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be
8208 <tt>CopyConstructible</tt>.
8209 </ins>
8210 </p></blockquote>
8211 </blockquote>
8212
8213 <p>
8214 Add new section [unord.multimap.modifiers]:
8215 </p>
8216
8217 <blockquote>
8218 <pre><ins>iterator insert(const value_type&amp; x);</ins>
8219 <ins>template &lt;class P&gt; iterator       insert(P&amp;&amp; x);</ins>
8220 <ins>iterator       insert(iterator hint, const value_type&amp; x);</ins>
8221 <ins>template &lt;class P&gt; iterator       insert(iterator hint, P&amp;&amp; x);</ins>
8222 <ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
8223 <ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; x);</ins>
8224 <ins>template &lt;class InputIterator&gt;
8225   void insert(InputIterator first, InputIterator last);</ins>
8226 </pre>
8227
8228 <blockquote>
8229 <p><ins>
8230 <i>Requires:</i> Those signatures taking a <tt>const value_type&amp;</tt> parameter
8231 requires both the <tt>key_type</tt> and the <tt>mapped_type</tt> to be
8232 <tt>CopyConstructible</tt>.
8233 </ins></p>
8234
8235 <p><ins>
8236 <tt>P</tt> shall be convertible to <tt>value_type</tt>.
8237  If <tt>P</tt> is instantiated as a reference
8238 type, then the argument <tt>x</tt> is copied from. Otherwise <tt>x</tt>
8239 is considered to be an rvalue as it is converted to <tt>value_type</tt>
8240 and inserted into the <tt>unordered_multimap</tt>. Specifically, in such
8241 cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or
8242 <tt>mapped_type</tt> unless the conversion from <tt>P</tt> specifically
8243 requires it (e.g. if <tt>P</tt> is a <tt>tuple&lt;const key_type,
8244 mapped_type&gt;</tt>, then <tt>key_type</tt> must be
8245 <tt>CopyConstructible</tt>).
8246 </ins></p>
8247
8248 <p><ins>
8249 The signature taking <tt>InputIterator</tt>
8250 parameters requires <tt>CopyConstructible</tt> of both
8251 <tt>key_type</tt> and <tt>mapped_type</tt> if the dereferenced
8252 <tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
8253 <tt>value_type</tt>.
8254 </ins></p>
8255 </blockquote>
8256
8257 </blockquote>
8258
8259 <p>
8260 Add to 23.4.2.2 [unord.multimap.swap]:
8261 </p>
8262
8263 <blockquote>
8264 <pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8265   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
8266             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
8267 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8268   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
8269             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
8270 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8271   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
8272             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
8273 </pre>
8274 </blockquote>
8275
8276 <p><b><tt>unordered_set</tt></b></p>
8277
8278 <p>
8279 Change 23.4.3 [unord.set]:
8280 </p>
8281
8282 <blockquote><pre>class unordered_set
8283 {
8284     ...
8285     unordered_set(const unordered_set&amp;);
8286     <ins>unordered_set(unordered_set&amp;&amp;);</ins>
8287     ~unordered_set();
8288     unordered_set&amp; operator=(const unordered_set&amp;);
8289     <ins>unordered_set&amp; operator=(unordered_set&amp;&amp;);</ins>
8290     ...
8291     // modifiers
8292     <del>std::</del>pair&lt;iterator, bool&gt; insert(const value_type&amp; obj);
8293     <ins>pair&lt;iterator, bool&gt; insert(value_type&amp;&amp; obj);</ins>
8294     iterator       insert(iterator hint, const value_type&amp; obj);
8295     <ins>iterator       insert(iterator hint, value_type&amp;&amp; obj);</ins>
8296     const_iterator insert(const_iterator hint, const value_type&amp; obj);
8297     <ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; obj);</ins>
8298     ...
8299     void swap(unordered_set&amp;<ins>&amp;</ins>);
8300     ...
8301 };
8302
8303 template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8304   void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
8305             unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
8306
8307 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8308   void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
8309             unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
8310
8311 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8312   void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
8313             unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
8314 </pre></blockquote>
8315
8316 <p>
8317 Add to 23.4.3.1 [unord.set.cnstr]:
8318 </p>
8319
8320 <blockquote>
8321 <pre>template &lt;class InputIterator&gt;
8322   unordered_set(InputIterator f, InputIterator l,
8323                 size_type n = <i>implementation-defined</i>,
8324                 const hasher&amp; hf = hasher(),
8325                 const key_equal&amp; eql = key_equal(),
8326                 const allocator_type&amp; a = allocator_type());
8327 </pre>
8328
8329 <blockquote><p>
8330 <ins>
8331 <i>Requires:</i> If the iterator's dereference operator returns an
8332 lvalue or a const rvalue <tt>value_type</tt>, then the
8333 <tt>value_type</tt> shall be <tt>CopyConstructible</tt>.
8334 </ins>
8335 </p></blockquote>
8336 </blockquote>
8337
8338 <p>
8339 Add new section [unord.set.modifiers]:
8340 </p>
8341
8342 <blockquote>
8343 <pre><ins>pair&lt;iterator, bool&gt; insert(const value_type&amp; x);</ins>
8344 <ins>pair&lt;iterator, bool&gt; insert(value_type&amp;&amp; x);</ins>
8345 <ins>iterator       insert(iterator hint, const value_type&amp; x);</ins>
8346 <ins>iterator       insert(iterator hint, value_type&amp;&amp; x);</ins>
8347 <ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
8348 <ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; x);</ins>
8349 <ins>template &lt;class InputIterator&gt;
8350   void insert(InputIterator first, InputIterator last);</ins>
8351 </pre>
8352
8353 <blockquote>
8354
8355 <p><ins>
8356 <i>Requires:</i> Those signatures taking a <tt>const
8357 value_type&amp;</tt> parameter requires the <tt>value_type</tt> to
8358 be <tt>CopyConstructible</tt>.
8359 </ins></p>
8360
8361 <p><ins>
8362 The signature taking <tt>InputIterator</tt> parameters requires
8363 <tt>CopyConstructible</tt> of <tt>value_type</tt> if the dereferenced
8364 <tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
8365 <tt>value_type</tt>.
8366 </ins></p>
8367
8368 </blockquote>
8369
8370 </blockquote>
8371
8372 <p>
8373 Add to 23.4.3.2 [unord.set.swap]:
8374 </p>
8375
8376 <blockquote>
8377 <pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8378   void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
8379             unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
8380 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8381   void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
8382             unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
8383 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8384   void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
8385             unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
8386 </pre>
8387 </blockquote>
8388
8389 <p><b><tt>unordered_multiset</tt></b></p>
8390
8391 <p>
8392 Change 23.4.4 [unord.multiset]:
8393 </p>
8394
8395 <blockquote><pre>class unordered_multiset
8396 {
8397     ...
8398     unordered_multiset(const unordered_multiset&amp;);
8399     <ins>unordered_multiset(unordered_multiset&amp;&amp;);</ins>
8400     ~unordered_multiset();
8401     unordered_multiset&amp; operator=(const unordered_multiset&amp;);
8402     <ins>unordered_multiset&amp; operator=(unordered_multiset&amp;&amp;);</ins>
8403     ...
8404     // modifiers
8405     iterator insert(const value_type&amp; obj);
8406     <ins>iterator insert(value_type&amp;&amp; obj);</ins>
8407     iterator       insert(iterator hint, const value_type&amp; obj);
8408     <ins>iterator       insert(iterator hint, value_type&amp;&amp; obj);</ins>
8409     const_iterator insert(const_iterator hint, const value_type&amp; obj);
8410     <ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; obj);</ins>
8411     ...
8412     void swap(unordered_multiset&amp;<ins>&amp;</ins>);
8413     ...
8414 };
8415
8416 template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8417   void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
8418             unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
8419
8420 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8421   void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
8422             unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
8423
8424 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8425   void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
8426             unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
8427 </pre></blockquote>
8428
8429 <p>
8430 Add to 23.4.4.1 [unord.multiset.cnstr]:
8431 </p>
8432
8433 <blockquote>
8434 <pre>template &lt;class InputIterator&gt;
8435   unordered_multiset(InputIterator f, InputIterator l,
8436                 size_type n = <i>implementation-defined</i>,
8437                 const hasher&amp; hf = hasher(),
8438                 const key_equal&amp; eql = key_equal(),
8439                 const allocator_type&amp; a = allocator_type());
8440 </pre>
8441
8442 <blockquote><p>
8443 <ins>
8444 <i>Requires:</i> If the iterator's dereference operator returns an
8445 lvalue or a const rvalue <tt>value_type</tt>, then the
8446 <tt>value_type</tt> shall be <tt>CopyConstructible</tt>.
8447 </ins>
8448 </p></blockquote>
8449 </blockquote>
8450
8451 <p>
8452 Add new section [unord.multiset.modifiers]:
8453 </p>
8454
8455 <blockquote>
8456 <pre><ins>iterator insert(const value_type&amp; x);</ins>
8457 <ins>iterator insert(value_type&amp;&amp; x);</ins>
8458 <ins>iterator       insert(iterator hint, const value_type&amp; x);</ins>
8459 <ins>iterator       insert(iterator hint, value_type&amp;&amp; x);</ins>
8460 <ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
8461 <ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; x);</ins>
8462 <ins>template &lt;class InputIterator&gt;
8463   void insert(InputIterator first, InputIterator last);</ins>
8464 </pre>
8465
8466 <blockquote>
8467
8468 <p><ins>
8469 <i>Requires:</i> Those signatures taking a <tt>const
8470 value_type&amp;</tt> parameter requires the <tt>value_type</tt> to
8471 be <tt>CopyConstructible</tt>.
8472 </ins></p>
8473
8474 <p><ins>
8475 The signature taking <tt>InputIterator</tt> parameters requires
8476 <tt>CopyConstructible</tt> of <tt>value_type</tt> if the dereferenced
8477 <tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
8478 <tt>value_type</tt>.
8479 </ins></p>
8480
8481 </blockquote>
8482
8483 </blockquote>
8484
8485 <p>
8486 Add to 23.4.4.2 [unord.multiset.swap]:
8487 </p>
8488
8489 <blockquote>
8490 <pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8491   void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
8492             unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
8493 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8494   void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
8495             unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
8496 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
8497   void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
8498             unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
8499 </pre>
8500 </blockquote>
8501
8502
8503
8504 <p><i>[
8505 Voted to WP in Bellevue.
8506 ]</i></p>
8507
8508
8509 <p><i>[
8510 post Bellevue, Pete notes:
8511 ]</i></p>
8512
8513
8514 <blockquote>
8515 <p>
8516 Please remind people who are reviewing issues to check that the text
8517 modifications match the current draft. Issue 676, for example, adds two
8518 overloads for unordered_map::insert taking a hint. One takes a
8519 const_iterator and returns a const_iterator, and the other takes an
8520 iterator and returns an iterator. This was correct at the time the issue
8521 was written, but was changed in Toronto so there is only one hint
8522 overload, taking a const_iterator and returning an iterator.
8523 </p>
8524 <p>
8525 This issue is not ready. In addition to the relatively minor signature
8526 problem I mentioned earlier, it puts requirements in the wrong places.
8527 Instead of duplicating requirements throughout the template
8528 specifications, it should put them in the front matter that talks about
8529 requirements for unordered containers in general. This presentation
8530 problem is editorial, but I'm not willing to do the extensive rewrite
8531 that it requires. Please put it back into Open status.
8532 </p>
8533 </blockquote>
8534
8535
8536
8537
8538 <hr>
8539 <h3><a name="688"></a>688. reference_wrapper, cref unsafe, allow binding to rvalues</h3>
8540 <p><b>Section:</b> 20.6.5.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
8541  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</p>
8542 <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>
8543 <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>
8544 <p><b>Discussion:</b></p>
8545 <p>
8546 A <tt>reference_wrapper</tt> can be constructed from an rvalue, either by using
8547 the constructor, or via <tt>cref</tt> (and <tt>ref</tt> in some corner cases). This leads
8548 to a dangling reference being stored into the <tt>reference_wrapper</tt> object.
8549 Now that we have a mechanism to detect an rvalue, we can fix them to
8550 disallow this source of undefined behavior.
8551 </p>
8552
8553 <p>
8554 Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
8555 </p>
8556
8557
8558
8559 <p><b>Proposed resolution:</b></p>
8560 <p>
8561 In 20.6 [function.objects], add the following two signatures to the synopsis:
8562 </p>
8563
8564 <blockquote><pre>template &lt;class T&gt; void ref(const T&amp;&amp; t) = delete;
8565 template &lt;class T&gt; void cref(const T&amp;&amp; t) = delete;
8566 </pre></blockquote>
8567
8568
8569
8570 <p><i>[
8571 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2292.html">N2292</a>
8572 addresses the first part of the resolution but not the second.
8573 ]</i></p>
8574
8575
8576 <p><i>[
8577 Bellevue:  Doug noticed problems with the current wording.
8578 ]</i></p>
8579
8580
8581 <p><i>[
8582 post Bellevue:  Howard and Peter provided revised wording.
8583 ]</i></p>
8584
8585
8586 <p><i>[
8587 This resolution depends on a "favorable" resolution of CWG 606:  that is,
8588 the "special deduction rule" is disabled with the const T&amp;&amp; pattern.
8589 ]</i></p>
8590
8591
8592
8593
8594
8595 <hr>
8596 <h3><a name="691"></a>691. const_local_iterator cbegin, cend missing from TR1</h3>
8597 <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#Ready">Ready</a>
8598  <b>Submitter:</b> Joaquín M López Muñoz <b>Date:</b> 2007-06-14</p>
8599 <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>
8600 <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>
8601 <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>
8602 <p><b>Discussion:</b></p>
8603 <p>
8604 The last version of TR1 does not include the following member
8605 functions
8606 for unordered containers:
8607 </p>
8608
8609 <blockquote><pre>const_local_iterator cbegin(size_type n) const;
8610 const_local_iterator cend(size_type n) const;
8611 </pre></blockquote>
8612
8613 <p>
8614 which looks like an oversight to me. I've checked th TR1 issues lists
8615 and the latest working draft of the C++0x std (N2284) and haven't
8616 found any mention to these menfuns or to their absence.
8617 </p>
8618 <p>
8619 Is this really an oversight, or am I missing something?
8620 </p>
8621
8622
8623
8624 <p><b>Proposed resolution:</b></p>
8625 <p>
8626 Add the following two rows to table 93 (unordered associative container
8627 requirements) in section 23.1.5 [unord.req]:
8628 </p>
8629
8630 <blockquote>
8631 <table border="1">
8632 <caption>Unordered associative container requirements (in addition to container)</caption>
8633 <tbody><tr>
8634 <th>expression</th> <th>return type</th> <th>assertion/note pre/post-condition</th> <th>complexity</th>
8635 </tr>
8636 <tr>
8637 <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>
8638 </tr>
8639 <tr>
8640 <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>
8641 </tr>
8642 </tbody></table>
8643 </blockquote>
8644
8645 <p>
8646 Add to the synopsis in 23.4.1 [unord.map]:
8647 </p>
8648
8649 <blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
8650 const_local_iterator cend(size_type n) const;</ins>
8651 </pre></blockquote>
8652
8653 <p>
8654 Add to the synopsis in 23.4.2 [unord.multimap]:
8655 </p>
8656
8657 <blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
8658 const_local_iterator cend(size_type n) const;</ins>
8659 </pre></blockquote>
8660
8661 <p>
8662 Add to the synopsis in 23.4.3 [unord.set]:
8663 </p>
8664
8665 <blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
8666 const_local_iterator cend(size_type n) const;</ins>
8667 </pre></blockquote>
8668
8669 <p>
8670 Add to the synopsis in 23.4.4 [unord.multiset]:
8671 </p>
8672
8673 <blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
8674 const_local_iterator cend(size_type n) const;</ins>
8675 </pre></blockquote>
8676
8677
8678
8679
8680
8681
8682 <hr>
8683 <h3><a name="692"></a>692. <code>get_money</code> and <code>put_money</code> should be formatted I/O functions</h3>
8684 <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#Review">Review</a>
8685  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p>
8686 <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>
8687 <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>
8688 <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>
8689 <p><b>Discussion:</b></p>
8690 <p>
8691 In a private email Bill Plauger notes:
8692 </p>
8693 <blockquote><p>
8694 I  believe that  the function  that  implements <code>get_money</code>
8695 [from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2072.html">N2072</a>]
8696 should behave  as a  formatted input function,  and the  function that
8697 implements <code>put_money</code> should  behave as a formatted output
8698 function. This  has implications regarding the  skipping of whitespace
8699 and the handling of errors, among other things.
8700 </p>
8701 <p>
8702 The words  don't say that  right now and  I'm far from  convinced that
8703 such a change is editorial.
8704 </p></blockquote>
8705 <p>
8706 Martin's response:
8707 </p>
8708 <blockquote><p>
8709 I agree that the manipulators should handle exceptions the same way as
8710 formatted I/O functions do. The text in N2072 assumes so but the
8711 <i>Returns</i> clause explicitly omits exception handling for the sake
8712 of brevity. The spec should be clarified to that effect.
8713 </p>
8714 <p>
8715 As for dealing  with whitespace, I also agree it  would make sense for
8716 the extractors  and inserters involving the new  manipulators to treat
8717 it the same way as formatted I/O.
8718 </p></blockquote>
8719
8720
8721 <p><b>Proposed resolution:</b></p>
8722 <p>
8723 Add  a new  paragraph immediately  above  p4 of 27.6.4 [ext.manip] with  the
8724 following text:
8725 </p>
8726 <blockquote><p>
8727 <i>Effects</i>:  The   expression  <code><i>in</i> &gt;&gt; get_money(mon, intl)</code>
8728 described below behaves as a formatted input function (as
8729 described in 27.6.1.2.1 [istream.formatted.reqmts]).
8730 </p></blockquote>
8731 <p>
8732 Also change p4 of 27.6.4 [ext.manip] as follows:
8733 </p>
8734 <blockquote><p>
8735 <i>Returns</i>: An object <code>s</code> of unspecified type such that
8736 if <code>in</code> is  an object of type <code>basic_istream&lt;charT,
8737 traits&gt;</code>    then    the    expression   <code><i>in</i> &gt;&gt; get_money(mon, intl)</code> behaves as <ins>a formatted input function
8738 that    calls    </ins><code>f(in, mon, intl)</code><del>    were
8739 called</del>. The function <code>f</code> can be defined as...
8740 </p></blockquote>
8741
8742
8743 <p><i>[
8744 post Bellevue:
8745 ]</i></p>
8746
8747
8748 <blockquote>
8749 We recommend moving immediately to Review. We've looked at the issue and
8750 have a consensus that the proposed resolution is correct, but want an
8751 iostream expert to sign off. Alisdair has taken the action item to putt
8752 this up on the reflector for possible movement by Howard to Tenatively
8753 Ready.
8754 </blockquote>
8755
8756
8757
8758
8759 <hr>
8760 <h3><a name="696"></a>696. <code>istream::operator&gt;&gt;(int&amp;)</code> broken</h3>
8761 <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>
8762  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-23</p>
8763 <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>
8764 <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>
8765 <p><b>Discussion:</b></p>
8766 <p>
8767 From message c++std-lib-17897:
8768 </p>
8769 <p>
8770 The  code  shown  in  27.6.1.2.2 [istream.formatted.arithmetic] as  the  "as  if"
8771 implementation  of the  two arithmetic  extractors that  don't  have a
8772 corresponding     <code>num_get</code>     interface    (i.e.,     the
8773 <code>short</code> and <code>int</code>  overloads) is subtly buggy in
8774 how  it  deals  with  <code>EOF</code>, overflow,  and  other  similar
8775 conditions (in addition to containing a few typos).
8776 </p>
8777 <p>
8778 One  problem is  that if  <code>num_get::get()</code> reaches  the EOF
8779 after reading in  an otherwise valid value that  exceeds the limits of
8780 the    narrower    type     (but    not    <code>LONG_MIN</code>    or
8781 <code>LONG_MAX</code>),   it  will   set   <code><i>err</i></code>  to
8782 <code>eofbit</code>.   Because   of  the  if   condition  testing  for
8783 <code>(<i>err</i> == 0)</code>,    the   extractor    won't   set
8784 <code>failbit</code>  (and presumably,  return  a bogus  value to  the
8785 caller).
8786 </p>
8787 <p>
8788 Another  problem with  the code  is that  it never  actually  sets the
8789 argument to  the extracted  value. It can't  happen after the  call to
8790 <code>setstate()</code> since  the function may  throw, so we  need to
8791 show when  and how it's done (we  can't just punt as  say: "it happens
8792 afterwards"). However, it  turns out that showing how  it's done isn't
8793 quite so  easy since  the argument is  normally left unchanged  by the
8794 facet on error  except when the error is due  to a misplaced thousands
8795 separator,  which causes  <code>failbit</code> to  be set  but doesn't
8796 prevent the facet from storing the value.
8797 </p>
8798
8799
8800 <p><b>Proposed resolution:</b></p>
8801 <p>
8802 </p>
8803
8804
8805
8806
8807
8808 <hr>
8809 <h3><a name="698"></a>698. <tt>system_error</tt> needs <tt>const char*</tt> constructors</h3>
8810 <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#Review">Review</a>
8811  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-06-24</p>
8812 <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>
8813 <p><b>Discussion:</b></p>
8814 <p>
8815 In 19.4.5.1 [syserr.syserr.overview] we have the class definition of
8816 <tt>std::system_error</tt>. In contrast to all exception classes, which
8817 are constructible with a <tt>what_arg string</tt> (see 19.1 [std.exceptions],
8818 or <tt>ios_base::failure</tt> in 27.4.2.1.1 [ios::failure]), only overloads with with
8819 <tt>const string&amp;</tt> are possible. For consistency with the re-designed
8820 remaining exception classes this class should also provide
8821 c'tors which accept a const <tt>char* what_arg</tt> string.
8822 </p>
8823 <p>
8824 Please note that this proposed addition makes sense even
8825 considering the given implementation hint for <tt>what()</tt>, because
8826 <tt>what_arg</tt> is required to be set as <tt>what_arg</tt> of the base class
8827 <tt>runtime_error</tt>, which now has the additional c'tor overload
8828 accepting a <tt>const char*</tt>.
8829 </p>
8830
8831
8832 <p><b>Proposed resolution:</b></p>
8833 <p>
8834 This proposed wording assumes issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a> has been accepted and applied to the working paper.
8835 </p>
8836
8837 <p>
8838 Change 19.4.5.1 [syserr.syserr.overview] Class system_error overview, as indicated:
8839 </p>
8840
8841 <blockquote><pre>public:
8842   system_error(error_code ec, const string&amp; what_arg);
8843   <ins>system_error(error_code ec, const char* what_arg);</ins>
8844   system_error(error_code ec);
8845   system_error(int ev, const error_category* ecat,
8846       const string&amp; what_arg);
8847   <ins>system_error(int ev, const error_category* ecat,
8848       const char* what_arg);</ins>
8849   system_error(int ev, const error_category* ecat);
8850 </pre></blockquote>
8851
8852 <p>
8853 To 19.4.5.2 [syserr.syserr.members] Class system_error members add:
8854 </p>
8855
8856 <blockquote>
8857 <pre>system_error(error_code ec, const char* what_arg);
8858 </pre>
8859 <blockquote>
8860 <p>
8861 <i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
8862 </p>
8863 <p>
8864 <i>Postconditions:</i> <tt>code() == ec</tt> and <tt>strcmp(runtime_error::what(), what_arg) == 0</tt>.
8865 </p>
8866 </blockquote>
8867
8868 <pre>system_error(int ev, const error_category* ecat, const char* what_arg);
8869 </pre>
8870
8871 <blockquote>
8872 <p>
8873 <i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
8874 </p>
8875 <p>
8876 <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and <tt>strcmp(runtime_error::what(), what_arg) == 0</tt>.
8877 </p>
8878 </blockquote>
8879 </blockquote>
8880
8881
8882
8883
8884
8885
8886 <hr>
8887 <h3><a name="701"></a>701. assoc laguerre poly's</h3>
8888 <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>
8889  <b>Submitter:</b> Christopher Crawford <b>Date:</b> 2007-06-30</p>
8890 <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>
8891 <p><b>Discussion:</b></p>
8892 <p>
8893 I see that the definition the associated Laguerre
8894 polynomials TR1 5.2.1.1 [tr.num.sf.Lnm] has been corrected since
8895 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1687.pdf">N1687</a>.
8896 However, the draft standard only specifies ranks of integer value <tt>m</tt>,
8897 while the associated Laguerre polynomials are actually valid for real
8898 values of <tt>m &gt; -1</tt>.  In the case of non-integer values of <tt>m</tt>, the
8899 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>
8900 must be used, which also holds for integer values of <tt>m</tt>.  See
8901 Abramowitz &amp; Stegun, 22.11.6 for the general case, and 22.5.16-17 for
8902 the integer case.  In fact fractional values are most commonly used in
8903 physics, for example to <tt>m = +/- 1/2</tt> to describe the harmonic
8904 oscillator in 1 dimension, and <tt>1/2, 3/2, 5/2, ...</tt> in 3
8905 dimensions.
8906 </p>
8907 <p>
8908 If I am correct, the calculation of the more general case is no
8909 more difficult, and is in fact the function implemented in the GNU
8910 Scientific Library.  I would urge you to consider upgrading the
8911 standard, either adding extra functions for real <tt>m</tt> or switching the
8912 current ones to <tt>double</tt>.
8913 </p>
8914
8915
8916 <p><b>Proposed resolution:</b></p>
8917 <p>
8918 </p>
8919
8920
8921
8922
8923
8924 <hr>
8925 <h3><a name="702"></a>702. Restriction in associated Legendre functions</h3>
8926 <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>
8927  <b>Submitter:</b> Christopher Crawford <b>Date:</b> 2007-06-30</p>
8928 <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>
8929 <p><b>Discussion:</b></p>
8930 <p>
8931 One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should  be
8932 <tt>|x| &lt;= 1</tt>, not <tt>x &gt;= 0</tt>.</p>
8933
8934
8935 <p><b>Proposed resolution:</b></p>
8936 <p>
8937 </p>
8938
8939
8940
8941
8942
8943 <hr>
8944 <h3><a name="704"></a>704. MoveAssignable requirement for container value type overly strict</h3>
8945 <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>
8946  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-20</p>
8947 <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>
8948 <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>
8949 <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>
8950 <p><b>Discussion:</b></p>
8951 <p>
8952 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>.
8953 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
8954 most of the member functions of node-based containers.  But the move-related changes
8955 unnecessarily introduced the <tt>MoveAssignable</tt> requirement for those members which used to
8956 require <tt>CopyAssignable</tt>.
8957 </p>
8958
8959 <p>
8960 We also discussed (c++std-lib-18722) the possibility of dropping <tt>MoveAssignable</tt>
8961 from some of the sequence requirements.  Additionally the <i>in-place</i> construction
8962 work may further reduce requirements.  For purposes of an easy reference, here are the
8963 minimum sequence requirements as I currently understand them.  Those items in requirements
8964 table in the working draft which do not appear below have been purposefully omitted for
8965 brevity as they do not have any requirements of this nature.  Some items which do not
8966 have any requirements of this nature are included below just to confirm that they were
8967 not omitted by mistake.
8968 </p>
8969
8970 <table border="1">
8971 <caption>Container Requirements</caption>
8972 <tbody><tr><td><tt>X u(a)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
8973 <tr><td><tt>X u(rv)</tt></td><td><tt>array</tt> and containers with a <tt>propagate_never</tt> allocator require <tt>value_type</tt> to be <tt>MoveConstructible</tt></td></tr>
8974 <tr><td><tt>a = u</tt></td><td>Sequences require <tt>value_type</tt> to be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.
8975                                Associative containers require <tt>value_type</tt> to be <tt>CopyConstructible</tt>.</td></tr>
8976 <tr><td><tt>a = rv</tt></td><td><tt>array</tt> requires <tt>value_type</tt> to be <tt>MoveAssignable</tt>.
8977                                 Sequences and Associative containers with <tt>propagate_never</tt> and <tt>propagate_on_copy_construction</tt> allocators require <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
8978 <tr><td><tt>swap(a,u)</tt></td><td><tt>array</tt> and containers with <tt>propagate_never</tt> and
8979                   <tt>propagate_on_copy_construction</tt> allocators require <tt>value_type</tt> to be <tt>Swappable</tt>.</td></tr>
8980 </tbody></table>
8981
8982 <p>
8983 </p>
8984
8985 <table border="1">
8986 <caption>Sequence Requirements</caption>
8987 <tbody><tr><td><tt>X(n)</tt></td><td><tt>value_type</tt> must be <tt>DefaultConstructible</tt></td></tr>
8988 <tr><td><tt>X(n, t)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
8989 <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>.
8990                                  If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
8991 <tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
8992                                         The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
8993 <tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
8994                                         The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
8995 <tr><td><tt>a.insert(p, n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
8996                                         The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
8997 <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>.
8998                                         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.
8999                                         If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
9000                                         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>
9001 <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>
9002 <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>
9003 <tr><td><tt>a.clear()</tt></td><td></td></tr>
9004 <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>.
9005                                         If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.</td></tr>
9006 <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>
9007 <tr><td><tt>a.resize(n)</tt></td><td>The <tt>value_type</tt> must be <tt>DefaultConstructible</tt>.
9008                                      The sequence <tt>vector</tt> also requires the <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
9009 <tr><td><tt>a.resize(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
9010 </tbody></table>
9011
9012 <p>
9013 </p>
9014
9015 <table border="1">
9016 <caption>Optional Sequence Requirements</caption>
9017 <tbody><tr><td><tt>a.front()</tt></td><td></td></tr>
9018 <tr><td><tt>a.back()</tt></td><td></td></tr>
9019 <tr><td><tt>a.push_front(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
9020 <tr><td><tt>a.push_front(rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
9021 <tr><td><tt>a.push_back(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
9022 <tr><td><tt>a.push_back(rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
9023 <tr><td><tt>a.pop_front()</tt></td><td></td></tr>
9024 <tr><td><tt>a.pop_back()</tt></td><td></td></tr>
9025 <tr><td><tt>a[n]</tt></td><td></td></tr>
9026 <tr><td><tt>a.at[n]</tt></td><td></td></tr>
9027 </tbody></table>
9028
9029 <p>
9030 </p>
9031
9032 <table border="1">
9033 <caption>Associative Container Requirements</caption>
9034 <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>.
9035                                  If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
9036 <tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
9037 <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>
9038 <tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
9039 <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>
9040 <tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
9041 <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>
9042 <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>.
9043                                         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>
9044 </tbody></table>
9045
9046 <p>
9047 </p>
9048
9049 <table border="1">
9050 <caption>Unordered Associative Container Requirements</caption>
9051 <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>.
9052                                  If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
9053 <tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
9054 <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>
9055 <tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
9056 <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>
9057 <tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
9058 <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>
9059 <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>.
9060                                         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>
9061 </tbody></table>
9062
9063 <p>
9064 </p>
9065
9066 <table border="1">
9067 <caption>Miscellaneous Requirements</caption>
9068 <tbody><tr><td><tt>map[lvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>CopyConstructible</tt>.
9069                                          The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr>
9070 <tr><td><tt>map[rvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>MoveConstructible</tt>.
9071                                          The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr>
9072 </tbody></table>
9073
9074 <p><i>[
9075 Kona (2007): Howard and Alan to update requirements table in issue with emplace signatures.
9076 ]</i></p>
9077
9078
9079 <p><i>[
9080 Bellevue: This should be handled as part of the concepts work.
9081 ]</i></p>
9082
9083
9084
9085
9086 <p><b>Proposed resolution:</b></p>
9087
9088
9089
9090
9091
9092
9093 <hr>
9094 <h3><a name="708"></a>708. Locales need to be per thread and updated for POSIX changes</h3>
9095 <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>
9096  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-07-28</p>
9097 <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>
9098 <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>
9099 <p><b>Discussion:</b></p>
9100 <p>
9101 The POSIX "Extended API Set Part 4,"
9102 </p>
9103 <blockquote><p>
9104 <a href="http://www.opengroup.org/sib/details.tpl?id=C065">http://www.opengroup.org/sib/details.tpl?id=C065</a>
9105 </p></blockquote>
9106 <p>
9107 introduces extensions to the C locale mechanism that
9108 allow multiple concurrent locales to be used in the same application
9109 by introducing a type <tt>locale_t</tt> that is very similar to
9110 <tt>std::locale</tt>, and a number of <tt>_l</tt> functions that make use of it.
9111 </p>
9112 <p>
9113 The global locale (set by setlocale) is now specified to be per-
9114 process. If a thread does not call <tt>uselocale</tt>, the global locale is
9115 in effect for that thread. It can install a per-thread locale by
9116 using <tt>uselocale</tt>.
9117 </p>
9118 <p>
9119 There is also a nice <tt>querylocale</tt> mechanism by which one can obtain
9120 the name (such as "de_DE") for a specific <tt>facet</tt>, even for combined
9121 locales, with no <tt>std::locale</tt> equivalent.
9122 </p>
9123 <p>
9124 <tt>std::locale</tt> should be harmonized with the new POSIX <tt>locale_t</tt>
9125 mechanism and provide equivalents for <tt>uselocale</tt> and <tt>querylocale</tt>.
9126 </p>
9127
9128 <p><i>[
9129 Kona (2007): Bill and Nick to provide wording.
9130 ]</i></p>
9131
9132
9133
9134
9135 <p><b>Proposed resolution:</b></p>
9136 <p>
9137 </p>
9138
9139
9140
9141
9142
9143 <hr>
9144 <h3><a name="709"></a>709. <tt>char_traits::not_eof</tt> has wrong signature</h3>
9145 <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#Review">Review</a>
9146  <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-13</p>
9147 <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>
9148 <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>
9149 <p><b>Discussion:</b></p>
9150 <p>
9151 The changes made for <tt>constexpr</tt> in 21.1.3 [char.traits.specializations] have
9152 not only changed the <tt>not_eof</tt> function from pass by const reference to
9153 pass by value, it has also changed the parameter type from <tt>int_type</tt> to
9154 <tt>char_type</tt>.
9155 </p>
9156 <p>
9157 This doesn't work for type <tt>char</tt>, and is inconsistent with the
9158 requirements in Table 56, Traits requirements, 21.1.1 [char.traits.require].
9159 </p>
9160
9161 <p>
9162 Pete adds:
9163 </p>
9164
9165 <blockquote><p>
9166 For what it's worth, that may not have been an intentional change.
9167 N2349, which detailed the changes for adding constant expressions to
9168 the library, has strikeout bars through the <tt>const</tt> and the <tt>&amp;</tt> that
9169 surround the <tt>char_type</tt> argument, but none through <tt>char_type</tt> itself.
9170 So the intention may have been just to change to pass by value, with
9171 text incorrectly copied from the standard.
9172 </p></blockquote>
9173
9174
9175
9176 <p><b>Proposed resolution:</b></p>
9177 <p>
9178 Change the signature in 21.1.3.1 [char.traits.specializations.char],
9179 21.1.3.2 [char.traits.specializations.char16_t], 21.1.3.3 [char.traits.specializations.char32_t],
9180 and 21.1.3.4 [char.traits.specializations.wchar.t] to
9181 </p>
9182
9183 <blockquote><pre>static constexpr int_type not_eof(<del>char_type</del> <ins>int_type</ins> c);
9184 </pre></blockquote>
9185
9186
9187
9188 <p><i>[
9189 Bellevue:
9190 ]</i></p>
9191
9192
9193 <blockquote>
9194 Resolution: NAD editorial - up to Pete's judgment
9195 </blockquote>
9196
9197 <p><i>[
9198 Post Sophia Antipolis
9199 ]</i></p>
9200
9201
9202 <blockquote>
9203 Moved from Pending NAD Editorial to Review.  The proposed wording appears to be correct but non-editorial.
9204 </blockquote>
9205
9206
9207
9208
9209 <hr>
9210 <h3><a name="711"></a>711. Contradiction in empty <tt>shared_ptr</tt></h3>
9211 <p><b>Section:</b> 20.7.12.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
9212  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-08-24</p>
9213 <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>
9214 <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>
9215 <p><b>Discussion:</b></p>
9216 <p>
9217 A discussion on
9218 <a href="http://groups.google.com/group/comp.std.c++/browse_frm/thread/8e89dceb35cd7971">comp.std.c++</a>
9219 has identified a contradiction in the <tt>shared_ptr</tt> specification.
9220 The note:
9221 </p>
9222
9223 <blockquote><p>
9224 [ <i>Note:</i> this constructor allows creation of an empty shared_ptr instance with a non-NULL stored pointer.
9225 -end note ]
9226 </p></blockquote>
9227
9228 <p>
9229 after the aliasing constructor
9230 </p>
9231
9232 <blockquote><pre>template&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt; const&amp; r, T *p);
9233 </pre></blockquote>
9234
9235 <p>
9236 reflects the intent of
9237 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm">N2351</a>
9238 to, well, allow the creation of an empty <tt>shared_ptr</tt>
9239 with a non-NULL stored pointer.
9240 </p>
9241
9242 <p>
9243 This is contradicted by the second sentence in the Returns clause of 20.7.12.2.5 [util.smartptr.shared.obs]:
9244 </p>
9245
9246 <blockquote>
9247 <pre>T* get() const;
9248 </pre>
9249 <blockquote><p>
9250 <i>Returns:</i> the stored pointer. Returns a null pointer if <tt>*this</tt> is empty.
9251 </p></blockquote>
9252 </blockquote>
9253
9254 <p><i>[
9255 Bellevue:
9256 ]</i></p>
9257
9258
9259 <blockquote>
9260 <p>
9261 Adopt option 1 and move to review, not ready.
9262 </p>
9263 <p>
9264 There was a lot of confusion about what an empty <tt>shared_ptr</tt> is (the term
9265 isn't defined anywhere), and whether we have a good mental model for how
9266 one behaves. We think it might be possible to deduce what the definition
9267 should be, but the words just aren't there. We need to open an issue on
9268 the use of this undefined term. (The resolution of that issue might
9269 affect the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>.)
9270 </p>
9271 <p>
9272 The LWG is getting more uncomfortable with the aliasing proposal (N2351)
9273 now that we realize some of its implications, and we need to keep an eye
9274 on it, but there isn't support for removing this feature at this time.
9275 </p>
9276 </blockquote>
9277
9278 <p><i>[
9279 Sophia Antipolis:
9280 ]</i></p>
9281
9282
9283 <blockquote>
9284 <p>
9285 We heard from Peter Dimov, who explained his reason for preferring solution 1.
9286 </p>
9287 <p>
9288 Because it doesn't seem to add anything. It simply makes the behavior
9289 for p = 0 undefined. For programmers who don't create empty pointers
9290 with p = 0, there is no difference. Those who do insist on creating them
9291 presumably have a good reason, and it costs nothing for us to define the
9292 behavior in this case.
9293 </p>
9294 <p>
9295 The aliasing constructor is sharp enough as it is, so "protecting" users
9296 doesn't make much sense in this particular case.
9297 </p>
9298 <p>
9299 &gt; Do you have a use case for r being empty and r being non-null?
9300 </p>
9301 <p>
9302 I have received a few requests for it from "performance-conscious"
9303 people (you should be familiar with this mindset) who don't like the
9304 overhead of allocating and maintaining a control block when a null
9305 deleter is used to approximate a raw pointer. It is obviously an "at
9306 your own risk", low-level feature; essentially a raw pointer behind a
9307 shared_ptr facade.
9308 </p>
9309 <p>
9310 We could not agree upon a resolution to the issue; some of us thought
9311 that Peter's description above is supporting an undesirable behavior.
9312 </p>
9313 </blockquote>
9314
9315
9316
9317 <p><b>Proposed resolution:</b></p>
9318 <p>
9319 In keeping the N2351 spirit and obviously my preference, change 20.7.12.2.5 [util.smartptr.shared.obs]:
9320 </p>
9321
9322 <blockquote>
9323 <pre>T* get() const;
9324 </pre>
9325 <blockquote><p>
9326 <i>Returns:</i> the stored pointer. <del>Returns a null pointer if <tt>*this</tt> is empty.</del>
9327 </p></blockquote>
9328 </blockquote>
9329
9330 <p>
9331 Alternative proposed resolution: (I won't be happy if we do this, but it's possible):
9332 </p>
9333
9334 <p>
9335 Change 20.7.12.2.1 [util.smartptr.shared.const]:
9336 </p>
9337
9338 <blockquote>
9339 <pre>template&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt; const&amp; r, T *p);
9340 </pre>
9341 <blockquote>
9342 <p>
9343 <ins><i>Requires:</i> If <tt>r</tt> is empty, <tt>p</tt> shall be <tt>0</tt>.</ins>
9344 </p>
9345 <p>
9346 <del>[ <i>Note:</i> this constructor allows creation of an empty <tt>shared_ptr</tt>
9347 instance with a non-NULL stored pointer.
9348 -- <i>end note</i> ]</del>
9349 </p>
9350 </blockquote>
9351 </blockquote>
9352
9353
9354
9355
9356
9357
9358 <hr>
9359 <h3><a name="713"></a>713. <tt>sort()</tt> complexity is too lax</h3>
9360 <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#Ready">Ready</a>
9361  <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-30</p>
9362 <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>
9363 <p><b>Discussion:</b></p>
9364 <p>
9365 The complexity of <tt>sort()</tt> is specified as "Approximately <tt>N
9366 log(N)</tt> (where <tt>N == last - first</tt> ) comparisons on the
9367 average", with no worst case complicity specified. The intention was to
9368 allow a median-of-three quicksort implementation, which is usually <tt>O(N
9369 log N)</tt> but can be quadratic for pathological inputs. However, there is
9370 no longer any reason to allow implementers the freedom to have a
9371 worst-cast-quadratic sort algorithm. Implementers who want to use
9372 quicksort can use a variant like David Musser's "Introsort" (Software
9373 Practice and Experience 27:983-993, 1997), which is guaranteed to be <tt>O(N
9374 log N)</tt> in the worst case without incurring additional overhead in the
9375 average case. Most C++ library implementers already do this, and there
9376 is no reason not to guarantee it in the standard.
9377 </p>
9378
9379
9380 <p><b>Proposed resolution:</b></p>
9381 <p>
9382 In 25.3.1.1 [sort], change the complexity to "O(N log N)", and remove footnote 266:
9383 </p>
9384
9385 <blockquote>
9386 <p>
9387 <i>Complexity:</i> <del>Approximately</del> <ins>O(</ins><i>N</i> log(<i>N</i>)<ins>)</ins> (where <i>N</i> == <i>last</i> - <i>first</i> )
9388 comparisons<del> on the average</del>.<del><sup>266)</sup></del>
9389 </p>
9390 <p>
9391 <del><sup>266)</sup>
9392 If the worst case behavior is important <tt>stable_sort()</tt> (25.3.1.2) or <tt>partial_sort()</tt>
9393 (25.3.1.3) should be used.</del>
9394 </p>
9395 </blockquote>
9396
9397
9398
9399
9400
9401
9402 <hr>
9403 <h3><a name="714"></a>714. <tt>search_n</tt> complexity is too lax</h3>
9404 <p><b>Section:</b> 25.1.12 [alg.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
9405  <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-30</p>
9406 <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>
9407 <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>
9408 <p><b>Discussion:</b></p>
9409 <p>
9410 The complexity for <tt>search_n</tt> (25.1.12 [alg.search] par 7) is specified as "At most
9411 (last - first ) * count applications of the corresponding predicate if
9412 count is positive, or 0 otherwise." This is unnecessarily pessimistic.
9413 Regardless of the value of count, there is no reason to examine any
9414 element in the range more than once.
9415 </p>
9416
9417
9418 <p><b>Proposed resolution:</b></p>
9419 <p>
9420 Change the complexity to "At most (last - first) applications of the corresponding predicate".
9421 </p>
9422
9423 <blockquote>
9424 <pre>template&lt;class ForwardIterator, class Size, class T&gt;
9425   ForwardIterator
9426     search_n(ForwardIterator first , ForwardIterator last , Size count ,
9427              const T&amp; value );
9428
9429 template&lt;class ForwardIterator, class Size, class T,
9430          class BinaryPredicate&gt;
9431   ForwardIterator
9432     search_n(ForwardIterator first , ForwardIterator last , Size count ,
9433              const T&amp; value , BinaryPredicate pred );
9434 </pre>
9435 <blockquote>
9436 <p>
9437 <i>Complexity:</i> At most <tt>(last - first ) <del>* count</del></tt> applications of the corresponding predicate
9438 <del>if <tt>count</tt> is positive, or 0 otherwise</del>.
9439 </p>
9440 </blockquote>
9441 </blockquote>
9442
9443
9444
9445
9446
9447
9448 <hr>
9449 <h3><a name="716"></a>716. Production in [re.grammar] not actually modified</h3>
9450 <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>
9451  <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2007-08-31</p>
9452 <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>
9453 <p><b>Discussion:</b></p>
9454 <p>
9455 TR1 7.13 [tr.re.grammar]/3 and C++0x WP 28.13 [re.grammar]/3 say:
9456 </p>
9457
9458 <blockquote>
9459 <p>
9460 The following productions within the ECMAScript grammar are modified as follows:
9461 </p>
9462
9463 <blockquote><pre>CharacterClass ::
9464 [ [lookahead &#8713; {^}] ClassRanges ]
9465 [ ^ ClassRanges ]
9466 </pre></blockquote>
9467
9468 </blockquote>
9469
9470 <p>
9471 This definition for <tt>CharacterClass</tt> appears to be exactly identical to that in ECMA-262.
9472 </p>
9473
9474 <p>
9475 Was an actual modification intended here and accidentally omitted, or was this production accidentally included?
9476 </p>
9477
9478
9479 <p><b>Proposed resolution:</b></p>
9480 <p>
9481 Remove this mention of the CharacterClass production.
9482 </p>
9483
9484 <blockquote><pre><del>CharacterClass ::
9485 [ [lookahead &#8713; {^}] ClassRanges ]
9486 [ ^ ClassRanges ]</del>
9487 </pre></blockquote>
9488
9489
9490
9491
9492
9493
9494 <hr>
9495 <h3><a name="718"></a>718. <tt>basic_string</tt> is not a sequence</h3>
9496 <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>
9497  <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-18</p>
9498 <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>
9499 <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>
9500 <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>
9501 <p><b>Discussion:</b></p>
9502 <p>
9503 Paragraph 21.3 [basic.string]/3 states:
9504 </p>
9505
9506 <blockquote>
9507 <p>
9508 The class template <tt>basic_string</tt> conforms to the requirements for a
9509 Sequence (23.1.1) and for a Reversible Container (23.1).
9510 </p>
9511 </blockquote>
9512
9513 <p>
9514 First of all, 23.1.3 [sequence.reqmts] is no longer "Sequence" but "Sequence container".
9515 Secondly, after the resent changes to containers (<tt>emplace</tt>, <tt>push_back</tt>,
9516 <tt>const_iterator</tt> parameters to <tt>insert</tt> and <tt>erase</tt>), <tt>basic_string</tt> is not
9517 even close to conform to the current requirements.
9518 </p>
9519
9520 <p><i>[
9521 Bellevue:
9522 ]</i></p>
9523
9524
9525 <blockquote>
9526 <ul>
9527 <li>emplace, for example, may not make sense for strings. Is also likely suboptimal</li>
9528 <li>with concepts do we need to maintain string as sequence container?</li>
9529 <li>One approach might be to say something like: string is a sequence except it doesn't have these functions</li>
9530 </ul>
9531 <ul>
9532 <li>basic_string already has push_back</li>
9533 <li>const_iterator parameters to insert and erase should be added to basic_string</li>
9534 <li>this leaves emplace to handle -- we have the following options:
9535 <ul>
9536 <li>option 1: add it to string even though it's optional</li>
9537 <li>option 2: make emplace optional to sequences (move from table 89 to 90)</li>
9538 <li>option 3: say string not sequence (the proposal),</li>
9539 <li>option 4: add an exception to basic string wording.</li>
9540 </ul>
9541 </li>
9542 </ul>
9543 General consensus is to suggest option 2.
9544 </blockquote>
9545
9546
9547
9548 <p><b>Proposed resolution:</b></p>
9549 <p>
9550 Remove this sentence, in recognition of the fact that <tt>basic_string</tt> is
9551 not just a <tt>vector</tt>-light for literal types, but something quite
9552 different, a string abstraction in its own right.
9553 </p>
9554
9555
9556
9557
9558
9559 <hr>
9560 <h3><a name="719"></a>719. <tt>std::is_literal</tt> type traits should be provided</h3>
9561 <p><b>Section:</b> 20.5 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
9562  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-25</p>
9563 <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>
9564 <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>
9565 <p><b>Discussion:</b></p>
9566 <p>
9567 Since the inclusion of <tt>constexpr</tt> in the standard draft N2369 we have
9568 a new type category "literal", which is defined in 3.9 [basic.types]/p.11:
9569 </p>
9570
9571 <blockquote>
9572 <p>
9573 -11- A type is a <i>literal</i> type if it is:
9574 </p>
9575 <ul>
9576 <li>a scalar type; or</li>
9577 <li><p>a class type (clause 9) with</p>
9578 <ul>
9579 <li>a trivial copy constructor,</li>
9580 <li>a trivial destructor,</li>
9581 <li>at least one constexpr constructor other than the copy constructor,</li>
9582 <li>no virtual base classes, and</li>
9583 <li>all non-static data members and base classes of literal types; or</li>
9584 </ul>
9585 </li>
9586 <li>an array of literal type.</li>
9587 </ul>
9588 </blockquote>
9589
9590 <p>
9591 I strongly suggest that the standard provides a type traits for
9592 literal types in 20.5.4.3 [meta.unary.prop] for several reasons:
9593 </p>
9594
9595 <ol type="a">
9596 <li>To keep the traits in sync with existing types.</li>
9597 <li>I see many reasons for programmers to use this trait in template
9598    code to provide optimized template definitions for these types,
9599    see below.</li>
9600 <li>A user-provided definition of this trait is practically impossible
9601 to write portably.</li>
9602 </ol>
9603
9604 <p>
9605 The special problem of reason (c) is that I don't see currently a
9606 way to portably test the condition for literal class types:
9607 </p>
9608
9609 <blockquote>
9610 <ul>
9611 <li>at least one constexpr constructor other than the copy constructor,</li>
9612 </ul>
9613 </blockquote>
9614
9615 <p>
9616 Here follows a simply example to demonstrate it's usefulness:
9617 </p>
9618
9619 <blockquote><pre>template &lt;typename T&gt;
9620 constexpr typename std::enable_if&lt;std::is_literal&lt;T&gt;::value, T&gt;::type
9621 abs(T x) {
9622   return x &lt; T() ? -x : x;
9623 }
9624
9625 template &lt;typename T&gt;
9626 typename std::enable_if&lt;!std::is_literal&lt;T&gt;::value, T&gt;::type
9627 abs(const T&amp; x) {
9628   return x &lt; T() ? -x : x;
9629 }
9630 </pre></blockquote>
9631
9632 <p>
9633 Here we have the possibility to provide a general <tt>abs</tt> function
9634 template that can be used in ICE's if it's argument is a literal
9635 type which's value is a constant expression, otherwise we
9636 have an optimized version for arguments which are expensive
9637 to copy and therefore need the usage of arguments of
9638 reference type (instead of <tt>const T&amp;</tt> we could decide to
9639 use <tt>T&amp;&amp;</tt>, but that is another issue).
9640 </p>
9641
9642 <p><i>[
9643 Alisdair is considering preparing a paper listing a number of missing
9644 type traits, and feels that it might be useful to handle them all
9645 together rather than piecemeal. This would affect issue 719 and 750.
9646 These two issues should move to OPEN pending AM paper on type traits.
9647 ]</i></p>
9648
9649
9650
9651
9652 <p><b>Proposed resolution:</b></p>
9653 <p>
9654 In 20.5.2 [meta.type.synop] in the group "type properties",
9655 just below the line
9656 </p>
9657
9658 <blockquote><pre>template &lt;class T&gt; struct is_pod;
9659 </pre></blockquote>
9660
9661 <p>
9662 add a new one:
9663 </p>
9664
9665 <blockquote><pre>template &lt;class T&gt; struct is_literal;
9666 </pre></blockquote>
9667
9668 <p>
9669 In 20.5.4.3 [meta.unary.prop], table Type Property Predicates, just
9670 below the line for the <tt>is_pod</tt> property add a new line:
9671 </p>
9672
9673 <table border="1">
9674 <tbody><tr>
9675 <th>Template</th><th>Condition</th><th>Preconditions</th>
9676 </tr>
9677 <tr>
9678 <td><tt>template &lt;class T&gt; struct is_literal;</tt></td>
9679 <td><tt>T</tt> is a literal type (3.9)</td>
9680 <td><tt>T</tt> shall be a complete type, an
9681 array of unknown bound, or
9682 (possibly cv-qualified) <tt>void</tt>.</td>
9683 </tr>
9684 </tbody></table>
9685
9686
9687
9688
9689
9690
9691 <hr>
9692 <h3><a name="720"></a>720. Omissions in constexpr usages</h3>
9693 <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#Ready">Ready</a>
9694  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-25</p>
9695 <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>
9696 <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>
9697 <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>
9698 <p><b>Discussion:</b></p>
9699 <ol>
9700 <li>
9701 The member function <tt>bool array&lt;T,N&gt;::empty() const</tt> should be a
9702 <tt>constexpr</tt> because this is easily to proof and to implement following it's operational
9703 semantics defined by Table 87 (Container requirements) which says: <tt>a.size() == 0</tt>.
9704 </li>
9705 <li>
9706 The member function <tt>bool bitset&lt;N&gt;::test() const</tt> must be a
9707 <tt>constexpr</tt> (otherwise it would violate the specification of <tt>constexpr
9708 bitset&lt;N&gt;::operator[](size_t) const</tt>, because it's return clause delegates to <tt>test()</tt>).
9709 </li>
9710 <li>
9711 I wonder how the constructor <tt>bitset&lt;N&gt;::bitset(unsigned long)</tt> can
9712 be declared as a <tt>constexpr</tt>. Current implementations usually have no such <tt>bitset</tt>
9713 c'tor which would fulfill the requirements of a <tt>constexpr</tt> c'tor because they have a
9714 non-empty c'tor body that typically contains for-loops or <tt>memcpy</tt> to compute the
9715 initialisation. What have I overlooked here?
9716 </li>
9717 </ol>
9718
9719 <p><i>[
9720 Sophia Antipolis:
9721 ]</i></p>
9722
9723
9724 <blockquote>
9725 <p>
9726 We handle this as two parts
9727 </p>
9728 <ol>
9729 <li>
9730 The proposed resolution is correct; move to ready.
9731 </li>
9732 <li>
9733 The issue points out a real problem, but the issue is larger than just
9734 this solution. We believe a paper is needed, applying the full new
9735 features of C++ (including extensible literals) to update <tt>std::bitset</tt>.
9736 We note that we do not consider this new work, and that is should be
9737 handled by the Library Working Group.
9738 </li>
9739 </ol>
9740 <p>
9741 In order to have a consistent working paper, Alisdair and Daniel produced a new wording for the resolution.
9742 </p>
9743 </blockquote>
9744
9745
9746
9747 <p><b>Proposed resolution:</b></p>
9748 <ol>
9749 <li>
9750 <p>In the class template definition of 23.2.1 [array]/p. 3 change</p>
9751 <blockquote><pre><ins>constexpr</ins> bool empty() const;
9752 </pre></blockquote>
9753 </li>
9754
9755 <li>
9756 <p>In the class template definition of 23.3.5 [template.bitset]/p. 1 change</p>
9757 <blockquote><pre><ins>constexpr</ins> bool test(size_t pos ) const;
9758 </pre></blockquote>
9759
9760 <p>
9761 and in 23.3.5.2 [bitset.members] change
9762 </p>
9763
9764 <blockquote><pre><ins>constexpr</ins> bool test(size_t pos ) const;
9765 </pre></blockquote>
9766
9767 </li>
9768 </ol>
9769
9770
9771
9772
9773
9774 <hr>
9775 <h3><a name="721"></a>721. <tt>wstring_convert</tt> inconsistensies</h3>
9776 <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>
9777  <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-27</p>
9778 <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>
9779 <p><b>Discussion:</b></p>
9780 <p>
9781 Paragraph 3 says that the <tt>Codecvt</tt> template parameter shall meet the
9782 requirements of <tt>std::codecvt</tt>, even though <tt>std::codecvt</tt> itself cannot
9783 be used (because of a protected destructor).
9784 </p>
9785
9786 <p>
9787 How are we going to explain this code to beginning programmers?
9788 </p>
9789
9790 <blockquote><pre>template&lt;class I, class E, class S&gt;
9791 struct codecvt : std::codecvt&lt;I, E, S&gt;
9792 {
9793     ~codecvt()
9794     { }
9795 };
9796
9797 void main()
9798 {
9799     std::wstring_convert&lt;codecvt&lt;wchar_t, char, std::mbstate_t&gt; &gt; compiles_ok;
9800
9801     std::wstring_convert&lt;std::codecvt&lt;wchar_t, char, std::mbstate_t&gt; &gt;   not_ok;
9802 }
9803 </pre></blockquote>
9804
9805
9806
9807 <p><b>Proposed resolution:</b></p>
9808 <p>
9809 </p>
9810
9811
9812
9813
9814
9815 <hr>
9816 <h3><a name="723"></a>723. <tt>basic_regex</tt> should be moveable</h3>
9817 <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#Open">Open</a>
9818  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-29</p>
9819 <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>
9820 <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>
9821 <p><b>Discussion:</b></p>
9822 <p>
9823 According to the current state of the standard draft, the class
9824 template <tt>basic_regex</tt>, as described in 28.8 [re.regex]/3, is
9825 neither <tt>MoveConstructible</tt> nor <tt>MoveAssignable</tt>.
9826 IMO it should be, because typical regex state machines tend
9827 to have a rather large data quantum and I have seen several
9828 use cases, where a factory function returns regex values,
9829 which would take advantage of moveabilities.
9830 </p>
9831
9832 <p><i>[
9833 Sophia Antipolis:
9834 ]</i></p>
9835
9836
9837 <blockquote>
9838 Needs wording for the semantics, the idea is agreed upon.
9839 </blockquote>
9840
9841
9842 <p><b>Proposed resolution:</b></p>
9843 <ol type="a">
9844 <li>
9845 <p>
9846 In the header <tt>&lt;regex&gt;</tt> synopsis 28.4 [re.syn], just below the function
9847 template <tt>swap</tt> add two further overloads:
9848 </p>
9849 <blockquote><pre>template &lt;class charT, class traits&gt;
9850   void swap(basic_regex&lt;charT, traits&gt;&amp; e1,  basic_regex&lt;charT, traits&gt;&amp; e2);
9851 <ins>template &lt;class charT, class traits&gt;
9852   void swap(basic_regex&lt;charT, traits&gt;&amp;&amp; e1, basic_regex&lt;charT, traits&gt;&amp; e2);
9853 template &lt;class charT, class traits&gt;
9854   void swap(basic_regex&lt;charT, traits&gt;&amp; e1,  basic_regex&lt;charT, traits&gt;&amp;&amp; e2);</ins>
9855 </pre></blockquote>
9856 <p>
9857 In the class definition of <tt>basic_regex</tt>, just below 28.8 [re.regex]/3,
9858 perform the following changes:
9859 </p>
9860 </li>
9861
9862 <li>
9863 <p>Just after the copy c'tor:</p>
9864 <blockquote><pre>basic_regex(basic_regex&amp;&amp;);
9865 </pre></blockquote>
9866 </li>
9867
9868 <li>
9869 <p>Just after the copy-assignment op.:</p>
9870 <blockquote><pre>basic_regex&amp; operator=(basic_regex&amp;&amp;);
9871 </pre></blockquote>
9872 </li>
9873
9874 <li>
9875 <p>Just after the first <tt>assign</tt> overload insert:</p>
9876 <blockquote><pre>basic_regex&amp; assign(basic_regex&amp;&amp; that);
9877 </pre></blockquote>
9878 </li>
9879
9880 <li>
9881 <p>Change the current <tt>swap</tt> function to read:</p>
9882 <blockquote><pre>void swap(basic_regex&amp;&amp;);
9883 </pre></blockquote>
9884 </li>
9885
9886 <li>
9887 <p>In 28.8.2 [re.regex.construct], just below the copy c'tor add a
9888 corresponding member definition of:</p>
9889 <blockquote><pre>basic_regex(basic_regex&amp;&amp;);
9890 </pre></blockquote>
9891 </li>
9892
9893 <li>
9894 <p>Also in 28.8.2 [re.regex.construct], just below the copy assignment
9895 c'tor add a corresponding member definition of:</p>
9896 <blockquote><pre>basic_regex&amp; operator=(basic_regex&amp;&amp;);
9897 </pre></blockquote>
9898 </li>
9899
9900 <li>
9901 <p>In 28.8.3 [re.regex.assign], just below the first <tt>assign</tt> overload add
9902 a corresponding member definition of:</p>
9903 <blockquote><pre>basic_regex&amp; assign(basic_regex&amp;&amp; that);
9904 </pre></blockquote>
9905 </li>
9906
9907 <li>
9908 <p>In 28.8.6 [re.regex.swap], change the signature of <tt>swap</tt> to
9909 say:</p>
9910 <blockquote><pre>void swap(basic_regex&amp;&amp; e);
9911 </pre></blockquote>
9912 </li>
9913
9914 <li>
9915 <p>In 28.8.7.1 [re.regex.nmswap], just below the single binary <tt>swap</tt>
9916 function, add the two missing overloads:</p>
9917 <blockquote><pre>template &lt;class charT, class traits&gt;
9918   void swap(basic_regex&lt;charT, traits&gt;&amp;&amp; e1, basic_regex&lt;charT, traits&gt;&amp; e2);
9919 template &lt;class charT, class traits&gt;
9920   void swap(basic_regex&lt;charT, traits&gt;&amp; e1, basic_regex&lt;charT, traits&gt;&amp;&amp; e2);
9921 </pre></blockquote>
9922 </li>
9923 </ol>
9924
9925 <p>
9926 Of course there would be need of corresponding proper standardese
9927 to describe these additions.
9928 </p>
9929
9930
9931
9932
9933
9934
9935 <hr>
9936 <h3><a name="724"></a>724. <tt>DefaultConstructible</tt> is not defined</h3>
9937 <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>
9938  <b>Submitter:</b> Pablo Halpern <b>Date:</b> 2007-09-12</p>
9939 <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>
9940 <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>
9941 <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>
9942 <p><b>Discussion:</b></p>
9943 <p>
9944 The <tt>DefaultConstructible</tt> requirement is referenced in
9945 several places in the August 2007 working draft
9946 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2369.pdf">N2369</a>,
9947 but is not defined anywhere.
9948 </p>
9949
9950 <p><i>[
9951 Bellevue:
9952 ]</i></p>
9953
9954
9955 <blockquote>
9956 <p>
9957 Walking into the default/value-initialization mess...
9958 </p>
9959 <p>
9960 Why two lines? Because we need both expressions to be valid.
9961 </p>
9962 <p>
9963 AJM not sure what the phrase "default constructed" means. This is
9964 unfortunate, as the phrase is already used 24 times in the library!
9965 </p>
9966 <p>
9967 Example: const int would not accept first line, but will accept the second.
9968 </p>
9969 <p>
9970 This is an issue that must be solved by concepts, but we might need to solve it independantly first.
9971 </p>
9972 <p>
9973 It seems that the requirements are the syntax in the proposed first
9974 column is valid, but not clear what semantics we need.
9975 </p>
9976 <p>
9977 A table where there is no post-condition seems odd, but appears to sum up our position best.
9978 </p>
9979 <p>
9980 At a minimum an object is declared and is destuctible.
9981 </p>
9982 <p>
9983 Move to open, as no-one happy to produce wording on the fly.
9984 </p>
9985 </blockquote>
9986
9987
9988 <p><b>Proposed resolution:</b></p>
9989 <p>
9990 In section 20.1.1 [utility.arg.requirements], before table 33, add the
9991 following table:
9992 </p>
9993
9994 <p style="text-align: center;" align="center">Table 33: <tt>DefaultConstructible</tt> requirements</p>
9995
9996 <div align="center">
9997
9998 <table style="border-collapse: collapse;" border="0" cellpadding="0" cellspacing="0">
9999  <tbody><tr>
10000   <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">
10001   <p style="margin: 0in 0in 0.0001pt; text-align: center;" align="center">expression</p>
10002   </td>
10003   <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">
10004   <p style="margin: 0in 0in 0.0001pt; text-align: center;" align="center">post-condition</p>
10005   </td>
10006  </tr>
10007  <tr>
10008   <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">
10009   <p style="margin: 0in 0in 0.0001pt;"><tt>T
10010   t;</tt><br>
10011   <tt>T()</tt></p>
10012   </td>
10013   <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">
10014   <p style="margin: 0in 0in 0.0001pt;"><tt>T</tt>
10015   is <i>default constructed.</i></p>
10016   </td>
10017  </tr>
10018 </tbody></table>
10019
10020 </div>
10021
10022
10023
10024
10025
10026
10027 <hr>
10028 <h3><a name="726"></a>726. Missing <tt>regex_replace()</tt> overloads</h3>
10029 <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#Open">Open</a>
10030  <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2007-09-22</p>
10031 <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>
10032 <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>
10033 <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>
10034 <p><b>Discussion:</b></p>
10035 <p>
10036 Two overloads of <tt>regex_replace()</tt> are currently provided:
10037 </p>
10038
10039 <blockquote><pre>template &lt;class OutputIterator, class BidirectionalIterator,
10040     class traits, class charT&gt;
10041   OutputIterator
10042   regex_replace(OutputIterator out,
10043                 BidirectionalIterator first, BidirectionalIterator last,
10044                 const basic_regex&lt;charT, traits&gt;&amp; e,
10045                 const basic_string&lt;charT&gt;&amp; fmt,
10046                 regex_constants::match_flag_type flags =
10047                   regex_constants::match_default);
10048
10049 template &lt;class traits, class charT&gt;
10050   basic_string&lt;charT&gt;
10051   regex_replace(const basic_string&lt;charT&gt;&amp; s,
10052                 const basic_regex&lt;charT, traits&gt;&amp; e,
10053                 const basic_string&lt;charT&gt;&amp; fmt,
10054                 regex_constants::match_flag_type flags =
10055                   regex_constants::match_default);
10056 </pre></blockquote>
10057
10058 <ol>
10059 <li>Overloads taking <tt>const charT *</tt> are provided for <tt>regex_match()</tt> and
10060 <tt>regex_search()</tt>, but not <tt>regex_replace()</tt>.  This is inconsistent.</li>
10061 <li>
10062 <p>The absence of <tt>const charT *</tt> overloads prevents ordinary-looking code from compiling, such as:</p>
10063
10064 <blockquote><pre>const string s("kitten");
10065 const regex r("en");
10066 cout &lt;&lt; regex_replace(s, r, "y") &lt;&lt; endl;
10067 </pre></blockquote>
10068
10069 <p>
10070 The compiler error message will be something like "could not deduce
10071 template argument for 'const std::basic_string&lt;_Elem&gt; &amp;' from 'const
10072 char[1]'".
10073 </p>
10074
10075 <p>
10076 Users expect that anything taking a <tt>basic_string&lt;charT&gt;</tt> can also take a
10077 <tt>const charT *</tt>.  In their own code, when they write a function taking
10078 <tt>std::string</tt> (or <tt>std::wstring</tt>), they can pass a <tt>const char *</tt> (or <tt>const
10079 wchar_t *</tt>), thanks to <tt>basic_string</tt>'s implicit constructor.  Because the
10080 regex algorithms are templated on <tt>charT</tt>, they can't rely on
10081 <tt>basic_string</tt>'s implicit constructor (as the compiler error message
10082 indicates, template argument deduction fails first).
10083 </p>
10084
10085 <p>
10086 If a user figures out what the compiler error message means, workarounds
10087 are available - but they are all verbose.  Explicit template arguments
10088 could be given to <tt>regex_replace()</tt>, allowing <tt>basic_string</tt>'s implicit
10089 constructor to be invoked - but <tt>charT</tt> is the last template argument, not
10090 the first, so this would be extremely verbose.  Therefore, constructing
10091 a <tt>basic_string</tt> from each C string is the simplest workaround.
10092 </p>
10093 </li>
10094
10095 <li>
10096 There is an efficiency consideration: constructing <tt>basic_string</tt>s can
10097 impose performance costs that could be avoided by a library
10098 implementation taking C strings and dealing with them directly.
10099 (Currently, for replacement sources, C strings can be converted into
10100 iterator pairs at the cost of verbosity, but for format strings, there
10101 is no way to avoid constructing a <tt>basic_string</tt>.)
10102 </li>
10103 </ol>
10104
10105 <p><i>[
10106 Sophia Antipolis:
10107 ]</i></p>
10108
10109
10110 <blockquote>
10111 We note that Boost already has these overloads. However, the proposed
10112 wording is provided only for 28.11.4 [re.alg.replace]; wording is needed for the synopsis
10113 as well. We also note that this has impact on <tt>match_results::format</tt>,
10114 which may require further overloads.
10115 </blockquote>
10116
10117
10118
10119 <p><b>Proposed resolution:</b></p>
10120 <p>
10121 Provide additional overloads for <tt>regex_replace()</tt>: one additional
10122 overload of the iterator-based form (taking <tt>const charT* fmt</tt>), and three
10123 additional overloads of the convenience form (one taking <tt>const charT*
10124 str</tt>, another taking <tt>const charT* fmt</tt>, and the third taking both <tt>const
10125 charT* str</tt> and <tt>const charT* fmt</tt>).  28.11.4 [re.alg.replace]:
10126 </p>
10127
10128 <blockquote>
10129 <pre>template &lt;class OutputIterator, class BidirectionalIterator,
10130     class traits, class charT&gt;
10131   OutputIterator
10132   regex_replace(OutputIterator out,
10133                 BidirectionalIterator first, BidirectionalIterator last,
10134                 const basic_regex&lt;charT, traits&gt;&amp; e,
10135                 const basic_string&lt;charT&gt;&amp; fmt,
10136                 regex_constants::match_flag_type flags =
10137                   regex_constants::match_default);
10138
10139 <ins>template &lt;class OutputIterator, class BidirectionalIterator,
10140     class traits, class charT&gt;
10141   OutputIterator
10142   regex_replace(OutputIterator out,
10143                 BidirectionalIterator first, BidirectionalIterator last,
10144                 const basic_regex&lt;charT, traits&gt;&amp; e,
10145                 const charT* fmt,
10146                 regex_constants::match_flag_type flags =
10147                   regex_constants::match_default);</ins>
10148 </pre>
10149 <p>...</p>
10150 <pre>template &lt;class traits, class charT&gt;
10151   basic_string&lt;charT&gt;
10152   regex_replace(const basic_string&lt;charT&gt;&amp; s,
10153                 const basic_regex&lt;charT, traits&gt;&amp; e,
10154                 const basic_string&lt;charT&gt;&amp; fmt,
10155                 regex_constants::match_flag_type flags =
10156                   regex_constants::match_default);
10157
10158 <ins>template &lt;class traits, class charT&gt;
10159   basic_string&lt;charT&gt;
10160   regex_replace(const basic_string&lt;charT&gt;&amp; s,
10161                 const basic_regex&lt;charT, traits&gt;&amp; e,
10162                 const charT* fmt,
10163                 regex_constants::match_flag_type flags =
10164                   regex_constants::match_default);</ins>
10165
10166 <ins>template &lt;class traits, class charT&gt;
10167   basic_string&lt;charT&gt;
10168   regex_replace(const charT* s,
10169                 const basic_regex&lt;charT, traits&gt;&amp; e,
10170                 const basic_string&lt;charT&gt;&amp; fmt,
10171                 regex_constants::match_flag_type flags =
10172                   regex_constants::match_default);</ins>
10173
10174 <ins>template &lt;class traits, class charT&gt;
10175   basic_string&lt;charT&gt;
10176   regex_replace(const charT* s,
10177                 const basic_regex&lt;charT, traits&gt;&amp; e,
10178                 const charT* fmt,
10179                 regex_constants::match_flag_type flags =
10180                   regex_constants::match_default);</ins>
10181 </pre>
10182 </blockquote>
10183
10184
10185
10186
10187
10188
10189 <hr>
10190 <h3><a name="727"></a>727. <tt>regex_replace()</tt> doesn't accept <tt>basic_string</tt>s with custom traits and allocators</h3>
10191 <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>
10192  <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2007-09-22</p>
10193 <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>
10194 <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>
10195 <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>
10196 <p><b>Discussion:</b></p>
10197 <p>
10198 <tt>regex_match()</tt> and <tt>regex_search()</tt> take <tt>const basic_string&lt;charT, ST,
10199 SA&gt;&amp;</tt>.  <tt>regex_replace()</tt> takes <tt>const basic_string&lt;charT&gt;&amp;</tt>.  This prevents
10200 <tt>regex_replace()</tt> from accepting <tt>basic_string</tt>s with custom traits and
10201 allocators.
10202 </p>
10203
10204
10205 <p><b>Proposed resolution:</b></p>
10206 <p>
10207 Overloads of <tt>regex_replace()</tt> taking <tt>basic_string</tt> should be additionally
10208 templated on <tt>class ST, class SA</tt> and take <tt>const basic_string&lt;charT, ST,
10209 SA&gt;&amp;</tt>.  Consistency with <tt>regex_match()</tt> and <tt>regex_search()</tt> would place
10210 <tt>class ST, class SA</tt> as the first template arguments; compatibility with
10211 existing code using TR1 and giving explicit template arguments to
10212 <tt>regex_replace()</tt> would place <tt>class ST, class SA</tt> as the last template
10213 arguments.
10214 </p>
10215
10216
10217
10218
10219
10220 <hr>
10221 <h3><a name="728"></a>728. Problem in [rand.eng.mers]/6</h3>
10222 <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#Ready">Ready</a>
10223  <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
10224 <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>
10225 <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>
10226 <p><b>Discussion:</b></p>
10227 <p>
10228 The <tt>mersenne_twister_engine</tt> is required to use a seeding method that is given
10229 as an algorithm parameterized over the number of bits <tt>W</tt>. I doubt whether the given generalization
10230 of an algorithm that was originally developed only for unsigned 32-bit integers is appropriate
10231 for other bit widths. For instance, <tt>W</tt> could be theoretically 16 and <tt>UIntType</tt> a 16-bit integer, in
10232 which case the given multiplier would not fit into the <tt>UIntType</tt>. Moreover, T. Nishimura and M.
10233 Matsumoto have chosen a dif ferent multiplier for their 64 bit Mersenne Twister
10234 [<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/VERSIONS/C-LANG/mt19937-64.c">reference</a>].
10235 </p>
10236
10237 <p>
10238 I see two possible resolutions:
10239 </p>
10240
10241 <ol type="a">
10242 <li>Restrict the parameter <tt>W</tt> of the <tt>mersenne_twister_template</tt> to values of 32 or 64 and use the
10243 multiplier from [the above reference] for the 64-bit case (my preference)</li>
10244 <li>Interpret the state array for any <tt>W</tt> as a 32-bit array of appropriate length (and a specified byte
10245 order) and always employ the 32-bit algorithm for seeding
10246 </li>
10247 </ol>
10248
10249 <p>
10250 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
10251 for further discussion.
10252 </p>
10253
10254 <p><i>[
10255 Bellevue:
10256 ]</i></p>
10257
10258
10259 <blockquote>
10260 <p>
10261 Stephan Tolksdorf has additional comments on N2424. He comments: "there
10262 is a typo in the required behaviour for mt19937_64: It should be the
10263 10000th (not 100000th) invocation whose value is given, and the value
10264 should be 9981545732273789042 (not 14002232017267485025)." These values
10265 need checking.
10266 </p>
10267 <p>
10268 Take the proposed recommendation in N2424 and move to REVIEW.
10269 </p>
10270 </blockquote>
10271
10272
10273
10274
10275 <p><b>Proposed resolution:</b></p>
10276
10277 <p>
10278 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
10279 for the proposed resolution.
10280 </p>
10281
10282 <p><i>[
10283 Stephan Tolksdorf adds pre-Bellevue:
10284 ]</i></p>
10285
10286
10287 <blockquote>
10288 I support the proposed resolution in
10289 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>,
10290 but there is a typo in the
10291 required behaviour for <tt>mt19937_64</tt>: It should be the 10000<sup>th</sup> (not
10292 100000<sup>th</sup>) invocation whose value is given, and the value should be
10293 9981545732273789042 (not 14002232017267485025). The change to para. 8
10294 proposed by Charles Karney should also be included in the proposed
10295 wording.
10296 </blockquote>
10297
10298 <p><i>[
10299 Sophia Antipolis:
10300 ]</i></p>
10301
10302
10303 <blockquote>
10304 Note the main part of the issue is resolved by
10305 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>.
10306 </blockquote>
10307
10308
10309
10310
10311
10312
10313 <hr>
10314 <h3><a name="732"></a>732. Defect in [rand.dist.samp.genpdf]</h3>
10315 <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>
10316  <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
10317 <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>
10318 <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>
10319 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a></p>
10320 <p><b>Discussion:</b></p>
10321 <p>
10322 26.4.8.5.3 [rand.dist.samp.genpdf] describes the interface for a distribution template that is
10323 meant to simulate random numbers from any general distribution given only the density and the
10324 support of the distribution. I'm not aware of any general purpose algorithm that would be capable
10325 of correctly and efficiently implementing the described functionality. From what I know, this is
10326 essentially an unsolved research problem. Existing algorithms either require more knowledge
10327 about the distribution and the problem domain or work only under very limited circumstances.
10328 Even the state of the art special purpose library UNU.RAN does not solve the problem in full
10329 generality, and in any case, testing and customer support for such a library feature would be a
10330 nightmare.
10331 </p>
10332
10333 <p>
10334 <b>Possible resolution:</b> For these reasons, I propose to delete section 26.4.8.5.3 [rand.dist.samp.genpdf].
10335 </p>
10336
10337 <p><i>[
10338 Bellevue:
10339 ]</i></p>
10340
10341
10342 <blockquote>
10343 <p>
10344 Disagreement persists.
10345 </p>
10346 <p>
10347 Objection to this issue is that this function takes a general functor.
10348 The general approach would be to normalize this function, integrate it,
10349 and take the inverse of the integral, which is not possible in general.
10350 An example function is sin(1+n*x) -- for any spatial frequency that the
10351 implementor chooses, there is a value of n that renders that choice
10352 arbitrarily erroneous.
10353 </p>
10354 <p>
10355 Correction: The formula above should instead read 1+sin(n*x).
10356 </p>
10357 <p>
10358 Objector proposes the following possible compromise positions:
10359 </p>
10360 <ul>
10361 <li>
10362 rand.dist.samp.genpdf takes an number of points so that implementor need not guess.
10363 </li>
10364 <li>replace rand.disk.samp.genpdf with an extension to either or both
10365 of the discrete functions to take arguments that take a functor and
10366 number of points in place of the list of probabilities. Reference
10367 issues 793 and 794.
10368 </li>
10369 </ul>
10370 </blockquote>
10371
10372
10373
10374 <p><b>Proposed resolution:</b></p>
10375 <p>
10376 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
10377 for the proposed resolution.
10378 </p>
10379
10380
10381
10382
10383
10384 <hr>
10385 <h3><a name="734"></a>734. Unnecessary restriction in [rand.dist.norm.chisq]</h3>
10386 <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#Review">Review</a>
10387  <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
10388 <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>
10389 <p><b>Discussion:</b></p>
10390 <p>
10391 <tt>chi_squared_distribution</tt>, <tt>fisher_f_distribution</tt> and <tt>student_t_distribution</tt>
10392 have parameters for the "degrees of freedom" <tt>n</tt> and <tt>m</tt> that are specified as integers. For the
10393 following two reasons this is an unnecessary restriction: First, in many applications such as
10394 Bayesian inference or Monte Carlo simulations it is more convenient to treat the respective param-
10395 eters as continuous variables. Second, the standard non-naive algorithms (i.e.
10396 O(1) algorithms)
10397 for simulating from these distributions work with floating-point parameters anyway (all three
10398 distributions could be easily implemented using the Gamma distribution, for instance).
10399 </p>
10400
10401 <p>
10402 Similar arguments could in principle be made for the parameters <tt>t</tt> and <tt>k</tt> of the discrete
10403 <tt>binomial_distribution</tt> and <tt>negative_binomial_distribution</tt>, though in both cases continuous
10404 parameters are less frequently used in practice and in case of the <tt>binomial_distribution</tt>
10405 the implementation would be significantly complicated by a non-discrete parameter (in most
10406 implementations one would need an approximation of the log-gamma function instead of just the
10407 log-factorial function).
10408 </p>
10409
10410 <p>
10411 <b>Possible resolution:</b> For these reasons, I propose to change the type of the respective parameters
10412 to double.
10413 </p>
10414
10415 <p><i>[
10416 Bellevue:
10417 ]</i></p>
10418
10419
10420 <blockquote>
10421 In N2424. Not wildly enthusiastic, not really felt necessary. Less
10422 frequently used in practice. Not terribly bad either. Move to OPEN.
10423 </blockquote>
10424
10425 <p><i>[
10426 Sophia Antipolis:
10427 ]</i></p>
10428
10429
10430 <blockquote>
10431 <p>
10432 Marc Paterno: The generalizations were explicitly left out when designing the facility. It's harder to test.
10433 </p>
10434 <p>
10435 Marc Paterno: Ask implementers whether floating-point is a significant burden.
10436 </p>
10437 <p>
10438 Alisdair: It's neater to do it now, do ask Bill Plauger.
10439 </p>
10440 <p>
10441 Disposition: move to review with the option for "NAD" if it's not straightforward to implement; unanimous consent.
10442 </p>
10443 </blockquote>
10444
10445
10446
10447 <p><b>Proposed resolution:</b></p>
10448 <p>
10449 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
10450 for the proposed resolution.
10451 </p>
10452
10453 <p><i>[
10454 Stephan Tolksdorf adds pre-Bellevue:
10455 ]</i></p>
10456
10457
10458 <blockquote>
10459 <p>
10460 In 26.4.8.4.3 [rand.dist.norm.chisq]:
10461 </p>
10462
10463 <blockquote>
10464 <p>
10465 Delete ", where <tt>n</tt> is a positive integer" in the first paragraph.
10466 </p>
10467
10468 <p>
10469 Replace both occurrences of "<tt>explicit chi_squared_distribution(int n = 1);</tt>"
10470 with "<tt>explicit chi_squared_distribution(RealType n = 1);</tt>".
10471 </p>
10472
10473 <p>
10474 Replace both occurrences of "<tt>int n() const;</tt>" with "<tt>RealType n() const;</tt>".
10475 </p>
10476
10477 </blockquote>
10478
10479 <p>
10480 In 26.4.8.4.5 [rand.dist.norm.f]:
10481 </p>
10482 <blockquote>
10483 <p>
10484 Delete ", where <tt>m</tt> and <tt>n</tt> are positive integers" in the first paragraph.
10485 </p>
10486
10487 <p>
10488 Replace both occurrences of
10489 </p>
10490 <blockquote><pre>explicit fisher_f_distribution(int m = 1, int n = 1);
10491 </pre></blockquote>
10492 <p>
10493 with
10494 </p>
10495 <blockquote><pre>explicit fisher_f_distribution(RealType m = 1, RealType n = 1);
10496 </pre></blockquote>
10497
10498 <p>
10499 Replace both occurrences of "<tt>int m() const;" with "RealType m() const;</tt>".
10500 </p>
10501
10502 <p>
10503 Replace both occurrences of "<tt>int n() const;" with "RealType n() const;</tt>".
10504 </p>
10505 </blockquote>
10506
10507 <p>
10508 In 26.4.8.4.6 [rand.dist.norm.t]:
10509 </p>
10510
10511 <blockquote>
10512 <p>
10513 Delete ", where <tt>n</tt> is a positive integer" in the first paragraph.
10514 </p>
10515
10516 <p>
10517 Replace both occurrences of "<tt>explicit student_t_distribution(int n = 1);</tt>"
10518 with "<tt>explicit student_t_distribution(RealType n = 1);</tt>".
10519 </p>
10520
10521 <p>
10522 Replace both occurrences of "<tt>int n() const;</tt>" with "<tt>RealType n() const;</tt>".
10523 </p>
10524 </blockquote>
10525
10526 </blockquote>
10527
10528
10529
10530
10531
10532 <hr>
10533 <h3><a name="742"></a>742. Enabling <tt>swap</tt> for proxy iterators</h3>
10534 <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>
10535  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-10-10</p>
10536 <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>
10537 <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>
10538 <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>
10539 <p><b>Discussion:</b></p>
10540 <p>
10541 This issue was split from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>. <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a> now just
10542 deals with changing the requirements of <tt>T</tt> in the <tt>Swappable</tt>
10543 requirement from <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt> to
10544 <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.
10545 </p>
10546
10547 <p>
10548 This issue seeks to widen the <tt>Swappable</tt> requirement to support proxy iterators.  Here
10549 is example code:
10550 </p>
10551
10552 <blockquote><pre>namespace Mine {
10553
10554 template &lt;class T&gt;
10555 struct proxy {...};
10556
10557 template &lt;class T&gt;
10558 struct proxied_iterator
10559 {
10560    typedef T value_type;
10561    typedef proxy&lt;T&gt; reference;
10562    reference operator*() const;
10563    ...
10564 };
10565
10566 struct A
10567 {
10568    // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
10569    void swap(A&amp;);
10570    ...
10571 };
10572
10573 void swap(A&amp;, A&amp;);
10574 void swap(proxy&lt;A&gt;, A&amp;);
10575 void swap(A&amp;, proxy&lt;A&gt;);
10576 void swap(proxy&lt;A&gt;, proxy&lt;A&gt;);
10577
10578 }  // Mine
10579
10580 ...
10581
10582 Mine::proxied_iterator&lt;Mine::A&gt; i(...)
10583 Mine::A a;
10584 <b>swap(*i1, a);</b>
10585 </pre></blockquote>
10586
10587 <p>
10588 The key point to note in the above code is that in the call to <tt>swap</tt>, <tt>*i1</tt>
10589 and <tt>a</tt> are different types (currently types can only be <tt>Swappable</tt> with the
10590 same type).  A secondary point is that to support proxies, one must be able to pass rvalues
10591 to <tt>swap</tt>.  But note that I am not stating that the general purpose <tt>std::swap</tt>
10592 should accept rvalues!  Only that overloaded <tt>swap</tt>s, as in the example above, be allowed
10593 to take rvalues.
10594 </p>
10595
10596 <p>
10597 That is, no standard library code needs to change.  We simply need to have a more flexible
10598 definition of <tt>Swappable</tt>.
10599 </p>
10600
10601 <p><i>[
10602 Bellevue:
10603 ]</i></p>
10604
10605
10606 <blockquote>
10607 <p>
10608 While we believe Concepts work will define a swappable concept, we
10609 should still resolve this issue if possible to give guidance to the
10610 Concepts work.
10611 </p>
10612 <p>
10613 Would an ambiguous swap function in two namespaces found by ADL break
10614 this wording? Suggest that the phrase "valid expression" means such a
10615 pair of types would still not be swappable.
10616 </p>
10617 <p>
10618 Motivation is proxy-iterators, but facility is considerably more
10619 general. Are we happy going so far?
10620 </p>
10621 <p>
10622 We think this wording is probably correct and probably an improvement on
10623 what's there in the WP. On the other hand, what's already there in the
10624 WP is awfully complicated. Why do we need the two bullet points? They're
10625 too implementation-centric. They don't add anything to the semantics of
10626 what swap() means, which is there in the post-condition. What's wrong
10627 with saying that types are swappable if you can call swap() and it
10628 satisfies the semantics of swapping?
10629 </p>
10630 </blockquote>
10631
10632
10633
10634 <p><b>Proposed resolution:</b></p>
10635 <p>
10636 Change 20.1.1 [utility.arg.requirements]:
10637 </p>
10638
10639 <blockquote>
10640
10641 <p>
10642 -1- The template definitions in the C++ Standard Library refer to various
10643 named requirements whose details are set out in tables 31-38. In these
10644 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
10645 instantiating a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
10646 values of type <tt>const T</tt>; <tt>s</tt> and <tt>t</tt> are modifiable
10647 lvalues of type <tt>T</tt>; <tt>u</tt> is a value of type (possibly
10648 <tt>const</tt>) <tt>T</tt>; <del>and</del> <tt>rv</tt> is a non-<tt>const</tt>
10649 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>.
10650 </p>
10651
10652 <table border="1">
10653 <caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
10654 <tbody><tr><th>expression</th><th>return type</th><th>post-condition</th></tr>
10655 <tr><td><tt>swap(<del>s</del><ins>w</ins>,<del>t</del><ins>v</ins>)</tt></td><td><tt>void</tt></td>
10656 <td><del><tt>t</tt></del><ins><tt>w</tt></ins> has the value originally
10657 held by <del><tt>u</tt></del><ins><tt>v</tt></ins>, and
10658 <del><tt>u</tt></del><ins><tt>v</tt></ins> has the value originally held
10659 by <del><tt>t</tt></del><ins><tt>w</tt></ins></td></tr>
10660 <tr><td colspan="3">
10661 <p>
10662 The <tt>Swappable</tt> requirement is met by satisfying one or more of the following conditions:
10663 </p>
10664 <ul>
10665 <li>
10666 <tt>T</tt> is <tt>Swappable</tt> if <ins><tt>T</tt> and <tt>V</tt> are
10667 the same type and </ins> <tt>T</tt> satisfies the
10668 <del><tt>CopyConstructible</tt></del>
10669 <ins><tt>MoveConstructible</tt></ins> requirements (Table <del>34</del>
10670 <ins>33</ins>) and the <del><tt>CopyAssignable</tt></del>
10671 <ins><tt>MoveAssignable</tt></ins> requirements (Table <del>36</del>
10672 <ins>35</ins>);
10673 </li>
10674 <li>
10675 <tt>T</tt> is <tt>Swappable</tt> <ins>with <tt>V</tt></ins> if a namespace scope function named
10676 <tt>swap</tt> exists in the same namespace as the definition of
10677 <tt>T</tt> <ins>or <tt>V</tt></ins>, such that the expression
10678 <tt>swap(<del>t</del><ins>w</ins>,<del>u</del> <ins>v</ins>)</tt> is valid and has the
10679 semantics described in this table.
10680 </li>
10681 </ul>
10682 </td></tr>
10683 </tbody></table>
10684 </blockquote>
10685
10686
10687
10688
10689
10690
10691 <hr>
10692 <h3><a name="747"></a>747. We have 3 separate type traits to identify classes supporting no-throw operations</h3>
10693 <p><b>Section:</b> 20.5.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>
10694  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
10695 <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>
10696 <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>
10697 <p><b>Discussion:</b></p>
10698 <p>
10699 We have 3 separate type traits to identify classes supporting no-throw
10700 operations, which are very useful when trying to provide exception safety
10701 guarantees.  However, I'm not entirely clear on what the current wording
10702 requires of a conforming implementation.  To quote from
10703 <tt>has_nothrow_default_constructor</tt>:
10704 </p>
10705 <blockquote><p>
10706 or <tt>T</tt> is a class type with a default constructor that is known not to throw
10707 any exceptions
10708 </p></blockquote>
10709 <p>
10710 What level of magic do we expect to deduce if this is known?
10711 </p>
10712 <p>
10713 E.g.
10714 </p>
10715
10716 <blockquote><pre>struct test{
10717  int x;
10718  test() : x() {}
10719 };
10720 </pre></blockquote>
10721 <p>
10722 Should I expect a conforming compiler to
10723  <tt>assert( has_nothrow_constructor&lt;test&gt;::value )</tt>
10724 </p>
10725 <p>
10726 Is this a QoI issue?
10727 </p>
10728 <p>
10729 Should I expect to 'know' only if-and-only-if there is an inline definition
10730 available?
10731 </p>
10732 <p>
10733 Should I never expect that to be true, and insist that the user supplies an
10734 empty throw spec if they want to assert the no-throw guarantee?
10735 </p>
10736 <p>
10737 It would be helpful to maybe have a footnote explaining what is required,
10738 but right now I don't know what to suggest putting in the footnote.
10739 </p>
10740 <p>
10741 (agreement since is that trivial ops and explicit no-throws are required.
10742 Open if QoI should be allowed to detect further)
10743 </p>
10744
10745 <p><i>[
10746 Bellevue:
10747 ]</i></p>
10748
10749
10750 <blockquote>
10751 This looks like a QoI issue.
10752 In the case of trivial and nothrow it is known. Static analysis of the program is definitely into QoI.
10753 Move to OPEN. Need to talk to Core about this.
10754 </blockquote>
10755
10756
10757 <p><b>Proposed resolution:</b></p>
10758 <p>
10759 </p>
10760
10761
10762
10763
10764
10765 <hr>
10766 <h3><a name="750"></a>750. The current definition for <tt>is_convertible</tt> requires that the type be
10767 implicitly convertible, so explicit constructors are ignored.</h3>
10768 <p><b>Section:</b> 20.5.5 [meta.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
10769  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
10770 <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>
10771 <p><b>Discussion:</b></p>
10772 <p>
10773 With the pending arrival of explicit conversion functions though, I'm
10774 wondering if we want an additional trait, <tt>is_explictly_convertible</tt>?
10775 </p>
10776
10777 <p><i>[
10778 Bellevue:
10779 ]</i></p>
10780
10781
10782 <blockquote>
10783 Alisdair is considering preparing a paper listing a number of missing
10784 type traits, and feels that it might be useful to handle them all
10785 together rather than piecemeal. This would affect issue 719 and 750.
10786 These two issues should move to OPEN pending AM paper on type traits.
10787 </blockquote>
10788
10789
10790 <p><b>Proposed resolution:</b></p>
10791 <p>
10792 </p>
10793
10794
10795
10796
10797
10798 <hr>
10799 <h3><a name="751"></a>751. change pass-by-reference members of <tt>vector&lt;bool&gt;</tt> to pass-by-value?</h3>
10800 <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>
10801  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
10802 <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>
10803 <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>
10804 <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>
10805 <p><b>Discussion:</b></p>
10806 <p>
10807 A number of vector&lt;bool&gt; members take const bool&amp; as arguments.
10808 Is there any chance we could change them to pass-by-value or would I
10809 be wasting everyone's time if wrote up an issue?
10810 </p>
10811
10812 <p><i>[
10813 post Bellevue:
10814 ]</i></p>
10815
10816
10817 <blockquote>
10818 <p>
10819 As we understand it, the original requester (Martin Sebor) would like
10820 for implementations to be permitted to pass-by-value. Alisdair suggests
10821 that if this is to be resolved, it should be resolved more generally,
10822 e.g. in other containers as well.
10823 </p>
10824 <p>
10825 We note that this would break ABI. However, we also suspect that this
10826 might be covered under the "as-if" rule in section 1.9.
10827 </p>
10828 <p>
10829 Many in the group feel that for vector&lt;bool&gt;, this is a "don't care",
10830 and that at this point in the process it's not worth the bandwidth.
10831 </p>
10832 <p>
10833 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
10834 now in the working paper -- is related to this, though not a duplicate.
10835 </p>
10836 <p>
10837 Moving to Open with a task for Alisdair to craft a informative note to
10838 be put whereever appropriate in the WP. This note would clarify places
10839 where pass-by-const-ref can be transformed to pass-by-value under the
10840 as-if rule.
10841 </p>
10842 </blockquote>
10843
10844
10845
10846 <p><b>Proposed resolution:</b></p>
10847 <p>
10848 </p>
10849
10850
10851
10852
10853
10854 <hr>
10855 <h3><a name="752"></a>752. Allocator complexity requirement</h3>
10856 <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#Review">Review</a>
10857  <b>Submitter:</b> Hans Boehm <b>Date:</b> 2007-10-11</p>
10858 <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>
10859 <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>
10860 <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>
10861 <p><b>Discussion:</b></p>
10862 <p>
10863 Did LWG recently discuss 20.1.2 [allocator.requirements]-2, which states that "All the operations
10864 on the allocators are expected to be amortized constant time."?
10865 </p>
10866 <p>
10867 As I think I pointed out earlier, this is currently fiction for
10868 <tt>allocate()</tt> if it has to obtain memory from the OS, and it's unclear to
10869 me how to interpret this for <tt>construct()</tt> and <tt>destroy()</tt> if they deal with
10870 large objects.  Would it be controversial to officially let these take
10871 time linear in the size of the object, as they already do in real life?
10872 </p>
10873 <p>
10874 <tt>Allocate()</tt> more blatantly takes time proportional to the size of the
10875 object if you mix in GC.  But it's not really a new problem, and I think
10876 we'd be confusing things by leaving the bogus requirements there.  The
10877 current requirement on <tt>allocate()</tt> is generally not important anyway,
10878 since it takes O(size) to construct objects in the resulting space.
10879 There are real performance issues here, but they're all concerned with
10880 the constants, not the asymptotic complexity.
10881 </p>
10882
10883
10884 <p><b>Proposed resolution:</b></p>
10885 <p>
10886 Change 20.1.2 [allocator.requirements]/2:
10887 </p>
10888
10889 <blockquote>
10890 <p>
10891 -2- Table 39 describes the requirements on types manipulated through
10892 allocators. <del>All the operations on the allocators are expected to be
10893 amortized constant time.</del> Table 40 describes the
10894 requirements on allocator types.
10895 </p>
10896 </blockquote>
10897
10898
10899
10900
10901
10902 <hr>
10903 <h3><a name="753"></a>753. Move constructor in draft</h3>
10904 <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>
10905  <b>Submitter:</b> Yechezkel Mett <b>Date:</b> 2007-10-14</p>
10906 <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>
10907 <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>
10908 <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>
10909 <p><b>Discussion:</b></p>
10910 <p>
10911 The draft standard n2369 uses the term <i>move constructor</i> in a few
10912 places, but doesn't seem to define it.
10913 </p>
10914
10915 <p>
10916 <tt>MoveConstructible</tt> requirements are defined in Table 33 in 20.1.1 [utility.arg.requirements] as
10917 follows:
10918 </p>
10919
10920 <blockquote>
10921 <table border="1">
10922 <caption><tt>MoveConstructible</tt> requirements</caption>
10923 <tbody><tr>
10924 <th>expression</th> <th>post-condition</th>
10925 </tr>
10926 <tr>
10927 <td><tt>T t = rv</tt></td> <td><tt>t</tt> is equivalent to the value of <tt>rv</tt> before the construction</td>
10928 </tr>
10929 <tr>
10930 <td colspan="2">[<i>Note:</i> There is no requirement on the value of <tt>rv</tt> after the
10931 construction. <i>-- end note</i>]</td>
10932 </tr>
10933 </tbody></table>
10934 </blockquote>
10935
10936 <p>
10937 (where <tt>rv</tt> is a non-const rvalue of type <tt>T</tt>).
10938 </p>
10939
10940 <p>
10941 So I assume the move constructor is the constructor that would be used
10942 in filling the above requirement.
10943 </p>
10944
10945 <p>
10946 For <tt>vector::reserve</tt>, <tt>vector::resize</tt> and the <tt>vector</tt> modifiers given in
10947 23.2.6.4 [vector.modifiers] we have
10948 </p>
10949
10950 <blockquote>
10951 <i>Requires:</i> If <tt>value_type</tt> has a move constructor, that constructor shall
10952 not throw any exceptions.
10953 </blockquote>
10954
10955 <p>
10956 Firstly "If <tt>value_type</tt> has a move constructor" is superfluous; every
10957 type which can be put into a <tt>vector</tt> has a move constructor (a copy
10958 constructor is also a move constructor). Secondly it means that for
10959 any <tt>value_type</tt> which has a throwing copy constructor and no other move
10960 constructor these functions cannot be used -- which I think will come
10961 as a shock to people who have been using such types in <tt>vector</tt> until
10962 now!
10963 </p>
10964
10965 <p>
10966 I can see two ways to correct this. The simpler, which is presumably
10967 what was intended, is to say "If <tt>value_type</tt> has a move constructor and
10968 no copy constructor, the move constructor shall not throw any
10969 exceptions" or "If <tt>value_type</tt> has a move constructor which changes the
10970 value of its parameter,".
10971 </p>
10972
10973 <p>
10974 The other alternative is add to <tt>MoveConstructible</tt> the requirement that
10975 the expression does not throw. This would mean that not every type
10976 that satisfies the <tt>CopyConstructible</tt> requirements also satisfies the
10977 <tt>MoveConstructible</tt> requirements. It would mean changing requirements in
10978 various places in the draft to allow either <tt>MoveConstructible</tt> or
10979 <tt>CopyConstructible</tt>, but I think the result would be clearer and
10980 possibly more concise too.
10981 </p>
10982
10983
10984 <p><b>Proposed resolution:</b></p>
10985 <p>
10986 Add new defintions to 17.1 [definitions]:
10987 </p>
10988
10989 <blockquote>
10990 <p>
10991 <b>move constructor</b>
10992 </p>
10993 <p>
10994 a constructor which accepts only rvalue arguments of that type, and modifies the rvalue as a
10995 side effect during the construction.
10996 </p>
10997 <p>
10998 <b>move assignment operator</b>
10999 </p>
11000 <p>
11001 an assignment operator which accepts only rvalue arguments of that type, and modifies the rvalue as a
11002 side effect during the assignment.
11003 </p>
11004 <p>
11005 <b>move assignment</b>
11006 </p>
11007 <p>
11008 use of the move assignment operator.
11009 </p>
11010 </blockquote>
11011
11012 <p><i>[
11013 Howard adds post-Bellevue:
11014 ]</i></p>
11015
11016
11017 <blockquote>
11018 <p>
11019 Unfortunately I believe the wording recommended by the LWG in Bellevue is incorrect.  <tt>reserve</tt> et. al. will use a move constructor
11020 if one is available, else it will use a copy constructor.  A type may have both.  If the move constructor is
11021 used, it must not throw.  If the copy constructor is used, it can throw.  The sentence in the proposed wording
11022 is correct without the recommended insertion.  The Bellevue LWG recommended moving this issue to Ready.  I am
11023 unfortunately pulling it back to Open.  But I'm drafting wording to atone for this egregious action. :-)
11024 </p>
11025 </blockquote>
11026
11027
11028
11029
11030
11031
11032 <hr>
11033 <h3><a name="758"></a>758. <tt>shared_ptr</tt> and <tt>nullptr</tt></h3>
11034 <p><b>Section:</b> 20.7.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
11035  <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-10-31</p>
11036 <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>
11037 <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>
11038 <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>
11039 <p><b>Discussion:</b></p>
11040 <p>
11041 Consider the following program:
11042 </p>
11043
11044 <blockquote><pre>int main() {
11045    shared_ptr&lt;int&gt; p(nullptr);
11046    return 0;
11047 }
11048 </pre></blockquote>
11049
11050 <p>
11051 This program will fail to compile because <tt>shared_ptr</tt> uses the following
11052 template constructor to construct itself from pointers:
11053 </p>
11054
11055 <blockquote><pre>template &lt;class Y&gt; shared_ptr(Y *);
11056 </pre></blockquote>
11057
11058 <p>
11059 According
11060 to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf">N2431</a>,
11061 the conversion from <tt>nullptr_t</tt> to <tt>Y *</tt> is not
11062 deducible, so the above constructor will not be found.  There are similar problems with the
11063 constructors that take a pointer and a <tt>deleter</tt> or a
11064 pointer, a <tt>deleter</tt> and an allocator, as well as the
11065 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>
11066 will solve this problem for constructing from just <tt>nullptr</tt>, but not for constructors that use
11067 <tt>deleters</tt> or allocators or for <tt>reset()</tt>.
11068 </p>
11069
11070 <p>
11071 In the case of the functions that take deleters, there is the additional
11072 question of what argument should be passed to the deleter when it is
11073 eventually called.  There are two reasonable possibilities: <tt>nullptr</tt> or
11074 <tt>static_cast&lt;T *&gt;(0)</tt>, where <tt>T</tt> is the template argument of the
11075 <tt>shared_ptr</tt>.  It is not immediately clear which of these is better.  If
11076 <tt>D::operator()</tt> is a template function similar to <tt>shared_ptr</tt>'s
11077 constructor, then <tt>d(static_cast&lt;T*&gt;(0))</tt> will compile and <tt>d(nullptr)</tt>
11078 will not.  On the other hand, if <tt>D::operator()()</tt> takes a parameter that
11079 is a pointer to some type other that <tt>T</tt> (for instance <tt>U*</tt> where <tt>U</tt> derives
11080 from <tt>T</tt>) then <tt>d(nullptr)</tt> will compile and <tt>d(static_cast&lt;T *&gt;(0))</tt> may not.
11081 </p>
11082
11083 <p><i>[
11084 Bellevue:
11085 ]</i></p>
11086
11087
11088 <blockquote>
11089 <p>
11090 The general idea is right, we need to be able to pass a nullptr to a
11091 shared_ptr, but there are a few borderline editorial issues here. (For
11092 example, the single-argument nullptr_t constructor in the class synopsis
11093 isn't marked explicit, but it is marked explicit in the proposed wording
11094 for 20.6.6.2.1. There is a missing empty parenthesis in the form that
11095 takes a nullptr_t, a deleter, and an allocator.)
11096 </p>
11097 <p>
11098 More seriously: this issue says that a shared_ptr constructed from a
11099 nullptr is empty. Since "empty" is undefined, it's hard to know whether
11100 that's right. This issue is pending on handling that term better.
11101 </p>
11102 <p>
11103 Peter suggests definition of empty should be "does not own anything"
11104 </p>
11105 <p>
11106 Is there an editorial issue that post-conditions should refer to get() =
11107 nullptr, rather than get() = 0?
11108 </p>
11109 <p>
11110 No strong feeling towards accept or NAD, but prefer to make a decision than leave it open.
11111 </p>
11112 <p>
11113 Seems there are no technical merits between NAD and Ready, comes down to
11114 "Do we intentially want to allow/disallow null pointers with these
11115 functions". Staw Poll - support null pointers 5 - No null pointers 0
11116 </p>
11117 <p>
11118 Move to Ready, modulo editorial comments
11119 </p>
11120 </blockquote>
11121
11122 <p><i>[
11123 post Bellevue Peter adds:
11124 ]</i></p>
11125
11126
11127 <blockquote>
11128 <p>
11129 The following wording changes are less intrusive:
11130 </p>
11131
11132 <p>
11133 In 20.7.12.2.1 [util.smartptr.shared.const], add:
11134 </p>
11135
11136 <blockquote><pre>shared_ptr(nullptr_t);
11137 </pre></blockquote>
11138
11139 <p>
11140 after:
11141 </p>
11142
11143 <blockquote><pre>shared_ptr();
11144 </pre></blockquote>
11145
11146 <p>
11147 (Absence of explicit intentional.)
11148 </p>
11149
11150 <p>
11151 <tt>px.reset( nullptr )</tt> seems a somewhat contrived way to write <tt>px.reset()</tt>, so
11152 I'm not convinced of its utility.
11153 </p>
11154 <p>
11155 It's similarly not clear to me whether the deleter constructors need to be
11156 extended to take <tt>nullptr</tt>, but if they need to:
11157 </p>
11158 <p>
11159 Add
11160 </p>
11161
11162 <blockquote><pre>template&lt;class D&gt; shared_ptr(nullptr_t p, D d);
11163 template&lt;class D, class A&gt; shared_ptr(nullptr_t p, D d, A a);
11164 </pre></blockquote>
11165
11166 <p>
11167 after
11168 </p>
11169
11170 <blockquote><pre>template&lt;class Y, class D&gt; shared_ptr(Y* p, D d);
11171 template&lt;class Y, class D, class A&gt; shared_ptr(Y* p, D d, A a);
11172 </pre></blockquote>
11173
11174 <p>
11175 Note that this changes the semantics of the new constructors such that they
11176 consistently call <tt>d(p)</tt> instead of <tt>d((T*)0)</tt> when <tt>p</tt> is <tt>nullptr</tt>.
11177 </p>
11178 <p>
11179 The ability to be able to pass <tt>0/NULL</tt> to a function that takes a <tt>shared_ptr</tt>
11180 has repeatedly been requested by users, but the other additions that the
11181 proposed resolution makes are not supported by real world demand or
11182 motivating examples.
11183 </p>
11184 <p>
11185 It might be useful to split the obvious and non-controversial <tt>nullptr_t</tt>
11186 constructor into a separate issue. Waiting for "empty" to be clarified is
11187 unnecessary; this is effectively an alias for the default constructor.
11188 </p>
11189 </blockquote>
11190
11191 <p><i>[
11192 Sophia Antipolis:
11193 ]</i></p>
11194
11195
11196 <blockquote>
11197 <p>
11198 We want to remove the reset functions from the proposed resolution.
11199 </p>
11200 <p>
11201 The remaining proposed resolution text (addressing the constructors) are wanted.
11202 </p>
11203 <p>
11204 Disposition: move to review. The review should check the wording in the then-current working draft.
11205 </p>
11206 </blockquote>
11207
11208
11209
11210 <p><b>Proposed resolution:</b></p>
11211 <p>
11212 Add the following constructors to 20.7.12.2 [util.smartptr.shared]:
11213 </p>
11214
11215 <blockquote><pre>shared_ptr(nullptr_t);
11216 template &lt;class D&gt; shared_ptr(nullptr_t, D d);
11217 template &lt;class D, class A&gt; shared_ptr(nullptr_t, D d, A a);
11218 </pre></blockquote>
11219
11220
11221
11222 <p>
11223 Add the following constructor definitions to 20.7.12.2.1 [util.smartptr.shared.const]:
11224 </p>
11225
11226 <blockquote>
11227 <pre> explicit shared_ptr(nullptr_t);
11228 </pre>
11229 <blockquote>
11230 <p>
11231 <i>Effects:</i> Constructs an empty shared_ptr object.
11232 </p>
11233 <p>
11234 <i>Postconditions:</i> <tt>use_count() == 0 &amp;&amp; get() == 0</tt>.
11235 </p>
11236 <p>
11237 <i>Throws:</i> nothing.
11238 </p>
11239 </blockquote>
11240 </blockquote>
11241
11242 <blockquote>
11243 <pre>template &lt;class D&gt; shared_ptr(nullptr_t, D d);
11244 template &lt;class D, class A&gt; shared_ptr&lt;nullptr_t, D d, A a);
11245 </pre>
11246 <blockquote>
11247 <p>
11248 <i>Requires:</i> <tt>D</tt> shall be <tt>CopyConstructible</tt>. The copy constructor and
11249 destructor of <tt>D</tt> shall not throw exceptions. The expression
11250 <tt>d(static_cast&lt;T *&gt;(0))</tt> shall be well-formed, shall have well defined behavior,
11251 and shall not throw exceptions. <tt>A</tt> shall be an allocator (20.1.2 [allocator.requirements]).
11252 The copy constructor and destructor of <tt>A</tt> shall not throw
11253 exceptions.
11254 </p>
11255 <p>
11256 <i>Effects:</i> Constructs a <tt>shared_ptr</tt> object that owns a null pointer of type <tt>T *</tt>
11257 and  deleter <tt>d</tt>.  The
11258 second constructor shall use a copy of <tt>a</tt> to allocate memory for
11259 internal use.
11260 </p>
11261 <p>
11262 <i>Postconditions:</i> <tt>use_count() == 1</tt> and <tt>get() == 0</tt>.
11263 </p>
11264 <p>
11265 <i>Throws:</i> <tt>bad_alloc</tt>, or an implementation-defined exception when a
11266 resource other than memory could not be obtained.
11267 </p>
11268 <p>
11269 <i>Exception safety:</i> If an exception is thrown, <tt>d(static_cast&lt;Y *&gt;(nullptr))</tt> is called.
11270 </p>
11271 </blockquote>
11272 </blockquote>
11273
11274
11275
11276
11277
11278
11279
11280
11281 <hr>
11282 <h3><a name="760"></a>760. The emplace issue</h3>
11283 <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>
11284  <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2007-11-11</p>
11285 <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>
11286 <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>
11287 <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>
11288 <p><b>Discussion:</b></p>
11289 <p>
11290 In an emplace member function the function parameter pack may be bound
11291 to a priori unlimited number of objects: some or all of them can be
11292 elements of the container itself. Apparently, in order to conform to the
11293 blanket statement 23.1 [container.requirements]/11, the implementation must check all of them for
11294 that possibility. A possible solution can involve extending the
11295 exception in 23.1 [container.requirements]/12 also to the emplace member. As a side note, the
11296 <tt>push_back</tt> and <tt>push_front</tt> member functions are luckily not affected by
11297 this problem, can be efficiently implemented anyway
11298 </p>
11299
11300 <p><i>[
11301 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>
11302 ]</i></p>
11303
11304
11305 <p><i>[
11306 Bellevue:
11307 ]</i></p>
11308
11309
11310 <blockquote>
11311 <p>
11312 The proposed addition (13) is partially redundant with the existing
11313 paragraph 12. Why was the qualifier "rvalues" added to paragraph 12? Why
11314 does it not cover subelements and pointers?
11315 </p>
11316 <p>
11317 Resolution: Alan Talbot to rework language, then set state to Review.
11318 </p>
11319 </blockquote>
11320
11321
11322
11323 <p><b>Proposed resolution:</b></p>
11324 <p>
11325 Add after 23.1 [container.requirements]/12:
11326 </p>
11327
11328 <blockquote>
11329 <p>
11330 -12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No
11331 diagnostic required.
11332 </p>
11333 <p>
11334 <ins>
11335 -13- Objects bound to the function parameter pack of the <tt>emplace</tt> member function shall not be elements or
11336 sub-objects of elements of the container. No diagnostic required.
11337 </ins>
11338 </p>
11339
11340 </blockquote>
11341
11342
11343
11344
11345
11346
11347 <hr>
11348 <h3><a name="762"></a>762. <tt>std::unique_ptr</tt> requires complete type?</h3>
11349 <p><b>Section:</b> 20.7.11 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
11350  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-11-30</p>
11351 <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>
11352 <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>
11353 <p><b>Discussion:</b></p>
11354 <p>
11355 In contrast to the proposed <tt>std::shared_ptr</tt>, <tt>std::unique_ptr</tt>
11356 does currently not support incomplete types, because it
11357 gives no explicit grant - thus instantiating <tt>unique_ptr</tt> with
11358 an incomplete pointee type <tt>T</tt> automatically belongs to
11359 undefined behaviour according to 17.4.3.7 [res.on.functions]/2, last
11360 bullet. This is an unnecessary restriction and prevents
11361 many well-established patterns - like the bridge pattern -
11362 for <tt>std::unique_ptr</tt>.
11363 </p>
11364
11365 <p><i>[
11366 Bellevue:
11367 ]</i></p>
11368
11369
11370 <blockquote>
11371 Move to open. The LWG is comfortable with the intent of allowing
11372 incomplete types and making <tt>unique_ptr</tt> more like <tt>shared_ptr</tt>, but we are
11373 not comfortable with the wording. The specification for <tt>unique_ptr</tt>
11374 should be more like that of <tt>shared_ptr</tt>. We need to know, for individual
11375 member functions, which ones require their types to be complete. The
11376 <tt>shared_ptr</tt> specification is careful to say that for each function, and
11377 we need the same level of care here. We also aren't comfortable with the
11378 "part of the operational semantic" language; it's not used elsewhere in
11379 the standard, and it's not clear what it means. We need a volunteer to
11380 produce new wording.
11381 </blockquote>
11382
11383
11384 <p><b>Proposed resolution:</b></p>
11385 <p>
11386 The proposed changes in the following revision refers to the current state of
11387 N2521 including the assumption that 20.7.11.4 [unique.ptr.compiletime] will be removed
11388 according to the current state of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>.
11389 </p>
11390 <p>
11391 The specialization <tt>unique_ptr&lt;T[]&gt;</tt> has some more restrictive constraints on
11392 type-completeness on <tt>T</tt> than <tt>unique_ptr&lt;T&gt;</tt>. The following proposed wordings
11393 try to cope with that. If the committee sees less usefulness on relaxed
11394 constraints on <tt>unique_ptr&lt;T[]&gt;</tt>, the alternative would be to stop this relaxation
11395 e.g. by adding one further bullet to 20.7.11.3 [unique.ptr.runtime]/1:
11396 "<tt>T</tt> shall be a complete type, if used as template argument of
11397 <tt>unique_ptr&lt;T[], D&gt;</tt>
11398 </p>
11399 <p>
11400 This issue has some overlap with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, but it seems not to cause any
11401 problems with this one,
11402 because <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> adds only optional requirements on <tt>D</tt> that do not conflict
11403 with the here discussed
11404 ones, provided that <tt>D::pointer</tt>'s operations (including default
11405 construction, copy construction/assignment,
11406 and pointer conversion) are specified <em>not</em> to throw, otherwise this
11407 would have impact on the
11408 current specification of <tt>unique_ptr</tt>.
11409 </p>
11410
11411 <ol>
11412 <li>
11413 <p>
11414 In 20.7.11 [unique.ptr]/2 add as the last sentence to the existing para:
11415 </p>
11416
11417 <blockquote>
11418 The <tt>unique_ptr</tt> provides a semantics of strict ownership. A
11419 <tt>unique_ptr</tt> owns the object it holds a pointer to. A
11420 <tt>unique_ptr</tt> is not <tt>CopyConstructible</tt>, nor
11421 <tt>CopyAssignable</tt>, however it is <tt>MoveConstructible</tt> and
11422 <tt>MoveAssignable</tt>. <ins>The template parameter <tt>T</tt> of
11423 <tt>unique_ptr</tt> may be an incomplete type.</ins> [ <i>Note:</i> The
11424 uses of <tt>unique_ptr</tt> include providing exception safety for
11425 dynamically allcoated memory, passing ownership of dynamically allocated
11426 memory to a function, and returning dynamically allocated memory from a
11427 function. -- <i>end note</i> ]
11428 </blockquote>
11429 </li>
11430
11431 <li>
11432 <p>
11433 20.7.11.2.1 [unique.ptr.single.ctor]/1: No changes necessary.
11434 </p>
11435
11436 <blockquote>
11437 <p><i>[
11438 N.B.: We only need the requirement that <tt>D</tt> is <tt>DefaultConstructible</tt>.
11439 The current wording says just this.
11440 ]</i></p>
11441
11442 </blockquote>
11443 </li>
11444
11445 <li>
11446 <p>
11447 In 20.7.11.2.1 [unique.ptr.single.ctor]/5 change the requires clause to say:
11448 </p>
11449
11450 <blockquote>
11451 <p>
11452 <i>Requires:</i> <del>The expression <tt>D()(p)</tt> shall be well formed. The default constructor
11453 of <tt>D</tt> shall not throw an exception.</del>
11454 <del><tt>D</tt> must not be a reference type.</del>
11455 <ins>
11456 <tt>D</tt> shall be default constructible, and that construction
11457 shall not throw an exception.
11458 </ins>
11459 </p>
11460 <p><i>[
11461 N.B.: There is no need that the expression <tt>D()(p)</tt> is well-formed at
11462 this point. I assume that the current wording is based on the
11463 corresponding <tt>shared_ptr</tt> wording. In case of <tt>shared_ptr</tt> this
11464 requirement is necessary, because the corresponding c'tor *can* fail
11465 and must invoke delete <tt>p/d(p)</tt> in this case. <tt>Unique_ptr</tt> is simpler in
11466 this regard. The *only* functions that must insist on well-formedness
11467 and well-definedness of the expression <tt>get_deleter()(get())</tt> are (1)
11468 the destructor and (2) <tt>reset</tt>. The reasoning for the wording change to
11469 explicitly require <tt>DefaultConstructible</tt> of <tt>D</tt> is to guarantee that
11470 invocation of
11471 <tt>D</tt>'s default c'tor is both well-formed and well-defined. Note also that
11472 we do *not* need the
11473 requirement that <tt>T</tt> must be complete, also in contrast to <tt>shared_ptr</tt>.
11474 <tt>Shared_ptr</tt> needs this, because it's c'tor is a template c'tor which
11475 potentially requires <tt>Convertible&lt;Y*, X*&gt;</tt>, which
11476 again requires Completeness of <tt>Y</tt>, if <tt>!SameType&lt;X, Y&gt;</tt>
11477 ]</i></p>
11478
11479 </blockquote>
11480 </li>
11481
11482 <li>
11483 <p>
11484 Merge 20.7.11.2.1 [unique.ptr.single.ctor]/12+13 thereby removing the sentence
11485 of 12, but transferring the "requires" to 13:
11486 </p>
11487
11488 <blockquote>
11489 <p>
11490 <i>Requires:</i> If <tt>D</tt> is not an lvalue-reference type then[..]
11491 </p>
11492 <p><i>[
11493 N.B.: For the same reasons as for (3), there is no need that <tt>d(p)</tt> is
11494 well-formed/well-defined at this point. The current wording guarantees
11495 all what we need, namely that the initialization of both the <tt>T*</tt>
11496 pointer and the <tt>D</tt> deleter are well-formed and well-defined.
11497 ]</i></p>
11498
11499 </blockquote>
11500 </li>
11501
11502 <li>
11503 20.7.11.2.1 [unique.ptr.single.ctor]/17: No changes necessary.
11504 </li>
11505 <li>
11506 <p>20.7.11.2.1 [unique.ptr.single.ctor]/21:</p>
11507
11508 <blockquote>
11509 <i>Requires:</i> If <tt>D</tt> is not a reference type, construction of
11510 the deleter <tt>D</tt> from an rvalue of type <tt>E</tt> shall be well
11511 formed and shall not throw an exception. If <tt>D</tt> is a reference
11512 type, then <tt>E</tt> shall be the same type as <tt>D</tt> (diagnostic
11513 required). <tt>U*</tt> shall be implicitly convertible to <tt>T*</tt>.
11514 <ins>[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt>
11515 be complete types. <i>-- end note</i>]</ins>
11516 </blockquote>
11517
11518 <p><i>[
11519 N.B.: The current wording of 21 already implicitly guarantees that <tt>U</tt>
11520 is completely defined, because it requires that <tt>Convertible&lt;U*, T*&gt;</tt> is
11521 true. If the committee wishes this explicit requirement can be added,
11522 e.g. "<tt>U</tt> shall be a complete type."
11523 ]</i></p>
11524
11525 </li>
11526
11527 <li>
11528 <p>
11529 20.7.11.2.2 [unique.ptr.single.dtor]: Just before p1 add a new paragraph:
11530 </p>
11531 <blockquote>
11532 <p>
11533 <i>Requires:</i> The expression <tt>get_deleter()(get())</tt> shall be well-formed,
11534 shall have well-defined behavior, and shall not throw exceptions.
11535 <ins>[<i>Note:</i> The use of <tt>default_delete</tt> requires <tt>T</tt> to
11536 be a complete type. <i>-- end note</i>]</ins>
11537 </p>
11538 <p><i>[
11539 N.B.: This requirement ensures that the whole responsibility on
11540 type-completeness of <tt>T</tt> is delegated to this expression.
11541 ]</i></p>
11542
11543 </blockquote>
11544 </li>
11545
11546 <li>
11547 <p>
11548 20.7.11.2.3 [unique.ptr.single.asgn]/1: No changes necessary, except the
11549 current editorial issue, that "must shall" has to be changed to
11550 "shall", but this change is not a special part of this resolution.
11551 </p>
11552
11553 <p><i>[
11554 N.B. The current wording is sufficient, because we can delegate all
11555 further requirements on the requirements of the effects clause
11556 ]</i></p>
11557
11558 </li>
11559
11560 <li>
11561 <p>
11562 20.7.11.2.3 [unique.ptr.single.asgn]/6:
11563 </p>
11564
11565 <blockquote>
11566 <i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
11567 <tt>D</tt> shall not throw an exception. <tt>U*</tt> shall be implicitly
11568 convertible to <tt>T*</tt>.
11569 <ins>[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt>
11570 be complete types. <i>-- end note</i>]</ins>
11571 </blockquote>
11572
11573 <p><i>[
11574 N.B.: The current wording of p. 6 already implicitly guarantees that
11575 <tt>U</tt> is completely defined, because it requires that <tt>Convertible&lt;U*, T*&gt;</tt>
11576 is true, see (6)+(8).
11577 ]</i></p>
11578
11579 </li>
11580
11581 <li>
11582 <p>
11583 20.7.11.2.3 [unique.ptr.single.asgn]/11: No changes necessary.
11584 </p>
11585 <p><i>[
11586 N.B.: Delegation to requirements of effects clause is sufficient.
11587 ]</i></p>
11588
11589 </li>
11590
11591 <li>
11592 20.7.11.2.4 [unique.ptr.single.observers]/1+4+7+9+11:
11593 </li>
11594
11595 <blockquote>
11596 <pre>T* operator-&gt;() const;</pre>
11597 <blockquote>
11598 <ins><i>Note:</i> Use typically requires <tt>T</tt> shall be complete. <i>-- end note</i>]</ins>
11599 </blockquote>
11600 </blockquote>
11601
11602 <li>
11603 20.7.11.2.5 [unique.ptr.single.modifiers]/1: No changes necessary.
11604 </li>
11605
11606 <li>
11607 <p>
11608 20.7.11.2.5 [unique.ptr.single.modifiers]/4: Just before p. 4 add a new paragraph:
11609 </p>
11610 <blockquote>
11611 <i>Requires:</i> The expression <tt>get_deleter()(get())</tt> shall be well-formed,
11612 shall have well-defined behavior, and shall not throw exceptions.
11613 </blockquote>
11614 </li>
11615
11616 <li>
11617 20.7.11.2.5 [unique.ptr.single.modifiers]/7: No changes necessary.
11618 </li>
11619
11620 <li>
11621 <p>
11622 20.7.11.3 [unique.ptr.runtime]: Add one additional bullet on paragraph 1:
11623 </p>
11624
11625 <blockquote>
11626 <p>
11627 A specialization for array types is provided with a slightly altered interface.
11628 </p>
11629
11630 <ul>
11631 <li>
11632 ...
11633 </li>
11634 <li>
11635 <ins><tt>T</tt> shall be a complete type.</ins>
11636 </li>
11637 </ul>
11638 </blockquote>
11639 </li>
11640 </ol>
11641
11642 <p><i>[
11643 post Bellevue: Daniel provided revised wording.
11644 ]</i></p>
11645
11646
11647
11648
11649
11650
11651
11652 <hr>
11653 <h3><a name="765"></a>765. more on iterator validity</h3>
11654 <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>
11655  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-12-14</p>
11656 <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>
11657 <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>
11658 <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>
11659 <p><b>Discussion:</b></p>
11660        <p>
11661
11662 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a>
11663 defines the meaning of the term "invalid iterator" as one that may be
11664 singular.
11665
11666        </p>
11667        <p>
11668
11669 Consider the following code:
11670
11671        </p>
11672        <pre>   std::deque&lt;int&gt; x, y;
11673    std::deque&lt;int&gt;::iterator i = x.end(), j = y.end();
11674    x.swap(y);
11675        </pre>
11676        <p>
11677
11678 Given that <code>swap()</code> is required not to invalidate iterators
11679 and using the definition above, what should be the expected result of
11680 comparing <code>i</code> and <code>j</code> to <code>x.end()</code>
11681 and <code>y.end()</code>, respectively, after the <code>swap()</code>?
11682
11683        </p>
11684        <p>
11685
11686 I.e., is the expression below required to evaluate
11687 to <code>true</code>?
11688
11689        </p>
11690        <pre>   i == y.end() &amp;&amp; j == x.end()
11691        </pre>
11692        <p>
11693
11694 (There are at least two implementations where the expression
11695 returns <code>false</code>.)
11696
11697        </p>
11698        <p>
11699
11700 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
11701 make any guarantees about whether iterators actually point to the same
11702 elements or be associated with the same containers after a
11703 non-invalidating operation as they did before?
11704
11705        </p>
11706        <p>
11707
11708 Here's a motivating example intended to demonstrate the importance of
11709 the question:
11710
11711        </p>
11712        <pre>   Container x, y ({ 1, 2});   // pseudocode to initialize y with { 1, 2 }
11713    Container::iterator i = y.begin() + 1;
11714    Container::iterator j = y.end();
11715    std::swap(x, y);
11716    std::find(i, j, 3);
11717        </pre>
11718        <p>
11719
11720 <code>swap()</code> guarantees that <code>i</code> and <code>j</code>
11721 continue to be valid. Unless the spec says that even though they are
11722 valid they may no longer denote a valid range the code above must be
11723 well-defined. Expert opinions on this differ as does the behavior of
11724 popular implementations for some standard <code>Containers</code>.
11725
11726        </p>
11727
11728
11729 <p><b>Proposed resolution:</b></p>
11730 <p>
11731 </p>
11732
11733
11734
11735
11736
11737 <hr>
11738 <h3><a name="769"></a>769. std::function should use nullptr_t instead of "unspecified-null-pointer-type"</h3>
11739 <p><b>Section:</b> 20.6.15.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
11740  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-10</p>
11741 <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>
11742 <p><b>Discussion:</b></p>
11743 <p>
11744 N2461 already replaced in 20.6.15.2 [func.wrap.func] it's originally proposed
11745 (implicit) conversion operator to "unspecified-bool-type" by the new
11746 explicit bool conversion, but the inverse conversion should also
11747 use the new <tt>std::nullptr_t</tt> type instead of "unspecified-null-pointer-
11748 type".
11749 </p>
11750
11751
11752 <p><b>Proposed resolution:</b></p>
11753
11754 <p>
11755 In 20.6 [function.objects], header <tt>&lt;functional&gt;</tt> synopsis replace:
11756 </p>
11757
11758 <blockquote><pre>template&lt;class R, class... ArgTypes&gt;
11759   bool operator==(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
11760 template&lt;class R, class... ArgTypes&gt;
11761   bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
11762 template&lt;class R, class... ArgTypes&gt;
11763   bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
11764 template&lt;class R, class... ArgTypes&gt;
11765   bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
11766 </pre></blockquote>
11767
11768 <p>
11769 In the class function synopsis of 20.6.15.2 [func.wrap.func] replace
11770 </p>
11771
11772 <blockquote><pre>function(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
11773 ...
11774 function&amp; operator=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
11775 </pre></blockquote>
11776
11777 <p>
11778 In 20.6.15.2 [func.wrap.func], "Null pointer comparisons" replace:
11779 </p>
11780
11781 <blockquote><pre>template &lt;class R, class... ArgTypes&gt;
11782   bool operator==(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
11783 template &lt;class R, class... ArgTypes&gt;
11784   bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
11785 template &lt;class R, class... ArgTypes&gt;
11786   bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
11787 template &lt;class R, class... ArgTypes&gt;
11788   bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
11789 </pre></blockquote>
11790
11791 <p>
11792 In 20.6.15.2.1 [func.wrap.func.con], replace
11793 </p>
11794
11795 <blockquote><pre>function(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
11796 ...
11797 function&amp; operator=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
11798 </pre></blockquote>
11799
11800 <p>
11801 In 20.6.15.2.6 [func.wrap.func.nullptr], replace
11802 </p>
11803
11804 <blockquote><pre>template &lt;class R, class... ArgTypes&gt;
11805   bool operator==(const function&lt;R(ArgTypes...)&gt;&amp; f, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
11806 template &lt;class R, class... ArgTypes&gt;
11807   bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp; f);
11808 </pre></blockquote>
11809
11810 <p>
11811 and replace
11812 </p>
11813
11814 <blockquote><pre>template &lt;class R, class... ArgTypes&gt;
11815   bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp; f, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
11816 template &lt;class R, class... ArgTypes&gt;
11817   bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp; f);
11818 </pre></blockquote>
11819
11820
11821
11822
11823
11824
11825 <hr>
11826 <h3><a name="771"></a>771. Impossible throws clause in [string.conversions]</h3>
11827 <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#Ready">Ready</a>
11828  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-13</p>
11829 <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>
11830 <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>
11831 <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>
11832 <p><b>Discussion:</b></p>
11833 <p>
11834 The new <tt>to_string</tt> and <tt>to_wstring</tt> functions described in 21.4 [string.conversions]
11835 have throws clauses (paragraphs 8 and 16) which say:
11836 </p>
11837
11838 <blockquote>
11839 <i>Throws:</i> nothing
11840 </blockquote>
11841
11842 <p>
11843 Since all overloads return either a <tt>std::string</tt> or a <tt>std::wstring</tt> by value
11844 this throws clause is impossible to realize in general, since the <tt>basic_string</tt>
11845 constructors can fail due to out-of-memory conditions. Either these throws
11846 clauses should be removed or should be more detailled like:
11847 </p>
11848
11849 <blockquote>
11850 <i>Throws:</i> Nothing if the string construction throws nothing
11851 </blockquote>
11852
11853 <p>
11854 Further there is an editorial issue in p. 14: All three <tt>to_wstring</tt>
11855 overloads return a <tt>string</tt>, which should be <tt>wstring</tt> instead (The
11856 header <tt>&lt;string&gt;</tt> synopsis of 21.2 [string.classes] is correct in this
11857 regard).
11858 </p>
11859
11860
11861
11862 <p><b>Proposed resolution:</b></p>
11863 <p>
11864 In 21.4 [string.conversions], remove the paragraphs 8 and 16.
11865 </p>
11866
11867 <blockquote>
11868 <pre>string to_string(long long val);
11869 string to_string(unsigned long long val);
11870 string to_string(long double val);
11871 </pre>
11872 <blockquote>
11873 <del><i>Throws:</i> nothing</del>
11874 </blockquote>
11875 </blockquote>
11876
11877 <blockquote>
11878 <pre><ins>w</ins>string to_wstring(long long val);
11879 <ins>w</ins>string to_wstring(unsigned long long val);
11880 <ins>w</ins>string to_wstring(long double val);
11881 </pre>
11882 <blockquote>
11883 <del><i>Throws:</i> nothing</del>
11884 </blockquote>
11885 </blockquote>
11886
11887
11888
11889
11890
11891
11892 <hr>
11893 <h3><a name="772"></a>772.  Impossible return clause in [string.conversions]</h3>
11894 <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#Ready">Ready</a>
11895  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-13</p>
11896 <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>
11897 <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>
11898 <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>
11899 <p><b>Discussion:</b></p>
11900 <p>
11901 The return clause 21.4 [string.conversions]/paragraph 15 of the new <tt>to_wstring</tt>
11902 overloads says:
11903 </p>
11904
11905 <blockquote>
11906 <i>Returns:</i> each function returns a <tt>wstring</tt> object holding the character
11907 representation of the value of its argument that would be generated by
11908 calling <tt>wsprintf(buf, fmt, val)</tt> with a format specifier of <tt>L"%lld"</tt>, <tt>L"%ulld"</tt>,
11909 or <tt>L"%f"</tt>, respectively.
11910 </blockquote>
11911
11912 <p>
11913 Problem is: There does not exist any <tt>wsprintf</tt> function in C99 (I checked
11914 the 2nd edition of ISO 9899, and the first and the second corrigenda from
11915 2001-09-01 and 2004-11-15). What probably meant here is the function
11916 <tt>swprintf</tt> from <tt>&lt;wchar.h&gt;/&lt;cwchar&gt;</tt>, but this has the non-equivalent
11917 declaration:
11918 </p>
11919
11920 <blockquote><pre>int swprintf(wchar_t * restrict s, size_t n,
11921 const wchar_t * restrict format, ...);
11922 </pre></blockquote>
11923
11924 <p>
11925 therefore the paragraph needs to mention the <tt>size_t</tt> parameter <tt>n</tt>.
11926 </p>
11927
11928
11929
11930 <p><b>Proposed resolution:</b></p>
11931 <p>
11932 Change the current wording of 21.4 [string.conversions]/p. 15 to:
11933 </p>
11934
11935 <blockquote>
11936 <i>Returns:</i> <del>e</del><ins>E</ins>ach function returns a
11937 <tt>wstring</tt> object holding the character representation of the
11938 value of its argument that would be generated by calling
11939 <tt><del>ws</del><ins>sw</ins>printf(buf, <ins>bufsz,</ins> fmt,
11940 val)</tt> with a format specifier <ins><tt>fmt</tt></ins> of <tt>L"%lld"</tt>,
11941 <tt>L"%ulld"</tt>, or <tt>L"%f"</tt>, respectively<ins>, where <tt>buf</tt>
11942 designates an internal character buffer of sufficient size <tt>bufsz</tt></ins>.
11943 </blockquote>
11944
11945 <p>
11946 [Hint to the editor: The resolution also adds to mention the name of
11947 the format specifier "fmt"]
11948 </p>
11949
11950 <p>
11951 I also would like to remark that the current wording of it's equivalent
11952 paragraph 7 should also mention the meaning of <tt>buf</tt> and <tt>fmt</tt>.
11953 </p>
11954
11955 <p>
11956 Change the current wording of 21.4 [string.conversions]/p. 7 to:
11957 </p>
11958
11959 <blockquote>
11960 <i>Returns:</i> <del>e</del><ins>E</ins>ach function returns a string object holding the
11961 character representation of the value of its argument that would be
11962 generated by calling <tt>sprintf(buf, fmt, val)</tt> with a format specifier <ins><tt>fmt</tt></ins> of
11963 <tt>"%lld"</tt>, <tt>"%ulld"</tt>, or <tt>"%f"</tt>, respectively<ins>, where <tt>buf</tt> designates an internal
11964 character buffer of sufficient size</ins>.
11965 </blockquote>
11966
11967
11968
11969
11970
11971
11972 <hr>
11973 <h3><a name="774"></a>774. Member swap undefined for most containers</h3>
11974 <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>
11975  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-01-14</p>
11976 <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>
11977 <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>
11978 <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>
11979 <p><b>Discussion:</b></p>
11980 <p>
11981 It appears most containers declare but do not define a member-swap
11982 function.
11983 </p>
11984
11985 <p>
11986 This is unfortunate, as all overload the <tt>swap</tt> algorithm to call the
11987 member-swap function!
11988 (required for <tt>swappable</tt> guarantees [Table 37] and Container Requirements
11989 [Table 87])
11990 </p>
11991
11992 <p>
11993 Note in particular that Table 87 gives semantics of <tt>a.swap(b)</tt> as <tt>swap(a,b)</tt>,
11994 yet for all containers we define <tt>swap(a,b)</tt> to call <tt>a.swap(b)</tt> - a circular
11995 definition.
11996 </p>
11997
11998 <p>
11999 A quick survey of clause 23 shows that the following containers provide a
12000 definition for member-swap:
12001 </p>
12002
12003 <blockquote><pre>array
12004 queue
12005 stack
12006 vector
12007 </pre></blockquote>
12008
12009 <p>
12010 Whereas the following declare it, but do not define the semantics:
12011 </p>
12012
12013 <blockquote><pre>deque
12014 list
12015 map
12016 multimap
12017 multiset
12018 priority_queue
12019 set
12020 unordered_map
12021 unordered_multi_map
12022 unordered_multi_set
12023 unordered_set
12024 </pre></blockquote>
12025
12026 <p>
12027 Suggested resolution:
12028 </p>
12029 <blockquote>
12030 Provide a definition for each of the affected containers...
12031 </blockquote>
12032
12033 <p><i>[
12034 Bellevue:
12035 ]</i></p>
12036
12037
12038 <blockquote>
12039 Move to Open and ask Alisdair to provide wording.
12040 </blockquote>
12041
12042
12043 <p><b>Proposed resolution:</b></p>
12044 <p>
12045 Wording provided in
12046 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2590.pdf">N2590</a>.
12047 </p>
12048
12049
12050
12051
12052
12053 <hr>
12054 <h3><a name="776"></a>776. Undescribed assign function of std::array</h3>
12055 <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#Ready">Ready</a>
12056  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-20</p>
12057 <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>
12058 <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>
12059 <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>
12060 <p><b>Discussion:</b></p>
12061 <p>
12062 The class template array synopsis in 23.2.1 [array]/3 declares a member
12063 function
12064 </p>
12065
12066 <blockquote><pre>void assign(const T&amp; u);
12067 </pre></blockquote>
12068
12069 <p>
12070 which's semantic is no-where described. Since this signature is
12071 not part of the container requirements, such a semantic cannot
12072 be derived by those.
12073 </p>
12074
12075 <p>
12076 I found only one reference to this function in the issue list,
12077 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a> where the question is raised:
12078 </p>
12079
12080 <blockquote>
12081 what's the effect of calling <tt>assign(T&amp;)</tt> on a zero-sized array?
12082 </blockquote>
12083
12084 <p>
12085 which does not answer the basic question of this issue.
12086 </p>
12087
12088 <p>
12089 If this function shall be part of the <tt>std::array</tt>, it's probable
12090 semantic should correspond to that of <tt>boost::array</tt>, but of
12091 course such wording must be added.
12092 </p>
12093
12094
12095 <p><b>Proposed resolution:</b></p>
12096 <p>
12097 Just after the section 23.2.1.4 [array.data] add the following new section:
12098 </p>
12099
12100 <p>
12101 23.2.1.5 array::fill [array.fill]
12102 </p>
12103
12104 <blockquote>
12105 <pre>void fill(const T&amp; u);
12106 </pre>
12107
12108 <p>
12109 1: <i>Effects:</i> <tt>fill_n(begin(), N, u)</tt>
12110 </p>
12111 </blockquote>
12112
12113 <p>
12114 [N.B: I wonder, why class <tt>array</tt> does not have a "modifiers"
12115 section. If it had, then <tt>assign</tt> would naturally belong to it]
12116 </p>
12117
12118 <p>
12119 Change the synopsis in 23.2.1 [array]/3:
12120 </p>
12121
12122 <blockquote><pre>template &lt;class T, size_t N&gt;
12123 struct array {
12124   ...
12125   void <del>assign</del> <ins>fill</ins>(const T&amp; u);
12126   ...
12127 </pre></blockquote>
12128
12129
12130 <p><i>[
12131 Bellevue:
12132 ]</i></p>
12133
12134
12135 <blockquote>
12136 <p>
12137 Suggest substituting "fill" instead of "assign".
12138 </p>
12139 <p>
12140 Set state to Review given substitution of "fill" for "assign".
12141 </p>
12142 </blockquote>
12143
12144
12145
12146
12147 <hr>
12148 <h3><a name="779"></a>779. Resolution of #283 incomplete</h3>
12149 <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#Ready">Ready</a>
12150  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-25</p>
12151 <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>
12152 <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>
12153 <p><b>Discussion:</b></p>
12154 <p>
12155 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
12156 <tt>remove_copy[_if]</tt>,
12157 which seems to be an oversight.
12158 </p>
12159
12160
12161 <p><b>Proposed resolution:</b></p>
12162 <p>
12163 In 25.2.8 [alg.remove]/p.6, replace the N2461 requires clause with:
12164 </p>
12165
12166 <blockquote>
12167 <i>Requires:</i> <del>Type <tt>T</tt> is <tt>EqualityComparable</tt> (31).</del> The ranges <tt>[first,last)</tt>
12168 and <tt>[result,result + (last - first))</tt> shall not overlap. <ins>The expression <tt>*result = *first</tt> shall be
12169 valid.</ins>
12170 </blockquote>
12171
12172
12173
12174
12175
12176
12177 <hr>
12178 <h3><a name="780"></a>780. <tt>std::merge()</tt> specification incorrect/insufficient</h3>
12179 <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>
12180  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-25</p>
12181 <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>
12182 <p><b>Discussion:</b></p>
12183 <p>
12184 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:
12185 </p>
12186
12187 <p>
12188 Both 25.3.4 [lib.alg.merge] in 14882:2003 and 25.3.4 [alg.merge] in N2461
12189 have no Requires element and the Effects element contains some requirements,
12190 which is probably editorial. Worse is that:
12191 </p>
12192
12193 <ul>
12194 <li>
12195 no assignment requirements are specified (neither implicit nor explicit).
12196 </li>
12197
12198 <li>
12199 the effects clause just speaks of "merges", which is badly worded
12200 near to a circular definition.
12201 </li>
12202
12203 <li>
12204 p. 2 mentions a range <tt>[first, last)</tt>, which is not defined by the
12205 function arguments or otherwise.
12206 </li>
12207
12208 <li>
12209 p. 2 says "according to the ordering defined by comp" which is both
12210 incomplete (because
12211 this excludes the first variant with &lt;) and redundant (because the
12212 following subordinate
12213 clause mentions comp again)
12214 </li>
12215 </ul>
12216
12217
12218
12219 <p><b>Proposed resolution:</b></p>
12220 <p>
12221 In 25.3.4 [alg.merge] replace p.1+ 2:
12222 </p>
12223
12224 <blockquote>
12225 <p>
12226 <i>Effects:</i> <del>Merges</del> <ins>Copies all the elements of the</ins> two sorted ranges <tt>[first1,last1)</tt> and
12227 <tt>[first2,last2)</tt> into the range
12228 <del><tt>[result,result + (last1 - first1) + (last2 - first2))</tt></del>
12229 <ins><tt>[result, last)</tt> (where <tt>last</tt> is equal to <tt>result + (last1
12230 - first1) + (last2 - first2))</tt>, such that resulting range will be
12231 sorted in non-decreasing order; that is, for every iterator <tt>i</tt> in
12232 <tt>[result,last)</tt> other than <tt>result</tt>, the condition <tt>*i &lt; *(i - 1)</tt> or,
12233 respectively, <tt>comp(*i, *(i - 1))</tt> will be false</ins>.
12234 </p>
12235
12236 <p>
12237 <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
12238 order according to the ordering defined by <tt>comp</tt>; that is, for every iterator <tt>i</tt> in
12239 <tt>[first,last)</tt> other than <tt>first</tt>, the condition <tt>*i &lt; *(i - 1)</tt> or
12240 <tt>comp(*i, *(i - 1))</tt> will be false.</del> <ins>The results of the expressions <tt>*first1</tt> and <tt>*first2</tt>
12241 shall be writable to the output iterator.</ins>
12242 </p>
12243 </blockquote>
12244
12245 <p>
12246 [N.B.: I attempted to reuse the wording style of <tt>inplace_merge</tt>,
12247 therefore proposing to
12248 insert ", respectively," between both predicate tests. This is no
12249 strictly necessary as
12250 other parts of <tt>&lt;algorithm&gt;</tt> show, just a matter of consistency]
12251 </p>
12252
12253
12254
12255
12256
12257
12258 <hr>
12259 <h3><a name="785"></a>785. Random Number Requirements in TR1</h3>
12260 <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>
12261  <b>Submitter:</b> John Maddock <b>Date:</b> 2008-01-15</p>
12262 <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>
12263 <p><b>Discussion:</b></p>
12264 <p>
12265 Table 16 of TR1 requires that all Pseudo Random Number generators have a
12266 </p>
12267
12268 <blockquote><pre>seed(integer-type s)
12269 </pre></blockquote>
12270
12271 <p>
12272 member function that is equivalent to:
12273 </p>
12274
12275 <blockquote><pre>mygen = Generator(s)
12276 </pre></blockquote>
12277
12278 <p>
12279 But the generators <tt>xor_combine</tt> and <tt>discard_block</tt> have no such seed member, only the
12280 </p>
12281
12282 <blockquote><pre>template &lt;class Gen&gt;
12283 seed(Gen&amp;);
12284 </pre></blockquote>
12285
12286 <p>
12287 member, which will not accept an integer literal as an argument: something that appears to violate the intent of Table 16.
12288 </p>
12289
12290 <p>
12291 So... is this a bug in TR1?
12292 </p>
12293
12294 <p>This is a real issue BTW, since the Boost implementation does adhere
12295 to the requirements of Table 16, while at least one commercial
12296 implementation does not and follows a strict adherence to sections
12297 5.1.4.5 and 5.1.4.6 instead.
12298 </p>
12299
12300 <p><i>[
12301 Jens adds:
12302 ]</i></p>
12303
12304
12305 <blockquote>
12306 Both engines do have the necessary
12307 constructor, therefore the omission of the <tt>seed()</tt> member
12308 functions appears to be an oversight.
12309 </blockquote>
12310
12311
12312
12313 <p><b>Proposed resolution:</b></p>
12314 <p>
12315 </p>
12316
12317
12318
12319
12320
12321 <hr>
12322 <h3><a name="787"></a>787. complexity of <tt>binary_search</tt></h3>
12323 <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#Ready">Ready</a>
12324  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-09-08</p>
12325 <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>
12326 <p><b>Discussion:</b></p>
12327 <p>
12328 In 25.3.3.4 [binary.search]/3 the complexity of <tt>binary_search</tt> is described as
12329 </p>
12330
12331 <blockquote>
12332 At most <tt>log(last - first) + 2</tt> comparisons.
12333 </blockquote>
12334
12335 <p>
12336 This should be precised and brought in line with the nomenclature used for
12337 <tt>lower_bound</tt>, <tt>upper_bound</tt>, and <tt>equal_range</tt>.
12338 </p>
12339
12340 <p>
12341 All existing libraries I'm aware of, delegate to
12342 <tt>lower_bound</tt> (+ one further comparison). Since
12343 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>
12344 has now WP status, the resolution of #787 should
12345 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>
12346 to <tt>+ O(1)</tt>.
12347 </p>
12348
12349 <p><i>[
12350 Sophia Antipolis:
12351 ]</i></p>
12352
12353
12354 <blockquote>
12355 Alisdair prefers to apply an upper bound instead of O(1), but that would
12356 require fixing for <tt>lower_bound</tt>, <tt>upper_bound</tt> etc. as well. If he really
12357 cares about it, he'll send an issue to Howard.
12358 </blockquote>
12359
12360
12361
12362 <p><b>Proposed resolution:</b></p>
12363 <p>
12364 Change 25.3.3.4 [binary.search]/3
12365 </p>
12366
12367 <blockquote>
12368 <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.
12369 </blockquote>
12370
12371
12372
12373
12374
12375 <hr>
12376 <h3><a name="788"></a>788. ambiguity in [istream.iterator]</h3>
12377 <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>
12378  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-02-06</p>
12379 <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>
12380 <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>
12381 <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>
12382 <p><b>Discussion:</b></p>
12383 <p>
12384 The description of how an istream_iterator object becomes an
12385 end-of-stream iterator is a) ambiguous and b) out of date WRT
12386 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>:
12387 </p>
12388
12389 <blockquote>
12390 <tt>istream_iterator</tt> reads (using <tt>operator&gt;&gt;</tt>) successive elements from the
12391 input stream for which it was constructed. After it is constructed, and
12392 every time <tt>++</tt> is used, the iterator reads and stores a value of <tt>T</tt>. If
12393 the end of stream is reached (<tt>operator void*()</tt> on the stream returns
12394 <tt>false</tt>), the iterator becomes equal to the <i>end-of-stream</i> iterator value.
12395 The constructor with no arguments <tt>istream_iterator()</tt> always constructs
12396 an end of stream input iterator object, which is the only legitimate
12397 iterator to be used for the end condition. The result of <tt>operator*</tt> on an
12398 end of stream is not defined. For any other iterator value a <tt>const T&amp;</tt> is
12399 returned. The result of <tt>operator-&gt;</tt> on an end of stream is not defined.
12400 For any other iterator value a <tt>const T*</tt> is returned. It is impossible to
12401 store things into istream iterators. The main peculiarity of the istream
12402 iterators is the fact that <tt>++</tt> operators are not equality preserving,
12403 that is, <tt>i == j</tt> does not guarantee at all that <tt>++i == ++j</tt>. Every time <tt>++</tt>
12404 is used a new value is read.
12405 </blockquote>
12406
12407 <p>
12408 <tt>istream::operator void*()</tt> returns null if <tt>istream::fail()</tt> is <tt>true</tt>,
12409 otherwise non-null. <tt>istream::fail()</tt> returns <tt>true</tt> if <tt>failbit</tt> or
12410 <tt>badbit</tt> is set in <tt>rdstate()</tt>. Reaching the end of stream doesn't
12411 necessarily imply that <tt>failbit</tt> or <tt>badbit</tt> is set (e.g., after
12412 extracting an <tt>int</tt> from <tt>stringstream("123")</tt> the stream object will
12413 have reached the end of stream but <tt>fail()</tt> is <tt>false</tt> and <tt>operator
12414 void*()</tt> will return a non-null value).
12415 </p>
12416
12417 <p>
12418 Also I would prefer to be explicit about calling <tt>fail()</tt> here
12419 (there is no <tt>operator void*()</tt> anymore.)
12420 </p>
12421
12422
12423 <p><b>Proposed resolution:</b></p>
12424 <p>
12425 Change 24.5.1 [istream.iterator]/1:
12426 </p>
12427
12428 <blockquote>
12429 <tt>istream_iterator</tt> reads (using <tt>operator&gt;&gt;</tt>) successive elements from the
12430 input stream for which it was constructed. After it is constructed, and
12431 every time <tt>++</tt> is used, the iterator reads and stores a value of <tt>T</tt>. If
12432 <del>the end of stream is reached</del> <ins>the iterator fails to read and store a value of <tt>T</tt></ins>
12433 (<tt><del>operator void*()</del> <ins>fail()</ins></tt> on the stream returns
12434 <tt><del>false</del> <ins>true</ins></tt>), the iterator becomes equal to the <i>end-of-stream</i> iterator value.
12435 The constructor with no arguments <tt>istream_iterator()</tt> always constructs
12436 an end of stream input iterator object, which is the only legitimate
12437 iterator to be used for the end condition. The result of <tt>operator*</tt> on an
12438 end of stream is not defined. For any other iterator value a <tt>const T&amp;</tt> is
12439 returned. The result of <tt>operator-&gt;</tt> on an end of stream is not defined.
12440 For any other iterator value a <tt>const T*</tt> is returned. It is impossible to
12441 store things into istream iterators. The main peculiarity of the istream
12442 iterators is the fact that <tt>++</tt> operators are not equality preserving,
12443 that is, <tt>i == j</tt> does not guarantee at all that <tt>++i == ++j</tt>. Every time <tt>++</tt>
12444 is used a new value is read.
12445 </blockquote>
12446
12447
12448
12449
12450
12451 <hr>
12452 <h3><a name="793"></a>793. <tt>discrete_distribution</tt> missing constructor</h3>
12453 <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>
12454  <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
12455 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.discrete">active issues</a> in [rand.dist.samp.discrete].</p>
12456 <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>
12457 <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>
12458 <p><b>Discussion:</b></p>
12459 <p>
12460 <tt>discrete_distribution</tt> should have a constructor like:
12461 </p>
12462
12463 <blockquote><pre>template&lt;class _Fn&gt;
12464   discrete_distribution(result_type _Count, double _Low, double _High,
12465                         _Fn&amp; _Func);
12466 </pre></blockquote>
12467
12468 <p>
12469 (Makes it easier to fill a histogram with function values over a range.)
12470 </p>
12471
12472 <p><i>[
12473 Bellevue:
12474 ]</i></p>
12475
12476
12477 <blockquote>
12478 How do you specify the function so that it does not return negative
12479 values? If you do it is a bad construction. This requirement is already
12480 there. Where in each bin does one evaluate the function? In the middle.
12481 Need to revisit tomorrow.
12482 </blockquote>
12483
12484 <p><i>[
12485 Sophia Antipolis:
12486 ]</i></p>
12487
12488
12489 <blockquote>
12490 <p>
12491 Bill is not requesting this.
12492 </p>
12493 <p>
12494 Marc Paterno: <tt>_Fn</tt> cannot return negative values at the points where the
12495 function is sampled. It is sampled in the middle of each bin. <tt>_Fn</tt> cannot
12496 return 0 everywhere it is sampled.
12497 </p>
12498 <p>
12499 Jens: lambda expressions are rvalues
12500 </p>
12501 <p>
12502 Add a library issue to provide an
12503 <tt>initializer_list&lt;double&gt;</tt> constructor for
12504 <tt>discrete_distribution</tt>.
12505 </p>
12506 <p>
12507 Marc Paterno: dislikes reference for <tt>_Fn</tt> parameter. Make it pass-by-value (to use lambda),
12508 use <tt>std::ref</tt> to wrap giant-state function objects.
12509 </p>
12510 <p>
12511 Daniel: See <tt>random_shuffle</tt>, pass-by-rvalue-reference.
12512 </p>
12513 <p>
12514 Daniel to draft wording.
12515 </p>
12516 </blockquote>
12517
12518 <p><i>[
12519 Pre San Francisco, Daniel provided wording:
12520 ]</i></p>
12521
12522
12523 <blockquote>
12524 The here proposed changes of the WP refer to the current state of
12525 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>.
12526 During the Sophia Antipolis meeting two different proposals came up
12527 regarding the functor argument type, either by value or by rvalue-reference.
12528 For consistence with existing conventions (state-free algorithms and the
12529 <tt>general_pdf_distribution</tt> c'tor signature) the author decided to propose a
12530 function argument that is provided by value. If severe concerns exists that
12531 stateful functions would be of dominant relevance, it should be possible to
12532 replace the two occurrences of <tt>Func</tt> by <tt>Func&amp;&amp;</tt> in this proposal as part
12533 of an editorial process.
12534 </blockquote>
12535
12536
12537
12538 <p><b>Proposed resolution:</b></p>
12539 <ol>
12540 <li>
12541 <p>
12542 In 26.4.8.5.1 [rand.dist.samp.discrete]/1, class <tt>discrete_distribution</tt>, just
12543 <em>before</em> the member declaration
12544 </p>
12545
12546 <blockquote><pre>explicit discrete_distribution(const param_type&amp; parm);
12547 </pre></blockquote>
12548
12549 <p>
12550 insert:
12551 </p>
12552
12553
12554 <blockquote><pre>template&lt;typename Func&gt;
12555 discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
12556 </pre></blockquote>
12557 </li>
12558
12559 <li>
12560 <p>
12561 Between p.4 and p.5 insert a series of new paragraphs as part of the
12562 new member description::
12563 </p>
12564 <blockquote><pre>template&lt;typename Func&gt;
12565 discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
12566 </pre>
12567
12568 <p>
12569 <i>Complexity:</i> Exactly nf invocations of fw.
12570 </p>
12571 <p>
12572 <i>Requires:</i>
12573 </p>
12574 <ol type="a">
12575 <li>
12576 fw shall be callable with one argument of type double, and shall
12577 return values of a type convertible to double;</li>
12578
12579 <li>If nf &gt; 0, the relation <tt><i>x</i><sub><i>min</i></sub></tt> &lt; <tt><i>x</i><sub><i>max</i></sub></tt> shall hold, and for all sample values
12580 <tt><i>x</i><sub><i>k</i></sub></tt>, fw(<tt><i>x</i><sub><i>k</i></sub></tt>) shall return a weight value <tt><i>w</i><sub><i>k</i></sub></tt> that is non-negative, non-NaN,
12581 and non-infinity;</li>
12582
12583 <li>The following relations shall hold: nf &#8805; 0, and 0 &lt; S = <tt><i>w</i><sub><i>0</i></sub></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.</li>
12584
12585 </ol>
12586
12587 <p>
12588 <i>Effects:</i>
12589 </p>
12590 <ol type="a">
12591 <li>If nf == 0, sets n = 1 and lets the sequence w have length n = 1 and
12592    consist of the single value <tt><i>w</i><sub><i>0</i></sub></tt> = 1.</li>
12593
12594 <li>
12595 <p>Otherwise, sets n = nf, deltax = (<tt><i>x</i><sub><i>max</i></sub></tt> - <tt><i>x</i><sub><i>min</i></sub></tt>)/n and <tt><i>x</i><sub><i>cent</i></sub></tt> = <tt><i>x</i><sub><i>min</i></sub></tt> +
12596 0.5 * deltax.</p>
12597 <blockquote><pre>For each k = 0, . . . ,n-1, calculates:
12598   <tt><i>x</i><sub><i>k</i></sub></tt> = <tt><i>x</i><sub><i>cent</i></sub></tt> + k * deltax
12599   <tt><i>w</i><sub><i>k</i></sub></tt> = fw(<tt><i>x</i><sub><i>k</i></sub></tt>)
12600 </pre></blockquote>
12601 </li>
12602 <li>
12603 <p>Constructs a discrete_distribution object with probabilities:</p>
12604 <blockquote><pre><tt><i>p</i><sub><i>k</i></sub></tt> = <tt><i>w</i><sub><i>k</i></sub></tt>/S  for k = 0, . . . , n-1.
12605 </pre></blockquote>
12606 </li>
12607 </ol>
12608 </blockquote>
12609 </li>
12610 </ol>
12611
12612
12613
12614
12615
12616 <hr>
12617 <h3><a name="794"></a>794. <tt>piecewise_constant_distribution</tt> missing constructor</h3>
12618 <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#Open">Open</a>
12619  <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
12620 <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>
12621 <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>
12622 <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>
12623 <p><b>Discussion:</b></p>
12624 <p>
12625 <tt>piecewise_constant_distribution</tt> should have a constructor like:
12626 </p>
12627
12628 <blockquote><pre>template&lt;class _Fn&gt;
12629    piecewise_constant_distribution(size_t _Count,
12630             _Ty _Low, _Ty _High, _Fn&amp; _Func);
12631 </pre></blockquote>
12632
12633 <p>
12634 (Makes it easier to fill a histogram with function values over a range.
12635 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
12636 <tt>general_pdf_distribution</tt>.)
12637 </p>
12638
12639 <p><i>[
12640 Sophia Antipolis:
12641 ]</i></p>
12642
12643
12644 <blockquote>
12645 <p>
12646 Marc: uses variable width of bins and weight for each bin. This is not
12647 giving enough flexibility to control both variables.
12648 </p>
12649 <p>
12650 Add a library issue to provide an constructor taking an
12651 <tt>initializer_list&lt;double&gt;</tt> and <tt>_Fn</tt> for <tt>piecewise_constant_distribution</tt>.
12652 </p>
12653 <p>
12654 Daniel to draft wording.
12655 </p>
12656 </blockquote>
12657
12658 <p><i>[
12659 Pre San Francisco, Daniel provided wording.
12660 ]</i></p>
12661
12662
12663 <blockquote>
12664 The here proposed changes of the WP refer to the current state of
12665 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>.
12666 For reasons explained in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>, the author decided to propose a function
12667 argument that is provided by value. The issue proposes a c'tor signature,
12668 that does not take advantage of the full flexibility of
12669 <tt>piecewise_constant_distribution</tt>,
12670 because it restricts on a constant bin width, but the use-case seems to
12671 be popular enough to justify it's introduction.
12672 </blockquote>
12673
12674
12675
12676 <p><b>Proposed resolution:</b></p>
12677
12678 <ol>
12679 <li>
12680 <p>
12681 In 26.4.8.5.2 [rand.dist.samp.pconst]/1, class <tt>piecewise_constant_distribution</tt>,
12682 just <em>before</em> the member declaration
12683 </p>
12684
12685 <blockquote><pre>explicit piecewise_constant_distribution(const param_type&amp; parm);
12686 </pre></blockquote>
12687 <p>
12688 insert:
12689 </p>
12690 <blockquote><pre>template&lt;typename Func&gt;
12691 piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
12692 </pre></blockquote>
12693 </li>
12694
12695 <li>
12696 <p>
12697 Between p.4 and p.5 insert a new sequence of paragraphs nominated
12698 below as [p5_1], [p5_2],
12699 [p5_3], and [p5_4] as part of the new member description:
12700 </p>
12701
12702 <blockquote><pre>template&lt;typename Func&gt;
12703 piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
12704 </pre>
12705 <blockquote>
12706 <p>
12707 [p5_1] <i>Complexity:</i> Exactly <tt>nf</tt> invocations of <tt>fw</tt>.
12708 </p>
12709 <p>
12710 [p5_2] <i>Requires:</i>
12711 </p>
12712 <ol type="a">
12713 <li><tt>fw</tt> shall be callable with one argument of type <tt>RealType</tt>, and shall
12714 return values of a type convertible to double;
12715 </li>
12716 <li>
12717 For all sample values <tt><i>x<sub>k</sub></i></tt> defined below, fw(<tt><i>x<sub>k</sub></i></tt>) shall return a weight
12718 value <tt><i>w<sub>k</sub></i></tt> that is non-negative, non-NaN, and non-infinity;
12719 </li>
12720 <li>
12721 The following relations shall hold: <tt><i>x<sub>min</sub></i></tt> &lt; <tt><i>x<sub>max</sub></i></tt>, and
12722 0 &lt; S = <tt><i>w<sub>0</sub></i></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.
12723 </li>
12724 </ol>
12725 <p>
12726 [p5_3] <i>Effects:</i>
12727 </p>
12728 <ol type="a">
12729 <li>
12730 <p>If nf == 0,</p>
12731  <ol type="a">
12732  <li>
12733 sets deltax = <tt><i>x<sub>max</sub></i></tt> - <tt><i>x<sub>min</sub></i></tt>, and</li>
12734 <li> lets the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist of the single
12735     value <tt><i>w<sub>0</sub></i></tt> = 1, and</li>
12736 <li> lets the sequence <tt>b</tt> have length <tt>n+1</tt> with <tt><i>b<sub>0</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> and
12737               <tt><i>b<sub>1</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt>
12738 </li>
12739 </ol>
12740 </li>
12741 <li>
12742 <p>Otherwise,</p>
12743 <ol type="a">
12744 <li> sets <tt>n = nf</tt>, <tt>deltax = </tt>(<tt><i>x<sub>max</sub></i></tt> - <tt><i>x<sub>min</sub></i></tt>)/n,
12745                  <tt><i>x<sub>cent</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> + 0.5 * deltax, and
12746 </li>
12747 <li><p>lets the sequences <tt>w</tt> and <tt>b</tt> have length <tt>n</tt> and <tt>n+1</tt>, resp. and</p>
12748 <blockquote><pre>for each k = 0, . . . ,n-1, calculates:
12749   <tt><i>dx<sub>k</sub></i></tt> = k * deltax
12750   <tt><i>b<sub>k</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> + <tt><i>dx<sub>k</sub></i></tt>
12751   <tt><i>x<sub>k</sub></i></tt> = <tt><i>x<sub>cent</sub></i></tt> + <tt><i>dx<sub>k</sub></i></tt>
12752   <tt><i>w<sub>k</sub></i></tt> = fw(<tt><i>x<sub>k</sub></i></tt>),
12753 </pre></blockquote>
12754 <p> and</p>
12755 </li>
12756 <li> sets <tt><i>b<sub>n</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt></li>
12757 </ol>
12758 </li>
12759 <li>
12760 <p>
12761 Constructs a <tt>piecewise_constant_distribution</tt> object with
12762 the above computed sequence <tt>b</tt> as the interval boundaries
12763 and with the probability densities:
12764 </p>
12765 <blockquote><pre><tt><i>&#961;<sub>k</sub></i></tt> = <tt><i>w<sub>k</sub></i></tt>/(S * deltax)  for k = 0, . . . , n-1.
12766 </pre></blockquote>
12767 </li>
12768 </ol>
12769 <p>
12770 [p5_4] <i>Remarks:</i> In this context, the subintervals [<tt><i>b<sub>k</sub></i></tt>, <tt><i>b<sub>k+1</sub></i></tt>) are commonly
12771  known as the <i>bins</i> of a histogram.
12772  </p>
12773 </blockquote>
12774 </blockquote>
12775 </li>
12776 </ol>
12777
12778
12779
12780
12781
12782
12783 <hr>
12784 <h3><a name="800"></a>800. Issues in 26.4.7.1 [rand.util.seedseq](6)</h3>
12785 <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>
12786  <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2008-02-18</p>
12787 <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>
12788 <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>
12789 <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>
12790 <p><b>Discussion:</b></p>
12791 <p>
12792 The for-loop in the algorithm specification has <tt>n</tt> iterations, where <tt>n</tt> is
12793 defined to be <tt>end - begin</tt>, i.e. the number of supplied w-bit quantities.
12794 Previous versions of this algorithm and the general logic behind it
12795 suggest that this is an oversight and that in the context of the
12796 for-loop <tt>n</tt> should be the number of full 32-bit quantities in <tt>b</tt> (rounded
12797 upwards). If <tt>w</tt> is 64, the current algorithm throws away half of all bits
12798 in <tt>b</tt>. If <tt>w</tt> is 16, the current algorithm sets half of all elements in <tt>v</tt>
12799 to 0.
12800 </p>
12801
12802 <p>
12803 There are two more minor issues:
12804 </p>
12805
12806 <ul>
12807 <li>
12808 Strictly speaking <tt>end - begin</tt> is not defined since
12809 <tt>InputIterator</tt> is not required to be a random access iterator.
12810 </li>
12811 <li>
12812 Currently all integral types are allowed as input to the <tt>seed_seq</tt>
12813 constructor, including <tt>bool</tt>. IMHO allowing <tt>bool</tt>s unnecessarily
12814 complicates the implementation without any real benefit to the user.
12815 I'd suggest to exclude <tt>bool</tt>s as input.
12816 </li>
12817 </ul>
12818
12819 <p><i>[
12820 Bellevue:
12821 ]</i></p>
12822
12823
12824 <blockquote>
12825 Move to OPEN Bill will try to propose a resolution by the next meeting.
12826 </blockquote>
12827
12828 <p><i>[
12829 post Bellevue:  Bill provided wording.
12830 ]</i></p>
12831
12832
12833 <p>
12834 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.
12835 </p>
12836
12837
12838
12839 <p><b>Proposed resolution:</b></p>
12840 <p>
12841 Replace 26.4.7.1 [rand.util.seedseq] paragraph 6 with:
12842 </p>
12843
12844 <blockquote>
12845 <p>
12846 <i>Effects:</i> Constructs a <tt>seed_seq</tt> object by effectively concatenating the
12847 low-order <tt>u</tt> bits of each of the elements of the supplied sequence <tt>[begin,
12848 end)</tt>
12849 in ascending order of significance to make a (possibly very large) unsigned
12850 binary number <tt>b</tt> having a total of <tt>n</tt> bits, and then carrying out the
12851 following
12852 algorithm:
12853 </p>
12854
12855 <blockquote><pre>for( v.clear(); n &gt; 0; n -= 32 )
12856    v.push_back(b mod 2<sup>32</sup>), b /= 2<sup>32</sup>;
12857 </pre></blockquote>
12858 </blockquote>
12859
12860
12861
12862
12863
12864 <hr>
12865 <h3><a name="801"></a>801. <tt>tuple</tt> and <tt>pair</tt> trivial members</h3>
12866 <p><b>Section:</b> 20.4 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
12867  <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-02-18</p>
12868 <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>
12869 <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>
12870 <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>
12871 <p><b>Discussion:</b></p>
12872 <p>
12873 Classes with trivial special member functions are inherently more
12874 efficient than classes without such functions.  This efficiency is
12875 particularly pronounced on modern ABIs that can pass small classes
12876 in registers.  Examples include value classes such as complex numbers
12877 and floating-point intervals.  Perhaps more important, though, are
12878 classes that are simple collections, like <tt>pair</tt> and <tt>tuple</tt>.  When the
12879 parameter types of these classes are trivial, the <tt>pair</tt>s and <tt>tuple</tt>s
12880 themselves can be trivial, leading to substantial performance wins.
12881 </p>
12882 <p>
12883 The current working draft make specification of trivial functions
12884 (where possible) much easer through <tt>default</tt>ed and <tt>delete</tt>d functions.
12885 As long as the semantics of defaulted and deleted functions match
12886 the intended semantics, specification of defaulted and deleted
12887 functions will yield more efficient programs.
12888 </p>
12889 <p>
12890 There are at least two cases where specification of an explicitly
12891 defaulted function may be desirable.
12892 </p>
12893 <p>
12894 First, the <tt>std::pair</tt> template has a non-trivial default constructor,
12895 which prevents static initialization of the pair even when the
12896 types are statically initializable.  Changing the definition to
12897 </p>
12898
12899 <blockquote><pre>pair() = default;
12900 </pre></blockquote>
12901
12902 <p>
12903 would enable such initialization.  Unfortunately, the change is
12904 not semantically neutral in that the current definition effectively
12905 forces value initialization whereas the change would not value
12906 initialize in some contexts.
12907 </p>
12908
12909 <p>
12910 ** Does the committee confirm that forced value initialization
12911 was the intent?  If not, does the committee wish to change the
12912 behavior of <tt>std::pair</tt> in C++0x?
12913 </p>
12914 <p>
12915 Second, the same default constructor issue applies to <tt>std::tuple</tt>.
12916 Furthermore, the <tt>tuple</tt> copy constructor is current non-trivial,
12917 which effectively prevents passing it in registers.  To enable
12918 passing <tt>tuples</tt> in registers, the copy constructor should be
12919 make explicitly <tt>default</tt>ed.  The new declarations are:
12920 </p>
12921
12922 <blockquote><pre>tuple() = default;
12923 tuple(const tuple&amp;) = default;
12924 </pre></blockquote>
12925
12926 <p>
12927 This changes is not implementation neutral.  In particular, it
12928 prevents implementations based on pointers to the parameter
12929 types.  It does however, permit implementations using the
12930 parameter types as bases.
12931 </p>
12932 <p>
12933 ** How does the committee wish to trade implementation
12934 efficiency versus implementation flexibility?
12935 </p>
12936
12937 <p><i>[
12938 Bellevue:
12939 ]</i></p>
12940
12941
12942 <blockquote>
12943 <p>
12944 General agreement; the first half of the issue is NAD.
12945 </p>
12946 <p>
12947 Before voting on the second half, it was agreed that a "Strongly Favor"
12948 vote meant support for trivial tuples (assuming usual requirements met),
12949 even at the expense of other desired qualities. A "Weakly Favor" vote
12950 meant support only if not at the expense of other desired qualities.
12951 </p>
12952 <p>
12953 Concensus: Go forward, but not at expense of other desired qualities.
12954 </p>
12955 <p>
12956 It was agreed to Alisdair should fold this work in with his other
12957 pair/tuple action items, above, and that issue 801 should be "open", but
12958 tabled until Alisdair's proposals are disposed of.
12959 </p>
12960 </blockquote>
12961
12962
12963 <p><b>Proposed resolution:</b></p>
12964 <p>
12965 </p>
12966
12967
12968
12969
12970
12971 <hr>
12972 <h3><a name="803"></a>803. Simplification of <tt>seed_seq::seq_seq</tt></h3>
12973 <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#Review">Review</a>
12974  <b>Submitter:</b> Charles Karney <b>Date:</b> 2008-02-22</p>
12975 <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>
12976 <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>
12977 <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>
12978 <p><b>Discussion:</b></p>
12979 <p>
12980 <tt>seed_seq(InputIterator begin, InputIterator end);</tt> constructs a <tt>seed_seq</tt>
12981 object repacking the bits of supplied sequence <tt>[begin, end)</tt> into a
12982 32-bit vector.
12983 </p>
12984 <p>
12985 This repacking triggers several problems:
12986 </p>
12987 <ol>
12988 <li>
12989 Distinctness of the output of <tt>seed_seq::generate</tt> required the
12990 introduction of the initial "<tt>if (w &lt; 32) v.push_back(n);</tt>"  (Otherwise
12991 the unsigned short vectors [1, 0] and [1] generate the same sequence.)
12992 </li>
12993 <li>
12994 Portability demanded the introduction of the template parameter <tt>u</tt>.
12995 (Otherwise some sequences could not be obtained on computers where no
12996 integer types are exactly 32-bits wide.)
12997 </li>
12998 <li>
12999 The description and algorithm have become unduly complicated.
13000 </li>
13001 </ol>
13002 <p>
13003 I propose simplifying this <tt>seed_seq</tt> constructor to be "32-bit only".
13004 Despite it's being simpler, there is NO loss of functionality (see
13005 below).
13006 </p>
13007 <p>
13008 Here's how the description would read
13009 </p>
13010 <blockquote>
13011 <p>
13012 26.4.7.1 [rand.util.seedseq] Class <tt>seed_seq</tt>
13013 </p>
13014
13015 <blockquote>
13016 <pre>template&lt;class InputIterator&gt;
13017   seed_seq(InputIterator begin, InputIterator end);
13018 </pre>
13019 <blockquote>
13020 <p>
13021 5 <i>Requires:</i> NO CHANGE
13022 </p>
13023 <p>
13024 6 <i>Effects:</i> Constructs a <tt>seed_seq</tt> object by
13025 </p>
13026 <blockquote>
13027 <pre>for (InputIterator s = begin; s != end; ++s)
13028    v.push_back((*s) mod 2^32);
13029 </pre>
13030 </blockquote>
13031 </blockquote>
13032 </blockquote>
13033 </blockquote>
13034
13035 <p>
13036 Discussion:
13037 </p>
13038 <p>
13039 The chief virtues here are simplicity, portability, and generality.
13040 </p>
13041 <ul>
13042 <li>
13043 Simplicity -- compare the above specification with the
13044 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a> proposal.
13045 </li>
13046 <li>
13047 Portability -- with <tt>iterator_traits&lt;InputIterator&gt;::value_type =
13048 uint_least32_t</tt> the user is guaranteed to get the same behavior across
13049 platforms.
13050 </li>
13051 <li>
13052 Generality -- any behavior that the
13053 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
13054 proposal can achieve can be
13055 obtained with this simpler proposal (albeit with a shuffling of bits
13056 in the input sequence).
13057 </li>
13058 </ul>
13059 <p>
13060 Arguments (and counter-arguments) against making this change (and
13061 retaining the
13062 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
13063 behavior) are:
13064 </p>
13065 <ul>
13066 <li>
13067 <p>
13068 The user can pass an array of <tt>unsigned char</tt> and <tt>seed_seq</tt> will nicely
13069  repack it.
13070 </p>
13071 <p>
13072  Response: So what?  Consider the seed string "ABC".  The
13073  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
13074  proposal results in
13075 </p>
13076 <blockquote><pre>v = { 0x3, 0x434241 };
13077 </pre></blockquote>
13078 <p>
13079 while the simplified proposal yields
13080 </p>
13081 <blockquote><pre>v = { 0x41, 0x42, 0x43 };
13082 </pre></blockquote>
13083 <p>
13084 The results produced by <tt>seed_seq::generate</tt> with the two inputs are
13085 different but nevertheless equivalently "mixed up" and this remains
13086 true even if the seed string is long.
13087 </p>
13088 </li>
13089 <li>
13090 <p>
13091 With long strings (e.g., with bit-length comparable to the number of
13092  bits in the state), <tt>v</tt> is longer (by a factor of 4) with the simplified
13093  proposal and <tt>seed_seq::generate</tt> will be slower.
13094 </p>
13095 <p>
13096 Response: It's unlikely that the efficiency of <tt>seed_seq::generate</tt> will
13097  be a big issue.  If it is, the user is free to repack the seed vector
13098  before constructing <tt>seed_seq</tt>.
13099 </p>
13100 </li>
13101 <li>
13102 <p>
13103 A user can pass an array of 64-bit integers and all the bits will be
13104  used.
13105 </p>
13106 <p>
13107  Response: Indeed.  However, there are many instances in the
13108  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
13109  where integers are silently coerced to a narrower width and this
13110  should just be a case of the user needing to read the documentation.
13111  The user can of course get equivalent behavior by repacking his seed
13112  into 32-bit pieces.  Furthermore, the unportability of the
13113  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
13114  proposal with
13115 </p>
13116 <blockquote><pre>unsigned long s[] = {1, 2, 3, 4};
13117 seed_seq q(s, s+4);
13118 </pre></blockquote>
13119 <p>
13120  which typically results in <tt>v = {1, 2, 3, 4}</tt> on 32-bit machines and in
13121 <tt>v = {1, 0, 2, 0, 3, 0, 4, 0}</tt> on 64-bit machines is a major pitfall for
13122  unsuspecting users.
13123 </p>
13124 </li>
13125 </ul>
13126
13127 <p>
13128 Note: this proposal renders moot issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>.
13129 </p>
13130
13131 <p><i>[
13132 Bellevue:
13133 ]</i></p>
13134
13135
13136 <blockquote>
13137 Walter needs to ask Fermilab for guidance. Defer till tomorrow. Bill likes the proposed resolution.
13138 </blockquote>
13139
13140 <p><i>[
13141 Sophia Antipolis:
13142 ]</i></p>
13143
13144
13145 <blockquote>
13146 <p>
13147 Marc Paterno wants portable behavior between 32bit and 64bit machines;
13148 we've gone to significant trouble to support portability of engines and
13149 their values.
13150 </p>
13151 <p>
13152 Jens: the new algorithm looks perfectly portable
13153 </p>
13154 <p>
13155 Marc Paterno to review off-line.
13156 </p>
13157 <p>
13158 Modify the proposed resolution to read "Constructs a seed_seq object by the following algorithm ..."
13159 </p>
13160 <p>
13161 Disposition: move to review; unanimous consent.
13162 </p>
13163 <p>
13164 (moots <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>)
13165 </p>
13166 </blockquote>
13167
13168
13169
13170 <p><b>Proposed resolution:</b></p>
13171 <p>
13172 Change 26.4.7.1 [rand.util.seedseq]:
13173 </p>
13174
13175 <blockquote>
13176 <pre>template&lt;class InputIterator<del>,
13177   size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</del>&gt;
13178   seed_seq(InputIterator begin, InputIterator end);
13179 </pre>
13180 <blockquote>
13181 <p>
13182 -5- <i>Requires:</i> <tt>InputIterator</tt> shall satisfy the requirements of an input iterator (24.1.1)
13183 such that <tt>iterator_traits&lt;InputIterator&gt;::value_type</tt> shall denote an integral type.
13184 </p>
13185 <p>
13186 -6- Constructs a <tt>seed_seq</tt> object by <ins>the following algorithm</ins> <del>rearranging some or all of the bits of the supplied sequence
13187 <tt>[begin,end)</tt> of w-bit quantities into 32-bit units, as if by the following: </del>
13188 </p>
13189 <p>
13190 <del>First extract the rightmost <tt>u</tt> bits from each of the <tt>n = end
13191 - begin</tt> elements of the supplied sequence and concatenate all the
13192 extracted bits to initialize a single (possibly very large) unsigned
13193 binary number, <tt>b = &#8721;<sup>n-1</sup><sub>i=0</sub> (begin[i]
13194 mod 2<sup>u</sup>) · 2<sup>w·i</sup></tt> (in which the bits of each <tt>begin[i]</tt>
13195 are treated as denoting an unsigned quantity). Then carry out
13196 the following algorithm:</del>
13197 </p>
13198 <blockquote><pre><del>
13199 v.clear();
13200 if ($w$ &lt; 32)
13201   v.push_back($n$);
13202 for( ; $n$ &gt; 0; --$n$)
13203   v.push_back(b mod 2<sup>32</sup>), b /= 2<sup>32</sup>;
13204 </del></pre></blockquote>
13205 <blockquote>
13206 <pre><ins>
13207 for (InputIterator s = begin; s != end; ++s)
13208    v.push_back((*s) mod 2<sup>32</sup>);
13209 </ins></pre>
13210 </blockquote>
13211 </blockquote>
13212 </blockquote>
13213
13214
13215
13216
13217
13218 <hr>
13219 <h3><a name="804"></a>804. Some problems with classes <tt>error_code</tt>/<tt>error_condition</tt></h3>
13220 <p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
13221  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-02-24</p>
13222 <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>
13223 <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>
13224 <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>
13225 <p><b>Discussion:</b></p>
13226 <ol type="A">
13227 <li>
13228 <p>
13229 19.4.2.1 [syserr.errcode.overview]/1, class <tt>error_code</tt> and
13230 19.4.3.1 [syserr.errcondition.overview]/, class <tt>error_condition</tt> synopses
13231 declare an expository data member <tt>cat_</tt>:
13232 </p>
13233 <blockquote><pre>const error_category&amp; cat_; // exposition only
13234 </pre></blockquote>
13235 <p>
13236 which is used to define the semantics of several members. The decision
13237 to use a member of reference type lead to several problems:
13238 </p>
13239 <ol>
13240 <li>
13241 The classes are not <tt>(Copy)Assignable</tt>, which is probably not the intent.
13242 </li>
13243 <li>
13244 The post conditions of all modifiers from
13245 19.4.2.3 [syserr.errcode.modifiers] and 19.4.3.3 [syserr.errcondition.modifiers], resp.,
13246 cannot be fulfilled.
13247 </li>
13248 </ol>
13249 <p>
13250 The simple fix would be to replace the reference by a pointer member.
13251 </p>
13252 </li>
13253
13254 <li>
13255 I would like to give the editorial remark that in both classes the
13256 constrained <tt>operator=</tt>
13257 overload (template with <tt>ErrorCodeEnum</tt> argument) makes in invalid
13258 usage of <tt>std::enable_if</tt>: By using the default value for the second <tt>enable_if</tt>
13259 parameter the return type would be defined to be <tt>void&amp;</tt> even in otherwise
13260 valid circumstances - this return type must be explicitly provided (In
13261 <tt>error_condition</tt> the first declaration uses an explicit value, but of wrong
13262 type).
13263 </li>
13264
13265 <li>
13266 The member function <tt>message</tt> throws clauses (
13267 19.4.1.2 [syserr.errcat.virtuals]/10, 19.4.2.4 [syserr.errcode.observers]/8, and
13268 19.4.3.4 [syserr.errcondition.observers]/6) guarantee "throws nothing",
13269 although
13270 they return a <tt>std::string</tt> by value, which might throw in out-of-memory
13271 conditions (see related issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>).
13272 </li>
13273 </ol>
13274
13275 <p><i>[
13276 Sophia Antipolis:
13277 ]</i></p>
13278
13279
13280 <blockquote>
13281 <p>
13282 Part A: NAD (editorial), cleared by the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>.
13283 </p>
13284 <p>
13285 Part B: Technically correct, save for typo. Rendered moot by the concept proposal
13286 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2620.html">N2620</a>) NAD (editorial).
13287 </p>
13288 <p>
13289 Part C: We agree; this is consistent with the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>.
13290 </p>
13291 <p>
13292 Howard: please ping Beman, asking him to clear away parts A and B from
13293 the wording in the proposed resolution, so it is clear to the editor
13294 what needs to be applied to the working paper.
13295 </p>
13296 <p>
13297 Beman provided updated wording. Since issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a> is not going
13298 forward, the provided wording includes resolution of part A.
13299 </p>
13300 </blockquote>
13301
13302
13303
13304 <p><b>Proposed resolution:</b></p>
13305
13306 <p>
13307 Resolution of part A:
13308 </p>
13309 <blockquote>
13310 <p>
13311 Change 19.4.2.1 [syserr.errcode.overview] Class error_code overview synopsis as indicated:
13312 </p>
13313
13314 <blockquote><pre>private:
13315   int val_;                    // exposition only
13316   const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
13317 </pre></blockquote>
13318
13319 <p>
13320 Change 19.4.2.2 [syserr.errcode.constructors] Class error_code constructors as indicated:
13321 </p>
13322
13323 <blockquote>
13324 <pre>error_code();
13325 </pre>
13326 <blockquote>
13327 <p>
13328 <i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
13329 </p>
13330 <p>
13331 <i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&amp;</ins>system_category</tt>.
13332 </p>
13333 <p>
13334 <i>Throws:</i> Nothing.
13335 </p>
13336 </blockquote>
13337 <pre>error_code(int val, const error_category&amp; cat);
13338 </pre>
13339 <blockquote>
13340 <p>
13341 <i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
13342 </p>
13343 <p>
13344 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
13345 </p>
13346 <p>
13347 <i>Throws:</i> Nothing.
13348 </p>
13349 </blockquote>
13350 </blockquote>
13351
13352 <p>
13353 Change 19.4.2.3 [syserr.errcode.modifiers] Class error_code modifiers as indicated:
13354 </p>
13355
13356 <blockquote>
13357 <pre>void assign(int val, const error_category&amp; cat);
13358 </pre>
13359 <blockquote>
13360 <p>
13361 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
13362 </p>
13363 <p>
13364 <i>Throws:</i> Nothing.
13365 </p>
13366 </blockquote>
13367 </blockquote>
13368
13369 <p>
13370 Change 19.4.2.4 [syserr.errcode.observers] Class error_code observers as indicated:
13371 </p>
13372
13373 <blockquote>
13374 const error_category&amp; category() const;
13375 <blockquote>
13376 <p>
13377 <i>Returns:</i> <tt><ins>*</ins>cat_</tt>.
13378 </p>
13379 <p>
13380 <i>Throws:</i> Nothing.
13381 </p>
13382 </blockquote>
13383 </blockquote>
13384
13385 <p>
13386 Change 19.4.3.1 [syserr.errcondition.overview] Class error_condition overview synopsis as indicated:
13387 </p>
13388
13389 <blockquote><pre>private:
13390   int val_;                    // exposition only
13391   const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
13392 </pre></blockquote>
13393
13394 <p>
13395 Change 19.4.3.2 [syserr.errcondition.constructors] Class error_condition constructors as indicated:
13396 </p>
13397 <p><i>[
13398 (If the proposed resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a> has already been applied, the
13399 name <tt>posix_category</tt> will have been changed to <tt>generic_category</tt>. That has
13400 no effect on this resolution.)
13401 ]</i></p>
13402
13403
13404 <blockquote>
13405 <pre>error_condition();
13406 </pre>
13407 <blockquote>
13408 <p>
13409 <i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
13410 </p>
13411 <p>
13412 <i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&amp;</ins>posix_category</tt>.
13413 </p>
13414 <p>
13415 <i>Throws:</i> Nothing.
13416 </p>
13417 </blockquote>
13418 <pre>error_condition(int val, const error_category&amp; cat);
13419 </pre>
13420 <blockquote>
13421 <p>
13422 <i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
13423 </p>
13424 <p>
13425 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
13426 </p>
13427 <p>
13428 <i>Throws:</i> Nothing.
13429 </p>
13430 </blockquote>
13431 </blockquote>
13432
13433 <p>
13434 Change 19.4.3.3 [syserr.errcondition.modifiers] Class error_condition modifiers as indicated:
13435 </p>
13436
13437 <blockquote>
13438 void assign(int val, const error_category&amp; cat);
13439 <blockquote>
13440 <p>
13441 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
13442 </p>
13443 <p>
13444 <i>Throws:</i> Nothing.
13445 </p>
13446 </blockquote>
13447 </blockquote>
13448
13449 <p>
13450 Change 19.4.3.4 [syserr.errcondition.observers] Class error_condition observers as indicated:
13451 </p>
13452
13453 <blockquote>
13454 const error_category&amp; category() const;
13455 <blockquote>
13456 <p>
13457 <i>Returns:</i> <tt><ins>*</ins>cat_</tt>.
13458 </p>
13459 <p>
13460 <i>Throws:</i> Nothing.
13461 </p>
13462 </blockquote>
13463 </blockquote>
13464 </blockquote>
13465
13466 <p>
13467 Resolution of part C:
13468 </p>
13469
13470 <blockquote>
13471
13472 <p>
13473 In 19.4.1.2 [syserr.errcat.virtuals], remove the throws clause p. 10.
13474 </p>
13475
13476 <blockquote>
13477 <pre>virtual string message(int ev) const = 0;
13478 </pre>
13479
13480 <blockquote>
13481 <p>
13482 <i>Returns:</i> A string that describes the error condition denoted by <tt>ev</tt>.
13483 </p>
13484 <p>
13485 <del><i>Throws:</i> Nothing.</del>
13486 </p>
13487 </blockquote>
13488 </blockquote>
13489
13490 <p>
13491 In 19.4.2.4 [syserr.errcode.observers], remove the throws clause p. 8.
13492 </p>
13493
13494 <blockquote>
13495 <pre>string message() const;
13496 </pre>
13497 <blockquote>
13498 <p>
13499 <i>Returns:</i> <tt>category().message(value())</tt>.
13500 </p>
13501 <p>
13502 <del><i>Throws:</i> Nothing.</del>
13503 </p>
13504 </blockquote>
13505 </blockquote>
13506
13507 <p>
13508 In 19.4.3.4 [syserr.errcondition.observers], remove the throws clause p. 6.
13509 </p>
13510
13511 <blockquote>
13512 <pre>string message() const;
13513 </pre>
13514 <blockquote>
13515 <p>
13516 <i>Returns:</i> <tt>category().message(value())</tt>.
13517 </p>
13518 <p>
13519 <del><i>Throws:</i> Nothing.</del>
13520 </p>
13521 </blockquote>
13522 </blockquote>
13523
13524 </blockquote>
13525
13526
13527
13528
13529
13530
13531 <hr>
13532 <h3><a name="805"></a>805. <tt>posix_error::posix_errno</tt> concerns</h3>
13533 <p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
13534  <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-02-24</p>
13535 <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>
13536 <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>
13537 <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>
13538 <p><b>Discussion:</b></p>
13539 <p>
13540 19.4 [syserr]
13541 </p>
13542
13543 <blockquote><pre>namespace posix_error {
13544   enum posix_errno {
13545     address_family_not_supported, // EAFNOSUPPORT
13546     ...
13547 </pre></blockquote>
13548
13549 <p>
13550 should rather use the new scoped-enum  facility (7.2 [dcl.enum]),
13551 which would avoid the necessity for a new <tt>posix_error</tt>
13552 namespace, if I understand correctly.
13553 </p>
13554
13555 <p><i>[
13556 Further discussion:
13557 ]</i></p>
13558
13559
13560 <blockquote>
13561 <p>
13562 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf">N2347</a>,
13563 Strongly Typed Enums, since renamed Scoped Enums.
13564 </p>
13565 <p>
13566 Alberto Ganesh Barbati also raised this issue in private email, and also proposed the scoped-enum solution.
13567 </p>
13568 <p>
13569 Nick Stoughton asked in Bellevue that <tt>posix_error</tt> and <tt>posix_errno</tt> not be used as names. The LWG agreed.
13570 </p>
13571 <p>
13572 The wording for the Proposed resolution was provided by Beman Dawes.
13573 </p>
13574 </blockquote>
13575
13576
13577 <p><b>Proposed resolution:</b></p>
13578 <p>
13579 Change System error support 19.4 [syserr] as indicated:
13580 </p>
13581
13582 <blockquote><pre><del>namespace posix_error {</del>
13583   enum <del>posix_errno</del> <ins>class errc</ins> {
13584     address_family_not_supported, // EAFNOSUPPORT
13585     ...
13586     wrong_protocol_type, // EPROTOTYPE
13587   };
13588 <del>} // namespace posix_error</del>
13589
13590 template &lt;&gt; struct is_error_condition_enum&lt;<del>posix_error::posix_errno</del> <ins>errc</ins>&gt;
13591   : public true_type {}
13592
13593 <del>namespace posix_error {</del>
13594   error_code make_error_code(<del>posix_errno</del> <ins>errc</ins> e);
13595   error_condition make_error_condition(<del>posix_errno</del> <ins>errc</ins> e);
13596 <del>} // namespace posix_error</del>
13597 </pre></blockquote>
13598
13599 <p>
13600 Change System error support 19.4 [syserr] :
13601 </p>
13602
13603 <blockquote>
13604 <del>The <tt>is_error_code_enum</tt> and <tt>is_error_condition_enum</tt> templates may be
13605 specialized for user-defined types to indicate that such a type is
13606 eligible for class <tt>error_code</tt> and class <tt>error_condition</tt> automatic
13607 conversions, respectively.</del>
13608 </blockquote>
13609
13610 <p>
13611 Change System error support 19.4 [syserr] and its subsections:
13612 </p>
13613
13614 <blockquote>
13615 <ul>
13616 <li>
13617 remove all occurrences of <tt>posix_error::</tt>
13618 </li>
13619 <li>
13620 change all instances of <tt>posix_errno</tt> to <tt>errc</tt>
13621 </li>
13622 <li>
13623 change all instances of <tt>posix_category</tt> to <tt>generic_category</tt>
13624 </li>
13625 <li>
13626 change all instances of <tt>get_posix_category</tt> to <tt>get_generic_category</tt>
13627 </li>
13628 </ul>
13629 </blockquote>
13630
13631 <p>
13632 Change Error category objects 19.4.1.5 [syserr.errcat.objects], paragraph 2:
13633 </p>
13634
13635 <blockquote>
13636 <i>Remarks:</i> The object's <tt>default_error_condition</tt> and equivalent virtual
13637 functions shall behave as specified for the class <tt>error_category</tt>. The
13638 object's name virtual function shall return a pointer to the string
13639 <del>"POSIX"</del> <ins>"GENERIC"</ins>.
13640 </blockquote>
13641
13642 <p>
13643 Change 19.4.2.5 [syserr.errcode.nonmembers] Class <tt>error_code</tt> non-member functions as indicated:
13644 </p>
13645
13646 <blockquote>
13647 <pre>error_code make_error_code(<del>posix_errno</del> <ins>errc</ins> e);
13648 </pre>
13649
13650 <blockquote>
13651 <i>Returns:</i> <tt>error_code(<ins>static_cast&lt;int&gt;(</ins>e<ins>)</ins>, <del>posix</del><ins>generic</ins>_category)</tt>.
13652 </blockquote>
13653 </blockquote>
13654
13655 <p>
13656 Change 19.4.3.5 [syserr.errcondition.nonmembers] Class <tt>error_condition</tt> non-member functions as indicated:
13657 </p>
13658
13659 <blockquote>
13660 <pre>error_condition make_error_condition(<del>posix_errno</del> <ins>errc</ins> e);
13661 </pre>
13662
13663 <blockquote>
13664 <i>Returns:</i> <tt>error_condition(<ins>static_cast&lt;int&gt;(</ins>e<ins>)</ins>, <del>posix</del><ins>generic</ins>_category)</tt>.
13665 </blockquote>
13666 </blockquote>
13667
13668
13669
13670 <p><b>Rationale:</b></p>
13671 <table border="1">
13672 <tbody><tr>
13673 <th colspan="2">Names Considered</th>
13674 </tr>
13675
13676 <tr>
13677 <td><tt>portable</tt></td>
13678 <td>
13679 Too non-specific. Did not wish to reserve such a common word in
13680 namespace std. Not quite the right meaning, either.
13681 </td>
13682 </tr>
13683
13684 <tr>
13685 <td><tt>portable_error</tt></td>
13686 <td>
13687 Too long. Explicit qualification is always required for scoped enums, so
13688 a short name is desirable. Not quite the right meaning, either. May be
13689 misleading because <tt>*_error</tt> in the std lib is usually an exception class
13690 name.
13691 </td>
13692 </tr>
13693
13694 <tr>
13695 <td><tt>std_error</tt></td>
13696 <td>
13697 Fairly short, yet explicit. But in fully qualified names like
13698 <tt>std::std_error::not_enough_memory</tt>, the std_ would be unfortunate. Not
13699 quite the right meaning, either. May be misleading because <tt>*_error</tt> in
13700 the std lib is usually an exception class name.
13701 </td>
13702 </tr>
13703
13704 <tr>
13705 <td><tt>generic</tt></td>
13706 <td>
13707 Short enough. The category could be <tt>generic_category</tt>. Fully qualified
13708 names like <tt>std::generic::not_enough_memory</tt> read well. Reserving in
13709 namespace std seems dicey.
13710 </td>
13711 </tr>
13712
13713 <tr>
13714 <td><tt>generic_error</tt></td>
13715 <td>
13716 Longish. The category could be <tt>generic_category</tt>. Fully qualified names
13717 like <tt>std::generic_error::not_enough_memory</tt> read well. Misleading because
13718 <tt>*_error</tt> in the std lib is usually an exception class name.
13719 </td>
13720 </tr>
13721
13722 <tr>
13723 <td><tt>generic_err</tt></td>
13724 <td>
13725 A bit less longish. The category could be <tt>generic_category</tt>. Fully
13726 qualified names like <tt>std::generic_err::not_enough_memory</tt> read well.
13727 </td>
13728 </tr>
13729
13730 <tr>
13731 <td><tt>gen_err</tt></td>
13732 <td>
13733 Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
13734 names like <tt>std::gen_err::not_enough_memory</tt> read well.
13735 </td>
13736 </tr>
13737
13738 <tr>
13739 <td><tt>generr</tt></td>
13740 <td>
13741 Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
13742 names like <tt>std::generr::not_enough_memory</tt> read well.
13743 </td>
13744 </tr>
13745
13746 <tr>
13747 <td><tt>error</tt></td>
13748 <td>
13749 Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
13750 names like <tt>std::error::not_enough_memory</tt> read well. Do we want to use
13751 this general a name?
13752 </td>
13753 </tr>
13754
13755 <tr>
13756 <td><tt>err</tt></td>
13757 <td>
13758 Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
13759 names like <tt>std::err::not_enough_memory</tt> read well. Although alone it
13760 looks odd as a name, given the existing <tt>errno</tt> and <tt>namespace std</tt> names,
13761 it seems fairly intuitive.
13762 Problem: <tt>err</tt> is used throughout the standard library as an argument name
13763 and in examples as a variable name; it seems too confusing to add yet
13764 another use of the name.
13765 </td>
13766 </tr>
13767
13768 <tr>
13769 <td><tt>errc</tt></td>
13770 <td>
13771 Short enough. The "c" stands for "constant". The category could be
13772 <tt>generic_category</tt>. Fully qualified names like
13773 <tt>std::errc::not_enough_memory</tt> read well. Although alone it looks odd as a
13774 name, given the existing <tt>errno</tt> and <tt>namespace std</tt> names, it seems fairly
13775 intuitive. There are no uses of <tt>errc</tt> in the current C++ standard.
13776 </td>
13777 </tr>
13778 </tbody></table>
13779
13780
13781
13782
13783
13784 <hr>
13785 <h3><a name="806"></a>806. <tt>unique_ptr::reset</tt> effects incorrect, too permissive</h3>
13786 <p><b>Section:</b> 20.7.11.2.5 [unique.ptr.single.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
13787  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-03-13</p>
13788 <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>
13789 <p><b>Discussion:</b></p>
13790 <p>
13791 <tt>void unique_ptr::reset(T* p = 0)</tt> is currently specified as:
13792 </p>
13793
13794 <blockquote>
13795 <i>Effects:</i> If <tt>p == get()</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
13796 </blockquote>
13797
13798 <p>
13799 There are two problems with this. One, if <tt>get() == 0</tt> and <tt>p != 0</tt>, the
13800 deleter is called with a NULL pointer, and this is probably not what's
13801 intended (the destructor avoids calling the deleter with 0.)
13802 </p>
13803
13804 <p>
13805 Two, the special check for <tt>get() == p</tt> is generally not needed and such a
13806 situation usually indicates an error in the client code, which is being
13807 masked. As a data point, <tt>boost::shared_ptr</tt> was changed to assert on such
13808 self-resets in 2001 and there were no complaints.
13809 </p>
13810
13811 <p>
13812 One might think that self-resets are necessary for operator= to work; it's specified to perform
13813 </p>
13814
13815 <blockquote><pre>reset( u.release() );
13816 </pre></blockquote>
13817
13818 <p>
13819 and the self-assignment
13820 </p>
13821
13822 <blockquote><pre>p = move(p);
13823 </pre></blockquote>
13824
13825 <p>
13826 might appear to result in a self-reset. But it doesn't; the <tt>release()</tt> is
13827 performed first, zeroing the stored pointer. In other words, <tt>p.reset(
13828 q.release() )</tt> works even when <tt>p</tt> and <tt>q</tt> are the same <tt>unique_ptr</tt>, and there
13829 is no need to special-case <tt>p.reset( q.get() )</tt> to work in a similar
13830 scenario, as it definitely doesn't when <tt>p</tt> and <tt>q</tt> are separate.
13831 </p>
13832
13833
13834
13835 <p><b>Proposed resolution:</b></p>
13836
13837 <p>
13838 Change 20.7.11.2.5 [unique.ptr.single.modifiers]:
13839 </p>
13840
13841 <blockquote>
13842 <pre>void reset(T* p = 0);
13843 </pre>
13844 <blockquote>
13845 -4- <i>Effects:</i> If <tt><del>p ==</del> get()<ins> == 0</ins></tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
13846 </blockquote>
13847 </blockquote>
13848
13849 <p>
13850 Change 20.7.11.3.3 [unique.ptr.runtime.modifiers]:
13851 </p>
13852
13853 <blockquote>
13854 <pre>void reset(T* p = 0);
13855 </pre>
13856 <blockquote>
13857 <p>...</p>
13858 <p>
13859 -2- <i>Effects:</i> If <tt><del>p ==</del> get()<ins> == 0</ins></tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
13860 </p>
13861 </blockquote>
13862 </blockquote>
13863
13864
13865
13866
13867
13868
13869 <hr>
13870 <h3><a name="807"></a>807. <tt>tuple</tt> construction should not fail unless its element's construction fails</h3>
13871 <p><b>Section:</b> 20.4.1.2 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
13872  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-03-13</p>
13873 <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>
13874 <p><b>Discussion:</b></p>
13875 <p>
13876 <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
13877 should be added to <tt>tuple</tt> except it ought to take into account move constructors as well.
13878 </p>
13879
13880
13881 <p><b>Proposed resolution:</b></p>
13882 <p>
13883 Add to 20.4.1.2 [tuple.cnstr]:
13884 </p>
13885
13886 <blockquote>
13887 <p>
13888 For each <tt>tuple</tt> constructor and assignment operator, an exception is thrown only if the construction
13889 or assignment of one of the types in <tt>Types</tt> throws an exception.
13890 </p>
13891 </blockquote>
13892
13893
13894
13895
13896
13897 <hr>
13898 <h3><a name="808"></a>808. [forward] incorrect redundant specification</h3>
13899 <p><b>Section:</b> 20.2.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
13900  <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-03-13</p>
13901 <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>
13902 <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>
13903 <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>
13904 <p><b>Discussion:</b></p>
13905 <p>
13906 p4 (forward) says:
13907 </p>
13908 <blockquote>
13909 <i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue.
13910 </blockquote>
13911
13912 <p>
13913 First of all, lvalue-ness and rvalue-ness are properties of an expression,
13914 not of a type (see 3.10 [basic.lval]).  Thus, the phrasing "Return type" is wrong.
13915 Second, the phrase says exactly what the core language wording says for
13916 folding references in 14.3.1 [temp.arg.type]/p4  and for function return values
13917 in 5.2.2 [expr.call]/p10.  (If we feel the wording should be retained, it should
13918 at most be a note with cross-references to those sections.)
13919 </p>
13920 <p>
13921 The prose after the example talks about "forwarding as an <tt>int&amp;</tt> (an lvalue)" etc.
13922 In my opinion, this is a category error:  "<tt>int&amp;</tt>" is a type, "lvalue" is a
13923 property of an expression, orthogonal to its type.  (Btw, expressions cannot
13924 have reference type, ever.)
13925 </p>
13926 <p>
13927 Similar with move:
13928 </p>
13929 <blockquote>
13930 Return type: an rvalue.
13931 </blockquote>
13932 <p>
13933 is just wrong and also redundant.
13934 </p>
13935
13936
13937 <p><b>Proposed resolution:</b></p>
13938 <p>
13939 Change 20.2.2 [forward] as indicated:
13940 </p>
13941
13942 <blockquote>
13943 <pre>template &lt;class T&gt; T&amp;&amp; forward(typename identity&lt;T&gt;::type&amp;&amp; t);
13944 </pre>
13945
13946 <blockquote>
13947 <p>...</p>
13948 <p>
13949 <del><i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue.</del>
13950 </p>
13951 <p>...</p>
13952 <p>
13953 -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
13954 as <del>an <tt>int&amp;&amp;</tt> (</del>an rvalue<del>)</del>. In the second call to factory, <tt>A1</tt> is deduced
13955 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>.
13956 In both cases, <tt>A2</tt> is deduced as double, so 1.414 is forwarded to <tt>A</tt>'s constructor as
13957 <del><tt>double&amp;&amp;</tt> (</del>an rvalue<del>)</del>.
13958 </p>
13959 </blockquote>
13960
13961 <pre>template &lt;class T&gt; typename remove_reference&lt;T&gt;::type&amp;&amp; move(T&amp;&amp; t);
13962 </pre>
13963
13964 <blockquote>
13965 <p>...</p>
13966 <p>
13967 <del><i>Return type:</i>  an rvalue.</del>
13968 </p>
13969 </blockquote>
13970
13971 </blockquote>
13972
13973
13974
13975
13976
13977
13978 <hr>
13979 <h3><a name="809"></a>809. std::swap should be overloaded for array types</h3>
13980 <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#Ready">Ready</a>
13981  <b>Submitter:</b> Niels Dekker <b>Date:</b> 2008-02-28</p>
13982 <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>
13983 <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>
13984 <p><b>Discussion:</b></p>
13985 <p>
13986 For the sake of generic programming, the header <code>&lt;algorithm&gt;</code> should provide an
13987 overload of <code>std::swap</code> for array types:
13988 </p><pre>template&lt;class T, size_t N&gt; void swap(T (&amp;a)[N], T (&amp;b)[N]);
13989 </pre>
13990
13991
13992 <p>
13993 It became apparent to me that this overload is missing, when I considered how to write a swap
13994 function for a generic wrapper class template.
13995 (Actually I was thinking of Boost's <a href="http://www.boost.org/libs/utility/value_init.htm">value_initialized</a>.)
13996 Please look at the following template, <code>W</code>, and suppose that is intended to be a very
13997 <em>generic</em> wrapper:
13998 </p><pre>template&lt;class T&gt; class W {
13999 public:
14000    T data;
14001 };
14002 </pre>
14003 Clearly <code>W&lt;T&gt;</code> is <em>CopyConstructible and CopyAssignable</em>, and therefore
14004 <em>Swappable</em>, whenever <code>T</code> is <em>CopyConstructible and CopyAssignable</em>.
14005 Moreover, <code>W&lt;T&gt;</code> is <em>also</em> Swappable when <code>T</code> is an array type
14006 whose element type is CopyConstructible and CopyAssignable.
14007 Still it is recommended to add a <em>custom</em> swap function template to such a class template,
14008 for the sake of efficiency and exception safety.
14009 (E.g., <em>Scott Meyers, Effective C++, Third Edition, item 25: Consider support for a non-throwing
14010 swap</em>.)
14011 This function template is typically written as follows:
14012 <pre>template&lt;class T&gt; void swap(W&lt;T&gt;&amp; x, W&lt;T&gt;&amp; y) {
14013   using std::swap;
14014   swap(x.data, y.data);
14015 }
14016 </pre>
14017 Unfortunately, this will introduce an undesirable inconsistency, when <code>T</code> is an array.
14018 For instance, <code>W&lt;std::string[8]&gt;</code> is Swappable, but the current Standard does not
14019 allow calling the custom swap function that was especially written for <code>W</code>!
14020 <pre>W&lt;std::string[8]&gt; w1, w2;  // Two objects of a Swappable type.
14021 std::swap(w1, w2);  // Well-defined, but inefficient.
14022 using std::swap;
14023 swap(w1, w2);  // Ill-formed, just because ADL finds W's swap function!!!
14024 </pre>
14025
14026 <code>W</code>'s <code>swap</code> function would try to call <code>std::swap</code> for an array,
14027 <code>std::string[8]</code>, which is not supported by the Standard Library.
14028 This issue is easily solved by providing an overload of <code>std::swap</code> for array types.
14029 This swap function should be implemented in terms of swapping the elements of the arrays, so that
14030 it would be non-throwing for arrays whose element types have a non-throwing swap.
14031
14032
14033 <p>
14034 Note that such an overload of <code>std::swap</code> should also support <em>multi-dimensional</em>
14035 arrays. Fortunately that isn't really an issue, because it would do so <i>automatically</i>, by
14036 means of recursion.
14037 </p>
14038
14039 <p>
14040 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
14041 Library] Shouldn't std::swap be overloaded for C-style arrays?</a>
14042 </p>
14043
14044
14045 <p><b>Proposed resolution:</b></p>
14046 <p>
14047 Add an extra condition to the definition of Swappable requirements [swappable] in 20.1.1 [utility.arg.requirements]:
14048 </p>
14049 <blockquote>
14050 - <tt>T</tt> is <tt>Swappable</tt> if <tt>T</tt> is an array type whose element type is <tt>Swappable</tt>.
14051 </blockquote>
14052 <p>
14053 Add the following to 25.2.3 [alg.swap]:
14054 </p>
14055 <blockquote>
14056 <pre>template&lt;class T, size_t N&gt; void swap(T (&amp;a)[N], T (&amp;b)[N]);
14057 </pre>
14058 <blockquote>
14059 <i>Requires:</i> Type <code>T</code> shall be <tt>Swappable</tt>.
14060 </blockquote>
14061 <blockquote>
14062 <i>Effects:</i> <code>swap_ranges(a, a + N, b);</code>
14063 </blockquote>
14064 </blockquote>
14065
14066
14067
14068
14069
14070 <hr>
14071 <h3><a name="810"></a>810. Missing traits dependencies in operational semantics of extended manipulators</h3>
14072 <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>
14073  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-03-01</p>
14074 <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>
14075 <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>
14076 <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>
14077 <p><b>Discussion:</b></p>
14078 <p>
14079 The recent draft (as well as the original proposal n2072) uses an
14080 operational semantic
14081 for <tt>get_money</tt> ([ext.manip]/3) and <tt>put_money</tt> ([ext.manip]/5), which uses
14082 </p>
14083
14084 <blockquote><pre>istreambuf_iterator&lt;charT&gt;
14085 </pre></blockquote>
14086
14087 <p>
14088 and
14089 </p>
14090
14091 <blockquote><pre>ostreambuf_iterator&lt;charT&gt;
14092 </pre></blockquote>
14093
14094 <p>
14095 resp, instead of the iterator instances, with explicitly provided
14096 traits argument (The operational semantic defined by <tt>f</tt> is also traits
14097 dependent). This is an obvious oversight because both <tt>*stream_buf</tt>
14098 c'tors expect a <tt>basic_streambuf&lt;charT,traits&gt;</tt> as argument.
14099 </p>
14100 <p>
14101 The same problem occurs within the <tt>get_time</tt> and <tt>put_time</tt> semantic (p.
14102 7 and p. 9)
14103 of n2071 incorporated in N2521, where additional to the problem we
14104 have an editorial issue in <tt>get_time</tt> (<tt>streambuf_iterator</tt> instead of
14105 <tt>istreambuf_iterator</tt>).
14106 </p>
14107
14108
14109 <p><b>Proposed resolution:</b></p>
14110 <p>
14111 In 27.6.4 [ext.manip]/3 within function <tt>f</tt> replace the first line
14112 </p>
14113
14114 <blockquote><pre>template &lt;class charT, class traits, class moneyT&gt;
14115 void f(basic_ios&lt;charT, traits&gt;&amp; str, moneyT&amp; mon, bool intl) {
14116    typedef istreambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
14117    ...
14118 </pre></blockquote>
14119
14120 <p>
14121 In 27.6.4 [ext.manip]/4 remove the first template <tt>charT</tt> parameter:
14122 </p>
14123
14124 <blockquote><pre>template &lt;<del>class charT, </del>class moneyT&gt; unspecified put_money(const moneyT&amp; mon, bool intl = false<ins>)</ins>;
14125 </pre></blockquote>
14126
14127 <p>
14128 In 27.6.4 [ext.manip]/5 within function <tt>f</tt> replace the first line
14129 </p>
14130
14131 <blockquote><pre>template &lt;class charT, class traits, class moneyT&gt;
14132 void f(basic_ios&lt;charT, traits&gt;&amp; str, const moneyT&amp; mon, bool intl) {
14133   typedef ostreambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
14134   ...
14135 </pre></blockquote>
14136
14137 <p>
14138 In 27.6.4 [ext.manip]/7 within function <tt>f</tt> replace the first line
14139 </p>
14140
14141 <blockquote><pre>template &lt;class charT, class traits&gt;
14142 void f(basic_ios&lt;charT, traits&gt;&amp; str, struct tm *tmb, const charT *fmt) {
14143   typedef <ins>i</ins>streambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
14144   ...
14145 </pre></blockquote>
14146
14147 <p>
14148 In 27.6.4 [ext.manip]/8 add const:
14149 </p>
14150
14151 <blockquote><pre>template &lt;class charT&gt; unspecified put_time(<ins>const</ins> struct tm *tmb, const charT *fmt);
14152 </pre></blockquote>
14153
14154 <p>
14155 In 27.6.4 [ext.manip]/9 within function <tt>f</tt> replace the first line
14156 </p>
14157
14158 <blockquote><pre>template &lt;class charT, class traits&gt;
14159 void f(basic_ios&lt;charT, traits&gt;&amp; str, const struct tm *tmb, const charT *fmt) {
14160   typedef ostreambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
14161   ...
14162 </pre></blockquote>
14163
14164 <p>
14165 Add to the <tt>&lt;iomanip&gt;</tt> synopsis in 27.6 [iostream.format]
14166 </p>
14167
14168 <blockquote><pre>template &lt;class moneyT&gt; unspecified get_money(moneyT&amp; mon, bool intl = false);
14169 template &lt;class moneyT&gt; unspecified put_money(const moneyT&amp; mon, bool intl = false);
14170 template &lt;class charT&gt; unspecified get_time(struct tm *tmb, const charT *fmt);
14171 template &lt;class charT&gt; unspecified put_time(const struct tm *tmb, const charT *fmt);
14172 </pre></blockquote>
14173
14174
14175
14176
14177
14178
14179 <hr>
14180 <h3><a name="811"></a>811. <tt>pair</tt> of pointers no longer works with literal 0</h3>
14181 <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>
14182  <b>Submitter:</b> Doug Gregor <b>Date:</b> 2008-03-14</p>
14183 <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>
14184 <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>
14185 <p><b>Discussion:</b></p>
14186 <blockquote><pre>#include &lt;utility&gt;
14187
14188 int main()
14189 {
14190    std::pair&lt;char *, char *&gt; p (0,0);
14191 }
14192 </pre></blockquote>
14193
14194 <p>
14195 I just got a bug report about that, because it's valid C++03, but not
14196 C++0x. The important realization, for me, is that the emplace
14197 proposal---which made <tt>push_back</tt> variadic, causing the <tt>push_back(0)</tt>
14198 issue---didn't cause this break in backward compatibility. The break
14199 actually happened when we added this pair constructor as part of adding
14200 rvalue references into the language, long before variadic templates or
14201 emplace came along:
14202 </p>
14203
14204 <blockquote><pre>template&lt;class U, class V&gt; pair(U&amp;&amp; x, V&amp;&amp; y);
14205 </pre></blockquote>
14206
14207 <p>
14208 Now, concepts will address this issue by constraining that <tt>pair</tt>
14209 constructor to only <tt>U</tt>'s and <tt>V</tt>'s that can properly construct "first" and
14210 "second", e.g. (from
14211 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2322.pdf">N2322</a>):
14212 </p>
14213
14214 <blockquote><pre>template&lt;class U , class V &gt;
14215 requires Constructible&lt;T1, U&amp;&amp;&gt; &amp;&amp; Constructible&lt;T2, V&amp;&amp;&gt;
14216 pair(U&amp;&amp; x , V&amp;&amp; y );
14217 </pre></blockquote>
14218
14219
14220
14221 <p><b>Proposed resolution:</b></p>
14222 <p>
14223 </p>
14224
14225
14226
14227
14228
14229 <hr>
14230 <h3><a name="812"></a>812. unsolicited multithreading considered harmful?</h3>
14231 <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>
14232  <b>Submitter:</b> Paul McKenney <b>Date:</b> 2008-02-27</p>
14233 <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>
14234 <p><b>Discussion:</b></p>
14235 <p>
14236 Multi-threading is a good thing, but unsolicited multi-threading can
14237 potentially be harmful.  For example, <tt>sort()</tt> performance might be
14238 greatly increased via a multithreaded implementation.  However, such
14239 a multithreaded implementation could result in concurrent invocations
14240 of the user-supplied comparator.  This would in turn result in problems
14241 given a caching comparator that might be written for complex sort keys.
14242 Please note that this is not a theoretical issue, as multithreaded
14243 implementations of <tt>sort()</tt> already exist.
14244 </p>
14245 <p>
14246 Having a multithreaded <tt>sort()</tt> available is good, but it should not
14247 be the default for programs that are not explicitly multithreaded.
14248 Users should not be forced to deal with concurrency unless they have
14249 asked for it.
14250 </p>
14251
14252 <p><i>[
14253 This may be covered by
14254 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2410.html">N2410</a>
14255 Thread-Safety in the Standard Library (Rev 1).
14256 ]</i></p>
14257
14258
14259
14260 <p><b>Proposed resolution:</b></p>
14261 <p>
14262 </p>
14263
14264
14265
14266
14267
14268 <hr>
14269 <h3><a name="813"></a>813. "empty" undefined for <tt>shared_ptr</tt></h3>
14270 <p><b>Section:</b> 20.7.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>
14271  <b>Submitter:</b> Matt Austern <b>Date:</b> 2008-02-26</p>
14272 <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>
14273 <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>
14274 <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>
14275 <p><b>Discussion:</b></p>
14276 <p>
14277 Several places in 20.7.12.2 [util.smartptr.shared] refer to an "empty" <tt>shared_ptr</tt>.
14278 However, that term is nowhere defined. The closest thing we have to a
14279 definition is that the default constructor creates an empty <tt>shared_ptr</tt>
14280 and that a copy of a default-constructed <tt>shared_ptr</tt> is empty. Are any
14281 other <tt>shared_ptr</tt>s empty? For example, is <tt>shared_ptr((T*) 0)</tt> empty? What
14282 are the properties of an empty <tt>shared_ptr</tt>? We should either clarify this
14283 term or stop using it.
14284 </p><p>
14285 </p>
14286 One reason it's not good enough to leave this term up to the reader's
14287 intuition is that, in light of
14288 <a href="http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2007/n2351.htm">N2351</a>
14289 and issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, most readers'
14290 intuitive understanding is likely to be wrong. Intuitively one might
14291 expect that an empty <tt>shared_ptr</tt> is one that doesn't store a pointer,
14292 but, whatever the definition is, that isn't it.
14293
14294
14295 <p><i>[
14296 Peter adds:
14297 ]</i></p>
14298
14299
14300 <blockquote>
14301 <p>
14302 Or, what is an "empty" <tt>shared_ptr</tt>?
14303 </p>
14304
14305 <ul>
14306 <li>
14307 <p>
14308 Are any other <tt>shared_ptrs</tt> empty?
14309 </p>
14310 <p>
14311 Yes. Whether a given <tt>shared_ptr</tt> instance is empty or not is (*)
14312 completely specified by the last mutating operation on that instance.
14313 Give me an example and I'll tell you whether the <tt>shared_ptr</tt> is empty or
14314 not.
14315 </p>
14316 <blockquote>
14317 (*) If it isn't, this is a legitimate defect.
14318 </blockquote>
14319 </li>
14320
14321 <li>
14322 <p>
14323 For example, is <tt>shared_ptr((T*) 0)</tt> empty?
14324 </p>
14325 <p>
14326 No. If it were empty, it would have a <tt>use_count()</tt> of 0, whereas it is
14327 specified to have an <tt>use_count()</tt> of 1.
14328 </p>
14329 </li>
14330
14331 <li>
14332 <p>
14333 What are the properties of an empty <tt>shared_ptr</tt>?
14334 </p>
14335 <p>
14336 The properties of an empty <tt>shared_ptr</tt> can be derived from the
14337 specification. One example is that its destructor is a no-op. Another is
14338 that its <tt>use_count()</tt> returns 0. I can enumerate the full list if you
14339 really like.
14340 </p>
14341 </li>
14342
14343 <li>
14344 <p>
14345 We should either clarify this term or stop using it.
14346 </p>
14347 <p>
14348 I don't agree with the imperative tone
14349 </p>
14350 <p>
14351 A clarification would be either a no-op - if it doesn't contradict the
14352 existing wording - or a big mistake if it does.
14353 </p>
14354 <p>
14355 I agree that a clarification that is formally a no-op may add value.
14356 </p>
14357 </li>
14358
14359 <li>
14360 <p>
14361 However, that term is nowhere defined.
14362 </p>
14363 <p>
14364 Terms can be useful without a definition. Consider the following
14365 simplistic example. We have a type <tt>X</tt> with the following operations
14366 defined:
14367 </p>
14368 <blockquote><pre>X x;
14369 X x2(x);
14370 X f(X x);
14371 X g(X x1, X x2);
14372 </pre></blockquote>
14373 <p>
14374 A default-constructed value is green.<br>
14375 A copy has the same color as the original.<br>
14376 <tt>f(x)</tt> returns a red value if the argument is green, a green value otherwise.<br>
14377 <tt>g(x1,x2)</tt> returns a green value if the arguments are of the same color, a red value otherwise.
14378 </p>
14379
14380 <p>
14381 Given these definitions, you can determine the color of every instance
14382 of type <tt>X</tt>, even if you have absolutely no idea what green and red mean.
14383 </p>
14384
14385 <p>
14386 Green and red are "nowhere defined" and completely defined at the same time.
14387 </p>
14388 </li>
14389 </ul>
14390
14391 <p>
14392 Alisdair's wording is fine.
14393 </p>
14394 </blockquote>
14395
14396
14397 <p><b>Proposed resolution:</b></p>
14398 <p>
14399 Append the following sentance to 20.7.12.2 [util.smartptr.shared]
14400 </p>
14401 <blockquote>
14402 The <code>shared_ptr</code> class template stores a pointer, usually obtained
14403 via <code>new</code>. <code>shared_ptr</code> implements semantics of
14404 shared ownership; the last remaining owner of the pointer is responsible for
14405 destroying the object, or otherwise releasing  the resources associated with
14406 the stored pointer. <ins>A <code>shared_ptr</code> object that does not own
14407 a pointer is said to be <i>empty</i>.</ins>
14408 </blockquote>
14409
14410
14411
14412
14413
14414 <hr>
14415 <h3><a name="814"></a>814. <tt>vector&lt;bool&gt;::swap(reference, reference)</tt> not defined</h3>
14416 <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>
14417  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-17</p>
14418 <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>
14419 <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>
14420 <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>
14421 <p><b>Discussion:</b></p>
14422 <p>
14423 <tt>vector&lt;bool&gt;::swap(reference, reference)</tt> has no definition.
14424 </p>
14425
14426
14427 <p><b>Proposed resolution:</b></p>
14428 <p>
14429 </p>
14430
14431
14432
14433
14434
14435 <hr>
14436 <h3><a name="815"></a>815. <tt>std::function</tt> and <tt>reference_closure</tt> do not use perfect forwarding</h3>
14437 <p><b>Section:</b> 20.6.15.2.4 [func.wrap.func.inv] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
14438  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-16</p>
14439 <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>
14440 <p><b>Discussion:</b></p>
14441 <p>
14442 <tt>std::function</tt> and <tt>reference_closure</tt> should use "perfect forwarding" as
14443 described in the rvalue core proposal.
14444 </p>
14445
14446 <p><i>[
14447 Sophia Antipolis:
14448 ]</i></p>
14449
14450
14451 <blockquote>
14452 According to Doug Gregor, as far as <tt>std::function</tt> is concerned, perfect
14453 forwarding can not be obtained because of type erasure. Not everyone
14454 agreed with this diagnosis of forwarding.
14455 </blockquote>
14456
14457
14458
14459 <p><b>Proposed resolution:</b></p>
14460 <p>
14461 </p>
14462
14463
14464
14465
14466
14467 <hr>
14468 <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>
14469 <p><b>Section:</b> 20.6.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>
14470  <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2008-02-08</p>
14471 <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>
14472 <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>
14473 <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>
14474 <p><b>Discussion:</b></p>
14475 <p>
14476 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>
14477 should be nofail when <tt>f, t1, ..., tN</tt> have nofail copy ctors.
14478 </p>
14479 <p>
14480 However, no guarantees are provided for the copy ctor of the functor
14481 returned by <tt>bind()</tt>.  (It's guaranteed to have a copy ctor, which can
14482 throw implementation-defined exceptions: <tt>bind()</tt> returns a forwarding
14483 call wrapper, TR1 3.6.3/2.  A forwarding call wrapper is a call wrapper,
14484 TR1 3.3/4.  Every call wrapper shall be CopyConstructible, TR1 3.3/4.
14485 Everything without an exception-specification may throw
14486 implementation-defined exceptions unless otherwise specified, C++03
14487 17.4.4.8/3.)
14488 </p>
14489 <p>
14490 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
14491 to cover both calling <tt>bind()</tt> and copying the returned functor?
14492 </p>
14493
14494 <p><i>[
14495 Howard adds:
14496 ]</i></p>
14497
14498
14499 <blockquote>
14500 <tt>tuple</tt> construction should probably have a similar guarantee.
14501 </blockquote>
14502
14503
14504
14505 <p><b>Proposed resolution:</b></p>
14506 <p>
14507 </p>
14508
14509
14510
14511
14512
14513 <hr>
14514 <h3><a name="817"></a>817. <tt>bind</tt> needs to be moved</h3>
14515 <p><b>Section:</b> 20.6.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>
14516  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-03-17</p>
14517 <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>
14518 <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>
14519 <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>
14520 <p><b>Discussion:</b></p>
14521 <p>
14522 The functor retureed by <tt>bind()</tt> should have a move constructor that
14523 requires only move construction of its contained functor and bound arguments.
14524 That way move-only functors can be passed to objects such as <tt>thread</tt>.
14525 </p>
14526 <p>
14527 This issue is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>.
14528 </p>
14529
14530
14531 <p><b>Proposed resolution:</b></p>
14532 <p>
14533 </p>
14534
14535
14536
14537
14538
14539 <hr>
14540 <h3><a name="818"></a>818. wording for memory ordering</h3>
14541 <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>
14542  <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-03-22</p>
14543 <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>
14544 <p><b>Discussion:</b></p>
14545 <p>
14546 29.1 [atomics.order] p1 says in the table that
14547 </p>
14548
14549 <blockquote>
14550 <table border="1">
14551 <tbody><tr>
14552 <th>Element</th><th>Meaning</th>
14553 </tr>
14554 <tr>
14555 <td><tt>memory_order_acq_rel</tt></td>
14556 <td>the operation has both acquire and release semantics</td>
14557 </tr>
14558 </tbody></table>
14559 </blockquote>
14560
14561 <p>
14562 To my naked eye, that seems to imply that even an atomic read has both
14563 acquire and release semantics.
14564 </p>
14565
14566 <p>
14567 Then, p1 says in the table:
14568 </p>
14569
14570 <blockquote>
14571 <table border="1">
14572 <tbody><tr>
14573 <th>Element</th><th>Meaning</th>
14574 </tr>
14575 <tr>
14576 <td><tt>memory_order_seq_cst</tt></td>
14577 <td>the operation has both acquire and release semantics,
14578     and, in addition, has sequentially-consistent operation ordering</td>
14579 </tr>
14580 </tbody></table>
14581 </blockquote>
14582
14583 <p>
14584 So that seems to be "the same thing" as <tt>memory_order_acq_rel</tt>, with additional
14585 constraints.
14586 </p>
14587
14588 <p>
14589 I'm then reading p2, where it says:
14590 </p>
14591
14592 <blockquote>
14593 The <tt>memory_order_seq_cst</tt> operations that load a value are acquire operations
14594 on the affected locations. The <tt>memory_order_seq_cst</tt> operations that store a value
14595 are release operations on the affected locations.
14596 </blockquote>
14597
14598 <p>
14599 That seems to imply that atomic reads only have acquire semantics.  If that
14600 is intended, does this also apply to <tt>memory_order_acq_rel</tt> and the individual
14601 load/store operations as well?
14602 </p>
14603
14604 <p>
14605 Also, the table in p1 contains phrases with "thus" that seem to indicate
14606 consequences of normative wording in 1.10 [intro.multithread].  That shouldn't be in
14607 normative text, for the fear of redundant or inconsistent specification with
14608 the other normative text.
14609 </p>
14610
14611 <p>
14612 Double-check 29.4 [atomics.types.operations] that each
14613 operation clearly says whether it's a load or a store operation, or
14614 both.  (It could be clearer, IMO.  Solution not in current proposed resolution.)
14615 </p>
14616
14617 <p>
14618 29.1 [atomics.order] p2:  What's a "consistent execution"?  It's not defined in
14619 1.10 [intro.multithread], it's just used in notes there.
14620 </p>
14621
14622 <p>
14623 And why does 29.4 [atomics.types.operations] p9 for "load" say:
14624 </p>
14625
14626
14627 <blockquote>
14628 <i>Requires:</i> The order argument shall not be <tt>memory_order_acquire</tt>
14629 nor <tt>memory_order_acq_rel</tt>.
14630 </blockquote>
14631
14632 <p>
14633 (Since this is exactly the same restriction as for "store", it seems to be a typo.)
14634 </p>
14635
14636 <p>
14637 And then: 29.4 [atomics.types.operations] p12:
14638 </p>
14639
14640 <blockquote>
14641 These operations are read-modify-write operations in the sense of the
14642 "synchronizes with" definition (1.10 [intro.multithread]), so both such an operation and the
14643 evaluation that produced the input value synchronize with any evaluation
14644 that reads the updated value.
14645 </blockquote>
14646
14647 <p>
14648 This is redundant with 1.10 [intro.multithread], see above for the reasoning.
14649 </p>
14650
14651
14652 <p><b>Proposed resolution:</b></p>
14653 <p>
14654 Replace the cross-reference in p1 to refer to 1.1 [intro.scope] instead of
14655 1.7 [intro.memory].
14656 Rephrase the table in as follows (maybe don't use a table):
14657 </p>
14658
14659 <blockquote>
14660 <p>
14661 For <tt>memory_order_relaxed</tt>, no operation orders memory.
14662 </p>
14663
14664 <p>
14665 For <tt>memory_order_release</tt>, <tt>memory_order_acq_rel</tt>, and <tt>memory_order_seq_cst</tt>,
14666 a store operation performs a release operation on the affected memory location.
14667 </p>
14668
14669 <p>
14670 For <tt>memory_order_acquire</tt>, <tt>memory_order_acq_rel</tt>, and <tt>memory_order_seq_cst</tt>,
14671 a load operation performs an acquire operation on the affected memory location.
14672 </p>
14673 </blockquote>
14674
14675 <p>
14676 Rephrase 29.1 [atomics.order] p2:
14677 </p>
14678
14679 <blockquote>
14680 <del>The <tt>memory_order_seq_cst</tt> operations that load a value are
14681 acquire operations on the affected locations. The
14682 <tt>memory_order_seq_cst</tt> operations that store a value are release
14683 operations on the affected locations.</del>
14684 <del>In addition, in a consistent
14685 execution, t</del><ins>T</ins>here <del>must be</del> <ins>is</ins> a single
14686 total order <tt>S</tt> on all
14687 <tt>memory_order_seq_cst</tt> operations, consistent with the happens before
14688 order and modification orders for all affected locations, such that each
14689 <tt>memory_order_seq_cst</tt> operation observes either the last preceding
14690 modification according to this order <tt>S</tt>, or the result of an operation
14691 that is not <tt>memory_order_seq_cst</tt>. [<i>Note:</i> Although it is not explicitly
14692 required that <tt>S</tt> include locks, it can always be extended to an order
14693 that does include lock and unlock operations, since the ordering between
14694 those is already included in the happens before ordering. <i>-- end note</i>]
14695 </blockquote>
14696
14697 <p>
14698 Rephrase 29.4 [atomics.types.operations] p12 as:
14699 </p>
14700
14701 <blockquote>
14702 <i>Effects:</i> Atomically replaces the value pointed to by object or by
14703 this with desired. Memory is affected according to the value of order.
14704 These operations are read-modify-write operations <del>in the sense of the
14705 "synchronizes with" definition</del> (1.10 [intro.multithread])<del>, so both such an operation and the
14706 evaluation that produced the input value synchronize with any evaluation
14707 that reads the updated value</del>.
14708 </blockquote>
14709
14710 <p>
14711 Same in p15, p20, p22.
14712 </p>
14713
14714
14715
14716
14717
14718
14719 <hr>
14720 <h3><a name="819"></a>819. rethrow_if_nested</h3>
14721 <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>
14722  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-25</p>
14723 <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>
14724 <p><b>Discussion:</b></p>
14725 <p>
14726 Looking at the wording I submitted for <tt>rethrow_if_nested</tt>, I don't think I
14727 got it quite right.
14728 </p>
14729
14730 <p>
14731 The current wording says:
14732 </p>
14733
14734 <blockquote>
14735 <pre>template &lt;class E&gt; void rethrow_if_nested(const E&amp; e);
14736 </pre>
14737 <blockquote>
14738 <p>
14739 <i>Effects:</i> Calls <tt>e.rethrow_nested()</tt> only if <tt>e</tt>
14740 is publicly derived from <tt>nested_exception</tt>.
14741 </p>
14742 </blockquote>
14743 </blockquote>
14744
14745 <p>
14746 This is trying to be a bit subtle, by requiring <tt>e</tt> (not <tt>E</tt>) to be publicly
14747 derived from <tt>nested_exception</tt> the idea is that a <tt>dynamic_cast</tt> would be
14748 required to be sure.  Unfortunately, if <tt>e</tt> is dynamically but not statically
14749 derived from <tt>nested_exception</tt>, <tt>e.rethrow_nested()</tt> is ill-formed.
14750 </p>
14751
14752
14753 <p><b>Proposed resolution:</b></p>
14754
14755
14756
14757
14758
14759 <hr>
14760 <h3><a name="820"></a>820. <tt>current_exception()</tt>'s interaction with throwing copy ctors</h3>
14761 <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>
14762  <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2008-03-26</p>
14763 <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>
14764 <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>
14765 <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>
14766 <p><b>Discussion:</b></p>
14767 <p>
14768 As of N2521, the Working Paper appears to be silent about what
14769 <tt>current_exception()</tt> should do if it tries to copy the currently handled
14770 exception and its copy constructor throws.  18.7.5 [propagation]/7 says "If the
14771 function needs to allocate memory and the attempt fails, it returns an
14772 <tt>exception_ptr</tt> object that refers to an instance of <tt>bad_alloc</tt>.", but
14773 doesn't say anything about what should happen if memory allocation
14774 succeeds but the actual copying fails.
14775 </p>
14776
14777 <p>
14778 I see three alternatives: (1) return an <tt>exception_ptr</tt> object that refers
14779 to an instance of some fixed exception type, (2) return an <tt>exception_ptr</tt>
14780 object that refers to an instance of the copy ctor's thrown exception
14781 (but if that has a throwing copy ctor, an infinite loop can occur), or
14782 (3) call <tt>terminate()</tt>.
14783 </p>
14784
14785 <p>
14786 I believe that <tt>terminate()</tt> is the most reasonable course of action, but
14787 before we go implement that, I wanted to raise this issue.
14788 </p>
14789
14790 <p><i>[
14791 Peter's summary:
14792 ]</i></p>
14793
14794
14795 <blockquote>
14796 <p>
14797 The current practice is to not have throwing copy constructors in
14798 exception classes, because this can lead to <tt>terminate()</tt> as described in
14799 15.5.1 [except.terminate]. Thus calling <tt>terminate()</tt> in this situation seems
14800 consistent and does not introduce any new problems.
14801 </p>
14802
14803 <p>
14804 However, the resolution of core issue 475 may relax this requirement:
14805 </p>
14806
14807 <blockquote>
14808 The CWG agreed with the position that <tt>std::uncaught_exception()</tt> should
14809 return <tt>false</tt> during the copy to the exception object and that <tt>std::terminate()</tt>
14810 should not be called if that constructor exits with an exception.
14811 </blockquote>
14812
14813 <p>
14814 Since throwing copy constructors will no longer call <tt>terminate()</tt>, option
14815 (3) doesn't seem reasonable as it is deemed too drastic a response in a
14816 recoverable situation.
14817 </p>
14818
14819 <p>
14820 Option (2) cannot be adopted by itself, because a potential infinite
14821 recursion will need to be terminated by one of the other options.
14822 </p>
14823
14824 </blockquote>
14825
14826
14827 <p><b>Proposed resolution:</b></p>
14828 <p>
14829 Add the following paragraph after 18.7.5 [propagation]/7:
14830 </p>
14831
14832 <blockquote>
14833 <p>
14834 <i>Returns (continued):</i> If the attempt to copy the current exception
14835 object throws an exception, the function returns an <tt>exception_ptr</tt> that
14836 refers to the thrown exception or, if this is not possible, to an
14837 instance of <tt>bad_exception</tt>.
14838 </p>
14839 <p>
14840 [<i>Note:</i> The copy constructor of the thrown exception may also fail, so
14841 the implementation is allowed to substitute a <tt>bad_exception</tt> to avoid
14842 infinite recursion. <i>-- end note.</i>]
14843 </p>
14844 </blockquote>
14845
14846
14847
14848
14849
14850
14851 <hr>
14852 <h3><a name="821"></a>821. Minor cleanup : <tt>unique_ptr</tt></h3>
14853 <p><b>Section:</b> 20.7.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>
14854  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-30</p>
14855 <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>
14856 <p><b>Discussion:</b></p>
14857 <p>
14858 Reading resolution of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> I noticed the following:
14859 </p>
14860
14861 <blockquote>
14862 <pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
14863 </pre>
14864
14865 <p>
14866 -1- <i>Requires:</i> Does not accept pointer types which are convertible
14867 to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (diagnostic
14868 required). [<i>Note:</i> One implementation technique is to create a private
14869 templated overload. <i>-- end note</i>]
14870 </p>
14871 </blockquote>
14872
14873 <p>
14874 This could be cleaned up by mandating the overload as a public deleted
14875 function.  In addition, we should probably overload <tt>reset</tt> on <tt>nullptr_t</tt>
14876 to be a stronger match than the deleted overload. Words...
14877 </p>
14878
14879
14880 <p><b>Proposed resolution:</b></p>
14881 <p>
14882 Add to class template definition in 20.7.11.3 [unique.ptr.runtime]
14883 </p>
14884
14885 <blockquote>
14886 <pre>// modifiers
14887 T* release();
14888 void reset(T* p = 0);
14889 <ins>void reset( nullptr_t );</ins>
14890 <ins>template&lt; typename T &gt; void reset( T ) = delete;</ins>
14891 void swap(unique_ptr&amp;&amp; u);
14892 </pre>
14893 </blockquote>
14894
14895 <p>
14896 Update 20.7.11.3.3 [unique.ptr.runtime.modifiers]
14897 </p>
14898
14899 <blockquote>
14900 <pre>void reset(pointer p = pointer());
14901 <ins>void reset(nullptr_t);</ins>
14902 </pre>
14903
14904 <p>
14905 <del>-1- <i>Requires:</i> Does not accept pointer types which are convertible
14906 to <tt>pointer</tt> (diagnostic
14907 required). [<i>Note:</i> One implementation technique is to create a private
14908 templated overload. <i>-- end note</i>]</del>
14909 </p>
14910 <p>
14911 <i>Effects:</i> If <tt>get() == nullptr</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
14912 </p>
14913 <p>...</p>
14914 </blockquote>
14915
14916 <p><i>[
14917 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-defects.html#673">673</a> (Ready).
14918 ]</i></p>
14919
14920
14921
14922
14923
14924
14925 <hr>
14926 <h3><a name="822"></a>822. Object with explicit copy constructor no longer <tt>CopyConstructible</tt></h3>
14927 <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>
14928  <b>Submitter:</b> James Kanze <b>Date:</b> 2008-04-01</p>
14929 <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>
14930 <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>
14931 <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>
14932 <p><b>Discussion:</b></p>
14933 <p>
14934 I just noticed that the following program is legal in C++03, but
14935 is forbidden in the current draft:
14936 </p>
14937
14938 <blockquote><pre>#include &lt;vector&gt;
14939 #include &lt;iostream&gt;
14940
14941 class Toto
14942 {
14943 public:
14944     Toto() {}
14945     explicit Toto( Toto const&amp; ) {}
14946 } ;
14947
14948 int
14949 main()
14950 {
14951     std::vector&lt; Toto &gt; v( 10 ) ;
14952     return 0 ;
14953 }
14954 </pre></blockquote>
14955
14956 <p>
14957 Is this change intentional?  (And if so, what is the
14958 justification?  I wouldn't call such code good, but I don't see
14959 any reason to break it unless we get something else in return.)
14960 </p>
14961
14962
14963
14964 <p><b>Proposed resolution:</b></p>
14965 <p>
14966 In 20.1.1 [utility.arg.requirements] change Table 33: <tt>MoveConstructible</tt> requirements [moveconstructible]:
14967 </p>
14968
14969 <blockquote>
14970 <table border="1">
14971 <tbody><tr>
14972 <th>expression</th><th>post-condition</th>
14973 </tr>
14974 <tr>
14975 <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>
14976 </tr>
14977 <tr>
14978 <td colspan="2" align="center">...</td>
14979 </tr>
14980 </tbody></table>
14981 </blockquote>
14982
14983 <p>
14984 In 20.1.1 [utility.arg.requirements] change Table 34: <tt>CopyConstructible</tt> requirements [copyconstructible]:
14985 </p>
14986
14987 <blockquote>
14988 <table border="1">
14989 <tbody><tr>
14990 <th>expression</th><th>post-condition</th>
14991 </tr>
14992 <tr>
14993 <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>
14994 </tr>
14995 <tr>
14996 <td colspan="2" align="center">...</td>
14997 </tr>
14998 </tbody></table>
14999 </blockquote>
15000
15001
15002
15003
15004
15005 <hr>
15006 <h3><a name="823"></a>823. <tt>identity&lt;void&gt;</tt> seems broken</h3>
15007 <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#Review">Review</a>
15008  <b>Submitter:</b> Walter Brown <b>Date:</b> 2008-04-09</p>
15009 <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>
15010 <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>
15011 <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>
15012 <p><b>Discussion:</b></p>
15013 <p>
15014 N2588 seems to have added an <tt>operator()</tt> member function to the
15015 <tt>identity&lt;&gt;</tt> helper in 20.2.2 [forward].  I believe this change makes it no
15016 longer possible to instantiate <tt>identity&lt;void&gt;</tt>, as it would require
15017 forming a reference-to-<tt>void</tt> type as this <tt>operator()</tt>'s parameter type.
15018 </p>
15019
15020 <p>
15021 Suggested resolution:  Specialize <tt>identity&lt;void&gt;</tt> so as not to require
15022 the member function's presence.
15023 </p>
15024
15025 <p><i>[
15026 Sophia Antipolis:
15027 ]</i></p>
15028
15029
15030 <blockquote>
15031 <p>
15032 Jens: suggests to add a requires clause to avoid specializing on <tt>void</tt>.
15033 </p>
15034 <p>
15035 Alisdair: also consider cv-qualified <tt>void</tt>.
15036 </p>
15037 <p>
15038 Alberto provided proposed wording.
15039 </p>
15040 </blockquote>
15041
15042
15043 <p><b>Proposed resolution:</b></p>
15044 <p>
15045 Change definition of <tt>identity</tt> in 20.2.2 [forward], paragraph 2, to:
15046 </p>
15047
15048 <blockquote><pre>template &lt;class T&gt;  struct identity {
15049     typedef T type;
15050
15051     <ins>requires ReferentType&lt;T&gt;</ins>
15052       const T&amp; operator()(const T&amp; x) const;
15053   };
15054 </pre></blockquote>
15055 <p>...</p>
15056 <blockquote><pre>  <ins>requires ReferentType&lt;T&gt;</ins>
15057     const T&amp; operator()(const T&amp; x) const;
15058 </pre></blockquote>
15059
15060
15061 <p><b>Rationale:</b></p>
15062 <p>
15063 The point here is to able to write <tt>T&amp;</tt> given <tt>T</tt> and <tt>ReferentType</tt> is
15064 precisely the concept that guarantees so, according to N2677
15065 (Foundational concepts). Because of this, it seems preferable than an
15066 explicit check for <tt>cv void</tt> using <tt>SameType/remove_cv</tt> as it was suggested
15067 in Sophia. In particular, Daniel remarked that there may be types other
15068 than <tt>cv void</tt> which aren't referent types (<tt>int[]</tt>, perhaps?).
15069 </p>
15070
15071
15072
15073
15074
15075 <hr>
15076 <h3><a name="824"></a>824. rvalue ref issue with <tt>basic_string</tt> inserter</h3>
15077 <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#Ready">Ready</a>
15078  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-04-10</p>
15079 <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>
15080 <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>
15081 <p><b>Discussion:</b></p>
15082 <p>
15083 In the current working paper, the <tt>&lt;string&gt;</tt> header synopsis at the end of
15084 21.2 [string.classes] lists a single <tt>operator&lt;&lt;</tt> overload
15085 for <tt>basic_string</tt>.
15086 </p>
15087
15088 <blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
15089  basic_ostream&lt;charT, traits&gt;&amp;
15090    operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os,
15091               const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
15092 </pre></blockquote>
15093
15094 <p>
15095 The definition in 21.3.8.9 [string.io] lists two:
15096 </p>
15097
15098 <blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
15099  basic_ostream&lt;charT, traits&gt;&amp;
15100    operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os,
15101               const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
15102
15103 template&lt;class charT, class traits, class Allocator&gt;
15104  basic_ostream&lt;charT, traits&gt;&amp;
15105    operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os,
15106               const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
15107 </pre></blockquote>
15108
15109 <p>
15110 I believe the synopsis in 21.2 [string.classes] is correct, and the first of the two
15111 signatures in 21.3.8.9 [string.io] should be deleted.
15112 </p>
15113
15114
15115 <p><b>Proposed resolution:</b></p>
15116 <p>
15117 Delete the first of the two signatures in 21.3.8.9 [string.io]:
15118 </p>
15119
15120 <blockquote><pre><del>template&lt;class charT, class traits, class Allocator&gt;
15121  basic_ostream&lt;charT, traits&gt;&amp;
15122    operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os,
15123               const basic_string&lt;charT,traits,Allocator&gt;&amp; str);</del>
15124
15125 template&lt;class charT, class traits, class Allocator&gt;
15126  basic_ostream&lt;charT, traits&gt;&amp;
15127    operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os,
15128               const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
15129 </pre></blockquote>
15130
15131
15132
15133
15134
15135 <hr>
15136 <h3><a name="825"></a>825. Missing rvalues reference stream insert/extract operators?</h3>
15137 <p><b>Section:</b> 19.4.2.1 [syserr.errcode.overview], 20.7.12.2.8
15138 [util.smartptr.shared.io], 22.2.8 [facets.examples], 23.3.5.3
15139 [bitset.operators], 26.3.6 [complex.ops], 27.5 [stream.buffers], 28.9
15140 [re.submatch] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
15141  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-04-10</p>
15142 <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>
15143 <p><b>Discussion:</b></p>
15144 <p>
15145 Should the following use rvalues references to stream in insert/extract
15146 operators?
15147 </p>
15148
15149 <ul>
15150 <li>19.4.2.1 [syserr.errcode.overview]</li>
15151 <li>20.7.12.2.8 [util.smartptr.shared.io]</li>
15152 <li>22.2.8 [facets.examples]</li>
15153 <li>23.3.5.3 [bitset.operators]</li>
15154 <li>26.3.6 [complex.ops]</li>
15155 <li>Doubled signatures in 27.5 [stream.buffers] for character inserters
15156 (ref 27.6.2.6.4 [ostream.inserters.character])
15157 + definition 27.6.2.6.4 [ostream.inserters.character]</li>
15158 <li>28.9 [re.submatch]</li>
15159 </ul>
15160
15161 <p><i>[
15162 Sophia Antipolis
15163 ]</i></p>
15164
15165
15166 <blockquote>
15167 Agree with the idea in the issue, Alisdair to provide wording.
15168 </blockquote>
15169
15170
15171
15172 <p><b>Proposed resolution:</b></p>
15173 <p>
15174 </p>
15175
15176
15177
15178
15179
15180 <hr>
15181 <h3><a name="827"></a>827. <tt>constexpr shared_ptr::shared_ptr()?</tt></h3>
15182 <p><b>Section:</b> 20.7.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>
15183  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-04-11</p>
15184 <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>
15185 <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>
15186 <p><b>Discussion:</b></p>
15187 <p>
15188 Would anyone object to making the default constructor of <tt>shared_ptr</tt> (and
15189 <tt>weak_ptr</tt> and <tt>enable_shared_from_this) constexpr</tt>? This would enable
15190 static initialization for <tt>shared_ptr</tt> variables, eliminating another
15191 unfair advantage of raw pointers.
15192 </p>
15193
15194
15195 <p><b>Proposed resolution:</b></p>
15196 <p>
15197 </p>
15198
15199
15200
15201
15202
15203 <hr>
15204 <h3><a name="828"></a>828. Static initialization for <tt>std::mutex</tt>?</h3>
15205 <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#Review">Review</a>
15206  <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-04-18</p>
15207 <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>
15208 <p><b>Discussion:</b></p>
15209 <p>
15210 [Note: I'm assuming here that 3.6.2 [basic.start.init]/1 will be fixed.]
15211 </p>
15212 <p>
15213 Currently <tt>std::mutex</tt> doesn't support static initialization. This is a
15214 regression with respect to <tt>pthread_mutex_t</tt>, which does. I believe that
15215 we should strive to eliminate such regressions in expressive power where
15216 possible, both to ease migration and to not provide incentives to (or
15217 force) people to forego the C++ primitives in favor of pthreads.
15218 </p>
15219
15220 <p><i>[
15221 Sophia Antipolis:
15222 ]</i></p>
15223
15224
15225 <blockquote>
15226 <p>
15227 We believe this is implementable on POSIX, because the initializer-list
15228 feature and the constexpr feature make this work. Double-check core
15229 language about static initialization for this case. Ask core for a core
15230 issue about order of destruction of statically-initialized objects wrt.
15231 dynamically-initialized objects (should come afterwards). Check
15232 non-POSIX systems for implementability.
15233 </p>
15234 <p>
15235 If ubiquitous implementability cannot be assured, plan B is to introduce
15236 another constructor, make this constexpr, which is
15237 conditionally-supported. To avod ambiguities, this new constructor needs
15238 to have an additional parameter.
15239 </p>
15240 </blockquote>
15241
15242
15243 <p><b>Proposed resolution:</b></p>
15244 <p>
15245 Change 30.3.1.1 [thread.mutex.class]:
15246 </p>
15247
15248 <blockquote><pre>class mutex {
15249 public:
15250   <ins>constexpr</ins> mutex();
15251   ...
15252 </pre></blockquote>
15253
15254
15255
15256
15257
15258 <hr>
15259 <h3><a name="829"></a>829. current_exception wording unclear about exception type</h3>
15260 <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>
15261  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-04-20</p>
15262 <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>
15263 <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>
15264 <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>
15265 <p><b>Discussion:</b></p>
15266 <p>Consider this code:</p>
15267
15268 <blockquote>
15269 <pre>exception_ptr xp;</pre>
15270 <pre>try {do_something(); }
15271
15272 catch (const runtime_error&amp; ) {xp = current_exception();}
15273
15274 ...
15275
15276 rethrow_exception(xp);</pre>
15277 </blockquote>
15278
15279 <p>
15280 Say <code>do_something()</code> throws an exception object of type <code>
15281 range_error</code>. What is the type of the exception object thrown by <code>
15282 rethrow_exception(xp)</code> above? It must have a type of <code>range_error</code>;
15283 if it were of type <code>runtime_error</code> it still isn't possible to
15284 propagate an exception and the exception_ptr/current_exception/rethrow_exception
15285 machinery serves no useful purpose.
15286 </p>
15287
15288 <p>
15289 Unfortunately, the current wording does not explicitly say that. Different
15290 people read the current wording and come to different conclusions. While it may
15291 be possible to deduce the correct type from the current wording, it would be
15292 much clearer to come right out and explicitly say what the type of the referred
15293 to exception is.
15294 </p>
15295
15296 <p><i>[
15297 Peter adds:
15298 ]</i></p>
15299
15300
15301 <blockquote>
15302 <p>
15303 I don't like the proposed resolution of 829. The normative text is
15304 unambiguous that the <tt>exception_ptr</tt> refers to the <em>currently handled
15305 exception</em>. This term has a standard meaning, see 15.3 [except.handle]/8; this is the
15306 exception that <tt>throw;</tt> would rethrow, see 15.1 [except.throw]/7.
15307 </p>
15308 <p>
15309 A better way to address this is to simply add the non-normative example
15310 in question as a clarification. The term <i>currently handled exception</i>
15311 should be italicized and cross-referenced. A [<i>Note:</i> the currently
15312 handled exception is the exception that a throw expression without an
15313 operand (15.1 [except.throw]/7) would rethrow. <i>--end note</i>] is also an option.
15314 </p>
15315 </blockquote>
15316
15317
15318
15319 <p><b>Proposed resolution:</b></p>
15320
15321 <p>
15322 After 18.7.5 [propagation] , paragraph 7, add the indicated text:
15323 </p>
15324
15325 <blockquote>
15326 <pre>exception_ptr current_exception();</pre>
15327
15328 <blockquote>
15329 <p>
15330 <i>Returns:</i> <code>exception_ptr</code> object that refers
15331 to the currently handled exception <ins>(15.3 [except.handle])</ins> or a copy of the currently handled
15332 exception, or a null <code>exception_ptr</code> object if no exception is being handled. If
15333 the function needs to allocate memory and the attempt fails, it returns an
15334 <code>exception_ptr</code> object that refers to an instance of <code>bad_alloc</code>.
15335 It is unspecified whether the return values of two successive calls to
15336 <code>current_exception</code> refer to the same exception object.
15337 [<i>Note:</i> that is, it
15338 is unspecified whether <code>current_exception</code>
15339 creates a new copy each time it is called.
15340 <i>-- end note</i>]
15341 </p>
15342
15343 <p>
15344 <i>Throws:</i> nothing.
15345 </p>
15346
15347 </blockquote>
15348 </blockquote>
15349
15350
15351
15352
15353
15354
15355 <hr>
15356 <h3><a name="830"></a>830. Incomplete list of char_traits specializations</h3>
15357 <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>
15358  <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2008-04-23</p>
15359 <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>
15360 <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>
15361 <p><b>Discussion:</b></p>
15362 <p>
15363   Paragraph 4 of 21.1 [char.traits] mentions that this
15364   section specifies two specializations (<code>char_traits&lt;char&gt;</code>
15365   and (<code>char_traits&lt;wchar_t&gt;</code>). However, there are actually
15366   four specializations provided, i.e. in addition to the two above also
15367   <code>char_traits&lt;char16_t&gt;</code> and <code>char_traits&lt;char32_t&gt;</code>).
15368   I guess this was just an oversight and there is nothing wrong with just
15369   fixing this.
15370 </p>
15371
15372 <p><i>[
15373 Alisdair adds:
15374 ]</i></p>
15375
15376 <blockquote>
15377 <tt>char_traits&lt; char16/32_t &gt;</tt>
15378 should also be added to <tt>&lt;ios_fwd&gt;</tt> in 27.2 [iostream.forward], and all the specializations
15379 taking a <tt>char_traits</tt> parameter in that header.
15380 </blockquote>
15381
15382 <p><i>[
15383 Sophia Antipolis:
15384 ]</i></p>
15385
15386
15387 <blockquote>
15388 <p>
15389 Idea of the issue is ok.
15390 </p>
15391 <p>
15392 Alisdair to provide wording, once that wording arrives, move to review.
15393 </p>
15394 </blockquote>
15395
15396
15397
15398 <p><b>Proposed resolution:</b></p>
15399 <p>
15400   Replace paragraph 4 of 21.1 [char.traits] by:
15401 </p>
15402 <blockquote>
15403 <p>
15404   This subclause specifies a struct template, <code>char_traits&lt;charT&gt;</code>,
15405   and four explicit specializations of it, <code>char_traits&lt;char&gt;</code>,
15406   <code>char_traits&lt;char16_t&gt;</code>, <code>char_traits&lt;char32_t&gt;</code>, and
15407   <code>char_traits&lt;wchar_t&gt;</code>, all of which appear in the header
15408   &lt;string&gt; and satisfy the requirements below.
15409 </p>
15410 </blockquote>
15411
15412
15413
15414
15415
15416 <hr>
15417 <h3><a name="832"></a>832. Applying constexpr to System error support</h3>
15418 <p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
15419  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-05-14</p>
15420 <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>
15421 <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>
15422 <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>
15423 <p><b>Discussion:</b></p>
15424 <p>
15425 Initialization of objects of class <tt>error_code</tt>
15426 (19.4.2 [syserr.errcode]) and class
15427 <tt>error_condition</tt> (19.4.3 [syserr.errcondition]) can be made simpler and more reliable by use of
15428 the new <tt>constexpr</tt> feature
15429 [<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2349.pdf">N2349</a>]
15430 of C++0x. Less code will need to be
15431 generated for both library implementations and user programs when
15432 manipulating constant objects of these types.
15433 </p>
15434
15435 <p>
15436 This was not proposed originally because the constant expressions
15437 proposal was moving into the standard at about the same time as the
15438 Diagnostics Enhancements proposal
15439 [<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html">N2241</a>],
15440 and it wasn't desirable to
15441 make the later depend on the former. There were also technical concerns
15442 as to how <tt>constexpr</tt> would apply to references. Those concerns are now
15443 resolved; <tt>constexpr</tt> can't be used for references, and that fact is
15444 reflected in the proposed resolution.
15445 </p>
15446
15447 <p>
15448 Thanks to Jens Maurer, Gabriel Dos Reis, and Bjarne Stroustrup for clarification of <tt>constexpr</tt> requirements.
15449 </p>
15450
15451 <p>
15452 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
15453 exposition only member <tt>cat_</tt> of class <tt>error_code</tt> (19.4.2 [syserr.errcode]) and class
15454 <tt>error_condition</tt> (19.4.3 [syserr.errcondition]) should be presented as a reference or pointer.
15455 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,
15456 presenting it as a pointer becomes more or less required with this
15457 proposal, given <tt>constexpr</tt> does not play well with references. The
15458 proposed resolution thus changes the private member to a pointer, which
15459 also brings it in sync with real implementations.
15460 </p>
15461
15462 <p><i>[
15463 Sophia Antipolis:
15464 ]</i></p>
15465
15466
15467 <blockquote>
15468 On going question of extern pointer vs. inline functions for interface.
15469 </blockquote>
15470
15471 <p><i>[
15472 Pre-San Francisco:
15473 ]</i></p>
15474
15475
15476 <blockquote>
15477 <p>
15478 Beman Dawes reports that this proposal is unimplementable, and thus NAD.
15479 </p>
15480 <p>
15481 Implementation would require <tt>constexpr</tt> objects of classes derived
15482 from class <tt>error_category</tt>, which has virtual functions, and that is
15483 not allowed by the core language. This was determined when trying to
15484 implement the proposal using a constexpr enabled compiler provided
15485 by Gabriel Dos Reis, and subsequently verified in discussions with
15486 Gabriel and Jens Maurer.
15487 </p>
15488
15489 </blockquote>
15490
15491
15492 <p><b>Proposed resolution:</b></p>
15493 <p>
15494 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
15495 applied to the WP, resulting in the former <tt>posix_category</tt> being renamed
15496 <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
15497 proposal must be adjusted accordingly.
15498 </p>
15499
15500 <p>
15501 Change 19.4.1.1 [syserr.errcat.overview] Class
15502 <tt>error_category</tt> overview <tt>error_category</tt> synopsis  as
15503 indicated:
15504 </p>
15505
15506 <blockquote><pre><del>const error_category&amp; get_generic_category();</del>
15507 <del>const error_category&amp; get_system_category();</del>
15508
15509 <del>static</del> <ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> generic_category<del> = get_generic_category()</del>;
15510 <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>;
15511 </pre></blockquote>
15512
15513 <p>
15514 Change 19.4.1.5 [syserr.errcat.objects] Error category objects as indicated:
15515 </p>
15516
15517 <blockquote>
15518 <pre><ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> <del>get_</del>generic_category<del>()</del>;
15519 </pre>
15520 <p>
15521 <del><i>Returns:</i> A reference</del> <ins><tt>generic_category</tt> shall point</ins>
15522 to <del>an</del> <ins>a statically initialized</ins> object of a type derived from
15523 class <tt>error_category</tt>.
15524 </p>
15525
15526 <p>
15527 <del><i>Remarks:</i></del> The object's <tt>default_error_condition</tt> and <tt>equivalent</tt> virtual
15528 functions shall behave as specified for the class <tt>error_category</tt>. The
15529 object's <tt>name</tt> virtual function shall return a pointer to the string
15530 <tt>"GENERIC"</tt>.
15531 </p>
15532
15533 <pre><ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> <del>get_</del>system_category<del>()</del>;
15534 </pre>
15535
15536 <p>
15537 <del><i>Returns:</i> A reference</del> <ins><tt>system_category</tt> shall point</ins>
15538 to <del>an</del> <ins>a statically
15539 initialized</ins> object of a type derived from class <tt>error_category</tt>.
15540 </p>
15541
15542 <p>
15543 <del><i>Remarks:</i></del>  The object's <tt>equivalent</tt> virtual functions shall behave as
15544 specified for class <tt>error_category</tt>. The object's <tt>name</tt> virtual function
15545 shall return a pointer to the string <tt>"system"</tt>. The object's
15546 <tt>default_error_condition</tt> virtual function shall behave as follows:
15547 </p>
15548
15549 <p>
15550 If the argument <tt>ev</tt> corresponds to a POSIX <tt>errno</tt> value <tt>posv</tt>, the function
15551 shall return <tt>error_condition(posv, generic_category)</tt>. Otherwise, the
15552 function shall return <tt>error_condition(ev, system_category)</tt>. What
15553 constitutes correspondence for any given operating system is
15554 unspecified. [<i>Note:</i> The number of potential system error codes is large
15555 and unbounded, and some may not correspond to any POSIX <tt>errno</tt> value.
15556 Thus implementations are given latitude in determining correspondence.
15557 <i>-- end note</i>]
15558 </p>
15559 </blockquote>
15560
15561 <p>
15562 Change 19.4.2.1 [syserr.errcode.overview] Class <tt>error_code</tt> overview as indicated:
15563 </p>
15564
15565 <blockquote><pre>class error_code {
15566 public:
15567   ...;
15568   <ins>constexpr</ins> error_code(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
15569   ...
15570   void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
15571   ...
15572   const error_category<del>&amp;</del><ins>*</ins> category() const;
15573   ...
15574 private:
15575   int val_;                    // exposition only
15576   const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
15577 </pre></blockquote>
15578
15579 <p>
15580 Change 19.4.2.2 [syserr.errcode.constructors] Class <tt>error_code</tt> constructors as indicated:
15581 </p>
15582
15583 <blockquote>
15584 <pre><ins>constexpr</ins> error_code(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
15585 </pre>
15586 <p>
15587 <i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
15588 </p>
15589 <p>
15590 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
15591 </p>
15592 <p>
15593 <i>Throws:</i> Nothing.
15594 </p>
15595 </blockquote>
15596
15597 <p>
15598 Change 19.4.2.3 [syserr.errcode.modifiers] Class <tt>error_code</tt> modifiers  as indicated:
15599 </p>
15600
15601 <blockquote>
15602 <pre>void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
15603 </pre>
15604 <p>
15605 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
15606 </p>
15607 <p>
15608 <i>Throws:</i> Nothing.
15609 </p>
15610 </blockquote>
15611
15612 <p>
15613 Change 19.4.2.4 [syserr.errcode.observers] Class <tt>error_code</tt> observers  as indicated:
15614 </p>
15615
15616 <blockquote>
15617 <pre>const error_category<del>&amp;</del><ins>*</ins> category() const;
15618 </pre>
15619
15620 <p>
15621 <i>Returns:</i> <tt>cat_</tt>.
15622 </p>
15623 <p>
15624 <i>Throws:</i> Nothing.
15625 </p>
15626 </blockquote>
15627
15628 <p>
15629 Change 19.4.3.1 [syserr.errcondition.overview] Class <tt>error_condition</tt> overview   as indicated:
15630 </p>
15631
15632 <blockquote>
15633 <pre>class error_condition {
15634 public:
15635   ...;
15636   <ins>constexpr</ins> error_condition(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
15637   ...
15638   void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
15639   ...
15640   const error_category<del>&amp;</del><ins>*</ins> category() const;
15641   ...
15642 private:
15643   int val_;                    // exposition only
15644   const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
15645 </pre>
15646 </blockquote>
15647
15648 <p>
15649 Change 19.4.3.2 [syserr.errcondition.constructors] Class <tt>error_condition</tt> constructors as indicated:
15650 </p>
15651
15652 <blockquote>
15653 <pre><ins>constexpr</ins> error_condition(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
15654 </pre>
15655 <p>
15656 <i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
15657 </p>
15658 <p>
15659 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
15660 </p>
15661 <p>
15662 <i>Throws:</i> Nothing.
15663 </p>
15664 </blockquote>
15665
15666 <p>
15667 Change 19.4.3.3 [syserr.errcondition.modifiers] Class <tt>error_condition</tt> modifiers as indicated:
15668 </p>
15669
15670 <blockquote>
15671 <pre>void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
15672 </pre>
15673 <p>
15674 <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
15675 </p>
15676 <p>
15677 <i>Throws:</i> Nothing.
15678 </p>
15679 </blockquote>
15680
15681 <p>
15682 Change 19.4.3.4 [syserr.errcondition.observers] Class <tt>error_condition</tt> observers as indicated:
15683 </p>
15684
15685 <blockquote>
15686 <pre>const error_category<del>&amp;</del><ins>*</ins> category() const;
15687 </pre>
15688 <p>
15689 <i>Returns:</i> <tt>cat_</tt>.
15690 </p>
15691 <p>
15692 <i>Throws:</i> Nothing.
15693 </p>
15694 </blockquote>
15695
15696 <p>
15697 Throughout 19.4 [syserr] System error support, change "<tt>category().</tt>"  to "<tt>category()-&gt;</tt>".
15698 Appears approximately six times.
15699 </p>
15700
15701 <p>
15702 <i>[Partially Editorial]</i> In 19.4.4 [syserr.compare] Comparison operators,
15703 paragraphs 2 and 4, change "<tt>category.equivalent(</tt>"  to
15704 "<tt>category()-&gt;equivalent(</tt>".
15705 </p>
15706
15707 <p>
15708 Change 19.4.5.1 [syserr.syserr.overview] Class system_error overview as indicated:
15709 </p>
15710
15711 <blockquote><pre>public:
15712   system_error(error_code ec, const string&amp; what_arg);
15713   system_error(error_code ec);
15714   system_error(int ev, const error_category<del>&amp;</del><ins>*</ins> ecat,
15715       const string&amp; what_arg);
15716   system_error(int ev, const error_category<del>&amp;</del><ins>*</ins> ecat);
15717 </pre></blockquote>
15718
15719 <p>
15720 Change 19.4.5.2 [syserr.syserr.members] Class system_error members as indicated:
15721 </p>
15722
15723 <blockquote>
15724 <pre>system_error(int ev, const error_category<del>&amp;</del><ins>*</ins> ecat, const string&amp; what_arg);
15725 </pre>
15726 <blockquote>
15727 <p>
15728 <i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
15729 </p>
15730 <p>
15731 <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and
15732 <tt>strcmp(runtime_error::what(), what_arg.c_str()) == 0</tt>.
15733 </p>
15734 </blockquote>
15735
15736 <pre>system_error(int ev, const error_category<del>&amp;</del><ins>*</ins> ecat);
15737 </pre>
15738 <blockquote>
15739 <p>
15740 <i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
15741 </p>
15742 <p>
15743 <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and
15744 <tt>strcmp(runtime_error::what(), "") == 0</tt>.
15745 </p>
15746 </blockquote>
15747 </blockquote>
15748
15749
15750
15751
15752
15753
15754 <hr>
15755 <h3><a name="833"></a>833. Freestanding implementations header list needs review for C++0x</h3>
15756 <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#Open">Open</a>
15757  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-05-14</p>
15758 <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>
15759 <p><b>Discussion:</b></p>
15760 <p>
15761 Once the C++0x standard library is feature complete, the LWG needs to
15762 review 17.4.1.3 [compliance] Freestanding implementations header list to
15763 ensure it reflects LWG consensus.
15764 </p>
15765
15766
15767 <p><b>Proposed resolution:</b></p>
15768
15769
15770
15771
15772
15773 <hr>
15774 <h3><a name="834"></a>834. Unique_ptr::pointer requirements underspecified</h3>
15775 <p><b>Section:</b> 20.7.11.2 [unique.ptr.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
15776  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-05-14</p>
15777 <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>
15778 <p><b>Discussion:</b></p>
15779 <p>
15780 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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
15781 extension point for <tt>unique_ptr</tt> by granting support for an optional
15782 <tt>deleter_type::pointer</tt> to act as pointer-like replacement for <tt>element_type*</tt>
15783 (In the following: <tt>pointer</tt>).
15784 </p>
15785 <p>
15786 Unfortunately no requirements are specified for the type <tt>pointer</tt> which has
15787 impact on at least two key features of <tt>unique_ptr</tt>:
15788 </p>
15789
15790 <ol>
15791 <li>Operational fail-safety.</li>
15792 <li>(Well-)Definedness of expressions.</li>
15793 </ol>
15794
15795 <p>
15796 <tt>Unique_ptr</tt> specification makes great efforts to require that essentially *all*
15797 operations cannot throw and therefore adds proper wording to the affected
15798 operations of the deleter as well. If user-provided <tt>pointer</tt>-emulating types
15799 ("smart pointers") will be allowed, either *all* throw-nothing clauses have to
15800 be replaced by weaker "An exception is thrown only if <tt>pointer</tt>'s {op} throws
15801 an exception"-clauses or it has to be said explicitly that all used
15802 operations of
15803 <tt>pointer</tt> are required *not* to throw. I understand the main focus of <tt>unique_ptr</tt>
15804 to be as near as possible to the advantages of native pointers which cannot
15805 fail and thus strongly favor the second choice. Also, the alternative position
15806 would make it much harder to write safe and simple template code for
15807 <tt>unique_ptr</tt>. Additionally, I assume that a general statement need to be given
15808 that all of the expressions of <tt>pointer</tt> used to define semantics are required to
15809 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>).
15810 </p>
15811
15812 <p><i>[
15813 Sophia Antipolis:
15814 ]</i></p>
15815
15816
15817 <blockquote>
15818 <p>
15819 Howard: We maybe need a core concept <tt>PointerLike</tt>, but we don't need the
15820 arithmetic (see <tt>shared_ptr</tt> vs. <tt>vector&lt;T&gt;::iterator</tt>.
15821 </p>
15822 <p>
15823 Howard will go through and enumerate the individual requirements wrt. <tt>pointer</tt> for each member function.
15824 </p>
15825 </blockquote>
15826
15827
15828
15829 <p><b>Proposed resolution:</b></p>
15830 <p>
15831 Add the following sentence just at the end of the newly proposed
15832 20.7.11.2 [unique.ptr.single]/p. 3:
15833 </p>
15834
15835 <blockquote>
15836 <tt>unique_ptr&lt;T, D&gt;::pointer</tt>'s operations shall be well-formed, shall have well
15837 defined behavior, and shall not throw exceptions.
15838 </blockquote>
15839
15840
15841
15842
15843
15844 <hr>
15845 <h3><a name="835"></a>835. tying two streams together (correction to DR 581)</h3>
15846 <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>
15847  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
15848 <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>
15849 <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>
15850 <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>
15851 <p><b>Discussion:</b></p>
15852        <p>
15853
15854 The fix for
15855 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>,
15856 now integrated into the working paper, overlooks a couple of minor
15857 problems.
15858
15859        </p>
15860        <p>
15861
15862 First, being an unformatted function once again, <code>flush()</code>
15863 is required to create a sentry object whose constructor must, among
15864 other things, flush the tied stream. When two streams are tied
15865 together, either directly or through another intermediate stream
15866 object, flushing one will also cause a call to <code>flush()</code> on
15867 the other tied stream(s) and vice versa, ad infinitum. The program
15868 below demonstrates the problem.
15869
15870        </p>
15871        <p>
15872
15873 Second, as Bo Persson notes in his
15874 comp.lang.c++.moderated <a href="http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/f2187794e9cc036d/305df31dc583054a">post</a>,
15875 for streams with the <code>unitbuf</code> flag set such
15876 as <code>std::stderr</code>, the destructor of the sentry object will
15877 again call <code>flush()</code>. This seems to create an infinite
15878 recursion for <code>std::cerr &lt;&lt; std::flush;</code>
15879
15880        </p>
15881        <blockquote>
15882            <pre>#include &lt;iostream&gt;
15883
15884 int main ()
15885 {
15886    std::cout.tie (&amp;std::cerr);
15887    std::cerr.tie (&amp;std::cout);
15888    std::cout &lt;&lt; "cout\n";
15889    std::cerr &lt;&lt; "cerr\n";
15890 }
15891            </pre>
15892        </blockquote>
15893
15894    <p><b>Proposed resolution:</b></p>
15895        <p>
15896
15897 I think an easy way to plug the first hole is to add a requires clause
15898 to <code>ostream::tie(ostream *tiestr)</code> requiring the this
15899 pointer not be equal to any pointer on the list starting
15900 with <code>tiestr-&gt;tie()</code>
15901 through <code>tiestr()-&gt;tie()-&gt;tie()</code> and so on. I am not
15902 proposing that we require implementations to traverse this list,
15903 although I think we could since the list is unlikely to be very long.
15904
15905        </p>
15906        <p>
15907
15908 Add a <i>Requires</i> clause to 27.4.4.2 [basic.ios.members] withethe following
15909 text:
15910
15911        </p>
15912        <blockquote>
15913
15914 <i>Requires:</i> If <code>(tiestr != 0)</code> is
15915 true, <code>tiestr</code> must not be reachable by traversing the
15916 linked list of tied stream objects starting
15917 from <code>tiestr-&gt;tie()</code>.
15918
15919        </blockquote>
15920        <p>
15921
15922 In addition, to prevent the infinite recursion that Bo writes about in
15923 his comp.lang.c++.moderated post, I propose to change
15924 27.6.2.4 [ostream::sentry], p2 like so:
15925
15926        </p>
15927        <blockquote>
15928
15929 If <code>((os.flags() &amp; ios_base::unitbuf) &amp;&amp;
15930 !uncaught_exception())</code> is true,
15931 calls <del>os.flush()</del> <ins><code>os.rdbuf()-&gt;pubsync()</code></ins>.
15932
15933        </blockquote>
15934
15935
15936
15937
15938 <hr>
15939 <h3><a name="836"></a>836.
15940        effects of <code>money_base::space</code> and
15941        <code>money_base::none</code> on <code>money_get</code>
15942    </h3>
15943 <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>
15944  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
15945 <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>
15946 <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>
15947 <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>
15948 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a></p>
15949 <p><b>Discussion:</b></p>
15950        <p>
15951
15952 In paragraph 2, 22.2.6.1.2 [locale.money.get.virtuals] specifies the following:
15953
15954        </p>
15955        <blockquote>
15956
15957 Where <code>space</code> or <code>none</code> appears in the format
15958 pattern, except at the end, optional white space (as recognized
15959 by <code>ct.is</code>) is consumed after any required space.
15960
15961        </blockquote>
15962        <p>
15963
15964 This requirement can be (and has been) interpreted two mutually
15965 exclusive ways by different readers. One possible interpretation
15966 is that:
15967
15968        </p>
15969        <blockquote>
15970            <ol>
15971                <li>
15972
15973 where <code>money_base::space</code> appears in the format, at least
15974 one space is required, and
15975
15976                </li>
15977                <li>
15978
15979 where <code>money_base::none</code> appears in the format, space is
15980 allowed but not required.
15981
15982                </li>
15983            </ol>
15984        </blockquote>
15985        <p>
15986
15987 The other is that:
15988
15989        </p>
15990        <blockquote>
15991
15992 where either <code>money_base::space</code> or <code>money_base::none</code> appears in the format, white space is optional.
15993
15994        </blockquote>
15995
15996
15997    <p><b>Proposed resolution:</b></p>
15998        <p>
15999
16000 I propose to change the text to make it clear that the first
16001 interpretation is intended, that is, to make following change to
16002 22.2.6.1.2 [locale.money.get.virtuals], p2:
16003
16004        </p>
16005
16006        <blockquote>
16007
16008 When <code><ins>money_base::</ins>space</code>
16009 or <code><ins>money_base::</ins>none</code> appears <ins>as the last
16010 element </ins>in the format pattern, <del>except at the end, optional
16011 white space (as recognized by <code>ct.is</code>) is consumed after
16012 any required space.</del> <ins>no white space is consumed. Otherwise,
16013 where <code>money_base::space</code> appears in any of the initial
16014 elements of the format pattern, at least one white space character is
16015 required. Where <code>money_base::none</code> appears in any of the
16016 initial elements of the format pattern, white space is allowed but not
16017 required. In either case, any required followed by all optional white
16018 space (as recognized by <code>ct.is()</code>) is consumed.</ins>
16019 If <code>(str.flags() &amp; str.showbase)</code> is <code>false</code>, ...
16020
16021        </blockquote>
16022
16023
16024
16025
16026 <hr>
16027 <h3><a name="837"></a>837.
16028    <code>basic_ios::copyfmt()</code> overly loosely specified
16029  </h3>
16030 <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>
16031  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
16032 <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>
16033 <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>
16034 <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>
16035 <p><b>Discussion:</b></p>
16036    <p>
16037
16038 The <code>basic_ios::copyfmt()</code> member function is specified in 27.4.4.2 [basic.ios.members] to have the following effects:
16039
16040    </p>
16041    <blockquote>
16042
16043 <i>Effects</i>: If <code>(this == &amp;rhs)</code> does
16044 nothing. Otherwise assigns to the member objects of <code>*this</code>
16045 the corresponding member objects of <code>rhs</code>, except that
16046
16047      <ul>
16048        <li>
16049
16050 <code>rdstate()</code> and <code>rdbuf()</code> are left unchanged;
16051
16052        </li>
16053        <li>
16054
16055 <code>exceptions()</code> is altered last by
16056 calling <code>exceptions(rhs.except)</code>
16057
16058        </li>
16059        <li>
16060
16061 the contents of arrays pointed at by <code>pword</code>
16062 and <code>iword</code> are copied not the pointers themselves
16063
16064        </li>
16065      </ul>
16066    </blockquote>
16067    <p>
16068
16069 Since the rest of the text doesn't specify what the member objects
16070 of <code>basic_ios</code> are this seems a little too loose.
16071
16072    </p>
16073
16074
16075  <p><b>Proposed resolution:</b></p>
16076    <p>
16077
16078 I propose to tighten things up by adding a <i>Postcondition</i> clause
16079 to the function like so:
16080
16081    </p>
16082    <blockquote>
16083      <i>Postconditions:</i>
16084
16085      <table border="1">
16086        <thead>
16087          <tr>
16088            <th colspan="2"><code>copyfmt()</code> postconditions</th>
16089          </tr>
16090          <tr>
16091            <th>Element</th>
16092            <th>Value</th>
16093          </tr>
16094        </thead>
16095        <tbody>
16096          <tr>
16097            <td><code>rdbuf()</code></td>
16098            <td><i>unchanged</i></td>
16099          </tr>
16100          <tr>
16101            <td><code>tie()</code></td>
16102            <td><code>rhs.tie()</code></td>
16103          </tr>
16104          <tr>
16105            <td><code>rdstate()</code></td>
16106            <td><i>unchanged</i></td>
16107          </tr>
16108          <tr>
16109            <td><code>exceptions()</code></td>
16110            <td><code>rhs.exceptions()</code></td>
16111          </tr>
16112          <tr>
16113            <td><code>flags()</code></td>
16114            <td><code>rhs.flags()</code></td>
16115          </tr>
16116          <tr>
16117            <td><code>width()</code></td>
16118            <td><code>rhs.width()</code></td>
16119          </tr>
16120          <tr>
16121            <td><code>precision()</code></td>
16122            <td><code>rhs.precision()</code></td>
16123          </tr>
16124          <tr>
16125            <td><code>fill()</code></td>
16126            <td><code>rhs.fill()</code></td>
16127          </tr>
16128          <tr>
16129            <td><code>getloc()</code></td>
16130            <td><code>rhs.getloc()</code></td>
16131          </tr>
16132        </tbody>
16133      </table>
16134    </blockquote>
16135    <p>
16136
16137 The format of the table follows Table 117 (as
16138 of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2588.pdf">N2588</a>): <code>basic_ios::init()</code>
16139 effects.
16140
16141    </p>
16142    <p>
16143
16144 The intent of the new table is not to impose any new requirements or
16145 change existing ones, just to be more explicit about what I believe is
16146 already there.
16147
16148    </p>
16149
16150
16151
16152
16153 <hr>
16154 <h3><a name="838"></a>838.
16155    can an <i>end-of-stream</i> iterator become a <i>non-end-of-stream</i> one?
16156  </h3>
16157 <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>
16158  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
16159 <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>
16160 <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>
16161 <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>
16162 <p><b>Discussion:</b></p>
16163    <p>
16164
16165 From message c++std-lib-20003...
16166
16167    </p>
16168    <p>
16169
16170 The description of <code>istream_iterator</code> in
16171 24.5.1 [istream.iterator], p1 specifies that objects of the
16172 class become the <i>end-of-stream</i> (EOS) iterators under the
16173 following condition (see also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a> another problem
16174 with this paragraph):
16175
16176    </p>
16177    <blockquote>
16178
16179 If the end of stream is reached (<code>operator void*()</code> on the
16180 stream returns <code>false</code>), the iterator becomes equal to
16181 the <i>end-of-stream</i> iterator value.
16182
16183    </blockquote>
16184    <p>
16185
16186 One possible implementation approach that has been used in practice is
16187 for the iterator to set its <code>in_stream</code> pointer to 0 when
16188 it reaches the end of the stream, just like the default ctor does on
16189 initialization. The problem with this approach is that
16190 the <i>Effects</i> clause for <code>operator++()</code> says the
16191 iterator unconditionally extracts the next value from the stream by
16192 evaluating <code>*in_stream &gt;&gt; value</code>, without checking
16193 for <code>(in_stream == 0)</code>.
16194
16195    </p>
16196    <p>
16197
16198 Conformance to the requirement outlined in the <i>Effects</i> clause
16199 can easily be verified in programs by setting <code>eofbit</code>
16200 or <code>failbit</code> in <code>exceptions()</code> of the associated
16201 stream and attempting to iterate past the end of the stream: each
16202 past-the-end access should trigger an exception. This suggests that
16203 some other, more elaborate technique might be intended.
16204
16205    </p>
16206    <p>
16207
16208 Another approach, one that allows <code>operator++()</code> to attempt
16209 to extract the value even for EOS iterators (just as long
16210 as <code>in_stream</code> is non-0) is for the iterator to maintain a
16211 flag indicating whether it has reached the end of the stream. This
16212 technique would satisfy the presumed requirement implied by
16213 the <i>Effects</i> clause mentioned above, but it isn't supported by
16214 the exposition-only members of the class (no such flag is shown). This
16215 approach is also found in existing practice.
16216
16217    </p>
16218    <p>
16219
16220 The inconsistency between existing implementations raises the question
16221 of whether the intent of the specification is that a non-EOS iterator
16222 that has reached the EOS become a non-EOS one again after the
16223 stream's <code>eofbit</code> flag has been cleared? That is, are the
16224 assertions in the program below expected to pass?
16225
16226    </p>
16227    <blockquote>
16228      <pre>   sstream strm ("1 ");
16229    istream_iterator eos;
16230    istream_iterator it (strm);
16231    int i;
16232    i = *it++
16233    assert (it == eos);
16234    strm.clear ();
16235    strm &lt;&lt; "2 3 ";
16236    assert (it != eos);
16237    i = *++it;
16238    assert (3 == i);
16239      </pre>
16240    </blockquote>
16241    <p>
16242
16243 Or is it intended that once an iterator becomes EOS it stays EOS until
16244 the end of its lifetime?
16245
16246    </p>
16247
16248
16249  <p><b>Proposed resolution:</b></p>
16250    <p>
16251
16252 The discussion of this issue on the reflector suggests that the intent
16253 of the standard is for an <code>istreambuf_iterator</code> that has
16254 reached the EOS to remain in the EOS state until the end of its
16255 lifetime. Implementations that permit EOS iterators to return to a
16256 non-EOS state may only do so as an extension, and only as a result of
16257 calling <code>istream_iterator</code> member functions on EOS
16258 iterators whose behavior is in this case undefined.
16259
16260    </p>
16261    <p>
16262
16263 To this end we propose to change 24.5.1 [istream.iterator], p1,
16264 as follows:
16265
16266    </p>
16267    <blockquote>
16268
16269 The result of operator-&gt; on an end<ins>-</ins>of<ins>-</ins>stream
16270 is not defined. For any other iterator value a <code>const T*</code>
16271 is returned.<ins> Invoking <code>operator++()</code> on
16272 an <i>end-of-stream</i> iterator is undefined.</ins> It is impossible
16273 to store things into istream iterators...
16274
16275    </blockquote>
16276    <p>
16277
16278 Add pre/postconditions to the member function descriptions of <code>istream_iterator</code> like so:
16279
16280    </p>
16281    <blockquote>
16282
16283 <pre>istream_iterator();</pre>
16284
16285 <i>Effects</i>: Constructs the <i>end-of-stream</i> iterator.<br>
16286 <ins><i>Postcondition</i>: <code>in_stream == 0</code>.</ins>
16287
16288 <pre>istream_iterator(istream_type &amp;s);</pre>
16289
16290 <i>Effects</i>: Initializes <code>in_stream</code> with &amp;s. value
16291 may be initialized during construction or the first time it is
16292 referenced.<br>
16293 <ins><i>Postcondition</i>: <code>in_stream == &amp;s</code>.</ins>
16294
16295 <pre>istream_iterator(const istream_iterator &amp;x);</pre>
16296
16297 <i>Effects</i>: Constructs a copy of <code>x</code>.<br>
16298 <ins><i>Postcondition</i>: <code>in_stream == x.in_stream</code>.</ins>
16299
16300 <pre>istream_iterator&amp; operator++();</pre>
16301
16302 <ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br>
16303 <i>Effects</i>: <code>*in_stream &gt;&gt; value</code>.
16304
16305 <pre>istream_iterator&amp; operator++(int);</pre>
16306
16307 <ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br>
16308 <i>Effects</i>:
16309    <blockquote><pre>istream_iterator tmp (*this);
16310 *in_stream &gt;&gt; value;
16311 return tmp;
16312      </pre>
16313      </blockquote>
16314    </blockquote>
16315
16316
16317
16318
16319 <hr>
16320 <h3><a name="839"></a>839. Maps and sets missing splice operation</h3>
16321 <p><b>Section:</b> 23.3 [associative], 23.4 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
16322  <b>Submitter:</b> Alan Talbot <b>Date:</b> 2008-05-18</p>
16323 <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>
16324 <p><b>Discussion:</b></p>
16325 <p>
16326 Splice is a very useful feature of <tt>list</tt>. This functionality is also very
16327 useful for any other node based container, and I frequently wish it were
16328 available for maps and sets. It seems like an omission that these
16329 containers lack this capability. Although the complexity for a splice is
16330 the same as for an insert, the actual time can be much less since the
16331 objects need not be reallocated and copied. When the element objects are
16332 heavy and the compare operations are fast (say a <tt>map&lt;int, huge_thingy&gt;</tt>)
16333 this can be a big win.
16334 </p>
16335
16336 <p>
16337 <b>Suggested resolution:</b>
16338 </p>
16339
16340 <p>
16341 Add the following signatures to map, set, multimap, multiset, and the unordered associative containers:
16342 </p>
16343 <blockquote><pre>
16344 void splice(list&lt;T,Allocator&gt;&amp;&amp; x);
16345 void splice(list&lt;T,Allocator&gt;&amp;&amp; x, const_iterator i);
16346 void splice(list&lt;T,Allocator&gt;&amp;&amp; x, const_iterator first, const_iterator last);
16347 </pre></blockquote>
16348
16349 <p>
16350 Hint versions of these are also useful to the extent hint is useful.
16351 (I'm looking for guidance about whether hints are in fact useful.)
16352 </p>
16353
16354 <blockquote><pre>
16355 void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x);
16356 void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x, const_iterator i);
16357 void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x, const_iterator first, const_iterator last);
16358 </pre></blockquote>
16359
16360 <p><i>[
16361 Sophia Antipolis:
16362 ]</i></p>
16363
16364
16365 <blockquote>
16366 <p>
16367 Don't try to <tt>splice "list"</tt> into the other containers, it should be container-type.
16368 </p>
16369 <p>
16370 <tt>forward_list</tt> already has <tt>splice_after</tt>.
16371 </p>
16372 <p>
16373 Would "<tt>splice</tt>" make sense for an <tt>unordered_map</tt>?
16374 </p>
16375 <p>
16376 Jens, Robert: "<tt>splice</tt>" is not the right term, it implies maintaining ordering in <tt>list</tt>s.
16377 </p>
16378 <p>
16379 Howard: <tt>adopt</tt>?
16380 </p>
16381 <p>
16382 Jens: <tt>absorb</tt>?
16383 </p>
16384 <p>
16385 Alan: <tt>subsume</tt>?
16386 </p>
16387 <p>
16388 Robert: <tt>recycle</tt>?
16389 </p>
16390 <p>
16391 Howard: <tt>transfer</tt>? (but no direction)
16392 </p>
16393 <p>
16394 Jens: <tt>transfer_from</tt>. No.
16395 </p>
16396 <p>
16397 Alisdair: Can we give a nothrow guarantee? If your <tt>compare()</tt> and <tt>hash()</tt> doesn't throw, yes.
16398 </p>
16399 <p>
16400 Daniel: For <tt>unordered_map</tt>, we can't guarantee nothrow.
16401 </p>
16402 </blockquote>
16403
16404
16405
16406 <p><b>Proposed resolution:</b></p>
16407
16408
16409
16410
16411
16412 <hr>
16413 <h3><a name="841"></a>841. cstdint.syn inconsistent with C99</h3>
16414 <p><b>Section:</b> 18.3.1 [cstdint.syn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
16415  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
16416 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint.syn">issues</a> in [cstdint.syn].</p>
16417 <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>
16418 <p><b>Discussion:</b></p>
16419    <p>
16420
16421 In specifying the names of macros and types defined in
16422 header <code>&lt;stdint.h&gt;</code>, C99 makes use of the
16423 symbol <code><i>N</i></code> to accommodate unusual platforms with
16424 word sizes that aren't powers of two. C99
16425 permits <code><i>N</i></code> to take on any positive integer value
16426 (including, for example, 24).
16427
16428    </p>
16429    <p>
16430
16431 In  cstdint.syn Header <code>&lt;cstdint&gt;</code>
16432 synopsis, C++ on the other hand, fixes the value
16433 of <code><i>N</i></code> to 8, 16, 32, and 64, and specifies only
16434 types with these exact widths.
16435
16436    </p>
16437    <p>
16438    </p>
16439
16440 In addition, paragraph 1 of the same section makes use of a rather
16441 informal shorthand notation to specify sets of macros. When
16442 interpreted strictly, the notation specifies macros such
16443 as <code>INT_8_MIN</code> that are not intended to be specified.
16444
16445    <p>
16446
16447 Finally, the section is missing the usual table of symbols defined
16448 in that header, making it inconsistent with the rest of the
16449 specification.
16450
16451    </p>
16452
16453  <p><b>Proposed resolution:</b></p>
16454    <p>
16455
16456 I propose to use the same approach in the C++ spec as C99 uses, that
16457 is, to specify the header synopsis in terms of "exposition only" types
16458 that make use of the symbol <code><i>N</i></code> to denote one or
16459 more of a theoretically unbounded set of widths.
16460
16461    </p>
16462    <p>
16463
16464 Further, I propose to add a new table to section listing the symbols
16465 defined in the header using a more formal notation that avoids
16466 introducing inconsistencies.
16467
16468    </p>
16469    <p>
16470
16471 To this effect, in  cstdint.syn
16472 Header <code>&lt;cstdint&gt;</code> synopsis, replace both the
16473 synopsis and paragraph 1 with the following text:
16474
16475    </p>
16476    <blockquote>
16477      <p>
16478        </p><ol>
16479          <li>
16480
16481 In the names defined in the <code>&lt;cstdint&gt;</code> header, the
16482 symbol <code><i>N</i></code> represents a positive decimal integer
16483 with no leading zeros (e.g., 8 or 24, but not 0, 04, or 048). With the
16484 exception of exact-width types, macros and types for values
16485 of <code><i>N</i></code> in the set of 8, 16, 32, and 64 are
16486 required. Exact-width types, and any macros and types for values
16487 of <code><i>N</i></code> other than 8, 16, 32, and 64 are
16488 optional. However, if an implementation provides integer types with
16489 widths of 8, 16, 32, or 64 bits, the corresponding exact-width types
16490 and macros are required.
16491
16492          </li>
16493        </ol>
16494
16495      <pre>namespace std {
16496
16497    // required types
16498
16499    // Fastest minimum-width integer types
16500    typedef <i>signed integer type</i>   int_fast8_t;
16501    typedef <i>signed integer type</i>   int_fast16_t;
16502    typedef <i>signed integer type</i>   int_fast32_t;
16503    typedef <i>signed integer type</i>   int_fast64_t;
16504
16505    typedef <i>unsigned integer type</i> uint_fast8_t;
16506    typedef <i>unsigned integer type</i> uint_fast16_t;
16507    typedef <i>unsigned integer type</i> uint_fast32_t;
16508    typedef <i>unsigned integer type</i> uint_fast64_t;
16509
16510    // Minimum-width integer types
16511    typedef <i>signed integer type</i>   int_least8_t;
16512    typedef <i>signed integer type</i>   int_least16_t;
16513    typedef <i>signed integer type</i>   int_least32_t;
16514    typedef <i>signed integer type</i>   int_least64_t;
16515
16516    typedef <i>unsigned integer type</i> uint_least8_t;
16517    typedef <i>unsigned integer type</i> uint_least16_t;
16518    typedef <i>unsigned integer type</i> uint_least32_t;
16519    typedef <i>unsigned integer type</i> uint_least64_t;
16520
16521    // Greatest-width integer types
16522    typedef <i>signed integer type</i>   intmax_t;
16523    typedef <i>unsigned integer type</i> uintmax_t;
16524
16525    // optionally defined types
16526
16527    // Exact-width integer types
16528    typedef <i>signed integer type</i>   int<i>N</i>_t;
16529    typedef <i>unsigned integer type</i> uint<i>N</i>_t;
16530
16531    // Fastest minimum-width integer types for values
16532    // of <i>N</i> other than 8, 16, 32, and 64
16533    typedef <i>signed integer type</i>   uint_fast<i>N</i>_t;
16534    typedef <i>unsigned integer type</i> uint_fast<i>N</i>_t;
16535
16536    // Minimum-width integer types for values
16537    // of <i>N</i> other than 8, 16, 32, and 64
16538    typedef <i>signed integer type</i>   uint_least<i>N</i>_t;
16539    typedef <i>unsigned integer type</i> uint_least<i>N</i>_t;
16540
16541    // Integer types capable of holding object pointers
16542    typedef <i>signed integer type</i>   intptr_t;
16543    typedef <i>signed integer type</i>   intptr_t;
16544
16545 }</pre>
16546    </blockquote>
16547    <p>
16548
16549 [Note to editor: Remove all of the existing paragraph 1 from  cstdint.syn.]
16550
16551    </p>
16552    <blockquote>
16553      Table ??: Header <code>&lt;cstdint&gt;</code> synopsis
16554      <table border="1">
16555        <thead>
16556          <tr>
16557            <th>Type</th>
16558            <th colspan="3">Name(s)</th>
16559          </tr>
16560        </thead>
16561        <tbody>
16562          <tr>
16563            <td rowspan="11"><b>Macros:</b></td>
16564            <td><tt>INT<i>N</i>_MIN</tt></td>
16565            <td><tt>INT<i>N</i>_MAX</tt></td>
16566            <td><tt>UINT<i>N</i>_MAX</tt></td>
16567          </tr>
16568          <tr>
16569            <td><tt>INT_FAST<i>N</i>_MIN</tt></td>
16570            <td><tt>INT_FAST<i>N</i>_MAX</tt></td>
16571            <td><tt>UINT_FAST<i>N</i>_MAX</tt></td>
16572          </tr>
16573          <tr>
16574            <td><tt>INT_LEAST<i>N</i>_MIN</tt></td>
16575            <td><tt>INT_LEAST<i>N</i>_MAX</tt></td>
16576            <td><tt>UINT_LEAST<i>N</i>_MAX</tt></td>
16577          </tr>
16578          <tr>
16579            <td><tt>INTPTR_MIN</tt></td>
16580            <td><tt>INTPTR_MAX</tt></td>
16581            <td><tt>UINTPTR_MAX</tt></td>
16582          </tr>
16583          <tr>
16584            <td><tt>INTMAX_MIN</tt></td>
16585            <td><tt>INTMAX_MAX</tt></td>
16586            <td><tt>UINTMAX_MAX</tt></td>
16587          </tr>
16588          <tr>
16589            <td><tt>PTRDIFF_MIN</tt></td>
16590            <td><tt>PTRDIFF_MAX</tt></td>
16591            <td><tt>PTRDIFF_MAX</tt></td>
16592          </tr>
16593          <tr>
16594            <td><tt>SIG_ATOMIC_MIN</tt></td>
16595            <td><tt>SIG_ATOMIC_MAX</tt></td>
16596            <td><tt>SIZE_MAX</tt></td>
16597          </tr>
16598          <tr>
16599            <td><tt>WCHAR_MIN</tt></td>
16600            <td><tt>WCHAR_MAX</tt></td>
16601          <td></td>
16602          </tr>
16603          <tr>
16604            <td><tt>WINT_MIN</tt></td>
16605            <td><tt>WINT_MAX</tt></td>
16606            <td></td>
16607          </tr>
16608          <tr>
16609            <td><tt>INT<i>N</i>_C()</tt></td>
16610            <td><tt>UINT<i>N</i>_C()</tt></td>
16611            <td></td>
16612          </tr>
16613          <tr>
16614            <td><tt>INTMAX_C()</tt></td>
16615            <td><tt>UINTMAX_C()</tt></td>
16616            <td></td>
16617          </tr>
16618          <tr>
16619            <td rowspan="5"><b>Types:</b></td>
16620            <td><tt>int<i>N</i>_t</tt></td>
16621            <td><tt>uint<i>N</i>_t</tt></td>
16622            <td></td>
16623          </tr>
16624          <tr>
16625            <td><tt>int_fast<i>N</i>_t</tt></td>
16626            <td><tt>uint_fast<i>N</i>_t</tt></td>
16627            <td></td>
16628          </tr>
16629          <tr>
16630            <td><tt>int_least<i>N</i>_t</tt></td>
16631            <td><tt>uint_least<i>N</i>_t</tt></td>
16632            <td></td>
16633          </tr>
16634          <tr>
16635            <td><tt>intptr_t</tt></td>
16636            <td><tt>uintptr_t</tt></td>
16637            <td></td>
16638          </tr>
16639          <tr>
16640            <td><tt>intmax_t</tt></td>
16641            <td><tt>uintmax_t</tt></td>
16642            <td></td>
16643          </tr>
16644        </tbody>
16645      </table>
16646    </blockquote>
16647
16648
16649
16650
16651
16652 <hr>
16653 <h3><a name="842"></a>842. ConstructibleAsElement and bit containers</h3>
16654 <p><b>Section:</b> 23.1 [container.requirements], 23.2.7 [vector.bool], 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
16655  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-06-03</p>
16656 <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>
16657 <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>
16658 <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>
16659 <p><b>Discussion:</b></p>
16660 <p>
16661 23.1 [container.requirements]/p3 says:
16662 </p>
16663
16664 <blockquote>
16665 Objects stored in these components shall be constructed using
16666 <tt>construct_element</tt> (20.6.9). For each operation that inserts an
16667 element of type <tt>T</tt> into a container (<tt>insert</tt>,
16668 <tt>push_back</tt>, <tt>push_front</tt>, <tt>emplace</tt>, etc.) with
16669 arguments <tt>args... T</tt> shall be <tt>ConstructibleAsElement</tt>,
16670 as described in table 88. [<i>Note:</i> If the component is instantiated
16671 with a scoped allocator of type <tt>A</tt> (i.e., an allocator for which
16672 <tt>is_scoped_allocator&lt;A&gt;::value</tt> is <tt>true</tt>), then
16673 <tt>construct_element</tt> may pass an inner allocator argument to
16674 <tt>T</tt>'s constructor. <i>-- end note</i>]
16675 </blockquote>
16676
16677 <p>
16678 However <tt>vector&lt;bool, A&gt;</tt> (23.2.7 [vector.bool]) and <tt>bitset&lt;N&gt;</tt>
16679 (23.3.5 [template.bitset]) store bits, not <tt>bool</tt>s, and <tt>bitset&lt;N&gt;</tt>
16680 does not even have an allocator.  But these containers are governed by this clause.  Clearly this
16681 is not implementable.
16682 </p>
16683
16684
16685 <p><b>Proposed resolution:</b></p>
16686 <p>
16687 Change 23.1 [container.requirements]/p3:
16688 </p>
16689
16690 <blockquote>
16691 Objects stored in these components shall be constructed using
16692 <tt>construct_element</tt> (20.6.9)<ins>, unless otherwise specified</ins>.
16693 For each operation that inserts an
16694 element of type <tt>T</tt> into a container (<tt>insert</tt>,
16695 <tt>push_back</tt>, <tt>push_front</tt>, <tt>emplace</tt>, etc.) with
16696 arguments <tt>args... T</tt> shall be <tt>ConstructibleAsElement</tt>,
16697 as described in table 88. [<i>Note:</i> If the component is instantiated
16698 with a scoped allocator of type <tt>A</tt> (i.e., an allocator for which
16699 <tt>is_scoped_allocator&lt;A&gt;::value</tt> is <tt>true</tt>), then
16700 <tt>construct_element</tt> may pass an inner allocator argument to
16701 <tt>T</tt>'s constructor. <i>-- end note</i>]
16702 </blockquote>
16703
16704 <p>
16705 Change 23.2.7 [vector.bool]/p2:
16706 </p>
16707
16708 <blockquote>
16709 Unless described below, all operations have the same requirements and semantics as the primary <tt>vector</tt> template,
16710 except that operations dealing with the <tt>bool</tt> value type map to bit values in the container storage<ins>,
16711 and <tt>construct_element</tt> (23.1 [container.requirements]) is not used to construct these values</ins>.
16712 </blockquote>
16713
16714 <p>
16715 Move 23.3.5 [template.bitset] to clause 20.
16716 </p>
16717
16718
16719
16720
16721
16722
16723 <hr>
16724 <h3><a name="843"></a>843.  Reference Closure</h3>
16725 <p><b>Section:</b> 20.6.17.1 [func.referenceclosure.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
16726  <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-06-02</p>
16727 <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>
16728 <p><b>Discussion:</b></p>
16729 <p>
16730 The <tt>std::reference_closure</tt> type has a deleted copy assignment operator
16731 under the theory that references cannot be assigned, and hence the
16732 assignment of its reference member must necessarily be ill-formed.
16733 </p>
16734 <p>
16735 However, other types, notably <tt>std::reference_wrapper</tt> and <tt>std::function</tt>
16736 provide for the "copying of references", and thus the current definition
16737 of <tt>std::reference_closure</tt> seems unnecessarily restrictive.  In particular,
16738 it should be possible to write generic functions using both <tt>std::function</tt>
16739 and <tt>std::reference_closure</tt>, but this generality is much harder when
16740 one such type does not support assignment.
16741 </p>
16742 <p>
16743 The definition of <tt>reference_closure</tt> does not necessarily imply direct
16744 implementation via reference types.  Indeed, the <tt>reference_closure</tt> is
16745 best implemented via a frame pointer, for which there is no standard
16746 type.
16747 </p>
16748 <p>
16749 The semantics of assignment are effectively obtained by use of the
16750 default destructor and default copy assignment operator via
16751 </p>
16752
16753 <blockquote><pre>x.~reference_closure(); new (x) reference_closure(y);
16754 </pre></blockquote>
16755
16756 <p>
16757 So the copy assignment operator generates no significant real burden
16758 to the implementation.
16759 </p>
16760
16761
16762 <p><b>Proposed resolution:</b></p>
16763 <p>
16764 In 20.6.17 [func.referenceclosure] Class template reference_closure,
16765 replace the <tt>=delete</tt> in the copy assignment operator in the synopsis
16766 with <tt>=default</tt>.
16767 </p>
16768
16769 <blockquote><pre>template&lt;class R , class... ArgTypes &gt;
16770   class reference_closure&lt;R (ArgTypes...)&gt; {
16771   public:
16772      ...
16773      reference_closure&amp; operator=(const reference_closure&amp;) = <del>delete</del> <ins>default</ins>;
16774      ...
16775 </pre></blockquote>
16776
16777 <p>
16778 In 20.6.17.1 [func.referenceclosure.cons] Construct, copy, destroy,
16779 add the member function description
16780 </p>
16781
16782 <blockquote>
16783 <pre>reference_closure&amp; operator=(const reference_closure&amp; f)
16784 </pre>
16785 <blockquote>
16786 <p>
16787 <i>Postcondition:</i> <tt>*this</tt> is a copy of <tt>f</tt>.
16788 </p>
16789 <p>
16790 <i>Returns:</i> <tt>*this</tt>.
16791 </p>
16792 </blockquote>
16793 </blockquote>
16794
16795
16796
16797
16798
16799
16800
16801 <hr>
16802 <h3><a name="844"></a>844. <tt>complex pow</tt> return type is ambiguous</h3>
16803 <p><b>Section:</b> 26.3.9 [cmplx.over] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
16804  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-06-03</p>
16805 <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>
16806 <p><b>Discussion:</b></p>
16807 <p>
16808 The current working draft is in an inconsistent state.
16809 </p>
16810
16811 <p>
16812 26.3.8 [complex.transcendentals] says that:
16813 </p>
16814
16815 <blockquote>
16816 <tt>pow(complex&lt;float&gt;(), int())</tt> returns a <tt>complex&lt;float&gt;</tt>.
16817 </blockquote>
16818
16819 <p>
16820 26.3.9 [cmplx.over] says that:
16821 </p>
16822
16823 <blockquote>
16824 <tt>pow(complex&lt;float&gt;(), int())</tt> returns a <tt>complex&lt;double&gt;</tt>.
16825 </blockquote>
16826
16827 <p><i>[
16828 Sophia Antipolis:
16829 ]</i></p>
16830
16831
16832 <blockquote>
16833 <p>
16834 Since <tt>int</tt> promotes to <tt>double</tt>, and C99 doesn't have an <tt>int</tt>-based
16835 overload for <tt>pow</tt>, the C99 result is <tt>complex&lt;double&gt;</tt>, see also C99
16836 7.22, see also library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>.
16837 </p>
16838 <p>
16839 Special note: ask P.J. Plauger.
16840 </p>
16841 <blockquote>
16842 Looks fine.
16843 </blockquote>
16844 </blockquote>
16845
16846
16847 <p><b>Proposed resolution:</b></p>
16848 <p>
16849 Strike this <tt>pow</tt> overload in 26.3.1 [complex.synopsis] and in 26.3.8 [complex.transcendentals]:
16850 </p>
16851
16852 <blockquote><pre><del>template&lt;class T&gt; complex&lt;T&gt; pow(const complex&lt;T&gt;&amp; x, int y);</del>
16853 </pre></blockquote>
16854
16855
16856
16857
16858
16859 <hr>
16860 <h3><a name="845"></a>845. atomics cannot support aggregate initialization</h3>
16861 <p><b>Section:</b> 29.3 [atomics.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
16862  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-06-03</p>
16863 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics.types">active issues</a> in [atomics.types].</p>
16864 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types">issues</a> in [atomics.types].</p>
16865 <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>
16866 <p><b>Discussion:</b></p>
16867 <p>
16868 The atomic classes (and class templates) are required to support aggregate
16869 initialization (29.3.1 [atomics.types.integral]p2 / 29.3.2 [atomics.types.address]p1)
16870 yet also have user declared constructors, so cannot be aggregates.
16871 </p>
16872 <p>
16873 This problem might be solved with the introduction of the proposed
16874 initialization syntax at Antipolis, but the wording above should be altered.
16875 Either strike the sentence as redundant with new syntax, or refer to 'brace
16876 initialization'.
16877 </p>
16878
16879 <p><i>[
16880 Jens adds:
16881 ]</i></p>
16882
16883
16884 <blockquote>
16885 <p>
16886 Note that
16887 </p>
16888 <blockquote><pre>atomic_itype a1 = { 5 };
16889 </pre></blockquote>
16890 <p>
16891 would be aggregate-initialization syntax (now coming under the disguise
16892 of brace initialization), but would be ill-formed, because the corresponding
16893 constructor for atomic_itype is explicit.  This works, though:
16894 </p>
16895 <blockquote><pre>atomic_itype a2 { 6 };
16896 </pre></blockquote>
16897
16898 </blockquote>
16899
16900
16901 <p><b>Proposed resolution:</b></p>
16902 <p>
16903 In 29.3.1 [atomics.types.integral], strike the following sentence from paragraph 2:
16904 </p>
16905
16906 <blockquote>
16907 The atomic integral types shall have standard layout. They shall each have a trivial default constructor, a constexpr
16908 explicit value constructor, a deleted copy constructor, a deleted copy assignment operator, and a trivial destructor.
16909 <del>They shall each support aggregate initialization syntax.</del>
16910 </blockquote>
16911
16912 <p><i>[
16913 2008-08-18, Lawrence adds:
16914 ]</i></p>
16915
16916 <blockquote>
16917 The syntactic compatibility of initialization with C is important.
16918 I suggest a different resolution; remove the explicit from the
16919 constructor.  For the same reasons we can have implicit conversions,
16920 we can also have implicit constructors.
16921 </blockquote>
16922
16923
16924
16925
16926
16927 <hr>
16928 <h3><a name="846"></a>846. No definition for constructor</h3>
16929 <p><b>Section:</b> 29.3 [atomics.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
16930  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-06-03</p>
16931 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics.types">active issues</a> in [atomics.types].</p>
16932 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types">issues</a> in [atomics.types].</p>
16933 <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>
16934 <p><b>Discussion:</b></p>
16935 <p>
16936 The atomic classes and class templates (29.3.1 [atomics.types.integral] /
16937 29.3.2 [atomics.types.address]) have a constexpr
16938 constructor taking a value of the appropriate type for that atomic.
16939 However, neither clause provides semantics or a definition for this
16940 constructor.  I'm not sure if the initialization is implied by use of
16941 constexpr keyword (which restricts the form of a constructor) but even if
16942 that is the case, I think it is worth spelling out explicitly as the
16943 inference would be far too subtle in that case.
16944 </p>
16945
16946
16947 <p><b>Proposed resolution:</b></p>
16948 <p>
16949 </p>
16950
16951
16952
16953
16954
16955 <hr>
16956 <h3><a name="847"></a>847. string exception safety guarantees</h3>
16957 <p><b>Section:</b> 21.3.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
16958  <b>Submitter:</b> Hervé Brönnimann <b>Date:</b> 2008-06-05</p>
16959 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.require">issues</a> in [string.require].</p>
16960 <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>
16961 <p><b>Discussion:</b></p>
16962 <p>
16963 In March, on comp.lang.c++.moderated, I asked what were the
16964 string exception safety guarantees are, because I cannot see
16965 *any* in the working paper, and any implementation I know offers
16966 the strong exception safety guarantee (string unchanged if a
16967 member throws exception). The closest the current draft comes to
16968 offering any guarantees is 21.3 [basic.string], para 3:
16969 </p>
16970
16971 <blockquote>
16972 The class template <tt>basic_string</tt> conforms to the requirements
16973 for a Sequence Container (23.1.1), for a Reversible Container (23.1),
16974 and for an Allocator-aware container (91). The iterators supported by
16975 <tt>basic_string</tt> are random access iterators (24.1.5).
16976 </blockquote>
16977
16978 <p>
16979 However, the chapter 23 only says, on the topic of exceptions:  23.1 [container.requirements],
16980 para 10:
16981 </p>
16982
16983 <blockquote>
16984 <p>
16985 Unless otherwise specified (see 23.2.2.3 and 23.2.6.4) all container types defined in this clause meet the following
16986 additional requirements:
16987 </p>
16988
16989 <ul>
16990 <li>if an exception is thrown by...</li>
16991 </ul>
16992 </blockquote>
16993
16994 <p>
16995 I take it  as saying that this paragraph has *no* implication on
16996 <tt>std::basic_string</tt>, as <tt>basic_string</tt> isn't defined in Clause 23 and
16997 this paragraph does not define a *requirement* of Sequence
16998 nor Reversible Container, just of the models defined in Clause 23.
16999 In addition, LWG Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a> proposes to remove 23.1 [container.requirements], para 3.
17000 </p>
17001
17002 <p>
17003 Finally, the fact that no operation on Traits should throw
17004 exceptions has no bearing, except to suggest (since the only
17005 other throws should be allocation, <tt>out_of_range</tt>, or <tt>length_error</tt>)
17006 that the strong exception guarantee can be achieved.
17007 </p>
17008
17009 <p>
17010 The reaction in that group by Niels Dekker, Martin Sebor, and
17011 Bo Persson, was all that this would be worth an LWG issue.
17012 </p>
17013
17014 <p>
17015 A related issue is that <tt>erase()</tt> does not throw.  This should be
17016 stated somewhere (and again, I don't think that the 23.1 [container.requirements], para 1
17017 applies here).
17018 </p>
17019
17020
17021
17022 <p><b>Proposed resolution:</b></p>
17023 <p>
17024 Add a blanket statement in 21.3.1 [string.require]:
17025 </p>
17026
17027 <blockquote>
17028 <p>
17029 - if any member function or operator of <tt>basic_string&lt;charT, traits, Allocator&gt;</tt>
17030 throws, that function or operator has no effect.
17031 </p>
17032 <p>
17033 - no <tt>erase()</tt> or <tt>pop_back()</tt> function throws.
17034 </p>
17035 </blockquote>
17036
17037 <p>
17038 As far as I can tell, this is achieved by any implementation.  If I made a
17039 mistake and it is not possible to offer this guarantee, then
17040 either state all the functions for which this is possible
17041 (certainly at least <tt>operator+=</tt>, <tt>append</tt>, <tt>assign</tt>, and <tt>insert</tt>),
17042 or add paragraphs to Effects clauses wherever appropriate.
17043 </p>
17044
17045
17046
17047
17048
17049 <hr>
17050 <h3><a name="848"></a>848. missing <tt>std::hash</tt> specializations for <tt>std::bitset/std::vector&lt;bool&gt;</tt></h3>
17051 <p><b>Section:</b> 20.6.16 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
17052  <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2008-06-05</p>
17053 <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>
17054 <p><b>Discussion:</b></p>
17055 <p>
17056 In the current working draft, <tt>std::hash&lt;T&gt;</tt> is specialized for builtin
17057 types and a few other types. Bitsets seems like one that is missing from
17058 the list, not because it cannot not be done by the user, but because it
17059 is hard or impossible to write an efficient implementation that works on
17060 32bit/64bit chunks at a time. For example, <tt>std::bitset</tt> is too much
17061 encapsulated in this respect.
17062 </p>
17063
17064
17065 <p><b>Proposed resolution:</b></p>
17066 <p>
17067 Add the following to the synopsis in 20.6 [function.objects]/2:
17068 </p>
17069
17070 <blockquote><pre>template&lt;class Allocator&gt; struct hash&lt;std::vector&lt;bool,Allocator&gt;&gt;;
17071 template&lt;size_t N&gt; struct hash&lt;std::bitset&lt;N&gt;&gt;;
17072 </pre></blockquote>
17073
17074 <p>
17075 Modify the last sentence of 20.6.16 [unord.hash]/1 to end with:
17076 </p>
17077
17078 <blockquote>
17079 ... and <tt>std::string</tt>, <tt>std::u16string</tt>, <tt>std::u32string</tt>, <tt>std::wstring</tt>,
17080 <tt>std::error_code</tt>, <tt>std::thread::id</tt>, <tt>std::bitset</tt>, <tt>and std::vector&lt;bool&gt;</tt>.
17081 </blockquote>
17082
17083
17084
17085
17086
17087
17088 <hr>
17089 <h3><a name="849"></a>849. missing type traits to compute root class and derived class of types in a class hierachy</h3>
17090 <p><b>Section:</b> 20.5.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17091  <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2008-06-05</p>
17092 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.trans.other">active issues</a> in [meta.trans.other].</p>
17093 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
17094 <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>
17095 <p><b>Discussion:</b></p>
17096 <p>
17097 The type traits library contains various traits to dealt with
17098 polymorphic types, e.g. <tt>std::has_virtual_destructor</tt>, <tt>std::is_polymorphic</tt>
17099 and <tt>std::is_base_of</tt>. However, there is no way to compute the unique
17100 public base class of a type  if such  one exists.  Such a trait could be
17101 very useful if one needs to instantiate a specialization made for the
17102 root class whenever a derived class is passed as parameter. For example,
17103 imagine that you wanted to specialize <tt>std::hash</tt> for a class
17104 hierarchy---instead of specializing each class, you could specialize the
17105 <tt>std::hash&lt;root_class&gt;</tt> and provide a partial specialization that worked
17106 for all derived classes.
17107 </p>
17108
17109 <p>
17110 This ability---to specify operations in terms of their equivalent in the
17111 root class---can be done with e.g. normal functions, but there is,
17112 AFAIK, no way to do it for class templates. Being able to access
17113 compile-time information about the type-hierachy can be very powerful,
17114 and I therefore also suggest traits that computes the directly derived
17115 class whenever that is possible.
17116 </p>
17117
17118 <p>
17119 If the computation can not be done, the traits should fall back on an
17120 identity transformation. I expect this gives the best overall usability.
17121 </p>
17122
17123
17124 <p><b>Proposed resolution:</b></p>
17125 <p>
17126 Add the following to the synopsis in 20.5.2 [meta.type.synop] under "other transformations":
17127 </p>
17128
17129 <blockquote><pre>template&lt; class T &gt; struct direct_base_class;
17130 template&lt; class T &gt; struct direct_derived_class;
17131 template&lt; class T &gt; struct root_base_class;
17132 </pre></blockquote>
17133
17134 <p>
17135 Add three new entries to table 51 (20.5.7 [meta.trans.other]) with the following content
17136 </p>
17137
17138 <blockquote>
17139 <table border="1">
17140 <tbody><tr>
17141 <th>Template</th><th>Condition</th><th>Comments</th>
17142 </tr>
17143 <tr>
17144 <td><tt>template&lt; class T &gt; struct direct_base_class;</tt></td>
17145 <td><tt>T</tt> shall be a complete type.</td>
17146 <td>The member typedef <tt>type</tt> shall equal the accessible unambiguous direct base class of <tt>T</tt>.
17147 If no such type exists, the member typedef <tt>type</tt> shall equal <tt>T</tt>.</td>
17148 </tr>
17149 <tr>
17150 <td><tt>template&lt; class T &gt; struct direct_derived_class;</tt></td>
17151 <td><tt>T</tt> shall be a complete type.</td>
17152 <td>The member typedef <tt>type</tt> shall equal the unambiguous type which has <tt>T</tt>
17153 as an accessible unambiguous direct base class. If no such type exists, the member typedef
17154 <tt>type</tt> shall equal <tt>T</tt>.</td>
17155 </tr>
17156 <tr>
17157 <td><tt>template&lt; class T &gt; struct root_base_class;</tt></td>
17158 <td><tt>T</tt> shall be a complete type.</td>
17159 <td>The member typedef <tt>type</tt> shall equal the accessible unambiguous most indirect base class of
17160 <tt>T</tt>. If no such type exists, the member typedef type shall equal <tt>T</tt>.</td>
17161 </tr>
17162 </tbody></table>
17163 </blockquote>
17164
17165
17166
17167
17168
17169
17170 <hr>
17171 <h3><a name="850"></a>850. Should <tt>shrink_to_fit</tt> apply to <tt>std::deque</tt>?</h3>
17172 <p><b>Section:</b> 23.2.2.2 [deque.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
17173  <b>Submitter:</b> Niels Dekker <b>Date:</b> 2008-06-05</p>
17174 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#deque.capacity">active issues</a> in [deque.capacity].</p>
17175 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#deque.capacity">issues</a> in [deque.capacity].</p>
17176 <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>
17177 <p><b>Discussion:</b></p>
17178 <p>
17179 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a> added a <tt>shrink_to_fit</tt> function to <tt>std::vector</tt> and <tt>std::string</tt>.
17180 It did not yet deal with <tt>std::deque</tt>, because of the fundamental
17181 difference between <tt>std::deque</tt> and the other two container types. The
17182 need for <tt>std::deque</tt> may seem less evident, because one might think that
17183 for this container, the overhead is a small map, and some number of
17184 blocks that's bounded by a small constant.
17185 </p>
17186 <p>
17187 The container overhead can in fact be arbitrarily large (i.e. is not
17188 necessarily O(N) where N is the number of elements currently held by the
17189 <tt>deque</tt>).  As Bill Plauger noted in a reflector message, unless the map of
17190 block pointers is shrunk, it must hold at least maxN/B pointers where
17191 maxN is the maximum of N over the lifetime of the <tt>deque</tt> since its
17192 creation.  This is independent of how the map is implemented
17193 (<tt>vector</tt>-like circular buffer and all), and maxN bears no relation to N,
17194 the number of elements it currently holds.
17195 </p>
17196 <p>
17197 Hervé Brönnimann reports a situation where a <tt>deque</tt> of requests grew very
17198 large due to some temporary backup (the front request hanging), and the
17199 map of the <tt>deque</tt> grew quite large before getting back to normal.  Just
17200 to put some color on it, assuming a <tt>deque</tt> with 1K pointer elements in
17201 steady regime, that held, at some point in its lifetime, maxN=10M
17202 pointers, with one block holding 128 elements, the spine must be at
17203 least (maxN / 128), in that case 100K.   In that case, shrink-to-fit
17204 would allow to reuse about 100K which would otherwise never be reclaimed
17205 in the lifetime of the <tt>deque</tt>.
17206 </p>
17207 <p>
17208 An added bonus would be that it *allows* implementations to hang on to
17209 empty blocks at the end (but does not care if they do or not).  A
17210 <tt>shrink_to_fit</tt> would take care of both shrinks, and guarantee that at
17211 most O(B) space is used in addition to the storage to hold the N
17212 elements and the N/B block pointers.
17213 </p>
17214
17215
17216 <p><b>Proposed resolution:</b></p>
17217 <p>
17218 To Class template deque 23.2.2 [deque] synopsis, add:
17219 </p>
17220 <blockquote><pre>void shrink_to_fit();
17221 </pre></blockquote>
17222
17223 <p>
17224 To deque capacity 23.2.2.2 [deque.capacity], add:
17225 </p>
17226 <blockquote><pre>void shrink_to_fit();
17227 </pre>
17228
17229 <blockquote>
17230 <i>Remarks:</i> <tt>shrink_to_fit</tt> is a non-binding request to reduce memory
17231 use. [<i>Note:</i> The request is non-binding to allow latitude for
17232 implementation-specific optimizations. -- <i>end note</i>]
17233 </blockquote>
17234 </blockquote>
17235
17236
17237
17238
17239
17240 <hr>
17241 <h3><a name="851"></a>851. simplified array construction</h3>
17242 <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>
17243  <b>Submitter:</b> Benjamin Kosnik <b>Date:</b> 2008-06-05</p>
17244 <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>
17245 <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>
17246 <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>
17247 <p><b>Discussion:</b></p>
17248 <p>
17249 This is an issue that came up on the libstdc++ list, where a
17250 discrepency between "C" arrays and C++0x's <tt>std::array</tt> was pointed
17251 out.
17252 </p>
17253
17254 <p>
17255 In "C," this array usage is possible:
17256 </p>
17257
17258 <blockquote><pre>int ar[] = {1, 4, 6};
17259 </pre></blockquote>
17260
17261 <p>
17262 But for C++,
17263 </p>
17264
17265 <blockquote><pre>std::array&lt;int&gt; a = { 1, 4, 6 }; // error
17266 </pre></blockquote>
17267
17268 <p>
17269 Instead, the second parameter of the <tt>array</tt> template must be
17270 explicit, like so:
17271 </p>
17272
17273 <blockquote><pre>std::array&lt;int, 3&gt; a = { 1, 4, 6 };
17274 </pre></blockquote>
17275
17276 <p>
17277 Doug Gregor proposes the following solution, that assumes
17278 generalized initializer lists.
17279 </p>
17280
17281 <blockquote><pre>template&lt;typename T, typename... Args&gt;
17282 inline array&lt;T, sizeof...(Args)&gt;
17283 make_array(Args&amp;&amp;... args)
17284 { return { std::forward&lt;Args&gt;(args)... };  }
17285 </pre></blockquote>
17286
17287 <p>
17288 Then, the way to build an <tt>array</tt> from a list of unknown size is:
17289 </p>
17290
17291 <blockquote><pre>auto a = make_array&lt;T&gt;(1, 4, 6);
17292 </pre></blockquote>
17293
17294
17295
17296 <p><b>Proposed resolution:</b></p>
17297 <p>
17298 Add to the <tt>array</tt> synopis in 23.2 [sequences]:
17299 </p>
17300
17301 <blockquote><pre>template&lt;typename T, typename... Args&gt;
17302   requires Convertible&lt;Args, T&gt;...
17303   array&lt;T, sizeof...(Args)&gt;
17304   make_array(Args&amp;&amp;... args);
17305 </pre></blockquote>
17306
17307 <p>
17308 Append after 23.2.1.6 [array.tuple] Tuple interface to class template <tt>array</tt> the
17309 following new section.
17310 </p>
17311
17312 <blockquote>
17313 <p>
17314 23.2.1.7 Convenience interface to class template <tt>array</tt> [array.tuple]
17315 </p>
17316
17317 <pre>template&lt;typename T, typename... Args&gt;
17318   requires Convertible&lt;Args, T&gt;...
17319   array&lt;T, sizeof...(Args)&gt;
17320   make_array(Args&amp;&amp;... args);
17321 </pre>
17322
17323 <blockquote>
17324 <p>
17325 <i>Returns:</i> <tt>{std::forward&lt;Args&gt;(args)...}</tt>
17326 </p>
17327 </blockquote>
17328 </blockquote>
17329
17330
17331
17332
17333
17334 <hr>
17335 <h3><a name="852"></a>852. unordered containers <tt>begin(n)</tt> mistakenly <tt>const</tt></h3>
17336 <p><b>Section:</b> 23.4 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
17337  <b>Submitter:</b> Robert Klarer <b>Date:</b> 2008-06-12</p>
17338 <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>
17339 <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>
17340 <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>
17341 <p><b>Discussion:</b></p>
17342 <p>
17343 In 3 of the four unordered containers the local <tt>begin</tt> member is mistakenly declared <tt>const</tt>:
17344 </p>
17345
17346 <blockquote><pre>local_iterator begin(size_type n) const;
17347 </pre></blockquote>
17348
17349
17350 <p><b>Proposed resolution:</b></p>
17351 <p>
17352 Change the synopsis in 23.4.1 [unord.map], 23.4.2 [unord.multimap], and 23.4.4 [unord.multiset]:
17353 </p>
17354
17355 <blockquote><pre>local_iterator begin(size_type n)<del> const</del>;
17356 </pre></blockquote>
17357
17358
17359
17360
17361
17362 <hr>
17363 <h3><a name="853"></a>853. <tt>to_string</tt> needs updating with <tt>zero</tt> and <tt>one</tt></h3>
17364 <p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17365  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-06-18</p>
17366 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
17367 <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>
17368 <p><b>Discussion:</b></p>
17369 <p>
17370 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#396">396</a> adds defaulted arguments to the <tt>to_string</tt> member, but neglects to update
17371 the three newer <tt>to_string</tt> overloads.
17372 </p>
17373
17374
17375 <p><b>Proposed resolution:</b></p>
17376 <p>
17377 Change the synopsis in 23.3.5 [template.bitset], and the signatures in 23.3.5.2 [bitset.members] to:
17378 </p>
17379
17380 <blockquote><pre>template &lt;class charT, class traits&gt;
17381   basic_string&lt;charT, traits, allocator&lt;charT&gt; &gt; to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const;
17382 template &lt;class charT&gt;
17383   basic_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt; to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const;
17384 basic_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt; to_string(<ins>char zero = '0', char one = '1'</ins>) const;
17385 </pre></blockquote>
17386
17387
17388
17389
17390
17391 <hr>
17392 <h3><a name="854"></a>854. <tt>default_delete</tt> converting constructor underspecified</h3>
17393 <p><b>Section:</b> 20.7.11.1.1 [unique.ptr.dltr.dflt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17394  <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-06-18</p>
17395 <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>
17396 <p><b>Discussion:</b></p>
17397 <p>
17398 No relationship between <tt>U</tt> and <tt>T</tt> in the converting constructor for <tt>default_delete</tt> template.
17399 </p>
17400 <p>
17401 Requirements: <tt>U*</tt> is convertible to <tt>T*</tt> and <tt>has_virtual_destructor&lt;T&gt;</tt>;
17402 the latter should also become a concept.
17403 </p>
17404 <p>
17405 Rules out cross-casting.
17406 </p>
17407 <p>
17408 The requirements for <tt>unique_ptr</tt> conversions should be the same as those on the deleter.
17409 </p>
17410
17411
17412 <p><b>Proposed resolution:</b></p>
17413 <p>
17414 Change 20.7.11.1.1 [unique.ptr.dltr.dflt]:
17415 </p>
17416
17417 <blockquote><pre>namespace std {
17418   template &lt;class T&gt; struct default_delete {
17419     default_delete();
17420     template &lt;class U&gt;
17421       <ins>requires Convertible&lt;U*, T*&gt; &amp;&amp; HasVirtualDestructor&lt;T&gt;</ins>
17422       default_delete(const default_delete&lt;U&gt;&amp;);
17423     void operator()(T*) const;
17424   };
17425 }
17426 </pre></blockquote>
17427
17428 <p>
17429 ...
17430 </p>
17431
17432 <blockquote><pre>template &lt;class U&gt;
17433   <ins>requires Convertible&lt;U*, T*&gt; &amp;&amp; HasVirtualDestructor&lt;T&gt;</ins>
17434   default_delete(const default_delete&lt;U&gt;&amp; other);
17435 </pre></blockquote>
17436
17437
17438
17439
17440
17441
17442 <hr>
17443 <h3><a name="855"></a>855. capacity() and reserve() for deque?</h3>
17444 <p><b>Section:</b> 23.2.2.2 [deque.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17445  <b>Submitter:</b> Hervé Brönnimann <b>Date:</b> 2008-06-11</p>
17446 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#deque.capacity">active issues</a> in [deque.capacity].</p>
17447 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#deque.capacity">issues</a> in [deque.capacity].</p>
17448 <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>
17449 <p><b>Discussion:</b></p>
17450 <p>
17451 The main point is that <tt>capacity</tt> can be viewed as a mechanism to
17452 guarantee the validity of <tt>iterators</tt> when only <tt>push_back/pop_back</tt>
17453 operations are used.  For <tt>vector</tt>, this goes with reallocation.  For
17454 <tt>deque</tt>, this is a bit more subtle:  <tt>capacity()</tt> of a <tt>deque</tt> may shrink,
17455 whereas that of <tt>vector</tt> doesn't.   In a circular buffer impl. of the
17456 map, as Howard did, there is very similar notion of capacity: as long
17457 as <tt>size()</tt> is less than <tt>B * (</tt>total size of the map <tt>- 2)</tt>, it is
17458 guaranteed that no <tt>iterator</tt> is invalidated after any number of
17459 <tt>push_front/back</tt> and <tt>pop_front/back</tt> operations.  But this does not
17460 hold for other implementations.
17461 </p>
17462 <p>
17463 Still, I believe, <tt>capacity()</tt> can be defined by <tt>size() +</tt>  how many
17464 <tt>push_front/back</tt> minus <tt>pop_front/back</tt> that can be performed before
17465 terators are invalidated.  In a classical impl., <tt>capacity() = size()
17466 + </tt> the min distance to either "physical" end of the deque (i.e.,
17467 counting the empty space in the last block plus all the blocks until
17468 the end of the map of block pointers).  In Howard's circular buffer
17469 impl., <tt>capacity() = B * (</tt>total size of the map <tt>- 2)</tt> still works with
17470 this definition, even though the guarantee could be made stronger.
17471 </p>
17472 <p>
17473 A simple picture of a deque:
17474 </p>
17475 <blockquote><pre>A-----|----|-----|---F+|++++|++B--|-----|-----Z
17476 </pre></blockquote>
17477 <p>
17478 (A,Z mark the beginning/end, | the block boundaries, F=front, B=back,
17479 and - are uninitialized, + are initialized)
17480 In that picture:  <tt>capacity = size() + min(dist(A,F),dist(B,Z)) = min
17481 (dist(A,B),dist(F,Z))</tt>.
17482 </p>
17483 <p>
17484 <tt>Reserve(n)</tt> can grow the map of pointers and add possibly a number of
17485 empty blocks to it, in order to guarantee that the next <tt>n-size()
17486 push_back/push_front</tt> operations will not invalidate iterators, and
17487 also will not allocate (i.e. cannot throw).  The second guarantee is
17488 not essential and can be left as a QoI.  I know well enough existing
17489 implementations of <tt>deque</tt> (sgi/stl, roguewave, stlport, and
17490 dinkumware) to know that either can be implemented with no change to
17491 the existing class layout and code, and only a few modifications if
17492 blocks are pre-allocated (instead of always allocating a new block,
17493 check if the next entry in the map of block pointers is not zero).
17494 </p>
17495 <p>
17496 Due to the difference with <tt>vector</tt>, wording is crucial.  Here's a
17497 proposed wording to make things concrete;  I tried to be reasonably
17498 careful but please double-check me:
17499 </p>
17500
17501
17502
17503 <p><b>Proposed resolution:</b></p>
17504
17505 <p>
17506 Add new signatures to synopsis in 23.2.2 [deque]:
17507 </p>
17508
17509 <blockquote><pre>size_type capacity() const;
17510 bool reserve(size_type n);
17511 </pre></blockquote>
17512
17513 <p>
17514 Add new signatures to 23.2.2.2 [deque.capacity]:
17515 </p>
17516
17517 <blockquote>
17518 <pre>size_type capacity() const;
17519 </pre>
17520 <blockquote>
17521 <p>
17522 1 <i>Returns:</i> An upper bound on <tt>n + max(n_f - m_f, n_b - m_b)</tt>  such
17523 that, for any sequence of <tt>n_f push_front</tt>, <tt>m_f pop_front</tt>, <tt>n_b
17524 push_back</tt>, and <tt>m_b pop_back</tt> operations, interleaved in any order,
17525 starting with the current <tt>deque</tt> of size <tt>n</tt>, the <tt>deque</tt> does not
17526 invalidate any of its iterators except to the erased elements.
17527 </p>
17528 <p>
17529 2 <i>Remarks:</i>  Unlike a <tt>vector</tt>'s capacity, the capacity of a <tt>deque</tt> can
17530 decrease after a sequence of insertions at both ends, even if none of
17531 the operations caused the <tt>deque</tt> to invalidate any of its iterators
17532 except to the erased elements.
17533 </p>
17534 </blockquote>
17535 </blockquote>
17536
17537 <blockquote>
17538 <pre>bool reserve(size_type n);
17539 </pre>
17540 <blockquote>
17541 <p>
17542 2 <i>Effects:</i> A directive that informs a <tt>deque</tt> of a planned sequence of
17543 <tt>push_front</tt>, <tt>pop_front</tt>, <tt>push_back</tt>, and <tt>pop_back</tt> operations, so that it
17544 can manage iterator invalidation accordingly. After <tt>reserve()</tt>,
17545 <tt>capacity()</tt> is greater or equal to the argument of <tt>reserve</tt> if this
17546 operation returns <tt>true</tt>; and equal to the previous value of <tt>capacity()</tt>
17547 otherwise.  If an exception is thrown, there are no effects.
17548 </p>
17549 <p>
17550 3 <i>Returns:</i> <tt>true</tt> if iterators are invalidated as a result of this
17551 operation, and false otherwise.
17552 </p>
17553 <p>
17554 4 <i>Complexity:</i> It does not change the size of the sequence and takes
17555 at most linear time in <tt>n</tt>.
17556 </p>
17557 <p>
17558 5 <i>Throws:</i> <tt>length_error</tt> if <tt>n &gt; max_size()</tt>.
17559 </p>
17560 <p>
17561 6 <i>Remarks:</i> It is guaranteed that no invalidation takes place during a
17562 sequence of <tt>insert</tt> or <tt>erase</tt> operations at either end that happens
17563 after a call to <tt>reserve()</tt> except to the erased elements, until the
17564 time when an insertion would make <tt>max(n_f-m_f, n_b-m_b)</tt> larger than
17565 <tt>capacity()</tt>, where <tt>n_f</tt> is the number of <tt>push_front</tt>, <tt>m_f</tt> of <tt>pop_front</tt>,
17566 <tt>n_b</tt> of <tt>push_back</tt>, and <tt>m_b</tt> of <tt>pop_back</tt> operations since the call to
17567 <tt>reserve()</tt>.
17568 </p>
17569 <p>
17570 7        An implementation is free to pre-allocate buffers so as to
17571 offer the additional guarantee that no exception will be thrown
17572 during such a sequence other than by the element constructors.
17573 </p>
17574 </blockquote>
17575 </blockquote>
17576
17577 <p>
17578 And 23.2.2.3 [deque.modifiers] para 1, can be enhanced:
17579 </p>
17580
17581 <blockquote>
17582 1 <i>Effects:</i> An insertion in the middle of the deque invalidates all the iterators and references to elements of the
17583 deque. An insertion at either end of the deque invalidates all the iterators to the deque,
17584 <ins>unless provisions have been made with reserve,</ins>
17585 but has no effect on the validity of references to elements of the deque.
17586 </blockquote>
17587
17588
17589
17590
17591
17592 <hr>
17593 <h3><a name="856"></a>856. Removal of <tt>aligned_union</tt></h3>
17594 <p><b>Section:</b> 20.5.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17595  <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-06-12</p>
17596 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.trans.other">active issues</a> in [meta.trans.other].</p>
17597 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
17598 <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>
17599 <p><b>Discussion:</b></p>
17600 <p>
17601 With the arrival of extended unions
17602 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2544.pdf">N2544</a>),
17603 there is no
17604 known use of <tt>aligned_union</tt> that couldn't be handled by
17605 the "extended unions" core-language facility.
17606 </p>
17607
17608
17609 <p><b>Proposed resolution:</b></p>
17610 <p>
17611 Remove the following signature from 20.5.2 [meta.type.synop]:
17612 </p>
17613 <blockquote><pre>template &lt;std::size_t Len, class... Types&gt; struct aligned_union;
17614 </pre></blockquote>
17615
17616 <p>
17617 Remove the second row from table 51 in 20.5.7 [meta.trans.other],
17618 starting with:
17619 </p>
17620
17621 <blockquote><pre>template &lt;std::size_t Len,
17622 class... Types&gt;
17623 struct aligned_union;
17624 </pre></blockquote>
17625
17626
17627
17628
17629
17630 <hr>
17631 <h3><a name="857"></a>857. <tt>condition_variable::time_wait</tt> return <tt>bool</tt> error prone</h3>
17632 <p><b>Section:</b> 30.4.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17633  <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-06-13</p>
17634 <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>
17635 <p><b>Discussion:</b></p>
17636 <p>
17637 The meaning of the <tt>bool</tt> returned by <tt>condition_variable::timed_wait</tt> is so
17638 obscure that even the class' designer can't deduce it correctly. Several
17639 people have independently stumbled on this issue.
17640 </p>
17641 <p>
17642 It might be simpler to change the return type to a scoped enum:
17643 </p>
17644 <blockquote><pre>enum class timeout { not_reached, reached };
17645 </pre></blockquote>
17646
17647 <p>
17648 That's the same cost as returning a <tt>bool</tt>, but not subject to mistakes. Your example below would be:
17649 </p>
17650
17651 <blockquote><pre>if (cv.wait_until(lk, time_limit) == timeout::reached )
17652   throw time_out();
17653 </pre></blockquote>
17654
17655 <p><i>[
17656 Beman to supply exact wording.
17657 ]</i></p>
17658
17659
17660
17661 <p><b>Proposed resolution:</b></p>
17662
17663
17664
17665
17666
17667 <hr>
17668 <h3><a name="858"></a>858. Wording for Minimal Support for Garbage Collection</h3>
17669 <p><b>Section:</b> X [garbage.collection] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17670  <b>Submitter:</b> Pete Becker  <b>Date:</b> 2008-06-21</p>
17671 <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>
17672 <p><b>Discussion:</b></p>
17673 <p>
17674 The first sentence of the Effects clause for <tt>undeclare_reachable</tt> seems
17675 to be missing some words. I can't parse
17676 </p>
17677 <blockquote>
17678 ... for all non-null <tt>p</tt> referencing the argument is no longer declared reachable...
17679 </blockquote>
17680 <p>
17681 I take it the intent is that <tt>undeclare_reachable</tt> should be called only
17682 when there has been a corresponding call to <tt>declare_reachable</tt>. In
17683 particular, although the wording seems to allow it, I assume that code
17684 shouldn't call <tt>declare_reachable</tt> once then call <tt>undeclare_reachable</tt>
17685 twice.
17686 </p>
17687 <p>
17688 I don't know what "shall be live" in the Requires clause means.
17689 </p>
17690 <p>
17691 In the final Note for <tt>undeclare_reachable</tt>, what does "cannot be
17692 deallocated" mean? Is this different from "will not be able to collect"?
17693 </p>
17694
17695 <p>
17696 For the wording on nesting of <tt>declare_reachable</tt> and
17697 <tt>undeclare_reachable</tt>, the words for locking and unlocking recursive
17698 mutexes probably are a good model.
17699 </p>
17700
17701
17702 <p><b>Proposed resolution:</b></p>
17703 <p>
17704 </p>
17705
17706
17707
17708
17709
17710 <hr>
17711 <h3><a name="859"></a>859. Monotonic Clock is Conditionally Supported?</h3>
17712 <p><b>Section:</b> X [datetime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17713  <b>Submitter:</b> Pete Becker <b>Date:</b> 2008-06-23</p>
17714 <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>
17715 <p><b>Discussion:</b></p>
17716 <p>
17717 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.html">N2661</a>
17718 says that there is a class named <tt>monotonic_clock</tt>. It also says that this
17719 name may be a synonym for <tt>system_clock</tt>, and that it's conditionally
17720 supported. So the actual requirement is that it can be monotonic or not,
17721 and you can tell by looking at <tt>is_monotonic</tt>, or it might not exist at
17722 all (since it's conditionally supported). Okay, maybe too much
17723 flexibility, but so be it.
17724 </p>
17725 <p>
17726 A problem comes up in the threading specification, where several
17727 variants of <tt>wait_for</tt> explicitly use <tt>monotonic_clock::now()</tt>. What is the
17728 meaning of an effects clause that says
17729 </p>
17730
17731 <blockquote><pre>wait_until(lock, chrono::monotonic_clock::now() + rel_time)
17732 </pre></blockquote>
17733
17734 <p>
17735 when <tt>monotonic_clock</tt> is not required to exist?
17736 </p>
17737
17738
17739 <p><b>Proposed resolution:</b></p>
17740 <p>
17741 </p>
17742
17743
17744
17745
17746
17747 <hr>
17748 <h3><a name="860"></a>860. Floating-Point State</h3>
17749 <p><b>Section:</b> 26 [numerics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17750  <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-06-23</p>
17751 <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>
17752 <p><b>Discussion:</b></p>
17753 <p>
17754 There are a number of functions that affect the floating point state.
17755 These function need to be thread-safe, but I'm unsure of the right
17756 approach in the standard, as we inherit them from C.
17757 </p>
17758
17759
17760 <p><b>Proposed resolution:</b></p>
17761 <p>
17762 </p>
17763
17764
17765
17766
17767
17768 <hr>
17769 <h3><a name="861"></a>861. Incomplete specification of EqualityComparable for std::forward_list</h3>
17770 <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#New">New</a>
17771  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-06-24</p>
17772 <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>
17773 <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>
17774 <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>
17775 <p><b>Discussion:</b></p>
17776 <p>
17777 Table 89, Container requirements, defines <tt>operator==</tt> in terms of the container
17778 member function <tt>size()</tt> and the algorithm <tt>std::equal</tt>:
17779 </p>
17780
17781 <blockquote>
17782 <tt>==</tt> is an equivalence relation. <tt>a.size() == b.size() &amp;&amp;
17783 equal(a.begin(), a.end(), b.begin()</tt>
17784 </blockquote>
17785
17786 <p>
17787 The new container <tt>forward_list</tt> does not provide a <tt>size</tt> member function
17788 by design but does provide <tt>operator==</tt> and <tt>operator!=</tt> without specifying it's semantic.
17789 </p>
17790 <p>
17791 Other parts of the (sequence) container requirements do also depend on
17792 <tt>size()</tt>, e.g. <tt>empty()</tt>
17793 or <tt>clear()</tt>, but this issue explicitly attempts to solve the missing
17794 <tt>EqualityComparable</tt> specification,
17795 because of the special design choices of <tt>forward_list</tt>.
17796 </p>
17797 <p>
17798 I propose to apply one of the following resolutions, which are described as:
17799 </p>
17800
17801 <ol type="A">
17802 <li>
17803 Provide a definition, which is optimal for this special container without
17804 previous size test. This choice prevents two <tt>O(N)</tt> calls of <tt>std::distance()</tt>
17805 with the corresponding container ranges and instead uses a special
17806 <tt>equals</tt> implementation which takes two container ranges instead of 1 1/2.
17807 </li>
17808 <li>
17809 The simple fix where the usual test is adapted such that <tt>size()</tt> is replaced
17810 by <tt>distance</tt> with corresponding performance disadvantages.
17811 </li>
17812 </ol>
17813 <p>
17814 Both proposal choices are discussed, the preferred choice of the author is
17815 to apply (A).
17816 </p>
17817
17818
17819 <p><b>Proposed resolution:</b></p>
17820 <p>
17821 Common part:
17822 </p>
17823 <ul>
17824 <li>
17825 <p>
17826 Just betwen 23.2.3.5 [forwardlist.ops] and 23.2.3.6 [forwardlist.spec]
17827 add a new
17828 section "forwardlist comparison operators" [forwardlist.compare] (and
17829 also add the
17830 new section number to 23.2.3 [forwardlist]/2 in front of "Comparison operators"):
17831 </p>
17832 <blockquote>
17833 forwardlist comparison operators [forwardlist.compare]
17834 </blockquote>
17835 </li>
17836 </ul>
17837
17838 <p>
17839 Option (A):
17840 </p>
17841 <blockquote>
17842 <ul>
17843 <li>
17844 <p>
17845 Add to the new section [forwardlist.compare] the following paragraphs:
17846 </p>
17847
17848 <blockquote>
17849 <pre>template &lt;class T, class Allocator&gt;
17850 bool operator==(const forward_list&lt;T,Allocator&gt;&amp; x, const forward_list&lt;T,Allocator&gt;&amp; y);
17851 </pre>
17852 <blockquote>
17853 <p>
17854 <i>Requires:</i> Type <tt>T</tt> is <tt>EqualityComparable</tt> ([equalitycomparable]).
17855 </p>
17856 <p>
17857 <i>Returns:</i> <tt>true</tt> if
17858 </p>
17859 <ul>
17860 <li>
17861 <p>
17862 for every iterator <tt>i</tt> in the range <tt>[x.begin(), E)</tt>, where <tt>E ==
17863 x.begin() + M</tt> and <tt>M ==
17864    min(distance(x.begin(), x.end()), distance(y.begin(), y.end()))</tt>,
17865 the following condition holds:
17866 </p>
17867 <blockquote><pre>*i == *(y.begin() + (i - x.begin())).
17868 </pre></blockquote>
17869 </li>
17870 <li>
17871 if <tt>i == E</tt> then <tt>i == x.end() &amp;&amp; (y.begin() + (i - x.begin())) == y.end()</tt>.
17872 </li>
17873 <li>
17874 Otherwise, returns <tt>false</tt>.
17875 </li>
17876 </ul>
17877 <p>
17878 <i>Throws:</i> Nothing unless an exception is thrown by the equality comparison.
17879 </p>
17880 <p>
17881 <i>Complexity:</i> At most <tt>M</tt> comparisons.
17882 </p>
17883 </blockquote>
17884 <pre>template &lt;class T, class Allocator&gt;
17885 bool operator!=(const forward_list&lt;T,Allocator&gt;&amp; x, const forward_list&lt;T,Allocator&gt;&amp; y);
17886 </pre>
17887 <blockquote>
17888 <i>Returns:</i> <tt>!(x == y)</tt>.
17889 </blockquote>
17890 </blockquote>
17891 </li>
17892 </ul>
17893 </blockquote>
17894
17895 <p>
17896 Option (B):
17897 </p>
17898 <blockquote>
17899 <ul>
17900 <li>
17901 <p>
17902 Add to the new section [forwardlist.compare] the following paragraphs:
17903 </p>
17904 <blockquote>
17905 <pre>template &lt;class T, class Allocator&gt;
17906 bool operator==(const forward_list&lt;T,Allocator&gt;&amp; x, const forward_list&lt;T,Allocator&gt;&amp; y);
17907 </pre>
17908 <blockquote>
17909 <p>
17910 <i>Requires:</i> Type <tt>T</tt> is <tt>EqualityComparable</tt> ([equalitycomparable]).
17911 </p>
17912 <p>
17913 <i>Returns:</i> <tt>distance(x.begin(), x.end()) == distance(y.begin(), y.end())
17914 &amp;&amp; equal(x.begin(), x.end(), y.begin())</tt>.
17915 </p>
17916 </blockquote>
17917 <pre>template &lt;class T, class Allocator&gt;
17918 bool operator!=(const forward_list&lt;T,Allocator&gt;&amp; x, const forward_list&lt;T,Allocator&gt;&amp; y);
17919 </pre>
17920 <blockquote>
17921 <i>Returns:</i> <tt>!(x == y)</tt>.
17922 </blockquote>
17923 </blockquote>
17924 </li>
17925 </ul>
17926 </blockquote>
17927
17928
17929
17930
17931
17932 <hr>
17933 <h3><a name="862"></a>862. Impossible complexity for 'includes'</h3>
17934 <p><b>Section:</b> 25.3.5.1 [includes] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17935  <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-07-02</p>
17936 <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>
17937 <p><b>Discussion:</b></p>
17938 <p>
17939 In 25.3.5.1 [includes] the complexity is "at most -1 comparisons" if passed
17940 two empty ranges.  I don't know how to perform a negative number of
17941 comparisions!
17942 </p>
17943
17944 <p>
17945 This same issue also applies to:
17946 </p>
17947
17948 <ul>
17949 <li><tt>set_union</tt></li>
17950 <li><tt>set_intersection</tt></li>
17951 <li><tt>set_difference</tt></li>
17952 <li><tt>set_symmetric_difference</tt></li>
17953 <li><tt>merge</tt></li>
17954 </ul>
17955
17956
17957 <p><b>Proposed resolution:</b></p>
17958 <p>
17959 </p>
17960
17961
17962
17963
17964
17965 <hr>
17966 <h3><a name="863"></a>863. What is the state of a stream after close() succeeds</h3>
17967 <p><b>Section:</b> 27.8.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17968  <b>Submitter:</b> Steve Clamage <b>Date:</b> 2008-07-08</p>
17969 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fstreams">issues</a> in [fstreams].</p>
17970 <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>
17971 <p><b>Discussion:</b></p>
17972 <p>
17973 Suppose writing to an <tt>[o]fstream</tt> fails and you later close the <tt>stream</tt>.
17974 The <tt>overflow()</tt> function is called to flush the buffer (if it exists).
17975 Then the file is unconditionally closed, as if by calling <tt>flcose</tt>.
17976 </p>
17977 <p>
17978 If either <tt>overflow</tt> or <tt>fclose</tt> fails, <tt>close()</tt> reports failure, and clearly
17979 the <tt>stream</tt> should be in a failed or bad state.
17980 </p>
17981 <p>
17982 Suppose the buffer is empty or non-existent (so that <tt>overflow()</tt> does not
17983 fail), and <tt>fclose</tt> succeeds. The <tt>close()</tt> function reports success, but
17984 what is the state of the <tt>stream</tt>?
17985 </p>
17986
17987
17988 <p><b>Proposed resolution:</b></p>
17989 <p>
17990 </p>
17991
17992
17993
17994
17995
17996 <hr>
17997 <h3><a name="864"></a>864. Defect in atomic wording</h3>
17998 <p><b>Section:</b> 29.4 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
17999  <b>Submitter:</b> Anthony Williams <b>Date:</b> 2008-07-10</p>
18000 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.operations">issues</a> in [atomics.types.operations].</p>
18001 <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>
18002 <p><b>Discussion:</b></p>
18003 <p>
18004 There's an error in 29.4 [atomics.types.operations]/p9:
18005 </p>
18006
18007 <blockquote>
18008 <pre>C atomic_load(const volatile A * object);
18009 C atomic_load_explicit(const volatile A * object, memory_order);
18010 C A ::load(memory_order order = memory_order_seq_cst) const volatile;
18011 </pre>
18012 <blockquote>
18013 <p>
18014 <i>Requires:</i> The <tt>order</tt> argument shall not be <tt>memory_order_acquire</tt> nor
18015 <tt>memory_order_acq_rel</tt>.
18016 </p>
18017 </blockquote>
18018 </blockquote>
18019
18020 <p>
18021 I believe that this should state
18022 </p>
18023 <blockquote>
18024 shall not be <tt>memory_order_release</tt>.
18025 </blockquote>
18026
18027 <p>
18028 There's also an error in 29.4 [atomics.types.operations]/p17:
18029 </p>
18030
18031 <blockquote>
18032 ... When only one <tt>memory_order</tt> argument is supplied, the value of success
18033 is <tt>order</tt>, and
18034 the value of failure is <tt>order</tt> except that a value of
18035 <tt>memory_order_acq_rel</tt> shall be replaced by the value
18036 <tt>memory_order_require</tt> ...
18037 </blockquote>
18038 <p>
18039 I believe this should state
18040 </p>
18041 <blockquote>
18042 shall be replaced by the value <tt>memory_order_acquire</tt> ...
18043 </blockquote>
18044
18045
18046 <p><b>Proposed resolution:</b></p>
18047 <p>
18048 Change 29.4 [atomics.types.operations]/p9:
18049 </p>
18050
18051 <blockquote>
18052 <pre>C atomic_load(const volatile A * object);
18053 C atomic_load_explicit(const volatile A * object, memory_order);
18054 C A ::load(memory_order order = memory_order_seq_cst) const volatile;
18055 </pre>
18056 <blockquote>
18057 <p>
18058 <i>Requires:</i> The <tt>order</tt> argument shall not be <del><tt>memory_order_acquire</tt></del>
18059 <ins><tt>memory_order_release</tt></ins> nor <tt>memory_order_acq_rel</tt>.
18060 </p>
18061 </blockquote>
18062 </blockquote>
18063
18064 <p>
18065 Change 29.4 [atomics.types.operations]/p17:
18066 </p>
18067
18068 <blockquote>
18069 ... When only one <tt>memory_order</tt> argument is supplied, the value of success
18070 is <tt>order</tt>, and
18071 the value of failure is <tt>order</tt> except that a value of
18072 <tt>memory_order_acq_rel</tt> shall be replaced by the value
18073 <del><tt>memory_order_require</tt></del> <ins><tt>memory_order_acquire</tt></ins> ...
18074 </blockquote>
18075
18076
18077
18078
18079
18080
18081 <hr>
18082 <h3><a name="865"></a>865. More algorithms that throw away information</h3>
18083 <p><b>Section:</b> 25.2.6 [alg.fill], 25.2.7 [alg.generate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
18084  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-07-13</p>
18085 <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>
18086 <p><b>Discussion:</b></p>
18087 <p>
18088 In regard to library defect <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a> I found some more algorithms which
18089 unnecessarily throw away information. These are typically algorithms,
18090 which sequentially write into an <tt>OutputIterator</tt>, but do not return the
18091 final value of this output iterator. These cases are:
18092 </p>
18093
18094 <ol>
18095 <li>
18096 <pre>template&lt;class OutputIterator, class Size, class T&gt;
18097 void fill_n(OutputIterator first, Size n, const T&amp; value);</pre></li>
18098
18099 <li>
18100 <pre>template&lt;class OutputIterator, class Size, class Generator&gt;
18101 void generate_n(OutputIterator first, Size n, Generator gen);</pre></li>
18102 </ol>
18103 <p>
18104 In both cases the minimum requirements on the iterator are
18105 <tt>OutputIterator</tt>, which means according to the requirements of
18106 24.1.2 [output.iterators]/2 that only single-pass iterations are guaranteed.
18107 So, if users of <tt>fill_n</tt> and <tt>generate_n</tt> have *only* an <tt>OutputIterator</tt>
18108 available, they have no chance to continue pushing further values
18109 into it, which seems to be a severe limitation to me.
18110 </p>
18111
18112
18113 <p><b>Proposed resolution:</b></p>
18114 <ol>
18115 <li>
18116 <p>
18117 Replace the current declaration of <tt>fill_n</tt> in 25 [algorithms]/2, header
18118 <tt>&lt;algorithm&gt;</tt> synopsis and in 25.2.6 [alg.fill] by
18119 </p>
18120
18121 <blockquote><pre>template&lt;class OutputIterator, class Size, class T&gt;
18122 <del>void</del> <ins>OutputIterator</ins> fill_n(OutputIterator first, Size n, const T&amp; value);
18123 </pre></blockquote>
18124 <p>
18125 Just after the effects clause p.2 add a new returns clause saying:
18126 </p>
18127 <blockquote>
18128 <i>Returns:</i> <tt>first + n</tt> for <tt>fill_n</tt>.
18129 </blockquote>
18130 </li>
18131 <li>
18132 <p>
18133 Replace the current declaration of <tt>generate_n</tt> in 25 [algorithms]/2, header
18134 <tt>&lt;algorithm&gt;</tt> synopsis and in 25.2.7 [alg.generate] by
18135 </p>
18136 <blockquote><pre>template&lt;class OutputIterator, class Size, class Generator&gt;
18137 <del>void</del> <ins>OutputIterator</ins> generate_n(OutputIterator first, Size n, Generator gen);
18138 </pre></blockquote>
18139 <p>
18140 Just after the effects clause p.1 add a new returns clause saying:
18141 </p>
18142 <blockquote>
18143 <i>Returns:</i> <tt>first + n</tt> for <tt>generate_n</tt>.
18144 </blockquote>
18145 </li>
18146 </ol>
18147
18148
18149
18150
18151
18152 <hr>
18153 <h3><a name="866"></a>866. Qualification of placement new-expressions</h3>
18154 <p><b>Section:</b> 20.7.10 [specialized.algorithms], 20.7.12.2.6 [util.smartptr.shared.create] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
18155  <b>Submitter:</b> Alberto Ganesh Barbati <b>Date:</b> 2008-07-14</p>
18156 <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>
18157 <p><b>Discussion:</b></p>
18158 <p>
18159 LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a> replaced "<tt>new</tt>" with "<tt>::new</tt>" in the placement
18160 new-expression in 20.7.5.1 [allocator.members]. I believe the rationale
18161 given in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a> applies also to the following other contexts:
18162 </p>
18163 <ul>
18164 <li>
18165 <p>
18166 in 20.7.10 [specialized.algorithms], all four algorithms <tt>unitialized_copy</tt>,
18167 <tt>unitialized_copy_n</tt>, <tt>unitialized_fill</tt> and <tt>unitialized_fill_n</tt> use
18168 the unqualified placement new-expression in some variation of the form:
18169 </p>
18170 <blockquote><pre>new  (static_cast&lt;void*&gt;(&amp;*result)) typename  iterator_traits&lt;ForwardIterator&gt;::value_type(*first);
18171 </pre></blockquote>
18172 </li>
18173 <li>
18174 <p>
18175 in 20.7.12.2.6 [util.smartptr.shared.create] there is a reference to the unqualified placement new-expression:
18176 </p>
18177 <blockquote><pre>new  (pv)  T(std::forward&lt;Args&gt;(args)...),
18178 </pre></blockquote>
18179 </li>
18180 </ul>
18181 <p>
18182 I suggest to add qualification in all those places. As far as I know,
18183 these are all the remaining places in the whole library that explicitly
18184 use a placement new-expression. Should other uses come out, they should
18185 be qualified as well.
18186 </p>
18187 <p>
18188 As an aside, a qualified placement new-expression does not need
18189 additional requirements to be compiled in a constrained context. By
18190 adding qualification, the <tt>HasPlacementNew</tt> concept introduced recently in
18191 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2677.pdf">N2677 (Foundational Concepts)</a>
18192 would no longer be needed by library and
18193 should therefore be removed.
18194 </p>
18195
18196
18197 <p><b>Proposed resolution:</b></p>
18198 <p>
18199 Replace "<tt>new</tt>" with "<tt>::new</tt>" in:
18200 </p>
18201 <ul>
18202 <li>
18203 20.7.10.1 [uninitialized.copy], paragraphs 1 and 3
18204 </li>
18205 <li>
18206 20.7.10.2 [uninitialized.fill]  paragraph 1
18207 </li>
18208 <li>
18209 20.7.10.3 [uninitialized.fill.n] paragraph 1
18210 </li>
18211 <li>
18212 20.7.12.2.6 [util.smartptr.shared.create] once in paragraph 1 and twice in paragraph 2.
18213 </li>
18214 </ul>
18215
18216
18217
18218
18219
18220
18221 <hr>
18222 <h3><a name="867"></a>867. Valarray and value-initialization</h3>
18223 <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#New">New</a>
18224  <b>Submitter:</b> Alberto Ganesh Barbati <b>Date:</b> 2008-07-20</p>
18225 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#valarray.cons">active issues</a> in [valarray.cons].</p>
18226 <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>
18227 <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>
18228 <p><b>Discussion:</b></p>
18229 <p>
18230 From 26.5.2.1 [valarray.cons], paragraph 2:
18231 </p>
18232
18233 <blockquote><pre>explicit  valarray(size_t);
18234 </pre>
18235 <blockquote>
18236 The array created by this constructor has a length equal to the value of the argument. The elements
18237 of the array are constructed using the default constructor for the instantiating type <tt>T</tt>.
18238 </blockquote>
18239 </blockquote>
18240
18241 <p>
18242 The problem is that the most obvious <tt>T</tt>s for <tt>valarray</tt> are <tt>float</tt>
18243 and <tt>double</tt>, they don't have a default constructor. I guess the intent is to value-initialize
18244 the elements, so I suggest replacing:
18245 </p>
18246
18247 <blockquote>
18248 The elements of the array are constructed using the default constructor for the instantiating type <tt>T</tt>.
18249 </blockquote>
18250 <p>
18251 with
18252 </p>
18253 <blockquote>
18254 The elements of the array are value-initialized.
18255 </blockquote>
18256
18257 <p>
18258 There is another reference to the default constructor of <tt>T</tt> in the non-normative note in paragraph 9.
18259 That reference should also be replaced. (The normative wording in paragraph 8 refers to <tt>T()</tt>
18260 and so it doesn't need changes).
18261 </p>
18262
18263
18264 <p><b>Proposed resolution:</b></p>
18265 <p>
18266 Change 26.5.2.1 [valarray.cons], paragraph 2:
18267 </p>
18268
18269 <blockquote>
18270 <pre>explicit  valarray(size_t);
18271 </pre>
18272 <blockquote>
18273 The array created by this constructor has a length equal to the value of the argument. The elements
18274 of the array are <del>constructed using the default constructor for the instantiating type <tt>T</tt></del>
18275 <ins>value-initialized (8.5 [dcl.init])</ins>.
18276 </blockquote>
18277 </blockquote>
18278
18279 <p>
18280 Change 26.5.2.7 [valarray.members], paragraph 9:
18281 </p>
18282
18283 <blockquote>
18284 [<i>Example:</i> If the argument has the value -2, the first two elements of the result will be <del>constructed using the
18285 default constructor</del>
18286 <ins>value-initialized (8.5 [dcl.init])</ins>;
18287 the third element of the result will be assigned the value of the first element of the argument; etc. <i>-- end example</i>]
18288 </blockquote>
18289
18290
18291
18292
18293
18294
18295 <hr>
18296 <h3><a name="868"></a>868. default construction and value-initialization</h3>
18297 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
18298  <b>Submitter:</b> Alberto Ganesh Barbati <b>Date:</b> 2008-07-22</p>
18299 <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>
18300 <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>
18301 <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>
18302 <p><b>Discussion:</b></p>
18303 <p>
18304 The term "default constructed" is often used in wording that predates
18305 the introduction of the concept of value-initialization. In a few such
18306 places the concept of value-initialization is more correct than the
18307 current wording (for example when the type involved can be a built-in)
18308 so a replacement is in order. Two of such places are already covered by
18309 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</a>. This issue deliberately addresses the hopefully
18310 non-controversial changes in the attempt of being approved more quickly.
18311 A few other occurrences (for example in <tt>std::tuple</tt>,
18312 <tt>std::reverse_iterator</tt> and <tt>std::move_iterator</tt>) are left to separate
18313 issues. For <tt>std::reverse_iterator</tt>, see also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#408">408</a>. This issue is
18314 related with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>.
18315 </p>
18316
18317
18318 <p><b>Proposed resolution:</b></p>
18319 <p>
18320 Change 20.1.1 [utility.arg.requirements], paragraph 2:
18321 </p>
18322
18323 <blockquote>
18324 In general, a default constructor is not required. Certain container class member function signatures specify
18325 <del>the default constructor</del>
18326 <ins><tt>T()</tt></ins>
18327 as a default argument. <tt>T()</tt> shall be a well-defined expression (8.5 [dcl.init]) if one of
18328 those signatures is called using  the default argument (8.3.6 [dcl.fct.default]).
18329 </blockquote>
18330
18331 <p>
18332 In all the following paragraphs in clause 23 [containers], replace "default constructed" with "value-initialized
18333 (8.5 [dcl.init])":
18334 </p>
18335
18336 <ul>
18337 <li>23.2.2.1 [deque.cons] para 2</li>
18338 <li>23.2.2.2 [deque.capacity] para 1</li>
18339 <li>23.2.3.1 [forwardlist.cons] para 3</li>
18340 <li>23.2.3.4 [forwardlist.modifiers] para 21</li>
18341 <li>23.2.4.1 [list.cons] para 3</li>
18342 <li>23.2.4.2 [list.capacity] para 1</li>
18343 <li>23.2.6.1 [vector.cons] para 3</li>
18344 <li>23.2.6.2 [vector.capacity] para 10</li>
18345 </ul>
18346
18347
18348
18349
18350
18351 <hr>
18352 <h3><a name="869"></a>869. Bucket (local) iterators and iterating past end</h3>
18353 <p><b>Section:</b> 23.1.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
18354  <b>Submitter:</b> Sohail Somani <b>Date:</b> 2008-07-22</p>
18355 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
18356 <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>
18357 <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>
18358 <p><b>Discussion:</b></p>
18359 <p>
18360 Is there any language in the current draft specifying the behaviour of the following snippet?
18361 </p>
18362
18363 <blockquote><pre>unordered_set&lt;int&gt; s;
18364 unordered_set&lt;int&gt;::local_iterator it = s.end(0);
18365
18366 // Iterate past end - the unspecified part
18367 it++;
18368 </pre></blockquote>
18369
18370 <p>
18371 I don't think there is anything about <tt>s.end(n)</tt> being considered an
18372 iterator for the past-the-end value though (I think) it should be.
18373 </p>
18374
18375
18376 <p><b>Proposed resolution:</b></p>
18377 <p>
18378 Change Table 97 "Unordered associative container requirements" in 23.1.5 [unord.req]:
18379 </p>
18380
18381 <blockquote>
18382 <table border="1">
18383 <caption>Table 97: Unordered associative container requirements</caption>
18384 <tbody><tr>
18385 <th>expression</th><th>return type</th><th>assertion/note pre/post-condition</th><th>complexity</th>
18386 </tr>
18387 <tr>
18388 <td><tt>b.begin(n)</tt></td>
18389 <td><tt>local_iterator</tt><br><tt>const_local_iterator</tt> for const <tt>b</tt>.</td>
18390 <td>Pre: n shall be in the range [0,b.bucket_count()). <del>Note: [b.begin(n), b.end(n)) is a
18391 valid range containing all of the elements in the n<sup>th</sup> bucket.</del>
18392 <ins><tt>b.begin(n)</tt> returns an iterator referring to the first element in the bucket.
18393 If the bucket is empty, then <tt>b.begin(n) == b.end(n)</tt>.</ins></td>
18394 <td>Constant</td>
18395 </tr>
18396 <tr>
18397 <td><tt>b.end(n)</tt></td>
18398 <td><tt>local_iterator</tt><br><tt>const_local_iterator</tt> for const <tt>b</tt>.</td>
18399 <td>Pre: n shall be in the range <tt>[0, b.bucket_count())</tt>.
18400 <ins><tt>b.end(n)</tt> returns an iterator which is the past-the-end value for the bucket.</ins></td>
18401 <td>Constant</td>
18402 </tr>
18403 </tbody></table>
18404 </blockquote>
18405
18406
18407
18408
18409
18410
18411 <hr>
18412 <h3><a name="870"></a>870. Do unordered containers not support function pointers for predicate/hasher?</h3>
18413 <p><b>Section:</b> 23.1.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
18414  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-08-17</p>
18415 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
18416 <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>
18417 <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>
18418 <p><b>Discussion:</b></p>
18419 <p>
18420 Good ol' associative containers allow both function pointers and
18421 function objects as feasible
18422 comparators, as described in 23.1.4 [associative.reqmts]/2:
18423 </p>
18424
18425 <blockquote>
18426 Each associative container is parameterized on <tt>Key</tt> and an ordering
18427 relation <tt>Compare</tt> that
18428 induces a strict weak ordering (25.3) on elements of Key. [..]. The
18429 object of type <tt>Compare</tt> is
18430 called the comparison object of a container. This comparison object
18431 may be a pointer to
18432 function or an object of a type with an appropriate function call operator.[..]
18433 </blockquote>
18434
18435 <p>
18436 The corresponding wording for unordered containers is not so clear,
18437 but I read it to disallow
18438 function pointers for the hasher and I miss a clear statement for the
18439 equality predicate, see
18440 23.1.5 [unord.req]/3+4+5:
18441 </p>
18442
18443 <blockquote>
18444 <p>
18445 Each unordered associative container is parameterized by <tt>Key</tt>, by a
18446 function object <tt>Hash</tt> that
18447 acts as a hash function for values of type <tt>Key</tt>, and by a binary
18448 predicate <tt>Pred</tt> that induces an
18449 equivalence relation on values of type <tt>Key</tt>.[..]
18450 </p>
18451 <p>
18452 A hash function is a function object that takes a single argument of
18453 type <tt>Key</tt> and returns a
18454 value of type <tt>std::size_t</tt>.
18455 </p>
18456 <p>
18457 Two values <tt>k1</tt> and <tt>k2</tt> of type <tt>Key</tt> are considered equal if the
18458 container's equality function object
18459 returns <tt>true</tt> when passed those values.[..]
18460 </p>
18461 </blockquote>
18462
18463 <p>
18464 and table 97 says in the column "assertion...post-condition" for the
18465 expression X::hasher:
18466 </p>
18467
18468 <blockquote>
18469 <tt>Hash</tt> shall be a unary function object type such that the expression
18470 <tt>hf(k)</tt> has type <tt>std::size_t</tt>.
18471 </blockquote>
18472
18473 <p>
18474 Note that 20.6 [function.objects]/1 defines as "Function objects are
18475 objects with an <tt>operator()</tt> defined.[..]"
18476 </p>
18477 <p>
18478 Does this restriction exist by design or is it an oversight? If an
18479 oversight, I suggest that to apply
18480 the following
18481 </p>
18482
18483
18484 <p><b>Proposed resolution:</b></p>
18485 <p>
18486 In 23.1.5 [unord.req]/3, just after the second sentence which is written as
18487 </p>
18488
18489 <blockquote>
18490 Additionally, <tt>unordered_map</tt> and <tt>unordered_multimap</tt> associate an
18491 arbitrary mapped type <tt>T</tt> with the <tt>Key</tt>.
18492 </blockquote>
18493
18494 <p>
18495 add one further sentence:
18496 </p>
18497
18498 <blockquote>
18499 Both <tt>Hash</tt> and <tt>Pred</tt> may be pointers to function or objects of a type
18500 with an appropriate function call operator.
18501 </blockquote>
18502
18503 <p>
18504 [Note1: Since the detailed requirements for <tt>Pred</tt> and <tt>Hash</tt> are given in
18505 p.4 and p.5, it an alternative resolution
18506 would be to insert a new paragraph just after p.5, which contains the
18507 above proposed sentence]
18508 </p>
18509 <p>
18510 [Note2: I do not propose a change of above quoted element in table 97,
18511 because the mis-usage of the
18512 notion of "function object" seems already present in the standard at
18513 several places, even if it includes
18514 function pointers, see e.g. 25 [algorithms]/7. The important point is
18515 that in those places a statement is
18516 given that the actually used symbol, like "Predicate" applies for
18517 function pointers as well]
18518 </p>
18519
18520
18521
18522
18523
18524 <hr>
18525 <h3><a name="871"></a>871. Iota's requirements on T are too strong</h3>
18526 <p><b>Section:</b> 26.6.5 [numeric.iota] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
18527  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-08-20</p>
18528 <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>
18529 <p><b>Discussion:</b></p>
18530 <p>
18531 According to the recent WP
18532 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>,
18533 26.6.5 [numeric.iota]/1, the requires clause
18534 of <tt>std::iota</tt> says:
18535 </p>
18536
18537 <blockquote>
18538 <tt>T</tt> shall meet the requirements of <tt>CopyConstructible</tt> and <tt>Assignable</tt> types, and
18539 shall be convertible to <tt>ForwardIterator</tt>'s value type.[..]
18540 </blockquote>
18541
18542 <p>
18543 Neither <tt>CopyConstructible</tt> nor <tt>Assignable</tt> is needed, instead <tt>MoveConstructible</tt>
18544 seems to be the correct choice. I guess the current wording resulted as an
18545 artifact from comparing it with similar numerical algorithms like <tt>accumulate</tt>.
18546 </p>
18547
18548 <p>
18549 Note: If this function will be conceptualized, the here proposed
18550 <tt>MoveConstructible</tt>
18551 requirement can be removed, because this is an implied requirement of
18552 function arguments, see
18553 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2710.pdf">N2710</a>/[temp.req.impl]/3, last bullet.
18554 </p>
18555
18556
18557
18558 <p><b>Proposed resolution:</b></p>
18559
18560 <p>
18561 Change the first sentence of 26.6.5 [numeric.iota]/1:
18562 </p>
18563
18564 <blockquote>
18565 <i>Requires:</i> <tt>T</tt> shall <del>meet the requirements of
18566 <tt>CopyConstructible</tt> and <tt>Assignable</tt> types,</del>
18567 <ins>
18568 be <tt>MoveConstructible</tt> (Table 34)
18569 </ins>
18570 and shall be
18571 convertible to <tt>ForwardIterator</tt>'s value type. [..]
18572 </blockquote>
18573
18574
18575
18576
18577
18578
18579 <hr>
18580 <h3><a name="872"></a>872. <tt>move_iterator::operator[]</tt> has wrong return type</h3>
18581 <p><b>Section:</b> 24.4.3.3.12 [move.iter.op.index] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
18582  <b>Submitter:</b> Doug Gregor <b>Date:</b> 2008-08-21</p>
18583 <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>
18584 <p><b>Discussion:</b></p>
18585 <p>
18586 <tt>move_iterator</tt>'s <tt>operator[]</tt> is declared as:
18587 </p>
18588
18589 <blockquote><pre>reference operator[](difference_type n) const;
18590 </pre></blockquote>
18591
18592 <p>
18593 This has the same problem that <tt>reverse_iterator</tt>'s <tt>operator[]</tt> used to
18594 have: if the underlying iterator's <tt>operator[]</tt> returns a proxy, the
18595 implicit conversion to <tt>value_type&amp;&amp;</tt> could end up referencing a temporary
18596 that has already been destroyed. This is essentially the same issue that
18597 we dealt with for <tt>reverse_iterator</tt> in DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#386">386</a>.
18598 </p>
18599
18600
18601 <p><b>Proposed resolution:</b></p>
18602 <p>
18603 In 24.4.3.1 [move.iterator] and 24.4.3.3.12 [move.iter.op.index], change the declaration of
18604 <tt>move_iterator</tt>'s <tt>operator[]</tt> to:
18605 </p>
18606
18607 <blockquote><pre><del>reference</del> <ins><i>unspecified</i></ins> operator[](difference_type n) const;
18608 </pre></blockquote>
18609
18610
18611
18612
18613
18614
18615 <hr>
18616 <h3><a name="873"></a>873. signed integral type and unsigned integral type are not clearly defined</h3>
18617 <p><b>Section:</b> 3.9.1 [basic.fundamental] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
18618  <b>Submitter:</b> Travis Vitek <b>Date:</b> 2008-06-30</p>
18619 <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>
18620 <p><b>Discussion:</b></p>
18621     <p>
18622       Neither the term "signed integral type" nor the term "unsigned
18623       integral type" is defined in the core language section of the
18624       standard, therefore the library section should avoid its use.  The
18625       terms <i>signed integer type</i> and <i>unsigned integer type</i> are
18626       indeed defined (in 3.9.1 [basic.fundamental]), thus the usages should be
18627       replaced accordingly.
18628     </p>
18629
18630     <p>
18631       Note that the key issue here is that "signed" + "integral type" !=
18632       "signed integral type".
18633
18634       The types <code>bool</code>, <code>char</code>, <code>char16_t</code>,
18635       <code>char32_t</code> and <code>wchar_t</code> are all listed as
18636       integral types, but are neither of <i>signed integer type</i> or
18637       <i>unsigned integer type</i>. According to 3.9 [basic.types] p7, a synonym for
18638       integral type is <i>integer type</i>.
18639
18640       Given this, one may choose to assume that an <i>integral type</i> that
18641       can represent values less than zero is a <i>signed integral type</i>.
18642       Unfortunately this can cause ambiguities.
18643
18644       As an example, if <code>T</code> is <code>unsigned char</code>, the
18645       expression <code>make_signed&lt;T&gt;::type</code>, is supposed to
18646       name a signed integral type. There are potentially two types that
18647       satisfy this requirement, namely <code>signed char</code> and
18648       <code>char</code> (assuming <code>CHAR_MIN &lt; 0</code>).
18649     </p>
18650
18651
18652   <p><b>Proposed resolution:</b></p>
18653     <p>
18654       I propose to use the terms "signed integer type" and "unsigned integer
18655       type" in place of "signed integral type" and "unsigned integral type"
18656       to eliminate such ambiguities.
18657     </p>
18658
18659     <p>
18660       The proposed change makes it absolutely clear that the difference
18661       between two pointers cannot be <tt>char</tt> or <tt>wchar_t</tt>,
18662       but could be any of the signed integer types.
18663       5.7 [expr.add] paragraph 6...
18664     </p>
18665     <blockquote>
18666       <p>
18667         </p><ol>
18668           <li>
18669             When two pointers to elements of the same array object are
18670             subtracted, the result is the difference of the subscripts of
18671             the two array elements. The type of the result is an
18672             implementation-defined <del>signed integral
18673             type</del><ins>signed integer type</ins>; this type shall be the
18674             same type that is defined as <code>std::ptrdiff_t</code> in the
18675             <code>&lt;cstdint&gt;</code> header (18.1)...
18676           </li>
18677         </ol>
18678
18679     </blockquote>
18680
18681     <p>
18682       The proposed change makes it clear that <tt>X::size_type</tt> and
18683       <tt>X::difference_type</tt> cannot be <tt>char</tt> or
18684       <tt>wchar_t</tt>, but could be one of the signed or unsigned integer
18685       types as appropriate.
18686       20.1.2 [allocator.requirements] table 40...
18687     </p>
18688     <blockquote>
18689       Table 40: Allocator requirements
18690       <table border="1">
18691         <thead>
18692           <tr>
18693             <th>expression</th>
18694             <th>return type</th>
18695             <th>assertion/note/pre/post-condition</th>
18696           </tr>
18697         </thead>
18698         <tbody>
18699           <tr>
18700             <td><tt>X::size_type</tt></td>
18701             <td>
18702               <del>unsigned integral type</del>
18703               <ins>unsigned integer type</ins>
18704             </td>
18705             <td>a type that can represent the size of the largest object in
18706             the allocation model.</td>
18707           </tr>
18708           <tr>
18709             <td><tt>X::difference_type</tt></td>
18710             <td>
18711               <del>signed integral type</del>
18712               <ins>signed integer type</ins>
18713             </td>
18714             <td>a type that can represent the difference between any two
18715             pointers in the allocation model.</td>
18716           </tr>
18717         </tbody>
18718       </table>
18719     </blockquote>
18720
18721     <p>
18722       The proposed change makes it clear that <tt>make_signed&lt;T&gt;::type</tt>
18723       must be one of the signed integer types as defined in 3.9.1. Ditto for
18724       <tt>make_unsigned&lt;T&gt;type</tt> and unsigned integer types.
18725       20.5.6.3 [meta.trans.sign] table 48...
18726     </p>
18727     <blockquote>
18728       Table 48: Sign modifications
18729       <table border="1">
18730         <thead>
18731           <tr>
18732             <th>Template</th>
18733             <th>Comments</th>
18734           </tr>
18735         </thead>
18736         <tbody>
18737           <tr>
18738             <td>
18739               <tt>template &lt;class T&gt; struct make_signed;</tt>
18740             </td>
18741             <td>
18742               If <code>T</code> names a (possibly cv-qualified) <del>signed
18743               integral type</del><ins>signed integer type</ins> (3.9.1) then
18744               the member typedef <code>type</code> shall name the type
18745               <code>T</code>; otherwise, if <code>T</code> names a (possibly
18746               cv-qualified) <del>unsigned integral type</del><ins>unsigned
18747               integer type</ins> then <code>type</code> shall name the
18748               corresponding <del>signed integral type</del><ins>signed
18749               integer type</ins>, with the same cv-qualifiers as
18750               <code>T</code>; otherwise, <code>type</code> shall name the
18751               <del>signed integral type</del><ins>signed integer type</ins>
18752               with the smallest rank (4.13) for which <code>sizeof(T) ==
18753               sizeof(type)</code>, with the same cv-qualifiers as
18754               <code>T</code>.
18755
18756               <i>Requires:</i> <code>T</code> shall be a (possibly
18757               cv-qualified) integral type or enumeration but not a
18758               <code>bool</code> type.
18759             </td>
18760           </tr>
18761           <tr>
18762             <td>
18763               <tt>template &lt;class T&gt; struct make_unsigned;</tt>
18764             </td>
18765             <td>
18766               If <code>T</code> names a (possibly cv-qualified)
18767               <del>unsigned integral type</del><ins>unsigned integer
18768               type</ins> (3.9.1) then the member typedef <code>type</code>
18769               shall name the type <code>T</code>; otherwise, if
18770               <code>T</code> names a (possibly cv-qualified) <del>signed
18771               integral type</del><ins>signed integer type</ins> then
18772               <code>type</code> shall name the corresponding <del>unsigned
18773               integral type</del><ins>unsigned integer type</ins>, with the
18774               same cv-qualifiers as <code>T</code>; otherwise,
18775               <code>type</code> shall name the <del>unsigned integral
18776               type</del><ins>unsigned integer type</ins> with the smallest
18777               rank (4.13) for which <code>sizeof(T) == sizeof(type)</code>,
18778               with the same cv-qualifiers as <code>T</code>.
18779
18780               <i>Requires:</i> <code>T</code> shall be a (possibly
18781               cv-qualified) integral type or enumeration but not a
18782               <code>bool</code> type.
18783             </td>
18784           </tr>
18785         </tbody>
18786       </table>
18787     </blockquote>
18788
18789
18790     <p>
18791       Note: I believe that the basefield values should probably be
18792       prefixed with <tt>ios_base::</tt> as they are in 22.2.2.2.2 [facet.num.put.virtuals]
18793
18794       The listed virtuals are all overloaded on signed and unsigned integer
18795       types, the new wording just maintains consistency.
18796
18797       22.2.2.1.2 [facet.num.get.virtuals] table 78...
18798     </p>
18799     <blockquote>
18800       Table 78: Integer Conversions
18801       <table border="1">
18802         <thead>
18803           <tr>
18804             <th>State</th>
18805             <th><tt>stdio</tt> equivalent</th>
18806           </tr>
18807         </thead>
18808         <tbody>
18809           <tr>
18810             <td><tt>basefield == oct</tt></td>
18811             <td><tt>%o</tt></td>
18812           </tr>
18813           <tr>
18814             <td><tt>basefield == hex</tt></td>
18815             <td><tt>%X</tt></td>
18816           </tr>
18817           <tr>
18818             <td><tt>basefield == 0</tt></td>
18819             <td><tt>%i</tt></td>
18820           </tr>
18821           <tr>
18822             <td><del>signed integral type</del><ins>signed integer
18823             type</ins></td>
18824             <td><tt>%d</tt></td>
18825           </tr>
18826           <tr>
18827             <td><del>unsigned integral type</del><ins>unsigned integer
18828             type</ins></td>
18829             <td><tt>%u</tt></td>
18830           </tr>
18831         </tbody>
18832       </table>
18833     </blockquote>
18834
18835
18836
18837     <p>
18838       Rationale is same as above.
18839       22.2.2.2.2 [facet.num.put.virtuals] table 80...
18840     </p>
18841     <blockquote>
18842       Table 80: Integer Conversions
18843       <table border="1">
18844         <thead>
18845           <tr>
18846             <th>State</th>
18847             <th><tt>stdio</tt> equivalent</th>
18848           </tr>
18849         </thead>
18850         <tbody>
18851           <tr>
18852             <td><tt>basefield == ios_base::oct</tt></td>
18853             <td><tt>%o</tt></td>
18854           </tr>
18855           <tr>
18856             <td><tt>(basefield == ios_base::hex) &amp;&amp;
18857             !uppercase</tt></td>
18858             <td><tt>%x</tt></td>
18859           </tr>
18860           <tr>
18861             <td><tt>(basefield == ios_base::hex)</tt></td>
18862             <td><tt>%X</tt></td>
18863           </tr>
18864           <tr>
18865             <td><tt>basefield == 0</tt></td>
18866             <td><tt>%i</tt></td>
18867           </tr>
18868           <tr>
18869             <td>for a <del>signed integral type</del><ins>signed integer
18870             type</ins></td>
18871             <td><tt>%d</tt></td>
18872           </tr>
18873           <tr>
18874             <td>for a <del>unsigned integral type</del><ins>unsigned integer
18875             type</ins></td>
18876             <td><tt>%u</tt></td>
18877           </tr>
18878         </tbody>
18879       </table>
18880     </blockquote>
18881
18882
18883     <p>
18884       23.1 [container.requirements] table 80...
18885     </p>
18886     <blockquote>
18887       Table 89: Container requirements
18888       <table border="1">
18889         <thead>
18890           <tr>
18891             <th>expression</th>
18892             <th>return type</th>
18893             <th>operational semantics</th>
18894             <th>assertion/note/pre/post-condition</th>
18895             <th>complexity</th>
18896           </tr>
18897         </thead>
18898         <tbody>
18899           <tr>
18900             <td><tt>X::difference_type</tt></td>
18901             <td><del>signed integral type</del><ins>signed integer type</ins></td>
18902             <td>&nbsp;</td>
18903             <td>is identical to the difference type of <tt>X::iterator</tt>
18904             and <tt>X::const_iterator</tt></td>
18905             <td>compile time</td>
18906           </tr>
18907           <tr>
18908             <td><tt>X::size_type</tt></td>
18909             <td><del>unsigned integral type</del><ins>unsigned integer type</ins></td>
18910             <td>&nbsp;</td>
18911             <td><tt>size_type</tt> can represent any non-negative value of
18912             <tt>difference_type</tt></td>
18913             <td>compile time</td>
18914           </tr>
18915         </tbody>
18916       </table>
18917     </blockquote>
18918
18919     <p>
18920       24.1 [iterator.requirements] paragraph 1...
18921     </p>
18922     <blockquote>
18923       Iterators are a generalization of pointers that allow a C++ program to
18924       work with different data structures (containers) in a uniform manner.
18925       To be able to construct template algorithms that work correctly and
18926       efficiently on different types of data structures, the library
18927       formalizes not just the interfaces but also the semantics and
18928       complexity assumptions of iterators. All input iterators
18929       <code>i</code> support the expression <code>*i</code>, resulting in a
18930       value of some class, enumeration, or built-in type <code>T</code>,
18931       called the <i>value type</i> of the iterator. All output iterators
18932       support the expression <code>*i = o</code> where <code>o</code> is a
18933       value of some type that is in the set of types that are
18934       <i>writable</i> to the particular iterator type of <code>i</code>. All
18935       iterators <code>i</code> for which the expression <code>(*i).m</code>
18936       is well-defined, support the expression <code>i-&gt;m</code> with the
18937       same semantics as <code>(*i).m</code>. For every iterator type
18938       <code>X</code> for which equality is defined, there is a corresponding
18939       <del>signed integral type</del> <ins>signed integer type</ins> called
18940       the <i>difference type</i> of the iterator.
18941     </blockquote>
18942
18943     <p>
18944       I'm a little unsure of this change. Previously this paragraph would
18945       allow instantiations of <tt>linear_congruential_engine</tt> on
18946       <tt>char</tt>, <tt>wchar_t</tt>, <tt>bool</tt>, and other types. The
18947       new wording prohibits this.
18948       26.4.3.1 [rand.eng.lcong] paragraph 2...
18949     </p>
18950     <blockquote>
18951       The template parameter <code>UIntType</code> shall denote an
18952       <del>unsigned integral type</del><ins>unsigned integer type</ins>
18953       large enough to store values as large as <code>m - 1</code>. If the
18954       template parameter <code>m</code> is 0, the modulus <code>m</code>
18955       used throughout this section 26.4.3.1 is
18956       <code>numeric_limits&lt;result_type&gt;::max()</code> plus 1.  [Note:
18957       The result need not be representable as a value of type
18958       <code>result_type</code>. --end note] Otherwise, the following
18959       relations shall hold: <code>a &lt; m</code> and <code>c &lt;
18960       m</code>.
18961     </blockquote>
18962
18963     <p>
18964       Same rationale as the previous change.
18965       26.4.4.4 [rand.adapt.xor] paragraph 6...
18966     </p>
18967     <blockquote>
18968       Both <code>Engine1::result_type</code> and
18969       <code>Engine2::result_type</code> shall denote (possibly different)
18970       <del>unsigned integral types</del><ins>unsigned integer types</ins>.
18971       The member <i>result_type</i> shall denote either the type
18972       <i>Engine1::result_type</i> or the type <i>Engine2::result_type</i>,
18973       whichever provides the most storage according to clause 3.9.1.
18974     </blockquote>
18975
18976     <p>
18977       26.4.7.1 [rand.util.seedseq] paragraph 7...
18978     </p>
18979     <blockquote>
18980       <i>Requires:</i><code>RandomAccessIterator</code> shall meet the
18981       requirements of a random access iterator (24.1.5) such that
18982       <code>iterator_traits&lt;RandomAccessIterator&gt;::value_type</code>
18983       shall denote an <del>unsigned integral type</del><ins>unsigned integer
18984       type</ins> capable of accomodating 32-bit quantities.
18985     </blockquote>
18986
18987     <p>
18988       By making this change, integral types that happen to have a signed
18989       representation, but are not signed integer types, would no longer be
18990       required to use a two's complement representation. This may go against
18991       the original intent, and should be reviewed.
18992       29.4 [atomics.types.operations] paragraph 24...
18993     </p>
18994     <blockquote>
18995       <i>Remark:</i> For <del>signed integral types</del><ins>signed integer
18996       types</ins>, arithmetic is defined using two's complement
18997       representation. There are no undefined results. For address types, the
18998       result may be an undefined address, but the operations otherwise have
18999       no undefined behavior.
19000     </blockquote>
19001
19002
19003
19004
19005
19006
19007 <hr>
19008 <h3><a name="874"></a>874. Missing <tt>initializer_list</tt> constructor for <tt>discrete_distribution</tt></h3>
19009 <p><b>Section:</b> 26.4.8.5.1 [rand.dist.samp.discrete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
19010  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-08-22</p>
19011 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.discrete">active issues</a> in [rand.dist.samp.discrete].</p>
19012 <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>
19013 <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>
19014 <p><b>Discussion:</b></p>
19015 <p>
19016 During the Sophia Antipolis meeting it was decided to separate from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a> a
19017 subrequest that adds initializer list support to
19018 <tt>discrete_distribution</tt>, specifically,
19019 the issue proposed to add a c'tor taking a <tt>initializer_list&lt;double&gt;</tt>.
19020 </p>
19021
19022
19023
19024 <p><b>Proposed resolution:</b></p>
19025 <ol>
19026 <li>
19027 <p>
19028 In 26.4.8.5.1 [rand.dist.samp.discrete]/1, class <tt>discrete_distribution</tt>,
19029 just <em>before</em> the member declaration
19030 </p>
19031
19032 <blockquote><pre>explicit discrete_distribution(const param_type&amp; parm);
19033 </pre></blockquote>
19034
19035 <p>
19036 insert
19037 </p>
19038
19039 <blockquote><pre>discrete_distribution(initializer_list&lt;double&gt; wl);
19040 </pre></blockquote>
19041 </li>
19042
19043 <li>
19044 <p>
19045 Between p.4 and p.5 of the same section insert a new
19046 paragraph as part of the new member description:
19047 </p>
19048
19049 <blockquote><pre>discrete_distribution(initializer_list&lt;double&gt; wl);
19050 </pre>
19051
19052 <blockquote>
19053 <i>Effects:</i> Same as <tt>discrete_distribution(wl.begin(), wl.end())</tt>.
19054 </blockquote>
19055 </blockquote>
19056 </li>
19057 </ol>
19058
19059
19060
19061
19062
19063 <hr>
19064 <h3><a name="875"></a>875. Missing <tt>initializer_list</tt> constructor for <tt>piecewise_constant_distribution</tt></h3>
19065 <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>
19066  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-08-22</p>
19067 <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>
19068 <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>
19069 <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>
19070 <p><b>Discussion:</b></p>
19071 <p>
19072 During the Sophia Antipolis meeting it was decided to separate from
19073 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#794">794</a> a subrequest that adds initializer list support to
19074 <tt>piecewise_constant_distribution</tt>, specifically, the issue proposed
19075 to add a c'tor taking a <tt>initializer_list&lt;double&gt;</tt> and a <tt>Callable</tt> to evaluate
19076 weight values. For consistency with the remainder of this class and
19077 the remainder of the <tt>initializer_list</tt>-aware library the author decided to
19078 change the list argument type to the template parameter <tt>RealType</tt>
19079 instead. For the reasoning to use <tt>Func</tt> instead of <tt>Func&amp;&amp;</tt> as c'tor
19080 function argument see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>.
19081 </p>
19082
19083
19084 <p><b>Proposed resolution:</b></p>
19085 <ol>
19086 <li>
19087 <p>
19088 In 26.4.8.5.2 [rand.dist.samp.pconst]/1, class <tt>piecewise_constant_distribution</tt>,
19089 just <em>before</em> the member declaration
19090 </p>
19091
19092 <blockquote><pre>explicit piecewise_constant_distribution(const param_type&amp; parm);
19093 </pre></blockquote>
19094
19095 <p>
19096 insert
19097 </p>
19098
19099 <blockquote><pre>template&lt;typename Func&gt;
19100 piecewise_constant_distribution(initializer_list&lt;RealType&gt; bl, Func fw);
19101 </pre></blockquote>
19102 </li>
19103
19104 <li>
19105 <p>
19106 Between p.4 and p.5 of the same section insert a series of
19107 new paragraphs nominated below as [p5_1], [p5_2], and [p5_3]
19108 as part of the new member description:
19109 </p>
19110
19111 <blockquote><pre>template&lt;typename Func&gt;
19112 piecewise_constant_distribution(initializer_list&lt;RealType&gt; bl, Func fw);
19113 </pre>
19114
19115 <blockquote>
19116
19117 <p>
19118 [p5_1] <i>Complexity:</i> Exactly <tt>nf = max(bl.size(), 1) - 1</tt> invocations of <tt>fw</tt>.
19119 </p>
19120
19121 <p>
19122 [p5_2] <i>Requires:</i>
19123 </p>
19124
19125 <ol type="a">
19126 <li>
19127 <tt>fw</tt> shall be callable with one argument of type <tt>RealType</tt>, and shall
19128    return values of a type convertible to <tt>double</tt>;
19129 </li>
19130 <li>
19131 The relation <tt>0 &lt; S = w<sub>0</sub>+. . .+w<sub>n-1</sub></tt> shall hold.
19132 For all sampled values <tt><i>x<sub>k</sub></i></tt> defined below, <tt>fw(<i>x<sub>k</sub></i>)</tt> shall return a weight
19133    value <tt><i>w<sub>k</sub></i></tt> that is non-negative, non-NaN, and non-infinity;
19134 </li>
19135 <li>
19136 If <tt>nf &gt; 0</tt> let <tt>b<sub><i>k</i></sub> = *(bl.begin() + k), k = 0, . . . , bl.size()-1</tt> and the
19137 following relations shall hold for <tt>k = 0, . . . , nf-1: b<sub><i>k</i></sub> &lt; b<sub><i>k+1</i></sub></tt>.
19138 </li>
19139 </ol>
19140
19141 <p>
19142 [p5_3] <i>Effects:</i>
19143 </p>
19144
19145 <ol type="a">
19146 <li>
19147 <p>If <tt>nf == 0</tt>,</p>
19148 <ol type="a">
19149 <li>
19150 lets the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist of the single
19151      value <tt>w<sub>0</sub> = 1</tt>, and
19152 </li>
19153 <li>
19154 lets the sequence <tt>b</tt> have length <tt>n+1</tt> with <tt>b<sub>0</sub> = 0</tt> and <tt>b<sub>1</sub> = 1</tt>.
19155 </li>
19156 </ol>
19157 </li>
19158
19159 <li>
19160 <p>Otherwise,</p>
19161 <ol type="a">
19162 <li>
19163 sets <tt>n = nf</tt>, and <tt>[bl.begin(), bl.end())</tt> shall form the sequence <tt>b</tt> of
19164 length <tt>n+1</tt>, and
19165 </li>
19166 <li>
19167 <p>lets the sequences <tt>w</tt> have length <tt>n</tt> and for each <tt>k = 0, . . . ,n-1</tt>,
19168      calculates:</p>
19169 <blockquote><pre>x<sub><i>k</i></sub> = 0.5*(b<sub><i>k+1</i></sub> + b<sub><i>k</i></sub>)
19170 w<sub><i>k</i></sub> = fw(x<sub><i>k</i></sub>)
19171 </pre></blockquote>
19172 </li>
19173 </ol>
19174 </li>
19175
19176 <li>
19177 <p>
19178 Constructs a <tt>piecewise_constant_distribution</tt> object with
19179 the above computed sequence <tt>b</tt> as the interval boundaries
19180 and with the probability densities:
19181 </p>
19182 <blockquote><pre>&#961;<sub><i>k</i></sub> = w<sub><i>k</i></sub>/(S * (b<sub><i>k+1</i></sub> - b<sub><i>k</i></sub>)) for k = 0, . . . , n-1.
19183 </pre></blockquote>
19184
19185 </li>
19186 </ol>
19187
19188 </blockquote>
19189 </blockquote>
19190 </li>
19191 </ol>
19192
19193
19194
19195
19196
19197 <hr>
19198 <h3><a name="876"></a>876. <tt>basic_string</tt> access operations should give stronger guarantees</h3>
19199 <p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
19200  <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-08-22</p>
19201 <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>
19202 <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>
19203 <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>
19204 <p><b>Discussion:</b></p>
19205 <p>
19206 During the Sophia Antipolis meeting it was decided to split-off some
19207 parts of the
19208 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2647.html">n2647</a>
19209 ("Concurrency modifications for <tt>basic_string</tt>")
19210 proposal into a separate issue, because these weren't actually
19211 concurrency-related. The here proposed changes refer to the recent
19212 update document
19213 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2668.htm">n2668</a>
19214 and attempt to take advantage of the
19215 stricter structural requirements.
19216 </p>
19217 <p>
19218 Indeed there exists some leeway for more guarantees that would be
19219 very useful for programmers, especially if interaction with transactionary
19220 or exception-unaware C API code is important. This would also allow
19221 compilers to take advantage of more performance optimizations, because
19222 more functions can have throw() specifications. This proposal uses the
19223 form of "Throws: Nothing" clauses to reach the same effect, because
19224 there already exists a different issue in progress to clean-up the current
19225 existing "schizophrenia" of the standard in this regard.
19226 </p>
19227 <p>
19228 Due to earlier support for copy-on-write, we find the following
19229 unnecessary limitations for C++0x:
19230 </p>
19231
19232 <ol>
19233 <li>
19234 Missing no-throw guarantees: <tt>data()</tt> and <tt>c_str()</tt> simply return
19235 a pointer to their guts, which is a non-failure operation. This should
19236 be spelled out. It is also noteworthy to mention that the same
19237 guarantees should also be given by the size query functions,
19238 because the combination of pointer to content and the length is
19239 typically needed during interaction with low-level API.
19240 </li>
19241 <li>
19242 Missing complexity guarantees: <tt>data()</tt> and <tt>c_str()</tt> simply return
19243 a pointer to their guts, which is guaranteed O(1). This should be
19244 spelled out.
19245 </li>
19246 <li>
19247 Missing reading access to the terminating character: Only the
19248 const overload of <tt>operator[]</tt> allows reading access to the terminator
19249 char. For more intuitive usage of strings, reading access to this
19250 position should be extended to the non-const case. In contrast
19251 to C++03 this reading access should now be homogeneously
19252 an lvalue access.
19253 </li>
19254 </ol>
19255
19256 <p>
19257 The proposed resolution is split into a main part (A) and a
19258 secondary part (B) (earlier called "Adjunct Adjunct Proposal").
19259 (B) extends (A) by also making access to index position
19260 size() of the at() overloads a no-throw operation. This was
19261 separated, because this part is theoretically observable in
19262 specifically designed test programs.
19263 </p>
19264
19265
19266 <p><b>Proposed resolution:</b></p>
19267 <ol type="A">
19268 <li>
19269 <ol>
19270 <li>
19271 <p>In 21.3.4 [string.capacity], just after p. 1 add a new paragraph:
19272 </p>
19273 <blockquote>
19274 <i>Throws:</i> Nothing.
19275 </blockquote>
19276
19277 </li>
19278 <li>
19279 <p>
19280 In 21.3.5 [string.access] <em>replace</em> p. 1 by the following <em>4</em> paragraghs:
19281 </p>
19282
19283 <blockquote>
19284 <p>
19285 <i>Requires:</i> <tt>pos &#8804; size()</tt>.
19286 </p>
19287 <p>
19288 <i>Returns:</i> If <tt>pos &lt; size()</tt>, returns <tt>*(begin() + pos)</tt>. Otherwise, returns
19289 a reference to a <tt>charT()</tt> that shall not be modified.
19290 </p>
19291 <p>
19292 <i>Throws:</i> Nothing.
19293 </p>
19294 <p>
19295 <i>Complexity:</i> Constant time.
19296 </p>
19297 </blockquote>
19298
19299 </li>
19300 <li>
19301 <p>
19302 In 21.3.7.1 [string.accessors] replace the now <em>common</em> returns
19303 clause of <tt>c_str()</tt> and <tt>data()</tt> by the following <em>three</em> paragraphs:
19304 </p>
19305 <blockquote>
19306 <p>
19307 <i>Returns:</i> A pointer <tt>p</tt> such that <tt>p+i == &amp;operator[](i)</tt> for each <tt>i</tt>
19308 in <tt>[0, size()]</tt>.
19309 </p>
19310 <p>
19311 <i>Throws:</i> Nothing.
19312 </p>
19313 <p>
19314 <i>Complexity:</i> Constant time.
19315 </p>
19316 </blockquote>
19317 </li>
19318 </ol>
19319 </li>
19320 <li>
19321 <ol start="4">
19322 <li>
19323 <p>
19324 In 21.3.5 [string.access] <em>replace</em> p.2 and p.3 by:
19325 </p>
19326 <blockquote>
19327 <p>
19328 <i>Requires:</i> <tt>pos &#8804; size()</tt>
19329 </p>
19330 <p>
19331 <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos &gt; size()</tt>.
19332 </p>
19333 </blockquote>
19334 </li>
19335 </ol>
19336 </li>
19337 </ol>
19338
19339
19340
19341
19342
19343
19344 <hr>
19345 <h3><a name="877"></a>877. to <tt>throw()</tt> or to <i>Throw:</i> Nothing.</h3>
19346 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
19347  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-08-23</p>
19348 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
19349 <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>
19350 <p><b>Discussion:</b></p>
19351        <p>
19352
19353 Recent changes to
19354 the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">working
19355 draft</a> have introduced a gratuitous inconsistency with the C++ 2003
19356 version of the specification with respect to exception guarantees
19357 provided by standard functions. While the C++ 2003 standard
19358 consistenly uses the empty exception specification, <tt>throw()</tt>,
19359 to declare functions that are guaranteed not to throw exceptions, the
19360 current working draft contains a number of "<i>Throws:</i> Nothing."
19361 clause to specify essentially the same requirement. The difference
19362 between the two approaches is that the former specifies the behavior
19363 of programs that violate the requirement (<tt>std::unexpected()</tt>
19364 is called) while the latter leaves the behavior undefined.
19365
19366        </p>
19367        <p>
19368
19369 A survey of the working draft reveals that there are a total of 209
19370 occurrences of <tt>throw()</tt> in the library portion of the spec,
19371 the majority in clause 18, a couple (literally) in 19, a handful in
19372 20, a bunch in 22, four in 24, one in 27, and about a dozen in D.9.
19373
19374        </p>
19375        <p>
19376
19377 There are also 203 occurrences of "<i>Throws:</i> Nothing." scattered
19378 throughout the spec.
19379
19380        </p>
19381        <p>
19382
19383 While sometimes there are good reasons to use the "<i>Throws:</i>
19384 Nothing."  approach rather than making use of <tt>throw()</tt>, these
19385 reasons do not apply in most of the cases where this new clause has
19386 been introduced and the empty exception specification would be a
19387 better approach.
19388
19389        </p>
19390        <p>
19391
19392 First, functions declared with the empty exception specification
19393 permit compilers to generate better code for calls to such
19394 functions. In some cases, the compiler might even be able to eliminate
19395 whole chunks of user-written code when instantiating a generic
19396 template on a type whose operations invoked from the template
19397 specialization are known not to throw. The prototypical example are
19398 the <tt>std::uninitialized_copy()</tt>
19399 and <tt>std::uninitialized_fill()</tt> algorithms where the
19400 entire <tt>catch(...)</tt> block can be optimized away.
19401
19402        </p>
19403        <p>
19404
19405 For example, given the following definition of
19406 the <tt>std::uninitialized_copy</tt> function template and a
19407 user-defined type <tt>SomeType</tt>:
19408
19409        </p>
19410        <blockquote>
19411            <pre>template &lt;class InputIterator, class ForwardIterator&gt;
19412 ForwardIterator
19413 uninitialized_copy (InputIterator first, InputIterator last, ForwardIterator res)
19414 {
19415    typedef iterator_traits&lt;ForwardIterator&gt;::value_type ValueType;
19416
19417    ForwardIterator start = res;
19418
19419    try {
19420        for (; first != last; ++first, ++res)
19421            ::new (&amp;*res) ValueType (*first);
19422    }
19423    catch (...) {
19424        for (; start != res; --start)
19425            (&amp;*start)-&gt;~ValueType ();
19426        throw;
19427    }
19428    return res;
19429 }
19430
19431 struct SomeType {
19432    SomeType (const SomeType&amp;) <ins>throw ()</ins>;
19433 }</pre>
19434        </blockquote>
19435        <p>
19436
19437 compilers are able to emit the following efficient specialization
19438 of <tt>std::uninitialized_copy&lt;const SomeType*, SomeType*&gt;</tt>
19439 (note that the <tt>catch</tt> block has been optimized away):
19440
19441        </p>
19442        <blockquote>
19443            <pre>template &lt;&gt; SomeType*
19444 uninitialized_copy (const SomeType *first, const SomeType *last, SomeType *res)
19445 {
19446    for (; first != last; ++first, ++res)
19447        ::new (res) SomeType (*first);
19448
19449    return res;
19450 }</pre>
19451        </blockquote>
19452        <p>
19453
19454 Another general example is default constructors which, when decorated
19455 with <tt>throw()</tt>, allow the compiler to eliminate the
19456 implicit <tt>try</tt> and <tt>catch</tt> blocks that it otherwise must
19457 emit around each the invocation of the constructor
19458 in <i>new-expressions</i>.
19459
19460        </p>
19461        <p>
19462
19463 For example, given the following definitions of
19464 class <tt>MayThrow</tt> and <tt>WontThrow</tt> and the two
19465 statements below:
19466
19467        </p>
19468        <blockquote>
19469            <pre>struct MayThrow {
19470    MayThrow ();
19471 };
19472
19473 struct WontThrow {
19474    WontThrow () <ins>throw ()</ins>;
19475 };
19476
19477 MayThrow  *a = new MayThrow [N];
19478 WontThrow *b = new WontThrow [N];</pre>
19479
19480        </blockquote>
19481        <p>
19482
19483 the compiler generates the following code for the first statement:
19484
19485        </p>
19486        <blockquote>
19487            <pre>MayThrow *a;
19488 {
19489    MayThrow *first = operator new[] (N * sizeof (*a));
19490    MayThrow *last  = first + N;
19491    MayThrow *next  = first;
19492    try {
19493        for ( ; next != last; ++next)
19494            new (next) MayThrow;
19495    }
19496    catch (...) {
19497        for ( ; first != first; --next)
19498            next-&gt;~MayThrow ();
19499        operator delete[] (first);
19500        throw;
19501    }
19502    a = first;
19503 }</pre>
19504        </blockquote>
19505        <p>
19506
19507 but it is can generate much more compact code for the second statement:
19508
19509        </p>
19510        <blockquote>
19511            <pre>WontThrow *b    = operator new[] (N * sizeof (*b));
19512 WontThrow *last = b + N;
19513 for (WontThrow *next = b; next != last; ++next)
19514    new (next) WontThrow;
19515 </pre>
19516        </blockquote>
19517        <p>
19518
19519 Second, in order for users to get the maximum benefit out of the new
19520 <tt>std::has_nothrow_xxx</tt> traits when using standard library types
19521 it will be important for implementations to decorate all non throwing
19522 copy constructors and assignment operators with <tt>throw()</tt>. Note
19523 that while an optimizer may be able to tell whether a function without
19524 an explicit exception specification can throw or not based on its
19525 definition, it can only do so when it can see the source code of the
19526 definition. When it can't it must assume that the function may
19527 throw. To prevent violating the One Definition Rule,
19528 the <tt>std::has_nothrow_xxx</tt> trait must return the most
19529 pessimistic guess across all translation units in the program, meaning
19530 that <tt>std::has_nothrow_xxx&lt;T&gt;::value</tt> must evaluate to
19531 <tt>false</tt> for any <tt>T</tt> whose <tt>xxx</tt>
19532 (where <tt>xxx</tt> is default or copy ctor, or assignment operator)
19533 is defined out-of-line.
19534
19535        </p>
19536        <p>
19537
19538 <b>Counterarguments:</b>
19539
19540        </p>
19541        <p>
19542
19543 During the discussion of this issue
19544 on <a href="mailto:c++std-lib@accu.org">c++std-lib@accu.org</a>
19545 (starting with post <tt>c++std-lib-21950</tt>) the following arguments
19546 in favor of the "<i>Throws:</i> Nothing." style have been made.
19547
19548        </p>
19549        <p>
19550          </p><ol>
19551            <li>
19552
19553 Decorating functions that cannot throw with the empty exception
19554 specification can cause the compiler to generate suboptimal code for
19555 the implementation of the function when it calls other functions that
19556 aren't known to the compiler not to throw (i.e., that aren't decorated
19557 with <tt>throw()</tt> even if they don't actually throw). This is a
19558 common situation when the called function is a C or POSIX function.
19559
19560            </li>
19561            <li>
19562
19563 Alternate, proprietary mechanisms exist (such as
19564 GCC <a href="http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Function-Attributes.html#index-g_t_0040code_007bnothrow_007d-function-attribute-2160"><tt>__attribute__((nothrow))</tt></a>
19565 or Visual
19566 C++ <a href="http://msdn.microsoft.com/en-us/library/49147z04%28VS.80%29.aspx"><tt>__declspec(nothrow)</tt></a>)
19567 that let implementers mark up non-throwing functions, often without
19568 the penalty mentioned in (1) above. The C++ standard shouldn't
19569 preclude the use of these potentially more efficient mechanisms.
19570
19571            </li>
19572            <li>
19573
19574 There are functions, especially function templates, that invoke
19575 user-defined functions that may or may not be
19576 declared <tt>throw()</tt>. Declaring such functions with the empty
19577 exception specification will cause compilers to generate suboptimal
19578 code when the user-defined function isn't also declared not to throw.
19579
19580            </li>
19581         </ol>
19582
19583        <p>
19584
19585 The answer to point (1) above is that implementers can (and some have)
19586 declare functions with <tt>throw()</tt> to indicate to the compiler
19587 that calls to the function can safely be assumed not to throw in order
19588 to allow it to generate efficient code at the call site without also
19589 having to define the functions the same way and causing the compiler
19590 to generate suboptimal code for the function definition. That is, the
19591 function is declared with <tt>throw()</tt> in a header but it's
19592 defined without it in the source file. The <tt>throw()</tt>
19593 declaration is suppressed when compiling the definition to avoid
19594 compiler errors. This technique, while strictly speaking no permitted
19595 by the language, is safe and has been employed in practice. For
19596 example, the GNU C library takes this approach. Microsoft Visual C++
19597 takes a similar approach by simply assuming that no function with C
19598 language linkage can throw an exception unless it's explicitly
19599 declared to do so using the language extension <tt>throw(...)</tt>.
19600
19601        </p>
19602        <p>
19603
19604 Our answer to point (2) above is that there is no existing practice
19605 where C++ Standard Library implementers have opted to make use of the
19606 proprietary mechanisms to declare functions that don't throw. The
19607 language provides a mechanism specifically designed for this
19608 purpose. Avoiding its use in the specification itself in favor of
19609 proprietary mechanisms defeats the purpose of the feature. In
19610 addition, making use of the empty exception specification
19611 inconsistently, in some areas of the standard, while conspicuously
19612 avoiding it and making use of the "<i>Throws:</i> Nothing." form in
19613 others is confusing to users.
19614
19615        </p>
19616        <p>
19617
19618 The answer to point (3) is simply to exercise caution when declaring
19619 functions and especially function templates with the empty exception
19620 specification. Functions that required not to throw but that may call
19621 back into user code are poor candidates for the empty exception
19622 specification and should instead be specified using "<i>Throws:</i>
19623 Nothing." clause.
19624
19625       </p>
19626
19627    <p><b>Proposed resolution:</b></p>
19628        <p>
19629
19630 We propose two possible solutions. Our recommendation is to adopt
19631 Option 1 below.
19632
19633        </p>
19634        <p>
19635
19636 <b>Option 1:</b>
19637
19638        </p>
19639        <p>
19640
19641 Except for functions or function templates that make calls back to
19642 user-defined functions that may not be declared <tt>throw()</tt>
19643 replace all occurrences of the "<i>Throws:</i> Nothing." clause with
19644 the empty exception specification. Functions that are required not to
19645 throw but that make calls back to user code should be specified to
19646 "<i>Throw:</i> Nothing."
19647
19648        </p>
19649        <p>
19650
19651 <b>Option 2:</b>
19652
19653        </p>
19654        <p>
19655
19656 For consistency, replace all occurrences of the empty exception
19657 specification with a "<i>Throws:</i> Nothing." clause.
19658
19659        </p>
19660
19661
19662
19663
19664 <hr>
19665 <h3><a name="878"></a>878. <tt>forward_list</tt> preconditions</h3>
19666 <p><b>Section:</b> 23.2.3 [forwardlist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
19667  <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-08-23</p>
19668 <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>
19669 <p><b>Discussion:</b></p>
19670        <p>
19671
19672 <tt>forward_list</tt> member functions that take
19673 a <tt>forward_list::iterator</tt> (denoted <tt>position</tt> in the
19674 function signatures) argument have the following precondition:
19675
19676        </p>
19677        <blockquote>
19678
19679 <i>Requires:</i> <tt>position</tt> is dereferenceable or equal
19680 to <tt>before_begin()</tt>.
19681
19682        </blockquote>
19683        <p>
19684
19685 I believe what's actually intended is this:
19686
19687        </p>
19688        <blockquote>
19689
19690 <i>Requires:</i> <tt>position</tt> is in the range
19691 [<tt>before_begin()</tt>, <tt>end()</tt>).
19692
19693        </blockquote>
19694        <p>
19695
19696 That is, when it's dereferenceable, <tt>position</tt> must point
19697 into <tt>*this</tt>, not just any <tt>forward_list</tt> object.
19698
19699        </p>
19700
19701    <p><b>Proposed resolution:</b></p>
19702        <p>
19703
19704 Change the <i>Requires</i> clause as follows:
19705
19706        </p>
19707        <blockquote>
19708
19709 <i>Requires:</i> <tt>position</tt> is <ins>in the range
19710 [<tt>before_begin()</tt>, <tt>end()</tt>)</ins> <del>dereferenceable
19711 or equal to <tt>before_begin()</tt></del>.
19712
19713        </blockquote>
19714
19715
19716
19717
19718 </body></html>