aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorPaolo Carlini <pcarlini@suse.de>2007-11-08 10:19:57 +0000
committerPaolo Carlini <paolo@gcc.gnu.org>2007-11-08 10:19:57 +0000
commit6749ca7e8bf1f99090000d77be29a46a5d168d1f (patch)
treeb93119c3d93562dea8a9c286ab896becc8a1c41c
parentbd7d4f5fa15f7ae92c2028027723b5e3de993c5b (diff)
downloadgcc-6749ca7e8bf1f99090000d77be29a46a5d168d1f.zip
gcc-6749ca7e8bf1f99090000d77be29a46a5d168d1f.tar.gz
gcc-6749ca7e8bf1f99090000d77be29a46a5d168d1f.tar.bz2
lwg-active.html: Update to Revision R52.
2007-11-08 Paolo Carlini <pcarlini@suse.de> * docs/html/ext/lwg-active.html: Update to Revision R52. * docs/html/ext/lwg-closed.html: Likewise. * docs/html/ext/lwg-defects.html: Likewise. * docs/html/ext/howto.html: Adjust. From-SVN: r129994
Diffstat
-rw-r--r--libstdc++-v3/ChangeLog7
-rw-r--r--libstdc++-v3/docs/html/ext/howto.html2
-rw-r--r--libstdc++-v3/docs/html/ext/lwg-active.html7002
-rw-r--r--libstdc++-v3/docs/html/ext/lwg-closed.html1131
-rw-r--r--libstdc++-v3/docs/html/ext/lwg-defects.html2747
5 files changed, 7977 insertions, 2912 deletions
diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index fd48059..4aa2237 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,3 +1,10 @@
+2007-11-08 Paolo Carlini <pcarlini@suse.de>
+
+ * docs/html/ext/lwg-active.html: Update to Revision R52.
+ * docs/html/ext/lwg-closed.html: Likewise.
+ * docs/html/ext/lwg-defects.html: Likewise.
+ * docs/html/ext/howto.html: Adjust.
+
2007-11-07 Paolo Carlini <pcarlini@suse.de>
* include/tr1_impl/complex (fabs): In C++0x mode adjust
diff --git a/libstdc++-v3/docs/html/ext/howto.html b/libstdc++-v3/docs/html/ext/howto.html
index cb544aa..e7f1f9a 100644
--- a/libstdc++-v3/docs/html/ext/howto.html
+++ b/libstdc++-v3/docs/html/ext/howto.html
@@ -626,7 +626,7 @@
<dd>Change it to be a formatted output function (i.e. catch exceptions).
</dd>
- <dt><a href="lwg-active.html#660">660</a>:
+ <dt><a href="lwg-defects.html#660">660</a>:
<em>Missing bitwise operations</em>
</dt>
<dd>Add the missing operations.
diff --git a/libstdc++-v3/docs/html/ext/lwg-active.html b/libstdc++-v3/docs/html/ext/lwg-active.html
index 8aec733..29e0d77 100644
--- a/libstdc++-v3/docs/html/ext/lwg-active.html
+++ b/libstdc++-v3/docs/html/ext/lwg-active.html
@@ -1,22 +1,22 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html><head><title>C++ Standard Library Active Issues List</title>
+
+
<style type="text/css">
p {text-align:justify}
li {text-align:justify}
-ins {background-color:#FFFFA0}
-del {background-color:#FFFFA0}
-</style></head>
-
-<body>
+ins {background-color:#A0FFA0}
+del {background-color:#FFA0A0}
+</style></head><body>
<table>
<tbody><tr>
<td align="left">Doc. no.</td>
-<td align="left">N2317=07-0177</td>
+<td align="left">N2456=07-0326</td>
</tr>
<tr>
<td align="left">Date:</td>
-<td align="left">2007-06-24</td>
+<td align="left">2007-10-20</td>
</tr>
<tr>
<td align="left">Project:</td>
@@ -27,7 +27,7 @@ del {background-color:#FFFFA0}
<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 R49)</h1>
+<h1>C++ Standard Library Active Issues List (Revision R52)</h1>
<p>Reference ISO/IEC IS 14882:1998(E)</p>
<p>Also see:</p>
@@ -83,7 +83,7 @@ del {background-color:#FFFFA0}
<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>.
+ 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
@@ -94,6 +94,71 @@ del {background-color:#FFFFA0}
<h2>Revision History</h2>
<ul>
+<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-active.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#754">754</a>.</li>
+<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-active.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li>
+<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-active.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#706">706</a>.</li>
+<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#680">680</a>.</li>
+<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>.</li>
+<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-active.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>.</li>
+</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-active.html#697">697</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li>
+<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-active.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#680">680</a>.</li>
+<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-defects.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-active.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>
@@ -103,7 +168,7 @@ del {background-color:#FFFFA0}
<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-active.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li>
<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>
@@ -120,7 +185,7 @@ del {background-color:#FFFFA0}
<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-active.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#663">663</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>.</li>
<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-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
<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>
@@ -130,8 +195,8 @@ del {background-color:#FFFFA0}
<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-active.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#604">604</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-defects.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>
@@ -147,7 +212,7 @@ del {background-color:#FFFFA0}
<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-active.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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 New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#626">626</a>.</li>
<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#570">570</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#614">614</a>.</li>
<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>
@@ -181,9 +246,9 @@ del {background-color:#FFFFA0}
<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-active.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li>
+<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li>
<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-active.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#604">604</a> to Review.</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>
@@ -197,7 +262,7 @@ del {background-color:#FFFFA0}
<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-active.html#583">583</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#592">592</a>.</li>
+<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>
@@ -227,8 +292,8 @@ del {background-color:#FFFFA0}
<li><b>Details:</b><ul>
<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#567">567</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
<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-active.html#525">525</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a> to Open.</li>
+<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>
@@ -243,7 +308,7 @@ del {background-color:#FFFFA0}
<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-active.html#566">566</a>.</li>
+<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>
@@ -264,7 +329,7 @@ del {background-color:#FFFFA0}
</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-active.html#528">528</a>.
+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.
@@ -290,7 +355,7 @@ previously in "DR" status were moved to "WP".
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-active.html#488">488</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#494">494</a>.
+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.
@@ -703,10 +768,100 @@ upon overflow. We considered three options based on this:</p>
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>
@@ -1364,7 +1519,6 @@ committee.
<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 other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.unformatted">active issues</a> in [istream.unformatted].</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>
@@ -1830,7 +1984,6 @@ partial can only occur if (from_next != from_end)?
<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#Open">Open</a>
<b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2002-11-08</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#complex.numbers">active issues</a> in [complex.numbers].</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#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
@@ -1954,62 +2107,6 @@ existing implementations already have the layout proposed here.</p>
<hr>
-<h3><a name="393"></a>393. do_in/do_out operation on state unclear</h3>
-<p><b>Section:</b> 22.2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alberto Barbati <b>Date:</b> 2002-12-24</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.codecvt.virtuals">active issues</a> in [locale.codecvt.virtuals].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.virtuals">issues</a> in [locale.codecvt.virtuals].</p>
-<p><b>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>
-this DR follows the discussion on the previous thread "codecvt::do_in
-not consuming external characters". It's just a clarification issue
-and not a request for a change.
-</p>
-<p>
-Can do_in()/do_out() produce output characters without consuming input
-characters as a result of operation on state?
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add a note at the end of 22.2.1.5.2 [lib.locale.codecvt.virtuals],
-paragraph 3:
-</p>
-
-<p>
-[Note: As a result of operations on state, it can return ok or partial
-and set from_next == from and to_next != to. --end note]
-</p>
-
-
-<p><b>Rationale:</b></p>
-<p>
-The submitter believes that standard already provides an affirmative
-answer to the question. However, the current wording has induced a few
-library implementors to make the incorrect assumption that
-do_in()/do_out() always consume at least one internal character when
-they succeed.
-</p>
-
-<p>
-The submitter also believes that the proposed resolution is not in
-conflict with the related issue 76. Moreover, by explicitly allowing
-operations on state to produce characters, a codecvt implementation
-may effectively implement N-to-M translations without violating the
-"one character at a time" principle described in such issue. On a side
-note, the footnote in the proposed resolution of issue 76 that
-informally rules out N-to-M translations for basic_filebuf should be
-removed if this issue is accepted as valid.
-</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>
@@ -2249,6 +2346,12 @@ 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-active.html#622">622</a> for related issues.
+]</i></p>
+
+
<p><b>Proposed resolution:</b></p>
@@ -2361,102 +2464,6 @@ end-of-file):
<hr>
-<h3><a name="401"></a>401. incorrect type casts in table 32 in lib.allocator.requirements</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> Markus Mauhart <b>Date:</b> 2003-02-27</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>
-I think that in par2 of [default.con.req] the last two
-lines of table 32 contain two incorrect type casts. The lines are ...
-</p>
-
-<pre> a.construct(p,t) Effect: new((void*)p) T(t)
- a.destroy(p) Effect: ((T*)p)?-&gt;~T()
-</pre>
-
-<p>
-.... with the prerequisits coming from the preceding two paragraphs, especially
-from table 31:
-</p>
-
-<pre> alloc&lt;T&gt; a ;// an allocator for T
- alloc&lt;T&gt;::pointer p ;// random access iterator
- // (may be different from T*)
- alloc&lt;T&gt;::reference r = *p;// T&amp;
- T const&amp; t ;
-</pre>
-
-<p>
-For that two type casts ("(void*)p" and "(T*)p") to be well-formed
-this would require then conversions to T* and void* for all
-alloc&lt;T&gt;::pointer, so it would implicitely introduce extra
-requirements for alloc&lt;T&gt;::pointer, additionally to the only
-current requirement (being a random access iterator).
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 20.1.2 [allocator.requirements], Table 35: Allocator requirements
-last column of the row describing "a.construct(p,t)" to:
-</p>
-
-<blockquote>
-<p>
-<del>Effect: <tt>::new((void*)p) T(t)</tt></del>
-<ins>Constructs a copy of <tt>t</tt> at <tt>p</tt>. If <tt>t</tt> is an
-rvalue, it is forwarded to <tt>T</tt>'s constructor as an rvalue, else it
-is forwarded as an lvalue.</ins>
-</p>
-</blockquote>
-
-<p>
-Change 20.1.2 [allocator.requirements], Table 35: Allocator requirements
-last column of the row describing "a.destroy(p)" to:
-</p>
-
-<blockquote>
-<p>
-<del>Effect: ((T*)p)-&gt;~T()</del>
-<ins>Destroys the object at p.</ins>
-</p>
-</blockquote>
-
-<p>
-Note: Actually I would prefer to replace "((T*)p)?-&gt;dtor_name" with
-"p?-&gt;dtor_name", but AFAICS this is not possible cause of an omission
-in 13.5.6 [over.ref] (for which I have filed another DR on 29.11.2002).
-</p>
-
-<p><i>[Kona: The LWG thinks this is somewhere on the border between
- Open and NAD. The intend is clear: <tt>construct</tt> constructs an
- object at the location <i>p</i>. It's reading too much into the
- description to think that literally calling <tt>new</tt> is
- required. Tweaking this description is low priority until we can do
- a thorough review of allocators, and, in particular, allocators with
- non-default pointer types.]</i></p>
-
-
-<p><i>[
-Batavia: Proposed resolution changed to less code and more description.
-]</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="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>
@@ -2653,6 +2660,12 @@ object throws.
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-active.html#622">622</a> for related issues.
+]</i></p>
+
+
+
<p><b>Proposed resolution:</b></p>
@@ -3318,6 +3331,31 @@ actual filename.
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><b>Proposed resolution:</b></p>
@@ -3939,100 +3977,6 @@ wording (I believe) x,a,b,c could be written to in any order.
<hr>
-<h3><a name="488"></a>488. rotate throws away useful information</h3>
-<p><b>Section:</b> 25.2.11 [alg.rotate] <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> 2004-11-22</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>
-rotate takes 3 iterators: first, middle and last which point into a
-sequence, and rearranges the sequence such that the subrange [middle,
-last) is now at the beginning of the sequence and the subrange [first,
-middle) follows. The return type is void.
-</p>
-
-<p>
-In many use cases of rotate, the client needs to know where the
-subrange [first, middle) starts after the rotate is performed. This
-might look like:
-</p>
-<pre> rotate(first, middle, last);
- Iterator i = advance(first, distance(middle, last));
-</pre>
-
-<p>
-Unless the iterators are random access, the computation to find the
-start of the subrange [first, middle) has linear complexity. However,
-it is not difficult for rotate to return this information with
-negligible additional computation expense. So the client could code:
-</p>
-<pre> Iterator i = rotate(first, middle, last);
-</pre>
-
-<p>
-and the resulting program becomes significantly more efficient.
-</p>
-
-<p>
-While the backwards compatibility hit with this change is not zero, it
-is very small (similar to that of lwg <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>), and there is
-a significant benefit to the change.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 25p2, change:</p>
-<pre> template&lt;class ForwardIterator&gt;
- void rotate(ForwardIterator first, ForwardIterator middle,
- ForwardIterator last);
-</pre>
-
-<p>to:</p>
-
-<pre> template&lt;class ForwardIterator&gt;
- ForwardIterator rotate(ForwardIterator first, ForwardIterator middle,
- ForwardIterator last);
-</pre>
-
-<p>In 25.2.10, change:</p>
-
-<pre> template&lt;class ForwardIterator&gt;
- void rotate(ForwardIterator first, ForwardIterator middle,
- ForwardIterator last);
-</pre>
-
-<p>to:</p>
-
-<pre> template&lt;class ForwardIterator&gt;
- ForwardIterator rotate(ForwardIterator first, ForwardIterator middle,
- ForwardIterator last);
-</pre>
-
-<p>In 25.2.10 insert a new paragraph after p1:</p>
-
-<blockquote>
-<p><b>Returns</b>: <tt>first + (last - middle)</tt>.</p>
-</blockquote>
-
-<p><i>[
-The LWG agrees with this idea, but has one quibble: we want to make
-sure not to give the impression that the function "advance" is
-actually called, just that the nth iterator is returned. (Calling
-advance is observable behavior, since users can specialize it for
-their own iterators.) Howard will provide wording.
-]</i></p>
-
-
-<p><i>[Howard provided wording for mid-meeting-mailing Jun. 2005.]</i></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>
@@ -4444,11 +4388,11 @@ Berlin: Bill to provide wording.
<hr>
<h3><a name="518"></a>518. Are insert and erase stable for unordered_multiset and unordered_multimap?</h3>
-<p><b>Section:</b> 23.1.3 [unord.req], TR1 6.3.1 [tr.unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+<p><b>Section:</b> 23.1.3 [unord.req], TR1 6.3.1 [tr.unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
<b>Submitter:</b> Matt Austern <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#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#Open">Open</a> status.</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>
Issue 371 deals with stability of multiset/multimap under insert and erase
@@ -4460,6 +4404,14 @@ Moved to open (from review): There is no resolution.
]</i></p>
+<p><i>[
+Toronto: We have a resolution now. Moved to Review. Some concern was noted
+as to whether this conflicted with existing practice or not. An additional
+concern was in specifying (partial) ordering for an unordered container.
+]</i></p>
+
+
+
<p><b>Proposed resolution:</b></p>
<p>
@@ -4520,6 +4472,10 @@ Berlin: Doug to provide wording.
Batavia: Howard to provide wording.
]</i></p>
+<p><i>[
+Toronto: Howard to provide wording (really this time).
+]</i></p>
+
@@ -4533,7 +4489,6 @@ Batavia: Howard to provide wording.
<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 other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re">active issues</a> in [re].</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>
@@ -4664,107 +4619,8 @@ Pete: Possible general problem with case insensitive ranges.
<hr>
-<h3><a name="524"></a>524. regex named character classes and case-insensitivity don't mix</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 other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re">active issues</a> in [re].</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>
-This defect is also being discussed on the Boost developers list. The
-full discussion can be found here:
-http://lists.boost.org/boost/2005/07/29546.php
-</p>
-<p>
--- Begin original message --
-</p>
-<p>
-Also, I may have found another issue, closely related to the one under
-discussion. It regards case-insensitive matching of named character
-classes. The regex_traits&lt;&gt; provides two functions for working with
-named char classes: lookup_classname and isctype. To match a char class
-such as [[:alpha:]], you pass "alpha" to lookup_classname and get a
-bitmask. Later, you pass a char and the bitmask to isctype and get a
-bool yes/no answer.
-</p>
-<p>
-But how does case-insensitivity work in this scenario? Suppose we're
-doing a case-insensitive match on [[:lower:]]. It should behave as if it
-were [[:lower:][:upper:]], right? But there doesn't seem to be enough
-smarts in the regex_traits interface to do this.
-</p>
-<p>
-Imagine I write a traits class which recognizes [[:fubar:]], and the
-"fubar" char class happens to be case-sensitive. How is the regex engine
-to know that? And how should it do a case-insensitive match of a
-character against the [[:fubar:]] char class? John, can you confirm this
-is a legitimate problem?
-</p>
-<p>
-I see two options:
-</p>
-<p>
-1) Add a bool icase parameter to lookup_classname. Then,
-lookup_classname( "upper", true ) will know to return lower|upper
-instead of just upper.
-</p>
-<p>
-2) Add a isctype_nocase function
-</p>
-<p>
-I prefer (1) because the extra computation happens at the time the
-pattern is compiled rather than when it is executed.
-</p>
-<p>
--- End original message --
-</p>
-
-<p>
-For what it's worth, John has also expressed his preference for option
-(1) above.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="525"></a>525. type traits definitions not clear</h3>
-<p><b>Section:</b> 20.4.4 [meta.unary], TR1 4.5 [tr.meta.unary] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Robert Klarer <b>Date:</b> 2005-07-11</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 is not completely clear how the primary type traits deal with
-cv-qualified types. And several of the secondary type traits
-seem to be lacking a definition.
-</p>
-
-<p><i>[
-Berlin: Howard to provide wording.
-]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Wording provided in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2028.html">N2028</a>.
-A
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html">revision (N2157)</a>
-provides more detail for motivation.
-</p>
-
-
-
-
-
-<hr>
<h3><a name="527"></a>527. tr1::bind has lost its Throws clause</h3>
-<p><b>Section:</b> 20.5.10.1.3 [func.bind.bind], TR1 3.6.3 [tr.func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+<p><b>Section:</b> 20.5.11.1.3 [func.bind.bind], TR1 3.6.3 [tr.func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
<b>Submitter:</b> Peter Dimov <b>Date:</b> 2005-10-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>
@@ -4791,6 +4647,13 @@ Batavia: Doug to translate wording to variadic templates.
]</i></p>
+<p><i>[
+Toronto: We agree but aren't quite happy with the wording. The "t"'s no
+longer refer to anything. Alan to provide improved wording.
+]</i></p>
+
+
+
<p><b>Proposed resolution:</b></p>
<p>
@@ -4814,77 +4677,6 @@ throws an exception.
<hr>
-<h3><a name="528"></a>528. TR1: issue 6.19 vs 6.3.4.3/2 (and 6.3.4.5/2)</h3>
-<p><b>Section:</b> 23.4 [unord], TR1 6.3.4 [tr.unord.unord] <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> 2005-10-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#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-while implementing the resolution of issue 6.19 I'm noticing the
-following: according to 6.3.4.3/2 (and 6.3.4.5/2), for unordered_set and
-unordered_multiset:
-</p>
-
-<blockquote><p>
- "The iterator and const_iterator types are both const types. It is
-unspecified whether they are the same type"
-</p></blockquote>
-
-<p>
-Now, according to the resolution of 6.19, we have overloads of insert
-with hint and erase (single and range) both for iterator and
-const_iterator, which, AFAICS, can be meaningful at the same time *only*
-if iterator and const_iterator *are* in fact different types.
-</p>
-<p>
-Then, iterator and const_iterator are *required* to be different types?
-Or that is an unintended consequence? Maybe the overloads for plain
-iterators should be added only to unordered_map and unordered_multimap?
-Or, of course, I'm missing something?
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add to 6.3.4.3p2 (and 6.3.4.5p2):
-</p>
-<p>
-2 ... The iterator and const_iterator types are both <del>const</del>
-<ins>constant</ins> iterator types.
-It is unspecified whether they are the same type.
-</p>
-
-<p>
-Add a new subsection to 17.4.4 [lib.conforming]:
-</p>
-
-<blockquote>
-<p>
-An implementation shall not supply an overloaded function
- signature specified in any library clause if such a signature
- would be inherently ambiguous during overload resolution
- due to two library types referring to the same type.
-</p>
-<p>
- [Note: For example, this occurs when a container's iterator
- and const_iterator types are the same. -- end note]
-</p>
-</blockquote>
-
-<p><i>[
-Post-Berlin: Beman supplied wording.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
<h3><a name="529"></a>529. The standard encourages redundant and confusing preconditions</h3>
<p><b>Section:</b> 17.4.3.8 [res.on.required] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
<b>Submitter:</b> David Abrahams <b>Date:</b> 2005-10-25</p>
@@ -4971,83 +4763,6 @@ Alan provided the survey
<hr>
-<h3><a name="531"></a>531. array forms of unformatted input functions</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#Ready">Ready</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-11-23</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.unformatted">active issues</a> in [istream.unformatted].</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#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The array forms of unformatted input functions don't seem to have well-defined
-semantics for zero-element arrays in a couple of cases. The affected ones
-(<tt>istream::get()</tt> and <tt>istream::getline()</tt>) are supposed to
-terminate when <tt>(n - 1)</tt> characters are stored, which obviously can
-never be true when <tt>(n == 0)</tt> holds to start with. See
-c++std-lib-16071.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-I suggest changing 27.6.1.3, p7 (<tt>istream::get()</tt>), bullet 1 to read:
-</p>
- <ul>
- <li>
- <tt>(n &lt; 1)</tt> is true or <tt>(n - 1)</tt> characters
- are stored;
- </li>
- </ul>
-<p>
-Change 27.6.1.3, p9:
-</p>
-
-<blockquote><p>
-If the function stores no characters, it calls <tt>setstate(failbit)</tt> (which
-may throw <tt>ios_base::failure</tt> (27.4.4.3)). In any case, <ins>if <tt>(n
-&gt; 0)</tt> is true</ins> it then stores a null character into the next
-successive location of the array.
-</p></blockquote>
-
- <p>
-
-and similarly p17 (<tt>istream::getline()</tt>), bullet 3 to:
-
- </p>
- <ul>
- <li>
- <tt>(n &lt; 1)</tt> is true or <tt>(n - 1)</tt> characters
- are stored (in which case the function calls
- <tt>setstate(failbit)</tt>).
- </li>
- </ul>
-
- <p>
-
-In addition, to clarify that <tt>istream::getline()</tt> must not store the
-terminating NUL character unless the the array has non-zero size, Robert
-Klarer suggests in c++std-lib-16082 to change 27.6.1.3, p20 to read:
-
- </p>
- <blockquote><p>
-
-In any case, provided <tt>(n &gt; 0)</tt> is true, it then stores a null character
-(using charT()) into the next successive location of the array.
-
- </p></blockquote>
-
-<p><i>[
-post-Redmond: Pete noticed that the current resolution for <tt>get</tt> requires
-writing to out of bounds memory when <tt>n == 0</tt>. Martin provided fix.
-]</i></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>
@@ -5209,10 +4924,9 @@ adding signatures to allow user to specify "accumulator".
<hr>
<h3><a name="546"></a>546. _Longlong and _ULonglong are integer types</h3>
-<p><b>Section:</b> 26.4.1 [rand.req], TR1 5.1.1 [tr.rand.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<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 other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req">issues</a> in [rand.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>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].
@@ -5236,47 +4950,12 @@ list, so that people may use long long as a hash key.
<hr>
-<h3><a name="548"></a>548. May random_device block?</h3>
-<p><b>Section:</b> 26.4.6 [rand.device], TR1 5.1.6 [tr.rand.device] <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>
-Class random_device "produces non-deterministic random numbers", using some
-external source of entropy. In most real-world systems, the amount of available
-entropy is limited. Suppose that entropy has been exhausted. What is an
-implementation permitted to do? In particular, is it permitted to block
-indefinitely until more random bits are available, or is the implementation
-required to detect failure immediately? This is not an academic question. On
-Linux a straightforward implementation would read from /dev/random, and "When
-the entropy pool is empty, reads to /dev/random will block until additional
-environmental noise is gathered." Programmers need to know whether random_device
-is permitted to (or possibly even required to?) behave the same way.
-</p>
-
-<p><i>[
-Berlin: Walter: N1932 considers this NAD. Does the standard specify whether std::cin
-may block?
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
<h3><a name="550"></a>550. What should the return type of pow(float,int) be?</h3>
-<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
<b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-01-12</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
-<p><b>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>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>
Assuming we adopt the
@@ -5325,98 +5004,64 @@ Fortran, C and TR1 and make the return type of <tt>pow(float,int)</tt> be
<tt>double</tt>.
</p>
+<p><i>[
+Kona (2007): Other functions that are affected by this issue include
+<tt>ldexp</tt>, <tt>scalbln</tt>, and <tt>scalbn</tt>. We also believe that there is a typo in
+26.7/10: <tt>float nexttoward(float, long double);</tt> [sic] should be <tt>float
+nexttoward(float, float);</tt> Proposed Disposition: Review (the proposed
+resolution appears above, rather than below, the heading "Proposed
+resolution")
+]</i></p>
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="551"></a>551. &lt;ccomplex&gt;</h3>
-<p><b>Section:</b> 26.3.11 [cmplxh], TR1 8.3 [tr.c99.cmplxh] <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> 2006-01-23</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>
-Previously xxx.h was parsable by C++. But in the case of C99's &lt;complex.h&gt;
-it isn't. Otherwise we could model it just like &lt;string.h&gt;, &lt;cstring&gt;, &lt;string&gt;:
-</p>
-
-<ul>
-<li>&lt;string&gt; : C++ API in namespace std</li>
-<li>&lt;cstring&gt; : C API in namespace std</li>
-<li>&lt;string.h&gt; : C API in global namespace</li>
-</ul>
-
-<p>
-In the case of C's complex, the C API won't compile in C++. So we have:
-</p>
-
-<ul>
-<li>&lt;complex&gt; : C++ API in namespace std</li>
-<li>&lt;ccomplex&gt; : ?</li>
-<li>&lt;complex.h&gt; : ?</li>
-</ul>
-
-<p>
-The ? can't refer to the C API. TR1 currently says:
-</p>
-
-<ul>
-<li>&lt;complex&gt; : C++ API in namespace std</li>
-<li>&lt;ccomplex&gt; : C++ API in namespace std</li>
-<li>&lt;complex.h&gt; : C++ API in global namespace</li>
-</ul>
-
-
-
-<p><b>Proposed resolution:</b></p>
+<p><i>[
+</i></p><p>
+<i>Howard, post Kona:
+</i></p>
+<blockquote>
<p>
-Change 26.3.11 [cmplxh]:
-</p>
-
+<i>Unfortunately I strongly disagree with a part of the resolution
+from Kona. I am moving from New to Open instead of to Review because I do not believe
+we have consensus on the intent of the resolution.
+</i></p>
+<p>
+<i>This issue does not include <tt>ldexp</tt>, <tt>scalbln</tt>, and <tt>scalbn</tt> because
+the second integral parameter in each of these signatures (from C99) is <b>not</b> a
+<i>generic parameter</i> according to C99 7.22p2. The corresponding C++ overloads are
+intended (as far as I know) to correspond directly to C99's definition of <i>generic parameter</i>.
+</i></p>
+<p>
+<i>For similar reasons, I do not believe that the second <tt>long double</tt> parameter of
+<tt>nexttoward</tt>, nor the return type of this function, is in error. I believe the
+correct signature is:
+</i></p>
<blockquote>
+<pre><i>float nexttoward(float, long double);
+</i></pre>
+</blockquote>
<p>
-The header behaves as if it includes the header
-<tt>&lt;ccomplex&gt;</tt><ins>.</ins><del>, and provides sufficient using
-declarations to declare in the global namespace all function and type names
-declared or defined in the neader <tt>&lt;complex&gt;</tt>.</del>
-<ins>[<i>Note:</i> <tt>&lt;complex.h&gt;</tt> does not promote any interface
-into the global namespace as there is no C interface to promote. <i>--end
-note</i>]</ins>
-</p>
+<i>which is what both the C++0X working paper and C99 state (as far as I currently understand).
+</i></p>
+<p>
+<i>This is really <b>only</b> about <tt>pow(float, int)</tt>. And this is because C++98 took one
+route (with <tt>pow</tt> only) and C99 took another (with many math functions in <tt>&lt;tgmath.h&gt;</tt>.
+The proposed resolution basically says: C++98 got it wrong and C99 got it right; let's go with C99.
+</i></p>
</blockquote>
+<i>]</i>
-
-
-<hr>
-<h3><a name="552"></a>552. random_shuffle and its generator</h3>
-<p><b>Section:</b> 25.2.12 [alg.random.shuffle] <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> 2006-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>
-...is specified to shuffle its range by calling swap but not how
-(or even that) it's supposed to use the RandomNumberGenerator
-argument passed to it.
-</p>
+<p><b>Proposed resolution:</b></p>
<p>
-Shouldn't we require that the generator object actually be used
-by the algorithm to obtain a series of random numbers and specify
-how many times its operator() should be invoked by the algorithm?
+Change 26.7 [c.math]
</p>
+<blockquote><pre>float pow(float, float);
+<del>float</del> <ins>double</ins> pow(float, int);
+</pre></blockquote>
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
@@ -5560,9 +5205,9 @@ responsible for avoiding conflicting declarations. -- <i>end note</i>]
<hr>
<h3><a name="561"></a>561. inserter overly generic</h3>
-<p><b>Section:</b> 24.4.2.6.5 [inserter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 24.4.2.6.5 [inserter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
<b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-02-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>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 declaration of <tt>std::inserter</tt> is:
@@ -5714,15 +5359,22 @@ Change 24.4.2.6.5:
+<p><i>[
+Kona (2007): This issue will probably be addressed as a part of the
+concepts overhaul of the library anyway, but the proposed resolution is
+correct in the absence of concepts. Proposed Disposition: Ready
+]</i></p>
+
+
<hr>
<h3><a name="562"></a>562. stringbuf ctor inefficient</h3>
-<p><b>Section:</b> 27.7 [string.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 27.7 [string.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
<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#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#New">New</a> status.</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>
@@ -5804,16 +5456,21 @@ s.size())</code> hold.</ins>
</blockquote>
+<p><i>[
+Kona (2007) Moved to Ready.
+]</i></p>
+
+
<hr>
<h3><a name="563"></a>563. stringbuf seeking from end</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#New">New</a>
+<p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
<b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#stringbuf.virtuals">active issues</a> in [stringbuf.virtuals].</p>
<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#New">New</a> status.</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>
According to Table 92 (unchanged by issue 432), when <code>(way ==
@@ -5858,16 +5515,21 @@ pointer (<code><del>xend</del> <ins>high_mark</ins> - xbeg</code>).
</p></blockquote>
+<p><i>[
+Kona (2007) Moved to Ready.
+]</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#New">New</a>
+<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 other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#stringbuf.virtuals">active issues</a> in [stringbuf.virtuals].</p>
<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#New">New</a> status.</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
@@ -5903,14 +5565,32 @@ the effect is undefined.</del></li>
</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#New">New</a>
+<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#New">New</a> status.</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>
@@ -5967,77 +5647,12 @@ are permitted to override <tt>xsputn()</tt> for efficiency.
</p>
-
-
-
-<hr>
-<h3><a name="566"></a>566. array forms of unformatted input function undefined for zero-element arrays</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#Ready">Ready</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.unformatted">active issues</a> in [istream.unformatted].</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#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-
-The array forms of unformatted input functions don't have well-defined
-semantics for zero-element arrays in a couple of cases. The affected
-ones (<tt>istream::get()</tt> and <tt>getline()</tt>) are supposed to
-terminate when <tt>(n - 1)</tt> characters are stored, which obviously
-can never be true when <tt>(n == 0)</tt> to start with.
-
- </p>
-
-
-<p><b>Proposed resolution:</b></p>
- <p>
-
-I propose the following changes (references are relative to the
-Working Draft (document N1804).
-
- </p>
- <p>
-
-Change 27.6.1.3, p8 (<tt>istream::get()</tt>), bullet 1 as follows:
-
- </p>
- <blockquote>
- <p>
-
-<ins>if <tt>(n &lt; 1)</tt> is true or </ins> <tt>(n - 1)</tt>
-characters are stored;
-
- </p>
- </blockquote>
- <p>
-
-Similarly, change 27.6.1.3, p18 (<tt>istream::getline()</tt>), bullet
-3 as follows:
-
- </p>
- <blockquote>
- <p>
-
-<ins><tt>(n &lt; 1)</tt> is true or </ins><tt>(n - 1)</tt> characters
-are stored (in which case the function calls
-<tt>setstate(failbit)</tt>).
-
- </p>
- </blockquote>
- <p>
-
-Finally, change p21 as follows:
-
- </p>
- <blockquote>
- <p>
-
-In any case, <ins>provided <tt>(n &gt; 0)</tt> is true, </ins>it then
-stores a null character (using charT()) into the next successive
-location of the array.
-
- </p>
- </blockquote>
+<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>
@@ -6045,11 +5660,11 @@ location of the array.
<hr>
<h3><a name="567"></a>567. streambuf inserter and extractor should be unformatted</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#New">New</a>
+<p><b>Section:</b> 27.6 [iostream.format] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
<b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-25</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iostream.format">active issues</a> in [iostream.format].</p>
<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#New">New</a> status.</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>
@@ -6103,6 +5718,11 @@ And change 27.6.2.5.3, p7 as follows:
</blockquote>
+<p><i>[
+Kona (2007): Proposed Disposition: Ready
+]</i></p>
+
+
@@ -6155,6 +5775,10 @@ Portland: Jack will rewrite
to propose a primary template that will work with other integral types.
]</i></p>
+<p><i>[
+Toronto: issue has grown with addition of <tt>char16_t</tt> and <tt>char32_t</tt>.
+]</i></p>
+
<p><b>Proposed resolution:</b></p>
@@ -6165,10 +5789,10 @@ to propose a primary template that will work with other integral types.
<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#New">New</a>
+<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#New">New</a> status.</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:
@@ -6201,6 +5825,12 @@ 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>
@@ -6213,10 +5843,10 @@ represent existing practice.
<hr>
<h3><a name="574"></a>574. DR 369 Contradicts Text</h3>
-<p><b>Section:</b> 27.3 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 27.3 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
<b>Submitter:</b> Pete Becker <b>Date:</b> 2006-04-18</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.objects">issues</a> in [iostream.objects].</p>
-<p><b>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>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>
lib.iostream.objects requires that the standard stream objects are never
@@ -6233,57 +5863,31 @@ not destroyed during program execution."
<p><b>Proposed resolution:</b></p>
<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="577"></a>577. upper_bound(first, last, ...) cannot return last</h3>
-<p><b>Section:</b> 25.3.3.2 [upper.bound] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Seungbeom Kim <b>Date:</b> 2006-05-03</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>
-ISO/IEC 14882:2003 says:
+Change 27.3 [iostream.objects]/1:
</p>
<blockquote>
<p>
-25.3.3.2 upper_bound
-</p>
-<p>
-<i>Returns:</i> The furthermost iterator <tt>i</tt> in the range
-<tt>[<i>first</i>, <i>last</i>)</tt> such that
-for any iterator <tt>j</tt> in the range <tt>[<i>first</i>, i)</tt> the following corresponding
-conditions hold: <tt>!(value &lt; *j)</tt> or <tt><i>comp</i>(<i>value</i>, *j) == false</tt>.
+-2- The objects are constructed and the associations are established at
+some time prior to or during the first time an object of class
+<tt>ios_base::Init</tt> is constructed, and in any case before the body of main
+begins execution.<sup>290)</sup> The objects are not destroyed during program
+execution.<sup>291)</sup> If a translation unit includes <tt>&lt;iostream&amp;t;</tt> or explicitly
+constructs an <tt>ios_base::Init</tt> object, these stream objects shall be
+constructed before dynamic initialization of non-local objects defined
+later in that translation unit<del>, and these stream objects shall be
+destroyed after the destruction of dynamically initialized non-local
+objects defined later in that translation unit</del>.
</p>
</blockquote>
-<p>
-From the description above, upper_bound cannot return last, since it's
-not in the interval [first, last). This seems to be a typo, because if
-value is greater than or equal to any other values in the range, or if
-the range is empty, returning last seems to be the intended behaviour.
-The corresponding interval for lower_bound is also [first, last].
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change [lib.upper.bound]:
-</p>
-
-<blockquote>
-<p>
-<i>Returns:</i> The furthermost iterator <tt>i</tt> in the range
-<tt>[<i>first</i>, <i>last</i><del>)</del><ins>]</ins></tt> such that
-for any iterator <tt>j</tt> in the range <tt>[<i>first</i>, i)</tt> the following corresponding
-conditions hold: <tt>!(value &lt; *j)</tt> or <tt><i>comp</i>(<i>value</i>, *j) == false</tt>.
-</p>
-</blockquote>
+<p><i>[
+Kona (2007): From 27.3 [iostream.objects]/2, strike the words "...and these stream objects
+shall be destroyed after the destruction of dynamically initialized
+non-local objects defined later in that translation unit." Proposed
+Disposition: Review
+]</i></p>
@@ -6291,11 +5895,11 @@ conditions hold: <tt>!(value &lt; *j)</tt> or <tt><i>comp</i>(<i>value</i>, *j)
<hr>
<h3><a name="579"></a>579. erase(iterator) for unordered containers should not return an iterator</h3>
-<p><b>Section:</b> 23.1.3 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 23.1.3 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
<b>Submitter:</b> Joaquín M López Muńoz <b>Date:</b> 2006-06-13</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>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>
See
@@ -6346,6 +5950,21 @@ code.
+<p><b>Rationale:</b></p>
+<p>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2023.pdf">N2023</a>
+was discussed in Portland and the consensus was that there appears to be
+no need for either change proposed in the paper. The consensus opinion
+was that since the iterator could serve as its own proxy, there appears
+to be no need for the change. In general, "converts to" is undesirable
+because it interferes with template matching.
+</p>
+
+<p>
+Post Toronto: There does not at this time appear to be consensus with the Portland consensus.
+</p>
+
+
@@ -6502,10 +6121,10 @@ post Oxford: This would be rendered NAD Editorial by acceptance of
<hr>
<h3><a name="581"></a>581. <code>flush()</code> not unformatted function</h3>
-<p><b>Section:</b> 27.6.2.7 [ostream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 27.6.2.7 [ostream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
<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#ostream.unformatted">issues</a> in [ostream.unformatted].</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>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>
@@ -6556,12 +6175,20 @@ not behave as an unformatted output function (as described in
+<p><i>[
+Kona (2007): Proposed Disposition: Ready
+]</i></p>
+
+
+
<hr>
<h3><a name="582"></a>582. specialized algorithms and volatile storage</h3>
<p><b>Section:</b> 20.6.4.1 [uninitialized.copy] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
<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#uninitialized.copy">active issues</a> in [uninitialized.copy].</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>
@@ -6683,71 +6310,12 @@ effect by means of function template overloading.
<hr>
-<h3><a name="583"></a>583. div() for unsigned integral types</h3>
-<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Beman Dawes <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#c.math">active issues</a> in [c.math].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
-<p><b>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 is no div() function for unsigned integer types.
-</p>
-<p>
-There are several possible resolutions. The simplest one is noted below. Other
-possibilities include a templated solution.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add to 26.7 [lib.c.math] paragraph 8:
-</p>
-
-<blockquote><pre>struct udiv_t div(unsigned, unsigned);
-struct uldiv_t div(unsigned long, unsigned long);
-struct ulldiv_t div(unsigned long long, unsigned long long);
-</pre></blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="584"></a>584. missing int pow(int,int) functionality</h3>
-<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Beman Dawes <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#c.math">active issues</a> in [c.math].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
-<p><b>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 is no pow() function for any integral type.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add something like:
-</p>
-
-<blockquote><pre>template&lt; typename T&gt;
-T power( T x, int n );
-// requires: n &gt;=0
-</pre></blockquote>
-
-
-
-
-
-<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#New">New</a>
+<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#New">New</a> status.</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>
@@ -6853,16 +6421,23 @@ 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#New">New</a>
+<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#New">New</a> status.</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
@@ -6998,59 +6573,11 @@ which, again, doesn't seem to consider fixed size containers
</p>
-
-
-
-<hr>
-<h3><a name="592"></a>592. Incorrect treatment of rdbuf()-&gt;close() return type</h3>
-<p><b>Section:</b> 27.8.1.9 [ifstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Christopher Kohlhoff <b>Date:</b> 2006-08-17</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ifstream.members">issues</a> in [ifstream.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>
-I just spotted a minor problem in 27.8.1.7
-[lib.ifstream.members] para 4 and also 27.8.1.13
-[lib.fstream.members] para 4. In both places it says:
-</p>
-<blockquote>
-<pre>void close();
-</pre>
-<p>
-Effects: Calls rdbuf()-&gt;close() and, if that function returns false, ...
-</p>
-</blockquote>
-<p>
-However, basic_filebuf::close() (27.8.1.2) returns a pointer to the
-filebuf on success, null on failure, so I think it is meant to
-say "if that function returns a null pointer". Oddly, it is
-correct for basic_ofstream.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 27.8.1.7 [lib.ifstream.members], p5:
-</p>
-
-<blockquote><p>
-<i>Effects:</i> Calls <tt>rdbuf()-&gt;close()</tt> and, if that function
-<ins>fails (</ins>returns <del><tt>false</tt></del> <ins>a null pointer)</ins>,
-calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>
-(27.4.4.3)).
-</p></blockquote>
-
-<p>
-Change 27.8.1.13 [lib.fstream.members], p5:
-</p>
-
-<blockquote><p>
-<i>Effects:</i> Calls <tt>rdbuf()-&gt;close()</tt> and, if that function
-<ins>fails (</ins>returns <del><tt>false</tt></del> <ins>a null pointer)</ins>,
-calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>
-(27.4.4.3)).
-</p></blockquote>
-
+<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>
@@ -7058,11 +6585,9 @@ calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>
<hr>
<h3><a name="595"></a>595. TR1/C++0x: fabs(complex&lt;T&gt;) redundant / wrongly specified</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#New">New</a>
+<p><b>Section:</b> 26.3.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
<b>Submitter:</b> Stefan Große Pawig <b>Date:</b> 2006-09-24</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#complex.numbers">active issues</a> in [complex.numbers].</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#New">New</a> status.</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>
TR1 introduced, in the C compatibility chapter, the function
@@ -7130,8 +6655,8 @@ So either the return value of fabs() is specified wrongly, or fabs()
does not behave the same as C99's cabs*().
</p>
+<b>Possible Resolutions</b>
-<p><b>Proposed resolution:</b></p>
<p>
This depends on the intention behind the introduction of fabs().
</p>
@@ -7168,18 +6693,50 @@ is already provided by the corresponding overloads of abs().
+<p><b>Proposed resolution:</b></p>
+
+<p>
+Change the synopsis in 26.3.1 [complex.synopsis]:
+</p>
+
+<blockquote><pre>template&lt;class T&gt; <del>complex&lt;</del>T<del>&gt;</del> fabs(const complex&lt;T&gt;&amp;);
+</pre></blockquote>
+
+<p>
+Change 26.3.7 [complex.value.ops], p7:
+</p>
+
+<blockquote>
+<pre>template&lt;class T&gt; <del>complex&lt;</del>T<del>&gt;</del> fabs(const complex&lt;T&gt;&amp; <i>x</i>);
+</pre>
+<blockquote>
+<p>
+-7- <i>Effects:</i> Behaves the same as C99 function <tt>cabs</tt>, defined in subclause 7.3.8.1.
+</p>
+</blockquote>
+</blockquote>
+
+
+
+<p><i>[
+Kona (2007): Change the return type of <tt>fabs(complex)</tt> to <tt>T</tt>.
+Proposed Disposition: Ready
+]</i></p>
+
+
+
<hr>
<h3><a name="596"></a>596. 27.8.1.3 Table 112 omits "a+" and "a+b" modes</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#New">New</a>
+<p><b>Section:</b> 27.8.1.4 [filebuf.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
<b>Submitter:</b> Thomas Plum <b>Date:</b> 2006-09-26</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#filebuf.members">active issues</a> in [filebuf.members].</p>
<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#New">New</a> status.</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 testing 27.8.1.3, Table 112 (in the latest N2009 draft), we invoke
+In testing 27.8.1.4 [filebuf.members], Table 112 (in the latest N2009 draft), we invoke
</p>
<blockquote><pre> ostr.open("somename", ios_base::out | ios_base::in | ios_base::app)
</pre></blockquote>
@@ -7224,6 +6781,85 @@ the same thing as "a+" already proposed in the issue.
<p><b>Proposed resolution:</b></p>
+<p>
+Add to the table "File open modes" in 27.8.1.4 [filebuf.members]:
+</p>
+
+<blockquote>
+<table border="1">
+<caption> File open modes</caption>
+<tbody><tr>
+<th colspan="5"><tt>ios_base</tt> Flag combination</th>
+<th><tt>stdio</tt> equivalent</th>
+</tr>
+<tr>
+<th><tt>binary</tt></th><th><tt>in</tt></th><th><tt>out</tt></th><th><tt>trunc</tt></th><th><tt>app</tt></th><th><tt>&nbsp;</tt></th>
+</tr>
+
+<tr>
+<td>&nbsp;</td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"w"</tt></td>
+</tr>
+<tr>
+<td>&nbsp;</td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>"a"</tt></td>
+</tr>
+<tr>
+<td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a"</tt></ins></td>
+</tr>
+<tr>
+<td>&nbsp;</td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"w"</tt></td>
+</tr>
+<tr>
+<td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"r"</tt></td>
+</tr>
+<tr>
+<td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"r+"</tt></td>
+</tr>
+<tr>
+<td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"w+"</tt></td>
+</tr>
+<tr>
+<td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+"</tt></ins></td>
+</tr>
+<tr>
+<td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+"</tt></ins></td>
+</tr>
+
+<tr>
+<td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"wb"</tt></td>
+</tr>
+<tr>
+<td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>"ab"</tt></td>
+</tr>
+<tr>
+<td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"ab"</tt></ins></td>
+</tr>
+<tr>
+<td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"wb"</tt></td>
+</tr>
+<tr>
+<td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"rb"</tt></td>
+</tr>
+<tr>
+<td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"r+b"</tt></td>
+</tr>
+<tr>
+<td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"w+b"</tt></td>
+</tr><tr>
+<td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+b"</tt></ins></td>
+</tr>
+<tr>
+<td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+b"</tt></ins></td>
+</tr>
+
+
+</tbody></table>
+</blockquote>
+
+
+
+<p><i>[
+Kona (2007) Added proposed wording and moved to Review.
+]</i></p>
@@ -7318,128 +6954,6 @@ C-to-C++ compatibility, since neither example can be expressed in C.
<hr>
-<h3><a name="604"></a>604. Decimal: Storing a reference to a facet unsafe.</h3>
-<p><b>Section:</b> TRDecimal 3 [trdec.types] <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> 2006-05-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types">issues</a> in [trdec.types].</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 c++std-lib-17197, Martin writes:
-</p>
-<blockquote><p>
-The extended_num_get and extended_num_put facets are designed
-to store a reference to a num_get or num_put facet which the
-extended facets delegate the parsing and formatting of types
-other than decimal. One form of the extended facet's ctor (the
-default ctor and the size_t overload) obtains the reference
-from the global C++ locale while the other form takes this
-reference as an argument.
-</p></blockquote>
-<blockquote><p>
-The problem with storing a reference to a facet in another
-object (as opposed to storing the locale object in which the
-facet is installed) is that doing so bypasses the reference
-counting mechanism designed to prevent a facet that is still
-being referenced (i.e., one that is still installed in some
-locale) from being destroyed when another locale that contains
-it is destroyed. Separating a facet reference from the locale
-it comes from van make it cumbersome (and in some cases might
-even make it impossible) for programs to prevent invalidating
-the reference. (The danger of this design is highlighted in
-the paper.)
-</p></blockquote>
-<blockquote><p>
-This problem could be easily avoided by having the extended
-facets store a copy of the locale from which they would extract
-the base facet either at construction time or when needed. To
-make it possible, the forms of ctors of the extended facets that
-take a reference to the base facet would need to be changed to
-take a locale argument instead.
-</p></blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-1. Change the <code>extended_num_get</code> synopsis in 3.10.2 as follows:
-</p>
-<pre> extended_num_get(const <del>std::num_get&lt;charT, InputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
-
- /* ... */
-
- <del>// <i>const std::num_get&lt;charT, InputIterator&gt; &amp; <b>base</b></i>; <i><b>exposition only</b></i></del>
- <ins>// <i>std::locale <b>baseloc</b></i>; <i><b>exposition only</b></i></ins>
-</pre>
-<p>
-2. Change the description of the above constructor in 3.10.2.1:
-</p>
-<pre> extended_num_get(const <del>std::num_get&lt;charT, InputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
-
-</pre>
-<blockquote>
-<p>
-<b>Effects:</b> Constructs an <code>extended_num_get</code> facet as if by:
-</p>
-<pre> extended_num_get(const <del>std::num_get&lt;charT, InputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0)
- : facet(<i>refs</i>), <i>base<ins>loc</ins></i>(<i>b</i>)
- { /* ... */ }
-
-</pre>
-<p>
-<del><b>Notes:</b> Care must be taken by the implementation to ensure that the lifetime of the facet referenced by <i>base</i> exceeds that of the resulting <code>extended_num_get</code> facet.</del>
-</p>
-</blockquote>
-<p>
-3. Change the <b>Returns:</b> clause for <code>do_get(iter_type, iter_type, ios_base &amp;, ios_base::iostate &amp;, bool &amp;) const</code>, <i>et al</i> to
-</p>
-<blockquote><p>
-<b>Returns:</b> <code><del><i>base</i></del> <ins>std::use_facet&lt;std::num_get&lt;charT, InputIterator&gt; &gt;(<i>baseloc</i>)</ins>.get(<i>in</i>, <i>end</i>, <i>str</i>, <i>err</i>, <i>val</i>)</code>.
-</p></blockquote>
-<p>
-4. Change the <code>extended_num_put</code> synopsis in 3.10.3 as follows:
-</p>
-<pre> extended_num_put(const <del>std::num_put&lt;charT, OutputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
-
- /* ... */
-
- <del>// <i>const std::num_put&lt;charT, OutputIterator&gt; &amp; <b>base</b></i>; <i><b>exposition only</b></i></del>
- <ins>// <i>std::locale <b>baseloc</b></i>; <i><b>exposition only</b></i></ins>
-</pre>
-<p>
-5. Change the description of the above constructor in 3.10.3.1:
-</p>
-<pre> extended_num_put(const <del>std::num_put&lt;charT, OutputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
-</pre>
-<blockquote>
-<p>
-<b>Effects:</b> Constructs an <code>extended_num_put</code> facet as if by:
-</p>
-<pre> extended_num_put(const <del>std::num_put&lt;charT, OutputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0)
- : facet(<i>refs</i>), <i>base<ins>loc</ins></i>(<i>b</i>)
- { /* ... */ }
-
-</pre>
-<p>
-<del><b>Notes:</b> Care must be taken by the implementation to ensure that the lifetime of the facet referenced by <i>base</i> exceeds that of the resulting <code>extended_num_put</code> facet.</del>
-</p>
-</blockquote>
-<p>
-6. Change the <b>Returns:</b> clause for <code>do_put(iter_type, ios_base &amp;, char_type, bool &amp;) const</code>, <i>et al</i> to
-</p>
-<blockquote><p>
-<b>Returns:</b> <code><del><i>base</i></del> <ins>std::use_facet&lt;std::num_put&lt;charT, OutputIterator&gt; &gt;(<i>baseloc</i>)</ins>.put(<i>s</i>, <i>f</i>, <i>fill</i>, <i>val</i>)</code>.
-</p></blockquote>
-
-<p><i>[
-Redmond: We would prefer to rename "extended" to "decimal".
-]</i></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>
@@ -7500,99 +7014,6 @@ Redmond: We prefer explicit conversions for narrowing and implicit for widening.
<hr>
-<h3><a name="607"></a>607. Concern about short seed vectors</h3>
-<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq], TR1 5.1 [tr.rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Charles Karney <b>Date:</b> 2006-10-26</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#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Short seed vectors of 32-bit quantities all result in different states. However
-this is not true of seed vectors of 16-bit (or smaller) quantities. For example
-these two seeds
-</p>
-
-<blockquote><pre>unsigned short seed = {1, 2, 3};
-unsigned short seed = {1, 2, 3, 0};
-</pre></blockquote>
-
-<p>
-both pack to
-</p>
-
-<blockquote><pre>unsigned seed = {0x20001, 0x3};
-</pre></blockquote>
-
-<p>
-yielding the same state.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 26.4.7.1[rand.util.seedseq]/8a, replace
-</p>
-
-<blockquote>
-<p>
-Set <tt>begin[0]</tt> to <tt>5489 + <del>s</del><ins>N</ins></tt>.
-</p>
-<p>
-where <tt>N</tt> is the bit length of the sequence used to construct the
-seed_seq in 26.4.7.1/6 [rand.util.seedseq]. (This quantity is called <tt>n</tt>
-in 26.4.7.1/6 [rand.util.seedseq], but <tt>n</tt> has a different meaning in
-26.4.7.1/8 [rand.util.seedseq]. We have <tt>32^(s-1) &lt; N &lt;= 32^s</tt>.) Now
-</p>
-
-<blockquote><pre>unsigned short seed = {1, 2, 3, 0};
-unsigned seed = {0x20001, 0x3};
-</pre></blockquote>
-
-<p>
-are equivalent (<tt>N = 64</tt>), but
-</p>
-
-<blockquote><pre>unsigned short seed = {1, 2, 3};
-</pre></blockquote>
-
-<p>
-gives a distinct state (<tt>N = 48</tt>).
-</p>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="608"></a>608. Unclear seed_seq construction details</h3>
-<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq], TR1 5.1 [tr.rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Charles Karney <b>Date:</b> 2006-10-26</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#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In 26.4.7.1 [rand.util.seedseq] /6, the order of packing the inputs into b and the
-treatment of signed quantities is unclear. Better to spell it out.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<blockquote><pre>b = sum( unsigned(begin[i]) 2^(w i), 0 &lt;= i &lt; end-begin )
-</pre></blockquote>
-
-<p>
-where <tt>w</tt> is the bit-width of the InputIterator.
-</p>
-
-
-
-
-
-<hr>
<h3><a name="612"></a>612. numeric_limits::is_modulo insufficently defined</h3>
<p><b>Section:</b> 18.2.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
<b>Submitter:</b> Chris Jefferson <b>Date:</b> 2006-11-10</p>
@@ -7644,6 +7065,7 @@ differs from the true value by an integer multiple of <tt>(max() - min() +
<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>
@@ -7742,9 +7164,9 @@ std::array does have, but array isn't mentioned.
<hr>
<h3><a name="618"></a>618. valarray::cshift() effects on empty array</h3>
-<p><b>Section:</b> 26.5.2.7 [valarray.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 26.5.2.7 [valarray.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
<b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2007-01-10</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>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>
I would respectfully request an issue be opened with the intention to
@@ -7754,32 +7176,56 @@ clarify the wording for <tt>size() == 0</tt> for <tt>cshift</tt>.
<p><b>Proposed resolution:</b></p>
<p>
-Change 26.5.2.7 [valarray.members], paragraph 7:
+Change 26.5.2.7 [valarray.members], paragraph 10:
</p>
+<blockquote>
+
+<pre>valarray&lt;T&gt; cshift(int <i>n</i>) const;
+</pre>
+
+<blockquote>
<p>
This function returns an object of class <tt>valarray&lt;T&gt;</tt>, of
-length <tt>size()</tt><ins>.</ins><del>, each of whose elements <tt>I</tt> is
+length <tt>size()</tt>, <del>each of whose elements <tt>I</tt> is
<tt>(*this)[(I + n ) % size()]</tt>. Thus, if element zero is taken as
the leftmost element, a positive value of <i>n</i> shifts the elements
-circularly left <i>n</i> places.</del> <ins>When
-<tt>size()</tt> is positive, each element at index <tt>I</tt> of the
-returned valarray is equivalent to <tt>(*this)[(I + n) % size()]</tt>.
-Therefore <tt>cshift()</tt> returns an <i>n</i>-fold left cyclic
-rotation of the elements of <tt>*this</tt>.</ins>
+circularly left <i>n</i> places.</del> <ins>that is a circular shift of <tt>*this</tt>. If
+element zero is taken as the leftmost element, a non-negative value of
+<i>n</i> shifts the elements circularly left <i>n</i> places and a
+negative value of <i>n</i> shifts the elements circularly right
+-<i>n</i> places.</ins>
+</p>
+</blockquote>
+</blockquote>
+
+
+
+<p><b>Rationale:</b></p>
+<p>
+We do not believe that there is any real ambiguity about what happens
+when <tt>size() == 0</tt>, but we do believe that spelling this out as a C++
+expression causes more trouble that it solves. The expression is
+certainly wrong when <tt>n &lt; 0</tt>, since the sign of % with negative arguments
+is implementation defined.
</p>
+<p><i>[
+Kona (2007) Changed proposed wording, added rationale and set to Review.
+]</i></p>
+
+
<hr>
<h3><a name="620"></a>620. valid uses of empty valarrays</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>
+<p><b>Section:</b> 26.5.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
<b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-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>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>
@@ -7845,10 +7291,10 @@ function.
<hr>
<h3><a name="621"></a>621. non-const copy assignment operators of helper arrays</h3>
-<p><b>Section:</b> 26.5 [numarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 26.5 [numarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
<b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numarray">issues</a> in [numarray].</p>
-<p><b>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>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>
@@ -7866,6 +7312,27 @@ reference semantics (existing implementations vary widely).
</p>
+<p>
+Pre-Kona, Martin adds:
+</p>
+
+<p>
+I realized that adding the const qualifier to the
+functions as I suggested would break the const correctness of the
+classes. A few possible solutions come to mind:
+</p>
+
+<ol>
+<li>Add the const qualifier to the return types of these functions.</li>
+<li>Change the return type of all the functions to void to match
+the signatures of all the other assignment operators these classes
+define.</li>
+<li>Prohibit the copy assignment of these classes by declaring the
+copy assignment operators private (as is done and documented by
+some implementations).</li>
+</ol>
+
+
<p><b>Proposed resolution:</b></p>
<p>
@@ -7882,53 +7349,58 @@ Specifically, make the following edits:
<p>
Change the signature in 26.5.5 [template.slice.array] and
-26.5.5.2 [slice.arr.assign] as follows:
+26.5.5.1 [slice.arr.assign] as follows:
</p>
<blockquote><pre>
-<code>slice_array&amp; operator= (const slice_array&amp;)<ins> const</ins>;</code>
+<code><ins>const</ins> slice_array&amp; operator= (const slice_array&amp;)<ins> const</ins>;</code>
</pre></blockquote>
<p>
Change the signature in 26.5.7 [template.gslice.array] and
-26.5.7.2 [gslice.array.assign] as follows:
+26.5.7.1 [gslice.array.assign] as follows:
</p>
<blockquote><pre>
-<code>gslice_array&amp; operator= (const gslice_array&amp;)<ins> const</ins>;</code>
+<code><ins>const</ins> gslice_array&amp; operator= (const gslice_array&amp;)<ins> const</ins>;</code>
</pre></blockquote>
<p>
-Change the signature in 26.5.8 [template.mask.array] and 26.5.8.2 [mask.array.assign] as
+Change the signature in 26.5.8 [template.mask.array] and 26.5.8.1 [mask.array.assign] as
follows:
</p>
<blockquote><pre>
-<code>mask_array&amp; operator= (const mask_array&amp;)<ins> const</ins>;</code>
+<code><ins>const</ins> mask_array&amp; operator= (const mask_array&amp;)<ins> const</ins>;</code>
</pre></blockquote>
<p>
Change the signature in 26.5.9 [template.indirect.array] and
-26.5.9.2 [indirect.array.assign] as follows:
+26.5.9.1 [indirect.array.assign] as follows:
</p>
<blockquote><pre>
-<code>indirect_array&amp; operator= (const indirect_array&amp;)<ins> const</ins>;</code>
+<code><ins>const</ins> indirect_array&amp; operator= (const indirect_array&amp;)<ins> const</ins>;</code>
</pre></blockquote>
+<p><i>[
+Kona (2007) Added const qualification to the return types and set to Ready.
+]</i></p>
+
+
<hr>
<h3><a name="622"></a>622. behavior of <code>filebuf</code> dtor and <code>close</code> on error</h3>
-<p><b>Section:</b> 27.8.1.17 [fstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 27.8.1.17 [fstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
<b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-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>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>
@@ -8000,6 +7472,12 @@ errors.
</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-active.html#418">418</a> for related issues.
+]</i></p>
+
+
+
<p><b>Proposed resolution:</b></p>
<p>
@@ -8073,9 +7551,9 @@ the exception is caught but not rethrown (see
<hr>
<h3><a name="623"></a>623. <code>pubimbue</code> forbidden to call <code>imbue</code></h3>
-<p><b>Section:</b> 27.1.1 [iostream.limits.imbue] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 27.1.1 [iostream.limits.imbue] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
<b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-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>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>
@@ -8117,9 +7595,9 @@ causes any instance of <code>basic_ios::imbue</code> or
<hr>
<h3><a name="624"></a>624. <code>valarray</code> assignment and arrays of unequal length</h3>
-<p><b>Section:</b> 26.5.2.2 [valarray.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 26.5.2.2 [valarray.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
<b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-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>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>
@@ -8176,9 +7654,6 @@ And see more history in
<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/1993/N0280.pdf">N0280</a>.
</p>
-
-
-<p><b>Proposed resolution:</b></p>
<p>
It has been argued in discussions on the committee's reflector that
@@ -8211,6 +7686,29 @@ to implement <code>valarray</code> efficiently.
</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Insert new paragraph into 26.5.2.2 [valarray.assign]:
+</p>
+
+<blockquote>
+<pre>valarray&lt;T&gt;&amp; operator=(const slice_array&lt;T&gt;&amp;);
+valarray&lt;T&gt;&amp; operator=(const gslice_array&lt;T&gt;&amp;);
+valarray&lt;T&gt;&amp; operator=(const mask_array&lt;T&gt;&amp;);
+valarray&lt;T&gt;&amp; operator=(const indirect_array&lt;T&gt;&amp;);
+</pre>
+<blockquote>
+<p><ins>
+<i>Requires</i>: The length of the array to which the argument refers
+equals <code>size()</code>.
+</ins></p>
+<p>
+These operators allow the results of a generalized subscripting operation to be assigned directly to a <tt>valarray</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+
@@ -8338,7 +7836,6 @@ Batavia: Alan and Pete to work.
<h3><a name="626"></a>626. new <i>Remark</i> clauses not documented</h3>
<p><b>Section:</b> 17.3.1.3 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
<b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#structure.specifications">active issues</a> in [structure.specifications].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#structure.specifications">issues</a> in [structure.specifications].</p>
<p><b>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>
@@ -8373,10 +7870,10 @@ Batavia: Alan and Pete to work.
<hr>
<h3><a name="627"></a>627. Low memory and exceptions</h3>
-<p><b>Section:</b> 18.5.1.1 [new.delete.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 18.5.1.1 [new.delete.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
<b>Submitter:</b> P.J. Plauger <b>Date:</b> 2007-01-23</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete.single">issues</a> in [new.delete.single].</p>
-<p><b>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>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 recognize the need for nothrow guarantees in the exception reporting
@@ -8400,47 +7897,11 @@ footnote, but the wording has to be a bit vague. The idea is that if
<hr>
-<h3><a name="628"></a>628. Inconsistent definition of basic_regex constructor</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#Ready">Ready</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-01-23</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>
-Section 28.8 [re.regex] lists a constructor
-</p>
-
-<blockquote><pre>template&lt;class InputIterator&gt;
-basic_regex(InputIterator first, InputIterator last,
- flag_type f = regex_constants::ECMAScript);
-</pre></blockquote>
-
-<p>
-However, in section 28.8.2 [re.regex.construct], this constructor takes a
-pair of <tt>ForwardIterator</tt>.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 28.8.2 [re.regex.construct]:
-</p>
-
-<blockquote><pre>template &lt;class <del>ForwardIterator</del> <ins>InputIterator</ins>&gt;
- basic_regex(<del>ForwardIterator</del> <ins>InputIterator</ins> first, <del>ForwardIterator</del> <ins>InputIterator</ins> last,
- flag_type f = regex_constants::ECMAScript);
-</pre></blockquote>
-
-
-
-
-
-
-<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#New">New</a>
+<p><b>Section:</b> 26.3.6 [complex.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
<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#New">New</a> status.</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>
is there an issue opened for (0,3) as complex number with
@@ -8478,11 +7939,11 @@ dedicated facet. Then complex should use that solution.
<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#New">New</a>
+<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#New">New</a> status.</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>
@@ -8609,15 +8070,22 @@ performing the assignment.</ins>
</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#New">New</a>
+<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#New">New</a> status.</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
@@ -8650,6 +8118,12 @@ In the description of <tt>lexicographical_compare</tt>, we have both
*<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>
@@ -8694,11 +8168,11 @@ when you only need one, and which one.
<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#New">New</a>
+<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#New">New</a> status.</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:
@@ -8747,101 +8221,24 @@ away.
</p>
-
-
-
-<hr>
-<h3><a name="634"></a>634. <tt>allocator.address()</tt> doesn't work for types overloading <tt>operator&amp;</tt></h3>
-<p><b>Section:</b> 20.6.1.1 [allocator.members] <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> 2007-02-07</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.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>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a></p>
-<p><b>Discussion:</b></p>
-
-<p>
-20.6.1.1 [allocator.members] says:
-</p>
-<blockquote>
-<pre>pointer address(reference <i>x</i>) const;</pre>
-<blockquote>
-<p>
--1- <i>Returns:</i> <tt>&amp;<i>x</i></tt>.
-</p>
-</blockquote>
-</blockquote>
-
-<p>
-20.6.1.1 [allocator.members] defines <tt>CopyConstructible</tt> which currently not
-only defines the semantics of copy construction, but also restricts what an overloaded
-<tt>operator&amp;</tt> may do. I believe proposals are in the works (such as concepts
-and rvalue reference) to decouple these two requirements. Indeed it is not evident
-that we should disallow overloading <tt>operator&amp;</tt> to return something other
-than the address of <tt>*this</tt>.
-</p>
-
-<p>
-An example of when you want to overload <tt>operator&amp;</tt> to return something
-other than the object's address is proxy references such as <tt>vector&lt;bool&gt;</tt>
-(or its replacement, currently code-named <tt>bit_vector</tt>). Taking the address of
-such a proxy reference should logically yield a proxy pointer, which when dereferenced,
-yields a copy of the original proxy reference again.
-</p>
-
-<p>
-On the other hand, some code truly needs the address of an object, and not a proxy
-(typically for determining the identity of an object compared to a reference object).
-<a href="http://www.boost.org/">boost</a> has long recognized this dilemma and solved it with
-<a href="http://www.boost.org/libs/utility/utility.htm#addressof"><tt>boost::addressof</tt></a>.
-It appears to me that this would be useful functionality for the default allocator. Adopting
-this definition for <tt>allocator::address</tt> would free the standard of requiring
-anything special from types which overload <tt>operator&amp;</tt>. Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a>
-is expected to make use of <tt>allocator::address</tt> mandatory for containers.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 20.6.1.1 [allocator.members]:
-</p>
-
-<blockquote>
-<pre>pointer address(reference <i>x</i>) const;</pre>
-<blockquote>
-<p>
--1- <i>Returns:</i> <del><tt>&amp;<i>x</i></tt>.</del> <ins>The actual address of <tt><i>x</i></tt>,
-even in the presence of an overloaded <tt>operator&amp;</tt>.</ins>
-</p>
-</blockquote>
-
-<pre>const_pointer address(address(const_reference <i>x</i>) const;</pre>
-<blockquote>
-<p>
--2- <i>Returns:</i> <del><tt>&amp;<i>x</i></tt>.</del> <ins>The actual address of <tt><i>x</i></tt>,
-even in the presence of an overloaded <tt>operator&amp;</tt>.</ins>
-</p>
-</blockquote>
-</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>.
+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>
-
-
<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#New">New</a>
+<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#New">New</a> status.</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
@@ -8907,54 +8304,22 @@ post Oxford: This would be rendered NAD Editorial by acceptance of
]</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="637"></a>637. [c.math]/10 inconsistent return values</h3>
-<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-02-13</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
-<p><b>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>
-26.7 [c.math], paragraph 10 has long lists of added signatures for float and long double
-functions. All the signatures have float/long double return values, which is
-inconsistent with some of the double functions they are supposed to
-overload.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 26.7 [c.math], paragraph 10,
-</p>
-
-<blockquote><pre><del>float</del> <ins>int</ins> ilogb(float);
-<del>float</del> <ins>long</ins> lrint(float);
-<del>float</del> <ins>long</ins> lround(float);
-<del>float</del> <ins>long long</ins> llrint(float);
-<del>float</del> <ins>long long</ins> llround(float);
-
-<del>long double</del> <ins>int</ins> ilogb(long double);
-<del>long double</del> <ins>long</ins> lrint(long double);
-<del>long double</del> <ins>long</ins> lround(long double);
-<del>long double</del> <ins>long long</ins> llrint(long double);
-<del>long double</del> <ins>long long</ins> llround(long double);
-</pre></blockquote>
-
-
-
<hr>
<h3><a name="638"></a>638. deque end invalidation during erase</h3>
-<p><b>Section:</b> 23.2.2.3 [deque.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 23.2.2.3 [deque.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
<b>Submitter:</b> Steve LoBasso <b>Date:</b> 2007-02-17</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>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 standard states at 23.2.2.3 [deque.modifiers]/4:
@@ -8992,298 +8357,31 @@ pop_front() with size() == 1
<p><b>Proposed resolution:</b></p>
<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="639"></a>639. Still problems with exceptions during streambuf IO</h3>
-<p><b>Section:</b> 27.6.1.2.3 [istream::extractors], 27.6.2.6.3 [ostream.inserters] <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> 2007-02-17</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</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 already exist two active DR's for the wording of 27.6.1.2.3 [istream::extractors]/13
-from 14882:2003(E), namely <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#413">413</a>.
-</p>
-
-<p>
-Even with these proposed corrections, already maintained in N2134,
-I have the feeling, that the current wording does still not properly
-handle the "exceptional" situation. The combination of para 14
-</p>
-
-<blockquote><p>
-"[..] Characters are extracted and inserted until
-any of the following occurs:
-</p>
-<p>
-[..]
-</p>
-<p>
-- an exception occurs (in which case the exception is caught)."
-</p></blockquote>
-
-<p>
-and 15
-</p>
-
-<blockquote><p>
-"If the function inserts no characters, it calls setstate(failbit),
-which
-may throw ios_base::failure (27.4.4.3). If it inserted no characters
-because it caught an exception thrown while extracting characters
-from *this and failbit is on in exceptions() (27.4.4.3), then the
-caught
-exception is rethrown."
-</p></blockquote>
-
-<p>
-both in N2134 seems to imply that any exception, which occurs
-*after* at least one character has been inserted is caught and lost
-for
-ever. It seems that even if failbit is on in exceptions() rethrow is
-not
-allowed due to the wording "If it inserted no characters because it
-caught an exception thrown while extracting".
-</p>
-
-<p>
-Is this behaviour by design?
-</p>
-
-<p>
-I would like to add that its output counterpart in 27.6.2.6.3 [ostream.inserters]/7-9
-(also
-N2134) does not demonstrate such an exception-loss-behaviour.
-On the other side, I wonder concerning several subtle differences
-compared to input::
-</p>
-<p>
-1) Paragraph 8 says at its end:
-</p>
-
-<blockquote><p>
-"- an exception occurs while getting a character from sb."
-</p></blockquote>
-
-<p>
-Note that there is nothing mentioned which would imply that such
-an exception will be caught compared to 27.6.1.2.3 [istream::extractors]/14.
-</p>
-
-<p>
-2) Paragraph 9 says:
-</p>
-
-<blockquote><p>
-"If the function inserts no characters, it calls setstate(failbit)
-(which
-may throw ios_base::failure (27.4.4.3)). If an exception was thrown
-while extracting a character, the function sets failbit in error
-state,
-and if failbit is on in exceptions() the caught exception is
-rethrown."
-</p></blockquote>
-
-<p>
-The sentence starting with "If an exception was thrown" seems to
-imply that such an exception *should* be caught before.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-(a) In 27.6.1.2.3 [istream::extractors]/15 (N2134) change the sentence
-</p>
-
-<blockquote><p>
-If the function inserts no characters, it calls
-<tt>setstate(failbit)</tt>, which may throw <tt>ios_base::failure</tt>
-(27.4.4.3). If <del>it inserted no characters because it caught an
-exception thrown while extracting characters from <tt>*this</tt></del>
-<ins>an exception was thrown while extracting a character from
-<tt>*this</tt>, the function sets <tt>failbit</tt> in error state,</ins>
-and <tt>failbit</tt> is on in <tt>exceptions()</tt> (27.4.4.3), then the
-caught exception is rethrown.
-</p></blockquote>
-
-<p>
-(b) In 27.6.2.6.3 [ostream.inserters]/8 (N2134) change the sentence:
+Change 23.2.2.3 [deque.modifiers], p4:
</p>
<blockquote>
-<p>
-Gets characters from <tt>sb</tt> and inserts them in <tt>*this</tt>.
-Characters are read from <tt>sb</tt> and inserted until any of the
-following occurs:
-</p>
-<ul>
-<li>end-of-file occurs on the input sequence;</li>
-<li>inserting in the output sequence fails (in which case the character to be inserted is not extracted);</li>
-<li>an exception occurs while getting a character from <tt>sb</tt> <ins>(in which
-case the exception is caught)</ins>.</li>
-</ul>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="640"></a>640. 27.6.2.5.2 does not handle (unsigned) long long</h3>
-<p><b>Section:</b> 27.6.2.6.2 [ostream.inserters.arithmetic] <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-02-17</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.inserters.arithmetic">issues</a> in [ostream.inserters.arithmetic].</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 arithmetic inserters are described in 27.6.2.6.2 [ostream.inserters.arithmetic].
-Although the section starts with a listing of the inserters including
-the new ones:
-</p>
-
-<blockquote><pre>operator&lt;&lt;(long long val );
-operator&lt;&lt;(unsigned long long val );
-</pre></blockquote>
-
-<p>
-the text in paragraph 1, which describes the corresponding effects
-of the inserters, depending on the actual type of val, does not
-handle the types <tt>long long</tt> and <tt>unsigned long long</tt>.
-</p>
-
-<p><i>[
-Alisdair: In addition to the (unsigned) long long problem, that whole paragraph
-misses any reference to extended integral types supplied by the
-implementation - one of the additions by core a couple of working papers
-back.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 27.6.2.6.2 [ostream.inserters.arithmetic]/1 change the third sentence
-</p>
-
-<blockquote>
-When val is of type <tt>bool</tt>, <tt>long</tt>, <tt>unsigned
-long</tt>, <ins>long long, unsigned long long,</ins> <tt>double</tt>,
-<tt>long double</tt>, or <tt>const void*</tt>, the formatting conversion
-occurs as if it performed the following code fragment:
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="643"></a>643. Impossible "as if" clauses</h3>
-<p><b>Section:</b> 27.8.1.1 [filebuf], 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#Ready">Ready</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-20</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 standard 14882:2003(E) as well as N2134 have the
-following
-defects:
-</p>
-
-<p>
-27.8.1.1 [filebuf]/5 says:
-</p>
+<pre>iterator erase(const_iterator position);
+iterator erase(const_iterator first, const_iterator last);
+</pre>
<blockquote>
<p>
-In order to support file I/O and multibyte/wide character conversion, conversions are performed using members of a
-facet, referred to as <tt><i>a_codecvt</i></tt> in following sections, obtained "as if" by
+-4- <i>Effects:</i> An erase in the middle of the <tt>deque</tt>
+invalidates all the iterators and references to elements of the
+<tt>deque</tt> <ins>and the past-the-end iterator</ins>. An erase at
+either end of the <tt>deque</tt> invalidates only the iterators and the
+references to the erased elements<ins>, except that erasing at the end
+also invalidates the past-the-end iterator</ins>.
</p>
-<blockquote><pre>codecvt&lt;charT,char,typename traits::state_type&gt; <i>a_codecvt</i> =
- use_facet&lt;codecvt&lt;charT,char,typename traits::state_type&gt; &gt;(getloc());
-</pre></blockquote>
</blockquote>
-
-<p>
-<tt>use_facet</tt> returns a <tt>const facet</tt> reference and no facet is
-copyconstructible, so the codecvt construction should fail to compile.
-</p>
-
-<p>
-A similar issue arises in 22.2.2.2.2 [facet.num.put.virtuals]/15 for <tt>num_punct</tt>.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 27.8.1.1 [filebuf]/5 change the "as if" code
-</p>
-
-<blockquote><pre><ins>const </ins>codecvt&lt;charT,char,typename traits::state_type&gt;<ins>&amp;</ins> <i>a_codecvt</i> =
- use_facet&lt;codecvt&lt;charT,char,typename traits::state_type&gt; &gt;(getloc());
-</pre></blockquote>
-
-<p>
-In 22.2.2.2.2 [facet.num.put.virtuals]/15 (This is para 5 in N2134) change
-</p>
-
-<blockquote>
-<p>
-A local variable <tt><i>punct</i></tt> is initialized via
-</p>
-<blockquote><pre><ins>const </ins>numpunct&lt;charT&gt;<ins>&amp;</ins> <i>punct</i> = use_facet&lt; numpunct&lt;charT&gt; &gt;(<i>str</i>.getloc() )<ins>;</ins>
-</pre></blockquote>
</blockquote>
-<p>
-(Please note also the additional provided trailing semicolon)
-</p>
-
-
-
-
-
-
-<hr>
-<h3><a name="644"></a>644. Possible typos in 'function' description</h3>
-<p><b>Section:</b> 20.5.14.2.6 [func.wrap.func.undef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</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#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-20.5.14.2.6 [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><b>Proposed resolution:</b></p>
-<p>
-Change 20.5.14.2 [func.wrap.func]
-</p>
-
-<blockquote><pre>...
-private:
- // 20.5.14.2.6 [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 20.5.14.2.6 [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>
+<p><i>[
+Kona (2007): Proposed wording added and moved to Review.
+]</i></p>
@@ -9291,11 +8389,11 @@ template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator!=(const
<hr>
<h3><a name="645"></a>645. Missing members in match_results</h3>
-<p><b>Section:</b> 28.10 [re.results] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 28.10 [re.results] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
<b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-26</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re.results">active issues</a> in [re.results].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.results">issues</a> in [re.results].</p>
-<p><b>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>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>
According to the description given in 28.10 [re.results]/2 the class template
@@ -9348,221 +8446,45 @@ should be added according to tables 80/81.
<p><b>Proposed resolution:</b></p>
<p>
+Add the following members to the <tt>match_results</tt> synopsis after <tt>end()</tt> in 28.10 [re.results]
+para 3:
</p>
-
-
-
-
-<hr>
-<h3><a name="646"></a>646. const incorrect match_result members</h3>
-<p><b>Section:</b> 28.10.4 [re.results.form] <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-02-26</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>
-28.10.4 [re.results.form] (root and para 3) in N2134 defines the two function template
-members format as non-const functions, although they are declared
-as const in 28.10 [re.results]/3.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add the missing <tt>const</tt> specifier to both <tt>format</tt> overloads described
-in section 28.10.4 [re.results.form].
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="647"></a>647. Inconsistent regex_search params</h3>
-<p><b>Section:</b> 28.11.3 [re.alg.search] <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> 2007-02-26</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>
-28.11.3 [re.alg.search]/5 declares
-</p>
-
-<blockquote><pre>template &lt;class iterator, class charT, class traits&gt;
-bool regex_search(iterator first, iterator last,
- const basic_regex&lt;charT, traits&gt;&amp; e,
- regex_constants::match_flag_type flags =
- regex_constants::match_default);
-</pre></blockquote>
-
-<p>
-where it's not explained, which iterator category
-the parameter iterator belongs to. This is inconsistent
-to the preceding declaration in the synopsis section
-28.4 [re.syn], which says:
-</p>
-
-<blockquote><pre>template &lt;class BidirectionalIterator, class charT, class traits&gt;
-bool regex_search(BidirectionalIterator first, BidirectionalIterator last,
- const basic_regex&lt;charT, traits&gt;&amp; e,
- regex_constants::match_flag_type flags =
- regex_constants::match_default);
+<blockquote><pre>const_iterator cbegin() const;
+const_iterator cend() const;
</pre></blockquote>
-
-<p><b>Proposed resolution:</b></p>
<p>
-In 28.11.3 [re.alg.search]/5 replace all three occurences of param "iterator" with
-"BidirectionalIterator"
+In section 28.10.3 [re.results.acc] change:
</p>
-<blockquote><pre>template &lt;class <del>iterator</del> <ins>BidirectionalIterator</ins>, class charT, class traits&gt;
- bool regex_search(<del>iterator</del> <ins>BidirectionalIterator</ins> first, <del>iterator</del> <ins>BidirectionalIterator</ins> last,
- const basic_regex&lt;charT, traits&gt;&amp; e,
- regex_constants::match_flag_type flags =
- regex_constants::match_default);
+<blockquote>
+<pre>const_iterator begin() const;
+<ins>const_iterator cbegin() const;</ins>
</pre>
+<blockquote>
<p>
--6- <i>Effects:</i> Behaves "as if" by constructing an object what of
-type <tt>match_results&lt;<del>iterator</del>
-<ins>BidirectionalIterator</ins>&gt;</tt> and then returning the result
-of <tt>regex_search(first, last, what, e, flags)</tt>.
+-7- <i>Returns:</i> A starting iterator that enumerates over all the sub-expressions stored in <tt>*this</tt>.
</p>
</blockquote>
-
-
-
-
-<hr>
-<h3><a name="650"></a>650. regex_token_iterator and const correctness</h3>
-<p><b>Section:</b> 28.12.2 [re.tokiter] <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> 2007-03-05</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.tokiter">issues</a> in [re.tokiter].</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>Both the class definition of regex_token_iterator (28.12.2
-[re.tokiter]/6) and the latter member specifications (28.12.2.2
-[re.tokiter.comp]/1+2) declare both comparison operators as
-non-const functions. Furtheron, both dereference operators are
-unexpectedly also declared as non-const in 28.12.2 [re.tokiter]/6
-as well as in (28.12.2.3 [re.tokiter.deref]/1+2).
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-1) In (28.12.2 [re.tokiter]/6) change the current declarations
-</p>
-
-<blockquote><pre>bool operator==(const regex_token_iterator&amp;) <ins>const</ins>;
-bool operator!=(const regex_token_iterator&amp;) <ins>const</ins>;
-const value_type&amp; operator*() <ins>const</ins>;
-const value_type* operator-&gt;() <ins>const</ins>;
-</pre></blockquote>
-
-<p>
-2) In 28.12.2.2 [re.tokiter.comp] change the following declarations
-</p>
-
-<blockquote><pre>bool operator==(const regex_token_iterator&amp; right) <ins>const</ins>;
-bool operator!=(const regex_token_iterator&amp; right) <ins>const</ins>;
-</pre></blockquote>
-
-<p>
-3) In 28.12.2.3 [re.tokiter.deref] change the following declarations
-</p>
-
-<blockquote><pre>const value_type&amp; operator*() <ins>const</ins>;
-const value_type* operator-&gt;() <ins>const</ins>;
-</pre></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="651"></a>651. Missing preconditions for regex_token_iterator c'tors</h3>
-<p><b>Section:</b> 28.12.2.1 [re.tokiter.cnstr] <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> 2007-03-05</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.tokiter.cnstr">issues</a> in [re.tokiter.cnstr].</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 text provided in 28.12.2.1 [re.tokiter.cnstr]/2+3 describes
-the effects of the three non-default constructors of class
-template regex_token_iterator but is does not clarify which values
-are legal values for submatch/submatches. This becomes
-an issue, if one takes 28.12.2 [re.tokiter]/9 into account, which explains
-the notion of a "current match" by saying:
-</p>
-
-<blockquote><p>
-The <i>current match</i> is <tt>(*position).prefix()</tt> if <tt>subs[N]
-== -1</tt>, or <tt>(*position)[subs[N]]</tt> for any other value of
-<tt>subs[N]</tt>.
-</p></blockquote>
-
-<p>
-It's not clear to me, whether other negative values except -1
-are legal arguments or not - it seems they are not.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add the following precondition paragraph just before the current
-28.12.2.1 [re.tokiter.cnstr]/2:
-</p>
-
-<blockquote><p>
-<i>Requires:</i> Each of the initialization values of <tt>subs</tt> must be <tt>&gt;= -1</tt>.
-</p></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="652"></a>652. regex_iterator and const correctness</h3>
-<p><b>Section:</b> 28.12.1 [re.regiter] <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> 2007-03-05</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>Both the class definition of regex_iterator (28.12.1 [re.regiter]/1)
-and the latter member specification (28.12.1.2 [re.regiter.comp]/1+2)
-declare both comparison operators as
-non-const functions. Furtheron, both dereference operators are
-unexpectedly also declared as non-const in 28.12.1 [re.regiter]/1
-as well as in (28.12.1.3 [re.regiter.deref]/1+2).
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-1) In (28.12.1 [re.regiter]/1) change the current declarations
-</p>
-
-<blockquote><pre>bool operator==(const regex_iterator&amp;) <ins>const</ins>;
-bool operator!=(const regex_iterator&amp;) <ins>const</ins>;
-const value_type&amp; operator*() <ins>const</ins>;
-const value_type* operator-&gt;() <ins>const</ins>;
-</pre></blockquote>
-
+<pre>const_iterator end() const;
+<ins>const_iterator cend() const;</ins>
+</pre>
+<blockquote>
<p>
-2) In 28.12.1.3 [re.regiter.deref] change the following declarations
+-8- <i>Returns:</i> A terminating iterator that enumerates over all the sub-expressions stored in <tt>*this</tt>.
</p>
+</blockquote>
+</blockquote>
-<blockquote><pre>const value_type&amp; operator*() <ins>const</ins>;
-const value_type* operator-&gt;() <ins>const</ins>;
-</pre></blockquote>
-<p>
-3) In 28.12.1.2 [re.regiter.comp] change the following declarations
-</p>
-<blockquote><pre>bool operator==(const regex_iterator&amp; right) <ins>const</ins>;
-bool operator!=(const regex_iterator&amp; right) <ins>const</ins>;
-</pre></blockquote>
+<p><i>[
+Kona (2007): Voted to adopt proposed wording in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>
+except removing the entry in the table container requirements. Moved to Review.
+]</i></p>
@@ -9570,10 +8492,10 @@ bool operator!=(const regex_iterator&amp; right) <ins>const</ins>;
<hr>
<h3><a name="653"></a>653. Library reserved names</h3>
-<p><b>Section:</b> 1.2 [intro.refs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 1.2 [intro.refs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
<b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-03-08</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#intro.refs">issues</a> in [intro.refs].</p>
-<p><b>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>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>
</p>
@@ -9622,322 +8544,27 @@ that are valid identifiers in C++ but likely to cause trouble in shared
headers (e.g. restrict)
</p>
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="654"></a>654. Missing IO roundtrip for random number engines</h3>
-<p><b>Section:</b> 26.4.1.3 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-08</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.req.eng">active issues</a> in [rand.req.eng].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req.eng">issues</a> in [rand.req.eng].</p>
-<p><b>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 98 and para 5 in 26.4.1.3 [rand.req.eng] specify
-the IO insertion and extraction semantic of random
-number engines. It can be shown, v.i., that the specification
-of the extractor cannot guarantee to fulfill the requirement
-from para 5:
-</p>
-
-<blockquote><p>
-If a textual representation written via os &lt;&lt; x was
-subsequently read via is &gt;&gt; v, then x == v provided that
-there have been no intervening invocations of x or of v.
-</p></blockquote>
-
-<p>
-The problem is, that the extraction process described in
-table 98 misses to specify that it will initially set the
-if.fmtflags to ios_base::dec, see table 104:
-</p>
-
-<blockquote><p>
-dec: converts integer input or generates integer output
-in decimal base
-</p></blockquote>
-
-<p>
-Proof: The following small program demonstrates the violation
-of requirements (exception safety not fulfilled):
-</p>
-
-<blockquote><pre>#include &lt;cassert&gt;
-#include &lt;ostream&gt;
-#include &lt;iostream&gt;
-#include &lt;iomanip&gt;
-#include &lt;sstream&gt;
-
-class RanNumEngine {
- int state;
-public:
- RanNumEngine() : state(42) {}
-
- bool operator==(RanNumEngine other) const {
- return state == other.state;
- }
-
- template &lt;typename Ch, typename Tr&gt;
- friend std::basic_ostream&lt;Ch, Tr&gt;&amp; operator&lt;&lt;(std::basic_ostream&lt;Ch, Tr&gt;&amp; os, RanNumEngine engine) {
- Ch old = os.fill(os.widen(' ')); // Sets space character
- std::ios_base::fmtflags f = os.flags();
- os &lt;&lt; std::dec &lt;&lt; std::left &lt;&lt; engine.state; // Adds ios_base::dec|ios_base::left
- os.fill(old); // Undo
- os.flags(f);
- return os;
- }
-
- template &lt;typename Ch, typename Tr&gt;
- friend std::basic_istream&lt;Ch, Tr&gt;&amp; operator&gt;&gt;(std::basic_istream&lt;Ch, Tr&gt;&amp; is, RanNumEngine&amp; engine) {
- // Uncomment only for the fix.
-
- //std::ios_base::fmtflags f = is.flags();
- //is &gt;&gt; std::dec;
- is &gt;&gt; engine.state;
- //is.flags(f);
- return is;
- }
-};
-
-int main() {
- std::stringstream s;
- s &lt;&lt; std::setfill('#'); // No problem
- s &lt;&lt; std::oct; // Yikes!
- // Here starts para 5 requirements:
- RanNumEngine x;
- s &lt;&lt; x;
- RanNumEngine v;
- s &gt;&gt; v;
- assert(x == v); // Fails: 42 == 34
-}
-</pre></blockquote>
-
-<p>
-A second, minor issue seems to be, that the insertion
-description from table 98 unnecessarily requires the
-addition of ios_base::fixed (which only influences floating-point
-numbers). Its not entirely clear to me whether the proposed
-standard does require that the state of random number engines
-is stored in integral types or not, but I have the impression
-that this is the indent, see e.g. p. 3
-</p>
-
-<blockquote><p>
-The specification of each random number engine defines the
-size of its state in multiples of the size of its result_type.
-</p></blockquote>
-
-<p>
-If other types than integrals are supported, then I wonder why
-no requirements are specified for the precision of the stream.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-1) In table 98 from 26.4.1.3 [rand.req.eng] in column "pre/post-condition",
-row expression "<tt>is &gt;&gt; x</tt>" change
-</p>
-
-<blockquote><p>
-Sets <tt>v</tt>'s state as determined by
-reading its textual representation
-<ins>with <tt>is.fmtflags</tt> set to <tt>ios_base::dec</tt></ins>
-from <tt>is</tt>.
-</p></blockquote>
-
-<p>
-2) In table 98 from 26.4.1.3 [rand.req.eng] in column "pre/post-condition",
-row expression "<tt>os &lt;&lt; x</tt>" change
-</p>
-
-<blockquote><p>
-With <tt>os.fmtflags</tt> set to
-<tt>ios_base::dec|<del>ios_base::fixed|</del>ios_base::left</tt> and[..]
-</p></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="655"></a>655. Signature of generate_canonical not useful</h3>
-<p><b>Section:</b> 26.4.7.2 [rand.util.canonical] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-08</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 26.4.2 [rand.synopsis] we have the declaration
-</p>
-
-<blockquote><pre>template&lt;class RealType, class UniformRandomNumberGenerator,
- size_t bits&gt;
-result_type generate_canonical(UniformRandomNumberGenerator&amp; g);
-</pre></blockquote>
-
-<p>
-Besides the "result_type" issue (already recognized by Bo Persson
-at Sun, 11 Feb 2007 05:26:47 GMT in this group) it's clear, that
-the template parameter order is not reasonably choosen: Obviously
-one always needs to specify all three parameters, although usually
-only two are required, namely the result type RealType and the
-wanted bits, because UniformRandomNumberGenerator can usually
-be deduced.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In the header <tt>&lt;random&gt;</tt> synopsis 26.4.2 [rand.synopsis] as well as in the corresponding
-function description in 26.4.7.2 [rand.util.canonical]26.4.7.2 between para 2 and 3 change the
-declaration
-</p>
-
-<blockquote><pre>template&lt;class RealType<del>, class UniformRandomNumberGenerator</del>, size_t bits<ins>, class UniformRandomNumberGenerator</ins>&gt;
-RealType generate_canonical(UniformRandomNumberGenerator&amp; g);
-</pre></blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="657"></a>657. unclear requirement about header inclusion</h3>
-<p><b>Section:</b> 17.4.2.1 [using.headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Gennaro Prota <b>Date:</b> 2007-03-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>
-17.4.2.1 [using.headers] states:
-</p>
-
-<blockquote><p>
-A translation unit shall include a header only outside of any
-external declaration or definition, [...]
-</p></blockquote>
-
-<p>
-I see three problems with this requirement:
-</p>
-
-<ol type="a">
-<li><p>The C++ standard doesn't define what an "external declaration" or
-an "external definition" are (incidentally the C99 standard does, and
-has a sentence very similar to the above regarding header inclusion).
-</p><p>
-I think the intent is that the #include directive shall lexically
-appear outside *any* declaration; instead, when the issue was pointed
-out on comp.std.c++ at least one poster interpreted "external
-declaration" as "declaration of an identifier with external linkage".
-If this were the correct interpretation, then the two inclusions below
-would be legal:
-</p>
-<blockquote><pre> // at global scope
- static void f()
- {
-# include &lt;cstddef&gt;
- }
-
- static void g()
- {
-# include &lt;stddef.h&gt;
- }
-</pre></blockquote>
-<p>
-(note that while the first example is unlikely to compile correctly,
-the second one may well do)
-</p></li>
-
-<li><p>as the sentence stands, violations will require a diagnostic; is
-this the intent? It was pointed out on comp.std.c++ (by several
-posters) that at least one way to ensure a diagnostic exists:
-</p>
-<blockquote><p>
- [If there is an actual file for each header,] one simple way
- to implement this would be to insert a reserved identifier
- such as __begin_header at the start of each standard header.
- This reserved identifier would be ignored for all other
- purposes, except that, at the appropriate point in phase 7, if
- it is found inside an external definition, a diagnostic is
- generated. There's many other similar ways to achieve the same
- effect.
- </p>
-<p> --James Kuyper, on comp.std.c++
-</p></blockquote></li>
-
-<li><p>is the term "header" meant to be limited to standard headers?
-Clause 17 is all about the library, but still the general question is
-interesting and affects one of the points in the explicit namespaces
-proposal (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1691.html">n1691</a>):
-</p>
-<blockquote><p>
- Those seeking to conveniently enable argument-dependent
- lookups for all operators within an explicit namespace
- could easily create a header file that does so:
-</p><pre> namespace mymath::
- {
- #include "using_ops.hpp"
- }
-</pre></blockquote>
-</li>
-</ol>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
+<p><i>[
+Kona (2007): Recommend NAD. No one has identified a specific defect, just the possibility of one.
+]</i></p>
-<hr>
-<h3><a name="658"></a>658. Two unspecified function comparators in [function.objects]</h3>
-<p><b>Section:</b> 20.5 [function.objects] <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> 2007-03-19</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#function.objects">active issues</a> in [function.objects].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</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 header <tt>&lt;functional&gt;</tt> synopsis in 20.5 [function.objects]
-contains the following two free comparison operator templates
-for the <tt>function</tt> class template
-</p>
+<p><i>[
+Post-Kona: Alisdair request Open. A good example of the problem was a
+discussion of the system error proposal, where it was pointed out an all-caps
+identifier starting with a capital E conflicted with reserved macro names for
+both Posix and C. I had absolutely no idea of this rule, and suspect I was
+not the only one in the room.<br>
+<br>
+Resolution will require someone with access to all the listed documents to
+research their respective name reservation rules, or people with access to
+specific documents add their rules to this issue until the list is complete.
+]</i></p>
-<blockquote><pre>template&lt;class Function1, class Function2&gt;
-void operator==(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);
-template&lt;class Function1, class Function2&gt;
-void operator!=(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);
-</pre></blockquote>
-<p>
-which are nowhere described. I assume that they are relicts before the
-corresponding two private and undefined member templates in the function
-template (see 20.5.14.2 [func.wrap.func] and 20.5.14.2.6 [func.wrap.func.undef]) have been introduced. The original free
-function templates should be removed, because using an undefined entity
-would lead to an ODR violation of the user.
-</p>
<p><b>Proposed resolution:</b></p>
-<p>
-Remove the above mentioned two function templates from
-the header <tt>&lt;functional&gt;</tt> synopsis (20.5 [function.objects])
-</p>
-
-<blockquote><pre><del>template&lt;class Function1, class Function2&gt;
-void operator==(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);
-template&lt;class Function1, class Function2&gt;
-void operator!=(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);</del>
-</pre></blockquote>
-
@@ -9945,10 +8572,10 @@ void operator!=(const function&lt;Function1&gt;&amp;, const function&lt;Function
<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#New">New</a>
+<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#New">New</a> status.</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
@@ -10022,78 +8649,50 @@ object suitable for use as an end-of-range.
+<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>
-<hr>
-<h3><a name="660"></a>660. Missing Bitwise Operations</h3>
-<p><b>Section:</b> 20.5 [function.objects] <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> 2007-04-02</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#function.objects">active issues</a> in [function.objects].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</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>Section 20.5 [function.objects] provides <span id="st" name="st" class="st">function</span>
-<span id="st" name="st" class="st">objects</span> for some unary and binary
-operations, but others are missing. In a LWG reflector discussion, beginning
-with c++std-lib-18078, pros and cons of adding some of the missing operations
-were discussed. Bjarne Stroustrup commented "Why standardize what isn't used?
-Yes, I see the chicken and egg problems here, but it would be nice to see a
-couple of genuine uses before making additions."</p>
-<p>A number of libraries, including Rogue Wave, GNU, Adobe ASL, and Boost, have
-already added these functions, either publicly or for internal use. For example,
-Doug Gregor commented: "Boost will also add ... (|, &amp;, ^) in 1.35.0, because we
-need those <span id="st" name="st" class="st">function</span>
-<span id="st" name="st" class="st">objects</span> to represent various parallel
-collective operations (reductions, prefix reductions, etc.) in the new Message
-Passing Interface (MPI) library."</p>
-<p>Because the bitwise operators have the strongest use cases, the proposed
-resolution is limited to them.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>To 20.5 [function.objects], Function objects, paragraph 2, add to the header
-&lt;functional&gt; synopsis:</p>
-<blockquote>
- <pre>template &lt;class T&gt; struct bit_and;
-template &lt;class T&gt; struct bit_or;
-template &lt;class T&gt; struct bit_xor;</pre>
-</blockquote>
-<p>At a location in clause 20 to be determined by the Project Editor, add:</p>
-<blockquote>
- <p>The library provides basic function object classes for all of the bitwise
- operators in the language ([expr.bit.and], [expr.or], [exp.xor]).</p>
- <pre>template &lt;class T&gt; struct bit_and : binary_function&lt;T,T,T&gt; {
- T operator()(const T&amp; x , const T&amp; y ) const;
-};</pre>
- <blockquote>
- <p><code>operator()</code> returns<code> x &amp; y</code> .</p>
- </blockquote>
- <pre>template &lt;class T&gt; struct bit_or : binary_function&lt;T,T,T&gt; {
- T operator()(const T&amp; x , const T&amp; y ) const;
-};</pre>
- <blockquote>
- <p><code>operator()</code> returns <code>x | y</code> .</p>
- </blockquote>
- <pre>template &lt;class T&gt; struct bit_xor : binary_function&lt;T,T,T&gt; {
- T operator()(const T&amp; x , const T&amp; y ) const;
-};</pre>
- <blockquote>
- <p><code>operator()</code> returns <code>x ^ y</code> .</p>
- </blockquote>
+<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. &nbsp;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>. &nbsp;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>. &nbsp;The main issue
+is just: <tt>istreambuf_iterator</tt> should have an <tt>operator-&gt;()</tt>!
+</p>
</blockquote>
-
<hr>
<h3><a name="661"></a>661. New 27.6.1.2.2 changes make special extractions useless</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>
+<p><b>Section:</b> 27.6.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
<b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-04-01</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.formatted.arithmetic">active issues</a> in [istream.formatted.arithmetic].</p>
<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>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>
To the more drastic changes of 27.6.1.2.2 [istream.formatted.arithmetic] in the current draft N2134 belong
@@ -10161,172 +8760,14 @@ setstate(err);
</ol>
-
-
-
-<hr>
-<h3><a name="662"></a>662. Inconsistent handling of incorrectly-placed thousands separators</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#New">New</a>
- <b>Submitter:</b> Cosmin Truta <b>Date:</b> 2007-04-05</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#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-From Section 22.2.2.1.2 [facet.num.get.virtuals], paragraphs 11 and 12, it is implied
-that the value read from a stream must be stored
-even if the placement of thousands separators does not conform to the
-<code>grouping()</code> specification from the <code>numpunct</code> facet.
-Since incorrectly-placed thousands separators are flagged as an extraction
-failure (by the means of <code>failbit</code>), we believe it is better not
-to store the value. A consistent strategy, in which any kind of extraction
-failure leaves the input item intact, is conceptually cleaner, is able to avoid
-corner-case traps, and is also more understandable from the programmer's point
-of view.
-</p>
-<p>
-Here is a quote from <i>"The C++ Programming Language (Special Edition)"</i>
-by B.&nbsp;Stroustrup (Section&nbsp;D.4.2.3, pg.&nbsp;897):
-</p>
-<blockquote><p>
-<i>"If a value of the desired type could not be read, failbit is set in r.
-[...] An input operator will use r to determine how to set the state of its
-stream. If no error was encountered, the value read is assigned through v;
-otherwise, v is left unchanged."</i>
-</p></blockquote>
-<p>
-This statement implies that <code>rdstate()</code> alone is sufficient to
-determine whether an extracted value is to be assigned to the input item
-<i>val</i> passed to <code>do_get</code>. However, this is in disagreement
-with the current C++ Standard. The above-mentioned assumption is true in all
-cases, except when there are mismatches in digit grouping. In the latter case,
-the parsed value is assigned to <i>val</i>, and, at the same time, <i>err</i>
-is assigned to <code>ios_base::failbit</code> (essentially "lying" about the
-success of the operation). Is this intentional? The current behavior raises
-both consistency and usability concerns.
-</p>
-<p>
-Although digit grouping is outside the scope of <code>scanf</code> (on which
-the virtual methods of <code>num_get</code> are based), handling of grouping
-should be consistent with the overall behavior of scanf. The specification of
-<code>scanf</code> makes a distinction between input failures and matching
-failures, and yet both kinds of failures have no effect on the input items
-passed to <code>scanf</code>. A mismatch in digit grouping logically falls in
-the category of matching failures, and it would be more consistent, and less
-surprising to the user, to leave the input item intact whenever a failure is
-being signaled.
-</p>
-<p>
-The extraction of <code>bool</code> is another example outside the scope of
-<code>scanf</code>, and yet consistent, even in the event of a successful
-extraction of a <code>long</code> but a failed conversion from
-<code>long</code> to <code>bool</code>.
-</p>
-<p>
-Inconsistency is further aggravated by the fact that, when failbit is set,
-subsequent extraction operations are no-ops until <code>failbit</code> is
-explicitly cleared. Assuming that there is no explicit handling of
-<code>rdstate()</code> (as in <code>cin&gt;&gt;i&gt;&gt;j</code>) it is
-counter-intuitive to be able to extract an integer with mismatched digit
-grouping, but to be unable to extract another, properly-formatted integer
-that immediately follows.
-</p>
-<p>
-Moreover, setting <code>failbit</code>, and selectively assigning a value to
-the input item, raises usability problems. Either the strategy of
-<code>scanf</code> (when there is no extracted value in case of failure), or
-the strategy of the <code>strtol</code> family (when there is always an
-extracted value, and there are well-defined defaults in case of a failure) are
-easy to understand and easy to use. On the other hand, if <code>failbit</code>
-alone cannot consistently make a difference between a failed extraction, and a
-successful but not-quite-correct extraction whose output happens to be the same
-as the previous value, the programmer must resort to implementation tricks.
-Consider the following example:
-</p>
-<pre> int i = old_i;
- cin &gt;&gt; i;
- if (cin.fail())
- // can the value of i be trusted?
- // what does it mean if i == old_i?
- // ...
-</pre>
-<p>
-Last but not least, the current behvaior is not only confusing to the casual
-reader, but it has also been confusing to some book authors. Besides
-Stroustrup's book, other books (e.g. "Standard C++ IOStreams and Locales" by
-Langer and Kreft) are describing the same mistaken assumption. Although books
-are not to be used instead of the standard reference, the readers of these
-books, as well as the people who are generally familiar to <code>scanf</code>,
-are even more likely to misinterpret the standard, and expect the input items
-to remain intact when a failure occurs.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-Change 22.2.2.1.2 [facet.num.get.virtuals]:
-</p>
-
-<blockquote>
-<p>
-<b>Stage 3:</b> The result of stage 2 processing can be one of
-</p>
-<ul>
-<li>A sequence of <code>chars</code> has been accumulated in stage 2 that is converted (according to the rules of <code>scanf</code>) to a value of the type of <code><i>val</i></code>. <del>This value is stored in <code><i>val</i></code> and <code>ios_base::goodbit</code> is stored in <code><i>err</i></code>.</del></li>
-
-<li>The sequence of <code>chars</code> accumulated in stage 2 would have caused <code>scanf</code> to report an input failure. <code>ios_base::failbit</code> is assigned to <code><i>err</i></code>.</li>
-</ul>
-<p>
-<ins>In the first case,</ins> <del>D</del><ins>d</ins>igit grouping is checked. That is, the positions of discarded separators is examined for consistency with <code>use_facet&lt;numpunct&lt;charT&gt; &gt;(<i>loc</i>).grouping()</code>. If they are not consistent then <code>ios_base::failbit</code> is assigned to <code><i>err</i></code>. <ins>Otherwise, the value that was converted in stage 2 is stored in <code><i>val</i></code> and <code>ios_base::goodbit</code> is stored in <code><i>err</i></code>.</ins>
-</p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="663"></a>663. Complexity Requirements</h3>
-<p><b>Section:</b> 17.3.1.3 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</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#structure.specifications">active issues</a> in [structure.specifications].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#structure.specifications">issues</a> in [structure.specifications].</p>
-<p><b>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>
-17.3.1.3 [structure.specifications] para 5 says
-</p>
-
-<blockquote><p>
--5- Complexity requirements specified in the library&nbsp;
-clauses are upper bounds, and implementations that provide better
-complexity guarantees satisfy the requirements.
-</p></blockquote>
-
-<p>
-The following
-objection has been raised:
-</p>
-
-<blockquote><p>
-The library clauses suggest general
-guidelines regarding complexity, but we have been unable to discover
-any absolute hard-and-fast formulae for these requirements.&nbsp; Unless
-or until the Library group standardizes specific hard-and-fast
-formulae, we regard all the complexity requirements as subject to a&nbsp;
-"fudge factor" without any intrinsic upper bound.
-</p></blockquote>
-
-<p>
-[Plum ref&nbsp;
-_23213Y31 etc]
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
+<p><i>[
+Kona (2007): Note to the editor: the name lval in the call to <tt>use_facet</tt>
+is incorrectly italicized in the code fragments corresponding to
+<tt>operator&gt;&gt;(short &amp;)</tt> and <tt>operator &gt;&gt;(int &amp;)</tt>. Also, val -- which appears
+twice on the line with the <tt>static_cast</tt> in the proposed resolution --
+should be italicized. Also, in response to part two of the issue: this
+is deliberate.
+]</i></p>
@@ -10334,11 +8775,11 @@ _23213Y31 etc]
<hr>
<h3><a name="664"></a>664. <tt>do_unshift</tt> for <tt>codecvt&lt;char, char, mbstate_t&gt;</tt></h3>
-<p><b>Section:</b> 22.2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 22.2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
<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.codecvt.virtuals">active issues</a> in [locale.codecvt.virtuals].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.virtuals">issues</a> in [locale.codecvt.virtuals].</p>
-<p><b>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>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>
22.2.1.4.2 [locale.codecvt.virtuals], para 7 says (regarding <tt>do_unshift</tt>):
@@ -10370,19 +8811,31 @@ instantiations of <tt>codecvt</tt>, it is overly restrictive to say that
<p><b>Proposed resolution:</b></p>
<p>
+Change 22.2.1.4.2 [locale.codecvt.virtuals], p7:
</p>
+<blockquote>
+<p>
+<i>Effects:</i> Places characters starting at <i>to</i> that should be
+appended to terminate a sequence when the current <tt>stateT</tt> is
+given by state.<sup>237)</sup> Stores no more than (<i>to_limit -to</i>)
+destination elements, and leaves the <i>to_next</i> pointer pointing one
+beyond the last element successfully stored. <del><tt>codecvt&lt;char, char,
+mbstate_t&gt;</tt> stores no characters.</del>
+</p>
+</blockquote>
+
<hr>
<h3><a name="665"></a>665. <tt>do_unshift</tt> return value</h3>
-<p><b>Section:</b> 22.2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 22.2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
<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.codecvt.virtuals">active issues</a> in [locale.codecvt.virtuals].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.virtuals">issues</a> in [locale.codecvt.virtuals].</p>
-<p><b>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>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>
22.2.1.4.2 [locale.codecvt.virtuals], para 8 says:
@@ -10410,18 +8863,28 @@ C functions do.
<p><b>Proposed resolution:</b></p>
<p>
+Change 22.2.1.4.2 [locale.codecvt.virtuals], p8:
</p>
+<blockquote>
+<p><i>Returns:</i> An enumeration value, as summarized in Table 76:</p>
+<p>...</p>
+<p>
+<del><tt>codecvt&lt;char,char,mbstate_t&gt;</tt>, returns <tt>noconv</tt>.</del>
+</p>
+</blockquote>
+
+
<hr>
<h3><a name="666"></a>666. <tt>moneypunct::do_curr_symbol()</tt></h3>
-<p><b>Section:</b> 22.2.6.3.2 [locale.moneypunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 22.2.6.3.2 [locale.moneypunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
<b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.moneypunct.virtuals">issues</a> in [locale.moneypunct.virtuals].</p>
-<p><b>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>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>
22.2.6.3.2 [locale.moneypunct.virtuals], para 4 footnote 257 says
@@ -10450,7 +8913,16 @@ four characters long.
<p><b>Proposed resolution:</b></p>
<p>
+Change footnote 253 in 22.2.6.3.2 [locale.moneypunct.virtuals]:
+</p>
+
+<blockquote>
+<p>
+<sup>253)</sup> For international specializations (second template
+parameter <tt>true</tt>) this is <del>always</del> <ins>typically</ins>
+four characters long, usually three letters and a space.
</p>
+</blockquote>
@@ -10458,11 +8930,11 @@ four characters long.
<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#New">New</a>
+<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#New">New</a> status.</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:
@@ -10499,6 +8971,11 @@ Furthermore: if <tt>ct.widen('9')</tt> produces <tt>L'X'</tt> (a non-digit), doe
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><b>Proposed resolution:</b></p>
<p>
@@ -10510,11 +8987,11 @@ parse fail if a <tt>'9'</tt> appears in the subject string? [Plum ref _22263Y33]
<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#New">New</a>
+<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#New">New</a> status.</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:
@@ -10541,6 +9018,12 @@ sign, so it's always there when you look for it".
[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>
@@ -10552,11 +9035,11 @@ sign, so it's always there when you look for it".
<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#New">New</a>
+<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#New">New</a> status.</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:
@@ -10582,6 +9065,12 @@ pattern is an unsuccessful match.
[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>
@@ -10593,9 +9082,9 @@ pattern is an unsuccessful match.
<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#New">New</a>
+<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#New">New</a> status.</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.3 [locale.moneypunct], para 2 says:
@@ -10618,6 +9107,14 @@ Whitespace&nbsp;is optional when matching space. (See 22.2.6.1.2 [locale.money.g
[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>
@@ -10629,10 +9126,10 @@ Whitespace&nbsp;is optional when matching space. (See 22.2.6.1.2 [locale.money.g
<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#New">New</a>
+<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#New">New</a> status.</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.
@@ -10694,15 +9191,21 @@ value 6.
</p>
+<p><i>[
+Kona (2007): Robert volunteers to propose wording.
+]</i></p>
+
+
<hr>
<h3><a name="672"></a>672. Swappable requirements need updating</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>
+<p><b>Section:</b> 20.1.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
<b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-04</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>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 <tt>Swappable</tt> is:
@@ -10797,41 +9300,38 @@ Change 20.1.1 [utility.arg.requirements]:
<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
+tables, <tt>T</tt> is a type 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>; and <tt>v</tt> is a value of type <tt>V</tt></ins>.
+<tt>const</tt>) <tt>T</tt>; and <tt>rv</tt> is a non-<tt>const</tt>
+rvalue of type <tt>T</tt>.
</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(s,<del>t</del><ins>v</ins>)</tt></td><td><tt>void</tt></td>
-<td><del><tt>t</tt></del><ins><tt>s</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>s</tt></ins></td></tr>
+<tr><td><tt>swap(s,t)</tt></td><td><tt>void</tt></td>
+<td><tt>t</tt> has the value originally
+held by <tt>u</tt>, and
+<tt>u</tt> has the value originally held
+by <tt>t</tt></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>);
+<tt>T</tt> is <tt>Swappable</tt> if <tt>T</tt> satisfies the
+<del><tt>CopyConstructible</tt></del> <ins>MoveConstructible</ins>
+requirements (Table <del>34</del> <ins>33</ins>) and the <del><tt>CopyAssignable</tt></del> <ins>MoveAssignable</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>T</tt> is <tt>Swappable</tt> 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>s</ins>,<del>u</del> <ins>v</ins>)</tt> is valid and has the
+<tt>T</tt>, such that the expression
+<tt>swap(t,u)</tt> is valid and has the
semantics described in this table.
</li>
</ul>
@@ -10839,13 +9339,21 @@ semantics described in this table.
</tbody></table>
</blockquote>
-<p><i>[Some editorial issues are also cleaned up by this resolution.]</i></p>
-<p>
-
-</p>
-
+<p><i>[
+Kona (2007): We like the change to the <tt>Swappable</tt> requirements to use
+move semantics. The issue relating to the support of proxies is
+separable from the one relating to move semantics, and it's bigger than
+just swap. We'd like to address only the move semantics changes under
+this issue, and open a separated issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>) to handle proxies. Also, there
+may be a third issue, in that the current definition of <tt>Swappable</tt> does
+not permit rvalues to be operands to a swap operation, and Howard's
+proposed resolution would allow the right-most operand to be an rvalue,
+but it would not allow the left-most operand to be an rvalue (some swap
+functions in the library have been overloaded to permit left operands to
+swap to be rvalues).
+]</i></p>
@@ -10853,9 +9361,9 @@ semantics described in this table.
<hr>
<h3><a name="673"></a>673. <tt>unique_ptr</tt> update</h3>
-<p><b>Section:</b> 20.6.5 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 20.6.5 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
<b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-04</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>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 publication of
@@ -10924,6 +9432,42 @@ deleter is not a pointer type in those constructors which do not accept deleters
</ul>
+<p><i>[
+Kona (2007): We don't like the solution given to the first bullet in
+light of concepts. The second bullet solves the problem of supporting
+fancy pointers for one library component only. The full LWG needs to
+decide whether to solve the problem of supporting fancy pointers
+piecemeal, or whether a paper addressing the whole library is needed. We
+think that the third bullet is correct.
+]</i></p>
+
+
+<p><i>[
+Post Kona: Howard adds example user code related to the first bullet:
+]</i></p>
+
+
+<blockquote>
+<pre>void legacy_code(void*, std::size_t);
+
+void foo(std::size_t N)
+{
+ std::unique_ptr&lt;void, void(*)(void*)&gt; ptr(std::malloc(N), std::free);
+ legacy_code(ptr.get(), N);
+} // unique_ptr used for exception safety purposes
+</pre>
+</blockquote>
+
+<p>
+I.e. <tt>unique_ptr&lt;void&gt;</tt> <i>is</i> a useful tool that we don't want
+to disable with concepts. The only part of <tt>unique_ptr&lt;void&gt;</tt> we
+want to disable (with concepts or by other means) are the two member functions:
+</p>
+
+<blockquote><pre>T&amp; operator*() const;
+T* operator-&gt;() const;
+</pre></blockquote>
+
<p><b>Proposed resolution:</b></p>
@@ -11217,10 +9761,11 @@ required)</ins>.
<hr>
<h3><a name="674"></a>674. <tt>shared_ptr</tt> interface changes for consistency with N1856</h3>
-<p><b>Section:</b> 20.6.6.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 20.6.6.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
<b>Submitter:</b> Peter Dimov <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#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#New">New</a> status.</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/papers/2005/n1856.html">N1856</a> does not propose
@@ -11237,16 +9782,11 @@ Change 20.6.6.2 [util.smartptr.shared] as follows:
<blockquote>
<pre>template&lt;class Y&gt; explicit shared_ptr(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);
-<ins>private:
-template&lt;class Y, class D&gt; explicit shared_ptr(const unique_ptr&lt;Y,D&gt;&amp; r);
-public:
+<ins>template&lt;class Y, class D&gt; explicit shared_ptr(const unique_ptr&lt;Y,D&gt;&amp; r) = delete;
template&lt;class Y, class D&gt; explicit shared_ptr(unique_ptr&lt;Y,D&gt;&amp;&amp; r);</ins>
...
template&lt;class Y&gt; shared_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);
-<ins>
-private:
-template&lt;class Y, class D&gt; shared_ptr&amp; operator=(const unique_ptr&lt;Y,D&gt;&amp; r);
-public:
+<ins>template&lt;class Y, class D&gt; shared_ptr&amp; operator=(const unique_ptr&lt;Y,D&gt;&amp; r) = delete;
template&lt;class Y, class D&gt; shared_ptr&amp; operator=(unique_ptr&lt;Y,D&gt;&amp;&amp; r);</ins></pre>
</blockquote>
@@ -11307,16 +9847,22 @@ Add to 20.6.6.2.3 [util.smartptr.shared.assign]:
+<p><i>[
+Kona (2007): We may need to open an issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#743">743</a>) to deal with the question of
+whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>.
+]</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#New">New</a>
+<p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
<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#New">New</a> status.</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>
James Hopkin pointed out to me that if <tt>vector&lt;T&gt;</tt> move assignment is O(1)
@@ -11375,7 +9921,7 @@ Change 23.1 [container.requirements]:
value that <tt>rv</tt> had
before this construction
</td>
-<td><del>constant</del> <ins>linear</ins></td>
+<td><del>constant</del> <ins>linear in <tt>a.size()</tt></ins></td>
</tr>
</tbody></table>
</blockquote>
@@ -11387,11 +9933,11 @@ before this construction
<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#New">New</a>
+<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> 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#New">New</a> status.</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>
Move semantics are missing from the <tt>unordered</tt> containers. The proposed
@@ -11993,247 +10539,10 @@ Add to 23.4.4.2 [unord.multiset.swap]:
<hr>
-<h3><a name="677"></a>677. Weaknesses in seed_seq::randomize [rand.util.seedseq]</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#New">New</a>
- <b>Submitter:</b> Charles Karney <b>Date:</b> 2007-05-15</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#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<tt>seed_seq::randomize</tt> provides a mechanism for initializing random number
-engines which ideally would yield "distant" states when given "close"
-seeds. The algorithm for <tt>seed_seq::randomize</tt> given in the current
-Working Draft for C++,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a>
-(2007-05-08), has 3 weaknesses
-</p>
-
-<ol>
-<li>
-<p> Collisions in state. Because of the way the state is initialized,
- seeds of different lengths may result in the same state. The
- current version of seed_seq has the following properties:</p>
-<ul>
-<li> For a given <tt>s &lt;= n</tt>, each of the 2^(32s) seed vectors results in a
- distinct state.</li>
-</ul>
-<p>
- The proposed algorithm (below) has the considerably stronger
- properties:</p>
-<ul>
-<li> All of the <tt>(2^(32n)-1)/(2^32-1)</tt> seed vectors of lengths <tt>s &lt; n</tt>
- result in distinct states.
-</li>
-<li> All of the <tt>2^(32n)</tt> seed vectors of length <tt>s == n</tt> result in
- distinct states.
-</li>
-</ul>
-</li>
-<li>
-<p> Poor mixing of <tt>v'</tt>s entropy into the state. Consider <tt>v.size() == n</tt>
- and hold <tt>v[n/2]</tt> thru <tt>v[n-1]</tt> fixed while varying <tt>v[0]</tt> thru <tt>v[n/2-1]</tt>,
- a total of <tt>2^(16n)</tt> possibilities. Because of the simple recursion
- used in <tt>seed_seq</tt>, <tt>begin[n/2]</tt> thru <tt>begin[n-1]</tt> can take on only 2^64
- possible states.</p>
-
-<p> The proposed algorithm uses a more complex recursion which results
- in much better mixing.</p>
-</li>
-<li> <tt>seed_seq::randomize</tt> is undefined for <tt>v.size() == 0</tt>. The proposed
- algorithm remedies this.
-</li>
-</ol>
-<p>
-The current algorithm for <tt>seed_seq::randomize</tt> is adapted by me from the
-initialization procedure for the Mersenne Twister by Makoto Matsumoto
-and Takuji Nishimura. The weakness (2) given above was communicated to
-me by Matsumoto last year.
-</p>
-<p>
-The proposed replacement for <tt>seed_seq::randomize</tt> is due to Mutsuo Saito,
-a student of Matsumoto, and is given in the implementation of the
-SIMD-oriented Fast Mersenne Twister random number generator SFMT.
-<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/index.html">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html</a>
-<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/SFMT-src-1.2.tar.gz">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/SFMT-src-1.2.tar.gz</a>
-</p>
-<p>
-See
-Mutsuo Saito,
-An Application of Finite Field: Design and Implementation of 128-bit
-Instruction-Based Fast Pseudorandom Number Generator,
-Master's Thesis, Dept. of Math., Hiroshima University (Feb. 2007)
-<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/M062821.pdf">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/M062821.pdf</a>
-</p>
-<p>
-One change has been made here, namely to treat the case of small <tt>n</tt>
-(setting <tt>t = (n-1)/2</tt> for <tt>n &lt; 7</tt>).
-</p>
-<p>
-Since <tt>seed_seq</tt> was introduced relatively recently there is little cost
-in making this incompatible improvement to it.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-The following is the proposed replacement of paragraph 8 of section
-26.4.7.1 [rand.util.seedseq]:
-</p>
-
-<blockquote>
-<p>
--8- <i>Effects:</i> With <tt><i>s</i> = v.size()</tt> and <tt><i>n</i> =
-end - begin</tt>, fills the supplied range <tt>[begin, end)</tt>
-according to the following algorithm in which each operation is to be
-carried out modulo 2<sup>32</sup>, each indexing operator applied to
-<tt>begin</tt> is to be taken modulo <tt><i>n</i></tt>, <del>each indexing
-operator applied to <tt>v</tt> is to be taken modulo <tt><i>s</i></tt>,</del>
-and <tt><i>T</i>(<i>x</i>)</tt> is defined as <tt><i>x</i> xor (<i>x</i>
-rshift <del>30</del> <ins>27</ins>)</tt>:
-</p>
-
-<ol type="a">
-<li><p><del>Set <tt>begin[0]</tt> to <tt>5489 + <i>s</i></tt>. Then,
-iteratively for <tt><i>k</i> = 1, ... , <i>n</i> - 1</tt>, set
-<tt>begin[<i>k</i>]</tt> to</del></p>
-<blockquote><pre><del>1812433253 * <i>T</i>(begin[<i>k</i>-1]) + <i>k</i>.</del>
-</pre></blockquote>
-</li>
-<li><p><del>With <tt><i>m</i></tt> as the larger of <tt><i>s</i></tt> and
-<tt><i>n</i></tt>, transform each element of the range (possibly more
-than once): iteratively for <tt><i>k</i> = 0, ..., <i>m</i> - 1</tt>,
-set <tt>begin[<i>k</i>]</tt> to</del></p>
-<blockquote><pre><del>(begin[<i>k</i>] xor (1664525 * <i>T</i>(begin[<i>k</i>-1]))) + v[<i>k</i>] + (<i>k</i> mod <i>s</i>).</del>
-</pre></blockquote>
-</li>
-<li><p><del>Transform each element of the range one last time, beginning
-where the previous step ended: iteratively for <tt><i>k</i> = <i>m</i>
-mod <i>n</i>, ..., <i>n</i> - 1, 0, ..., (<i>m</i> - 1) mod
-<i>n</i></tt>, set <tt>begin[<i>k</i>]</tt> to</del></p>
-<blockquote><pre><del>(begin[<i>k</i>] xor (1566083941 * <i>T</i>(begin[<i>k</i>-1]))) - <i>k</i>.</del>
-</pre></blockquote>
-</li>
-</ol>
-
-<blockquote><pre><ins>
-fill(begin, end, 0x8b8b8b8b);
-
-if (n &gt;= 623)
- t = 11;
-else if (n &gt;= 68)
- t = 7;
-else if (n &gt;= 39)
- t = 5;
-else if (n &gt;= 7)
- t = 3;
-else
- t = (n-1)/2;
-
-p = (n-t)/2;
-q = p+t;
-
-m = max(s+1, n);
-for (k = 0; k &lt; m; k += 1) {
- r = 1664525 * T(begin[k] ^ begin[k+p] ^ begin[k-1]);
- begin[k+p] += r;
- r += k % n;
- if (k == 0)
- r += s;
- else if (k &lt;= s)
- r += v[k-1];
- begin[k+q] += r;
- begin[k] = r;
-}
-
-for (k = m; k &lt; m + n; k += 1) {
- r = 1566083941 * T(begin[k] + begin[k+p] + begin[k-1]);
- begin[k+p] ^= r;
- r -= k % n;
- begin[k+q] ^= r;
- begin[k] = r;
-}
-</ins></pre></blockquote>
-
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="678"></a>678. Changes for [rand.req.eng]</h3>
-<p><b>Section:</b> 26.4.1.3 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Charles Karney <b>Date:</b> 2007-05-15</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.req.eng">active issues</a> in [rand.req.eng].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req.eng">issues</a> in [rand.req.eng].</p>
-<p><b>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>
-Section 26.4.1.3 [rand.req.eng] Random number engine requirements:
-</p>
-
-<p>
-This change follows naturally from the proposed change to
-<tt>seed_seq::randomize</tt> in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#677">677</a>.
-</p>
-
-<p>
-In table 104 the description of <tt>X(q)</tt> contains a special treatment of
-the case <tt>q.size() == 0</tt>. This is undesirable for 4 reasons:
-</p>
-
-<ol>
-<li>It replicates the functionality provided by <tt>X()</tt>.</li>
-<li>It leads to the possibility of a collision in the state provided
- by some other <tt>X(q)</tt> with <tt>q.size() &gt; 0</tt>.</li>
-<li>It is inconsistent with the description of the <tt>X(q)</tt> in
-paragraphs 26.4.3.1 [rand.eng.lcong] p5, 26.4.3.2 [rand.eng.mers] p8, and 26.4.3.3 [rand.eng.sub] p10 where
-there is no special treatment of <tt>q.size() == 0</tt>.</li>
-<li>The proposed replacement for <tt>seed_seq::randomize</tt> given above
- allows for the case <tt>q.size() == 0</tt>.</li>
-</ol>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-I recommend removing the special-case treatment of <tt>q.size() == 0</tt>. Here
-is the replacement line for table 104 of section 26.4.1.3 [rand.req.eng]:
-</p>
-
-<blockquote>
-<table border="1">
-<tbody><tr>
-<td><tt>X(q)</tt><sup>272</sup></td>
-<td>-</td>
-<td>
-<del>With <tt>n = q.size()</tt>, creates an
-engine <tt>u</tt> with initial state
-determined as follows: If <tt>n</tt> is <tt>0</tt>, <tt>u
-== X();</tt> otherwise, the</del> <ins>Create an engine <tt>u</tt> with an</ins> initial state <ins>which</ins>
-depends on a sequence produced by
-one call to <tt>q.randomize</tt>.
-</td>
-<td>
-O(max(<del>n</del> <ins><tt>q.size()</tt></ins>, size of state))
-</td>
-</tr>
-</tbody></table>
-</blockquote>
-
-
-
-
-
-
-<hr>
<h3><a name="679"></a>679. resize parameter by value</h3>
-<p><b>Section:</b> 23.2 [sequences] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 23.2 [sequences] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
<b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-06-11</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>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 C++98 standard specifies that one member function alone of the containers
@@ -12328,7 +10637,6 @@ Change 23.2.2.2 [deque.capacity], p3:
<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
</pre></blockquote>
-<p><b>Proposed resolution:</b></p>
<p>
Change 23.2.3 [list], p2:
</p>
@@ -12345,7 +10653,6 @@ Change 23.2.3.2 [list.capacity], p3:
<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
</pre></blockquote>
-<p><b>Proposed resolution:</b></p>
<p>
Change 23.2.5 [vector], p2:
</p>
@@ -12369,9 +10676,9 @@ Change 23.2.5.2 [vector.capacity], p11:
<hr>
<h3><a name="680"></a>680. move_iterator operator-&gt; return</h3>
-<p><b>Section:</b> 24.4.3.1 [move.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 24.4.3.1 [move.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
<b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-06-11</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>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>move_iterator</tt>'s <tt>operator-&gt;</tt> return type <tt>pointer</tt>
@@ -12432,105 +10739,12 @@ Change the synopsis in 24.4.3.1 [move.iterator]:
<hr>
-<h3><a name="681"></a>681. Operator functions impossible to compare are defined in [re.submatch.op]</h3>
-<p><b>Section:</b> 28.9.2 [re.submatch.op] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Nozomu Katoo <b>Date:</b> 2007-05-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>
-In 28.9.2 [re.submatch.op] of N2284,
-operator functions numbered 31-42 seem impossible to compare. &nbsp;E.g.:
-</p>
-
-<blockquote>
-<pre>template &lt;class BiIter&gt;
-&nbsp; &nbsp; bool operator==(typename iterator_traits&lt;BiIter&gt;::value_type const&amp; lhs,
-&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; const sub_match&lt;BiIter&gt;&amp; rhs);
-</pre>
-<blockquote>
-<p>
--31- <i>Returns:</i> <tt>lhs == rhs.str()</tt>.
-</p>
-</blockquote>
-</blockquote>
-
-<p>
-When <tt>char*</tt> is used as <tt>BiIter</tt>, <tt>iterator_traits&lt;BiIter&gt;::value_type</tt> would be
-<tt>char</tt>, so that <tt>lhs == rhs.str()</tt> ends up comparing a <tt>char</tt> value and an object
-of <tt>std::basic_string&lt;char&gt;</tt>. &nbsp;However, the behaviour of comparison between
-these two types is not defined in 21.3.8 [string.nonmembers] of N2284.
-&nbsp;This applies when <tt>wchar_t*</tt> is used as <tt>BiIter</tt>.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="682"></a>682. basic_regex ctor takes InputIterator or ForwardIterator?</h3>
-<p><b>Section:</b> 28.8.2 [re.regex.construct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Eric Niebler <b>Date:</b> 2007-06-03</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 N2284, 28.8 [re.regex], p3 <tt>basic_regex</tt> class template synopsis shows this
-constructor:
-</p>
-<blockquote><pre>template &lt;class InputIterator&gt;
-&nbsp; &nbsp; &nbsp;basic_regex(InputIterator first, InputIterator last,
-&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;flag_type f = regex_constants::ECMAScript);
-</pre></blockquote>
-
-<p>
-In 28.8.2 [re.regex.construct], p15, the constructor appears with this signature:
-</p>
-
-<blockquote><pre>template &lt;class ForwardIterator&gt;
-&nbsp; &nbsp; &nbsp;basic_regex(ForwardIterator first, ForwardIterator last,
-&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;flag_type f = regex_constants::ECMAScript);
-</pre></blockquote>
-
-<p>
-<tt>ForwardIterator</tt> is probably correct, so the synopsis is wrong.
-</p>
-
-<p><i>[
-John adds:
-]</i></p>
-
-
-<blockquote>
-<p>
-I think either could be implemented? &nbsp;Although an input iterator would
-probably require an internal copy of the string being made.
-</p>
-<p>
-I have no strong feelings either way, although I think my original intent
-was <tt>InputIterator</tt>.
-</p>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
<h3><a name="684"></a>684. Unclear which members of match_results should be used in comparison</h3>
-<p><b>Section:</b> 28.10 [re.results] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 28.10 [re.results] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
<b>Submitter:</b> Nozomu Katoo <b>Date:</b> 2007-05-27</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re.results">active issues</a> in [re.results].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.results">issues</a> in [re.results].</p>
-<p><b>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>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 28.4 [re.syn] of N2284, two template functions
@@ -12566,10 +10780,56 @@ the two objects refer to the same match - ie if one object was constructed as a
copy of the other.
</p></blockquote>
+<p><i>[
+Kona (2007): Bill and Pete to add minor wording to that proposed in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
+]</i></p>
+
+
<p><b>Proposed resolution:</b></p>
<p>
+Add a new section after 28.10.6 [re.results.swap], which reads:
+</p>
+<p>
+28.10.7 match_results non-member functions.
+</p>
+
+<blockquote>
+<pre>template&lt;class BidirectionalIterator, class Allocator&gt;
+ bool operator==(const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1,
+ const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2);
+</pre>
+<blockquote>
+<p>
+<i>Returns:</i> <tt>true</tt> only if the two objects refer to the same match.
+</p>
+</blockquote>
+</blockquote>
+
+<blockquote>
+<pre>template&lt;class BidirectionalIterator, class Allocator&gt;
+ bool operator!=(const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1,
+ const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2);
+</pre>
+<blockquote>
+<p>
+<i>Returns:</i> <tt>!(m1 == m2)</tt>.
</p>
+</blockquote>
+</blockquote>
+
+<blockquote>
+<pre>template&lt;class BidirectionalIterator, class Allocator&gt;
+ void swap(match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1,
+ match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2);
+</pre>
+<blockquote>
+<p>
+<i>Returns:</i> <tt>m1.swap(m2)</tt>.
+</p>
+</blockquote>
+</blockquote>
@@ -12577,9 +10837,9 @@ copy of the other.
<hr>
<h3><a name="685"></a>685. reverse_iterator/move_iterator difference has invalid signatures</h3>
-<p><b>Section:</b> 24.4.1.3.19 [reverse.iter.opdiff], 24.4.3.3.14 [move.iter.nonmember] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 24.4.1.3.19 [reverse.iter.opdiff], 24.4.3.3.14 [move.iter.nonmember] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
<b>Submitter:</b> Bo Persson <b>Date:</b> 2007-06-10</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>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 C++03 the difference between two <tt>reverse_iterators</tt>
@@ -12615,21 +10875,87 @@ The same problem now also appears in <tt>operator-()</tt> for <tt>move_iterator<
<p><b>Proposed resolution:</b></p>
<p>
+Change the synopsis in 24.4.1.1 [reverse.iterator]:
+</p>
+
+<blockquote>
+<pre>template &lt;class Iterator1, class Iterator2&gt;
+ <del>typename reverse_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-(
+ const reverse_iterator&lt;Iterator1&gt;&amp; x,
+ const reverse_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(operator-(Iterator1, Iterator2))</ins>;
+</pre>
+<blockquote>
+<p>
+<i>Returns:</i> <tt>y.current - x.current</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+Change 24.4.1.3.19 [reverse.iter.opdiff]:
+</p>
+
+<blockquote>
+<pre>template &lt;class Iterator1, class Iterator2&gt;
+ <del>typename reverse_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-(
+ const reverse_iterator&lt;Iterator1&gt;&amp; x,
+ const reverse_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(operator-(Iterator1, Iterator2))</ins>;
+</pre>
+<blockquote>
+<p>
+<i>Returns:</i> <tt>y.current - x.current</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+
+<p>
+Change the synopsis in 24.4.3.1 [move.iterator]:
+</p>
+
+<blockquote>
+<pre>template &lt;class Iterator1, class Iterator2&gt;
+ <del>typename move_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-(
+ const move_iterator&lt;Iterator1&gt;&amp; x,
+ const move_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(operator-(Iterator1, Iterator2))</ins>;
+</pre>
+<blockquote>
+<p>
+<i>Returns:</i> <tt>y.current - x.current</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+Change 24.4.3.3.14 [move.iter.nonmember]:
</p>
+<blockquote>
+<pre>template &lt;class Iterator1, class Iterator2&gt;
+ <del>typename move_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-(
+ const move_iterator&lt;Iterator1&gt;&amp; x,
+ const move_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(operator-(Iterator1, Iterator2))</ins>;
+</pre>
+<blockquote>
+<p>
+<i>Returns:</i> <tt>x.base() - y.base()</tt>.
+</p>
+</blockquote>
+</blockquote>
+
<hr>
<h3><a name="686"></a>686. Unique_ptr and shared_ptr fail to specify non-convertibility to int for unspecified-bool-type</h3>
-<p><b>Section:</b> 20.6.5.2.4 [unique.ptr.single.observers], 20.6.6.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 20.6.5.2.4 [unique.ptr.single.observers], 20.6.6.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
<b>Submitter:</b> Beman Dawes <b>Date:</b> 2007-06-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>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 library uses the <tt>operator <i>unspecified-bool-type</i>() const</tt> idiom in
-five places. In three of those places (20.5.14.2.3 [func.wrap.func.cap], function capacity
+five places. In three of those places (20.5.15.2.3 [func.wrap.func.cap], function capacity
for example) the returned value is constrained to disallow
unintended conversions to int. The standardese is
</p>
@@ -12653,14 +10979,19 @@ The return type shall not be convertible to <tt>int</tt>.
</p></blockquote>
+<p><i>[
+Kona (2007): Uncertain if <tt>nullptr</tt> will address this issue.
+]</i></p>
+
+
<hr>
<h3><a name="687"></a>687. shared_ptr conversion constructor not constrained</h3>
-<p><b>Section:</b> 20.6.6.2.1 [util.smartptr.shared.const], 20.6.6.3.1 [util.smartptr.weak.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 20.6.6.2.1 [util.smartptr.shared.const], 20.6.6.3.1 [util.smartptr.weak.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
<b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</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>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>
Since all conversions from <tt>shared_ptr&lt;T&gt;</tt> to <tt>shared_ptr&lt;U&gt;</tt> have the same
@@ -12692,7 +11023,7 @@ In 20.6.6.2.1 [util.smartptr.shared.const], change:
<blockquote><p>
-14- <i>Requires:</i> <del>For the second constructor</del> <ins>The
second constructor shall not participate in the overload resolution
-unless</ins> <tt>Y*</tt> <del>shall be</del> <ins>is</ins> convertible
+unless</ins> <tt>Y*</tt> <del>shall be</del> <ins>is implicitly</ins> convertible
to <tt>T*</tt>.
</p></blockquote>
@@ -12712,7 +11043,7 @@ In 20.6.6.3.1 [util.smartptr.weak.const], change:
-4- <i>Requires:</i> <del>For</del> <del>t</del><ins>T</ins>he second and
third constructors<del>,</del> <ins>shall not participate in the
overload resolution unless</ins> <tt>Y*</tt> <del>shall be</del>
-<ins>is</ins> convertible to <tt>T*</tt>.
+<ins>is implicitly</ins> convertible to <tt>T*</tt>.
</p></blockquote>
</blockquote>
@@ -12723,11 +11054,11 @@ overload resolution unless</ins> <tt>Y*</tt> <del>shall be</del>
<hr>
<h3><a name="688"></a>688. reference_wrapper, cref unsafe, allow binding to rvalues</h3>
-<p><b>Section:</b> 20.5.5.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 20.5.5.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
<b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#refwrap.const">active issues</a> in [refwrap.const].</p>
<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#New">New</a> status.</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 <tt>reference_wrapper</tt> can be constructed from an rvalue, either by using
@@ -12737,6 +11068,11 @@ 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>
@@ -12796,16 +11132,22 @@ In 20.5.5.5 [refwrap.helpers], change:
+<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>
+
+
<hr>
<h3><a name="689"></a>689. reference_wrapper constructor overly constrained</h3>
-<p><b>Section:</b> 20.5.5.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 20.5.5.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
<b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#refwrap.const">active issues</a> in [refwrap.const].</p>
<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#New">New</a> status.</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 constructor of <tt>reference_wrapper</tt> is currently <tt>explicit</tt>. The primary
@@ -12814,6 +11156,9 @@ which is addressed by the proposed resolution of the previous issue.
Therefore we should consider relaxing the requirements on the
constructor since requests for the implicit conversion keep resurfacing.
</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>
@@ -12828,48 +11173,12 @@ proposed resolution of the previous issue is accepted, remove the
<hr>
-<h3><a name="690"></a>690. abs(long long) should return long long</h3>
-<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Niels Dekker <b>Date:</b> 2007-06-10</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
-<p><b>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>
-Quoting the latest draft (n2135), 26.7 [c.math]:
-</p>
-
-<blockquote>
-<p>
-The added signatures are:
-</p>
-<blockquote><pre>long abs(long); // labs()
-long abs(long long); // llabs()
-</pre></blockquote>
-</blockquote>
-<p>
-Shouldn't <tt>abs(long long)</tt> have <tt>long long</tt> as return type?
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 26.7 [c.math]:
-</p>
-<blockquote><pre><ins>long </ins>long abs(long long); // llabs()
-</pre></blockquote>
-
-
-
-
-
-<hr>
<h3><a name="691"></a>691. const_local_iterator cbegin, cend missing from TR1</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#New">New</a>
+<p><b>Section:</b> 23.4 [unord], TR1 6.3 [tr.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
<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#New">New</a> status.</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 last version of TR1 does not include the following member
@@ -12891,10 +11200,61 @@ 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.3 [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>
+
+
@@ -12964,11 +11324,11 @@ called</del>. The function <code>f</code> can be defined as...
<hr>
<h3><a name="693"></a>693. <code>std::bitset::all()</code> missing</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>
+<p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
<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#template.bitset">active issues</a> in [template.bitset].</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>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 <code>bitset</code> class template provides the member function
@@ -13009,7 +11369,7 @@ Add a description of the new member function to the end of 23.3.5.2 [bitset.memb
<code>bool all() const;</code>
</p>
<blockquote>
-<i>Returns</i>: <code>count() == b.size()</code>.
+<i>Returns</i>: <code>count() == size()</code>.
</blockquote>
</blockquote>
@@ -13044,11 +11404,11 @@ is one</del><ins><code>count() == 0</code></ins>.
<hr>
<h3><a name="694"></a>694. <code>std::bitset</code> and <code>long long</code></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>
+<p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
<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#template.bitset">active issues</a> in [template.bitset].</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>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>
Objects of the <code>bitset</code> class template specializations can
@@ -13145,9 +11505,9 @@ cannot be represented as type <code>unsigned long long</code>.
<hr>
<h3><a name="695"></a>695. ctype&lt;char&gt;::classic_table() not accessible</h3>
-<p><b>Section:</b> 22.2.1.3 [facet.ctype.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+<p><b>Section:</b> 22.2.1.3 [facet.ctype.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
<b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-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>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 <code>ctype&lt;char&gt;::classic_table()</code> static member
@@ -13253,4 +11613,3084 @@ prevent the facet from storing the value.
+<hr>
+<h3><a name="697"></a>697. New <tt>&lt;system_error&gt;</tt> header leads to name clashes</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#New">New</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#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The most recent state of
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html">N2241</a>
+as well as the current draft
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a>
+(section 19.4 [syserr], p.2) proposes a
+new
+enumeration type <tt>posix_errno</tt> immediatly in the namespace <tt>std</tt>. One of
+the enumerators has the name <tt>invalid_argument</tt>, or fully qualified:
+<tt>std::invalid_argument</tt>. This name clashes with the exception type
+<tt>std::invalid_argument</tt>, see 19.1 [std.exceptions]/p.3. This clash makes
+e.g. the following snippet invalid:
+</p>
+
+<blockquote><pre>#include &lt;system_error&gt;
+#include &lt;stdexcept&gt;
+
+void foo() { throw std::invalid_argument("Don't call us - we call you!"); }
+</pre></blockquote>
+
+<p>
+I propose that this enumeration type (and probably the remaining parts
+of
+<tt>&lt;system_error&gt;</tt> as well) should be moved into one additional inner
+namespace, e.g. <tt>sys</tt> or <tt>system</tt> to reduce foreseeable future clashes
+due
+to the great number of members that <tt>std::posix_errno</tt> already contains
+(Btw.: Why has the already proposed <tt>std::sys</tt> sub-namespace from
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2066.html">N2066</a>
+been rejected?). A further clash <em>candidate</em> seems to be
+<tt>std::protocol_error</tt>
+(a reasonable name for an exception related to a std network library,
+I guess).
+</p>
+
+<p>
+Another possible resolution would rely on the proposed strongly typed
+enums,
+as described in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2213.pdf">N2213</a>.
+But maybe the forbidden implicit conversion to integral types would
+make
+these enumerators less attractive in this special case?
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+
+<hr>
+<h3><a name="698"></a>698. Some system_error issues</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#New">New</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#New">New</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>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="700"></a>700. N1856 defines struct <tt>identity</tt></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> P.J. Plauger <b>Date:</b> 2007-07-01</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/papers/2005/n1856.html">N1856</a>
+defines struct <tt>identity</tt> in <tt>&lt;utility&gt;</tt> which clashes with
+the traditional definition of struct <tt>identity</tt> in <tt>&lt;functional&gt;</tt>
+(not standard, but a common extension from old STL). Be nice
+if we could avoid this name clash for backward compatibility.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.2.2 [forward]:
+</p>
+
+<blockquote>
+<pre>template &lt;class T&gt; struct identity
+{
+ typedef T type;
+ <ins>const T&amp; operator()(const T&amp; x) const;</ins>
+};
+</pre>
+<blockquote>
+<pre><ins>const T&amp; operator()(const T&amp; x) const;</ins>
+</pre>
+<blockquote>
+<p>
+<ins><i>Returns:</i> <tt>x</tt>.</ins>
+</p>
+</blockquote>
+</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>. &nbsp;In the case of non-integer values of <tt>m</tt>, the
+definition &nbsp;<tt><i>L</i><sub>n</sub><sup>(m)</sup> = (1/n!)e<sup>x</sup>x<sup>-m</sup> (d/dx)<sup>n</sup> (e<sup>-x</sup>x<sup>m+n</sup>)</tt>
+must be used, which also holds for integer values of <tt>m</tt>. &nbsp;See
+Abramowitz &amp; Stegun, 22.11.6 for the general case, and 22.5.16-17 for
+the integer case.&nbsp;&nbsp;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.&nbsp;&nbsp;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&nbsp;&nbsp;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="703"></a>703. <tt>map::at()</tt> need a complexity specification</h3>
+<p><b>Section:</b> 23.3.1.2 [map.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-07-03</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map.access">issues</a> in [map.access].</p>
+<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>map::at()</tt> need a complexity specification.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the following to the specification of <tt>map::at()</tt>, 23.3.1.2 [map.access]:
+</p>
+<blockquote>
+<p>
+<i>Complexity:</i> logarithmic.
+</p>
+</blockquote>
+
+
+
+
+
+<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> requires <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 with non-<tt>Swappable</tt> allocators require <tt>value_type</tt> to be <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.
+ Associative containers with non-<tt>Swappable</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> requires <tt>value_type</tt> to be <tt>Swappable</tt>.
+ Sequences with non-<tt>Swappable</tt> allocators require <tt>value_type</tt> to be <tt>Swappable</tt>, <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.
+ Associative containers with non-<tt>Swappable</tt> allocators require <tt>value_type</tt> to be <tt>MoveConstructible</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 sequences <tt>vector</tt> and <tt>deque</tt> also require 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><b>Proposed resolution:</b></p>
+
+
+
+
+
+
+<hr>
+<h3><a name="705"></a>705. type-trait <tt>decay</tt> incompletely specified</h3>
+<p><b>Section:</b> 20.4.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
+ <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2007-07-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>
+The current working draft has a type-trait <tt>decay</tt> in 20.4.7 [meta.trans.other].
+</p>
+
+<p>
+Its use is to turn C++03 pass-by-value parameters into efficient C++0x
+pass-by-rvalue-reference parameters. However, the current definition
+introduces an incompatible change where the cv-qualification of the
+parameter type is retained. The deduced type should loose such
+cv-qualification, as pass-by-value does.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 20.4.7 [meta.trans.other] change the last sentence:
+</p>
+
+<blockquote><p>
+Otherwise the member typedef <tt>type</tt> equals <tt><ins>remove_cv&lt;</ins>U<ins>&gt;::type</ins></tt>.
+</p></blockquote>
+
+<p>
+In 20.3.1.2 [tuple.creation]/1 change:
+</p>
+
+<blockquote><p>
+<del>where each <tt>Vi</tt> in <tt>VTypes</tt> is <tt>X&amp;</tt> if, for the
+corresponding type <tt>Ti</tt> in <tt>Types</tt>,
+<tt>remove_cv&lt;remove_reference&lt;Ti&gt;::type&gt;::type</tt> equals
+<tt>reference_wrapper&lt;X&gt;</tt>, otherwise <tt>Vi</tt> is
+<tt>decay&lt;Ti&gt;::type</tt>.</del>
+<ins>Let <tt>Ui</tt> be <tt>decay&lt;Ti&gt;::type</tt> for each
+<tt>Ti</tt> in <tt>Types</tt>. Then each <tt>Vi</tt> in <tt>VTypes</tt>
+is <tt>X&amp;</tt> if <tt>Ui</tt> equals
+<tt>reference_wrapper&lt;X&gt;</tt>, otherwise <tt>Vi</tt> is
+<tt>Ui</tt>.</ins>
+</p></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="706"></a>706. <tt>make_pair()</tt> should behave as <tt>make_tuple()</tt> wrt. <tt>reference_wrapper()</tt></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#Ready">Ready</a>
+ <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2007-07-08</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#Ready">Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The current draft has <tt>make_pair()</tt> in 20.2.3 [pairs]/16
+and <tt>make_tuple()</tt> in 20.3.1.2 [tuple.creation].
+<tt>make_tuple()</tt> detects the presence of
+<tt>reference_wrapper&lt;X&gt;</tt> arguments and "unwraps" the reference in
+such cases. <tt>make_pair()</tt> would OTOH create a
+<tt>reference_wrapper&lt;X&gt;</tt> member. I suggest that the two
+functions are made to behave similar in this respect to minimize
+confusion.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 20.2 [utility] change the synopsis for make_pair() to read
+</p>
+
+<blockquote><pre>template &lt;class T1, class T2&gt;
+ pair&lt;<del>typename decay&lt;T1&gt;::type</del> <ins>V1</ins>, <del>typename decay&lt;T2&gt;::type</del> <ins>V2</ins>&gt; make_pair(T1&amp;&amp;, T2&amp;&amp;);
+</pre></blockquote>
+
+<p>
+In 20.2.3 [pairs]/16 change the declaration to match the above synopsis.
+Then change the 20.2.3 [pairs]/17 to:
+</p>
+
+<blockquote>
+<p>
+<i>Returns:</i> <tt>pair&lt;<del>typename decay&lt;T1&gt;::type</del> <ins>V1</ins>,<del>typename decay&lt;T2&gt;::type</del> <ins>V2</ins>&gt;(forward&lt;T1&gt;(x),forward&lt;T2&gt;(y))</tt> <ins>where <tt>V1</tt> and
+<tt>V2</tt> are determined as follows: Let <tt>Ui</tt> be
+<tt>decay&lt;Ti&gt;::type</tt> for each <tt>Ti</tt>. Then each
+<tt>Vi</tt> is <tt>X&amp;</tt> if <tt>Ui</tt> equals
+<tt>reference_wrapper&lt;X&gt;</tt>, otherwise <tt>Vi</tt> is
+<tt>Ui</tt>.</ins>
+</p>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="707"></a>707. null pointer constant for <tt>exception_ptr</tt></h3>
+<p><b>Section:</b> 18.7.1 [exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Jens Maurer <b>Date:</b> 2007-07-20</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 the Toronto Core wiki:
+</p>
+
+<p>
+What do you mean by "null pointer constant"? How do you guarantee that
+<tt>exception_ptr() == 1</tt> doesn't work? &nbsp;Do you even want to prevent that?
+What's the semantics? &nbsp;What about <tt>void *p = 0; exception_ptr() == p</tt>?
+Maybe disallow those in the interface, but how do you do that with
+portable C++? Could specify just "make it work".
+</p>
+
+<p>
+Peter's response:
+</p>
+
+<p>
+null pointer constant as defined in 4.10 [conv.ptr]. Intent is "just make it
+work", can be implemented as assignment operator taking a unique pointer
+to member, as in the unspecified bool type idiom.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</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#New">New</a>
+ <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-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 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>
+
+
+
+
+
+
+<hr>
+<h3><a name="710"></a>710. Missing postconditions</h3>
+<p><b>Section:</b> 20.6.6.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-08-24</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#New">New</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 <tt>shared_ptr</tt> move constructor and the cast functions are
+missing postconditions for the <tt>get()</tt> accessor.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add to 20.6.6.2.1 [util.smartptr.shared.const]:
+</p>
+
+<blockquote>
+<pre>shared_ptr(shared_ptr&amp;&amp; r);
+template&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt;&amp;&amp; r);
+</pre>
+<blockquote>
+<p>
+<i>Postconditions:</i> <tt>*this</tt> shall contain the old value of <tt>r</tt>. <tt>r</tt>
+shall be empty. <ins><tt>r.get() == 0</tt>.</ins>
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+Add to 20.6.6.2.10 [util.smartptr.shared.cast]:
+</p>
+
+<blockquote>
+<pre>template&lt;class T, class U&gt; shared_ptr&lt;T&gt; static_pointer_cast(shared_ptr&lt;U&gt; const&amp; r);
+</pre>
+<blockquote>
+<p>
+<ins><i>Postconditions:</i> If <tt>w</tt> is the return value,
+<tt>w.get() == static_cast&lt;T*&gt;(r.get()) &amp;&amp; w.use_count() == r.use_count()</tt>.</ins>
+</p>
+</blockquote>
+</blockquote>
+
+<blockquote>
+<pre>template&lt;class T, class U&gt; shared_ptr&lt;T&gt; dynamic_pointer_cast(shared_ptr&lt;U&gt; const&amp; r);
+</pre>
+<blockquote>
+<p>
+<ins><i>Postconditions:</i> If <tt>w</tt> is the return value, <tt>w.get() == dynamic_cast&lt;T*&gt;(r.get())</tt>.</ins>
+</p>
+</blockquote>
+</blockquote>
+
+<blockquote>
+<pre>template&lt;class T, class U&gt; shared_ptr&lt;T&gt; const_pointer_cast(shared_ptr&lt;U&gt; const&amp; r);
+</pre>
+<blockquote>
+<p>
+<ins><i>Postconditions:</i> If <tt>w</tt> is the return value,
+<tt>w.get() == const_cast&lt;T*&gt;(r.get()) &amp;&amp; w.use_count() == r.use_count()</tt>.</ins>
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+Alberto Ganesh Barbati has written an
+<a href="http://barbati.net/c++/shared_ptr.pdf">alternative proposal</a>
+where he suggests (among other things) that the casts be respecified in terms of
+the aliasing constructor as follows:
+</p>
+
+<p>
+Change 20.6.6.2.10 [util.smartptr.shared.cast]:
+</p>
+
+<blockquote>
+<p>
+-2- <i>Returns:</i> <del>If <tt>r</tt> is empty, an <tt>empty
+shared_ptr&lt;T&gt;;</tt> otherwise, a <tt>shared_ptr&lt;T&gt;</tt>
+object that stores <tt>static_cast&lt;T*&gt;(r.get())</tt> and shares ownership with
+<tt>r</tt>.</del> <ins><tt>shared_ptr&lt;T&gt;(r, static_cast&lt;T*&gt;(r.get())</tt>.</ins>
+</p>
+</blockquote>
+
+<blockquote>
+<p>
+-6- <i>Returns:</i>
+</p>
+<ul>
+<li><del>When <tt>dynamic_cast&lt;T*&gt;(r.get())</tt> returns a nonzero value,
+a <tt>shared_ptr&lt;T&gt;</tt> object that stores a copy
+of it and <i>shares ownership</i> with <tt>r</tt>;</del></li>
+<li><del>Otherwise, an <i>empty</i> <tt>shared_ptr&lt;T&gt;</tt> object.</del></li>
+<li><ins>If <tt>p = dynamic_cast&lt;T*&gt;(r.get())</tt> is a non-null pointer, <tt>shared_ptr&lt;T&gt;(r, p);</tt></ins></li>
+<li><ins>Otherwise, <tt>shared_ptr&lt;T&gt;()</tt>.</ins></li>
+</ul>
+</blockquote>
+
+<blockquote>
+<p>
+-10- <i>Returns:</i> <del>If <tt>r</tt> is empty, an <tt>empty
+shared_ptr&lt;T&gt;;</tt> otherwise, a <tt>shared_ptr&lt;T&gt;</tt>
+object that stores <tt>const_cast&lt;T*&gt;(r.get())</tt> and shares ownership with
+<tt>r</tt>.</del> <ins><tt>shared_ptr&lt;T&gt;(r, const_cast&lt;T*&gt;(r.get())</tt>.</ins>
+</p>
+</blockquote>
+
+<p>
+This takes care of the missing postconditions for the casts by bringing
+in the aliasing constructor postcondition "by reference".
+</p>
+
+
+
+
+
+
+<hr>
+<h3><a name="711"></a>711. Contradiction in empty <tt>shared_ptr</tt></h3>
+<p><b>Section:</b> 20.6.6.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <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#New">New</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.6.6.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><b>Proposed resolution:</b></p>
+<p>
+In keeping the N2351 spirit and obviously my preference, change 20.6.6.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.6.6.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#New">New</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#New">New</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> <del>(where <i>N</i> == <i>last</i> - <i>first</i> )
+</del>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.9 [alg.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</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#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The complexity for <tt>search_n</tt> (25.1.9 [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="715"></a>715. <tt>minmax_element</tt> complexity is too lax</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#New">New</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.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#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The complexity for <tt>minmax_element</tt> (25.3.7 [alg.min.max] par 16) says "At most <tt>max(2 *
+(last - first ) - 2, 0)</tt> applications of the corresponding comparisons",
+i.e. the worst case complexity is no better than calling <tt>min_element</tt> and
+<tt>max_element</tt> separately. This is gratuitously inefficient. There is a
+well known technique that does better: see section 9.1 of CLRS
+(Introduction to Algorithms, by Cormen, Leiserson, Rivest, and Stein).
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 25.3.7 [alg.min.max] to:
+</p>
+
+<blockquote>
+<pre>template&lt;class ForwardIterator&gt;
+ pair&lt;ForwardIterator, ForwardIterator&gt;
+ minmax_element(ForwardIterator first , ForwardIterator last);
+template&lt;class ForwardIterator, class Compare&gt;
+ pair&lt;ForwardIterator, ForwardIterator&gt;
+ minmax_element(ForwardIterator first , ForwardIterator last , Compare comp);
+</pre>
+<blockquote>
+<p>
+<i>Returns:</i> <tt>make_pair(m, M)</tt>, where <tt>m</tt> is
+<del><tt>min_element(first, last)</tt> or <tt>min_element(first, last,
+comp)</tt></del> <ins>the first iterator <tt>i</tt> in <tt>[first,
+last)</tt> such that no other element in the range is smaller,</ins> and
+<ins>where</ins> <tt>M</tt> is <del><tt>max_element(first, last)</tt> or
+<tt>max_element(first, last, comp)</tt></del> <ins>the last iterator
+<tt>i</tt> in <tt>[first, last)</tt> such that no other element in the
+range is larger</ins>.
+</p>
+<p>
+<i>Complexity:</i> At most <del><tt>max(2 * (last - first ) - 2, 0)</tt></del>
+<ins><tt>max(&#8970;(3/2) (N-1)&#8971;, 0)</tt></ins> applications of the
+corresponding <del>comparisons</del> <ins>predicate, where <tt>N</tt> is <tt>distance(first, last)</tt></ins>.
+</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="717"></a>717. Incomplete <tt>valarray::operator[]</tt> specification in [valarray.access]</h3>
+<p><b>Section:</b> 26.5.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-27</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.access">issues</a> in [valarray.access].</p>
+<p><b>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>
+Since the return type of <tt>valarray</tt>'s <tt>operator[] const</tt> overload has been
+changed to <tt>const T&amp;</tt> as described in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> several paragraphs of
+the section 26.5.2.3 [valarray.access] are now
+incompletely
+specified, because many requirements and guarantees should now also
+apply to the const overload. Most notably, the address and reference
+guarantees should be extended to the const overload case.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 26.5.2.3 [valarray.access]:
+</p>
+
+<blockquote>
+<p>
+-1- <del>When applied to a constant array, the subscript operator returns a
+reference to the corresponding element of the array. When applied to a
+non-constant array, t</del><ins>T</ins>he subscript operator returns a
+reference to the corresponding element of the array.
+</p>
+
+<p>
+-3- The expression <tt>&amp;a[i+j] == &amp;a[i] + j</tt> evaluates as <tt>true</tt> for all <tt>size_t i</tt>
+and <tt>size_t j</tt> such that <tt>i+j</tt> is less
+than the length of the <del>non-constant</del> array <tt>a</tt>.
+</p>
+
+<p>
+-4- Likewise, the expression <tt>&amp;a[i] != &amp;b[j]</tt> evaluates
+as <tt>true</tt> for any two <del>non-constant</del> arrays <tt>a</tt> and
+<tt>b</tt> and for any <tt>size_t i</tt> and <tt>size_t j</tt> such that
+<tt>i</tt> is less than the length of <tt>a</tt> and <tt>j</tt> is less
+than the length of <tt>b</tt>. This property indicates an absence of
+aliasing and may be used to advantage by optimizing
+compilers.<sup>281)</sup>
+</p>
+
+<p>
+-5- The reference returned by the subscript operator for a<ins>n</ins> <del>non-constant</del> array is guaranteed to be valid until
+the member function <tt>resize(size_t, T)</tt> (26.5.2.7) is called for that array or until the lifetime
+of that array ends, whichever happens first.
+</p>
+
+</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#New">New</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#New">New</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.1 [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><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.4 [meta] <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> 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#New">New</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.4.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><b>Proposed resolution:</b></p>
+<p>
+In 20.4.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.4.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#New">New</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#New">New</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><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="722"></a>722. Missing [c.math] functions <tt>nanf</tt> and <tt>nanl</tt></h3>
+<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-27</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
+<p><b>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 the listing of 26.7 [c.math], table 108: Header <tt>&lt;cmath&gt;</tt> synopsis I miss
+the following C99 functions (from 7.12.11.2):
+</p>
+
+<blockquote><pre>float nanf(const char *tagp);
+long double nanl(const char *tagp);
+</pre></blockquote>
+
+<p>
+(Note: These functions cannot be overloaded and they are also not
+listed anywhere else)
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 26.7 [c.math], table 108, section "Functions", add <tt>nanf</tt> and <tt>nanl</tt>
+just after the existing entry <tt>nan</tt>.
+</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#New">New</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#New">New</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><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#New">New</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#New">New</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><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="725"></a>725. Optional sequence container requirements column label</h3>
+<p><b>Section:</b> 23.1.1 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> David Abrahams <b>Date:</b> 2007-09-16</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
+<p><b>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 90: (Optional sequence container operations) states the
+"assertion note pre/post-condition" of <tt>operator[]</tt> to be
+</p>
+
+<blockquote><pre>*(a.begin() + n)
+</pre></blockquote>
+
+<p>
+Surely that's meant to be "operational semantics?"
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<blockquote>
+<table border="1">
+<caption>Table 90: Optional sequence container operations</caption>
+<tbody><tr>
+<th>expression</th> <th>return type</th> <th><del>assertion/note<br>pre/post-condition</del><br> <ins>operational semantics</ins></th> <th>container</th>
+</tr>
+</tbody></table>
+</blockquote>
+
+
+
+
+
+
+<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#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>
+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);
+&nbsp;
+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>.&nbsp; 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>.&nbsp; 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.&nbsp; 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.&nbsp; 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.&nbsp; 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.&nbsp;
+(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><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>.&nbsp; <tt>regex_replace()</tt> takes <tt>const basic_string&lt;charT&gt;&amp;</tt>.&nbsp; 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>.&nbsp; 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#New">New</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#New">New</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/n2423.pdf">N2423</a>
+for further discussion.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for the proposed resolution.
+</p>
+
+
+
+
+
+
+<hr>
+<h3><a name="729"></a>729. Problem in [rand.req.eng]/3</h3>
+<p><b>Section:</b> 26.4.1.3 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <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.req.eng">issues</a> in [rand.req.eng].</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 3rd table row in 26.4.1.3 [rand.req.eng]/3 requires random number engines to accept any
+arithmetic type as a seed, which is then casted to the engine's <tt>result_type</tt> and subsequently
+used for seeding the state of the engine. The requirement stated as "Creates an engine with
+initial state determined by <tt>static_cast&lt;X::result_type&gt;(s)</tt>" forces random number engines
+to either use a seeding method that completely depends on the <tt>result_type</tt> (see the discussion
+of seeding for the <tt>mersenne_twister_engine</tt> in point T2 above) or at least to throw away "bits
+of randomness" in the seed value if the <tt>result_type</tt> is smaller than the seed type. This seems
+to be inappropriate for many modern random number generators, in particular F2-linear or
+cryptographic ones, which operate on an internal bit array that in principle is independent of the
+type of numbers returned.
+</p>
+
+<p>
+<b>Posible resolution:</b> I propose to change the wording to a version similar to "Creates an
+engine with initial state determined by <tt>static_cast&lt;UintType&gt;(s)</tt>, where <tt>UintType</tt> is an
+implementation specific unsigned integer type."
+</p>
+
+<p>
+Additionally, the definition of s in 26.4.1.3 [rand.req.eng]/1 c) could be restricted to unsigned integer types.
+</p>
+
+<p>
+Similarly, the type of the seed in 26.4.1.4 [rand.req.adapt]/3 e) could be left unspecified.
+</p>
+
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for further discussion.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for further discussion.
+</p>
+
+
+
+
+
+
+<hr>
+<h3><a name="730"></a>730. Comment on [rand.req.adapt]/3 e)</h3>
+<p><b>Section:</b> 26.4.1.4 [rand.req.adapt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <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#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+If an engine adaptor is invoked with an argument of type <tt>seed_seq</tt>, then all base
+engines are specified to be seeded with this <tt>seed_seq</tt>. As <tt>seed_seq</tt>'s randomization method is
+qualified as constant, this procedure will ef fectively initialize all base engines with the same seed
+(though the resulting state might still dif fer to a certain degree if the engines are of different types).
+It is not clear whether this mode of operation is in general appropriate, hence -- as far as the
+stated requirements are of general nature and not just specific to the engine adaptors provided by
+the library -- it might be better to leave the behaviour unspecified, since the current definition of
+<tt>seed_seq</tt> does not allow for a generally satisfying specification.
+</p>
+
+<p>
+<b>Posssible resolution:</b> [As above]
+</p>
+
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for further discussion.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for the proposed resolution.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="731"></a>731. proposal for a customizable <tt>seed_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#New">New</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.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#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The proper way to seed random number engines seems to be the most frequently
+discussed issue of the 26.4 [rand] proposal. While the new <tt>seed_seq</tt> approach is already rather
+general and probably sufficient for most situations, it is unlikely to be optimal in every case (one
+problem was pointed out in point T5 above). In some situations it might, for instance, be better to
+seed the state with a cryptographic generator.
+</p>
+<p>
+In my opinion this is a pretty strong argument for extending the standard with a simple facility to
+customize the seeding procedure. This could, for example, be done with the following minimal
+changes:
+</p>
+
+<p>
+<b>Possible resolution:</b>
+</p>
+
+<ol type="a">
+<li>
+Turn the interface specification of 26.4.7.1 [rand.util.seedseq]/2 into a "SeedSeq" requirement, where the
+exact behaviour of the constructors and the randomize method are left unspecified and where the
+const qualification for randomize is removed. Classes implementing this interface are additionally
+required to specialize the traits class in c).
+</li>
+<li>
+Provide the class <tt>seed_seq</tt> as a default implementation of the SeedSeq interface.
+</li>
+<li>
+<p>
+Supplement the <tt>seed_seq</tt> with a traits class
+</p>
+<blockquote><pre>template &lt;typename T&gt;
+struct is_seed_seq { static const bool value = false; }
+</pre></blockquote>
+<p>and the specialization</p>
+<blockquote><pre>template &lt;&gt;
+struct is_seed_seq&lt;seed_seq&gt; { static const bool value = true; }
+</pre></blockquote>
+<p>which users can supplement with further specializations.</p>
+</li>
+<li>
+Change 26.4.1.3 [rand.req.eng]/1 d) to "q is an lvalue of a type that fulfils the SeedSeq requirements", and
+modify the constructors and seed methods in 26.4.3 [rand.eng] appropriately (the actual implementation
+could be done using the SFINAE technique).
+</li>
+</ol>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for the proposed resolution.
+</p>
+
+
+
+
+
+<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#New">New</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#New">New</a> status.</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><b>Proposed resolution:</b></p>
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for the proposed resolution.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="733"></a>733. Comment on [rand.req.dist]/9</h3>
+<p><b>Section:</b> 26.4.1.5 [rand.req.dist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <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#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The requirement "P shall have a declaration of the form <tt>typedef X distribution_-
+type</tt>" effectively makes the use of inheritance for implementing distributions very inconvenient,
+because the child of a distribution class in general will not satisfy this requirement. In my opinion
+the benefits of having a typedef in the parameter class pointing back to the distribution class are
+not worth the hassle this requirement causes. [In my code base I never made use of the nested
+typedef but on several occasions could have profited from being able to use simple inheritance for
+the implementation of a distribution class.]
+</p>
+
+<p>
+<b>Proposed resolution:</b> I propose to drop this requirement.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</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#New">New</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#New">New</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><b>Proposed resolution:</b></p>
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for the proposed resolution.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="735"></a>735. Unfortunate naming</h3>
+<p><b>Section:</b> 26.4.8.2.2 [rand.dist.bern.bin], 26.4.8.2.4 [rand.dist.bern.negbin] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <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#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In my opinion the choice of name for the <tt>t</tt> parameter of the <tt>binomial_distribution</tt>
+is very unfortunate. In virtually every internet reference, book and software implementation
+this parameter is called <tt>n</tt> instead, see for example Wikipedia, Mathworld, Evans et al. (1993)
+Statistical Distributions, 2nd E., Wiley, p. 38, the R statistical computing language, p. 926,
+Mathematica and Matlab.
+</p>
+
+<p>
+Similarly, the choice of <tt>k</tt> for the parameter of the negative binomial distributions is rather unusual.
+The most common choice for the negative binomial distribution seems to be <tt>r</tt> instead.
+</p>
+
+<p>
+Choosing unusual names for the parameters causes confusion among users and makes the
+interface unnecessarily inconvenient to use.
+</p>
+
+<p>
+<b>Possible resolution:</b> For these reasons, I propose to change the name of the respective parameters
+to <tt>n</tt> and <tt>r</tt>.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for the proposed resolution.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="736"></a>736. Comment on [rand.dist.samp.discrete]</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> 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#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<ol type="a">
+<li>
+The specification for <tt>discrete_distribution</tt> requires the member <tt>probabilities()</tt>
+to return a vector of <i>standardized</i> probabilities, which forces the implementation every time to
+divide each probability by the sum of all probabilities, as the sum will in practice almost never be
+exactly 1.0. This is unnecessarily inef ficient as the implementation would otherwise not need to
+compute the standardized probabilities at all and could instead work with the non-standardized
+probabilities and the sum. If there was no standardization the user would just get back the
+probabilities that were previously supplied to the distribution object, which to me seems to be the
+more obvious solution.
+</li>
+<li>
+The behaviour of <tt>discrete_distribution</tt> is not specified in case the number of given
+probabilities is larger than the maximum number representable by the IntType.
+</li>
+</ol>
+
+<p>
+<b>Possible resolution:</b> I propose to change the specification such that the non-standardized
+probabilities need to be returned and that an additional requirement is included for the number
+of probabilities to be smaller than the maximum of IntType.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for the proposed resolution.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="737"></a>737. Comment on [rand.dist.samp.pconst]</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> 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#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<ol type="a">
+<li>
+The discussion in point T11 above regarding <tt>probabilities()</tt> similarly applies
+to the method <tt>densities()</tt> of <tt>piecewise_constant_distribution</tt>.
+</li>
+<li>
+<p>
+The design of the constructor
+</p>
+<blockquote><pre>template &lt;class InputIteratorB, class InputIteratorW&gt;
+piecewise_constant_distribution( InputIteratorB firstB, InputIteratorB lastB,
+ InputIteratorW firstW);
+</pre></blockquote>
+<p>
+is unnecessarily unsafe, as there is no separate end-iterator given for the weights. I can't see
+any performance or convenience reasons that would justify the risks inherent in such a function
+interface, in particular the risk that input error might go unnoticed.
+</p>
+</li>
+</ol>
+
+<p>
+<b>Possible resolution:</b> I propose to add an <tt>InputIteratorW lastW</tt> argument to the interface.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for the proposed resolution.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="738"></a>738. Editorial issue in [rand.adapt.disc]/3</h3>
+<p><b>Section:</b> 26.4.4.1 [rand.adapt.disc] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <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#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Since the template parameter <tt>p</tt> and <tt>r</tt> are of type <tt>size_t</tt>, the member <tt>n</tt> in the class
+exposition should have type <tt>size_t</tt>, too.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for the proposed resolution.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="739"></a>739. Defect in [rand.util.canonical]/3</h3>
+<p><b>Section:</b> 26.4.7.2 [rand.util.canonical] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <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.util.canonical">issues</a> in [rand.util.canonical].</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 complexity of <tt>generate_canonical</tt> is specified to be "exactly k=max(1, ceil(b/log2
+R)) invocations of g". This terms involves a logarithm that is not rounded and hence can not (in
+general) be computed at compile time. As this function template is performance critical, I propose
+to replace ceil(b/log2 R) with ceil(b/floor(log2 R)).
+</p>
+
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for further discussion.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for the proposed resolution.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="740"></a>740. Please remove <tt>*_ptr&lt;T[N]&gt;</tt></h3>
+<p><b>Section:</b> 20.6.5.4 [unique.ptr.compiletime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Herb Sutter <b>Date:</b> 2007-10-04</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>
+Please don't provide <tt>*_ptr&lt;T[N]&gt;</tt>. It doesn't enable any useful
+bounds-checking (e.g., you could imagine that doing <tt>op++</tt> on a
+<tt>shared_ptr&lt;T[N]&gt;</tt> yields a <tt>shared_ptr&lt;T[N-1]&gt;</tt>, but that promising path
+immediately falters on <tt>op--</tt> which can't reliably dereference because we
+don't know the lower bound). Also, most buffers you'd want to point to
+don't have a compile-time known size.
+</p>
+
+<p>
+To enable any bounds-checking would require run-time information, with
+the usual triplet: base (lower bound), current offset, and max offset
+(upper bound). And I can sympathize with the point of view that you
+wouldn't want to require this on <tt>*_ptr</tt> itself. But please let's not
+follow the <tt>&lt;T[N]&gt;</tt> path, especially not with additional functions to
+query the bounds etc., because this sets wrong user expectations by
+embarking on a path that doesn't go all the way to bounds checking as it
+seems to imply.
+</p>
+
+<p>
+If bounds checking is desired, consider a <tt>checked_*_ptr</tt> instead (e.g.,
+<tt>checked_shared_ptr</tt>). And make the interfaces otherwise identical so that
+user code could easily <tt>#define/typedef</tt> between prepending <tt>checked_</tt> on
+debug builds and not doing so on release builds (for example).
+</p>
+
+<p>
+Note that some may object that <tt>checked_*_ptr</tt> may seem to make the smart
+pointer more like <tt>vector</tt>, and we don't want two ways to spell <tt>vector</tt>. I
+don't agree, but if that were true that would be another reason to
+remove <tt>*_ptr&lt;T[N]&gt;</tt> which equally makes the smart pointer more like
+<tt>std::array.</tt> :-)
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis under 20.6.5 [unique.ptr] p2:
+</p>
+
+<blockquote><pre>...
+template&lt;class T&gt; struct default_delete;
+template&lt;class T&gt; struct default_delete&lt;T[]&gt;;
+<del>template&lt;class T, size_t N&gt; struct default_delete&lt;T[N]&gt;;</del>
+
+template&lt;class T, class D = default_delete&lt;T&gt;&gt; class unique_ptr;
+template&lt;class T, class D&gt; class unique_ptr&lt;T[], D&gt;;
+<del>template&lt;class T, class D, size_t N&gt; class unique_ptr&lt;T[N], D&gt;;</del>
+...
+</pre></blockquote>
+
+<p>
+Remove the entire section 20.6.5.1.3 [unique.ptr.dltr.dflt2] <b><tt>default_delete&lt;T[N]&gt;</tt></b>.
+</p>
+
+<p>
+Remove the entire section 20.6.5.4 [unique.ptr.compiletime] <b><tt>unique_ptr</tt> for array objects with a compile time length</b>
+and its subsections: 20.6.5.4.1 [unique.ptr.compiletime.dtor], 20.6.5.4.2 [unique.ptr.compiletime.observers],
+20.6.5.4.3 [unique.ptr.compiletime.modifiers].
+</p>
+
+
+
+
+
+
+<hr>
+<h3><a name="741"></a>741. Const-incorrect <tt>get_deleter</tt> function for <tt>shared_ptr</tt></h3>
+<p><b>Section:</b> 20.6.6.2.11 [util.smartptr.getdeleter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-09-27</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.getdeleter">issues</a> in [util.smartptr.getdeleter].</p>
+<p><b>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 following issue was raised by Alf P. Steinbach in c.l.c++.mod:
+</p>
+
+<p>
+According to the recent draft N2369, both the header memory synopsis
+of 20.6 [memory] and 20.6.6.2.11 [util.smartptr.getdeleter] declare:
+</p>
+
+<blockquote><pre>template&lt;class D, class T&gt; D* get_deleter(shared_ptr&lt;T&gt; const&amp; p);
+</pre></blockquote>
+
+<p>
+This allows to retrieve the pointer to a mutable deleter of a <tt>const
+shared_ptr</tt> (if that owns one) and therefore contradicts the usual
+philosophy that associated functors are either read-only (e.g.
+<tt>key_comp</tt> or <tt>value_comp</tt> of <tt>std::map</tt>) or do at least reflect
+the mutability of the owner (as seen for the both overloads of
+<tt>unique_ptr::get_deleter</tt>).
+Even the next similar counter-part of <tt>get_deleter</tt> - the two
+overloads of <tt>function::target</tt> in the class template function
+synopsis 20.5.15.2 [func.wrap.func] or in 20.5.15.2.5 [func.wrap.func.targ] - do
+properly mirror the const-state of the owner.
+</p>
+
+<b>Possible proposed resolutions:</b>
+
+<p>
+Replace the declarations of <tt>get_deleter</tt> in the header <tt>&lt;memory&gt;</tt>
+synopsis of 20.6 [memory] and in 20.6.6.2.11 [util.smartptr.getdeleter] by one of the
+following alternatives (A) or (B):
+</p>
+
+<ol type="A">
+<li>
+Provide <b>only</b> the immutable variant. This would reflect the
+current praxis of <tt>container::get_allocator()</tt>, <tt>map::key_comp()</tt>, or
+<tt>map::value_comp</tt>.
+
+<blockquote><pre>template&lt;class D, class T&gt; const D* get_deleter(shared_ptr&lt;T&gt; const&amp; p);
+</pre></blockquote>
+</li>
+<li>
+Just remove the function.
+</li>
+</ol>
+
+<p>
+Alberto Ganesh Barbati adds:
+</p>
+
+<ol start="3" type="A">
+<li>
+<p>
+Replace it with two functions:
+</p>
+<blockquote><pre>template &lt;class D, class T&gt; D get_deleter(shared_ptr&lt;T&gt; const&amp;);
+template &lt;class D, class T&gt; bool has_deleter(shared_ptr&lt;T&gt; const&amp;);
+</pre></blockquote>
+
+<p>
+The first one would throw if <tt>D</tt> is the wrong type, while the latter would
+never throw. This approach would reflect the current praxis of
+<tt>use_facet/has_facet</tt>, with the twist of returning the deleter by value as
+<tt>container::get_allocator()</tt> do.
+</p>
+</li>
+</ol>
+
+<p>
+Peter Dimov adds:
+</p>
+
+<blockquote>
+<p>
+My favorite option is "not a defect". A, B and C break useful code.
+</p>
+</blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<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#New">New</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#New">New</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-active.html#672">672</a>. <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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><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="743"></a>743. rvalue <tt>swap</tt> for <tt>shared_ptr</tt></h3>
+<p><b>Section:</b> 20.6.6.2.9 [util.smartptr.shared.spec] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Howard Hinnant <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#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+When the LWG looked at <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#674">674</a> in Kona the following note was made:
+</p>
+
+<blockquote><p>
+We may need to open an issue to deal with the question of
+whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>.
+</p></blockquote>
+
+<p>
+This issue was opened in response to that note.
+</p>
+
+<p>
+I believe allowing rvalue <tt>shared_ptr</tt>s to <tt>swap</tt> is both
+appropriate, and consistent with how other library components are currently specified.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis in 20.6.6.2 [util.smartptr.shared]:
+</p>
+
+<blockquote><pre>void swap(shared_ptr&amp;<ins>&amp;</ins> r);
+...
+template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp; b);
+<ins>template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp;&amp; a, shared_ptr&lt;T&gt;&amp; b);
+template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp;&amp; b);</ins>
+</pre></blockquote>
+
+<p>
+Change 20.6.6.2.4 [util.smartptr.shared.mod]:
+</p>
+
+<blockquote><pre>void swap(shared_ptr&amp;<ins>&amp;</ins> r);
+</pre></blockquote>
+
+<p>
+Change 20.6.6.2.9 [util.smartptr.shared.spec]:
+</p>
+
+<blockquote><pre>template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp; b);
+<ins>template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp;&amp; a, shared_ptr&lt;T&gt;&amp; b);
+template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp;&amp; b);</ins>
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="744"></a>744. What is the lifetime of an exception pointed to by an exception_ptr?</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> 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#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>
+Without some lifetime guarantee, it is hard to know how this type can be
+used. &nbsp;Very specifically, I don't see how the current wording would
+guarantee and exception_ptr caught at the end of one thread could be safely
+stored and rethrown in another thread - the original motivation for this
+API.
+</p>
+<p>
+(Peter Dimov agreed it should be clearer, maybe a non-normative note to
+explain?)
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="745"></a>745. copy_exception API slices.</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> 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#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>
+It could be I did not understand the design rationale, but I thought
+copy_exception would produce an exception_ptr to the most-derived (dynamic)
+type of the passed exception. &nbsp;Instead it slices, which appears to be less
+useful, and a likely source of FAQ questions in the future.
+</p>
+<p>
+(Peter Dimov suggests NAD)
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="746"></a>746. current_exception may fail with bad_alloc</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> 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#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>
+I understand that the attempt to copy an exception may run out of memory,
+but I believe this is the only part of the standard that mandates failure
+with specifically <tt>bad_alloc</tt>, as opposed to allowing an
+implementation-defined type derived from <tt>bad_alloc</tt>. &nbsp;For instance, the Core
+language for a failed new expression is:
+</p>
+<blockquote>
+<p>
+Any other allocation function that fails to allocate storage shall indicate
+failure only by throwing an exception of a type that would match a handler
+(15.3) of type <tt>std::bad_alloc</tt> (18.5.2.1).
+</p>
+</blockquote>
+<p>
+I think we should allow similar freedom here (or add a blanket
+compatible-exception freedom paragraph in 17)
+</p>
+<p>
+I prefer the clause 17 approach myself, and maybe clean up any outstanding
+wording that could also rely on it.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<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.4.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <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#meta.unary.prop">active issues</a> in [meta.unary.prop].</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#New">New</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. &nbsp;However, I'm not entirely clear on what the current wording
+requires of a conforming implementation. &nbsp;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{
+&nbsp;int x;
+&nbsp;test() : x() {}
+};
+</pre></blockquote>
+<p>
+Should I expect a conforming compiler to
+&nbsp;<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><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="748"></a>748. The is_abstract type trait is defined by reference to 10.4.</h3>
+<p><b>Section:</b> 20.4.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <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#meta.unary.prop">active issues</a> in [meta.unary.prop].</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#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+I am trying to decide is a pure virtual function is a <i>necessary</i> as well as
+sufficient requirement to be classified as abstract?
+</p>
+<p>
+For instance, is the following (non-polymorphic) type considered abstract?
+</p>
+<blockquote><pre>struct abstract {
+protected:
+&nbsp;abstract(){}
+&nbsp;abstract( abstract const &amp; ) {}
+&nbsp;~abstract() {}
+};
+</pre></blockquote>
+<p>
+(Suggested that this may be NAD, with an editorial fix-up from Pete on the
+core wording to make clear that abstract requires a pure virtual function)
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="749"></a>749. Currently <tt>has_nothrow_copy_constructor&lt;T&gt;::value</tt> is true if T has 'a' nothrow copy constructor.</h3>
+<p><b>Section:</b> 20.4.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <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#meta.unary.prop">active issues</a> in [meta.unary.prop].</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#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Unfortunately a class can have multiple copy constructors, and I believe to
+be useful this trait should only return true is ALL copy constructors are
+no-throw.
+</p>
+<p>
+For instance:
+</p>
+<blockquote>
+<pre>struct awkward {
+&nbsp;awkward( const awkward &amp; ) throw() {}
+&nbsp;awkward( awkward &amp; ) { throw "oops"; } };
+</pre>
+</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.4.5 [meta.rel] <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 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 pending arrival of explicit conversion functions though, I'm
+wondering if we want an additional trait, <tt>is_explictly_convertible</tt>?
+</p>
+
+
+<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.6 [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 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><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#New">New</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#New">New</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. &nbsp;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. &nbsp;But it's not really a new problem, and I think
+we'd be confusing things by leaving the bogus requirements there. &nbsp;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. All the operations on the allocators are expected to be
+amortized constant time<ins>, except that <tt>allocate</tt> and
+<tt>construct</tt> may require time proportional to the size of the
+object allocated or constructed</ins>. 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#New">New</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#New">New</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.5.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>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="754"></a>754. Ambiguous return clause for <tt>std::uninitialized_copy</tt></h3>
+<p><b>Section:</b> 20.6.4.1 [uninitialized.copy] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-10-15</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#uninitialized.copy">active issues</a> in [uninitialized.copy].</p>
+<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#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+14882-2003, [lib.uninitialized.copy] is currently written as follows:
+</p>
+
+<blockquote>
+<pre>template &lt;class InputIterator, class ForwardIterator&gt;
+ ForwardIterator uninitialized_copy(InputIterator <i>first</i>, InputIterator <i>last</i>,
+ ForwardIterator <i>result</i>);
+</pre>
+<blockquote>
+<p>
+-1- <i>Effects:</i>
+</p>
+<blockquote><pre>for (; first != last; ++result, ++first)
+ new (static_cast&lt;void*&gt;(&amp;*result))
+ typename iterator_traits&lt;ForwardIterator&gt;::value_type(*first);
+</pre></blockquote>
+<p>
+-2- <i>Returns:</i> <tt><i>result</i></tt>
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+similarily for N2369, and its corresponding section
+20.6.4.1 [uninitialized.copy].
+</p>
+
+<p>
+It's not clear to me what the return clause is supposed to mean, I see
+two
+possible interpretations:
+</p>
+
+<ol type="a">
+<li>
+The notion of <tt><i>result</i></tt> is supposed to mean the value given by the
+function parameter <tt><i>result</i></tt> [Note to the issue editor: Please use italics for
+<tt><i>result</i></tt>].
+This seems somewhat implied by recognizing that both the function
+parameter
+and the name used in the clause do have the same italic font.
+</li>
+<li>
+The notion of "result" is supposed to mean the value of <tt><i>result</i></tt>
+after the
+preceding effects clause. This is in fact what all implementations I
+checked
+do (and which is probably it's intend, because it matches the
+specification of <tt>std::copy</tt>).
+</li>
+</ol>
+
+<p>
+The problem is: I see nothing in the standard which grants that this
+interpretation
+is correct, specifically [lib.structure.specifications] or
+17.3.1.3 [structure.specifications]
+resp. do not clarify which "look-up" rules apply for names found in
+the elements
+of the detailed specifications - Do they relate to the corresponding
+synopsis or
+to the effects clause (or possibly other elements)? Fortunately most
+detailed
+descriptions are unambigious in this regard, e.g. this problem does
+not apply
+for <tt>std::copy</tt>.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the wording of the return clause to say (20.6.4.1 [uninitialized.copy]):
+</p>
+
+<blockquote>
+<p>
+-2- <i>Returns:</i> <ins>The value of</ins> <tt><i>result</i></tt> <ins>after effects have taken place.</ins>
+</p>
+</blockquote>
+
+
+
+
+
+
</body></html> \ No newline at end of file
diff --git a/libstdc++-v3/docs/html/ext/lwg-closed.html b/libstdc++-v3/docs/html/ext/lwg-closed.html
index 4d0c76d..52184fb 100644
--- a/libstdc++-v3/docs/html/ext/lwg-closed.html
+++ b/libstdc++-v3/docs/html/ext/lwg-closed.html
@@ -1,22 +1,22 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html><head><title>C++ Standard Library Closed Issues List</title>
+
+
<style type="text/css">
p {text-align:justify}
li {text-align:justify}
-ins {background-color:#FFFFA0}
-del {background-color:#FFFFA0}
-</style></head>
-
-<body>
+ins {background-color:#A0FFA0}
+del {background-color:#FFA0A0}
+</style></head><body>
<table>
<tbody><tr>
<td align="left">Doc. no.</td>
-<td align="left">N2319=07-0179</td>
+<td align="left">N2458=07-0328</td>
</tr>
<tr>
<td align="left">Date:</td>
-<td align="left">2007-06-24</td>
+<td align="left">2007-10-20</td>
</tr>
<tr>
<td align="left">Project:</td>
@@ -27,7 +27,7 @@ del {background-color:#FFFFA0}
<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 Closed Issues List (Revision R49)</h1>
+<h1>C++ Standard Library Closed Issues List (Revision R52)</h1>
<p>Reference ISO/IEC IS 14882:1998(E)</p>
<p>Also see:</p>
@@ -49,6 +49,71 @@ del {background-color:#FFFFA0}
<h2>Revision History</h2>
<ul>
+<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-active.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#754">754</a>.</li>
+<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-active.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li>
+<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-active.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#706">706</a>.</li>
+<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#680">680</a>.</li>
+<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>.</li>
+<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-active.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>.</li>
+</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-active.html#697">697</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li>
+<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-active.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#680">680</a>.</li>
+<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-defects.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-active.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>
@@ -58,7 +123,7 @@ del {background-color:#FFFFA0}
<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-active.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li>
<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>
@@ -75,7 +140,7 @@ del {background-color:#FFFFA0}
<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-active.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#663">663</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>.</li>
<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-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
<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>
@@ -85,8 +150,8 @@ del {background-color:#FFFFA0}
<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-active.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#604">604</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-defects.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>
@@ -102,7 +167,7 @@ del {background-color:#FFFFA0}
<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-active.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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 New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#626">626</a>.</li>
<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#570">570</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#614">614</a>.</li>
<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>
@@ -136,9 +201,9 @@ del {background-color:#FFFFA0}
<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-active.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li>
+<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li>
<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-active.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#604">604</a> to Review.</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>
@@ -152,7 +217,7 @@ del {background-color:#FFFFA0}
<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-active.html#583">583</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#592">592</a>.</li>
+<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>
@@ -182,8 +247,8 @@ del {background-color:#FFFFA0}
<li><b>Details:</b><ul>
<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#567">567</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
<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-active.html#525">525</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a> to Open.</li>
+<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>
@@ -198,7 +263,7 @@ del {background-color:#FFFFA0}
<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-active.html#566">566</a>.</li>
+<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>
@@ -219,7 +284,7 @@ del {background-color:#FFFFA0}
</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-active.html#528">528</a>.
+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.
@@ -245,7 +310,7 @@ previously in "DR" status were moved to "WP".
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-active.html#488">488</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#494">494</a>.
+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.
@@ -485,6 +550,7 @@ exists.)</p>
<h3><a name="4"></a>4. Basic_string size_type and difference_type should be implementation defined</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#NAD">NAD</a>
<b>Submitter:</b> Beman Dawes <b>Date:</b> 1997-11-16</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#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
@@ -765,10 +831,10 @@ meaningless.</p>
<hr>
<h3><a name="77"></a>77. Valarray operator[] const returning value</h3>
-<p><b>Section:</b> 26.5.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
+<p><b>Section:</b> 26.5.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
<b>Submitter:</b> Levente Farkas <b>Date:</b> 1998-09-09</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.access">issues</a> in [valarray.access].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a></p>
<p><b>Discussion:</b></p>
<p>valarray:<br>
@@ -1983,7 +2049,6 @@ output</p>
<h3><a name="163"></a>163. Return of <tt>gcount()</tt> after a call to <tt>gcount</tt></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#Dup">Dup</a>
<b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.unformatted">active issues</a> in [istream.unformatted].</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#Dup">Dup</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a></p>
@@ -4188,11 +4253,11 @@ operator&lt; on any pair type which contains a pointer.
<hr>
<h3><a name="350"></a>350. allocator&lt;&gt;::address</h3>
-<p><b>Section:</b> 20.6.1.1 [allocator.members], 20.1.2 [allocator.requirements], 17.4.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
+<p><b>Section:</b> 20.6.1.1 [allocator.members], 20.1.2 [allocator.requirements], 17.4.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
<b>Submitter:</b> Nathan Myers <b>Date:</b> 2001-10-25</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#634">634</a></p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
+<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a></p>
<p><b>Discussion:</b></p>
<p>See c++std-lib-9006 and c++std-lib-9007. This issue is taken
verbatim from -9007.</p>
@@ -4275,14 +4340,13 @@ exhibiting a problem.</p>
<h3><a name="351"></a>351. unary_negate and binary_negate: struct or class?</h3>
<p><b>Section:</b> 20.5 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
<b>Submitter:</b> Dale Riley <b>Date:</b> 2001-11-12</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#function.objects">active issues</a> in [function.objects].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 20.5 [function.objects] the header &lt;functional&gt; synopsis declares
the unary_negate and binary_negate function objects as struct.
-However in 20.5.9 [negators] the unary_negate and binary_negate
+However in 20.5.10 [negators] the unary_negate and binary_negate
function objects are defined as class. Given the context, they are
not "basic function objects" like negate, so this is either a typo or
an editorial oversight.
@@ -4293,7 +4357,7 @@ an editorial oversight.
<p><b>Proposed resolution:</b></p>
-<p>Change the synopsis to reflect the useage in 20.5.9 [negators]</p>
+<p>Change the synopsis to reflect the useage in 20.5.10 [negators]</p>
<p><i>[Curaçao: Since the language permits "struct", the LWG
views this as NAD. They suggest, however, that the Project Editor
@@ -5047,7 +5111,6 @@ then precisely describe and enforce the precise requirements.
<h3><a name="388"></a>388. Use of complex as a key in associative containers</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#NAD%20Future">NAD Future</a>
<b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2002-11-08</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#complex.numbers">active issues</a> in [complex.numbers].</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#NAD%20Future">NAD Future</a> status.</p>
<p><b>Discussion:</b></p>
@@ -5099,6 +5162,7 @@ provide their own comparison function object.</p>
<h3><a name="390"></a>390. CopyConstructible requirements too strict</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#NAD%20Future">NAD Future</a>
<b>Submitter:</b> Doug Gregor <b>Date:</b> 2002-10-24</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#NAD%20Future">NAD Future</a> status.</p>
<p><b>Discussion:</b></p>
@@ -5228,10 +5292,72 @@ of input iterators.</p>
<hr>
+<h3><a name="393"></a>393. do_in/do_out operation on state unclear</h3>
+<p><b>Section:</b> 22.2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
+ <b>Submitter:</b> Alberto Barbati <b>Date:</b> 2002-12-24</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.codecvt.virtuals">active issues</a> in [locale.codecvt.virtuals].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.virtuals">issues</a> in [locale.codecvt.virtuals].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+this DR follows the discussion on the previous thread "codecvt::do_in
+not consuming external characters". It's just a clarification issue
+and not a request for a change.
+</p>
+<p>
+Can do_in()/do_out() produce output characters without consuming input
+characters as a result of operation on state?
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add a note at the end of 22.2.1.4.2 [locale.codecvt.virtuals],
+paragraph 3:
+</p>
+
+<p>
+[Note: As a result of operations on state, it can return ok or partial
+and set from_next == from and to_next != to. --end note]
+</p>
+
+
+<p><b>Rationale:</b></p>
+<p>
+The submitter believes that standard already provides an affirmative
+answer to the question. However, the current wording has induced a few
+library implementors to make the incorrect assumption that
+do_in()/do_out() always consume at least one internal character when
+they succeed.
+</p>
+
+<p>
+The submitter also believes that the proposed resolution is not in
+conflict with the related issue 76. Moreover, by explicitly allowing
+operations on state to produce characters, a codecvt implementation
+may effectively implement N-to-M translations without violating the
+"one character at a time" principle described in such issue. On a side
+note, the footnote in the proposed resolution of issue 76 that
+informally rules out N-to-M translations for basic_filebuf should be
+removed if this issue is accepted as valid.
+</p>
+
+
+<p><i>[
+Kona (2007): The proposed resolution is to add a note. Since this is
+non-normative, the issue is editorial, but we believe that the note is
+correct. Proposed Disposition: NAD, Editorial
+]</i></p>
+
+
+
+
+
+
+<hr>
<h3><a name="399"></a>399. volations of unformatted input function requirements</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#NAD">NAD</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#istream.unformatted">active issues</a> in [istream.unformatted].</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#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
@@ -8029,6 +8155,41 @@ Berlin: N1932 considers this NAD. This is a QOI issue.
<hr>
+<h3><a name="525"></a>525. type traits definitions not clear</h3>
+<p><b>Section:</b> 20.4.4 [meta.unary], TR1 4.5 [tr.meta.unary] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Robert Klarer <b>Date:</b> 2005-07-11</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+It is not completely clear how the primary type traits deal with
+cv-qualified types. And several of the secondary type traits
+seem to be lacking a definition.
+</p>
+
+<p><i>[
+Berlin: Howard to provide wording.
+]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Wording provided in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2028.html">N2028</a>.
+A
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html">revision (N2157)</a>
+provides more detail for motivation.
+</p>
+
+
+<p><b>Rationale:</b></p>
+Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html">revision (N2157)</a>
+in the WP.
+
+
+
+
+
+<hr>
<h3><a name="526"></a>526. Is it undefined if a function in the standard changes in parameters?</h3>
<p><b>Section:</b> 23.1.1 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
<b>Submitter:</b> Chris Jefferson <b>Date:</b> 2005-09-14</p>
@@ -8179,6 +8340,83 @@ template insert functions from self referencing.</li>
<hr>
+<h3><a name="528"></a>528. <tt>const_iterator</tt> <tt>iterator</tt> issue when they are the same type</h3>
+<p><b>Section:</b> 23.4 [unord], TR1 6.3.4 [tr.unord.unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2005-10-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#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+while implementing the resolution of issue 6.19 I'm noticing the
+following: according to 6.3.4.3/2 (and 6.3.4.5/2), for unordered_set and
+unordered_multiset:
+</p>
+
+<blockquote><p>
+ "The iterator and const_iterator types are both const types. It is
+unspecified whether they are the same type"
+</p></blockquote>
+
+<p>
+Now, according to the resolution of 6.19, we have overloads of insert
+with hint and erase (single and range) both for iterator and
+const_iterator, which, AFAICS, can be meaningful at the same time *only*
+if iterator and const_iterator *are* in fact different types.
+</p>
+<p>
+Then, iterator and const_iterator are *required* to be different types?
+Or that is an unintended consequence? Maybe the overloads for plain
+iterators should be added only to unordered_map and unordered_multimap?
+Or, of course, I'm missing something?
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add to 6.3.4.3p2 (and 6.3.4.5p2):
+</p>
+<p>
+2 ... The iterator and const_iterator types are both <del>const</del>
+<ins>constant</ins> iterator types.
+It is unspecified whether they are the same type.
+</p>
+
+<p>
+Add a new subsection to 17.4.4 [lib.conforming]:
+</p>
+
+<blockquote>
+<p>
+An implementation shall not supply an overloaded function
+ signature specified in any library clause if such a signature
+ would be inherently ambiguous during overload resolution
+ due to two library types referring to the same type.
+</p>
+<p>
+ [Note: For example, this occurs when a container's iterator
+ and const_iterator types are the same. -- end note]
+</p>
+</blockquote>
+
+<p><i>[
+Post-Berlin: Beman supplied wording.
+]</i></p>
+
+
+
+
+<p><b>Rationale:</b></p>
+Toronto: The first issue has been fixed by N2350 (the insert and erase members
+are collapsed into one signature). Alisdair to open a separate issue on the
+chapter 17 wording.
+
+
+
+
+
+<hr>
<h3><a name="532"></a>532. Tuple comparison</h3>
<p><b>Section:</b> 20.3.1.5 [tuple.rel], TR1 6.1.3.5 [tr.tuple.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
<b>Submitter:</b> David Abrahams <b>Date:</b> 2005-11-29</p>
@@ -8402,6 +8640,48 @@ Recommend NAD as the affected section is now gone and so the issue is moot.
<hr>
+<h3><a name="548"></a>548. May random_device block?</h3>
+<p><b>Section:</b> 26.4.6 [rand.device], TR1 5.1.6 [tr.rand.device] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</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#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Class random_device "produces non-deterministic random numbers", using some
+external source of entropy. In most real-world systems, the amount of available
+entropy is limited. Suppose that entropy has been exhausted. What is an
+implementation permitted to do? In particular, is it permitted to block
+indefinitely until more random bits are available, or is the implementation
+required to detect failure immediately? This is not an academic question. On
+Linux a straightforward implementation would read from /dev/random, and "When
+the entropy pool is empty, reads to /dev/random will block until additional
+environmental noise is gathered." Programmers need to know whether random_device
+is permitted to (or possibly even required to?) behave the same way.
+</p>
+
+<p><i>[
+Berlin: Walter: N1932 considers this NAD. Does the standard specify whether std::cin
+may block?
+]</i></p>
+
+
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for some further discussion.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Adopt the proposed resolution in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> (NAD).
+</p>
+
+
+
+
+
+<hr>
<h3><a name="549"></a>549. Undefined variable in binomial_distribution</h3>
<p><b>Section:</b> 26.4.8 [rand.dist], TR1 5.1.7.5 [tr.rand.dist.bin] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
<b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p>
@@ -8432,9 +8712,9 @@ Portland: Subsumed by N2111.
<hr>
<h3><a name="553"></a>553. very minor editorial change intptr_t / uintptr_t</h3>
-<p><b>Section:</b> 18.3.1 [cstdint.syn], TR1 8.22.1 [tr.c99.cstdint.syn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
+<p><b>Section:</b> 18.3.1 [cstdint.syn], TR1 8.22.1 [tr.c99.cstdint.syn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
<b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-01-30</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In the synopsis, some types are identified as optional: int8_t, int16_t,
@@ -8792,10 +9072,10 @@ committee meant.
<hr>
<h3><a name="571"></a>571. Update C90 references to C99?</h3>
-<p><b>Section:</b> 1.2 [intro.refs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
+<p><b>Section:</b> 1.2 [intro.refs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
<b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-04-08</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#intro.refs">issues</a> in [intro.refs].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p>
1.2 Normative references [intro.refs] of the WP currently refers to ISO/IEC
@@ -8863,6 +9143,76 @@ is adopted.
<hr>
+<h3><a name="583"></a>583. div() for unsigned integral types</h3>
+<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Beman Dawes <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#c.math">active issues</a> in [c.math].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+There is no div() function for unsigned integer types.
+</p>
+<p>
+There are several possible resolutions. The simplest one is noted below. Other
+possibilities include a templated solution.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add to 26.7 [lib.c.math] paragraph 8:
+</p>
+
+<blockquote><pre>struct udiv_t div(unsigned, unsigned);
+struct uldiv_t div(unsigned long, unsigned long);
+struct ulldiv_t div(unsigned long long, unsigned long long);
+</pre></blockquote>
+
+
+
+<p><b>Rationale:</b></p>
+Toronto: C99 does not have these unsigned versions because
+the signed version exist just to define the implementation-defined behavior
+of signed integer division. Unsigned integer division has no implementation-defined
+behavior and thus does not need this treatment.
+
+
+
+
+
+<hr>
+<h3><a name="584"></a>584. missing int pow(int,int) functionality</h3>
+<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Beman Dawes <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#c.math">active issues</a> in [c.math].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+There is no pow() function for any integral type.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add something like:
+</p>
+
+<blockquote><pre>template&lt; typename T&gt;
+T power( T x, int n );
+// requires: n &gt;=0
+</pre></blockquote>
+
+
+<p><b>Rationale:</b></p>
+Toronto: We already have double pow(integral, integral) from 26.7 [c.math] p11.
+
+
+
+
+
+<hr>
<h3><a name="587"></a>587. iststream ctor missing description</h3>
<p><b>Section:</b> D.7.2.1 [depr.istrstream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
<b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-22</p>
@@ -8899,6 +9249,7 @@ post Oxford: Noted that it is already fixed in
<h3><a name="590"></a>590. Type traits implementation latitude should be removed for C++0x</h3>
<p><b>Section:</b> 20.4 [meta], TR1 4.9 [tr.meta.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
<b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-08-10</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#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p>
@@ -8937,10 +9288,10 @@ current working draft.
<hr>
<h3><a name="591"></a>591. Misleading "built-in</h3>
-<p><b>Section:</b> 18.2.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
+<p><b>Section:</b> 18.2.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
<b>Submitter:</b> whyglinux <b>Date:</b> 2006-08-08</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.limits.members">issues</a> in [numeric.limits.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p>
18.2.1.2 numeric_limits members [lib.numeric.limits.members]
@@ -9005,9 +9356,70 @@ Recommend NAD / Editorial. The proposed resolution is accepted as editorial.
<hr>
+<h3><a name="592"></a>592. Incorrect treatment of rdbuf()-&gt;close() return type</h3>
+<p><b>Section:</b> 27.8.1.9 [ifstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
+ <b>Submitter:</b> Christopher Kohlhoff <b>Date:</b> 2006-08-17</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ifstream.members">issues</a> in [ifstream.members].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+I just spotted a minor problem in 27.8.1.7
+[lib.ifstream.members] para 4 and also 27.8.1.13
+[lib.fstream.members] para 4. In both places it says:
+</p>
+<blockquote>
+<pre>void close();
+</pre>
+<p>
+Effects: Calls rdbuf()-&gt;close() and, if that function returns false, ...
+</p>
+</blockquote>
+<p>
+However, basic_filebuf::close() (27.8.1.2) returns a pointer to the
+filebuf on success, null on failure, so I think it is meant to
+say "if that function returns a null pointer". Oddly, it is
+correct for basic_ofstream.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 27.8.1.9 [ifstream.members], p5:
+</p>
+
+<blockquote><p>
+<i>Effects:</i> Calls <tt>rdbuf()-&gt;close()</tt> and, if that function
+<ins>fails (</ins>returns <del><tt>false</tt></del> <ins>a null pointer)</ins>,
+calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>
+(27.4.4.3)).
+</p></blockquote>
+
+<p>
+Change 27.8.1.17 [fstream.members], p5:
+</p>
+
+<blockquote><p>
+<i>Effects:</i> Calls <tt>rdbuf()-&gt;close()</tt> and, if that function
+<ins>fails (</ins>returns <del><tt>false</tt></del> <ins>a null pointer)</ins>,
+calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>
+(27.4.4.3)).
+</p></blockquote>
+
+
+
+<p><i>[
+Kona (2007): Proposed Disposition: NAD, Editorial
+]</i></p>
+
+
+
+
+
+<hr>
<h3><a name="594"></a>594. Disadvantages of defining Swappable in terms of CopyConstructible and Assignable</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#NAD%20Editorial">Pending NAD Editorial</a>
<b>Submitter:</b> Niels Dekker <b>Date:</b> 2006-11-02</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#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
@@ -9148,7 +9560,7 @@ will essentially rewrite this section and provide the desired semantics.
<hr>
<h3><a name="615"></a>615. Inconsistencies in Section 21.4</h3>
-<p><b>Section:</b> 21.4 [c.strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+<p><b>Section:</b> 21.5 [c.strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
<b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-11</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.strings">issues</a> in [c.strings].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
@@ -9187,12 +9599,12 @@ Recommend NAD, editorial. Send to Pete.
<hr>
<h3><a name="633"></a>633. Return clause mentions undefined "type()"</h3>
-<p><b>Section:</b> 20.5.14.2.5 [func.wrap.func.targ] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
+<p><b>Section:</b> 20.5.15.2.5 [func.wrap.func.targ] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
<b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-03</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-20.5.14.2.5 [func.wrap.func.targ], p4 says:
+20.5.15.2.5 [func.wrap.func.targ], p4 says:
</p>
<blockquote><p>
<i>Returns:</i> If <tt>type() == typeid(T)</tt>, a pointer to the stored
@@ -9208,7 +9620,7 @@ function <tt>type()</tt> in class template function nor in the global or
<li>
Assuming that <tt>type</tt> should have been <tt>target_type()</tt>,
this description would lead to false results, if <tt>T = <i>cv</i>
-void</tt> due to returns clause 20.5.14.2.5 [func.wrap.func.targ], p1.
+void</tt> due to returns clause 20.5.15.2.5 [func.wrap.func.targ], p1.
</li>
</ol>
@@ -9216,7 +9628,7 @@ void</tt> due to returns clause 20.5.14.2.5 [func.wrap.func.targ], p1.
<p><b>Proposed resolution:</b></p>
<p>
-Change 20.5.14.2.5 [func.wrap.func.targ], p4:
+Change 20.5.15.2.5 [func.wrap.func.targ], p4:
</p>
<blockquote><p>
@@ -9237,10 +9649,10 @@ Pete: Agreed. It's editorial, so I'll fix it.
<hr>
<h3><a name="636"></a>636. 26.5.2.3 valarray::operator[]</h3>
-<p><b>Section:</b> 26.5.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
+<p><b>Section:</b> 26.5.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
<b>Submitter:</b> Bo Persson <b>Date:</b> 2007-02-11</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.access">issues</a> in [valarray.access].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The signature of the const operator[] has been changed to return a const
@@ -9265,11 +9677,193 @@ Pete recommends editorial fix.
<hr>
+<h3><a name="637"></a>637. [c.math]/10 inconsistent return values</h3>
+<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-02-13</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+26.7 [c.math], paragraph 10 has long lists of added signatures for float and long double
+functions. All the signatures have float/long double return values, which is
+inconsistent with some of the double functions they are supposed to
+overload.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 26.7 [c.math], paragraph 10,
+</p>
+
+<blockquote><pre><del>float</del> <ins>int</ins> ilogb(float);
+<del>float</del> <ins>long</ins> lrint(float);
+<del>float</del> <ins>long</ins> lround(float);
+<del>float</del> <ins>long long</ins> llrint(float);
+<del>float</del> <ins>long long</ins> llround(float);
+
+<del>long double</del> <ins>int</ins> ilogb(long double);
+<del>long double</del> <ins>long</ins> lrint(long double);
+<del>long double</del> <ins>long</ins> lround(long double);
+<del>long double</del> <ins>long long</ins> llrint(long double);
+<del>long double</del> <ins>long long</ins> llround(long double);
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="639"></a>639. Still problems with exceptions during streambuf IO</h3>
+<p><b>Section:</b> 27.6.1.2.3 [istream::extractors], 27.6.2.6.3 [ostream.inserters] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-17</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+There already exist two active DR's for the wording of 27.6.1.2.3 [istream::extractors]/13
+from 14882:2003(E), namely <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#413">413</a>.
+</p>
+
+<p>
+Even with these proposed corrections, already maintained in N2134,
+I have the feeling, that the current wording does still not properly
+handle the "exceptional" situation. The combination of para 14
+</p>
+
+<blockquote><p>
+"[..] Characters are extracted and inserted until
+any of the following occurs:
+</p>
+<p>
+[..]
+</p>
+<p>
+- an exception occurs (in which case the exception is caught)."
+</p></blockquote>
+
+<p>
+and 15
+</p>
+
+<blockquote><p>
+"If the function inserts no characters, it calls setstate(failbit),
+which
+may throw ios_base::failure (27.4.4.3). If it inserted no characters
+because it caught an exception thrown while extracting characters
+from *this and failbit is on in exceptions() (27.4.4.3), then the
+caught
+exception is rethrown."
+</p></blockquote>
+
+<p>
+both in N2134 seems to imply that any exception, which occurs
+*after* at least one character has been inserted is caught and lost
+for
+ever. It seems that even if failbit is on in exceptions() rethrow is
+not
+allowed due to the wording "If it inserted no characters because it
+caught an exception thrown while extracting".
+</p>
+
+<p>
+Is this behaviour by design?
+</p>
+
+<p>
+I would like to add that its output counterpart in 27.6.2.6.3 [ostream.inserters]/7-9
+(also
+N2134) does not demonstrate such an exception-loss-behaviour.
+On the other side, I wonder concerning several subtle differences
+compared to input::
+</p>
+<p>
+1) Paragraph 8 says at its end:
+</p>
+
+<blockquote><p>
+"- an exception occurs while getting a character from sb."
+</p></blockquote>
+
+<p>
+Note that there is nothing mentioned which would imply that such
+an exception will be caught compared to 27.6.1.2.3 [istream::extractors]/14.
+</p>
+
+<p>
+2) Paragraph 9 says:
+</p>
+
+<blockquote><p>
+"If the function inserts no characters, it calls setstate(failbit)
+(which
+may throw ios_base::failure (27.4.4.3)). If an exception was thrown
+while extracting a character, the function sets failbit in error
+state,
+and if failbit is on in exceptions() the caught exception is
+rethrown."
+</p></blockquote>
+
+<p>
+The sentence starting with "If an exception was thrown" seems to
+imply that such an exception *should* be caught before.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+(a) In 27.6.1.2.3 [istream::extractors]/15 (N2134) change the sentence
+</p>
+
+<blockquote><p>
+If the function inserts no characters, it calls
+<tt>setstate(failbit)</tt>, which may throw <tt>ios_base::failure</tt>
+(27.4.4.3). If <del>it inserted no characters because it caught an
+exception thrown while extracting characters from <tt>*this</tt></del>
+<ins>an exception was thrown while extracting a character from
+<tt>*this</tt>, the function sets <tt>failbit</tt> in error state,</ins>
+and <tt>failbit</tt> is on in <tt>exceptions()</tt> (27.4.4.3), then the
+caught exception is rethrown.
+</p></blockquote>
+
+<p>
+(b) In 27.6.2.6.3 [ostream.inserters]/8 (N2134) change the sentence:
+</p>
+
+<blockquote>
+<p>
+Gets characters from <tt>sb</tt> and inserts them in <tt>*this</tt>.
+Characters are read from <tt>sb</tt> and inserted until any of the
+following occurs:
+</p>
+<ul>
+<li>end-of-file occurs on the input sequence;</li>
+<li>inserting in the output sequence fails (in which case the character to be inserted is not extracted);</li>
+<li>an exception occurs while getting a character from <tt>sb</tt> <ins>(in which
+case the exception is caught)</ins>.</li>
+</ul>
+</blockquote>
+
+
+
+<p><b>Rationale:</b></p>
+This extractor is described as a formatted input function so the
+exception behavior is already specified. There is additional behavior
+described in this section that applies to the case in which failbit is
+set. This doesn't contradict the usual exception behavior for formatted
+input functions because that applies to the case in which badbit is set.
+
+
+
+
+
+<hr>
<h3><a name="641"></a>641. Editorial fix for 27.6.4 (N2134)</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#NAD%20Editorial">Pending NAD Editorial</a>
+<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#NAD%20Editorial">NAD Editorial</a>
<b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-18</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#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The function <tt>f</tt> in para 4 (27.6.4 [ext.manip]) references an unknown <tt>strm</tt>
@@ -9300,10 +9894,10 @@ Oxford: Editorial.
<hr>
<h3><a name="642"></a>642. Invalidated fstream footnotes in N2134</h3>
-<p><b>Section:</b> 27.8.1.9 [ifstream.members], 27.8.1.13 [ofstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
+<p><b>Section:</b> 27.8.1.9 [ifstream.members], 27.8.1.13 [ofstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
<b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-20</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ifstream.members">issues</a> in [ifstream.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The standard wording of N2134 has extended the 14882:2003(E)
@@ -9369,10 +9963,70 @@ In 27.8.1.13 [ofstream.members], remove footnote:
<hr>
+<h3><a name="647"></a>647. Inconsistent regex_search params</h3>
+<p><b>Section:</b> 28.11.3 [re.alg.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+28.11.3 [re.alg.search]/5 declares
+</p>
+
+<blockquote><pre>template &lt;class iterator, class charT, class traits&gt;
+bool regex_search(iterator first, iterator last,
+ const basic_regex&lt;charT, traits&gt;&amp; e,
+ regex_constants::match_flag_type flags =
+ regex_constants::match_default);
+</pre></blockquote>
+
+<p>
+where it's not explained, which iterator category
+the parameter iterator belongs to. This is inconsistent
+to the preceding declaration in the synopsis section
+28.4 [re.syn], which says:
+</p>
+
+<blockquote><pre>template &lt;class BidirectionalIterator, class charT, class traits&gt;
+bool regex_search(BidirectionalIterator first, BidirectionalIterator last,
+ const basic_regex&lt;charT, traits&gt;&amp; e,
+ regex_constants::match_flag_type flags =
+ regex_constants::match_default);
+</pre></blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 28.11.3 [re.alg.search]/5 replace all three occurences of param "iterator" with
+"BidirectionalIterator"
+</p>
+
+<blockquote><pre>template &lt;class <del>iterator</del> <ins>BidirectionalIterator</ins>, class charT, class traits&gt;
+ bool regex_search(<del>iterator</del> <ins>BidirectionalIterator</ins> first, <del>iterator</del> <ins>BidirectionalIterator</ins> last,
+ const basic_regex&lt;charT, traits&gt;&amp; e,
+ regex_constants::match_flag_type flags =
+ regex_constants::match_default);
+</pre>
+<p>
+-6- <i>Effects:</i> Behaves "as if" by constructing an object what of
+type <tt>match_results&lt;<del>iterator</del>
+<ins>BidirectionalIterator</ins>&gt;</tt> and then returning the result
+of <tt>regex_search(first, last, what, e, flags)</tt>.
+</p>
+</blockquote>
+
+
+<p><b>Rationale:</b></p>
+Applied to working paper while issue was still in New status.
+
+
+
+
+
+<hr>
<h3><a name="648"></a>648. regex_iterator c'tor needs clarification/editorial fix</h3>
-<p><b>Section:</b> 28.12.1.1 [re.regiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
+<p><b>Section:</b> 28.12.1.1 [re.regiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
<b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-03</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 28.12.1.1 [re.regiter.cnstr]/2 the effects paragraph starts with:
@@ -9424,10 +10078,10 @@ constructor sets <tt>*this</tt> to the end-of-sequence iterator.
<hr>
<h3><a name="649"></a>649. Several typos in regex_token_iterator constructors</h3>
-<p><b>Section:</b> 28.12.2.1 [re.tokiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
+<p><b>Section:</b> 28.12.2.1 [re.tokiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
<b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-03</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.tokiter.cnstr">issues</a> in [re.tokiter.cnstr].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In 28.12.2.1 [re.tokiter.cnstr]/1+2 both the constructor declaration
@@ -9526,10 +10180,10 @@ constructor sets <tt>*this</tt> to an end-of-sequence iterator.
<hr>
<h3><a name="656"></a>656. Typo in subtract_with_carry_engine declaration</h3>
-<p><b>Section:</b> 26.4.2 [rand.synopsis] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
+<p><b>Section:</b> 26.4.2 [rand.synopsis] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
<b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-08</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.synopsis">issues</a> in [rand.synopsis].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p>
26.4.2 [rand.synopsis] the header <tt>&lt;random&gt;</tt> synopsis
@@ -9557,6 +10211,331 @@ Pete: Recommends editorial.
<hr>
+<h3><a name="657"></a>657. unclear requirement about header inclusion</h3>
+<p><b>Section:</b> 17.4.2.1 [using.headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Gennaro Prota <b>Date:</b> 2007-03-14</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+17.4.2.1 [using.headers] states:
+</p>
+
+<blockquote><p>
+A translation unit shall include a header only outside of any
+external declaration or definition, [...]
+</p></blockquote>
+
+<p>
+I see three problems with this requirement:
+</p>
+
+<ol type="a">
+<li><p>The C++ standard doesn't define what an "external declaration" or
+an "external definition" are (incidentally the C99 standard does, and
+has a sentence very similar to the above regarding header inclusion).
+</p><p>
+I think the intent is that the #include directive shall lexically
+appear outside *any* declaration; instead, when the issue was pointed
+out on comp.std.c++ at least one poster interpreted "external
+declaration" as "declaration of an identifier with external linkage".
+If this were the correct interpretation, then the two inclusions below
+would be legal:
+</p>
+<blockquote><pre> // at global scope
+ static void f()
+ {
+# include &lt;cstddef&gt;
+ }
+
+ static void g()
+ {
+# include &lt;stddef.h&gt;
+ }
+</pre></blockquote>
+<p>
+(note that while the first example is unlikely to compile correctly,
+the second one may well do)
+</p></li>
+
+<li><p>as the sentence stands, violations will require a diagnostic; is
+this the intent? It was pointed out on comp.std.c++ (by several
+posters) that at least one way to ensure a diagnostic exists:
+</p>
+<blockquote><p>
+ [If there is an actual file for each header,] one simple way
+ to implement this would be to insert a reserved identifier
+ such as __begin_header at the start of each standard header.
+ This reserved identifier would be ignored for all other
+ purposes, except that, at the appropriate point in phase 7, if
+ it is found inside an external definition, a diagnostic is
+ generated. There's many other similar ways to achieve the same
+ effect.
+ </p>
+<p> --James Kuyper, on comp.std.c++
+</p></blockquote></li>
+
+<li><p>is the term "header" meant to be limited to standard headers?
+Clause 17 is all about the library, but still the general question is
+interesting and affects one of the points in the explicit namespaces
+proposal (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1691.html">n1691</a>):
+</p>
+<blockquote><p>
+ Those seeking to conveniently enable argument-dependent
+ lookups for all operators within an explicit namespace
+ could easily create a header file that does so:
+</p><pre> namespace mymath::
+ {
+ #include "using_ops.hpp"
+ }
+</pre></blockquote>
+</li>
+</ol>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+<p><b>Rationale:</b></p>
+We believe that the existing language does not cause any real confusion
+and any new formulation of the rules that we could come up with are
+unlikely to be better than what's already in the standard.
+
+
+
+
+
+<hr>
+<h3><a name="658"></a>658. Two unspecified function comparators in [function.objects]</h3>
+<p><b>Section:</b> 20.5 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-19</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The header <tt>&lt;functional&gt;</tt> synopsis in 20.5 [function.objects]
+contains the following two free comparison operator templates
+for the <tt>function</tt> class template
+</p>
+
+<blockquote><pre>template&lt;class Function1, class Function2&gt;
+void operator==(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);
+template&lt;class Function1, class Function2&gt;
+void operator!=(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);
+</pre></blockquote>
+
+<p>
+which are nowhere described. I assume that they are relicts before the
+corresponding two private and undefined member templates in the function
+template (see 20.5.15.2 [func.wrap.func] and X [func.wrap.func.undef]) have been introduced. The original free
+function templates should be removed, because using an undefined entity
+would lead to an ODR violation of the user.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Remove the above mentioned two function templates from
+the header <tt>&lt;functional&gt;</tt> synopsis (20.5 [function.objects])
+</p>
+
+<blockquote><pre><del>template&lt;class Function1, class Function2&gt;
+void operator==(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);
+template&lt;class Function1, class Function2&gt;
+void operator!=(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);</del>
+</pre></blockquote>
+
+
+
+<p><b>Rationale:</b></p>
+Fixed by
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2292.html">N2292</a>
+Standard Library Applications for Deleted Functions.
+
+
+
+
+
+<hr>
+<h3><a name="662"></a>662. Inconsistent handling of incorrectly-placed thousands separators</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#NAD">NAD</a>
+ <b>Submitter:</b> Cosmin Truta <b>Date:</b> 2007-04-05</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#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+From Section 22.2.2.1.2 [facet.num.get.virtuals], paragraphs 11 and 12, it is implied
+that the value read from a stream must be stored
+even if the placement of thousands separators does not conform to the
+<code>grouping()</code> specification from the <code>numpunct</code> facet.
+Since incorrectly-placed thousands separators are flagged as an extraction
+failure (by the means of <code>failbit</code>), we believe it is better not
+to store the value. A consistent strategy, in which any kind of extraction
+failure leaves the input item intact, is conceptually cleaner, is able to avoid
+corner-case traps, and is also more understandable from the programmer's point
+of view.
+</p>
+<p>
+Here is a quote from <i>"The C++ Programming Language (Special Edition)"</i>
+by B.&nbsp;Stroustrup (Section&nbsp;D.4.2.3, pg.&nbsp;897):
+</p>
+<blockquote><p>
+<i>"If a value of the desired type could not be read, failbit is set in r.
+[...] An input operator will use r to determine how to set the state of its
+stream. If no error was encountered, the value read is assigned through v;
+otherwise, v is left unchanged."</i>
+</p></blockquote>
+<p>
+This statement implies that <code>rdstate()</code> alone is sufficient to
+determine whether an extracted value is to be assigned to the input item
+<i>val</i> passed to <code>do_get</code>. However, this is in disagreement
+with the current C++ Standard. The above-mentioned assumption is true in all
+cases, except when there are mismatches in digit grouping. In the latter case,
+the parsed value is assigned to <i>val</i>, and, at the same time, <i>err</i>
+is assigned to <code>ios_base::failbit</code> (essentially "lying" about the
+success of the operation). Is this intentional? The current behavior raises
+both consistency and usability concerns.
+</p>
+<p>
+Although digit grouping is outside the scope of <code>scanf</code> (on which
+the virtual methods of <code>num_get</code> are based), handling of grouping
+should be consistent with the overall behavior of scanf. The specification of
+<code>scanf</code> makes a distinction between input failures and matching
+failures, and yet both kinds of failures have no effect on the input items
+passed to <code>scanf</code>. A mismatch in digit grouping logically falls in
+the category of matching failures, and it would be more consistent, and less
+surprising to the user, to leave the input item intact whenever a failure is
+being signaled.
+</p>
+<p>
+The extraction of <code>bool</code> is another example outside the scope of
+<code>scanf</code>, and yet consistent, even in the event of a successful
+extraction of a <code>long</code> but a failed conversion from
+<code>long</code> to <code>bool</code>.
+</p>
+<p>
+Inconsistency is further aggravated by the fact that, when failbit is set,
+subsequent extraction operations are no-ops until <code>failbit</code> is
+explicitly cleared. Assuming that there is no explicit handling of
+<code>rdstate()</code> (as in <code>cin&gt;&gt;i&gt;&gt;j</code>) it is
+counter-intuitive to be able to extract an integer with mismatched digit
+grouping, but to be unable to extract another, properly-formatted integer
+that immediately follows.
+</p>
+<p>
+Moreover, setting <code>failbit</code>, and selectively assigning a value to
+the input item, raises usability problems. Either the strategy of
+<code>scanf</code> (when there is no extracted value in case of failure), or
+the strategy of the <code>strtol</code> family (when there is always an
+extracted value, and there are well-defined defaults in case of a failure) are
+easy to understand and easy to use. On the other hand, if <code>failbit</code>
+alone cannot consistently make a difference between a failed extraction, and a
+successful but not-quite-correct extraction whose output happens to be the same
+as the previous value, the programmer must resort to implementation tricks.
+Consider the following example:
+</p>
+<pre> int i = old_i;
+ cin &gt;&gt; i;
+ if (cin.fail())
+ // can the value of i be trusted?
+ // what does it mean if i == old_i?
+ // ...
+</pre>
+<p>
+Last but not least, the current behvaior is not only confusing to the casual
+reader, but it has also been confusing to some book authors. Besides
+Stroustrup's book, other books (e.g. "Standard C++ IOStreams and Locales" by
+Langer and Kreft) are describing the same mistaken assumption. Although books
+are not to be used instead of the standard reference, the readers of these
+books, as well as the people who are generally familiar to <code>scanf</code>,
+are even more likely to misinterpret the standard, and expect the input items
+to remain intact when a failure occurs.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+Change 22.2.2.1.2 [facet.num.get.virtuals]:
+</p>
+
+<blockquote>
+<p>
+<b>Stage 3:</b> The result of stage 2 processing can be one of
+</p>
+<ul>
+<li>A sequence of <code>chars</code> has been accumulated in stage 2 that is converted (according to the rules of <code>scanf</code>) to a value of the type of <code><i>val</i></code>. <del>This value is stored in <code><i>val</i></code> and <code>ios_base::goodbit</code> is stored in <code><i>err</i></code>.</del></li>
+
+<li>The sequence of <code>chars</code> accumulated in stage 2 would have caused <code>scanf</code> to report an input failure. <code>ios_base::failbit</code> is assigned to <code><i>err</i></code>.</li>
+</ul>
+<p>
+<ins>In the first case,</ins> <del>D</del><ins>d</ins>igit grouping is checked. That is, the positions of discarded separators is examined for consistency with <code>use_facet&lt;numpunct&lt;charT&gt; &gt;(<i>loc</i>).grouping()</code>. If they are not consistent then <code>ios_base::failbit</code> is assigned to <code><i>err</i></code>. <ins>Otherwise, the value that was converted in stage 2 is stored in <code><i>val</i></code> and <code>ios_base::goodbit</code> is stored in <code><i>err</i></code>.</ins>
+</p>
+</blockquote>
+
+
+<p><b>Rationale:</b></p>
+post-Toronto: Changed from New to NAD at the request of the author. The preferred solution of
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2327.pdf">N2327</a>
+makes this resolution obsolete.
+
+
+
+
+
+<hr>
+<h3><a name="663"></a>663. Complexity Requirements</h3>
+<p><b>Section:</b> 17.3.1.3 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
+ <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#structure.specifications">issues</a> in [structure.specifications].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+17.3.1.3 [structure.specifications] para 5 says
+</p>
+
+<blockquote><p>
+-5- Complexity requirements specified in the library&nbsp;
+clauses are upper bounds, and implementations that provide better
+complexity guarantees satisfy the requirements.
+</p></blockquote>
+
+<p>
+The following
+objection has been raised:
+</p>
+
+<blockquote><p>
+The library clauses suggest general
+guidelines regarding complexity, but we have been unable to discover
+any absolute hard-and-fast formulae for these requirements.&nbsp; Unless
+or until the Library group standardizes specific hard-and-fast
+formulae, we regard all the complexity requirements as subject to a&nbsp;
+"fudge factor" without any intrinsic upper bound.
+</p></blockquote>
+
+<p>
+[Plum ref&nbsp;
+_23213Y31 etc]
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+<p><b>Rationale:</b></p>
+Kona (2007): No specific instances of underspecification have been
+identified, and big-O notation always involves constant factors.
+
+
+
+
+
+<hr>
<h3><a name="683"></a>683. regex_token_iterator summary error</h3>
<p><b>Section:</b> 28.12.2 [re.tokiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
<b>Submitter:</b> Eric Niebler <b>Date:</b> 2007-06-02</p>
@@ -9605,4 +10584,44 @@ Yep, looks like a typo/administrative fix to me.
+<hr>
+<h3><a name="690"></a>690. abs(long long) should return long long</h3>
+<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
+ <b>Submitter:</b> Niels Dekker <b>Date:</b> 2007-06-10</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Quoting the latest draft (n2135), 26.7 [c.math]:
+</p>
+
+<blockquote>
+<p>
+The added signatures are:
+</p>
+<blockquote><pre>long abs(long); // labs()
+long abs(long long); // llabs()
+</pre></blockquote>
+</blockquote>
+<p>
+Shouldn't <tt>abs(long long)</tt> have <tt>long long</tt> as return type?
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 26.7 [c.math]:
+</p>
+<blockquote><pre><ins>long </ins>long abs(long long); // llabs()
+</pre></blockquote>
+
+
+<p><b>Rationale:</b></p>
+Had already been fixed in the WP by the time the LWG reviewed this.
+
+
+
+
+
</body></html> \ No newline at end of file
diff --git a/libstdc++-v3/docs/html/ext/lwg-defects.html b/libstdc++-v3/docs/html/ext/lwg-defects.html
index 3f4b20c..cefbee6 100644
--- a/libstdc++-v3/docs/html/ext/lwg-defects.html
+++ b/libstdc++-v3/docs/html/ext/lwg-defects.html
@@ -1,22 +1,22 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html><head><title>C++ Standard Library Defect Report List</title>
+
+
<style type="text/css">
p {text-align:justify}
li {text-align:justify}
-ins {background-color:#FFFFA0}
-del {background-color:#FFFFA0}
-</style></head>
-
-<body>
+ins {background-color:#A0FFA0}
+del {background-color:#FFA0A0}
+</style></head><body>
<table>
<tbody><tr>
<td align="left">Doc. no.</td>
-<td align="left">N2318=07-0178</td>
+<td align="left">N2457=07-0327</td>
</tr>
<tr>
<td align="left">Date:</td>
-<td align="left">2007-06-24</td>
+<td align="left">2007-10-20</td>
</tr>
<tr>
<td align="left">Project:</td>
@@ -27,7 +27,7 @@ del {background-color:#FFFFA0}
<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 Defect Report List (Revision R49)</h1>
+<h1>C++ Standard Library Defect Report List (Revision R52)</h1>
<p>Reference ISO/IEC IS 14882:1998(E)</p>
<p>Also see:</p>
@@ -49,6 +49,71 @@ del {background-color:#FFFFA0}
<h2>Revision History</h2>
<ul>
+<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-active.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#754">754</a>.</li>
+<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-active.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li>
+<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-active.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#706">706</a>.</li>
+<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#680">680</a>.</li>
+<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>.</li>
+<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-active.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>.</li>
+</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-active.html#697">697</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li>
+<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-active.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#680">680</a>.</li>
+<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-defects.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-active.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>
@@ -58,7 +123,7 @@ del {background-color:#FFFFA0}
<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-active.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li>
<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>
@@ -75,7 +140,7 @@ del {background-color:#FFFFA0}
<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-active.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#663">663</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>.</li>
+<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>.</li>
<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-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
<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>
@@ -85,8 +150,8 @@ del {background-color:#FFFFA0}
<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-active.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#604">604</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-defects.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>
@@ -102,7 +167,7 @@ del {background-color:#FFFFA0}
<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-active.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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 New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#626">626</a>.</li>
<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#570">570</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#614">614</a>.</li>
<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>
@@ -136,9 +201,9 @@ del {background-color:#FFFFA0}
<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-active.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li>
+<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li>
<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-active.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#604">604</a> to Review.</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>
@@ -152,7 +217,7 @@ del {background-color:#FFFFA0}
<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-active.html#583">583</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#592">592</a>.</li>
+<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>
@@ -182,8 +247,8 @@ del {background-color:#FFFFA0}
<li><b>Details:</b><ul>
<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#567">567</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
<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-active.html#525">525</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.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-active.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a> to Open.</li>
+<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>
@@ -198,7 +263,7 @@ del {background-color:#FFFFA0}
<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-active.html#566">566</a>.</li>
+<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>
@@ -219,7 +284,7 @@ del {background-color:#FFFFA0}
</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-active.html#528">528</a>.
+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.
@@ -245,7 +310,7 @@ previously in "DR" status were moved to "WP".
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-active.html#488">488</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#494">494</a>.
+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.
@@ -1867,6 +1932,7 @@ setstate(badbit).]</i></p>
<h3><a name="42"></a>42. String ctors specify wrong default allocator</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#TC">TC</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#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#TC">TC</a> status.</p>
<p><b>Discussion:</b></p>
@@ -3038,7 +3104,6 @@ VI of that paper.</p>
<h3><a name="61"></a>61. Ambiguity in iostreams exception policy</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#TC">TC</a>
<b>Submitter:</b> Matt Austern <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#istream.unformatted">active issues</a> in [istream.unformatted].</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#TC">TC</a> status.</p>
<p><b>Discussion:</b></p>
@@ -3088,7 +3153,6 @@ resolution as better standardese.</p>
<h3><a name="62"></a>62. <tt>Sync</tt>'s return value</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#TC">TC</a>
<b>Submitter:</b> Matt Austern <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#istream.unformatted">active issues</a> in [istream.unformatted].</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#TC">TC</a> status.</p>
<p><b>Discussion:</b></p>
@@ -3608,6 +3672,7 @@ class complex. This redundancy should be removed.</p>
<h3><a name="83"></a>83. String::npos vs. string::max_size()</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#TC">TC</a>
<b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</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#TC">TC</a> status.</p>
<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#89">89</a></p>
@@ -4768,17 +4833,17 @@ typedefs and that is sufficient. </p>
<hr>
<h3><a name="123"></a>123. Should valarray helper arrays fill functions be const?</h3>
-<p><b>Section:</b> 26.5.5.4 [slice.arr.fill], 26.5.7.4 [gslice.array.fill], 26.5.8.4 [mask.array.fill], 26.5.9.4 [indirect.array.fill] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 26.5.5.3 [slice.arr.fill], 26.5.7.3 [gslice.array.fill], 26.5.8.3 [mask.array.fill], 26.5.9.3 [indirect.array.fill] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
<b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>One of the operator= in the valarray helper arrays is const and one
is not. For example, look at slice_array. This operator= in Section
-26.5.5.2 [slice.arr.assign] is const: </p>
+26.5.5.1 [slice.arr.assign] is const: </p>
<p>&nbsp;&nbsp;&nbsp; <tt>void operator=(const valarray&lt;T&gt;&amp;) const;</tt> </p>
-<p>but this one in Section 26.5.5.4 [slice.arr.fill] is not: </p>
+<p>but this one in Section 26.5.5.3 [slice.arr.fill] is not: </p>
<p>&nbsp;&nbsp;&nbsp; <tt>void operator=(const T&amp;); </tt></p>
@@ -4799,7 +4864,7 @@ is not. For example, look at slice_array. This operator= in Section
</pre>
</blockquote>
-<p>26.5.5.4 [slice.arr.fill] slice_array fill function</p>
+<p>26.5.5.3 [slice.arr.fill] slice_array fill function</p>
<blockquote>
<p>Change the function declaration</p>
@@ -4822,7 +4887,7 @@ is not. For example, look at slice_array. This operator= in Section
</pre>
</blockquote>
-<p>26.5.7.4 [gslice.array.fill] gslice_array fill function</p>
+<p>26.5.7.3 [gslice.array.fill] gslice_array fill function</p>
<blockquote>
<p>Change the function declaration</p>
@@ -4845,7 +4910,7 @@ is not. For example, look at slice_array. This operator= in Section
</pre>
</blockquote>
-<p>26.5.8.4 [mask.array.fill] mask_array fill function</p>
+<p>26.5.8.3 [mask.array.fill] mask_array fill function</p>
<blockquote>
<p>Change the function declaration</p>
@@ -4868,7 +4933,7 @@ is not. For example, look at slice_array. This operator= in Section
</pre>
</blockquote>
-<p>26.5.9.4 [indirect.array.fill] indirect_array fill function</p>
+<p>26.5.9.3 [indirect.array.fill] indirect_array fill function</p>
<blockquote>
<p>Change the function declaration</p>
@@ -5047,7 +5112,6 @@ a public assignment operator to the <tt>auto_ptr</tt> definition: </p>
<h3><a name="129"></a>129. Need error indication from seekp() and seekg()</h3>
<p><b>Section:</b> 27.6.1.3 [istream.unformatted], 27.6.2.5 [ostream.seeks] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
<b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-02-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.unformatted">active issues</a> in [istream.unformatted].</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#TC">TC</a> status.</p>
<p><b>Discussion:</b></p>
@@ -5146,7 +5210,12 @@ Matt provided wording.]</i></p>
of erase as well as the single-iterator form. Also, the wording is
slightly different from the wording we have for sequences; there's no
good reason for having a difference. Matt provided new wording,
- which we will review at the next meeting.
+(reflected above) which we will review at the next meeting.
+]</i></p>
+
+
+<p><i>[
+Redmond: formally voted into WP.
]</i></p>
@@ -5253,7 +5322,6 @@ is greater than or equal to 2.
<h3><a name="136"></a>136. seekp, seekg setting wrong streams?</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#WP">WP</a>
<b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.unformatted">active issues</a> in [istream.unformatted].</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#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
@@ -6366,7 +6434,6 @@ paragraph 14 from:</p>
<h3><a name="172"></a>172. Inconsistent types for <tt>basic_istream::ignore()</tt></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#TC">TC</a>
<b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Date:</b> 1999-07-23</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.unformatted">active issues</a> in [istream.unformatted].</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#TC">TC</a> status.</p>
<p><b>Discussion:</b></p>
@@ -7119,7 +7186,6 @@ Josuttis provided the above wording.]</i></p>
<h3><a name="185"></a>185. Questionable use of term "inline"</h3>
<p><b>Section:</b> 20.5 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
<b>Submitter:</b> UK Panel <b>Date:</b> 1999-07-26</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#function.objects">active issues</a> in [function.objects].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
@@ -8204,6 +8270,7 @@ iterators. Null pointers are singular.
<h3><a name="209"></a>209. basic_string declarations 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#TC">TC</a>
<b>Submitter:</b> Igor Stauder <b>Date:</b> 2000-02-11</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#TC">TC</a> status.</p>
<p><b>Discussion:</b></p>
@@ -8537,7 +8604,6 @@ deliberately, with full knowledge of that limitation.</p>
<h3><a name="222"></a>222. Are throw clauses necessary if a throw is already implied by the effects clause?</h3>
<p><b>Section:</b> 17.3.1.3 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
<b>Submitter:</b> Judy Ward <b>Date:</b> 2000-03-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#structure.specifications">active issues</a> in [structure.specifications].</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#structure.specifications">issues</a> in [structure.specifications].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
<p><b>Discussion:</b></p>
@@ -10060,7 +10126,6 @@ intentional.]</i></p>
<h3><a name="243"></a>243. <tt>get</tt> and <tt>getline</tt> when sentry reports failure</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#WP">WP</a>
<b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-05-15</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.unformatted">active issues</a> in [istream.unformatted].</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#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
@@ -10456,12 +10521,12 @@ classes are almost entirely useless.</p>
<li> Make the copy constructor and copy-assignment operator declarations
public in the slice_array class template definition in 26.5.5 [template.slice.array] </li>
<li> remove paragraph 3 of 26.5.5 [template.slice.array]</li>
-<li> remove the copy constructor declaration from 26.5.5.1 [cons.slice.arr]</li>
-<li> change paragraph 1 of 26.5.5.1 [cons.slice.arr] to read "This constructor is declared
+<li> remove the copy constructor declaration from [cons.slice.arr]</li>
+<li> change paragraph 1 of [cons.slice.arr] to read "This constructor is declared
to be private. This constructor need not be defined."</li>
-<li> remove the first sentence of paragraph 1 of 26.5.5.2 [slice.arr.assign]</li>
+<li> remove the first sentence of paragraph 1 of 26.5.5.1 [slice.arr.assign]</li>
<li> Change the first three words of the second sentence of paragraph 1 of
- 26.5.5.2 [slice.arr.assign] to "These assignment operators have"</li>
+ 26.5.5.1 [slice.arr.assign] to "These assignment operators have"</li>
</ul>
<p>gslice_array:</p>
@@ -10469,12 +10534,12 @@ classes are almost entirely useless.</p>
<li> Make the copy constructor and copy-assignment operator declarations
public in the gslice_array class template definition in 26.5.7 [template.gslice.array] </li>
<li> remove the note in paragraph 3 of 26.5.7 [template.gslice.array]</li>
-<li> remove the copy constructor declaration from 26.5.7.1 [gslice.array.cons]</li>
-<li> change paragraph 1 of 26.5.7.1 [gslice.array.cons] to read "This constructor is declared
+<li> remove the copy constructor declaration from [gslice.array.cons]</li>
+<li> change paragraph 1 of [gslice.array.cons] to read "This constructor is declared
to be private. This constructor need not be defined."</li>
-<li> remove the first sentence of paragraph 1 of 26.5.7.2 [gslice.array.assign]</li>
+<li> remove the first sentence of paragraph 1 of 26.5.7.1 [gslice.array.assign]</li>
<li> Change the first three words of the second sentence of paragraph 1 of
- 26.5.7.2 [gslice.array.assign] to "These assignment operators have"</li>
+ 26.5.7.1 [gslice.array.assign] to "These assignment operators have"</li>
</ul>
<p>mask_array:</p>
@@ -10482,12 +10547,12 @@ classes are almost entirely useless.</p>
<li> Make the copy constructor and copy-assignment operator declarations
public in the mask_array class template definition in 26.5.8 [template.mask.array] </li>
<li> remove the note in paragraph 2 of 26.5.8 [template.mask.array]</li>
-<li> remove the copy constructor declaration from 26.5.8.1 [mask.array.cons]</li>
-<li> change paragraph 1 of 26.5.8.1 [mask.array.cons] to read "This constructor is declared
+<li> remove the copy constructor declaration from [mask.array.cons]</li>
+<li> change paragraph 1 of [mask.array.cons] to read "This constructor is declared
to be private. This constructor need not be defined."</li>
-<li> remove the first sentence of paragraph 1 of 26.5.8.2 [mask.array.assign]</li>
+<li> remove the first sentence of paragraph 1 of 26.5.8.1 [mask.array.assign]</li>
<li> Change the first three words of the second sentence of paragraph 1 of
- 26.5.8.2 [mask.array.assign] to "These assignment operators have"</li>
+ 26.5.8.1 [mask.array.assign] to "These assignment operators have"</li>
</ul>
<p>indirect_array:</p>
@@ -10495,12 +10560,12 @@ classes are almost entirely useless.</p>
<li>Make the copy constructor and copy-assignment operator declarations
public in the indirect_array class definition in 26.5.9 [template.indirect.array]</li>
<li> remove the note in paragraph 2 of 26.5.9 [template.indirect.array]</li>
-<li> remove the copy constructor declaration from 26.5.9.1 [indirect.array.cons]</li>
-<li> change the descriptive text in 26.5.9.1 [indirect.array.cons] to read "This constructor is
+<li> remove the copy constructor declaration from [indirect.array.cons]</li>
+<li> change the descriptive text in [indirect.array.cons] to read "This constructor is
declared to be private. This constructor need not be defined."</li>
-<li> remove the first sentence of paragraph 1 of 26.5.9.2 [indirect.array.assign]</li>
+<li> remove the first sentence of paragraph 1 of 26.5.9.1 [indirect.array.assign]</li>
<li> Change the first three words of the second sentence of paragraph 1 of
- 26.5.9.2 [indirect.array.assign] to "These assignment operators have"</li>
+ 26.5.9.1 [indirect.array.assign] to "These assignment operators have"</li>
</ul>
<p><i>[Proposed resolution was modified in Santa Cruz: explicitly make
copy constructor and copy assignment operators public, instead of
@@ -11006,10 +11071,11 @@ copyfmt_event.
<hr>
<h3><a name="258"></a>258. Missing allocator 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#WP">Pending WP</a>
+<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#WP">WP</a>
<b>Submitter:</b> Matt Austern <b>Date:</b> 2000-08-22</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#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
From lib-7752:
@@ -11081,15 +11147,9 @@ other issues related to allocator instances.]</i></p>
<p><b>Proposed resolution:</b></p>
<p>
-Add row to Table 35: Allocator requirements, right after the row defining <tt>operator!=</tt>:
-</p>
-
-<blockquote>
-<p>
-If <tt>a1 == a2</tt> then <tt>Y(a1) == Y(a2)</tt>
+Accept proposed wording from
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2436.pdf">N2436</a> part 3.
</p>
-</blockquote>
-
<p><i>[Lillehammer: Same conclusion as before: this should be
@@ -11101,6 +11161,21 @@ Batavia: An allocator redesign is not forthcoming and thus we fixed this one is
]</i></p>
+<p><i>[
+Toronto: Reopened at the request of the project editor (Pete) because the proposed
+wording did not fit within the indicated table. The intent of the resolution remains
+unchanged. Pablo to work with Pete on improved wording.
+]</i></p>
+
+
+<p><i>[
+Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which
+was subsequently split out into a separate paper N2436 for the purposes of voting.
+The resolution in N2436 addresses this issue. The LWG voted to accelerate this
+issue to Ready status to be voted into the WP at Kona.
+]</i></p>
+
+
@@ -11236,6 +11311,7 @@ to:
<h3><a name="263"></a>263. Severe restriction on <tt>basic_string</tt> reference counting</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#WP">WP</a>
<b>Submitter:</b> Kevlin Henney <b>Date:</b> 2000-09-04</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#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
@@ -14728,6 +14804,7 @@ does.</p>
<h3><a name="334"></a>334. map::operator[] specification forces inefficient implementation</h3>
<p><b>Section:</b> 23.3.1.2 [map.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
<b>Submitter:</b> Andrea Griffini <b>Date:</b> 2001-09-02</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map.access">issues</a> in [map.access].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
@@ -15266,20 +15343,20 @@ the two vectors, including their reallocation guarantees.
<hr>
<h3><a name="345"></a>345. type tm in &lt;cwchar&gt;</h3>
-<p><b>Section:</b> 21.4 [c.strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 21.5 [c.strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
<b>Submitter:</b> Clark Nelson <b>Date:</b> 2001-10-19</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.strings">issues</a> in [c.strings].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>C99, and presumably amendment 1 to C90, specify that &lt;wchar.h&gt;
-declares struct tm as an incomplete type. However, table 48 in 21.4
+declares struct tm as an incomplete type. However, table 48 in 21.5
[c.strings] does not mention the type tm as being declared in
&lt;cwchar&gt;. Is this omission intentional or accidental?
</p>
<p><b>Proposed resolution:</b></p>
-<p>In section 21.4 [c.strings], add "tm" to table 48.</p>
+<p>In section 21.5 [c.strings], add "tm" to table 48.</p>
@@ -16187,7 +16264,6 @@ do to ensure that stream objects are constructed during startup.</p>
<h3><a name="370"></a>370. Minor error in basic_istream::get</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#WP">WP</a>
<b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-07-15</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.unformatted">active issues</a> in [istream.unformatted].</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#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
@@ -16982,6 +17058,90 @@ Replace "((T*) p)" with "p".
<hr>
+<h3><a name="401"></a>401. incorrect type casts in table 32 in lib.allocator.requirements</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#WP">WP</a>
+ <b>Submitter:</b> Markus Mauhart <b>Date:</b> 2003-02-27</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#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+I think that in par2 of [default.con.req] the last two
+lines of table 32 contain two incorrect type casts. The lines are ...
+</p>
+
+<pre> a.construct(p,t) Effect: new((void*)p) T(t)
+ a.destroy(p) Effect: ((T*)p)?-&gt;~T()
+</pre>
+
+<p>
+.... with the prerequisits coming from the preceding two paragraphs, especially
+from table 31:
+</p>
+
+<pre> alloc&lt;T&gt; a ;// an allocator for T
+ alloc&lt;T&gt;::pointer p ;// random access iterator
+ // (may be different from T*)
+ alloc&lt;T&gt;::reference r = *p;// T&amp;
+ T const&amp; t ;
+</pre>
+
+<p>
+For that two type casts ("(void*)p" and "(T*)p") to be well-formed
+this would require then conversions to T* and void* for all
+alloc&lt;T&gt;::pointer, so it would implicitely introduce extra
+requirements for alloc&lt;T&gt;::pointer, additionally to the only
+current requirement (being a random access iterator).
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+Accept proposed wording from
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2436.pdf">N2436</a> part 1.
+</p>
+
+<p>
+Note: Actually I would prefer to replace "((T*)p)?-&gt;dtor_name" with
+"p?-&gt;dtor_name", but AFAICS this is not possible cause of an omission
+in 13.5.6 [over.ref] (for which I have filed another DR on 29.11.2002).
+</p>
+
+<p><i>[Kona: The LWG thinks this is somewhere on the border between
+ Open and NAD. The intend is clear: <tt>construct</tt> constructs an
+ object at the location <i>p</i>. It's reading too much into the
+ description to think that literally calling <tt>new</tt> is
+ required. Tweaking this description is low priority until we can do
+ a thorough review of allocators, and, in particular, allocators with
+ non-default pointer types.]</i></p>
+
+
+<p><i>[
+Batavia: Proposed resolution changed to less code and more description.
+]</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>
+
+
+<p><i>[
+Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which
+was subsequently split out into a separate paper N2436 for the purposes of voting.
+The resolution in N2436 addresses this issue. The LWG voted to accelerate this
+issue to Ready status to be voted into the WP at Kona.
+]</i></p>
+
+
+
+
+
+
+
+<hr>
<h3><a name="402"></a>402. wrong new expression in [some_]allocator::construct</h3>
<p><b>Section:</b> 20.1.2 [allocator.requirements], 20.6.1.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
<b>Submitter:</b> Markus Mauhart <b>Date:</b> 2003-02-27</p>
@@ -17882,6 +18042,7 @@ no storage can be obtained or if <i>n</i> &lt;= 0."</p>
<h3><a name="426"></a>426. search_n(), fill_n(), and generate_n() with negative n</h3>
<p><b>Section:</b> 25.1.9 [alg.search], 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#WP">WP</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#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#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<p>
@@ -19140,11 +19301,11 @@ undefined."
<hr>
<h3><a name="453"></a>453. basic_stringbuf::seekoff need not always fail for an empty stream</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#DR">DR</a>
+<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#WP">WP</a>
<b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#stringbuf.virtuals">active issues</a> in [stringbuf.virtuals].</p>
<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#DR">DR</a> status.</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<pre> pos_type basic_stringbuf::seekoff(off_type, ios_base::seekdir,
ios_base::openmode);
@@ -19997,6 +20158,92 @@ This is a defect because it constrains an lvalue to returning a modifiable lvalu
<hr>
+<h3><a name="488"></a>488. rotate throws away useful information</h3>
+<p><b>Section:</b> 25.2.11 [alg.rotate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2004-11-22</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+rotate takes 3 iterators: first, middle and last which point into a
+sequence, and rearranges the sequence such that the subrange [middle,
+last) is now at the beginning of the sequence and the subrange [first,
+middle) follows. The return type is void.
+</p>
+
+<p>
+In many use cases of rotate, the client needs to know where the
+subrange [first, middle) starts after the rotate is performed. This
+might look like:
+</p>
+<pre> rotate(first, middle, last);
+ Iterator i = advance(first, distance(middle, last));
+</pre>
+
+<p>
+Unless the iterators are random access, the computation to find the
+start of the subrange [first, middle) has linear complexity. However,
+it is not difficult for rotate to return this information with
+negligible additional computation expense. So the client could code:
+</p>
+<pre> Iterator i = rotate(first, middle, last);
+</pre>
+
+<p>
+and the resulting program becomes significantly more efficient.
+</p>
+
+<p>
+While the backwards compatibility hit with this change is not zero, it
+is very small (similar to that of lwg <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>), and there is
+a significant benefit to the change.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>In 25 [algorithms] p2, change:</p>
+
+<blockquote><pre> template&lt;class ForwardIterator&gt;
+ <del>void</del> <ins>ForwardIterator</ins> rotate(ForwardIterator first, ForwardIterator middle,
+ ForwardIterator last);
+</pre></blockquote>
+
+<p>In 25.2.11 [alg.rotate], change:</p>
+
+<blockquote><pre> template&lt;class ForwardIterator&gt;
+ <del>void</del> <ins>ForwardIterator</ins> rotate(ForwardIterator first, ForwardIterator middle,
+ ForwardIterator last);
+</pre></blockquote>
+
+<p>In 25.2.11 [alg.rotate] insert a new paragraph after p1:</p>
+
+<blockquote>
+<p><b>Returns</b>: <tt>first + (last - middle)</tt>.</p>
+</blockquote>
+
+<p><i>[
+The LWG agrees with this idea, but has one quibble: we want to make
+sure not to give the impression that the function "advance" is
+actually called, just that the nth iterator is returned. (Calling
+advance is observable behavior, since users can specialize it for
+their own iterators.) Howard will provide wording.
+]</i></p>
+
+
+<p><i>[Howard provided wording for mid-meeting-mailing Jun. 2005.]</i></p>
+
+
+<p><i>[
+Toronto: moved to Ready.
+]</i></p>
+
+
+
+
+
+
+
+<hr>
<h3><a name="495"></a>495. Clause 22 template parameter requirements</h3>
<p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
<b>Submitter:</b> Beman Dawes <b>Date:</b> 2005-01-10</p>
@@ -20362,7 +20609,7 @@ of <tt>data()</tt> is unspecified.
<hr>
<h3><a name="520"></a>520. Result_of and pointers to data members</h3>
-<p><b>Section:</b> 20.5.10.1 [func.bind], TR1 3.6 [tr.func.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 20.5.11.1 [func.bind], TR1 3.6 [tr.func.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
<b>Submitter:</b> Pete Becker <b>Date:</b> 2005-07-03</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
@@ -20475,9 +20722,88 @@ function's cv-qualifiers); the type <tt>T1</tt> is <tt><i>cv</i> T0*</tt></ins>
<hr>
+<h3><a name="524"></a>524. regex named character classes and case-insensitivity don't mix</h3>
+<p><b>Section:</b> 28 [re] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</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#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+This defect is also being discussed on the Boost developers list. The
+full discussion can be found here:
+http://lists.boost.org/boost/2005/07/29546.php
+</p>
+<p>
+-- Begin original message --
+</p>
+<p>
+Also, I may have found another issue, closely related to the one under
+discussion. It regards case-insensitive matching of named character
+classes. The regex_traits&lt;&gt; provides two functions for working with
+named char classes: lookup_classname and isctype. To match a char class
+such as [[:alpha:]], you pass "alpha" to lookup_classname and get a
+bitmask. Later, you pass a char and the bitmask to isctype and get a
+bool yes/no answer.
+</p>
+<p>
+But how does case-insensitivity work in this scenario? Suppose we're
+doing a case-insensitive match on [[:lower:]]. It should behave as if it
+were [[:lower:][:upper:]], right? But there doesn't seem to be enough
+smarts in the regex_traits interface to do this.
+</p>
+<p>
+Imagine I write a traits class which recognizes [[:fubar:]], and the
+"fubar" char class happens to be case-sensitive. How is the regex engine
+to know that? And how should it do a case-insensitive match of a
+character against the [[:fubar:]] char class? John, can you confirm this
+is a legitimate problem?
+</p>
+<p>
+I see two options:
+</p>
+<p>
+1) Add a bool icase parameter to lookup_classname. Then,
+lookup_classname( "upper", true ) will know to return lower|upper
+instead of just upper.
+</p>
+<p>
+2) Add a isctype_nocase function
+</p>
+<p>
+I prefer (1) because the extra computation happens at the time the
+pattern is compiled rather than when it is executed.
+</p>
+<p>
+-- End original message --
+</p>
+
+<p>
+For what it's worth, John has also expressed his preference for option
+(1) above.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Adopt the proposed resolution in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
+</p>
+
+
+<p><i>[
+Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]</i></p>
+
+
+
+
+
+<hr>
<h3><a name="530"></a>530. Must elements of a string be contiguous?</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#WP">WP</a>
<b>Submitter:</b> Matt Austern <b>Date:</b> 2005-11-15</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#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
@@ -20528,8 +20854,84 @@ more design choices.
<hr>
+<h3><a name="531"></a>531. array forms of unformatted input functions</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#WP">WP</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-11-23</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#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The array forms of unformatted input functions don't seem to have well-defined
+semantics for zero-element arrays in a couple of cases. The affected ones
+(<tt>istream::get()</tt> and <tt>istream::getline()</tt>) are supposed to
+terminate when <tt>(n - 1)</tt> characters are stored, which obviously can
+never be true when <tt>(n == 0)</tt> holds to start with. See
+c++std-lib-16071.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+I suggest changing 27.6.1.3, p7 (<tt>istream::get()</tt>), bullet 1 to read:
+</p>
+ <ul>
+ <li>
+ <tt>(n &lt; 1)</tt> is true or <tt>(n - 1)</tt> characters
+ are stored;
+ </li>
+ </ul>
+<p>
+Change 27.6.1.3, p9:
+</p>
+
+<blockquote><p>
+If the function stores no characters, it calls <tt>setstate(failbit)</tt> (which
+may throw <tt>ios_base::failure</tt> (27.4.4.3)). In any case, <ins>if <tt>(n
+&gt; 0)</tt> is true</ins> it then stores a null character into the next
+successive location of the array.
+</p></blockquote>
+
+ <p>
+
+and similarly p17 (<tt>istream::getline()</tt>), bullet 3 to:
+
+ </p>
+ <ul>
+ <li>
+ <tt>(n &lt; 1)</tt> is true or <tt>(n - 1)</tt> characters
+ are stored (in which case the function calls
+ <tt>setstate(failbit)</tt>).
+ </li>
+ </ul>
+
+ <p>
+
+In addition, to clarify that <tt>istream::getline()</tt> must not store the
+terminating NUL character unless the the array has non-zero size, Robert
+Klarer suggests in c++std-lib-16082 to change 27.6.1.3, p20 to read:
+
+ </p>
+ <blockquote><p>
+
+In any case, provided <tt>(n &gt; 0)</tt> is true, it then stores a null character
+(using charT()) into the next successive location of the array.
+
+ </p></blockquote>
+
+<p><i>[
+post-Redmond: Pete noticed that the current resolution for <tt>get</tt> requires
+writing to out of bounds memory when <tt>n == 0</tt>. Martin provided fix.
+]</i></p>
+
+
+
+
+
+
+
+<hr>
<h3><a name="533"></a>533. typo in 2.2.3.10/1</h3>
-<p><b>Section:</b> 20.6.6.2.10 [util.smartptr.getdeleter], TR1 2.2.3.10 [tr.util.smartptr.getdeleter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
+<p><b>Section:</b> 20.6.6.2.11 [util.smartptr.getdeleter], TR1 2.2.3.10 [tr.util.smartptr.getdeleter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
<b>Submitter:</b> Paolo Carlini <b>Date:</b> 2005-11-09</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.getdeleter">issues</a> in [util.smartptr.getdeleter].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
@@ -20562,6 +20964,7 @@ If <tt><del>*this</del> <ins>p</ins></tt> <i>owns</i> a deleter <tt>d</tt>...
<h3><a name="534"></a>534. Missing basic_string members</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#WP">WP</a>
<b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2005-11-16</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#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
@@ -20743,7 +21146,6 @@ characters that <del>were</del> <ins>was</ins> in <tt><i>s</i></tt>,
<h3><a name="537"></a>537. Typos in the signatures in 27.6.1.3/42-43 and 27.6.2.4</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#WP">WP</a>
<b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-02-12</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.unformatted">active issues</a> in [istream.unformatted].</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#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
@@ -20914,6 +21316,7 @@ definition) of the function shall be well-formed.</ins>
<h3><a name="541"></a>541. shared_ptr template assignment and void</h3>
<p><b>Section:</b> 20.6.6.2 [util.smartptr.shared], TR1 2.2.3 [tr.util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
<b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-10-16</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#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
@@ -21129,7 +21532,7 @@ lengths, and strides, as explained in the previous section.
<hr>
<h3><a name="545"></a>545. When is a deleter deleted?</h3>
-<p><b>Section:</b> 20.6.6.2.10 [util.smartptr.getdeleter], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+<p><b>Section:</b> 20.6.6.2.11 [util.smartptr.getdeleter], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
<b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.getdeleter">issues</a> in [util.smartptr.getdeleter].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
@@ -21147,7 +21550,7 @@ instances). We should say which it is.
<p><b>Proposed resolution:</b></p>
<p>
-Add after the first sentence of 20.6.6.2.10 [util.smartptr.getdeleter]/1:
+Add after the first sentence of 20.6.6.2.11 [util.smartptr.getdeleter]/1:
</p>
<blockquote>
<p>
@@ -21166,6 +21569,108 @@ This can happen if the implementation doesn't destroy the deleter until all
<hr>
+<h3><a name="551"></a>551. &lt;ccomplex&gt;</h3>
+<p><b>Section:</b> 26.3.11 [cmplxh], TR1 8.3 [tr.c99.cmplxh] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-01-23</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Previously xxx.h was parsable by C++. But in the case of C99's &lt;complex.h&gt;
+it isn't. Otherwise we could model it just like &lt;string.h&gt;, &lt;cstring&gt;, &lt;string&gt;:
+</p>
+
+<ul>
+<li>&lt;string&gt; : C++ API in namespace std</li>
+<li>&lt;cstring&gt; : C API in namespace std</li>
+<li>&lt;string.h&gt; : C API in global namespace</li>
+</ul>
+
+<p>
+In the case of C's complex, the C API won't compile in C++. So we have:
+</p>
+
+<ul>
+<li>&lt;complex&gt; : C++ API in namespace std</li>
+<li>&lt;ccomplex&gt; : ?</li>
+<li>&lt;complex.h&gt; : ?</li>
+</ul>
+
+<p>
+The ? can't refer to the C API. TR1 currently says:
+</p>
+
+<ul>
+<li>&lt;complex&gt; : C++ API in namespace std</li>
+<li>&lt;ccomplex&gt; : C++ API in namespace std</li>
+<li>&lt;complex.h&gt; : C++ API in global namespace</li>
+</ul>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 26.3.11 [cmplxh]:
+</p>
+
+<blockquote>
+<p>
+The header behaves as if it includes the header
+<tt>&lt;ccomplex&gt;</tt><ins>.</ins><del>, and provides sufficient using
+declarations to declare in the global namespace all function and type names
+declared or defined in the neader <tt>&lt;complex&gt;</tt>.</del>
+<ins>[<i>Note:</i> <tt>&lt;complex.h&gt;</tt> does not promote any interface
+into the global namespace as there is no C interface to promote. <i>--end
+note</i>]</ins>
+</p>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="552"></a>552. random_shuffle and its generator</h3>
+<p><b>Section:</b> 25.2.12 [alg.random.shuffle] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-01-25</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+...is specified to shuffle its range by calling swap but not how
+(or even that) it's supposed to use the RandomNumberGenerator
+argument passed to it.
+</p>
+<p>
+Shouldn't we require that the generator object actually be used
+by the algorithm to obtain a series of random numbers and specify
+how many times its operator() should be invoked by the algorithm?
+</p>
+
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for some further discussion.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Adopt the proposed resolution in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
+</p>
+
+
+<p><i>[
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]</i></p>
+
+
+
+
+
+<hr>
<h3><a name="559"></a>559. numeric_limits&lt;const T&gt;</h3>
<p><b>Section:</b> 18.2.1 [limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
<b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-19</p>
@@ -21241,6 +21746,78 @@ automatically.
<hr>
+<h3><a name="566"></a>566. array forms of unformatted input function undefined for zero-element arrays</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#WP">WP</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#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#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+ <p>
+
+The array forms of unformatted input functions don't have well-defined
+semantics for zero-element arrays in a couple of cases. The affected
+ones (<tt>istream::get()</tt> and <tt>getline()</tt>) are supposed to
+terminate when <tt>(n - 1)</tt> characters are stored, which obviously
+can never be true when <tt>(n == 0)</tt> to start with.
+
+ </p>
+
+
+<p><b>Proposed resolution:</b></p>
+ <p>
+
+I propose the following changes (references are relative to the
+Working Draft (document N1804).
+
+ </p>
+ <p>
+
+Change 27.6.1.3, p8 (<tt>istream::get()</tt>), bullet 1 as follows:
+
+ </p>
+ <blockquote>
+ <p>
+
+<ins>if <tt>(n &lt; 1)</tt> is true or </ins> <tt>(n - 1)</tt>
+characters are stored;
+
+ </p>
+ </blockquote>
+ <p>
+
+Similarly, change 27.6.1.3, p18 (<tt>istream::getline()</tt>), bullet
+3 as follows:
+
+ </p>
+ <blockquote>
+ <p>
+
+<ins><tt>(n &lt; 1)</tt> is true or </ins><tt>(n - 1)</tt> characters
+are stored (in which case the function calls
+<tt>setstate(failbit)</tt>).
+
+ </p>
+ </blockquote>
+ <p>
+
+Finally, change p21 as follows:
+
+ </p>
+ <blockquote>
+ <p>
+
+In any case, <ins>provided <tt>(n &gt; 0)</tt> is true, </ins>it then
+stores a null character (using charT()) into the next successive
+location of the array.
+
+ </p>
+ </blockquote>
+
+
+
+
+
+<hr>
<h3><a name="575"></a>575. the specification of ~shared_ptr is MT-unfriendly, makes implementation assumptions</h3>
<p><b>Section:</b> 20.6.6.2.2 [util.smartptr.shared.dest], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
<b>Submitter:</b> Peter Dimov <b>Date:</b> 2006-04-23</p>
@@ -21372,6 +21949,56 @@ template&lt;class <del>ForwardIterator1</del><ins>InputIterator1</ins>, class Fo
<hr>
+<h3><a name="577"></a>577. upper_bound(first, last, ...) cannot return last</h3>
+<p><b>Section:</b> 25.3.3.2 [upper.bound] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Seungbeom Kim <b>Date:</b> 2006-05-03</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+ISO/IEC 14882:2003 says:
+</p>
+
+<blockquote>
+<p>
+25.3.3.2 upper_bound
+</p>
+<p>
+<i>Returns:</i> The furthermost iterator <tt>i</tt> in the range
+<tt>[<i>first</i>, <i>last</i>)</tt> such that
+for any iterator <tt>j</tt> in the range <tt>[<i>first</i>, i)</tt> the following corresponding
+conditions hold: <tt>!(value &lt; *j)</tt> or <tt><i>comp</i>(<i>value</i>, *j) == false</tt>.
+</p>
+</blockquote>
+
+<p>
+From the description above, upper_bound cannot return last, since it's
+not in the interval [first, last). This seems to be a typo, because if
+value is greater than or equal to any other values in the range, or if
+the range is empty, returning last seems to be the intended behaviour.
+The corresponding interval for lower_bound is also [first, last].
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change [lib.upper.bound]:
+</p>
+
+<blockquote>
+<p>
+<i>Returns:</i> The furthermost iterator <tt>i</tt> in the range
+<tt>[<i>first</i>, <i>last</i><del>)</del><ins>]</ins></tt> such that
+for any iterator <tt>j</tt> in the range <tt>[<i>first</i>, i)</tt> the following corresponding
+conditions hold: <tt>!(value &lt; *j)</tt> or <tt><i>comp</i>(<i>value</i>, *j) == false</tt>.
+</p>
+</blockquote>
+
+
+
+
+
+
+<hr>
<h3><a name="578"></a>578. purpose of hint to allocator::allocate()</h3>
<p><b>Section:</b> 20.6.1.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
<b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-05-17</p>
@@ -21682,4 +22309,1976 @@ Change the <b>Returns:</b> clause in 3.2.2.4 to:
Change the <b>Returns:</b> clause in 3.2.3.4 to:
</p>
<blockquote><p>
-<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <code>llroundd64(*this)</code> <ins>while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code></ins></p></blockquote></body></html> \ No newline at end of file
+<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <code>llroundd64(*this)</code> <ins>while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
+</p></blockquote>
+<p>
+Change the <b>Returns:</b> clause in 3.2.4.4 to:
+</p>
+<blockquote><p>
+<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <del><code>llroundd64(*this)</code></del> <ins><code>llroundd128(*this)</code> while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
+</p></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="599"></a>599. Decimal: Say "octets" instead of "bytes."</h3>
+<p><b>Section:</b> TRDecimal 3.1 [trdec.types.encodings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
+ <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Daniel writes in a private email:
+</p>
+
+<blockquote>
+<p>
+- 3.1 'Decimal type encodings' says in its note:
+</p>
+<pre>"this implies that
+sizeof(std::decimal::decimal32) == 4,
+sizeof(std::decimal::decimal64) == 8, and
+sizeof(std::decimal::decimal128) == 16."
+</pre>
+<p>
+This is a wrong assertion, because the definition
+of 'byte' in 1.7 'The C+ + memory model' of ISO
+14882 (2nd edition) does not specify that a byte
+must be necessarily 8 bits large, which would be
+necessary to compare with the specified bit sizes
+of the types decimal32, decimal64, and decimal128.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 3.1 as follows:
+</p>
+<blockquote>
+<p>
+The three decimal encoding formats defined in IEEE-754R correspond to the three decimal floating types as follows:
+</p>
+<ul>
+<li>
+decimal32 is a <em>decimal32</em> number, which is encoded in four consecutive <del>bytes</del> <ins>octets</ins> (32 bits)
+</li>
+<li>
+decimal64 is a <em>decimal64</em> number, which is encoded in eight consecutive <del>bytes</del> <ins>octets</ins> (64 bits)
+
+</li>
+<li>
+decimal128 is a <em>decimal128</em> number, which is encoded in 16 consecutive <del>bytes</del> <ins>octets</ins> (128 bits)
+</li>
+</ul>
+<p>
+<del>[<i>Note:</i> this implies that <code>sizeof(std::decimal::decimal32) == 4</code>, <code>sizeof(std::decimal::decimal64) == 8</code>, and <code>sizeof(std::decimal::decimal128) == 16</code>. <i>--end note</i>]</del>
+</p>
+</blockquote>
+
+
+
+
+<hr>
+<h3><a name="600"></a>600. Decimal: Wrong parameters for wcstod* functions</h3>
+<p><b>Section:</b> TRDecimal 3.9 [trdec.types.cwchar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
+ <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Daniel writes:
+</p>
+<blockquote><p>
+- 3.9.1 'Additions to &lt;cwchar&gt;' provides wrong
+signatures to the wcstod32, wcstod64, and
+wcstod128 functions ([the parameters have type pointer-to-] char instead of wchar_t).
+</p></blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change "3.9.1 Additions to <code>&lt;cwchar&gt;</code> synopsis" to:
+</p>
+<pre> namespace std {
+ namespace decimal {
+ // 3.9.2 wcstod functions:
+ decimal32 wcstod32 (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr);
+ decimal64 wcstod64 (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr);
+ decimal128 wcstod128 (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr);
+ }
+ }
+</pre>
+
+
+
+
+<hr>
+<h3><a name="601"></a>601. Decimal: numeric_limits typos</h3>
+<p><b>Section:</b> TRDecimal 3.3 [trdec.types.limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
+ <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Daniel writes in a private email:
+</p>
+
+<blockquote>
+<p>
+- 3.3 'Additions to header &lt;limits&gt;' contains two
+errors in the specialisation of numeric_limits&lt;decimal::decimal128&gt;:
+</p>
+<ol>
+<li>The static member max() returns DEC128_MIN, this should be DEC128_MAX.</li>
+<li>The static member digits is assigned to 384,
+this should be 34 (Probably mixed up with the
+max. exponent for decimal::decimal64).</li>
+</ol>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In "3.3 Additions to header <code>&lt;limits&gt;</code>" change numeric_limits&lt;decimal::decimal128&gt; as follows:
+</p>
+<pre> template&lt;&gt; class numeric_limits&lt;decimal::decimal128&gt; {
+ public:
+ static const bool is_specialized = true;
+
+ static decimal::decimal128 min() throw() { return DEC128_MIN; }
+ static decimal::decimal128 max() throw() { return <del>DEC128_MIN;</del> <ins>DEC128_MAX;</ins> }
+
+ static const int digits = <del>384</del> <ins>34</ins>;
+ /* ... */
+</pre>
+
+
+
+
+<hr>
+<h3><a name="602"></a>602. Decimal: "generic floating type" not defined.</h3>
+<p><b>Section:</b> TRDecimal 3 [trdec.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
+ <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types">issues</a> in [trdec.types].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The document uses the term "generic floating types," but defines it nowhere.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the first paragraph of "3 Decimal floating-point types" as follows:
+</p>
+<blockquote><p>
+This Technical Report introduces three decimal floating-point types, named
+decimal32, decimal64, and decimal128. The set of values of type decimal32 is a
+subset of the set of values of type decimal64; the set of values of the type
+decimal64 is a subset of the set of values of the type decimal128. Support for
+decimal128 is optional. <ins>These types supplement the Standard C++ types
+<code>float</code>, <code>double</code>, and <code>long double</code>, which are
+collectively described as the <i>basic floating types</i></ins>.
+</p></blockquote>
+
+
+
+
+<hr>
+<h3><a name="603"></a>603. Decimal: Trivially simplifying decimal classes.</h3>
+<p><b>Section:</b> TRDecimal 3 [trdec.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-05-28</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types">issues</a> in [trdec.types].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>In c++std-lib-17198, Martin writes:</p>
+
+<blockquote><p>
+Each of the three classes proposed in the paper (decimal32, decimal64,
+and decimal128) explicitly declares and specifies the semantics of its
+copy constructor, copy assignment operator, and destructor. Since the
+semantics of all three functions are identical to the trivial versions
+implicitly generated by the compiler in the absence of any declarations
+it is safe to drop them from the spec. This change would make the
+proposed classes consistent with other similar classes already in the
+standard (e.g., std::complex).
+</p></blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change "3.2.2 Class <code>decimal32</code>" as follows:
+</p>
+<pre> namespace std {
+ namespace decimal {
+ class decimal32 {
+ public:
+ // 3.2.2.1 construct/copy/destroy:
+ decimal32();
+ <del>decimal32(const decimal32 &amp; d32);</del>
+ <del>decimal32 &amp; operator=(const decimal32 &amp; d32);</del>
+ <del>~decimal32();</del>
+ /* ... */
+</pre>
+<p>
+Change "3.2.2.1 construct/copy/destroy" as follows:
+</p>
+<pre> decimal32();
+
+ Effects: Constructs an object of type decimal32 with the value 0;
+
+ <del>decimal32(const decimal32 &amp; d32);</del>
+ <del>decimal32 &amp; operator=(const decimal32 &amp; d32);</del>
+
+ <del>Effects: Copies an object of type decimal32.</del>
+
+ <del>~decimal32();</del>
+
+ <del>Effects: Destroys an object of type decimal32.</del>
+
+</pre>
+<p>
+Change "3.2.3 Class <code>decimal64</code>" as follows:
+</p>
+<pre> namespace std {
+ namespace decimal {
+ class decimal64 {
+ public:
+ // 3.2.3.1 construct/copy/destroy:
+ decimal64();
+ <del>decimal64(const decimal64 &amp; d64);</del>
+ <del>decimal64 &amp; operator=(const decimal64 &amp; d64);</del>
+ <del>~decimal64();</del>
+ /* ... */
+</pre>
+<p>
+Change "3.2.3.1 construct/copy/destroy" as follows:
+</p>
+<pre> decimal64();
+
+ Effects: Constructs an object of type decimal64 with the value 0;
+
+ <del>decimal64(const decimal64 &amp; d64);</del>
+ <del>decimal64 &amp; operator=(const decimal64 &amp; d64);</del>
+
+ <del>Effects: Copies an object of type decimal64.</del>
+
+ <del>~decimal64();</del>
+
+ <del>Effects: Destroys an object of type decimal64.</del>
+
+</pre>
+<p>
+Change "3.2.4 Class <code>decimal128</code>" as follows:
+</p>
+<pre> namespace std {
+ namespace decimal {
+ class decimal128 {
+ public:
+ // 3.2.4.1 construct/copy/destroy:
+ decimal128();
+ <del>decimal128(const decimal128 &amp; d128);</del>
+ <del>decimal128 &amp; operator=(const decimal128 &amp; d128);</del>
+ <del>~decimal128();</del>
+ /* ... */
+</pre>
+<p>
+Change "3.2.4.1 construct/copy/destroy" as follows:
+</p>
+<pre> decimal128();
+
+ Effects: Constructs an object of type decimal128 with the value 0;
+
+ <del>decimal128(const decimal128 &amp; d128);</del>
+ <del>decimal128 &amp; operator=(const decimal128 &amp; d128);</del>
+
+ <del>Effects: Copies an object of type decimal128.</del>
+
+ <del>~decimal128();</del>
+
+ <del>Effects: Destroys an object of type decimal128.</del>
+
+</pre>
+
+
+
+
+<hr>
+<h3><a name="604"></a>604. Decimal: Storing a reference to a facet unsafe.</h3>
+<p><b>Section:</b> TRDecimal 3 [trdec.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-05-28</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types">issues</a> in [trdec.types].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In c++std-lib-17197, Martin writes:
+</p>
+<blockquote><p>
+The extended_num_get and extended_num_put facets are designed
+to store a reference to a num_get or num_put facet which the
+extended facets delegate the parsing and formatting of types
+other than decimal. One form of the extended facet's ctor (the
+default ctor and the size_t overload) obtains the reference
+from the global C++ locale while the other form takes this
+reference as an argument.
+</p></blockquote>
+<blockquote><p>
+The problem with storing a reference to a facet in another
+object (as opposed to storing the locale object in which the
+facet is installed) is that doing so bypasses the reference
+counting mechanism designed to prevent a facet that is still
+being referenced (i.e., one that is still installed in some
+locale) from being destroyed when another locale that contains
+it is destroyed. Separating a facet reference from the locale
+it comes from van make it cumbersome (and in some cases might
+even make it impossible) for programs to prevent invalidating
+the reference. (The danger of this design is highlighted in
+the paper.)
+</p></blockquote>
+<blockquote><p>
+This problem could be easily avoided by having the extended
+facets store a copy of the locale from which they would extract
+the base facet either at construction time or when needed. To
+make it possible, the forms of ctors of the extended facets that
+take a reference to the base facet would need to be changed to
+take a locale argument instead.
+</p></blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+1. Change the <code>extended_num_get</code> synopsis in 3.10.2 as follows:
+</p>
+<pre> extended_num_get(const <del>std::num_get&lt;charT, InputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
+
+ /* ... */
+
+ <del>// <i>const std::num_get&lt;charT, InputIterator&gt; &amp; <b>base</b></i>; <i><b>exposition only</b></i></del>
+ <ins>// <i>std::locale <b>baseloc</b></i>; <i><b>exposition only</b></i></ins>
+</pre>
+<p>
+2. Change the description of the above constructor in 3.10.2.1:
+</p>
+<pre> extended_num_get(const <del>std::num_get&lt;charT, InputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
+
+</pre>
+<blockquote>
+<p>
+<b>Effects:</b> Constructs an <code>extended_num_get</code> facet as if by:
+</p>
+<pre> extended_num_get(const <del>std::num_get&lt;charT, InputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0)
+ : facet(<i>refs</i>), <i>base<ins>loc</ins></i>(<i>b</i>)
+ { /* ... */ }
+
+</pre>
+<p>
+<del><b>Notes:</b> Care must be taken by the implementation to ensure that the lifetime of the facet referenced by <i>base</i> exceeds that of the resulting <code>extended_num_get</code> facet.</del>
+</p>
+</blockquote>
+<p>
+3. Change the <b>Returns:</b> clause for <code>do_get(iter_type, iter_type, ios_base &amp;, ios_base::iostate &amp;, bool &amp;) const</code>, <i>et al</i> to
+</p>
+<blockquote><p>
+<b>Returns:</b> <code><del><i>base</i></del> <ins>std::use_facet&lt;std::num_get&lt;charT, InputIterator&gt; &gt;(<i>baseloc</i>)</ins>.get(<i>in</i>, <i>end</i>, <i>str</i>, <i>err</i>, <i>val</i>)</code>.
+</p></blockquote>
+<p>
+4. Change the <code>extended_num_put</code> synopsis in 3.10.3 as follows:
+</p>
+<pre> extended_num_put(const <del>std::num_put&lt;charT, OutputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
+
+ /* ... */
+
+ <del>// <i>const std::num_put&lt;charT, OutputIterator&gt; &amp; <b>base</b></i>; <i><b>exposition only</b></i></del>
+ <ins>// <i>std::locale <b>baseloc</b></i>; <i><b>exposition only</b></i></ins>
+</pre>
+<p>
+5. Change the description of the above constructor in 3.10.3.1:
+</p>
+<pre> extended_num_put(const <del>std::num_put&lt;charT, OutputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
+</pre>
+<blockquote>
+<p>
+<b>Effects:</b> Constructs an <code>extended_num_put</code> facet as if by:
+</p>
+<pre> extended_num_put(const <del>std::num_put&lt;charT, OutputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0)
+ : facet(<i>refs</i>), <i>base<ins>loc</ins></i>(<i>b</i>)
+ { /* ... */ }
+
+</pre>
+<p>
+<del><b>Notes:</b> Care must be taken by the implementation to ensure that the lifetime of the facet referenced by <i>base</i> exceeds that of the resulting <code>extended_num_put</code> facet.</del>
+</p>
+</blockquote>
+<p>
+6. Change the <b>Returns:</b> clause for <code>do_put(iter_type, ios_base &amp;, char_type, bool &amp;) const</code>, <i>et al</i> to
+</p>
+<blockquote><p>
+<b>Returns:</b> <code><del><i>base</i></del> <ins>std::use_facet&lt;std::num_put&lt;charT, OutputIterator&gt; &gt;(<i>baseloc</i>)</ins>.put(<i>s</i>, <i>f</i>, <i>fill</i>, <i>val</i>)</code>.
+</p></blockquote>
+
+<p><i>[
+Redmond: We would prefer to rename "extended" to "decimal".
+]</i></p>
+
+
+
+
+
+
+<hr>
+<h3><a name="605"></a>605. Decimal: &lt;decfloat.h&gt; doesn't live here anymore.</h3>
+<p><b>Section:</b> TRDecimal 3.4 [trdec.types.cdecfloat] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
+ <b>Submitter:</b> Robert Klarer <b>Date:</b> 2006-10-17</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In Berlin, WG14 decided to drop the &lt;decfloat.h&gt; header. The
+contents of that header have been moved into &lt;float.h&gt;. For the
+sake of C compatibility, we should make corresponding changes.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+1. Change the heading of subclause 3.4, "Headers <code>&lt;cdecfloat&gt;</code> and <code>&lt;decfloat.h&gt;</code>" to "Additions to headers <code>&lt;cfloat&gt;</code> and <code>&lt;float.h&gt;</code>."
+</p>
+<p>
+2. Change the text of subclause 3.4 as follows:
+</p>
+<blockquote>
+<p>
+<del>The standard C++ headers <code>&lt;cfloat&gt;</code> and <code>&lt;float.h&gt;</code> define characteristics of the floating-point types <code>float</code>, <code>double</code>, and <code>long double</code>. Their contents remain unchanged by this Technical Report.</del>
+</p>
+<p>
+<del>Headers <code>&lt;cdecfloat&gt;</code> and <code>&lt;decfloat.h&gt;</code> define characteristics of the decimal floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>. As well, <code>&lt;decfloat.h&gt;</code> defines the convenience typedefs <code>_Decimal32</code>, <code>_Decimal64</code>, and <code>_Decimal128</code>, for compatibilty with the C programming language.</del>
+</p>
+<p>
+<ins>The header <code>&lt;cfloat&gt;</code> is described in [tr.c99.cfloat]. The header <code>&lt;float.h&gt;</code>
+is described in [tr.c99.floath]. These headers are extended by this
+Technical Report to define characteristics of the decimal
+floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>. As well, <code>&lt;float.h&gt;</code> is extended to define the convenience typedefs <code>_Decimal32</code>, <code>_Decimal64</code>, and <code>_Decimal128</code> for compatibility with the C programming language.</ins>
+</p>
+</blockquote>
+<p>
+3. Change the heading of subclause 3.4.1, "Header <code>&lt;cdecfloat&gt;</code> synopsis" to "Additions to header <code>&lt;cfloat&gt;</code> synopsis."
+</p>
+<p>
+4. Change the heading of subclause 3.4.2, "Header <code>&lt;decfloat.h&gt;</code> synopsis" to "Additions to header <code>&lt;float.h&gt;</code> synopsis."
+</p>
+<p>
+5. Change the contents of 3.4.2 as follows:
+</p>
+<pre> <del>#include &lt;cdecfloat&gt;</del>
+
+ // <i>C-compatibility convenience typedefs:</i>
+
+ typedef std::decimal::decimal32 _Decimal32;
+ typedef std::decimal::decimal64 _Decimal64;
+ typedef std::decimal::decimal128 _Decimal128;
+</pre>
+
+
+
+
+
+<hr>
+<h3><a name="607"></a>607. Concern about short seed vectors</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#WP">Pending WP</a>
+ <b>Submitter:</b> Charles Karney <b>Date:</b> 2006-10-26</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#Pending%20WP">Pending WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Short seed vectors of 32-bit quantities all result in different states. However
+this is not true of seed vectors of 16-bit (or smaller) quantities. For example
+these two seeds
+</p>
+
+<blockquote><pre>unsigned short seed = {1, 2, 3};
+unsigned short seed = {1, 2, 3, 0};
+</pre></blockquote>
+
+<p>
+both pack to
+</p>
+
+<blockquote><pre>unsigned seed = {0x20001, 0x3};
+</pre></blockquote>
+
+<p>
+yielding the same state.
+</p>
+
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for some further discussion.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Adopt the proposed resolution in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
+</p>
+
+
+<p><i>[
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="608"></a>608. Unclear seed_seq construction details</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#WP">Pending WP</a>
+ <b>Submitter:</b> Charles Karney <b>Date:</b> 2006-10-26</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#Pending%20WP">Pending WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In 26.4.7.1 [rand.util.seedseq] /6, the order of packing the inputs into b and the
+treatment of signed quantities is unclear. Better to spell it out.
+</p>
+
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for some further discussion.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Adopt the proposed resolution in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
+</p>
+
+
+<p><i>[
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="609"></a>609. missing static const</h3>
+<p><b>Section:</b> 26.4.4.2 [rand.adapt.ibits], TR1 5.1 [tr.rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Walter E. Brown <b>Date:</b> 2006-11-02</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In preparing N2111, an error on my part resulted in the omission of the
+following line from the template synopsis in the cited section:
+</p>
+
+<blockquote><pre>static const size_t word_size = w;
+</pre></blockquote>
+
+<p>
+(This same constant is found, for example, in 26.4.3.3 [rand.eng.sub].)
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the above declaration as the first line after the comment in [rand.adapt.ibits] p4:
+</p>
+
+<blockquote><pre>// engine characteristics
+<ins>static const size_t word_size = w;</ins>
+</pre></blockquote>
+
+<p>
+and accept my apologies for the oversight.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="610"></a>610. Suggested non-normative note for C++0x</h3>
+<p><b>Section:</b> 20.5.15.2.1 [func.wrap.func.con], TR1 3.7.2.1 [tr.func.wrap.func.con] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Scott Meyers <b>Date:</b> 2006-11-02</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+My suggestion is that implementers of both tr1::function and its
+official C++0x successor be explicitly encouraged (but not required) to
+optimize for the cases mentioned above, i.e., function pointers and
+small function objects. They could do this by using a small internal
+buffer akin to the buffer used by implementations of the small string
+optimization. (That would make this the small functor optimization --
+SFO :-}) The form of this encouragement could be a note in the standard
+akin to footnote 214 of the current standard.
+</p>
+
+<p>
+Dave Abrahams notes:
+</p>
+
+<p>
+"shall not throw exceptions" should really be "nothing," both to be more
+grammatical and to be consistent with existing wording in the standard.
+</p>
+
+<p>
+Doug Gregor comments: I think this is a good idea. Currently, implementations of
+tr1::function are required to have non-throwing constructors and assignment
+operators when the target function object is a function pointer or a
+reference_wrapper. The common case, however, is for a tr1::function to store
+either an empty function object or a member pointer + an object pointer.
+</p>
+<p>
+The function implementation in the upcoming Boost 1.34.0 uses the
+"SFO", so that the function objects for typical bind expressions like
+</p>
+<blockquote><pre>bind(&amp;X::f, this, _1, _2, _3)
+</pre></blockquote>
+
+<p>
+do not require heap allocation when stored in a boost::function. I
+believe Dinkumware's implementation also performs this optimization.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Revise 20.5.14.2.1 p6 [func.wrap.func.con] to add a note as follows:
+</p>
+
+<blockquote>
+<p>
+<i>Throws:</i> shall not throw exceptions if <tt>f</tt>'s target is a function
+pointer or a function object passed via <tt>reference_wrapper</tt>. Otherwise,
+may throw <tt>bad_alloc</tt> or any exception thrown by the copy constructor of
+the stored function object.
+</p>
+<p>
+<ins><i>Note:</i> Implementations are encouraged to avoid the use of dynamically
+allocated memory for "small" function objects, e.g., where <tt>f</tt>'s target
+is an object holding only a pointer or reference to an object and a member
+function pointer (a "bound member function").</ins>
+</p>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="611"></a>611. Standard library templates and incomplete types</h3>
+<p><b>Section:</b> 17.4.3.6 [res.on.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Nicola Musatti <b>Date:</b> 2006-11-13</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In the latest available draft standard
+(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>)
+§ 17.4.3.6 [res.on.functions] states:
+</p>
+
+<blockquote>
+<p>
+-1- In certain cases (replacement functions, handler functions, operations on
+types used to instantiate standard library template components), the C++
+Standard Library depends on components supplied by a C++ program. If these
+components do not meet their requirements, the Standard places no requirements
+on the implementation.
+</p>
+
+<p>
+-2- In particular, the effects are undefined in the following cases:
+</p>
+<p>
+[...]
+</p>
+<ul>
+<li>if an incomplete type (3.9) is used as a template argument when
+instantiating a template component. </li>
+</ul>
+</blockquote>
+
+<p>
+This is contradicted by § 20.6.6.2/2 [util.smartptr.shared] which
+states:
+</p>
+
+<blockquote>
+<p>
+[...]
+</p>
+
+<p>
+The template parameter <tt>T</tt> of <tt>shared_ptr</tt> may be an incomplete type.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Modify the last bullet of § 17.4.3.6/2 [res.on.functions] to allow for
+exceptions:
+</p>
+
+<blockquote>
+<ul>
+<li>if an incomplete type (3.9) is used as a template argument when
+instantiating a template component<ins>, unless specifically allowed for the
+component</ins>. </li>
+</ul>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="613"></a>613. max_digits10 missing from numeric_limits</h3>
+<p><b>Section:</b> 18.2.1.5 [numeric.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-11-20</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.special">issues</a> in [numeric.special].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Section 18.2.1.5 [numeric.special] starts out by saying that "All members shall be provided
+for all specializations."
+</p>
+<p>
+Then it goes on to show specializations for float and bool, where one member
+is missing (max_digits10).
+</p>
+
+<p>
+Maarten Kronenburg adds:
+</p>
+
+<p>
+I agree, just adding the comment that the exact number of decimal digits
+is digits * ln(radix) / ln(10), where probably this real number is
+rounded downward for digits10, and rounded upward for max_digits10
+(when radix=10, then digits10=max_digits10).
+Why not add this exact definition also to the standard, so the user
+knows what these numbers exactly mean.
+</p>
+
+<p>
+Howard adds:
+</p>
+
+<p>
+For reference, here are the correct formulas from
+<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1822.pdf">N1822</a>:
+</p>
+
+<blockquote><pre>digits10 = floor((digits-1) * log10(2))
+max_digits10 = ceil((1 + digits) * log10(2))
+</pre></blockquote>
+
+<p>
+We are also missing a statement regarding for what specializations this member has meaning.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change and add after 18.2.1.2 [numeric.limits.members], p11:
+</p>
+
+<blockquote>
+<pre>static const int max_digits10;</pre>
+<blockquote>
+<p>
+-11- Number of base 10 digits required to ensure that values which
+differ <del>by only one epsilon</del> are always differentiated.
+</p>
+<p><ins>
+-12- Meaningful for all floating point types.
+</ins></p>
+</blockquote>
+</blockquote>
+
+<p>
+Change 18.2.1.5 [numeric.special], p2:
+</p>
+
+<blockquote><pre>template&lt;&gt; class numeric_limits&lt;float&gt; {
+public:
+ static const bool is_specialized = true;
+ ...
+ static const int digits10 = 6;
+ <ins>static const int max_digits10 = 9</ins>;
+ ...
+</pre></blockquote>
+
+<p>
+Change 18.2.1.5 [numeric.special], p3:
+</p>
+
+<blockquote><pre>template&lt;&gt; class numeric_limits&lt;bool&gt; {
+public:
+ static const bool is_specialized = true;
+ ...
+ static const int digits10 = 0;
+ <ins>static const int max_digits10 = 0</ins>;
+ ...
+</pre></blockquote>
+
+
+
+
+
+
+
+<hr>
+<h3><a name="616"></a>616. missing 'typename' in ctype_byname</h3>
+<p><b>Section:</b> 22.2.1.2 [locale.ctype.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-16</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.byname">issues</a> in [locale.ctype.byname].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Section 22.2.1.2 defines the ctype_byname class template. It contains the
+line
+</p>
+
+<blockquote><pre>typedef ctype&lt;charT&gt;::mask mask;
+</pre></blockquote>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+as this is a dependent type, it should obviously be
+</p>
+
+<blockquote><pre>typedef <ins>typename</ins> ctype&lt;charT&gt;::mask mask;
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="619"></a>619. Longjmp wording problem</h3>
+<p><b>Section:</b> 18.8 [support.runtime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2007-01-12</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The wording for <tt>longjmp</tt> is confusing.
+</p>
+<p>
+18.8 [support.runtime] -4- Other runtime support
+</p>
+<blockquote><p>
+The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more restricted
+behavior in this International Standard. If any automatic objects would
+be destroyed by a thrown exception transferring control to another
+(destination) point in the program, then a call to <tt>longjmp(jbuf, val)</tt> that
+the throw point that transfers control to the same (destination) point has
+undefined behavior.
+</p></blockquote>
+<p>
+Someone at Google thinks that should say "then a call to <tt>longjmp(jbuf, val)</tt>
+*at* the throw point that transfers control".
+</p>
+<p>
+Bill Gibbons thinks it should say something like "If any automatic objects
+would be destroyed by an exception thrown at the point of the longjmp and
+caught only at the point of the setjmp, the behavior is undefined."
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In general, accept Bill Gibbons' recommendation,
+but add "call" to indicate that the undefined behavior
+comes from the dynamic call, not from its presence in the code.
+In 18.8 [support.runtime] paragraph 4, change
+</p>
+
+<blockquote><p>
+The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more
+restricted behavior in this International Standard. <del>If any automatic
+objects would be destroyed by a thrown exception transferring control to another
+(destination) point in the program, then a call to <tt>longjmp(jbuf, val)</tt>
+that the throw point that transfers control to the same (destination) point has
+undefined behavior.</del> <ins>A <tt>setjmp</tt>/<tt>longjmp</tt> call pair has
+undefined behavior if replacing the <tt>setjmp</tt> and <tt>longjmp</tt> by
+<tt>catch</tt> and <tt>throw</tt> would destroy any automatic objects.</ins>
+</p></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="628"></a>628. Inconsistent definition of basic_regex constructor</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#WP">WP</a>
+ <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-01-23</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#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Section 28.8 [re.regex] lists a constructor
+</p>
+
+<blockquote><pre>template&lt;class InputIterator&gt;
+basic_regex(InputIterator first, InputIterator last,
+ flag_type f = regex_constants::ECMAScript);
+</pre></blockquote>
+
+<p>
+However, in section 28.8.2 [re.regex.construct], this constructor takes a
+pair of <tt>ForwardIterator</tt>.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 28.8.2 [re.regex.construct]:
+</p>
+
+<blockquote><pre>template &lt;class <del>ForwardIterator</del> <ins>InputIterator</ins>&gt;
+ basic_regex(<del>ForwardIterator</del> <ins>InputIterator</ins> first, <del>ForwardIterator</del> <ins>InputIterator</ins> last,
+ flag_type f = regex_constants::ECMAScript);
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="634"></a>634. <tt>allocator.address()</tt> doesn't work for types overloading <tt>operator&amp;</tt></h3>
+<p><b>Section:</b> 20.6.1.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-02-07</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a></p>
+<p><b>Discussion:</b></p>
+
+<p>
+20.6.1.1 [allocator.members] says:
+</p>
+<blockquote>
+<pre>pointer address(reference <i>x</i>) const;</pre>
+<blockquote>
+<p>
+-1- <i>Returns:</i> <tt>&amp;<i>x</i></tt>.
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+20.6.1.1 [allocator.members] defines <tt>CopyConstructible</tt> which currently not
+only defines the semantics of copy construction, but also restricts what an overloaded
+<tt>operator&amp;</tt> may do. I believe proposals are in the works (such as concepts
+and rvalue reference) to decouple these two requirements. Indeed it is not evident
+that we should disallow overloading <tt>operator&amp;</tt> to return something other
+than the address of <tt>*this</tt>.
+</p>
+
+<p>
+An example of when you want to overload <tt>operator&amp;</tt> to return something
+other than the object's address is proxy references such as <tt>vector&lt;bool&gt;</tt>
+(or its replacement, currently code-named <tt>bit_vector</tt>). Taking the address of
+such a proxy reference should logically yield a proxy pointer, which when dereferenced,
+yields a copy of the original proxy reference again.
+</p>
+
+<p>
+On the other hand, some code truly needs the address of an object, and not a proxy
+(typically for determining the identity of an object compared to a reference object).
+<a href="http://www.boost.org/">boost</a> has long recognized this dilemma and solved it with
+<a href="http://www.boost.org/libs/utility/utility.htm#addressof"><tt>boost::addressof</tt></a>.
+It appears to me that this would be useful functionality for the default allocator. Adopting
+this definition for <tt>allocator::address</tt> would free the standard of requiring
+anything special from types which overload <tt>operator&amp;</tt>. Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a>
+is expected to make use of <tt>allocator::address</tt> mandatory for containers.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 20.6.1.1 [allocator.members]:
+</p>
+
+<blockquote>
+<pre>pointer address(reference <i>x</i>) const;</pre>
+<blockquote>
+<p>
+-1- <i>Returns:</i> <del><tt>&amp;<i>x</i></tt>.</del> <ins>The actual address of object referenced by <i>x</i>,
+even in the presence of an overloaded <tt>operator&amp;</tt>.</ins>
+</p>
+</blockquote>
+
+<pre>const_pointer address(address(const_reference <i>x</i>) const;</pre>
+<blockquote>
+<p>
+-2- <i>Returns:</i> <del><tt>&amp;<i>x</i></tt>.</del> <ins>The actual address of object referenced by <i>x</i>,
+even in the presence of an overloaded <tt>operator&amp;</tt>.</ins>
+</p>
+</blockquote>
+</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): The LWG adopted the proposed resolution of N2387 for this issue which
+was subsequently split out into a separate paper N2436 for the purposes of voting.
+The resolution in N2436 addresses this issue. The LWG voted to accelerate this
+issue to Ready status to be voted into the WP at Kona.
+]</i></p>
+
+
+
+
+
+
+
+<hr>
+<h3><a name="640"></a>640. 27.6.2.5.2 does not handle (unsigned) long long</h3>
+<p><b>Section:</b> 27.6.2.6.2 [ostream.inserters.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-17</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.inserters.arithmetic">issues</a> in [ostream.inserters.arithmetic].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The arithmetic inserters are described in 27.6.2.6.2 [ostream.inserters.arithmetic].
+Although the section starts with a listing of the inserters including
+the new ones:
+</p>
+
+<blockquote><pre>operator&lt;&lt;(long long val );
+operator&lt;&lt;(unsigned long long val );
+</pre></blockquote>
+
+<p>
+the text in paragraph 1, which describes the corresponding effects
+of the inserters, depending on the actual type of val, does not
+handle the types <tt>long long</tt> and <tt>unsigned long long</tt>.
+</p>
+
+<p><i>[
+Alisdair: In addition to the (unsigned) long long problem, that whole paragraph
+misses any reference to extended integral types supplied by the
+implementation - one of the additions by core a couple of working papers
+back.
+]</i></p>
+
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 27.6.2.6.2 [ostream.inserters.arithmetic]/1 change the third sentence
+</p>
+
+<blockquote>
+When val is of type <tt>bool</tt>, <tt>long</tt>, <tt>unsigned
+long</tt>, <ins>long long, unsigned long long,</ins> <tt>double</tt>,
+<tt>long double</tt>, or <tt>const void*</tt>, the formatting conversion
+occurs as if it performed the following code fragment:
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="643"></a>643. Impossible "as if" clauses</h3>
+<p><b>Section:</b> 27.8.1.1 [filebuf], 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#WP">WP</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-20</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The current standard 14882:2003(E) as well as N2134 have the
+following
+defects:
+</p>
+
+<p>
+27.8.1.1 [filebuf]/5 says:
+</p>
+
+<blockquote>
+<p>
+In order to support file I/O and multibyte/wide character conversion, conversions are performed using members of a
+facet, referred to as <tt><i>a_codecvt</i></tt> in following sections, obtained "as if" by
+</p>
+<blockquote><pre>codecvt&lt;charT,char,typename traits::state_type&gt; <i>a_codecvt</i> =
+ use_facet&lt;codecvt&lt;charT,char,typename traits::state_type&gt; &gt;(getloc());
+</pre></blockquote>
+</blockquote>
+
+<p>
+<tt>use_facet</tt> returns a <tt>const facet</tt> reference and no facet is
+copyconstructible, so the codecvt construction should fail to compile.
+</p>
+
+<p>
+A similar issue arises in 22.2.2.2.2 [facet.num.put.virtuals]/15 for <tt>num_punct</tt>.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 27.8.1.1 [filebuf]/5 change the "as if" code
+</p>
+
+<blockquote><pre><ins>const </ins>codecvt&lt;charT,char,typename traits::state_type&gt;<ins>&amp;</ins> <i>a_codecvt</i> =
+ use_facet&lt;codecvt&lt;charT,char,typename traits::state_type&gt; &gt;(getloc());
+</pre></blockquote>
+
+<p>
+In 22.2.2.2.2 [facet.num.put.virtuals]/15 (This is para 5 in N2134) change
+</p>
+
+<blockquote>
+<p>
+A local variable <tt><i>punct</i></tt> is initialized via
+</p>
+<blockquote><pre><ins>const </ins>numpunct&lt;charT&gt;<ins>&amp;</ins> <i>punct</i> = use_facet&lt; numpunct&lt;charT&gt; &gt;(<i>str</i>.getloc() )<ins>;</ins>
+</pre></blockquote>
+</blockquote>
+
+<p>
+(Please note also the additional provided trailing semicolon)
+</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#WP">Pending WP</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#Pending%20WP">Pending WP</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><b>Proposed resolution:</b></p>
+<p>
+Change 20.5.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="646"></a>646. const incorrect match_result members</h3>
+<p><b>Section:</b> 28.10.4 [re.results.form] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-26</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+28.10.4 [re.results.form] (root and para 3) in N2134 defines the two function template
+members format as non-const functions, although they are declared
+as const in 28.10 [re.results]/3.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the missing <tt>const</tt> specifier to both <tt>format</tt> overloads described
+in section 28.10.4 [re.results.form].
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="650"></a>650. regex_token_iterator and const correctness</h3>
+<p><b>Section:</b> 28.12.2 [re.tokiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-05</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.tokiter">issues</a> in [re.tokiter].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Both the class definition of regex_token_iterator (28.12.2
+[re.tokiter]/6) and the latter member specifications (28.12.2.2
+[re.tokiter.comp]/1+2) declare both comparison operators as
+non-const functions. Furtheron, both dereference operators are
+unexpectedly also declared as non-const in 28.12.2 [re.tokiter]/6
+as well as in (28.12.2.3 [re.tokiter.deref]/1+2).
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+1) In (28.12.2 [re.tokiter]/6) change the current declarations
+</p>
+
+<blockquote><pre>bool operator==(const regex_token_iterator&amp;) <ins>const</ins>;
+bool operator!=(const regex_token_iterator&amp;) <ins>const</ins>;
+const value_type&amp; operator*() <ins>const</ins>;
+const value_type* operator-&gt;() <ins>const</ins>;
+</pre></blockquote>
+
+<p>
+2) In 28.12.2.2 [re.tokiter.comp] change the following declarations
+</p>
+
+<blockquote><pre>bool operator==(const regex_token_iterator&amp; right) <ins>const</ins>;
+bool operator!=(const regex_token_iterator&amp; right) <ins>const</ins>;
+</pre></blockquote>
+
+<p>
+3) In 28.12.2.3 [re.tokiter.deref] change the following declarations
+</p>
+
+<blockquote><pre>const value_type&amp; operator*() <ins>const</ins>;
+const value_type* operator-&gt;() <ins>const</ins>;
+</pre></blockquote>
+
+
+<p><i>[
+Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
+is to adopt the proposed wording in this issue).
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="651"></a>651. Missing preconditions for regex_token_iterator c'tors</h3>
+<p><b>Section:</b> 28.12.2.1 [re.tokiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-05</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.tokiter.cnstr">issues</a> in [re.tokiter.cnstr].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The text provided in 28.12.2.1 [re.tokiter.cnstr]/2+3 describes
+the effects of the three non-default constructors of class
+template regex_token_iterator but is does not clarify which values
+are legal values for submatch/submatches. This becomes
+an issue, if one takes 28.12.2 [re.tokiter]/9 into account, which explains
+the notion of a "current match" by saying:
+</p>
+
+<blockquote><p>
+The <i>current match</i> is <tt>(*position).prefix()</tt> if <tt>subs[N]
+== -1</tt>, or <tt>(*position)[subs[N]]</tt> for any other value of
+<tt>subs[N]</tt>.
+</p></blockquote>
+
+<p>
+It's not clear to me, whether other negative values except -1
+are legal arguments or not - it seems they are not.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the following precondition paragraph just before the current
+28.12.2.1 [re.tokiter.cnstr]/2:
+</p>
+
+<blockquote><p>
+<i>Requires:</i> Each of the initialization values of <tt>subs</tt> must be <tt>&gt;= -1</tt>.
+</p></blockquote>
+
+
+<p><i>[
+Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
+is to adopt the proposed wording in this issue).
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="652"></a>652. regex_iterator and const correctness</h3>
+<p><b>Section:</b> 28.12.1 [re.regiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-05</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>Both the class definition of regex_iterator (28.12.1 [re.regiter]/1)
+and the latter member specification (28.12.1.2 [re.regiter.comp]/1+2)
+declare both comparison operators as
+non-const functions. Furtheron, both dereference operators are
+unexpectedly also declared as non-const in 28.12.1 [re.regiter]/1
+as well as in (28.12.1.3 [re.regiter.deref]/1+2).
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+1) In (28.12.1 [re.regiter]/1) change the current declarations
+</p>
+
+<blockquote><pre>bool operator==(const regex_iterator&amp;) <ins>const</ins>;
+bool operator!=(const regex_iterator&amp;) <ins>const</ins>;
+const value_type&amp; operator*() <ins>const</ins>;
+const value_type* operator-&gt;() <ins>const</ins>;
+</pre></blockquote>
+
+<p>
+2) In 28.12.1.3 [re.regiter.deref] change the following declarations
+</p>
+
+<blockquote><pre>const value_type&amp; operator*() <ins>const</ins>;
+const value_type* operator-&gt;() <ins>const</ins>;
+</pre></blockquote>
+
+<p>
+3) In 28.12.1.2 [re.regiter.comp] change the following declarations
+</p>
+
+<blockquote><pre>bool operator==(const regex_iterator&amp; right) <ins>const</ins>;
+bool operator!=(const regex_iterator&amp; right) <ins>const</ins>;
+</pre></blockquote>
+
+
+<p><i>[
+Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
+is to adopt the proposed wording in this issue).
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="654"></a>654. Missing IO roundtrip for random number engines</h3>
+<p><b>Section:</b> 26.4.1.3 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">Pending WP</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-08</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req.eng">issues</a> in [rand.req.eng].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20WP">Pending WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Table 98 and para 5 in 26.4.1.3 [rand.req.eng] specify
+the IO insertion and extraction semantic of random
+number engines. It can be shown, v.i., that the specification
+of the extractor cannot guarantee to fulfill the requirement
+from para 5:
+</p>
+
+<blockquote><p>
+If a textual representation written via os &lt;&lt; x was
+subsequently read via is &gt;&gt; v, then x == v provided that
+there have been no intervening invocations of x or of v.
+</p></blockquote>
+
+<p>
+The problem is, that the extraction process described in
+table 98 misses to specify that it will initially set the
+if.fmtflags to ios_base::dec, see table 104:
+</p>
+
+<blockquote><p>
+dec: converts integer input or generates integer output
+in decimal base
+</p></blockquote>
+
+<p>
+Proof: The following small program demonstrates the violation
+of requirements (exception safety not fulfilled):
+</p>
+
+<blockquote><pre>#include &lt;cassert&gt;
+#include &lt;ostream&gt;
+#include &lt;iostream&gt;
+#include &lt;iomanip&gt;
+#include &lt;sstream&gt;
+
+class RanNumEngine {
+ int state;
+public:
+ RanNumEngine() : state(42) {}
+
+ bool operator==(RanNumEngine other) const {
+ return state == other.state;
+ }
+
+ template &lt;typename Ch, typename Tr&gt;
+ friend std::basic_ostream&lt;Ch, Tr&gt;&amp; operator&lt;&lt;(std::basic_ostream&lt;Ch, Tr&gt;&amp; os, RanNumEngine engine) {
+ Ch old = os.fill(os.widen(' ')); // Sets space character
+ std::ios_base::fmtflags f = os.flags();
+ os &lt;&lt; std::dec &lt;&lt; std::left &lt;&lt; engine.state; // Adds ios_base::dec|ios_base::left
+ os.fill(old); // Undo
+ os.flags(f);
+ return os;
+ }
+
+ template &lt;typename Ch, typename Tr&gt;
+ friend std::basic_istream&lt;Ch, Tr&gt;&amp; operator&gt;&gt;(std::basic_istream&lt;Ch, Tr&gt;&amp; is, RanNumEngine&amp; engine) {
+ // Uncomment only for the fix.
+
+ //std::ios_base::fmtflags f = is.flags();
+ //is &gt;&gt; std::dec;
+ is &gt;&gt; engine.state;
+ //is.flags(f);
+ return is;
+ }
+};
+
+int main() {
+ std::stringstream s;
+ s &lt;&lt; std::setfill('#'); // No problem
+ s &lt;&lt; std::oct; // Yikes!
+ // Here starts para 5 requirements:
+ RanNumEngine x;
+ s &lt;&lt; x;
+ RanNumEngine v;
+ s &gt;&gt; v;
+ assert(x == v); // Fails: 42 == 34
+}
+</pre></blockquote>
+
+<p>
+A second, minor issue seems to be, that the insertion
+description from table 98 unnecessarily requires the
+addition of ios_base::fixed (which only influences floating-point
+numbers). Its not entirely clear to me whether the proposed
+standard does require that the state of random number engines
+is stored in integral types or not, but I have the impression
+that this is the indent, see e.g. p. 3
+</p>
+
+<blockquote><p>
+The specification of each random number engine defines the
+size of its state in multiples of the size of its result_type.
+</p></blockquote>
+
+<p>
+If other types than integrals are supported, then I wonder why
+no requirements are specified for the precision of the stream.
+</p>
+
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for some further discussion.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Adopt the proposed resolution in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
+</p>
+
+
+<p><i>[
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="655"></a>655. Signature of generate_canonical not useful</h3>
+<p><b>Section:</b> 26.4.7.2 [rand.util.canonical] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">Pending WP</a>
+ <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-08</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.canonical">issues</a> in [rand.util.canonical].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20WP">Pending WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In 26.4.2 [rand.synopsis] we have the declaration
+</p>
+
+<blockquote><pre>template&lt;class RealType, class UniformRandomNumberGenerator,
+ size_t bits&gt;
+result_type generate_canonical(UniformRandomNumberGenerator&amp; g);
+</pre></blockquote>
+
+<p>
+Besides the "result_type" issue (already recognized by Bo Persson
+at Sun, 11 Feb 2007 05:26:47 GMT in this group) it's clear, that
+the template parameter order is not reasonably choosen: Obviously
+one always needs to specify all three parameters, although usually
+only two are required, namely the result type RealType and the
+wanted bits, because UniformRandomNumberGenerator can usually
+be deduced.
+</p>
+
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for some further discussion.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Adopt the proposed resolution in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
+</p>
+
+
+<p><i>[
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="660"></a>660. Missing Bitwise Operations</h3>
+<p><b>Section:</b> 20.5 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Beman Dawes <b>Date:</b> 2007-04-02</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>Section 20.5 [function.objects] provides <span id="st" name="st" class="st">function</span>
+<span id="st" name="st" class="st">objects</span> for some unary and binary
+operations, but others are missing. In a LWG reflector discussion, beginning
+with c++std-lib-18078, pros and cons of adding some of the missing operations
+were discussed. Bjarne Stroustrup commented "Why standardize what isn't used?
+Yes, I see the chicken and egg problems here, but it would be nice to see a
+couple of genuine uses before making additions."</p>
+<p>A number of libraries, including Rogue Wave, GNU, Adobe ASL, and Boost, have
+already added these functions, either publicly or for internal use. For example,
+Doug Gregor commented: "Boost will also add ... (|, &amp;, ^) in 1.35.0, because we
+need those <span id="st" name="st" class="st">function</span>
+<span id="st" name="st" class="st">objects</span> to represent various parallel
+collective operations (reductions, prefix reductions, etc.) in the new Message
+Passing Interface (MPI) library."</p>
+<p>Because the bitwise operators have the strongest use cases, the proposed
+resolution is limited to them.</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>To 20.5 [function.objects], Function objects, paragraph 2, add to the header
+&lt;functional&gt; synopsis:</p>
+<blockquote>
+ <pre>template &lt;class T&gt; struct bit_and;
+template &lt;class T&gt; struct bit_or;
+template &lt;class T&gt; struct bit_xor;</pre>
+</blockquote>
+<p>At a location in clause 20 to be determined by the Project Editor, add:</p>
+<blockquote>
+ <p>The library provides basic function object classes for all of the bitwise
+ operators in the language ([expr.bit.and], [expr.or], [exp.xor]).</p>
+ <pre>template &lt;class T&gt; struct bit_and : binary_function&lt;T,T,T&gt; {
+ T operator()(const T&amp; x , const T&amp; y ) const;
+};</pre>
+ <blockquote>
+ <p><code>operator()</code> returns<code> x &amp; y</code> .</p>
+ </blockquote>
+ <pre>template &lt;class T&gt; struct bit_or : binary_function&lt;T,T,T&gt; {
+ T operator()(const T&amp; x , const T&amp; y ) const;
+};</pre>
+ <blockquote>
+ <p><code>operator()</code> returns <code>x | y</code> .</p>
+ </blockquote>
+ <pre>template &lt;class T&gt; struct bit_xor : binary_function&lt;T,T,T&gt; {
+ T operator()(const T&amp; x , const T&amp; y ) const;
+};</pre>
+ <blockquote>
+ <p><code>operator()</code> returns <code>x ^ y</code> .</p>
+ </blockquote>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="677"></a>677. Weaknesses in seed_seq::randomize [rand.util.seedseq]</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#WP">Pending WP</a>
+ <b>Submitter:</b> Charles Karney <b>Date:</b> 2007-05-15</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#Pending%20WP">Pending WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+<tt>seed_seq::randomize</tt> provides a mechanism for initializing random number
+engines which ideally would yield "distant" states when given "close"
+seeds. The algorithm for <tt>seed_seq::randomize</tt> given in the current
+Working Draft for C++,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a>
+(2007-05-08), has 3 weaknesses
+</p>
+
+<ol>
+<li>
+<p> Collisions in state. Because of the way the state is initialized,
+ seeds of different lengths may result in the same state. The
+ current version of seed_seq has the following properties:</p>
+<ul>
+<li> For a given <tt>s &lt;= n</tt>, each of the 2^(32s) seed vectors results in a
+ distinct state.</li>
+</ul>
+<p>
+ The proposed algorithm (below) has the considerably stronger
+ properties:</p>
+<ul>
+<li> All of the <tt>(2^(32n)-1)/(2^32-1)</tt> seed vectors of lengths <tt>s &lt; n</tt>
+ result in distinct states.
+</li>
+<li> All of the <tt>2^(32n)</tt> seed vectors of length <tt>s == n</tt> result in
+ distinct states.
+</li>
+</ul>
+</li>
+<li>
+<p> Poor mixing of <tt>v'</tt>s entropy into the state. Consider <tt>v.size() == n</tt>
+ and hold <tt>v[n/2]</tt> thru <tt>v[n-1]</tt> fixed while varying <tt>v[0]</tt> thru <tt>v[n/2-1]</tt>,
+ a total of <tt>2^(16n)</tt> possibilities. Because of the simple recursion
+ used in <tt>seed_seq</tt>, <tt>begin[n/2]</tt> thru <tt>begin[n-1]</tt> can take on only 2^64
+ possible states.</p>
+
+<p> The proposed algorithm uses a more complex recursion which results
+ in much better mixing.</p>
+</li>
+<li> <tt>seed_seq::randomize</tt> is undefined for <tt>v.size() == 0</tt>. The proposed
+ algorithm remedies this.
+</li>
+</ol>
+<p>
+The current algorithm for <tt>seed_seq::randomize</tt> is adapted by me from the
+initialization procedure for the Mersenne Twister by Makoto Matsumoto
+and Takuji Nishimura. The weakness (2) given above was communicated to
+me by Matsumoto last year.
+</p>
+<p>
+The proposed replacement for <tt>seed_seq::randomize</tt> is due to Mutsuo Saito,
+a student of Matsumoto, and is given in the implementation of the
+SIMD-oriented Fast Mersenne Twister random number generator SFMT.
+<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/index.html">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html</a>
+<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/SFMT-src-1.2.tar.gz">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/SFMT-src-1.2.tar.gz</a>
+</p>
+<p>
+See
+Mutsuo Saito,
+An Application of Finite Field: Design and Implementation of 128-bit
+Instruction-Based Fast Pseudorandom Number Generator,
+Master's Thesis, Dept. of Math., Hiroshima University (Feb. 2007)
+<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/M062821.pdf">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/M062821.pdf</a>
+</p>
+<p>
+One change has been made here, namely to treat the case of small <tt>n</tt>
+(setting <tt>t = (n-1)/2</tt> for <tt>n &lt; 7</tt>).
+</p>
+<p>
+Since <tt>seed_seq</tt> was introduced relatively recently there is little cost
+in making this incompatible improvement to it.
+</p>
+
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for some further discussion.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Adopt the proposed resolution in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
+</p>
+
+
+<p><i>[
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="678"></a>678. Changes for [rand.req.eng]</h3>
+<p><b>Section:</b> 26.4.1.3 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Charles Karney <b>Date:</b> 2007-05-15</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req.eng">issues</a> in [rand.req.eng].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Section 26.4.1.3 [rand.req.eng] Random number engine requirements:
+</p>
+
+<p>
+This change follows naturally from the proposed change to
+<tt>seed_seq::randomize</tt> in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>.
+</p>
+
+<p>
+In table 104 the description of <tt>X(q)</tt> contains a special treatment of
+the case <tt>q.size() == 0</tt>. This is undesirable for 4 reasons:
+</p>
+
+<ol>
+<li>It replicates the functionality provided by <tt>X()</tt>.</li>
+<li>It leads to the possibility of a collision in the state provided
+ by some other <tt>X(q)</tt> with <tt>q.size() &gt; 0</tt>.</li>
+<li>It is inconsistent with the description of the <tt>X(q)</tt> in
+paragraphs 26.4.3.1 [rand.eng.lcong] p5, 26.4.3.2 [rand.eng.mers] p8, and 26.4.3.3 [rand.eng.sub] p10 where
+there is no special treatment of <tt>q.size() == 0</tt>.</li>
+<li>The proposed replacement for <tt>seed_seq::randomize</tt> given above
+ allows for the case <tt>q.size() == 0</tt>.</li>
+</ol>
+
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for some further discussion.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Adopt the proposed resolution in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
+</p>
+
+
+<p><i>[
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="681"></a>681. Operator functions impossible to compare are defined in [re.submatch.op]</h3>
+<p><b>Section:</b> 28.9.2 [re.submatch.op] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> Nozomu Katoo <b>Date:</b> 2007-05-27</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In 28.9.2 [re.submatch.op] of N2284,
+operator functions numbered 31-42 seem impossible to compare. &nbsp;E.g.:
+</p>
+
+<blockquote>
+<pre>
+template &lt;class BiIter&gt;
+&nbsp; &nbsp; bool operator==(typename iterator_traits&lt;BiIter&gt;::value_type const&amp; lhs,
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; const sub_match&lt;BiIter&gt;&amp; rhs);
+</pre>
+<blockquote>
+<p>
+-31- <i>Returns:</i> <tt>lhs == rhs.str()</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+<p>
+When <tt>char*</tt> is used as <tt>BiIter</tt>, <tt>iterator_traits&lt;BiIter&gt;::value_type</tt> would be
+<tt>char</tt>, so that <tt>lhs == rhs.str()</tt> ends up comparing a <tt>char</tt> value and an object
+of <tt>std::basic_string&lt;char&gt;</tt>. &nbsp;However, the behaviour of comparison between
+these two types is not defined in 21.3.8 [string.nonmembers] of N2284.
+&nbsp;This applies when <tt>wchar_t*</tt> is used as <tt>BiIter</tt>.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Adopt the proposed resolution in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
+</p>
+
+
+<p><i>[
+Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="682"></a>682. basic_regex ctor takes InputIterator or ForwardIterator?</h3>
+<p><b>Section:</b> 28.8.2 [re.regex.construct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">Pending WP</a>
+ <b>Submitter:</b> Eric Niebler <b>Date:</b> 2007-06-03</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20WP">Pending WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Looking at N2284, 28.8 [re.regex], p3 <tt>basic_regex</tt> class template synopsis shows this
+constructor:
+</p>
+<blockquote><pre>template &lt;class InputIterator&gt;
+&nbsp; &nbsp; &nbsp;basic_regex(InputIterator first, InputIterator last,
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;flag_type f = regex_constants::ECMAScript);
+</pre></blockquote>
+
+<p>
+In 28.8.2 [re.regex.construct], p15, the constructor appears with this signature:
+</p>
+
+<blockquote><pre>template &lt;class ForwardIterator&gt;
+&nbsp; &nbsp; &nbsp;basic_regex(ForwardIterator first, ForwardIterator last,
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;flag_type f = regex_constants::ECMAScript);
+</pre></blockquote>
+
+<p>
+<tt>ForwardIterator</tt> is probably correct, so the synopsis is wrong.
+</p>
+
+<p><i>[
+John adds:
+]</i></p>
+
+
+<blockquote>
+<p>
+I think either could be implemented? &nbsp;Although an input iterator would
+probably require an internal copy of the string being made.
+</p>
+<p>
+I have no strong feelings either way, although I think my original intent
+was <tt>InputIterator</tt>.
+</p>
+</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Adopt the proposed resolution in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
+</p>
+
+
+<p><i>[
+Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="699"></a>699. N2111 changes min/max</h3>
+<p><b>Section:</b> 26.4 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
+ <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2007-07-01</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand">issues</a> in [rand].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2111.pdf">N2111</a>
+changes <tt>min/max</tt> in several places in random from member
+functions to static data members. I believe this introduces
+a needless backward compatibility problem between C++0X and
+TR1. I'd like us to find new names for the static data members,
+or perhaps change <tt>min/max</tt> to <tt>constexpr</tt>s in C++0X.
+</p>
+
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for some further discussion.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Adopt the proposed resolution in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
+</p>
+
+
+<p><i>[
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]</i></p>
+
+
+
+
+
+<hr>
+<h3><a name="712"></a>712. <tt>seed_seq::size</tt> no longer useful</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#WP">WP</a>
+ <b>Submitter:</b> Marc Paterno <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#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#WP">WP</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+One of the motivations for incorporating <tt>seed_seq::size()</tt>
+was to simplify the wording
+in other parts of 26.4 [rand].
+As a side effect of resolving related issues,
+all such references
+to <tt>seed_seq::size()</tt> will have been excised.
+More importantly,
+the present specification is contradictory,
+as "The number of 32-bit units the object can deliver"
+is not the same as "the result of <tt>v.size()</tt>."
+</p>
+
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for some further discussion.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Adopt the proposed resolution in
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
+</p>
+
+
+<p><i>[
+Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
+The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
+]</i></p>
+
+
+
+
+
+
+</body></html> \ No newline at end of file
generated by cgit v1.1 at 2025-08-11 11:43:34 +0000