--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
+<html><head>
+<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
+
+
+<title>C++ Standard Library Active Issues List</title>
+<style type="text/css">
+p {text-align:justify}
+li {text-align:justify}
+ins {background-color:#A0FFA0}
+del {background-color:#FFA0A0}
+</style>
+</head><body>
+<table>
+<tbody><tr>
+<td align="left">Doc. no.</td>
+<td align="left">N2727=08-0237</td>
+</tr>
+<tr>
+<td align="left">Date:</td>
+<td align="left">2008-08-24</td>
+</tr>
+<tr>
+<td align="left">Project:</td>
+<td align="left">Programming Language C++</td>
+</tr>
+<tr>
+<td align="left">Reply to:</td>
+<td align="left">Howard Hinnant <<a href="mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>></td>
+</tr>
+</tbody></table>
+<h1>C++ Standard Library Active Issues List (Revision R59)</h1>
+
+ <p>Reference ISO/IEC IS 14882:1998(E)</p>
+ <p>Also see:</p>
+ <ul>
+ <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html">Table of Contents</a> for all library issues.</li>
+ <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html">Index by Section</a> for all library issues.</li>
+ <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html">Index by Status</a> for all library issues.</li>
+ <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a></li>
+ <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a></li>
+ </ul>
+ <p>The purpose of this document is to record the status of issues
+ which have come before the Library Working Group (LWG) of the ANSI
+ (J16) and ISO (WG21) C++ Standards Committee. Issues represent
+ potential defects in the ISO/IEC IS 14882:1998(E) document. Issues
+ are not to be used to request new features. </p>
+
+ <p>This document contains only library issues which are actively being
+ considered by the Library Working Group. That is, issues which have a
+ 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>,
+ <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
+ <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a> for issues considered defects and
+ <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a> for issues considered closed.</p>
+
+ <p>The issues in these lists are not necessarily formal ISO Defect
+ Reports (DR's). While some issues will eventually be elevated to
+ official Defect Report status, other issues will be disposed of in
+ other ways. See <a href="#Status">Issue Status</a>.</p>
+
+ <p>This document is in an experimental format designed for both
+ viewing via a world-wide web browser and hard-copy printing. It
+ is available as an HTML file for browsing or PDF file for
+ printing.</p>
+
+ <p>Prior to Revision 14, library issues lists existed in two slightly
+ different versions; a Committee Version and a Public
+ Version. Beginning with Revision 14 the two versions were combined
+ into a single version.</p>
+
+ <p>This document includes <i>[bracketed italicized notes]</i> as a
+ reminder to the LWG of current progress on issues. Such notes are
+ strictly unofficial and should be read with caution as they may be
+ incomplete or incorrect. Be aware that LWG support for a particular
+ resolution can quickly change if new viewpoints or killer examples are
+ presented in subsequent discussions.</p>
+
+ <p>For the most current official version of this document see
+ <a href="http://www.open-std.org/jtc1/sc22/wg21/">http://www.open-std.org/jtc1/sc22/wg21/</a>.
+ Requests for further information about this document should include
+ the document number above, reference ISO/IEC 14882:1998(E), and be
+ submitted to Information Technology Industry Council (ITI), 1250 Eye
+ Street NW, Washington, DC 20005.</p>
+
+ <p>Public information as to how to obtain a copy of the C++ Standard,
+ join the standards committee, submit an issue, or comment on an issue
+ can be found in the comp.std.c++ FAQ.
+ Public discussion of C++ Standard related issues occurs on <a href="news:comp.std.c++">news:comp.std.c++</a>.
+ </p>
+
+ <p>For committee members, files available on the committee's private
+ web site include the HTML version of the Standard itself. HTML
+ hyperlinks from this issues list to those files will only work for
+ committee members who have downloaded them into the same disk
+ directory as the issues list files. </p>
+
+<h2>Revision History</h2>
+<ul>
+<li>R59:
+2008-08-22 pre-San Francisco mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>192 open issues, up by 9.</li>
+<li>686 closed issues, up by 0.</li>
+<li>878 issues total, up by 9.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<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>
+</ul></li>
+</ul>
+</li>
+<li>R58:
+2008-07-28 mid-term mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>183 open issues, up by 12.</li>
+<li>686 closed issues, down by 4.</li>
+<li>869 issues total, up by 8.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<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>
+<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>
+<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>
+<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>
+<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>
+</ul></li>
+</ul>
+</li>
+<li>R57:
+2008-06-27 post-Sophia Antipolis mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>171 open issues, down by 20.</li>
+<li>690 closed issues, up by 43.</li>
+<li>861 issues total, up by 23.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#840">840</a>.</li>
+<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>
+<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#839">839</a>.</li>
+<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>
+<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#851">851</a>.</li>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+</ul></li>
+</ul>
+</li>
+<li>R56:
+2008-05-16 pre-Sophia Antipolis mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>191 open issues, up by 24.</li>
+<li>647 closed issues, up by 1.</li>
+<li>838 issues total, up by 25.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<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>
+<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>
+</ul></li>
+</ul>
+</li>
+<li>R55:
+2008-03-14 post-Bellevue mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>167 open issues, down by 39.</li>
+<li>646 closed issues, up by 65.</li>
+<li>813 issues total, up by 26.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<li>Added the following Dup issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a>.</li>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+</ul></li>
+</ul>
+</li>
+<li>R54:
+2008-02-01 pre-Bellevue mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>206 open issues, up by 23.</li>
+<li>581 closed issues, up by 0.</li>
+<li>787 issues total, up by 23.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+</ul></li>
+</ul>
+</li>
+<li>R53:
+2007-12-09 mid-term mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>183 open issues, up by 11.</li>
+<li>581 closed issues, down by 1.</li>
+<li>764 issues total, up by 10.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<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>
+<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>
+<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>
+</ul></li>
+</ul>
+</li>
+<li>R52:
+2007-10-19 post-Kona mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>172 open issues, up by 4.</li>
+<li>582 closed issues, up by 27.</li>
+<li>754 issues total, up by 31.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+</ul></li>
+</ul>
+</li>
+<li>R51:
+2007-09-09 pre-Kona mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>168 open issues, up by 15.</li>
+<li>555 closed issues, up by 0.</li>
+<li>723 issues total, up by 15.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<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>
+</ul></li>
+</ul>
+</li>
+<li>R50:
+2007-08-05 post-Toronto mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>153 open issues, down by 5.</li>
+<li>555 closed issues, up by 17.</li>
+<li>708 issues total, up by 12.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+</ul></li>
+</ul>
+</li>
+<li>R49:
+2007-06-23 pre-Toronto mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>158 open issues, up by 13.</li>
+<li>538 closed issues, up by 7.</li>
+<li>696 issues total, up by 20.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<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>
+<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>
+<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>
+<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>
+<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>
+</ul></li>
+</ul>
+</li>
+<li>R48:
+2007-05-06 post-Oxford mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>145 open issues, down by 33.</li>
+<li>531 closed issues, up by 53.</li>
+<li>676 issues total, up by 20.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+</ul></li>
+</ul>
+</li>
+<li>R47:
+2007-03-09 pre-Oxford mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>178 open issues, up by 37.</li>
+<li>478 closed issues, up by 0.</li>
+<li>656 issues total, up by 37.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+</ul></li>
+</ul>
+</li>
+<li>R46:
+2007-01-12 mid-term mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>141 open issues, up by 11.</li>
+<li>478 closed issues, down by 1.</li>
+<li>619 issues total, up by 10.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<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>
+</ul></li>
+</ul>
+</li>
+<li>R45:
+2006-11-03 post-Portland mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>130 open issues, up by 0.</li>
+<li>479 closed issues, up by 17.</li>
+<li>609 issues total, up by 17.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<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>
+<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>
+<li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Dup.</li>
+<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>
+<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>
+<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>
+<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>
+</ul></li>
+</ul>
+</li>
+<li>R44:
+2006-09-08 pre-Portland mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>130 open issues, up by 6.</li>
+<li>462 closed issues, down by 1.</li>
+<li>592 issues total, up by 5.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<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>
+</ul></li>
+</ul>
+</li>
+<li>R43:
+2006-06-23 mid-term mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>124 open issues, up by 14.</li>
+<li>463 closed issues, down by 1.</li>
+<li>587 issues total, up by 13.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<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>
+<li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#255">255</a>.</li>
+<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>
+</ul></li>
+</ul>
+</li>
+<li>R42:
+2006-04-21 post-Berlin mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>110 open issues, down by 16.</li>
+<li>464 closed issues, up by 24.</li>
+<li>574 issues total, up by 8.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<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>
+<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>
+<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>
+<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>
+<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>
+<li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li>
+</ul></li>
+</ul>
+</li>
+<li>R41:
+2006-02-24 pre-Berlin mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>126 open issues, up by 31.</li>
+<li>440 closed issues, up by 0.</li>
+<li>566 issues total, up by 31.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<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>
+<li>Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a> from Ready to Open.</li>
+<li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309">309</a>.</li>
+</ul></li>
+</ul>
+</li>
+<li>R40:
+2005-12-16 mid-term mailing.
+<ul>
+<li><b>Summary:</b><ul>
+<li>95 open issues.</li>
+<li>440 closed issues.</li>
+<li>535 issues total.</li>
+</ul></li>
+<li><b>Details:</b><ul>
+<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>
+</ul></li>
+</ul>
+</li>
+<li>R39:
+2005-10-14 post-Mont Tremblant mailing.
+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>.
+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.
+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.
+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.
+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.
+Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
+Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a> from New to Review.
+</li>
+<li>R38:
+2005-07-03 pre-Mont Tremblant mailing.
+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>.
+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>
+</li>
+<li>R37:
+2005-06 mid-term mailing.
+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>.
+</li>
+<li>R36:
+2005-04 post-Lillehammer mailing. All issues in "ready" status except
+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
+previously in "DR" status were moved to "WP".
+</li>
+<li>R35:
+2005-03 pre-Lillehammer mailing.
+</li>
+<li>R34:
+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>.
+</li>
+<li>R33:
+2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
+</li>
+<li>R32:
+2004-09 pre-Redmond mailing: reflects new proposed resolutions and
+new issues received after the 2004-07 mailing. Added
+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>.
+</li>
+<li>R31:
+2004-07 mid-term mailing: reflects new proposed resolutions and
+new issues received after the post-Sydney mailing. Added
+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>.
+</li>
+<li>R30:
+Post-Sydney mailing: reflects decisions made at the Sydney meeting.
+Voted all "Ready" issues from R29 into the working paper.
+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>.
+</li>
+<li>R29:
+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>.
+</li>
+<li>R28:
+Post-Kona mailing: reflects decisions made at the Kona meeting.
+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>.
+</li>
+<li>R27:
+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>.
+</li>
+<li>R26:
+Post-Oxford mailing: reflects decisions made at the Oxford meeting.
+All issues in Ready status were voted into DR status. All issues in
+DR status were voted into WP status.
+</li>
+<li>R25:
+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>.
+</li>
+<li>R24:
+Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
+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
+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
+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
+concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
+</li>
+<li>R23:
+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>.
+Moved issues in the TC to TC status.
+</li>
+<li>R22:
+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>.
+</li>
+<li>R21:
+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>.
+</li>
+<li>R20:
+Post-Redmond mailing; reflects actions taken in Redmond. Added
+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
+<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
+not discussed at the meeting.
+
+All Ready issues were moved to DR status, with the exception of issues
+<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>.
+
+Noteworthy issues discussed at Redmond include
+<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>,
+<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>.
+</li>
+<li>R19:
+Pre-Redmond mailing. Added new issues
+<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>.
+</li>
+<li>R18:
+Post-Copenhagen mailing; reflects actions taken in Copenhagen.
+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
+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>.
+
+Changed status of 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#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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>
+to DR.
+
+Changed status of 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#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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+<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>
+to Ready.
+
+Closed issues
+<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>
+<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>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
+as NAD.
+
+</li>
+<li>R17:
+Pre-Copenhagen mailing. Converted issues list to XML. Added proposed
+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>.
+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>.
+</li>
+<li>R16:
+post-Toronto mailing; reflects actions taken in Toronto. Added new
+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
+<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>,
+<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>,
+<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>,
+<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>,
+<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>,
+<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>,
+<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>,
+<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>,
+<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>,
+<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>,
+<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>,
+<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>,
+<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
+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
+<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
+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
+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
+the bug in enough places.
+</li>
+<li>R15:
+pre-Toronto mailing. Added issues
+<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
+changes so that we pass Weblint tests.
+</li>
+<li>R14:
+post-Tokyo II mailing; reflects committee actions taken in
+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)
+</li>
+<li>R13:
+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>.
+</li>
+<li>R12:
+pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to
+<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
+of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>. Add further rationale to issue
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>.
+</li>
+<li>R11:
+post-Kona mailing: Updated to reflect LWG and full committee actions
+in Kona (99-0048/N1224). Note changed resolution of issues
+<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>
+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
+"closed" documents. Changed the proposed resolution of issue
+<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
+of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>.
+</li>
+<li>R10:
+pre-Kona updated. Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</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#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>,
+<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
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
+</li>
+<li>R9:
+pre-Kona mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
+"closed" documents. (99-0030/N1206, 25 Aug 99)
+</li>
+<li>R8:
+post-Dublin mailing. Updated to reflect LWG and full committee actions
+in Dublin. (99-0016/N1193, 21 Apr 99)
+</li>
+<li>R7:
+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>,
+<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>,
+<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>,
+<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)
+</li>
+<li>R6:
+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>,
+and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>. (99-0007/N1194, 22 Feb 99)
+</li>
+<li>R5:
+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
+<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
+for making list public. (30 Dec 98)
+</li>
+<li>R4:
+post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</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-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#113">113</a> added, several
+issues corrected. (22 Oct 98)
+</li>
+<li>R3:
+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>
+added, many issues updated to reflect LWG consensus (12 Oct 98)
+</li>
+<li>R2:
+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,
+issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98)
+</li>
+<li>R1:
+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
+format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98)
+</li>
+</ul>
+
+<h2><a name="Status"></a>Issue Status</h2>
+
+ <p><b><a name="New">New</a></b> - The issue has not yet been
+ reviewed by the LWG. Any <b>Proposed Resolution</b> is purely a
+ suggestion from the issue submitter, and should not be construed as
+ the view of LWG.</p>
+
+ <p><b><a name="Open">Open</a></b> - The LWG has discussed the issue
+ but is not yet ready to move the issue forward. There are several
+ possible reasons for open status:</p>
+ <ul>
+ <li>Consensus may have not yet have been reached as to how to deal
+ with the issue.</li>
+ <li>Informal consensus may have been reached, but the LWG awaits
+ exact <b>Proposed Resolution</b> wording for review.</li>
+ <li>The LWG wishes to consult additional technical experts before
+ proceeding.</li>
+ <li>The issue may require further study.</li>
+ </ul>
+
+ <p>A <b>Proposed Resolution</b> for an open issue is still not be
+ construed as the view of LWG. Comments on the current state of
+ discussions are often given at the end of open issues in an italic
+ font. Such comments are for information only and should not be given
+ undue importance.</p>
+
+ <p><b><a name="Dup">Dup</a></b> - The LWG has reached consensus that
+ the issue is a duplicate of another issue, and will not be further
+ dealt with. A <b>Rationale</b> identifies the duplicated issue's
+ issue number. </p>
+
+ <p><b><a name="NAD">NAD</a></b> - The LWG has reached consensus that
+ the issue is not a defect in the Standard.</p>
+
+ <p><b><a name="NAD Editorial">NAD Editorial</a></b> - The LWG has reached consensus that
+ the issue can either be handled editorially, or is handled by a paper (usually
+ linked to in the rationale).</p>
+
+ <p><b><a name="NAD Future">NAD Future</a></b> - In addition to the regular
+ status, the LWG believes that this issue should be revisited at the
+ next revision of the standard.</p>
+
+ <p><b><a name="Review">Review</a></b> - Exact wording of a
+ <b>Proposed Resolution</b> is now available for review on an issue
+ for which the LWG previously reached informal consensus.</p>
+
+ <p><b><a name="Tentatively Ready">Tentatively Ready</a></b> - The issue has
+ been reviewed online, but not in a meeting, and some support has been formed
+ for the proposed resolution. Tentatively Ready issues may be moved to Ready
+ and forwarded to full committee within the same meeting. Unlike Ready issues
+ they will be reviewed in subcommittee prior to forwarding to full committee.</p>
+
+ <p><b><a name="Ready">Ready</a></b> - The LWG has reached consensus
+ that the issue is a defect in the Standard, the <b>Proposed
+ Resolution</b> is correct, and the issue is ready to forward to the
+ full committee for further action as a Defect Report (DR).</p>
+
+ <p><b><a name="DR">DR</a></b> - (Defect Report) - The full J16
+ committee has voted to forward the issue to the Project Editor to be
+ processed as a Potential Defect Report. The Project Editor reviews
+ the issue, and then forwards it to the WG21 Convenor, who returns it
+ to the full committee for final disposition. This issues list
+ accords the status of DR to all these Defect Reports regardless of
+ where they are in that process.</p>
+
+ <p><b><a name="TC">TC</a></b> - (Technical Corrigenda) - The full
+ WG21 committee has voted to accept the Defect Report's Proposed
+ Resolution as a Technical Corrigenda. Action on this issue is thus
+ complete and no further action is possible under ISO rules.</p>
+
+ <p><b><a name="TRDec">TRDec</a></b> - (Decimal TR defect) - The
+ LWG has voted to accept the Defect Report's Proposed
+ Resolution into the Decimal TR. Action on this issue is thus
+ complete and no further action is expected.</p>
+
+ <p><b><a name="WP">WP</a></b> - (Working Paper) - The proposed
+ resolution has not been accepted as a Technical Corrigendum, but
+ the full WG21 committee has voted to apply the Defect Report's Proposed
+ Resolution to the working paper.</p>
+
+ <p><b>Pending</b> - This is a <i>status qualifier</i>. When prepended to
+ a status this indicates the issue has been
+ processed by the committee, and a decision has been made to move the issue to
+ the associated unqualified status. However for logistical reasons the indicated
+ outcome of the issue has not yet appeared in the latest working paper.
+
+ </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
+ they first appear on the issues list. They may progress to
+ <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
+ is actively working on them. When the LWG has reached consensus on
+ the disposition of an issue, the status will then change to
+ <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
+ <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
+ forward Ready issues to the Project Editor, they are given the
+ 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
+ become the basis for Technical Corrigenda (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>),
+ or are closed without action other than a Record of Response
+ (<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
+ only issues which are truly defects in the Standard move to the
+ formal ISO DR status.
+ </p>
+
+
+<h2>Active Issues</h2>
+<hr>
+<h3><a name="23"></a>23. Num_get overflow result</h3>
+<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>
+ <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>The current description of numeric input does not account for the
+possibility of overflow. This is an implicit result of changing the
+description to rely on the definition of scanf() (which fails to
+report overflow), and conflicts with the documented behavior of
+traditional and current implementations. </p>
+
+<p>Users expect, when reading a character sequence that results in a
+value unrepresentable in the specified type, to have an error
+reported. The standard as written does not permit this. </p>
+
+<p><b>Further comments from Dietmar:</b></p>
+
+<p>
+I don't feel comfortable with the proposed resolution to issue 23: It
+kind of simplifies the issue to much. Here is what is going on:
+</p>
+
+<p>
+Currently, the behavior of numeric overflow is rather counter intuitive
+and hard to trace, so I will describe it briefly:
+</p>
+
+<ul>
+ <li>
+ According to 22.2.2.1.2 [facet.num.get.virtuals]
+ paragraph 11 <tt>failbit</tt> is set if <tt>scanf()</tt> would
+ return an input error; otherwise a value is converted to the rules
+ of <tt>scanf</tt>.
+ </li>
+ <li>
+ <tt>scanf()</tt> is defined in terms of <tt>fscanf()</tt>.
+ </li>
+ <li>
+ <tt>fscanf()</tt> returns an input failure if during conversion no
+ character matching the conversion specification could be extracted
+ before reaching EOF. This is the only reason for <tt>fscanf()</tt>
+ to fail due to an input error and clearly does not apply to the case
+ of overflow.
+ </li>
+ <li>
+ Thus, the conversion is performed according to the rules of
+ <tt>fscanf()</tt> which basically says that <tt>strtod</tt>,
+ <tt>strtol()</tt>, etc. are to be used for the conversion.
+ </li>
+ <li>
+ The <tt>strtod()</tt>, <tt>strtol()</tt>, etc. functions consume as
+ many matching characters as there are and on overflow continue to
+ consume matching characters but also return a value identical to
+ the maximum (or minimum for signed types if there was a leading minus)
+ value of the corresponding type and set <tt>errno</tt> to <tt>ERANGE</tt>.
+ </li>
+ <li>
+ Thus, according to the current wording in the standard, overflows
+ can be detected! All what is to be done is to check <tt>errno</tt>
+ after reading an element and, of course, clearing <tt>errno</tt>
+ before trying a conversion. With the current wording, it can be
+ detected whether the overflow was due to a positive or negative
+ number for signed types.
+ </li>
+</ul>
+
+<p><b>Further discussion from Redmond:</b></p>
+
+<p>The basic problem is that we've defined our behavior,
+including our error-reporting behavior, in terms of C90. However,
+C90's method of reporting overflow in scanf is not technically an
+"input error". The <tt>strto_*</tt> functions are more precise.</p>
+
+<p>There was general consensus that <tt>failbit</tt> should be set
+upon overflow. We considered three options based on this:</p>
+<ol>
+<li>Set failbit upon conversion error (including overflow), and
+ don't store any value.</li>
+<li>Set failbit upon conversion error, and also set <tt>errno</tt> to
+ indicated the precise nature of the error.</li>
+<li>Set failbit upon conversion error. If the error was due to
+ overflow, store +-numeric_limits<T>::max() as an
+ overflow indication.</li>
+</ol>
+
+<p>Straw poll: (1) 5; (2) 0; (3) 8.</p>
+
+
+<p>Discussed at Lillehammer. General outline of what we want the
+ solution to look like: we want to say that overflow is an error, and
+ provide a way to distinguish overflow from other kinds of errors.
+ Choose candidate field the same way scanf does, but don't describe
+ the rest of the process in terms of format. If a finite input field
+ is too large (positive or negative) to be represented as a finite
+ value, then set failbit and assign the nearest representable value.
+ Bill will provide wording.</p>
+
+<p>
+Discussed at Toronto:
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2327.pdf">N2327</a>
+is in alignment with the direction we wanted to go with in Lillehammer. Bill
+to work on.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+Change 22.2.2.1.2 [facet.num.get.virtuals], end of p3:
+</p>
+
+<blockquote>
+<p>
+<b>Stage 3:</b> <del>The result of stage 2 processing can be one of</del>
+<ins>The sequence of <tt>char</tt>s accumulated in stage 2 (the field) is
+converted to a numeric value by the rules of one of the functions declared
+in the header <tt><cstdlib></tt>:</ins>
+</p>
+<ul>
+<li>
+<del>A sequence of <tt>char</tt>s has been accumulated in stage 2 that is
+converted (according to the rules of <tt>scanf</tt>) to a value of the
+type of <i>val</i>. This value is stored in <i>val</i> and <tt>ios_base::goodbit</tt> is
+stored in <i>err</i>.</del>
+<ins>For a signed integer value, the function <tt>strtoll</tt>.</ins>
+</li>
+<li>
+<del>The sequence of <tt>char</tt>s accumulated in stage 2 would have caused
+<tt>scanf</tt> to report an input failure. <tt>ios_base::failbit</tt> is
+assigned to <i>err</i>.</del>
+<ins>For an unsigned integer value, the function <tt>strtoull</tt>.</ins>
+</li>
+<li>
+<ins>For a floating-point value, the function <tt>strtold</tt>.</ins>
+</li>
+</ul>
+<p>
+<ins>The numeric value to be stored can be one of:</ins>
+</p>
+<ul>
+<li><ins>zero, if the conversion function fails to convert the entire field.
+<tt>ios_base::failbit</tt> is assigned to err.</ins></li>
+<li><ins>the most positive representable value, if the field represents a value
+too large positive to be represented in <i>val</i>. <tt>ios_base::failbit</tt> is assigned
+to <i>err</i>.</ins></li>
+<li><ins>the most negative representable value (zero for unsigned integer), if
+the field represents a value too large negative to be represented in <i>val</i>.
+<tt>ios_base::failbit</tt> is assigned to <i>err</i>.</ins></li>
+<li><ins>the converted value, otherwise.</ins></li>
+</ul>
+
+<p><ins>
+The resultant numeric value is stored in <i>val</i>.
+</ins></p>
+</blockquote>
+
+<p>
+Change 22.2.2.1.2 [facet.num.get.virtuals], p6-p7:
+</p>
+
+<blockquote>
+<pre>iter_type do_get(iter_type <i>in</i>, iter_type <i>end</i>, ios_base& <i>str</i>,
+ ios_base::iostate& <i>err</i>, bool& <i>val</i>) const;
+</pre>
+<blockquote>
+<p>
+-6- <i>Effects:</i> If
+<tt>(<i>str</i>.flags()&ios_base::boolalpha)==0</tt> then input
+proceeds as it would for a <tt>long</tt> except that if a value is being
+stored into <i>val</i>, the value is determined according to the
+following: If the value to be stored is 0 then <tt>false</tt> is stored.
+If the value is 1 then <tt>true</tt> is stored. Otherwise
+<del><tt><i>err</i>|=ios_base::failbit</tt> is performed and no value</del> <ins><tt>true</tt></ins> is
+stored<del>.</del> <ins>and <tt>ios_base::failbit</tt> is assigned to <i>err</i>.</ins>
+</p>
+<p>
+-7- Otherwise target sequences are determined "as if" by calling the
+members <tt>falsename()</tt> and <tt>truename()</tt> of the facet
+obtained by <tt>use_facet<numpunct<charT>
+>(<i>str</i>.getloc())</tt>. Successive characters in the range
+<tt>[<i>in</i>,<i>end</i>)</tt> (see 23.1.1) are obtained and matched
+against corresponding positions in the target sequences only as
+necessary to identify a unique match. The input iterator <i>in</i> is
+compared to <i>end</i> only when necessary to obtain a character. If <del>and
+only if</del> a target sequence is uniquely matched, <i>val</i> is set to the
+corresponding value. <ins>Otherwise <tt>false</tt> is stored and <tt>ios_base::failbit</tt>
+is assigned to <i>err</i>.</ins>
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="96"></a>96. Vector<bool> is not a container</h3>
+<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>
+ <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p><tt>vector<bool></tt> is not a container as its reference and
+pointer types are not references and pointers. </p>
+
+<p>Also it forces everyone to have a space optimization instead of a
+speed one.</p>
+
+<p><b>See also:</b> 99-0008 == N1185 Vector<bool> is
+Nonconforming, Forces Optimization Choice.</p>
+
+<p><i>[In Santa Cruz the LWG felt that this was Not A Defect.]</i></p>
+
+
+<p><i>[In Dublin many present felt that failure to meet Container
+requirements was a defect. There was disagreement as to whether
+or not the optimization requirements constituted a defect.]</i></p>
+
+
+<p><i>[The LWG looked at the following resolutions in some detail:
+<br>
+ * Not A Defect.<br>
+ * Add a note explaining that vector<bool> does not meet
+Container requirements.<br>
+ * Remove vector<bool>.<br>
+ * Add a new category of container requirements which
+vector<bool> would meet.<br>
+ * Rename vector<bool>.<br>
+<br>
+No alternative had strong, wide-spread, support and every alternative
+had at least one "over my dead body" response.<br>
+<br>
+There was also mention of a transition scheme something like (1) add
+vector_bool and deprecate vector<bool> in the next standard. (2)
+Remove vector<bool> in the following standard.]</i></p>
+
+
+<p><i>[Modifying container requirements to permit returning proxies
+(thus allowing container requirements conforming vector<bool>)
+was also discussed.]</i></p>
+
+
+<p><i>[It was also noted that there is a partial but ugly workaround in
+that vector<bool> may be further specialized with a customer
+allocator.]</i></p>
+
+
+<p><i>[Kona: Herb Sutter presented his paper J16/99-0035==WG21/N1211,
+vector<bool>: More Problems, Better Solutions. Much discussion
+of a two step approach: a) deprecate, b) provide replacement under a
+new name. LWG straw vote on that: 1-favor, 11-could live with, 2-over
+my dead body. This resolution was mentioned in the LWG report to the
+full committee, where several additional committee members indicated
+over-my-dead-body positions.]</i></p>
+
+
+<p>Discussed at Lillehammer. General agreement that we should
+ deprecate vector<bool> and introduce this functionality under
+ a different name, e.g. bit_vector. This might make it possible to
+ remove the vector<bool> specialization in the standard that comes
+ after C++0x. There was also a suggestion that
+ in C++0x we could additional say that it's implementation defined
+ whether vector<bool> refers to the specialization or to the
+ primary template, but there wasn't general agreement that this was a
+ good idea.</p>
+
+<p>We need a paper for the new bit_vector class.</p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+We now have:
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2050.pdf">N2050</a>
+and
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2160.html">N2160</a>.
+</p>
+
+<p><i>[
+Batavia: The LWG feels we need something closer to SGI's <tt>bitvector</tt> to ease migration
+from <tt>vector<bool></tt>. Although some of the funcitonality from
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2050.pdf">N2050</a>
+could well be used in such a template. The concern is easing the API migration for those
+users who want to continue using a bit-packed container. Alan and Beman to work.
+]</i></p>
+
+
+
+
+
+
+<hr>
+<h3><a name="128"></a>128. Need open_mode() function for file stream, string streams, file buffers, and string buffers</h3>
+<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>
+ <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-02-22</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>The following question came from Thorsten Herlemann:</p>
+
+<blockquote>
+ <p>You can set a mode when constructing or opening a file-stream or
+ filebuf, e.g. ios::in, ios::out, ios::binary, ... But how can I get
+ that mode later on, e.g. in my own operator << or operator
+ >> or when I want to check whether a file-stream or
+ file-buffer object passed as parameter is opened for input or output
+ or binary? Is there no possibility? Is this a design-error in the
+ standard C++ library? </p>
+</blockquote>
+
+<p>It is indeed impossible to find out what a stream's or stream
+buffer's open mode is, and without that knowledge you don't know
+how certain operations behave. Just think of the append mode. </p>
+
+<p>Both streams and stream buffers should have a <tt>mode()</tt> function that returns the
+current open mode setting. </p>
+
+<p><i>[
+post Bellevue: Alisdair requested to re-Open.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>For stream buffers, add a function to the base class as a non-virtual function
+qualified as const to 27.5.2 [streambuf]:</p>
+
+<p> <tt>openmode mode() const</tt>;</p>
+
+<p><b> Returns</b> the current open mode.</p>
+
+<p>With streams, I'm not sure what to suggest. In principle, the mode
+could already be returned by <tt>ios_base</tt>, but the mode is only
+initialized for file and string stream objects, unless I'm overlooking
+anything. For this reason it should be added to the most derived
+stream classes. Alternatively, it could be added to <tt>basic_ios</tt>
+and would be default initialized in <tt>basic_ios<>::init()</tt>.</p>
+
+
+<p><b>Rationale:</b></p>
+<p>This might be an interesting extension for some future, but it is
+not a defect in the current standard. The Proposed Resolution is
+retained for future reference.</p>
+
+
+
+
+
+<hr>
+<h3><a name="180"></a>180. Container member iterator arguments constness has unintended consequences</h3>
+<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>
+ <b>Submitter:</b> Dave Abrahams <b>Date:</b> 1999-07-01</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>It is the constness of the container which should control whether
+it can be modified through a member function such as erase(), not the
+constness of the iterators. The iterators only serve to give
+positioning information.</p>
+
+<p>Here's a simple and typical example problem which is currently very
+difficult or impossible to solve without the change proposed
+below.</p>
+
+<p>Wrap a standard container C in a class W which allows clients to
+find and read (but not modify) a subrange of (C.begin(), C.end()]. The
+only modification clients are allowed to make to elements in this
+subrange is to erase them from C through the use of a member function
+of W.</p>
+
+<p><i>[
+post Bellevue, Alisdair adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+This issue was implemented by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2350.pdf">N2350</a>
+for everything but <tt>basic_string</tt>.
+</p>
+
+<p>
+Note that the specific example in this issue (<tt>basic_string</tt>) is the one place
+we forgot to amend in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2350.pdf">N2350</a>,
+so we might open this issue for that
+single container?
+</p>
+</blockquote>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+This was a fix that was intended for all standard library containers,
+and has been done for other containers, but string was missed.
+</p>
+<p>
+The wording updated.
+</p>
+<p>
+We did not make the change in <tt>replace</tt>, because this change would affect
+the implementation because the string may be written into. This is an
+issue that should be taken up by concepts.
+</p>
+<p>
+We note that the supplied wording addresses the initializer list provided in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2679.pdf">N2679</a>.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Update the following signature in the <tt>basic_string</tt> class template definition in
+21.3 [basic.string], p5:
+</p>
+<blockquote><pre>namespace std {
+ template<class charT, class traits = char_traits<charT>,
+ class Allocator = allocator<charT> >
+ class basic_string {
+
+ ...
+
+ iterator insert(<ins>const_</ins>iterator p, charT c);
+ void insert(<ins>const_</ins>iterator p, size_type n, charT c);
+ template<class InputIterator>
+ void insert(<ins>const_</ins>iterator p, InputIterator first, InputIterator last);
+ void insert(<ins>const_</ins>iterator <ins>p</ins>, initializer_list<charT>);
+
+ ...
+
+ iterator erase(<ins>const_</ins>iterator <ins>const_</ins>position);
+ iterator erase(<ins>const_</ins>iterator first, <ins>const_</ins>iterator last);
+
+ ...
+
+ };
+}
+</pre></blockquote>
+
+<p>
+Update the following signatures in 21.3.6.4 [string::insert]:
+</p>
+
+<blockquote><pre>iterator insert(<ins>const_</ins>iterator p, charT c);
+void insert(<ins>const_</ins>iterator p, size_type n, charT c);
+template<class InputIterator>
+ void insert(<ins>const_</ins>iterator p, InputIterator first, InputIterator last);
+void insert(<ins>const_</ins>iterator <ins>p</ins>, initializer_list<charT>);
+</pre></blockquote>
+
+<p>
+Update the following signatures in 21.3.6.5 [string::erase]:
+</p>
+
+<blockquote><pre>iterator erase(<ins>const_</ins>iterator <ins>const_</ins>position);
+iterator erase(<ins>const_</ins>iterator first, <ins>const_</ins>iterator last);
+</pre></blockquote>
+
+
+
+<p><b>Rationale:</b></p>
+<p>The issue was discussed at length. It was generally agreed that 1)
+There is no major technical argument against the change (although
+there is a minor argument that some obscure programs may break), and
+2) Such a change would not break const correctness. The concerns about
+making the change were 1) it is user detectable (although only in
+boundary cases), 2) it changes a large number of signatures, and 3) it
+seems more of a design issue that an out-and-out defect.</p>
+
+<p>The LWG believes that this issue should be considered as part of a
+general review of const issues for the next revision of the
+standard. Also see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>.</p>
+
+
+
+
+<hr>
+<h3><a name="190"></a>190. min() and max() functions should be std::binary_functions</h3>
+<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>
+ <b>Submitter:</b> Mark Rintoul <b>Date:</b> 1999-08-26</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>Both std::min and std::max are defined as template functions. This
+is very different than the definition of std::plus (and similar
+structs) which are defined as function objects which inherit
+std::binary_function.<br>
+<br>
+ This lack of inheritance leaves std::min and std::max somewhat useless in standard library algorithms which require
+a function object that inherits std::binary_function.</p>
+
+<p><i>[
+post Bellevue: Alisdair requested to re-Open.
+]</i></p>
+
+
+
+
+<p><b>Rationale:</b></p>
+<p>Although perhaps an unfortunate design decision, the omission is not a defect
+in the current standard. A future standard may wish to consider additional
+function objects.</p>
+
+
+
+
+<hr>
+<h3><a name="255"></a>255. Why do <tt>basic_streambuf<>::pbump()</tt> and <tt>gbump()</tt> take an int?</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-08-12</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The basic_streambuf members gbump() and pbump() are specified to take an
+int argument. This requirement prevents the functions from effectively
+manipulating buffers larger than std::numeric_limits<int>::max()
+characters. It also makes the common use case for these functions
+somewhat difficult as many compilers will issue a warning when an
+argument of type larger than int (such as ptrdiff_t on LLP64
+architectures) is passed to either of the function. Since it's often the
+result of the subtraction of two pointers that is passed to the
+functions, a cast is necessary to silence such warnings. Finally, the
+usage of a native type in the functions signatures is inconsistent with
+other member functions (such as sgetn() and sputn()) that manipulate the
+underlying character buffer. Those functions take a streamsize argument.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the signatures of these functions in the synopsis of template
+class basic_streambuf (27.5.2) and in their descriptions (27.5.2.3.1, p4
+and 27.5.2.3.2, p4) to take a streamsize argument.
+</p>
+
+<p>
+Although this change has the potential of changing the ABI of the
+library, the change will affect only platforms where int is different
+than the definition of streamsize. However, since both functions are
+typically inline (they are on all known implementations), even on such
+platforms the change will not affect any user code unless it explicitly
+relies on the existing type of the functions (e.g., by taking their
+address). Such a possibility is IMO quite remote.
+</p>
+
+<p>
+Alternate Suggestion from Howard Hinnant, c++std-lib-7780:
+</p>
+
+<p>
+This is something of a nit, but I'm wondering if streamoff wouldn't be a
+better choice than streamsize. The argument to pbump and gbump MUST be
+signed. But the standard has this to say about streamsize
+(27.4.1/2/Footnote):
+</p>
+
+<blockquote><p>
+ [Footnote: streamsize is used in most places where ISO C would use
+ size_t. Most of the uses of streamsize could use size_t, except for
+ the strstreambuf constructors, which require negative values. It
+ should probably be the signed type corresponding to size_t (which is
+ what Posix.2 calls ssize_t). --- end footnote]
+</p></blockquote>
+
+<p>
+This seems a little weak for the argument to pbump and gbump. Should we
+ever really get rid of strstream, this footnote might go with it, along
+with the reason to make streamsize signed.
+</p>
+
+
+<p><b>Rationale:</b></p>
+<p>The LWG believes this change is too big for now. We may wish to
+reconsider this for a future revision of the standard. One
+possibility is overloading pbump, rather than changing the
+signature.</p>
+<p><i>[
+[2006-05-04: Reopened at the request of Chris (Krzysztof ?elechowski)]
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="290"></a>290. Requirements to for_each and its function object</h3>
+<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>
+ <b>Submitter:</b> Angelika Langer <b>Date:</b> 2001-01-03</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>The specification of the for_each algorithm does not have a
+"Requires" section, which means that there are no
+restrictions imposed on the function object whatsoever. In essence it
+means that I can provide any function object with arbitrary side
+effects and I can still expect a predictable result. In particular I
+can expect that the function object is applied exactly last - first
+times, which is promised in the "Complexity" section.
+</p>
+
+<p>I don't see how any implementation can give such a guarantee
+without imposing requirements on the function object.
+</p>
+
+<p>Just as an example: consider a function object that removes
+elements from the input sequence. In that case, what does the
+complexity guarantee (applies f exactly last - first times) mean?
+</p>
+
+<p>One can argue that this is obviously a nonsensical application and
+a theoretical case, which unfortunately it isn't. I have seen
+programmers shooting themselves in the foot this way, and they did not
+understand that there are restrictions even if the description of the
+algorithm does not say so.
+</p>
+<p><i>[Lillehammer: This is more general than for_each. We don't want
+ the function object in transform invalidiating iterators
+ either. There should be a note somewhere in clause 17 (17, not 25)
+ saying that user code operating on a range may not invalidate
+ iterators unless otherwise specified. Bill will provide wording.]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+
+<hr>
+<h3><a name="299"></a>299. Incorrect return types for iterator dereference</h3>
+<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>
+ <b>Submitter:</b> John Potter <b>Date:</b> 2001-01-22</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+In section 24.1.4 [bidirectional.iterators],
+Table 75 gives the return type of *r-- as convertible to T. This is
+not consistent with Table 74 which gives the return type of *r++ as
+T&. *r++ = t is valid while *r-- = t is invalid.
+</p>
+
+<p>
+In section 24.1.5 [random.access.iterators],
+Table 76 gives the return type of a[n] as convertible to T. This is
+not consistent with the semantics of *(a + n) which returns T& by
+Table 74. *(a + n) = t is valid while a[n] = t is invalid.
+</p>
+
+<p>
+Discussion from the Copenhagen meeting: the first part is
+uncontroversial. The second part, operator[] for Random Access
+Iterators, requires more thought. There are reasonable arguments on
+both sides. Return by value from operator[] enables some potentially
+useful iterators, e.g. a random access "iota iterator" (a.k.a
+"counting iterator" or "int iterator"). There isn't any obvious way
+to do this with return-by-reference, since the reference would be to a
+temporary. On the other hand, <tt>reverse_iterator</tt> takes an
+arbitrary Random Access Iterator as template argument, and its
+operator[] returns by reference. If we decided that the return type
+in Table 76 was correct, we would have to change
+<tt>reverse_iterator</tt>. This change would probably affect user
+code.
+</p>
+
+<p>
+History: the contradiction between <tt>reverse_iterator</tt> and the
+Random Access Iterator requirements has been present from an early
+stage. In both the STL proposal adopted by the committee
+(N0527==94-0140) and the STL technical report (HPL-95-11 (R.1), by
+Stepanov and Lee), the Random Access Iterator requirements say that
+operator[]'s return value is "convertible to T". In N0527
+reverse_iterator's operator[] returns by value, but in HPL-95-11
+(R.1), and in the STL implementation that HP released to the public,
+reverse_iterator's operator[] returns by reference. In 1995, the
+standard was amended to reflect the contents of HPL-95-11 (R.1). The
+original intent for operator[] is unclear.
+</p>
+
+<p>
+In the long term it may be desirable to add more fine-grained
+iterator requirements, so that access method and traversal strategy
+can be decoupled. (See "Improved Iterator Categories and
+Requirements", N1297 = 01-0011, by Jeremy Siek.) Any decisions
+about issue 299 should keep this possibility in mind.
+</p>
+
+<p>Further discussion: I propose a compromise between John Potter's
+resolution, which requires <tt>T&</tt> as the return type of
+<tt>a[n]</tt>, and the current wording, which requires convertible to
+<tt>T</tt>. The compromise is to keep the convertible to <tt>T</tt>
+for the return type of the expression <tt>a[n]</tt>, but to also add
+<tt>a[n] = t</tt> as a valid expression. This compromise "saves" the
+common case uses of random access iterators, while at the same time
+allowing iterators such as counting iterator and caching file
+iterators to remain random access iterators (iterators where the
+lifetime of the object returned by <tt>operator*()</tt> is tied to the
+lifetime of the iterator).
+</p>
+
+<p>
+Note that the compromise resolution necessitates a change to
+<tt>reverse_iterator</tt>. It would need to use a proxy to support
+<tt>a[n] = t</tt>.
+</p>
+
+<p>
+Note also there is one kind of mutable random access iterator that
+will no longer meet the new requirements. Currently, iterators that
+return an r-value from <tt>operator[]</tt> meet the requirements for a
+mutable random access iterartor, even though the expression <tt>a[n] =
+t</tt> will only modify a temporary that goes away. With this proposed
+resolution, <tt>a[n] = t</tt> will be required to have the same
+operational semantics as <tt>*(a + n) = t</tt>.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+In section 24.1.4 [lib.bidirectdional.iterators], change the return
+type in table 75 from "convertible to <tt>T</tt>" to
+<tt>T&</tt>.
+</p>
+
+<p>
+In section 24.1.5 [lib.random.access.iterators], change the
+operational semantics for <tt>a[n]</tt> to " the r-value of
+<tt>a[n]</tt> is equivalent to the r-value of <tt>*(a +
+n)</tt>". Add a new row in the table for the expression <tt>a[n] = t</tt>
+with a return type of convertible to <tt>T</tt> and operational semantics of
+<tt>*(a + n) = t</tt>.
+</p>
+
+<p><i>[Lillehammer: Real problem, but should be addressed as part of
+ iterator redesign]</i></p>
+
+
+
+
+
+
+
+
+<hr>
+<h3><a name="309"></a>309. Does sentry catch exceptions?</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-03-19</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The descriptions of the constructors of basic_istream<>::sentry
+(27.6.1.1.3 [istream::sentry]) and basic_ostream<>::sentry
+(27.6.2.4 [ostream::sentry]) do not explain what the functions do in
+case an exception is thrown while they execute. Some current
+implementations allow all exceptions to propagate, others catch them
+and set ios_base::badbit instead, still others catch some but let
+others propagate.
+</p>
+
+<p>
+The text also mentions that the functions may call setstate(failbit)
+(without actually saying on what object, but presumably the stream
+argument is meant). That may have been fine for
+basic_istream<>::sentry prior to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>, since
+the function performs an input operation which may fail. However,
+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
+clarify that the function should actually call setstate(failbit |
+eofbit), so the sentence in p3 is redundant or even somewhat
+contradictory.
+</p>
+
+<p>
+The same sentence that appears in 27.6.2.4 [ostream::sentry], p3
+doesn't seem to be very meaningful for basic_istream<>::sentry
+which performs no input. It is actually rather misleading since it
+would appear to guide library implementers to calling
+setstate(failbit) when os.tie()->flush(), the only called function,
+throws an exception (typically, it's badbit that's set in response to
+such an event).
+</p>
+
+<p><b>Additional comments from Martin, who isn't comfortable with the
+ current proposed resolution</b> (see c++std-lib-11530)</p>
+
+<p>
+The istream::sentry ctor says nothing about how the function
+deals with exemptions (27.6.1.1.2, p1 says that the class is
+responsible for doing "exception safe"(*) prefix and suffix
+operations but it doesn't explain what level of exception
+safety the class promises to provide). The mockup example
+of a "typical implementation of the sentry ctor" given in
+27.6.1.1.2, p6, removed in ISO/IEC 14882:2003, doesn't show
+exception handling, either. Since the ctor is not classified
+as a formatted or unformatted input function, the text in
+27.6.1.1, p1 through p4 does not apply. All this would seem
+to suggest that the sentry ctor should not catch or in any
+way handle exceptions thrown from any functions it may call.
+Thus, the typical implementation of an istream extractor may
+look something like [1].
+</p>
+
+<p>
+The problem with [1] is that while it correctly sets ios::badbit
+if an exception is thrown from one of the functions called from
+the sentry ctor, if the sentry ctor reaches EOF while extracting
+whitespace from a stream that has eofbit or failbit set in
+exceptions(), it will cause an ios::failure to be thrown, which
+will in turn cause the extractor to set ios::badbit.
+</p>
+
+<p>
+The only straightforward way to prevent this behavior is to
+move the definition of the sentry object in the extractor
+above the try block (as suggested by the example in 22.2.8,
+p9 and also indirectly supported by 27.6.1.3, p1). See [2].
+But such an implementation will allow exceptions thrown from
+functions called from the ctor to freely propagate to the
+caller regardless of the setting of ios::badbit in the stream
+object's exceptions().
+</p>
+
+<p>
+So since neither [1] nor [2] behaves as expected, the only
+possible solution is to have the sentry ctor catch exceptions
+thrown from called functions, set badbit, and propagate those
+exceptions if badbit is also set in exceptions(). (Another
+solution exists that deals with both kinds of sentries, but
+the code is non-obvious and cumbersome -- see [3].)
+</p>
+
+<p>
+Please note that, as the issue points out, current libraries
+do not behave consistently, suggesting that implementors are
+not quite clear on the exception handling in istream::sentry,
+despite the fact that some LWG members might feel otherwise.
+(As documented by the parenthetical comment here:
+http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1480.html#309)
+</p>
+
+<p>
+Also please note that those LWG members who in Copenhagen
+felt that "a sentry's constructor should not catch exceptions,
+because sentries should only be used within (un)formatted input
+functions and that exception handling is the responsibility of
+those functions, not of the sentries," as noted here
+http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1310.html#309
+would in effect be either arguing for the behavior described
+in [1] or for extractors implemented along the lines of [3].
+</p>
+
+<p>
+The original proposed resolution (Revision 25 of the issues
+list) clarifies the role of the sentry ctor WRT exception
+handling by making it clear that extractors (both library
+or user-defined) should be implemented along the lines of
+[2] (as opposed to [1]) and that no exception thrown from
+the callees should propagate out of either function unless
+badbit is also set in exceptions().
+</p>
+
+
+<p>[1] Extractor that catches exceptions thrown from sentry:</p>
+
+<blockquote>
+<pre>struct S { long i; };
+
+istream& operator>> (istream &strm, S &s)
+{
+ ios::iostate err = ios::goodbit;
+ try {
+ const istream::sentry guard (strm, false);
+ if (guard) {
+ use_facet<num_get<char> >(strm.getloc ())
+ .get (istreambuf_iterator<char>(strm),
+ istreambuf_iterator<char>(),
+ strm, err, s.i);
+ }
+ }
+ catch (...) {
+ bool rethrow;
+ try {
+ strm.setstate (ios::badbit);
+ rethrow = false;
+ }
+ catch (...) {
+ rethrow = true;
+ }
+ if (rethrow)
+ throw;
+ }
+ if (err)
+ strm.setstate (err);
+ return strm;
+}
+</pre>
+</blockquote>
+
+<p>[2] Extractor that propagates exceptions thrown from sentry:</p>
+
+<blockquote>
+<pre>istream& operator>> (istream &strm, S &s)
+{
+ istream::sentry guard (strm, false);
+ if (guard) {
+ ios::iostate err = ios::goodbit;
+ try {
+ use_facet<num_get<char> >(strm.getloc ())
+ .get (istreambuf_iterator<char>(strm),
+ istreambuf_iterator<char>(),
+ strm, err, s.i);
+ }
+ catch (...) {
+ bool rethrow;
+ try {
+ strm.setstate (ios::badbit);
+ rethrow = false;
+ }
+ catch (...) {
+ rethrow = true;
+ }
+ if (rethrow)
+ throw;
+ }
+ if (err)
+ strm.setstate (err);
+ }
+ return strm;
+}
+</pre>
+</blockquote>
+
+<p>
+[3] Extractor that catches exceptions thrown from sentry
+but doesn't set badbit if the exception was thrown as a
+result of a call to strm.clear().
+</p>
+
+<blockquote>
+<pre>istream& operator>> (istream &strm, S &s)
+{
+ const ios::iostate state = strm.rdstate ();
+ const ios::iostate except = strm.exceptions ();
+ ios::iostate err = std::ios::goodbit;
+ bool thrown = true;
+ try {
+ const istream::sentry guard (strm, false);
+ thrown = false;
+ if (guard) {
+ use_facet<num_get<char> >(strm.getloc ())
+ .get (istreambuf_iterator<char>(strm),
+ istreambuf_iterator<char>(),
+ strm, err, s.i);
+ }
+ }
+ catch (...) {
+ if (thrown && state & except)
+ throw;
+ try {
+ strm.setstate (ios::badbit);
+ thrown = false;
+ }
+ catch (...) {
+ thrown = true;
+ }
+ if (thrown)
+ throw;
+ }
+ if (err)
+ strm.setstate (err);
+
+ return strm;
+}
+</pre>
+</blockquote>
+
+<p>
+[Pre-Berlin] Reopened at the request of Paolo Carlini and Steve Clamage.
+</p>
+
+<p>
+[Pre-Portland] A relevant newsgroup post:
+</p>
+
+<p>
+The current proposed resolution of issue #309
+(http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309) is
+unacceptable. I write commerical software and coding around this
+makes my code ugly, non-intuitive, and requires comments referring
+people to this very issue. Following is the full explanation of my
+experience.
+</p>
+<p>
+In the course of writing software for commercial use, I constructed
+std::ifstream's based on user-supplied pathnames on typical POSIX
+systems.
+</p>
+<p>
+It was expected that some files that opened successfully might not read
+successfully -- such as a pathname which actually refered to a
+directory. Intuitively, I expected the streambuffer underflow() code
+to throw an exception in this situation, and recent implementations of
+libstdc++'s basic_filebuf do just that (as well as many of my own
+custom streambufs).
+</p>
+<p>
+I also intuitively expected that the istream code would convert these
+exceptions to the "badbit' set on the stream object, because I had not
+requested exceptions. I refer to 27.6.1.1. P4.
+</p>
+<p>
+However, this was not the case on at least two implementations -- if
+the first thing I did with an istream was call operator>>( T& ) for T
+among the basic arithmetic types and std::string. Looking further I
+found that the sentry's constructor was invoking the exception when it
+pre-scanned for whitespace, and the extractor function (operator>>())
+was not catching exceptions in this situation.
+</p>
+<p>
+So, I was in a situation where setting 'noskipws' would change the
+istream's behavior even though no characters (whitespace or not) could
+ever be successfully read.
+</p>
+<p>
+Also, calling .peek() on the istream before calling the extractor()
+changed the behavior (.peek() had the effect of setting the badbit
+ahead of time).
+</p>
+<p>
+I found this all to be so inconsistent and inconvenient for me and my
+code design, that I filed a bugzilla entry for libstdc++. I was then
+told that the bug cannot be fixed until issue #309 is resolved by the
+committee.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+<p><b>Rationale:</b></p>
+<p>The LWG agrees there is minor variation between implementations,
+ but believes that it doesn't matter. This is a rarely used corner
+ case. There is no evidence that this has any commercial importance
+ or that it causes actual portability problems for customers trying
+ to write code that runs on multiple implementations.</p>
+
+
+
+
+
+<hr>
+<h3><a name="342"></a>342. seek and eofbit</h3>
+<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>
+ <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2001-10-09</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>I think we have a defect.</p>
+
+<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
+description of seekg in 27.6.1.3 [istream.unformatted] paragraph 38 now looks
+like:</p>
+
+<blockquote><p>
+Behaves as an unformatted input function (as described in 27.6.1.3,
+paragraph 1), except that it does not count the number of characters
+extracted and does not affect the value returned by subsequent calls to
+gcount(). After constructing a sentry object, if fail() != true,
+executes rdbuf()->pubseekpos( pos).
+</p></blockquote>
+
+<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,
+27.6.1.3, paragraph 1 looks like:</p>
+
+<blockquote><p>
+Each unformatted input function begins execution by constructing an
+object of class sentry with the default argument noskipws (second)
+argument true. If the sentry object returns true, when converted to a
+value of type bool, the function endeavors to obtain the requested
+input. Otherwise, if the sentry constructor exits by throwing an
+exception or if the sentry object returns false, when converted to a
+value of type bool, the function returns without attempting to obtain
+any input. In either case the number of extracted characters is set to
+0; unformatted input functions taking a character array of non-zero
+size as an argument shall also store a null character (using charT())
+in the first location of the array. If an exception is thrown during
+input then ios::badbit is turned on in *this'ss error state. If
+(exception()&badbit)!= 0 then the exception is rethrown. It also counts
+the number of characters extracted. If no exception has been thrown it
+ends by storing the count in a member object and returning the value
+specified. In any event the sentry object is destroyed before leaving
+the unformatted input function.
+</p></blockquote>
+
+<p>And finally 27.6.1.1.2/5 says this about sentry:</p>
+
+<blockquote><p>
+If, after any preparation is completed, is.good() is true, ok_ != false
+otherwise, ok_ == false.
+</p></blockquote>
+
+<p>
+So although the seekg paragraph says that the operation proceeds if
+!fail(), the behavior of unformatted functions says the operation
+proceeds only if good(). The two statements are contradictory when only
+eofbit is set. I don't think the current text is clear which condition
+should be respected.
+</p>
+
+<p><b>Further discussion from Redmond:</b></p>
+
+<p>PJP: It doesn't seem quite right to say that <tt>seekg</tt> is
+"unformatted". That makes specific claims about sentry that
+aren't quite appropriate for seeking, which has less fragile failure
+modes than actual input. If we do really mean that it's unformatted
+input, it should behave the same way as other unformatted input. On
+the other hand, "principle of least surprise" is that seeking from EOF
+ought to be OK.</p>
+
+<p>
+Pre-Berlin: Paolo points out several problems with the proposed resolution in
+Ready state:
+</p>
+
+<ul>
+<li>It should apply to both overloads of seekg.</li>
+<li>tellg has similar issues, except that it should not call clear().</li>
+<li>The point about clear() seems to apply to seekp().</li>
+<li>Depending on the outcome of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#419">419</a>
+if the sentry
+sets <tt>failbit</tt> when it finds <tt>eofbit</tt> already set, then
+you can never seek away from the end of stream.</li>
+</ul>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>Change 27.6.1.3 [istream.unformatted] to:</p>
+<blockquote><p>
+Behaves as an unformatted input function (as described in 27.6.1.3,
+paragraph 1), except that it does not count the number of characters
+extracted, does not affect the value returned by subsequent calls to
+gcount(), and does not examine the value returned by the sentry
+object. After constructing a sentry object, if <tt>fail() !=
+true</tt>, executes <tt>rdbuf()->pubseekpos(pos)</tt>. In
+case of success, the function calls clear().
+In case of failure, the function calls <tt>setstate(failbit)</tt>
+(which may throw <tt>ios_base::failure</tt>).
+</p></blockquote>
+
+<p><i>[Lillehammer: Matt provided wording.]</i></p>
+
+
+
+
+<p><b>Rationale:</b></p>
+<p>In C, fseek does clear EOF. This is probably what most users would
+ expect. We agree that having eofbit set should not deter a seek,
+ and that a successful seek should clear eofbit. Note
+ that <tt>fail()</tt> is true only if <tt>failbit</tt>
+ or <tt>badbit</tt> is set, so using <tt>!fail()</tt>, rather
+ than <tt>good()</tt>, satisfies this goal.</p>
+
+
+
+
+
+<hr>
+<h3><a name="343"></a>343. Unspecified library header dependencies</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-10-09</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The synopses of the C++ library headers clearly show which names are
+required to be defined in each header. Since in order to implement the
+classes and templates defined in these headers declarations of other
+templates (but not necessarily their definitions) are typically
+necessary the standard in 17.4.4, p1 permits library implementers to
+include any headers needed to implement the definitions in each header.
+</p>
+
+<p>
+For instance, although it is not explicitly specified in the synopsis of
+<string>, at the point of definition of the std::basic_string template
+the declaration of the std::allocator template must be in scope. All
+current implementations simply include <memory> from within <string>,
+either directly or indirectly, to bring the declaration of
+std::allocator into scope.
+</p>
+
+<p>
+Additionally, however, some implementation also include <istream> and
+<ostream> at the top of <string> to bring the declarations of
+std::basic_istream and std::basic_ostream into scope (which are needed
+in order to implement the string inserter and extractor operators
+(21.3.7.9 [lib.string.io])). Other implementations only include
+<iosfwd>, since strictly speaking, only the declarations and not the
+full definitions are necessary.
+</p>
+
+<p>
+Obviously, it is possible to implement <string> without actually
+providing the full definitions of all the templates std::basic_string
+uses (std::allocator, std::basic_istream, and std::basic_ostream).
+Furthermore, not only is it possible, doing so is likely to have a
+positive effect on compile-time efficiency.
+</p>
+
+<p>
+But while it may seem perfectly reasonable to expect a program that uses
+the std::basic_string insertion and extraction operators to also
+explicitly include <istream> or <ostream>, respectively, it doesn't seem
+reasonable to also expect it to explicitly include <memory>. Since
+what's reasonable and what isn't is highly subjective one would expect
+the standard to specify what can and what cannot be assumed.
+Unfortunately, that isn't the case.
+</p>
+
+<p>The examples below demonstrate the issue.</p>
+
+<p>Example 1:</p>
+
+<p>It is not clear whether the following program is complete:</p>
+
+<pre>#include <string>
+
+extern std::basic_ostream<char> &strm;
+
+int main () {
+ strm << std::string ("Hello, World!\n");
+}
+</pre>
+
+<p>or whether one must explicitly include <memory> or
+<ostream> (or both) in addition to <string> in order for
+the program to compile.</p>
+
+
+<p>Example 2:</p>
+
+<p>Similarly, it is unclear whether the following program is complete:</p>
+
+<pre>#include <istream>
+
+extern std::basic_iostream<char> &strm;
+
+int main () {
+ strm << "Hello, World!\n";
+}
+</pre>
+
+<p>
+or whether one needs to explicitly include <ostream>, and
+perhaps even other headers containing the definitions of other
+required templates:</p>
+
+<pre>#include <ios>
+#include <istream>
+#include <ostream>
+#include <streambuf>
+
+extern std::basic_iostream<char> &strm;
+
+int main () {
+ strm << "Hello, World!\n";
+}
+</pre>
+
+<p>Example 3:</p>
+
+<p>Likewise, it seems unclear whether the program below is complete:</p>
+<pre>#include <iterator>
+
+bool foo (std::istream_iterator<int> a, std::istream_iterator<int> b)
+{
+ return a == b;
+}
+
+int main () { }
+</pre>
+
+<p>or whether one should be required to include <istream>.</p>
+
+<p>There are many more examples that demonstrate this lack of a
+requirement. I believe that in a good number of cases it would be
+unreasonable to require that a program explicitly include all the
+headers necessary for a particular template to be specialized, but I
+think that there are cases such as some of those above where it would
+be desirable to allow implementations to include only as much as
+necessary and not more.</p>
+
+<p><i>[
+post Bellevue:
+]</i></p>
+
+
+<blockquote>
+Position taken in prior reviews is that the idea of a table of header
+dependencies is a good one. Our view is that a full paper is needed to
+do justice to this, and we've made that recommendation to the issue
+author.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+For every C++ library header, supply a minimum set of other C++ library
+headers that are required to be included by that header. The proposed
+list is below (C++ headers for C Library Facilities, table 12 in
+17.4.1.2, p3, are omitted):
+</p>
+
+<pre>+------------+--------------------+
+| C++ header |required to include |
++============+====================+
+|<algorithm> | |
++------------+--------------------+
+|<bitset> | |
++------------+--------------------+
+|<complex> | |
++------------+--------------------+
+|<deque> |<memory> |
++------------+--------------------+
+|<exception> | |
++------------+--------------------+
+|<fstream> |<ios> |
++------------+--------------------+
+|<functional>| |
++------------+--------------------+
+|<iomanip> |<ios> |
++------------+--------------------+
+|<ios> |<streambuf> |
++------------+--------------------+
+|<iosfwd> | |
++------------+--------------------+
+|<iostream> |<istream>, <ostream>|
++------------+--------------------+
+|<istream> |<ios> |
++------------+--------------------+
+|<iterator> | |
++------------+--------------------+
+|<limits> | |
++------------+--------------------+
+|<list> |<memory> |
++------------+--------------------+
+|<locale> | |
++------------+--------------------+
+|<map> |<memory> |
++------------+--------------------+
+|<memory> | |
++------------+--------------------+
+|<new> |<exception> |
++------------+--------------------+
+|<numeric> | |
++------------+--------------------+
+|<ostream> |<ios> |
++------------+--------------------+
+|<queue> |<deque> |
++------------+--------------------+
+|<set> |<memory> |
++------------+--------------------+
+|<sstream> |<ios>, <string> |
++------------+--------------------+
+|<stack> |<deque> |
++------------+--------------------+
+|<stdexcept> | |
++------------+--------------------+
+|<streambuf> |<ios> |
++------------+--------------------+
+|<string> |<memory> |
++------------+--------------------+
+|<strstream> | |
++------------+--------------------+
+|<typeinfo> |<exception> |
++------------+--------------------+
+|<utility> | |
++------------+--------------------+
+|<valarray> | |
++------------+--------------------+
+|<vector> |<memory> |
++------------+--------------------+
+</pre>
+
+
+<p><b>Rationale:</b></p>
+<p>The portability problem is real. A program that works correctly on
+one implementation might fail on another, because of different header
+dependencies. This problem was understood before the standard was
+completed, and it was a conscious design choice.</p>
+<p>One possible way to deal with this, as a library extension, would
+be an <all> header.</p>
+
+<p>
+Hinnant: It's time we dealt with this issue for C++0X. Reopened.
+</p>
+
+
+
+
+
+
+
+<hr>
+<h3><a name="382"></a>382. codecvt do_in/out result</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-08-30</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+It seems that the descriptions of codecvt do_in() and do_out() leave
+sufficient room for interpretation so that two implementations of
+codecvt may not work correctly with the same filebuf. Specifically,
+the following seems less than adequately specified:
+</p>
+
+<ol>
+<li>
+ the conditions under which the functions terminate
+</li>
+<li>
+ precisely when the functions return ok
+</li>
+<li>
+ precisely when the functions return partial
+</li>
+<li>
+ the full set of conditions when the functions return error
+</li>
+</ol>
+
+<ol>
+<li>
+ 22.2.1.4.2 [locale.codecvt.virtuals], p2 says this about the effects of the
+ function: ...Stops if it encounters a character it cannot
+ convert... This assumes that there *is* a character to
+ convert. What happens when there is a sequence that doesn't form a
+ valid source character, such as an unassigned or invalid UNICODE
+ character, or a sequence that cannot possibly form a character
+ (e.g., the sequence "\xc0\xff" in UTF-8)?
+</li>
+<li>
+ Table 53 says that the function returns codecvt_base::ok
+ to indicate that the function(s) "completed the conversion."
+ Suppose that the source sequence is "\xc0\x80" in UTF-8,
+ with from pointing to '\xc0' and (from_end==from + 1).
+ It is not clear whether the return value should be ok
+ or partial (see below).
+</li>
+<li>
+ Table 53 says that the function returns codecvt_base::partial
+ if "not all source characters converted." With the from pointers
+ set up the same way as above, it is not clear whether the return
+ value should be partial or ok (see above).
+</li>
+<li>
+ Table 53, in the row describing the meaning of error mistakenly
+ refers to a "from_type" character, without the symbol from_type
+ having been defined. Most likely, the word "source" character
+ is intended, although that is not sufficient. The functions
+ may also fail when they encounter an invalid source sequence
+ that cannot possibly form a valid source character (e.g., as
+ explained in bullet 1 above).
+</li>
+</ol>
+<p>
+Finally, the conditions described at the end of 22.2.1.4.2 [locale.codecvt.virtuals], p4 don't seem to be possible:
+</p>
+<blockquote><p>
+ "A return value of partial, if (from_next == from_end),
+ indicates that either the destination sequence has not
+ absorbed all the available destination elements, or that
+ additional source elements are needed before another
+ destination element can be produced."
+</p></blockquote>
+<p>
+If the value is partial, it's not clear to me that (from_next
+==from_end) could ever hold if there isn't enough room
+in the destination buffer. In order for (from_next==from_end) to
+hold, all characters in that range must have been successfully
+converted (according to 22.2.1.4.2 [locale.codecvt.virtuals], p2) and since there are no
+further source characters to convert, no more room in the
+destination buffer can be needed.
+</p>
+<p>
+It's also not clear to me that (from_next==from_end) could ever
+hold if additional source elements are needed to produce another
+destination character (not element as incorrectly stated in the
+text). partial is returned if "not all source characters have
+been converted" according to Table 53, which also implies that
+(from_next==from) does NOT hold.
+</p>
+<p>
+Could it be that the intended qualifying condition was actually
+(from_next != from_end), i.e., that the sentence was supposed
+to read
+</p>
+<blockquote><p>
+ "A return value of partial, if (from_next != from_end),..."
+</p></blockquote>
+<p>
+which would make perfect sense, since, as far as I understand it,
+partial can only occur if (from_next != from_end)?
+</p>
+<p><i>[Lillehammer: Defer for the moment, but this really needs to be
+ fixed. Right now, the description of codecvt is too vague for it to
+ be a useful contract between providers and clients of codecvt
+ facets. (Note that both vendors and users can be both providers and
+ clients of codecvt facets.) The major philosophical issue is whether
+ the standard should only describe mappings that take a single wide
+ character to multiple narrow characters (and vice versa), or whether
+ it should describe fully general N-to-M conversions. When the
+ original standard was written only the former was contemplated, but
+ today, in light of the popularity of utf8 and utf16, that doesn't
+ seem sufficient for C++0x. Bill supports general N-to-M conversions;
+ we need to make sure Martin and Howard agree.]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+<hr>
+<h3><a name="387"></a>387. std::complex over-encapsulated</h3>
+<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>
+ <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2002-11-08</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The absence of explicit description of std::complex<T> layout
+makes it imposible to reuse existing software developed in traditional
+languages like Fortran or C with unambigous and commonly accepted
+layout assumptions. There ought to be a way for practitioners to
+predict with confidence the layout of std::complex<T> whenever T
+is a numerical datatype. The absence of ways to access individual
+parts of a std::complex<T> object as lvalues unduly promotes
+severe pessimizations. For example, the only way to change,
+independently, the real and imaginary parts is to write something like
+</p>
+
+<pre>complex<T> z;
+// ...
+// set the real part to r
+z = complex<T>(r, z.imag());
+// ...
+// set the imaginary part to i
+z = complex<T>(z.real(), i);
+</pre>
+
+<p>
+At this point, it seems appropriate to recall that a complex number
+is, in effect, just a pair of numbers with no particular invariant to
+maintain. Existing practice in numerical computations has it that a
+complex number datatype is usually represented by Cartesian
+coordinates. Therefore the over-encapsulation put in the specification
+of std::complex<> is not justified.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>Add the following requirements to 26.3 [complex.numbers] as 26.3/4:</p>
+<blockquote>
+<p>If z is an lvalue expression of type cv std::complex<T> then</p>
+
+<ul>
+<li>the expression reinterpret_cast<cv T(&)[2]>(z)
+is well-formed; and</li>
+<li>reinterpret_cast<cv T(&)[2]>(z)[0]designates the
+real part of z; and</li>
+<li>reinterpret_cast<cv T(&)[2]>(z)[1]designates the
+imaginary part of z.</li>
+</ul>
+
+<p>
+Moreover, if a is an expression of pointer type cv complex<T>*
+and the expression a[i] is well-defined for an integer expression
+i then:
+</p>
+
+<ul>
+<li>reinterpret_cast<cv T*>(a)[2*i] designates the real
+part of a[i]; and</li>
+<li>reinterpret_cast<cv T*>(a)[2*i+1] designates the
+imaginary part of a[i].</li>
+</ul>
+</blockquote>
+
+<p>
+In 26.3.2 [complex] and 26.3.3 [complex.special] add the following member functions
+(changing <tt>T</tt> to concrete types as appropriate for the specializations).
+</p>
+
+<blockquote><pre>void real(T);
+void imag(T);
+</pre></blockquote>
+
+<p>
+Add to 26.3.4 [complex.members]
+</p>
+
+<blockquote>
+<pre>T real() const;
+</pre>
+<blockquote>
+<i>Returns:</i> the value of the real component
+</blockquote>
+<pre>void real(T val);
+</pre>
+<blockquote>
+Assigns val to the real component.
+</blockquote>
+<pre>T imag() const;
+</pre>
+<blockquote>
+<i>Returns:</i> the value of the imaginary component
+</blockquote>
+<pre>void imag(T val);
+</pre>
+<blockquote>
+Assigns val to the imaginary component.
+</blockquote>
+</blockquote>
+
+<p><i>[Kona: The layout guarantee is absolutely necessary for C
+ compatibility. However, there was disagreement about the other part
+ of this proposal: retrieving elements of the complex number as
+ lvalues. An alternative: continue to have real() and imag() return
+ rvalues, but add set_real() and set_imag(). Straw poll: return
+ lvalues - 2, add setter functions - 5. Related issue: do we want
+ reinterpret_cast as the interface for converting a complex to an
+ array of two reals, or do we want to provide a more explicit way of
+ doing it? Howard will try to resolve this issue for the next
+ meeting.]</i></p>
+
+
+<p><i>[pre-Sydney: Howard summarized the options in n1589.]</i></p>
+
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Second half of proposed wording replaced and moved to Ready.
+</blockquote>
+
+<p><i>[
+Pre-Sophia Antipolis, Howard adds:
+]</i></p>
+
+
+<blockquote>
+Added the members to 26.3.3 [complex.special] and changed from Ready to Review.
+</blockquote>
+
+<p><i>[
+Post-Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+Moved from WP back to Ready so that the "and 26.3.3 [complex.special]" in the proposed
+resolution can be officially applied.
+</blockquote>
+
+
+
+<p><b>Rationale:</b></p>
+<p>The LWG believes that C99 compatibility would be enough
+justification for this change even without other considerations. All
+existing implementations already have the layout proposed here.</p>
+
+
+
+
+
+<hr>
+<h3><a name="394"></a>394. behavior of formatted output on failure</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-12-27</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+There is a contradiction in Formatted output about what bit is
+supposed to be set if the formatting fails. On sentence says it's
+badbit and another that it's failbit.
+</p>
+<p>
+27.6.2.5.1, p1 says in the Common Requirements on Formatted output
+functions:
+</p>
+<pre> ... If the generation fails, then the formatted output function
+ does setstate(ios::failbit), which might throw an exception.
+</pre>
+<p>
+27.6.2.5.2, p1 goes on to say this about Arithmetic Inserters:
+</p>
+<p>
+ ... The formatting conversion occurs as if it performed the
+ following code fragment:
+</p>
+<pre> bool failed =
+ use_facet<num_put<charT,ostreambuf_iterator<charT,traits>
+ > >
+ (getloc()).put(*this, *this, fill(), val). failed();
+
+ ... If failed is true then does setstate(badbit) ...
+</pre>
+<p>
+The original intent of the text, according to Jerry Schwarz (see
+c++std-lib-10500), is captured in the following paragraph:
+</p>
+<p>
+In general "badbit" should mean that the stream is unusable because
+of some underlying failure, such as disk full or socket closure;
+"failbit" should mean that the requested formatting wasn't possible
+because of some inconsistency such as negative widths. So typically
+if you clear badbit and try to output something else you'll fail
+again, but if you clear failbit and try to output something else
+you'll succeed.
+</p>
+<p>
+In the case of the arithmetic inserters, since num_put cannot
+report failure by any means other than exceptions (in response
+to which the stream must set badbit, which prevents the kind of
+recoverable error reporting mentioned above), the only other
+detectable failure is if the iterator returned from num_put
+returns true from failed().
+</p>
+<p>
+Since that can only happen (at least with the required iostream
+specializations) under such conditions as the underlying failure
+referred to above (e.g., disk full), setting badbit would seem
+to be the appropriate response (indeed, it is required in
+27.6.2.5.2, p1). It follows that failbit can never be directly
+set by the arithmetic (it can only be set by the sentry object
+under some unspecified conditions).
+</p>
+<p>
+The situation is different for other formatted output functions
+which can fail as a result of the streambuf functions failing
+(they may do so by means other than exceptions), and which are
+then required to set failbit.
+</p>
+<p>
+The contradiction, then, is that ostream::operator<<(int) will
+set badbit if the disk is full, while operator<<(ostream&,
+char) will set failbit under the same conditions. To make the behavior
+consistent, the Common requirements sections for the Formatted output
+functions should be changed as proposed below.
+</p>
+<p><i>[Kona: There's agreement that this is a real issue. What we
+ decided at Kona: 1. An error from the buffer (which can be detected
+ either directly from streambuf's member functions or by examining a
+ streambuf_iterator) should always result in badbit getting set.
+ 2. There should never be a circumstance where failbit gets set.
+ That represents a formatting error, and there are no circumstances
+ under which the output facets are specified as signaling a
+ formatting error. (Even more so for string output that for numeric
+ because there's nothing to format.) If we ever decide to make it
+ possible for formatting errors to exist then the facets can signal
+ the error directly, and that should go in clause 22, not clause 27.
+ 3. The phrase "if generation fails" is unclear and should be
+ eliminated. It's not clear whether it's intended to mean a buffer
+ error (e.g. a full disk), a formatting error, or something else.
+ Most people thought it was supposed to refer to buffer errors; if
+ so, we should say so. Martin will provide wording.]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+<p><b>Rationale:</b></p>
+
+
+
+
+
+
+<hr>
+<h3><a name="396"></a>396. what are characters zero and one</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-01-05</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+ <p>
+23.3.5.1, p6 [lib.bitset.cons] talks about a generic character
+having the value of 0 or 1 but there is no definition of what
+that means for charT other than char and wchar_t. And even for
+those two types, the values 0 and 1 are not actually what is
+intended -- the values '0' and '1' are. This, along with the
+converse problem in the description of to_string() in 23.3.5.2,
+p33, looks like a defect remotely related to DR 303.
+ </p>
+ <p>
+http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#303
+ </p>
+ <pre>23.3.5.1:
+ -6- An element of the constructed string has value zero if the
+ corresponding character in str, beginning at position pos,
+ is 0. Otherwise, the element has the value one.
+ </pre>
+ <pre>23.3.5.2:
+ -33- Effects: Constructs a string object of the appropriate
+ type and initializes it to a string of length N characters.
+ Each character is determined by the value of its
+ corresponding bit position in *this. Character position N
+ ?- 1 corresponds to bit position zero. Subsequent decreasing
+ character positions correspond to increasing bit positions.
+ Bit value zero becomes the character 0, bit value one becomes
+ the character 1.
+ </pre>
+ <p>
+Also note the typo in 23.3.5.1, p6: the object under construction
+is a bitset, not a string.
+ </p>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+We note that <tt>bitset</tt> has been moved from section 23 to section 20, by
+another issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#842">842</a>) previously resolved at this meeting.
+</p>
+<p>
+Disposition: move to ready.
+</p>
+<p>
+We request that Howard submit a separate issue regarding the three to_string overloads.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>Change the constructor's function declaration immediately before
+23.3.5.1 [bitset.cons] p3 to:</p>
+<pre> template <class charT, class traits, class Allocator>
+ explicit
+ bitset(const basic_string<charT, traits, Allocator>& str,
+ typename basic_string<charT, traits, Allocator>::size_type pos = 0,
+ typename basic_string<charT, traits, Allocator>::size_type n =
+ basic_string<charT, traits, Allocator>::npos,
+ charT zero = charT('0'), charT one = charT('1'))
+</pre>
+<p>Change the first two sentences of 23.3.5.1 [bitset.cons] p6 to: "An
+element of the constructed string has value 0 if the corresponding
+character in <i>str</i>, beginning at position <i>pos</i>,
+is <i>zero</i>. Otherwise, the element has the value 1.</p>
+
+<p>Change the text of the second sentence in 23.3.5.1, p5 to read:
+ "The function then throws invalid_argument if any of the rlen
+ characters in str beginning at position pos is other than <i>zero</i>
+ or <i>one</i>. The function uses traits::eq() to compare the character
+ values."
+</p>
+
+<p>Change the declaration of the <tt>to_string</tt> member function
+ immediately before 23.3.5.2 [bitset.members] p33 to:</p>
+<pre> template <class charT, class traits, class Allocator>
+ basic_string<charT, traits, Allocator>
+ to_string(charT zero = charT('0'), charT one = charT('1')) const;
+</pre>
+<p>Change the last sentence of 23.3.5.2 [bitset.members] p33 to: "Bit
+ value 0 becomes the character <tt><i>zero</i></tt>, bit value 1 becomes the
+ character <tt><i>one</i></tt>.</p>
+<p>Change 23.3.5.3 [bitset.operators] p8 to:</p>
+<p><b>Returns</b>:</p>
+<pre> os << x.template to_string<charT,traits,allocator<charT> >(
+ use_facet<ctype<charT> >(<i>os</i>.getloc()).widen('0'),
+ use_facet<ctype<charT> >(<i>os</i>.getloc()).widen('1'));
+</pre>
+
+
+<p><b>Rationale:</b></p>
+<p>There is a real problem here: we need the character values of '0'
+ and '1', and we have no way to get them since strings don't have
+ imbued locales. In principle the "right" solution would be to
+ provide an extra object, either a ctype facet or a full locale,
+ which would be used to widen '0' and '1'. However, there was some
+ discomfort about using such a heavyweight mechanism. The proposed
+ resolution allows those users who care about this issue to get it
+ right.</p>
+<p>We fix the inserter to use the new arguments. Note that we already
+ 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>
+
+
+
+<p><i>[
+post Bellevue:
+]</i></p>
+
+
+<blockquote>
+We are happy with the resolution as proposed, and we move this to Ready.
+</blockquote>
+
+<p><i>[
+Howard adds:
+]</i></p>
+
+
+<blockquote>
+The proposed wording neglects the 3 newer to_string overloads.
+</blockquote>
+
+
+
+
+<hr>
+<h3><a name="397"></a>397. ostream::sentry dtor throws exceptions</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-01-05</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+ <p>
+17.4.4.8, p3 prohibits library dtors from throwing exceptions.
+ </p>
+ <p>
+27.6.2.3, p4 says this about the ostream::sentry dtor:
+ </p>
+ <pre> -4- If ((os.flags() & ios_base::unitbuf) && !uncaught_exception())
+ is true, calls os.flush().
+ </pre>
+ <p>
+27.6.2.6, p7 that describes ostream::flush() says:
+ </p>
+ <pre> -7- If rdbuf() is not a null pointer, calls rdbuf()->pubsync().
+ If that function returns ?-1 calls setstate(badbit) (which
+ may throw ios_base::failure (27.4.4.3)).
+ </pre>
+ <p>
+That seems like a defect, since both pubsync() and setstate() can
+throw an exception.
+ </p>
+<p><i>[
+The contradiction is real. Clause 17 says destructors may never
+throw exceptions, and clause 27 specifies a destructor that does
+throw. In principle we might change either one. We're leaning
+toward changing clause 17: putting in an "unless otherwise specified"
+clause, and then putting in a footnote saying the sentry destructor
+is the only one that can throw. PJP suggests specifying that
+sentry::~sentry() should internally catch any exceptions it might cause.
+]</i></p>
+
+
+<p><i>[
+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.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="398"></a>398. effects of end-of-file on unformatted input functions</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-01-05</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+ <p>
+While reviewing unformatted input member functions of istream
+for their behavior when they encounter end-of-file during input
+I found that the requirements vary, sometimes unexpectedly, and
+in more than one case even contradict established practice (GNU
+libstdc++ 3.2, IBM VAC++ 6.0, STLPort 4.5, SunPro 5.3, HP aCC
+5.38, Rogue Wave libstd 3.1, and Classic Iostreams).
+ </p>
+ <p>
+The following unformatted input member functions set eofbit if they
+encounter an end-of-file (this is the expected behavior, and also
+the behavior of all major implementations):
+ </p>
+ <pre> basic_istream<charT, traits>&
+ get (char_type*, streamsize, char_type);
+ </pre>
+ <p>
+ Also sets failbit if it fails to extract any characters.
+ </p>
+ <pre> basic_istream<charT, traits>&
+ get (char_type*, streamsize);
+ </pre>
+ <p>
+ Also sets failbit if it fails to extract any characters.
+ </p>
+ <pre> basic_istream<charT, traits>&
+ getline (char_type*, streamsize, char_type);
+ </pre>
+ <p>
+ Also sets failbit if it fails to extract any characters.
+ </p>
+ <pre> basic_istream<charT, traits>&
+ getline (char_type*, streamsize);
+ </pre>
+ <p>
+ Also sets failbit if it fails to extract any characters.
+ </p>
+ <pre> basic_istream<charT, traits>&
+ ignore (int, int_type);
+ </pre>
+ <pre> basic_istream<charT, traits>&
+ read (char_type*, streamsize);
+ </pre>
+ <p>
+ Also sets failbit if it encounters end-of-file.
+ </p>
+ <pre> streamsize readsome (char_type*, streamsize);
+ </pre>
+
+ <p>
+The following unformated input member functions set failbit but
+not eofbit if they encounter an end-of-file (I find this odd
+since the functions make it impossible to distinguish a general
+failure from a failure due to end-of-file; the requirement is
+also in conflict with all major implementation which set both
+eofbit and failbit):
+ </p>
+ <pre> int_type get();
+ </pre>
+ <pre> basic_istream<charT, traits>&
+ get (char_type&);
+ </pre>
+ <p>
+These functions only set failbit of they extract no characters,
+otherwise they don't set any bits, even on failure (I find this
+inconsistency quite unexpected; the requirement is also in
+conflict with all major implementations which set eofbit
+whenever they encounter end-of-file):
+ </p>
+ <pre> basic_istream<charT, traits>&
+ get (basic_streambuf<charT, traits>&, char_type);
+ </pre>
+ <pre> basic_istream<charT, traits>&
+ get (basic_streambuf<charT, traits>&);
+ </pre>
+ <p>
+This function sets no bits (all implementations except for
+STLport and Classic Iostreams set eofbit when they encounter
+end-of-file):
+ </p>
+ <pre> int_type peek ();
+ </pre>
+<p>Informally, what we want is a global statement of intent saying
+ that eofbit gets set if we trip across EOF, and then we can take
+ away the specific wording for individual functions. A full review
+ is necessary. The wording currently in the standard is a mishmash,
+ and changing it on an individual basis wouldn't make things better.
+ Dietmar will do this work.</p>
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+<hr>
+<h3><a name="408"></a>408. Is vector<reverse_iterator<char*> > forbidden?</h3>
+<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>
+ <b>Submitter:</b> Nathan Myers <b>Date:</b> 2003-06-03</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+I've been discussing iterator semantics with Dave Abrahams, and a
+surprise has popped up. I don't think this has been discussed before.
+</p>
+
+<p>
+24.1 [iterator.requirements] says that the only operation that can be performed on "singular"
+iterator values is to assign a non-singular value to them. (It
+doesn't say they can be destroyed, and that's probably a defect.)
+Some implementations have taken this to imply that there is no need
+to initialize the data member of a reverse_iterator<> in the default
+constructor. As a result, code like
+</p>
+<blockquote><pre> std::vector<std::reverse_iterator<char*> > v(7);
+ v.reserve(1000);
+</pre></blockquote>
+<p>
+invokes undefined behavior, because it must default-initialize the
+vector elements, and then copy them to other storage. Of course many
+other vector operations on these adapters are also left undefined,
+and which those are is not reliably deducible from the standard.
+</p>
+
+<p>
+I don't think that 24.1 was meant to make standard-library iterator
+types unsafe. Rather, it was meant to restrict what operations may
+be performed by functions which take general user- and standard
+iterators as arguments, so that raw pointers would qualify as
+iterators. However, this is not clear in the text, others have come
+to the opposite conclusion.
+</p>
+
+<p>
+One question is whether the standard iterator adaptors have defined
+copy semantics. Another is whether they have defined destructor
+semantics: is
+</p>
+<blockquote><pre> { std::vector<std::reverse_iterator<char*> > v(7); }
+</pre></blockquote>
+<p>
+undefined too?
+</p>
+
+<p>
+Note this is not a question of whether algorithms are allowed to
+rely on copy semantics for arbitrary iterators, just whether the
+types we actually supply support those operations. I believe the
+resolution must be expressed in terms of the semantics of the
+adapter's argument type. It should make clear that, e.g., the
+reverse_iterator<T> constructor is actually required to execute
+T(), and so copying is defined if the result of T() is copyable.
+</p>
+
+<p>
+Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, which defines reverse_iterator's default
+constructor more precisely, has some relevance to this issue.
+However, it is not the whole story.
+</p>
+
+<p>
+The issue was whether
+</p>
+<blockquote><pre> reverse_iterator() { }
+</pre></blockquote>
+<p>
+is allowed, vs.
+</p>
+<blockquote><pre> reverse_iterator() : current() { }
+</pre></blockquote>
+
+<p>
+The difference is when T is char*, where the first leaves the member
+uninitialized, and possibly equal to an existing pointer value, or
+(on some targets) may result in a hardware trap when copied.
+</p>
+
+<p>
+8.5 paragraph 5 seems to make clear that the second is required to
+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
+types.
+</p>
+
+<p>
+But that only takes care of reverse_iterator, and doesn't establish
+a policy for all iterators. (The reverse iterator adapter was just
+an example.) In particular, does my function
+</p>
+<blockquote><pre> template <typename Iterator>
+ void f() { std::vector<Iterator> v(7); }
+</pre></blockquote>
+<p>
+evoke undefined behavior for some conforming iterator definitions?
+I think it does, now, because vector<> will destroy those singular
+iterator values, and that's explicitly disallowed.
+</p>
+
+<p>
+24.1 shouldn't give blanket permission to copy all singular iterators,
+because then pointers wouldn't qualify as iterators. However, it
+should allow copying of that subset of singular iterator values that
+are default-initialized, and it should explicitly allow destroying any
+iterator value, singular or not, default-initialized or not.
+</p>
+
+<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#407">407</a></p>
+<p><i>[
+We don't want to require all singular iterators to be copyable,
+because that is not the case for pointers. However, default
+construction may be a special case. Issue: is it really default
+construction we want to talk about, or is it something like value
+initialization? We need to check with core to see whether default
+constructed pointers are required to be copyable; if not, it would be
+wrong to impose so strict a requirement for iterators.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="417"></a>417. what does ctype::do_widen() return on failure</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The Effects and Returns clauses of the do_widen() member function of
+the ctype facet fail to specify the behavior of the function on failure.
+That the function may not be able to simply cast the narrow character
+argument to the type of the result since doing so may yield the wrong value
+for some wchar_t encodings. Popular implementations of ctype<wchar_t> that
+use mbtowc() and UTF-8 as the native encoding (e.g., GNU glibc) will fail
+when the argument's MSB is set. There is no way for the the rest of locale
+and iostream to reliably detect this failure.
+</p>
+<p><i>[Kona: This is a real problem. Widening can fail. It's unclear
+ what the solution should be. Returning WEOF works for the wchar_t
+ specialization, but not in general. One option might be to add a
+ default, like <i>narrow</i>. But that's an incompatible change.
+ Using <i>traits::eof</i> might seem like a good idea, but facets
+ don't have access to traits (a recurring problem). We could
+ have <i>widen</i> throw an exception, but that's a scary option;
+ existing library components aren't written with the assumption
+ that <i>widen</i> can throw.]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+<hr>
+<h3><a name="418"></a>418. exceptions thrown during iostream cleanup</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The dtor of the ios_base::Init object is supposed to call flush() on the
+6 standard iostream objects cout, cerr, clog, wcout, wcerr, and wclog.
+This call may cause an exception to be thrown.
+</p>
+
+<p>
+17.4.4.8, p3 prohibits all library destructors from throwing exceptions.
+</p>
+
+<p>
+The question is: What should this dtor do if one or more of these calls
+to flush() ends up throwing an exception? This can happen quite easily
+if one of the facets installed in the locale imbued in the iostream
+object throws.
+</p>
+<p><i>[Kona: We probably can't do much better than what we've got, so
+ the LWG is leaning toward NAD. At the point where the standard
+ stream objects are being cleaned up, the usual error reporting
+ mechanism are all unavailable. And exception from flush at this
+ point will definitely cause problems. A quality implementation
+ might reasonably swallow the exception, or call abort, or do
+ something even more drastic.]</i></p>
+
+
+<p><i>[
+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.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+<hr>
+<h3><a name="419"></a>419. istream extractors not setting failbit if eofbit is already set</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+ <p>
+
+27.6.1.1.3 [istream::sentry], p2 says that istream::sentry ctor prepares for input if is.good()
+is true. p4 then goes on to say that the ctor sets the sentry::ok_ member to
+true if the stream state is good after any preparation. 27.6.1.2.1 [istream.formatted.reqmts], p1 then
+says that a formatted input function endeavors to obtain the requested input
+if the sentry's operator bool() returns true.
+
+Given these requirements, no formatted extractor should ever set failbit if
+the initial stream rdstate() == eofbit. That is contrary to the behavior of
+all implementations I tested. The program below prints out
+
+eof = 1, fail = 0
+eof = 1, fail = 1
+
+on all of them.
+ </p>
+<pre>
+#include <sstream>
+#include <cstdio>
+
+int main()
+{
+ std::istringstream strm ("1");
+
+ int i = 0;
+
+ strm >> i;
+
+ std::printf ("eof = %d, fail = %d\n",
+ !!strm.eof (), !!strm.fail ());
+
+ strm >> i;
+
+ std::printf ("eof = %d, fail = %d\n",
+ !!strm.eof (), !!strm.fail ());
+}
+
+</pre>
+ <p>
+<br>
+
+Comments from Jerry Schwarz (c++std-lib-11373):
+<br>
+
+Jerry Schwarz wrote:
+<br>
+
+I don't know where (if anywhere) it says it in the standard, but the
+formatted extractors are supposed to set failbit if they don't extract
+any characters. If they didn't then simple loops like
+<br>
+
+while (cin >> x);
+<br>
+
+would loop forever.
+<br>
+
+Further comments from Martin Sebor:
+<br>
+
+The question is which part of the extraction should prevent this from happening
+by setting failbit when eofbit is already set. It could either be the sentry
+object or the extractor. It seems that most implementations have chosen to
+set failbit in the sentry [...] so that's the text that will need to be
+corrected.
+
+ </p>
+<p>
+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
+sets <tt>failbit</tt> when it finds <tt>eofbit</tt> already set, then
+you can never seek away from the end of stream.
+</p>
+<p>Kona: Possibly NAD. If eofbit is set then good() will return false. We
+ then set <i>ok</i> to false. We believe that the sentry's
+ constructor should always set failbit when <i>ok</i> is false, and
+ we also think the standard already says that. Possibly it could be
+ clearer.</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 27.6.1.1.3 [istream::sentry], p2 to:
+</p>
+
+<blockquote>
+<pre>explicit sentry(basic_istream<charT,traits>& <i>is</i> , bool <i>noskipws</i> = false);</pre>
+<p>
+-2- <i>Effects:</i> If <tt>is.good()</tt> is <del><tt>true</tt></del>
+<ins><tt>false</tt></ins>, <ins>calls <tt>is.setstate(failbit)</tt>.
+Otherwise</ins> prepares for formatted or unformatted input. ...
+</p>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="421"></a>421. is basic_streambuf copy-constructible?</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The reflector thread starting with c++std-lib-11346 notes that the class
+template basic_streambuf, along with basic_stringbuf and basic_filebuf,
+is copy-constructible but that the semantics of the copy constructors
+are not defined anywhere. Further, different implementations behave
+differently in this respect: some prevent copy construction of objects
+of these types by declaring their copy ctors and assignment operators
+private, others exhibit undefined behavior, while others still give
+these operations well-defined semantics.
+</p>
+
+<p>
+Note that this problem doesn't seem to be isolated to just the three
+types mentioned above. A number of other types in the library section
+of the standard provide a compiler-generated copy ctor and assignment
+operator yet fail to specify their semantics. It's believed that the
+only types for which this is actually a problem (i.e. types where the
+compiler-generated default may be inappropriate and may not have been
+intended) are locale facets. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#439">439</a>.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+27.5.2 [lib.streambuf]: Add into the synopsis, public section, just above the destructor declaration:
+</p>
+
+<blockquote>
+<pre>basic_streambuf(const basic_streambuf& sb);
+basic_streambuf& operator=(const basic_streambuf& sb);
+</pre>
+</blockquote>
+
+<p>Insert after 27.5.2.1, paragraph 2:</p>
+<blockquote>
+<pre>basic_streambuf(const basic_streambuf& sb);
+</pre>
+
+<p>Constructs a copy of sb.</p>
+<p>Postcondtions:</p>
+<pre> eback() == sb.eback()
+ gptr() == sb.gptr()
+ egptr() == sb.egptr()
+ pbase() == sb.pbase()
+ pptr() == sb.pptr()
+ epptr() == sb.epptr()
+ getloc() == sb.getloc()
+</pre>
+
+<pre>basic_streambuf& operator=(const basic_streambuf& sb);
+</pre>
+
+<p>Assigns the data members of sb to this.</p>
+
+<p>Postcondtions:</p>
+<pre> eback() == sb.eback()
+ gptr() == sb.gptr()
+ egptr() == sb.egptr()
+ pbase() == sb.pbase()
+ pptr() == sb.pptr()
+ epptr() == sb.epptr()
+ getloc() == sb.getloc()
+</pre>
+
+<p>Returns: *this.</p>
+</blockquote>
+
+<p>27.7.1 [lib.stringbuf]:</p>
+
+<p><b>Option A:</b></p>
+
+<blockquote>
+<p>Insert into the basic_stringbuf synopsis in the private section:</p>
+
+<pre>basic_stringbuf(const basic_stringbuf&); // not defined
+basic_stringbuf& operator=(const basic_stringbuf&); // not defined
+</pre>
+</blockquote>
+
+<p><b>Option B:</b></p>
+
+<blockquote>
+<p>Insert into the basic_stringbuf synopsis in the public section:</p>
+
+<pre>basic_stringbuf(const basic_stringbuf& sb);
+basic_stringbuf& operator=(const basic_stringbuf& sb);
+</pre>
+
+<p>27.7.1.1, insert after paragraph 4:</p>
+
+<pre>basic_stringbuf(const basic_stringbuf& sb);</pre>
+
+<p>
+Constructs an independent copy of sb as if with sb.str(), and with the openmode that sb was constructed with.
+</p>
+
+<p>Postcondtions: </p>
+<pre> str() == sb.str()
+ gptr() - eback() == sb.gptr() - sb.eback()
+ egptr() - eback() == sb.egptr() - sb.eback()
+ pptr() - pbase() == sb.pptr() - sb.pbase()
+ getloc() == sb.getloc()
+</pre>
+
+<p>
+Note: The only requirement on epptr() is that it point beyond the
+initialized range if an output sequence exists. There is no requirement
+that epptr() - pbase() == sb.epptr() - sb.pbase().
+</p>
+
+<pre>basic_stringbuf& operator=(const basic_stringbuf& sb);</pre>
+<p>After assignment the basic_stringbuf has the same state as if it
+were initially copy constructed from sb, except that the
+basic_stringbuf is allowed to retain any excess capacity it might have,
+which may in turn effect the value of epptr().
+</p>
+</blockquote>
+
+<p>27.8.1.1 [lib.filebuf]</p>
+
+<p>Insert at the bottom of the basic_filebuf synopsis:</p>
+
+<blockquote>
+<pre>private:
+ basic_filebuf(const basic_filebuf&); // not defined
+ basic_filebuf& operator=(const basic_filebuf&); // not defined
+</pre>
+</blockquote>
+<p><i>[Kona: this is an issue for basic_streambuf itself and for its
+ derived classes. We are leaning toward allowing basic_streambuf to
+ be copyable, and specifying its precise semantics. (Probably the
+ obvious: copying the buffer pointers.) We are less sure whether
+ the streambuf derived classes should be copyable. Howard will
+ write up a proposal.]</i></p>
+
+
+<p><i>[Sydney: Dietmar presented a new argument against basic_streambuf
+ being copyable: it can lead to an encapsulation violation. Filebuf
+ inherits from streambuf. Now suppose you inhert a my_hijacking_buf
+ from streambuf. You can copy the streambuf portion of a filebuf to a
+ my_hijacking_buf, giving you access to the pointers into the
+ filebuf's internal buffer. Perhaps not a very strong argument, but
+ it was strong enough to make people nervous. There was weak
+ preference for having streambuf not be copyable. There was weak
+ preference for having stringbuf not be copyable even if streambuf
+ is. Move this issue to open for now.
+]</i></p>
+
+
+<p><i>[
+2007-01-12, Howard:
+<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>
+recommends protected copy constructor and assignment for <tt>basic_streambuf</tt> with the same semantics
+as would be generated by the compiler. These members aid in derived classes implementing move semantics.
+A protected copy constructor and copy assignment operator do not expose encapsulation more so than it is
+today as each data member of a <tt>basic_streambuf</tt> is already both readable and writable by derived
+classes via various get/set protected member functions (<tt>eback()</tt>, <tt>setp()</tt>, etc.). Rather
+a protected copy constructor and copy assignment operator simply make the job of derived classes implementing
+move semantics less tedious and error prone.
+]</i></p>
+
+
+
+
+<p><b>Rationale:</b></p>
+<p>
+27.5.2 [lib.streambuf]: The proposed basic_streambuf copy constructor
+and assignment operator are the same as currently implied by the lack
+of declarations: public and simply copies the data members. This
+resolution is not a change but a clarification of the current
+standard.
+</p>
+
+<p>
+27.7.1 [lib.stringbuf]: There are two reasonable options: A) Make
+basic_stringbuf not copyable. This is likely the status-quo of
+current implementations. B) Reasonable copy semantics of
+basic_stringbuf can be defined and implemented. A copyable
+basic_streambuf is arguably more useful than a non-copyable one. This
+should be considered as new functionality and not the fixing of a
+defect. If option B is chosen, ramifications from issue 432 are taken
+into account.
+</p>
+
+<p>
+27.8.1.1 [lib.filebuf]: There are no reasonable copy semantics for
+basic_filebuf.
+</p>
+
+
+
+
+
+
+<hr>
+<h3><a name="423"></a>423. effects of negative streamsize in iostreams</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+
+<p>
+A third party test suite tries to exercise istream::ignore(N) with
+a negative value of N and expects that the implementation will treat
+N as if it were 0. Our implementation asserts that (N >= 0) holds and
+aborts the test.
+</p>
+
+<p>
+I can't find anything in section 27 that prohibits such values but I don't
+see what the effects of such calls should be, either (this applies to
+a number of unformatted input functions as well as some member functions
+of the basic_streambuf template).
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+I propose that we add to each function in clause 27 that takes an argument,
+say N, of type streamsize a Requires clause saying that "N >= 0." The intent
+is to allow negative streamsize values in calls to precision() and width()
+but disallow it in calls to streambuf::sgetn(), istream::ignore(), or
+ostream::write().
+</p>
+
+<p><i>[Kona: The LWG agreed that this is probably what we want. However, we
+ need a review to find all places where functions in clause 27 take
+ arguments of type streamsize that shouldn't be allowed to go
+ negative. Martin will do that review.]</i></p>
+
+
+
+
+
+
+<hr>
+<h3><a name="427"></a>427. stage 2 and rationale of DR 221</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The requirements specified in Stage 2 and reiterated in the rationale
+of DR 221 (and echoed again in DR 303) specify that num_get<charT>::
+do_get() compares characters on the stream against the widened elements
+of "012...abc...ABCX+-"
+</p>
+
+<p>
+An implementation is required to allow programs to instantiate the num_get
+template on any charT that satisfies the requirements on a user-defined
+character type. These requirements do not include the ability of the
+character type to be equality comparable (the char_traits template must
+be used to perform tests for equality). Hence, the num_get template cannot
+be implemented to support any arbitrary character type. The num_get template
+must either make the assumption that the character type is equality-comparable
+(as some popular implementations do), or it may use char_traits<charT> to do
+the comparisons (some other popular implementations do that). This diversity
+of approaches makes it difficult to write portable programs that attempt to
+instantiate the num_get template on user-defined types.
+</p>
+
+<p><i>[Kona: the heart of the problem is that we're theoretically
+ supposed to use traits classes for all fundamental character
+ operations like assignment and comparison, but facets don't have
+ traits parameters. This is a fundamental design flaw and it
+ appears all over the place, not just in this one place. It's not
+ clear what the correct solution is, but a thorough review of facets
+ and traits is in order. The LWG considered and rejected the
+ possibility of changing numeric facets to use narrowing instead of
+ widening. This may be a good idea for other reasons (see issue
+ <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
+ issue. Whether we use widen or narrow the <tt>num_get</tt> facet
+ still has no idea which traits class the user wants to use for
+ the comparison, because only streams, not facets, are passed traits
+ classes. The standard does not require that two different
+ traits classes with the same <tt>char_type</tt> must necessarily
+ have the same behavior.]</i></p>
+
+
+<p>Informally, one possibility: require that some of the basic
+character operations, such as <tt>eq</tt>, <tt>lt</tt>,
+and <tt>assign</tt>, must behave the same way for all traits classes
+with the same <tt>char_type</tt>. If we accept that limitation on
+traits classes, then the facet could reasonably be required to
+use <tt>char_traits<charT></tt>.</p>
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+<hr>
+<h3><a name="430"></a>430. valarray subset operations</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The standard fails to specify the behavior of valarray::operator[](slice)
+and other valarray subset operations when they are passed an "invalid"
+slice object, i.e., either a slice that doesn't make sense at all (e.g.,
+slice (0, 1, 0) or one that doesn't specify a valid subset of the valarray
+object (e.g., slice (2, 1, 1) for a valarray of size 1).
+</p>
+<p><i>[Kona: the LWG believes that invalid slices should invoke
+ undefined behavior. Valarrays are supposed to be designed for high
+ performance, so we don't want to require specific checking. We
+ need wording to express this decision.]</i></p>
+
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Please note that the standard also fails to specify the behavior of
+slice_array and gslice_array in the valid case. Bill Plauger will
+endeavor to provide revised wording for slice_array and gslice_array.
+</blockquote>
+
+<p><i>[
+post-Bellevue: Bill provided wording.
+]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Insert after 26.5.2.4 [valarray.sub], paragraph 1:
+</p>
+
+<blockquote>
+<p>
+The member operator is overloaded to provide several ways to select
+sequences
+of elements from among those controlled by <tt>*this</tt>. The first group of five
+member operators work in conjunction with various overloads of <tt>operator=</tt>
+(and other assigning operators) to allow selective replacement (slicing) of
+the controlled sequence. The selected elements must exist.
+</p>
+<p>
+The first member operator selects element off. For example:
+</p>
+
+<blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
+v0[3] = 'A';
+// v0 == valarray<char>("abcAefghijklmnop", 16)
+</pre></blockquote>
+
+<p>
+The second member operator selects those elements of the controlled sequence
+designated by <tt>slicearr</tt>. For example:
+</p>
+
+<blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
+valarray<char> v1("ABCDE", 5);
+v0[slice(2, 5, 3)] = v1;
+// v0 == valarray<char>("abAdeBghCjkDmnEp", 16)
+</pre></blockquote>
+
+<p>
+The third member operator selects those elements of the controlled sequence
+designated by <tt>gslicearr</tt>. For example:
+</p>
+
+<blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
+valarray<char> v1("ABCDEF", 6);
+const size_t lv[] = {2, 3};
+const size_t dv[] = {7, 2};
+const valarray<size_t> len(lv, 2), str(dv, 2);
+v0[gslice(3, len, str)] = v1;
+// v0 == valarray<char>("abcAeBgCijDlEnFp", 16)
+</pre></blockquote>
+
+<p>
+The fourth member operator selects those elements of the controlled sequence
+designated by <tt>boolarr</tt>. For example:
+</p>
+
+<blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
+valarray<char> v1("ABC", 3);
+const bool vb[] = {false, false, true, true, false, true};
+v0[valarray<bool>(vb, 6)] = v1;
+// v0 == valarray<char>("abABeCghijklmnop", 16)
+</pre></blockquote>
+
+<p>
+The fifth member operator selects those elements of the controlled sequence
+designated by indarr. For example:
+</p>
+
+<blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
+valarray<char> v1("ABCDE", 5);
+const size_t vi[] = {7, 5, 2, 3, 8};
+v0[valarray<size_t>(vi, 5)] = v1;
+// v0 == valarray<char>("abCDeBgAEjklmnop", 16)
+</pre></blockquote>
+
+<p>
+The second group of five member operators each construct an object that
+represents the value(s) selected. The selected elements must exist.
+</p>
+
+<p>
+The sixth member operator returns the value of element off. For example:
+</p>
+
+<blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
+// v0[3] returns 'd'
+</pre></blockquote>
+
+<p>
+The seventh member operator returns an object of class <tt>valarray<Ty></tt>
+containing those elements of the controlled sequence designated by <tt>slicearr</tt>.
+For example:
+</p>
+
+<blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
+// v0[slice(2, 5, 3)] returns valarray<char>("cfilo", 5)
+</pre></blockquote>
+
+<p>
+The eighth member operator selects those elements of the controlled sequence
+designated by <tt>gslicearr</tt>. For example:
+</p>
+
+<blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
+const size_t lv[] = {2, 3};
+const size_t dv[] = {7, 2};
+const valarray<size_t> len(lv, 2), str(dv, 2);
+// v0[gslice(3, len, str)] returns
+// valarray<char>("dfhkmo", 6)
+</pre></blockquote>
+
+<p>
+The ninth member operator selects those elements of the controlled sequence
+designated by <tt>boolarr</tt>. For example:
+</p>
+
+<blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
+const bool vb[] = {false, false, true, true, false, true};
+// v0[valarray<bool>(vb, 6)] returns
+// valarray<char>("cdf", 3)
+</pre></blockquote>
+
+<p>
+The last member operator selects those elements of the controlled sequence
+designated by <tt>indarr</tt>. For example:
+</p>
+
+<blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16);
+const size_t vi[] = {7, 5, 2, 3, 8};
+// v0[valarray<size_t>(vi, 5)] returns
+// valarray<char>("hfcdi", 5)
+</pre></blockquote>
+
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="431"></a>431. Swapping containers with unequal allocators</h3>
+<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>
+ <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-09-20</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>Clause 20.1.2 [allocator.requirements] paragraph 4 says that implementations
+ are permitted to supply containers that are unable to cope with
+ allocator instances and that container implementations may assume
+ that all instances of an allocator type compare equal. We gave
+ implementers this latitude as a temporary hack, and eventually we
+ want to get rid of it. What happens when we're dealing with
+ allocators that <i>don't</i> compare equal?
+</p>
+
+<p>In particular: suppose that <tt>v1</tt> and <tt>v2</tt> are both
+ objects of type <tt>vector<int, my_alloc></tt> and that
+ <tt>v1.get_allocator() != v2.get_allocator()</tt>. What happens if
+ we write <tt>v1.swap(v2)</tt>? Informally, three possibilities:</p>
+
+<p>1. This operation is illegal. Perhaps we could say that an
+ implementation is required to check and to throw an exception, or
+ perhaps we could say it's undefined behavior.</p>
+<p>2. The operation performs a slow swap (i.e. using three
+ invocations of <tt>operator=</tt>, leaving each allocator with its
+ original container. This would be an O(N) operation.</p>
+<p>3. The operation swaps both the vectors' contents and their
+ allocators. This would be an O(1) operation. That is:</p>
+ <blockquote>
+ <pre> my_alloc a1(...);
+ my_alloc a2(...);
+ assert(a1 != a2);
+
+ vector<int, my_alloc> v1(a1);
+ vector<int, my_alloc> v2(a2);
+ assert(a1 == v1.get_allocator());
+ assert(a2 == v2.get_allocator());
+
+ v1.swap(v2);
+ assert(a1 == v2.get_allocator());
+ assert(a2 == v1.get_allocator());
+ </pre>
+ </blockquote>
+
+<p><i>[Kona: This is part of a general problem. We need a paper
+ saying how to deal with unequal allocators in general.]</i></p>
+
+
+<p><i>[pre-Sydney: Howard argues for option 3 in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1599.html">N1599</a>.
+]</i></p>
+
+
+<p><i>[
+2007-01-12, Howard: This issue will now tend to come up more often with move constructors
+and move assignment operators. For containers, these members transfer resources (i.e.
+the allocated memory) just like swap.
+]</i></p>
+
+
+<p><i>[
+Batavia: There is agreement to overload the container <tt>swap</tt> on the allocator's Swappable
+requirement using concepts. If the allocator supports Swappable, then container's swap will
+swap allocators, else it will perform a "slow swap" using copy construction and copy assignment.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="446"></a>446. Iterator equality between different containers</h3>
+<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>
+ <b>Submitter:</b> Andy Koenig <b>Date:</b> 2003-12-16</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+What requirements does the standard place on equality comparisons between
+iterators that refer to elements of different containers. For example, if
+v1 and v2 are empty vectors, is v1.end() == v2.end() allowed to yield true?
+Is it allowed to throw an exception?
+</p>
+
+<p>
+The standard appears to be silent on both questions.
+</p>
+<p><i>[Sydney: The intention is that comparing two iterators from
+different containers is undefined, but it's not clear if we say that,
+or even whether it's something we should be saying in clause 23 or in
+clause 24. Intuitively we might want to say that equality is defined
+only if one iterator is reachable from another, but figuring out how
+to say it in any sensible way is a bit tricky: reachability is defined
+in terms of equality, so we can't also define equality in terms of
+reachability.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+
+<hr>
+<h3><a name="454"></a>454. basic_filebuf::open should accept wchar_t names</h3>
+<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>
+ <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
+<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>
+<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>
+<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a></p>
+<p><b>Discussion:</b></p>
+<pre> basic_filebuf *basic_filebuf::open(const char *, ios_base::open_mode);
+</pre>
+
+<p>should be supplemented with the overload:</p>
+
+<pre> basic_filebuf *basic_filebuf::open(const wchar_t *, ios_base::open_mode);
+</pre>
+
+<p>
+Depending on the operating system, one of these forms is fundamental and
+the other requires an implementation-defined mapping to determine the
+actual filename.
+</p>
+
+<p><i>[Sydney: Yes, we want to allow wchar_t filenames. Bill will
+ provide wording.]</i></p>
+
+
+<p><i>[
+In Toronto we noted that this is issue 5 from
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1569.htm">N1569</a>.
+]</i></p>
+
+<p>
+How does this interact with the newly-defined character types, and how
+do we avoid interface explosion considering <tt>std::string</tt> overloads that
+were added? Propose another solution that is different than the
+suggestion proposed by PJP.
+</p>
+<p>
+Suggestion is to make a member template function for <tt>basic_string</tt> (for
+<tt>char</tt>, <tt>wchar_t</tt>, <tt>u16char</tt>, <tt>u32char</tt> instantiations), and then just keep a
+<tt>const char*</tt> member.
+</p>
+<p>
+Goal is to do implicit conversion between character string literals to
+appropriate <tt>basic_string</tt> type. Not quite sure if this is possible.
+</p>
+<p>
+Implementors are free to add specific overloads for non-char character
+types.
+</p>
+
+<p><i>[
+Martin adds pre-Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+Please see <a href="http://wiki.dinkumware.com/twiki/pub/Wg21sophiaAntipolis/LibraryWorkingGroup/issue-454.html">issue 454: problems and solutions</a>.
+</blockquote>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+Beman is concerned that making these changes to <tt>basic_filebuf</tt> is not
+usefully changed unless <tt>fstream</tt> is also changed; this also only handles
+<tt>wchar_t</tt> and not other character types.
+</p>
+<p>
+The TR2 filesystem library is a more complete solution, but is not available soon.
+</p>
+</blockquote>
+
+<p><i>[
+Martin adds: please reference
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2683.html">N2683</a> for
+problems and solutions.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>Change from:</p>
+<blockquote>
+<pre>basic_filebuf<charT,traits>* open(
+ const char* s,
+ ios_base::openmode mode );
+</pre>
+
+<p>
+Effects: If is_open() != false, returns a null pointer.
+Otherwise, initializes the filebuf as required. It then
+opens a file, if possible, whose name is the NTBS s ("as if"
+by calling std::fopen(s,modstr)).</p>
+</blockquote>
+
+<p>to:</p>
+
+<blockquote>
+<pre>basic_filebuf<charT,traits>* open(
+ const char* s,
+ ios_base::openmode mode );
+
+basic_filebuf<charT,traits>* open(
+ const wchar_t* ws,
+ ios_base::openmode mode );
+</pre>
+
+<p>
+Effects: If is_open() != false, returns a null pointer.
+Otherwise, initializes the filebuf as required. It then
+opens a file, if possible, whose name is the NTBS s ("as if"
+by calling std::fopen(s,modstr)).
+For the second signature, the NTBS s is determined from the
+WCBS ws in an implementation-defined manner.
+</p>
+
+<p>
+(NOTE: For a system that "naturally" represents a filename
+as a WCBS, the NTBS s in the first signature may instead
+be mapped to a WCBS; if so, it follows the same mapping
+rules as the first argument to open.)
+</p>
+</blockquote>
+
+
+
+<p><b>Rationale:</b></p>
+<p>
+Slightly controversial, but by a 7-1 straw poll the LWG agreed to move
+this to Ready. The controversy was because the mapping between wide
+names and files in a filesystem is implementation defined. The
+counterargument, which most but not all LWG members accepted, is that
+the mapping between narrow files names and files is also
+implemenation defined.</p>
+
+<p><i>[Lillehammer: Moved back to "open" status, at Beman's urging.
+(1) Why just basic_filebuf, instead of also basic_fstream (and
+possibly other things too). (2) Why not also constructors that take
+std::basic_string? (3) We might want to wait until we see Beman's
+filesystem library; we might decide that it obviates this.]</i></p>
+
+
+<p><i>[
+post Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+Move again to Ready.
+</p>
+<p>
+There is a timing issue here. Since the filesystem library will not be
+in C++0x, this should be brought forward. This solution would remain
+valid in the context of the proposed filesystem.
+</p>
+<p>
+This issue has been kicking around for a while, and the wchar_t addition
+alone would help many users. Thus, we suggest putting this on the
+reflector list with an invitation for someone to produce proposed
+wording that covers basic_fstream. In the meantime, we suggest that the
+proposed wording be adopted as-is.
+</p>
+<p>
+If more of the Lillehammer questions come back, they should be
+introduced as separate issues.
+</p>
+</blockquote>
+
+
+
+
+
+
+
+
+<hr>
+<h3><a name="458"></a>458. 24.1.5 contains unintented limitation for operator-</h3>
+<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>
+ <b>Submitter:</b> Daniel Frey <b>Date:</b> 2004-02-27</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+In 24.1.5 [lib.random.access.iterators], table 76 the operational
+semantics for the expression "r -= n" are defined as "return r += -n".
+This means, that the expression -n must be valid, which is not the case
+for unsigned types.
+</p>
+
+<p><i>[
+Sydney: Possibly not a real problem, since difference type is required
+to be a signed integer type. However, the wording in the standard may
+be less clear than we would like.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+To remove this limitation, I suggest to change the
+operational semantics for this column to:
+</p>
+<blockquote><pre> { Distance m = n;
+ if (m >= 0)
+ while (m--) --r;
+ else
+ while (m++) ++r;
+ return r; }
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="459"></a>459. Requirement for widening in stage 2 is overspecification</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-03-16</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>When parsing strings of wide-character digits, the standard
+ requires the library to widen narrow-character "atoms" and compare
+ the widened atoms against the characters that are being parsed.
+ Simply narrowing the wide characters would be far simpler, and
+ probably more efficient. The two choices are equivalent except in
+ convoluted test cases, and many implementations already ignore the
+ standard and use narrow instead of widen.</p>
+
+<p>
+First, I disagree that using narrow() instead of widen() would
+necessarily have unfortunate performance implications. A possible
+implementation of narrow() that allows num_get to be implemented
+in a much simpler and arguably comparably efficient way as calling
+widen() allows, i.e. without making a virtual call to do_narrow every
+time, is as follows:
+</p>
+
+<pre> inline char ctype<wchar_t>::narrow (wchar_t wc, char dflt) const
+ {
+ const unsigned wi = unsigned (wc);
+
+ if (wi > UCHAR_MAX)
+ return typeid (*this) == typeid (ctype<wchar_t>) ?
+ dflt : do_narrow (wc, dflt);
+
+ if (narrow_ [wi] < 0) {
+ const char nc = do_narrow (wc, dflt);
+ if (nc == dflt)
+ return dflt;
+ narrow_ [wi] = nc;
+ }
+
+ return char (narrow_ [wi]);
+ }
+</pre>
+
+<p>
+Second, I don't think the change proposed in the issue (i.e., to use
+narrow() instead of widen() during Stage 2) would be at all
+drastic. Existing implementations with the exception of libstdc++
+currently already use narrow() so the impact of the change on programs
+would presumably be isolated to just a single implementation. Further,
+since narrow() is not required to translate alternate wide digit
+representations such as those mentioned in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a>
+to
+their narrow equivalents (i.e., the portable source characters '0'
+through '9'), the change does not necessarily imply that these
+alternate digits would be treated as ordinary digits and accepted as
+part of numbers during parsing. In fact, the requirement in 22.2.1.1.2
+[locale.ctype.virtuals], p13 forbids narrow() to translate an alternate
+digit character, wc, to an ordinary digit in the basic source
+character set unless the expression
+(ctype<charT>::is(ctype_base::digit, wc) == true) holds. This in
+turn is prohibited by the C standard (7.25.2.1.5, 7.25.2.1.5, and
+5.2.1, respectively) for charT of either char or wchar_t.
+</p>
+
+<p><i>[Sydney: To a large extent this is a nonproblem. As long as
+you're only trafficking in char and wchar_t we're only dealing with a
+stable character set, so you don't really need either 'widen' or
+'narrow': can just use literals. Finally, it's not even clear whether
+widen-vs-narrow is the right question; arguably we should be using
+codecvt instead.]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>Change stage 2 so that implementations are permitted to use either
+technique to perform the comparison:</p>
+<ol>
+ <li> call widen on the atoms and compare (either by using
+ operator== or char_traits<charT>::eq) the input with
+ the widened atoms, or</li>
+ <li> call narrow on the input and compare the narrow input
+ with the atoms</li>
+ <li> do (1) or (2) only if charT is not char or wchar_t,
+ respectively; i.e., avoid calling widen or narrow
+ if it the source and destination types are the same</li>
+</ol>
+
+
+
+
+
+<hr>
+<h3><a name="463"></a>463. auto_ptr usability issues</h3>
+<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>
+ <b>Submitter:</b> Rani Sharoni <b>Date:</b> 2003-12-07</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+
+<p>
+TC1 CWG DR #84 effectively made the template<class Y> operator auto_ptr<Y>()
+member of auto_ptr (20.4.5.3/4) obsolete.
+</p>
+
+<p>
+The sole purpose of this obsolete conversion member is to enable copy
+initialization base from r-value derived (or any convertible types like
+cv-types) case:
+</p>
+<pre>#include <memory>
+using std::auto_ptr;
+
+struct B {};
+struct D : B {};
+
+auto_ptr<D> source();
+int sink(auto_ptr<B>);
+int x1 = sink( source() ); // #1 EDG - no suitable copy constructor
+</pre>
+
+<p>
+The excellent analysis of conversion operations that was given in the final
+auto_ptr proposal
+(http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/1997/N1128.pdf)
+explicitly specifies this case analysis (case 4). DR #84 makes the analysis
+wrong and actually comes to forbid the loophole that was exploited by the
+auto_ptr designers.
+</p>
+
+<p>
+I didn't encounter any compliant compiler (e.g. EDG, GCC, BCC and VC) that
+ever allowed this case. This is probably because it requires 3 user defined
+conversions and in fact current compilers conform to DR #84.
+</p>
+
+<p>
+I was surprised to discover that the obsolete conversion member actually has
+negative impact of the copy initialization base from l-value derived
+case:</p>
+<pre>auto_ptr<D> dp;
+int x2 = sink(dp); // #2 EDG - more than one user-defined conversion applies
+</pre>
+
+<p>
+I'm sure that the original intention was allowing this initialization using
+the template<class Y> auto_ptr(auto_ptr<Y>& a) constructor (20.4.5.1/4) but
+since in this copy initialization it's merely user defined conversion (UDC)
+and the obsolete conversion member is UDC with the same rank (for the early
+overloading stage) there is an ambiguity between them.
+</p>
+
+<p>
+Removing the obsolete member will have impact on code that explicitly
+invokes it:
+</p>
+<pre>int y = sink(source().operator auto_ptr<B>());
+</pre>
+
+<p>
+IMHO no one ever wrote such awkward code and the reasonable workaround for
+#1 is:
+</p>
+<pre>int y = sink( auto_ptr<B>(source()) );
+</pre>
+
+<p>
+I was even more surprised to find out that after removing the obsolete
+conversion member the initialization was still ill-formed:
+int x3 = sink(dp); // #3 EDG - no suitable copy constructor
+</p>
+
+<p>
+This copy initialization semantically requires copy constructor which means
+that both template conversion constructor and the auto_ptr_ref conversion
+member (20.4.5.3/3) are required which is what was explicitly forbidden in
+DR #84. This is a bit amusing case in which removing ambiguity results with
+no candidates.
+</p>
+
+<p>
+I also found exception safety issue with auto_ptr related to auto_ptr_ref:
+</p>
+<pre>int f(auto_ptr<B>, std::string);
+auto_ptr<B> source2();
+
+// string constructor throws while auto_ptr_ref
+// "holds" the pointer
+int x4 = f(source2(), "xyz"); // #4
+</pre>
+
+<p>
+The theoretic execution sequence that will cause a leak:
+</p>
+<ol>
+<li>call auto_ptr<B>::operator auto_ptr_ref<B>()</li>
+<li>call string::string(char const*) and throw</li>
+</ol>
+
+<p>
+According to 20.4.5.3/3 and 20.4.5/2 the auto_ptr_ref conversion member
+returns auto_ptr_ref<Y> that holds *this and this is another defect since
+the type of *this is auto_ptr<X> where X might be different from Y. Several
+library vendors (e.g. SGI) implement auto_ptr_ref<Y> with Y* as member which
+is much more reasonable. Other vendor implemented auto_ptr_ref as
+defectively required and it results with awkward and catastrophic code:
+int oops = sink(auto_ptr<B>(source())); // warning recursive on all control
+paths
+</p>
+
+<p>
+Dave Abrahams noticed that there is no specification saying that
+auto_ptr_ref copy constructor can't throw.
+</p>
+
+<p>
+My proposal comes to solve all the above issues and significantly simplify
+auto_ptr implementation. One of the fundamental requirements from auto_ptr
+is that it can be constructed in an intuitive manner (i.e. like ordinary
+pointers) but with strict ownership semantics which yield that source
+auto_ptr in initialization must be non-const. My idea is to add additional
+constructor template with sole propose to generate ill-formed, diagnostic
+required, instance for const auto_ptr arguments during instantiation of
+declaration. This special constructor will not be instantiated for other
+types which is achievable using 14.8.2/2 (SFINAE). Having this constructor
+in hand makes the constructor template<class Y> auto_ptr(auto_ptr<Y> const&)
+legitimate since the actual argument can't be const yet non const r-value
+are acceptable.
+</p>
+
+<p>
+This implementation technique makes the "private auxiliary class"
+auto_ptr_ref obsolete and I found out that modern C++ compilers (e.g. EDG,
+GCC and VC) consume the new implementation as expected and allow all
+intuitive initialization and assignment cases while rejecting illegal cases
+that involve const auto_ptr arguments.
+</p>
+
+<p>The proposed auto_ptr interface:</p>
+
+<pre>namespace std {
+ template<class X> class auto_ptr {
+ public:
+ typedef X element_type;
+
+ // 20.4.5.1 construct/copy/destroy:
+ explicit auto_ptr(X* p=0) throw();
+ auto_ptr(auto_ptr&) throw();
+ template<class Y> auto_ptr(auto_ptr<Y> const&) throw();
+ auto_ptr& operator=(auto_ptr&) throw();
+ template<class Y> auto_ptr& operator=(auto_ptr<Y>) throw();
+ ~auto_ptr() throw();
+
+ // 20.4.5.2 members:
+ X& operator*() const throw();
+ X* operator->() const throw();
+ X* get() const throw();
+ X* release() throw();
+ void reset(X* p=0) throw();
+
+ private:
+ template<class U>
+ auto_ptr(U& rhs, typename
+unspecified_error_on_const_auto_ptr<U>::type = 0);
+ };
+}
+</pre>
+
+<p>
+One compliant technique to implement the unspecified_error_on_const_auto_ptr
+helper class is using additional private auto_ptr member class template like
+the following:
+</p>
+<pre>template<typename T> struct unspecified_error_on_const_auto_ptr;
+
+template<typename T>
+struct unspecified_error_on_const_auto_ptr<auto_ptr<T> const>
+{ typedef typename auto_ptr<T>::const_auto_ptr_is_not_allowed type; };
+</pre>
+
+<p>
+There are other techniques to implement this helper class that might work
+better for different compliers (i.e. better diagnostics) and therefore I
+suggest defining its semantic behavior without mandating any specific
+implementation. IMO, and I didn't found any compiler that thinks otherwise,
+14.7.1/5 doesn't theoretically defeat the suggested technique but I suggest
+verifying this with core language experts.
+</p>
+
+<p><b>Further changes in standard text:</b></p>
+<p>Remove section 20.4.5.3</p>
+
+<p>Change 20.4.5/2 to read something like:
+Initializing auto_ptr<X> from const auto_ptr<Y> will result with unspecified
+ill-formed declaration that will require unspecified diagnostic.</p>
+
+<p>Change 20.4.5.1/4,5,6 to read:</p>
+
+<pre>template<class Y> auto_ptr(auto_ptr<Y> const& a) throw();</pre>
+<p> 4 Requires: Y* can be implicitly converted to X*.</p>
+<p> 5 Effects: Calls const_cast<auto_ptr<Y>&>(a).release().</p>
+<p> 6 Postconditions: *this holds the pointer returned from a.release().</p>
+
+<p>Change 20.4.5.1/10</p>
+<pre>template<class Y> auto_ptr& operator=(auto_ptr<Y> a) throw();
+</pre>
+<p>
+10 Requires: Y* can be implicitly converted to X*. The expression delete
+get() is well formed.
+</p>
+
+<p>LWG TC DR #127 is obsolete.</p>
+
+<p>
+Notice that the copy constructor and copy assignment operator should remain
+as before and accept non-const auto_ptr& since they have effect on the form
+of the implicitly declared copy constructor and copy assignment operator of
+class that contains auto_ptr as member per 12.8/5,10:
+</p>
+<pre>struct X {
+ // implicit X(X&)
+ // implicit X& operator=(X&)
+ auto_ptr<D> aptr_;
+};
+</pre>
+
+<p>
+In most cases this indicates about sloppy programming but preserves the
+current auto_ptr behavior.
+</p>
+
+<p>
+Dave Abrahams encouraged me to suggest fallback implementation in case that
+my suggestion that involves removing of auto_ptr_ref will not be accepted.
+In this case removing the obsolete conversion member to auto_ptr<Y> and
+20.4.5.3/4,5 is still required in order to eliminate ambiguity in legal
+cases. The two constructors that I suggested will co exist with the current
+members but will make auto_ptr_ref obsolete in initialization contexts.
+auto_ptr_ref will be effective in assignment contexts as suggested in DR
+#127 and I can't see any serious exception safety issues in those cases
+(although it's possible to synthesize such). auto_ptr_ref<X> semantics will
+have to be revised to say that it strictly holds pointer of type X and not
+reference to an auto_ptr for the favor of cases in which auto_ptr_ref<Y> is
+constructed from auto_ptr<X> in which X is different from Y (i.e. assignment
+from r-value derived to base).
+</p>
+
+<p><i>[Redmond: punt for the moment. We haven't decided yet whether we
+ want to fix auto_ptr for C++-0x, or remove it and replace it with
+ move_ptr and unique_ptr.]</i></p>
+
+
+<p><i>[
+Oxford 2007: Recommend NAD. We're just going to deprecate it. It still works for simple use cases
+and people know how to deal with it. Going forward <tt>unique_ptr</tt> is the recommended
+tool.
+]</i></p>
+
+
+<p><i>[
+2007-11-09: Reopened at the request of David Abrahams, Alisdair Meredith and Gabriel Dos Reis.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis in D.9.1 [auto.ptr]:
+</p>
+
+<blockquote><pre>namespace std {
+ <del>template <class Y> struct auto_ptr_ref {};</del>
+
+ <ins>// exposition only</ins>
+ <ins>template <class T> struct constant_object;</ins>
+
+ <ins>// exposition only</ins>
+ <ins>template <class T></ins>
+ <ins>struct cannot_transfer_ownership_from</ins>
+ <ins>: constant_object<T> {};</ins>
+
+ template <class X> class auto_ptr {
+ public:
+ typedef X element_type;
+
+ // D.9.1.1 construct/copy/destroy:
+ explicit auto_ptr(X* p =0) throw();
+ auto_ptr(auto_ptr&) throw();
+ template<class Y> auto_ptr(auto_ptr<Y><ins> const</ins>&) throw();
+ auto_ptr& operator=(auto_ptr&) throw();
+ template<class Y> auto_ptr& operator=(auto_ptr<Y><del>&</del>) throw();
+ <del>auto_ptr& operator=(auto_ptr_ref<X> r) throw();</del>
+ ~auto_ptr() throw();
+
+ // D.9.1.2 members:
+ X& operator*() const throw();
+ X* operator->() const throw();
+ X* get() const throw();
+ X* release() throw();
+ void reset(X* p =0) throw();
+
+ <del>// D.9.1.3 conversions:</del>
+ <del>auto_ptr(auto_ptr_ref<X>) throw();</del>
+ <del>template<class Y> operator auto_ptr_ref<Y>() throw();</del>
+ <del>template<class Y> operator auto_ptr<Y>() throw();</del>
+
+ <ins>// exposition only</ins>
+ <ins>template<class U></ins>
+ <ins>auto_ptr(U& rhs, typename cannot_transfer_ownership_from<U>::error = 0);</ins>
+ };
+
+ template <> class auto_ptr<void>
+ {
+ public:
+ typedef void element_type;
+ };
+
+}
+</pre></blockquote>
+
+<p>
+Remove D.9.1.3 [auto.ptr.conv].
+</p>
+
+<p>
+Change D.9.1 [auto.ptr], p3:
+</p>
+
+<blockquote>
+The <tt>auto_ptr</tt> provides a semantics of strict ownership. An
+<tt>auto_ptr</tt> owns the object it holds a pointer to. Copying an
+<tt>auto_ptr</tt> copies the pointer and transfers ownership to the
+destination. If more than one <tt>auto_ptr</tt> owns the same object at
+the same time the behavior of the program is undefined. <ins>Templates
+<tt>constant_object</tt> and <tt>cannot_transfer_ownership_from</tt>,
+and the final constructor of <tt>auto_ptr</tt> are for exposition only.
+For any types <tt>X</tt> and <tt>Y</tt>, initializing
+<tt>auto_ptr<X></tt> from <tt>const auto_ptr<Y></tt> is
+ill-formed, diagnostic required.</ins> [<i>Note:</i> The uses of
+<tt>auto_ptr</tt> include providing temporary exception-safety for
+dynamically allocated memory, passing ownership of dynamically allocated
+memory to a function, and returning dynamically allocated memory from a
+function. <tt>auto_ptr</tt> does not meet the <tt>CopyConstructible</tt>
+and <tt>Assignable</tt> requirements for Standard Library container
+elements and thus instantiating a Standard Library container with an
+<tt>auto_ptr</tt> results in undefined behavior. <i>-- end note</i>]
+</blockquote>
+
+<p>
+Change D.9.1.1 [auto.ptr.cons], p5:
+</p>
+
+<blockquote>
+<pre>template<class Y> auto_ptr(auto_ptr<Y><ins> const</ins>& a) throw();
+</pre>
+<blockquote>
+<p>
+<i>Requires:</i> <tt>Y*</tt> can be implicitly converted to <tt>X*</tt>.
+</p>
+<p>
+<i>Effects:</i> Calls <ins><tt>const_cast<auto_ptr<Y>&>(</tt></ins><tt>a</tt><ins><tt>)</tt></ins><tt>.release()</tt>.
+</p>
+<p>
+<i>Postconditions:</i> <tt>*this</tt> holds the pointer returned from <tt>a.release()</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+Change D.9.1.1 [auto.ptr.cons], p10:
+</p>
+
+<blockquote>
+<pre>template<class Y> auto_ptr& operator=(auto_ptr<Y><del>&</del> a) throw();
+</pre>
+<blockquote>
+<p>
+<i>Requires:</i> <tt>Y*</tt> can be implicitly converted to <tt>X*</tt>.
+The expression <tt>delete get()</tt> is well formed.
+</p>
+<p>
+<i>Effects:</i> Calls <tt>reset(a.release())</tt>.
+</p>
+<p>
+<i>Returns:</i> <tt>*this</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="471"></a>471. result of what() implementation-defined</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-28</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+
+<p>[lib.exception] specifies the following:</p>
+<pre> exception (const exception&) throw();
+ exception& operator= (const exception&) throw();
+
+ -4- Effects: Copies an exception object.
+ -5- Notes: The effects of calling what() after assignment
+ are implementation-defined.
+</pre>
+
+<p>
+First, does the Note only apply to the assignment operator? If so,
+what are the effects of calling what() on a copy of an object? Is
+the returned pointer supposed to point to an identical copy of
+the NTBS returned by what() called on the original object or not?
+</p>
+
+<p>
+Second, is this Note intended to extend to all the derived classes
+in section 19? I.e., does the standard provide any guarantee for
+the effects of what() called on a copy of any of the derived class
+described in section 19?
+</p>
+
+<p>
+Finally, if the answer to the first question is no, I believe it
+constitutes a defect since throwing an exception object typically
+implies invoking the copy ctor on the object. If the answer is yes,
+then I believe the standard ought to be clarified to spell out
+exactly what the effects are on the copy (i.e., after the copy
+ctor was called).
+</p>
+
+<p><i>[Redmond: Yes, this is fuzzy. The issue of derived classes is
+ fuzzy too.]</i></p>
+
+
+<p><i>[
+Batavia: Howard provided wording.
+]</i></p>
+
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+Eric concerned this is unimplementable, due to nothrow guarantees.
+Suggested implementation would involve reference counting.
+</p>
+<p>
+Is the implied reference counting subtle enough to call out a note on
+implementation? Probably not.
+</p>
+<p>
+If reference counting required, could we tighten specification further
+to require same pointer value? Probably an overspecification, especially
+if exception classes defer evalutation of final string to calls to
+what().
+</p>
+<p>
+Remember issue moved open and not resolved at Batavia, but cannot
+remember who objected to canvas a disenting opinion - please speak up if
+you disagree while reading these minutes!
+</p>
+<p>
+Move to Ready as we are accepting words unmodified.
+</p>
+</blockquote>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+The issue was pulled from Ready. It needs to make clear that only homogenous copying
+is intended to be supported. Not coping from a dervied to a base.
+</blockquote>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+Change 18.7.1 [exception] to:
+</p>
+
+<blockquote>
+<pre>exception(const exception& <ins><i>e</i></ins>) throw();
+exception& operator=(const exception& <ins><i>e</i></ins>) throw();</pre>
+<blockquote>
+<p>
+-4- <i>Effects:</i> Copies an exception object.
+</p>
+<p>
+<del> -5- <i>Remarks:</i> The effects of calling what() after assignment are implementation-defined.</del>
+</p>
+<p>
+<ins>-5- <i>Throws:</i> Nothing. This also applies
+to all standard library-defined classes that derive from <tt>exception</tt>.</ins>
+</p>
+<p>
+<ins>-7- <i>Postcondition:</i> <tt>strcmp(what(), <i>e</i>.what()) == 0</tt>. This also applies
+to all standard library-defined classes that derive from <tt>exception</tt>.</ins>
+</p>
+
+</blockquote>
+</blockquote>
+
+
+
+
+<hr>
+<h3><a name="473"></a>473. underspecified ctype calls</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-07-01</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+Most ctype member functions come in two forms: one that operates
+on a single character at a time and another form that operates
+on a range of characters. Both forms are typically described by
+a single Effects and/or Returns clause.
+</p>
+<p>
+The Returns clause of each of the single-character non-virtual forms
+suggests that the function calls the corresponding single character
+virtual function, and that the array form calls the corresponding
+virtual array form. Neither of the two forms of each virtual member
+function is required to be implemented in terms of the other.
+</p>
+<p>
+There are three problems:
+</p>
+<p>
+1. One is that while the standard does suggest that each non-virtual
+member function calls the corresponding form of the virtual function,
+it doesn't actually explicitly require it.
+</p>
+<p>
+Implementations that cache results from some of the virtual member
+functions for some or all values of their arguments might want to
+call the array form from the non-array form the first time to fill
+the cache and avoid any or most subsequent virtual calls. Programs
+that rely on each form of the virtual function being called from
+the corresponding non-virtual function will see unexpected behavior
+when using such implementations.
+</p>
+<p>
+2. The second problem is that either form of each of the virtual
+functions can be overridden by a user-defined function in a derived
+class to return a value that is different from the one produced by
+the virtual function of the alternate form that has not been
+overriden.
+</p>
+<p>
+Thus, it might be possible for, say, ctype::widen(c) to return one
+value, while for ctype::widen(&c, &c + 1, &wc) to set
+wc to another value. This is almost certainly not intended. Both
+forms of every function should be required to return the same result
+for the same character, otherwise the same program using an
+implementation that calls one form of the functions will behave
+differently than when using another implementation that calls the
+other form of the function "under the hood."
+</p>
+<p>
+3. The last problem is that the standard text fails to specify whether
+one form of any of the virtual functions is permitted to be implemented
+in terms of the other form or not, and if so, whether it is required
+or permitted to call the overridden virtual function or not.
+</p>
+<p>
+Thus, a program that overrides one of the virtual functions so that
+it calls the other form which then calls the base member might end
+up in an infinite loop if the called form of the base implementation
+of the function in turn calls the other form.
+</p>
+<p>
+Lillehammer: Part of this isn't a real problem. We already talk about
+caching. 22.1.1/6 But part is a real problem. ctype virtuals may call
+each other, so users don't know which ones to override to avoid avoid
+infinite loops.</p>
+
+<p>This is a problem for all facet virtuals, not just ctype virtuals,
+so we probably want a blanket statement in clause 22 for all
+facets. The LWG is leaning toward a blanket prohibition, that a
+facet's virtuals may never call each other. We might want to do that
+in clause 27 too, for that matter. A review is necessary. Bill will
+provide wording.</p>
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+<hr>
+<h3><a name="484"></a>484. Convertible to T</h3>
+<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>
+ <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2004-09-16</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>From comp.std.c++:</p>
+
+<p>
+I note that given an input iterator a for type T,
+then *a only has to be "convertable to T", not actually of type T.
+</p>
+
+<p>Firstly, I can't seem to find an exact definition of "convertable to T".
+While I assume it is the obvious definition (an implicit conversion), I
+can't find an exact definition. Is there one?</p>
+
+<p>Slightly more worryingly, there doesn't seem to be any restriction on
+the this type, other than it is "convertable to T". Consider two input
+iterators a and b. I would personally assume that most people would
+expect *a==*b would perform T(*a)==T(*b), however it doesn't seem that
+the standard requires that, and that whatever type *a is (call it U)
+could have == defined on it with totally different symantics and still
+be a valid inputer iterator.</p>
+
+<p>Is this a correct reading? When using input iterators should I write
+T(*a) all over the place to be sure that the object i'm using is the
+class I expect?</p>
+
+<p>This is especially a nuisance for operations that are defined to be
+ "convertible to bool". (This is probably allowed so that
+ implementations could return say an int and avoid an unnessary
+ conversion. However all implementations I have seen simply return a
+ bool anyway. Typical implemtations of STL algorithms just write
+ things like <tt>while(a!=b && *a!=0)</tt>. But strictly
+ speaking, there are lots of types that are convertible to T but
+ that also overload the appropriate operators so this doesn't behave
+ as expected.</p>
+
+<p>If we want to make code like this legal (which most people seem to
+ expect), then we'll need to tighten up what we mean by "convertible
+ to T".</p>
+
+<p><i>[Lillehammer: The first part is NAD, since "convertible" is
+ well-defined in core. The second part is basically about pathological
+ overloads. It's a minor problem but a real one. So leave open for
+ now, hope we solve it as part of iterator redesign.]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="485"></a>485. output iterator insufficently constrained</h3>
+<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>
+ <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2004-10-13</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The note on 24.1.2 Output iterators insufficently limits what can be
+performed on output iterators. While it requires that each iterator is
+progressed through only once and that each iterator is written to only
+once, it does not require the following things:</p>
+
+<p>Note: Here it is assumed that x is an output iterator of type X which
+has not yet been assigned to.</p>
+
+<p>a) That each value of the output iterator is written to:
+The standard allows:
+++x; ++x; ++x;
+</p>
+
+<p>
+b) That assignments to the output iterator are made in order
+X a(x); ++a; *a=1; *x=2; is allowed
+</p>
+
+<p>
+c) Chains of output iterators cannot be constructed:
+X a(x); ++a; X b(a); ++b; X c(b); ++c; is allowed, and under the current
+wording (I believe) x,a,b,c could be written to in any order.
+</p>
+
+<p>I do not believe this was the intension of the standard?</p>
+<p><i>[Lillehammer: Real issue. There are lots of constraints we
+ intended but didn't specify. Should be solved as part of iterator
+ redesign.]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="492"></a>492. Invalid iterator arithmetic expressions</h3>
+<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>
+ <b>Submitter:</b> Thomas Mang <b>Date:</b> 2004-12-12</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>Various clauses other than clause 25 make use of iterator arithmetic not
+supported by the iterator category in question.
+Algorithms in clause 25 are exceptional because of 25 [lib.algorithms],
+paragraph 9, but this paragraph does not provide semantics to the
+expression "iterator - n", where n denotes a value of a distance type
+between iterators.</p>
+
+<p>1) Examples of current wording:</p>
+
+<p>Current wording outside clause 25:</p>
+
+<p>
+23.2.2.4 [lib.list.ops], paragraphs 19-21: "first + 1", "(i - 1)",
+"(last - first)"
+23.3.1.1 [lib.map.cons], paragraph 4: "last - first"
+23.3.2.1 [lib.multimap.cons], paragraph 4: "last - first"
+23.3.3.1 [lib.set.cons], paragraph 4: "last - first"
+23.3.4.1 [lib.multiset.cons], paragraph 4: "last - first"
+24.4.1 [lib.reverse.iterators], paragraph 1: "(i - 1)"
+</p>
+
+<p>
+[Important note: The list is not complete, just an illustration. The
+same issue might well apply to other paragraphs not listed here.]</p>
+
+<p>None of these expressions is valid for the corresponding iterator
+category.</p>
+
+<p>Current wording in clause 25:</p>
+
+<p>
+25.1.1 [lib.alg.foreach], paragraph 1: "last - 1"
+25.1.3 [lib.alg.find.end], paragraph 2: "[first1, last1 -
+(last2-first2))"
+25.2.8 [lib.alg.unique], paragraph 1: "(i - 1)"
+25.2.8 [lib.alg.unique], paragraph 5: "(i - 1)"
+</p>
+
+<p>
+However, current wording of 25 [lib.algorithms], paragraph 9 covers
+neither of these four cases:</p>
+
+<p>Current wording of 25 [lib.algorithms], paragraph 9:</p>
+
+<p>
+"In the description of the algorithms operator + and - are used for some
+of the iterator categories for which they do not have to be defined. In
+these cases the semantics of a+n is the same as that of</p>
+<pre>{X tmp = a;
+advance(tmp, n);
+return tmp;
+}
+</pre>
+<p>and that of b-a is the same as of return distance(a, b)"</p>
+
+<p>
+This paragrpah does not take the expression "iterator - n" into account,
+where n denotes a value of a distance type between two iterators [Note:
+According to current wording, the expression "iterator - n" would be
+resolved as equivalent to "return distance(n, iterator)"]. Even if the
+expression "iterator - n" were to be reinterpreted as equivalent to
+"iterator + -n" [Note: This would imply that "a" and "b" were
+interpreted implicitly as values of iterator types, and "n" as value of
+a distance type], then 24.3.4/2 interfers because it says: "Requires: n
+may be negative only for random access and bidirectional iterators.",
+and none of the paragraphs quoted above requires the iterators on which
+the algorithms operate to be of random access or bidirectional category.
+</p>
+
+<p>2) Description of intended behavior:</p>
+
+<p>
+For the rest of this Defect Report, it is assumed that the expression
+"iterator1 + n" and "iterator1 - iterator2" has the semantics as
+described in current 25 [lib.algorithms], paragraph 9, but applying to
+all clauses. The expression "iterator1 - n" is equivalent to an
+result-iterator for which the expression "result-iterator + n" yields an
+iterator denoting the same position as iterator1 does. The terms
+"iterator1", "iterator2" and "result-iterator" shall denote the value of
+an iterator type, and the term "n" shall denote a value of a distance
+type between two iterators.</p>
+
+<p>
+All implementations known to the author of this Defect Report comply
+with these assumptions.
+No impact on current code is expected.</p>
+
+<p>3) Proposed fixes:</p>
+
+
+<p>Change 25 [lib.algorithms], paragraph 9 to:</p>
+
+<p>
+"In the description of the algorithms operator + and - are used for some
+of the iterator categories for which they do not have to be defined. In
+this paragraph, a and b denote values of an iterator type, and n denotes
+a value of a distance type between two iterators. In these cases the
+semantics of a+n is the same as that of</p>
+<pre>{X tmp = a;
+advance(tmp, n);
+return tmp;
+}
+</pre>
+<p>,the semantics of a-n denotes the value of an iterator i for which the
+following condition holds:
+advance(i, n) == a,
+and that of b-a is the same as of
+return distance(a, b)".
+</p>
+
+<p>Comments to the new wording:</p>
+
+<p>
+a) The wording " In this paragraph, a and b denote values of an iterator
+type, and n denotes a value of a distance type between two iterators."
+was added so the expressions "b-a" and "a-n" are distinguished regarding
+the types of the values on which they operate.
+b) The wording ",the semantics of a-n denotes the value of an iterator i
+for which the following condition holds: advance(i, n) == a" was added
+to cover the expression 'iterator - n'. The wording "advance(i, n) == a"
+was used to avoid a dependency on the semantics of a+n, as the wording
+"i + n == a" would have implied. However, such a dependency might well
+be deserved.
+c) DR 225 is not considered in the new wording.
+</p>
+
+<p>
+Proposed fixes regarding invalid iterator arithmetic expressions outside
+clause 25:</p>
+
+<p>
+Either
+a) Move modified 25 [lib.algorithms], paragraph 9 (as proposed above)
+before any current invalid iterator arithmetic expression. In that case,
+the first sentence of 25 [lib.algorithms], paragraph 9, need also to be
+modified and could read: "For the rest of this International Standard,
+...." / "In the description of the following clauses including this
+...." / "In the description of the text below ..." etc. - anyways
+substituting the wording "algorithms", which is a straight reference to
+clause 25.
+In that case, 25 [lib.algorithms] paragraph 9 will certainly become
+obsolete.
+Alternatively,
+b) Add an appropiate paragraph similar to resolved 25 [lib.algorithms],
+paragraph 9, to the beginning of each clause containing invalid iterator
+arithmetic expressions.
+Alternatively,
+c) Fix each paragraph (both current wording and possible resolutions of
+DRs) containing invalid iterator arithmetic expressions separately.
+</p>
+
+<p>5) References to other DRs:</p>
+
+<p>
+See DR 225.
+See DR 237. The resolution could then also read "Linear in last -
+first".
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Keep open and ask Bill to provide wording.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p><i>[Lillehammer: Minor issue, but real. We have a blanket statement
+about this in 25/11. But (a) it should be in 17, not 25; and (b) it's
+not quite broad enough, because there are some arithmetic expressions
+it doesn't cover. Bill will provide wording.]</i></p>
+
+
+
+
+
+
+
+<hr>
+<h3><a name="498"></a>498. Requirements for partition() and stable_partition() too strong</h3>
+<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>
+ <b>Submitter:</b> Sean Parent, Joe Gottman <b>Date:</b> 2005-05-04</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+Problem:
+The iterator requirements for partition() and stable_partition() [25.2.12]
+are listed as BidirectionalIterator, however, there are efficient algorithms
+for these functions that only require ForwardIterator that have been known
+since before the standard existed. The SGI implementation includes these (see
+<a href="http://www.sgi.com/tech/stl/partition.html">http://www.sgi.com/tech/stl/partition.html</a>
+and
+<a href="http://www.sgi.com/tech/stl/stable_partition.html">http://www.sgi.com/tech/stl/stable_partition.html</a>).
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 25.2.12 from </p>
+<blockquote><pre>template<class BidirectionalIterator, class Predicate>
+BidirectionalIterator partition(BidirectionalIterato r first,
+ BidirectionalIterator last,
+ Predicate pred);
+</pre></blockquote>
+<p>to </p>
+<blockquote><pre>template<class ForwardIterator, class Predicate>
+ForwardIterator partition(ForwardIterator first,
+ ForwardIterator last,
+ Predicate pred);
+</pre></blockquote>
+<p>Change the complexity from </p>
+
+<blockquote><p>
+At most (last - first)/2 swaps are done. Exactly (last - first)
+applications of the predicate are done.
+</p></blockquote>
+
+<p>to </p>
+
+<blockquote><p>
+If ForwardIterator is a bidirectional_iterator, at most (last - first)/2
+swaps are done; otherwise at most (last - first) swaps are done. Exactly
+(last - first) applications of the predicate are done.
+</p></blockquote>
+
+
+
+<p><b>Rationale:</b></p>
+<p>
+Partition is a "foundation" algorithm useful in many contexts (like sorting
+as just one example) - my motivation for extending it to include forward
+iterators is slist - without this extension you can't partition an slist
+(without writing your own partition). Holes like this in the standard
+library weaken the argument for generic programming (ideally I'd be able
+to provide a library that would refine std::partition() to other concepts
+without fear of conflicting with other libraries doing the same - but
+that is a digression). I consider the fact that partition isn't defined
+to work for ForwardIterator a minor embarrassment.
+</p>
+
+<p><i>[Mont Tremblant: Moved to Open, request motivation and use cases
+by next meeting. Sean provided further rationale by post-meeting
+mailing.]</i></p>
+
+
+
+
+
+
+
+<hr>
+<h3><a name="502"></a>502. Proposition: Clarification of the interaction between a facet and an iterator</h3>
+<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>
+ <b>Submitter:</b> Christopher Conrade Zseleghovski <b>Date:</b> 2005-06-07</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+Motivation:
+</p>
+
+<p>
+This requirement seems obvious to me, it is the essence of code modularity.
+I have complained to Mr. Plauger that the Dinkumware library does not
+observe this principle but he objected that this behaviour is not covered in
+the standard.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Append the following point to 22.1.1.1.1:
+</p>
+
+<p>
+6. The implementation of a facet of Table 52 parametrized with an
+InputIterator/OutputIterator should use that iterator only as character
+source/sink respectively.
+For a *_get facet, it means that the value received depends only on the
+sequence of input characters and not on how they are accessed.
+For a *_put facet, it means that the sequence of characters output depends
+only on the value to be formatted and not of how the characters are stored.
+</p>
+
+<p><i>[
+Berlin: Moved to Open, Need to clean up this area to make it clear
+locales don't have to contain open ended sets of facets. Jack, Howard,
+Bill.
+]</i></p>
+
+
+
+
+
+
+
+<hr>
+<h3><a name="503"></a>503. more on locales</h3>
+<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>
+ <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2005-06-20</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+a) In 22.2.1.1 para. 2 we refer to "the instantiations required in Table
+51" to refer to the facet *objects* associated with a locale. And we
+almost certainly mean just those associated with the default or "C"
+locale. Otherwise, you can't switch to a locale that enforces a different
+mapping between narrow and wide characters, or that defines additional
+uppercase characters.
+</p>
+
+<p>
+b) 22.2.1.5 para. 3 (codecvt) has the same issues.
+</p>
+
+<p>
+c) 22.2.1.5.2 (do_unshift) is even worse. It *forbids* the generation of
+a homing sequence for the basic character set, which might very well need
+one.
+</p>
+
+<p>
+d) 22.2.1.5.2 (do_length) likewise dictates that the default mapping
+between wide and narrow characters be taken as one-for-one.
+</p>
+
+<p>
+e) 22.2.2 para. 2 (num_get/put) is both muddled and vacuous, as far as
+I can tell. The muddle is, as before, calling Table 51 a list of
+instantiations. But the constraint it applies seems to me to cover
+*all* defined uses of num_get/put, so why bother to say so?
+</p>
+
+<p>
+f) 22.2.3.1.2 para. 1(do_decimal_point) says "The required instantiations
+return '.' or L'.'.) Presumably this means "as appropriate for the
+character type. But given the vague definition of "required" earlier,
+this overrules *any* change of decimal point for non "C" locales.
+Surely we don't want to do that.
+</p>
+
+<p>
+g) 22.2.3.1.2 para. 2 (do_thousands_sep) says "The required instantiations
+return ',' or L','.) As above, this probably means "as appropriate for the
+character type. But this overrules the "C" locale, which requires *no*
+character ('\0') for the thousands separator. Even if we agree that we
+don't mean to block changes in decimal point or thousands separator,
+we should also eliminate this clear incompatibility with C.
+</p>
+
+<p>
+h) 22.2.3.1.2 para. 2 (do_grouping) says "The required instantiations
+return the empty string, indicating no grouping." Same considerations
+as for do_decimal_point.
+</p>
+
+<p>
+i) 22.2.4.1 para. 1 (collate) refers to "instantiations required in Table
+51". Same bad jargon.
+</p>
+
+<p>
+j) 22.2.4.1.2 para. 1 (do_compare) refers to "instantiations required
+in Table 51". Same bad jargon.
+</p>
+
+<p>
+k) 22.2.5 para. 1 (time_get/put) uses the same muddled and vacuous
+as num_get/put.
+</p>
+
+<p>
+l) 22.2.6 para. 2 (money_get/put) uses the same muddled and vacuous
+as num_get/put.
+</p>
+
+<p>
+m) 22.2.6.3.2 (do_pos/neg_format) says "The instantiations required
+in Table 51 ... return an object of type pattern initialized to
+{symbol, sign, none, value}." This once again *overrides* the "C"
+locale, as well as any other locale."
+</p>
+
+<p>
+3) We constrain the use_facet calls that can be made by num_get/put,
+so why don't we do the same for money_get/put? Or for any of the
+other facets, for that matter?
+</p>
+
+<p>
+4) As an almost aside, we spell out when a facet needs to use the ctype
+facet, but several also need to use a codecvt facet and we don't say so.
+</p>
+<p><i>[
+Berlin: Bill to provide wording.
+]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="522"></a>522. Tuple doesn't define swap</h3>
+<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>
+ <b>Submitter:</b> Andy Koenig <b>Date:</b> 2005-07-03</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+Tuple doesn't define swap(). It should.
+</p>
+<p><i>[
+Berlin: Doug to provide wording.
+]</i></p>
+
+<p><i>[
+Batavia: Howard to provide wording.
+]</i></p>
+
+<p><i>[
+Toronto: Howard to provide wording (really this time).
+]</i></p>
+
+
+<p><i>[
+Bellevue: Alisdair provided wording.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+Add these signatures to 20.4 [tuple]
+</p>
+
+<blockquote><pre>template <class... Types>
+ void swap(tuple<Types...>& x, tuple<Types...>& y);
+template <class... Types>
+ void swap(tuple<Types...>&& x, tuple<Types...>& y);
+template <class... Types>
+ void swap(tuple<Types...>& x, tuple<Types...>&& y);
+</pre></blockquote>
+
+<p>
+Add this signature to 20.4.1 [tuple.tuple]
+</p>
+
+<blockquote><pre>void swap(tuple&&);
+</pre></blockquote>
+
+<p>
+Add the following two sections to the end of the tuple clauses
+</p>
+
+<blockquote>
+<p>
+20.3.1.7 tuple swap [tuple.swap]
+</p>
+
+<pre>void swap(tuple&& rhs);
+</pre>
+
+<blockquote>
+<p>
+<i>Requires:</i> Each type in <tt>Types</tt> shall be <tt>Swappable</tt>.
+</p>
+<p>
+<i>Effects:</i> Calls <tt>swap</tt> for each element in <tt>*this</tt> and its corresponding element
+in <tt>rhs</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing, unless one of the element-wise <tt>swap</tt> calls throw an
+exception.
+</p>
+</blockquote>
+
+<p>
+20.3.1.8 tuple specialized algorithms [tuple.special]
+</p>
+
+<pre>template <class... Types>
+ void swap(tuple<Types...>& x, tuple<Types...>& y);
+template <class... Types>
+ void swap(tuple<Types...>&& x, tuple<Types...>& y);
+template <class... Types>
+ void swap(tuple<Types...>& x, tuple<Types...>&& y);
+</pre>
+
+<blockquote>
+<p>
+<i>Effects:</i> x.swap(y)
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="523"></a>523. regex case-insensitive character ranges are unimplementable as specified</h3>
+<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>
+ <b>Submitter:</b> Eric Niebler <b>Date:</b> 2005-07-01</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+A problem with TR1 regex is currently being discussed on the Boost
+developers list. It involves the handling of case-insensitive matching
+of character ranges such as [Z-a]. The proper behavior (according to the
+ECMAScript standard) is unimplementable given the current specification
+of the TR1 regex_traits<> class template. John Maddock, the author of
+the TR1 regex proposal, agrees there is a problem. The full discussion
+can be found at http://lists.boost.org/boost/2005/06/28850.php (first
+message copied below). We don't have any recommendations as yet.
+</p>
+<p>
+-- Begin original message --
+</p>
+<p>
+The situation of interest is described in the ECMAScript specification
+(ECMA-262), section 15.10.2.15:
+</p>
+<p>
+"Even if the pattern ignores case, the case of the two ends of a range
+is significant in determining which characters belong to the range.
+Thus, for example, the pattern /[E-F]/i matches only the letters E, F,
+e, and f, while the pattern /[E-f]/i matches all upper and lower-case
+ASCII letters as well as the symbols [, \, ], ^, _, and `."
+</p>
+<p>
+A more interesting case is what should happen when doing a
+case-insentitive match on a range such as [Z-a]. It should match z, Z,
+a, A and the symbols [, \, ], ^, _, and `. This is not what happens with
+Boost.Regex (it throws an exception from the regex constructor).
+</p>
+<p>
+The tough pill to swallow is that, given the specification in TR1, I
+don't think there is any effective way to handle this situation.
+According to the spec, case-insensitivity is handled with
+regex_traits<>::translate_nocase(CharT) -- two characters are equivalent
+if they compare equal after both are sent through the translate_nocase
+function. But I don't see any way of using this translation function to
+make character ranges case-insensitive. Consider the difficulty of
+detecting whether "z" is in the range [Z-a]. Applying the transformation
+to "z" has no effect (it is essentially std::tolower). And we're not
+allowed to apply the transformation to the ends of the range, because as
+ECMA-262 says, "the case of the two ends of a range is significant."
+</p>
+<p>
+So AFAICT, TR1 regex is just broken, as is Boost.Regex. One possible fix
+is to redefine translate_nocase to return a string_type containing all
+the characters that should compare equal to the specified character. But
+this function is hard to implement for Unicode, and it doesn't play nice
+with the existing ctype facet. What a mess!
+</p>
+<p>
+-- End original message --
+</p>
+
+<p><i>[
+John Maddock adds:
+]</i></p>
+
+
+<p>
+One small correction, I have since found that ICU's regex package does
+implement this correctly, using a similar mechanism to the current
+TR1.Regex.
+</p>
+<p>
+Given an expression [c1-c2] that is compiled as case insensitive it:
+</p>
+<p>
+Enumerates every character in the range c1 to c2 and converts it to it's
+case folded equivalent. That case folded character is then used a key to a
+table of equivalence classes, and each member of the class is added to the
+list of possible matches supported by the character-class. This second step
+isn't possible with our current traits class design, but isn't necessary if
+the input text is also converted to a case-folded equivalent on the fly.
+</p>
+<p>
+ICU applies similar brute force mechanisms to character classes such as
+[[:lower:]] and [[:word:]], however these are at least cached, so the impact
+is less noticeable in this case.
+</p>
+<p>
+Quick and dirty performance comparisons show that expressions such as
+"[X-\\x{fff0}]+" are indeed very slow to compile with ICU (about 200 times
+slower than a "normal" expression). For an application that uses a lot of
+regexes this could have a noticeable performance impact. ICU also has an
+advantage in that it knows the range of valid characters codes: code points
+outside that range are assumed not to require enumeration, as they can not
+be part of any equivalence class. I presume that if we want the TR1.Regex
+to work with arbitrarily large character sets enumeration really does become
+impractical.
+</p>
+<p>
+Finally note that Unicode has:
+</p>
+<p>
+Three cases (upper, lower and title).
+One to many, and many to one case transformations.
+Character that have context sensitive case translations - for example an
+uppercase sigma has two different lowercase forms - the form chosen depends
+on context(is it end of a word or not), a caseless match for an upper case
+sigma should match either of the lower case forms, which is why case folding
+is often approximated by tolower(toupper(c)).
+</p>
+<p>
+Probably we need some way to enumerate character equivalence classes,
+including digraphs (either as a result or an input), and some way to tell
+whether the next character pair is a valid digraph in the current locale.
+</p>
+<p>
+Hoping this doesn't make this even more complex that it was already,
+</p>
+
+<p><i>[
+Portland: Alisdair: Detect as invalid, throw an exception.
+Pete: Possible general problem with case insensitive ranges.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="539"></a>539. partial_sum and adjacent_difference should mention requirements</h3>
+<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>
+ <b>Submitter:</b> Marc Schoolderman <b>Date:</b> 2006-02-06</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+There are some problems in the definition of partial_sum and
+adjacent_difference in 26.4 [lib.numeric.ops]
+</p>
+
+<p>
+Unlike <tt>accumulate</tt> and <tt>inner_product</tt>, these functions are not
+parametrized on a "type T", instead, 26.4.3 [lib.partial.sum] simply
+specifies the effects clause as;
+</p>
+
+<blockquote><p>
+Assigns to every element referred to by iterator <tt>i</tt> in the range
+<tt>[result,result + (last - first))</tt> a value correspondingly equal to
+</p>
+<blockquote><pre>((...(* first + *( first + 1)) + ...) + *( first + ( i - result )))
+</pre></blockquote>
+</blockquote>
+
+<p>
+And similarly for BinaryOperation. Using just this definition, it seems
+logical to expect that:
+</p>
+
+
+<blockquote><pre>char i_array[4] = { 100, 100, 100, 100 };
+int o_array[4];
+
+std::partial_sum(i_array, i_array+4, o_array);
+</pre></blockquote>
+
+<p>
+Is equivalent to
+</p>
+
+<blockquote><pre>int o_array[4] = { 100, 100+100, 100+100+100, 100+100+100+100 };
+</pre></blockquote>
+
+<p>
+i.e. 100, 200, 300, 400, with addition happening in the <tt>result type</tt>,
+<tt>int</tt>.
+</p>
+
+<p>
+Yet all implementations I have tested produce 100, -56, 44, -112,
+because they are using an accumulator of the <tt>InputIterator</tt>'s
+<tt>value_type</tt>, which in this case is <tt>char</tt>, not <tt>int</tt>.
+</p>
+
+<p>
+The issue becomes more noticeable when the result of the expression <tt>*i +
+*(i+1)</tt> or <tt>binary_op(*i, *i-1)</tt> can't be converted to the
+<tt>value_type</tt>. In a contrived example:
+</p>
+
+<blockquote><pre>enum not_int { x = 1, y = 2 };
+...
+not_int e_array[4] = { x, x, y, y };
+std::partial_sum(e_array, e_array+4, o_array);
+</pre></blockquote>
+
+<p>
+Is it the intent that the operations happen in the <tt>input type</tt>, or in
+the <tt>result type</tt>?
+</p>
+
+<p>
+If the intent is that operations happen in the <tt>result type</tt>, something
+like this should be added to the "Requires" clause of 26.4.3/4
+[lib.partial.sum]:
+</p>
+
+<blockquote><p>
+The type of <tt>*i + *(i+1)</tt> or <tt>binary_op(*i, *(i+1))</tt> shall meet the
+requirements of <tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt>
+(23.1) types.
+</p></blockquote>
+
+<p>
+(As also required for <tt>T</tt> in 26.4.1 [lib.accumulate] and 26.4.2
+[lib.inner.product].)
+</p>
+
+<p>
+The "auto initializer" feature proposed in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1894.pdf">N1894</a>
+is not required to
+implement <tt>partial_sum</tt> this way. The 'narrowing' behaviour can still be
+obtained by using the <tt>std::plus<></tt> function object.
+</p>
+
+<p>
+If the intent is that operations happen in the <tt>input type</tt>, then
+something like this should be added instead;
+</p>
+
+<blockquote><p>
+The type of *first shall meet the requirements of
+<tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt> (23.1) types.
+The result of <tt>*i + *(i+1)</tt> or <tt>binary_op(*i, *(i+1))</tt> shall be
+convertible to this type.
+</p></blockquote>
+
+<p>
+The 'widening' behaviour can then be obtained by writing a custom proxy
+iterator, which is somewhat involved.
+</p>
+
+<p>
+In both cases, the semantics should probably be clarified.
+</p>
+
+<p>
+26.4.4 [lib.adjacent.difference] is similarly underspecified, although
+all implementations seem to perform operations in the 'result' type:
+</p>
+
+<blockquote><pre>unsigned char i_array[4] = { 4, 3, 2, 1 };
+int o_array[4];
+
+std::adjacent_difference(i_array, i_array+4, o_array);
+</pre></blockquote>
+
+<p>
+o_array is 4, -1, -1, -1 as expected, not 4, 255, 255, 255.
+</p>
+
+<p>
+In any case, <tt>adjacent_difference</tt> doesn't mention the requirements on the
+<tt>value_type</tt>; it can be brought in line with the rest of 26.4
+[lib.numeric.ops] by adding the following to 26.4.4/2
+[lib.adjacent.difference]:
+</p>
+
+<blockquote><p>
+The type of <tt>*first</tt> shall meet the requirements of
+<tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt> (23.1) types."
+</p></blockquote>
+<p><i>[
+Berlin: Giving output iterator's value_types very controversial. Suggestion of
+adding signatures to allow user to specify "accumulator".
+]</i></p>
+
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+The intent of the algorithms is to perform their calculations using the type of the input iterator.
+Proposed wording provided.
+</blockquote>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+We did not agree that the proposed resolution was correct. For example,
+when the arguments are types <tt>(float*, float*, double*)</tt>, the
+highest-quality solution would use double as the type of the
+accumulator. If the intent of the wording is to require that the type of
+the accumulator must be the <tt>input_iterator</tt>'s <tt>value_type</tt>, the wording
+should specify it.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add to section 26.6.3 [partial.sum] paragraph 4 the following two sentences:
+</p>
+
+<blockquote>
+The type of <tt>*first</tt> shall meet the requirements of <tt>CopyConstructible</tt>?
+(20.1.3?) and <tt>Assignable</tt> (23.1?) types. The result of <tt>*i + *(i+1)</tt> or
+<tt>binary_op(*i, *(i+1))</tt> shall be convertible to this type.
+</blockquote>
+
+<p>
+Add to section 26.6.4 [adjacent.difference] paragraph 2 the following sentence:
+</p>
+
+<blockquote>
+The type of <tt>*first</tt> shall meet the requirements of <tt>CopyConstructible</tt>?
+(20.1.3) and <tt>Assignable</tt> (23.1) types.
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="546"></a>546. _Longlong and _ULonglong are integer types</h3>
+<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>
+ <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The TR sneaks in two new integer types, _Longlong and _Ulonglong, in [tr.c99].
+The rest of the TR should use that type. I believe this affects two places.
+First, the random number requirements, 5.1.1/10-11, lists all of the types with
+which template parameters named IntType and UIntType may be instantiated.
+_Longlong (or "long long", assuming it is added to C++0x) should be added to the
+IntType list, and UIntType (again, or "unsigned long long") should be added to
+the UIntType list. Second, 6.3.2 lists the types for which hash<> is
+required to be instantiable. _Longlong and _Ulonglong should be added to that
+list, so that people may use long long as a hash key.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="556"></a>556. is Compare a BinaryPredicate?</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-05</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+In 25, p8 we allow BinaryPredicates to return a type that's convertible
+to bool but need not actually be bool. That allows predicates to return
+things like proxies and requires that implementations be careful about
+what kinds of expressions they use the result of the predicate in (e.g.,
+the expression in if (!pred(a, b)) need not be well-formed since the
+negation operator may be inaccessible or return a type that's not
+convertible to bool).
+</p>
+<p>
+Here's the text for reference:
+</p>
+<blockquote><p>
+ ...if an algorithm takes BinaryPredicate binary_pred as its argument
+ and first1 and first2 as its iterator arguments, it should work
+ correctly in the construct if (binary_pred(*first1, first2)){...}.
+</p></blockquote>
+
+<p>
+In 25.3, p2 we require that the Compare function object return true
+of false, which would seem to preclude such proxies. The relevant text
+is here:
+</p>
+<blockquote><p>
+ Compare is used as a function object which returns true if the first
+ argument is less than the second, and false otherwise...
+</p></blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+I think we could fix this by rewording 25.3, p2 to read somthing like:
+</p>
+<blockquote><p>
+-2- <tt>Compare</tt> is <del>used as a function object which returns
+<tt>true</tt> if the first argument</del> <ins>a <tt>BinaryPredicate</tt>. The
+return value of the function call operator applied to an object of type
+<tt>Compare</tt>, when converted to type <tt>bool</tt>, yields <tt>true</tt>
+if the first argument of the call</ins> is less than the second, and
+<tt>false</tt> otherwise. <tt>Compare <i>comp</i></tt> is used throughout for
+algorithms assuming an ordering relation. It is assumed that <tt><i>comp</i></tt>
+will not apply any non-constant function through the dereferenced iterator.
+</p></blockquote>
+
+
+<p><i>[
+Portland: Jack to define "convertible to bool" such that short circuiting isn't
+destroyed.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="564"></a>564. stringbuf seekpos underspecified</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The effects of the <code>seekpos()</code> member function of
+<code>basic_stringbuf</code> simply say that the function positions
+the input and/or output sequences but fail to spell out exactly
+how. This is in contrast to the detail in which <code>seekoff()</code>
+is described.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+ <p>
+
+Change 27.7.1.3, p13 to read:
+
+ </p>
+<blockquote>
+<p>
+-13- <i>Effects:</i> <ins>Same as <tt>seekoff(off_type(<i>sp</i>), ios_base::beg,
+<i>which</i>)</tt>.</ins> <del>Alters the stream position within the controlled sequences,
+if possible, to correspond to the stream position stored in <tt><i>sp</i></tt>
+(as described below).</del>
+</p>
+<ul>
+<li><del>If <tt>(<i>which</i> & ios_base::in) != 0</tt>, positions the input sequence.</del></li>
+<li><del>If <tt>(<i>which</i> & ios_base::out) != 0</tt>, positions the output sequence.</del></li>
+<li><del>If <tt><i>sp</i></tt> is an invalid stream position, or if the function
+positions neither sequence, the positioning operation fails. If <tt><i>sp</i></tt>
+has not been obtained by a previous successful call to one of the positioning
+functions (<tt>seekoff</tt>, <tt>seekpos</tt>, <tt>tellg</tt>, <tt>tellp</tt>)
+the effect is undefined.</del></li>
+</ul>
+</blockquote>
+
+
+<p><i>[
+Kona (2007): A <tt>pos_type</tt> is a position in a stream by
+definition, so there is no ambiguity as to what it means. Proposed
+Disposition: NAD
+]</i></p>
+
+
+<p><i>[
+Post-Kona Martin adds:
+I'm afraid I disagree
+with the Kona '07 rationale for marking it NAD. The only text
+that describes precisely what it means to position the input
+or output sequence is in <tt>seekoff()</tt>. The <tt>seekpos()</tt> Effects
+clause is inadequate in comparison and the proposed resolution
+plugs the hole by specifying <tt>seekpos()</tt> in terms of <tt>seekoff()</tt>.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="565"></a>565. xsputn inefficient</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
+<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>
+<p><b>Discussion:</b></p>
+ <p>
+
+<tt>streambuf::xsputn()</tt> is specified to have the effect of
+"writing up to <tt>n</tt> characters to the output sequence as if by
+repeated calls to <tt>sputc(c)</tt>."
+
+ </p>
+ <p>
+
+Since <tt>sputc()</tt> is required to call <tt>overflow()</tt> when
+<tt>(pptr() == epptr())</tt> is true, strictly speaking
+<tt>xsputn()</tt> should do the same. However, doing so would be
+suboptimal in some interesting cases, such as in unbuffered mode or
+when the buffer is <tt>basic_stringbuf</tt>.
+
+ </p>
+ <p>
+
+Assuming calling <tt>overflow()</tt> is not really intended to be
+required and the wording is simply meant to describe the general
+effect of appending to the end of the sequence it would be worthwhile
+to mention in <tt>xsputn()</tt> that the function is not actually
+required to cause a call to <tt>overflow()</tt>.
+
+ </p>
+
+
+<p><b>Proposed resolution:</b></p>
+ <p>
+
+Add the following sentence to the <tt>xsputn()</tt> Effects clause in
+27.5.2.4.5, p1 (N1804):
+
+ </p>
+ <blockquote>
+ <p>
+-1- <i>Effects:</i> Writes up to <tt><i>n</i></tt> characters to the output
+sequence as if by repeated calls to <tt>sputc(<i>c</i>)</tt>. The characters
+written are obtained from successive elements of the array whose first element
+is designated by <tt><i>s</i></tt>. Writing stops when either <tt><i>n</i></tt>
+characters have been written or a call to <tt>sputc(<i>c</i>)</tt> would return
+<tt>traits::eof()</tt>. <ins>It is uspecified whether the function calls
+<tt>overflow()</tt> when <tt>(pptr() == epptr())</tt> becomes true or whether
+it achieves the same effects by other means.</ins>
+ </p>
+ </blockquote>
+ <p>
+
+In addition, I suggest to add a footnote to this function with the
+same text as Footnote 292 to make it extra clear that derived classes
+are permitted to override <tt>xsputn()</tt> for efficiency.
+
+ </p>
+
+
+<p><i>[
+Kona (2007): We want to permit a <tt>streambuf</tt> that streams output directly
+to a device without making calls to <tt>sputc</tt> or <tt>overflow</tt>. We believe that
+has always been the intention of the committee. We believe that the
+proposed wording doesn't accomplish that. Proposed Disposition: Open
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="568"></a>568. log2 overloads missing</h3>
+<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>
+ <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-03-07</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+<tt>log2</tt> is missing from the list of "additional overloads" in TR1 8.16.4 [tr.c99.cmath.over] p1.
+</p>
+
+<p>
+Hinnant: This is a TR1 issue only. It is fixed in the current (N2135) WD.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add <tt>log2</tt> to the list of functions in TR1 8.16.4 [tr.c99.cmath.over] p1.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="573"></a>573. C++0x file positioning should handle modern file sizes</h3>
+<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>
+ <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-04-12</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+There are two deficiencies related to file sizes:
+</p>
+<ol>
+<li>It doesn't appear that the Standard Library is specified in
+ a way that handles modern file sizes, which are often too
+ large to be represented by an unsigned long.</li>
+
+<li>The std::fpos class does not currently have the ability to
+ set/get file positions.</li>
+</ol>
+<p>
+The Dinkumware implementation of the Standard Library as shipped with the Microsoft compiler copes with these issues by:
+</p>
+<ol type="A">
+<li>Defining fpos_t be long long, which is large enough to
+ represent any file position likely in the foreseeable future.</li>
+
+<li>Adding member functions to class fpos. For example,
+<blockquote><pre>fpos_t seekpos() const;
+</pre></blockquote>
+</li>
+</ol>
+<p>
+Because there are so many types relating to file positions and offsets (fpos_t,
+fpos, pos_type, off_type, streamoff, streamsize, streampos, wstreampos, and
+perhaps more), it is difficult to know if the Dinkumware extensions are
+sufficient. But they seem a useful starting place for discussions, and they do
+represent existing practice.
+</p>
+
+<p><i>[
+Kona (2007): We need a paper. It would be nice if someone proposed
+clarifications to the definitions of <tt>pos_type</tt> and <tt>off_type</tt>. Currently
+these definitions are horrible. Proposed Disposition: Open
+]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="580"></a>580. unused allocator members</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-14</p>
+<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>
+<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>
+<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>
+<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a></p>
+<p><b>Discussion:</b></p>
+ <p>
+
+C++ Standard Library templates that take an allocator as an argument
+are required to call the <code>allocate()</code> and
+<code>deallocate()</code> members of the allocator object to obtain
+storage. However, they do not appear to be required to call any other
+allocator members such as <code>construct()</code>,
+<code>destroy()</code>, <code>address()</code>, and
+<code>max_size()</code>. This makes these allocator members less than
+useful in portable programs.
+
+ </p>
+ <p>
+
+It's unclear to me whether the absence of the requirement to use these
+allocator members is an unintentional omission or a deliberate
+choice. However, since the functions exist in the standard allocator
+and since they are required to be provided by any user-defined
+allocator I believe the standard ought to be clarified to explictly
+specify whether programs should or should not be able to rely on
+standard containers calling the functions.
+
+ </p>
+ <p>
+
+I propose that all containers be required to make use of these
+functions.
+
+ </p>
+<p><i>[
+Batavia: We support this resolution. Martin to provide wording.
+]</i></p>
+
+<p><i>[
+pre-Oxford: Martin provided wording.
+]</i></p>
+
+
+
+ <p><b>Proposed resolution:</b></p>
+ <p>
+
+Specifically, I propose to change 23.1 [container.requirements],
+p9 as follows:
+
+ </p>
+ <blockquote>
+<p>
+-9- Copy constructors for all container types defined in this clause
+<ins>that are parametrized on <code>Allocator</code></ins> copy
+<del>an</del><ins>the</ins> allocator argument from their respective
+first parameters.
+
+All other constructors for these container types take a<del>n</del>
+<ins>const</ins> <code>Allocator&</code> argument (20.1.6), an
+allocator whose <code>value_type</code> is the same as the container's
+<code>value_type</code>.
+
+A copy of this argument <del>is</del><ins>shall be</ins> used for any
+memory allocation <ins> and deallocation</ins> performed<del>,</del>
+by these constructors and by all member functions<del>,</del> during
+the lifetime of each container object. <ins>Allocation shall be
+performed "as if" by calling the <code>allocate()</code> member
+function on a copy of the allocator object of the appropriate type
+<sup>New Footnote)</sup>, and deallocation "as if" by calling
+<code>deallocate()</code> on a copy of the same allocator object of
+the corresponding type.</ins>
+
+<ins>A copy of this argument shall also be used to construct and
+destroy objects whose lifetime is managed by the container, including
+but not limited to those of the container's <code>value_type</code>,
+and to obtain their address. All objects residing in storage
+allocated by a container's allocator shall be constructed "as if" by
+calling the <code>construct()</code> member function on a copy of the
+allocator object of the appropriate type. The same objects shall be
+destroyed "as if" by calling <code>destroy()</code> on a copy of the
+same allocator object of the same type. The address of such objects
+shall be obtained "as if" by calling the <code>address()</code> member
+function on a copy of the allocator object of the appropriate
+type.</ins>
+
+<ins>Finally, a copy of this argument shall be used by its container
+object to determine the maximum number of objects of the container's
+<code>value_type</code> the container may store at the same time. The
+container member function <code>max_size()</code> obtains this number
+from the value returned by a call to
+<code>get_allocator().max_size()</code>.</ins>
+
+In all container types defined in this clause <ins>that are
+parametrized on <code>Allocator</code></ins>, the member
+<code>get_allocator()</code> returns a copy of the
+<code>Allocator</code> object used to construct the
+container.<sup>258)</sup>
+</p>
+<p>
+New Footnote: This type may be different from <code>Allocator</code>:
+it may be derived from <code>Allocator</code> via
+<code>Allocator::rebind<U>::other</code> for the appropriate
+type <code>U</code>.
+</p>
+ </blockquote>
+ <p>
+
+The proposed wording seems cumbersome but I couldn't think of a better
+way to describe the requirement that containers use their
+<code>Allocator</code> to manage only objects (regardless of their
+type) that persist over their lifetimes and not, for example,
+temporaries created on the stack. That is, containers shouldn't be
+required to call <code>Allocator::construct(Allocator::allocate(1),
+elem)</code> just to construct a temporary copy of an element, or
+<code>Allocator::destroy(Allocator::address(temp), 1)</code> to
+destroy temporaries.
+
+ </p>
+
+
+<p><i>[
+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>.
+]</i></p>
+
+
+<p><i>[
+post Oxford: This would be rendered NAD Editorial by acceptance of
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="582"></a>582. specialized algorithms and volatile storage</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-14</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+ <p>
+
+The specialized algorithms [lib.specialized.algorithms] are specified
+as having the general effect of invoking the following expression:
+
+ </p>
+ <pre>
+new (static_cast<void*>(&*i))
+ typename iterator_traits<ForwardIterator>::value_type (x)
+
+ </pre>
+ <p>
+
+This expression is ill-formed when the type of the subexpression
+<code>&*i</code> is some volatile-qualified <code>T</code>.
+
+ </p>
+
+<p><i>[
+Batavia: Lack of support for proposed resolution but agree there is a
+defect. Howard to look at wording. Concern that move semantics
+properly expressed if iterator returns rvalue.
+]</i></p>
+
+
+
+
+ <p><b>Proposed resolution:</b></p>
+ <p>
+
+In order to allow these algorithms to operate on volatile storage I
+propose to change the expression so as to make it well-formed even for
+pointers to volatile types. Specifically, I propose the following
+changes to clauses 20 and 24. Change 20.6.4.1, p1 to read:
+
+ </p>
+ <pre>
+<i>Effects</i>:
+
+typedef typename iterator_traits<ForwardIterator>::pointer pointer;
+typedef typename iterator_traits<ForwardIterator>::value_type value_type;
+
+for (; first != last; ++result, ++first)
+ new (static_cast<void*>(const_cast<pointer>(&*result))
+ value_type (*first);
+
+ </pre>
+ <p>
+
+change 20.6.4.2, p1 to read
+
+ </p>
+ <pre>
+<i>Effects</i>:
+
+typedef typename iterator_traits<ForwardIterator>::pointer pointer;
+typedef typename iterator_traits<ForwardIterator>::value_type value_type;
+
+for (; first != last; ++result, ++first)
+ new (static_cast<void*>(const_cast<pointer>(&*first))
+ value_type (*x);
+
+ </pre>
+ <p>
+
+and change 20.6.4.3, p1 to read
+
+ </p>
+ <pre>
+<i>Effects</i>:
+
+typedef typename iterator_traits<ForwardIterator>::pointer pointer;
+typedef typename iterator_traits<ForwardIterator>::value_type value_type;
+
+for (; n--; ++first)
+ new (static_cast<void*>(const_cast<pointer>(&*first))
+ value_type (*x);
+
+ </pre>
+ <p>
+
+In addition, since there is no partial specialization for
+<code>iterator_traits<volatile T*></code> I propose to add one
+to parallel such specialization for <const T*>. Specifically, I
+propose to add the following text to the end of 24.3.1, p3:
+
+ </p>
+ <p>
+
+and for pointers to volatile as
+
+ </p>
+ <pre>
+namespace std {
+template<class T> struct iterator_traits<volatile T*> {
+typedef ptrdiff_t difference_type;
+typedef T value_type;
+typedef volatile T* pointer;
+typedef volatile T& reference;
+typedef random_access_iterator_tag iterator_category;
+};
+}
+
+ </pre>
+ <p>
+
+Note that the change to <code>iterator_traits</code> isn't necessary
+in order to implement the specialized algorithms in a way that allows
+them to operate on volatile strorage. It is only necesassary in order
+to specify their effects in terms of <code>iterator_traits</code> as
+is done here. Implementations can (and some do) achieve the same
+effect by means of function template overloading.
+
+ </p>
+
+
+
+
+<hr>
+<h3><a name="585"></a>585. facet error reporting</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor, Paolo Carlini <b>Date:</b> 2006-06-22</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+ <p>
+
+Section 22.2, paragraph 2 requires facet <code>get()</code> members
+that take an <code>ios_base::iostate&</code> argument,
+<code><i>err</i></code>, to ignore the (initial) value of the
+argument, but to set it to <code>ios_base::failbit</code> in case of a
+parse error.
+
+ </p>
+ <p>
+
+We believe there are a few minor problems with this blanket
+requirement in conjunction with the wording specific to each
+<code>get()</code> member function.
+
+ </p>
+ <p>
+
+First, besides <code>get()</code> there are other member functions
+with a slightly different name (for example,
+<code>get_date()</code>). It's not completely clear that the intent of
+the paragraph is to include those as well, and at least one
+implementation has interpreted the requirement literally.
+
+ </p>
+ <p>
+
+Second, the requirement to "set the argument to
+<code>ios_base::failbit</code> suggests that the functions are not
+permitted to set it to any other value (such as
+<code>ios_base::eofbit</code>, or even <code>ios_base::eofbit |
+ios_base::failbit</code>).
+
+ </p>
+ <p>
+
+However, 22.2.2.1.2, p5 (Stage 3 of <code>num_get</code> parsing) and
+p6 (<code>bool</code> parsing) specifies that the <code>do_get</code>
+functions perform <code><i>err</i> |= ios_base::eofbit</code>, which
+contradicts the earlier requirement to ignore <i>err</i>'s initial
+value.
+
+ </p>
+ <p>
+
+22.2.6.1.2, p1 (the Effects clause of the <code>money_get</code>
+facet's <code>do_get</code> member functions) also specifies that
+<code><i>err</i></code>'s initial value be used to compute the final
+value by ORing it with either <code>ios_base::failbit</code> or
+with<code>ios_base::eofbit | ios_base::failbit</code>.
+
+ </p>
+
+
+ <p><b>Proposed resolution:</b></p>
+ <p>
+
+We believe the intent is for all facet member functions that take an
+<code>ios_base::iostate&</code> argument to:
+
+ </p>
+ <ul>
+ <li>
+
+ignore the initial value of the <code><i>err</i></code> argument,
+
+ </li>
+ <li>
+
+reset <code><i>err</i></code> to <code>ios_base::goodbit</code> prior
+to any further processing,
+
+ </li>
+ <li>
+
+and set either <code>ios_base::eofbit</code>, or
+<code>ios_base::failbit</code>, or both in <code><i>err</i></code>, as
+appropriate, in response to reaching the end-of-file or on parse
+error, or both.
+
+ </li>
+ </ul>
+ <p>
+
+To that effect we propose to change 22.2, p2 as follows:
+
+ </p>
+ <p>
+
+The <i>put</i><del>()</del> members make no provision for error
+reporting. (Any failures of the OutputIterator argument must be
+extracted from the returned iterator.) <ins>Unless otherwise
+specified, </ins>the <i>get</i><del>()</del> members <ins>that</ins>
+take an <code>ios_base::iostate&</code> argument <del>whose value
+they ignore, but set to ios_base::failbit in case of a parse
+error.</del><ins>, <code><i>err</i></code>, start by evaluating
+<code>err = ios_base::goodbit</code>, and may subsequently set
+<i>err</i> to either <code>ios_base::eofbit</code>, or
+<code>ios_base::failbit</code>, or <code>ios_base::eofbit |
+ios_base::failbit</code> in response to reaching the end-of-file or in
+case of a parse error, or both, respectively.</ins>
+
+ </p>
+
+
+<p><i>[
+Kona (2007): We need to change the proposed wording to clarify that the
+phrase "the get members" actually denotes <tt>get()</tt>, <tt>get_date()</tt>, etc.
+Proposed Disposition: Open
+]</i></p>
+
+
+
+
+<hr>
+<h3><a name="588"></a>588. requirements on zero sized tr1::arrays and other details</h3>
+<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>
+ <b>Submitter:</b> Gennaro Prota <b>Date:</b> 2006-07-18</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The wording used for section 23.2.1 [lib.array] seems to be subtly
+ambiguous about zero sized arrays (N==0). Specifically:
+</p>
+<p>
+* "An instance of array<T, N> stores N elements of type T, so that
+[...]"
+</p>
+<p>
+Does this imply that a zero sized array object stores 0 elements, i.e.
+that it cannot store any element of type T? The next point clarifies
+the rationale behind this question, basically how to implement begin()
+and end():
+</p>
+<p>
+* 23.2.1.5 [lib.array.zero], p2: "In the case that N == 0, begin() ==
+end() == unique value."
+</p>
+<p>
+What does "unique" mean in this context? Let's consider the following
+possible implementations, all relying on a partial specialization:
+</p>
+<blockquote><pre>a)
+ template< typename T >
+ class array< T, 0 > {
+
+ ....
+
+ iterator begin()
+ { return iterator( reinterpret_cast< T * >( this ) ); }
+ ....
+
+ };
+</pre></blockquote>
+<p>
+This has been used in boost, probably intending that the return value
+had to be unique to the specific array object and that array couldn't
+store any T. Note that, besides relying on a reinterpret_cast, has
+(more than potential) alignment problems.
+</p>
+<blockquote><pre>b)
+ template< typename T >
+ class array< T, 0 > {
+
+ T t;
+
+ iterator begin()
+ { return iterator( &t ); }
+ ....
+
+ };
+</pre></blockquote>
+<p>
+This provides a value which is unique to the object and to the type of
+the array, but requires storing a T. Also, it would allow the user to
+mistakenly provide an initializer list with one element.
+</p>
+<p>
+A slight variant could be returning *the* null pointer of type T
+</p>
+<blockquote><pre> return static_cast<T*>(0);
+</pre></blockquote>
+<p>
+In this case the value would be unique to the type array<T, 0> but not
+to the objects (all objects of type array<T, 0> with the same value
+for T would yield the same pointer value).
+</p>
+<p>
+Furthermore this is inconsistent with what the standard requires from
+allocation functions (see library issue 9).
+</p>
+<p>
+c) same as above but with t being a static data member; again, the
+value would be unique to the type, not to the object.
+</p>
+<p>
+d) to avoid storing a T *directly* while disallowing the possibility
+to use a one-element initializer list a non-aggregate nested class
+could be defined
+</p>
+<blockquote><pre> struct holder { holder() {} T t; } h;
+</pre></blockquote>
+<p>
+and then begin be defined as
+</p>
+<blockquote><pre> iterator begin() { return &h.t; }
+</pre></blockquote>
+<p>
+But then, it's arguable whether the array stores a T or not.
+Indirectly it does.
+</p>
+<p>
+-----------------------------------------------------
+</p>
+<p>
+Now, on different issues:
+</p>
+<p>
+* what's the effect of calling assign(T&) on a zero-sized array? There
+seems to be only mention of front() and back(), in 23.2.1 [lib.array]
+p4 (I would also suggest to move that bullet to section 23.2.1.5
+[lib.array.zero], for locality of reference)
+</p>
+<p>
+* (minor) the opening paragraph of 23.2.1 [lib.array] wording is a bit
+inconsistent with that of other sequences: that's not a problem in
+itself, but compare it for instance with "A vector is a kind of
+sequence that supports random access iterators"; though the intent is
+obvious one might argue that the wording used for arrays doesn't tell
+what an array is, and relies on the reader to infer that it is what
+the <array> header defines.
+</p>
+<p>
+* it would be desiderable to have a static const data member of type
+std::size_t, with value N, for usage as integral constant expression
+</p>
+<p>
+* section 23.1 [lib.container.requirements] seem not to consider
+fixed-size containers at all, as it says: "[containers] control
+allocation and deallocation of these objects [the contained objects]
+through constructors, destructors, *insert and erase* operations"
+</p>
+<p>
+* max_size() isn't specified: the result is obvious but, technically,
+it relies on table 80: "size() of the largest possible container"
+which, again, doesn't seem to consider fixed size containers
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+<p><i>[
+Kona (2007): requirements on zero sized <tt>tr1::array</tt>s and other details
+Issue 617: <tt>std::array</tt> is a sequence that doesn't satisfy the sequence
+requirements? Alisdair will prepare a paper. Proposed Disposition: Open
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="597"></a>597. Decimal: The notion of 'promotion' cannot be emulated by user-defined types.</h3>
+<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>
+ <b>Submitter:</b> Daveed Vandevoorde <b>Date:</b> 2006-04-05</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+In a private email, Daveed writes:
+</p>
+<blockquote>
+<p>
+I am not familiar with the C TR, but my guess is that the
+class type approach still won't match a built-in type
+approach because the notion of "promotion" cannot be
+emulated by user-defined types.
+</p>
+<p>
+Here is an example:
+</p>
+</blockquote>
+<pre>
+ struct S {
+ S(_Decimal32 const&); // Converting constructor
+ };
+ void f(S);
+
+ void f(_Decimal64);
+
+ void g(_Decimal32 d) {
+ f(d);
+ }
+</pre>
+
+<blockquote>
+<p>
+If _Decimal32 is a built-in type, the call f(d) will likely
+resolve to f(_Decimal64) because that requires only a
+promotion, whereas f(S) requires a user-defined conversion.
+</p>
+<p>
+If _Decimal32 is a class type, I think the call f(d) will be
+ambiguous because both the conversion to _Decimal64 and the
+conversion to S will be user-defined conversions with neither
+better than the other.
+</p>
+</blockquote>
+<p>
+Robert comments:
+</p>
+<p>
+In general, a library of arithmetic types cannot exactly emulate the
+behavior of the intrinsic numeric types. There are several ways to tell
+whether an implementation of the decimal types uses compiler
+intrinisics or a library. For example:
+</p>
+<pre> _Decimal32 d1;
+ d1.operator+=(5); // If d1 is a builtin type, this won't compile.
+</pre>
+<p>
+In preparing the decimal TR, we have three options:
+</p>
+<ol>
+<li>require that the decimal types be class types</li>
+<li>require that the decimal types be builtin types, like float and double</li>
+<li>specify a library of class types, but allow enough implementor
+latitude that a conforming implementation could instead provide builtin
+types</li>
+</ol>
+<p>
+We decided as a group to pursue option #3, but that approach implies
+that implementations may not agree on the semantics of certain use
+cases (first example, above), or on whether certain other cases are
+well-formed (second example). Another potentially important problem is
+that, under the present definition of POD, the decimal classes are not
+POD types, but builtins will be.
+</p>
+<p>Note that neither example above implies any problems with respect to
+C-to-C++ compatibility, since neither example can be expressed in C.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="606"></a>606. Decimal: allow narrowing conversions</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-15</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+In c++std-lib-17205, Martin writes:
+</p>
+<blockquote><p>...was it a deliberate design choice to make narrowing
+assignments ill-formed while permitting narrowing compound assignments?
+For instance:
+</p></blockquote>
+<pre> decimal32 d32;
+ decimal64 d64;
+
+ d32 = 64; // error
+ d32 += 64; // okay
+</pre>
+<p>
+In c++std-lib-17229, Robert responds:
+</p>
+<blockquote><p>It is a vestige of an old idea that I forgot to remove
+from the paper. Narrowing assignments should be permitted. The bug is
+that the converting constructors that cause narrowing should not be
+explicit. Thanks for pointing this out.
+</p></blockquote>
+
+<p><b>Proposed resolution:</b></p>
+<p>
+1. In "3.2.2 Class <code>decimal32</code>" synopsis, remove the <code>explicit</code> specifier from the narrowing conversions:
+</p>
+<pre> // <i>3.2.2.2 conversion from floating-point type:</i>
+ <del>explicit</del> decimal32(decimal64 <i>d64</i>);
+ <del>explicit</del> decimal32(decimal128 <i>d128</i>);
+</pre>
+<p>
+2. Do the same thing in "3.2.2.2. Conversion from floating-point type."
+</p>
+<p>
+3. In "3.2.3 Class <code>decimal64</code>" synopsis, remove the <code>explicit</code> specifier from the narrowing conversion:
+</p>
+<pre> // <i>3.2.3.2 conversion from floating-point type:</i>
+ <del>explicit</del> decimal64(decimal128 <i>d128</i>);
+</pre>
+<p>
+4. Do the same thing in "3.2.3.2. Conversion from floating-point type."
+</p>
+
+<p><i>[
+Redmond: We prefer explicit conversions for narrowing and implicit for widening.
+]</i></p>
+
+
+
+
+
+
+<hr>
+<h3><a name="614"></a>614. std::string allocator requirements still inconsistent</h3>
+<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>
+ <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-05</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+This is based on N2134, where 21.3.1/2 states:
+"... The Allocator object used shall be a copy of the Allocator object
+passed to the basic_string object's constructor or, if the constructor does
+not take an Allocator argument, a copy of a default-constructed Allocator
+object."
+</p>
+<p>
+Section 21.3.2/1 lists two constructors:
+</p>
+<blockquote><pre>basic_string(const basic_string<charT,traits,Allocator>& str );
+
+basic_string(const basic_string<charT,traits,Allocator>& str ,
+ size_type pos , size_type n = npos,
+ const Allocator& a = Allocator());
+</pre></blockquote>
+<p>
+and then says "In the first form, the Allocator value used is copied from
+str.get_allocator().", which isn't an option according to 21.3.1.
+</p>
+<p><i>[
+Batavia: We need blanket statement to the effect of:
+]</i></p>
+
+
+<ol>
+<li>If an allocator is passed in, use it, or,</li>
+<li>If a string is passed in, use its allocator.</li>
+</ol>
+<p><i>[
+Review constructors and functions that return a string; make sure we follow these
+rules (substr, operator+, etc.). Howard to supply wording.
+]</i></p>
+
+
+<p><i>[
+Bo adds: The new container constructor which takes only a <tt>size_type</tt> is not
+consistent with 23.1 [container.requirements], p9 which says in part:
+
+<blockquote>
+All other constructors for these container types take an
+<tt>Allocator&</tt> argument (20.1.2), an allocator whose value type
+is the same as the container's value type. A copy of this argument is
+used for any memory allocation performed, by these constructors and by
+all member functions, during the lifetime of each container object.
+</blockquote>
+]</i></p>
+
+
+<p><i>[
+post Bellevue: We re-confirm that the issue is real. Pablo will provide wording.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="617"></a>617. std::array is a sequence that doesn't satisfy the sequence requirements?</h3>
+<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>
+ <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-30</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The <tt><array></tt> header is given under 23.2 [sequences].
+23.2.1 [array]/paragraph 3 says:
+</p>
+<blockquote><p>
+"Unless otherwise specified, all array operations are as described in
+23.1 [container.requirements]".
+</p></blockquote>
+<p>
+However, array isn't mentioned at all in section 23.1 [container.requirements].
+In particular, Table 82 "Sequence requirements" lists several operations (insert, erase, clear)
+that std::array does not have in 23.2.1 [array].
+</p>
+<p>
+Also, Table 83 "Optional sequence operations" lists several operations that
+std::array does have, but array isn't mentioned.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="629"></a>629. complex<t> insertion and locale dependence</t></h3>
+<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>
+ <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2007-01-28</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+is there an issue opened for (0,3) as complex number with
+the French local? With the English local, the above parses as an
+imaginery complex number. With the French locale it parses as a
+real complex number.
+</p>
+
+<p>
+Further notes/ideas from the lib-reflector, messages 17982-17984:
+</p>
+
+<blockquote>
+<p>
+Add additional entries in num_punct to cover the complex separator (French would be ';').
+</p>
+<p>
+Insert a space before the comma, which should eliminate the ambiguity.
+</p>
+<p>
+Solve the problem for ordered sequences in general, perhaps with a
+dedicated facet. Then complex should use that solution.
+</p>
+</blockquote>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+After much discussion, we agreed on the following: Add a footnote:
+</p>
+<p>
+[In a locale in which comma is being used as a decimal point character,
+inserting "showbase" into the output stream forces all outputs to show
+an explicit decimal point character; then all inserted complex sequences
+will extract unambiguously.]
+</p>
+<p>
+And move this to READY status.
+</p>
+</blockquote>
+
+<p><i>[
+Pre-Sophia Antipolis, Howard adds:
+]</i></p>
+
+
+<blockquote>
+Changed "showbase" to "showpoint" and changed from Ready to Review.
+</blockquote>
+
+<p><i>[
+Post-Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+I neglected to pull this issue from the formal motions page after the "showbase" to "showpoint" change.
+In Sophia Antipolis this change was reviewed by the LWG and the issue was set to Ready. We subsequently
+voted the footnote into the WP with "showbase".
+</p>
+<p>
+I'm changing from WP back to Ready to pick up the "showbase" to "showpoint" change.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add a footnote to 26.3.6 [complex.ops] p16:
+</p>
+
+<blockquote>
+[In a locale in which comma is being used as a decimal point character,
+inserting <tt>showpoint</tt> into the output stream forces all outputs to show
+an explicit decimal point character; then all inserted complex sequences
+will extract unambiguously.]
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="630"></a>630. arrays of valarray</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-28</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+ <p>
+
+Section 26.1 [numeric.requirements], p1 suggests that a
+<code>valarray</code> specialization on a type <code>T</code> that
+satisfies the requirements enumerated in the paragraph is itself a
+valid type on which <code>valarray</code> may be instantiated
+(Footnote 269 makes this clear). I.e.,
+<code>valarray<valarray<T> ></code> is valid as long as
+<code>T</code> is valid. However, since implementations of
+<code>valarray</code> are permitted to initialize storage allocated by
+the class by invoking the default ctor of <code>T</code> followed by
+the copy assignment operator, such implementations of
+<code>valarray</code> wouldn't work with (perhaps user-defined)
+specializations of <code>valarray</code> whose assignment operator had
+undefined behavior when the size of its argument didn't match the size
+of <code>*this</code>. By <i>"wouldn't work"</i> I mean that it would
+be impossible to resize such an array of arrays by calling the
+<code>resize()</code> member function on it if the function used the
+copy assignment operator after constructing all elements using the
+default ctor (e.g., by invoking <code>new value_type[N]</code>) to
+obtain default-initialized storage) as it's permitted to do.
+
+ </p>
+ <p>
+
+Stated more generally, the problem is that
+<code>valarray<valarray<T> >::resize(size_t)</code> isn't
+required or guaranteed to have well-defined semantics for every type
+<code>T</code> that satisfies all requirements in
+26.1 [numeric.requirements].
+
+ </p>
+ <p>
+
+I believe this problem was introduced by the adoption of the
+resolution outlined in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0857.asc">N0857</a>,
+<i>Assignment of valarrays</i>, from 1996. The copy assignment
+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>,
+as well as the one proposed in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0308.asc">N0308</a>
+(both from 1993), had well-defined semantics for arrays of unequal
+size (the latter explicitly only when <code>*this</code> was empty;
+assignment of non empty arrays of unequal size was a runtime error).
+
+ </p>
+ <p>
+
+The justification for the change given in N0857 was the "loss of
+performance [deemed] only significant for very simple operations on
+small arrays or for architectures with very few registers."
+
+ </p>
+ <p>
+
+Since tiny arrays on a limited subset of hardware architectures are
+likely to be an exceedingly rare case (despite the continued
+popularity of x86) I propose to revert the resolution and make the
+behavior of all <code>valarray</code> assignment operators
+well-defined even for non-conformal arrays (i.e., arrays of unequal
+size). I have implemented this change and measured no significant
+degradation in performance in the common case (non-empty arrays of
+equal size). I have measured a 50% (and in some cases even greater)
+speedup in the case of assignments to empty arrays versus calling
+<code>resize()</code> first followed by an invocation of the copy
+assignment operator.
+
+ </p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+If no proposed wording by June meeting, this issue should be closed NAD.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+ <p>
+
+Change 26.5.2.2 [valarray.assign], p1 as follows:
+
+ </p>
+ <blockquote>
+ <p>
+ <code>
+
+valarray<T>& operator=(const valarray<T>&<ins> x</ins>);
+
+ </code>
+ </p>
+ <p>
+
+-1- Each element of the <code>*this</code> array is assigned the value
+of the corresponding element of the argument array. <del>The
+resulting behavior is undefined if </del><ins>When </ins>the length of
+the argument array is not equal to the length of the *this
+array<del>.</del><ins> resizes <code>*this</code> to make the two
+arrays the same length, as if by calling
+<code>resize(x.size())</code>, before performing the assignment.</ins>
+
+ </p>
+ </blockquote>
+ <p>
+
+And add a new paragraph just below paragraph 1 with the following
+text:
+
+ </p>
+ <blockquote>
+ <p>
+
+<ins>-2- <i>Postcondition</i>: <code>size() == x.size()</code>.</ins>
+
+ </p>
+ </blockquote>
+ <p>
+
+Also add the following paragraph to 26.5.2.2 [valarray.assign], immediately after p4:
+
+ </p>
+ <blockquote>
+ <p>
+
+<ins>-?- When the length, <i><code>N</code></i> of the array referred
+to by the argument is not equal to the length of <code>*this</code>,
+the operator resizes <code>*this</code> to make the two arrays the
+same length, as if by calling <code>resize(<i>N</i>)</code>, before
+performing the assignment.</ins>
+
+ </p>
+ </blockquote>
+
+<p><i>[
+pre-Sophia Antipolis, Martin adds the following compromise wording, but
+prefers the original proposed resolution:
+]</i></p>
+
+
+<p>
+Change 26.5.2.2 [valarray.assign], p1 as follows:
+</p>
+
+<blockquote>
+<p>
+ -1- <i>Requires:</i> <tt>size() == 0 || size() == x.size()</tt>.
+</p>
+<p>
+ -2- <i>Effects:</i> If <tt>size() == 0</tt> calls <tt>x.resize(x.size())</tt> first.
+ Each element of the <tt>*this</tt> array is assigned the value of the
+ corresponding element of the argument array.
+</p>
+<p>
+ -3- <i>Postcondition:</i> <tt>size() == x.size()</tt>.
+</p>
+</blockquote>
+
+<p>
+Add the following paragraph to 26.5.2.2 [valarray.assign], immediately after
+p4:
+</p>
+
+<blockquote>
+<p>
+ -?- When <tt>size() == 0</tt> and the length, <tt>N</tt> of the array referred to by
+ the argument is not equal to the length of <tt>*this</tt>, the operator
+ resizes <tt>*this</tt> to make the two arrays the same length, as if by
+ calling <tt>resize(N)</tt>, before performing the assignment. Otherwise,
+ when <tt>size() > 0</tt> and <tt>size() != N</tt>, the behavior is undefined.
+</p>
+</blockquote>
+
+
+
+<p><i>[
+Kona (2007): Gaby to propose wording for an alternative resolution in
+which you can assign to a <tt>valarray</tt> of size 0, but not to any other
+<tt>valarray</tt> whose size is unequal to the right hand side of the assignment.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="631"></a>631. conflicting requirements for <tt>BinaryPredicate</tt></h3>
+<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>
+ <b>Submitter:</b> James Kanze <b>Date:</b> 2007-01-31</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The general requirements for <tt><tt>BinaryPredicate</tt></tt> (in 25 [algorithms]/8) contradict the implied specific requirements for
+some functions. In particular, it says that:
+</p>
+
+<blockquote><p>
+[...] if an algorithm takes <tt>BinaryPredicate <i>binary_pred</i></tt>
+as its argument and <tt><i>first1</i></tt> and <i>first2</i> as its
+iterator arguments, it should work correctly in the construct <tt>if
+(binary_pred (*<i>first1</i> , *<i>first2</i> )){...}</tt>.
+<tt>BinaryPredicate</tt> always takes the first iterator type as its
+first argument, that is, in those cases when <tt>T <i>value</i></tt> is
+part of the signature, it should work correctly in the context of <tt>if
+(binary_pred (*<i>first1</i> , <i>value</i>)){...}</tt>.
+</p></blockquote>
+
+<p>
+In the description of <tt>upper_bound</tt> (25.3.3.2 [upper.bound]/2), however, the use is described as
+"<tt>!comp(<i>value</i>, <i>e</i>)</tt>", where <tt><i>e</i></tt> is an
+element of the sequence (a result of dereferencing
+<tt>*<i>first</i></tt>).
+</p>
+
+<p>
+In the description of <tt>lexicographical_compare</tt>, we have both
+"<tt>*<i>first1</i> < *<i>first2</i></tt>" and "<tt>*<i>first2</i>
+< *<i>first1</i></tt>" (which presumably implies "<tt>comp(
+*<i>first1</i>, *<i>first2</i> )</tt>" and "<tt>comp( *<i>first2</i>,
+*<i>first1</i> )</tt>".
+</p>
+
+<p><i>[
+Toronto: Moved to Open. ConceptGCC seems to get <tt>lower_bound</tt>
+and <tt>upper_bound</tt> to work withoutt these changes.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Logically, the <tt>BinaryPredicate</tt> is used as an ordering
+relationship, with the semantics of "less than". Depending on the
+function, it may be used to determine equality, or any of the inequality
+relationships; doing this requires being able to use it with either
+parameter first. I would thus suggest that the requirement be:
+</p>
+
+<blockquote><p>
+[...] <tt>BinaryPredicate</tt> always takes the first iterator
+<tt>value_type</tt> as one of its arguments, it is unspecified which. If
+an algorithm takes <tt>BinaryPredicate <i>binary_pred</i></tt> as its
+argument and <tt><i><i>first1</i></i></tt> and <i>first2</i> as its
+iterator arguments, it should work correctly both in the construct
+<tt>if (binary_pred (*<i>first1</i> , *<i>first2</i> )){...}</tt> and
+<tt>if (binary_pred (*<i>first2</i>, *<i>first1</i>)){...}</tt>. In
+those cases when <tt>T <i>value</i></tt> is part of the signature, it
+should work correctly in the context of <tt>if (binary_pred
+(*<i>first1</i> , <i>value</i>)){...}</tt> and of <tt>if (binary_pred
+(<i>value</i>, *<i>first1</i>)){...}</tt>. [<i>Note:</i> if the two
+types are not identical, and neither is convertable to the other, this
+may require that the <tt>BinaryPredicate</tt> be a functional object
+with two overloaded <tt>operator()()</tt> functions. <i>--end note</i>]
+</p></blockquote>
+
+<p>
+Alternatively, one could specify an order for each function. IMHO, this
+would be more work for the committee, more work for the implementors,
+and of no real advantage for the user: some functions, such as
+<tt>lexicographical_compare</tt> or <tt>equal_range</tt>, will still require both
+functions, and it seems like a much easier rule to teach that both
+functions are always required, rather than to have a complicated list of
+when you only need one, and which one.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="632"></a>632. Time complexity of size() for std::set</h3>
+<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>
+ <b>Submitter:</b> Lionel B <b>Date:</b> 2007-02-01</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+A recent news group discussion:
+</p>
+<blockquote>
+<p>
+Anyone know if the Standard has anything to say about the time complexity
+of size() for std::set? I need to access a set's size (/not/ to know if it is empty!) heavily
+during an algorithm and was thus wondering whether I'd be better off
+tracking the size "manually" or whether that'd be pointless.
+</p>
+<p>
+That would be pointless. size() is O(1).
+</p>
+<p>
+Nit: the standard says "should" have constant time. Implementations may take
+license to do worse. I know that some do this for <tt>std::list<></tt> as a part of
+some trade-off with other operation.
+</p>
+
+<p>
+I was aware of that, hence my reluctance to use size() for std::set.
+</p>
+<p>
+However, this reason would not apply to <tt>std::set<></tt> as far as I can see.
+</p>
+<p>
+Ok, I guess the only option is to try it and see...
+</p>
+</blockquote>
+
+<p>
+If I have any recommendation to the C++ Standards Committee it is that
+implementations must (not "should"!) document clearly[1], where known, the
+time complexity of *all* container access operations.
+</p>
+<p>
+[1] In my case (gcc 4.1.1) I can't swear that the time complexity of size()
+for std::set is not documented... but if it is it's certainly well hidden
+away.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+<p><i>[
+Kona (2007): This issue affects all the containers. We'd love to see a
+paper dealing with the broad issue. We think that the complexity of the
+<tt>size()</tt> member of every container -- except possibly <tt>list</tt> -- should be
+O(1). Alan has volunteered to provide wording.
+]</i></p>
+
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Mandating O(1) size will not fly, too many implementations would be
+invalidated. Alan to provide wording that toughens wording, but that
+does not absolutely mandate O(1).
+</blockquote>
+
+
+
+
+<hr>
+<h3><a name="635"></a>635. domain of <tt>allocator::address</tt></h3>
+<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>
+ <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-02-08</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The table of allocator requirements in 20.1.2 [allocator.requirements] describes
+<tt>allocator::address</tt> as:
+</p>
+<blockquote><pre>a.address(r)
+a.address(s)
+</pre></blockquote>
+<p>
+where <tt>r</tt> and <tt>s</tt> are described as:
+</p>
+<blockquote><p>
+a value of type <tt>X::reference</tt> obtained by the expression <tt>*p</tt>.
+</p></blockquote>
+
+<p>
+and <tt>p</tt> is
+</p>
+
+<blockquote><p>
+a value of type <tt>X::pointer</tt>, obtained by calling <tt>a1.allocate</tt>,
+where <tt>a1 == a</tt>
+</p></blockquote>
+
+<p>
+This all implies that to get the address of some value of type <tt>T</tt> that
+value must have been allocated by this allocator or a copy of it.
+</p>
+
+<p>
+However sometimes container code needs to compare the address of an external value of
+type <tt>T</tt> with an internal value. For example <tt>list::remove(const T& t)</tt>
+may want to compare the address of the external value <tt>t</tt> with that of a value
+stored within the list. Similarly <tt>vector</tt> or <tt>deque insert</tt> may
+want to make similar comparisons (to check for self-referencing calls).
+</p>
+
+<p>
+Mandating that <tt>allocator::address</tt> can only be called for values which the
+allocator allocated seems overly restrictive.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.1.2 [allocator.requirements]:
+</p>
+
+<blockquote>
+<p>
+<tt>r</tt> : a value of type <tt>X::reference</tt> <del>obtained by the expression *p</del>.
+</p>
+<p>
+<tt>s</tt> : a value of type <tt>X::const_reference</tt> <del>obtained by the
+expression <tt>*q</tt> or by conversion from a value <tt>r</tt></del>.
+</p>
+</blockquote>
+
+<p><i>[
+post Oxford: This would be rendered NAD Editorial by acceptance of
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
+]</i></p>
+
+
+<p><i>[
+Kona (2007): This issue is section 8 of N2387. There was some discussion of it but
+no resolution to this issue was recorded. Moved to Open.
+]</i></p>
+
+
+
+
+
+
+
+<hr>
+<h3><a name="644"></a>644. Possible typos in 'function' description</h3>
+<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>
+ <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-02-25</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+X [func.wrap.func.undef]
+</p>
+<p>
+The note in paragraph 2 refers to 'undefined void operators', while the
+section declares a pair of operators returning bool.
+</p>
+
+<p><i>[
+Post-Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+Changed from Pending WP to Open. This issue was voted to WP at the same time the operators were
+changed from private to deleted. The two issues stepped on each other. What do we want the return
+type of these deleted functions to be?
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.6.15.2 [func.wrap.func]
+</p>
+
+<blockquote><pre>...
+private:
+ // X [func.wrap.func.undef], undefined operators:
+ template<class Function2> <del>bool</del> <ins>void</ins> operator==(const function<Function2>&);
+ template<class Function2> <del>bool</del> <ins>void</ins> operator!=(const function<Function2>&);
+};
+</pre></blockquote>
+
+<p>
+Change X [func.wrap.func.undef]
+</p>
+
+<blockquote><pre>template<class Function2> <del>bool</del> <ins>void</ins> operator==(const function<Function2>&);
+template<class Function2> <del>bool</del> <ins>void</ins> operator!=(const function<Function2>&);
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="659"></a>659. istreambuf_iterator should have an operator->()</h3>
+<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>
+ <b>Submitter:</b> Niels Dekker <b>Date:</b> 2007-03-25</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+Greg Herlihy has clearly demonstrated that a user defined input
+iterator should have an operator->(), even if its
+value type is a built-in type (comp.std.c++, "Re: Should any iterator
+have an operator->() in C++0x?", March 2007). And as Howard
+Hinnant remarked in the same thread that the input iterator
+<tt>istreambuf_iterator</tt> doesn't have one, this must be a
+defect!
+</p>
+<p>
+Based on Greg's example, the following code demonstrates the issue:
+</p><pre> #include <iostream>
+ #include <fstream>
+ #include <streambuf>
+
+ typedef char C;
+ int main ()
+ {
+ std::ifstream s("filename", std::ios::in);
+ std::istreambuf_iterator<char> i(s);
+
+ (*i).~C(); // This is well-formed...
+ i->~C(); // ... so this should be supported!
+ }
+</pre>
+
+<p>
+Of course, operator-> is also needed when the value_type of
+istreambuf_iterator is a class.
+</p>
+<p>
+The operator-> could be implemented in various ways. For instance,
+by storing the current value inside the iterator, and returning its
+address. Or by returning a proxy, like operator_arrow_proxy, from
+<a href="http://www.boost.org/boost/iterator/iterator_facade.hpp">http://www.boost.org/boost/iterator/iterator_facade.hpp</a>
+</p>
+<p>
+I hope that the resolution of this issue will contribute to getting a
+clear and consistent definition of iterator concepts.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add to the synopsis in 24.5.3 [istreambuf.iterator]:
+</p>
+
+<blockquote><pre>charT operator*() const;
+<ins>pointer operator->() const;</ins>
+istreambuf_iterator<charT,traits>& operator++();
+</pre></blockquote>
+
+<p>
+Change 24.5.3 [istreambuf.iterator], p1:
+</p>
+
+<blockquote><p>
+The class template <tt>istreambuf_iterator</tt> reads successive
+characters from the <tt>streambuf</tt> for which it was constructed.
+<tt>operator*</tt> provides access to the current input character, if
+any. <ins><tt>operator-></tt> may return a proxy.</ins> Each time
+<tt>operator++</tt> is evaluated, the iterator advances to the next
+input character. If the end of stream is reached
+(<tt>streambuf_type::sgetc()</tt> returns <tt>traits::eof()</tt>), the
+iterator becomes equal to the end of stream iterator value. The default
+constructor <tt>istreambuf_iterator()</tt> and the constructor
+<tt>istreambuf_iterator(0)</tt> both construct an end of stream iterator
+object suitable for use as an end-of-range.
+</p></blockquote>
+
+
+
+<p><i>[
+Kona (2007): The proposed resolution is inconsistent because the return
+type of <tt>istreambuf_iterator::operator->()</tt> is specified to be <tt>pointer</tt>,
+but the proposed text also states that "<tt>operator-></tt> may return a proxy."
+]</i></p>
+
+
+<p><i>[
+Niels Dekker (mailed to Howard Hinnant):
+]</i></p>
+
+<blockquote>
+<p>
+The proposed resolution does
+not seem inconsistent to me. <tt>istreambuf_iterator::operator->()</tt> should
+have <tt>istreambuf_iterator::pointer</tt> as return type, and this return type
+may in fact be a proxy.
+</p>
+<p>
+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>
+unspecified for some iterator categories") implies that for any iterator
+class <tt>Iter</tt>, the return type of <tt>operator->()</tt> is <tt>Iter::pointer</tt>, by
+definition. I don't think <tt>Iter::pointer</tt> needs to be a raw pointer.
+</p>
+<p>
+Still I wouldn't mind if the text "<tt>operator-></tt> may return a proxy" would
+be removed from the resolution. I think it's up to the library
+implementation, how to implement <tt>istreambuf_iterator::operator->()</tt>. As
+longs as it behaves as expected: <tt>i->m</tt> should have the same effect as
+<tt>(*i).m</tt>. Even for an explicit destructor call, <tt>i->~C()</tt>. The main issue
+is just: <tt>istreambuf_iterator</tt> should have an <tt>operator->()</tt>!
+</p>
+</blockquote>
+
+
+
+
+<hr>
+<h3><a name="667"></a>667. <tt>money_get</tt>'s widened minus sign</h3>
+<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>
+ <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+22.2.6.1.2 [locale.money.get.virtuals], para 1 says:
+</p>
+
+<blockquote><p>
+The result is returned as an integral value
+stored in <tt>units</tt> or as a sequence of digits possibly preceded by a
+minus sign (as produced by <tt>ct.widen(c)</tt> where <tt>c</tt> is '-' or in the range
+from '0' through '9', inclusive) stored in <tt>digits</tt>.
+</p></blockquote>
+
+<p>
+The following
+objection has been raised:
+</p>
+
+<blockquote><p>
+Some implementations interpret this to mean that a facet derived from
+<tt>ctype<wchar_t></tt> can provide its own member <tt>do_widen(char)</tt>
+which produces e.g. <tt>L'@'</tt> for the "widened" minus sign, and that the
+<tt>'@'</tt> symbol will appear in the resulting sequence of digits. Other
+implementations have assumed that one or more places in the standard permit the
+implementation to "hard-wire" <tt>L'-'</tt> as the "widened" minus sign. Are
+both interpretations permissible, or only one?
+</p></blockquote>
+
+<p>
+[Plum ref _222612Y14]
+</p>
+
+<p>
+Furthermore: if <tt>ct.widen('9')</tt> produces <tt>L'X'</tt> (a non-digit), does a
+parse fail if a <tt>'9'</tt> appears in the subject string? [Plum ref _22263Y33]
+</p>
+
+<p><i>[
+Kona (2007): Bill and Dietmar to provide proposed wording.
+]</i></p>
+
+
+<p><i>[
+post Bellevue: Bill adds:
+]</i></p>
+
+
+<blockquote>
+The Standard is clear that the minus sign stored in <tt>digits</tt> is <tt>ct.widen('-')</tt>.
+The subject string must contain characters <tt>c</tt> in the set <tt>[-0123456789]</tt>
+which are translated by <tt>ct.widen(c)</tt> calls before being stored in <tt>digits</tt>;
+the widened characters are not relevant to the parsing of the subject string.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="668"></a>668. <tt>money_get</tt>'s empty minus sign</h3>
+<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>
+ <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+22.2.6.1.2 [locale.money.get.virtuals], para 3 says:
+</p>
+
+<blockquote><p>
+If <tt>pos</tt> or <tt>neg</tt> is empty, the sign component is
+optional, and if no sign is detected, the result is given the sign
+that corresponds to the source of the empty string.
+</p></blockquote>
+
+<p>
+The following
+objection has been raised:
+</p>
+
+<blockquote><p>
+A <tt>negative_sign</tt> of "" means "there is no
+way to write a negative sign" not "any null sequence is a negative
+sign, so it's always there when you look for it".
+</p></blockquote>
+
+<p>
+[Plum ref _222612Y32]
+</p>
+
+<p><i>[
+Kona (2007): Bill to provide proposed wording and interpretation of existing wording.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="669"></a>669. Equivalent postive and negative signs in <tt>money_get</tt></h3>
+<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>
+ <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+22.2.6.1.2 [locale.money.get.virtuals], para 3 sentence 4 says:
+</p>
+
+<blockquote><p>
+If the first character of <tt>pos</tt> is equal to the first character of <tt>neg</tt>,
+or if both strings are empty, the result is given a positive sign.
+</p></blockquote>
+
+<p>
+One interpretation is that an input sequence must match either the
+positive pattern or the negative pattern, and then in either event it
+is interpreted as positive. The following objections has been raised:
+</p>
+
+<blockquote><p>
+The input can successfully match only a positive sign, so the negative
+pattern is an unsuccessful match.
+</p></blockquote>
+
+<p>
+[Plum ref _222612Y34, 222612Y51b]
+</p>
+
+<p><i>[
+Bill to provide proposed wording and interpretation of existing wording.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="670"></a>670. <tt>money_base::pattern</tt> and <tt>space</tt></h3>
+<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>
+ <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
+<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>
+<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a></p>
+<p><b>Discussion:</b></p>
+
+
+<p>
+22.2.6.3 [locale.moneypunct], para 2 says:
+</p>
+
+<blockquote><p>
+The value <tt>space</tt> indicates that at least one space is required at
+that position.
+</p></blockquote>
+
+<p>
+The following objection has been raised:
+</p>
+
+<blockquote><p>
+Whitespace is optional when matching space. (See 22.2.6.1.2 [locale.money.get.virtuals], para 2.)
+</p></blockquote>
+
+<p>
+[Plum ref _22263Y22]
+</p>
+
+<p><i>[
+Kona (2007): Bill to provide proposed wording. We agree that C++03 is
+ambiguous, and that we want C++0X to say "space" means 0 or more
+whitespace characters on input.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="671"></a>671. precision of hexfloat</h3>
+<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>
+ <b>Submitter:</b> John Salmon <b>Date:</b> 2007-04-20</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+I am trying to understand how TR1 supports hex float (%a) output.
+</p>
+<p>
+As far as I can tell, it does so via the following:
+</p>
+<p>
+8.15 Additions to header <locale> [tr.c99.locale]
+</p>
+<p>
+In subclause 22.2.2.2.2 [facet.num.put.virtuals], Table 58 Floating-point conversions, after
+the line:
+floatfield == ios_base::scientific %E
+</p>
+<p>
+add the two lines:
+</p>
+<blockquote><pre>floatfield == ios_base::fixed | ios_base::scientific && !uppercase %a
+floatfield == ios_base::fixed | ios_base::scientific %A 2
+</pre></blockquote>
+<p>
+[Note: The additional requirements on print and scan functions, later
+in this clause, ensure that the print functions generate hexadecimal
+floating-point fields with a %a or %A conversion specifier, and that
+the scan functions match hexadecimal floating-point fields with a %g
+conversion specifier. end note]
+</p>
+<p>
+Following the thread, in 22.2.2.2.2 [facet.num.put.virtuals], we find:
+</p>
+<p>
+For conversion from a floating-point type, if (flags & fixed) != 0 or
+if str.precision() > 0, then str.precision() is specified in the
+conversion specification.
+</p>
+<p>
+This would seem to imply that when floatfield == fixed|scientific, the
+precision of the conversion specifier is to be taken from
+str.precision(). Is this really what's intended? I sincerely hope
+that I'm either missing something or this is an oversight. Please
+tell me that the committee did not intend to mandate that hex floats
+(and doubles) should by default be printed as if by %.6a.
+</p>
+
+<p><i>[
+Howard: I think the fundamental issue we overlooked was that with %f,
+%e, %g, the default precision was always 6. With %a the default
+precision is not 6, it is infinity. So for the first time, we need to
+distinguish between the default value of precision, and the precision
+value 6.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+<p><i>[
+Kona (2007): Robert volunteers to propose wording.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="675"></a>675. Move assignment of containers</h3>
+<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>
+ <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-05</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+James Hopkin pointed out to me that if <tt>vector<T></tt> move assignment is O(1)
+(just a <tt>swap</tt>) then containers such as <tt>vector<shared_ptr<ostream>></tt> might have
+the wrong semantics under move assignment when the source is not truly an rvalue, but a
+moved-from lvalue (destructors could run late).
+</p>
+
+<blockquote><pre><tt>vector<shared_ptr<ostream>></tt> v1;
+<tt>vector<shared_ptr<ostream>></tt> v2;
+...
+v1 = v2; // #1
+v1 = std::move(v2); // #2
+</pre></blockquote>
+
+<p>
+Move semantics means not caring what happens to the source (<tt>v2</tt> in this example).
+It doesn't mean not caring what happens to the target (<tt>v1</tt>). In the above example
+both assignments should have the same effect on <tt>v1</tt>. Any non-shared <tt>ostream</tt>'s
+<tt>v1</tt> owns before the assignment should be closed, whether <tt>v1</tt> is undergoing
+copy assignment or move assignment.
+</p>
+
+<p>
+This implies that the semantics of move assignment of a generic container should be
+<tt>clear, swap</tt> instead of just swap. An alternative which could achieve the same
+effect would be to move assign each element. In either case, the complexity of move
+assignment needs to be relaxed to <tt>O(v1.size())</tt>.
+</p>
+
+<p>
+The performance hit of this change is not nearly as drastic as it sounds.
+In practice, the target of a move assignment has always just been move constructed
+or move assigned <i>from</i>. Therefore under <tt>clear, swap</tt> semantics (in
+this common use case) we are still achieving O(1) complexity.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 23.1 [container.requirements]:
+</p>
+
+<blockquote>
+<table border="1">
+<caption>Table 89: Container requirements</caption>
+<tbody><tr>
+<th>expression</th><th>return type</th><th>operational semantics</th>
+<th>assertion/note pre/post-condition</th><th>complexity</th>
+</tr>
+<tr>
+<td><tt>a = rv;</tt></td><td><tt>X&</tt></td>
+<td>All existing elements of <tt>a</tt> are either move assigned or destructed</td>
+<td><tt>a</tt> shall be equal to the
+value that <tt>rv</tt> had
+before this construction
+</td>
+<td><del>(Note C)</del> <ins>linear</ins></td>
+</tr>
+</tbody></table>
+
+<p>
+Notes: the algorithms <tt>swap()</tt>, <tt>equal()</tt> and
+<tt>lexicographical_compare()</tt> are defined in clause 25. Those
+entries marked "(Note A)" should have constant complexity. Those entries
+marked "(Note B)" have constant complexity unless
+<tt>allocator_propagate_never<X::allocator_type>::value</tt> is
+<tt>true</tt>, in which case they have linear complexity.
+<del>Those entries
+marked "(Note C)" have constant complexity if <tt>a.get_allocator() ==
+rv.get_allocator()</tt> or if either
+<tt>allocator_propagate_on_move_assignment<X::allocator_type>::value</tt>
+is <tt>true</tt> or
+<tt>allocator_propagate_on_copy_assignment<X::allocator_type>::value</tt>
+is <tt>true</tt> and linear complexity otherwise.</del>
+</p>
+</blockquote>
+
+
+
+<p><i>[
+post Bellevue Howard adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+This issue was voted to WP in Bellevue, but accidently got stepped on by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>
+which was voted to WP simulataneously. Moving back to Open for the purpose of getting
+the wording right. The intent of this issue and N2525 are not in conflict.
+</p>
+</blockquote>
+
+<p><i>[
+post Sophia Antipolis Howard updated proposed wording:
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="676"></a>676. Moving the unordered containers</h3>
+<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>
+ <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-05</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+Move semantics are missing from the <tt>unordered</tt> containers. The proposed
+resolution below adds move-support consistent with
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1858.html">N1858</a>
+and the current working draft.
+</p>
+
+<p>
+The current proposed resolution simply lists the requirements for each function.
+These might better be hoisted into the requirements table for unordered associative containers.
+Futhermore a mild reorganization of the container requirements could well be in order.
+This defect report is purposefully ignoring these larger issues and just focusing
+on getting the unordered containers "moved".
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+Add to 23.4 [unord]:
+</p>
+
+<blockquote><pre>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
+ unordered_map<Key, T, Hash, Pred, Alloc>& y);
+
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
+ unordered_map<Key, T, Hash, Pred, Alloc>&& y);</ins>
+
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x,
+ unordered_map<Key, T, Hash, Pred, Alloc>& y);</ins>
+
+template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
+ unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
+
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
+ unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);</ins>
+
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x,
+ unordered_multimap<Key, T, Hash, Pred, Alloc>& y);</ins>
+
+...
+
+template <class Value, class Hash, class Pred, class Alloc>
+ void swap(unordered_set<Value, Hash, Pred, Alloc>& x,
+ unordered_set<Value, Hash, Pred, Alloc>& y);
+
+<ins>template <class Value, class Hash, class Pred, class Alloc>
+ void swap(unordered_set<Value, Hash, Pred, Alloc>& x,
+ unordered_set<Value, Hash, Pred, Alloc>&& y);</ins>
+
+<ins>template <class Value, class Hash, class Pred, class Alloc>
+ void swap(unordered_set<Value, Hash, Pred, Alloc>&& x,
+ unordered_set<Value, Hash, Pred, Alloc>& y);</ins>
+
+template <class Value, class Hash, class Pred, class Alloc>
+ void swap(unordered_multiset<Value, Hash, Pred, Alloc>& x,
+ unordered_multiset<Value, Hash, Pred, Alloc>& y);
+
+<ins>template <class Value, class Hash, class Pred, class Alloc>
+ void swap(unordered_multiset<Value, Hash, Pred, Alloc>& x,
+ unordered_multiset<Value, Hash, Pred, Alloc>&& y);</ins>
+
+<ins>template <class Value, class Hash, class Pred, class Alloc>
+ void swap(unordered_multiset<Value, Hash, Pred, Alloc>&& x,
+ unordered_multiset<Value, Hash, Pred, Alloc>& y);</ins>
+</pre></blockquote>
+
+<p><b><tt>unordered_map</tt></b></p>
+
+<p>
+Change 23.4.1 [unord.map]:
+</p>
+
+<blockquote><pre>class unordered_map
+{
+ ...
+ unordered_map(const unordered_map&);
+ <ins>unordered_map(unordered_map&&);</ins>
+ ~unordered_map();
+ unordered_map& operator=(const unordered_map&);
+ <ins>unordered_map& operator=(unordered_map&&);</ins>
+ ...
+ // modifiers
+ <del>std::</del>pair<iterator, bool> insert(const value_type& obj);
+ <ins>template <class P> pair<iterator, bool> insert(P&& obj);</ins>
+ iterator insert(iterator hint, const value_type& obj);
+ <ins>template <class P> iterator insert(iterator hint, P&& obj);</ins>
+ const_iterator insert(const_iterator hint, const value_type& obj);
+ <ins>template <class P> const_iterator insert(const_iterator hint, P&& obj);</ins>
+ ...
+ void swap(unordered_map&<ins>&</ins>);
+ ...
+ mapped_type& operator[](const key_type& k);
+ <ins>mapped_type& operator[](key_type&& k);</ins>
+ ...
+};
+
+template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
+ unordered_map<Key, T, Hash, Pred, Alloc>& y);
+
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
+ unordered_map<Key, T, Hash, Pred, Alloc>&& y);</ins>
+
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x,
+ unordered_map<Key, T, Hash, Pred, Alloc>& y);</ins>
+</pre></blockquote>
+
+<p>
+Add to 23.4.1.1 [unord.map.cnstr]:
+</p>
+
+<blockquote>
+<pre>template <class InputIterator>
+ unordered_map(InputIterator f, InputIterator l,
+ size_type n = <i>implementation-defined</i>,
+ const hasher& hf = hasher(),
+ const key_equal& eql = key_equal(),
+ const allocator_type& a = allocator_type());
+</pre>
+
+<blockquote><p>
+<ins>
+<i>Requires:</i> If the iterator's dereference operator returns an
+lvalue or a const rvalue <tt>pair<key_type, mapped_type></tt>,
+then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be
+<tt>CopyConstructible</tt>.
+</ins>
+</p></blockquote>
+</blockquote>
+
+<p>
+Add to 23.4.1.2 [unord.map.elem]:
+</p>
+
+<blockquote>
+
+<pre>mapped_type& operator[](const key_type& k);</pre>
+
+<blockquote>
+<p>...</p>
+<p><ins>
+<i>Requires:</i> <tt>key_type</tt> shall be <tt>CopyConstructible</tt>
+and <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>.
+</ins></p>
+</blockquote>
+
+<pre><ins>mapped_type& operator[](key_type&& k);</ins></pre>
+
+<blockquote>
+<p><ins>
+<i>Effects:</i> If the <tt>unordered_map</tt> does not already contain an
+element whose key is equivalent to <tt>k</tt> , inserts the value
+<tt>std::pair<const key_type, mapped_type>(std::move(k), mapped_type())</tt>.
+</ins></p>
+
+<p><ins>
+<i>Requires:</i> <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>.
+</ins></p>
+
+<p><ins>
+<i>Returns:</i> A reference to <tt>x.second</tt>, where <tt>x</tt> is the
+(unique) element whose key is equivalent to <tt>k</tt>.
+</ins></p>
+
+</blockquote>
+
+</blockquote>
+
+<p>
+Add new section [unord.map.modifiers]:
+</p>
+
+<blockquote>
+<pre><ins>pair<iterator, bool> insert(const value_type& x);</ins>
+<ins>template <class P> pair<iterator, bool> insert(P&& x);</ins>
+<ins>iterator insert(iterator hint, const value_type& x);</ins>
+<ins>template <class P> iterator insert(iterator hint, P&& x);</ins>
+<ins>const_iterator insert(const_iterator hint, const value_type& x);</ins>
+<ins>template <class P> const_iterator insert(const_iterator hint, P&& x);</ins>
+<ins>template <class InputIterator>
+ void insert(InputIterator first, InputIterator last);</ins>
+</pre>
+
+<blockquote>
+<p><ins>
+<i>Requires:</i> Those signatures taking a <tt>const value_type&</tt> parameter
+requires both the <tt>key_type</tt> and the <tt>mapped_type</tt> to be
+<tt>CopyConstructible</tt>.
+</ins></p>
+
+<p><ins>
+<tt>P</tt> shall be convertible to <tt>value_type</tt>.
+ If <tt>P</tt> is instantiated as a reference
+type, then the argument <tt>x</tt> is copied from. Otherwise <tt>x</tt>
+is considered to be an rvalue as it is converted to <tt>value_type</tt>
+and inserted into the <tt>unordered_map</tt>. Specifically, in such
+cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or
+<tt>mapped_type</tt> unless the conversion from <tt>P</tt> specifically
+requires it (e.g. if <tt>P</tt> is a <tt>tuple<const key_type,
+mapped_type></tt>, then <tt>key_type</tt> must be
+<tt>CopyConstructible</tt>).
+</ins></p>
+
+<p><ins>
+The signature taking <tt>InputIterator</tt>
+parameters requires <tt>CopyConstructible</tt> of both
+<tt>key_type</tt> and <tt>mapped_type</tt> if the dereferenced
+<tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
+<tt>value_type</tt>.
+</ins></p>
+
+</blockquote>
+
+</blockquote>
+
+<p>
+Add to 23.4.1.3 [unord.map.swap]:
+</p>
+
+<blockquote>
+<pre>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
+ unordered_map<Key, T, Hash, Pred, Alloc>& y);
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
+ unordered_map<Key, T, Hash, Pred, Alloc>&& y);</ins>
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x,
+ unordered_map<Key, T, Hash, Pred, Alloc>& y);</ins>
+</pre>
+</blockquote>
+
+<p><b><tt>unordered_multimap</tt></b></p>
+
+<p>
+Change 23.4.2 [unord.multimap]:
+</p>
+
+<blockquote><pre>class unordered_multimap
+{
+ ...
+ unordered_multimap(const unordered_multimap&);
+ <ins>unordered_multimap(unordered_multimap&&);</ins>
+ ~unordered_multimap();
+ unordered_multimap& operator=(const unordered_multimap&);
+ <ins>unordered_multimap& operator=(unordered_multimap&&);</ins>
+ ...
+ // modifiers
+ iterator insert(const value_type& obj);
+ <ins>template <class P> iterator insert(P&& obj);</ins>
+ iterator insert(iterator hint, const value_type& obj);
+ <ins>template <class P> iterator insert(iterator hint, P&& obj);</ins>
+ const_iterator insert(const_iterator hint, const value_type& obj);
+ <ins>template <class P> const_iterator insert(const_iterator hint, P&& obj);</ins>
+ ...
+ void swap(unordered_multimap&<ins>&</ins>);
+ ...
+};
+
+template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
+ unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
+
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
+ unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);</ins>
+
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x,
+ unordered_multimap<Key, T, Hash, Pred, Alloc>& y);</ins>
+</pre></blockquote>
+
+<p>
+Add to 23.4.2.1 [unord.multimap.cnstr]:
+</p>
+
+<blockquote>
+<pre>template <class InputIterator>
+ unordered_multimap(InputIterator f, InputIterator l,
+ size_type n = <i>implementation-defined</i>,
+ const hasher& hf = hasher(),
+ const key_equal& eql = key_equal(),
+ const allocator_type& a = allocator_type());
+</pre>
+
+<blockquote><p>
+<ins>
+<i>Requires:</i> If the iterator's dereference operator returns an
+lvalue or a const rvalue <tt>pair<key_type, mapped_type></tt>,
+then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be
+<tt>CopyConstructible</tt>.
+</ins>
+</p></blockquote>
+</blockquote>
+
+<p>
+Add new section [unord.multimap.modifiers]:
+</p>
+
+<blockquote>
+<pre><ins>iterator insert(const value_type& x);</ins>
+<ins>template <class P> iterator insert(P&& x);</ins>
+<ins>iterator insert(iterator hint, const value_type& x);</ins>
+<ins>template <class P> iterator insert(iterator hint, P&& x);</ins>
+<ins>const_iterator insert(const_iterator hint, const value_type& x);</ins>
+<ins>template <class P> const_iterator insert(const_iterator hint, P&& x);</ins>
+<ins>template <class InputIterator>
+ void insert(InputIterator first, InputIterator last);</ins>
+</pre>
+
+<blockquote>
+<p><ins>
+<i>Requires:</i> Those signatures taking a <tt>const value_type&</tt> parameter
+requires both the <tt>key_type</tt> and the <tt>mapped_type</tt> to be
+<tt>CopyConstructible</tt>.
+</ins></p>
+
+<p><ins>
+<tt>P</tt> shall be convertible to <tt>value_type</tt>.
+ If <tt>P</tt> is instantiated as a reference
+type, then the argument <tt>x</tt> is copied from. Otherwise <tt>x</tt>
+is considered to be an rvalue as it is converted to <tt>value_type</tt>
+and inserted into the <tt>unordered_multimap</tt>. Specifically, in such
+cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or
+<tt>mapped_type</tt> unless the conversion from <tt>P</tt> specifically
+requires it (e.g. if <tt>P</tt> is a <tt>tuple<const key_type,
+mapped_type></tt>, then <tt>key_type</tt> must be
+<tt>CopyConstructible</tt>).
+</ins></p>
+
+<p><ins>
+The signature taking <tt>InputIterator</tt>
+parameters requires <tt>CopyConstructible</tt> of both
+<tt>key_type</tt> and <tt>mapped_type</tt> if the dereferenced
+<tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
+<tt>value_type</tt>.
+</ins></p>
+</blockquote>
+
+</blockquote>
+
+<p>
+Add to 23.4.2.2 [unord.multimap.swap]:
+</p>
+
+<blockquote>
+<pre>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
+ unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
+ unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);</ins>
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x,
+ unordered_multimap<Key, T, Hash, Pred, Alloc>& y);</ins>
+</pre>
+</blockquote>
+
+<p><b><tt>unordered_set</tt></b></p>
+
+<p>
+Change 23.4.3 [unord.set]:
+</p>
+
+<blockquote><pre>class unordered_set
+{
+ ...
+ unordered_set(const unordered_set&);
+ <ins>unordered_set(unordered_set&&);</ins>
+ ~unordered_set();
+ unordered_set& operator=(const unordered_set&);
+ <ins>unordered_set& operator=(unordered_set&&);</ins>
+ ...
+ // modifiers
+ <del>std::</del>pair<iterator, bool> insert(const value_type& obj);
+ <ins>pair<iterator, bool> insert(value_type&& obj);</ins>
+ iterator insert(iterator hint, const value_type& obj);
+ <ins>iterator insert(iterator hint, value_type&& obj);</ins>
+ const_iterator insert(const_iterator hint, const value_type& obj);
+ <ins>const_iterator insert(const_iterator hint, value_type&& obj);</ins>
+ ...
+ void swap(unordered_set&<ins>&</ins>);
+ ...
+};
+
+template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x,
+ unordered_set<Key, T, Hash, Pred, Alloc>& y);
+
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x,
+ unordered_set<Key, T, Hash, Pred, Alloc>&& y);</ins>
+
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_set<Key, T, Hash, Pred, Alloc>&& x,
+ unordered_set<Key, T, Hash, Pred, Alloc>& y);</ins>
+</pre></blockquote>
+
+<p>
+Add to 23.4.3.1 [unord.set.cnstr]:
+</p>
+
+<blockquote>
+<pre>template <class InputIterator>
+ unordered_set(InputIterator f, InputIterator l,
+ size_type n = <i>implementation-defined</i>,
+ const hasher& hf = hasher(),
+ const key_equal& eql = key_equal(),
+ const allocator_type& a = allocator_type());
+</pre>
+
+<blockquote><p>
+<ins>
+<i>Requires:</i> If the iterator's dereference operator returns an
+lvalue or a const rvalue <tt>value_type</tt>, then the
+<tt>value_type</tt> shall be <tt>CopyConstructible</tt>.
+</ins>
+</p></blockquote>
+</blockquote>
+
+<p>
+Add new section [unord.set.modifiers]:
+</p>
+
+<blockquote>
+<pre><ins>pair<iterator, bool> insert(const value_type& x);</ins>
+<ins>pair<iterator, bool> insert(value_type&& x);</ins>
+<ins>iterator insert(iterator hint, const value_type& x);</ins>
+<ins>iterator insert(iterator hint, value_type&& x);</ins>
+<ins>const_iterator insert(const_iterator hint, const value_type& x);</ins>
+<ins>const_iterator insert(const_iterator hint, value_type&& x);</ins>
+<ins>template <class InputIterator>
+ void insert(InputIterator first, InputIterator last);</ins>
+</pre>
+
+<blockquote>
+
+<p><ins>
+<i>Requires:</i> Those signatures taking a <tt>const
+value_type&</tt> parameter requires the <tt>value_type</tt> to
+be <tt>CopyConstructible</tt>.
+</ins></p>
+
+<p><ins>
+The signature taking <tt>InputIterator</tt> parameters requires
+<tt>CopyConstructible</tt> of <tt>value_type</tt> if the dereferenced
+<tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
+<tt>value_type</tt>.
+</ins></p>
+
+</blockquote>
+
+</blockquote>
+
+<p>
+Add to 23.4.3.2 [unord.set.swap]:
+</p>
+
+<blockquote>
+<pre>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x,
+ unordered_set<Key, T, Hash, Pred, Alloc>& y);
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x,
+ unordered_set<Key, T, Hash, Pred, Alloc>&& y);</ins>
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_set<Key, T, Hash, Pred, Alloc>&& x,
+ unordered_set<Key, T, Hash, Pred, Alloc>& y);</ins>
+</pre>
+</blockquote>
+
+<p><b><tt>unordered_multiset</tt></b></p>
+
+<p>
+Change 23.4.4 [unord.multiset]:
+</p>
+
+<blockquote><pre>class unordered_multiset
+{
+ ...
+ unordered_multiset(const unordered_multiset&);
+ <ins>unordered_multiset(unordered_multiset&&);</ins>
+ ~unordered_multiset();
+ unordered_multiset& operator=(const unordered_multiset&);
+ <ins>unordered_multiset& operator=(unordered_multiset&&);</ins>
+ ...
+ // modifiers
+ iterator insert(const value_type& obj);
+ <ins>iterator insert(value_type&& obj);</ins>
+ iterator insert(iterator hint, const value_type& obj);
+ <ins>iterator insert(iterator hint, value_type&& obj);</ins>
+ const_iterator insert(const_iterator hint, const value_type& obj);
+ <ins>const_iterator insert(const_iterator hint, value_type&& obj);</ins>
+ ...
+ void swap(unordered_multiset&<ins>&</ins>);
+ ...
+};
+
+template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x,
+ unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
+
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x,
+ unordered_multiset<Key, T, Hash, Pred, Alloc>&& y);</ins>
+
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>&& x,
+ unordered_multiset<Key, T, Hash, Pred, Alloc>& y);</ins>
+</pre></blockquote>
+
+<p>
+Add to 23.4.4.1 [unord.multiset.cnstr]:
+</p>
+
+<blockquote>
+<pre>template <class InputIterator>
+ unordered_multiset(InputIterator f, InputIterator l,
+ size_type n = <i>implementation-defined</i>,
+ const hasher& hf = hasher(),
+ const key_equal& eql = key_equal(),
+ const allocator_type& a = allocator_type());
+</pre>
+
+<blockquote><p>
+<ins>
+<i>Requires:</i> If the iterator's dereference operator returns an
+lvalue or a const rvalue <tt>value_type</tt>, then the
+<tt>value_type</tt> shall be <tt>CopyConstructible</tt>.
+</ins>
+</p></blockquote>
+</blockquote>
+
+<p>
+Add new section [unord.multiset.modifiers]:
+</p>
+
+<blockquote>
+<pre><ins>iterator insert(const value_type& x);</ins>
+<ins>iterator insert(value_type&& x);</ins>
+<ins>iterator insert(iterator hint, const value_type& x);</ins>
+<ins>iterator insert(iterator hint, value_type&& x);</ins>
+<ins>const_iterator insert(const_iterator hint, const value_type& x);</ins>
+<ins>const_iterator insert(const_iterator hint, value_type&& x);</ins>
+<ins>template <class InputIterator>
+ void insert(InputIterator first, InputIterator last);</ins>
+</pre>
+
+<blockquote>
+
+<p><ins>
+<i>Requires:</i> Those signatures taking a <tt>const
+value_type&</tt> parameter requires the <tt>value_type</tt> to
+be <tt>CopyConstructible</tt>.
+</ins></p>
+
+<p><ins>
+The signature taking <tt>InputIterator</tt> parameters requires
+<tt>CopyConstructible</tt> of <tt>value_type</tt> if the dereferenced
+<tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
+<tt>value_type</tt>.
+</ins></p>
+
+</blockquote>
+
+</blockquote>
+
+<p>
+Add to 23.4.4.2 [unord.multiset.swap]:
+</p>
+
+<blockquote>
+<pre>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x,
+ unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x,
+ unordered_multiset<Key, T, Hash, Pred, Alloc>&& y);</ins>
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>&& x,
+ unordered_multiset<Key, T, Hash, Pred, Alloc>& y);</ins>
+</pre>
+</blockquote>
+
+
+
+<p><i>[
+Voted to WP in Bellevue.
+]</i></p>
+
+
+<p><i>[
+post Bellevue, Pete notes:
+]</i></p>
+
+
+<blockquote>
+<p>
+Please remind people who are reviewing issues to check that the text
+modifications match the current draft. Issue 676, for example, adds two
+overloads for unordered_map::insert taking a hint. One takes a
+const_iterator and returns a const_iterator, and the other takes an
+iterator and returns an iterator. This was correct at the time the issue
+was written, but was changed in Toronto so there is only one hint
+overload, taking a const_iterator and returning an iterator.
+</p>
+<p>
+This issue is not ready. In addition to the relatively minor signature
+problem I mentioned earlier, it puts requirements in the wrong places.
+Instead of duplicating requirements throughout the template
+specifications, it should put them in the front matter that talks about
+requirements for unordered containers in general. This presentation
+problem is editorial, but I'm not willing to do the extensive rewrite
+that it requires. Please put it back into Open status.
+</p>
+</blockquote>
+
+
+
+
+<hr>
+<h3><a name="688"></a>688. reference_wrapper, cref unsafe, allow binding to rvalues</h3>
+<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>
+ <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+A <tt>reference_wrapper</tt> can be constructed from an rvalue, either by using
+the constructor, or via <tt>cref</tt> (and <tt>ref</tt> in some corner cases). This leads
+to a dangling reference being stored into the <tt>reference_wrapper</tt> object.
+Now that we have a mechanism to detect an rvalue, we can fix them to
+disallow this source of undefined behavior.
+</p>
+
+<p>
+Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 20.6 [function.objects], add the following two signatures to the synopsis:
+</p>
+
+<blockquote><pre>template <class T> void ref(const T&& t) = delete;
+template <class T> void cref(const T&& t) = delete;
+</pre></blockquote>
+
+
+
+<p><i>[
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2292.html">N2292</a>
+addresses the first part of the resolution but not the second.
+]</i></p>
+
+
+<p><i>[
+Bellevue: Doug noticed problems with the current wording.
+]</i></p>
+
+
+<p><i>[
+post Bellevue: Howard and Peter provided revised wording.
+]</i></p>
+
+
+<p><i>[
+This resolution depends on a "favorable" resolution of CWG 606: that is,
+the "special deduction rule" is disabled with the const T&& pattern.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="691"></a>691. const_local_iterator cbegin, cend missing from TR1</h3>
+<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>
+ <b>Submitter:</b> Joaquín M López Muñoz <b>Date:</b> 2007-06-14</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The last version of TR1 does not include the following member
+functions
+for unordered containers:
+</p>
+
+<blockquote><pre>const_local_iterator cbegin(size_type n) const;
+const_local_iterator cend(size_type n) const;
+</pre></blockquote>
+
+<p>
+which looks like an oversight to me. I've checked th TR1 issues lists
+and the latest working draft of the C++0x std (N2284) and haven't
+found any mention to these menfuns or to their absence.
+</p>
+<p>
+Is this really an oversight, or am I missing something?
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the following two rows to table 93 (unordered associative container
+requirements) in section 23.1.5 [unord.req]:
+</p>
+
+<blockquote>
+<table border="1">
+<caption>Unordered associative container requirements (in addition to container)</caption>
+<tbody><tr>
+<th>expression</th> <th>return type</th> <th>assertion/note pre/post-condition</th> <th>complexity</th>
+</tr>
+<tr>
+<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>
+</tr>
+<tr>
+<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>
+</tr>
+</tbody></table>
+</blockquote>
+
+<p>
+Add to the synopsis in 23.4.1 [unord.map]:
+</p>
+
+<blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
+const_local_iterator cend(size_type n) const;</ins>
+</pre></blockquote>
+
+<p>
+Add to the synopsis in 23.4.2 [unord.multimap]:
+</p>
+
+<blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
+const_local_iterator cend(size_type n) const;</ins>
+</pre></blockquote>
+
+<p>
+Add to the synopsis in 23.4.3 [unord.set]:
+</p>
+
+<blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
+const_local_iterator cend(size_type n) const;</ins>
+</pre></blockquote>
+
+<p>
+Add to the synopsis in 23.4.4 [unord.multiset]:
+</p>
+
+<blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
+const_local_iterator cend(size_type n) const;</ins>
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="692"></a>692. <code>get_money</code> and <code>put_money</code> should be formatted I/O functions</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+In a private email Bill Plauger notes:
+</p>
+<blockquote><p>
+I believe that the function that implements <code>get_money</code>
+[from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2072.html">N2072</a>]
+should behave as a formatted input function, and the function that
+implements <code>put_money</code> should behave as a formatted output
+function. This has implications regarding the skipping of whitespace
+and the handling of errors, among other things.
+</p>
+<p>
+The words don't say that right now and I'm far from convinced that
+such a change is editorial.
+</p></blockquote>
+<p>
+Martin's response:
+</p>
+<blockquote><p>
+I agree that the manipulators should handle exceptions the same way as
+formatted I/O functions do. The text in N2072 assumes so but the
+<i>Returns</i> clause explicitly omits exception handling for the sake
+of brevity. The spec should be clarified to that effect.
+</p>
+<p>
+As for dealing with whitespace, I also agree it would make sense for
+the extractors and inserters involving the new manipulators to treat
+it the same way as formatted I/O.
+</p></blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add a new paragraph immediately above p4 of 27.6.4 [ext.manip] with the
+following text:
+</p>
+<blockquote><p>
+<i>Effects</i>: The expression <code><i>in</i> >> get_money(mon, intl)</code>
+described below behaves as a formatted input function (as
+described in 27.6.1.2.1 [istream.formatted.reqmts]).
+</p></blockquote>
+<p>
+Also change p4 of 27.6.4 [ext.manip] as follows:
+</p>
+<blockquote><p>
+<i>Returns</i>: An object <code>s</code> of unspecified type such that
+if <code>in</code> is an object of type <code>basic_istream<charT,
+traits></code> then the expression <code><i>in</i> >> get_money(mon, intl)</code> behaves as <ins>a formatted input function
+that calls </ins><code>f(in, mon, intl)</code><del> were
+called</del>. The function <code>f</code> can be defined as...
+</p></blockquote>
+
+
+<p><i>[
+post Bellevue:
+]</i></p>
+
+
+<blockquote>
+We recommend moving immediately to Review. We've looked at the issue and
+have a consensus that the proposed resolution is correct, but want an
+iostream expert to sign off. Alisdair has taken the action item to putt
+this up on the reflector for possible movement by Howard to Tenatively
+Ready.
+</blockquote>
+
+
+
+
+<hr>
+<h3><a name="696"></a>696. <code>istream::operator>>(int&)</code> broken</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-23</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+From message c++std-lib-17897:
+</p>
+<p>
+The code shown in 27.6.1.2.2 [istream.formatted.arithmetic] as the "as if"
+implementation of the two arithmetic extractors that don't have a
+corresponding <code>num_get</code> interface (i.e., the
+<code>short</code> and <code>int</code> overloads) is subtly buggy in
+how it deals with <code>EOF</code>, overflow, and other similar
+conditions (in addition to containing a few typos).
+</p>
+<p>
+One problem is that if <code>num_get::get()</code> reaches the EOF
+after reading in an otherwise valid value that exceeds the limits of
+the narrower type (but not <code>LONG_MIN</code> or
+<code>LONG_MAX</code>), it will set <code><i>err</i></code> to
+<code>eofbit</code>. Because of the if condition testing for
+<code>(<i>err</i> == 0)</code>, the extractor won't set
+<code>failbit</code> (and presumably, return a bogus value to the
+caller).
+</p>
+<p>
+Another problem with the code is that it never actually sets the
+argument to the extracted value. It can't happen after the call to
+<code>setstate()</code> since the function may throw, so we need to
+show when and how it's done (we can't just punt as say: "it happens
+afterwards"). However, it turns out that showing how it's done isn't
+quite so easy since the argument is normally left unchanged by the
+facet on error except when the error is due to a misplaced thousands
+separator, which causes <code>failbit</code> to be set but doesn't
+prevent the facet from storing the value.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="698"></a>698. <tt>system_error</tt> needs <tt>const char*</tt> constructors</h3>
+<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>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-06-24</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+In 19.4.5.1 [syserr.syserr.overview] we have the class definition of
+<tt>std::system_error</tt>. In contrast to all exception classes, which
+are constructible with a <tt>what_arg string</tt> (see 19.1 [std.exceptions],
+or <tt>ios_base::failure</tt> in 27.4.2.1.1 [ios::failure]), only overloads with with
+<tt>const string&</tt> are possible. For consistency with the re-designed
+remaining exception classes this class should also provide
+c'tors which accept a const <tt>char* what_arg</tt> string.
+</p>
+<p>
+Please note that this proposed addition makes sense even
+considering the given implementation hint for <tt>what()</tt>, because
+<tt>what_arg</tt> is required to be set as <tt>what_arg</tt> of the base class
+<tt>runtime_error</tt>, which now has the additional c'tor overload
+accepting a <tt>const char*</tt>.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+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.
+</p>
+
+<p>
+Change 19.4.5.1 [syserr.syserr.overview] Class system_error overview, as indicated:
+</p>
+
+<blockquote><pre>public:
+ system_error(error_code ec, const string& what_arg);
+ <ins>system_error(error_code ec, const char* what_arg);</ins>
+ system_error(error_code ec);
+ system_error(int ev, const error_category* ecat,
+ const string& what_arg);
+ <ins>system_error(int ev, const error_category* ecat,
+ const char* what_arg);</ins>
+ system_error(int ev, const error_category* ecat);
+</pre></blockquote>
+
+<p>
+To 19.4.5.2 [syserr.syserr.members] Class system_error members add:
+</p>
+
+<blockquote>
+<pre>system_error(error_code ec, const char* what_arg);
+</pre>
+<blockquote>
+<p>
+<i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
+</p>
+<p>
+<i>Postconditions:</i> <tt>code() == ec</tt> and <tt>strcmp(runtime_error::what(), what_arg) == 0</tt>.
+</p>
+</blockquote>
+
+<pre>system_error(int ev, const error_category* ecat, const char* what_arg);
+</pre>
+
+<blockquote>
+<p>
+<i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
+</p>
+<p>
+<i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and <tt>strcmp(runtime_error::what(), what_arg) == 0</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="701"></a>701. assoc laguerre poly's</h3>
+<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>
+ <b>Submitter:</b> Christopher Crawford <b>Date:</b> 2007-06-30</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+I see that the definition the associated Laguerre
+polynomials TR1 5.2.1.1 [tr.num.sf.Lnm] has been corrected since
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1687.pdf">N1687</a>.
+However, the draft standard only specifies ranks of integer value <tt>m</tt>,
+while the associated Laguerre polynomials are actually valid for real
+values of <tt>m > -1</tt>. In the case of non-integer values of <tt>m</tt>, the
+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>
+must be used, which also holds for integer values of <tt>m</tt>. See
+Abramowitz & Stegun, 22.11.6 for the general case, and 22.5.16-17 for
+the integer case. In fact fractional values are most commonly used in
+physics, for example to <tt>m = +/- 1/2</tt> to describe the harmonic
+oscillator in 1 dimension, and <tt>1/2, 3/2, 5/2, ...</tt> in 3
+dimensions.
+</p>
+<p>
+If I am correct, the calculation of the more general case is no
+more difficult, and is in fact the function implemented in the GNU
+Scientific Library. I would urge you to consider upgrading the
+standard, either adding extra functions for real <tt>m</tt> or switching the
+current ones to <tt>double</tt>.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="702"></a>702. Restriction in associated Legendre functions</h3>
+<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>
+ <b>Submitter:</b> Christopher Crawford <b>Date:</b> 2007-06-30</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should be
+<tt>|x| <= 1</tt>, not <tt>x >= 0</tt>.</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="704"></a>704. MoveAssignable requirement for container value type overly strict</h3>
+<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>
+ <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-20</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+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>.
+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
+most of the member functions of node-based containers. But the move-related changes
+unnecessarily introduced the <tt>MoveAssignable</tt> requirement for those members which used to
+require <tt>CopyAssignable</tt>.
+</p>
+
+<p>
+We also discussed (c++std-lib-18722) the possibility of dropping <tt>MoveAssignable</tt>
+from some of the sequence requirements. Additionally the <i>in-place</i> construction
+work may further reduce requirements. For purposes of an easy reference, here are the
+minimum sequence requirements as I currently understand them. Those items in requirements
+table in the working draft which do not appear below have been purposefully omitted for
+brevity as they do not have any requirements of this nature. Some items which do not
+have any requirements of this nature are included below just to confirm that they were
+not omitted by mistake.
+</p>
+
+<table border="1">
+<caption>Container Requirements</caption>
+<tbody><tr><td><tt>X u(a)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
+<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>
+<tr><td><tt>a = u</tt></td><td>Sequences require <tt>value_type</tt> to be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.
+ Associative containers require <tt>value_type</tt> to be <tt>CopyConstructible</tt>.</td></tr>
+<tr><td><tt>a = rv</tt></td><td><tt>array</tt> requires <tt>value_type</tt> to be <tt>MoveAssignable</tt>.
+ 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>
+<tr><td><tt>swap(a,u)</tt></td><td><tt>array</tt> and containers with <tt>propagate_never</tt> and
+ <tt>propagate_on_copy_construction</tt> allocators require <tt>value_type</tt> to be <tt>Swappable</tt>.</td></tr>
+</tbody></table>
+
+<p>
+</p>
+
+<table border="1">
+<caption>Sequence Requirements</caption>
+<tbody><tr><td><tt>X(n)</tt></td><td><tt>value_type</tt> must be <tt>DefaultConstructible</tt></td></tr>
+<tr><td><tt>X(n, t)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
+<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>.
+ If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
+ The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
+<tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
+ The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
+<tr><td><tt>a.insert(p, n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
+ The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
+<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>.
+ 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.
+ If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
+ 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>
+<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>
+<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>
+<tr><td><tt>a.clear()</tt></td><td></td></tr>
+<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>.
+ If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.</td></tr>
+<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>
+<tr><td><tt>a.resize(n)</tt></td><td>The <tt>value_type</tt> must be <tt>DefaultConstructible</tt>.
+ The sequence <tt>vector</tt> also requires the <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a.resize(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
+</tbody></table>
+
+<p>
+</p>
+
+<table border="1">
+<caption>Optional Sequence Requirements</caption>
+<tbody><tr><td><tt>a.front()</tt></td><td></td></tr>
+<tr><td><tt>a.back()</tt></td><td></td></tr>
+<tr><td><tt>a.push_front(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
+<tr><td><tt>a.push_front(rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a.push_back(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
+<tr><td><tt>a.push_back(rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a.pop_front()</tt></td><td></td></tr>
+<tr><td><tt>a.pop_back()</tt></td><td></td></tr>
+<tr><td><tt>a[n]</tt></td><td></td></tr>
+<tr><td><tt>a.at[n]</tt></td><td></td></tr>
+</tbody></table>
+
+<p>
+</p>
+
+<table border="1">
+<caption>Associative Container Requirements</caption>
+<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>.
+ If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
+<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>
+<tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
+<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>
+<tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
+<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>
+<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>.
+ 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>
+</tbody></table>
+
+<p>
+</p>
+
+<table border="1">
+<caption>Unordered Associative Container Requirements</caption>
+<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>.
+ If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
+<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>
+<tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
+<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>
+<tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
+<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>
+<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>.
+ 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>
+</tbody></table>
+
+<p>
+</p>
+
+<table border="1">
+<caption>Miscellaneous Requirements</caption>
+<tbody><tr><td><tt>map[lvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>CopyConstructible</tt>.
+ The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr>
+<tr><td><tt>map[rvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>MoveConstructible</tt>.
+ The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr>
+</tbody></table>
+
+<p><i>[
+Kona (2007): Howard and Alan to update requirements table in issue with emplace signatures.
+]</i></p>
+
+
+<p><i>[
+Bellevue: This should be handled as part of the concepts work.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+
+<hr>
+<h3><a name="708"></a>708. Locales need to be per thread and updated for POSIX changes</h3>
+<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>
+ <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-07-28</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The POSIX "Extended API Set Part 4,"
+</p>
+<blockquote><p>
+<a href="http://www.opengroup.org/sib/details.tpl?id=C065">http://www.opengroup.org/sib/details.tpl?id=C065</a>
+</p></blockquote>
+<p>
+introduces extensions to the C locale mechanism that
+allow multiple concurrent locales to be used in the same application
+by introducing a type <tt>locale_t</tt> that is very similar to
+<tt>std::locale</tt>, and a number of <tt>_l</tt> functions that make use of it.
+</p>
+<p>
+The global locale (set by setlocale) is now specified to be per-
+process. If a thread does not call <tt>uselocale</tt>, the global locale is
+in effect for that thread. It can install a per-thread locale by
+using <tt>uselocale</tt>.
+</p>
+<p>
+There is also a nice <tt>querylocale</tt> mechanism by which one can obtain
+the name (such as "de_DE") for a specific <tt>facet</tt>, even for combined
+locales, with no <tt>std::locale</tt> equivalent.
+</p>
+<p>
+<tt>std::locale</tt> should be harmonized with the new POSIX <tt>locale_t</tt>
+mechanism and provide equivalents for <tt>uselocale</tt> and <tt>querylocale</tt>.
+</p>
+
+<p><i>[
+Kona (2007): Bill and Nick to provide wording.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="709"></a>709. <tt>char_traits::not_eof</tt> has wrong signature</h3>
+<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>
+ <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-13</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The changes made for <tt>constexpr</tt> in 21.1.3 [char.traits.specializations] have
+not only changed the <tt>not_eof</tt> function from pass by const reference to
+pass by value, it has also changed the parameter type from <tt>int_type</tt> to
+<tt>char_type</tt>.
+</p>
+<p>
+This doesn't work for type <tt>char</tt>, and is inconsistent with the
+requirements in Table 56, Traits requirements, 21.1.1 [char.traits.require].
+</p>
+
+<p>
+Pete adds:
+</p>
+
+<blockquote><p>
+For what it's worth, that may not have been an intentional change.
+N2349, which detailed the changes for adding constant expressions to
+the library, has strikeout bars through the <tt>const</tt> and the <tt>&</tt> that
+surround the <tt>char_type</tt> argument, but none through <tt>char_type</tt> itself.
+So the intention may have been just to change to pass by value, with
+text incorrectly copied from the standard.
+</p></blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the signature in 21.1.3.1 [char.traits.specializations.char],
+21.1.3.2 [char.traits.specializations.char16_t], 21.1.3.3 [char.traits.specializations.char32_t],
+and 21.1.3.4 [char.traits.specializations.wchar.t] to
+</p>
+
+<blockquote><pre>static constexpr int_type not_eof(<del>char_type</del> <ins>int_type</ins> c);
+</pre></blockquote>
+
+
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Resolution: NAD editorial - up to Pete's judgment
+</blockquote>
+
+<p><i>[
+Post Sophia Antipolis
+]</i></p>
+
+
+<blockquote>
+Moved from Pending NAD Editorial to Review. The proposed wording appears to be correct but non-editorial.
+</blockquote>
+
+
+
+
+<hr>
+<h3><a name="711"></a>711. Contradiction in empty <tt>shared_ptr</tt></h3>
+<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>
+ <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-08-24</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+A discussion on
+<a href="http://groups.google.com/group/comp.std.c++/browse_frm/thread/8e89dceb35cd7971">comp.std.c++</a>
+has identified a contradiction in the <tt>shared_ptr</tt> specification.
+The note:
+</p>
+
+<blockquote><p>
+[ <i>Note:</i> this constructor allows creation of an empty shared_ptr instance with a non-NULL stored pointer.
+-end note ]
+</p></blockquote>
+
+<p>
+after the aliasing constructor
+</p>
+
+<blockquote><pre>template<class Y> shared_ptr(shared_ptr<Y> const& r, T *p);
+</pre></blockquote>
+
+<p>
+reflects the intent of
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm">N2351</a>
+to, well, allow the creation of an empty <tt>shared_ptr</tt>
+with a non-NULL stored pointer.
+</p>
+
+<p>
+This is contradicted by the second sentence in the Returns clause of 20.7.12.2.5 [util.smartptr.shared.obs]:
+</p>
+
+<blockquote>
+<pre>T* get() const;
+</pre>
+<blockquote><p>
+<i>Returns:</i> the stored pointer. Returns a null pointer if <tt>*this</tt> is empty.
+</p></blockquote>
+</blockquote>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+Adopt option 1 and move to review, not ready.
+</p>
+<p>
+There was a lot of confusion about what an empty <tt>shared_ptr</tt> is (the term
+isn't defined anywhere), and whether we have a good mental model for how
+one behaves. We think it might be possible to deduce what the definition
+should be, but the words just aren't there. We need to open an issue on
+the use of this undefined term. (The resolution of that issue might
+affect the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>.)
+</p>
+<p>
+The LWG is getting more uncomfortable with the aliasing proposal (N2351)
+now that we realize some of its implications, and we need to keep an eye
+on it, but there isn't support for removing this feature at this time.
+</p>
+</blockquote>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+We heard from Peter Dimov, who explained his reason for preferring solution 1.
+</p>
+<p>
+Because it doesn't seem to add anything. It simply makes the behavior
+for p = 0 undefined. For programmers who don't create empty pointers
+with p = 0, there is no difference. Those who do insist on creating them
+presumably have a good reason, and it costs nothing for us to define the
+behavior in this case.
+</p>
+<p>
+The aliasing constructor is sharp enough as it is, so "protecting" users
+doesn't make much sense in this particular case.
+</p>
+<p>
+> Do you have a use case for r being empty and r being non-null?
+</p>
+<p>
+I have received a few requests for it from "performance-conscious"
+people (you should be familiar with this mindset) who don't like the
+overhead of allocating and maintaining a control block when a null
+deleter is used to approximate a raw pointer. It is obviously an "at
+your own risk", low-level feature; essentially a raw pointer behind a
+shared_ptr facade.
+</p>
+<p>
+We could not agree upon a resolution to the issue; some of us thought
+that Peter's description above is supporting an undesirable behavior.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In keeping the N2351 spirit and obviously my preference, change 20.7.12.2.5 [util.smartptr.shared.obs]:
+</p>
+
+<blockquote>
+<pre>T* get() const;
+</pre>
+<blockquote><p>
+<i>Returns:</i> the stored pointer. <del>Returns a null pointer if <tt>*this</tt> is empty.</del>
+</p></blockquote>
+</blockquote>
+
+<p>
+Alternative proposed resolution: (I won't be happy if we do this, but it's possible):
+</p>
+
+<p>
+Change 20.7.12.2.1 [util.smartptr.shared.const]:
+</p>
+
+<blockquote>
+<pre>template<class Y> shared_ptr(shared_ptr<Y> const& r, T *p);
+</pre>
+<blockquote>
+<p>
+<ins><i>Requires:</i> If <tt>r</tt> is empty, <tt>p</tt> shall be <tt>0</tt>.</ins>
+</p>
+<p>
+<del>[ <i>Note:</i> this constructor allows creation of an empty <tt>shared_ptr</tt>
+instance with a non-NULL stored pointer.
+-- <i>end note</i> ]</del>
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="713"></a>713. <tt>sort()</tt> complexity is too lax</h3>
+<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>
+ <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-30</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The complexity of <tt>sort()</tt> is specified as "Approximately <tt>N
+log(N)</tt> (where <tt>N == last - first</tt> ) comparisons on the
+average", with no worst case complicity specified. The intention was to
+allow a median-of-three quicksort implementation, which is usually <tt>O(N
+log N)</tt> but can be quadratic for pathological inputs. However, there is
+no longer any reason to allow implementers the freedom to have a
+worst-cast-quadratic sort algorithm. Implementers who want to use
+quicksort can use a variant like David Musser's "Introsort" (Software
+Practice and Experience 27:983-993, 1997), which is guaranteed to be <tt>O(N
+log N)</tt> in the worst case without incurring additional overhead in the
+average case. Most C++ library implementers already do this, and there
+is no reason not to guarantee it in the standard.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 25.3.1.1 [sort], change the complexity to "O(N log N)", and remove footnote 266:
+</p>
+
+<blockquote>
+<p>
+<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> )
+comparisons<del> on the average</del>.<del><sup>266)</sup></del>
+</p>
+<p>
+<del><sup>266)</sup>
+If the worst case behavior is important <tt>stable_sort()</tt> (25.3.1.2) or <tt>partial_sort()</tt>
+(25.3.1.3) should be used.</del>
+</p>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="714"></a>714. <tt>search_n</tt> complexity is too lax</h3>
+<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>
+ <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-30</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The complexity for <tt>search_n</tt> (25.1.12 [alg.search] par 7) is specified as "At most
+(last - first ) * count applications of the corresponding predicate if
+count is positive, or 0 otherwise." This is unnecessarily pessimistic.
+Regardless of the value of count, there is no reason to examine any
+element in the range more than once.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the complexity to "At most (last - first) applications of the corresponding predicate".
+</p>
+
+<blockquote>
+<pre>template<class ForwardIterator, class Size, class T>
+ ForwardIterator
+ search_n(ForwardIterator first , ForwardIterator last , Size count ,
+ const T& value );
+
+template<class ForwardIterator, class Size, class T,
+ class BinaryPredicate>
+ ForwardIterator
+ search_n(ForwardIterator first , ForwardIterator last , Size count ,
+ const T& value , BinaryPredicate pred );
+</pre>
+<blockquote>
+<p>
+<i>Complexity:</i> At most <tt>(last - first ) <del>* count</del></tt> applications of the corresponding predicate
+<del>if <tt>count</tt> is positive, or 0 otherwise</del>.
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="716"></a>716. Production in [re.grammar] not actually modified</h3>
+<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>
+ <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2007-08-31</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+TR1 7.13 [tr.re.grammar]/3 and C++0x WP 28.13 [re.grammar]/3 say:
+</p>
+
+<blockquote>
+<p>
+The following productions within the ECMAScript grammar are modified as follows:
+</p>
+
+<blockquote><pre>CharacterClass ::
+[ [lookahead ∉ {^}] ClassRanges ]
+[ ^ ClassRanges ]
+</pre></blockquote>
+
+</blockquote>
+
+<p>
+This definition for <tt>CharacterClass</tt> appears to be exactly identical to that in ECMA-262.
+</p>
+
+<p>
+Was an actual modification intended here and accidentally omitted, or was this production accidentally included?
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Remove this mention of the CharacterClass production.
+</p>
+
+<blockquote><pre><del>CharacterClass ::
+[ [lookahead ∉ {^}] ClassRanges ]
+[ ^ ClassRanges ]</del>
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="718"></a>718. <tt>basic_string</tt> is not a sequence</h3>
+<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>
+ <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-18</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+Paragraph 21.3 [basic.string]/3 states:
+</p>
+
+<blockquote>
+<p>
+The class template <tt>basic_string</tt> conforms to the requirements for a
+Sequence (23.1.1) and for a Reversible Container (23.1).
+</p>
+</blockquote>
+
+<p>
+First of all, 23.1.3 [sequence.reqmts] is no longer "Sequence" but "Sequence container".
+Secondly, after the resent changes to containers (<tt>emplace</tt>, <tt>push_back</tt>,
+<tt>const_iterator</tt> parameters to <tt>insert</tt> and <tt>erase</tt>), <tt>basic_string</tt> is not
+even close to conform to the current requirements.
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+<ul>
+<li>emplace, for example, may not make sense for strings. Is also likely suboptimal</li>
+<li>with concepts do we need to maintain string as sequence container?</li>
+<li>One approach might be to say something like: string is a sequence except it doesn't have these functions</li>
+</ul>
+<ul>
+<li>basic_string already has push_back</li>
+<li>const_iterator parameters to insert and erase should be added to basic_string</li>
+<li>this leaves emplace to handle -- we have the following options:
+<ul>
+<li>option 1: add it to string even though it's optional</li>
+<li>option 2: make emplace optional to sequences (move from table 89 to 90)</li>
+<li>option 3: say string not sequence (the proposal),</li>
+<li>option 4: add an exception to basic string wording.</li>
+</ul>
+</li>
+</ul>
+General consensus is to suggest option 2.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Remove this sentence, in recognition of the fact that <tt>basic_string</tt> is
+not just a <tt>vector</tt>-light for literal types, but something quite
+different, a string abstraction in its own right.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="719"></a>719. <tt>std::is_literal</tt> type traits should be provided</h3>
+<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>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-25</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+Since the inclusion of <tt>constexpr</tt> in the standard draft N2369 we have
+a new type category "literal", which is defined in 3.9 [basic.types]/p.11:
+</p>
+
+<blockquote>
+<p>
+-11- A type is a <i>literal</i> type if it is:
+</p>
+<ul>
+<li>a scalar type; or</li>
+<li><p>a class type (clause 9) with</p>
+<ul>
+<li>a trivial copy constructor,</li>
+<li>a trivial destructor,</li>
+<li>at least one constexpr constructor other than the copy constructor,</li>
+<li>no virtual base classes, and</li>
+<li>all non-static data members and base classes of literal types; or</li>
+</ul>
+</li>
+<li>an array of literal type.</li>
+</ul>
+</blockquote>
+
+<p>
+I strongly suggest that the standard provides a type traits for
+literal types in 20.5.4.3 [meta.unary.prop] for several reasons:
+</p>
+
+<ol type="a">
+<li>To keep the traits in sync with existing types.</li>
+<li>I see many reasons for programmers to use this trait in template
+ code to provide optimized template definitions for these types,
+ see below.</li>
+<li>A user-provided definition of this trait is practically impossible
+to write portably.</li>
+</ol>
+
+<p>
+The special problem of reason (c) is that I don't see currently a
+way to portably test the condition for literal class types:
+</p>
+
+<blockquote>
+<ul>
+<li>at least one constexpr constructor other than the copy constructor,</li>
+</ul>
+</blockquote>
+
+<p>
+Here follows a simply example to demonstrate it's usefulness:
+</p>
+
+<blockquote><pre>template <typename T>
+constexpr typename std::enable_if<std::is_literal<T>::value, T>::type
+abs(T x) {
+ return x < T() ? -x : x;
+}
+
+template <typename T>
+typename std::enable_if<!std::is_literal<T>::value, T>::type
+abs(const T& x) {
+ return x < T() ? -x : x;
+}
+</pre></blockquote>
+
+<p>
+Here we have the possibility to provide a general <tt>abs</tt> function
+template that can be used in ICE's if it's argument is a literal
+type which's value is a constant expression, otherwise we
+have an optimized version for arguments which are expensive
+to copy and therefore need the usage of arguments of
+reference type (instead of <tt>const T&</tt> we could decide to
+use <tt>T&&</tt>, but that is another issue).
+</p>
+
+<p><i>[
+Alisdair is considering preparing a paper listing a number of missing
+type traits, and feels that it might be useful to handle them all
+together rather than piecemeal. This would affect issue 719 and 750.
+These two issues should move to OPEN pending AM paper on type traits.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 20.5.2 [meta.type.synop] in the group "type properties",
+just below the line
+</p>
+
+<blockquote><pre>template <class T> struct is_pod;
+</pre></blockquote>
+
+<p>
+add a new one:
+</p>
+
+<blockquote><pre>template <class T> struct is_literal;
+</pre></blockquote>
+
+<p>
+In 20.5.4.3 [meta.unary.prop], table Type Property Predicates, just
+below the line for the <tt>is_pod</tt> property add a new line:
+</p>
+
+<table border="1">
+<tbody><tr>
+<th>Template</th><th>Condition</th><th>Preconditions</th>
+</tr>
+<tr>
+<td><tt>template <class T> struct is_literal;</tt></td>
+<td><tt>T</tt> is a literal type (3.9)</td>
+<td><tt>T</tt> shall be a complete type, an
+array of unknown bound, or
+(possibly cv-qualified) <tt>void</tt>.</td>
+</tr>
+</tbody></table>
+
+
+
+
+
+
+<hr>
+<h3><a name="720"></a>720. Omissions in constexpr usages</h3>
+<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>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-25</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<ol>
+<li>
+The member function <tt>bool array<T,N>::empty() const</tt> should be a
+<tt>constexpr</tt> because this is easily to proof and to implement following it's operational
+semantics defined by Table 87 (Container requirements) which says: <tt>a.size() == 0</tt>.
+</li>
+<li>
+The member function <tt>bool bitset<N>::test() const</tt> must be a
+<tt>constexpr</tt> (otherwise it would violate the specification of <tt>constexpr
+bitset<N>::operator[](size_t) const</tt>, because it's return clause delegates to <tt>test()</tt>).
+</li>
+<li>
+I wonder how the constructor <tt>bitset<N>::bitset(unsigned long)</tt> can
+be declared as a <tt>constexpr</tt>. Current implementations usually have no such <tt>bitset</tt>
+c'tor which would fulfill the requirements of a <tt>constexpr</tt> c'tor because they have a
+non-empty c'tor body that typically contains for-loops or <tt>memcpy</tt> to compute the
+initialisation. What have I overlooked here?
+</li>
+</ol>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+We handle this as two parts
+</p>
+<ol>
+<li>
+The proposed resolution is correct; move to ready.
+</li>
+<li>
+The issue points out a real problem, but the issue is larger than just
+this solution. We believe a paper is needed, applying the full new
+features of C++ (including extensible literals) to update <tt>std::bitset</tt>.
+We note that we do not consider this new work, and that is should be
+handled by the Library Working Group.
+</li>
+</ol>
+<p>
+In order to have a consistent working paper, Alisdair and Daniel produced a new wording for the resolution.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<ol>
+<li>
+<p>In the class template definition of 23.2.1 [array]/p. 3 change</p>
+<blockquote><pre><ins>constexpr</ins> bool empty() const;
+</pre></blockquote>
+</li>
+
+<li>
+<p>In the class template definition of 23.3.5 [template.bitset]/p. 1 change</p>
+<blockquote><pre><ins>constexpr</ins> bool test(size_t pos ) const;
+</pre></blockquote>
+
+<p>
+and in 23.3.5.2 [bitset.members] change
+</p>
+
+<blockquote><pre><ins>constexpr</ins> bool test(size_t pos ) const;
+</pre></blockquote>
+
+</li>
+</ol>
+
+
+
+
+
+<hr>
+<h3><a name="721"></a>721. <tt>wstring_convert</tt> inconsistensies</h3>
+<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>
+ <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-27</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+Paragraph 3 says that the <tt>Codecvt</tt> template parameter shall meet the
+requirements of <tt>std::codecvt</tt>, even though <tt>std::codecvt</tt> itself cannot
+be used (because of a protected destructor).
+</p>
+
+<p>
+How are we going to explain this code to beginning programmers?
+</p>
+
+<blockquote><pre>template<class I, class E, class S>
+struct codecvt : std::codecvt<I, E, S>
+{
+ ~codecvt()
+ { }
+};
+
+void main()
+{
+ std::wstring_convert<codecvt<wchar_t, char, std::mbstate_t> > compiles_ok;
+
+ std::wstring_convert<std::codecvt<wchar_t, char, std::mbstate_t> > not_ok;
+}
+</pre></blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="723"></a>723. <tt>basic_regex</tt> should be moveable</h3>
+<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>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-29</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+According to the current state of the standard draft, the class
+template <tt>basic_regex</tt>, as described in 28.8 [re.regex]/3, is
+neither <tt>MoveConstructible</tt> nor <tt>MoveAssignable</tt>.
+IMO it should be, because typical regex state machines tend
+to have a rather large data quantum and I have seen several
+use cases, where a factory function returns regex values,
+which would take advantage of moveabilities.
+</p>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+Needs wording for the semantics, the idea is agreed upon.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<ol type="a">
+<li>
+<p>
+In the header <tt><regex></tt> synopsis 28.4 [re.syn], just below the function
+template <tt>swap</tt> add two further overloads:
+</p>
+<blockquote><pre>template <class charT, class traits>
+ void swap(basic_regex<charT, traits>& e1, basic_regex<charT, traits>& e2);
+<ins>template <class charT, class traits>
+ void swap(basic_regex<charT, traits>&& e1, basic_regex<charT, traits>& e2);
+template <class charT, class traits>
+ void swap(basic_regex<charT, traits>& e1, basic_regex<charT, traits>&& e2);</ins>
+</pre></blockquote>
+<p>
+In the class definition of <tt>basic_regex</tt>, just below 28.8 [re.regex]/3,
+perform the following changes:
+</p>
+</li>
+
+<li>
+<p>Just after the copy c'tor:</p>
+<blockquote><pre>basic_regex(basic_regex&&);
+</pre></blockquote>
+</li>
+
+<li>
+<p>Just after the copy-assignment op.:</p>
+<blockquote><pre>basic_regex& operator=(basic_regex&&);
+</pre></blockquote>
+</li>
+
+<li>
+<p>Just after the first <tt>assign</tt> overload insert:</p>
+<blockquote><pre>basic_regex& assign(basic_regex&& that);
+</pre></blockquote>
+</li>
+
+<li>
+<p>Change the current <tt>swap</tt> function to read:</p>
+<blockquote><pre>void swap(basic_regex&&);
+</pre></blockquote>
+</li>
+
+<li>
+<p>In 28.8.2 [re.regex.construct], just below the copy c'tor add a
+corresponding member definition of:</p>
+<blockquote><pre>basic_regex(basic_regex&&);
+</pre></blockquote>
+</li>
+
+<li>
+<p>Also in 28.8.2 [re.regex.construct], just below the copy assignment
+c'tor add a corresponding member definition of:</p>
+<blockquote><pre>basic_regex& operator=(basic_regex&&);
+</pre></blockquote>
+</li>
+
+<li>
+<p>In 28.8.3 [re.regex.assign], just below the first <tt>assign</tt> overload add
+a corresponding member definition of:</p>
+<blockquote><pre>basic_regex& assign(basic_regex&& that);
+</pre></blockquote>
+</li>
+
+<li>
+<p>In 28.8.6 [re.regex.swap], change the signature of <tt>swap</tt> to
+say:</p>
+<blockquote><pre>void swap(basic_regex&& e);
+</pre></blockquote>
+</li>
+
+<li>
+<p>In 28.8.7.1 [re.regex.nmswap], just below the single binary <tt>swap</tt>
+function, add the two missing overloads:</p>
+<blockquote><pre>template <class charT, class traits>
+ void swap(basic_regex<charT, traits>&& e1, basic_regex<charT, traits>& e2);
+template <class charT, class traits>
+ void swap(basic_regex<charT, traits>& e1, basic_regex<charT, traits>&& e2);
+</pre></blockquote>
+</li>
+</ol>
+
+<p>
+Of course there would be need of corresponding proper standardese
+to describe these additions.
+</p>
+
+
+
+
+
+
+<hr>
+<h3><a name="724"></a>724. <tt>DefaultConstructible</tt> is not defined</h3>
+<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>
+ <b>Submitter:</b> Pablo Halpern <b>Date:</b> 2007-09-12</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The <tt>DefaultConstructible</tt> requirement is referenced in
+several places in the August 2007 working draft
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2369.pdf">N2369</a>,
+but is not defined anywhere.
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+Walking into the default/value-initialization mess...
+</p>
+<p>
+Why two lines? Because we need both expressions to be valid.
+</p>
+<p>
+AJM not sure what the phrase "default constructed" means. This is
+unfortunate, as the phrase is already used 24 times in the library!
+</p>
+<p>
+Example: const int would not accept first line, but will accept the second.
+</p>
+<p>
+This is an issue that must be solved by concepts, but we might need to solve it independantly first.
+</p>
+<p>
+It seems that the requirements are the syntax in the proposed first
+column is valid, but not clear what semantics we need.
+</p>
+<p>
+A table where there is no post-condition seems odd, but appears to sum up our position best.
+</p>
+<p>
+At a minimum an object is declared and is destuctible.
+</p>
+<p>
+Move to open, as no-one happy to produce wording on the fly.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In section 20.1.1 [utility.arg.requirements], before table 33, add the
+following table:
+</p>
+
+<p style="text-align: center;" align="center">Table 33: <tt>DefaultConstructible</tt> requirements</p>
+
+<div align="center">
+
+<table style="border-collapse: collapse;" border="0" cellpadding="0" cellspacing="0">
+ <tbody><tr>
+ <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">
+ <p style="margin: 0in 0in 0.0001pt; text-align: center;" align="center">expression</p>
+ </td>
+ <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">
+ <p style="margin: 0in 0in 0.0001pt; text-align: center;" align="center">post-condition</p>
+ </td>
+ </tr>
+ <tr>
+ <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">
+ <p style="margin: 0in 0in 0.0001pt;"><tt>T
+ t;</tt><br>
+ <tt>T()</tt></p>
+ </td>
+ <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">
+ <p style="margin: 0in 0in 0.0001pt;"><tt>T</tt>
+ is <i>default constructed.</i></p>
+ </td>
+ </tr>
+</tbody></table>
+
+</div>
+
+
+
+
+
+
+<hr>
+<h3><a name="726"></a>726. Missing <tt>regex_replace()</tt> overloads</h3>
+<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>
+ <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2007-09-22</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+Two overloads of <tt>regex_replace()</tt> are currently provided:
+</p>
+
+<blockquote><pre>template <class OutputIterator, class BidirectionalIterator,
+ class traits, class charT>
+ OutputIterator
+ regex_replace(OutputIterator out,
+ BidirectionalIterator first, BidirectionalIterator last,
+ const basic_regex<charT, traits>& e,
+ const basic_string<charT>& fmt,
+ regex_constants::match_flag_type flags =
+ regex_constants::match_default);
+
+template <class traits, class charT>
+ basic_string<charT>
+ regex_replace(const basic_string<charT>& s,
+ const basic_regex<charT, traits>& e,
+ const basic_string<charT>& fmt,
+ regex_constants::match_flag_type flags =
+ regex_constants::match_default);
+</pre></blockquote>
+
+<ol>
+<li>Overloads taking <tt>const charT *</tt> are provided for <tt>regex_match()</tt> and
+<tt>regex_search()</tt>, but not <tt>regex_replace()</tt>. This is inconsistent.</li>
+<li>
+<p>The absence of <tt>const charT *</tt> overloads prevents ordinary-looking code from compiling, such as:</p>
+
+<blockquote><pre>const string s("kitten");
+const regex r("en");
+cout << regex_replace(s, r, "y") << endl;
+</pre></blockquote>
+
+<p>
+The compiler error message will be something like "could not deduce
+template argument for 'const std::basic_string<_Elem> &' from 'const
+char[1]'".
+</p>
+
+<p>
+Users expect that anything taking a <tt>basic_string<charT></tt> can also take a
+<tt>const charT *</tt>. In their own code, when they write a function taking
+<tt>std::string</tt> (or <tt>std::wstring</tt>), they can pass a <tt>const char *</tt> (or <tt>const
+wchar_t *</tt>), thanks to <tt>basic_string</tt>'s implicit constructor. Because the
+regex algorithms are templated on <tt>charT</tt>, they can't rely on
+<tt>basic_string</tt>'s implicit constructor (as the compiler error message
+indicates, template argument deduction fails first).
+</p>
+
+<p>
+If a user figures out what the compiler error message means, workarounds
+are available - but they are all verbose. Explicit template arguments
+could be given to <tt>regex_replace()</tt>, allowing <tt>basic_string</tt>'s implicit
+constructor to be invoked - but <tt>charT</tt> is the last template argument, not
+the first, so this would be extremely verbose. Therefore, constructing
+a <tt>basic_string</tt> from each C string is the simplest workaround.
+</p>
+</li>
+
+<li>
+There is an efficiency consideration: constructing <tt>basic_string</tt>s can
+impose performance costs that could be avoided by a library
+implementation taking C strings and dealing with them directly.
+(Currently, for replacement sources, C strings can be converted into
+iterator pairs at the cost of verbosity, but for format strings, there
+is no way to avoid constructing a <tt>basic_string</tt>.)
+</li>
+</ol>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+We note that Boost already has these overloads. However, the proposed
+wording is provided only for 28.11.4 [re.alg.replace]; wording is needed for the synopsis
+as well. We also note that this has impact on <tt>match_results::format</tt>,
+which may require further overloads.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Provide additional overloads for <tt>regex_replace()</tt>: one additional
+overload of the iterator-based form (taking <tt>const charT* fmt</tt>), and three
+additional overloads of the convenience form (one taking <tt>const charT*
+str</tt>, another taking <tt>const charT* fmt</tt>, and the third taking both <tt>const
+charT* str</tt> and <tt>const charT* fmt</tt>). 28.11.4 [re.alg.replace]:
+</p>
+
+<blockquote>
+<pre>template <class OutputIterator, class BidirectionalIterator,
+ class traits, class charT>
+ OutputIterator
+ regex_replace(OutputIterator out,
+ BidirectionalIterator first, BidirectionalIterator last,
+ const basic_regex<charT, traits>& e,
+ const basic_string<charT>& fmt,
+ regex_constants::match_flag_type flags =
+ regex_constants::match_default);
+
+<ins>template <class OutputIterator, class BidirectionalIterator,
+ class traits, class charT>
+ OutputIterator
+ regex_replace(OutputIterator out,
+ BidirectionalIterator first, BidirectionalIterator last,
+ const basic_regex<charT, traits>& e,
+ const charT* fmt,
+ regex_constants::match_flag_type flags =
+ regex_constants::match_default);</ins>
+</pre>
+<p>...</p>
+<pre>template <class traits, class charT>
+ basic_string<charT>
+ regex_replace(const basic_string<charT>& s,
+ const basic_regex<charT, traits>& e,
+ const basic_string<charT>& fmt,
+ regex_constants::match_flag_type flags =
+ regex_constants::match_default);
+
+<ins>template <class traits, class charT>
+ basic_string<charT>
+ regex_replace(const basic_string<charT>& s,
+ const basic_regex<charT, traits>& e,
+ const charT* fmt,
+ regex_constants::match_flag_type flags =
+ regex_constants::match_default);</ins>
+
+<ins>template <class traits, class charT>
+ basic_string<charT>
+ regex_replace(const charT* s,
+ const basic_regex<charT, traits>& e,
+ const basic_string<charT>& fmt,
+ regex_constants::match_flag_type flags =
+ regex_constants::match_default);</ins>
+
+<ins>template <class traits, class charT>
+ basic_string<charT>
+ regex_replace(const charT* s,
+ const basic_regex<charT, traits>& e,
+ const charT* fmt,
+ regex_constants::match_flag_type flags =
+ regex_constants::match_default);</ins>
+</pre>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="727"></a>727. <tt>regex_replace()</tt> doesn't accept <tt>basic_string</tt>s with custom traits and allocators</h3>
+<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>
+ <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2007-09-22</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+<tt>regex_match()</tt> and <tt>regex_search()</tt> take <tt>const basic_string<charT, ST,
+SA>&</tt>. <tt>regex_replace()</tt> takes <tt>const basic_string<charT>&</tt>. This prevents
+<tt>regex_replace()</tt> from accepting <tt>basic_string</tt>s with custom traits and
+allocators.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Overloads of <tt>regex_replace()</tt> taking <tt>basic_string</tt> should be additionally
+templated on <tt>class ST, class SA</tt> and take <tt>const basic_string<charT, ST,
+SA>&</tt>. Consistency with <tt>regex_match()</tt> and <tt>regex_search()</tt> would place
+<tt>class ST, class SA</tt> as the first template arguments; compatibility with
+existing code using TR1 and giving explicit template arguments to
+<tt>regex_replace()</tt> would place <tt>class ST, class SA</tt> as the last template
+arguments.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="728"></a>728. Problem in [rand.eng.mers]/6</h3>
+<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>
+ <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The <tt>mersenne_twister_engine</tt> is required to use a seeding method that is given
+as an algorithm parameterized over the number of bits <tt>W</tt>. I doubt whether the given generalization
+of an algorithm that was originally developed only for unsigned 32-bit integers is appropriate
+for other bit widths. For instance, <tt>W</tt> could be theoretically 16 and <tt>UIntType</tt> a 16-bit integer, in
+which case the given multiplier would not fit into the <tt>UIntType</tt>. Moreover, T. Nishimura and M.
+Matsumoto have chosen a dif ferent multiplier for their 64 bit Mersenne Twister
+[<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/VERSIONS/C-LANG/mt19937-64.c">reference</a>].
+</p>
+
+<p>
+I see two possible resolutions:
+</p>
+
+<ol type="a">
+<li>Restrict the parameter <tt>W</tt> of the <tt>mersenne_twister_template</tt> to values of 32 or 64 and use the
+multiplier from [the above reference] for the 64-bit case (my preference)</li>
+<li>Interpret the state array for any <tt>W</tt> as a 32-bit array of appropriate length (and a specified byte
+order) and always employ the 32-bit algorithm for seeding
+</li>
+</ol>
+
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+for further discussion.
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+Stephan Tolksdorf has additional comments on N2424. He comments: "there
+is a typo in the required behaviour for mt19937_64: It should be the
+10000th (not 100000th) invocation whose value is given, and the value
+should be 9981545732273789042 (not 14002232017267485025)." These values
+need checking.
+</p>
+<p>
+Take the proposed recommendation in N2424 and move to REVIEW.
+</p>
+</blockquote>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+for the proposed resolution.
+</p>
+
+<p><i>[
+Stephan Tolksdorf adds pre-Bellevue:
+]</i></p>
+
+
+<blockquote>
+I support the proposed resolution in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>,
+but there is a typo in the
+required behaviour for <tt>mt19937_64</tt>: It should be the 10000<sup>th</sup> (not
+100000<sup>th</sup>) invocation whose value is given, and the value should be
+9981545732273789042 (not 14002232017267485025). The change to para. 8
+proposed by Charles Karney should also be included in the proposed
+wording.
+</blockquote>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+Note the main part of the issue is resolved by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>.
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="732"></a>732. Defect in [rand.dist.samp.genpdf]</h3>
+<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>
+ <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
+<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>
+<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>
+<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a></p>
+<p><b>Discussion:</b></p>
+<p>
+26.4.8.5.3 [rand.dist.samp.genpdf] describes the interface for a distribution template that is
+meant to simulate random numbers from any general distribution given only the density and the
+support of the distribution. I'm not aware of any general purpose algorithm that would be capable
+of correctly and efficiently implementing the described functionality. From what I know, this is
+essentially an unsolved research problem. Existing algorithms either require more knowledge
+about the distribution and the problem domain or work only under very limited circumstances.
+Even the state of the art special purpose library UNU.RAN does not solve the problem in full
+generality, and in any case, testing and customer support for such a library feature would be a
+nightmare.
+</p>
+
+<p>
+<b>Possible resolution:</b> For these reasons, I propose to delete section 26.4.8.5.3 [rand.dist.samp.genpdf].
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+Disagreement persists.
+</p>
+<p>
+Objection to this issue is that this function takes a general functor.
+The general approach would be to normalize this function, integrate it,
+and take the inverse of the integral, which is not possible in general.
+An example function is sin(1+n*x) -- for any spatial frequency that the
+implementor chooses, there is a value of n that renders that choice
+arbitrarily erroneous.
+</p>
+<p>
+Correction: The formula above should instead read 1+sin(n*x).
+</p>
+<p>
+Objector proposes the following possible compromise positions:
+</p>
+<ul>
+<li>
+rand.dist.samp.genpdf takes an number of points so that implementor need not guess.
+</li>
+<li>replace rand.disk.samp.genpdf with an extension to either or both
+of the discrete functions to take arguments that take a functor and
+number of points in place of the list of probabilities. Reference
+issues 793 and 794.
+</li>
+</ul>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+for the proposed resolution.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="734"></a>734. Unnecessary restriction in [rand.dist.norm.chisq]</h3>
+<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>
+ <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+<tt>chi_squared_distribution</tt>, <tt>fisher_f_distribution</tt> and <tt>student_t_distribution</tt>
+have parameters for the "degrees of freedom" <tt>n</tt> and <tt>m</tt> that are specified as integers. For the
+following two reasons this is an unnecessary restriction: First, in many applications such as
+Bayesian inference or Monte Carlo simulations it is more convenient to treat the respective param-
+eters as continuous variables. Second, the standard non-naive algorithms (i.e.
+O(1) algorithms)
+for simulating from these distributions work with floating-point parameters anyway (all three
+distributions could be easily implemented using the Gamma distribution, for instance).
+</p>
+
+<p>
+Similar arguments could in principle be made for the parameters <tt>t</tt> and <tt>k</tt> of the discrete
+<tt>binomial_distribution</tt> and <tt>negative_binomial_distribution</tt>, though in both cases continuous
+parameters are less frequently used in practice and in case of the <tt>binomial_distribution</tt>
+the implementation would be significantly complicated by a non-discrete parameter (in most
+implementations one would need an approximation of the log-gamma function instead of just the
+log-factorial function).
+</p>
+
+<p>
+<b>Possible resolution:</b> For these reasons, I propose to change the type of the respective parameters
+to double.
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+In N2424. Not wildly enthusiastic, not really felt necessary. Less
+frequently used in practice. Not terribly bad either. Move to OPEN.
+</blockquote>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+Marc Paterno: The generalizations were explicitly left out when designing the facility. It's harder to test.
+</p>
+<p>
+Marc Paterno: Ask implementers whether floating-point is a significant burden.
+</p>
+<p>
+Alisdair: It's neater to do it now, do ask Bill Plauger.
+</p>
+<p>
+Disposition: move to review with the option for "NAD" if it's not straightforward to implement; unanimous consent.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
+for the proposed resolution.
+</p>
+
+<p><i>[
+Stephan Tolksdorf adds pre-Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+In 26.4.8.4.3 [rand.dist.norm.chisq]:
+</p>
+
+<blockquote>
+<p>
+Delete ", where <tt>n</tt> is a positive integer" in the first paragraph.
+</p>
+
+<p>
+Replace both occurrences of "<tt>explicit chi_squared_distribution(int n = 1);</tt>"
+with "<tt>explicit chi_squared_distribution(RealType n = 1);</tt>".
+</p>
+
+<p>
+Replace both occurrences of "<tt>int n() const;</tt>" with "<tt>RealType n() const;</tt>".
+</p>
+
+</blockquote>
+
+<p>
+In 26.4.8.4.5 [rand.dist.norm.f]:
+</p>
+<blockquote>
+<p>
+Delete ", where <tt>m</tt> and <tt>n</tt> are positive integers" in the first paragraph.
+</p>
+
+<p>
+Replace both occurrences of
+</p>
+<blockquote><pre>explicit fisher_f_distribution(int m = 1, int n = 1);
+</pre></blockquote>
+<p>
+with
+</p>
+<blockquote><pre>explicit fisher_f_distribution(RealType m = 1, RealType n = 1);
+</pre></blockquote>
+
+<p>
+Replace both occurrences of "<tt>int m() const;" with "RealType m() const;</tt>".
+</p>
+
+<p>
+Replace both occurrences of "<tt>int n() const;" with "RealType n() const;</tt>".
+</p>
+</blockquote>
+
+<p>
+In 26.4.8.4.6 [rand.dist.norm.t]:
+</p>
+
+<blockquote>
+<p>
+Delete ", where <tt>n</tt> is a positive integer" in the first paragraph.
+</p>
+
+<p>
+Replace both occurrences of "<tt>explicit student_t_distribution(int n = 1);</tt>"
+with "<tt>explicit student_t_distribution(RealType n = 1);</tt>".
+</p>
+
+<p>
+Replace both occurrences of "<tt>int n() const;</tt>" with "<tt>RealType n() const;</tt>".
+</p>
+</blockquote>
+
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="742"></a>742. Enabling <tt>swap</tt> for proxy iterators</h3>
+<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>
+ <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-10-10</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+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
+deals with changing the requirements of <tt>T</tt> in the <tt>Swappable</tt>
+requirement from <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt> to
+<tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.
+</p>
+
+<p>
+This issue seeks to widen the <tt>Swappable</tt> requirement to support proxy iterators. Here
+is example code:
+</p>
+
+<blockquote><pre>namespace Mine {
+
+template <class T>
+struct proxy {...};
+
+template <class T>
+struct proxied_iterator
+{
+ typedef T value_type;
+ typedef proxy<T> reference;
+ reference operator*() const;
+ ...
+};
+
+struct A
+{
+ // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
+ void swap(A&);
+ ...
+};
+
+void swap(A&, A&);
+void swap(proxy<A>, A&);
+void swap(A&, proxy<A>);
+void swap(proxy<A>, proxy<A>);
+
+} // Mine
+
+...
+
+Mine::proxied_iterator<Mine::A> i(...)
+Mine::A a;
+<b>swap(*i1, a);</b>
+</pre></blockquote>
+
+<p>
+The key point to note in the above code is that in the call to <tt>swap</tt>, <tt>*i1</tt>
+and <tt>a</tt> are different types (currently types can only be <tt>Swappable</tt> with the
+same type). A secondary point is that to support proxies, one must be able to pass rvalues
+to <tt>swap</tt>. But note that I am not stating that the general purpose <tt>std::swap</tt>
+should accept rvalues! Only that overloaded <tt>swap</tt>s, as in the example above, be allowed
+to take rvalues.
+</p>
+
+<p>
+That is, no standard library code needs to change. We simply need to have a more flexible
+definition of <tt>Swappable</tt>.
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+While we believe Concepts work will define a swappable concept, we
+should still resolve this issue if possible to give guidance to the
+Concepts work.
+</p>
+<p>
+Would an ambiguous swap function in two namespaces found by ADL break
+this wording? Suggest that the phrase "valid expression" means such a
+pair of types would still not be swappable.
+</p>
+<p>
+Motivation is proxy-iterators, but facility is considerably more
+general. Are we happy going so far?
+</p>
+<p>
+We think this wording is probably correct and probably an improvement on
+what's there in the WP. On the other hand, what's already there in the
+WP is awfully complicated. Why do we need the two bullet points? They're
+too implementation-centric. They don't add anything to the semantics of
+what swap() means, which is there in the post-condition. What's wrong
+with saying that types are swappable if you can call swap() and it
+satisfies the semantics of swapping?
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.1.1 [utility.arg.requirements]:
+</p>
+
+<blockquote>
+
+<p>
+-1- The template definitions in the C++ Standard Library refer to various
+named requirements whose details are set out in tables 31-38. In these
+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
+instantiating a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
+values of type <tt>const T</tt>; <tt>s</tt> and <tt>t</tt> are modifiable
+lvalues of type <tt>T</tt>; <tt>u</tt> is a value of type (possibly
+<tt>const</tt>) <tt>T</tt>; <del>and</del> <tt>rv</tt> is a non-<tt>const</tt>
+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>.
+</p>
+
+<table border="1">
+<caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
+<tbody><tr><th>expression</th><th>return type</th><th>post-condition</th></tr>
+<tr><td><tt>swap(<del>s</del><ins>w</ins>,<del>t</del><ins>v</ins>)</tt></td><td><tt>void</tt></td>
+<td><del><tt>t</tt></del><ins><tt>w</tt></ins> has the value originally
+held by <del><tt>u</tt></del><ins><tt>v</tt></ins>, and
+<del><tt>u</tt></del><ins><tt>v</tt></ins> has the value originally held
+by <del><tt>t</tt></del><ins><tt>w</tt></ins></td></tr>
+<tr><td colspan="3">
+<p>
+The <tt>Swappable</tt> requirement is met by satisfying one or more of the following conditions:
+</p>
+<ul>
+<li>
+<tt>T</tt> is <tt>Swappable</tt> if <ins><tt>T</tt> and <tt>V</tt> are
+the same type and </ins> <tt>T</tt> satisfies the
+<del><tt>CopyConstructible</tt></del>
+<ins><tt>MoveConstructible</tt></ins> requirements (Table <del>34</del>
+<ins>33</ins>) and the <del><tt>CopyAssignable</tt></del>
+<ins><tt>MoveAssignable</tt></ins> requirements (Table <del>36</del>
+<ins>35</ins>);
+</li>
+<li>
+<tt>T</tt> is <tt>Swappable</tt> <ins>with <tt>V</tt></ins> if a namespace scope function named
+<tt>swap</tt> exists in the same namespace as the definition of
+<tt>T</tt> <ins>or <tt>V</tt></ins>, such that the expression
+<tt>swap(<del>t</del><ins>w</ins>,<del>u</del> <ins>v</ins>)</tt> is valid and has the
+semantics described in this table.
+</li>
+</ul>
+</td></tr>
+</tbody></table>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="747"></a>747. We have 3 separate type traits to identify classes supporting no-throw operations</h3>
+<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>
+ <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+We have 3 separate type traits to identify classes supporting no-throw
+operations, which are very useful when trying to provide exception safety
+guarantees. However, I'm not entirely clear on what the current wording
+requires of a conforming implementation. To quote from
+<tt>has_nothrow_default_constructor</tt>:
+</p>
+<blockquote><p>
+or <tt>T</tt> is a class type with a default constructor that is known not to throw
+any exceptions
+</p></blockquote>
+<p>
+What level of magic do we expect to deduce if this is known?
+</p>
+<p>
+E.g.
+</p>
+
+<blockquote><pre>struct test{
+ int x;
+ test() : x() {}
+};
+</pre></blockquote>
+<p>
+Should I expect a conforming compiler to
+ <tt>assert( has_nothrow_constructor<test>::value )</tt>
+</p>
+<p>
+Is this a QoI issue?
+</p>
+<p>
+Should I expect to 'know' only if-and-only-if there is an inline definition
+available?
+</p>
+<p>
+Should I never expect that to be true, and insist that the user supplies an
+empty throw spec if they want to assert the no-throw guarantee?
+</p>
+<p>
+It would be helpful to maybe have a footnote explaining what is required,
+but right now I don't know what to suggest putting in the footnote.
+</p>
+<p>
+(agreement since is that trivial ops and explicit no-throws are required.
+Open if QoI should be allowed to detect further)
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+This looks like a QoI issue.
+In the case of trivial and nothrow it is known. Static analysis of the program is definitely into QoI.
+Move to OPEN. Need to talk to Core about this.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="750"></a>750. The current definition for <tt>is_convertible</tt> requires that the type be
+implicitly convertible, so explicit constructors are ignored.</h3>
+<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>
+ <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+With the pending arrival of explicit conversion functions though, I'm
+wondering if we want an additional trait, <tt>is_explictly_convertible</tt>?
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Alisdair is considering preparing a paper listing a number of missing
+type traits, and feels that it might be useful to handle them all
+together rather than piecemeal. This would affect issue 719 and 750.
+These two issues should move to OPEN pending AM paper on type traits.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="751"></a>751. change pass-by-reference members of <tt>vector<bool></tt> to pass-by-value?</h3>
+<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>
+ <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+A number of vector<bool> members take const bool& as arguments.
+Is there any chance we could change them to pass-by-value or would I
+be wasting everyone's time if wrote up an issue?
+</p>
+
+<p><i>[
+post Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+As we understand it, the original requester (Martin Sebor) would like
+for implementations to be permitted to pass-by-value. Alisdair suggests
+that if this is to be resolved, it should be resolved more generally,
+e.g. in other containers as well.
+</p>
+<p>
+We note that this would break ABI. However, we also suspect that this
+might be covered under the "as-if" rule in section 1.9.
+</p>
+<p>
+Many in the group feel that for vector<bool>, this is a "don't care",
+and that at this point in the process it's not worth the bandwidth.
+</p>
+<p>
+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
+now in the working paper -- is related to this, though not a duplicate.
+</p>
+<p>
+Moving to Open with a task for Alisdair to craft a informative note to
+be put whereever appropriate in the WP. This note would clarify places
+where pass-by-const-ref can be transformed to pass-by-value under the
+as-if rule.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="752"></a>752. Allocator complexity requirement</h3>
+<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>
+ <b>Submitter:</b> Hans Boehm <b>Date:</b> 2007-10-11</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+Did LWG recently discuss 20.1.2 [allocator.requirements]-2, which states that "All the operations
+on the allocators are expected to be amortized constant time."?
+</p>
+<p>
+As I think I pointed out earlier, this is currently fiction for
+<tt>allocate()</tt> if it has to obtain memory from the OS, and it's unclear to
+me how to interpret this for <tt>construct()</tt> and <tt>destroy()</tt> if they deal with
+large objects. Would it be controversial to officially let these take
+time linear in the size of the object, as they already do in real life?
+</p>
+<p>
+<tt>Allocate()</tt> more blatantly takes time proportional to the size of the
+object if you mix in GC. But it's not really a new problem, and I think
+we'd be confusing things by leaving the bogus requirements there. The
+current requirement on <tt>allocate()</tt> is generally not important anyway,
+since it takes O(size) to construct objects in the resulting space.
+There are real performance issues here, but they're all concerned with
+the constants, not the asymptotic complexity.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.1.2 [allocator.requirements]/2:
+</p>
+
+<blockquote>
+<p>
+-2- Table 39 describes the requirements on types manipulated through
+allocators. <del>All the operations on the allocators are expected to be
+amortized constant time.</del> Table 40 describes the
+requirements on allocator types.
+</p>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="753"></a>753. Move constructor in draft</h3>
+<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>
+ <b>Submitter:</b> Yechezkel Mett <b>Date:</b> 2007-10-14</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The draft standard n2369 uses the term <i>move constructor</i> in a few
+places, but doesn't seem to define it.
+</p>
+
+<p>
+<tt>MoveConstructible</tt> requirements are defined in Table 33 in 20.1.1 [utility.arg.requirements] as
+follows:
+</p>
+
+<blockquote>
+<table border="1">
+<caption><tt>MoveConstructible</tt> requirements</caption>
+<tbody><tr>
+<th>expression</th> <th>post-condition</th>
+</tr>
+<tr>
+<td><tt>T t = rv</tt></td> <td><tt>t</tt> is equivalent to the value of <tt>rv</tt> before the construction</td>
+</tr>
+<tr>
+<td colspan="2">[<i>Note:</i> There is no requirement on the value of <tt>rv</tt> after the
+construction. <i>-- end note</i>]</td>
+</tr>
+</tbody></table>
+</blockquote>
+
+<p>
+(where <tt>rv</tt> is a non-const rvalue of type <tt>T</tt>).
+</p>
+
+<p>
+So I assume the move constructor is the constructor that would be used
+in filling the above requirement.
+</p>
+
+<p>
+For <tt>vector::reserve</tt>, <tt>vector::resize</tt> and the <tt>vector</tt> modifiers given in
+23.2.6.4 [vector.modifiers] we have
+</p>
+
+<blockquote>
+<i>Requires:</i> If <tt>value_type</tt> has a move constructor, that constructor shall
+not throw any exceptions.
+</blockquote>
+
+<p>
+Firstly "If <tt>value_type</tt> has a move constructor" is superfluous; every
+type which can be put into a <tt>vector</tt> has a move constructor (a copy
+constructor is also a move constructor). Secondly it means that for
+any <tt>value_type</tt> which has a throwing copy constructor and no other move
+constructor these functions cannot be used -- which I think will come
+as a shock to people who have been using such types in <tt>vector</tt> until
+now!
+</p>
+
+<p>
+I can see two ways to correct this. The simpler, which is presumably
+what was intended, is to say "If <tt>value_type</tt> has a move constructor and
+no copy constructor, the move constructor shall not throw any
+exceptions" or "If <tt>value_type</tt> has a move constructor which changes the
+value of its parameter,".
+</p>
+
+<p>
+The other alternative is add to <tt>MoveConstructible</tt> the requirement that
+the expression does not throw. This would mean that not every type
+that satisfies the <tt>CopyConstructible</tt> requirements also satisfies the
+<tt>MoveConstructible</tt> requirements. It would mean changing requirements in
+various places in the draft to allow either <tt>MoveConstructible</tt> or
+<tt>CopyConstructible</tt>, but I think the result would be clearer and
+possibly more concise too.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add new defintions to 17.1 [definitions]:
+</p>
+
+<blockquote>
+<p>
+<b>move constructor</b>
+</p>
+<p>
+a constructor which accepts only rvalue arguments of that type, and modifies the rvalue as a
+side effect during the construction.
+</p>
+<p>
+<b>move assignment operator</b>
+</p>
+<p>
+an assignment operator which accepts only rvalue arguments of that type, and modifies the rvalue as a
+side effect during the assignment.
+</p>
+<p>
+<b>move assignment</b>
+</p>
+<p>
+use of the move assignment operator.
+</p>
+</blockquote>
+
+<p><i>[
+Howard adds post-Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+Unfortunately I believe the wording recommended by the LWG in Bellevue is incorrect. <tt>reserve</tt> et. al. will use a move constructor
+if one is available, else it will use a copy constructor. A type may have both. If the move constructor is
+used, it must not throw. If the copy constructor is used, it can throw. The sentence in the proposed wording
+is correct without the recommended insertion. The Bellevue LWG recommended moving this issue to Ready. I am
+unfortunately pulling it back to Open. But I'm drafting wording to atone for this egregious action. :-)
+</p>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="758"></a>758. <tt>shared_ptr</tt> and <tt>nullptr</tt></h3>
+<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>
+ <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-10-31</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+Consider the following program:
+</p>
+
+<blockquote><pre>int main() {
+ shared_ptr<int> p(nullptr);
+ return 0;
+}
+</pre></blockquote>
+
+<p>
+This program will fail to compile because <tt>shared_ptr</tt> uses the following
+template constructor to construct itself from pointers:
+</p>
+
+<blockquote><pre>template <class Y> shared_ptr(Y *);
+</pre></blockquote>
+
+<p>
+According
+to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf">N2431</a>,
+the conversion from <tt>nullptr_t</tt> to <tt>Y *</tt> is not
+deducible, so the above constructor will not be found. There are similar problems with the
+constructors that take a pointer and a <tt>deleter</tt> or a
+pointer, a <tt>deleter</tt> and an allocator, as well as the
+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>
+will solve this problem for constructing from just <tt>nullptr</tt>, but not for constructors that use
+<tt>deleters</tt> or allocators or for <tt>reset()</tt>.
+</p>
+
+<p>
+In the case of the functions that take deleters, there is the additional
+question of what argument should be passed to the deleter when it is
+eventually called. There are two reasonable possibilities: <tt>nullptr</tt> or
+<tt>static_cast<T *>(0)</tt>, where <tt>T</tt> is the template argument of the
+<tt>shared_ptr</tt>. It is not immediately clear which of these is better. If
+<tt>D::operator()</tt> is a template function similar to <tt>shared_ptr</tt>'s
+constructor, then <tt>d(static_cast<T*>(0))</tt> will compile and <tt>d(nullptr)</tt>
+will not. On the other hand, if <tt>D::operator()()</tt> takes a parameter that
+is a pointer to some type other that <tt>T</tt> (for instance <tt>U*</tt> where <tt>U</tt> derives
+from <tt>T</tt>) then <tt>d(nullptr)</tt> will compile and <tt>d(static_cast<T *>(0))</tt> may not.
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+The general idea is right, we need to be able to pass a nullptr to a
+shared_ptr, but there are a few borderline editorial issues here. (For
+example, the single-argument nullptr_t constructor in the class synopsis
+isn't marked explicit, but it is marked explicit in the proposed wording
+for 20.6.6.2.1. There is a missing empty parenthesis in the form that
+takes a nullptr_t, a deleter, and an allocator.)
+</p>
+<p>
+More seriously: this issue says that a shared_ptr constructed from a
+nullptr is empty. Since "empty" is undefined, it's hard to know whether
+that's right. This issue is pending on handling that term better.
+</p>
+<p>
+Peter suggests definition of empty should be "does not own anything"
+</p>
+<p>
+Is there an editorial issue that post-conditions should refer to get() =
+nullptr, rather than get() = 0?
+</p>
+<p>
+No strong feeling towards accept or NAD, but prefer to make a decision than leave it open.
+</p>
+<p>
+Seems there are no technical merits between NAD and Ready, comes down to
+"Do we intentially want to allow/disallow null pointers with these
+functions". Staw Poll - support null pointers 5 - No null pointers 0
+</p>
+<p>
+Move to Ready, modulo editorial comments
+</p>
+</blockquote>
+
+<p><i>[
+post Bellevue Peter adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+The following wording changes are less intrusive:
+</p>
+
+<p>
+In 20.7.12.2.1 [util.smartptr.shared.const], add:
+</p>
+
+<blockquote><pre>shared_ptr(nullptr_t);
+</pre></blockquote>
+
+<p>
+after:
+</p>
+
+<blockquote><pre>shared_ptr();
+</pre></blockquote>
+
+<p>
+(Absence of explicit intentional.)
+</p>
+
+<p>
+<tt>px.reset( nullptr )</tt> seems a somewhat contrived way to write <tt>px.reset()</tt>, so
+I'm not convinced of its utility.
+</p>
+<p>
+It's similarly not clear to me whether the deleter constructors need to be
+extended to take <tt>nullptr</tt>, but if they need to:
+</p>
+<p>
+Add
+</p>
+
+<blockquote><pre>template<class D> shared_ptr(nullptr_t p, D d);
+template<class D, class A> shared_ptr(nullptr_t p, D d, A a);
+</pre></blockquote>
+
+<p>
+after
+</p>
+
+<blockquote><pre>template<class Y, class D> shared_ptr(Y* p, D d);
+template<class Y, class D, class A> shared_ptr(Y* p, D d, A a);
+</pre></blockquote>
+
+<p>
+Note that this changes the semantics of the new constructors such that they
+consistently call <tt>d(p)</tt> instead of <tt>d((T*)0)</tt> when <tt>p</tt> is <tt>nullptr</tt>.
+</p>
+<p>
+The ability to be able to pass <tt>0/NULL</tt> to a function that takes a <tt>shared_ptr</tt>
+has repeatedly been requested by users, but the other additions that the
+proposed resolution makes are not supported by real world demand or
+motivating examples.
+</p>
+<p>
+It might be useful to split the obvious and non-controversial <tt>nullptr_t</tt>
+constructor into a separate issue. Waiting for "empty" to be clarified is
+unnecessary; this is effectively an alias for the default constructor.
+</p>
+</blockquote>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+We want to remove the reset functions from the proposed resolution.
+</p>
+<p>
+The remaining proposed resolution text (addressing the constructors) are wanted.
+</p>
+<p>
+Disposition: move to review. The review should check the wording in the then-current working draft.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the following constructors to 20.7.12.2 [util.smartptr.shared]:
+</p>
+
+<blockquote><pre>shared_ptr(nullptr_t);
+template <class D> shared_ptr(nullptr_t, D d);
+template <class D, class A> shared_ptr(nullptr_t, D d, A a);
+</pre></blockquote>
+
+
+
+<p>
+Add the following constructor definitions to 20.7.12.2.1 [util.smartptr.shared.const]:
+</p>
+
+<blockquote>
+<pre> explicit shared_ptr(nullptr_t);
+</pre>
+<blockquote>
+<p>
+<i>Effects:</i> Constructs an empty shared_ptr object.
+</p>
+<p>
+<i>Postconditions:</i> <tt>use_count() == 0 && get() == 0</tt>.
+</p>
+<p>
+<i>Throws:</i> nothing.
+</p>
+</blockquote>
+</blockquote>
+
+<blockquote>
+<pre>template <class D> shared_ptr(nullptr_t, D d);
+template <class D, class A> shared_ptr<nullptr_t, D d, A a);
+</pre>
+<blockquote>
+<p>
+<i>Requires:</i> <tt>D</tt> shall be <tt>CopyConstructible</tt>. The copy constructor and
+destructor of <tt>D</tt> shall not throw exceptions. The expression
+<tt>d(static_cast<T *>(0))</tt> shall be well-formed, shall have well defined behavior,
+and shall not throw exceptions. <tt>A</tt> shall be an allocator (20.1.2 [allocator.requirements]).
+The copy constructor and destructor of <tt>A</tt> shall not throw
+exceptions.
+</p>
+<p>
+<i>Effects:</i> Constructs a <tt>shared_ptr</tt> object that owns a null pointer of type <tt>T *</tt>
+and deleter <tt>d</tt>. The
+second constructor shall use a copy of <tt>a</tt> to allocate memory for
+internal use.
+</p>
+<p>
+<i>Postconditions:</i> <tt>use_count() == 1</tt> and <tt>get() == 0</tt>.
+</p>
+<p>
+<i>Throws:</i> <tt>bad_alloc</tt>, or an implementation-defined exception when a
+resource other than memory could not be obtained.
+</p>
+<p>
+<i>Exception safety:</i> If an exception is thrown, <tt>d(static_cast<Y *>(nullptr))</tt> is called.
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+
+
+<hr>
+<h3><a name="760"></a>760. The emplace issue</h3>
+<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>
+ <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2007-11-11</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+In an emplace member function the function parameter pack may be bound
+to a priori unlimited number of objects: some or all of them can be
+elements of the container itself. Apparently, in order to conform to the
+blanket statement 23.1 [container.requirements]/11, the implementation must check all of them for
+that possibility. A possible solution can involve extending the
+exception in 23.1 [container.requirements]/12 also to the emplace member. As a side note, the
+<tt>push_back</tt> and <tt>push_front</tt> member functions are luckily not affected by
+this problem, can be efficiently implemented anyway
+</p>
+
+<p><i>[
+Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>
+]</i></p>
+
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+The proposed addition (13) is partially redundant with the existing
+paragraph 12. Why was the qualifier "rvalues" added to paragraph 12? Why
+does it not cover subelements and pointers?
+</p>
+<p>
+Resolution: Alan Talbot to rework language, then set state to Review.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add after 23.1 [container.requirements]/12:
+</p>
+
+<blockquote>
+<p>
+-12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No
+diagnostic required.
+</p>
+<p>
+<ins>
+-13- Objects bound to the function parameter pack of the <tt>emplace</tt> member function shall not be elements or
+sub-objects of elements of the container. No diagnostic required.
+</ins>
+</p>
+
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="762"></a>762. <tt>std::unique_ptr</tt> requires complete type?</h3>
+<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>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-11-30</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+In contrast to the proposed <tt>std::shared_ptr</tt>, <tt>std::unique_ptr</tt>
+does currently not support incomplete types, because it
+gives no explicit grant - thus instantiating <tt>unique_ptr</tt> with
+an incomplete pointee type <tt>T</tt> automatically belongs to
+undefined behaviour according to 17.4.3.7 [res.on.functions]/2, last
+bullet. This is an unnecessary restriction and prevents
+many well-established patterns - like the bridge pattern -
+for <tt>std::unique_ptr</tt>.
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Move to open. The LWG is comfortable with the intent of allowing
+incomplete types and making <tt>unique_ptr</tt> more like <tt>shared_ptr</tt>, but we are
+not comfortable with the wording. The specification for <tt>unique_ptr</tt>
+should be more like that of <tt>shared_ptr</tt>. We need to know, for individual
+member functions, which ones require their types to be complete. The
+<tt>shared_ptr</tt> specification is careful to say that for each function, and
+we need the same level of care here. We also aren't comfortable with the
+"part of the operational semantic" language; it's not used elsewhere in
+the standard, and it's not clear what it means. We need a volunteer to
+produce new wording.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+The proposed changes in the following revision refers to the current state of
+N2521 including the assumption that 20.7.11.4 [unique.ptr.compiletime] will be removed
+according to the current state of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>.
+</p>
+<p>
+The specialization <tt>unique_ptr<T[]></tt> has some more restrictive constraints on
+type-completeness on <tt>T</tt> than <tt>unique_ptr<T></tt>. The following proposed wordings
+try to cope with that. If the committee sees less usefulness on relaxed
+constraints on <tt>unique_ptr<T[]></tt>, the alternative would be to stop this relaxation
+e.g. by adding one further bullet to 20.7.11.3 [unique.ptr.runtime]/1:
+"<tt>T</tt> shall be a complete type, if used as template argument of
+<tt>unique_ptr<T[], D></tt>
+</p>
+<p>
+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
+problems with this one,
+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
+with the here discussed
+ones, provided that <tt>D::pointer</tt>'s operations (including default
+construction, copy construction/assignment,
+and pointer conversion) are specified <em>not</em> to throw, otherwise this
+would have impact on the
+current specification of <tt>unique_ptr</tt>.
+</p>
+
+<ol>
+<li>
+<p>
+In 20.7.11 [unique.ptr]/2 add as the last sentence to the existing para:
+</p>
+
+<blockquote>
+The <tt>unique_ptr</tt> provides a semantics of strict ownership. A
+<tt>unique_ptr</tt> owns the object it holds a pointer to. A
+<tt>unique_ptr</tt> is not <tt>CopyConstructible</tt>, nor
+<tt>CopyAssignable</tt>, however it is <tt>MoveConstructible</tt> and
+<tt>MoveAssignable</tt>. <ins>The template parameter <tt>T</tt> of
+<tt>unique_ptr</tt> may be an incomplete type.</ins> [ <i>Note:</i> The
+uses of <tt>unique_ptr</tt> include providing exception safety for
+dynamically allcoated memory, passing ownership of dynamically allocated
+memory to a function, and returning dynamically allocated memory from a
+function. -- <i>end note</i> ]
+</blockquote>
+</li>
+
+<li>
+<p>
+20.7.11.2.1 [unique.ptr.single.ctor]/1: No changes necessary.
+</p>
+
+<blockquote>
+<p><i>[
+N.B.: We only need the requirement that <tt>D</tt> is <tt>DefaultConstructible</tt>.
+The current wording says just this.
+]</i></p>
+
+</blockquote>
+</li>
+
+<li>
+<p>
+In 20.7.11.2.1 [unique.ptr.single.ctor]/5 change the requires clause to say:
+</p>
+
+<blockquote>
+<p>
+<i>Requires:</i> <del>The expression <tt>D()(p)</tt> shall be well formed. The default constructor
+of <tt>D</tt> shall not throw an exception.</del>
+<del><tt>D</tt> must not be a reference type.</del>
+<ins>
+<tt>D</tt> shall be default constructible, and that construction
+shall not throw an exception.
+</ins>
+</p>
+<p><i>[
+N.B.: There is no need that the expression <tt>D()(p)</tt> is well-formed at
+this point. I assume that the current wording is based on the
+corresponding <tt>shared_ptr</tt> wording. In case of <tt>shared_ptr</tt> this
+requirement is necessary, because the corresponding c'tor *can* fail
+and must invoke delete <tt>p/d(p)</tt> in this case. <tt>Unique_ptr</tt> is simpler in
+this regard. The *only* functions that must insist on well-formedness
+and well-definedness of the expression <tt>get_deleter()(get())</tt> are (1)
+the destructor and (2) <tt>reset</tt>. The reasoning for the wording change to
+explicitly require <tt>DefaultConstructible</tt> of <tt>D</tt> is to guarantee that
+invocation of
+<tt>D</tt>'s default c'tor is both well-formed and well-defined. Note also that
+we do *not* need the
+requirement that <tt>T</tt> must be complete, also in contrast to <tt>shared_ptr</tt>.
+<tt>Shared_ptr</tt> needs this, because it's c'tor is a template c'tor which
+potentially requires <tt>Convertible<Y*, X*></tt>, which
+again requires Completeness of <tt>Y</tt>, if <tt>!SameType<X, Y></tt>
+]</i></p>
+
+</blockquote>
+</li>
+
+<li>
+<p>
+Merge 20.7.11.2.1 [unique.ptr.single.ctor]/12+13 thereby removing the sentence
+of 12, but transferring the "requires" to 13:
+</p>
+
+<blockquote>
+<p>
+<i>Requires:</i> If <tt>D</tt> is not an lvalue-reference type then[..]
+</p>
+<p><i>[
+N.B.: For the same reasons as for (3), there is no need that <tt>d(p)</tt> is
+well-formed/well-defined at this point. The current wording guarantees
+all what we need, namely that the initialization of both the <tt>T*</tt>
+pointer and the <tt>D</tt> deleter are well-formed and well-defined.
+]</i></p>
+
+</blockquote>
+</li>
+
+<li>
+20.7.11.2.1 [unique.ptr.single.ctor]/17: No changes necessary.
+</li>
+<li>
+<p>20.7.11.2.1 [unique.ptr.single.ctor]/21:</p>
+
+<blockquote>
+<i>Requires:</i> If <tt>D</tt> is not a reference type, construction of
+the deleter <tt>D</tt> from an rvalue of type <tt>E</tt> shall be well
+formed and shall not throw an exception. If <tt>D</tt> is a reference
+type, then <tt>E</tt> shall be the same type as <tt>D</tt> (diagnostic
+required). <tt>U*</tt> shall be implicitly convertible to <tt>T*</tt>.
+<ins>[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt>
+be complete types. <i>-- end note</i>]</ins>
+</blockquote>
+
+<p><i>[
+N.B.: The current wording of 21 already implicitly guarantees that <tt>U</tt>
+is completely defined, because it requires that <tt>Convertible<U*, T*></tt> is
+true. If the committee wishes this explicit requirement can be added,
+e.g. "<tt>U</tt> shall be a complete type."
+]</i></p>
+
+</li>
+
+<li>
+<p>
+20.7.11.2.2 [unique.ptr.single.dtor]: Just before p1 add a new paragraph:
+</p>
+<blockquote>
+<p>
+<i>Requires:</i> The expression <tt>get_deleter()(get())</tt> shall be well-formed,
+shall have well-defined behavior, and shall not throw exceptions.
+<ins>[<i>Note:</i> The use of <tt>default_delete</tt> requires <tt>T</tt> to
+be a complete type. <i>-- end note</i>]</ins>
+</p>
+<p><i>[
+N.B.: This requirement ensures that the whole responsibility on
+type-completeness of <tt>T</tt> is delegated to this expression.
+]</i></p>
+
+</blockquote>
+</li>
+
+<li>
+<p>
+20.7.11.2.3 [unique.ptr.single.asgn]/1: No changes necessary, except the
+current editorial issue, that "must shall" has to be changed to
+"shall", but this change is not a special part of this resolution.
+</p>
+
+<p><i>[
+N.B. The current wording is sufficient, because we can delegate all
+further requirements on the requirements of the effects clause
+]</i></p>
+
+</li>
+
+<li>
+<p>
+20.7.11.2.3 [unique.ptr.single.asgn]/6:
+</p>
+
+<blockquote>
+<i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
+<tt>D</tt> shall not throw an exception. <tt>U*</tt> shall be implicitly
+convertible to <tt>T*</tt>.
+<ins>[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt>
+be complete types. <i>-- end note</i>]</ins>
+</blockquote>
+
+<p><i>[
+N.B.: The current wording of p. 6 already implicitly guarantees that
+<tt>U</tt> is completely defined, because it requires that <tt>Convertible<U*, T*></tt>
+is true, see (6)+(8).
+]</i></p>
+
+</li>
+
+<li>
+<p>
+20.7.11.2.3 [unique.ptr.single.asgn]/11: No changes necessary.
+</p>
+<p><i>[
+N.B.: Delegation to requirements of effects clause is sufficient.
+]</i></p>
+
+</li>
+
+<li>
+20.7.11.2.4 [unique.ptr.single.observers]/1+4+7+9+11:
+</li>
+
+<blockquote>
+<pre>T* operator->() const;</pre>
+<blockquote>
+<ins><i>Note:</i> Use typically requires <tt>T</tt> shall be complete. <i>-- end note</i>]</ins>
+</blockquote>
+</blockquote>
+
+<li>
+20.7.11.2.5 [unique.ptr.single.modifiers]/1: No changes necessary.
+</li>
+
+<li>
+<p>
+20.7.11.2.5 [unique.ptr.single.modifiers]/4: Just before p. 4 add a new paragraph:
+</p>
+<blockquote>
+<i>Requires:</i> The expression <tt>get_deleter()(get())</tt> shall be well-formed,
+shall have well-defined behavior, and shall not throw exceptions.
+</blockquote>
+</li>
+
+<li>
+20.7.11.2.5 [unique.ptr.single.modifiers]/7: No changes necessary.
+</li>
+
+<li>
+<p>
+20.7.11.3 [unique.ptr.runtime]: Add one additional bullet on paragraph 1:
+</p>
+
+<blockquote>
+<p>
+A specialization for array types is provided with a slightly altered interface.
+</p>
+
+<ul>
+<li>
+...
+</li>
+<li>
+<ins><tt>T</tt> shall be a complete type.</ins>
+</li>
+</ul>
+</blockquote>
+</li>
+</ol>
+
+<p><i>[
+post Bellevue: Daniel provided revised wording.
+]</i></p>
+
+
+
+
+
+
+
+<hr>
+<h3><a name="765"></a>765. more on iterator validity</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-12-14</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+ <p>
+
+Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a>
+defines the meaning of the term "invalid iterator" as one that may be
+singular.
+
+ </p>
+ <p>
+
+Consider the following code:
+
+ </p>
+ <pre> std::deque<int> x, y;
+ std::deque<int>::iterator i = x.end(), j = y.end();
+ x.swap(y);
+ </pre>
+ <p>
+
+Given that <code>swap()</code> is required not to invalidate iterators
+and using the definition above, what should be the expected result of
+comparing <code>i</code> and <code>j</code> to <code>x.end()</code>
+and <code>y.end()</code>, respectively, after the <code>swap()</code>?
+
+ </p>
+ <p>
+
+I.e., is the expression below required to evaluate
+to <code>true</code>?
+
+ </p>
+ <pre> i == y.end() && j == x.end()
+ </pre>
+ <p>
+
+(There are at least two implementations where the expression
+returns <code>false</code>.)
+
+ </p>
+ <p>
+
+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
+make any guarantees about whether iterators actually point to the same
+elements or be associated with the same containers after a
+non-invalidating operation as they did before?
+
+ </p>
+ <p>
+
+Here's a motivating example intended to demonstrate the importance of
+the question:
+
+ </p>
+ <pre> Container x, y ({ 1, 2}); // pseudocode to initialize y with { 1, 2 }
+ Container::iterator i = y.begin() + 1;
+ Container::iterator j = y.end();
+ std::swap(x, y);
+ std::find(i, j, 3);
+ </pre>
+ <p>
+
+<code>swap()</code> guarantees that <code>i</code> and <code>j</code>
+continue to be valid. Unless the spec says that even though they are
+valid they may no longer denote a valid range the code above must be
+well-defined. Expert opinions on this differ as does the behavior of
+popular implementations for some standard <code>Containers</code>.
+
+ </p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="769"></a>769. std::function should use nullptr_t instead of "unspecified-null-pointer-type"</h3>
+<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>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-10</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+N2461 already replaced in 20.6.15.2 [func.wrap.func] it's originally proposed
+(implicit) conversion operator to "unspecified-bool-type" by the new
+explicit bool conversion, but the inverse conversion should also
+use the new <tt>std::nullptr_t</tt> type instead of "unspecified-null-pointer-
+type".
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+In 20.6 [function.objects], header <tt><functional></tt> synopsis replace:
+</p>
+
+<blockquote><pre>template<class R, class... ArgTypes>
+ bool operator==(const function<R(ArgTypes...)>&, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
+template<class R, class... ArgTypes>
+ bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>&);
+template<class R, class... ArgTypes>
+ bool operator!=(const function<R(ArgTypes...)>&, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
+template<class R, class... ArgTypes>
+ bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>&);
+</pre></blockquote>
+
+<p>
+In the class function synopsis of 20.6.15.2 [func.wrap.func] replace
+</p>
+
+<blockquote><pre>function(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
+...
+function& operator=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
+</pre></blockquote>
+
+<p>
+In 20.6.15.2 [func.wrap.func], "Null pointer comparisons" replace:
+</p>
+
+<blockquote><pre>template <class R, class... ArgTypes>
+ bool operator==(const function<R(ArgTypes...)>&, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
+template <class R, class... ArgTypes>
+ bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>&);
+template <class R, class... ArgTypes>
+ bool operator!=(const function<R(ArgTypes...)>&, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
+template <class R, class... ArgTypes>
+ bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>&);
+</pre></blockquote>
+
+<p>
+In 20.6.15.2.1 [func.wrap.func.con], replace
+</p>
+
+<blockquote><pre>function(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
+...
+function& operator=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
+</pre></blockquote>
+
+<p>
+In 20.6.15.2.6 [func.wrap.func.nullptr], replace
+</p>
+
+<blockquote><pre>template <class R, class... ArgTypes>
+ bool operator==(const function<R(ArgTypes...)>& f, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
+template <class R, class... ArgTypes>
+ bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>& f);
+</pre></blockquote>
+
+<p>
+and replace
+</p>
+
+<blockquote><pre>template <class R, class... ArgTypes>
+ bool operator!=(const function<R(ArgTypes...)>& f, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
+template <class R, class... ArgTypes>
+ bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>& f);
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="771"></a>771. Impossible throws clause in [string.conversions]</h3>
+<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>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-13</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The new <tt>to_string</tt> and <tt>to_wstring</tt> functions described in 21.4 [string.conversions]
+have throws clauses (paragraphs 8 and 16) which say:
+</p>
+
+<blockquote>
+<i>Throws:</i> nothing
+</blockquote>
+
+<p>
+Since all overloads return either a <tt>std::string</tt> or a <tt>std::wstring</tt> by value
+this throws clause is impossible to realize in general, since the <tt>basic_string</tt>
+constructors can fail due to out-of-memory conditions. Either these throws
+clauses should be removed or should be more detailled like:
+</p>
+
+<blockquote>
+<i>Throws:</i> Nothing if the string construction throws nothing
+</blockquote>
+
+<p>
+Further there is an editorial issue in p. 14: All three <tt>to_wstring</tt>
+overloads return a <tt>string</tt>, which should be <tt>wstring</tt> instead (The
+header <tt><string></tt> synopsis of 21.2 [string.classes] is correct in this
+regard).
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 21.4 [string.conversions], remove the paragraphs 8 and 16.
+</p>
+
+<blockquote>
+<pre>string to_string(long long val);
+string to_string(unsigned long long val);
+string to_string(long double val);
+</pre>
+<blockquote>
+<del><i>Throws:</i> nothing</del>
+</blockquote>
+</blockquote>
+
+<blockquote>
+<pre><ins>w</ins>string to_wstring(long long val);
+<ins>w</ins>string to_wstring(unsigned long long val);
+<ins>w</ins>string to_wstring(long double val);
+</pre>
+<blockquote>
+<del><i>Throws:</i> nothing</del>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="772"></a>772. Impossible return clause in [string.conversions]</h3>
+<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>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-13</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The return clause 21.4 [string.conversions]/paragraph 15 of the new <tt>to_wstring</tt>
+overloads says:
+</p>
+
+<blockquote>
+<i>Returns:</i> each function returns a <tt>wstring</tt> object holding the character
+representation of the value of its argument that would be generated by
+calling <tt>wsprintf(buf, fmt, val)</tt> with a format specifier of <tt>L"%lld"</tt>, <tt>L"%ulld"</tt>,
+or <tt>L"%f"</tt>, respectively.
+</blockquote>
+
+<p>
+Problem is: There does not exist any <tt>wsprintf</tt> function in C99 (I checked
+the 2nd edition of ISO 9899, and the first and the second corrigenda from
+2001-09-01 and 2004-11-15). What probably meant here is the function
+<tt>swprintf</tt> from <tt><wchar.h>/<cwchar></tt>, but this has the non-equivalent
+declaration:
+</p>
+
+<blockquote><pre>int swprintf(wchar_t * restrict s, size_t n,
+const wchar_t * restrict format, ...);
+</pre></blockquote>
+
+<p>
+therefore the paragraph needs to mention the <tt>size_t</tt> parameter <tt>n</tt>.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the current wording of 21.4 [string.conversions]/p. 15 to:
+</p>
+
+<blockquote>
+<i>Returns:</i> <del>e</del><ins>E</ins>ach function returns a
+<tt>wstring</tt> object holding the character representation of the
+value of its argument that would be generated by calling
+<tt><del>ws</del><ins>sw</ins>printf(buf, <ins>bufsz,</ins> fmt,
+val)</tt> with a format specifier <ins><tt>fmt</tt></ins> of <tt>L"%lld"</tt>,
+<tt>L"%ulld"</tt>, or <tt>L"%f"</tt>, respectively<ins>, where <tt>buf</tt>
+designates an internal character buffer of sufficient size <tt>bufsz</tt></ins>.
+</blockquote>
+
+<p>
+[Hint to the editor: The resolution also adds to mention the name of
+the format specifier "fmt"]
+</p>
+
+<p>
+I also would like to remark that the current wording of it's equivalent
+paragraph 7 should also mention the meaning of <tt>buf</tt> and <tt>fmt</tt>.
+</p>
+
+<p>
+Change the current wording of 21.4 [string.conversions]/p. 7 to:
+</p>
+
+<blockquote>
+<i>Returns:</i> <del>e</del><ins>E</ins>ach function returns a string object holding the
+character representation of the value of its argument that would be
+generated by calling <tt>sprintf(buf, fmt, val)</tt> with a format specifier <ins><tt>fmt</tt></ins> of
+<tt>"%lld"</tt>, <tt>"%ulld"</tt>, or <tt>"%f"</tt>, respectively<ins>, where <tt>buf</tt> designates an internal
+character buffer of sufficient size</ins>.
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="774"></a>774. Member swap undefined for most containers</h3>
+<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>
+ <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-01-14</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+It appears most containers declare but do not define a member-swap
+function.
+</p>
+
+<p>
+This is unfortunate, as all overload the <tt>swap</tt> algorithm to call the
+member-swap function!
+(required for <tt>swappable</tt> guarantees [Table 37] and Container Requirements
+[Table 87])
+</p>
+
+<p>
+Note in particular that Table 87 gives semantics of <tt>a.swap(b)</tt> as <tt>swap(a,b)</tt>,
+yet for all containers we define <tt>swap(a,b)</tt> to call <tt>a.swap(b)</tt> - a circular
+definition.
+</p>
+
+<p>
+A quick survey of clause 23 shows that the following containers provide a
+definition for member-swap:
+</p>
+
+<blockquote><pre>array
+queue
+stack
+vector
+</pre></blockquote>
+
+<p>
+Whereas the following declare it, but do not define the semantics:
+</p>
+
+<blockquote><pre>deque
+list
+map
+multimap
+multiset
+priority_queue
+set
+unordered_map
+unordered_multi_map
+unordered_multi_set
+unordered_set
+</pre></blockquote>
+
+<p>
+Suggested resolution:
+</p>
+<blockquote>
+Provide a definition for each of the affected containers...
+</blockquote>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Move to Open and ask Alisdair to provide wording.
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Wording provided in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2590.pdf">N2590</a>.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="776"></a>776. Undescribed assign function of std::array</h3>
+<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>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-20</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The class template array synopsis in 23.2.1 [array]/3 declares a member
+function
+</p>
+
+<blockquote><pre>void assign(const T& u);
+</pre></blockquote>
+
+<p>
+which's semantic is no-where described. Since this signature is
+not part of the container requirements, such a semantic cannot
+be derived by those.
+</p>
+
+<p>
+I found only one reference to this function in the issue list,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a> where the question is raised:
+</p>
+
+<blockquote>
+what's the effect of calling <tt>assign(T&)</tt> on a zero-sized array?
+</blockquote>
+
+<p>
+which does not answer the basic question of this issue.
+</p>
+
+<p>
+If this function shall be part of the <tt>std::array</tt>, it's probable
+semantic should correspond to that of <tt>boost::array</tt>, but of
+course such wording must be added.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Just after the section 23.2.1.4 [array.data] add the following new section:
+</p>
+
+<p>
+23.2.1.5 array::fill [array.fill]
+</p>
+
+<blockquote>
+<pre>void fill(const T& u);
+</pre>
+
+<p>
+1: <i>Effects:</i> <tt>fill_n(begin(), N, u)</tt>
+</p>
+</blockquote>
+
+<p>
+[N.B: I wonder, why class <tt>array</tt> does not have a "modifiers"
+section. If it had, then <tt>assign</tt> would naturally belong to it]
+</p>
+
+<p>
+Change the synopsis in 23.2.1 [array]/3:
+</p>
+
+<blockquote><pre>template <class T, size_t N>
+struct array {
+ ...
+ void <del>assign</del> <ins>fill</ins>(const T& u);
+ ...
+</pre></blockquote>
+
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+Suggest substituting "fill" instead of "assign".
+</p>
+<p>
+Set state to Review given substitution of "fill" for "assign".
+</p>
+</blockquote>
+
+
+
+
+<hr>
+<h3><a name="779"></a>779. Resolution of #283 incomplete</h3>
+<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>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-25</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+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
+<tt>remove_copy[_if]</tt>,
+which seems to be an oversight.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 25.2.8 [alg.remove]/p.6, replace the N2461 requires clause with:
+</p>
+
+<blockquote>
+<i>Requires:</i> <del>Type <tt>T</tt> is <tt>EqualityComparable</tt> (31).</del> The ranges <tt>[first,last)</tt>
+and <tt>[result,result + (last - first))</tt> shall not overlap. <ins>The expression <tt>*result = *first</tt> shall be
+valid.</ins>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="780"></a>780. <tt>std::merge()</tt> specification incorrect/insufficient</h3>
+<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>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-25</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+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:
+</p>
+
+<p>
+Both 25.3.4 [lib.alg.merge] in 14882:2003 and 25.3.4 [alg.merge] in N2461
+have no Requires element and the Effects element contains some requirements,
+which is probably editorial. Worse is that:
+</p>
+
+<ul>
+<li>
+no assignment requirements are specified (neither implicit nor explicit).
+</li>
+
+<li>
+the effects clause just speaks of "merges", which is badly worded
+near to a circular definition.
+</li>
+
+<li>
+p. 2 mentions a range <tt>[first, last)</tt>, which is not defined by the
+function arguments or otherwise.
+</li>
+
+<li>
+p. 2 says "according to the ordering defined by comp" which is both
+incomplete (because
+this excludes the first variant with <) and redundant (because the
+following subordinate
+clause mentions comp again)
+</li>
+</ul>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 25.3.4 [alg.merge] replace p.1+ 2:
+</p>
+
+<blockquote>
+<p>
+<i>Effects:</i> <del>Merges</del> <ins>Copies all the elements of the</ins> two sorted ranges <tt>[first1,last1)</tt> and
+<tt>[first2,last2)</tt> into the range
+<del><tt>[result,result + (last1 - first1) + (last2 - first2))</tt></del>
+<ins><tt>[result, last)</tt> (where <tt>last</tt> is equal to <tt>result + (last1
+- first1) + (last2 - first2))</tt>, such that resulting range will be
+sorted in non-decreasing order; that is, for every iterator <tt>i</tt> in
+<tt>[result,last)</tt> other than <tt>result</tt>, the condition <tt>*i < *(i - 1)</tt> or,
+respectively, <tt>comp(*i, *(i - 1))</tt> will be false</ins>.
+</p>
+
+<p>
+<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
+order according to the ordering defined by <tt>comp</tt>; that is, for every iterator <tt>i</tt> in
+<tt>[first,last)</tt> other than <tt>first</tt>, the condition <tt>*i < *(i - 1)</tt> or
+<tt>comp(*i, *(i - 1))</tt> will be false.</del> <ins>The results of the expressions <tt>*first1</tt> and <tt>*first2</tt>
+shall be writable to the output iterator.</ins>
+</p>
+</blockquote>
+
+<p>
+[N.B.: I attempted to reuse the wording style of <tt>inplace_merge</tt>,
+therefore proposing to
+insert ", respectively," between both predicate tests. This is no
+strictly necessary as
+other parts of <tt><algorithm></tt> show, just a matter of consistency]
+</p>
+
+
+
+
+
+
+<hr>
+<h3><a name="785"></a>785. Random Number Requirements in TR1</h3>
+<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>
+ <b>Submitter:</b> John Maddock <b>Date:</b> 2008-01-15</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+Table 16 of TR1 requires that all Pseudo Random Number generators have a
+</p>
+
+<blockquote><pre>seed(integer-type s)
+</pre></blockquote>
+
+<p>
+member function that is equivalent to:
+</p>
+
+<blockquote><pre>mygen = Generator(s)
+</pre></blockquote>
+
+<p>
+But the generators <tt>xor_combine</tt> and <tt>discard_block</tt> have no such seed member, only the
+</p>
+
+<blockquote><pre>template <class Gen>
+seed(Gen&);
+</pre></blockquote>
+
+<p>
+member, which will not accept an integer literal as an argument: something that appears to violate the intent of Table 16.
+</p>
+
+<p>
+So... is this a bug in TR1?
+</p>
+
+<p>This is a real issue BTW, since the Boost implementation does adhere
+to the requirements of Table 16, while at least one commercial
+implementation does not and follows a strict adherence to sections
+5.1.4.5 and 5.1.4.6 instead.
+</p>
+
+<p><i>[
+Jens adds:
+]</i></p>
+
+
+<blockquote>
+Both engines do have the necessary
+constructor, therefore the omission of the <tt>seed()</tt> member
+functions appears to be an oversight.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="787"></a>787. complexity of <tt>binary_search</tt></h3>
+<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>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-09-08</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+In 25.3.3.4 [binary.search]/3 the complexity of <tt>binary_search</tt> is described as
+</p>
+
+<blockquote>
+At most <tt>log(last - first) + 2</tt> comparisons.
+</blockquote>
+
+<p>
+This should be precised and brought in line with the nomenclature used for
+<tt>lower_bound</tt>, <tt>upper_bound</tt>, and <tt>equal_range</tt>.
+</p>
+
+<p>
+All existing libraries I'm aware of, delegate to
+<tt>lower_bound</tt> (+ one further comparison). Since
+issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>
+has now WP status, the resolution of #787 should
+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>
+to <tt>+ O(1)</tt>.
+</p>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+Alisdair prefers to apply an upper bound instead of O(1), but that would
+require fixing for <tt>lower_bound</tt>, <tt>upper_bound</tt> etc. as well. If he really
+cares about it, he'll send an issue to Howard.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 25.3.3.4 [binary.search]/3
+</p>
+
+<blockquote>
+<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.
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="788"></a>788. ambiguity in [istream.iterator]</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-02-06</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The description of how an istream_iterator object becomes an
+end-of-stream iterator is a) ambiguous and b) out of date WRT
+issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>:
+</p>
+
+<blockquote>
+<tt>istream_iterator</tt> reads (using <tt>operator>></tt>) successive elements from the
+input stream for which it was constructed. After it is constructed, and
+every time <tt>++</tt> is used, the iterator reads and stores a value of <tt>T</tt>. If
+the end of stream is reached (<tt>operator void*()</tt> on the stream returns
+<tt>false</tt>), the iterator becomes equal to the <i>end-of-stream</i> iterator value.
+The constructor with no arguments <tt>istream_iterator()</tt> always constructs
+an end of stream input iterator object, which is the only legitimate
+iterator to be used for the end condition. The result of <tt>operator*</tt> on an
+end of stream is not defined. For any other iterator value a <tt>const T&</tt> is
+returned. The result of <tt>operator-></tt> on an end of stream is not defined.
+For any other iterator value a <tt>const T*</tt> is returned. It is impossible to
+store things into istream iterators. The main peculiarity of the istream
+iterators is the fact that <tt>++</tt> operators are not equality preserving,
+that is, <tt>i == j</tt> does not guarantee at all that <tt>++i == ++j</tt>. Every time <tt>++</tt>
+is used a new value is read.
+</blockquote>
+
+<p>
+<tt>istream::operator void*()</tt> returns null if <tt>istream::fail()</tt> is <tt>true</tt>,
+otherwise non-null. <tt>istream::fail()</tt> returns <tt>true</tt> if <tt>failbit</tt> or
+<tt>badbit</tt> is set in <tt>rdstate()</tt>. Reaching the end of stream doesn't
+necessarily imply that <tt>failbit</tt> or <tt>badbit</tt> is set (e.g., after
+extracting an <tt>int</tt> from <tt>stringstream("123")</tt> the stream object will
+have reached the end of stream but <tt>fail()</tt> is <tt>false</tt> and <tt>operator
+void*()</tt> will return a non-null value).
+</p>
+
+<p>
+Also I would prefer to be explicit about calling <tt>fail()</tt> here
+(there is no <tt>operator void*()</tt> anymore.)
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 24.5.1 [istream.iterator]/1:
+</p>
+
+<blockquote>
+<tt>istream_iterator</tt> reads (using <tt>operator>></tt>) successive elements from the
+input stream for which it was constructed. After it is constructed, and
+every time <tt>++</tt> is used, the iterator reads and stores a value of <tt>T</tt>. If
+<del>the end of stream is reached</del> <ins>the iterator fails to read and store a value of <tt>T</tt></ins>
+(<tt><del>operator void*()</del> <ins>fail()</ins></tt> on the stream returns
+<tt><del>false</del> <ins>true</ins></tt>), the iterator becomes equal to the <i>end-of-stream</i> iterator value.
+The constructor with no arguments <tt>istream_iterator()</tt> always constructs
+an end of stream input iterator object, which is the only legitimate
+iterator to be used for the end condition. The result of <tt>operator*</tt> on an
+end of stream is not defined. For any other iterator value a <tt>const T&</tt> is
+returned. The result of <tt>operator-></tt> on an end of stream is not defined.
+For any other iterator value a <tt>const T*</tt> is returned. It is impossible to
+store things into istream iterators. The main peculiarity of the istream
+iterators is the fact that <tt>++</tt> operators are not equality preserving,
+that is, <tt>i == j</tt> does not guarantee at all that <tt>++i == ++j</tt>. Every time <tt>++</tt>
+is used a new value is read.
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="793"></a>793. <tt>discrete_distribution</tt> missing constructor</h3>
+<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>
+ <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+<tt>discrete_distribution</tt> should have a constructor like:
+</p>
+
+<blockquote><pre>template<class _Fn>
+ discrete_distribution(result_type _Count, double _Low, double _High,
+ _Fn& _Func);
+</pre></blockquote>
+
+<p>
+(Makes it easier to fill a histogram with function values over a range.)
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+How do you specify the function so that it does not return negative
+values? If you do it is a bad construction. This requirement is already
+there. Where in each bin does one evaluate the function? In the middle.
+Need to revisit tomorrow.
+</blockquote>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+Bill is not requesting this.
+</p>
+<p>
+Marc Paterno: <tt>_Fn</tt> cannot return negative values at the points where the
+function is sampled. It is sampled in the middle of each bin. <tt>_Fn</tt> cannot
+return 0 everywhere it is sampled.
+</p>
+<p>
+Jens: lambda expressions are rvalues
+</p>
+<p>
+Add a library issue to provide an
+<tt>initializer_list<double></tt> constructor for
+<tt>discrete_distribution</tt>.
+</p>
+<p>
+Marc Paterno: dislikes reference for <tt>_Fn</tt> parameter. Make it pass-by-value (to use lambda),
+use <tt>std::ref</tt> to wrap giant-state function objects.
+</p>
+<p>
+Daniel: See <tt>random_shuffle</tt>, pass-by-rvalue-reference.
+</p>
+<p>
+Daniel to draft wording.
+</p>
+</blockquote>
+
+<p><i>[
+Pre San Francisco, Daniel provided wording:
+]</i></p>
+
+
+<blockquote>
+The here proposed changes of the WP refer to the current state of
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>.
+During the Sophia Antipolis meeting two different proposals came up
+regarding the functor argument type, either by value or by rvalue-reference.
+For consistence with existing conventions (state-free algorithms and the
+<tt>general_pdf_distribution</tt> c'tor signature) the author decided to propose a
+function argument that is provided by value. If severe concerns exists that
+stateful functions would be of dominant relevance, it should be possible to
+replace the two occurrences of <tt>Func</tt> by <tt>Func&&</tt> in this proposal as part
+of an editorial process.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<ol>
+<li>
+<p>
+In 26.4.8.5.1 [rand.dist.samp.discrete]/1, class <tt>discrete_distribution</tt>, just
+<em>before</em> the member declaration
+</p>
+
+<blockquote><pre>explicit discrete_distribution(const param_type& parm);
+</pre></blockquote>
+
+<p>
+insert:
+</p>
+
+
+<blockquote><pre>template<typename Func>
+discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
+</pre></blockquote>
+</li>
+
+<li>
+<p>
+Between p.4 and p.5 insert a series of new paragraphs as part of the
+new member description::
+</p>
+<blockquote><pre>template<typename Func>
+discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
+</pre>
+
+<p>
+<i>Complexity:</i> Exactly nf invocations of fw.
+</p>
+<p>
+<i>Requires:</i>
+</p>
+<ol type="a">
+<li>
+fw shall be callable with one argument of type double, and shall
+return values of a type convertible to double;</li>
+
+<li>If nf > 0, the relation <tt><i>x</i><sub><i>min</i></sub></tt> < <tt><i>x</i><sub><i>max</i></sub></tt> shall hold, and for all sample values
+<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,
+and non-infinity;</li>
+
+<li>The following relations shall hold: nf ≥ 0, and 0 < S = <tt><i>w</i><sub><i>0</i></sub></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.</li>
+
+</ol>
+
+<p>
+<i>Effects:</i>
+</p>
+<ol type="a">
+<li>If nf == 0, sets n = 1 and lets the sequence w have length n = 1 and
+ consist of the single value <tt><i>w</i><sub><i>0</i></sub></tt> = 1.</li>
+
+<li>
+<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> +
+0.5 * deltax.</p>
+<blockquote><pre>For each k = 0, . . . ,n-1, calculates:
+ <tt><i>x</i><sub><i>k</i></sub></tt> = <tt><i>x</i><sub><i>cent</i></sub></tt> + k * deltax
+ <tt><i>w</i><sub><i>k</i></sub></tt> = fw(<tt><i>x</i><sub><i>k</i></sub></tt>)
+</pre></blockquote>
+</li>
+<li>
+<p>Constructs a discrete_distribution object with probabilities:</p>
+<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.
+</pre></blockquote>
+</li>
+</ol>
+</blockquote>
+</li>
+</ol>
+
+
+
+
+
+<hr>
+<h3><a name="794"></a>794. <tt>piecewise_constant_distribution</tt> missing constructor</h3>
+<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>
+ <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+<tt>piecewise_constant_distribution</tt> should have a constructor like:
+</p>
+
+<blockquote><pre>template<class _Fn>
+ piecewise_constant_distribution(size_t _Count,
+ _Ty _Low, _Ty _High, _Fn& _Func);
+</pre></blockquote>
+
+<p>
+(Makes it easier to fill a histogram with function values over a range.
+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
+<tt>general_pdf_distribution</tt>.)
+</p>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+Marc: uses variable width of bins and weight for each bin. This is not
+giving enough flexibility to control both variables.
+</p>
+<p>
+Add a library issue to provide an constructor taking an
+<tt>initializer_list<double></tt> and <tt>_Fn</tt> for <tt>piecewise_constant_distribution</tt>.
+</p>
+<p>
+Daniel to draft wording.
+</p>
+</blockquote>
+
+<p><i>[
+Pre San Francisco, Daniel provided wording.
+]</i></p>
+
+
+<blockquote>
+The here proposed changes of the WP refer to the current state of
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>.
+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
+argument that is provided by value. The issue proposes a c'tor signature,
+that does not take advantage of the full flexibility of
+<tt>piecewise_constant_distribution</tt>,
+because it restricts on a constant bin width, but the use-case seems to
+be popular enough to justify it's introduction.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<ol>
+<li>
+<p>
+In 26.4.8.5.2 [rand.dist.samp.pconst]/1, class <tt>piecewise_constant_distribution</tt>,
+just <em>before</em> the member declaration
+</p>
+
+<blockquote><pre>explicit piecewise_constant_distribution(const param_type& parm);
+</pre></blockquote>
+<p>
+insert:
+</p>
+<blockquote><pre>template<typename Func>
+piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
+</pre></blockquote>
+</li>
+
+<li>
+<p>
+Between p.4 and p.5 insert a new sequence of paragraphs nominated
+below as [p5_1], [p5_2],
+[p5_3], and [p5_4] as part of the new member description:
+</p>
+
+<blockquote><pre>template<typename Func>
+piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
+</pre>
+<blockquote>
+<p>
+[p5_1] <i>Complexity:</i> Exactly <tt>nf</tt> invocations of <tt>fw</tt>.
+</p>
+<p>
+[p5_2] <i>Requires:</i>
+</p>
+<ol type="a">
+<li><tt>fw</tt> shall be callable with one argument of type <tt>RealType</tt>, and shall
+return values of a type convertible to double;
+</li>
+<li>
+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
+value <tt><i>w<sub>k</sub></i></tt> that is non-negative, non-NaN, and non-infinity;
+</li>
+<li>
+The following relations shall hold: <tt><i>x<sub>min</sub></i></tt> < <tt><i>x<sub>max</sub></i></tt>, and
+0 < S = <tt><i>w<sub>0</sub></i></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.
+</li>
+</ol>
+<p>
+[p5_3] <i>Effects:</i>
+</p>
+<ol type="a">
+<li>
+<p>If nf == 0,</p>
+ <ol type="a">
+ <li>
+sets deltax = <tt><i>x<sub>max</sub></i></tt> - <tt><i>x<sub>min</sub></i></tt>, and</li>
+<li> lets the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist of the single
+ value <tt><i>w<sub>0</sub></i></tt> = 1, and</li>
+<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
+ <tt><i>b<sub>1</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt>
+</li>
+</ol>
+</li>
+<li>
+<p>Otherwise,</p>
+<ol type="a">
+<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,
+ <tt><i>x<sub>cent</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> + 0.5 * deltax, and
+</li>
+<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>
+<blockquote><pre>for each k = 0, . . . ,n-1, calculates:
+ <tt><i>dx<sub>k</sub></i></tt> = k * deltax
+ <tt><i>b<sub>k</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> + <tt><i>dx<sub>k</sub></i></tt>
+ <tt><i>x<sub>k</sub></i></tt> = <tt><i>x<sub>cent</sub></i></tt> + <tt><i>dx<sub>k</sub></i></tt>
+ <tt><i>w<sub>k</sub></i></tt> = fw(<tt><i>x<sub>k</sub></i></tt>),
+</pre></blockquote>
+<p> and</p>
+</li>
+<li> sets <tt><i>b<sub>n</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt></li>
+</ol>
+</li>
+<li>
+<p>
+Constructs a <tt>piecewise_constant_distribution</tt> object with
+the above computed sequence <tt>b</tt> as the interval boundaries
+and with the probability densities:
+</p>
+<blockquote><pre><tt><i>ρ<sub>k</sub></i></tt> = <tt><i>w<sub>k</sub></i></tt>/(S * deltax) for k = 0, . . . , n-1.
+</pre></blockquote>
+</li>
+</ol>
+<p>
+[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
+ known as the <i>bins</i> of a histogram.
+ </p>
+</blockquote>
+</blockquote>
+</li>
+</ol>
+
+
+
+
+
+
+<hr>
+<h3><a name="800"></a>800. Issues in 26.4.7.1 [rand.util.seedseq](6)</h3>
+<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>
+ <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2008-02-18</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The for-loop in the algorithm specification has <tt>n</tt> iterations, where <tt>n</tt> is
+defined to be <tt>end - begin</tt>, i.e. the number of supplied w-bit quantities.
+Previous versions of this algorithm and the general logic behind it
+suggest that this is an oversight and that in the context of the
+for-loop <tt>n</tt> should be the number of full 32-bit quantities in <tt>b</tt> (rounded
+upwards). If <tt>w</tt> is 64, the current algorithm throws away half of all bits
+in <tt>b</tt>. If <tt>w</tt> is 16, the current algorithm sets half of all elements in <tt>v</tt>
+to 0.
+</p>
+
+<p>
+There are two more minor issues:
+</p>
+
+<ul>
+<li>
+Strictly speaking <tt>end - begin</tt> is not defined since
+<tt>InputIterator</tt> is not required to be a random access iterator.
+</li>
+<li>
+Currently all integral types are allowed as input to the <tt>seed_seq</tt>
+constructor, including <tt>bool</tt>. IMHO allowing <tt>bool</tt>s unnecessarily
+complicates the implementation without any real benefit to the user.
+I'd suggest to exclude <tt>bool</tt>s as input.
+</li>
+</ul>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Move to OPEN Bill will try to propose a resolution by the next meeting.
+</blockquote>
+
+<p><i>[
+post Bellevue: Bill provided wording.
+]</i></p>
+
+
+<p>
+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.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Replace 26.4.7.1 [rand.util.seedseq] paragraph 6 with:
+</p>
+
+<blockquote>
+<p>
+<i>Effects:</i> Constructs a <tt>seed_seq</tt> object by effectively concatenating the
+low-order <tt>u</tt> bits of each of the elements of the supplied sequence <tt>[begin,
+end)</tt>
+in ascending order of significance to make a (possibly very large) unsigned
+binary number <tt>b</tt> having a total of <tt>n</tt> bits, and then carrying out the
+following
+algorithm:
+</p>
+
+<blockquote><pre>for( v.clear(); n > 0; n -= 32 )
+ v.push_back(b mod 2<sup>32</sup>), b /= 2<sup>32</sup>;
+</pre></blockquote>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="801"></a>801. <tt>tuple</tt> and <tt>pair</tt> trivial members</h3>
+<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>
+ <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-02-18</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+Classes with trivial special member functions are inherently more
+efficient than classes without such functions. This efficiency is
+particularly pronounced on modern ABIs that can pass small classes
+in registers. Examples include value classes such as complex numbers
+and floating-point intervals. Perhaps more important, though, are
+classes that are simple collections, like <tt>pair</tt> and <tt>tuple</tt>. When the
+parameter types of these classes are trivial, the <tt>pair</tt>s and <tt>tuple</tt>s
+themselves can be trivial, leading to substantial performance wins.
+</p>
+<p>
+The current working draft make specification of trivial functions
+(where possible) much easer through <tt>default</tt>ed and <tt>delete</tt>d functions.
+As long as the semantics of defaulted and deleted functions match
+the intended semantics, specification of defaulted and deleted
+functions will yield more efficient programs.
+</p>
+<p>
+There are at least two cases where specification of an explicitly
+defaulted function may be desirable.
+</p>
+<p>
+First, the <tt>std::pair</tt> template has a non-trivial default constructor,
+which prevents static initialization of the pair even when the
+types are statically initializable. Changing the definition to
+</p>
+
+<blockquote><pre>pair() = default;
+</pre></blockquote>
+
+<p>
+would enable such initialization. Unfortunately, the change is
+not semantically neutral in that the current definition effectively
+forces value initialization whereas the change would not value
+initialize in some contexts.
+</p>
+
+<p>
+** Does the committee confirm that forced value initialization
+was the intent? If not, does the committee wish to change the
+behavior of <tt>std::pair</tt> in C++0x?
+</p>
+<p>
+Second, the same default constructor issue applies to <tt>std::tuple</tt>.
+Furthermore, the <tt>tuple</tt> copy constructor is current non-trivial,
+which effectively prevents passing it in registers. To enable
+passing <tt>tuples</tt> in registers, the copy constructor should be
+make explicitly <tt>default</tt>ed. The new declarations are:
+</p>
+
+<blockquote><pre>tuple() = default;
+tuple(const tuple&) = default;
+</pre></blockquote>
+
+<p>
+This changes is not implementation neutral. In particular, it
+prevents implementations based on pointers to the parameter
+types. It does however, permit implementations using the
+parameter types as bases.
+</p>
+<p>
+** How does the committee wish to trade implementation
+efficiency versus implementation flexibility?
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+<p>
+General agreement; the first half of the issue is NAD.
+</p>
+<p>
+Before voting on the second half, it was agreed that a "Strongly Favor"
+vote meant support for trivial tuples (assuming usual requirements met),
+even at the expense of other desired qualities. A "Weakly Favor" vote
+meant support only if not at the expense of other desired qualities.
+</p>
+<p>
+Concensus: Go forward, but not at expense of other desired qualities.
+</p>
+<p>
+It was agreed to Alisdair should fold this work in with his other
+pair/tuple action items, above, and that issue 801 should be "open", but
+tabled until Alisdair's proposals are disposed of.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="803"></a>803. Simplification of <tt>seed_seq::seq_seq</tt></h3>
+<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>
+ <b>Submitter:</b> Charles Karney <b>Date:</b> 2008-02-22</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+<tt>seed_seq(InputIterator begin, InputIterator end);</tt> constructs a <tt>seed_seq</tt>
+object repacking the bits of supplied sequence <tt>[begin, end)</tt> into a
+32-bit vector.
+</p>
+<p>
+This repacking triggers several problems:
+</p>
+<ol>
+<li>
+Distinctness of the output of <tt>seed_seq::generate</tt> required the
+introduction of the initial "<tt>if (w < 32) v.push_back(n);</tt>" (Otherwise
+the unsigned short vectors [1, 0] and [1] generate the same sequence.)
+</li>
+<li>
+Portability demanded the introduction of the template parameter <tt>u</tt>.
+(Otherwise some sequences could not be obtained on computers where no
+integer types are exactly 32-bits wide.)
+</li>
+<li>
+The description and algorithm have become unduly complicated.
+</li>
+</ol>
+<p>
+I propose simplifying this <tt>seed_seq</tt> constructor to be "32-bit only".
+Despite it's being simpler, there is NO loss of functionality (see
+below).
+</p>
+<p>
+Here's how the description would read
+</p>
+<blockquote>
+<p>
+26.4.7.1 [rand.util.seedseq] Class <tt>seed_seq</tt>
+</p>
+
+<blockquote>
+<pre>template<class InputIterator>
+ seed_seq(InputIterator begin, InputIterator end);
+</pre>
+<blockquote>
+<p>
+5 <i>Requires:</i> NO CHANGE
+</p>
+<p>
+6 <i>Effects:</i> Constructs a <tt>seed_seq</tt> object by
+</p>
+<blockquote>
+<pre>for (InputIterator s = begin; s != end; ++s)
+ v.push_back((*s) mod 2^32);
+</pre>
+</blockquote>
+</blockquote>
+</blockquote>
+</blockquote>
+
+<p>
+Discussion:
+</p>
+<p>
+The chief virtues here are simplicity, portability, and generality.
+</p>
+<ul>
+<li>
+Simplicity -- compare the above specification with the
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a> proposal.
+</li>
+<li>
+Portability -- with <tt>iterator_traits<InputIterator>::value_type =
+uint_least32_t</tt> the user is guaranteed to get the same behavior across
+platforms.
+</li>
+<li>
+Generality -- any behavior that the
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
+proposal can achieve can be
+obtained with this simpler proposal (albeit with a shuffling of bits
+in the input sequence).
+</li>
+</ul>
+<p>
+Arguments (and counter-arguments) against making this change (and
+retaining the
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
+behavior) are:
+</p>
+<ul>
+<li>
+<p>
+The user can pass an array of <tt>unsigned char</tt> and <tt>seed_seq</tt> will nicely
+ repack it.
+</p>
+<p>
+ Response: So what? Consider the seed string "ABC". The
+ <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
+ proposal results in
+</p>
+<blockquote><pre>v = { 0x3, 0x434241 };
+</pre></blockquote>
+<p>
+while the simplified proposal yields
+</p>
+<blockquote><pre>v = { 0x41, 0x42, 0x43 };
+</pre></blockquote>
+<p>
+The results produced by <tt>seed_seq::generate</tt> with the two inputs are
+different but nevertheless equivalently "mixed up" and this remains
+true even if the seed string is long.
+</p>
+</li>
+<li>
+<p>
+With long strings (e.g., with bit-length comparable to the number of
+ bits in the state), <tt>v</tt> is longer (by a factor of 4) with the simplified
+ proposal and <tt>seed_seq::generate</tt> will be slower.
+</p>
+<p>
+Response: It's unlikely that the efficiency of <tt>seed_seq::generate</tt> will
+ be a big issue. If it is, the user is free to repack the seed vector
+ before constructing <tt>seed_seq</tt>.
+</p>
+</li>
+<li>
+<p>
+A user can pass an array of 64-bit integers and all the bits will be
+ used.
+</p>
+<p>
+ Response: Indeed. However, there are many instances in the
+ <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
+ where integers are silently coerced to a narrower width and this
+ should just be a case of the user needing to read the documentation.
+ The user can of course get equivalent behavior by repacking his seed
+ into 32-bit pieces. Furthermore, the unportability of the
+ <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
+ proposal with
+</p>
+<blockquote><pre>unsigned long s[] = {1, 2, 3, 4};
+seed_seq q(s, s+4);
+</pre></blockquote>
+<p>
+ which typically results in <tt>v = {1, 2, 3, 4}</tt> on 32-bit machines and in
+<tt>v = {1, 0, 2, 0, 3, 0, 4, 0}</tt> on 64-bit machines is a major pitfall for
+ unsuspecting users.
+</p>
+</li>
+</ul>
+
+<p>
+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>.
+</p>
+
+<p><i>[
+Bellevue:
+]</i></p>
+
+
+<blockquote>
+Walter needs to ask Fermilab for guidance. Defer till tomorrow. Bill likes the proposed resolution.
+</blockquote>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+Marc Paterno wants portable behavior between 32bit and 64bit machines;
+we've gone to significant trouble to support portability of engines and
+their values.
+</p>
+<p>
+Jens: the new algorithm looks perfectly portable
+</p>
+<p>
+Marc Paterno to review off-line.
+</p>
+<p>
+Modify the proposed resolution to read "Constructs a seed_seq object by the following algorithm ..."
+</p>
+<p>
+Disposition: move to review; unanimous consent.
+</p>
+<p>
+(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>)
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 26.4.7.1 [rand.util.seedseq]:
+</p>
+
+<blockquote>
+<pre>template<class InputIterator<del>,
+ size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits</del>>
+ seed_seq(InputIterator begin, InputIterator end);
+</pre>
+<blockquote>
+<p>
+-5- <i>Requires:</i> <tt>InputIterator</tt> shall satisfy the requirements of an input iterator (24.1.1)
+such that <tt>iterator_traits<InputIterator>::value_type</tt> shall denote an integral type.
+</p>
+<p>
+-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
+<tt>[begin,end)</tt> of w-bit quantities into 32-bit units, as if by the following: </del>
+</p>
+<p>
+<del>First extract the rightmost <tt>u</tt> bits from each of the <tt>n = end
+- begin</tt> elements of the supplied sequence and concatenate all the
+extracted bits to initialize a single (possibly very large) unsigned
+binary number, <tt>b = ∑<sup>n-1</sup><sub>i=0</sub> (begin[i]
+mod 2<sup>u</sup>) · 2<sup>w·i</sup></tt> (in which the bits of each <tt>begin[i]</tt>
+are treated as denoting an unsigned quantity). Then carry out
+the following algorithm:</del>
+</p>
+<blockquote><pre><del>
+v.clear();
+if ($w$ < 32)
+ v.push_back($n$);
+for( ; $n$ > 0; --$n$)
+ v.push_back(b mod 2<sup>32</sup>), b /= 2<sup>32</sup>;
+</del></pre></blockquote>
+<blockquote>
+<pre><ins>
+for (InputIterator s = begin; s != end; ++s)
+ v.push_back((*s) mod 2<sup>32</sup>);
+</ins></pre>
+</blockquote>
+</blockquote>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="804"></a>804. Some problems with classes <tt>error_code</tt>/<tt>error_condition</tt></h3>
+<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>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-02-24</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<ol type="A">
+<li>
+<p>
+19.4.2.1 [syserr.errcode.overview]/1, class <tt>error_code</tt> and
+19.4.3.1 [syserr.errcondition.overview]/, class <tt>error_condition</tt> synopses
+declare an expository data member <tt>cat_</tt>:
+</p>
+<blockquote><pre>const error_category& cat_; // exposition only
+</pre></blockquote>
+<p>
+which is used to define the semantics of several members. The decision
+to use a member of reference type lead to several problems:
+</p>
+<ol>
+<li>
+The classes are not <tt>(Copy)Assignable</tt>, which is probably not the intent.
+</li>
+<li>
+The post conditions of all modifiers from
+19.4.2.3 [syserr.errcode.modifiers] and 19.4.3.3 [syserr.errcondition.modifiers], resp.,
+cannot be fulfilled.
+</li>
+</ol>
+<p>
+The simple fix would be to replace the reference by a pointer member.
+</p>
+</li>
+
+<li>
+I would like to give the editorial remark that in both classes the
+constrained <tt>operator=</tt>
+overload (template with <tt>ErrorCodeEnum</tt> argument) makes in invalid
+usage of <tt>std::enable_if</tt>: By using the default value for the second <tt>enable_if</tt>
+parameter the return type would be defined to be <tt>void&</tt> even in otherwise
+valid circumstances - this return type must be explicitly provided (In
+<tt>error_condition</tt> the first declaration uses an explicit value, but of wrong
+type).
+</li>
+
+<li>
+The member function <tt>message</tt> throws clauses (
+19.4.1.2 [syserr.errcat.virtuals]/10, 19.4.2.4 [syserr.errcode.observers]/8, and
+19.4.3.4 [syserr.errcondition.observers]/6) guarantee "throws nothing",
+although
+they return a <tt>std::string</tt> by value, which might throw in out-of-memory
+conditions (see related issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>).
+</li>
+</ol>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+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>.
+</p>
+<p>
+Part B: Technically correct, save for typo. Rendered moot by the concept proposal
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2620.html">N2620</a>) NAD (editorial).
+</p>
+<p>
+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>.
+</p>
+<p>
+Howard: please ping Beman, asking him to clear away parts A and B from
+the wording in the proposed resolution, so it is clear to the editor
+what needs to be applied to the working paper.
+</p>
+<p>
+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
+forward, the provided wording includes resolution of part A.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+Resolution of part A:
+</p>
+<blockquote>
+<p>
+Change 19.4.2.1 [syserr.errcode.overview] Class error_code overview synopsis as indicated:
+</p>
+
+<blockquote><pre>private:
+ int val_; // exposition only
+ const error_category<del>&</del><ins>*</ins> cat_; // exposition only
+</pre></blockquote>
+
+<p>
+Change 19.4.2.2 [syserr.errcode.constructors] Class error_code constructors as indicated:
+</p>
+
+<blockquote>
+<pre>error_code();
+</pre>
+<blockquote>
+<p>
+<i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
+</p>
+<p>
+<i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&</ins>system_category</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+<pre>error_code(int val, const error_category& cat);
+</pre>
+<blockquote>
+<p>
+<i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
+</p>
+<p>
+<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&</ins>cat</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+Change 19.4.2.3 [syserr.errcode.modifiers] Class error_code modifiers as indicated:
+</p>
+
+<blockquote>
+<pre>void assign(int val, const error_category& cat);
+</pre>
+<blockquote>
+<p>
+<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&</ins>cat</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+Change 19.4.2.4 [syserr.errcode.observers] Class error_code observers as indicated:
+</p>
+
+<blockquote>
+const error_category& category() const;
+<blockquote>
+<p>
+<i>Returns:</i> <tt><ins>*</ins>cat_</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+Change 19.4.3.1 [syserr.errcondition.overview] Class error_condition overview synopsis as indicated:
+</p>
+
+<blockquote><pre>private:
+ int val_; // exposition only
+ const error_category<del>&</del><ins>*</ins> cat_; // exposition only
+</pre></blockquote>
+
+<p>
+Change 19.4.3.2 [syserr.errcondition.constructors] Class error_condition constructors as indicated:
+</p>
+<p><i>[
+(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
+name <tt>posix_category</tt> will have been changed to <tt>generic_category</tt>. That has
+no effect on this resolution.)
+]</i></p>
+
+
+<blockquote>
+<pre>error_condition();
+</pre>
+<blockquote>
+<p>
+<i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
+</p>
+<p>
+<i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&</ins>posix_category</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+<pre>error_condition(int val, const error_category& cat);
+</pre>
+<blockquote>
+<p>
+<i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
+</p>
+<p>
+<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&</ins>cat</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+Change 19.4.3.3 [syserr.errcondition.modifiers] Class error_condition modifiers as indicated:
+</p>
+
+<blockquote>
+void assign(int val, const error_category& cat);
+<blockquote>
+<p>
+<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&</ins>cat</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+Change 19.4.3.4 [syserr.errcondition.observers] Class error_condition observers as indicated:
+</p>
+
+<blockquote>
+const error_category& category() const;
+<blockquote>
+<p>
+<i>Returns:</i> <tt><ins>*</ins>cat_</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+</blockquote>
+</blockquote>
+
+<p>
+Resolution of part C:
+</p>
+
+<blockquote>
+
+<p>
+In 19.4.1.2 [syserr.errcat.virtuals], remove the throws clause p. 10.
+</p>
+
+<blockquote>
+<pre>virtual string message(int ev) const = 0;
+</pre>
+
+<blockquote>
+<p>
+<i>Returns:</i> A string that describes the error condition denoted by <tt>ev</tt>.
+</p>
+<p>
+<del><i>Throws:</i> Nothing.</del>
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+In 19.4.2.4 [syserr.errcode.observers], remove the throws clause p. 8.
+</p>
+
+<blockquote>
+<pre>string message() const;
+</pre>
+<blockquote>
+<p>
+<i>Returns:</i> <tt>category().message(value())</tt>.
+</p>
+<p>
+<del><i>Throws:</i> Nothing.</del>
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+In 19.4.3.4 [syserr.errcondition.observers], remove the throws clause p. 6.
+</p>
+
+<blockquote>
+<pre>string message() const;
+</pre>
+<blockquote>
+<p>
+<i>Returns:</i> <tt>category().message(value())</tt>.
+</p>
+<p>
+<del><i>Throws:</i> Nothing.</del>
+</p>
+</blockquote>
+</blockquote>
+
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="805"></a>805. <tt>posix_error::posix_errno</tt> concerns</h3>
+<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>
+ <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-02-24</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+19.4 [syserr]
+</p>
+
+<blockquote><pre>namespace posix_error {
+ enum posix_errno {
+ address_family_not_supported, // EAFNOSUPPORT
+ ...
+</pre></blockquote>
+
+<p>
+should rather use the new scoped-enum facility (7.2 [dcl.enum]),
+which would avoid the necessity for a new <tt>posix_error</tt>
+namespace, if I understand correctly.
+</p>
+
+<p><i>[
+Further discussion:
+]</i></p>
+
+
+<blockquote>
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf">N2347</a>,
+Strongly Typed Enums, since renamed Scoped Enums.
+</p>
+<p>
+Alberto Ganesh Barbati also raised this issue in private email, and also proposed the scoped-enum solution.
+</p>
+<p>
+Nick Stoughton asked in Bellevue that <tt>posix_error</tt> and <tt>posix_errno</tt> not be used as names. The LWG agreed.
+</p>
+<p>
+The wording for the Proposed resolution was provided by Beman Dawes.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change System error support 19.4 [syserr] as indicated:
+</p>
+
+<blockquote><pre><del>namespace posix_error {</del>
+ enum <del>posix_errno</del> <ins>class errc</ins> {
+ address_family_not_supported, // EAFNOSUPPORT
+ ...
+ wrong_protocol_type, // EPROTOTYPE
+ };
+<del>} // namespace posix_error</del>
+
+template <> struct is_error_condition_enum<<del>posix_error::posix_errno</del> <ins>errc</ins>>
+ : public true_type {}
+
+<del>namespace posix_error {</del>
+ error_code make_error_code(<del>posix_errno</del> <ins>errc</ins> e);
+ error_condition make_error_condition(<del>posix_errno</del> <ins>errc</ins> e);
+<del>} // namespace posix_error</del>
+</pre></blockquote>
+
+<p>
+Change System error support 19.4 [syserr] :
+</p>
+
+<blockquote>
+<del>The <tt>is_error_code_enum</tt> and <tt>is_error_condition_enum</tt> templates may be
+specialized for user-defined types to indicate that such a type is
+eligible for class <tt>error_code</tt> and class <tt>error_condition</tt> automatic
+conversions, respectively.</del>
+</blockquote>
+
+<p>
+Change System error support 19.4 [syserr] and its subsections:
+</p>
+
+<blockquote>
+<ul>
+<li>
+remove all occurrences of <tt>posix_error::</tt>
+</li>
+<li>
+change all instances of <tt>posix_errno</tt> to <tt>errc</tt>
+</li>
+<li>
+change all instances of <tt>posix_category</tt> to <tt>generic_category</tt>
+</li>
+<li>
+change all instances of <tt>get_posix_category</tt> to <tt>get_generic_category</tt>
+</li>
+</ul>
+</blockquote>
+
+<p>
+Change Error category objects 19.4.1.5 [syserr.errcat.objects], paragraph 2:
+</p>
+
+<blockquote>
+<i>Remarks:</i> The object's <tt>default_error_condition</tt> and equivalent virtual
+functions shall behave as specified for the class <tt>error_category</tt>. The
+object's name virtual function shall return a pointer to the string
+<del>"POSIX"</del> <ins>"GENERIC"</ins>.
+</blockquote>
+
+<p>
+Change 19.4.2.5 [syserr.errcode.nonmembers] Class <tt>error_code</tt> non-member functions as indicated:
+</p>
+
+<blockquote>
+<pre>error_code make_error_code(<del>posix_errno</del> <ins>errc</ins> e);
+</pre>
+
+<blockquote>
+<i>Returns:</i> <tt>error_code(<ins>static_cast<int>(</ins>e<ins>)</ins>, <del>posix</del><ins>generic</ins>_category)</tt>.
+</blockquote>
+</blockquote>
+
+<p>
+Change 19.4.3.5 [syserr.errcondition.nonmembers] Class <tt>error_condition</tt> non-member functions as indicated:
+</p>
+
+<blockquote>
+<pre>error_condition make_error_condition(<del>posix_errno</del> <ins>errc</ins> e);
+</pre>
+
+<blockquote>
+<i>Returns:</i> <tt>error_condition(<ins>static_cast<int>(</ins>e<ins>)</ins>, <del>posix</del><ins>generic</ins>_category)</tt>.
+</blockquote>
+</blockquote>
+
+
+
+<p><b>Rationale:</b></p>
+<table border="1">
+<tbody><tr>
+<th colspan="2">Names Considered</th>
+</tr>
+
+<tr>
+<td><tt>portable</tt></td>
+<td>
+Too non-specific. Did not wish to reserve such a common word in
+namespace std. Not quite the right meaning, either.
+</td>
+</tr>
+
+<tr>
+<td><tt>portable_error</tt></td>
+<td>
+Too long. Explicit qualification is always required for scoped enums, so
+a short name is desirable. Not quite the right meaning, either. May be
+misleading because <tt>*_error</tt> in the std lib is usually an exception class
+name.
+</td>
+</tr>
+
+<tr>
+<td><tt>std_error</tt></td>
+<td>
+Fairly short, yet explicit. But in fully qualified names like
+<tt>std::std_error::not_enough_memory</tt>, the std_ would be unfortunate. Not
+quite the right meaning, either. May be misleading because <tt>*_error</tt> in
+the std lib is usually an exception class name.
+</td>
+</tr>
+
+<tr>
+<td><tt>generic</tt></td>
+<td>
+Short enough. The category could be <tt>generic_category</tt>. Fully qualified
+names like <tt>std::generic::not_enough_memory</tt> read well. Reserving in
+namespace std seems dicey.
+</td>
+</tr>
+
+<tr>
+<td><tt>generic_error</tt></td>
+<td>
+Longish. The category could be <tt>generic_category</tt>. Fully qualified names
+like <tt>std::generic_error::not_enough_memory</tt> read well. Misleading because
+<tt>*_error</tt> in the std lib is usually an exception class name.
+</td>
+</tr>
+
+<tr>
+<td><tt>generic_err</tt></td>
+<td>
+A bit less longish. The category could be <tt>generic_category</tt>. Fully
+qualified names like <tt>std::generic_err::not_enough_memory</tt> read well.
+</td>
+</tr>
+
+<tr>
+<td><tt>gen_err</tt></td>
+<td>
+Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
+names like <tt>std::gen_err::not_enough_memory</tt> read well.
+</td>
+</tr>
+
+<tr>
+<td><tt>generr</tt></td>
+<td>
+Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
+names like <tt>std::generr::not_enough_memory</tt> read well.
+</td>
+</tr>
+
+<tr>
+<td><tt>error</tt></td>
+<td>
+Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
+names like <tt>std::error::not_enough_memory</tt> read well. Do we want to use
+this general a name?
+</td>
+</tr>
+
+<tr>
+<td><tt>err</tt></td>
+<td>
+Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
+names like <tt>std::err::not_enough_memory</tt> read well. Although alone it
+looks odd as a name, given the existing <tt>errno</tt> and <tt>namespace std</tt> names,
+it seems fairly intuitive.
+Problem: <tt>err</tt> is used throughout the standard library as an argument name
+and in examples as a variable name; it seems too confusing to add yet
+another use of the name.
+</td>
+</tr>
+
+<tr>
+<td><tt>errc</tt></td>
+<td>
+Short enough. The "c" stands for "constant". The category could be
+<tt>generic_category</tt>. Fully qualified names like
+<tt>std::errc::not_enough_memory</tt> read well. Although alone it looks odd as a
+name, given the existing <tt>errno</tt> and <tt>namespace std</tt> names, it seems fairly
+intuitive. There are no uses of <tt>errc</tt> in the current C++ standard.
+</td>
+</tr>
+</tbody></table>
+
+
+
+
+
+<hr>
+<h3><a name="806"></a>806. <tt>unique_ptr::reset</tt> effects incorrect, too permissive</h3>
+<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>
+ <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-03-13</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+<tt>void unique_ptr::reset(T* p = 0)</tt> is currently specified as:
+</p>
+
+<blockquote>
+<i>Effects:</i> If <tt>p == get()</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
+</blockquote>
+
+<p>
+There are two problems with this. One, if <tt>get() == 0</tt> and <tt>p != 0</tt>, the
+deleter is called with a NULL pointer, and this is probably not what's
+intended (the destructor avoids calling the deleter with 0.)
+</p>
+
+<p>
+Two, the special check for <tt>get() == p</tt> is generally not needed and such a
+situation usually indicates an error in the client code, which is being
+masked. As a data point, <tt>boost::shared_ptr</tt> was changed to assert on such
+self-resets in 2001 and there were no complaints.
+</p>
+
+<p>
+One might think that self-resets are necessary for operator= to work; it's specified to perform
+</p>
+
+<blockquote><pre>reset( u.release() );
+</pre></blockquote>
+
+<p>
+and the self-assignment
+</p>
+
+<blockquote><pre>p = move(p);
+</pre></blockquote>
+
+<p>
+might appear to result in a self-reset. But it doesn't; the <tt>release()</tt> is
+performed first, zeroing the stored pointer. In other words, <tt>p.reset(
+q.release() )</tt> works even when <tt>p</tt> and <tt>q</tt> are the same <tt>unique_ptr</tt>, and there
+is no need to special-case <tt>p.reset( q.get() )</tt> to work in a similar
+scenario, as it definitely doesn't when <tt>p</tt> and <tt>q</tt> are separate.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+Change 20.7.11.2.5 [unique.ptr.single.modifiers]:
+</p>
+
+<blockquote>
+<pre>void reset(T* p = 0);
+</pre>
+<blockquote>
+-4- <i>Effects:</i> If <tt><del>p ==</del> get()<ins> == 0</ins></tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
+</blockquote>
+</blockquote>
+
+<p>
+Change 20.7.11.3.3 [unique.ptr.runtime.modifiers]:
+</p>
+
+<blockquote>
+<pre>void reset(T* p = 0);
+</pre>
+<blockquote>
+<p>...</p>
+<p>
+-2- <i>Effects:</i> If <tt><del>p ==</del> get()<ins> == 0</ins></tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="807"></a>807. <tt>tuple</tt> construction should not fail unless its element's construction fails</h3>
+<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>
+ <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-03-13</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+<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
+should be added to <tt>tuple</tt> except it ought to take into account move constructors as well.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add to 20.4.1.2 [tuple.cnstr]:
+</p>
+
+<blockquote>
+<p>
+For each <tt>tuple</tt> constructor and assignment operator, an exception is thrown only if the construction
+or assignment of one of the types in <tt>Types</tt> throws an exception.
+</p>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="808"></a>808. [forward] incorrect redundant specification</h3>
+<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>
+ <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-03-13</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+p4 (forward) says:
+</p>
+<blockquote>
+<i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue.
+</blockquote>
+
+<p>
+First of all, lvalue-ness and rvalue-ness are properties of an expression,
+not of a type (see 3.10 [basic.lval]). Thus, the phrasing "Return type" is wrong.
+Second, the phrase says exactly what the core language wording says for
+folding references in 14.3.1 [temp.arg.type]/p4 and for function return values
+in 5.2.2 [expr.call]/p10. (If we feel the wording should be retained, it should
+at most be a note with cross-references to those sections.)
+</p>
+<p>
+The prose after the example talks about "forwarding as an <tt>int&</tt> (an lvalue)" etc.
+In my opinion, this is a category error: "<tt>int&</tt>" is a type, "lvalue" is a
+property of an expression, orthogonal to its type. (Btw, expressions cannot
+have reference type, ever.)
+</p>
+<p>
+Similar with move:
+</p>
+<blockquote>
+Return type: an rvalue.
+</blockquote>
+<p>
+is just wrong and also redundant.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.2.2 [forward] as indicated:
+</p>
+
+<blockquote>
+<pre>template <class T> T&& forward(typename identity<T>::type&& t);
+</pre>
+
+<blockquote>
+<p>...</p>
+<p>
+<del><i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue.</del>
+</p>
+<p>...</p>
+<p>
+-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
+as <del>an <tt>int&&</tt> (</del>an rvalue<del>)</del>. In the second call to factory, <tt>A1</tt> is deduced
+as <tt>int&</tt>, so <tt>i</tt> is forwarded to <tt>A</tt>'s constructor as <del>an <tt>int&</tt> (</del>an lvalue<del>)</del>.
+In both cases, <tt>A2</tt> is deduced as double, so 1.414 is forwarded to <tt>A</tt>'s constructor as
+<del><tt>double&&</tt> (</del>an rvalue<del>)</del>.
+</p>
+</blockquote>
+
+<pre>template <class T> typename remove_reference<T>::type&& move(T&& t);
+</pre>
+
+<blockquote>
+<p>...</p>
+<p>
+<del><i>Return type:</i> an rvalue.</del>
+</p>
+</blockquote>
+
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="809"></a>809. std::swap should be overloaded for array types</h3>
+<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>
+ <b>Submitter:</b> Niels Dekker <b>Date:</b> 2008-02-28</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+For the sake of generic programming, the header <code><algorithm></code> should provide an
+overload of <code>std::swap</code> for array types:
+</p><pre>template<class T, size_t N> void swap(T (&a)[N], T (&b)[N]);
+</pre>
+
+
+<p>
+It became apparent to me that this overload is missing, when I considered how to write a swap
+function for a generic wrapper class template.
+(Actually I was thinking of Boost's <a href="http://www.boost.org/libs/utility/value_init.htm">value_initialized</a>.)
+Please look at the following template, <code>W</code>, and suppose that is intended to be a very
+<em>generic</em> wrapper:
+</p><pre>template<class T> class W {
+public:
+ T data;
+};
+</pre>
+Clearly <code>W<T></code> is <em>CopyConstructible and CopyAssignable</em>, and therefore
+<em>Swappable</em>, whenever <code>T</code> is <em>CopyConstructible and CopyAssignable</em>.
+Moreover, <code>W<T></code> is <em>also</em> Swappable when <code>T</code> is an array type
+whose element type is CopyConstructible and CopyAssignable.
+Still it is recommended to add a <em>custom</em> swap function template to such a class template,
+for the sake of efficiency and exception safety.
+(E.g., <em>Scott Meyers, Effective C++, Third Edition, item 25: Consider support for a non-throwing
+swap</em>.)
+This function template is typically written as follows:
+<pre>template<class T> void swap(W<T>& x, W<T>& y) {
+ using std::swap;
+ swap(x.data, y.data);
+}
+</pre>
+Unfortunately, this will introduce an undesirable inconsistency, when <code>T</code> is an array.
+For instance, <code>W<std::string[8]></code> is Swappable, but the current Standard does not
+allow calling the custom swap function that was especially written for <code>W</code>!
+<pre>W<std::string[8]> w1, w2; // Two objects of a Swappable type.
+std::swap(w1, w2); // Well-defined, but inefficient.
+using std::swap;
+swap(w1, w2); // Ill-formed, just because ADL finds W's swap function!!!
+</pre>
+
+<code>W</code>'s <code>swap</code> function would try to call <code>std::swap</code> for an array,
+<code>std::string[8]</code>, which is not supported by the Standard Library.
+This issue is easily solved by providing an overload of <code>std::swap</code> for array types.
+This swap function should be implemented in terms of swapping the elements of the arrays, so that
+it would be non-throwing for arrays whose element types have a non-throwing swap.
+
+
+<p>
+Note that such an overload of <code>std::swap</code> should also support <em>multi-dimensional</em>
+arrays. Fortunately that isn't really an issue, because it would do so <i>automatically</i>, by
+means of recursion.
+</p>
+
+<p>
+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
+Library] Shouldn't std::swap be overloaded for C-style arrays?</a>
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add an extra condition to the definition of Swappable requirements [swappable] in 20.1.1 [utility.arg.requirements]:
+</p>
+<blockquote>
+- <tt>T</tt> is <tt>Swappable</tt> if <tt>T</tt> is an array type whose element type is <tt>Swappable</tt>.
+</blockquote>
+<p>
+Add the following to 25.2.3 [alg.swap]:
+</p>
+<blockquote>
+<pre>template<class T, size_t N> void swap(T (&a)[N], T (&b)[N]);
+</pre>
+<blockquote>
+<i>Requires:</i> Type <code>T</code> shall be <tt>Swappable</tt>.
+</blockquote>
+<blockquote>
+<i>Effects:</i> <code>swap_ranges(a, a + N, b);</code>
+</blockquote>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="810"></a>810. Missing traits dependencies in operational semantics of extended manipulators</h3>
+<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>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-03-01</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The recent draft (as well as the original proposal n2072) uses an
+operational semantic
+for <tt>get_money</tt> ([ext.manip]/3) and <tt>put_money</tt> ([ext.manip]/5), which uses
+</p>
+
+<blockquote><pre>istreambuf_iterator<charT>
+</pre></blockquote>
+
+<p>
+and
+</p>
+
+<blockquote><pre>ostreambuf_iterator<charT>
+</pre></blockquote>
+
+<p>
+resp, instead of the iterator instances, with explicitly provided
+traits argument (The operational semantic defined by <tt>f</tt> is also traits
+dependent). This is an obvious oversight because both <tt>*stream_buf</tt>
+c'tors expect a <tt>basic_streambuf<charT,traits></tt> as argument.
+</p>
+<p>
+The same problem occurs within the <tt>get_time</tt> and <tt>put_time</tt> semantic (p.
+7 and p. 9)
+of n2071 incorporated in N2521, where additional to the problem we
+have an editorial issue in <tt>get_time</tt> (<tt>streambuf_iterator</tt> instead of
+<tt>istreambuf_iterator</tt>).
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 27.6.4 [ext.manip]/3 within function <tt>f</tt> replace the first line
+</p>
+
+<blockquote><pre>template <class charT, class traits, class moneyT>
+void f(basic_ios<charT, traits>& str, moneyT& mon, bool intl) {
+ typedef istreambuf_iterator<charT<ins>, traits</ins>> Iter;
+ ...
+</pre></blockquote>
+
+<p>
+In 27.6.4 [ext.manip]/4 remove the first template <tt>charT</tt> parameter:
+</p>
+
+<blockquote><pre>template <<del>class charT, </del>class moneyT> unspecified put_money(const moneyT& mon, bool intl = false<ins>)</ins>;
+</pre></blockquote>
+
+<p>
+In 27.6.4 [ext.manip]/5 within function <tt>f</tt> replace the first line
+</p>
+
+<blockquote><pre>template <class charT, class traits, class moneyT>
+void f(basic_ios<charT, traits>& str, const moneyT& mon, bool intl) {
+ typedef ostreambuf_iterator<charT<ins>, traits</ins>> Iter;
+ ...
+</pre></blockquote>
+
+<p>
+In 27.6.4 [ext.manip]/7 within function <tt>f</tt> replace the first line
+</p>
+
+<blockquote><pre>template <class charT, class traits>
+void f(basic_ios<charT, traits>& str, struct tm *tmb, const charT *fmt) {
+ typedef <ins>i</ins>streambuf_iterator<charT<ins>, traits</ins>> Iter;
+ ...
+</pre></blockquote>
+
+<p>
+In 27.6.4 [ext.manip]/8 add const:
+</p>
+
+<blockquote><pre>template <class charT> unspecified put_time(<ins>const</ins> struct tm *tmb, const charT *fmt);
+</pre></blockquote>
+
+<p>
+In 27.6.4 [ext.manip]/9 within function <tt>f</tt> replace the first line
+</p>
+
+<blockquote><pre>template <class charT, class traits>
+void f(basic_ios<charT, traits>& str, const struct tm *tmb, const charT *fmt) {
+ typedef ostreambuf_iterator<charT<ins>, traits</ins>> Iter;
+ ...
+</pre></blockquote>
+
+<p>
+Add to the <tt><iomanip></tt> synopsis in 27.6 [iostream.format]
+</p>
+
+<blockquote><pre>template <class moneyT> unspecified get_money(moneyT& mon, bool intl = false);
+template <class moneyT> unspecified put_money(const moneyT& mon, bool intl = false);
+template <class charT> unspecified get_time(struct tm *tmb, const charT *fmt);
+template <class charT> unspecified put_time(const struct tm *tmb, const charT *fmt);
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="811"></a>811. <tt>pair</tt> of pointers no longer works with literal 0</h3>
+<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>
+ <b>Submitter:</b> Doug Gregor <b>Date:</b> 2008-03-14</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<blockquote><pre>#include <utility>
+
+int main()
+{
+ std::pair<char *, char *> p (0,0);
+}
+</pre></blockquote>
+
+<p>
+I just got a bug report about that, because it's valid C++03, but not
+C++0x. The important realization, for me, is that the emplace
+proposal---which made <tt>push_back</tt> variadic, causing the <tt>push_back(0)</tt>
+issue---didn't cause this break in backward compatibility. The break
+actually happened when we added this pair constructor as part of adding
+rvalue references into the language, long before variadic templates or
+emplace came along:
+</p>
+
+<blockquote><pre>template<class U, class V> pair(U&& x, V&& y);
+</pre></blockquote>
+
+<p>
+Now, concepts will address this issue by constraining that <tt>pair</tt>
+constructor to only <tt>U</tt>'s and <tt>V</tt>'s that can properly construct "first" and
+"second", e.g. (from
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2322.pdf">N2322</a>):
+</p>
+
+<blockquote><pre>template<class U , class V >
+requires Constructible<T1, U&&> && Constructible<T2, V&&>
+pair(U&& x , V&& y );
+</pre></blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="812"></a>812. unsolicited multithreading considered harmful?</h3>
+<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>
+ <b>Submitter:</b> Paul McKenney <b>Date:</b> 2008-02-27</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+Multi-threading is a good thing, but unsolicited multi-threading can
+potentially be harmful. For example, <tt>sort()</tt> performance might be
+greatly increased via a multithreaded implementation. However, such
+a multithreaded implementation could result in concurrent invocations
+of the user-supplied comparator. This would in turn result in problems
+given a caching comparator that might be written for complex sort keys.
+Please note that this is not a theoretical issue, as multithreaded
+implementations of <tt>sort()</tt> already exist.
+</p>
+<p>
+Having a multithreaded <tt>sort()</tt> available is good, but it should not
+be the default for programs that are not explicitly multithreaded.
+Users should not be forced to deal with concurrency unless they have
+asked for it.
+</p>
+
+<p><i>[
+This may be covered by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2410.html">N2410</a>
+Thread-Safety in the Standard Library (Rev 1).
+]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="813"></a>813. "empty" undefined for <tt>shared_ptr</tt></h3>
+<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>
+ <b>Submitter:</b> Matt Austern <b>Date:</b> 2008-02-26</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+Several places in 20.7.12.2 [util.smartptr.shared] refer to an "empty" <tt>shared_ptr</tt>.
+However, that term is nowhere defined. The closest thing we have to a
+definition is that the default constructor creates an empty <tt>shared_ptr</tt>
+and that a copy of a default-constructed <tt>shared_ptr</tt> is empty. Are any
+other <tt>shared_ptr</tt>s empty? For example, is <tt>shared_ptr((T*) 0)</tt> empty? What
+are the properties of an empty <tt>shared_ptr</tt>? We should either clarify this
+term or stop using it.
+</p><p>
+</p>
+One reason it's not good enough to leave this term up to the reader's
+intuition is that, in light of
+<a href="http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2007/n2351.htm">N2351</a>
+and issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, most readers'
+intuitive understanding is likely to be wrong. Intuitively one might
+expect that an empty <tt>shared_ptr</tt> is one that doesn't store a pointer,
+but, whatever the definition is, that isn't it.
+
+
+<p><i>[
+Peter adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+Or, what is an "empty" <tt>shared_ptr</tt>?
+</p>
+
+<ul>
+<li>
+<p>
+Are any other <tt>shared_ptrs</tt> empty?
+</p>
+<p>
+Yes. Whether a given <tt>shared_ptr</tt> instance is empty or not is (*)
+completely specified by the last mutating operation on that instance.
+Give me an example and I'll tell you whether the <tt>shared_ptr</tt> is empty or
+not.
+</p>
+<blockquote>
+(*) If it isn't, this is a legitimate defect.
+</blockquote>
+</li>
+
+<li>
+<p>
+For example, is <tt>shared_ptr((T*) 0)</tt> empty?
+</p>
+<p>
+No. If it were empty, it would have a <tt>use_count()</tt> of 0, whereas it is
+specified to have an <tt>use_count()</tt> of 1.
+</p>
+</li>
+
+<li>
+<p>
+What are the properties of an empty <tt>shared_ptr</tt>?
+</p>
+<p>
+The properties of an empty <tt>shared_ptr</tt> can be derived from the
+specification. One example is that its destructor is a no-op. Another is
+that its <tt>use_count()</tt> returns 0. I can enumerate the full list if you
+really like.
+</p>
+</li>
+
+<li>
+<p>
+We should either clarify this term or stop using it.
+</p>
+<p>
+I don't agree with the imperative tone
+</p>
+<p>
+A clarification would be either a no-op - if it doesn't contradict the
+existing wording - or a big mistake if it does.
+</p>
+<p>
+I agree that a clarification that is formally a no-op may add value.
+</p>
+</li>
+
+<li>
+<p>
+However, that term is nowhere defined.
+</p>
+<p>
+Terms can be useful without a definition. Consider the following
+simplistic example. We have a type <tt>X</tt> with the following operations
+defined:
+</p>
+<blockquote><pre>X x;
+X x2(x);
+X f(X x);
+X g(X x1, X x2);
+</pre></blockquote>
+<p>
+A default-constructed value is green.<br>
+A copy has the same color as the original.<br>
+<tt>f(x)</tt> returns a red value if the argument is green, a green value otherwise.<br>
+<tt>g(x1,x2)</tt> returns a green value if the arguments are of the same color, a red value otherwise.
+</p>
+
+<p>
+Given these definitions, you can determine the color of every instance
+of type <tt>X</tt>, even if you have absolutely no idea what green and red mean.
+</p>
+
+<p>
+Green and red are "nowhere defined" and completely defined at the same time.
+</p>
+</li>
+</ul>
+
+<p>
+Alisdair's wording is fine.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Append the following sentance to 20.7.12.2 [util.smartptr.shared]
+</p>
+<blockquote>
+The <code>shared_ptr</code> class template stores a pointer, usually obtained
+via <code>new</code>. <code>shared_ptr</code> implements semantics of
+shared ownership; the last remaining owner of the pointer is responsible for
+destroying the object, or otherwise releasing the resources associated with
+the stored pointer. <ins>A <code>shared_ptr</code> object that does not own
+a pointer is said to be <i>empty</i>.</ins>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="814"></a>814. <tt>vector<bool>::swap(reference, reference)</tt> not defined</h3>
+<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>
+ <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-17</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+<tt>vector<bool>::swap(reference, reference)</tt> has no definition.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="815"></a>815. <tt>std::function</tt> and <tt>reference_closure</tt> do not use perfect forwarding</h3>
+<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>
+ <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-16</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+<tt>std::function</tt> and <tt>reference_closure</tt> should use "perfect forwarding" as
+described in the rvalue core proposal.
+</p>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+According to Doug Gregor, as far as <tt>std::function</tt> is concerned, perfect
+forwarding can not be obtained because of type erasure. Not everyone
+agreed with this diagnosis of forwarding.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<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>
+<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>
+ <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2008-02-08</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+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>
+should be nofail when <tt>f, t1, ..., tN</tt> have nofail copy ctors.
+</p>
+<p>
+However, no guarantees are provided for the copy ctor of the functor
+returned by <tt>bind()</tt>. (It's guaranteed to have a copy ctor, which can
+throw implementation-defined exceptions: <tt>bind()</tt> returns a forwarding
+call wrapper, TR1 3.6.3/2. A forwarding call wrapper is a call wrapper,
+TR1 3.3/4. Every call wrapper shall be CopyConstructible, TR1 3.3/4.
+Everything without an exception-specification may throw
+implementation-defined exceptions unless otherwise specified, C++03
+17.4.4.8/3.)
+</p>
+<p>
+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
+to cover both calling <tt>bind()</tt> and copying the returned functor?
+</p>
+
+<p><i>[
+Howard adds:
+]</i></p>
+
+
+<blockquote>
+<tt>tuple</tt> construction should probably have a similar guarantee.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="817"></a>817. <tt>bind</tt> needs to be moved</h3>
+<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>
+ <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-03-17</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The functor retureed by <tt>bind()</tt> should have a move constructor that
+requires only move construction of its contained functor and bound arguments.
+That way move-only functors can be passed to objects such as <tt>thread</tt>.
+</p>
+<p>
+This issue is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="818"></a>818. wording for memory ordering</h3>
+<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>
+ <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-03-22</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+29.1 [atomics.order] p1 says in the table that
+</p>
+
+<blockquote>
+<table border="1">
+<tbody><tr>
+<th>Element</th><th>Meaning</th>
+</tr>
+<tr>
+<td><tt>memory_order_acq_rel</tt></td>
+<td>the operation has both acquire and release semantics</td>
+</tr>
+</tbody></table>
+</blockquote>
+
+<p>
+To my naked eye, that seems to imply that even an atomic read has both
+acquire and release semantics.
+</p>
+
+<p>
+Then, p1 says in the table:
+</p>
+
+<blockquote>
+<table border="1">
+<tbody><tr>
+<th>Element</th><th>Meaning</th>
+</tr>
+<tr>
+<td><tt>memory_order_seq_cst</tt></td>
+<td>the operation has both acquire and release semantics,
+ and, in addition, has sequentially-consistent operation ordering</td>
+</tr>
+</tbody></table>
+</blockquote>
+
+<p>
+So that seems to be "the same thing" as <tt>memory_order_acq_rel</tt>, with additional
+constraints.
+</p>
+
+<p>
+I'm then reading p2, where it says:
+</p>
+
+<blockquote>
+The <tt>memory_order_seq_cst</tt> operations that load a value are acquire operations
+on the affected locations. The <tt>memory_order_seq_cst</tt> operations that store a value
+are release operations on the affected locations.
+</blockquote>
+
+<p>
+That seems to imply that atomic reads only have acquire semantics. If that
+is intended, does this also apply to <tt>memory_order_acq_rel</tt> and the individual
+load/store operations as well?
+</p>
+
+<p>
+Also, the table in p1 contains phrases with "thus" that seem to indicate
+consequences of normative wording in 1.10 [intro.multithread]. That shouldn't be in
+normative text, for the fear of redundant or inconsistent specification with
+the other normative text.
+</p>
+
+<p>
+Double-check 29.4 [atomics.types.operations] that each
+operation clearly says whether it's a load or a store operation, or
+both. (It could be clearer, IMO. Solution not in current proposed resolution.)
+</p>
+
+<p>
+29.1 [atomics.order] p2: What's a "consistent execution"? It's not defined in
+1.10 [intro.multithread], it's just used in notes there.
+</p>
+
+<p>
+And why does 29.4 [atomics.types.operations] p9 for "load" say:
+</p>
+
+
+<blockquote>
+<i>Requires:</i> The order argument shall not be <tt>memory_order_acquire</tt>
+nor <tt>memory_order_acq_rel</tt>.
+</blockquote>
+
+<p>
+(Since this is exactly the same restriction as for "store", it seems to be a typo.)
+</p>
+
+<p>
+And then: 29.4 [atomics.types.operations] p12:
+</p>
+
+<blockquote>
+These operations are read-modify-write operations in the sense of the
+"synchronizes with" definition (1.10 [intro.multithread]), so both such an operation and the
+evaluation that produced the input value synchronize with any evaluation
+that reads the updated value.
+</blockquote>
+
+<p>
+This is redundant with 1.10 [intro.multithread], see above for the reasoning.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Replace the cross-reference in p1 to refer to 1.1 [intro.scope] instead of
+1.7 [intro.memory].
+Rephrase the table in as follows (maybe don't use a table):
+</p>
+
+<blockquote>
+<p>
+For <tt>memory_order_relaxed</tt>, no operation orders memory.
+</p>
+
+<p>
+For <tt>memory_order_release</tt>, <tt>memory_order_acq_rel</tt>, and <tt>memory_order_seq_cst</tt>,
+a store operation performs a release operation on the affected memory location.
+</p>
+
+<p>
+For <tt>memory_order_acquire</tt>, <tt>memory_order_acq_rel</tt>, and <tt>memory_order_seq_cst</tt>,
+a load operation performs an acquire operation on the affected memory location.
+</p>
+</blockquote>
+
+<p>
+Rephrase 29.1 [atomics.order] p2:
+</p>
+
+<blockquote>
+<del>The <tt>memory_order_seq_cst</tt> operations that load a value are
+acquire operations on the affected locations. The
+<tt>memory_order_seq_cst</tt> operations that store a value are release
+operations on the affected locations.</del>
+<del>In addition, in a consistent
+execution, t</del><ins>T</ins>here <del>must be</del> <ins>is</ins> a single
+total order <tt>S</tt> on all
+<tt>memory_order_seq_cst</tt> operations, consistent with the happens before
+order and modification orders for all affected locations, such that each
+<tt>memory_order_seq_cst</tt> operation observes either the last preceding
+modification according to this order <tt>S</tt>, or the result of an operation
+that is not <tt>memory_order_seq_cst</tt>. [<i>Note:</i> Although it is not explicitly
+required that <tt>S</tt> include locks, it can always be extended to an order
+that does include lock and unlock operations, since the ordering between
+those is already included in the happens before ordering. <i>-- end note</i>]
+</blockquote>
+
+<p>
+Rephrase 29.4 [atomics.types.operations] p12 as:
+</p>
+
+<blockquote>
+<i>Effects:</i> Atomically replaces the value pointed to by object or by
+this with desired. Memory is affected according to the value of order.
+These operations are read-modify-write operations <del>in the sense of the
+"synchronizes with" definition</del> (1.10 [intro.multithread])<del>, so both such an operation and the
+evaluation that produced the input value synchronize with any evaluation
+that reads the updated value</del>.
+</blockquote>
+
+<p>
+Same in p15, p20, p22.
+</p>
+
+
+
+
+
+
+<hr>
+<h3><a name="819"></a>819. rethrow_if_nested</h3>
+<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>
+ <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-25</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+Looking at the wording I submitted for <tt>rethrow_if_nested</tt>, I don't think I
+got it quite right.
+</p>
+
+<p>
+The current wording says:
+</p>
+
+<blockquote>
+<pre>template <class E> void rethrow_if_nested(const E& e);
+</pre>
+<blockquote>
+<p>
+<i>Effects:</i> Calls <tt>e.rethrow_nested()</tt> only if <tt>e</tt>
+is publicly derived from <tt>nested_exception</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+This is trying to be a bit subtle, by requiring <tt>e</tt> (not <tt>E</tt>) to be publicly
+derived from <tt>nested_exception</tt> the idea is that a <tt>dynamic_cast</tt> would be
+required to be sure. Unfortunately, if <tt>e</tt> is dynamically but not statically
+derived from <tt>nested_exception</tt>, <tt>e.rethrow_nested()</tt> is ill-formed.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="820"></a>820. <tt>current_exception()</tt>'s interaction with throwing copy ctors</h3>
+<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>
+ <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2008-03-26</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+As of N2521, the Working Paper appears to be silent about what
+<tt>current_exception()</tt> should do if it tries to copy the currently handled
+exception and its copy constructor throws. 18.7.5 [propagation]/7 says "If the
+function needs to allocate memory and the attempt fails, it returns an
+<tt>exception_ptr</tt> object that refers to an instance of <tt>bad_alloc</tt>.", but
+doesn't say anything about what should happen if memory allocation
+succeeds but the actual copying fails.
+</p>
+
+<p>
+I see three alternatives: (1) return an <tt>exception_ptr</tt> object that refers
+to an instance of some fixed exception type, (2) return an <tt>exception_ptr</tt>
+object that refers to an instance of the copy ctor's thrown exception
+(but if that has a throwing copy ctor, an infinite loop can occur), or
+(3) call <tt>terminate()</tt>.
+</p>
+
+<p>
+I believe that <tt>terminate()</tt> is the most reasonable course of action, but
+before we go implement that, I wanted to raise this issue.
+</p>
+
+<p><i>[
+Peter's summary:
+]</i></p>
+
+
+<blockquote>
+<p>
+The current practice is to not have throwing copy constructors in
+exception classes, because this can lead to <tt>terminate()</tt> as described in
+15.5.1 [except.terminate]. Thus calling <tt>terminate()</tt> in this situation seems
+consistent and does not introduce any new problems.
+</p>
+
+<p>
+However, the resolution of core issue 475 may relax this requirement:
+</p>
+
+<blockquote>
+The CWG agreed with the position that <tt>std::uncaught_exception()</tt> should
+return <tt>false</tt> during the copy to the exception object and that <tt>std::terminate()</tt>
+should not be called if that constructor exits with an exception.
+</blockquote>
+
+<p>
+Since throwing copy constructors will no longer call <tt>terminate()</tt>, option
+(3) doesn't seem reasonable as it is deemed too drastic a response in a
+recoverable situation.
+</p>
+
+<p>
+Option (2) cannot be adopted by itself, because a potential infinite
+recursion will need to be terminated by one of the other options.
+</p>
+
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the following paragraph after 18.7.5 [propagation]/7:
+</p>
+
+<blockquote>
+<p>
+<i>Returns (continued):</i> If the attempt to copy the current exception
+object throws an exception, the function returns an <tt>exception_ptr</tt> that
+refers to the thrown exception or, if this is not possible, to an
+instance of <tt>bad_exception</tt>.
+</p>
+<p>
+[<i>Note:</i> The copy constructor of the thrown exception may also fail, so
+the implementation is allowed to substitute a <tt>bad_exception</tt> to avoid
+infinite recursion. <i>-- end note.</i>]
+</p>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="821"></a>821. Minor cleanup : <tt>unique_ptr</tt></h3>
+<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>
+ <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-30</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+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:
+</p>
+
+<blockquote>
+<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
+</pre>
+
+<p>
+-1- <i>Requires:</i> Does not accept pointer types which are convertible
+to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (diagnostic
+required). [<i>Note:</i> One implementation technique is to create a private
+templated overload. <i>-- end note</i>]
+</p>
+</blockquote>
+
+<p>
+This could be cleaned up by mandating the overload as a public deleted
+function. In addition, we should probably overload <tt>reset</tt> on <tt>nullptr_t</tt>
+to be a stronger match than the deleted overload. Words...
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add to class template definition in 20.7.11.3 [unique.ptr.runtime]
+</p>
+
+<blockquote>
+<pre>// modifiers
+T* release();
+void reset(T* p = 0);
+<ins>void reset( nullptr_t );</ins>
+<ins>template< typename T > void reset( T ) = delete;</ins>
+void swap(unique_ptr&& u);
+</pre>
+</blockquote>
+
+<p>
+Update 20.7.11.3.3 [unique.ptr.runtime.modifiers]
+</p>
+
+<blockquote>
+<pre>void reset(pointer p = pointer());
+<ins>void reset(nullptr_t);</ins>
+</pre>
+
+<p>
+<del>-1- <i>Requires:</i> Does not accept pointer types which are convertible
+to <tt>pointer</tt> (diagnostic
+required). [<i>Note:</i> One implementation technique is to create a private
+templated overload. <i>-- end note</i>]</del>
+</p>
+<p>
+<i>Effects:</i> If <tt>get() == nullptr</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
+</p>
+<p>...</p>
+</blockquote>
+
+<p><i>[
+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).
+]</i></p>
+
+
+
+
+
+
+<hr>
+<h3><a name="822"></a>822. Object with explicit copy constructor no longer <tt>CopyConstructible</tt></h3>
+<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>
+ <b>Submitter:</b> James Kanze <b>Date:</b> 2008-04-01</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+I just noticed that the following program is legal in C++03, but
+is forbidden in the current draft:
+</p>
+
+<blockquote><pre>#include <vector>
+#include <iostream>
+
+class Toto
+{
+public:
+ Toto() {}
+ explicit Toto( Toto const& ) {}
+} ;
+
+int
+main()
+{
+ std::vector< Toto > v( 10 ) ;
+ return 0 ;
+}
+</pre></blockquote>
+
+<p>
+Is this change intentional? (And if so, what is the
+justification? I wouldn't call such code good, but I don't see
+any reason to break it unless we get something else in return.)
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 20.1.1 [utility.arg.requirements] change Table 33: <tt>MoveConstructible</tt> requirements [moveconstructible]:
+</p>
+
+<blockquote>
+<table border="1">
+<tbody><tr>
+<th>expression</th><th>post-condition</th>
+</tr>
+<tr>
+<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>
+</tr>
+<tr>
+<td colspan="2" align="center">...</td>
+</tr>
+</tbody></table>
+</blockquote>
+
+<p>
+In 20.1.1 [utility.arg.requirements] change Table 34: <tt>CopyConstructible</tt> requirements [copyconstructible]:
+</p>
+
+<blockquote>
+<table border="1">
+<tbody><tr>
+<th>expression</th><th>post-condition</th>
+</tr>
+<tr>
+<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>
+</tr>
+<tr>
+<td colspan="2" align="center">...</td>
+</tr>
+</tbody></table>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="823"></a>823. <tt>identity<void></tt> seems broken</h3>
+<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>
+ <b>Submitter:</b> Walter Brown <b>Date:</b> 2008-04-09</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+N2588 seems to have added an <tt>operator()</tt> member function to the
+<tt>identity<></tt> helper in 20.2.2 [forward]. I believe this change makes it no
+longer possible to instantiate <tt>identity<void></tt>, as it would require
+forming a reference-to-<tt>void</tt> type as this <tt>operator()</tt>'s parameter type.
+</p>
+
+<p>
+Suggested resolution: Specialize <tt>identity<void></tt> so as not to require
+the member function's presence.
+</p>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+Jens: suggests to add a requires clause to avoid specializing on <tt>void</tt>.
+</p>
+<p>
+Alisdair: also consider cv-qualified <tt>void</tt>.
+</p>
+<p>
+Alberto provided proposed wording.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change definition of <tt>identity</tt> in 20.2.2 [forward], paragraph 2, to:
+</p>
+
+<blockquote><pre>template <class T> struct identity {
+ typedef T type;
+
+ <ins>requires ReferentType<T></ins>
+ const T& operator()(const T& x) const;
+ };
+</pre></blockquote>
+<p>...</p>
+<blockquote><pre> <ins>requires ReferentType<T></ins>
+ const T& operator()(const T& x) const;
+</pre></blockquote>
+
+
+<p><b>Rationale:</b></p>
+<p>
+The point here is to able to write <tt>T&</tt> given <tt>T</tt> and <tt>ReferentType</tt> is
+precisely the concept that guarantees so, according to N2677
+(Foundational concepts). Because of this, it seems preferable than an
+explicit check for <tt>cv void</tt> using <tt>SameType/remove_cv</tt> as it was suggested
+in Sophia. In particular, Daniel remarked that there may be types other
+than <tt>cv void</tt> which aren't referent types (<tt>int[]</tt>, perhaps?).
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="824"></a>824. rvalue ref issue with <tt>basic_string</tt> inserter</h3>
+<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>
+ <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-04-10</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+In the current working paper, the <tt><string></tt> header synopsis at the end of
+21.2 [string.classes] lists a single <tt>operator<<</tt> overload
+for <tt>basic_string</tt>.
+</p>
+
+<blockquote><pre>template<class charT, class traits, class Allocator>
+ basic_ostream<charT, traits>&
+ operator<<(basic_ostream<charT, traits>&& os,
+ const basic_string<charT,traits,Allocator>& str);
+</pre></blockquote>
+
+<p>
+The definition in 21.3.8.9 [string.io] lists two:
+</p>
+
+<blockquote><pre>template<class charT, class traits, class Allocator>
+ basic_ostream<charT, traits>&
+ operator<<(basic_ostream<charT, traits>& os,
+ const basic_string<charT,traits,Allocator>& str);
+
+template<class charT, class traits, class Allocator>
+ basic_ostream<charT, traits>&
+ operator<<(basic_ostream<charT, traits>&& os,
+ const basic_string<charT,traits,Allocator>& str);
+</pre></blockquote>
+
+<p>
+I believe the synopsis in 21.2 [string.classes] is correct, and the first of the two
+signatures in 21.3.8.9 [string.io] should be deleted.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Delete the first of the two signatures in 21.3.8.9 [string.io]:
+</p>
+
+<blockquote><pre><del>template<class charT, class traits, class Allocator>
+ basic_ostream<charT, traits>&
+ operator<<(basic_ostream<charT, traits>& os,
+ const basic_string<charT,traits,Allocator>& str);</del>
+
+template<class charT, class traits, class Allocator>
+ basic_ostream<charT, traits>&
+ operator<<(basic_ostream<charT, traits>&& os,
+ const basic_string<charT,traits,Allocator>& str);
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="825"></a>825. Missing rvalues reference stream insert/extract operators?</h3>
+<p><b>Section:</b> 19.4.2.1 [syserr.errcode.overview], 20.7.12.2.8
+[util.smartptr.shared.io], 22.2.8 [facets.examples], 23.3.5.3
+[bitset.operators], 26.3.6 [complex.ops], 27.5 [stream.buffers], 28.9
+[re.submatch] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-04-10</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+Should the following use rvalues references to stream in insert/extract
+operators?
+</p>
+
+<ul>
+<li>19.4.2.1 [syserr.errcode.overview]</li>
+<li>20.7.12.2.8 [util.smartptr.shared.io]</li>
+<li>22.2.8 [facets.examples]</li>
+<li>23.3.5.3 [bitset.operators]</li>
+<li>26.3.6 [complex.ops]</li>
+<li>Doubled signatures in 27.5 [stream.buffers] for character inserters
+(ref 27.6.2.6.4 [ostream.inserters.character])
++ definition 27.6.2.6.4 [ostream.inserters.character]</li>
+<li>28.9 [re.submatch]</li>
+</ul>
+
+<p><i>[
+Sophia Antipolis
+]</i></p>
+
+
+<blockquote>
+Agree with the idea in the issue, Alisdair to provide wording.
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="827"></a>827. <tt>constexpr shared_ptr::shared_ptr()?</tt></h3>
+<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>
+ <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-04-11</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+Would anyone object to making the default constructor of <tt>shared_ptr</tt> (and
+<tt>weak_ptr</tt> and <tt>enable_shared_from_this) constexpr</tt>? This would enable
+static initialization for <tt>shared_ptr</tt> variables, eliminating another
+unfair advantage of raw pointers.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="828"></a>828. Static initialization for <tt>std::mutex</tt>?</h3>
+<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>
+ <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-04-18</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+[Note: I'm assuming here that 3.6.2 [basic.start.init]/1 will be fixed.]
+</p>
+<p>
+Currently <tt>std::mutex</tt> doesn't support static initialization. This is a
+regression with respect to <tt>pthread_mutex_t</tt>, which does. I believe that
+we should strive to eliminate such regressions in expressive power where
+possible, both to ease migration and to not provide incentives to (or
+force) people to forego the C++ primitives in favor of pthreads.
+</p>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+We believe this is implementable on POSIX, because the initializer-list
+feature and the constexpr feature make this work. Double-check core
+language about static initialization for this case. Ask core for a core
+issue about order of destruction of statically-initialized objects wrt.
+dynamically-initialized objects (should come afterwards). Check
+non-POSIX systems for implementability.
+</p>
+<p>
+If ubiquitous implementability cannot be assured, plan B is to introduce
+another constructor, make this constexpr, which is
+conditionally-supported. To avod ambiguities, this new constructor needs
+to have an additional parameter.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 30.3.1.1 [thread.mutex.class]:
+</p>
+
+<blockquote><pre>class mutex {
+public:
+ <ins>constexpr</ins> mutex();
+ ...
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="829"></a>829. current_exception wording unclear about exception type</h3>
+<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>
+ <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-04-20</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>Consider this code:</p>
+
+<blockquote>
+<pre>exception_ptr xp;</pre>
+<pre>try {do_something(); }
+
+catch (const runtime_error& ) {xp = current_exception();}
+
+...
+
+rethrow_exception(xp);</pre>
+</blockquote>
+
+<p>
+Say <code>do_something()</code> throws an exception object of type <code>
+range_error</code>. What is the type of the exception object thrown by <code>
+rethrow_exception(xp)</code> above? It must have a type of <code>range_error</code>;
+if it were of type <code>runtime_error</code> it still isn't possible to
+propagate an exception and the exception_ptr/current_exception/rethrow_exception
+machinery serves no useful purpose.
+</p>
+
+<p>
+Unfortunately, the current wording does not explicitly say that. Different
+people read the current wording and come to different conclusions. While it may
+be possible to deduce the correct type from the current wording, it would be
+much clearer to come right out and explicitly say what the type of the referred
+to exception is.
+</p>
+
+<p><i>[
+Peter adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+I don't like the proposed resolution of 829. The normative text is
+unambiguous that the <tt>exception_ptr</tt> refers to the <em>currently handled
+exception</em>. This term has a standard meaning, see 15.3 [except.handle]/8; this is the
+exception that <tt>throw;</tt> would rethrow, see 15.1 [except.throw]/7.
+</p>
+<p>
+A better way to address this is to simply add the non-normative example
+in question as a clarification. The term <i>currently handled exception</i>
+should be italicized and cross-referenced. A [<i>Note:</i> the currently
+handled exception is the exception that a throw expression without an
+operand (15.1 [except.throw]/7) would rethrow. <i>--end note</i>] is also an option.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+After 18.7.5 [propagation] , paragraph 7, add the indicated text:
+</p>
+
+<blockquote>
+<pre>exception_ptr current_exception();</pre>
+
+<blockquote>
+<p>
+<i>Returns:</i> <code>exception_ptr</code> object that refers
+to the currently handled exception <ins>(15.3 [except.handle])</ins> or a copy of the currently handled
+exception, or a null <code>exception_ptr</code> object if no exception is being handled. If
+the function needs to allocate memory and the attempt fails, it returns an
+<code>exception_ptr</code> object that refers to an instance of <code>bad_alloc</code>.
+It is unspecified whether the return values of two successive calls to
+<code>current_exception</code> refer to the same exception object.
+[<i>Note:</i> that is, it
+is unspecified whether <code>current_exception</code>
+creates a new copy each time it is called.
+<i>-- end note</i>]
+</p>
+
+<p>
+<i>Throws:</i> nothing.
+</p>
+
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="830"></a>830. Incomplete list of char_traits specializations</h3>
+<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>
+ <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2008-04-23</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+ Paragraph 4 of 21.1 [char.traits] mentions that this
+ section specifies two specializations (<code>char_traits<char></code>
+ and (<code>char_traits<wchar_t></code>). However, there are actually
+ four specializations provided, i.e. in addition to the two above also
+ <code>char_traits<char16_t></code> and <code>char_traits<char32_t></code>).
+ I guess this was just an oversight and there is nothing wrong with just
+ fixing this.
+</p>
+
+<p><i>[
+Alisdair adds:
+]</i></p>
+
+<blockquote>
+<tt>char_traits< char16/32_t ></tt>
+should also be added to <tt><ios_fwd></tt> in 27.2 [iostream.forward], and all the specializations
+taking a <tt>char_traits</tt> parameter in that header.
+</blockquote>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+Idea of the issue is ok.
+</p>
+<p>
+Alisdair to provide wording, once that wording arrives, move to review.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+ Replace paragraph 4 of 21.1 [char.traits] by:
+</p>
+<blockquote>
+<p>
+ This subclause specifies a struct template, <code>char_traits<charT></code>,
+ and four explicit specializations of it, <code>char_traits<char></code>,
+ <code>char_traits<char16_t></code>, <code>char_traits<char32_t></code>, and
+ <code>char_traits<wchar_t></code>, all of which appear in the header
+ <string> and satisfy the requirements below.
+</p>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="832"></a>832. Applying constexpr to System error support</h3>
+<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>
+ <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-05-14</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+Initialization of objects of class <tt>error_code</tt>
+(19.4.2 [syserr.errcode]) and class
+<tt>error_condition</tt> (19.4.3 [syserr.errcondition]) can be made simpler and more reliable by use of
+the new <tt>constexpr</tt> feature
+[<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2349.pdf">N2349</a>]
+of C++0x. Less code will need to be
+generated for both library implementations and user programs when
+manipulating constant objects of these types.
+</p>
+
+<p>
+This was not proposed originally because the constant expressions
+proposal was moving into the standard at about the same time as the
+Diagnostics Enhancements proposal
+[<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html">N2241</a>],
+and it wasn't desirable to
+make the later depend on the former. There were also technical concerns
+as to how <tt>constexpr</tt> would apply to references. Those concerns are now
+resolved; <tt>constexpr</tt> can't be used for references, and that fact is
+reflected in the proposed resolution.
+</p>
+
+<p>
+Thanks to Jens Maurer, Gabriel Dos Reis, and Bjarne Stroustrup for clarification of <tt>constexpr</tt> requirements.
+</p>
+
+<p>
+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
+exposition only member <tt>cat_</tt> of class <tt>error_code</tt> (19.4.2 [syserr.errcode]) and class
+<tt>error_condition</tt> (19.4.3 [syserr.errcondition]) should be presented as a reference or pointer.
+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,
+presenting it as a pointer becomes more or less required with this
+proposal, given <tt>constexpr</tt> does not play well with references. The
+proposed resolution thus changes the private member to a pointer, which
+also brings it in sync with real implementations.
+</p>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+On going question of extern pointer vs. inline functions for interface.
+</blockquote>
+
+<p><i>[
+Pre-San Francisco:
+]</i></p>
+
+
+<blockquote>
+<p>
+Beman Dawes reports that this proposal is unimplementable, and thus NAD.
+</p>
+<p>
+Implementation would require <tt>constexpr</tt> objects of classes derived
+from class <tt>error_category</tt>, which has virtual functions, and that is
+not allowed by the core language. This was determined when trying to
+implement the proposal using a constexpr enabled compiler provided
+by Gabriel Dos Reis, and subsequently verified in discussions with
+Gabriel and Jens Maurer.
+</p>
+
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+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
+applied to the WP, resulting in the former <tt>posix_category</tt> being renamed
+<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
+proposal must be adjusted accordingly.
+</p>
+
+<p>
+Change 19.4.1.1 [syserr.errcat.overview] Class
+<tt>error_category</tt> overview <tt>error_category</tt> synopsis as
+indicated:
+</p>
+
+<blockquote><pre><del>const error_category& get_generic_category();</del>
+<del>const error_category& get_system_category();</del>
+
+<del>static</del> <ins>extern</ins> const error_category<del>&</del><ins>* const</ins> generic_category<del> = get_generic_category()</del>;
+<del>static</del> <ins>extern</ins> const error_category<del>&</del><ins>* const</ins> <del>native_category</del> system_category<del> = get_system_category()</del>;
+</pre></blockquote>
+
+<p>
+Change 19.4.1.5 [syserr.errcat.objects] Error category objects as indicated:
+</p>
+
+<blockquote>
+<pre><ins>extern</ins> const error_category<del>&</del><ins>* const</ins> <del>get_</del>generic_category<del>()</del>;
+</pre>
+<p>
+<del><i>Returns:</i> A reference</del> <ins><tt>generic_category</tt> shall point</ins>
+to <del>an</del> <ins>a statically initialized</ins> object of a type derived from
+class <tt>error_category</tt>.
+</p>
+
+<p>
+<del><i>Remarks:</i></del> The object's <tt>default_error_condition</tt> and <tt>equivalent</tt> virtual
+functions shall behave as specified for the class <tt>error_category</tt>. The
+object's <tt>name</tt> virtual function shall return a pointer to the string
+<tt>"GENERIC"</tt>.
+</p>
+
+<pre><ins>extern</ins> const error_category<del>&</del><ins>* const</ins> <del>get_</del>system_category<del>()</del>;
+</pre>
+
+<p>
+<del><i>Returns:</i> A reference</del> <ins><tt>system_category</tt> shall point</ins>
+to <del>an</del> <ins>a statically
+initialized</ins> object of a type derived from class <tt>error_category</tt>.
+</p>
+
+<p>
+<del><i>Remarks:</i></del> The object's <tt>equivalent</tt> virtual functions shall behave as
+specified for class <tt>error_category</tt>. The object's <tt>name</tt> virtual function
+shall return a pointer to the string <tt>"system"</tt>. The object's
+<tt>default_error_condition</tt> virtual function shall behave as follows:
+</p>
+
+<p>
+If the argument <tt>ev</tt> corresponds to a POSIX <tt>errno</tt> value <tt>posv</tt>, the function
+shall return <tt>error_condition(posv, generic_category)</tt>. Otherwise, the
+function shall return <tt>error_condition(ev, system_category)</tt>. What
+constitutes correspondence for any given operating system is
+unspecified. [<i>Note:</i> The number of potential system error codes is large
+and unbounded, and some may not correspond to any POSIX <tt>errno</tt> value.
+Thus implementations are given latitude in determining correspondence.
+<i>-- end note</i>]
+</p>
+</blockquote>
+
+<p>
+Change 19.4.2.1 [syserr.errcode.overview] Class <tt>error_code</tt> overview as indicated:
+</p>
+
+<blockquote><pre>class error_code {
+public:
+ ...;
+ <ins>constexpr</ins> error_code(int val, const error_category<del>&</del><ins>*</ins> cat);
+ ...
+ void assign(int val, const error_category<del>&</del><ins>*</ins> cat);
+ ...
+ const error_category<del>&</del><ins>*</ins> category() const;
+ ...
+private:
+ int val_; // exposition only
+ const error_category<del>&</del><ins>*</ins> cat_; // exposition only
+</pre></blockquote>
+
+<p>
+Change 19.4.2.2 [syserr.errcode.constructors] Class <tt>error_code</tt> constructors as indicated:
+</p>
+
+<blockquote>
+<pre><ins>constexpr</ins> error_code(int val, const error_category<del>&</del><ins>*</ins> cat);
+</pre>
+<p>
+<i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
+</p>
+<p>
+<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+
+<p>
+Change 19.4.2.3 [syserr.errcode.modifiers] Class <tt>error_code</tt> modifiers as indicated:
+</p>
+
+<blockquote>
+<pre>void assign(int val, const error_category<del>&</del><ins>*</ins> cat);
+</pre>
+<p>
+<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+
+<p>
+Change 19.4.2.4 [syserr.errcode.observers] Class <tt>error_code</tt> observers as indicated:
+</p>
+
+<blockquote>
+<pre>const error_category<del>&</del><ins>*</ins> category() const;
+</pre>
+
+<p>
+<i>Returns:</i> <tt>cat_</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+
+<p>
+Change 19.4.3.1 [syserr.errcondition.overview] Class <tt>error_condition</tt> overview as indicated:
+</p>
+
+<blockquote>
+<pre>class error_condition {
+public:
+ ...;
+ <ins>constexpr</ins> error_condition(int val, const error_category<del>&</del><ins>*</ins> cat);
+ ...
+ void assign(int val, const error_category<del>&</del><ins>*</ins> cat);
+ ...
+ const error_category<del>&</del><ins>*</ins> category() const;
+ ...
+private:
+ int val_; // exposition only
+ const error_category<del>&</del><ins>*</ins> cat_; // exposition only
+</pre>
+</blockquote>
+
+<p>
+Change 19.4.3.2 [syserr.errcondition.constructors] Class <tt>error_condition</tt> constructors as indicated:
+</p>
+
+<blockquote>
+<pre><ins>constexpr</ins> error_condition(int val, const error_category<del>&</del><ins>*</ins> cat);
+</pre>
+<p>
+<i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
+</p>
+<p>
+<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+
+<p>
+Change 19.4.3.3 [syserr.errcondition.modifiers] Class <tt>error_condition</tt> modifiers as indicated:
+</p>
+
+<blockquote>
+<pre>void assign(int val, const error_category<del>&</del><ins>*</ins> cat);
+</pre>
+<p>
+<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+
+<p>
+Change 19.4.3.4 [syserr.errcondition.observers] Class <tt>error_condition</tt> observers as indicated:
+</p>
+
+<blockquote>
+<pre>const error_category<del>&</del><ins>*</ins> category() const;
+</pre>
+<p>
+<i>Returns:</i> <tt>cat_</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+</blockquote>
+
+<p>
+Throughout 19.4 [syserr] System error support, change "<tt>category().</tt>" to "<tt>category()-></tt>".
+Appears approximately six times.
+</p>
+
+<p>
+<i>[Partially Editorial]</i> In 19.4.4 [syserr.compare] Comparison operators,
+paragraphs 2 and 4, change "<tt>category.equivalent(</tt>" to
+"<tt>category()->equivalent(</tt>".
+</p>
+
+<p>
+Change 19.4.5.1 [syserr.syserr.overview] Class system_error overview as indicated:
+</p>
+
+<blockquote><pre>public:
+ system_error(error_code ec, const string& what_arg);
+ system_error(error_code ec);
+ system_error(int ev, const error_category<del>&</del><ins>*</ins> ecat,
+ const string& what_arg);
+ system_error(int ev, const error_category<del>&</del><ins>*</ins> ecat);
+</pre></blockquote>
+
+<p>
+Change 19.4.5.2 [syserr.syserr.members] Class system_error members as indicated:
+</p>
+
+<blockquote>
+<pre>system_error(int ev, const error_category<del>&</del><ins>*</ins> ecat, const string& what_arg);
+</pre>
+<blockquote>
+<p>
+<i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
+</p>
+<p>
+<i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and
+<tt>strcmp(runtime_error::what(), what_arg.c_str()) == 0</tt>.
+</p>
+</blockquote>
+
+<pre>system_error(int ev, const error_category<del>&</del><ins>*</ins> ecat);
+</pre>
+<blockquote>
+<p>
+<i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
+</p>
+<p>
+<i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and
+<tt>strcmp(runtime_error::what(), "") == 0</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="833"></a>833. Freestanding implementations header list needs review for C++0x</h3>
+<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>
+ <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-05-14</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+Once the C++0x standard library is feature complete, the LWG needs to
+review 17.4.1.3 [compliance] Freestanding implementations header list to
+ensure it reflects LWG consensus.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="834"></a>834. Unique_ptr::pointer requirements underspecified</h3>
+<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>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-05-14</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+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
+extension point for <tt>unique_ptr</tt> by granting support for an optional
+<tt>deleter_type::pointer</tt> to act as pointer-like replacement for <tt>element_type*</tt>
+(In the following: <tt>pointer</tt>).
+</p>
+<p>
+Unfortunately no requirements are specified for the type <tt>pointer</tt> which has
+impact on at least two key features of <tt>unique_ptr</tt>:
+</p>
+
+<ol>
+<li>Operational fail-safety.</li>
+<li>(Well-)Definedness of expressions.</li>
+</ol>
+
+<p>
+<tt>Unique_ptr</tt> specification makes great efforts to require that essentially *all*
+operations cannot throw and therefore adds proper wording to the affected
+operations of the deleter as well. If user-provided <tt>pointer</tt>-emulating types
+("smart pointers") will be allowed, either *all* throw-nothing clauses have to
+be replaced by weaker "An exception is thrown only if <tt>pointer</tt>'s {op} throws
+an exception"-clauses or it has to be said explicitly that all used
+operations of
+<tt>pointer</tt> are required *not* to throw. I understand the main focus of <tt>unique_ptr</tt>
+to be as near as possible to the advantages of native pointers which cannot
+fail and thus strongly favor the second choice. Also, the alternative position
+would make it much harder to write safe and simple template code for
+<tt>unique_ptr</tt>. Additionally, I assume that a general statement need to be given
+that all of the expressions of <tt>pointer</tt> used to define semantics are required to
+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>).
+</p>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+Howard: We maybe need a core concept <tt>PointerLike</tt>, but we don't need the
+arithmetic (see <tt>shared_ptr</tt> vs. <tt>vector<T>::iterator</tt>.
+</p>
+<p>
+Howard will go through and enumerate the individual requirements wrt. <tt>pointer</tt> for each member function.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the following sentence just at the end of the newly proposed
+20.7.11.2 [unique.ptr.single]/p. 3:
+</p>
+
+<blockquote>
+<tt>unique_ptr<T, D>::pointer</tt>'s operations shall be well-formed, shall have well
+defined behavior, and shall not throw exceptions.
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="835"></a>835. tying two streams together (correction to DR 581)</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+ <p>
+
+The fix for
+issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>,
+now integrated into the working paper, overlooks a couple of minor
+problems.
+
+ </p>
+ <p>
+
+First, being an unformatted function once again, <code>flush()</code>
+is required to create a sentry object whose constructor must, among
+other things, flush the tied stream. When two streams are tied
+together, either directly or through another intermediate stream
+object, flushing one will also cause a call to <code>flush()</code> on
+the other tied stream(s) and vice versa, ad infinitum. The program
+below demonstrates the problem.
+
+ </p>
+ <p>
+
+Second, as Bo Persson notes in his
+comp.lang.c++.moderated <a href="http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/f2187794e9cc036d/305df31dc583054a">post</a>,
+for streams with the <code>unitbuf</code> flag set such
+as <code>std::stderr</code>, the destructor of the sentry object will
+again call <code>flush()</code>. This seems to create an infinite
+recursion for <code>std::cerr << std::flush;</code>
+
+ </p>
+ <blockquote>
+ <pre>#include <iostream>
+
+int main ()
+{
+ std::cout.tie (&std::cerr);
+ std::cerr.tie (&std::cout);
+ std::cout << "cout\n";
+ std::cerr << "cerr\n";
+}
+ </pre>
+ </blockquote>
+
+ <p><b>Proposed resolution:</b></p>
+ <p>
+
+I think an easy way to plug the first hole is to add a requires clause
+to <code>ostream::tie(ostream *tiestr)</code> requiring the this
+pointer not be equal to any pointer on the list starting
+with <code>tiestr->tie()</code>
+through <code>tiestr()->tie()->tie()</code> and so on. I am not
+proposing that we require implementations to traverse this list,
+although I think we could since the list is unlikely to be very long.
+
+ </p>
+ <p>
+
+Add a <i>Requires</i> clause to 27.4.4.2 [basic.ios.members] withethe following
+text:
+
+ </p>
+ <blockquote>
+
+<i>Requires:</i> If <code>(tiestr != 0)</code> is
+true, <code>tiestr</code> must not be reachable by traversing the
+linked list of tied stream objects starting
+from <code>tiestr->tie()</code>.
+
+ </blockquote>
+ <p>
+
+In addition, to prevent the infinite recursion that Bo writes about in
+his comp.lang.c++.moderated post, I propose to change
+27.6.2.4 [ostream::sentry], p2 like so:
+
+ </p>
+ <blockquote>
+
+If <code>((os.flags() & ios_base::unitbuf) &&
+!uncaught_exception())</code> is true,
+calls <del>os.flush()</del> <ins><code>os.rdbuf()->pubsync()</code></ins>.
+
+ </blockquote>
+
+
+
+
+<hr>
+<h3><a name="836"></a>836.
+ effects of <code>money_base::space</code> and
+ <code>money_base::none</code> on <code>money_get</code>
+ </h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
+<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>
+<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>
+<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>
+<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a></p>
+<p><b>Discussion:</b></p>
+ <p>
+
+In paragraph 2, 22.2.6.1.2 [locale.money.get.virtuals] specifies the following:
+
+ </p>
+ <blockquote>
+
+Where <code>space</code> or <code>none</code> appears in the format
+pattern, except at the end, optional white space (as recognized
+by <code>ct.is</code>) is consumed after any required space.
+
+ </blockquote>
+ <p>
+
+This requirement can be (and has been) interpreted two mutually
+exclusive ways by different readers. One possible interpretation
+is that:
+
+ </p>
+ <blockquote>
+ <ol>
+ <li>
+
+where <code>money_base::space</code> appears in the format, at least
+one space is required, and
+
+ </li>
+ <li>
+
+where <code>money_base::none</code> appears in the format, space is
+allowed but not required.
+
+ </li>
+ </ol>
+ </blockquote>
+ <p>
+
+The other is that:
+
+ </p>
+ <blockquote>
+
+where either <code>money_base::space</code> or <code>money_base::none</code> appears in the format, white space is optional.
+
+ </blockquote>
+
+
+ <p><b>Proposed resolution:</b></p>
+ <p>
+
+I propose to change the text to make it clear that the first
+interpretation is intended, that is, to make following change to
+22.2.6.1.2 [locale.money.get.virtuals], p2:
+
+ </p>
+
+ <blockquote>
+
+When <code><ins>money_base::</ins>space</code>
+or <code><ins>money_base::</ins>none</code> appears <ins>as the last
+element </ins>in the format pattern, <del>except at the end, optional
+white space (as recognized by <code>ct.is</code>) is consumed after
+any required space.</del> <ins>no white space is consumed. Otherwise,
+where <code>money_base::space</code> appears in any of the initial
+elements of the format pattern, at least one white space character is
+required. Where <code>money_base::none</code> appears in any of the
+initial elements of the format pattern, white space is allowed but not
+required. In either case, any required followed by all optional white
+space (as recognized by <code>ct.is()</code>) is consumed.</ins>
+If <code>(str.flags() & str.showbase)</code> is <code>false</code>, ...
+
+ </blockquote>
+
+
+
+
+<hr>
+<h3><a name="837"></a>837.
+ <code>basic_ios::copyfmt()</code> overly loosely specified
+ </h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+ <p>
+
+The <code>basic_ios::copyfmt()</code> member function is specified in 27.4.4.2 [basic.ios.members] to have the following effects:
+
+ </p>
+ <blockquote>
+
+<i>Effects</i>: If <code>(this == &rhs)</code> does
+nothing. Otherwise assigns to the member objects of <code>*this</code>
+the corresponding member objects of <code>rhs</code>, except that
+
+ <ul>
+ <li>
+
+<code>rdstate()</code> and <code>rdbuf()</code> are left unchanged;
+
+ </li>
+ <li>
+
+<code>exceptions()</code> is altered last by
+calling <code>exceptions(rhs.except)</code>
+
+ </li>
+ <li>
+
+the contents of arrays pointed at by <code>pword</code>
+and <code>iword</code> are copied not the pointers themselves
+
+ </li>
+ </ul>
+ </blockquote>
+ <p>
+
+Since the rest of the text doesn't specify what the member objects
+of <code>basic_ios</code> are this seems a little too loose.
+
+ </p>
+
+
+ <p><b>Proposed resolution:</b></p>
+ <p>
+
+I propose to tighten things up by adding a <i>Postcondition</i> clause
+to the function like so:
+
+ </p>
+ <blockquote>
+ <i>Postconditions:</i>
+
+ <table border="1">
+ <thead>
+ <tr>
+ <th colspan="2"><code>copyfmt()</code> postconditions</th>
+ </tr>
+ <tr>
+ <th>Element</th>
+ <th>Value</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td><code>rdbuf()</code></td>
+ <td><i>unchanged</i></td>
+ </tr>
+ <tr>
+ <td><code>tie()</code></td>
+ <td><code>rhs.tie()</code></td>
+ </tr>
+ <tr>
+ <td><code>rdstate()</code></td>
+ <td><i>unchanged</i></td>
+ </tr>
+ <tr>
+ <td><code>exceptions()</code></td>
+ <td><code>rhs.exceptions()</code></td>
+ </tr>
+ <tr>
+ <td><code>flags()</code></td>
+ <td><code>rhs.flags()</code></td>
+ </tr>
+ <tr>
+ <td><code>width()</code></td>
+ <td><code>rhs.width()</code></td>
+ </tr>
+ <tr>
+ <td><code>precision()</code></td>
+ <td><code>rhs.precision()</code></td>
+ </tr>
+ <tr>
+ <td><code>fill()</code></td>
+ <td><code>rhs.fill()</code></td>
+ </tr>
+ <tr>
+ <td><code>getloc()</code></td>
+ <td><code>rhs.getloc()</code></td>
+ </tr>
+ </tbody>
+ </table>
+ </blockquote>
+ <p>
+
+The format of the table follows Table 117 (as
+of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2588.pdf">N2588</a>): <code>basic_ios::init()</code>
+effects.
+
+ </p>
+ <p>
+
+The intent of the new table is not to impose any new requirements or
+change existing ones, just to be more explicit about what I believe is
+already there.
+
+ </p>
+
+
+
+
+<hr>
+<h3><a name="838"></a>838.
+ can an <i>end-of-stream</i> iterator become a <i>non-end-of-stream</i> one?
+ </h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+ <p>
+
+From message c++std-lib-20003...
+
+ </p>
+ <p>
+
+The description of <code>istream_iterator</code> in
+24.5.1 [istream.iterator], p1 specifies that objects of the
+class become the <i>end-of-stream</i> (EOS) iterators under the
+following condition (see also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a> another problem
+with this paragraph):
+
+ </p>
+ <blockquote>
+
+If the end of stream is reached (<code>operator void*()</code> on the
+stream returns <code>false</code>), the iterator becomes equal to
+the <i>end-of-stream</i> iterator value.
+
+ </blockquote>
+ <p>
+
+One possible implementation approach that has been used in practice is
+for the iterator to set its <code>in_stream</code> pointer to 0 when
+it reaches the end of the stream, just like the default ctor does on
+initialization. The problem with this approach is that
+the <i>Effects</i> clause for <code>operator++()</code> says the
+iterator unconditionally extracts the next value from the stream by
+evaluating <code>*in_stream >> value</code>, without checking
+for <code>(in_stream == 0)</code>.
+
+ </p>
+ <p>
+
+Conformance to the requirement outlined in the <i>Effects</i> clause
+can easily be verified in programs by setting <code>eofbit</code>
+or <code>failbit</code> in <code>exceptions()</code> of the associated
+stream and attempting to iterate past the end of the stream: each
+past-the-end access should trigger an exception. This suggests that
+some other, more elaborate technique might be intended.
+
+ </p>
+ <p>
+
+Another approach, one that allows <code>operator++()</code> to attempt
+to extract the value even for EOS iterators (just as long
+as <code>in_stream</code> is non-0) is for the iterator to maintain a
+flag indicating whether it has reached the end of the stream. This
+technique would satisfy the presumed requirement implied by
+the <i>Effects</i> clause mentioned above, but it isn't supported by
+the exposition-only members of the class (no such flag is shown). This
+approach is also found in existing practice.
+
+ </p>
+ <p>
+
+The inconsistency between existing implementations raises the question
+of whether the intent of the specification is that a non-EOS iterator
+that has reached the EOS become a non-EOS one again after the
+stream's <code>eofbit</code> flag has been cleared? That is, are the
+assertions in the program below expected to pass?
+
+ </p>
+ <blockquote>
+ <pre> sstream strm ("1 ");
+ istream_iterator eos;
+ istream_iterator it (strm);
+ int i;
+ i = *it++
+ assert (it == eos);
+ strm.clear ();
+ strm << "2 3 ";
+ assert (it != eos);
+ i = *++it;
+ assert (3 == i);
+ </pre>
+ </blockquote>
+ <p>
+
+Or is it intended that once an iterator becomes EOS it stays EOS until
+the end of its lifetime?
+
+ </p>
+
+
+ <p><b>Proposed resolution:</b></p>
+ <p>
+
+The discussion of this issue on the reflector suggests that the intent
+of the standard is for an <code>istreambuf_iterator</code> that has
+reached the EOS to remain in the EOS state until the end of its
+lifetime. Implementations that permit EOS iterators to return to a
+non-EOS state may only do so as an extension, and only as a result of
+calling <code>istream_iterator</code> member functions on EOS
+iterators whose behavior is in this case undefined.
+
+ </p>
+ <p>
+
+To this end we propose to change 24.5.1 [istream.iterator], p1,
+as follows:
+
+ </p>
+ <blockquote>
+
+The result of operator-> on an end<ins>-</ins>of<ins>-</ins>stream
+is not defined. For any other iterator value a <code>const T*</code>
+is returned.<ins> Invoking <code>operator++()</code> on
+an <i>end-of-stream</i> iterator is undefined.</ins> It is impossible
+to store things into istream iterators...
+
+ </blockquote>
+ <p>
+
+Add pre/postconditions to the member function descriptions of <code>istream_iterator</code> like so:
+
+ </p>
+ <blockquote>
+
+<pre>istream_iterator();</pre>
+
+<i>Effects</i>: Constructs the <i>end-of-stream</i> iterator.<br>
+<ins><i>Postcondition</i>: <code>in_stream == 0</code>.</ins>
+
+<pre>istream_iterator(istream_type &s);</pre>
+
+<i>Effects</i>: Initializes <code>in_stream</code> with &s. value
+may be initialized during construction or the first time it is
+referenced.<br>
+<ins><i>Postcondition</i>: <code>in_stream == &s</code>.</ins>
+
+<pre>istream_iterator(const istream_iterator &x);</pre>
+
+<i>Effects</i>: Constructs a copy of <code>x</code>.<br>
+<ins><i>Postcondition</i>: <code>in_stream == x.in_stream</code>.</ins>
+
+<pre>istream_iterator& operator++();</pre>
+
+<ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br>
+<i>Effects</i>: <code>*in_stream >> value</code>.
+
+<pre>istream_iterator& operator++(int);</pre>
+
+<ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br>
+<i>Effects</i>:
+ <blockquote><pre>istream_iterator tmp (*this);
+*in_stream >> value;
+return tmp;
+ </pre>
+ </blockquote>
+ </blockquote>
+
+
+
+
+<hr>
+<h3><a name="839"></a>839. Maps and sets missing splice operation</h3>
+<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>
+ <b>Submitter:</b> Alan Talbot <b>Date:</b> 2008-05-18</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+Splice is a very useful feature of <tt>list</tt>. This functionality is also very
+useful for any other node based container, and I frequently wish it were
+available for maps and sets. It seems like an omission that these
+containers lack this capability. Although the complexity for a splice is
+the same as for an insert, the actual time can be much less since the
+objects need not be reallocated and copied. When the element objects are
+heavy and the compare operations are fast (say a <tt>map<int, huge_thingy></tt>)
+this can be a big win.
+</p>
+
+<p>
+<b>Suggested resolution:</b>
+</p>
+
+<p>
+Add the following signatures to map, set, multimap, multiset, and the unordered associative containers:
+</p>
+<blockquote><pre>
+void splice(list<T,Allocator>&& x);
+void splice(list<T,Allocator>&& x, const_iterator i);
+void splice(list<T,Allocator>&& x, const_iterator first, const_iterator last);
+</pre></blockquote>
+
+<p>
+Hint versions of these are also useful to the extent hint is useful.
+(I'm looking for guidance about whether hints are in fact useful.)
+</p>
+
+<blockquote><pre>
+void splice(const_iterator position, list<T,Allocator>&& x);
+void splice(const_iterator position, list<T,Allocator>&& x, const_iterator i);
+void splice(const_iterator position, list<T,Allocator>&& x, const_iterator first, const_iterator last);
+</pre></blockquote>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+Don't try to <tt>splice "list"</tt> into the other containers, it should be container-type.
+</p>
+<p>
+<tt>forward_list</tt> already has <tt>splice_after</tt>.
+</p>
+<p>
+Would "<tt>splice</tt>" make sense for an <tt>unordered_map</tt>?
+</p>
+<p>
+Jens, Robert: "<tt>splice</tt>" is not the right term, it implies maintaining ordering in <tt>list</tt>s.
+</p>
+<p>
+Howard: <tt>adopt</tt>?
+</p>
+<p>
+Jens: <tt>absorb</tt>?
+</p>
+<p>
+Alan: <tt>subsume</tt>?
+</p>
+<p>
+Robert: <tt>recycle</tt>?
+</p>
+<p>
+Howard: <tt>transfer</tt>? (but no direction)
+</p>
+<p>
+Jens: <tt>transfer_from</tt>. No.
+</p>
+<p>
+Alisdair: Can we give a nothrow guarantee? If your <tt>compare()</tt> and <tt>hash()</tt> doesn't throw, yes.
+</p>
+<p>
+Daniel: For <tt>unordered_map</tt>, we can't guarantee nothrow.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="841"></a>841. cstdint.syn inconsistent with C99</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+ <p>
+
+In specifying the names of macros and types defined in
+header <code><stdint.h></code>, C99 makes use of the
+symbol <code><i>N</i></code> to accommodate unusual platforms with
+word sizes that aren't powers of two. C99
+permits <code><i>N</i></code> to take on any positive integer value
+(including, for example, 24).
+
+ </p>
+ <p>
+
+In cstdint.syn Header <code><cstdint></code>
+synopsis, C++ on the other hand, fixes the value
+of <code><i>N</i></code> to 8, 16, 32, and 64, and specifies only
+types with these exact widths.
+
+ </p>
+ <p>
+ </p>
+
+In addition, paragraph 1 of the same section makes use of a rather
+informal shorthand notation to specify sets of macros. When
+interpreted strictly, the notation specifies macros such
+as <code>INT_8_MIN</code> that are not intended to be specified.
+
+ <p>
+
+Finally, the section is missing the usual table of symbols defined
+in that header, making it inconsistent with the rest of the
+specification.
+
+ </p>
+
+ <p><b>Proposed resolution:</b></p>
+ <p>
+
+I propose to use the same approach in the C++ spec as C99 uses, that
+is, to specify the header synopsis in terms of "exposition only" types
+that make use of the symbol <code><i>N</i></code> to denote one or
+more of a theoretically unbounded set of widths.
+
+ </p>
+ <p>
+
+Further, I propose to add a new table to section listing the symbols
+defined in the header using a more formal notation that avoids
+introducing inconsistencies.
+
+ </p>
+ <p>
+
+To this effect, in cstdint.syn
+Header <code><cstdint></code> synopsis, replace both the
+synopsis and paragraph 1 with the following text:
+
+ </p>
+ <blockquote>
+ <p>
+ </p><ol>
+ <li>
+
+In the names defined in the <code><cstdint></code> header, the
+symbol <code><i>N</i></code> represents a positive decimal integer
+with no leading zeros (e.g., 8 or 24, but not 0, 04, or 048). With the
+exception of exact-width types, macros and types for values
+of <code><i>N</i></code> in the set of 8, 16, 32, and 64 are
+required. Exact-width types, and any macros and types for values
+of <code><i>N</i></code> other than 8, 16, 32, and 64 are
+optional. However, if an implementation provides integer types with
+widths of 8, 16, 32, or 64 bits, the corresponding exact-width types
+and macros are required.
+
+ </li>
+ </ol>
+
+ <pre>namespace std {
+
+ // required types
+
+ // Fastest minimum-width integer types
+ typedef <i>signed integer type</i> int_fast8_t;
+ typedef <i>signed integer type</i> int_fast16_t;
+ typedef <i>signed integer type</i> int_fast32_t;
+ typedef <i>signed integer type</i> int_fast64_t;
+
+ typedef <i>unsigned integer type</i> uint_fast8_t;
+ typedef <i>unsigned integer type</i> uint_fast16_t;
+ typedef <i>unsigned integer type</i> uint_fast32_t;
+ typedef <i>unsigned integer type</i> uint_fast64_t;
+
+ // Minimum-width integer types
+ typedef <i>signed integer type</i> int_least8_t;
+ typedef <i>signed integer type</i> int_least16_t;
+ typedef <i>signed integer type</i> int_least32_t;
+ typedef <i>signed integer type</i> int_least64_t;
+
+ typedef <i>unsigned integer type</i> uint_least8_t;
+ typedef <i>unsigned integer type</i> uint_least16_t;
+ typedef <i>unsigned integer type</i> uint_least32_t;
+ typedef <i>unsigned integer type</i> uint_least64_t;
+
+ // Greatest-width integer types
+ typedef <i>signed integer type</i> intmax_t;
+ typedef <i>unsigned integer type</i> uintmax_t;
+
+ // optionally defined types
+
+ // Exact-width integer types
+ typedef <i>signed integer type</i> int<i>N</i>_t;
+ typedef <i>unsigned integer type</i> uint<i>N</i>_t;
+
+ // Fastest minimum-width integer types for values
+ // of <i>N</i> other than 8, 16, 32, and 64
+ typedef <i>signed integer type</i> uint_fast<i>N</i>_t;
+ typedef <i>unsigned integer type</i> uint_fast<i>N</i>_t;
+
+ // Minimum-width integer types for values
+ // of <i>N</i> other than 8, 16, 32, and 64
+ typedef <i>signed integer type</i> uint_least<i>N</i>_t;
+ typedef <i>unsigned integer type</i> uint_least<i>N</i>_t;
+
+ // Integer types capable of holding object pointers
+ typedef <i>signed integer type</i> intptr_t;
+ typedef <i>signed integer type</i> intptr_t;
+
+}</pre>
+ </blockquote>
+ <p>
+
+[Note to editor: Remove all of the existing paragraph 1 from cstdint.syn.]
+
+ </p>
+ <blockquote>
+ Table ??: Header <code><cstdint></code> synopsis
+ <table border="1">
+ <thead>
+ <tr>
+ <th>Type</th>
+ <th colspan="3">Name(s)</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td rowspan="11"><b>Macros:</b></td>
+ <td><tt>INT<i>N</i>_MIN</tt></td>
+ <td><tt>INT<i>N</i>_MAX</tt></td>
+ <td><tt>UINT<i>N</i>_MAX</tt></td>
+ </tr>
+ <tr>
+ <td><tt>INT_FAST<i>N</i>_MIN</tt></td>
+ <td><tt>INT_FAST<i>N</i>_MAX</tt></td>
+ <td><tt>UINT_FAST<i>N</i>_MAX</tt></td>
+ </tr>
+ <tr>
+ <td><tt>INT_LEAST<i>N</i>_MIN</tt></td>
+ <td><tt>INT_LEAST<i>N</i>_MAX</tt></td>
+ <td><tt>UINT_LEAST<i>N</i>_MAX</tt></td>
+ </tr>
+ <tr>
+ <td><tt>INTPTR_MIN</tt></td>
+ <td><tt>INTPTR_MAX</tt></td>
+ <td><tt>UINTPTR_MAX</tt></td>
+ </tr>
+ <tr>
+ <td><tt>INTMAX_MIN</tt></td>
+ <td><tt>INTMAX_MAX</tt></td>
+ <td><tt>UINTMAX_MAX</tt></td>
+ </tr>
+ <tr>
+ <td><tt>PTRDIFF_MIN</tt></td>
+ <td><tt>PTRDIFF_MAX</tt></td>
+ <td><tt>PTRDIFF_MAX</tt></td>
+ </tr>
+ <tr>
+ <td><tt>SIG_ATOMIC_MIN</tt></td>
+ <td><tt>SIG_ATOMIC_MAX</tt></td>
+ <td><tt>SIZE_MAX</tt></td>
+ </tr>
+ <tr>
+ <td><tt>WCHAR_MIN</tt></td>
+ <td><tt>WCHAR_MAX</tt></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><tt>WINT_MIN</tt></td>
+ <td><tt>WINT_MAX</tt></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><tt>INT<i>N</i>_C()</tt></td>
+ <td><tt>UINT<i>N</i>_C()</tt></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><tt>INTMAX_C()</tt></td>
+ <td><tt>UINTMAX_C()</tt></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td rowspan="5"><b>Types:</b></td>
+ <td><tt>int<i>N</i>_t</tt></td>
+ <td><tt>uint<i>N</i>_t</tt></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><tt>int_fast<i>N</i>_t</tt></td>
+ <td><tt>uint_fast<i>N</i>_t</tt></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><tt>int_least<i>N</i>_t</tt></td>
+ <td><tt>uint_least<i>N</i>_t</tt></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><tt>intptr_t</tt></td>
+ <td><tt>uintptr_t</tt></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><tt>intmax_t</tt></td>
+ <td><tt>uintmax_t</tt></td>
+ <td></td>
+ </tr>
+ </tbody>
+ </table>
+ </blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="842"></a>842. ConstructibleAsElement and bit containers</h3>
+<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>
+ <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-06-03</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+23.1 [container.requirements]/p3 says:
+</p>
+
+<blockquote>
+Objects stored in these components shall be constructed using
+<tt>construct_element</tt> (20.6.9). For each operation that inserts an
+element of type <tt>T</tt> into a container (<tt>insert</tt>,
+<tt>push_back</tt>, <tt>push_front</tt>, <tt>emplace</tt>, etc.) with
+arguments <tt>args... T</tt> shall be <tt>ConstructibleAsElement</tt>,
+as described in table 88. [<i>Note:</i> If the component is instantiated
+with a scoped allocator of type <tt>A</tt> (i.e., an allocator for which
+<tt>is_scoped_allocator<A>::value</tt> is <tt>true</tt>), then
+<tt>construct_element</tt> may pass an inner allocator argument to
+<tt>T</tt>'s constructor. <i>-- end note</i>]
+</blockquote>
+
+<p>
+However <tt>vector<bool, A></tt> (23.2.7 [vector.bool]) and <tt>bitset<N></tt>
+(23.3.5 [template.bitset]) store bits, not <tt>bool</tt>s, and <tt>bitset<N></tt>
+does not even have an allocator. But these containers are governed by this clause. Clearly this
+is not implementable.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 23.1 [container.requirements]/p3:
+</p>
+
+<blockquote>
+Objects stored in these components shall be constructed using
+<tt>construct_element</tt> (20.6.9)<ins>, unless otherwise specified</ins>.
+For each operation that inserts an
+element of type <tt>T</tt> into a container (<tt>insert</tt>,
+<tt>push_back</tt>, <tt>push_front</tt>, <tt>emplace</tt>, etc.) with
+arguments <tt>args... T</tt> shall be <tt>ConstructibleAsElement</tt>,
+as described in table 88. [<i>Note:</i> If the component is instantiated
+with a scoped allocator of type <tt>A</tt> (i.e., an allocator for which
+<tt>is_scoped_allocator<A>::value</tt> is <tt>true</tt>), then
+<tt>construct_element</tt> may pass an inner allocator argument to
+<tt>T</tt>'s constructor. <i>-- end note</i>]
+</blockquote>
+
+<p>
+Change 23.2.7 [vector.bool]/p2:
+</p>
+
+<blockquote>
+Unless described below, all operations have the same requirements and semantics as the primary <tt>vector</tt> template,
+except that operations dealing with the <tt>bool</tt> value type map to bit values in the container storage<ins>,
+and <tt>construct_element</tt> (23.1 [container.requirements]) is not used to construct these values</ins>.
+</blockquote>
+
+<p>
+Move 23.3.5 [template.bitset] to clause 20.
+</p>
+
+
+
+
+
+
+<hr>
+<h3><a name="843"></a>843. Reference Closure</h3>
+<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>
+ <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-06-02</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The <tt>std::reference_closure</tt> type has a deleted copy assignment operator
+under the theory that references cannot be assigned, and hence the
+assignment of its reference member must necessarily be ill-formed.
+</p>
+<p>
+However, other types, notably <tt>std::reference_wrapper</tt> and <tt>std::function</tt>
+provide for the "copying of references", and thus the current definition
+of <tt>std::reference_closure</tt> seems unnecessarily restrictive. In particular,
+it should be possible to write generic functions using both <tt>std::function</tt>
+and <tt>std::reference_closure</tt>, but this generality is much harder when
+one such type does not support assignment.
+</p>
+<p>
+The definition of <tt>reference_closure</tt> does not necessarily imply direct
+implementation via reference types. Indeed, the <tt>reference_closure</tt> is
+best implemented via a frame pointer, for which there is no standard
+type.
+</p>
+<p>
+The semantics of assignment are effectively obtained by use of the
+default destructor and default copy assignment operator via
+</p>
+
+<blockquote><pre>x.~reference_closure(); new (x) reference_closure(y);
+</pre></blockquote>
+
+<p>
+So the copy assignment operator generates no significant real burden
+to the implementation.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 20.6.17 [func.referenceclosure] Class template reference_closure,
+replace the <tt>=delete</tt> in the copy assignment operator in the synopsis
+with <tt>=default</tt>.
+</p>
+
+<blockquote><pre>template<class R , class... ArgTypes >
+ class reference_closure<R (ArgTypes...)> {
+ public:
+ ...
+ reference_closure& operator=(const reference_closure&) = <del>delete</del> <ins>default</ins>;
+ ...
+</pre></blockquote>
+
+<p>
+In 20.6.17.1 [func.referenceclosure.cons] Construct, copy, destroy,
+add the member function description
+</p>
+
+<blockquote>
+<pre>reference_closure& operator=(const reference_closure& f)
+</pre>
+<blockquote>
+<p>
+<i>Postcondition:</i> <tt>*this</tt> is a copy of <tt>f</tt>.
+</p>
+<p>
+<i>Returns:</i> <tt>*this</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+
+
+<hr>
+<h3><a name="844"></a>844. <tt>complex pow</tt> return type is ambiguous</h3>
+<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>
+ <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-06-03</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The current working draft is in an inconsistent state.
+</p>
+
+<p>
+26.3.8 [complex.transcendentals] says that:
+</p>
+
+<blockquote>
+<tt>pow(complex<float>(), int())</tt> returns a <tt>complex<float></tt>.
+</blockquote>
+
+<p>
+26.3.9 [cmplx.over] says that:
+</p>
+
+<blockquote>
+<tt>pow(complex<float>(), int())</tt> returns a <tt>complex<double></tt>.
+</blockquote>
+
+<p><i>[
+Sophia Antipolis:
+]</i></p>
+
+
+<blockquote>
+<p>
+Since <tt>int</tt> promotes to <tt>double</tt>, and C99 doesn't have an <tt>int</tt>-based
+overload for <tt>pow</tt>, the C99 result is <tt>complex<double></tt>, see also C99
+7.22, see also library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>.
+</p>
+<p>
+Special note: ask P.J. Plauger.
+</p>
+<blockquote>
+Looks fine.
+</blockquote>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Strike this <tt>pow</tt> overload in 26.3.1 [complex.synopsis] and in 26.3.8 [complex.transcendentals]:
+</p>
+
+<blockquote><pre><del>template<class T> complex<T> pow(const complex<T>& x, int y);</del>
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="845"></a>845. atomics cannot support aggregate initialization</h3>
+<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>
+ <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-06-03</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The atomic classes (and class templates) are required to support aggregate
+initialization (29.3.1 [atomics.types.integral]p2 / 29.3.2 [atomics.types.address]p1)
+yet also have user declared constructors, so cannot be aggregates.
+</p>
+<p>
+This problem might be solved with the introduction of the proposed
+initialization syntax at Antipolis, but the wording above should be altered.
+Either strike the sentence as redundant with new syntax, or refer to 'brace
+initialization'.
+</p>
+
+<p><i>[
+Jens adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+Note that
+</p>
+<blockquote><pre>atomic_itype a1 = { 5 };
+</pre></blockquote>
+<p>
+would be aggregate-initialization syntax (now coming under the disguise
+of brace initialization), but would be ill-formed, because the corresponding
+constructor for atomic_itype is explicit. This works, though:
+</p>
+<blockquote><pre>atomic_itype a2 { 6 };
+</pre></blockquote>
+
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 29.3.1 [atomics.types.integral], strike the following sentence from paragraph 2:
+</p>
+
+<blockquote>
+The atomic integral types shall have standard layout. They shall each have a trivial default constructor, a constexpr
+explicit value constructor, a deleted copy constructor, a deleted copy assignment operator, and a trivial destructor.
+<del>They shall each support aggregate initialization syntax.</del>
+</blockquote>
+
+<p><i>[
+2008-08-18, Lawrence adds:
+]</i></p>
+
+<blockquote>
+The syntactic compatibility of initialization with C is important.
+I suggest a different resolution; remove the explicit from the
+constructor. For the same reasons we can have implicit conversions,
+we can also have implicit constructors.
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="846"></a>846. No definition for constructor</h3>
+<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>
+ <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-06-03</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The atomic classes and class templates (29.3.1 [atomics.types.integral] /
+29.3.2 [atomics.types.address]) have a constexpr
+constructor taking a value of the appropriate type for that atomic.
+However, neither clause provides semantics or a definition for this
+constructor. I'm not sure if the initialization is implied by use of
+constexpr keyword (which restricts the form of a constructor) but even if
+that is the case, I think it is worth spelling out explicitly as the
+inference would be far too subtle in that case.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="847"></a>847. string exception safety guarantees</h3>
+<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>
+ <b>Submitter:</b> Hervé Brönnimann <b>Date:</b> 2008-06-05</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+In March, on comp.lang.c++.moderated, I asked what were the
+string exception safety guarantees are, because I cannot see
+*any* in the working paper, and any implementation I know offers
+the strong exception safety guarantee (string unchanged if a
+member throws exception). The closest the current draft comes to
+offering any guarantees is 21.3 [basic.string], para 3:
+</p>
+
+<blockquote>
+The class template <tt>basic_string</tt> conforms to the requirements
+for a Sequence Container (23.1.1), for a Reversible Container (23.1),
+and for an Allocator-aware container (91). The iterators supported by
+<tt>basic_string</tt> are random access iterators (24.1.5).
+</blockquote>
+
+<p>
+However, the chapter 23 only says, on the topic of exceptions: 23.1 [container.requirements],
+para 10:
+</p>
+
+<blockquote>
+<p>
+Unless otherwise specified (see 23.2.2.3 and 23.2.6.4) all container types defined in this clause meet the following
+additional requirements:
+</p>
+
+<ul>
+<li>if an exception is thrown by...</li>
+</ul>
+</blockquote>
+
+<p>
+I take it as saying that this paragraph has *no* implication on
+<tt>std::basic_string</tt>, as <tt>basic_string</tt> isn't defined in Clause 23 and
+this paragraph does not define a *requirement* of Sequence
+nor Reversible Container, just of the models defined in Clause 23.
+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.
+</p>
+
+<p>
+Finally, the fact that no operation on Traits should throw
+exceptions has no bearing, except to suggest (since the only
+other throws should be allocation, <tt>out_of_range</tt>, or <tt>length_error</tt>)
+that the strong exception guarantee can be achieved.
+</p>
+
+<p>
+The reaction in that group by Niels Dekker, Martin Sebor, and
+Bo Persson, was all that this would be worth an LWG issue.
+</p>
+
+<p>
+A related issue is that <tt>erase()</tt> does not throw. This should be
+stated somewhere (and again, I don't think that the 23.1 [container.requirements], para 1
+applies here).
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add a blanket statement in 21.3.1 [string.require]:
+</p>
+
+<blockquote>
+<p>
+- if any member function or operator of <tt>basic_string<charT, traits, Allocator></tt>
+throws, that function or operator has no effect.
+</p>
+<p>
+- no <tt>erase()</tt> or <tt>pop_back()</tt> function throws.
+</p>
+</blockquote>
+
+<p>
+As far as I can tell, this is achieved by any implementation. If I made a
+mistake and it is not possible to offer this guarantee, then
+either state all the functions for which this is possible
+(certainly at least <tt>operator+=</tt>, <tt>append</tt>, <tt>assign</tt>, and <tt>insert</tt>),
+or add paragraphs to Effects clauses wherever appropriate.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="848"></a>848. missing <tt>std::hash</tt> specializations for <tt>std::bitset/std::vector<bool></tt></h3>
+<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>
+ <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2008-06-05</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+In the current working draft, <tt>std::hash<T></tt> is specialized for builtin
+types and a few other types. Bitsets seems like one that is missing from
+the list, not because it cannot not be done by the user, but because it
+is hard or impossible to write an efficient implementation that works on
+32bit/64bit chunks at a time. For example, <tt>std::bitset</tt> is too much
+encapsulated in this respect.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the following to the synopsis in 20.6 [function.objects]/2:
+</p>
+
+<blockquote><pre>template<class Allocator> struct hash<std::vector<bool,Allocator>>;
+template<size_t N> struct hash<std::bitset<N>>;
+</pre></blockquote>
+
+<p>
+Modify the last sentence of 20.6.16 [unord.hash]/1 to end with:
+</p>
+
+<blockquote>
+... and <tt>std::string</tt>, <tt>std::u16string</tt>, <tt>std::u32string</tt>, <tt>std::wstring</tt>,
+<tt>std::error_code</tt>, <tt>std::thread::id</tt>, <tt>std::bitset</tt>, <tt>and std::vector<bool></tt>.
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="849"></a>849. missing type traits to compute root class and derived class of types in a class hierachy</h3>
+<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>
+ <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2008-06-05</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The type traits library contains various traits to dealt with
+polymorphic types, e.g. <tt>std::has_virtual_destructor</tt>, <tt>std::is_polymorphic</tt>
+and <tt>std::is_base_of</tt>. However, there is no way to compute the unique
+public base class of a type if such one exists. Such a trait could be
+very useful if one needs to instantiate a specialization made for the
+root class whenever a derived class is passed as parameter. For example,
+imagine that you wanted to specialize <tt>std::hash</tt> for a class
+hierarchy---instead of specializing each class, you could specialize the
+<tt>std::hash<root_class></tt> and provide a partial specialization that worked
+for all derived classes.
+</p>
+
+<p>
+This ability---to specify operations in terms of their equivalent in the
+root class---can be done with e.g. normal functions, but there is,
+AFAIK, no way to do it for class templates. Being able to access
+compile-time information about the type-hierachy can be very powerful,
+and I therefore also suggest traits that computes the directly derived
+class whenever that is possible.
+</p>
+
+<p>
+If the computation can not be done, the traits should fall back on an
+identity transformation. I expect this gives the best overall usability.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the following to the synopsis in 20.5.2 [meta.type.synop] under "other transformations":
+</p>
+
+<blockquote><pre>template< class T > struct direct_base_class;
+template< class T > struct direct_derived_class;
+template< class T > struct root_base_class;
+</pre></blockquote>
+
+<p>
+Add three new entries to table 51 (20.5.7 [meta.trans.other]) with the following content
+</p>
+
+<blockquote>
+<table border="1">
+<tbody><tr>
+<th>Template</th><th>Condition</th><th>Comments</th>
+</tr>
+<tr>
+<td><tt>template< class T > struct direct_base_class;</tt></td>
+<td><tt>T</tt> shall be a complete type.</td>
+<td>The member typedef <tt>type</tt> shall equal the accessible unambiguous direct base class of <tt>T</tt>.
+If no such type exists, the member typedef <tt>type</tt> shall equal <tt>T</tt>.</td>
+</tr>
+<tr>
+<td><tt>template< class T > struct direct_derived_class;</tt></td>
+<td><tt>T</tt> shall be a complete type.</td>
+<td>The member typedef <tt>type</tt> shall equal the unambiguous type which has <tt>T</tt>
+as an accessible unambiguous direct base class. If no such type exists, the member typedef
+<tt>type</tt> shall equal <tt>T</tt>.</td>
+</tr>
+<tr>
+<td><tt>template< class T > struct root_base_class;</tt></td>
+<td><tt>T</tt> shall be a complete type.</td>
+<td>The member typedef <tt>type</tt> shall equal the accessible unambiguous most indirect base class of
+<tt>T</tt>. If no such type exists, the member typedef type shall equal <tt>T</tt>.</td>
+</tr>
+</tbody></table>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="850"></a>850. Should <tt>shrink_to_fit</tt> apply to <tt>std::deque</tt>?</h3>
+<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>
+ <b>Submitter:</b> Niels Dekker <b>Date:</b> 2008-06-05</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+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>.
+It did not yet deal with <tt>std::deque</tt>, because of the fundamental
+difference between <tt>std::deque</tt> and the other two container types. The
+need for <tt>std::deque</tt> may seem less evident, because one might think that
+for this container, the overhead is a small map, and some number of
+blocks that's bounded by a small constant.
+</p>
+<p>
+The container overhead can in fact be arbitrarily large (i.e. is not
+necessarily O(N) where N is the number of elements currently held by the
+<tt>deque</tt>). As Bill Plauger noted in a reflector message, unless the map of
+block pointers is shrunk, it must hold at least maxN/B pointers where
+maxN is the maximum of N over the lifetime of the <tt>deque</tt> since its
+creation. This is independent of how the map is implemented
+(<tt>vector</tt>-like circular buffer and all), and maxN bears no relation to N,
+the number of elements it currently holds.
+</p>
+<p>
+Hervé Brönnimann reports a situation where a <tt>deque</tt> of requests grew very
+large due to some temporary backup (the front request hanging), and the
+map of the <tt>deque</tt> grew quite large before getting back to normal. Just
+to put some color on it, assuming a <tt>deque</tt> with 1K pointer elements in
+steady regime, that held, at some point in its lifetime, maxN=10M
+pointers, with one block holding 128 elements, the spine must be at
+least (maxN / 128), in that case 100K. In that case, shrink-to-fit
+would allow to reuse about 100K which would otherwise never be reclaimed
+in the lifetime of the <tt>deque</tt>.
+</p>
+<p>
+An added bonus would be that it *allows* implementations to hang on to
+empty blocks at the end (but does not care if they do or not). A
+<tt>shrink_to_fit</tt> would take care of both shrinks, and guarantee that at
+most O(B) space is used in addition to the storage to hold the N
+elements and the N/B block pointers.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+To Class template deque 23.2.2 [deque] synopsis, add:
+</p>
+<blockquote><pre>void shrink_to_fit();
+</pre></blockquote>
+
+<p>
+To deque capacity 23.2.2.2 [deque.capacity], add:
+</p>
+<blockquote><pre>void shrink_to_fit();
+</pre>
+
+<blockquote>
+<i>Remarks:</i> <tt>shrink_to_fit</tt> is a non-binding request to reduce memory
+use. [<i>Note:</i> The request is non-binding to allow latitude for
+implementation-specific optimizations. -- <i>end note</i>]
+</blockquote>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="851"></a>851. simplified array construction</h3>
+<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>
+ <b>Submitter:</b> Benjamin Kosnik <b>Date:</b> 2008-06-05</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+This is an issue that came up on the libstdc++ list, where a
+discrepency between "C" arrays and C++0x's <tt>std::array</tt> was pointed
+out.
+</p>
+
+<p>
+In "C," this array usage is possible:
+</p>
+
+<blockquote><pre>int ar[] = {1, 4, 6};
+</pre></blockquote>
+
+<p>
+But for C++,
+</p>
+
+<blockquote><pre>std::array<int> a = { 1, 4, 6 }; // error
+</pre></blockquote>
+
+<p>
+Instead, the second parameter of the <tt>array</tt> template must be
+explicit, like so:
+</p>
+
+<blockquote><pre>std::array<int, 3> a = { 1, 4, 6 };
+</pre></blockquote>
+
+<p>
+Doug Gregor proposes the following solution, that assumes
+generalized initializer lists.
+</p>
+
+<blockquote><pre>template<typename T, typename... Args>
+inline array<T, sizeof...(Args)>
+make_array(Args&&... args)
+{ return { std::forward<Args>(args)... }; }
+</pre></blockquote>
+
+<p>
+Then, the way to build an <tt>array</tt> from a list of unknown size is:
+</p>
+
+<blockquote><pre>auto a = make_array<T>(1, 4, 6);
+</pre></blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add to the <tt>array</tt> synopis in 23.2 [sequences]:
+</p>
+
+<blockquote><pre>template<typename T, typename... Args>
+ requires Convertible<Args, T>...
+ array<T, sizeof...(Args)>
+ make_array(Args&&... args);
+</pre></blockquote>
+
+<p>
+Append after 23.2.1.6 [array.tuple] Tuple interface to class template <tt>array</tt> the
+following new section.
+</p>
+
+<blockquote>
+<p>
+23.2.1.7 Convenience interface to class template <tt>array</tt> [array.tuple]
+</p>
+
+<pre>template<typename T, typename... Args>
+ requires Convertible<Args, T>...
+ array<T, sizeof...(Args)>
+ make_array(Args&&... args);
+</pre>
+
+<blockquote>
+<p>
+<i>Returns:</i> <tt>{std::forward<Args>(args)...}</tt>
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="852"></a>852. unordered containers <tt>begin(n)</tt> mistakenly <tt>const</tt></h3>
+<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>
+ <b>Submitter:</b> Robert Klarer <b>Date:</b> 2008-06-12</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+In 3 of the four unordered containers the local <tt>begin</tt> member is mistakenly declared <tt>const</tt>:
+</p>
+
+<blockquote><pre>local_iterator begin(size_type n) const;
+</pre></blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis in 23.4.1 [unord.map], 23.4.2 [unord.multimap], and 23.4.4 [unord.multiset]:
+</p>
+
+<blockquote><pre>local_iterator begin(size_type n)<del> const</del>;
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="853"></a>853. <tt>to_string</tt> needs updating with <tt>zero</tt> and <tt>one</tt></h3>
+<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>
+ <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-06-18</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+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
+the three newer <tt>to_string</tt> overloads.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis in 23.3.5 [template.bitset], and the signatures in 23.3.5.2 [bitset.members] to:
+</p>
+
+<blockquote><pre>template <class charT, class traits>
+ basic_string<charT, traits, allocator<charT> > to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const;
+template <class charT>
+ basic_string<charT, char_traits<charT>, allocator<charT> > to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const;
+basic_string<char, char_traits<char>, allocator<char> > to_string(<ins>char zero = '0', char one = '1'</ins>) const;
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="854"></a>854. <tt>default_delete</tt> converting constructor underspecified</h3>
+<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>
+ <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-06-18</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+No relationship between <tt>U</tt> and <tt>T</tt> in the converting constructor for <tt>default_delete</tt> template.
+</p>
+<p>
+Requirements: <tt>U*</tt> is convertible to <tt>T*</tt> and <tt>has_virtual_destructor<T></tt>;
+the latter should also become a concept.
+</p>
+<p>
+Rules out cross-casting.
+</p>
+<p>
+The requirements for <tt>unique_ptr</tt> conversions should be the same as those on the deleter.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.7.11.1.1 [unique.ptr.dltr.dflt]:
+</p>
+
+<blockquote><pre>namespace std {
+ template <class T> struct default_delete {
+ default_delete();
+ template <class U>
+ <ins>requires Convertible<U*, T*> && HasVirtualDestructor<T></ins>
+ default_delete(const default_delete<U>&);
+ void operator()(T*) const;
+ };
+}
+</pre></blockquote>
+
+<p>
+...
+</p>
+
+<blockquote><pre>template <class U>
+ <ins>requires Convertible<U*, T*> && HasVirtualDestructor<T></ins>
+ default_delete(const default_delete<U>& other);
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="855"></a>855. capacity() and reserve() for deque?</h3>
+<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>
+ <b>Submitter:</b> Hervé Brönnimann <b>Date:</b> 2008-06-11</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The main point is that <tt>capacity</tt> can be viewed as a mechanism to
+guarantee the validity of <tt>iterators</tt> when only <tt>push_back/pop_back</tt>
+operations are used. For <tt>vector</tt>, this goes with reallocation. For
+<tt>deque</tt>, this is a bit more subtle: <tt>capacity()</tt> of a <tt>deque</tt> may shrink,
+whereas that of <tt>vector</tt> doesn't. In a circular buffer impl. of the
+map, as Howard did, there is very similar notion of capacity: as long
+as <tt>size()</tt> is less than <tt>B * (</tt>total size of the map <tt>- 2)</tt>, it is
+guaranteed that no <tt>iterator</tt> is invalidated after any number of
+<tt>push_front/back</tt> and <tt>pop_front/back</tt> operations. But this does not
+hold for other implementations.
+</p>
+<p>
+Still, I believe, <tt>capacity()</tt> can be defined by <tt>size() +</tt> how many
+<tt>push_front/back</tt> minus <tt>pop_front/back</tt> that can be performed before
+terators are invalidated. In a classical impl., <tt>capacity() = size()
++ </tt> the min distance to either "physical" end of the deque (i.e.,
+counting the empty space in the last block plus all the blocks until
+the end of the map of block pointers). In Howard's circular buffer
+impl., <tt>capacity() = B * (</tt>total size of the map <tt>- 2)</tt> still works with
+this definition, even though the guarantee could be made stronger.
+</p>
+<p>
+A simple picture of a deque:
+</p>
+<blockquote><pre>A-----|----|-----|---F+|++++|++B--|-----|-----Z
+</pre></blockquote>
+<p>
+(A,Z mark the beginning/end, | the block boundaries, F=front, B=back,
+and - are uninitialized, + are initialized)
+In that picture: <tt>capacity = size() + min(dist(A,F),dist(B,Z)) = min
+(dist(A,B),dist(F,Z))</tt>.
+</p>
+<p>
+<tt>Reserve(n)</tt> can grow the map of pointers and add possibly a number of
+empty blocks to it, in order to guarantee that the next <tt>n-size()
+push_back/push_front</tt> operations will not invalidate iterators, and
+also will not allocate (i.e. cannot throw). The second guarantee is
+not essential and can be left as a QoI. I know well enough existing
+implementations of <tt>deque</tt> (sgi/stl, roguewave, stlport, and
+dinkumware) to know that either can be implemented with no change to
+the existing class layout and code, and only a few modifications if
+blocks are pre-allocated (instead of always allocating a new block,
+check if the next entry in the map of block pointers is not zero).
+</p>
+<p>
+Due to the difference with <tt>vector</tt>, wording is crucial. Here's a
+proposed wording to make things concrete; I tried to be reasonably
+careful but please double-check me:
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+Add new signatures to synopsis in 23.2.2 [deque]:
+</p>
+
+<blockquote><pre>size_type capacity() const;
+bool reserve(size_type n);
+</pre></blockquote>
+
+<p>
+Add new signatures to 23.2.2.2 [deque.capacity]:
+</p>
+
+<blockquote>
+<pre>size_type capacity() const;
+</pre>
+<blockquote>
+<p>
+1 <i>Returns:</i> An upper bound on <tt>n + max(n_f - m_f, n_b - m_b)</tt> such
+that, for any sequence of <tt>n_f push_front</tt>, <tt>m_f pop_front</tt>, <tt>n_b
+push_back</tt>, and <tt>m_b pop_back</tt> operations, interleaved in any order,
+starting with the current <tt>deque</tt> of size <tt>n</tt>, the <tt>deque</tt> does not
+invalidate any of its iterators except to the erased elements.
+</p>
+<p>
+2 <i>Remarks:</i> Unlike a <tt>vector</tt>'s capacity, the capacity of a <tt>deque</tt> can
+decrease after a sequence of insertions at both ends, even if none of
+the operations caused the <tt>deque</tt> to invalidate any of its iterators
+except to the erased elements.
+</p>
+</blockquote>
+</blockquote>
+
+<blockquote>
+<pre>bool reserve(size_type n);
+</pre>
+<blockquote>
+<p>
+2 <i>Effects:</i> A directive that informs a <tt>deque</tt> of a planned sequence of
+<tt>push_front</tt>, <tt>pop_front</tt>, <tt>push_back</tt>, and <tt>pop_back</tt> operations, so that it
+can manage iterator invalidation accordingly. After <tt>reserve()</tt>,
+<tt>capacity()</tt> is greater or equal to the argument of <tt>reserve</tt> if this
+operation returns <tt>true</tt>; and equal to the previous value of <tt>capacity()</tt>
+otherwise. If an exception is thrown, there are no effects.
+</p>
+<p>
+3 <i>Returns:</i> <tt>true</tt> if iterators are invalidated as a result of this
+operation, and false otherwise.
+</p>
+<p>
+4 <i>Complexity:</i> It does not change the size of the sequence and takes
+at most linear time in <tt>n</tt>.
+</p>
+<p>
+5 <i>Throws:</i> <tt>length_error</tt> if <tt>n > max_size()</tt>.
+</p>
+<p>
+6 <i>Remarks:</i> It is guaranteed that no invalidation takes place during a
+sequence of <tt>insert</tt> or <tt>erase</tt> operations at either end that happens
+after a call to <tt>reserve()</tt> except to the erased elements, until the
+time when an insertion would make <tt>max(n_f-m_f, n_b-m_b)</tt> larger than
+<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>,
+<tt>n_b</tt> of <tt>push_back</tt>, and <tt>m_b</tt> of <tt>pop_back</tt> operations since the call to
+<tt>reserve()</tt>.
+</p>
+<p>
+7 An implementation is free to pre-allocate buffers so as to
+offer the additional guarantee that no exception will be thrown
+during such a sequence other than by the element constructors.
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+And 23.2.2.3 [deque.modifiers] para 1, can be enhanced:
+</p>
+
+<blockquote>
+1 <i>Effects:</i> An insertion in the middle of the deque invalidates all the iterators and references to elements of the
+deque. An insertion at either end of the deque invalidates all the iterators to the deque,
+<ins>unless provisions have been made with reserve,</ins>
+but has no effect on the validity of references to elements of the deque.
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="856"></a>856. Removal of <tt>aligned_union</tt></h3>
+<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>
+ <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-06-12</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+With the arrival of extended unions
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2544.pdf">N2544</a>),
+there is no
+known use of <tt>aligned_union</tt> that couldn't be handled by
+the "extended unions" core-language facility.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Remove the following signature from 20.5.2 [meta.type.synop]:
+</p>
+<blockquote><pre>template <std::size_t Len, class... Types> struct aligned_union;
+</pre></blockquote>
+
+<p>
+Remove the second row from table 51 in 20.5.7 [meta.trans.other],
+starting with:
+</p>
+
+<blockquote><pre>template <std::size_t Len,
+class... Types>
+struct aligned_union;
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="857"></a>857. <tt>condition_variable::time_wait</tt> return <tt>bool</tt> error prone</h3>
+<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>
+ <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-06-13</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The meaning of the <tt>bool</tt> returned by <tt>condition_variable::timed_wait</tt> is so
+obscure that even the class' designer can't deduce it correctly. Several
+people have independently stumbled on this issue.
+</p>
+<p>
+It might be simpler to change the return type to a scoped enum:
+</p>
+<blockquote><pre>enum class timeout { not_reached, reached };
+</pre></blockquote>
+
+<p>
+That's the same cost as returning a <tt>bool</tt>, but not subject to mistakes. Your example below would be:
+</p>
+
+<blockquote><pre>if (cv.wait_until(lk, time_limit) == timeout::reached )
+ throw time_out();
+</pre></blockquote>
+
+<p><i>[
+Beman to supply exact wording.
+]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+
+
+
+
+<hr>
+<h3><a name="858"></a>858. Wording for Minimal Support for Garbage Collection</h3>
+<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>
+ <b>Submitter:</b> Pete Becker <b>Date:</b> 2008-06-21</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The first sentence of the Effects clause for <tt>undeclare_reachable</tt> seems
+to be missing some words. I can't parse
+</p>
+<blockquote>
+... for all non-null <tt>p</tt> referencing the argument is no longer declared reachable...
+</blockquote>
+<p>
+I take it the intent is that <tt>undeclare_reachable</tt> should be called only
+when there has been a corresponding call to <tt>declare_reachable</tt>. In
+particular, although the wording seems to allow it, I assume that code
+shouldn't call <tt>declare_reachable</tt> once then call <tt>undeclare_reachable</tt>
+twice.
+</p>
+<p>
+I don't know what "shall be live" in the Requires clause means.
+</p>
+<p>
+In the final Note for <tt>undeclare_reachable</tt>, what does "cannot be
+deallocated" mean? Is this different from "will not be able to collect"?
+</p>
+
+<p>
+For the wording on nesting of <tt>declare_reachable</tt> and
+<tt>undeclare_reachable</tt>, the words for locking and unlocking recursive
+mutexes probably are a good model.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="859"></a>859. Monotonic Clock is Conditionally Supported?</h3>
+<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>
+ <b>Submitter:</b> Pete Becker <b>Date:</b> 2008-06-23</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.html">N2661</a>
+says that there is a class named <tt>monotonic_clock</tt>. It also says that this
+name may be a synonym for <tt>system_clock</tt>, and that it's conditionally
+supported. So the actual requirement is that it can be monotonic or not,
+and you can tell by looking at <tt>is_monotonic</tt>, or it might not exist at
+all (since it's conditionally supported). Okay, maybe too much
+flexibility, but so be it.
+</p>
+<p>
+A problem comes up in the threading specification, where several
+variants of <tt>wait_for</tt> explicitly use <tt>monotonic_clock::now()</tt>. What is the
+meaning of an effects clause that says
+</p>
+
+<blockquote><pre>wait_until(lock, chrono::monotonic_clock::now() + rel_time)
+</pre></blockquote>
+
+<p>
+when <tt>monotonic_clock</tt> is not required to exist?
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="860"></a>860. Floating-Point State</h3>
+<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>
+ <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-06-23</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+There are a number of functions that affect the floating point state.
+These function need to be thread-safe, but I'm unsure of the right
+approach in the standard, as we inherit them from C.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="861"></a>861. Incomplete specification of EqualityComparable for std::forward_list</h3>
+<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>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-06-24</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+Table 89, Container requirements, defines <tt>operator==</tt> in terms of the container
+member function <tt>size()</tt> and the algorithm <tt>std::equal</tt>:
+</p>
+
+<blockquote>
+<tt>==</tt> is an equivalence relation. <tt>a.size() == b.size() &&
+equal(a.begin(), a.end(), b.begin()</tt>
+</blockquote>
+
+<p>
+The new container <tt>forward_list</tt> does not provide a <tt>size</tt> member function
+by design but does provide <tt>operator==</tt> and <tt>operator!=</tt> without specifying it's semantic.
+</p>
+<p>
+Other parts of the (sequence) container requirements do also depend on
+<tt>size()</tt>, e.g. <tt>empty()</tt>
+or <tt>clear()</tt>, but this issue explicitly attempts to solve the missing
+<tt>EqualityComparable</tt> specification,
+because of the special design choices of <tt>forward_list</tt>.
+</p>
+<p>
+I propose to apply one of the following resolutions, which are described as:
+</p>
+
+<ol type="A">
+<li>
+Provide a definition, which is optimal for this special container without
+previous size test. This choice prevents two <tt>O(N)</tt> calls of <tt>std::distance()</tt>
+with the corresponding container ranges and instead uses a special
+<tt>equals</tt> implementation which takes two container ranges instead of 1 1/2.
+</li>
+<li>
+The simple fix where the usual test is adapted such that <tt>size()</tt> is replaced
+by <tt>distance</tt> with corresponding performance disadvantages.
+</li>
+</ol>
+<p>
+Both proposal choices are discussed, the preferred choice of the author is
+to apply (A).
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Common part:
+</p>
+<ul>
+<li>
+<p>
+Just betwen 23.2.3.5 [forwardlist.ops] and 23.2.3.6 [forwardlist.spec]
+add a new
+section "forwardlist comparison operators" [forwardlist.compare] (and
+also add the
+new section number to 23.2.3 [forwardlist]/2 in front of "Comparison operators"):
+</p>
+<blockquote>
+forwardlist comparison operators [forwardlist.compare]
+</blockquote>
+</li>
+</ul>
+
+<p>
+Option (A):
+</p>
+<blockquote>
+<ul>
+<li>
+<p>
+Add to the new section [forwardlist.compare] the following paragraphs:
+</p>
+
+<blockquote>
+<pre>template <class T, class Allocator>
+bool operator==(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y);
+</pre>
+<blockquote>
+<p>
+<i>Requires:</i> Type <tt>T</tt> is <tt>EqualityComparable</tt> ([equalitycomparable]).
+</p>
+<p>
+<i>Returns:</i> <tt>true</tt> if
+</p>
+<ul>
+<li>
+<p>
+for every iterator <tt>i</tt> in the range <tt>[x.begin(), E)</tt>, where <tt>E ==
+x.begin() + M</tt> and <tt>M ==
+ min(distance(x.begin(), x.end()), distance(y.begin(), y.end()))</tt>,
+the following condition holds:
+</p>
+<blockquote><pre>*i == *(y.begin() + (i - x.begin())).
+</pre></blockquote>
+</li>
+<li>
+if <tt>i == E</tt> then <tt>i == x.end() && (y.begin() + (i - x.begin())) == y.end()</tt>.
+</li>
+<li>
+Otherwise, returns <tt>false</tt>.
+</li>
+</ul>
+<p>
+<i>Throws:</i> Nothing unless an exception is thrown by the equality comparison.
+</p>
+<p>
+<i>Complexity:</i> At most <tt>M</tt> comparisons.
+</p>
+</blockquote>
+<pre>template <class T, class Allocator>
+bool operator!=(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y);
+</pre>
+<blockquote>
+<i>Returns:</i> <tt>!(x == y)</tt>.
+</blockquote>
+</blockquote>
+</li>
+</ul>
+</blockquote>
+
+<p>
+Option (B):
+</p>
+<blockquote>
+<ul>
+<li>
+<p>
+Add to the new section [forwardlist.compare] the following paragraphs:
+</p>
+<blockquote>
+<pre>template <class T, class Allocator>
+bool operator==(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y);
+</pre>
+<blockquote>
+<p>
+<i>Requires:</i> Type <tt>T</tt> is <tt>EqualityComparable</tt> ([equalitycomparable]).
+</p>
+<p>
+<i>Returns:</i> <tt>distance(x.begin(), x.end()) == distance(y.begin(), y.end())
+&& equal(x.begin(), x.end(), y.begin())</tt>.
+</p>
+</blockquote>
+<pre>template <class T, class Allocator>
+bool operator!=(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y);
+</pre>
+<blockquote>
+<i>Returns:</i> <tt>!(x == y)</tt>.
+</blockquote>
+</blockquote>
+</li>
+</ul>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="862"></a>862. Impossible complexity for 'includes'</h3>
+<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>
+ <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-07-02</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+In 25.3.5.1 [includes] the complexity is "at most -1 comparisons" if passed
+two empty ranges. I don't know how to perform a negative number of
+comparisions!
+</p>
+
+<p>
+This same issue also applies to:
+</p>
+
+<ul>
+<li><tt>set_union</tt></li>
+<li><tt>set_intersection</tt></li>
+<li><tt>set_difference</tt></li>
+<li><tt>set_symmetric_difference</tt></li>
+<li><tt>merge</tt></li>
+</ul>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="863"></a>863. What is the state of a stream after close() succeeds</h3>
+<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>
+ <b>Submitter:</b> Steve Clamage <b>Date:</b> 2008-07-08</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+Suppose writing to an <tt>[o]fstream</tt> fails and you later close the <tt>stream</tt>.
+The <tt>overflow()</tt> function is called to flush the buffer (if it exists).
+Then the file is unconditionally closed, as if by calling <tt>flcose</tt>.
+</p>
+<p>
+If either <tt>overflow</tt> or <tt>fclose</tt> fails, <tt>close()</tt> reports failure, and clearly
+the <tt>stream</tt> should be in a failed or bad state.
+</p>
+<p>
+Suppose the buffer is empty or non-existent (so that <tt>overflow()</tt> does not
+fail), and <tt>fclose</tt> succeeds. The <tt>close()</tt> function reports success, but
+what is the state of the <tt>stream</tt>?
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="864"></a>864. Defect in atomic wording</h3>
+<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>
+ <b>Submitter:</b> Anthony Williams <b>Date:</b> 2008-07-10</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+There's an error in 29.4 [atomics.types.operations]/p9:
+</p>
+
+<blockquote>
+<pre>C atomic_load(const volatile A * object);
+C atomic_load_explicit(const volatile A * object, memory_order);
+C A ::load(memory_order order = memory_order_seq_cst) const volatile;
+</pre>
+<blockquote>
+<p>
+<i>Requires:</i> The <tt>order</tt> argument shall not be <tt>memory_order_acquire</tt> nor
+<tt>memory_order_acq_rel</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+I believe that this should state
+</p>
+<blockquote>
+shall not be <tt>memory_order_release</tt>.
+</blockquote>
+
+<p>
+There's also an error in 29.4 [atomics.types.operations]/p17:
+</p>
+
+<blockquote>
+... When only one <tt>memory_order</tt> argument is supplied, the value of success
+is <tt>order</tt>, and
+the value of failure is <tt>order</tt> except that a value of
+<tt>memory_order_acq_rel</tt> shall be replaced by the value
+<tt>memory_order_require</tt> ...
+</blockquote>
+<p>
+I believe this should state
+</p>
+<blockquote>
+shall be replaced by the value <tt>memory_order_acquire</tt> ...
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 29.4 [atomics.types.operations]/p9:
+</p>
+
+<blockquote>
+<pre>C atomic_load(const volatile A * object);
+C atomic_load_explicit(const volatile A * object, memory_order);
+C A ::load(memory_order order = memory_order_seq_cst) const volatile;
+</pre>
+<blockquote>
+<p>
+<i>Requires:</i> The <tt>order</tt> argument shall not be <del><tt>memory_order_acquire</tt></del>
+<ins><tt>memory_order_release</tt></ins> nor <tt>memory_order_acq_rel</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+Change 29.4 [atomics.types.operations]/p17:
+</p>
+
+<blockquote>
+... When only one <tt>memory_order</tt> argument is supplied, the value of success
+is <tt>order</tt>, and
+the value of failure is <tt>order</tt> except that a value of
+<tt>memory_order_acq_rel</tt> shall be replaced by the value
+<del><tt>memory_order_require</tt></del> <ins><tt>memory_order_acquire</tt></ins> ...
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="865"></a>865. More algorithms that throw away information</h3>
+<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>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-07-13</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+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
+unnecessarily throw away information. These are typically algorithms,
+which sequentially write into an <tt>OutputIterator</tt>, but do not return the
+final value of this output iterator. These cases are:
+</p>
+
+<ol>
+<li>
+<pre>template<class OutputIterator, class Size, class T>
+void fill_n(OutputIterator first, Size n, const T& value);</pre></li>
+
+<li>
+<pre>template<class OutputIterator, class Size, class Generator>
+void generate_n(OutputIterator first, Size n, Generator gen);</pre></li>
+</ol>
+<p>
+In both cases the minimum requirements on the iterator are
+<tt>OutputIterator</tt>, which means according to the requirements of
+24.1.2 [output.iterators]/2 that only single-pass iterations are guaranteed.
+So, if users of <tt>fill_n</tt> and <tt>generate_n</tt> have *only* an <tt>OutputIterator</tt>
+available, they have no chance to continue pushing further values
+into it, which seems to be a severe limitation to me.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<ol>
+<li>
+<p>
+Replace the current declaration of <tt>fill_n</tt> in 25 [algorithms]/2, header
+<tt><algorithm></tt> synopsis and in 25.2.6 [alg.fill] by
+</p>
+
+<blockquote><pre>template<class OutputIterator, class Size, class T>
+<del>void</del> <ins>OutputIterator</ins> fill_n(OutputIterator first, Size n, const T& value);
+</pre></blockquote>
+<p>
+Just after the effects clause p.2 add a new returns clause saying:
+</p>
+<blockquote>
+<i>Returns:</i> <tt>first + n</tt> for <tt>fill_n</tt>.
+</blockquote>
+</li>
+<li>
+<p>
+Replace the current declaration of <tt>generate_n</tt> in 25 [algorithms]/2, header
+<tt><algorithm></tt> synopsis and in 25.2.7 [alg.generate] by
+</p>
+<blockquote><pre>template<class OutputIterator, class Size, class Generator>
+<del>void</del> <ins>OutputIterator</ins> generate_n(OutputIterator first, Size n, Generator gen);
+</pre></blockquote>
+<p>
+Just after the effects clause p.1 add a new returns clause saying:
+</p>
+<blockquote>
+<i>Returns:</i> <tt>first + n</tt> for <tt>generate_n</tt>.
+</blockquote>
+</li>
+</ol>
+
+
+
+
+
+<hr>
+<h3><a name="866"></a>866. Qualification of placement new-expressions</h3>
+<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>
+ <b>Submitter:</b> Alberto Ganesh Barbati <b>Date:</b> 2008-07-14</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+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
+new-expression in 20.7.5.1 [allocator.members]. I believe the rationale
+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:
+</p>
+<ul>
+<li>
+<p>
+in 20.7.10 [specialized.algorithms], all four algorithms <tt>unitialized_copy</tt>,
+<tt>unitialized_copy_n</tt>, <tt>unitialized_fill</tt> and <tt>unitialized_fill_n</tt> use
+the unqualified placement new-expression in some variation of the form:
+</p>
+<blockquote><pre>new (static_cast<void*>(&*result)) typename iterator_traits<ForwardIterator>::value_type(*first);
+</pre></blockquote>
+</li>
+<li>
+<p>
+in 20.7.12.2.6 [util.smartptr.shared.create] there is a reference to the unqualified placement new-expression:
+</p>
+<blockquote><pre>new (pv) T(std::forward<Args>(args)...),
+</pre></blockquote>
+</li>
+</ul>
+<p>
+I suggest to add qualification in all those places. As far as I know,
+these are all the remaining places in the whole library that explicitly
+use a placement new-expression. Should other uses come out, they should
+be qualified as well.
+</p>
+<p>
+As an aside, a qualified placement new-expression does not need
+additional requirements to be compiled in a constrained context. By
+adding qualification, the <tt>HasPlacementNew</tt> concept introduced recently in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2677.pdf">N2677 (Foundational Concepts)</a>
+would no longer be needed by library and
+should therefore be removed.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Replace "<tt>new</tt>" with "<tt>::new</tt>" in:
+</p>
+<ul>
+<li>
+20.7.10.1 [uninitialized.copy], paragraphs 1 and 3
+</li>
+<li>
+20.7.10.2 [uninitialized.fill] paragraph 1
+</li>
+<li>
+20.7.10.3 [uninitialized.fill.n] paragraph 1
+</li>
+<li>
+20.7.12.2.6 [util.smartptr.shared.create] once in paragraph 1 and twice in paragraph 2.
+</li>
+</ul>
+
+
+
+
+
+
+<hr>
+<h3><a name="867"></a>867. Valarray and value-initialization</h3>
+<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>
+ <b>Submitter:</b> Alberto Ganesh Barbati <b>Date:</b> 2008-07-20</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+From 26.5.2.1 [valarray.cons], paragraph 2:
+</p>
+
+<blockquote><pre>explicit valarray(size_t);
+</pre>
+<blockquote>
+The array created by this constructor has a length equal to the value of the argument. The elements
+of the array are constructed using the default constructor for the instantiating type <tt>T</tt>.
+</blockquote>
+</blockquote>
+
+<p>
+The problem is that the most obvious <tt>T</tt>s for <tt>valarray</tt> are <tt>float</tt>
+and <tt>double</tt>, they don't have a default constructor. I guess the intent is to value-initialize
+the elements, so I suggest replacing:
+</p>
+
+<blockquote>
+The elements of the array are constructed using the default constructor for the instantiating type <tt>T</tt>.
+</blockquote>
+<p>
+with
+</p>
+<blockquote>
+The elements of the array are value-initialized.
+</blockquote>
+
+<p>
+There is another reference to the default constructor of <tt>T</tt> in the non-normative note in paragraph 9.
+That reference should also be replaced. (The normative wording in paragraph 8 refers to <tt>T()</tt>
+and so it doesn't need changes).
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 26.5.2.1 [valarray.cons], paragraph 2:
+</p>
+
+<blockquote>
+<pre>explicit valarray(size_t);
+</pre>
+<blockquote>
+The array created by this constructor has a length equal to the value of the argument. The elements
+of the array are <del>constructed using the default constructor for the instantiating type <tt>T</tt></del>
+<ins>value-initialized (8.5 [dcl.init])</ins>.
+</blockquote>
+</blockquote>
+
+<p>
+Change 26.5.2.7 [valarray.members], paragraph 9:
+</p>
+
+<blockquote>
+[<i>Example:</i> If the argument has the value -2, the first two elements of the result will be <del>constructed using the
+default constructor</del>
+<ins>value-initialized (8.5 [dcl.init])</ins>;
+the third element of the result will be assigned the value of the first element of the argument; etc. <i>-- end example</i>]
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="868"></a>868. default construction and value-initialization</h3>
+<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>
+ <b>Submitter:</b> Alberto Ganesh Barbati <b>Date:</b> 2008-07-22</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+The term "default constructed" is often used in wording that predates
+the introduction of the concept of value-initialization. In a few such
+places the concept of value-initialization is more correct than the
+current wording (for example when the type involved can be a built-in)
+so a replacement is in order. Two of such places are already covered by
+issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</a>. This issue deliberately addresses the hopefully
+non-controversial changes in the attempt of being approved more quickly.
+A few other occurrences (for example in <tt>std::tuple</tt>,
+<tt>std::reverse_iterator</tt> and <tt>std::move_iterator</tt>) are left to separate
+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
+related with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.1.1 [utility.arg.requirements], paragraph 2:
+</p>
+
+<blockquote>
+In general, a default constructor is not required. Certain container class member function signatures specify
+<del>the default constructor</del>
+<ins><tt>T()</tt></ins>
+as a default argument. <tt>T()</tt> shall be a well-defined expression (8.5 [dcl.init]) if one of
+those signatures is called using the default argument (8.3.6 [dcl.fct.default]).
+</blockquote>
+
+<p>
+In all the following paragraphs in clause 23 [containers], replace "default constructed" with "value-initialized
+(8.5 [dcl.init])":
+</p>
+
+<ul>
+<li>23.2.2.1 [deque.cons] para 2</li>
+<li>23.2.2.2 [deque.capacity] para 1</li>
+<li>23.2.3.1 [forwardlist.cons] para 3</li>
+<li>23.2.3.4 [forwardlist.modifiers] para 21</li>
+<li>23.2.4.1 [list.cons] para 3</li>
+<li>23.2.4.2 [list.capacity] para 1</li>
+<li>23.2.6.1 [vector.cons] para 3</li>
+<li>23.2.6.2 [vector.capacity] para 10</li>
+</ul>
+
+
+
+
+
+<hr>
+<h3><a name="869"></a>869. Bucket (local) iterators and iterating past end</h3>
+<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>
+ <b>Submitter:</b> Sohail Somani <b>Date:</b> 2008-07-22</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+Is there any language in the current draft specifying the behaviour of the following snippet?
+</p>
+
+<blockquote><pre>unordered_set<int> s;
+unordered_set<int>::local_iterator it = s.end(0);
+
+// Iterate past end - the unspecified part
+it++;
+</pre></blockquote>
+
+<p>
+I don't think there is anything about <tt>s.end(n)</tt> being considered an
+iterator for the past-the-end value though (I think) it should be.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change Table 97 "Unordered associative container requirements" in 23.1.5 [unord.req]:
+</p>
+
+<blockquote>
+<table border="1">
+<caption>Table 97: Unordered associative container requirements</caption>
+<tbody><tr>
+<th>expression</th><th>return type</th><th>assertion/note pre/post-condition</th><th>complexity</th>
+</tr>
+<tr>
+<td><tt>b.begin(n)</tt></td>
+<td><tt>local_iterator</tt><br><tt>const_local_iterator</tt> for const <tt>b</tt>.</td>
+<td>Pre: n shall be in the range [0,b.bucket_count()). <del>Note: [b.begin(n), b.end(n)) is a
+valid range containing all of the elements in the n<sup>th</sup> bucket.</del>
+<ins><tt>b.begin(n)</tt> returns an iterator referring to the first element in the bucket.
+If the bucket is empty, then <tt>b.begin(n) == b.end(n)</tt>.</ins></td>
+<td>Constant</td>
+</tr>
+<tr>
+<td><tt>b.end(n)</tt></td>
+<td><tt>local_iterator</tt><br><tt>const_local_iterator</tt> for const <tt>b</tt>.</td>
+<td>Pre: n shall be in the range <tt>[0, b.bucket_count())</tt>.
+<ins><tt>b.end(n)</tt> returns an iterator which is the past-the-end value for the bucket.</ins></td>
+<td>Constant</td>
+</tr>
+</tbody></table>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="870"></a>870. Do unordered containers not support function pointers for predicate/hasher?</h3>
+<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>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-08-17</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+Good ol' associative containers allow both function pointers and
+function objects as feasible
+comparators, as described in 23.1.4 [associative.reqmts]/2:
+</p>
+
+<blockquote>
+Each associative container is parameterized on <tt>Key</tt> and an ordering
+relation <tt>Compare</tt> that
+induces a strict weak ordering (25.3) on elements of Key. [..]. The
+object of type <tt>Compare</tt> is
+called the comparison object of a container. This comparison object
+may be a pointer to
+function or an object of a type with an appropriate function call operator.[..]
+</blockquote>
+
+<p>
+The corresponding wording for unordered containers is not so clear,
+but I read it to disallow
+function pointers for the hasher and I miss a clear statement for the
+equality predicate, see
+23.1.5 [unord.req]/3+4+5:
+</p>
+
+<blockquote>
+<p>
+Each unordered associative container is parameterized by <tt>Key</tt>, by a
+function object <tt>Hash</tt> that
+acts as a hash function for values of type <tt>Key</tt>, and by a binary
+predicate <tt>Pred</tt> that induces an
+equivalence relation on values of type <tt>Key</tt>.[..]
+</p>
+<p>
+A hash function is a function object that takes a single argument of
+type <tt>Key</tt> and returns a
+value of type <tt>std::size_t</tt>.
+</p>
+<p>
+Two values <tt>k1</tt> and <tt>k2</tt> of type <tt>Key</tt> are considered equal if the
+container's equality function object
+returns <tt>true</tt> when passed those values.[..]
+</p>
+</blockquote>
+
+<p>
+and table 97 says in the column "assertion...post-condition" for the
+expression X::hasher:
+</p>
+
+<blockquote>
+<tt>Hash</tt> shall be a unary function object type such that the expression
+<tt>hf(k)</tt> has type <tt>std::size_t</tt>.
+</blockquote>
+
+<p>
+Note that 20.6 [function.objects]/1 defines as "Function objects are
+objects with an <tt>operator()</tt> defined.[..]"
+</p>
+<p>
+Does this restriction exist by design or is it an oversight? If an
+oversight, I suggest that to apply
+the following
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 23.1.5 [unord.req]/3, just after the second sentence which is written as
+</p>
+
+<blockquote>
+Additionally, <tt>unordered_map</tt> and <tt>unordered_multimap</tt> associate an
+arbitrary mapped type <tt>T</tt> with the <tt>Key</tt>.
+</blockquote>
+
+<p>
+add one further sentence:
+</p>
+
+<blockquote>
+Both <tt>Hash</tt> and <tt>Pred</tt> may be pointers to function or objects of a type
+with an appropriate function call operator.
+</blockquote>
+
+<p>
+[Note1: Since the detailed requirements for <tt>Pred</tt> and <tt>Hash</tt> are given in
+p.4 and p.5, it an alternative resolution
+would be to insert a new paragraph just after p.5, which contains the
+above proposed sentence]
+</p>
+<p>
+[Note2: I do not propose a change of above quoted element in table 97,
+because the mis-usage of the
+notion of "function object" seems already present in the standard at
+several places, even if it includes
+function pointers, see e.g. 25 [algorithms]/7. The important point is
+that in those places a statement is
+given that the actually used symbol, like "Predicate" applies for
+function pointers as well]
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="871"></a>871. Iota's requirements on T are too strong</h3>
+<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>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-08-20</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+According to the recent WP
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>,
+26.6.5 [numeric.iota]/1, the requires clause
+of <tt>std::iota</tt> says:
+</p>
+
+<blockquote>
+<tt>T</tt> shall meet the requirements of <tt>CopyConstructible</tt> and <tt>Assignable</tt> types, and
+shall be convertible to <tt>ForwardIterator</tt>'s value type.[..]
+</blockquote>
+
+<p>
+Neither <tt>CopyConstructible</tt> nor <tt>Assignable</tt> is needed, instead <tt>MoveConstructible</tt>
+seems to be the correct choice. I guess the current wording resulted as an
+artifact from comparing it with similar numerical algorithms like <tt>accumulate</tt>.
+</p>
+
+<p>
+Note: If this function will be conceptualized, the here proposed
+<tt>MoveConstructible</tt>
+requirement can be removed, because this is an implied requirement of
+function arguments, see
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2710.pdf">N2710</a>/[temp.req.impl]/3, last bullet.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+Change the first sentence of 26.6.5 [numeric.iota]/1:
+</p>
+
+<blockquote>
+<i>Requires:</i> <tt>T</tt> shall <del>meet the requirements of
+<tt>CopyConstructible</tt> and <tt>Assignable</tt> types,</del>
+<ins>
+be <tt>MoveConstructible</tt> (Table 34)
+</ins>
+and shall be
+convertible to <tt>ForwardIterator</tt>'s value type. [..]
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="872"></a>872. <tt>move_iterator::operator[]</tt> has wrong return type</h3>
+<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>
+ <b>Submitter:</b> Doug Gregor <b>Date:</b> 2008-08-21</p>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+<tt>move_iterator</tt>'s <tt>operator[]</tt> is declared as:
+</p>
+
+<blockquote><pre>reference operator[](difference_type n) const;
+</pre></blockquote>
+
+<p>
+This has the same problem that <tt>reverse_iterator</tt>'s <tt>operator[]</tt> used to
+have: if the underlying iterator's <tt>operator[]</tt> returns a proxy, the
+implicit conversion to <tt>value_type&&</tt> could end up referencing a temporary
+that has already been destroyed. This is essentially the same issue that
+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>.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 24.4.3.1 [move.iterator] and 24.4.3.3.12 [move.iter.op.index], change the declaration of
+<tt>move_iterator</tt>'s <tt>operator[]</tt> to:
+</p>
+
+<blockquote><pre><del>reference</del> <ins><i>unspecified</i></ins> operator[](difference_type n) const;
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="873"></a>873. signed integral type and unsigned integral type are not clearly defined</h3>
+<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>
+ <b>Submitter:</b> Travis Vitek <b>Date:</b> 2008-06-30</p>
+<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>
+<p><b>Discussion:</b></p>
+ <p>
+ Neither the term "signed integral type" nor the term "unsigned
+ integral type" is defined in the core language section of the
+ standard, therefore the library section should avoid its use. The
+ terms <i>signed integer type</i> and <i>unsigned integer type</i> are
+ indeed defined (in 3.9.1 [basic.fundamental]), thus the usages should be
+ replaced accordingly.
+ </p>
+
+ <p>
+ Note that the key issue here is that "signed" + "integral type" !=
+ "signed integral type".
+
+ The types <code>bool</code>, <code>char</code>, <code>char16_t</code>,
+ <code>char32_t</code> and <code>wchar_t</code> are all listed as
+ integral types, but are neither of <i>signed integer type</i> or
+ <i>unsigned integer type</i>. According to 3.9 [basic.types] p7, a synonym for
+ integral type is <i>integer type</i>.
+
+ Given this, one may choose to assume that an <i>integral type</i> that
+ can represent values less than zero is a <i>signed integral type</i>.
+ Unfortunately this can cause ambiguities.
+
+ As an example, if <code>T</code> is <code>unsigned char</code>, the
+ expression <code>make_signed<T>::type</code>, is supposed to
+ name a signed integral type. There are potentially two types that
+ satisfy this requirement, namely <code>signed char</code> and
+ <code>char</code> (assuming <code>CHAR_MIN < 0</code>).
+ </p>
+
+
+ <p><b>Proposed resolution:</b></p>
+ <p>
+ I propose to use the terms "signed integer type" and "unsigned integer
+ type" in place of "signed integral type" and "unsigned integral type"
+ to eliminate such ambiguities.
+ </p>
+
+ <p>
+ The proposed change makes it absolutely clear that the difference
+ between two pointers cannot be <tt>char</tt> or <tt>wchar_t</tt>,
+ but could be any of the signed integer types.
+ 5.7 [expr.add] paragraph 6...
+ </p>
+ <blockquote>
+ <p>
+ </p><ol>
+ <li>
+ When two pointers to elements of the same array object are
+ subtracted, the result is the difference of the subscripts of
+ the two array elements. The type of the result is an
+ implementation-defined <del>signed integral
+ type</del><ins>signed integer type</ins>; this type shall be the
+ same type that is defined as <code>std::ptrdiff_t</code> in the
+ <code><cstdint></code> header (18.1)...
+ </li>
+ </ol>
+
+ </blockquote>
+
+ <p>
+ The proposed change makes it clear that <tt>X::size_type</tt> and
+ <tt>X::difference_type</tt> cannot be <tt>char</tt> or
+ <tt>wchar_t</tt>, but could be one of the signed or unsigned integer
+ types as appropriate.
+ 20.1.2 [allocator.requirements] table 40...
+ </p>
+ <blockquote>
+ Table 40: Allocator requirements
+ <table border="1">
+ <thead>
+ <tr>
+ <th>expression</th>
+ <th>return type</th>
+ <th>assertion/note/pre/post-condition</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td><tt>X::size_type</tt></td>
+ <td>
+ <del>unsigned integral type</del>
+ <ins>unsigned integer type</ins>
+ </td>
+ <td>a type that can represent the size of the largest object in
+ the allocation model.</td>
+ </tr>
+ <tr>
+ <td><tt>X::difference_type</tt></td>
+ <td>
+ <del>signed integral type</del>
+ <ins>signed integer type</ins>
+ </td>
+ <td>a type that can represent the difference between any two
+ pointers in the allocation model.</td>
+ </tr>
+ </tbody>
+ </table>
+ </blockquote>
+
+ <p>
+ The proposed change makes it clear that <tt>make_signed<T>::type</tt>
+ must be one of the signed integer types as defined in 3.9.1. Ditto for
+ <tt>make_unsigned<T>type</tt> and unsigned integer types.
+ 20.5.6.3 [meta.trans.sign] table 48...
+ </p>
+ <blockquote>
+ Table 48: Sign modifications
+ <table border="1">
+ <thead>
+ <tr>
+ <th>Template</th>
+ <th>Comments</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>
+ <tt>template <class T> struct make_signed;</tt>
+ </td>
+ <td>
+ If <code>T</code> names a (possibly cv-qualified) <del>signed
+ integral type</del><ins>signed integer type</ins> (3.9.1) then
+ the member typedef <code>type</code> shall name the type
+ <code>T</code>; otherwise, if <code>T</code> names a (possibly
+ cv-qualified) <del>unsigned integral type</del><ins>unsigned
+ integer type</ins> then <code>type</code> shall name the
+ corresponding <del>signed integral type</del><ins>signed
+ integer type</ins>, with the same cv-qualifiers as
+ <code>T</code>; otherwise, <code>type</code> shall name the
+ <del>signed integral type</del><ins>signed integer type</ins>
+ with the smallest rank (4.13) for which <code>sizeof(T) ==
+ sizeof(type)</code>, with the same cv-qualifiers as
+ <code>T</code>.
+
+ <i>Requires:</i> <code>T</code> shall be a (possibly
+ cv-qualified) integral type or enumeration but not a
+ <code>bool</code> type.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <tt>template <class T> struct make_unsigned;</tt>
+ </td>
+ <td>
+ If <code>T</code> names a (possibly cv-qualified)
+ <del>unsigned integral type</del><ins>unsigned integer
+ type</ins> (3.9.1) then the member typedef <code>type</code>
+ shall name the type <code>T</code>; otherwise, if
+ <code>T</code> names a (possibly cv-qualified) <del>signed
+ integral type</del><ins>signed integer type</ins> then
+ <code>type</code> shall name the corresponding <del>unsigned
+ integral type</del><ins>unsigned integer type</ins>, with the
+ same cv-qualifiers as <code>T</code>; otherwise,
+ <code>type</code> shall name the <del>unsigned integral
+ type</del><ins>unsigned integer type</ins> with the smallest
+ rank (4.13) for which <code>sizeof(T) == sizeof(type)</code>,
+ with the same cv-qualifiers as <code>T</code>.
+
+ <i>Requires:</i> <code>T</code> shall be a (possibly
+ cv-qualified) integral type or enumeration but not a
+ <code>bool</code> type.
+ </td>
+ </tr>
+ </tbody>
+ </table>
+ </blockquote>
+
+
+ <p>
+ Note: I believe that the basefield values should probably be
+ prefixed with <tt>ios_base::</tt> as they are in 22.2.2.2.2 [facet.num.put.virtuals]
+
+ The listed virtuals are all overloaded on signed and unsigned integer
+ types, the new wording just maintains consistency.
+
+ 22.2.2.1.2 [facet.num.get.virtuals] table 78...
+ </p>
+ <blockquote>
+ Table 78: Integer Conversions
+ <table border="1">
+ <thead>
+ <tr>
+ <th>State</th>
+ <th><tt>stdio</tt> equivalent</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td><tt>basefield == oct</tt></td>
+ <td><tt>%o</tt></td>
+ </tr>
+ <tr>
+ <td><tt>basefield == hex</tt></td>
+ <td><tt>%X</tt></td>
+ </tr>
+ <tr>
+ <td><tt>basefield == 0</tt></td>
+ <td><tt>%i</tt></td>
+ </tr>
+ <tr>
+ <td><del>signed integral type</del><ins>signed integer
+ type</ins></td>
+ <td><tt>%d</tt></td>
+ </tr>
+ <tr>
+ <td><del>unsigned integral type</del><ins>unsigned integer
+ type</ins></td>
+ <td><tt>%u</tt></td>
+ </tr>
+ </tbody>
+ </table>
+ </blockquote>
+
+
+
+ <p>
+ Rationale is same as above.
+ 22.2.2.2.2 [facet.num.put.virtuals] table 80...
+ </p>
+ <blockquote>
+ Table 80: Integer Conversions
+ <table border="1">
+ <thead>
+ <tr>
+ <th>State</th>
+ <th><tt>stdio</tt> equivalent</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td><tt>basefield == ios_base::oct</tt></td>
+ <td><tt>%o</tt></td>
+ </tr>
+ <tr>
+ <td><tt>(basefield == ios_base::hex) &&
+ !uppercase</tt></td>
+ <td><tt>%x</tt></td>
+ </tr>
+ <tr>
+ <td><tt>(basefield == ios_base::hex)</tt></td>
+ <td><tt>%X</tt></td>
+ </tr>
+ <tr>
+ <td><tt>basefield == 0</tt></td>
+ <td><tt>%i</tt></td>
+ </tr>
+ <tr>
+ <td>for a <del>signed integral type</del><ins>signed integer
+ type</ins></td>
+ <td><tt>%d</tt></td>
+ </tr>
+ <tr>
+ <td>for a <del>unsigned integral type</del><ins>unsigned integer
+ type</ins></td>
+ <td><tt>%u</tt></td>
+ </tr>
+ </tbody>
+ </table>
+ </blockquote>
+
+
+ <p>
+ 23.1 [container.requirements] table 80...
+ </p>
+ <blockquote>
+ Table 89: Container requirements
+ <table border="1">
+ <thead>
+ <tr>
+ <th>expression</th>
+ <th>return type</th>
+ <th>operational semantics</th>
+ <th>assertion/note/pre/post-condition</th>
+ <th>complexity</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td><tt>X::difference_type</tt></td>
+ <td><del>signed integral type</del><ins>signed integer type</ins></td>
+ <td> </td>
+ <td>is identical to the difference type of <tt>X::iterator</tt>
+ and <tt>X::const_iterator</tt></td>
+ <td>compile time</td>
+ </tr>
+ <tr>
+ <td><tt>X::size_type</tt></td>
+ <td><del>unsigned integral type</del><ins>unsigned integer type</ins></td>
+ <td> </td>
+ <td><tt>size_type</tt> can represent any non-negative value of
+ <tt>difference_type</tt></td>
+ <td>compile time</td>
+ </tr>
+ </tbody>
+ </table>
+ </blockquote>
+
+ <p>
+ 24.1 [iterator.requirements] paragraph 1...
+ </p>
+ <blockquote>
+ Iterators are a generalization of pointers that allow a C++ program to
+ work with different data structures (containers) in a uniform manner.
+ To be able to construct template algorithms that work correctly and
+ efficiently on different types of data structures, the library
+ formalizes not just the interfaces but also the semantics and
+ complexity assumptions of iterators. All input iterators
+ <code>i</code> support the expression <code>*i</code>, resulting in a
+ value of some class, enumeration, or built-in type <code>T</code>,
+ called the <i>value type</i> of the iterator. All output iterators
+ support the expression <code>*i = o</code> where <code>o</code> is a
+ value of some type that is in the set of types that are
+ <i>writable</i> to the particular iterator type of <code>i</code>. All
+ iterators <code>i</code> for which the expression <code>(*i).m</code>
+ is well-defined, support the expression <code>i->m</code> with the
+ same semantics as <code>(*i).m</code>. For every iterator type
+ <code>X</code> for which equality is defined, there is a corresponding
+ <del>signed integral type</del> <ins>signed integer type</ins> called
+ the <i>difference type</i> of the iterator.
+ </blockquote>
+
+ <p>
+ I'm a little unsure of this change. Previously this paragraph would
+ allow instantiations of <tt>linear_congruential_engine</tt> on
+ <tt>char</tt>, <tt>wchar_t</tt>, <tt>bool</tt>, and other types. The
+ new wording prohibits this.
+ 26.4.3.1 [rand.eng.lcong] paragraph 2...
+ </p>
+ <blockquote>
+ The template parameter <code>UIntType</code> shall denote an
+ <del>unsigned integral type</del><ins>unsigned integer type</ins>
+ large enough to store values as large as <code>m - 1</code>. If the
+ template parameter <code>m</code> is 0, the modulus <code>m</code>
+ used throughout this section 26.4.3.1 is
+ <code>numeric_limits<result_type>::max()</code> plus 1. [Note:
+ The result need not be representable as a value of type
+ <code>result_type</code>. --end note] Otherwise, the following
+ relations shall hold: <code>a < m</code> and <code>c <
+ m</code>.
+ </blockquote>
+
+ <p>
+ Same rationale as the previous change.
+ 26.4.4.4 [rand.adapt.xor] paragraph 6...
+ </p>
+ <blockquote>
+ Both <code>Engine1::result_type</code> and
+ <code>Engine2::result_type</code> shall denote (possibly different)
+ <del>unsigned integral types</del><ins>unsigned integer types</ins>.
+ The member <i>result_type</i> shall denote either the type
+ <i>Engine1::result_type</i> or the type <i>Engine2::result_type</i>,
+ whichever provides the most storage according to clause 3.9.1.
+ </blockquote>
+
+ <p>
+ 26.4.7.1 [rand.util.seedseq] paragraph 7...
+ </p>
+ <blockquote>
+ <i>Requires:</i><code>RandomAccessIterator</code> shall meet the
+ requirements of a random access iterator (24.1.5) such that
+ <code>iterator_traits<RandomAccessIterator>::value_type</code>
+ shall denote an <del>unsigned integral type</del><ins>unsigned integer
+ type</ins> capable of accomodating 32-bit quantities.
+ </blockquote>
+
+ <p>
+ By making this change, integral types that happen to have a signed
+ representation, but are not signed integer types, would no longer be
+ required to use a two's complement representation. This may go against
+ the original intent, and should be reviewed.
+ 29.4 [atomics.types.operations] paragraph 24...
+ </p>
+ <blockquote>
+ <i>Remark:</i> For <del>signed integral types</del><ins>signed integer
+ types</ins>, arithmetic is defined using two's complement
+ representation. There are no undefined results. For address types, the
+ result may be an undefined address, but the operations otherwise have
+ no undefined behavior.
+ </blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="874"></a>874. Missing <tt>initializer_list</tt> constructor for <tt>discrete_distribution</tt></h3>
+<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>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-08-22</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+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
+subrequest that adds initializer list support to
+<tt>discrete_distribution</tt>, specifically,
+the issue proposed to add a c'tor taking a <tt>initializer_list<double></tt>.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<ol>
+<li>
+<p>
+In 26.4.8.5.1 [rand.dist.samp.discrete]/1, class <tt>discrete_distribution</tt>,
+just <em>before</em> the member declaration
+</p>
+
+<blockquote><pre>explicit discrete_distribution(const param_type& parm);
+</pre></blockquote>
+
+<p>
+insert
+</p>
+
+<blockquote><pre>discrete_distribution(initializer_list<double> wl);
+</pre></blockquote>
+</li>
+
+<li>
+<p>
+Between p.4 and p.5 of the same section insert a new
+paragraph as part of the new member description:
+</p>
+
+<blockquote><pre>discrete_distribution(initializer_list<double> wl);
+</pre>
+
+<blockquote>
+<i>Effects:</i> Same as <tt>discrete_distribution(wl.begin(), wl.end())</tt>.
+</blockquote>
+</blockquote>
+</li>
+</ol>
+
+
+
+
+
+<hr>
+<h3><a name="875"></a>875. Missing <tt>initializer_list</tt> constructor for <tt>piecewise_constant_distribution</tt></h3>
+<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>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-08-22</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+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#794">794</a> a subrequest that adds initializer list support to
+<tt>piecewise_constant_distribution</tt>, specifically, the issue proposed
+to add a c'tor taking a <tt>initializer_list<double></tt> and a <tt>Callable</tt> to evaluate
+weight values. For consistency with the remainder of this class and
+the remainder of the <tt>initializer_list</tt>-aware library the author decided to
+change the list argument type to the template parameter <tt>RealType</tt>
+instead. For the reasoning to use <tt>Func</tt> instead of <tt>Func&&</tt> as c'tor
+function argument see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<ol>
+<li>
+<p>
+In 26.4.8.5.2 [rand.dist.samp.pconst]/1, class <tt>piecewise_constant_distribution</tt>,
+just <em>before</em> the member declaration
+</p>
+
+<blockquote><pre>explicit piecewise_constant_distribution(const param_type& parm);
+</pre></blockquote>
+
+<p>
+insert
+</p>
+
+<blockquote><pre>template<typename Func>
+piecewise_constant_distribution(initializer_list<RealType> bl, Func fw);
+</pre></blockquote>
+</li>
+
+<li>
+<p>
+Between p.4 and p.5 of the same section insert a series of
+new paragraphs nominated below as [p5_1], [p5_2], and [p5_3]
+as part of the new member description:
+</p>
+
+<blockquote><pre>template<typename Func>
+piecewise_constant_distribution(initializer_list<RealType> bl, Func fw);
+</pre>
+
+<blockquote>
+
+<p>
+[p5_1] <i>Complexity:</i> Exactly <tt>nf = max(bl.size(), 1) - 1</tt> invocations of <tt>fw</tt>.
+</p>
+
+<p>
+[p5_2] <i>Requires:</i>
+</p>
+
+<ol type="a">
+<li>
+<tt>fw</tt> shall be callable with one argument of type <tt>RealType</tt>, and shall
+ return values of a type convertible to <tt>double</tt>;
+</li>
+<li>
+The relation <tt>0 < S = w<sub>0</sub>+. . .+w<sub>n-1</sub></tt> shall hold.
+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
+ value <tt><i>w<sub>k</sub></i></tt> that is non-negative, non-NaN, and non-infinity;
+</li>
+<li>
+If <tt>nf > 0</tt> let <tt>b<sub><i>k</i></sub> = *(bl.begin() + k), k = 0, . . . , bl.size()-1</tt> and the
+following relations shall hold for <tt>k = 0, . . . , nf-1: b<sub><i>k</i></sub> < b<sub><i>k+1</i></sub></tt>.
+</li>
+</ol>
+
+<p>
+[p5_3] <i>Effects:</i>
+</p>
+
+<ol type="a">
+<li>
+<p>If <tt>nf == 0</tt>,</p>
+<ol type="a">
+<li>
+lets the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist of the single
+ value <tt>w<sub>0</sub> = 1</tt>, and
+</li>
+<li>
+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>.
+</li>
+</ol>
+</li>
+
+<li>
+<p>Otherwise,</p>
+<ol type="a">
+<li>
+sets <tt>n = nf</tt>, and <tt>[bl.begin(), bl.end())</tt> shall form the sequence <tt>b</tt> of
+length <tt>n+1</tt>, and
+</li>
+<li>
+<p>lets the sequences <tt>w</tt> have length <tt>n</tt> and for each <tt>k = 0, . . . ,n-1</tt>,
+ calculates:</p>
+<blockquote><pre>x<sub><i>k</i></sub> = 0.5*(b<sub><i>k+1</i></sub> + b<sub><i>k</i></sub>)
+w<sub><i>k</i></sub> = fw(x<sub><i>k</i></sub>)
+</pre></blockquote>
+</li>
+</ol>
+</li>
+
+<li>
+<p>
+Constructs a <tt>piecewise_constant_distribution</tt> object with
+the above computed sequence <tt>b</tt> as the interval boundaries
+and with the probability densities:
+</p>
+<blockquote><pre>ρ<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.
+</pre></blockquote>
+
+</li>
+</ol>
+
+</blockquote>
+</blockquote>
+</li>
+</ol>
+
+
+
+
+
+<hr>
+<h3><a name="876"></a>876. <tt>basic_string</tt> access operations should give stronger guarantees</h3>
+<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>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-08-22</p>
+<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>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+<p>
+During the Sophia Antipolis meeting it was decided to split-off some
+parts of the
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2647.html">n2647</a>
+("Concurrency modifications for <tt>basic_string</tt>")
+proposal into a separate issue, because these weren't actually
+concurrency-related. The here proposed changes refer to the recent
+update document
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2668.htm">n2668</a>
+and attempt to take advantage of the
+stricter structural requirements.
+</p>
+<p>
+Indeed there exists some leeway for more guarantees that would be
+very useful for programmers, especially if interaction with transactionary
+or exception-unaware C API code is important. This would also allow
+compilers to take advantage of more performance optimizations, because
+more functions can have throw() specifications. This proposal uses the
+form of "Throws: Nothing" clauses to reach the same effect, because
+there already exists a different issue in progress to clean-up the current
+existing "schizophrenia" of the standard in this regard.
+</p>
+<p>
+Due to earlier support for copy-on-write, we find the following
+unnecessary limitations for C++0x:
+</p>
+
+<ol>
+<li>
+Missing no-throw guarantees: <tt>data()</tt> and <tt>c_str()</tt> simply return
+a pointer to their guts, which is a non-failure operation. This should
+be spelled out. It is also noteworthy to mention that the same
+guarantees should also be given by the size query functions,
+because the combination of pointer to content and the length is
+typically needed during interaction with low-level API.
+</li>
+<li>
+Missing complexity guarantees: <tt>data()</tt> and <tt>c_str()</tt> simply return
+a pointer to their guts, which is guaranteed O(1). This should be
+spelled out.
+</li>
+<li>
+Missing reading access to the terminating character: Only the
+const overload of <tt>operator[]</tt> allows reading access to the terminator
+char. For more intuitive usage of strings, reading access to this
+position should be extended to the non-const case. In contrast
+to C++03 this reading access should now be homogeneously
+an lvalue access.
+</li>
+</ol>
+
+<p>
+The proposed resolution is split into a main part (A) and a
+secondary part (B) (earlier called "Adjunct Adjunct Proposal").
+(B) extends (A) by also making access to index position
+size() of the at() overloads a no-throw operation. This was
+separated, because this part is theoretically observable in
+specifically designed test programs.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<ol type="A">
+<li>
+<ol>
+<li>
+<p>In 21.3.4 [string.capacity], just after p. 1 add a new paragraph:
+</p>
+<blockquote>
+<i>Throws:</i> Nothing.
+</blockquote>
+
+</li>
+<li>
+<p>
+In 21.3.5 [string.access] <em>replace</em> p. 1 by the following <em>4</em> paragraghs:
+</p>
+
+<blockquote>
+<p>
+<i>Requires:</i> <tt>pos ≤ size()</tt>.
+</p>
+<p>
+<i>Returns:</i> If <tt>pos < size()</tt>, returns <tt>*(begin() + pos)</tt>. Otherwise, returns
+a reference to a <tt>charT()</tt> that shall not be modified.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+<p>
+<i>Complexity:</i> Constant time.
+</p>
+</blockquote>
+
+</li>
+<li>
+<p>
+In 21.3.7.1 [string.accessors] replace the now <em>common</em> returns
+clause of <tt>c_str()</tt> and <tt>data()</tt> by the following <em>three</em> paragraphs:
+</p>
+<blockquote>
+<p>
+<i>Returns:</i> A pointer <tt>p</tt> such that <tt>p+i == &operator[](i)</tt> for each <tt>i</tt>
+in <tt>[0, size()]</tt>.
+</p>
+<p>
+<i>Throws:</i> Nothing.
+</p>
+<p>
+<i>Complexity:</i> Constant time.
+</p>
+</blockquote>
+</li>
+</ol>
+</li>
+<li>
+<ol start="4">
+<li>
+<p>
+In 21.3.5 [string.access] <em>replace</em> p.2 and p.3 by:
+</p>
+<blockquote>
+<p>
+<i>Requires:</i> <tt>pos ≤ size()</tt>
+</p>
+<p>
+<i>Throws:</i> <tt>out_of_range</tt> if <tt>pos > size()</tt>.
+</p>
+</blockquote>
+</li>
+</ol>
+</li>
+</ol>
+
+
+
+
+
+
+<hr>
+<h3><a name="877"></a>877. to <tt>throw()</tt> or to <i>Throw:</i> Nothing.</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-08-23</p>
+<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>
+<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>
+<p><b>Discussion:</b></p>
+ <p>
+
+Recent changes to
+the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">working
+draft</a> have introduced a gratuitous inconsistency with the C++ 2003
+version of the specification with respect to exception guarantees
+provided by standard functions. While the C++ 2003 standard
+consistenly uses the empty exception specification, <tt>throw()</tt>,
+to declare functions that are guaranteed not to throw exceptions, the
+current working draft contains a number of "<i>Throws:</i> Nothing."
+clause to specify essentially the same requirement. The difference
+between the two approaches is that the former specifies the behavior
+of programs that violate the requirement (<tt>std::unexpected()</tt>
+is called) while the latter leaves the behavior undefined.
+
+ </p>
+ <p>
+
+A survey of the working draft reveals that there are a total of 209
+occurrences of <tt>throw()</tt> in the library portion of the spec,
+the majority in clause 18, a couple (literally) in 19, a handful in
+20, a bunch in 22, four in 24, one in 27, and about a dozen in D.9.
+
+ </p>
+ <p>
+
+There are also 203 occurrences of "<i>Throws:</i> Nothing." scattered
+throughout the spec.
+
+ </p>
+ <p>
+
+While sometimes there are good reasons to use the "<i>Throws:</i>
+Nothing." approach rather than making use of <tt>throw()</tt>, these
+reasons do not apply in most of the cases where this new clause has
+been introduced and the empty exception specification would be a
+better approach.
+
+ </p>
+ <p>
+
+First, functions declared with the empty exception specification
+permit compilers to generate better code for calls to such
+functions. In some cases, the compiler might even be able to eliminate
+whole chunks of user-written code when instantiating a generic
+template on a type whose operations invoked from the template
+specialization are known not to throw. The prototypical example are
+the <tt>std::uninitialized_copy()</tt>
+and <tt>std::uninitialized_fill()</tt> algorithms where the
+entire <tt>catch(...)</tt> block can be optimized away.
+
+ </p>
+ <p>
+
+For example, given the following definition of
+the <tt>std::uninitialized_copy</tt> function template and a
+user-defined type <tt>SomeType</tt>:
+
+ </p>
+ <blockquote>
+ <pre>template <class InputIterator, class ForwardIterator>
+ForwardIterator
+uninitialized_copy (InputIterator first, InputIterator last, ForwardIterator res)
+{
+ typedef iterator_traits<ForwardIterator>::value_type ValueType;
+
+ ForwardIterator start = res;
+
+ try {
+ for (; first != last; ++first, ++res)
+ ::new (&*res) ValueType (*first);
+ }
+ catch (...) {
+ for (; start != res; --start)
+ (&*start)->~ValueType ();
+ throw;
+ }
+ return res;
+}
+
+struct SomeType {
+ SomeType (const SomeType&) <ins>throw ()</ins>;
+}</pre>
+ </blockquote>
+ <p>
+
+compilers are able to emit the following efficient specialization
+of <tt>std::uninitialized_copy<const SomeType*, SomeType*></tt>
+(note that the <tt>catch</tt> block has been optimized away):
+
+ </p>
+ <blockquote>
+ <pre>template <> SomeType*
+uninitialized_copy (const SomeType *first, const SomeType *last, SomeType *res)
+{
+ for (; first != last; ++first, ++res)
+ ::new (res) SomeType (*first);
+
+ return res;
+}</pre>
+ </blockquote>
+ <p>
+
+Another general example is default constructors which, when decorated
+with <tt>throw()</tt>, allow the compiler to eliminate the
+implicit <tt>try</tt> and <tt>catch</tt> blocks that it otherwise must
+emit around each the invocation of the constructor
+in <i>new-expressions</i>.
+
+ </p>
+ <p>
+
+For example, given the following definitions of
+class <tt>MayThrow</tt> and <tt>WontThrow</tt> and the two
+statements below:
+
+ </p>
+ <blockquote>
+ <pre>struct MayThrow {
+ MayThrow ();
+};
+
+struct WontThrow {
+ WontThrow () <ins>throw ()</ins>;
+};
+
+MayThrow *a = new MayThrow [N];
+WontThrow *b = new WontThrow [N];</pre>
+
+ </blockquote>
+ <p>
+
+the compiler generates the following code for the first statement:
+
+ </p>
+ <blockquote>
+ <pre>MayThrow *a;
+{
+ MayThrow *first = operator new[] (N * sizeof (*a));
+ MayThrow *last = first + N;
+ MayThrow *next = first;
+ try {
+ for ( ; next != last; ++next)
+ new (next) MayThrow;
+ }
+ catch (...) {
+ for ( ; first != first; --next)
+ next->~MayThrow ();
+ operator delete[] (first);
+ throw;
+ }
+ a = first;
+}</pre>
+ </blockquote>
+ <p>
+
+but it is can generate much more compact code for the second statement:
+
+ </p>
+ <blockquote>
+ <pre>WontThrow *b = operator new[] (N * sizeof (*b));
+WontThrow *last = b + N;
+for (WontThrow *next = b; next != last; ++next)
+ new (next) WontThrow;
+</pre>
+ </blockquote>
+ <p>
+
+Second, in order for users to get the maximum benefit out of the new
+<tt>std::has_nothrow_xxx</tt> traits when using standard library types
+it will be important for implementations to decorate all non throwing
+copy constructors and assignment operators with <tt>throw()</tt>. Note
+that while an optimizer may be able to tell whether a function without
+an explicit exception specification can throw or not based on its
+definition, it can only do so when it can see the source code of the
+definition. When it can't it must assume that the function may
+throw. To prevent violating the One Definition Rule,
+the <tt>std::has_nothrow_xxx</tt> trait must return the most
+pessimistic guess across all translation units in the program, meaning
+that <tt>std::has_nothrow_xxx<T>::value</tt> must evaluate to
+<tt>false</tt> for any <tt>T</tt> whose <tt>xxx</tt>
+(where <tt>xxx</tt> is default or copy ctor, or assignment operator)
+is defined out-of-line.
+
+ </p>
+ <p>
+
+<b>Counterarguments:</b>
+
+ </p>
+ <p>
+
+During the discussion of this issue
+on <a href="mailto:c++std-lib@accu.org">c++std-lib@accu.org</a>
+(starting with post <tt>c++std-lib-21950</tt>) the following arguments
+in favor of the "<i>Throws:</i> Nothing." style have been made.
+
+ </p>
+ <p>
+ </p><ol>
+ <li>
+
+Decorating functions that cannot throw with the empty exception
+specification can cause the compiler to generate suboptimal code for
+the implementation of the function when it calls other functions that
+aren't known to the compiler not to throw (i.e., that aren't decorated
+with <tt>throw()</tt> even if they don't actually throw). This is a
+common situation when the called function is a C or POSIX function.
+
+ </li>
+ <li>
+
+Alternate, proprietary mechanisms exist (such as
+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>
+or Visual
+C++ <a href="http://msdn.microsoft.com/en-us/library/49147z04%28VS.80%29.aspx"><tt>__declspec(nothrow)</tt></a>)
+that let implementers mark up non-throwing functions, often without
+the penalty mentioned in (1) above. The C++ standard shouldn't
+preclude the use of these potentially more efficient mechanisms.
+
+ </li>
+ <li>
+
+There are functions, especially function templates, that invoke
+user-defined functions that may or may not be
+declared <tt>throw()</tt>. Declaring such functions with the empty
+exception specification will cause compilers to generate suboptimal
+code when the user-defined function isn't also declared not to throw.
+
+ </li>
+ </ol>
+
+ <p>
+
+The answer to point (1) above is that implementers can (and some have)
+declare functions with <tt>throw()</tt> to indicate to the compiler
+that calls to the function can safely be assumed not to throw in order
+to allow it to generate efficient code at the call site without also
+having to define the functions the same way and causing the compiler
+to generate suboptimal code for the function definition. That is, the
+function is declared with <tt>throw()</tt> in a header but it's
+defined without it in the source file. The <tt>throw()</tt>
+declaration is suppressed when compiling the definition to avoid
+compiler errors. This technique, while strictly speaking no permitted
+by the language, is safe and has been employed in practice. For
+example, the GNU C library takes this approach. Microsoft Visual C++
+takes a similar approach by simply assuming that no function with C
+language linkage can throw an exception unless it's explicitly
+declared to do so using the language extension <tt>throw(...)</tt>.
+
+ </p>
+ <p>
+
+Our answer to point (2) above is that there is no existing practice
+where C++ Standard Library implementers have opted to make use of the
+proprietary mechanisms to declare functions that don't throw. The
+language provides a mechanism specifically designed for this
+purpose. Avoiding its use in the specification itself in favor of
+proprietary mechanisms defeats the purpose of the feature. In
+addition, making use of the empty exception specification
+inconsistently, in some areas of the standard, while conspicuously
+avoiding it and making use of the "<i>Throws:</i> Nothing." form in
+others is confusing to users.
+
+ </p>
+ <p>
+
+The answer to point (3) is simply to exercise caution when declaring
+functions and especially function templates with the empty exception
+specification. Functions that required not to throw but that may call
+back into user code are poor candidates for the empty exception
+specification and should instead be specified using "<i>Throws:</i>
+Nothing." clause.
+
+ </p>
+
+ <p><b>Proposed resolution:</b></p>
+ <p>
+
+We propose two possible solutions. Our recommendation is to adopt
+Option 1 below.
+
+ </p>
+ <p>
+
+<b>Option 1:</b>
+
+ </p>
+ <p>
+
+Except for functions or function templates that make calls back to
+user-defined functions that may not be declared <tt>throw()</tt>
+replace all occurrences of the "<i>Throws:</i> Nothing." clause with
+the empty exception specification. Functions that are required not to
+throw but that make calls back to user code should be specified to
+"<i>Throw:</i> Nothing."
+
+ </p>
+ <p>
+
+<b>Option 2:</b>
+
+ </p>
+ <p>
+
+For consistency, replace all occurrences of the empty exception
+specification with a "<i>Throws:</i> Nothing." clause.
+
+ </p>
+
+
+
+
+<hr>
+<h3><a name="878"></a>878. <tt>forward_list</tt> preconditions</h3>
+<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>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-08-23</p>
+<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>
+<p><b>Discussion:</b></p>
+ <p>
+
+<tt>forward_list</tt> member functions that take
+a <tt>forward_list::iterator</tt> (denoted <tt>position</tt> in the
+function signatures) argument have the following precondition:
+
+ </p>
+ <blockquote>
+
+<i>Requires:</i> <tt>position</tt> is dereferenceable or equal
+to <tt>before_begin()</tt>.
+
+ </blockquote>
+ <p>
+
+I believe what's actually intended is this:
+
+ </p>
+ <blockquote>
+
+<i>Requires:</i> <tt>position</tt> is in the range
+[<tt>before_begin()</tt>, <tt>end()</tt>).
+
+ </blockquote>
+ <p>
+
+That is, when it's dereferenceable, <tt>position</tt> must point
+into <tt>*this</tt>, not just any <tt>forward_list</tt> object.
+
+ </p>
+
+ <p><b>Proposed resolution:</b></p>
+ <p>
+
+Change the <i>Requires</i> clause as follows:
+
+ </p>
+ <blockquote>
+
+<i>Requires:</i> <tt>position</tt> is <ins>in the range
+[<tt>before_begin()</tt>, <tt>end()</tt>)</ins> <del>dereferenceable
+or equal to <tt>before_begin()</tt></del>.
+
+ </blockquote>
+
+
+
+
+</body></html>
\ No newline at end of file
projects / msp430-gcc.git / blobdiff