aboutsummaryrefslogtreecommitdiffstats
path: root/gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-active.html
diff options
context:
space:
mode:
Diffstat (limited to 'gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-active.html')
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-active.html19718
1 files changed, 0 insertions, 19718 deletions
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-active.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-active.html
deleted file mode 100644
index 94b57c0a6..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-active.html
+++ /dev/null
@@ -1,19718 +0,0 @@
-<!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 &lt;<a href="mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>&gt;</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&lt;T&gt;::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>&lt;cstdlib&gt;</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&amp; <i>str</i>,
- ios_base::iostate&amp; <i>err</i>, bool&amp; <i>val</i>) const;
-</pre>
-<blockquote>
-<p>
--6- <i>Effects:</i> If
-<tt>(<i>str</i>.flags()&amp;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&lt;numpunct&lt;charT&gt;
-&gt;(<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&lt;bool&gt; 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&lt;bool&gt;</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&lt;bool&gt; 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>
-&nbsp;&nbsp;&nbsp;&nbsp; * Not A Defect.<br>
-&nbsp;&nbsp;&nbsp;&nbsp; * Add a note explaining that vector&lt;bool&gt; does not meet
-Container requirements.<br>
-&nbsp;&nbsp;&nbsp;&nbsp; * Remove vector&lt;bool&gt;.<br>
-&nbsp;&nbsp;&nbsp;&nbsp; * Add a new category of container requirements which
-vector&lt;bool&gt; would meet.<br>
-&nbsp;&nbsp;&nbsp;&nbsp; * Rename vector&lt;bool&gt;.<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&lt;bool&gt; in the next standard. (2)
-Remove vector&lt;bool&gt; in the following standard.]</i></p>
-
-
-<p><i>[Modifying container requirements to permit returning proxies
-(thus allowing container requirements conforming vector&lt;bool&gt;)
-was also discussed.]</i></p>
-
-
-<p><i>[It was also noted that there is a partial but ugly workaround in
-that vector&lt;bool&gt; may be further specialized with a customer
-allocator.]</i></p>
-
-
-<p><i>[Kona: Herb Sutter presented his paper J16/99-0035==WG21/N1211,
-vector&lt;bool&gt;: 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&lt;bool&gt; and introduce this functionality under
- a different name, e.g. bit_vector. This might make it possible to
- remove the vector&lt;bool&gt; 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&lt;bool&gt; 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&lt;bool&gt;</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&nbsp; 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 &lt;&lt; or operator
- &gt;&gt; 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>&nbsp;&nbsp;&nbsp;&nbsp;<tt>openmode mode() const</tt>;</p>
-
-<p><b>&nbsp;&nbsp;&nbsp; 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&lt;&gt;::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&lt;class charT, class traits = char_traits&lt;charT&gt;,
- class Allocator = allocator&lt;charT&gt; &gt;
- 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&lt;class InputIterator&gt;
- void insert(<ins>const_</ins>iterator p, InputIterator first, InputIterator last);
- void insert(<ins>const_</ins>iterator <ins>p</ins>, initializer_list&lt;charT&gt;);
-
- ...
-
- 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&lt;class InputIterator&gt;
- void insert(<ins>const_</ins>iterator p, InputIterator first, InputIterator last);
-void insert(<ins>const_</ins>iterator <ins>p</ins>, initializer_list&lt;charT&gt;);
-</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.&nbsp; A future standard may wish to consider additional
-function objects.</p>
-
-
-
-
-<hr>
-<h3><a name="255"></a>255. Why do <tt>basic_streambuf&lt;&gt;::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&lt;int&gt;::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&amp;. *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&amp; 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&amp;</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&amp;</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&lt;&gt;::sentry
-(27.6.1.1.3 [istream::sentry]) and basic_ostream&lt;&gt;::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&lt;&gt;::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&lt;&gt;::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()-&gt;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&amp; operator&gt;&gt; (istream &amp;strm, S &amp;s)
-{
- ios::iostate err = ios::goodbit;
- try {
- const istream::sentry guard (strm, false);
- if (guard) {
- use_facet&lt;num_get&lt;char&gt; &gt;(strm.getloc ())
- .get (istreambuf_iterator&lt;char&gt;(strm),
- istreambuf_iterator&lt;char&gt;(),
- 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&amp; operator&gt;&gt; (istream &amp;strm, S &amp;s)
-{
- istream::sentry guard (strm, false);
- if (guard) {
- ios::iostate err = ios::goodbit;
- try {
- use_facet&lt;num_get&lt;char&gt; &gt;(strm.getloc ())
- .get (istreambuf_iterator&lt;char&gt;(strm),
- istreambuf_iterator&lt;char&gt;(),
- 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&amp; operator&gt;&gt; (istream &amp;strm, S &amp;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&lt;num_get&lt;char&gt; &gt;(strm.getloc ())
- .get (istreambuf_iterator&lt;char&gt;(strm),
- istreambuf_iterator&lt;char&gt;(),
- strm, err, s.i);
- }
- }
- catch (...) {
- if (thrown &amp;&amp; state &amp; 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&gt;&gt;( T&amp; ) 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&gt;&gt;())
-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()-&gt;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()&amp;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()-&gt;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
-&lt;string&gt;, 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 &lt;memory&gt; from within &lt;string&gt;,
-either directly or indirectly, to bring the declaration of
-std::allocator into scope.
-</p>
-
-<p>
-Additionally, however, some implementation also include &lt;istream&gt; and
-&lt;ostream&gt; at the top of &lt;string&gt; 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
-&lt;iosfwd&gt;, since strictly speaking, only the declarations and not the
-full definitions are necessary.
-</p>
-
-<p>
-Obviously, it is possible to implement &lt;string&gt; 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 &lt;istream&gt; or &lt;ostream&gt;, respectively, it doesn't seem
-reasonable to also expect it to explicitly include &lt;memory&gt;. 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 &lt;string&gt;
-
-extern std::basic_ostream&lt;char&gt; &amp;strm;
-
-int main () {
- strm &lt;&lt; std::string ("Hello, World!\n");
-}
-</pre>
-
-<p>or whether one must explicitly include &lt;memory&gt; or
-&lt;ostream&gt; (or both) in addition to &lt;string&gt; 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 &lt;istream&gt;
-
-extern std::basic_iostream&lt;char&gt; &amp;strm;
-
-int main () {
- strm &lt;&lt; "Hello, World!\n";
-}
-</pre>
-
-<p>
-or whether one needs to explicitly include &lt;ostream&gt;, and
-perhaps even other headers containing the definitions of other
-required templates:</p>
-
-<pre>#include &lt;ios&gt;
-#include &lt;istream&gt;
-#include &lt;ostream&gt;
-#include &lt;streambuf&gt;
-
-extern std::basic_iostream&lt;char&gt; &amp;strm;
-
-int main () {
- strm &lt;&lt; "Hello, World!\n";
-}
-</pre>
-
-<p>Example 3:</p>
-
-<p>Likewise, it seems unclear whether the program below is complete:</p>
-<pre>#include &lt;iterator&gt;
-
-bool foo (std::istream_iterator&lt;int&gt; a, std::istream_iterator&lt;int&gt; b)
-{
- return a == b;
-}
-
-int main () { }
-</pre>
-
-<p>or whether one should be required to include &lt;istream&gt;.</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 |
-+============+====================+
-|&lt;algorithm&gt; | |
-+------------+--------------------+
-|&lt;bitset&gt; | |
-+------------+--------------------+
-|&lt;complex&gt; | |
-+------------+--------------------+
-|&lt;deque&gt; |&lt;memory&gt; |
-+------------+--------------------+
-|&lt;exception&gt; | |
-+------------+--------------------+
-|&lt;fstream&gt; |&lt;ios&gt; |
-+------------+--------------------+
-|&lt;functional&gt;| |
-+------------+--------------------+
-|&lt;iomanip&gt; |&lt;ios&gt; |
-+------------+--------------------+
-|&lt;ios&gt; |&lt;streambuf&gt; |
-+------------+--------------------+
-|&lt;iosfwd&gt; | |
-+------------+--------------------+
-|&lt;iostream&gt; |&lt;istream&gt;, &lt;ostream&gt;|
-+------------+--------------------+
-|&lt;istream&gt; |&lt;ios&gt; |
-+------------+--------------------+
-|&lt;iterator&gt; | |
-+------------+--------------------+
-|&lt;limits&gt; | |
-+------------+--------------------+
-|&lt;list&gt; |&lt;memory&gt; |
-+------------+--------------------+
-|&lt;locale&gt; | |
-+------------+--------------------+
-|&lt;map&gt; |&lt;memory&gt; |
-+------------+--------------------+
-|&lt;memory&gt; | |
-+------------+--------------------+
-|&lt;new&gt; |&lt;exception&gt; |
-+------------+--------------------+
-|&lt;numeric&gt; | |
-+------------+--------------------+
-|&lt;ostream&gt; |&lt;ios&gt; |
-+------------+--------------------+
-|&lt;queue&gt; |&lt;deque&gt; |
-+------------+--------------------+
-|&lt;set&gt; |&lt;memory&gt; |
-+------------+--------------------+
-|&lt;sstream&gt; |&lt;ios&gt;, &lt;string&gt; |
-+------------+--------------------+
-|&lt;stack&gt; |&lt;deque&gt; |
-+------------+--------------------+
-|&lt;stdexcept&gt; | |
-+------------+--------------------+
-|&lt;streambuf&gt; |&lt;ios&gt; |
-+------------+--------------------+
-|&lt;string&gt; |&lt;memory&gt; |
-+------------+--------------------+
-|&lt;strstream&gt; | |
-+------------+--------------------+
-|&lt;typeinfo&gt; |&lt;exception&gt; |
-+------------+--------------------+
-|&lt;utility&gt; | |
-+------------+--------------------+
-|&lt;valarray&gt; | |
-+------------+--------------------+
-|&lt;vector&gt; |&lt;memory&gt; |
-+------------+--------------------+
-</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 &lt;all&gt; 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&lt;T&gt; 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&lt;T&gt; whenever T
-is a numerical datatype. The absence of ways to access individual
-parts of a std::complex&lt;T&gt; 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&lt;T&gt; z;
-// ...
-// set the real part to r
-z = complex&lt;T&gt;(r, z.imag());
-// ...
-// set the imaginary part to i
-z = complex&lt;T&gt;(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&lt;&gt; 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&lt;T&gt; then</p>
-
-<ul>
-<li>the expression reinterpret_cast&lt;cv T(&amp;)[2]&gt;(z)
-is well-formed; and</li>
-<li>reinterpret_cast&lt;cv T(&amp;)[2]&gt;(z)[0]designates the
-real part of z; and</li>
-<li>reinterpret_cast&lt;cv T(&amp;)[2]&gt;(z)[1]designates the
-imaginary part of z.</li>
-</ul>
-
-<p>
-Moreover, if a is an expression of pointer type cv complex&lt;T&gt;*
-and the expression a[i] is well-defined for an integer expression
-i then:
-</p>
-
-<ul>
-<li>reinterpret_cast&lt;cv T*&gt;(a)[2*i] designates the real
-part of a[i]; and</li>
-<li>reinterpret_cast&lt;cv T*&gt;(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&lt;num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt;
- &gt; &gt;
- (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&lt;&lt;(int) will
-set badbit if the disk is full, while operator&lt;&lt;(ostream&amp;,
-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 &lt;class charT, class traits, class Allocator&gt;
- explicit
- bitset(const basic_string&lt;charT, traits, Allocator&gt;&amp; str,
- typename basic_string&lt;charT, traits, Allocator&gt;::size_type pos = 0,
- typename basic_string&lt;charT, traits, Allocator&gt;::size_type n =
- basic_string&lt;charT, traits, Allocator&gt;::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 &lt;class charT, class traits, class Allocator&gt;
- basic_string&lt;charT, traits, Allocator&gt;
- 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 &lt;&lt; x.template to_string&lt;charT,traits,allocator&lt;charT&gt; &gt;(
- use_facet&lt;ctype&lt;charT&gt; &gt;(<i>os</i>.getloc()).widen('0'),
- use_facet&lt;ctype&lt;charT&gt; &gt;(<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() &amp; ios_base::unitbuf) &amp;&amp; !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()-&gt;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&lt;charT, traits&gt;&amp;
- get (char_type*, streamsize, char_type);
- </pre>
- <p>
- Also sets failbit if it fails to extract any characters.
- </p>
- <pre> basic_istream&lt;charT, traits&gt;&amp;
- get (char_type*, streamsize);
- </pre>
- <p>
- Also sets failbit if it fails to extract any characters.
- </p>
- <pre> basic_istream&lt;charT, traits&gt;&amp;
- getline (char_type*, streamsize, char_type);
- </pre>
- <p>
- Also sets failbit if it fails to extract any characters.
- </p>
- <pre> basic_istream&lt;charT, traits&gt;&amp;
- getline (char_type*, streamsize);
- </pre>
- <p>
- Also sets failbit if it fails to extract any characters.
- </p>
- <pre> basic_istream&lt;charT, traits&gt;&amp;
- ignore (int, int_type);
- </pre>
- <pre> basic_istream&lt;charT, traits&gt;&amp;
- 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&lt;charT, traits&gt;&amp;
- get (char_type&amp;);
- </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&lt;charT, traits&gt;&amp;
- get (basic_streambuf&lt;charT, traits&gt;&amp;, char_type);
- </pre>
- <pre> basic_istream&lt;charT, traits&gt;&amp;
- get (basic_streambuf&lt;charT, traits&gt;&amp;);
- </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&lt;reverse_iterator&lt;char*&gt; &gt; 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&lt;&gt; in the default
-constructor. As a result, code like
-</p>
-<blockquote><pre> std::vector&lt;std::reverse_iterator&lt;char*&gt; &gt; 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&lt;std::reverse_iterator&lt;char*&gt; &gt; 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&lt;T&gt; 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 &lt;typename Iterator&gt;
- void f() { std::vector&lt;Iterator&gt; v(7); }
-</pre></blockquote>
-<p>
-evoke undefined behavior for some conforming iterator definitions?
-I think it does, now, because vector&lt;&gt; 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&lt;wchar_t&gt; 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 &lt;sstream&gt;
-#include &lt;cstdio&gt;
-
-int main()
-{
- std::istringstream strm ("1");
-
- int i = 0;
-
- strm &gt;&gt; i;
-
- std::printf ("eof = %d, fail = %d\n",
- !!strm.eof (), !!strm.fail ());
-
- strm &gt;&gt; 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 &gt;&gt; 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&lt;charT,traits&gt;&amp; <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&amp; sb);
-basic_streambuf&amp; operator=(const basic_streambuf&amp; sb);
-</pre>
-</blockquote>
-
-<p>Insert after 27.5.2.1, paragraph 2:</p>
-<blockquote>
-<pre>basic_streambuf(const basic_streambuf&amp; 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&amp; operator=(const basic_streambuf&amp; 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&amp;); // not defined
-basic_stringbuf&amp; operator=(const basic_stringbuf&amp;); // 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&amp; sb);
-basic_stringbuf&amp; operator=(const basic_stringbuf&amp; sb);
-</pre>
-
-<p>27.7.1.1, insert after paragraph 4:</p>
-
-<pre>basic_stringbuf(const basic_stringbuf&amp; 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&amp; operator=(const basic_stringbuf&amp; 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&amp;); // not defined
- basic_filebuf&amp; operator=(const basic_filebuf&amp;); // 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 &gt;= 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 &gt;= 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&lt;charT&gt;::
-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&lt;charT&gt; 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&lt;charT&gt;</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&lt;char&gt; v0("abcdefghijklmnop", 16);
-v0[3] = 'A';
-// v0 == valarray&lt;char&gt;("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&lt;char&gt; v0("abcdefghijklmnop", 16);
-valarray&lt;char&gt; v1("ABCDE", 5);
-v0[slice(2, 5, 3)] = v1;
-// v0 == valarray&lt;char&gt;("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&lt;char&gt; v0("abcdefghijklmnop", 16);
-valarray&lt;char&gt; v1("ABCDEF", 6);
-const size_t lv[] = {2, 3};
-const size_t dv[] = {7, 2};
-const valarray&lt;size_t&gt; len(lv, 2), str(dv, 2);
-v0[gslice(3, len, str)] = v1;
-// v0 == valarray&lt;char&gt;("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&lt;char&gt; v0("abcdefghijklmnop", 16);
-valarray&lt;char&gt; v1("ABC", 3);
-const bool vb[] = {false, false, true, true, false, true};
-v0[valarray&lt;bool&gt;(vb, 6)] = v1;
-// v0 == valarray&lt;char&gt;("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&lt;char&gt; v0("abcdefghijklmnop", 16);
-valarray&lt;char&gt; v1("ABCDE", 5);
-const size_t vi[] = {7, 5, 2, 3, 8};
-v0[valarray&lt;size_t&gt;(vi, 5)] = v1;
-// v0 == valarray&lt;char&gt;("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&lt;char&gt; v0("abcdefghijklmnop", 16);
-// v0[3] returns 'd'
-</pre></blockquote>
-
-<p>
-The seventh member operator returns an object of class <tt>valarray&lt;Ty&gt;</tt>
-containing those elements of the controlled sequence designated by <tt>slicearr</tt>.
-For example:
-</p>
-
-<blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
-// v0[slice(2, 5, 3)] returns valarray&lt;char&gt;("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&lt;char&gt; v0("abcdefghijklmnop", 16);
-const size_t lv[] = {2, 3};
-const size_t dv[] = {7, 2};
-const valarray&lt;size_t&gt; len(lv, 2), str(dv, 2);
-// v0[gslice(3, len, str)] returns
-// &nbsp;&nbsp;&nbsp;valarray&lt;char&gt;("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&lt;char&gt; v0("abcdefghijklmnop", 16);
-const bool vb[] = {false, false, true, true, false, true};
-// v0[valarray&lt;bool&gt;(vb, 6)] returns
-// &nbsp;&nbsp;&nbsp;valarray&lt;char&gt;("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&lt;char&gt; v0("abcdefghijklmnop", 16);
-const size_t vi[] = {7, 5, 2, 3, 8};
-// v0[valarray&lt;size_t&gt;(vi, 5)] returns
-// valarray&lt;char&gt;("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&lt;int, my_alloc&gt;</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&lt;int, my_alloc&gt; v1(a1);
- vector&lt;int, my_alloc&gt; 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&lt;charT,traits&gt;* 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&lt;charT,traits&gt;* open(
- const char* s,
- ios_base::openmode mode );
-
-basic_filebuf&lt;charT,traits&gt;* 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 &gt;= 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&lt;wchar_t&gt;::narrow (wchar_t wc, char dflt) const
- {
- const unsigned wi = unsigned (wc);
-
- if (wi &gt; UCHAR_MAX)
- return typeid (*this) == typeid (ctype&lt;wchar_t&gt;) ?
- dflt : do_narrow (wc, dflt);
-
- if (narrow_ [wi] &lt; 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&lt;charT&gt;::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&lt;charT&gt;::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&lt;class Y&gt; operator auto_ptr&lt;Y&gt;()
-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 &lt;memory&gt;
-using std::auto_ptr;
-
-struct B {};
-struct D : B {};
-
-auto_ptr&lt;D&gt; source();
-int sink(auto_ptr&lt;B&gt;);
-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&lt;D&gt; 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&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;&amp; 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&lt;B&gt;());
-</pre>
-
-<p>
-IMHO no one ever wrote such awkward code and the reasonable workaround for
-#1 is:
-</p>
-<pre>int y = sink( auto_ptr&lt;B&gt;(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&lt;B&gt;, std::string);
-auto_ptr&lt;B&gt; 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&lt;B&gt;::operator auto_ptr_ref&lt;B&gt;()</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&lt;Y&gt; that holds *this and this is another defect since
-the type of *this is auto_ptr&lt;X&gt; where X might be different from Y. Several
-library vendors (e.g. SGI) implement auto_ptr_ref&lt;Y&gt; 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&lt;B&gt;(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&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp;)
-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&lt;class X&gt; 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&amp;) throw();
- template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp;) throw();
- auto_ptr&amp; operator=(auto_ptr&amp;) throw();
- template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;) throw();
- ~auto_ptr() throw();
-
- // 20.4.5.2 members:
- X&amp; operator*() const throw();
- X* operator-&gt;() const throw();
- X* get() const throw();
- X* release() throw();
- void reset(X* p=0) throw();
-
- private:
- template&lt;class U&gt;
- auto_ptr(U&amp; rhs, typename
-unspecified_error_on_const_auto_ptr&lt;U&gt;::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&lt;typename T&gt; struct unspecified_error_on_const_auto_ptr;
-
-template&lt;typename T&gt;
-struct unspecified_error_on_const_auto_ptr&lt;auto_ptr&lt;T&gt; const&gt;
-{ typedef typename auto_ptr&lt;T&gt;::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&lt;X&gt; from const auto_ptr&lt;Y&gt; 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&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp; a) throw();</pre>
-<p> 4 Requires: Y* can be implicitly converted to X*.</p>
-<p> 5 Effects: Calls const_cast&lt;auto_ptr&lt;Y&gt;&amp;&gt;(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&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt; 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&amp; 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&amp;)
- // implicit X&amp; operator=(X&amp;)
- auto_ptr&lt;D&gt; 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&lt;Y&gt; 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&lt;X&gt; 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&lt;Y&gt; is
-constructed from auto_ptr&lt;X&gt; 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 &lt;class Y&gt; struct auto_ptr_ref {};</del>
-
- <ins>// exposition only</ins>
- <ins>template &lt;class T&gt; struct constant_object;</ins>
-
- <ins>// exposition only</ins>
- <ins>template &lt;class T&gt;</ins>
- <ins>struct cannot_transfer_ownership_from</ins>
- <ins>: constant_object&lt;T&gt; {};</ins>
-
- template &lt;class X&gt; 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&amp;) throw();
- template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;<ins> const</ins>&amp;) throw();
- auto_ptr&amp; operator=(auto_ptr&amp;) throw();
- template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del>) throw();
- <del>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw();</del>
- ~auto_ptr() throw();
-
- // D.9.1.2 members:
- X&amp; operator*() const throw();
- X* operator-&gt;() 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&lt;X&gt;) throw();</del>
- <del>template&lt;class Y&gt; operator auto_ptr_ref&lt;Y&gt;() throw();</del>
- <del>template&lt;class Y&gt; operator auto_ptr&lt;Y&gt;() throw();</del>
-
- <ins>// exposition only</ins>
- <ins>template&lt;class U&gt;</ins>
- <ins>auto_ptr(U&amp; rhs, typename cannot_transfer_ownership_from&lt;U&gt;::error = 0);</ins>
- };
-
- template &lt;&gt; class auto_ptr&lt;void&gt;
- {
- 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&lt;X&gt;</tt> from <tt>const auto_ptr&lt;Y&gt;</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&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;<ins> const</ins>&amp; 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&lt;auto_ptr&lt;Y&gt;&amp;&gt;(</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&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</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&amp;) throw();
- exception&amp; operator= (const exception&amp;) 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&amp; <ins><i>e</i></ins>) throw();
-exception&amp; operator=(const exception&amp; <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(&amp;c, &amp;c + 1, &amp;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 &amp;&amp; *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&lt;class BidirectionalIterator, class Predicate&gt;
-BidirectionalIterator partition(BidirectionalIterato r first,
- BidirectionalIterator last,
- Predicate pred);
-</pre></blockquote>
-<p>to </p>
-<blockquote><pre>template&lt;class ForwardIterator, class Predicate&gt;
-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 &lt;class... Types&gt;
- void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp; y);
-template &lt;class... Types&gt;
- void swap(tuple&lt;Types...&gt;&amp;&amp; x, tuple&lt;Types...&gt;&amp; y);
-template &lt;class... Types&gt;
- void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp;&amp; y);
-</pre></blockquote>
-
-<p>
-Add this signature to 20.4.1 [tuple.tuple]
-</p>
-
-<blockquote><pre>void swap(tuple&amp;&amp;);
-</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&amp;&amp; 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 &lt;class... Types&gt;
- void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp; y);
-template &lt;class... Types&gt;
- void swap(tuple&lt;Types...&gt;&amp;&amp; x, tuple&lt;Types...&gt;&amp; y);
-template &lt;class... Types&gt;
- void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp;&amp; 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&lt;&gt; 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&lt;&gt;::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&lt;&gt;</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&lt;&gt; 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> &amp; ios_base::in) != 0</tt>, positions the input sequence.</del></li>
-<li><del>If <tt>(<i>which</i> &amp; 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&amp;</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&lt;U&gt;::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&lt;void*&gt;(&amp;*i))
- typename iterator_traits&lt;ForwardIterator&gt;::value_type (x)
-
- </pre>
- <p>
-
-This expression is ill-formed when the type of the subexpression
-<code>&amp;*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&lt;ForwardIterator&gt;::pointer pointer;
-typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type value_type;
-
-for (; first != last; ++result, ++first)
- new (static_cast&lt;void*&gt;(const_cast&lt;pointer&gt;(&amp;*result))
- value_type (*first);
-
- </pre>
- <p>
-
-change 20.6.4.2, p1 to read
-
- </p>
- <pre>
-<i>Effects</i>:
-
-typedef typename iterator_traits&lt;ForwardIterator&gt;::pointer pointer;
-typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type value_type;
-
-for (; first != last; ++result, ++first)
- new (static_cast&lt;void*&gt;(const_cast&lt;pointer&gt;(&amp;*first))
- value_type (*x);
-
- </pre>
- <p>
-
-and change 20.6.4.3, p1 to read
-
- </p>
- <pre>
-<i>Effects</i>:
-
-typedef typename iterator_traits&lt;ForwardIterator&gt;::pointer pointer;
-typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type value_type;
-
-for (; n--; ++first)
- new (static_cast&lt;void*&gt;(const_cast&lt;pointer&gt;(&amp;*first))
- value_type (*x);
-
- </pre>
- <p>
-
-In addition, since there is no partial specialization for
-<code>iterator_traits&lt;volatile T*&gt;</code> I propose to add one
-to parallel such specialization for &lt;const T*&gt;. 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&lt;class T&gt; struct iterator_traits&lt;volatile T*&gt; {
-typedef ptrdiff_t difference_type;
-typedef T value_type;
-typedef volatile T* pointer;
-typedef volatile T&amp; 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&amp;</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&amp;</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&amp;</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&lt;T, N&gt; 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&lt; typename T &gt;
- class array&lt; T, 0 &gt; {
-
- ....
-
- iterator begin()
- { return iterator( reinterpret_cast&lt; T * &gt;( 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&lt; typename T &gt;
- class array&lt; T, 0 &gt; {
-
- T t;
-
- iterator begin()
- { return iterator( &amp;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&lt;T*&gt;(0);
-</pre></blockquote>
-<p>
-In this case the value would be unique to the type array&lt;T, 0&gt; but not
-to the objects (all objects of type array&lt;T, 0&gt; 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 &amp;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&amp;) 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 &lt;array&gt; 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&amp;); // 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&lt;charT,traits,Allocator&gt;&amp; str );
-
-basic_string(const basic_string&lt;charT,traits,Allocator&gt;&amp; str ,
- size_type pos , size_type n = npos,
- const Allocator&amp; 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&amp;</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>&lt;array&gt;</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&lt;valarray&lt;T&gt; &gt;</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&lt;valarray&lt;T&gt; &gt;::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&lt;T&gt;&amp; operator=(const valarray&lt;T&gt;&amp;<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() &gt; 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> &lt; *<i>first2</i></tt>" and "<tt>*<i>first2</i>
-&lt; *<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&lt;&gt;</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&lt;&gt;</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&amp; 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&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator==(const function&lt;Function2&gt;&amp;);
- template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator!=(const function&lt;Function2&gt;&amp;);
-};
-</pre></blockquote>
-
-<p>
-Change X [func.wrap.func.undef]
-</p>
-
-<blockquote><pre>template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator==(const function&lt;Function2&gt;&amp;);
-template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator!=(const function&lt;Function2&gt;&amp;);
-</pre></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="659"></a>659. istreambuf_iterator should have an operator-&gt;()</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-&gt;(), even if its
-value type is a built-in type (comp.std.c++, "Re: Should any iterator
-have an operator-&gt;() 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 &lt;iostream&gt;
- #include &lt;fstream&gt;
- #include &lt;streambuf&gt;
-
- typedef char C;
- int main ()
- {
- std::ifstream s("filename", std::ios::in);
- std::istreambuf_iterator&lt;char&gt; i(s);
-
- (*i).~C(); // This is well-formed...
- i-&gt;~C(); // ... so this should be supported!
- }
-</pre>
-
-<p>
-Of course, operator-&gt; is also needed when the value_type of
-istreambuf_iterator is a class.
-</p>
-<p>
-The operator-&gt; 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-&gt;() const;</ins>
-istreambuf_iterator&lt;charT,traits&gt;&amp; 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-&gt;</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-&gt;()</tt> is specified to be <tt>pointer</tt>,
-but the proposed text also states that "<tt>operator-&gt;</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-&gt;()</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-&gt;()</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-&gt;</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-&gt;()</tt>. As
-longs as it behaves as expected: <tt>i-&gt;m</tt> should have the same effect as
-<tt>(*i).m</tt>. Even for an explicit destructor call, <tt>i-&gt;~C()</tt>. The main issue
-is just: <tt>istreambuf_iterator</tt> should have an <tt>operator-&gt;()</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&lt;wchar_t&gt;</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 &lt;locale&gt; [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 &amp;&amp; !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. &nbsp;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 &amp; fixed) != 0 or
-if str.precision() &gt; 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(). &nbsp;Is this really what's intended? &nbsp;I sincerely hope
-that I'm either missing something or this is an oversight. &nbsp;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. &nbsp;With %a the default
-precision is not 6, it is infinity. &nbsp;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&lt;T&gt;</tt> move assignment is O(1)
-(just a <tt>swap</tt>) then containers such as <tt>vector&lt;shared_ptr&lt;ostream&gt;&gt;</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&lt;shared_ptr&lt;ostream&gt;&gt;</tt> v1;
-<tt>vector&lt;shared_ptr&lt;ostream&gt;&gt;</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&amp;</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&lt;X::allocator_type&gt;::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&lt;X::allocator_type&gt;::value</tt>
-is <tt>true</tt> or
-<tt>allocator_propagate_on_copy_assignment&lt;X::allocator_type&gt;::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 &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
-
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
- unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
-
-template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
-
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
- unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
-
-...
-
-template &lt;class Value, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; x,
- unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; y);
-
-<ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; x,
- unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-
-<ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; x,
- unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; y);</ins>
-
-template &lt;class Value, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; x,
- unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; y);
-
-<ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; x,
- unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-
-<ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; x,
- unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; 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&amp;);
- <ins>unordered_map(unordered_map&amp;&amp;);</ins>
- ~unordered_map();
- unordered_map&amp; operator=(const unordered_map&amp;);
- <ins>unordered_map&amp; operator=(unordered_map&amp;&amp;);</ins>
- ...
- // modifiers
- <del>std::</del>pair&lt;iterator, bool&gt; insert(const value_type&amp; obj);
- <ins>template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(P&amp;&amp; obj);</ins>
- iterator insert(iterator hint, const value_type&amp; obj);
- <ins>template &lt;class P&gt; iterator insert(iterator hint, P&amp;&amp; obj);</ins>
- const_iterator insert(const_iterator hint, const value_type&amp; obj);
- <ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; obj);</ins>
- ...
- void swap(unordered_map&amp;<ins>&amp;</ins>);
- ...
- mapped_type&amp; operator[](const key_type&amp; k);
- <ins>mapped_type&amp; operator[](key_type&amp;&amp; k);</ins>
- ...
-};
-
-template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
-
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
- unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
-</pre></blockquote>
-
-<p>
-Add to 23.4.1.1 [unord.map.cnstr]:
-</p>
-
-<blockquote>
-<pre>template &lt;class InputIterator&gt;
- unordered_map(InputIterator f, InputIterator l,
- size_type n = <i>implementation-defined</i>,
- const hasher&amp; hf = hasher(),
- const key_equal&amp; eql = key_equal(),
- const allocator_type&amp; 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&lt;key_type, mapped_type&gt;</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&amp; operator[](const key_type&amp; 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&amp; operator[](key_type&amp;&amp; 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&lt;const key_type, mapped_type&gt;(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&lt;iterator, bool&gt; insert(const value_type&amp; x);</ins>
-<ins>template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(P&amp;&amp; x);</ins>
-<ins>iterator insert(iterator hint, const value_type&amp; x);</ins>
-<ins>template &lt;class P&gt; iterator insert(iterator hint, P&amp;&amp; x);</ins>
-<ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
-<ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; x);</ins>
-<ins>template &lt;class InputIterator&gt;
- void insert(InputIterator first, InputIterator last);</ins>
-</pre>
-
-<blockquote>
-<p><ins>
-<i>Requires:</i> Those signatures taking a <tt>const value_type&amp;</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&lt;const key_type,
-mapped_type&gt;</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 &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
- unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; 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&amp;);
- <ins>unordered_multimap(unordered_multimap&amp;&amp;);</ins>
- ~unordered_multimap();
- unordered_multimap&amp; operator=(const unordered_multimap&amp;);
- <ins>unordered_multimap&amp; operator=(unordered_multimap&amp;&amp;);</ins>
- ...
- // modifiers
- iterator insert(const value_type&amp; obj);
- <ins>template &lt;class P&gt; iterator insert(P&amp;&amp; obj);</ins>
- iterator insert(iterator hint, const value_type&amp; obj);
- <ins>template &lt;class P&gt; iterator insert(iterator hint, P&amp;&amp; obj);</ins>
- const_iterator insert(const_iterator hint, const value_type&amp; obj);
- <ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; obj);</ins>
- ...
- void swap(unordered_multimap&amp;<ins>&amp;</ins>);
- ...
-};
-
-template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
-
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
- unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
-</pre></blockquote>
-
-<p>
-Add to 23.4.2.1 [unord.multimap.cnstr]:
-</p>
-
-<blockquote>
-<pre>template &lt;class InputIterator&gt;
- unordered_multimap(InputIterator f, InputIterator l,
- size_type n = <i>implementation-defined</i>,
- const hasher&amp; hf = hasher(),
- const key_equal&amp; eql = key_equal(),
- const allocator_type&amp; 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&lt;key_type, mapped_type&gt;</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&amp; x);</ins>
-<ins>template &lt;class P&gt; iterator insert(P&amp;&amp; x);</ins>
-<ins>iterator insert(iterator hint, const value_type&amp; x);</ins>
-<ins>template &lt;class P&gt; iterator insert(iterator hint, P&amp;&amp; x);</ins>
-<ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
-<ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; x);</ins>
-<ins>template &lt;class InputIterator&gt;
- void insert(InputIterator first, InputIterator last);</ins>
-</pre>
-
-<blockquote>
-<p><ins>
-<i>Requires:</i> Those signatures taking a <tt>const value_type&amp;</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&lt;const key_type,
-mapped_type&gt;</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 &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
- unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; 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&amp;);
- <ins>unordered_set(unordered_set&amp;&amp;);</ins>
- ~unordered_set();
- unordered_set&amp; operator=(const unordered_set&amp;);
- <ins>unordered_set&amp; operator=(unordered_set&amp;&amp;);</ins>
- ...
- // modifiers
- <del>std::</del>pair&lt;iterator, bool&gt; insert(const value_type&amp; obj);
- <ins>pair&lt;iterator, bool&gt; insert(value_type&amp;&amp; obj);</ins>
- iterator insert(iterator hint, const value_type&amp; obj);
- <ins>iterator insert(iterator hint, value_type&amp;&amp; obj);</ins>
- const_iterator insert(const_iterator hint, const value_type&amp; obj);
- <ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; obj);</ins>
- ...
- void swap(unordered_set&amp;<ins>&amp;</ins>);
- ...
-};
-
-template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
-
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
- unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
-</pre></blockquote>
-
-<p>
-Add to 23.4.3.1 [unord.set.cnstr]:
-</p>
-
-<blockquote>
-<pre>template &lt;class InputIterator&gt;
- unordered_set(InputIterator f, InputIterator l,
- size_type n = <i>implementation-defined</i>,
- const hasher&amp; hf = hasher(),
- const key_equal&amp; eql = key_equal(),
- const allocator_type&amp; 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&lt;iterator, bool&gt; insert(const value_type&amp; x);</ins>
-<ins>pair&lt;iterator, bool&gt; insert(value_type&amp;&amp; x);</ins>
-<ins>iterator insert(iterator hint, const value_type&amp; x);</ins>
-<ins>iterator insert(iterator hint, value_type&amp;&amp; x);</ins>
-<ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
-<ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; x);</ins>
-<ins>template &lt;class InputIterator&gt;
- void insert(InputIterator first, InputIterator last);</ins>
-</pre>
-
-<blockquote>
-
-<p><ins>
-<i>Requires:</i> Those signatures taking a <tt>const
-value_type&amp;</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 &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
- unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; 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&amp;);
- <ins>unordered_multiset(unordered_multiset&amp;&amp;);</ins>
- ~unordered_multiset();
- unordered_multiset&amp; operator=(const unordered_multiset&amp;);
- <ins>unordered_multiset&amp; operator=(unordered_multiset&amp;&amp;);</ins>
- ...
- // modifiers
- iterator insert(const value_type&amp; obj);
- <ins>iterator insert(value_type&amp;&amp; obj);</ins>
- iterator insert(iterator hint, const value_type&amp; obj);
- <ins>iterator insert(iterator hint, value_type&amp;&amp; obj);</ins>
- const_iterator insert(const_iterator hint, const value_type&amp; obj);
- <ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; obj);</ins>
- ...
- void swap(unordered_multiset&amp;<ins>&amp;</ins>);
- ...
-};
-
-template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
-
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
- unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
-</pre></blockquote>
-
-<p>
-Add to 23.4.4.1 [unord.multiset.cnstr]:
-</p>
-
-<blockquote>
-<pre>template &lt;class InputIterator&gt;
- unordered_multiset(InputIterator f, InputIterator l,
- size_type n = <i>implementation-defined</i>,
- const hasher&amp; hf = hasher(),
- const key_equal&amp; eql = key_equal(),
- const allocator_type&amp; 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&amp; x);</ins>
-<ins>iterator insert(value_type&amp;&amp; x);</ins>
-<ins>iterator insert(iterator hint, const value_type&amp; x);</ins>
-<ins>iterator insert(iterator hint, value_type&amp;&amp; x);</ins>
-<ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
-<ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; x);</ins>
-<ins>template &lt;class InputIterator&gt;
- void insert(InputIterator first, InputIterator last);</ins>
-</pre>
-
-<blockquote>
-
-<p><ins>
-<i>Requires:</i> Those signatures taking a <tt>const
-value_type&amp;</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 &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
- unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; 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 &lt;class T&gt; void ref(const T&amp;&amp; t) = delete;
-template &lt;class T&gt; void cref(const T&amp;&amp; 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&amp;&amp; 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> &gt;&gt; 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&lt;charT,
-traits&gt;</code> then the expression <code><i>in</i> &gt;&gt; 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&gt;&gt;(int&amp;)</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&amp;</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&amp; 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&amp; 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 &gt; -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 &amp; 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| &lt;= 1</tt>, not <tt>x &gt;= 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>&amp;</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&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt; const&amp; 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>
-&gt; 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&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt; const&amp; 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&lt;class ForwardIterator, class Size, class T&gt;
- ForwardIterator
- search_n(ForwardIterator first , ForwardIterator last , Size count ,
- const T&amp; value );
-
-template&lt;class ForwardIterator, class Size, class T,
- class BinaryPredicate&gt;
- ForwardIterator
- search_n(ForwardIterator first , ForwardIterator last , Size count ,
- const T&amp; 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 &#8713; {^}] 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 &#8713; {^}] 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 &lt;typename T&gt;
-constexpr typename std::enable_if&lt;std::is_literal&lt;T&gt;::value, T&gt;::type
-abs(T x) {
- return x &lt; T() ? -x : x;
-}
-
-template &lt;typename T&gt;
-typename std::enable_if&lt;!std::is_literal&lt;T&gt;::value, T&gt;::type
-abs(const T&amp; x) {
- return x &lt; 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&amp;</tt> we could decide to
-use <tt>T&amp;&amp;</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 &lt;class T&gt; struct is_pod;
-</pre></blockquote>
-
-<p>
-add a new one:
-</p>
-
-<blockquote><pre>template &lt;class T&gt; 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 &lt;class T&gt; 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&lt;T,N&gt;::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&lt;N&gt;::test() const</tt> must be a
-<tt>constexpr</tt> (otherwise it would violate the specification of <tt>constexpr
-bitset&lt;N&gt;::operator[](size_t) const</tt>, because it's return clause delegates to <tt>test()</tt>).
-</li>
-<li>
-I wonder how the constructor <tt>bitset&lt;N&gt;::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&lt;class I, class E, class S&gt;
-struct codecvt : std::codecvt&lt;I, E, S&gt;
-{
- ~codecvt()
- { }
-};
-
-void main()
-{
- std::wstring_convert&lt;codecvt&lt;wchar_t, char, std::mbstate_t&gt; &gt; compiles_ok;
-
- std::wstring_convert&lt;std::codecvt&lt;wchar_t, char, std::mbstate_t&gt; &gt; 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>&lt;regex&gt;</tt> synopsis 28.4 [re.syn], just below the function
-template <tt>swap</tt> add two further overloads:
-</p>
-<blockquote><pre>template &lt;class charT, class traits&gt;
- void swap(basic_regex&lt;charT, traits&gt;&amp; e1, basic_regex&lt;charT, traits&gt;&amp; e2);
-<ins>template &lt;class charT, class traits&gt;
- void swap(basic_regex&lt;charT, traits&gt;&amp;&amp; e1, basic_regex&lt;charT, traits&gt;&amp; e2);
-template &lt;class charT, class traits&gt;
- void swap(basic_regex&lt;charT, traits&gt;&amp; e1, basic_regex&lt;charT, traits&gt;&amp;&amp; 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&amp;&amp;);
-</pre></blockquote>
-</li>
-
-<li>
-<p>Just after the copy-assignment op.:</p>
-<blockquote><pre>basic_regex&amp; operator=(basic_regex&amp;&amp;);
-</pre></blockquote>
-</li>
-
-<li>
-<p>Just after the first <tt>assign</tt> overload insert:</p>
-<blockquote><pre>basic_regex&amp; assign(basic_regex&amp;&amp; that);
-</pre></blockquote>
-</li>
-
-<li>
-<p>Change the current <tt>swap</tt> function to read:</p>
-<blockquote><pre>void swap(basic_regex&amp;&amp;);
-</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&amp;&amp;);
-</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&amp; operator=(basic_regex&amp;&amp;);
-</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&amp; assign(basic_regex&amp;&amp; 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&amp;&amp; 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 &lt;class charT, class traits&gt;
- void swap(basic_regex&lt;charT, traits&gt;&amp;&amp; e1, basic_regex&lt;charT, traits&gt;&amp; e2);
-template &lt;class charT, class traits&gt;
- void swap(basic_regex&lt;charT, traits&gt;&amp; e1, basic_regex&lt;charT, traits&gt;&amp;&amp; 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 &lt;class OutputIterator, class BidirectionalIterator,
- class traits, class charT&gt;
- OutputIterator
- regex_replace(OutputIterator out,
- BidirectionalIterator first, BidirectionalIterator last,
- const basic_regex&lt;charT, traits&gt;&amp; e,
- const basic_string&lt;charT&gt;&amp; fmt,
- regex_constants::match_flag_type flags =
- regex_constants::match_default);
-
-template &lt;class traits, class charT&gt;
- basic_string&lt;charT&gt;
- regex_replace(const basic_string&lt;charT&gt;&amp; s,
- const basic_regex&lt;charT, traits&gt;&amp; e,
- const basic_string&lt;charT&gt;&amp; 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 &lt;&lt; regex_replace(s, r, "y") &lt;&lt; endl;
-</pre></blockquote>
-
-<p>
-The compiler error message will be something like "could not deduce
-template argument for 'const std::basic_string&lt;_Elem&gt; &amp;' from 'const
-char[1]'".
-</p>
-
-<p>
-Users expect that anything taking a <tt>basic_string&lt;charT&gt;</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 &lt;class OutputIterator, class BidirectionalIterator,
- class traits, class charT&gt;
- OutputIterator
- regex_replace(OutputIterator out,
- BidirectionalIterator first, BidirectionalIterator last,
- const basic_regex&lt;charT, traits&gt;&amp; e,
- const basic_string&lt;charT&gt;&amp; fmt,
- regex_constants::match_flag_type flags =
- regex_constants::match_default);
-
-<ins>template &lt;class OutputIterator, class BidirectionalIterator,
- class traits, class charT&gt;
- OutputIterator
- regex_replace(OutputIterator out,
- BidirectionalIterator first, BidirectionalIterator last,
- const basic_regex&lt;charT, traits&gt;&amp; e,
- const charT* fmt,
- regex_constants::match_flag_type flags =
- regex_constants::match_default);</ins>
-</pre>
-<p>...</p>
-<pre>template &lt;class traits, class charT&gt;
- basic_string&lt;charT&gt;
- regex_replace(const basic_string&lt;charT&gt;&amp; s,
- const basic_regex&lt;charT, traits&gt;&amp; e,
- const basic_string&lt;charT&gt;&amp; fmt,
- regex_constants::match_flag_type flags =
- regex_constants::match_default);
-
-<ins>template &lt;class traits, class charT&gt;
- basic_string&lt;charT&gt;
- regex_replace(const basic_string&lt;charT&gt;&amp; s,
- const basic_regex&lt;charT, traits&gt;&amp; e,
- const charT* fmt,
- regex_constants::match_flag_type flags =
- regex_constants::match_default);</ins>
-
-<ins>template &lt;class traits, class charT&gt;
- basic_string&lt;charT&gt;
- regex_replace(const charT* s,
- const basic_regex&lt;charT, traits&gt;&amp; e,
- const basic_string&lt;charT&gt;&amp; fmt,
- regex_constants::match_flag_type flags =
- regex_constants::match_default);</ins>
-
-<ins>template &lt;class traits, class charT&gt;
- basic_string&lt;charT&gt;
- regex_replace(const charT* s,
- const basic_regex&lt;charT, traits&gt;&amp; 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&lt;charT, ST,
-SA&gt;&amp;</tt>. <tt>regex_replace()</tt> takes <tt>const basic_string&lt;charT&gt;&amp;</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&lt;charT, ST,
-SA&gt;&amp;</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 &lt;class T&gt;
-struct proxy {...};
-
-template &lt;class T&gt;
-struct proxied_iterator
-{
- typedef T value_type;
- typedef proxy&lt;T&gt; reference;
- reference operator*() const;
- ...
-};
-
-struct A
-{
- // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
- void swap(A&amp;);
- ...
-};
-
-void swap(A&amp;, A&amp;);
-void swap(proxy&lt;A&gt;, A&amp;);
-void swap(A&amp;, proxy&lt;A&gt;);
-void swap(proxy&lt;A&gt;, proxy&lt;A&gt;);
-
-} // Mine
-
-...
-
-Mine::proxied_iterator&lt;Mine::A&gt; 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&lt;test&gt;::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&lt;bool&gt;</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&lt;bool&gt; members take const bool&amp; 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&lt;bool&gt;, 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&lt;int&gt; 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 &lt;class Y&gt; 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&lt;T *&gt;(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&lt;T*&gt;(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&lt;T *&gt;(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&lt;class D&gt; shared_ptr(nullptr_t p, D d);
-template&lt;class D, class A&gt; shared_ptr(nullptr_t p, D d, A a);
-</pre></blockquote>
-
-<p>
-after
-</p>
-
-<blockquote><pre>template&lt;class Y, class D&gt; shared_ptr(Y* p, D d);
-template&lt;class Y, class D, class A&gt; 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 &lt;class D&gt; shared_ptr(nullptr_t, D d);
-template &lt;class D, class A&gt; 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 &amp;&amp; get() == 0</tt>.
-</p>
-<p>
-<i>Throws:</i> nothing.
-</p>
-</blockquote>
-</blockquote>
-
-<blockquote>
-<pre>template &lt;class D&gt; shared_ptr(nullptr_t, D d);
-template &lt;class D, class A&gt; shared_ptr&lt;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&lt;T *&gt;(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&lt;Y *&gt;(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&lt;T[]&gt;</tt> has some more restrictive constraints on
-type-completeness on <tt>T</tt> than <tt>unique_ptr&lt;T&gt;</tt>. The following proposed wordings
-try to cope with that. If the committee sees less usefulness on relaxed
-constraints on <tt>unique_ptr&lt;T[]&gt;</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&lt;T[], D&gt;</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&lt;Y*, X*&gt;</tt>, which
-again requires Completeness of <tt>Y</tt>, if <tt>!SameType&lt;X, Y&gt;</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&lt;U*, T*&gt;</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&lt;U*, T*&gt;</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-&gt;() 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&lt;int&gt; x, y;
- std::deque&lt;int&gt;::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() &amp;&amp; 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>&lt;functional&gt;</tt> synopsis replace:
-</p>
-
-<blockquote><pre>template&lt;class R, class... ArgTypes&gt;
- bool operator==(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-template&lt;class R, class... ArgTypes&gt;
- bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
-template&lt;class R, class... ArgTypes&gt;
- bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-template&lt;class R, class... ArgTypes&gt;
- bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
-</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&amp; 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 &lt;class R, class... ArgTypes&gt;
- bool operator==(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-template &lt;class R, class... ArgTypes&gt;
- bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
-template &lt;class R, class... ArgTypes&gt;
- bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-template &lt;class R, class... ArgTypes&gt;
- bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
-</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&amp; 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 &lt;class R, class... ArgTypes&gt;
- bool operator==(const function&lt;R(ArgTypes...)&gt;&amp; f, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-template &lt;class R, class... ArgTypes&gt;
- bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp; f);
-</pre></blockquote>
-
-<p>
-and replace
-</p>
-
-<blockquote><pre>template &lt;class R, class... ArgTypes&gt;
- bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp; f, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-template &lt;class R, class... ArgTypes&gt;
- bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp; 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>&lt;string&gt;</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>&lt;wchar.h&gt;/&lt;cwchar&gt;</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&amp; 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&amp;)</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&amp; 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 &lt;class T, size_t N&gt;
-struct array {
- ...
- void <del>assign</del> <ins>fill</ins>(const T&amp; 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 &lt;) 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 &lt; *(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 &lt; *(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>&lt;algorithm&gt;</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 &lt;class Gen&gt;
-seed(Gen&amp;);
-</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&gt;&gt;</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&amp;</tt> is
-returned. The result of <tt>operator-&gt;</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&gt;&gt;</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&amp;</tt> is
-returned. The result of <tt>operator-&gt;</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&lt;class _Fn&gt;
- discrete_distribution(result_type _Count, double _Low, double _High,
- _Fn&amp; _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&lt;double&gt;</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&amp;&amp;</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&amp; parm);
-</pre></blockquote>
-
-<p>
-insert:
-</p>
-
-
-<blockquote><pre>template&lt;typename Func&gt;
-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&lt;typename Func&gt;
-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 &gt; 0, the relation <tt><i>x</i><sub><i>min</i></sub></tt> &lt; <tt><i>x</i><sub><i>max</i></sub></tt> shall hold, and for all sample values
-<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 &#8805; 0, and 0 &lt; S = <tt><i>w</i><sub><i>0</i></sub></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.</li>
-
-</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&lt;class _Fn&gt;
- piecewise_constant_distribution(size_t _Count,
- _Ty _Low, _Ty _High, _Fn&amp; _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&lt;double&gt;</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&amp; parm);
-</pre></blockquote>
-<p>
-insert:
-</p>
-<blockquote><pre>template&lt;typename Func&gt;
-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&lt;typename Func&gt;
-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> &lt; <tt><i>x<sub>max</sub></i></tt>, and
-0 &lt; 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>&#961;<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 &gt; 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&amp;) = 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 &lt; 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&lt;class InputIterator&gt;
- 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&lt;InputIterator&gt;::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&lt;class InputIterator<del>,
- size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</del>&gt;
- 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&lt;InputIterator&gt;::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 = &#8721;<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$ &lt; 32)
- v.push_back($n$);
-for( ; $n$ &gt; 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&amp; 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&amp;</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>&amp;</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>&amp;</ins>system_category</tt>.
-</p>
-<p>
-<i>Throws:</i> Nothing.
-</p>
-</blockquote>
-<pre>error_code(int val, const error_category&amp; 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>&amp;</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&amp; cat);
-</pre>
-<blockquote>
-<p>
-<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</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&amp; 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>&amp;</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>&amp;</ins>posix_category</tt>.
-</p>
-<p>
-<i>Throws:</i> Nothing.
-</p>
-</blockquote>
-<pre>error_condition(int val, const error_category&amp; 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>&amp;</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&amp; cat);
-<blockquote>
-<p>
-<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</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&amp; 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 &lt;&gt; struct is_error_condition_enum&lt;<del>posix_error::posix_errno</del> <ins>errc</ins>&gt;
- : 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&lt;int&gt;(</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&lt;int&gt;(</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&amp;</tt> (an lvalue)" etc.
-In my opinion, this is a category error: "<tt>int&amp;</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 &lt;class T&gt; T&amp;&amp; forward(typename identity&lt;T&gt;::type&amp;&amp; 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&amp;&amp;</tt> (</del>an rvalue<del>)</del>. In the second call to factory, <tt>A1</tt> is deduced
-as <tt>int&amp;</tt>, so <tt>i</tt> is forwarded to <tt>A</tt>'s constructor as <del>an <tt>int&amp;</tt> (</del>an lvalue<del>)</del>.
-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&amp;&amp;</tt> (</del>an rvalue<del>)</del>.
-</p>
-</blockquote>
-
-<pre>template &lt;class T&gt; typename remove_reference&lt;T&gt;::type&amp;&amp; move(T&amp;&amp; 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>&lt;algorithm&gt;</code> should provide an
-overload of <code>std::swap</code> for array types:
-</p><pre>template&lt;class T, size_t N&gt; void swap(T (&amp;a)[N], T (&amp;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&lt;class T&gt; class W {
-public:
- T data;
-};
-</pre>
-Clearly <code>W&lt;T&gt;</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&lt;T&gt;</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&lt;class T&gt; void swap(W&lt;T&gt;&amp; x, W&lt;T&gt;&amp; 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&lt;std::string[8]&gt;</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&lt;std::string[8]&gt; 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&lt;class T, size_t N&gt; void swap(T (&amp;a)[N], T (&amp;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&lt;charT&gt;
-</pre></blockquote>
-
-<p>
-and
-</p>
-
-<blockquote><pre>ostreambuf_iterator&lt;charT&gt;
-</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&lt;charT,traits&gt;</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 &lt;class charT, class traits, class moneyT&gt;
-void f(basic_ios&lt;charT, traits&gt;&amp; str, moneyT&amp; mon, bool intl) {
- typedef istreambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
- ...
-</pre></blockquote>
-
-<p>
-In 27.6.4 [ext.manip]/4 remove the first template <tt>charT</tt> parameter:
-</p>
-
-<blockquote><pre>template &lt;<del>class charT, </del>class moneyT&gt; unspecified put_money(const moneyT&amp; 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 &lt;class charT, class traits, class moneyT&gt;
-void f(basic_ios&lt;charT, traits&gt;&amp; str, const moneyT&amp; mon, bool intl) {
- typedef ostreambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
- ...
-</pre></blockquote>
-
-<p>
-In 27.6.4 [ext.manip]/7 within function <tt>f</tt> replace the first line
-</p>
-
-<blockquote><pre>template &lt;class charT, class traits&gt;
-void f(basic_ios&lt;charT, traits&gt;&amp; str, struct tm *tmb, const charT *fmt) {
- typedef <ins>i</ins>streambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
- ...
-</pre></blockquote>
-
-<p>
-In 27.6.4 [ext.manip]/8 add const:
-</p>
-
-<blockquote><pre>template &lt;class charT&gt; 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 &lt;class charT, class traits&gt;
-void f(basic_ios&lt;charT, traits&gt;&amp; str, const struct tm *tmb, const charT *fmt) {
- typedef ostreambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
- ...
-</pre></blockquote>
-
-<p>
-Add to the <tt>&lt;iomanip&gt;</tt> synopsis in 27.6 [iostream.format]
-</p>
-
-<blockquote><pre>template &lt;class moneyT&gt; unspecified get_money(moneyT&amp; mon, bool intl = false);
-template &lt;class moneyT&gt; unspecified put_money(const moneyT&amp; mon, bool intl = false);
-template &lt;class charT&gt; unspecified get_time(struct tm *tmb, const charT *fmt);
-template &lt;class charT&gt; 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 &lt;utility&gt;
-
-int main()
-{
- std::pair&lt;char *, char *&gt; 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&lt;class U, class V&gt; pair(U&amp;&amp; x, V&amp;&amp; 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&lt;class U , class V &gt;
-requires Constructible&lt;T1, U&amp;&amp;&gt; &amp;&amp; Constructible&lt;T2, V&amp;&amp;&gt;
-pair(U&amp;&amp; x , V&amp;&amp; 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&lt;bool&gt;::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&lt;bool&gt;::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 &lt;class E&gt; void rethrow_if_nested(const E&amp; 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&lt; typename T &gt; void reset( T ) = delete;</ins>
-void swap(unique_ptr&amp;&amp; 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 &lt;vector&gt;
-#include &lt;iostream&gt;
-
-class Toto
-{
-public:
- Toto() {}
- explicit Toto( Toto const&amp; ) {}
-} ;
-
-int
-main()
-{
- std::vector&lt; Toto &gt; 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&lt;void&gt;</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&lt;&gt;</tt> helper in 20.2.2 [forward]. I believe this change makes it no
-longer possible to instantiate <tt>identity&lt;void&gt;</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&lt;void&gt;</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 &lt;class T&gt; struct identity {
- typedef T type;
-
- <ins>requires ReferentType&lt;T&gt;</ins>
- const T&amp; operator()(const T&amp; x) const;
- };
-</pre></blockquote>
-<p>...</p>
-<blockquote><pre> <ins>requires ReferentType&lt;T&gt;</ins>
- const T&amp; operator()(const T&amp; x) const;
-</pre></blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>
-The point here is to able to write <tt>T&amp;</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>&lt;string&gt;</tt> header synopsis at the end of
-21.2 [string.classes] lists a single <tt>operator&lt;&lt;</tt> overload
-for <tt>basic_string</tt>.
-</p>
-
-<blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
- basic_ostream&lt;charT, traits&gt;&amp;
- operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os,
- const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
-</pre></blockquote>
-
-<p>
-The definition in 21.3.8.9 [string.io] lists two:
-</p>
-
-<blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
- basic_ostream&lt;charT, traits&gt;&amp;
- operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os,
- const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
-
-template&lt;class charT, class traits, class Allocator&gt;
- basic_ostream&lt;charT, traits&gt;&amp;
- operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os,
- const basic_string&lt;charT,traits,Allocator&gt;&amp; 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&lt;class charT, class traits, class Allocator&gt;
- basic_ostream&lt;charT, traits&gt;&amp;
- operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os,
- const basic_string&lt;charT,traits,Allocator&gt;&amp; str);</del>
-
-template&lt;class charT, class traits, class Allocator&gt;
- basic_ostream&lt;charT, traits&gt;&amp;
- operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os,
- const basic_string&lt;charT,traits,Allocator&gt;&amp; 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&amp; ) {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&lt;char&gt;</code>
- and (<code>char_traits&lt;wchar_t&gt;</code>). However, there are actually
- four specializations provided, i.e. in addition to the two above also
- <code>char_traits&lt;char16_t&gt;</code> and <code>char_traits&lt;char32_t&gt;</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&lt; char16/32_t &gt;</tt>
-should also be added to <tt>&lt;ios_fwd&gt;</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&lt;charT&gt;</code>,
- and four explicit specializations of it, <code>char_traits&lt;char&gt;</code>,
- <code>char_traits&lt;char16_t&gt;</code>, <code>char_traits&lt;char32_t&gt;</code>, and
- <code>char_traits&lt;wchar_t&gt;</code>, all of which appear in the header
- &lt;string&gt; 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&amp; get_generic_category();</del>
-<del>const error_category&amp; get_system_category();</del>
-
-<del>static</del> <ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> generic_category<del> = get_generic_category()</del>;
-<del>static</del> <ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> <del>native_category</del> system_category<del> = get_system_category()</del>;
-</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>&amp;</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>&amp;</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>&amp;</del><ins>*</ins> cat);
- ...
- void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
- ...
- const error_category<del>&amp;</del><ins>*</ins> category() const;
- ...
-private:
- int val_; // exposition only
- const error_category<del>&amp;</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>&amp;</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>&amp;</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>&amp;</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>&amp;</del><ins>*</ins> cat);
- ...
- void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
- ...
- const error_category<del>&amp;</del><ins>*</ins> category() const;
- ...
-private:
- int val_; // exposition only
- const error_category<del>&amp;</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>&amp;</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>&amp;</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>&amp;</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()-&gt;</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()-&gt;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&amp; what_arg);
- system_error(error_code ec);
- system_error(int ev, const error_category<del>&amp;</del><ins>*</ins> ecat,
- const string&amp; what_arg);
- system_error(int ev, const error_category<del>&amp;</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>&amp;</del><ins>*</ins> ecat, const string&amp; 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>&amp;</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&lt;T&gt;::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&lt;T, D&gt;::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 &lt;&lt; std::flush;</code>
-
- </p>
- <blockquote>
- <pre>#include &lt;iostream&gt;
-
-int main ()
-{
- std::cout.tie (&amp;std::cerr);
- std::cerr.tie (&amp;std::cout);
- std::cout &lt;&lt; "cout\n";
- std::cerr &lt;&lt; "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-&gt;tie()</code>
-through <code>tiestr()-&gt;tie()-&gt;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-&gt;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() &amp; ios_base::unitbuf) &amp;&amp;
-!uncaught_exception())</code> is true,
-calls <del>os.flush()</del> <ins><code>os.rdbuf()-&gt;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() &amp; 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 == &amp;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 &gt;&gt; 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 &lt;&lt; "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-&gt; 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 &amp;s);</pre>
-
-<i>Effects</i>: Initializes <code>in_stream</code> with &amp;s. value
-may be initialized during construction or the first time it is
-referenced.<br>
-<ins><i>Postcondition</i>: <code>in_stream == &amp;s</code>.</ins>
-
-<pre>istream_iterator(const istream_iterator &amp;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&amp; operator++();</pre>
-
-<ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br>
-<i>Effects</i>: <code>*in_stream &gt;&gt; value</code>.
-
-<pre>istream_iterator&amp; 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 &gt;&gt; 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&lt;int, huge_thingy&gt;</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&lt;T,Allocator&gt;&amp;&amp; x);
-void splice(list&lt;T,Allocator&gt;&amp;&amp; x, const_iterator i);
-void splice(list&lt;T,Allocator&gt;&amp;&amp; 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&lt;T,Allocator&gt;&amp;&amp; x);
-void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x, const_iterator i);
-void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; 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>&lt;stdint.h&gt;</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>&lt;cstdint&gt;</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>&lt;cstdint&gt;</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>&lt;cstdint&gt;</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>&lt;cstdint&gt;</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&lt;A&gt;::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&lt;bool, A&gt;</tt> (23.2.7 [vector.bool]) and <tt>bitset&lt;N&gt;</tt>
-(23.3.5 [template.bitset]) store bits, not <tt>bool</tt>s, and <tt>bitset&lt;N&gt;</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&lt;A&gt;::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&lt;class R , class... ArgTypes &gt;
- class reference_closure&lt;R (ArgTypes...)&gt; {
- public:
- ...
- reference_closure&amp; operator=(const reference_closure&amp;) = <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&amp; operator=(const reference_closure&amp; 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&lt;float&gt;(), int())</tt> returns a <tt>complex&lt;float&gt;</tt>.
-</blockquote>
-
-<p>
-26.3.9 [cmplx.over] says that:
-</p>
-
-<blockquote>
-<tt>pow(complex&lt;float&gt;(), int())</tt> returns a <tt>complex&lt;double&gt;</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&lt;double&gt;</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&lt;class T&gt; complex&lt;T&gt; pow(const complex&lt;T&gt;&amp; 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&lt;charT, traits, Allocator&gt;</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&lt;bool&gt;</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&lt;T&gt;</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&lt;class Allocator&gt; struct hash&lt;std::vector&lt;bool,Allocator&gt;&gt;;
-template&lt;size_t N&gt; struct hash&lt;std::bitset&lt;N&gt;&gt;;
-</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&lt;bool&gt;</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&lt;root_class&gt;</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&lt; class T &gt; struct direct_base_class;
-template&lt; class T &gt; struct direct_derived_class;
-template&lt; class T &gt; 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&lt; class T &gt; 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&lt; class T &gt; 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&lt; class T &gt; 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&lt;int&gt; 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&lt;int, 3&gt; a = { 1, 4, 6 };
-</pre></blockquote>
-
-<p>
-Doug Gregor proposes the following solution, that assumes
-generalized initializer lists.
-</p>
-
-<blockquote><pre>template&lt;typename T, typename... Args&gt;
-inline array&lt;T, sizeof...(Args)&gt;
-make_array(Args&amp;&amp;... args)
-{ return { std::forward&lt;Args&gt;(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&lt;T&gt;(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&lt;typename T, typename... Args&gt;
- requires Convertible&lt;Args, T&gt;...
- array&lt;T, sizeof...(Args)&gt;
- make_array(Args&amp;&amp;... 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&lt;typename T, typename... Args&gt;
- requires Convertible&lt;Args, T&gt;...
- array&lt;T, sizeof...(Args)&gt;
- make_array(Args&amp;&amp;... args);
-</pre>
-
-<blockquote>
-<p>
-<i>Returns:</i> <tt>{std::forward&lt;Args&gt;(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 &lt;class charT, class traits&gt;
- basic_string&lt;charT, traits, allocator&lt;charT&gt; &gt; to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const;
-template &lt;class charT&gt;
- basic_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt; to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const;
-basic_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt; to_string(<ins>char zero = '0', char one = '1'</ins>) const;
-</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&lt;T&gt;</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 &lt;class T&gt; struct default_delete {
- default_delete();
- template &lt;class U&gt;
- <ins>requires Convertible&lt;U*, T*&gt; &amp;&amp; HasVirtualDestructor&lt;T&gt;</ins>
- default_delete(const default_delete&lt;U&gt;&amp;);
- void operator()(T*) const;
- };
-}
-</pre></blockquote>
-
-<p>
-...
-</p>
-
-<blockquote><pre>template &lt;class U&gt;
- <ins>requires Convertible&lt;U*, T*&gt; &amp;&amp; HasVirtualDestructor&lt;T&gt;</ins>
- default_delete(const default_delete&lt;U&gt;&amp; 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 &gt; 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 &lt;std::size_t Len, class... Types&gt; 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 &lt;std::size_t Len,
-class... Types&gt;
-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() &amp;&amp;
-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 &lt;class T, class Allocator&gt;
-bool operator==(const forward_list&lt;T,Allocator&gt;&amp; x, const forward_list&lt;T,Allocator&gt;&amp; 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() &amp;&amp; (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 &lt;class T, class Allocator&gt;
-bool operator!=(const forward_list&lt;T,Allocator&gt;&amp; x, const forward_list&lt;T,Allocator&gt;&amp; 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 &lt;class T, class Allocator&gt;
-bool operator==(const forward_list&lt;T,Allocator&gt;&amp; x, const forward_list&lt;T,Allocator&gt;&amp; 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())
-&amp;&amp; equal(x.begin(), x.end(), y.begin())</tt>.
-</p>
-</blockquote>
-<pre>template &lt;class T, class Allocator&gt;
-bool operator!=(const forward_list&lt;T,Allocator&gt;&amp; x, const forward_list&lt;T,Allocator&gt;&amp; 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&lt;class OutputIterator, class Size, class T&gt;
-void fill_n(OutputIterator first, Size n, const T&amp; value);</pre></li>
-
-<li>
-<pre>template&lt;class OutputIterator, class Size, class Generator&gt;
-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>&lt;algorithm&gt;</tt> synopsis and in 25.2.6 [alg.fill] by
-</p>
-
-<blockquote><pre>template&lt;class OutputIterator, class Size, class T&gt;
-<del>void</del> <ins>OutputIterator</ins> fill_n(OutputIterator first, Size n, const T&amp; 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>&lt;algorithm&gt;</tt> synopsis and in 25.2.7 [alg.generate] by
-</p>
-<blockquote><pre>template&lt;class OutputIterator, class Size, class Generator&gt;
-<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&lt;void*&gt;(&amp;*result)) typename iterator_traits&lt;ForwardIterator&gt;::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&lt;Args&gt;(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&lt;int&gt; s;
-unordered_set&lt;int&gt;::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&amp;&amp;</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&lt;T&gt;::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 &lt; 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>&lt;cstdint&gt;</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&lt;T&gt;::type</tt>
- must be one of the signed integer types as defined in 3.9.1. Ditto for
- <tt>make_unsigned&lt;T&gt;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 &lt;class T&gt; 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 &lt;class T&gt; 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) &amp;&amp;
- !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>&nbsp;</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>&nbsp;</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-&gt;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&lt;result_type&gt;::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 &lt; m</code> and <code>c &lt;
- 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&lt;RandomAccessIterator&gt;::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&lt;double&gt;</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&amp; parm);
-</pre></blockquote>
-
-<p>
-insert
-</p>
-
-<blockquote><pre>discrete_distribution(initializer_list&lt;double&gt; 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&lt;double&gt; 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&lt;double&gt;</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&amp;&amp;</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&amp; parm);
-</pre></blockquote>
-
-<p>
-insert
-</p>
-
-<blockquote><pre>template&lt;typename Func&gt;
-piecewise_constant_distribution(initializer_list&lt;RealType&gt; 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&lt;typename Func&gt;
-piecewise_constant_distribution(initializer_list&lt;RealType&gt; 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 &lt; 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 &gt; 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> &lt; 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>&#961;<sub><i>k</i></sub> = w<sub><i>k</i></sub>/(S * (b<sub><i>k+1</i></sub> - b<sub><i>k</i></sub>)) for k = 0, . . . , n-1.
-</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 &#8804; size()</tt>.
-</p>
-<p>
-<i>Returns:</i> If <tt>pos &lt; 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 == &amp;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 &#8804; size()</tt>
-</p>
-<p>
-<i>Throws:</i> <tt>out_of_range</tt> if <tt>pos &gt; 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 &lt;class InputIterator, class ForwardIterator&gt;
-ForwardIterator
-uninitialized_copy (InputIterator first, InputIterator last, ForwardIterator res)
-{
- typedef iterator_traits&lt;ForwardIterator&gt;::value_type ValueType;
-
- ForwardIterator start = res;
-
- try {
- for (; first != last; ++first, ++res)
- ::new (&amp;*res) ValueType (*first);
- }
- catch (...) {
- for (; start != res; --start)
- (&amp;*start)-&gt;~ValueType ();
- throw;
- }
- return res;
-}
-
-struct SomeType {
- SomeType (const SomeType&amp;) <ins>throw ()</ins>;
-}</pre>
- </blockquote>
- <p>
-
-compilers are able to emit the following efficient specialization
-of <tt>std::uninitialized_copy&lt;const SomeType*, SomeType*&gt;</tt>
-(note that the <tt>catch</tt> block has been optimized away):
-
- </p>
- <blockquote>
- <pre>template &lt;&gt; 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-&gt;~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&lt;T&gt;::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