<!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>
<td align="left">Howard Hinnant <<a href="mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>></td>
</tr>
</tbody></table>
-<h1>C++ Standard Library Active Issues List (Revision 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>
<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
<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>
<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>
<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>
<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>
<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>
<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>
<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>
<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>
<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>
</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.
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.
value, then set failbit and assign the nearest representable value.
Bill will provide wording.</p>
+<p>
+Discussed at Toronto:
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2327.pdf">N2327</a>
+is in alignment with the direction we wanted to go with in Lillehammer. Bill
+to work on.
+</p>
+
<p><b>Proposed resolution:</b></p>
+<p>
+Change 22.2.2.1.2 [facet.num.get.virtuals], end of p3:
+</p>
+
+<blockquote>
+<p>
+<b>Stage 3:</b> <del>The result of stage 2 processing can be one of</del>
+<ins>The sequence of <tt>char</tt>s accumulated in stage 2 (the field) is
+converted to a numeric value by the rules of one of the functions declared
+in the header <tt><cstdlib></tt>:</ins>
+</p>
+<ul>
+<li>
+<del>A sequence of <tt>char</tt>s has been accumulated in stage 2 that is
+converted (according to the rules of <tt>scanf</tt>) to a value of the
+type of <i>val</i>. This value is stored in <i>val</i> and <tt>ios_base::goodbit</tt> is
+stored in <i>err</i>.</del>
+<ins>For a signed integer value, the function <tt>strtoll</tt>.</ins>
+</li>
+<li>
+<del>The sequence of <tt>char</tt>s accumulated in stage 2 would have caused
+<tt>scanf</tt> to report an input failure. <tt>ios_base::failbit</tt> is
+assigned to <i>err</i>.</del>
+<ins>For an unsigned integer value, the function <tt>strtoull</tt>.</ins>
+</li>
+<li>
+<ins>For a floating-point value, the function <tt>strtold</tt>.</ins>
+</li>
+</ul>
+<p>
+<ins>The numeric value to be stored can be one of:</ins>
+</p>
+<ul>
+<li><ins>zero, if the conversion function fails to convert the entire field.
+<tt>ios_base::failbit</tt> is assigned to err.</ins></li>
+<li><ins>the most positive representable value, if the field represents a value
+too large positive to be represented in <i>val</i>. <tt>ios_base::failbit</tt> is assigned
+to <i>err</i>.</ins></li>
+<li><ins>the most negative representable value (zero for unsigned integer), if
+the field represents a value too large negative to be represented in <i>val</i>.
+<tt>ios_base::failbit</tt> is assigned to <i>err</i>.</ins></li>
+<li><ins>the converted value, otherwise.</ins></li>
+</ul>
+
+<p><ins>
+The resultant numeric value is stored in <i>val</i>.
+</ins></p>
+</blockquote>
+
+<p>
+Change 22.2.2.1.2 [facet.num.get.virtuals], p6-p7:
+</p>
+
+<blockquote>
+<pre>iter_type do_get(iter_type <i>in</i>, iter_type <i>end</i>, ios_base& <i>str</i>,
+ ios_base::iostate& <i>err</i>, bool& <i>val</i>) const;
+</pre>
+<blockquote>
+<p>
+-6- <i>Effects:</i> If
+<tt>(<i>str</i>.flags()&ios_base::boolalpha)==0</tt> then input
+proceeds as it would for a <tt>long</tt> except that if a value is being
+stored into <i>val</i>, the value is determined according to the
+following: If the value to be stored is 0 then <tt>false</tt> is stored.
+If the value is 1 then <tt>true</tt> is stored. Otherwise
+<del><tt><i>err</i>|=ios_base::failbit</tt> is performed and no value</del> <ins><tt>true</tt></ins> is
+stored<del>.</del> <ins>and <tt>ios_base::failbit</tt> is assigned to <i>err</i>.</ins>
+</p>
+<p>
+-7- Otherwise target sequences are determined "as if" by calling the
+members <tt>falsename()</tt> and <tt>truename()</tt> of the facet
+obtained by <tt>use_facet<numpunct<charT>
+>(<i>str</i>.getloc())</tt>. Successive characters in the range
+<tt>[<i>in</i>,<i>end</i>)</tt> (see 23.1.1) are obtained and matched
+against corresponding positions in the target sequences only as
+necessary to identify a unique match. The input iterator <i>in</i> is
+compared to <i>end</i> only when necessary to obtain a character. If <del>and
+only if</del> a target sequence is uniquely matched, <i>val</i> is set to the
+corresponding value. <ins>Otherwise <tt>false</tt> is stored and <tt>ios_base::failbit</tt>
+is assigned to <i>err</i>.</ins>
+</p>
+</blockquote>
+</blockquote>
<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>
<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>
<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>
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>
<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)?->~T()
-</pre>
-
-<p>
-.... with the prerequisits coming from the preceding two paragraphs, especially
-from table 31:
-</p>
-
-<pre> alloc<T> a ;// an allocator for T
- alloc<T>::pointer p ;// random access iterator
- // (may be different from T*)
- alloc<T>::reference r = *p;// T&
- T const& 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<T>::pointer, so it would implicitely introduce extra
-requirements for alloc<T>::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)->~T()</del>
-<ins>Destroys the object at p.</ins>
-</p>
-</blockquote>
-
-<p>
-Note: Actually I would prefer to replace "((T*)p)?->dtor_name" with
-"p?->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<reverse_iterator<char*> > forbidden?</h3>
<p><b>Section:</b> 24.1 [iterator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
<b>Submitter:</b> Nathan Myers <b>Date:</b> 2003-06-03</p>
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>
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>
<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<class ForwardIterator>
- void rotate(ForwardIterator first, ForwardIterator middle,
- ForwardIterator last);
-</pre>
-
-<p>to:</p>
-
-<pre> template<class ForwardIterator>
- ForwardIterator rotate(ForwardIterator first, ForwardIterator middle,
- ForwardIterator last);
-</pre>
-
-<p>In 25.2.10, change:</p>
-
-<pre> template<class ForwardIterator>
- void rotate(ForwardIterator first, ForwardIterator middle,
- ForwardIterator last);
-</pre>
-
-<p>to:</p>
-
-<pre> template<class ForwardIterator>
- 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>
<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
]</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>
Batavia: Howard to provide wording.
]</i></p>
+<p><i>[
+Toronto: Howard to provide wording (really this time).
+]</i></p>
+
<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>
<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>
+<h3><a name="527"></a>527. tr1::bind has lost its Throws clause</h3>
+<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>
<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<> 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.
+The original bind proposal gives the guarantee that tr1::bind(f, t1,
+..., tN) does not throw when the copy constructors of f, t1, ..., tN
+don't.
</p>
+
<p>
-2) Add a isctype_nocase function
+This guarantee is not present in the final version of TR1.
</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.
+I'm pretty certain that we never removed it on purpose. Editorial omission? :-)
</p>
<p><i>[
-Berlin: Howard to provide wording.
+Berlin: not quite editorial, needs proposed 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>
- <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>
-<p>
-The original bind proposal gives the guarantee that tr1::bind(f, t1,
-..., tN) does not throw when the copy constructors of f, t1, ..., tN
-don't.
-</p>
-
-<p>
-This guarantee is not present in the final version of TR1.
-</p>
-
-<p>
-I'm pretty certain that we never removed it on purpose. Editorial omission? :-)
-</p>
-
<p><i>[
-Berlin: not quite editorial, needs proposed wording.
+Batavia: Doug to translate wording to variadic templates.
]</i></p>
+
<p><i>[
-Batavia: Doug to translate wording to variadic templates.
+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>
In 20.5.10.1.3 [lib.func.bind.bind] ([tr.func.bind.bind]), add a new paragraph after p2:
<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>
<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 < 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
-> 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 < 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 > 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>
<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].
<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
<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. <ccomplex></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 <complex.h>
-it isn't. Otherwise we could model it just like <string.h>, <cstring>, <string>:
-</p>
-
-<ul>
-<li><string> : C++ API in namespace std</li>
-<li><cstring> : C API in namespace std</li>
-<li><string.h> : 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><complex> : C++ API in namespace std</li>
-<li><ccomplex> : ?</li>
-<li><complex.h> : ?</li>
-</ul>
-
-<p>
-The ? can't refer to the C API. TR1 currently says:
-</p>
-
-<ul>
-<li><complex> : C++ API in namespace std</li>
-<li><ccomplex> : C++ API in namespace std</li>
-<li><complex.h> : 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><ccomplex></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><complex></tt>.</del>
-<ins>[<i>Note:</i> <tt><complex.h></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><tgmath.h></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>
<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:
+<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>
</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 ==
</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
</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>
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 < 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 < 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 > 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>
<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>
</blockquote>
+<p><i>[
+Kona (2007): Proposed Disposition: Ready
+]</i></p>
+
+
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>
<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:
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>
<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
<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 < *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><iostream&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 < *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>
<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
+<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>
+
+
<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>
+<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>
<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< typename T>
-T power( T x, int n );
-// requires: n >=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>
</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
</p>
-
-
-
-<hr>
-<h3><a name="592"></a>592. Incorrect treatment of rdbuf()->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()->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()->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()->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>
<hr>
<h3><a name="595"></a>595. TR1/C++0x: fabs(complex<T>) 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
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>
+<p><b>Proposed resolution:</b></p>
+
+<p>
+Change the synopsis in 26.3.1 [complex.synopsis]:
+</p>
+
+<blockquote><pre>template<class T> <del>complex<</del>T<del>></del> fabs(const complex<T>&);
+</pre></blockquote>
+
+<p>
+Change 26.3.7 [complex.value.ops], p7:
+</p>
+
+<blockquote>
+<pre>template<class T> <del>complex<</del>T<del>></del> fabs(const complex<T>& <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>
<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="597"></a>597. Decimal: The notion of 'promotion' cannot be emulated by user-defined types.</h3>
-<p><b>Section:</b> TRDecimal 3.2 [trdec.types.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Daveed Vandevoorde <b>Date:</b> 2006-04-05</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#trdec.types.types">active issues</a> in [trdec.types.types].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types.types">issues</a> in [trdec.types.types].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In a private email, Daveed writes:
-</p>
-<blockquote>
-<p>
-I am not familiar with the C TR, but my guess is that the
-class type approach still won't match a built-in type
-approach because the notion of "promotion" cannot be
-emulated by user-defined types.
-</p>
<p>
-Here is an example:
+Add to the table "File open modes" in 27.8.1.4 [filebuf.members]:
</p>
-</blockquote>
-<pre>
- struct S {
- S(_Decimal32 const&); // Converting constructor
- };
- void f(S);
- void f(_Decimal64);
+<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> </tt></th>
+</tr>
+
+<tr>
+<td> </td> <td> </td> <td><tt>+</tt></td> <td> </td> <td> </td> <td><tt>"w"</tt></td>
+</tr>
+<tr>
+<td> </td> <td> </td> <td><tt>+</tt></td> <td> </td> <td><tt>+</tt></td> <td><tt>"a"</tt></td>
+</tr>
+<tr>
+<td> </td> <td> </td> <td> </td> <td> </td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a"</tt></ins></td>
+</tr>
+<tr>
+<td> </td> <td> </td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td> </td> <td><tt>"w"</tt></td>
+</tr>
+<tr>
+<td> </td> <td><tt>+</tt></td> <td> </td> <td> </td> <td> </td> <td><tt>"r"</tt></td>
+</tr>
+<tr>
+<td> </td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td> </td> <td> </td> <td><tt>"r+"</tt></td>
+</tr>
+<tr>
+<td> </td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td> </td> <td><tt>"w+"</tt></td>
+</tr>
+<tr>
+<td> </td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td> </td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+"</tt></ins></td>
+</tr>
+<tr>
+<td> </td> <td><ins><tt>+</tt></ins></td> <td> </td> <td> </td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+"</tt></ins></td>
+</tr>
+
+<tr>
+<td><tt>+</tt></td> <td> </td> <td><tt>+</tt></td> <td> </td> <td> </td> <td><tt>"wb"</tt></td>
+</tr>
+<tr>
+<td><tt>+</tt></td> <td> </td> <td><tt>+</tt></td> <td> </td> <td><tt>+</tt></td> <td><tt>"ab"</tt></td>
+</tr>
+<tr>
+<td><ins><tt>+</tt></ins></td> <td> </td> <td> </td> <td> </td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"ab"</tt></ins></td>
+</tr>
+<tr>
+<td><tt>+</tt></td> <td> </td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td> </td> <td><tt>"wb"</tt></td>
+</tr>
+<tr>
+<td><tt>+</tt></td> <td><tt>+</tt></td> <td> </td> <td> </td> <td> </td> <td><tt>"rb"</tt></td>
+</tr>
+<tr>
+<td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td> </td> <td> </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> </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> </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> </td> <td> </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>
+
+
+
+
+
+<hr>
+<h3><a name="597"></a>597. Decimal: The notion of 'promotion' cannot be emulated by user-defined types.</h3>
+<p><b>Section:</b> TRDecimal 3.2 [trdec.types.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Daveed Vandevoorde <b>Date:</b> 2006-04-05</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#trdec.types.types">active issues</a> in [trdec.types.types].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types.types">issues</a> in [trdec.types.types].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In a private email, Daveed writes:
+</p>
+<blockquote>
+<p>
+I am not familiar with the C TR, but my guess is that the
+class type approach still won't match a built-in type
+approach because the notion of "promotion" cannot be
+emulated by user-defined types.
+</p>
+<p>
+Here is an example:
+</p>
+</blockquote>
+<pre>
+ struct S {
+ S(_Decimal32 const&); // Converting constructor
+ };
+ void f(S);
+
+ void f(_Decimal64);
void g(_Decimal32 d) {
f(d);
<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<charT, InputIterator></del> <ins>std::locale</ins> & <i>b</i>, size_t <i>refs</i> = 0);
-
- /* ... */
-
- <del>// <i>const std::num_get<charT, InputIterator> & <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<charT, InputIterator></del> <ins>std::locale</ins> & <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<charT, InputIterator></del> <ins>std::locale</ins> & <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 &, ios_base::iostate &, bool &) const</code>, <i>et al</i> to
-</p>
-<blockquote><p>
-<b>Returns:</b> <code><del><i>base</i></del> <ins>std::use_facet<std::num_get<charT, InputIterator> >(<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<charT, OutputIterator></del> <ins>std::locale</ins> & <i>b</i>, size_t <i>refs</i> = 0);
-
- /* ... */
-
- <del>// <i>const std::num_put<charT, OutputIterator> & <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<charT, OutputIterator></del> <ins>std::locale</ins> & <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<charT, OutputIterator></del> <ins>std::locale</ins> & <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 &, char_type, bool &) const</code>, <i>et al</i> to
-</p>
-<blockquote><p>
-<b>Returns:</b> <code><del><i>base</i></del> <ins>std::use_facet<std::num_put<charT, OutputIterator> >(<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>
<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) < N <= 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 <= i < 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>
<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>
<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
<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<T> cshift(int <i>n</i>) const;
+</pre>
+
+<blockquote>
<p>
This function returns an object of class <tt>valarray<T></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 < 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>
<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>
</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>
<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& operator= (const slice_array&)<ins> const</ins>;</code>
+<code><ins>const</ins> slice_array& operator= (const slice_array&)<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& operator= (const gslice_array&)<ins> const</ins>;</code>
+<code><ins>const</ins> gslice_array& operator= (const gslice_array&)<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& operator= (const mask_array&)<ins> const</ins>;</code>
+<code><ins>const</ins> mask_array& operator= (const mask_array&)<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& operator= (const indirect_array&)<ins> const</ins>;</code>
+<code><ins>const</ins> indirect_array& operator= (const indirect_array&)<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>
</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>
<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>
<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>
<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
</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Insert new paragraph into 26.5.2.2 [valarray.assign]:
+</p>
+
+<blockquote>
+<pre>valarray<T>& operator=(const slice_array<T>&);
+valarray<T>& operator=(const gslice_array<T>&);
+valarray<T>& operator=(const mask_array<T>&);
+valarray<T>& operator=(const indirect_array<T>&);
+</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>
+
+
<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>
<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
<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<class InputIterator>
-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 <class <del>ForwardIterator</del> <ins>InputIterator</ins>>
- 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
<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>
</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
*<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>
<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:
</p>
-
-
-
-<hr>
-<h3><a name="634"></a>634. <tt>allocator.address()</tt> doesn't work for types overloading <tt>operator&</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>&<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&</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&</tt> to return something other
-than the address of <tt>*this</tt>.
-</p>
-
-<p>
-An example of when you want to overload <tt>operator&</tt> to return something
-other than the object's address is proxy references such as <tt>vector<bool></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&</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>&<i>x</i></tt>.</del> <ins>The actual address of <tt><i>x</i></tt>,
-even in the presence of an overloaded <tt>operator&</tt>.</ins>
-</p>
-</blockquote>
-
-<pre>const_pointer address(address(const_reference <i>x</i>) const;</pre>
-<blockquote>
-<p>
--2- <i>Returns:</i> <del><tt>&<i>x</i></tt>.</del> <ins>The actual address of <tt><i>x</i></tt>,
-even in the presence of an overloaded <tt>operator&</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
]</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:
<p><b>Proposed resolution:</b></p>
<p>
+Change 23.2.2.3 [deque.modifiers], p4:
</p>
+<blockquote>
+<pre>iterator erase(const_iterator position);
+iterator erase(const_iterator first, const_iterator last);
+</pre>
+<blockquote>
+<p>
+-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>
+</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#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><i>[
+Kona (2007): Proposed wording added and moved to Review.
+]</i></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>
+<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#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#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
<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".
+According to the description given in 28.10 [re.results]/2 the class template
+match_results "shall satisfy the requirements of a Sequence, [..],
+except that only operations defined for const-qualified Sequences
+are supported".
+Comparing the provided operations from 28.10 [re.results]/3 with the
+sequence/container tables 80 and 81 one recognizes the following
+missing operations:
</p>
<p>
-Is this behaviour by design?
+1) The members
</p>
+<blockquote><pre>const_iterator rbegin() const;
+const_iterator rend() const;
+</pre></blockquote>
+
<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::
+should exists because 23.1/10 demands these for containers
+(all sequences are containers) which support bidirectional
+iterators. Aren't these supported by match_result? This is not
+explicitely expressed, but it's somewhat implied by two arguments:
</p>
<p>
-1) Paragraph 8 says at its end:
+(a) Several typedefs delegate to
+<tt>iterator_traits<BidirectionalIterator></tt>.
</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.
+(b) The existence of <tt>const_reference operator[](size_type n) const</tt>
+implies even random-access iteration.
+I also suggest, that <tt>match_result</tt> should explicitly mention,
+which minimum iterator category is supported and if this does
+not include random-access the existence of <tt>operator[]</tt> is
+somewhat questionable.
</p>
-
<p>
-2) Paragraph 9 says:
+2) The new "convenience" members
</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>
-
+<blockquote><pre>const_iterator cbegin() const;
+const_iterator cend() const;
+const_iterator crbegin() const;
+const_iterator crend() const;
+</pre></blockquote>
<p>
-The sentence starting with "If an exception was thrown" seems to
-imply that such an exception *should* be caught before.
+should be added according to tables 80/81.
</p>
<p><b>Proposed resolution:</b></p>
<p>
-(a) In 27.6.1.2.3 [istream::extractors]/15 (N2134) change the sentence
+Add the following members to the <tt>match_results</tt> synopsis after <tt>end()</tt> in 28.10 [re.results]
+para 3:
</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>
+<blockquote><pre>const_iterator cbegin() const;
+const_iterator cend() const;
+</pre></blockquote>
<p>
-(b) In 27.6.2.6.3 [ostream.inserters]/8 (N2134) change the sentence:
+In section 28.10.3 [re.results.acc] change:
</p>
<blockquote>
+<pre>const_iterator begin() const;
+<ins>const_iterator cbegin() const;</ins>
+</pre>
+<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:
+-7- <i>Returns:</i> A starting iterator that enumerates over all the sub-expressions stored in <tt>*this</tt>.
</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>
+<pre>const_iterator end() const;
+<ins>const_iterator cend() const;</ins>
+</pre>
+<blockquote>
<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:
+-8- <i>Returns:</i> A terminating iterator that enumerates over all the sub-expressions stored in <tt>*this</tt>.
</p>
+</blockquote>
+</blockquote>
-<blockquote><pre>operator<<(long long val );
-operator<<(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.
+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>
-<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>
+<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#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#Open">Open</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<charT,char,typename traits::state_type> <i>a_codecvt</i> =
- use_facet<codecvt<charT,char,typename traits::state_type> >(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.
+1.2 [intro.refs] Normative references
</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
+The following standards contain provisions which, through reference in
+this text, constitute provisions of this Interna- tional Standard. At
+the time of publication, the editions indicated were valid. All
+standards are subject to revision, and parties to agreements based on
+this International Standard are encouraged to investigate the
+possibility of applying the most recent editions of the standards
+indicated below. Members of IEC and ISO maintain registers of currently
+valid International Standards.
</p>
-<blockquote><pre><ins>const </ins>codecvt<charT,char,typename traits::state_type><ins>&</ins> <i>a_codecvt</i> =
- use_facet<codecvt<charT,char,typename traits::state_type> >(getloc());
-</pre></blockquote>
-
-<p>
-In 22.2.2.2.2 [facet.num.put.virtuals]/15 (This is para 5 in N2134) change
-</p>
+<ul>
+<li>Ecma International, ECMAScript Language Specification, Standard
+Ecma-262, third edition, 1999.</li>
+<li>ISO/IEC 2382 (all parts), Information technology - Vocabulary</li>
+<li>ISO/IEC 9899:1990, Programming languages - C</li>
+<li>ISO/IEC 9899/Amd.1:1995, Programming languages - C, AMENDMENT 1: C
+Integrity</li>
+<li>ISO/IEC 9899:1999, Programming languages - C</li>
+<li>ISO/IEC 9899:1999/Cor.1:2001 Programming languages - C</li>
+<li>ISO/IEC 9899:1999/Cor.2:2004 Programming languages - C</li>
+<li>ISO/IEC 9945:2003, Information Technology-Portable Operating System
+Interface (POSIX)</li>
+<li>ISO/IEC 10646-1:1993 Information technology - Universal Multiple-Octet
+Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual
+Plane</li>
+</ul>
+</blockquote>
-<blockquote>
<p>
-A local variable <tt><i>punct</i></tt> is initialized via
+I'm not sure how many of those reserve naming patterns that might affect
+us, but I am equally sure I don't own a copy of any of these to check!
</p>
-<blockquote><pre><ins>const </ins>numpunct<charT><ins>&</ins> <i>punct</i> = use_facet< numpunct<charT> >(<i>str</i>.getloc() )<ins>;</ins>
-</pre></blockquote>
-</blockquote>
-
<p>
-(Please note also the additional provided trailing semicolon)
+The point is to list the reserved naming patterns, rather than the
+individual names themselves - although we may want to list C keywords
+that are valid identifiers in C++ but likely to cause trouble in shared
+headers (e.g. restrict)
</p>
+<p><i>[
+Kona (2007): Recommend NAD. No one has identified a specific defect, just the possibility of one.
+]</i></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>
-<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<class Function2> <del>bool</del> <ins>void</ins> operator==(const function<Function2>&);
- template<class Function2> <del>bool</del> <ins>void</ins> operator!=(const function<Function2>&);
-};
-</pre></blockquote>
-
-<p>
-Change 20.5.14.2.6 [func.wrap.func.undef]
-</p>
-
-<blockquote><pre>template<class Function2> <del>bool</del> <ins>void</ins> operator==(const function<Function2>&);
-template<class Function2> <del>bool</del> <ins>void</ins> operator!=(const function<Function2>&);
-</pre></blockquote>
<hr>
-<h3><a name="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>
- <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>
+<h3><a name="659"></a>659. istreambuf_iterator should have an operator->()</h3>
+<p><b>Section:</b> 24.5.3 [istreambuf.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Niels Dekker <b>Date:</b> 2007-03-25</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istreambuf.iterator">issues</a> in [istreambuf.iterator].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-According to the description given in 28.10 [re.results]/2 the class template
-match_results "shall satisfy the requirements of a Sequence, [..],
-except that only operations defined for const-qualified Sequences
-are supported".
-Comparing the provided operations from 28.10 [re.results]/3 with the
-sequence/container tables 80 and 81 one recognizes the following
-missing operations:
+Greg Herlihy has clearly demonstrated that a user defined input
+iterator should have an operator->(), even if its
+value type is a built-in type (comp.std.c++, "Re: Should any iterator
+have an operator->() in C++0x?", March 2007). And as Howard
+Hinnant remarked in the same thread that the input iterator
+<tt>istreambuf_iterator</tt> doesn't have one, this must be a
+defect!
</p>
-
<p>
-1) The members
-</p>
+Based on Greg's example, the following code demonstrates the issue:
+</p><pre> #include <iostream>
+ #include <fstream>
+ #include <streambuf>
-<blockquote><pre>const_iterator rbegin() const;
-const_iterator rend() const;
-</pre></blockquote>
+ typedef char C;
+ int main ()
+ {
+ std::ifstream s("filename", std::ios::in);
+ std::istreambuf_iterator<char> i(s);
+
+ (*i).~C(); // This is well-formed...
+ i->~C(); // ... so this should be supported!
+ }
+</pre>
<p>
-should exists because 23.1/10 demands these for containers
-(all sequences are containers) which support bidirectional
-iterators. Aren't these supported by match_result? This is not
-explicitely expressed, but it's somewhat implied by two arguments:
-</p>
-<p>
-(a) Several typedefs delegate to
-<tt>iterator_traits<BidirectionalIterator></tt>.
-</p>
-<p>
-(b) The existence of <tt>const_reference operator[](size_type n) const</tt>
-implies even random-access iteration.
-I also suggest, that <tt>match_result</tt> should explicitly mention,
-which minimum iterator category is supported and if this does
-not include random-access the existence of <tt>operator[]</tt> is
-somewhat questionable.
+Of course, operator-> is also needed when the value_type of
+istreambuf_iterator is a class.
</p>
<p>
-2) The new "convenience" members
+The operator-> could be implemented in various ways. For instance,
+by storing the current value inside the iterator, and returning its
+address. Or by returning a proxy, like operator_arrow_proxy, from
+<a href="http://www.boost.org/boost/iterator/iterator_facade.hpp">http://www.boost.org/boost/iterator/iterator_facade.hpp</a>
</p>
-<blockquote><pre>const_iterator cbegin() const;
-const_iterator cend() const;
-const_iterator crbegin() const;
-const_iterator crend() const;
-</pre></blockquote>
<p>
-should be added according to tables 80/81.
+I hope that the resolution of this issue will contribute to getting a
+clear and consistent definition of iterator concepts.
</p>
<p><b>Proposed resolution:</b></p>
<p>
+Add to the synopsis in 24.5.3 [istreambuf.iterator]:
</p>
+<blockquote><pre>charT operator*() const;
+<ins>pointer operator->() const;</ins>
+istreambuf_iterator<charT,traits>& operator++();
+</pre></blockquote>
-
-
-
-<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].
+Change 24.5.3 [istreambuf.iterator], p1:
</p>
+<blockquote><p>
+The class template <tt>istreambuf_iterator</tt> reads successive
+characters from the <tt>streambuf</tt> for which it was constructed.
+<tt>operator*</tt> provides access to the current input character, if
+any. <ins><tt>operator-></tt> may return a proxy.</ins> Each time
+<tt>operator++</tt> is evaluated, the iterator advances to the next
+input character. If the end of stream is reached
+(<tt>streambuf_type::sgetc()</tt> returns <tt>traits::eof()</tt>), the
+iterator becomes equal to the end of stream iterator value. The default
+constructor <tt>istreambuf_iterator()</tt> and the constructor
+<tt>istreambuf_iterator(0)</tt> both construct an end of stream iterator
+object suitable for use as an end-of-range.
+</p></blockquote>
+<p><i>[
+Kona (2007): The proposed resolution is inconsistent because the return
+type of <tt>istreambuf_iterator::operator->()</tt> is specified to be <tt>pointer</tt>,
+but the proposed text also states that "<tt>operator-></tt> may return a proxy."
+]</i></p>
-<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 <class iterator, class charT, class traits>
-bool regex_search(iterator first, iterator last,
- const basic_regex<charT, traits>& e,
- regex_constants::match_flag_type flags =
- regex_constants::match_default);
-</pre></blockquote>
+<p><i>[
+Niels Dekker (mailed to Howard Hinnant):
+]</i></p>
+<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:
+The proposed resolution does
+not seem inconsistent to me. <tt>istreambuf_iterator::operator->()</tt> should
+have <tt>istreambuf_iterator::pointer</tt> as return type, and this return type
+may in fact be a proxy.
</p>
-
-<blockquote><pre>template <class BidirectionalIterator, class charT, class traits>
-bool regex_search(BidirectionalIterator first, BidirectionalIterator last,
- const basic_regex<charT, traits>& 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"
+AFAIK, the resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#445">445</a> ("<tt>iterator_traits::reference</tt>
+unspecified for some iterator categories") implies that for any iterator
+class <tt>Iter</tt>, the return type of <tt>operator->()</tt> is <tt>Iter::pointer</tt>, by
+definition. I don't think <tt>Iter::pointer</tt> needs to be a raw pointer.
</p>
-
-<blockquote><pre>template <class <del>iterator</del> <ins>BidirectionalIterator</ins>, class charT, class traits>
- bool regex_search(<del>iterator</del> <ins>BidirectionalIterator</ins> first, <del>iterator</del> <ins>BidirectionalIterator</ins> last,
- const basic_regex<charT, traits>& 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<<del>iterator</del>
-<ins>BidirectionalIterator</ins>></tt> and then returning the result
-of <tt>regex_search(first, last, what, e, flags)</tt>.
+Still I wouldn't mind if the text "<tt>operator-></tt> may return a proxy" would
+be removed from the resolution. I think it's up to the library
+implementation, how to implement <tt>istreambuf_iterator::operator->()</tt>. As
+longs as it behaves as expected: <tt>i->m</tt> should have the same effect as
+<tt>(*i).m</tt>. Even for an explicit destructor call, <tt>i->~C()</tt>. The main issue
+is just: <tt>istreambuf_iterator</tt> should have an <tt>operator->()</tt>!
</p>
</blockquote>
-
<hr>
-<h3><a name="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>
+<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#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#Ready">Ready</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>
+To the more drastic changes of 27.6.1.2.2 [istream.formatted.arithmetic] in the current draft N2134 belong
+the explicit description of the extraction of the types short and int in
+terms of as-if code fragments.
</p>
+<ol>
+<li>
+The corresponding as-if extractions in paragraph 2 and 3 will never
+result in a change of the operator>> argument val, because the
+contents of the local variable lval is in no case written into val.
+Furtheron both fragments need a currently missing parentheses in the
+beginning of the if-statement to be valid C++.
+</li>
+<li>I would like to ask whether the omission of a similar explicit
+extraction of unsigned short and unsigned int in terms of long -
+compared to their corresponding new insertions, as described in
+27.6.2.6.2 [ostream.inserters.arithmetic], is a deliberate decision or
+an
+oversight.
+</li>
+</ol>
+
<p><b>Proposed resolution:</b></p>
+<ol>
+<li>
<p>
-1) In (28.12.2 [re.tokiter]/6) change the current declarations
+In 27.6.1.2.2 [istream.formatted.arithmetic]/2 change the current as-if code fragment
</p>
-
-<blockquote><pre>bool operator==(const regex_token_iterator&) <ins>const</ins>;
-bool operator!=(const regex_token_iterator&) <ins>const</ins>;
-const value_type& operator*() <ins>const</ins>;
-const value_type* operator->() <ins>const</ins>;
+<blockquote><pre>typedef num_get<charT,istreambuf_iterator<charT,traits> > numget;
+iostate err = 0;
+long lval;
+use_facet<numget>(loc).get(*this, 0, *this, err, lval );
+if (err == 0) <ins>{</ins>
+ <del>&&</del> <ins>if</ins> (lval < numeric_limits<short>::min() || numeric_limits<short>::max() < lval)<del>)</del>
+ err = ios_base::failbit;
+ <ins>else
+ val = static_cast<short>(lval);
+}</ins>
+setstate(err);
</pre></blockquote>
<p>
-2) In 28.12.2.2 [re.tokiter.comp] change the following declarations
+Similarily in 27.6.1.2.2 [istream.formatted.arithmetic]/3 change the current as-if fragment
</p>
-<blockquote><pre>bool operator==(const regex_token_iterator& right) <ins>const</ins>;
-bool operator!=(const regex_token_iterator& right) <ins>const</ins>;
+<blockquote><pre>typedef num_get<charT,istreambuf_iterator<charT,traits> > numget;
+iostate err = 0;
+long lval;
+use_facet<numget>(loc).get(*this, 0, *this, err, lval );
+if (err == 0) <ins>{</ins>
+ <del>&&</del> <ins>if</ins> (lval < numeric_limits<int>::min() || numeric_limits<int>::max() < lval)<del>)</del>
+ err = ios_base::failbit;
+ <ins>else
+ val = static_cast<int>(lval);
+}</ins>
+setstate(err);
</pre></blockquote>
+</li>
+<li>
+---
+</li>
+</ol>
-<p>
-3) In 28.12.2.3 [re.tokiter.deref] change the following declarations
-</p>
-
-<blockquote><pre>const value_type& operator*() <ins>const</ins>;
-const value_type* operator->() <ins>const</ins>;
-</pre></blockquote>
+
+<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>>(short &)</tt> and <tt>operator >>(int &)</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>
<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>
+<h3><a name="664"></a>664. <tt>do_unshift</tt> for <tt>codecvt<char, char, mbstate_t></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#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#Ready">Ready</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:
+22.2.1.4.2 [locale.codecvt.virtuals], para 7 says (regarding <tt>do_unshift</tt>):
</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>.
+<i>Effects:</i> Places characters starting at to that should be appended to
+terminate a sequence when the current <tt>stateT</tt> is given by
+<tt><i>state</i></tt>.<sup>237)</sup> Stores no more than <tt>(<i>to_limit</i> -
+<i>to</i>)</tt> destination elements, and leaves the <tt><i>to_next</i></tt>
+pointer pointing one beyond the last element successfully stored.
+<em><tt>codecvt<char, char, mbstate_t></tt> stores no characters.</em>
</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:
+The following objection has been raised:
</p>
<blockquote><p>
-<i>Requires:</i> Each of the initialization values of <tt>subs</tt> must be <tt>>= -1</tt>.
+Since the C++ Standard permits a nontrivial conversion for the required
+instantiations of <tt>codecvt</tt>, it is overly restrictive to say that
+<tt>do_unshift</tt> must store no characters and return <tt>noconv</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
+[Plum ref _222152Y50]
</p>
-<blockquote><pre>bool operator==(const regex_iterator&) <ins>const</ins>;
-bool operator!=(const regex_iterator&) <ins>const</ins>;
-const value_type& operator*() <ins>const</ins>;
-const value_type* operator->() <ins>const</ins>;
-</pre></blockquote>
+<p><b>Proposed resolution:</b></p>
<p>
-2) In 28.12.1.3 [re.regiter.deref] change the following declarations
+Change 22.2.1.4.2 [locale.codecvt.virtuals], p7:
</p>
-<blockquote><pre>const value_type& operator*() <ins>const</ins>;
-const value_type* operator->() <ins>const</ins>;
-</pre></blockquote>
-
+<blockquote>
<p>
-3) In 28.12.1.2 [re.regiter.comp] change the following declarations
+<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<char, char,
+mbstate_t></tt> stores no characters.</del>
</p>
-
-<blockquote><pre>bool operator==(const regex_iterator& right) <ins>const</ins>;
-bool operator!=(const regex_iterator& right) <ins>const</ins>;
-</pre></blockquote>
+</blockquote>
<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>
- <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>
+<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#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#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
+22.2.1.4.2 [locale.codecvt.virtuals], para 8 says:
</p>
-<blockquote>
+
+<blockquote><p>
+<tt>codecvt<char,char,mbstate_t></tt>, returns <tt>noconv</tt>.
+</p></blockquote>
+
<p>
-1.2 [intro.refs] Normative references
+The following objection has been raised:
</p>
+<blockquote><p>
+Despite what the C++ Standard
+says, <tt>unshift</tt> can't always return <tt>noconv</tt> for the default facets, since
+they can be nontrivial. At least one implementation does whatever the
+C functions do.
+</p></blockquote>
+
<p>
-The following standards contain provisions which, through reference in
-this text, constitute provisions of this Interna- tional Standard. At
-the time of publication, the editions indicated were valid. All
-standards are subject to revision, and parties to agreements based on
-this International Standard are encouraged to investigate the
-possibility of applying the most recent editions of the standards
-indicated below. Members of IEC and ISO maintain registers of currently
-valid International Standards.
+[Plum ref _222152Y62]
</p>
-<ul>
-<li>Ecma International, ECMAScript Language Specification, Standard
-Ecma-262, third edition, 1999.</li>
-<li>ISO/IEC 2382 (all parts), Information technology - Vocabulary</li>
-<li>ISO/IEC 9899:1990, Programming languages - C</li>
-<li>ISO/IEC 9899/Amd.1:1995, Programming languages - C, AMENDMENT 1: C
-Integrity</li>
-<li>ISO/IEC 9899:1999, Programming languages - C</li>
-<li>ISO/IEC 9899:1999/Cor.1:2001 Programming languages - C</li>
-<li>ISO/IEC 9899:1999/Cor.2:2004 Programming languages - C</li>
-<li>ISO/IEC 9945:2003, Information Technology-Portable Operating System
-Interface (POSIX)</li>
-<li>ISO/IEC 10646-1:1993 Information technology - Universal Multiple-Octet
-Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual
-Plane</li>
-</ul>
-</blockquote>
+<p><b>Proposed resolution:</b></p>
<p>
-I'm not sure how many of those reserve naming patterns that might affect
-us, but I am equally sure I don't own a copy of any of these to check!
+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>
-The point is to list the reserved naming patterns, rather than the
-individual names themselves - although we may want to list C keywords
-that are valid identifiers in C++ but likely to cause trouble in shared
-headers (e.g. restrict)
+<del><tt>codecvt<char,char,mbstate_t></tt>, returns <tt>noconv</tt>.</del>
</p>
+</blockquote>
-<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>
+<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#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#Ready">Ready</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:
+22.2.6.3.2 [locale.moneypunct.virtuals], para 4 footnote 257 says
</p>
<blockquote><p>
-If a textual representation written via os << x was
-subsequently read via is >> v, then x == v provided that
-there have been no intervening invocations of x or of v.
+<sup>257)</sup> For international
+specializations (second template parameter <tt>true</tt>) this is always four
+characters long, usually three letters and a space.
</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:
+The following objection has been raised:
</p>
<blockquote><p>
-dec: converts integer input or generates integer output
-in decimal base
+The international currency
+symbol is whatever the underlying locale says it is, not necessarily
+four characters long.
</p></blockquote>
<p>
-Proof: The following small program demonstrates the violation
-of requirements (exception safety not fulfilled):
+[Plum ref _222632Y41]
</p>
-<blockquote><pre>#include <cassert>
-#include <ostream>
-#include <iostream>
-#include <iomanip>
-#include <sstream>
-class RanNumEngine {
- int state;
-public:
- RanNumEngine() : state(42) {}
+<p><b>Proposed resolution:</b></p>
+<p>
+Change footnote 253 in 22.2.6.3.2 [locale.moneypunct.virtuals]:
+</p>
- bool operator==(RanNumEngine other) const {
- return state == other.state;
- }
+<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>
- template <typename Ch, typename Tr>
- friend std::basic_ostream<Ch, Tr>& operator<<(std::basic_ostream<Ch, Tr>& os, RanNumEngine engine) {
- Ch old = os.fill(os.widen(' ')); // Sets space character
- std::ios_base::fmtflags f = os.flags();
- os << std::dec << std::left << engine.state; // Adds ios_base::dec|ios_base::left
- os.fill(old); // Undo
- os.flags(f);
- return os;
- }
- template <typename Ch, typename Tr>
- friend std::basic_istream<Ch, Tr>& operator>>(std::basic_istream<Ch, Tr>& is, RanNumEngine& engine) {
- // Uncomment only for the fix.
- //std::ios_base::fmtflags f = is.flags();
- //is >> std::dec;
- is >> engine.state;
- //is.flags(f);
- return is;
- }
-};
-int main() {
- std::stringstream s;
- s << std::setfill('#'); // No problem
- s << std::oct; // Yikes!
- // Here starts para 5 requirements:
- RanNumEngine x;
- s << x;
- RanNumEngine v;
- s >> v;
- assert(x == v); // Fails: 42 == 34
-}
-</pre></blockquote>
+<hr>
+<h3><a name="667"></a>667. <tt>money_get</tt>'s widened minus sign</h3>
+<p><b>Section:</b> 22.2.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
<p>
-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
+22.2.6.1.2 [locale.money.get.virtuals], para 1 says:
</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.
+The result is returned as an integral value
+stored in <tt>units</tt> or as a sequence of digits possibly preceded by a
+minus sign (as produced by <tt>ct.widen(c)</tt> where <tt>c</tt> is '-' or in the range
+from '0' through '9', inclusive) stored in <tt>digits</tt>.
</p></blockquote>
<p>
-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 >> x</tt>" change
+The following
+objection has been raised:
</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>.
+Some implementations interpret this to mean that a facet derived from
+<tt>ctype<wchar_t></tt> can provide its own member <tt>do_widen(char)</tt>
+which produces e.g. <tt>L'@'</tt> for the "widened" minus sign, and that the
+<tt>'@'</tt> symbol will appear in the resulting sequence of digits. Other
+implementations have assumed that one or more places in the standard permit the
+implementation to "hard-wire" <tt>L'-'</tt> as the "widened" minus sign. Are
+both interpretations permissible, or only one?
</p></blockquote>
<p>
-2) In table 98 from 26.4.1.3 [rand.req.eng] in column "pre/post-condition",
-row expression "<tt>os << x</tt>" change
+[Plum ref _222612Y14]
</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
+Furthermore: if <tt>ct.widen('9')</tt> produces <tt>L'X'</tt> (a non-digit), does a
+parse fail if a <tt>'9'</tt> appears in the subject string? [Plum ref _22263Y33]
</p>
-<blockquote><pre>template<class RealType, class UniformRandomNumberGenerator,
- size_t bits>
-result_type generate_canonical(UniformRandomNumberGenerator& g);
-</pre></blockquote>
+<p><i>[
+Kona (2007): Bill and Dietmar to provide proposed wording.
+]</i></p>
-<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><random></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<class RealType<del>, class UniformRandomNumberGenerator</del>, size_t bits<ins>, class UniformRandomNumberGenerator</ins>>
-RealType generate_canonical(UniformRandomNumberGenerator& 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>
+<h3><a name="668"></a>668. <tt>money_get</tt>'s empty minus sign</h3>
+<p><b>Section:</b> 22.2.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-17.4.2.1 [using.headers] states:
+22.2.6.1.2 [locale.money.get.virtuals], para 3 says:
</p>
<blockquote><p>
-A translation unit shall include a header only outside of any
-external declaration or definition, [...]
+If <tt>pos</tt> or <tt>neg</tt> is empty, the sign component is
+optional, and if no sign is detected, the result is given the sign
+that corresponds to the source of the empty string.
</p></blockquote>
<p>
-I see three problems with this requirement:
+The following
+objection has been raised:
</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 <cstddef>
- }
+<blockquote><p>
+A <tt>negative_sign</tt> of "" means "there is no
+way to write a negative sign" not "any null sequence is a negative
+sign, so it's always there when you look for it".
+</p></blockquote>
- static void g()
- {
-# include <stddef.h>
- }
-</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>):
+[Plum ref _222612Y32]
</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><i>[
+Kona (2007): Bill to provide proposed wording and interpretation of existing wording.
+]</i></p>
+
+
<p><b>Proposed resolution:</b></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>
+<h3><a name="669"></a>669. Equivalent postive and negative signs in <tt>money_get</tt></h3>
+<p><b>Section:</b> 22.2.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-The header <tt><functional></tt> synopsis in 20.5 [function.objects]
-contains the following two free comparison operator templates
-for the <tt>function</tt> class template
+22.2.6.1.2 [locale.money.get.virtuals], para 3 sentence 4 says:
</p>
-<blockquote><pre>template<class Function1, class Function2>
-void operator==(const function<Function1>&, const function<Function2>&);
-template<class Function1, class Function2>
-void operator!=(const function<Function1>&, const function<Function2>&);
-</pre></blockquote>
+<blockquote><p>
+If the first character of <tt>pos</tt> is equal to the first character of <tt>neg</tt>,
+or if both strings are empty, the result is given a positive sign.
+</p></blockquote>
<p>
-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.
+One interpretation is that an input sequence must match either the
+positive pattern or the negative pattern, and then in either event it
+is interpreted as positive. The following objections has been raised:
</p>
+<blockquote><p>
+The input can successfully match only a positive sign, so the negative
+pattern is an unsuccessful match.
+</p></blockquote>
-<p><b>Proposed resolution:</b></p>
<p>
-Remove the above mentioned two function templates from
-the header <tt><functional></tt> synopsis (20.5 [function.objects])
+[Plum ref _222612Y34, 222612Y51b]
</p>
-<blockquote><pre><del>template<class Function1, class Function2>
-void operator==(const function<Function1>&, const function<Function2>&);
-template<class Function1, class Function2>
-void operator!=(const function<Function1>&, const function<Function2>&);</del>
-</pre></blockquote>
+<p><i>[
+Bill to provide proposed wording and interpretation of existing wording.
+]</i></p>
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
-<hr>
-<h3><a name="659"></a>659. istreambuf_iterator should have an operator->()</h3>
-<p><b>Section:</b> 24.5.3 [istreambuf.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</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>Discussion:</b></p>
-<p>
-Greg Herlihy has clearly demonstrated that a user defined input
-iterator should have an operator->(), even if its
-value type is a built-in type (comp.std.c++, "Re: Should any iterator
-have an operator->() in C++0x?", March 2007). And as Howard
-Hinnant remarked in the same thread that the input iterator
-<tt>istreambuf_iterator</tt> doesn't have one, this must be a
-defect!
-</p>
-<p>
-Based on Greg's example, the following code demonstrates the issue:
-</p><pre> #include <iostream>
- #include <fstream>
- #include <streambuf>
-
- typedef char C;
- int main ()
- {
- std::ifstream s("filename", std::ios::in);
- std::istreambuf_iterator<char> i(s);
-
- (*i).~C(); // This is well-formed...
- i->~C(); // ... so this should be supported!
- }
-</pre>
-<p>
-Of course, operator-> is also needed when the value_type of
-istreambuf_iterator is a class.
-</p>
-<p>
-The operator-> could be implemented in various ways. For instance,
-by storing the current value inside the iterator, and returning its
-address. Or by returning a proxy, like operator_arrow_proxy, from
-<a href="http://www.boost.org/boost/iterator/iterator_facade.hpp">http://www.boost.org/boost/iterator/iterator_facade.hpp</a>
-</p>
-<p>
-I hope that the resolution of this issue will contribute to getting a
-clear and consistent definition of iterator concepts.
-</p>
-<p><b>Proposed resolution:</b></p>
+<hr>
+<h3><a name="670"></a>670. <tt>money_base::pattern</tt> and <tt>space</tt></h3>
+<p><b>Section:</b> 22.2.6.3 [locale.moneypunct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
+<p><b>Discussion:</b></p>
<p>
-Add to the synopsis in 24.5.3 [istreambuf.iterator]:
+22.2.6.3 [locale.moneypunct], para 2 says:
</p>
-<blockquote><pre>charT operator*() const;
-<ins>pointer operator->() const;</ins>
-istreambuf_iterator<charT,traits>& operator++();
-</pre></blockquote>
+<blockquote><p>
+The value <tt>space</tt> indicates that at least one space is required at
+that position.
+</p></blockquote>
<p>
-Change 24.5.3 [istreambuf.iterator], p1:
+The following objection has been raised:
</p>
<blockquote><p>
-The class template <tt>istreambuf_iterator</tt> reads successive
-characters from the <tt>streambuf</tt> for which it was constructed.
-<tt>operator*</tt> provides access to the current input character, if
-any. <ins><tt>operator-></tt> may return a proxy.</ins> Each time
-<tt>operator++</tt> is evaluated, the iterator advances to the next
-input character. If the end of stream is reached
-(<tt>streambuf_type::sgetc()</tt> returns <tt>traits::eof()</tt>), the
-iterator becomes equal to the end of stream iterator value. The default
-constructor <tt>istreambuf_iterator()</tt> and the constructor
-<tt>istreambuf_iterator(0)</tt> both construct an end of stream iterator
-object suitable for use as an end-of-range.
+Whitespace is optional when matching space. (See 22.2.6.1.2 [locale.money.get.virtuals], para 2.)
</p></blockquote>
-
-
-
-
-
-<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 ... (|, &, ^) 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
-<functional> synopsis:</p>
-<blockquote>
- <pre>template <class T> struct bit_and;
-template <class T> struct bit_or;
-template <class T> 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 <class T> struct bit_and : binary_function<T,T,T> {
- T operator()(const T& x , const T& y ) const;
-};</pre>
- <blockquote>
- <p><code>operator()</code> returns<code> x & y</code> .</p>
- </blockquote>
- <pre>template <class T> struct bit_or : binary_function<T,T,T> {
- T operator()(const T& x , const T& y ) const;
-};</pre>
- <blockquote>
- <p><code>operator()</code> returns <code>x | y</code> .</p>
- </blockquote>
- <pre>template <class T> struct bit_xor : binary_function<T,T,T> {
- T operator()(const T& x , const T& y ) const;
-};</pre>
- <blockquote>
- <p><code>operator()</code> returns <code>x ^ y</code> .</p>
- </blockquote>
-</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>
- <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>Discussion:</b></p>
<p>
-To the more drastic changes of 27.6.1.2.2 [istream.formatted.arithmetic] in the current draft N2134 belong
-the explicit description of the extraction of the types short and int in
-terms of as-if code fragments.
+[Plum ref _22263Y22]
</p>
-<ol>
-<li>
-The corresponding as-if extractions in paragraph 2 and 3 will never
-result in a change of the operator>> argument val, because the
-contents of the local variable lval is in no case written into val.
-Furtheron both fragments need a currently missing parentheses in the
-beginning of the if-statement to be valid C++.
-</li>
-<li>I would like to ask whether the omission of a similar explicit
-extraction of unsigned short and unsigned int in terms of long -
-compared to their corresponding new insertions, as described in
-27.6.2.6.2 [ostream.inserters.arithmetic], is a deliberate decision or
-an
-oversight.
-</li>
-</ol>
+<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>
-<ol>
-<li>
-<p>
-In 27.6.1.2.2 [istream.formatted.arithmetic]/2 change the current as-if code fragment
-</p>
-<blockquote><pre>typedef num_get<charT,istreambuf_iterator<charT,traits> > numget;
-iostate err = 0;
-long lval;
-use_facet<numget>(loc).get(*this, 0, *this, err, lval );
-if (err == 0) <ins>{</ins>
- <del>&&</del> <ins>if</ins> (lval < numeric_limits<short>::min() || numeric_limits<short>::max() < lval)<del>)</del>
- err = ios_base::failbit;
- <ins>else
- val = static_cast<short>(lval);
-}</ins>
-setstate(err);
-</pre></blockquote>
+
+<p><b>Proposed resolution:</b></p>
<p>
-Similarily in 27.6.1.2.2 [istream.formatted.arithmetic]/3 change the current as-if fragment
</p>
-<blockquote><pre>typedef num_get<charT,istreambuf_iterator<charT,traits> > numget;
-iostate err = 0;
-long lval;
-use_facet<numget>(loc).get(*this, 0, *this, err, lval );
-if (err == 0) <ins>{</ins>
- <del>&&</del> <ins>if</ins> (lval < numeric_limits<int>::min() || numeric_limits<int>::max() < lval)<del>)</del>
- err = ios_base::failbit;
- <ins>else
- val = static_cast<int>(lval);
-}</ins>
-setstate(err);
-</pre></blockquote>
-</li>
-<li>
----
-</li>
-</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>
+<h3><a name="671"></a>671. precision of hexfloat</h3>
+<p><b>Section:</b> 22.2.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
+ <b>Submitter:</b> John Salmon <b>Date:</b> 2007-04-20</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.put.virtuals">issues</a> in [facet.num.put.virtuals].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-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.
+I am trying to understand how TR1 supports hex float (%a) output.
</p>
<p>
-Here is a quote from <i>"The C++ Programming Language (Special Edition)"</i>
-by B. Stroustrup (Section D.4.2.3, pg. 897):
+As far as I can tell, it does so via the following:
</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>>i>>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 >> i;
- if (cin.fail())
- // can the value of i be trusted?
- // what does it mean if i == old_i?
- // ...
-</pre>
+8.15 Additions to header <locale> [tr.c99.locale]
+</p>
<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.
+In subclause 22.2.2.2.2 [facet.num.put.virtuals], Table 58 Floating-point conversions, after
+the line:
+floatfield == ios_base::scientific %E
</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
<p>
-Change 22.2.2.1.2 [facet.num.get.virtuals]:
+add the two lines:
</p>
-
-<blockquote>
+<blockquote><pre>floatfield == ios_base::fixed | ios_base::scientific && !uppercase %a
+floatfield == ios_base::fixed | ios_base::scientific %A 2
+</pre></blockquote>
<p>
-<b>Stage 3:</b> The result of stage 2 processing can be one of
+[Note: The additional requirements on print and scan functions, later
+in this clause, ensure that the print functions generate hexadecimal
+floating-point fields with a %a or %A conversion specifier, and that
+the scan functions match hexadecimal floating-point fields with a %g
+conversion specifier. end note]
</p>
-<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<numpunct<charT> >(<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>
+Following the thread, in 22.2.2.2.2 [facet.num.put.virtuals], we find:
</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
+For conversion from a floating-point type, if (flags & fixed) != 0 or
+if str.precision() > 0, then str.precision() is specified in the
+conversion specification.
</p>
-
-<blockquote><p>
--5- Complexity requirements specified in the library
-clauses are upper bounds, and implementations that provide better
-complexity guarantees satisfy the requirements.
-</p></blockquote>
-
<p>
-The following
-objection has been raised:
+This would seem to imply that when floatfield == fixed|scientific, the
+precision of the conversion specifier is to be taken from
+str.precision(). Is this really what's intended? I sincerely hope
+that I'm either missing something or this is an oversight. Please
+tell me that the committee did not intend to mandate that hex floats
+(and doubles) should by default be printed as if by %.6a.
</p>
-<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. Unless
-or until the Library group standardizes specific hard-and-fast
-formulae, we regard all the complexity requirements as subject to a
-"fudge factor" without any intrinsic upper bound.
-</p></blockquote>
+<p><i>[
+Howard: I think the fundamental issue we overlooked was that with %f,
+%e, %g, the default precision was always 6. With %a the default
+precision is not 6, it is infinity. So for the first time, we need to
+distinguish between the default value of precision, and the precision
+value 6.
+]</i></p>
+
-<p>
-[Plum ref
-_23213Y31 etc]
-</p>
<p><b>Proposed resolution:</b></p>
</p>
+<p><i>[
+Kona (2007): Robert volunteers to propose wording.
+]</i></p>
+
+
<hr>
-<h3><a name="664"></a>664. <tt>do_unshift</tt> for <tt>codecvt<char, char, mbstate_t></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>
- <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>
+<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#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#Review">Review</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>):
+The current <tt>Swappable</tt> is:
</p>
-<blockquote><p>
-<i>Effects:</i> Places characters starting at to that should be appended to
-terminate a sequence when the current <tt>stateT</tt> is given by
-<tt><i>state</i></tt>.<sup>237)</sup> Stores no more than <tt>(<i>to_limit</i> -
-<i>to</i>)</tt> destination elements, and leaves the <tt><i>to_next</i></tt>
-pointer pointing one beyond the last element successfully stored.
-<em><tt>codecvt<char, char, mbstate_t></tt> stores no characters.</em>
-</p></blockquote>
-
+<blockquote>
+<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,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 following objection has been raised:
+The Swappable requirement is met by satisfying one or more of the following conditions:
</p>
-
-<blockquote><p>
-Since the C++ Standard permits a nontrivial conversion for the required
-instantiations of <tt>codecvt</tt>, it is overly restrictive to say that
-<tt>do_unshift</tt> must store no characters and return <tt>noconv</tt>.
-</p></blockquote>
+<ul>
+<li>
+<tt>T</tt> is Swappable if <tt>T</tt> satisfies the <tt>CopyConstructible</tt> requirements (Table 34)
+and the <tt>CopyAssignable</tt> requirements (Table 36);
+</li>
+<li>
+<tt>T</tt> is Swappable if a namespace scope function named <tt>swap</tt> exists in the same
+namespace as the definition of <tt>T</tt>, such that the expression <tt>swap(t,u)</tt> is valid
+and has the semantics described in this table.
+</li>
+</ul>
+</td></tr>
+</tbody></table>
+</blockquote>
<p>
-[Plum ref _222152Y50]
+With the passage of rvalue reference into the language, <tt>Swappable</tt> needs to be updated to
+require only <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>. This is a minimum.
</p>
-
-<p><b>Proposed resolution:</b></p>
<p>
+Additionally we may want to support proxy references such that the following code is acceptable:
</p>
+<blockquote><pre>namespace Mine {
+template <class T>
+struct proxy {...};
+template <class T>
+struct proxied_iterator
+{
+ typedef T value_type;
+ typedef proxy<T> reference;
+ reference operator*() const;
+ ...
+};
+struct A
+{
+ // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
+ void swap(A&);
+ ...
+};
+
+void swap(A&, A&);
+void swap(proxy<A>, A&);
+void swap(A&, proxy<A>);
+void swap(proxy<A>, proxy<A>);
+
+} // Mine
+
+...
+
+Mine::proxied_iterator<Mine::A> i(...)
+Mine::A a;
+swap(*i1, a);
+</pre></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>
- <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>Discussion:</b></p>
<p>
-22.2.1.4.2 [locale.codecvt.virtuals], para 8 says:
+I.e. here is a call to <tt>swap</tt> which the user enables swapping between a proxy to a class and the class
+itself. We do not need to anything in terms of implementation except not block their way with overly
+constrained concepts. That is, the <tt>Swappable</tt> concept should be expanded to allow swapping
+between two different types for the case that one is binding to a user-defined <tt>swap</tt>.
</p>
-<blockquote><p>
-<tt>codecvt<char,char,mbstate_t></tt>, returns <tt>noconv</tt>.
-</p></blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
<p>
-The following objection has been raised:
+Change 20.1.1 [utility.arg.requirements]:
</p>
-<blockquote><p>
-Despite what the C++ Standard
-says, <tt>unshift</tt> can't always return <tt>noconv</tt> for the default facets, since
-they can be nontrivial. At least one implementation does whatever the
-C functions do.
-</p></blockquote>
+<blockquote>
<p>
-[Plum ref _222152Y62]
+-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> 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>; and <tt>rv</tt> is a non-<tt>const</tt>
+rvalue of type <tt>T</tt>.
</p>
-
-<p><b>Proposed resolution:</b></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,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 <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> if a namespace scope function named
+<tt>swap</tt> exists in the same namespace as the definition of
+<tt>T</tt>, such that the expression
+<tt>swap(t,u)</tt> is valid and has the
+semantics described in this table.
+</li>
+</ul>
+</td></tr>
+</tbody></table>
+</blockquote>
+
+
+
+<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>
<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>
- <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>
+<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#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#Open">Open</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-22.2.6.3.2 [locale.moneypunct.virtuals], para 4 footnote 257 says
+Since the publication of
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a>
+there have been a few small but significant advances which should be included into
+<tt>unique_ptr</tt>. There exists a
+<a href="http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html">reference implmenation</a>
+for all of these changes.
</p>
-<blockquote><p>
-<sup>257)</sup> For international
-specializations (second template parameter <tt>true</tt>) this is always four
-characters long, usually three letters and a space.
-</p></blockquote>
+<ul>
+<li>
<p>
-The following objection has been raised:
+Even though <tt>unique_ptr<void></tt> is not a valid use case (unlike for <tt>shared_ptr<void></tt>),
+unexpected cases to crop up which require the instantiation of the interface of <tt>unique_ptr<void></tt>
+even if it is never used. For example see
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">LWG 541</a> for how this accidently
+happened to <tt>auto_ptr</tt>. I believe the most robust way to protect <tt>unique_ptr</tt> against this
+type of failure is to augment the return type of <tt>unique_ptr<T>:operator*()</tt> with
+<tt>add_lvalue_reference<T>::type</tt>. This means that given an instantiated <tt>unique_ptr<void></tt>
+the act of dereferencing it will simply return <tt>void</tt> instead of causing a compile time failure.
+This is simpler than creating a <tt>unique_ptr<void></tt> specialization which isn't robust in the
+face of <tt><i>cv-</i></tt>qualified <tt>void</tt> types.
</p>
-<blockquote><p>
-The international currency
-symbol is whatever the underlying locale says it is, not necessarily
-four characters long.
-</p></blockquote>
-
<p>
-[Plum ref _222632Y41]
+This resolution also supports instantiations such as <tt>unique_ptr<void, free_deleter></tt>
+which could be very useful to the client.
</p>
+</li>
-<p><b>Proposed resolution:</b></p>
+<li>
+<p>
+Efforts have been made to better support containers and smart pointers in shared
+memory contexts. One of the key hurdles in such support is not assuming that a
+pointer type is actually a <tt>T*</tt>. This can easily be accomplished
+for <tt>unique_ptr</tt> by having the deleter define the pointer type:
+<tt>D::pointer</tt>. Furthermore this type can easily be defaulted to
+<tt>T*</tt> should the deleter <tt>D</tt> choose not to define a pointer
+type (reference implementation
+<a href="http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html">here</a>).
+This change has no run time overhead. It has no interface overhead on
+authors of custom delter types. It simply allows (but not requires)
+authors of custom deleter types to define a smart pointer for the
+storage type of <tt>unique_ptr</tt> if they find such functionality
+useful. <tt>std::default_delete</tt> is an example of a deleter which
+defaults <tt>pointer</tt> to <tt>T*</tt> by simply ignoring this issue
+and not including a <tt>pointer typedef</tt>.
+</p>
+</li>
+
+<li>
<p>
+When the deleter type is a function pointer then it is unsafe to construct
+a <tt>unique_ptr</tt> without specifying the function pointer in the constructor.
+This case is easy to check for with a <tt>static_assert</tt> assuring that the
+deleter is not a pointer type in those constructors which do not accept deleters.
</p>
+<blockquote><pre>unique_ptr<A, void(*)(void*)> p(new A); // error, no function given to delete the pointer!
+</pre></blockquote>
+</li>
+</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>
-<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>
- <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>Discussion:</b></p>
-<p>
-22.2.6.1.2 [locale.money.get.virtuals], para 1 says:
-</p>
-<blockquote><p>
-The result is returned as an integral value
-stored in <tt>units</tt> or as a sequence of digits possibly preceded by a
-minus sign (as produced by <tt>ct.widen(c)</tt> where <tt>c</tt> is '-' or in the range
-from '0' through '9', inclusive) stored in <tt>digits</tt>.
-</p></blockquote>
+<p><i>[
+Post Kona: Howard adds example user code related to the first bullet:
+]</i></p>
-<p>
-The following
-objection has been raised:
-</p>
-<blockquote><p>
-Some implementations interpret this to mean that a facet derived from
-<tt>ctype<wchar_t></tt> can provide its own member <tt>do_widen(char)</tt>
-which produces e.g. <tt>L'@'</tt> for the "widened" minus sign, and that the
-<tt>'@'</tt> symbol will appear in the resulting sequence of digits. Other
-implementations have assumed that one or more places in the standard permit the
-implementation to "hard-wire" <tt>L'-'</tt> as the "widened" minus sign. Are
-both interpretations permissible, or only one?
-</p></blockquote>
+<blockquote>
+<pre>void legacy_code(void*, std::size_t);
-<p>
-[Plum ref _222612Y14]
-</p>
+void foo(std::size_t N)
+{
+ std::unique_ptr<void, void(*)(void*)> ptr(std::malloc(N), std::free);
+ legacy_code(ptr.get(), N);
+} // unique_ptr used for exception safety purposes
+</pre>
+</blockquote>
<p>
-Furthermore: if <tt>ct.widen('9')</tt> produces <tt>L'X'</tt> (a non-digit), does a
-parse fail if a <tt>'9'</tt> appears in the subject string? [Plum ref _22263Y33]
+I.e. <tt>unique_ptr<void></tt> <i>is</i> a useful tool that we don't want
+to disable with concepts. The only part of <tt>unique_ptr<void></tt> we
+want to disable (with concepts or by other means) are the two member functions:
</p>
+<blockquote><pre>T& operator*() const;
+T* operator->() const;
+</pre></blockquote>
+
+
<p><b>Proposed resolution:</b></p>
-<p>
-</p>
+<p><i>[
+I am grateful for the generous aid of Peter Dimov and Ion Gaztañaga in helping formulate and review
+the proposed resolutions below.
+]</i></p>
+<ul>
+<li>
+<p>
+Change 20.6.5.2 [unique.ptr.single]:
+</p>
+
+<blockquote><pre>template <class T, class D = default_delete<T>> class unique_ptr {
+ ...
+ <del>T&</del> <ins>typename add_lvalue_reference<T>::type</ins> operator*() const;
+ ...
+};
+</pre></blockquote>
-<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>
- <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>Discussion:</b></p>
<p>
-22.2.6.1.2 [locale.money.get.virtuals], para 3 says:
+Change 20.6.5.2.4 [unique.ptr.single.observers]:
</p>
-<blockquote><p>
-If <tt>pos</tt> or <tt>neg</tt> is empty, the sign component is
-optional, and if no sign is detected, the result is given the sign
-that corresponds to the source of the empty string.
-</p></blockquote>
+<blockquote><pre><del>T&</del> <ins>typename add_lvalue_reference<T>::type</ins> operator*() const;
+</pre></blockquote>
+
+</li>
+<li>
<p>
-The following
-objection has been raised:
+Change 20.6.5.2 [unique.ptr.single]:
</p>
-<blockquote><p>
-A <tt>negative_sign</tt> of "" means "there is no
-way to write a negative sign" not "any null sequence is a negative
-sign, so it's always there when you look for it".
-</p></blockquote>
+<blockquote><pre>template <class T, class D = default_delete<T>> class unique_ptr {
+public:
+ <ins>typedef <i>implementation (see description below)</i> pointer;</ins>
+ ...
+ explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p);
+ ...
+ unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined (see description below)</i> d);
+ unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined (see description below)</i> d);
+ ...
+ <del>T*</del> <ins>pointer</ins> operator->() const;
+ <del>T*</del> <ins>pointer</ins> get() const;
+ ...
+ <del>T*</del> <ins>pointer</ins> release();
+ void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
+};
+</pre></blockquote>
<p>
-[Plum ref _222612Y32]
+<ins>
+-3- If the type <tt>remove_reference<D>::type::pointer</tt>
+exists, then <tt>unique_ptr<T, D>::pointer</tt> is a typedef to
+<tt>remove_reference<D>::type::pointer</tt>. Otherwise
+<tt>unique_ptr<T, D>::pointer</tt> is a typedef to <tt>T*</tt>.
+The type <tt>unique_ptr<T, D>::pointer</tt> must be <tt>CopyConstructible</tt>
+and <tt>CopyAssignable</tt>.
+</ins>
</p>
-
-<p><b>Proposed resolution:</b></p>
<p>
+Change 20.6.5.2.1 [unique.ptr.single.ctor]:
</p>
+<blockquote><pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);
+...
+unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
+unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
+...
+unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A& d);
+unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&& d);
+...
+unique_ptr(<del>T*</del> <ins>pointer</ins> p, A& d);
+unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&& d);
+...
+unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A& d);
+unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A&& d);
+...
+</pre></blockquote>
+<p>
+-23- <i>Requires:</i> If <tt>D</tt> is not a reference type,
+construction of the deleter <tt>D</tt> from an rvalue of type <tt>E</tt>
+must be well formed and not throw an exception. If <tt>D</tt> is a
+reference type, then <tt>E</tt> must be the same type as <tt>D</tt>
+(diagnostic required). <del><tt>U*</tt></del> <ins><tt>unique_ptr<U,E>::pointer</tt></ins>
+must be implicitly convertible to <del><tt>T*</tt></del>
+<ins>pointer</ins>.
+</p>
+<p>
+-25- <i>Postconditions:</i> <tt>get() == value u.get()</tt> had before
+the construction, modulo any required offset adjustments resulting from
+the cast from <del><tt>U*</tt></del>
+<ins><tt>unique_ptr<U,E>::pointer</tt></ins> to <del><tt>T*</tt></del>
+<ins>pointer</ins>. <tt>get_deleter()</tt> returns a reference to the
+internally stored deleter which was constructed from
+<tt>u.get_deleter()</tt>.
+</p>
-
-<hr>
-<h3><a name="669"></a>669. Equivalent postive and negative signs in <tt>money_get</tt></h3>
-<p><b>Section:</b> 22.2.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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#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>Discussion:</b></p>
<p>
-22.2.6.1.2 [locale.money.get.virtuals], para 3 sentence 4 says:
+Change 20.6.5.2.3 [unique.ptr.single.asgn]:
</p>
-<blockquote><p>
-If the first character of <tt>pos</tt> is equal to the first character of <tt>neg</tt>,
-or if both strings are empty, the result is given a positive sign.
-</p></blockquote>
+<blockquote>
+<p>
+-8- <i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
+<tt>D</tt> must not throw an exception. <del><tt>U*</tt></del>
+<ins><tt>unique_ptr<U,E>::pointer</tt></ins> must be implicitly
+convertible to <del><tt>T*</tt></del> <ins>pointer</ins>.
+</p>
+</blockquote>
<p>
-One interpretation is that an input sequence must match either the
-positive pattern or the negative pattern, and then in either event it
-is interpreted as positive. The following objections has been raised:
+Change 20.6.5.2.4 [unique.ptr.single.observers]:
</p>
-<blockquote><p>
-The input can successfully match only a positive sign, so the negative
-pattern is an unsuccessful match.
-</p></blockquote>
+<blockquote>
+<pre><del>T*</del> <ins>pointer</ins> operator->() const;</pre>
+...
+<pre><del>T*</del> <ins>pointer</ins> get() const;</pre>
+</blockquote>
<p>
-[Plum ref _222612Y34, 222612Y51b]
+Change 20.6.5.2.5 [unique.ptr.single.modifiers]:
</p>
+<blockquote>
+<pre><del>T*</del> <ins>pointer</ins> release();</pre>
+...
+<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);</pre>
+</blockquote>
-<p><b>Proposed resolution:</b></p>
<p>
+Change 20.6.5.3 [unique.ptr.runtime]:
</p>
+<blockquote><pre>template <class T, class D> class unique_ptr<T[], D> {
+public:
+ <ins>typedef <i>implementation</i> pointer;</ins>
+ ...
+ explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p);
+ ...
+ unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
+ unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
+ ...
+ <del>T*</del> <ins>pointer</ins> get() const;
+ ...
+ <del>T*</del> <ins>pointer</ins> release();
+ void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
+};
+</pre></blockquote>
+<p>
+Change 20.6.5.3.1 [unique.ptr.runtime.ctor]:
+</p>
+<blockquote>
+<pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);
+unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
+unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
+</pre>
+<p>
+These constructors behave the same as in the primary template except
+that they do not accept pointer types which are convertible to
+<del><tt>T*</tt></del> <ins><tt>pointer</tt></ins>. [<i>Note:</i> One
+implementation technique is to create private templated overloads of
+these members. <i>-- end note</i>]
+</p>
+</blockquote>
-<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>
- <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>Discussion:</b></p>
<p>
-22.2.6.3 [locale.moneypunct], para 2 says:
+Change 20.6.5.3.3 [unique.ptr.runtime.modifiers]:
</p>
-<blockquote><p>
-The value <tt>space</tt> indicates that at least one space is required at
-that position.
-</p></blockquote>
+<blockquote>
+<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
+</pre>
<p>
-The following objection has been raised:
+-1- <i>Requires:</i> Does not accept pointer types which are convertible
+to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (diagnostic
+required). [<i>Note:</i> One implementation technique is to create a private
+templated overload. <i>-- end note</i>]
</p>
-
-<blockquote><p>
-Whitespace is optional when matching space. (See 22.2.6.1.2 [locale.money.get.virtuals], para 2.)
-</p></blockquote>
+</blockquote>
<p>
-[Plum ref _22263Y22]
+Change 20.6.5.4 [unique.ptr.compiletime]:
</p>
+<blockquote><pre>template <class T, class D, size_t N> class unique_ptr<T[N], D> {
+public:
+ <ins>typedef <i>implementation</i> pointer;</ins>
+ ...
+ explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p);
+ ...
+ unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
+ unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
+ ...
+ <del>T*</del> <ins>pointer</ins> get() const;
+ ...
+ <del>T*</del> <ins>pointer</ins> release();
+ void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
+};
+</pre></blockquote>
-<p><b>Proposed resolution:</b></p>
<p>
+Change 20.6.5.4.3 [unique.ptr.compiletime.modifiers]:
</p>
+<blockquote>
+<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
+</pre>
+<p>
+-1- <i>Requires:</i> Does not accept pointer types which are convertible
+to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (dignostic required). [<i>Note:</i> One implementation
+technique is to create a private templated overload. <i>--end note</i>]
+</p>
+</blockquote>
+</li>
+
+<li>
-<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>
- <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>Discussion:</b></p>
<p>
-I am trying to understand how TR1 supports hex float (%a) output.
+Change 20.6.5.2.1 [unique.ptr.single.ctor]:
</p>
+
+<blockquote>
+<pre>unique_ptr();</pre>
+<blockquote>
<p>
-As far as I can tell, it does so via the following:
+<i>Requires:</i> <tt>D</tt> must be default constructible, and that
+construction must not throw an exception. <tt>D</tt> must not be a
+reference type <ins>or pointer type (diagnostic required)</ins>.
</p>
+</blockquote>
+<pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);</pre>
+<blockquote>
<p>
-8.15 Additions to header <locale> [tr.c99.locale]
+<i>Requires:</i> The expression <tt>D()(p)</tt> must be well formed.
+The default constructor of <tt>D</tt> must not throw an exception.
+<tt>D</tt> must not be a reference type <ins>or pointer type (diagnostic
+required)</ins>.
</p>
+</blockquote>
+</blockquote>
+
<p>
-In subclause 22.2.2.2.2 [facet.num.put.virtuals], Table 58 Floating-point conversions, after
-the line:
-floatfield == ios_base::scientific %E
-</p>
-<p>
-add the two lines:
-</p>
-<blockquote><pre>floatfield == ios_base::fixed | ios_base::scientific && !uppercase %a
-floatfield == ios_base::fixed | ios_base::scientific %A 2
-</pre></blockquote>
-<p>
-[Note: The additional requirements on print and scan functions, later
-in this clause, ensure that the print functions generate hexadecimal
-floating-point fields with a %a or %A conversion specifier, and that
-the scan functions match hexadecimal floating-point fields with a %g
-conversion specifier. end note]
-</p>
-<p>
-Following the thread, in 22.2.2.2.2 [facet.num.put.virtuals], we find:
+Change 20.6.5.2.1 [unique.ptr.single.ctor]:
</p>
+
+<blockquote>
+<pre>unique_ptr();</pre>
+<blockquote>
<p>
-For conversion from a floating-point type, if (flags & fixed) != 0 or
-if str.precision() > 0, then str.precision() is specified in the
-conversion specification.
+<i>Requires:</i> <tt>D</tt> must be default constructible, and that
+construction must not throw an exception. <tt>D</tt> must not be a
+reference type <ins>or pointer type (diagnostic required)</ins>.
</p>
+</blockquote>
+<pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);</pre>
+<blockquote>
<p>
-This would seem to imply that when floatfield == fixed|scientific, the
-precision of the conversion specifier is to be taken from
-str.precision(). Is this really what's intended? I sincerely hope
-that I'm either missing something or this is an oversight. Please
-tell me that the committee did not intend to mandate that hex floats
-(and doubles) should by default be printed as if by %.6a.
+<i>Requires:</i> The expression <tt>D()(p)</tt> must be well formed.
+The default constructor of <tt>D</tt> must not throw an exception.
+<tt>D</tt> must not be a reference type <ins>or pointer type (diagnostic
+required)</ins>.
</p>
+</blockquote>
+</blockquote>
-<p><i>[
-Howard: I think the fundamental issue we overlooked was that with %f,
-%e, %g, the default precision was always 6. With %a the default
-precision is not 6, it is infinity. So for the first time, we need to
-distinguish between the default value of precision, and the precision
-value 6.
-]</i></p>
-
-
+</li>
+</ul>
-<p><b>Proposed resolution:</b></p>
-<p>
-</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>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-04</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>
+<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#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#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-The current <tt>Swappable</tt> is:
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a> does not propose
+any changes to <tt>shared_ptr</tt>. It needs to be updated to use a rvalue reference where appropriate
+and to interoperate with <tt>unique_ptr</tt> as it does with <tt>auto_ptr</tt>.
</p>
-<blockquote>
-<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,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><b>Proposed resolution:</b></p>
+
<p>
-The Swappable requirement is met by satisfying one or more of the following conditions:
+Change 20.6.6.2 [util.smartptr.shared] as follows:
</p>
-<ul>
-<li>
-<tt>T</tt> is Swappable if <tt>T</tt> satisfies the <tt>CopyConstructible</tt> requirements (Table 34)
-and the <tt>CopyAssignable</tt> requirements (Table 36);
-</li>
-<li>
-<tt>T</tt> is Swappable if a namespace scope function named <tt>swap</tt> exists in the same
-namespace as the definition of <tt>T</tt>, such that the expression <tt>swap(t,u)</tt> is valid
-and has the semantics described in this table.
-</li>
-</ul>
-</td></tr>
-</tbody></table>
+
+<blockquote>
+<pre>template<class Y> explicit shared_ptr(auto_ptr<Y><del>&</del><ins>&&</ins> r);
+<ins>template<class Y, class D> explicit shared_ptr(const unique_ptr<Y,D>& r) = delete;
+template<class Y, class D> explicit shared_ptr(unique_ptr<Y,D>&& r);</ins>
+...
+template<class Y> shared_ptr& operator=(auto_ptr<Y><del>&</del><ins>&&</ins> r);
+<ins>template<class Y, class D> shared_ptr& operator=(const unique_ptr<Y,D>& r) = delete;
+template<class Y, class D> shared_ptr& operator=(unique_ptr<Y,D>&& r);</ins></pre>
</blockquote>
<p>
-With the passage of rvalue reference into the language, <tt>Swappable</tt> needs to be updated to
-require only <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>. This is a minimum.
+Change 20.6.6.2.1 [util.smartptr.shared.const] as follows:
</p>
+<blockquote>
+<pre><ins>template<class Y> shared_ptr(auto_ptr<Y><del>&</del><ins>&&</ins> r);</ins></pre>
+</blockquote>
+
<p>
-Additionally we may want to support proxy references such that the following code is acceptable:
+Add to 20.6.6.2.1 [util.smartptr.shared.const]:
</p>
-<blockquote><pre>namespace Mine {
-
-template <class T>
-struct proxy {...};
-
-template <class T>
-struct proxied_iterator
-{
- typedef T value_type;
- typedef proxy<T> reference;
- reference operator*() const;
- ...
-};
-
-struct A
-{
- // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
- void swap(A&);
- ...
-};
-
-void swap(A&, A&);
-void swap(proxy<A>, A&);
-void swap(A&, proxy<A>);
-void swap(proxy<A>, proxy<A>);
+<blockquote>
+<pre><ins>template<class Y, class D> shared_ptr(unique_ptr<Y, D>&& r);</ins></pre>
+<blockquote>
-} // Mine
+<p><ins>
+<i>Effects:</i> Equivalent to <tt>shared_ptr( r.release(), r.get_deleter() )</tt> when <tt>D</tt> is
+ not a reference type, <tt>shared_ptr( r.release(), ref( r.get_deleter() ) )</tt>
+ otherwise.
+</ins></p>
-...
+<p><ins>
+<i>Exception safety:</i> If an exception is thrown, the constructor has no effect.
+</ins></p>
+</blockquote>
-Mine::proxied_iterator<Mine::A> i(...)
-Mine::A a;
-swap(*i1, a);
-</pre></blockquote>
+</blockquote>
<p>
-I.e. here is a call to <tt>swap</tt> which the user enables swapping between a proxy to a class and the class
-itself. We do not need to anything in terms of implementation except not block their way with overly
-constrained concepts. That is, the <tt>Swappable</tt> concept should be expanded to allow swapping
-between two different types for the case that one is binding to a user-defined <tt>swap</tt>.
+Change 20.6.6.2.3 [util.smartptr.shared.assign] as follows:
</p>
-
-
-<p><b>Proposed resolution:</b></p>
+<blockquote>
+<pre>template<class Y> shared_ptr& operator=(auto_ptr<Y><del>&</del><ins>&&</ins> r);</pre>
+</blockquote>
<p>
-Change 20.1.1 [utility.arg.requirements]:
+Add to 20.6.6.2.3 [util.smartptr.shared.assign]:
</p>
<blockquote>
+<pre><ins>template<class Y, class D> shared_ptr& operator=(unique_ptr<Y,D>&& r);</ins></pre>
-<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>; 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(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 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>s</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>
+<p><ins>
+-4- <i>Effects:</i> Equivalent to <tt>shared_ptr(std::move(r)).swap(*this)</tt>.
+</ins></p>
+<p><ins>
+-5- <i>Returns:</i> <tt>*this</tt>.
+</ins></p>
</blockquote>
-<p><i>[Some editorial issues are also cleaned up by this resolution.]</i></p>
-
+</blockquote>
-<p>
-</p>
+<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="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>
- <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>
+<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#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#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-Since the publication of
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a>
-there have been a few small but significant advances which should be included into
-<tt>unique_ptr</tt>. There exists a
-<a href="http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html">reference implmenation</a>
-for all of these changes.
+James Hopkin pointed out to me that if <tt>vector<T></tt> move assignment is O(1)
+(just a <tt>swap</tt>) then containers such as <tt>vector<shared_ptr<ostream>></tt> might have
+the wrong semantics under move assignment when the source is not truly an rvalue, but a
+moved-from lvalue (destructors could run late).
</p>
-<ul>
-
-<li>
-<p>
-Even though <tt>unique_ptr<void></tt> is not a valid use case (unlike for <tt>shared_ptr<void></tt>),
-unexpected cases to crop up which require the instantiation of the interface of <tt>unique_ptr<void></tt>
-even if it is never used. For example see
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">LWG 541</a> for how this accidently
-happened to <tt>auto_ptr</tt>. I believe the most robust way to protect <tt>unique_ptr</tt> against this
-type of failure is to augment the return type of <tt>unique_ptr<T>:operator*()</tt> with
-<tt>add_lvalue_reference<T>::type</tt>. This means that given an instantiated <tt>unique_ptr<void></tt>
-the act of dereferencing it will simply return <tt>void</tt> instead of causing a compile time failure.
-This is simpler than creating a <tt>unique_ptr<void></tt> specialization which isn't robust in the
-face of <tt><i>cv-</i></tt>qualified <tt>void</tt> types.
-</p>
+<blockquote><pre><tt>vector<shared_ptr<ostream>></tt> v1;
+<tt>vector<shared_ptr<ostream>></tt> v2;
+...
+v1 = v2; // #1
+v1 = std::move(v2); // #2
+</pre></blockquote>
<p>
-This resolution also supports instantiations such as <tt>unique_ptr<void, free_deleter></tt>
-which could be very useful to the client.
+Move semantics means not caring what happens to the source (<tt>v2</tt> in this example).
+It doesn't mean not caring what happens to the target (<tt>v1</tt>). In the above example
+both assignments should have the same effect on <tt>v1</tt>. Any non-shared <tt>ostream</tt>'s
+<tt>v1</tt> owns before the assignment should be closed, whether <tt>v1</tt> is undergoing
+copy assignment or move assignment.
+</p>
+
+<p>
+This implies that the semantics of move assignment of a generic container should be
+<tt>clear, swap</tt> instead of just swap. An alternative which could achieve the same
+effect would be to move assign each element. In either case, the complexity of move
+assignment needs to be relaxed to <tt>O(v1.size())</tt>.
+</p>
+
+<p>
+The performance hit of this change is not nearly as drastic as it sounds.
+In practice, the target of a move assignment has always just been move constructed
+or move assigned <i>from</i>. Therefore under <tt>clear, swap</tt> semantics (in
+this common use case) we are still achieving O(1) complexity.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 23.1 [container.requirements]:
+</p>
+
+<blockquote>
+<table border="1">
+<caption>Table 86: Container requirements</caption>
+<tbody><tr>
+<th>expression</th><th>return type</th><th>operational semantics</th>
+<th>assertion/note pre/post-condition</th><th>complexity</th>
+</tr>
+<tr>
+<td><tt>a = rv;</tt></td><td><tt>X&</tt></td>
+<td><ins>All existing elements of <tt>a</tt> are either move assigned or destructed</ins></td>
+<td><tt>a</tt> shall be equal to the
+value that <tt>rv</tt> had
+before this construction
+</td>
+<td><del>constant</del> <ins>linear in <tt>a.size()</tt></ins></td>
+</tr>
+</tbody></table>
+</blockquote>
+
+
+
+
+
+
+<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#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#Ready">Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Move semantics are missing from the <tt>unordered</tt> containers. The proposed
+resolution below adds move-support consistent with
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1858.html">N1858</a>
+and the current working draft.
+</p>
+
+<p>
+The current proposed resolution simply lists the requirements for each function.
+These might better be hoisted into the requirements table for unordered associative containers.
+Futhermore a mild reorganization of the container requirements could well be in order.
+This defect report is purposefully ignoring these larger issues and just focusing
+on getting the unordered containers "moved".
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+
+<p>
+Add to 23.4 [unord]:
+</p>
+
+<blockquote><pre>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
+ unordered_map<Key, T, Hash, Pred, Alloc>& y);
+
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
+ unordered_map<Key, T, Hash, Pred, Alloc>&& y);</ins>
+
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x,
+ unordered_map<Key, T, Hash, Pred, Alloc>& y);</ins>
+
+template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
+ unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
+
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
+ unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);</ins>
+
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x,
+ unordered_multimap<Key, T, Hash, Pred, Alloc>& y);</ins>
+
+...
+
+template <class Value, class Hash, class Pred, class Alloc>
+ void swap(unordered_set<Value, Hash, Pred, Alloc>& x,
+ unordered_set<Value, Hash, Pred, Alloc>& y);
+
+<ins>template <class Value, class Hash, class Pred, class Alloc>
+ void swap(unordered_set<Value, Hash, Pred, Alloc>& x,
+ unordered_set<Value, Hash, Pred, Alloc>&& y);</ins>
+
+<ins>template <class Value, class Hash, class Pred, class Alloc>
+ void swap(unordered_set<Value, Hash, Pred, Alloc>&& x,
+ unordered_set<Value, Hash, Pred, Alloc>& y);</ins>
+
+template <class Value, class Hash, class Pred, class Alloc>
+ void swap(unordered_multiset<Value, Hash, Pred, Alloc>& x,
+ unordered_multiset<Value, Hash, Pred, Alloc>& y);
+
+<ins>template <class Value, class Hash, class Pred, class Alloc>
+ void swap(unordered_multiset<Value, Hash, Pred, Alloc>& x,
+ unordered_multiset<Value, Hash, Pred, Alloc>&& y);</ins>
+
+<ins>template <class Value, class Hash, class Pred, class Alloc>
+ void swap(unordered_multiset<Value, Hash, Pred, Alloc>&& x,
+ unordered_multiset<Value, Hash, Pred, Alloc>& y);</ins>
+</pre></blockquote>
+
+<p><b><tt>unordered_map</tt></b></p>
+
+<p>
+Change 23.4.1 [unord.map]:
+</p>
+
+<blockquote><pre>class unordered_map
+{
+ ...
+ unordered_map(const unordered_map&);
+ <ins>unordered_map(unordered_map&&);</ins>
+ ~unordered_map();
+ unordered_map& operator=(const unordered_map&);
+ <ins>unordered_map& operator=(unordered_map&&);</ins>
+ ...
+ // modifiers
+ <del>std::</del>pair<iterator, bool> insert(const value_type& obj);
+ <ins>template <class P> pair<iterator, bool> insert(P&& obj);</ins>
+ iterator insert(iterator hint, const value_type& obj);
+ <ins>template <class P> iterator insert(iterator hint, P&& obj);</ins>
+ const_iterator insert(const_iterator hint, const value_type& obj);
+ <ins>template <class P> const_iterator insert(const_iterator hint, P&& obj);</ins>
+ ...
+ void swap(unordered_map&<ins>&</ins>);
+ ...
+ mapped_type& operator[](const key_type& k);
+ <ins>mapped_type& operator[](key_type&& k);</ins>
+ ...
+};
+
+template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
+ unordered_map<Key, T, Hash, Pred, Alloc>& y);
+
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
+ unordered_map<Key, T, Hash, Pred, Alloc>&& y);</ins>
+
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x,
+ unordered_map<Key, T, Hash, Pred, Alloc>& y);</ins>
+</pre></blockquote>
+
+<p>
+Add to 23.4.1.1 [unord.map.cnstr]:
+</p>
+
+<blockquote>
+<pre>template <class InputIterator>
+ unordered_map(InputIterator f, InputIterator l,
+ size_type n = <i>implementation-defined</i>,
+ const hasher& hf = hasher(),
+ const key_equal& eql = key_equal(),
+ const allocator_type& a = allocator_type());
+</pre>
+
+<blockquote><p>
+<ins>
+<i>Requires:</i> If the iterator's dereference operator returns an
+lvalue or a const rvalue <tt>pair<key_type, mapped_type></tt>,
+then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be
+<tt>CopyConstructible</tt>.
+</ins>
+</p></blockquote>
+</blockquote>
+
+<p>
+Add to 23.4.1.2 [unord.map.elem]:
+</p>
+
+<blockquote>
+
+<pre>mapped_type& operator[](const key_type& k);</pre>
+
+<blockquote>
+<p>...</p>
+<p><ins>
+<i>Requires:</i> <tt>key_type</tt> shall be <tt>CopyConstructible</tt>
+and <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>.
+</ins></p>
+</blockquote>
+
+<pre><ins>mapped_type& operator[](key_type&& k);</ins></pre>
+
+<blockquote>
+<p><ins>
+<i>Effects:</i> If the <tt>unordered_map</tt> does not already contain an
+element whose key is equivalent to <tt>k</tt> , inserts the value
+<tt>std::pair<const key_type, mapped_type>(std::move(k), mapped_type())</tt>.
+</ins></p>
+
+<p><ins>
+<i>Requires:</i> <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>.
+</ins></p>
+
+<p><ins>
+<i>Returns:</i> A reference to <tt>x.second</tt>, where <tt>x</tt> is the
+(unique) element whose key is equivalent to <tt>k</tt>.
+</ins></p>
+
+</blockquote>
+
+</blockquote>
+
+<p>
+Add new section [unord.map.modifiers]:
+</p>
+
+<blockquote>
+<pre><ins>pair<iterator, bool> insert(const value_type& x);</ins>
+<ins>template <class P> pair<iterator, bool> insert(P&& x);</ins>
+<ins>iterator insert(iterator hint, const value_type& x);</ins>
+<ins>template <class P> iterator insert(iterator hint, P&& x);</ins>
+<ins>const_iterator insert(const_iterator hint, const value_type& x);</ins>
+<ins>template <class P> const_iterator insert(const_iterator hint, P&& x);</ins>
+<ins>template <class InputIterator>
+ void insert(InputIterator first, InputIterator last);</ins>
+</pre>
+
+<blockquote>
+<p><ins>
+<i>Requires:</i> Those signatures taking a <tt>const value_type&</tt> parameter
+requires both the <tt>key_type</tt> and the <tt>mapped_type</tt> to be
+<tt>CopyConstructible</tt>.
+</ins></p>
+
+<p><ins>
+<tt>P</tt> shall be convertible to <tt>value_type</tt>.
+ If <tt>P</tt> is instantiated as a reference
+type, then the argument <tt>x</tt> is copied from. Otherwise <tt>x</tt>
+is considered to be an rvalue as it is converted to <tt>value_type</tt>
+and inserted into the <tt>unordered_map</tt>. Specifically, in such
+cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or
+<tt>mapped_type</tt> unless the conversion from <tt>P</tt> specifically
+requires it (e.g. if <tt>P</tt> is a <tt>tuple<const key_type,
+mapped_type></tt>, then <tt>key_type</tt> must be
+<tt>CopyConstructible</tt>).
+</ins></p>
+
+<p><ins>
+The signature taking <tt>InputIterator</tt>
+parameters requires <tt>CopyConstructible</tt> of both
+<tt>key_type</tt> and <tt>mapped_type</tt> if the dereferenced
+<tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
+<tt>value_type</tt>.
+</ins></p>
+
+</blockquote>
+
+</blockquote>
+
+<p>
+Add to 23.4.1.3 [unord.map.swap]:
+</p>
+
+<blockquote>
+<pre>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
+ unordered_map<Key, T, Hash, Pred, Alloc>& y);
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
+ unordered_map<Key, T, Hash, Pred, Alloc>&& y);</ins>
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x,
+ unordered_map<Key, T, Hash, Pred, Alloc>& y);</ins>
+</pre>
+</blockquote>
+
+<p><b><tt>unordered_multimap</tt></b></p>
+
+<p>
+Change 23.4.2 [unord.multimap]:
+</p>
+
+<blockquote><pre>class unordered_multimap
+{
+ ...
+ unordered_multimap(const unordered_multimap&);
+ <ins>unordered_multimap(unordered_multimap&&);</ins>
+ ~unordered_multimap();
+ unordered_multimap& operator=(const unordered_multimap&);
+ <ins>unordered_multimap& operator=(unordered_multimap&&);</ins>
+ ...
+ // modifiers
+ iterator insert(const value_type& obj);
+ <ins>template <class P> iterator insert(P&& obj);</ins>
+ iterator insert(iterator hint, const value_type& obj);
+ <ins>template <class P> iterator insert(iterator hint, P&& obj);</ins>
+ const_iterator insert(const_iterator hint, const value_type& obj);
+ <ins>template <class P> const_iterator insert(const_iterator hint, P&& obj);</ins>
+ ...
+ void swap(unordered_multimap&<ins>&</ins>);
+ ...
+};
+
+template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
+ unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
+
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
+ unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);</ins>
+
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x,
+ unordered_multimap<Key, T, Hash, Pred, Alloc>& y);</ins>
+</pre></blockquote>
+
+<p>
+Add to 23.4.2.1 [unord.multimap.cnstr]:
+</p>
+
+<blockquote>
+<pre>template <class InputIterator>
+ unordered_multimap(InputIterator f, InputIterator l,
+ size_type n = <i>implementation-defined</i>,
+ const hasher& hf = hasher(),
+ const key_equal& eql = key_equal(),
+ const allocator_type& a = allocator_type());
+</pre>
+
+<blockquote><p>
+<ins>
+<i>Requires:</i> If the iterator's dereference operator returns an
+lvalue or a const rvalue <tt>pair<key_type, mapped_type></tt>,
+then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be
+<tt>CopyConstructible</tt>.
+</ins>
+</p></blockquote>
+</blockquote>
+
+<p>
+Add new section [unord.multimap.modifiers]:
+</p>
+
+<blockquote>
+<pre><ins>iterator insert(const value_type& x);</ins>
+<ins>template <class P> iterator insert(P&& x);</ins>
+<ins>iterator insert(iterator hint, const value_type& x);</ins>
+<ins>template <class P> iterator insert(iterator hint, P&& x);</ins>
+<ins>const_iterator insert(const_iterator hint, const value_type& x);</ins>
+<ins>template <class P> const_iterator insert(const_iterator hint, P&& x);</ins>
+<ins>template <class InputIterator>
+ void insert(InputIterator first, InputIterator last);</ins>
+</pre>
+
+<blockquote>
+<p><ins>
+<i>Requires:</i> Those signatures taking a <tt>const value_type&</tt> parameter
+requires both the <tt>key_type</tt> and the <tt>mapped_type</tt> to be
+<tt>CopyConstructible</tt>.
+</ins></p>
+
+<p><ins>
+<tt>P</tt> shall be convertible to <tt>value_type</tt>.
+ If <tt>P</tt> is instantiated as a reference
+type, then the argument <tt>x</tt> is copied from. Otherwise <tt>x</tt>
+is considered to be an rvalue as it is converted to <tt>value_type</tt>
+and inserted into the <tt>unordered_multimap</tt>. Specifically, in such
+cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or
+<tt>mapped_type</tt> unless the conversion from <tt>P</tt> specifically
+requires it (e.g. if <tt>P</tt> is a <tt>tuple<const key_type,
+mapped_type></tt>, then <tt>key_type</tt> must be
+<tt>CopyConstructible</tt>).
+</ins></p>
+
+<p><ins>
+The signature taking <tt>InputIterator</tt>
+parameters requires <tt>CopyConstructible</tt> of both
+<tt>key_type</tt> and <tt>mapped_type</tt> if the dereferenced
+<tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
+<tt>value_type</tt>.
+</ins></p>
+</blockquote>
+
+</blockquote>
+
+<p>
+Add to 23.4.2.2 [unord.multimap.swap]:
+</p>
+
+<blockquote>
+<pre>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
+ unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
+ unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);</ins>
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x,
+ unordered_multimap<Key, T, Hash, Pred, Alloc>& y);</ins>
+</pre>
+</blockquote>
+
+<p><b><tt>unordered_set</tt></b></p>
+
+<p>
+Change 23.4.3 [unord.set]:
+</p>
+
+<blockquote><pre>class unordered_set
+{
+ ...
+ unordered_set(const unordered_set&);
+ <ins>unordered_set(unordered_set&&);</ins>
+ ~unordered_set();
+ unordered_set& operator=(const unordered_set&);
+ <ins>unordered_set& operator=(unordered_set&&);</ins>
+ ...
+ // modifiers
+ <del>std::</del>pair<iterator, bool> insert(const value_type& obj);
+ <ins>pair<iterator, bool> insert(value_type&& obj);</ins>
+ iterator insert(iterator hint, const value_type& obj);
+ <ins>iterator insert(iterator hint, value_type&& obj);</ins>
+ const_iterator insert(const_iterator hint, const value_type& obj);
+ <ins>const_iterator insert(const_iterator hint, value_type&& obj);</ins>
+ ...
+ void swap(unordered_set&<ins>&</ins>);
+ ...
+};
+
+template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x,
+ unordered_set<Key, T, Hash, Pred, Alloc>& y);
+
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x,
+ unordered_set<Key, T, Hash, Pred, Alloc>&& y);</ins>
+
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_set<Key, T, Hash, Pred, Alloc>&& x,
+ unordered_set<Key, T, Hash, Pred, Alloc>& y);</ins>
+</pre></blockquote>
+
+<p>
+Add to 23.4.3.1 [unord.set.cnstr]:
+</p>
+
+<blockquote>
+<pre>template <class InputIterator>
+ unordered_set(InputIterator f, InputIterator l,
+ size_type n = <i>implementation-defined</i>,
+ const hasher& hf = hasher(),
+ const key_equal& eql = key_equal(),
+ const allocator_type& a = allocator_type());
+</pre>
+
+<blockquote><p>
+<ins>
+<i>Requires:</i> If the iterator's dereference operator returns an
+lvalue or a const rvalue <tt>value_type</tt>, then the
+<tt>value_type</tt> shall be <tt>CopyConstructible</tt>.
+</ins>
+</p></blockquote>
+</blockquote>
+
+<p>
+Add new section [unord.set.modifiers]:
+</p>
+
+<blockquote>
+<pre><ins>pair<iterator, bool> insert(const value_type& x);</ins>
+<ins>pair<iterator, bool> insert(value_type&& x);</ins>
+<ins>iterator insert(iterator hint, const value_type& x);</ins>
+<ins>iterator insert(iterator hint, value_type&& x);</ins>
+<ins>const_iterator insert(const_iterator hint, const value_type& x);</ins>
+<ins>const_iterator insert(const_iterator hint, value_type&& x);</ins>
+<ins>template <class InputIterator>
+ void insert(InputIterator first, InputIterator last);</ins>
+</pre>
+
+<blockquote>
+
+<p><ins>
+<i>Requires:</i> Those signatures taking a <tt>const
+value_type&</tt> parameter requires the <tt>value_type</tt> to
+be <tt>CopyConstructible</tt>.
+</ins></p>
+
+<p><ins>
+The signature taking <tt>InputIterator</tt> parameters requires
+<tt>CopyConstructible</tt> of <tt>value_type</tt> if the dereferenced
+<tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
+<tt>value_type</tt>.
+</ins></p>
+
+</blockquote>
+
+</blockquote>
+
+<p>
+Add to 23.4.3.2 [unord.set.swap]:
+</p>
+
+<blockquote>
+<pre>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x,
+ unordered_set<Key, T, Hash, Pred, Alloc>& y);
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x,
+ unordered_set<Key, T, Hash, Pred, Alloc>&& y);</ins>
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_set<Key, T, Hash, Pred, Alloc>&& x,
+ unordered_set<Key, T, Hash, Pred, Alloc>& y);</ins>
+</pre>
+</blockquote>
+
+<p><b><tt>unordered_multiset</tt></b></p>
+
+<p>
+Change 23.4.4 [unord.multiset]:
+</p>
+
+<blockquote><pre>class unordered_multiset
+{
+ ...
+ unordered_multiset(const unordered_multiset&);
+ <ins>unordered_multiset(unordered_multiset&&);</ins>
+ ~unordered_multiset();
+ unordered_multiset& operator=(const unordered_multiset&);
+ <ins>unordered_multiset& operator=(unordered_multiset&&);</ins>
+ ...
+ // modifiers
+ iterator insert(const value_type& obj);
+ <ins>iterator insert(value_type&& obj);</ins>
+ iterator insert(iterator hint, const value_type& obj);
+ <ins>iterator insert(iterator hint, value_type&& obj);</ins>
+ const_iterator insert(const_iterator hint, const value_type& obj);
+ <ins>const_iterator insert(const_iterator hint, value_type&& obj);</ins>
+ ...
+ void swap(unordered_multiset&<ins>&</ins>);
+ ...
+};
+
+template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x,
+ unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
+
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x,
+ unordered_multiset<Key, T, Hash, Pred, Alloc>&& y);</ins>
+
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>&& x,
+ unordered_multiset<Key, T, Hash, Pred, Alloc>& y);</ins>
+</pre></blockquote>
+
+<p>
+Add to 23.4.4.1 [unord.multiset.cnstr]:
+</p>
+
+<blockquote>
+<pre>template <class InputIterator>
+ unordered_multiset(InputIterator f, InputIterator l,
+ size_type n = <i>implementation-defined</i>,
+ const hasher& hf = hasher(),
+ const key_equal& eql = key_equal(),
+ const allocator_type& a = allocator_type());
+</pre>
+
+<blockquote><p>
+<ins>
+<i>Requires:</i> If the iterator's dereference operator returns an
+lvalue or a const rvalue <tt>value_type</tt>, then the
+<tt>value_type</tt> shall be <tt>CopyConstructible</tt>.
+</ins>
+</p></blockquote>
+</blockquote>
+
+<p>
+Add new section [unord.multiset.modifiers]:
+</p>
+
+<blockquote>
+<pre><ins>iterator insert(const value_type& x);</ins>
+<ins>iterator insert(value_type&& x);</ins>
+<ins>iterator insert(iterator hint, const value_type& x);</ins>
+<ins>iterator insert(iterator hint, value_type&& x);</ins>
+<ins>const_iterator insert(const_iterator hint, const value_type& x);</ins>
+<ins>const_iterator insert(const_iterator hint, value_type&& x);</ins>
+<ins>template <class InputIterator>
+ void insert(InputIterator first, InputIterator last);</ins>
+</pre>
+
+<blockquote>
+
+<p><ins>
+<i>Requires:</i> Those signatures taking a <tt>const
+value_type&</tt> parameter requires the <tt>value_type</tt> to
+be <tt>CopyConstructible</tt>.
+</ins></p>
+
+<p><ins>
+The signature taking <tt>InputIterator</tt> parameters requires
+<tt>CopyConstructible</tt> of <tt>value_type</tt> if the dereferenced
+<tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
+<tt>value_type</tt>.
+</ins></p>
+
+</blockquote>
+
+</blockquote>
+
+<p>
+Add to 23.4.4.2 [unord.multiset.swap]:
+</p>
+
+<blockquote>
+<pre>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x,
+ unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x,
+ unordered_multiset<Key, T, Hash, Pred, Alloc>&& y);</ins>
+<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
+ void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>&& x,
+ unordered_multiset<Key, T, Hash, Pred, Alloc>& y);</ins>
+</pre>
+</blockquote>
+
+
+
+
+
+
+<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#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#Ready">Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The C++98 standard specifies that one member function alone of the containers
+passes its parameter (<tt>T</tt>) by value instead of by const reference:
+</p>
+
+<blockquote><pre>void resize(size_type sz, T c = T());
+</pre></blockquote>
+
+<p>
+This fact has been discussed / debated repeatedly over the years, the first time
+being even before C++98 was ratified. The rationale for passing this parameter by
+value has been:
+</p>
+
+<blockquote>
+<p>
+So that self referencing statements are guaranteed to work, for example:
+</p>
+<blockquote><pre>v.resize(v.size() + 1, v[0]);
+</pre></blockquote>
+</blockquote>
+
+<p>
+However this rationale is not convincing as the signature for <tt>push_back</tt> is:
+</p>
+
+<blockquote><pre>void push_back(const T& x);
+</pre></blockquote>
+
+<p>
+And <tt>push_back</tt> has similar semantics to <tt>resize</tt> (append).
+And <tt>push_back</tt> must also work in the self referencing case:
+</p>
+
+<blockquote><pre>v.push_back(v[0]); // must work
+</pre></blockquote>
+
+<p>
+The problem with passing <tt>T</tt> by value is that it can be significantly more
+expensive than passing by reference. The converse is also true, however when it is
+true it is usually far less dramatic (e.g. for scalar types).
+</p>
+
+<p>
+Even with move semantics available, passing this parameter by value can be expensive.
+Consider for example <tt>vector<vector<int>></tt>:
+</p>
+
+<blockquote><pre>std::vector<int> x(1000);
+std::vector<std::vector<int>> v;
+...
+v.resize(v.size()+1, x);
+</pre></blockquote>
+
+<p>
+In the pass-by-value case, <tt>x</tt> is copied once to the parameter of
+<tt>resize</tt>. And then internally, since the code can not know at compile
+time by how much <tt>resize</tt> is growing the <tt>vector</tt>, <tt>x</tt> is
+usually copied (not moved) a second time from <tt>resize</tt>'s parameter into its proper place
+within the <tt>vector</tt>.
+</p>
+
+<p>
+With pass-by-const-reference, the <tt>x</tt> in the above example need be copied
+only once. In this case, <tt>x</tt> has an expensive copy constructor and so any
+copies that can be saved represents a significant savings.
+</p>
+
+<p>
+If we can be efficient for <tt>push_back</tt>, we should be efficient for <tt>resize</tt>
+as well. The resize taking a reference parameter has been coded and shipped in the
+CodeWarrior library with no reports of problems which I am aware of.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 23.2.2 [deque], p2:
+</p>
+
+<blockquote><pre>class deque {
+ ...
+ void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c);
+</pre></blockquote>
+
+<p>
+Change 23.2.2.2 [deque.capacity], p3:
+</p>
+
+<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c);
+</pre></blockquote>
+
+<p>
+Change 23.2.3 [list], p2:
+</p>
+
+<blockquote><pre>class list {
+ ...
+ void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c);
+</pre></blockquote>
+
+<p>
+Change 23.2.3.2 [list.capacity], p3:
+</p>
+
+<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c);
+</pre></blockquote>
+
+<p>
+Change 23.2.5 [vector], p2:
+</p>
+
+<blockquote><pre>class vector {
+ ...
+ void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c);
+</pre></blockquote>
+
+<p>
+Change 23.2.5.2 [vector.capacity], p11:
+</p>
+
+<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c);
+</pre></blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="680"></a>680. move_iterator operator-> 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#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#Ready">Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+<tt>move_iterator</tt>'s <tt>operator-></tt> return type <tt>pointer</tt>
+does not consistently match the type which is returned in the description
+in 24.4.3.3.5 [move.iter.op.ref].
+</p>
+
+<blockquote><pre>template <class Iterator>
+class move_iterator {
+public:
+ ...
+ typedef typename iterator_traits<Iterator>::pointer pointer;
+ ...
+ pointer operator->() const {return current;}
+ ...
+private:
+ Iterator current; // exposition only
+};
+</pre></blockquote>
+
+
+<p>
+There are two possible fixes.
+</p>
+
+<ol>
+<li><tt>pointer operator->() const {return &*current;}</tt></li>
+<li><tt>typedef Iterator pointer;</tt></li>
+</ol>
+
+<p>
+The first solution is the one chosen by <tt>reverse_iterator</tt>. A potential
+disadvantage of this is it may not work well with iterators which return a
+proxy on dereference and that proxy has overloaded <tt>operator&()</tt>. Proxy
+references often need to overloaad <tt>operator&()</tt> to return a proxy
+pointer. That proxy pointer may or may not be the same type as the iterator's
+<tt>pointer</tt> type.
+</p>
+
+<p>
+By simply returning the <tt>Iterator</tt> and taking advantage of the fact that
+the language forwards calls to <tt>operator-></tt> automatically until it
+finds a non-class type, the second solution avoids the issue of an overloaded
+<tt>operator&()</tt> entirely.
+</p>
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis in 24.4.3.1 [move.iterator]:
+</p>
+
+<blockquote><pre>typedef <del>typename iterator_traits<</del>Iterator<del>>::pointer</del> pointer;
+</pre></blockquote>
+
+
+
+
+
+
+<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#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#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In 28.4 [re.syn] of N2284, two template functions
+are declared here:
+</p>
+<blockquote><pre>// 28.10, class template match_results:
+ <<i>snip</i>>
+// match_results comparisons
+ template <class BidirectionalIterator, class Allocator>
+ bool operator== (const match_results<BidirectionalIterator, Allocator>& m1,
+ const match_results<BidirectionalIterator, Allocator>& m2);
+ template <class BidirectionalIterator, class Allocator>
+ bool operator!= (const match_results<BidirectionalIterator, Allocator>& m1,
+ const match_results<BidirectionalIterator, Allocator>& m2);
+
+// 28.10.6, match_results swap:
+</pre></blockquote>
+
+<p>
+But the details of these two bool operator functions (i.e., which members of
+<tt>match_results</tt> should be used in comparison) are not described in any
+following sections.
+</p>
+
+<p><i>[
+John adds:
+]</i></p>
+
+
+<blockquote><p>
+That looks like a bug: <tt>operator==</tt> should return <tt>true</tt> only if
+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<class BidirectionalIterator, class Allocator>
+ bool operator==(const match_results<BidirectionalIterator, Allocator>& m1,
+ const match_results<BidirectionalIterator, Allocator>& 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<class BidirectionalIterator, class Allocator>
+ bool operator!=(const match_results<BidirectionalIterator, Allocator>& m1,
+ const match_results<BidirectionalIterator, Allocator>& m2);
+</pre>
+<blockquote>
+<p>
+<i>Returns:</i> <tt>!(m1 == m2)</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+<blockquote>
+<pre>template<class BidirectionalIterator, class Allocator>
+ void swap(match_results<BidirectionalIterator, Allocator>& m1,
+ match_results<BidirectionalIterator, Allocator>& m2);
+</pre>
+<blockquote>
+<p>
+<i>Returns:</i> <tt>m1.swap(m2)</tt>.
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+<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#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#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In C++03 the difference between two <tt>reverse_iterators</tt>
+</p>
+<blockquote><pre>ri1 - ri2
+</pre></blockquote>
+<p>
+is possible to compute only if both iterators have the same base
+iterator. The result type is the <tt>difference_type</tt> of the base iterator.
+</p>
+<p>
+In the current draft, the operator is defined as 24.4.1.3.19 [reverse.iter.opdiff]
+</p>
+<blockquote><pre>template<class Iterator1, class Iterator2>
+typename reverse_iterator<Iterator>::difference_type
+ operator-(const reverse_iterator<Iterator1>& x,
+ const reverse_iterator<Iterator2>& y);
+</pre></blockquote>
+<p>
+The return type is the same as the C++03 one, based on the no longer
+present <tt>Iterator</tt> template parameter.
+</p>
+<p>
+Besides being slightly invalid, should this operator work only when
+<tt>Iterator1</tt> and <tt>Iterator2</tt> has the same <tt>difference_type</tt>? Or should the
+implementation choose one of them? Which one?
+</p>
+<p>
+The same problem now also appears in <tt>operator-()</tt> for <tt>move_iterator</tt>
+24.4.3.3.14 [move.iter.nonmember].
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis in 24.4.1.1 [reverse.iterator]:
+</p>
+
+<blockquote>
+<pre>template <class Iterator1, class Iterator2>
+ <del>typename reverse_iterator<Iterator>::difference_type</del> <ins>auto</ins> operator-(
+ const reverse_iterator<Iterator1>& x,
+ const reverse_iterator<Iterator2>& y)<ins> -> 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 <class Iterator1, class Iterator2>
+ <del>typename reverse_iterator<Iterator>::difference_type</del> <ins>auto</ins> operator-(
+ const reverse_iterator<Iterator1>& x,
+ const reverse_iterator<Iterator2>& y)<ins> -> 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 <class Iterator1, class Iterator2>
+ <del>typename move_iterator<Iterator>::difference_type</del> <ins>auto</ins> operator-(
+ const move_iterator<Iterator1>& x,
+ const move_iterator<Iterator2>& y)<ins> -> 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 <class Iterator1, class Iterator2>
+ <del>typename move_iterator<Iterator>::difference_type</del> <ins>auto</ins> operator-(
+ const move_iterator<Iterator1>& x,
+ const move_iterator<Iterator2>& y)<ins> -> 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#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#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.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>
+<blockquote><p>
+The return type shall not be convertible to <tt>int</tt>.
+</p></blockquote>
+<p>
+This constraint is omitted for <tt>unique_ptr</tt> and <tt>shared_ptr</tt>. It should be added for those.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+To the <i>Returns</i> paragraph for <tt>operator <i>unspecified-bool-type</i>()
+const</tt>
+of 20.6.5.2.4 [unique.ptr.single.observers] paragraph 11 and 20.6.6.2.5
+[util.smartptr.shared.obs] paragraph 16, add the sentence:
+</p>
+<blockquote><p>
+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#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#Ready">Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Since all conversions from <tt>shared_ptr<T></tt> to <tt>shared_ptr<U></tt> have the same
+rank regardless of the relationship between <tt>T</tt> and <tt>U</tt>, reasonable user
+code that works with raw pointers fails with <tt>shared_ptr</tt>:
+</p>
+
+<blockquote><pre>void f( shared_ptr<void> );
+void f( shared_ptr<int> );
+
+int main()
+{
+ f( shared_ptr<double>() ); // ambiguous
+}
+</pre></blockquote>
+
+<p>
+Now that we officially have <tt>enable_if</tt>, we can constrain the constructor
+and the corresponding assignment operator to only participate in the
+overload resolution when the pointer types are compatible.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 20.6.6.2.1 [util.smartptr.shared.const], change:
+</p>
+
+<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 implicitly</ins> convertible
+to <tt>T*</tt>.
+</p></blockquote>
+
+<p>
+In 20.6.6.3.1 [util.smartptr.weak.const], change:
+</p>
+
+<blockquote>
+<pre><del>template<class Y> weak_ptr(shared_ptr<Y> const& r);</del>
+<del>weak_ptr(weak_ptr const& r);</del>
+<del>template<class Y> weak_ptr(weak_ptr<Y> const& r);</del>
+<ins>weak_ptr(weak_ptr const& r);</ins>
+<ins>template<class Y> weak_ptr(weak_ptr<Y> const& r);</ins>
+<ins>template<class Y> weak_ptr(shared_ptr<Y> const& r);</ins>
+</pre>
+<blockquote><p>
+-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 implicitly</ins> convertible to <tt>T*</tt>.
+</p></blockquote>
+</blockquote>
+
+
+
+
+
+
+<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#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#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
+the constructor, or via <tt>cref</tt> (and <tt>ref</tt> in some corner cases). This leads
+to a dangling reference being stored into the <tt>reference_wrapper</tt> object.
+Now that we have a mechanism to detect an rvalue, we can fix them to
+disallow this source of undefined behavior.
+</p>
+
+<p>
+Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 20.5.5 [refwrap], add:
+</p>
+
+<blockquote><pre><ins>private:</ins>
+<ins> explicit reference_wrapper(T&&);</ins>
+</pre></blockquote>
+
+<p>
+In 20.5.5.1 [refwrap.const], add:
+</p>
+
+<blockquote>
+<pre><ins>explicit reference_wrapper(T&&);</ins>
+</pre>
+<blockquote><p>
+<ins>-?- Not defined to disallow creating a <tt>reference_wrapper</tt> from an rvalue.</ins>
+</p></blockquote>
+</blockquote>
+
+<p>
+In the synopsis of <tt><functional></tt> (20.5.5 [refwrap]), change the declarations
+of <tt>ref</tt> and <tt>cref</tt> to:
+</p>
+
+<blockquote><pre>template<class T> reference_wrapper<T> ref(T&<ins>&</ins>);
+template<class T> reference_wrapper<const T> cref(<del>const</del> T&<ins>&</ins>);
+</pre></blockquote>
+
+<p>
+In 20.5.5.5 [refwrap.helpers], change:
+</p>
+
+<blockquote>
+<pre>template<class T> reference_wrapper<T> ref(T&<ins>&</ins> t);
+</pre>
+<blockquote>
+<p>
+<ins>-1- <i>Requires:</i> <tt>t</tt> shall be an lvalue.</ins>
+</p>
+</blockquote>
+</blockquote>
+
+<p>and change:</p>
+
+<blockquote>
+<pre>template<class T> reference_wrapper<const T> cref(<del>const</del> T&<ins>&</ins> t);
+</pre>
+<blockquote>
+<p>
+<ins>-6- <i>Requires:</i> <tt>t</tt> shall be an lvalue.</ins>
+</p>
+</blockquote>
+</blockquote>
+
+
+
+<p><i>[
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2292.html">N2292</a>
+addresses the first part of the resolution but not the second.
+]</i></p>
+
+
+
+
+
+<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#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#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
+motivation behind this is the safety problem with respect to rvalues,
+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>
+<p>
+Remove the <tt>explicit</tt> from the constructor of <tt>reference_wrapper</tt>. If the
+proposed resolution of the previous issue is accepted, remove the
+<tt>explicit</tt> from the <tt>T&&</tt> constructor as well to keep them in sync.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="691"></a>691. const_local_iterator cbegin, cend missing from TR1</h3>
+<p><b>Section:</b> 23.4 [unord], TR1 6.3 [tr.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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#Review">Review</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The last version of TR1 does not include the following member
+functions
+for unordered containers:
+</p>
+
+<blockquote><pre>const_local_iterator cbegin(size_type n) const;
+const_local_iterator cend(size_type n) const;
+</pre></blockquote>
+
+<p>
+which looks like an oversight to me. I've checked th TR1 issues lists
+and the latest working draft of the C++0x std (N2284) and haven't
+found any mention to these menfuns or to their absence.
+</p>
+<p>
+Is this really an oversight, or am I missing something?
+</p>
+
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the following two rows to table 93 (unordered associative container
+requirements) in section 23.1.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>
+
+
+
+
+
+
+<hr>
+<h3><a name="692"></a>692. <code>get_money</code> and <code>put_money</code> should be formatted I/O functions</h3>
+<p><b>Section:</b> 27.6.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ext.manip">issues</a> in [ext.manip].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+In a private email Bill Plauger notes:
+</p>
+<blockquote><p>
+I believe that the function that implements <code>get_money</code>
+[from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2072.html">N2072</a>]
+should behave as a formatted input function, and the function that
+implements <code>put_money</code> should behave as a formatted output
+function. This has implications regarding the skipping of whitespace
+and the handling of errors, among other things.
+</p>
+<p>
+The words don't say that right now and I'm far from convinced that
+such a change is editorial.
+</p></blockquote>
+<p>
+Martin's response:
+</p>
+<blockquote><p>
+I agree that the manipulators should handle exceptions the same way as
+formatted I/O functions do. The text in N2072 assumes so but the
+<i>Returns</i> clause explicitly omits exception handling for the sake
+of brevity. The spec should be clarified to that effect.
+</p>
+<p>
+As for dealing with whitespace, I also agree it would make sense for
+the extractors and inserters involving the new manipulators to treat
+it the same way as formatted I/O.
+</p></blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add a new paragraph immediately above p4 of 27.6.4 [ext.manip] with the
+following text:
+</p>
+<blockquote><p>
+<i>Effects</i>: The expression <code><i>in</i> >> get_money(mon, intl)</code>
+described below behaves as a formatted input function (as
+described in 27.6.1.2.1 [istream.formatted.reqmts]).
+</p></blockquote>
+<p>
+Also change p4 of 27.6.4 [ext.manip] as follows:
+</p>
+<blockquote><p>
+<i>Returns</i>: An object <code>s</code> of unspecified type such that
+if <code>in</code> is an object of type <code>basic_istream<charT,
+traits></code> then the expression <code><i>in</i> >> get_money(mon, intl)</code> behaves as <ins>a formatted input function
+that calls </ins><code>f(in, mon, intl)</code><del> were
+called</del>. The function <code>f</code> can be defined as...
+</p></blockquote>
+
+
+
+
+
+<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#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#Ready">Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The <code>bitset</code> class template provides the member function
+<code>any()</code> to determine whether an object of the type has any
+bits set, and the member function <code>none()</code> to determine
+whether all of an object's bits are clear. However, the template does
+not provide a corresponding function to discover whether a
+<code>bitset</code> object has all its bits set. While it is
+possible, even easy, to obtain this information by comparing the
+result of <code>count()</code> with the result of <code>size()</code>
+for equality (i.e., via <code>b.count() == b.size()</code>) the
+operation is less efficient than a member function designed
+specifically for that purpose could be. (<code>count()</code> must
+count all non-zero bits in a <code>bitset</code> a word at a time
+while <code>all()</code> could stop counting as soon as it encountered
+the first word with a zero bit).
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Add a declaration of the new member function <code>all()</code> to the
+defintion of the <code>bitset</code> template in 23.3.5 [template.bitset], p1,
+right above the declaration of <code>any()</code> as shown below:
+</p>
+
+<blockquote><pre>bool operator!=(const bitset<N>& rhs) const;
+bool test(size_t pos) const;
+<ins>bool all() const;</ins>
+bool any() const;
+bool none() const;
+</pre></blockquote>
+
+<p>
+Add a description of the new member function to the end of 23.3.5.2 [bitset.members] with the following text:
+</p>
+<blockquote><p>
+<code>bool all() const;</code>
+</p>
+<blockquote>
+<i>Returns</i>: <code>count() == size()</code>.
+</blockquote>
+</blockquote>
+
+<p>
+In addition, change the description of <code>any()</code> and
+<code>none()</code> for consistency with <code>all()</code> as
+follows:
+</p>
+<blockquote><p>
+<code>bool any() const;</code>
+</p>
+<blockquote>
+<p>
+<i>Returns</i>: <del><code>true</code> if any bit in <code>*this</code>
+is one</del><ins><code>count() != 0</code></ins>.
+</p>
+</blockquote>
+<p>
+<code>bool none() const;</code>
+</p>
+<blockquote>
+<p>
+<i>Returns</i>: <del><code>true</code> if no bit in <code>*this</code>
+is one</del><ins><code>count() == 0</code></ins>.
+</p>
+</blockquote>
+</blockquote>
+
+
+
+
+
+<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#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#Ready">Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+Objects of the <code>bitset</code> class template specializations can
+be constructed from and explicitly converted to values of the widest
+C++ integer type, <code>unsigned long</code>. With the introduction
+of <code>long long</code> into the language the template should be
+enhanced to make it possible to interoperate with values of this type
+as well, or perhaps <code>uintmax_t</code>. See c++std-lib-18274 for
+a brief discussion in support of this change.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+For simplicity, instead of adding overloads for <code>unsigned long
+long</code> and dealing with possible ambiguities in the spec, replace
+the <code>bitset</code> ctor that takes an <code>unsigned long</code>
+argument with one taking <code>unsigned long long</code> in the
+definition of the template as shown below. (The standard permits
+implementations to add overloads on other integer types or employ
+template tricks to achieve the same effect provided they don't cause
+ambiguities or changes in behavior.)
+</p>
+<blockquote>
+<pre>// [bitset.cons] constructors:
+bitset();
+bitset(unsigned <ins>long</ins> long val);
+template<class charT, class traits, class Allocator>
+explicit bitset(
+ const basic_string<charT,traits,Allocator>& str,
+ typename basic_string<charT,traits,Allocator>::size_type pos = 0,
+ typename basic_string<charT,traits,Allocator>::size_type n =
+ basic_string<charT,traits,Allocator>::npos);
+</pre>
+</blockquote>
+<p>
+Make a corresponding change in 23.3.5.1 [bitset.cons], p2:
+</p>
+<blockquote>
+<p>
+<code>bitset(unsigned <ins>long</ins> long val);</code>
+</p>
+<blockquote>
+<i>Effects</i>: Constructs an object of class bitset<N>,
+initializing the first <code><i>M</i></code> bit positions to the
+corresponding bit values in <code><i>val</i></code>.
+<code><i>M</i></code> is the smaller of <code><i>N</i></code> and the
+number of bits in the value representation (section [basic.types]) of
+<code>unsigned <ins> long</ins> long</code>. If <code><i>M</i> <
+<i>N</i></code> <ins>is <code>true</code></ins>, the remaining bit
+positions are initialized to zero.
+</blockquote>
+</blockquote>
+
+<p>
+Additionally, introduce a new member function <code>to_ullong()</code>
+to make it possible to convert <code>bitset</code> to values of the
+new type. Add the following declaration to the definition of the
+template, immediate after the declaration of <code>to_ulong()</code>
+in 23.3.5 [template.bitset], p1, as shown below:
+</p>
+<blockquote>
+<pre>// element access:
+bool operator[](size_t pos) const; // for b[i];
+reference operator[](size_t pos); // for b[i];
+unsigned long to_ulong() const;
+<ins>unsigned long long to_ullong() const;</ins>
+template <class charT, class traits, class Allocator>
+basic_string<charT, traits, Allocator> to_string() const;
+</pre>
+</blockquote>
+<p>
+And add a description of the new member function to 23.3.5.2 [bitset.members],
+below the description of the existing <code>to_ulong()</code> (if
+possible), with the following text:
+</p>
+<blockquote>
+<p>
+<code>unsigned long long to_ullong() const;</code>
+</p>
+<blockquote>
+<i>Throws</i>: <code>overflow_error</code> if the integral value
+<code><i>x</i></code> corresponding to the bits in <code>*this</code>
+cannot be represented as type <code>unsigned long long</code>.
+</blockquote>
+<blockquote>
+<i>Returns:</i> <code><i>x</i></code>.
+</blockquote>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="695"></a>695. ctype<char>::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#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#Ready">Ready</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+The <code>ctype<char>::classic_table()</code> static member
+function returns a pointer to an array of const
+<code>ctype_base::mask</code> objects (enums) that contains
+<code>ctype<char>::table_size</code> elements. The table
+describes the properties of the character set in the "C" locale (i.e.,
+whether a character at an index given by its value is alpha, digit,
+punct, etc.), and is typically used to initialize the
+<code>ctype<char></code> facet in the classic "C" locale (the
+protected <code>ctype<char></code> member function
+<code>table()</code> then returns the same value as
+<code>classic_table()</code>).
+</p>
+<p>
+However, while <code>ctype<char>::table_size</code> (the size of
+the table) is a public static const member of the
+<code>ctype<char></code> specialization, the
+<code>classic_table()</code> static member function is protected. That
+makes getting at the classic data less than convenient (i.e., one has
+to create a whole derived class just to get at the masks array). It
+makes little sense to expose the size of the table in the public
+interface while making the table itself protected, especially when the
+table is a constant object.
+</p>
+<p>
+The same argument can be made for the non-static protected member
+function <code>table()</code>.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Make the <code>ctype<char>::classic_table()</code> and
+<code>ctype<char>::table()</code> member functions public by
+moving their declarations into the public section of the definition of
+specialization in 22.2.1.3 [facet.ctype.special] as shown below:
+</p>
+<blockquote>
+<pre> static locale::id id;
+ static const size_t table_size = IMPLEMENTATION_DEFINED;
+<del>protected:</del>
+ const mask* table() const throw();
+ static const mask* classic_table() throw();
+<ins>protected:</ins>
+
+~ctype(); // virtual
+virtual char do_toupper(char c) const;
+</pre>
+</blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="696"></a>696. <code>istream::operator>>(int&)</code> broken</h3>
+<p><b>Section:</b> 27.6.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-23</p>
+<p><b>View 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>Discussion:</b></p>
+<p>
+From message c++std-lib-17897:
+</p>
+<p>
+The code shown in 27.6.1.2.2 [istream.formatted.arithmetic] as the "as if"
+implementation of the two arithmetic extractors that don't have a
+corresponding <code>num_get</code> interface (i.e., the
+<code>short</code> and <code>int</code> overloads) is subtly buggy in
+how it deals with <code>EOF</code>, overflow, and other similar
+conditions (in addition to containing a few typos).
+</p>
+<p>
+One problem is that if <code>num_get::get()</code> reaches the EOF
+after reading in an otherwise valid value that exceeds the limits of
+the narrower type (but not <code>LONG_MIN</code> or
+<code>LONG_MAX</code>), it will set <code><i>err</i></code> to
+<code>eofbit</code>. Because of the if condition testing for
+<code>(<i>err</i> == 0)</code>, the extractor won't set
+<code>failbit</code> (and presumably, return a bogus value to the
+caller).
+</p>
+<p>
+Another problem with the code is that it never actually sets the
+argument to the extracted value. It can't happen after the call to
+<code>setstate()</code> since the function may throw, so we need to
+show when and how it's done (we can't just punt as say: "it happens
+afterwards"). However, it turns out that showing how it's done isn't
+quite so easy since the argument is normally left unchanged by the
+facet on error except when the error is due to a misplaced thousands
+separator, which causes <code>failbit</code> to be set but doesn't
+prevent the facet from storing the value.
</p>
-</li>
-<li>
+<p><b>Proposed resolution:</b></p>
<p>
-Efforts have been made to better support containers and smart pointers in shared
-memory contexts. One of the key hurdles in such support is not assuming that a
-pointer type is actually a <tt>T*</tt>. This can easily be accomplished
-for <tt>unique_ptr</tt> by having the deleter define the pointer type:
-<tt>D::pointer</tt>. Furthermore this type can easily be defaulted to
-<tt>T*</tt> should the deleter <tt>D</tt> choose not to define a pointer
-type (reference implementation
-<a href="http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html">here</a>).
-This change has no run time overhead. It has no interface overhead on
-authors of custom delter types. It simply allows (but not requires)
-authors of custom deleter types to define a smart pointer for the
-storage type of <tt>unique_ptr</tt> if they find such functionality
-useful. <tt>std::default_delete</tt> is an example of a deleter which
-defaults <tt>pointer</tt> to <tt>T*</tt> by simply ignoring this issue
-and not including a <tt>pointer typedef</tt>.
</p>
-</li>
-<li>
+
+
+
+
+<hr>
+<h3><a name="697"></a>697. New <tt><system_error></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>
-When the deleter type is a function pointer then it is unsafe to construct
-a <tt>unique_ptr</tt> without specifying the function pointer in the constructor.
-This case is easy to check for with a <tt>static_assert</tt> assuring that the
-deleter is not a pointer type in those constructors which do not accept deleters.
+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>unique_ptr<A, void(*)(void*)> p(new A); // error, no function given to delete the pointer!
+<blockquote><pre>#include <system_error>
+#include <stdexcept>
+
+void foo() { throw std::invalid_argument("Don't call us - we call you!"); }
</pre></blockquote>
-</li>
+<p>
+I propose that this enumeration type (and probably the remaining parts
+of
+<tt><system_error></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&</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><utility></tt> which clashes with
+the traditional definition of struct <tt>identity</tt> in <tt><functional></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 <class T> struct identity
+{
+ typedef T type;
+ <ins>const T& operator()(const T& x) const;</ins>
+};
+</pre>
+<blockquote>
+<pre><ins>const T& operator()(const T& x) const;</ins>
+</pre>
+<blockquote>
+<p>
+<ins><i>Returns:</i> <tt>x</tt>.</ins>
+</p>
+</blockquote>
+</blockquote>
+
+</blockquote>
+
+
+
-</ul>
+<hr>
+<h3><a name="701"></a>701. assoc laguerre poly's</h3>
+<p><b>Section:</b> TR1 5.2.1.1 [tr.num.sf.Lnm] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Christopher Crawford <b>Date:</b> 2007-06-30</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+I see that the definition the associated Laguerre
+polynomials TR1 5.2.1.1 [tr.num.sf.Lnm] has been corrected since
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1687.pdf">N1687</a>.
+However, the draft standard only specifies ranks of integer value <tt>m</tt>,
+while the associated Laguerre polynomials are actually valid for real
+values of <tt>m > -1</tt>. In the case of non-integer values of <tt>m</tt>, the
+definition <tt><i>L</i><sub>n</sub><sup>(m)</sup> = (1/n!)e<sup>x</sup>x<sup>-m</sup> (d/dx)<sup>n</sup> (e<sup>-x</sup>x<sup>m+n</sup>)</tt>
+must be used, which also holds for integer values of <tt>m</tt>. See
+Abramowitz & Stegun, 22.11.6 for the general case, and 22.5.16-17 for
+the integer case. In fact fractional values are most commonly used in
+physics, for example to <tt>m = +/- 1/2</tt> to describe the harmonic
+oscillator in 1 dimension, and <tt>1/2, 3/2, 5/2, ...</tt> in 3
+dimensions.
+</p>
+<p>
+If I am correct, the calculation of the more general case is no
+more difficult, and is in fact the function implemented in the GNU
+Scientific Library. I would urge you to consider upgrading the
+standard, either adding extra functions for real <tt>m</tt> or switching the
+current ones to <tt>double</tt>.
+</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="702"></a>702. Restriction in associated Legendre functions</h3>
+<p><b>Section:</b> TR1 5.2.1.2 [tr.num.sf.Plm] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Christopher Crawford <b>Date:</b> 2007-06-30</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
+<p>
+One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should be
+<tt>|x| <= 1</tt>, not <tt>x >= 0</tt>.</p>
+
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="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>[
-I am grateful for the generous aid of Peter Dimov and Ion Gaztañaga in helping formulate and review
-the proposed resolutions below.
+Kona (2007): Howard and Alan to update requirements table in issue with emplace signatures.
]</i></p>
-<ul>
-<li>
-<p>
-Change 20.6.5.2 [unique.ptr.single]:
-</p>
-<blockquote><pre>template <class T, class D = default_delete<T>> class unique_ptr {
- ...
- <del>T&</del> <ins>typename add_lvalue_reference<T>::type</ins> operator*() const;
- ...
-};
-</pre></blockquote>
+<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<</ins>U<ins>>::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&</tt> if, for the
+corresponding type <tt>Ti</tt> in <tt>Types</tt>,
+<tt>remove_cv<remove_reference<Ti>::type>::type</tt> equals
+<tt>reference_wrapper<X></tt>, otherwise <tt>Vi</tt> is
+<tt>decay<Ti>::type</tt>.</del>
+<ins>Let <tt>Ui</tt> be <tt>decay<Ti>::type</tt> for each
+<tt>Ti</tt> in <tt>Types</tt>. Then each <tt>Vi</tt> in <tt>VTypes</tt>
+is <tt>X&</tt> if <tt>Ui</tt> equals
+<tt>reference_wrapper<X></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>
-Change 20.6.5.2.4 [unique.ptr.single.observers]:
+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<X></tt> arguments and "unwraps" the reference in
+such cases. <tt>make_pair()</tt> would OTOH create a
+<tt>reference_wrapper<X></tt> member. I suggest that the two
+functions are made to behave similar in this respect to minimize
+confusion.
</p>
-<blockquote><pre><del>T&</del> <ins>typename add_lvalue_reference<T>::type</ins> operator*() const;
-</pre></blockquote>
-
-</li>
-<li>
+<p><b>Proposed resolution:</b></p>
<p>
-Change 20.6.5.2 [unique.ptr.single]:
+In 20.2 [utility] change the synopsis for make_pair() to read
</p>
-<blockquote><pre>template <class T, class D = default_delete<T>> class unique_ptr {
-public:
- <ins>typedef <i>implementation (see description below)</i> pointer;</ins>
- ...
- explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p);
- ...
- unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined (see description below)</i> d);
- unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined (see description below)</i> d);
- ...
- <del>T*</del> <ins>pointer</ins> operator->() const;
- <del>T*</del> <ins>pointer</ins> get() const;
- ...
- <del>T*</del> <ins>pointer</ins> release();
- void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
-};
+<blockquote><pre>template <class T1, class T2>
+ pair<<del>typename decay<T1>::type</del> <ins>V1</ins>, <del>typename decay<T2>::type</del> <ins>V2</ins>> make_pair(T1&&, T2&&);
</pre></blockquote>
<p>
-<ins>
--3- If the type <tt>remove_reference<D>::type::pointer</tt>
-exists, then <tt>unique_ptr<T, D>::pointer</tt> is a typedef to
-<tt>remove_reference<D>::type::pointer</tt>. Otherwise
-<tt>unique_ptr<T, D>::pointer</tt> is a typedef to <tt>T*</tt>.
-The type <tt>unique_ptr<T, D>::pointer</tt> must be <tt>CopyConstructible</tt>
-and <tt>CopyAssignable</tt>.
-</ins>
+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>
-Change 20.6.5.2.1 [unique.ptr.single.ctor]:
+<i>Returns:</i> <tt>pair<<del>typename decay<T1>::type</del> <ins>V1</ins>,<del>typename decay<T2>::type</del> <ins>V2</ins>>(forward<T1>(x),forward<T2>(y))</tt> <ins>where <tt>V1</tt> and
+<tt>V2</tt> are determined as follows: Let <tt>Ui</tt> be
+<tt>decay<Ti>::type</tt> for each <tt>Ti</tt>. Then each
+<tt>Vi</tt> is <tt>X&</tt> if <tt>Ui</tt> equals
+<tt>reference_wrapper<X></tt>, otherwise <tt>Vi</tt> is
+<tt>Ui</tt>.</ins>
</p>
+</blockquote>
+
-<blockquote><pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);
-...
-unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
-unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
-...
-unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A& d);
-unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&& d);
-...
-unique_ptr(<del>T*</del> <ins>pointer</ins> p, A& d);
-unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&& d);
-...
-unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A& d);
-unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A&& d);
-...
-</pre></blockquote>
-<p>
--23- <i>Requires:</i> If <tt>D</tt> is not a reference type,
-construction of the deleter <tt>D</tt> from an rvalue of type <tt>E</tt>
-must be well formed and not throw an exception. If <tt>D</tt> is a
-reference type, then <tt>E</tt> must be the same type as <tt>D</tt>
-(diagnostic required). <del><tt>U*</tt></del> <ins><tt>unique_ptr<U,E>::pointer</tt></ins>
-must be implicitly convertible to <del><tt>T*</tt></del>
-<ins>pointer</ins>.
-</p>
+
+
+
+<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>
--25- <i>Postconditions:</i> <tt>get() == value u.get()</tt> had before
-the construction, modulo any required offset adjustments resulting from
-the cast from <del><tt>U*</tt></del>
-<ins><tt>unique_ptr<U,E>::pointer</tt></ins> to <del><tt>T*</tt></del>
-<ins>pointer</ins>. <tt>get_deleter()</tt> returns a reference to the
-internally stored deleter which was constructed from
-<tt>u.get_deleter()</tt>.
+From the Toronto Core wiki:
</p>
<p>
-Change 20.6.5.2.3 [unique.ptr.single.asgn]:
+What do you mean by "null pointer constant"? How do you guarantee that
+<tt>exception_ptr() == 1</tt> doesn't work? Do you even want to prevent that?
+What's the semantics? 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>
-<blockquote>
<p>
--8- <i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
-<tt>D</tt> must not throw an exception. <del><tt>U*</tt></del>
-<ins><tt>unique_ptr<U,E>::pointer</tt></ins> must be implicitly
-convertible to <del><tt>T*</tt></del> <ins>pointer</ins>.
+Peter's response:
</p>
-</blockquote>
<p>
-Change 20.6.5.2.4 [unique.ptr.single.observers]:
+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>
-<blockquote>
-<pre><del>T*</del> <ins>pointer</ins> operator->() const;</pre>
-...
-<pre><del>T*</del> <ins>pointer</ins> get() const;</pre>
-</blockquote>
+
+<p><b>Proposed resolution:</b></p>
<p>
-Change 20.6.5.2.5 [unique.ptr.single.modifiers]:
</p>
-<blockquote>
-<pre><del>T*</del> <ins>pointer</ins> release();</pre>
-...
-<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);</pre>
-</blockquote>
+
+
+
+<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>
-Change 20.6.5.3 [unique.ptr.runtime]:
+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>
-<blockquote><pre>template <class T, class D> class unique_ptr<T[], D> {
-public:
- <ins>typedef <i>implementation</i> pointer;</ins>
- ...
- explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p);
- ...
- unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
- unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
- ...
- <del>T*</del> <ins>pointer</ins> get() const;
- ...
- <del>T*</del> <ins>pointer</ins> release();
- void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
-};
-</pre></blockquote>
+<p><i>[
+Kona (2007): Bill and Nick to provide wording.
+]</i></p>
+
+
+
+<p><b>Proposed resolution:</b></p>
<p>
-Change 20.6.5.3.1 [unique.ptr.runtime.ctor]:
</p>
-<blockquote>
-<pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);
-unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
-unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
-</pre>
+
+
+
+<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>
-These constructors behave the same as in the primary template except
-that they do not accept pointer types which are convertible to
-<del><tt>T*</tt></del> <ins><tt>pointer</tt></ins>. [<i>Note:</i> One
-implementation technique is to create private templated overloads of
-these members. <i>-- end note</i>]
+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>
-</blockquote>
<p>
-Change 20.6.5.3.3 [unique.ptr.runtime.modifiers]:
+Pete adds:
</p>
-<blockquote>
-<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
-</pre>
+<blockquote><p>
+For what it's worth, that may not have been an intentional change.
+N2349, which detailed the changes for adding constant expressions to
+the library, has strikeout bars through the <tt>const</tt> and the <tt>&</tt> that
+surround the <tt>char_type</tt> argument, but none through <tt>char_type</tt> itself.
+So the intention may have been just to change to pass by value, with
+text incorrectly copied from the standard.
+</p></blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
<p>
--1- <i>Requires:</i> Does not accept pointer types which are convertible
-to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (diagnostic
-required). [<i>Note:</i> One implementation technique is to create a private
-templated overload. <i>-- end note</i>]
+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>
+<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>
-Change 20.6.5.4 [unique.ptr.compiletime]:
+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>
-<blockquote><pre>template <class T, class D, size_t N> class unique_ptr<T[N], D> {
-public:
- <ins>typedef <i>implementation</i> pointer;</ins>
- ...
- explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p);
- ...
- unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
- unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
- ...
- <del>T*</del> <ins>pointer</ins> get() const;
- ...
- <del>T*</del> <ins>pointer</ins> release();
- void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
-};
-</pre></blockquote>
+<p><b>Proposed resolution:</b></p>
<p>
-Change 20.6.5.4.3 [unique.ptr.compiletime.modifiers]:
+Add to 20.6.6.2.1 [util.smartptr.shared.const]:
</p>
<blockquote>
-<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
+<pre>shared_ptr(shared_ptr&& r);
+template<class Y> shared_ptr(shared_ptr<Y>&& r);
</pre>
-
+<blockquote>
<p>
--1- <i>Requires:</i> Does not accept pointer types which are convertible
-to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (dignostic required). [<i>Note:</i> One implementation
-technique is to create a private templated overload. <i>--end note</i>]
+<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>
-</li>
-
-<li>
+<p>
+Add to 20.6.6.2.10 [util.smartptr.shared.cast]:
+</p>
+<blockquote>
+<pre>template<class T, class U> shared_ptr<T> static_pointer_cast(shared_ptr<U> const& r);
+</pre>
+<blockquote>
<p>
-Change 20.6.5.2.1 [unique.ptr.single.ctor]:
+<ins><i>Postconditions:</i> If <tt>w</tt> is the return value,
+<tt>w.get() == static_cast<T*>(r.get()) && w.use_count() == r.use_count()</tt>.</ins>
</p>
+</blockquote>
+</blockquote>
<blockquote>
-<pre>unique_ptr();</pre>
+<pre>template<class T, class U> shared_ptr<T> dynamic_pointer_cast(shared_ptr<U> const& r);
+</pre>
<blockquote>
<p>
-<i>Requires:</i> <tt>D</tt> must be default constructible, and that
-construction must not throw an exception. <tt>D</tt> must not be a
-reference type <ins>or pointer type (diagnostic required)</ins>.
+<ins><i>Postconditions:</i> If <tt>w</tt> is the return value, <tt>w.get() == dynamic_cast<T*>(r.get())</tt>.</ins>
</p>
</blockquote>
-<pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);</pre>
+</blockquote>
+
+<blockquote>
+<pre>template<class T, class U> shared_ptr<T> const_pointer_cast(shared_ptr<U> const& r);
+</pre>
<blockquote>
<p>
-<i>Requires:</i> The expression <tt>D()(p)</tt> must be well formed.
-The default constructor of <tt>D</tt> must not throw an exception.
-<tt>D</tt> must not be a reference type <ins>or pointer type (diagnostic
-required)</ins>.
+<ins><i>Postconditions:</i> If <tt>w</tt> is the return value,
+<tt>w.get() == const_cast<T*>(r.get()) && w.use_count() == r.use_count()</tt>.</ins>
</p>
</blockquote>
</blockquote>
<p>
-Change 20.6.5.2.1 [unique.ptr.single.ctor]:
+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>
-<pre>unique_ptr();</pre>
+<p>
+-2- <i>Returns:</i> <del>If <tt>r</tt> is empty, an <tt>empty
+shared_ptr<T>;</tt> otherwise, a <tt>shared_ptr<T></tt>
+object that stores <tt>static_cast<T*>(r.get())</tt> and shares ownership with
+<tt>r</tt>.</del> <ins><tt>shared_ptr<T>(r, static_cast<T*>(r.get())</tt>.</ins>
+</p>
+</blockquote>
+
<blockquote>
<p>
-<i>Requires:</i> <tt>D</tt> must be default constructible, and that
-construction must not throw an exception. <tt>D</tt> must not be a
-reference type <ins>or pointer type (diagnostic required)</ins>.
+-6- <i>Returns:</i>
</p>
+<ul>
+<li><del>When <tt>dynamic_cast<T*>(r.get())</tt> returns a nonzero value,
+a <tt>shared_ptr<T></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<T></tt> object.</del></li>
+<li><ins>If <tt>p = dynamic_cast<T*>(r.get())</tt> is a non-null pointer, <tt>shared_ptr<T>(r, p);</tt></ins></li>
+<li><ins>Otherwise, <tt>shared_ptr<T>()</tt>.</ins></li>
+</ul>
</blockquote>
-<pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);</pre>
+
<blockquote>
<p>
-<i>Requires:</i> The expression <tt>D()(p)</tt> must be well formed.
-The default constructor of <tt>D</tt> must not throw an exception.
-<tt>D</tt> must not be a reference type <ins>or pointer type (diagnostic
-required)</ins>.
+-10- <i>Returns:</i> <del>If <tt>r</tt> is empty, an <tt>empty
+shared_ptr<T>;</tt> otherwise, a <tt>shared_ptr<T></tt>
+object that stores <tt>const_cast<T*>(r.get())</tt> and shares ownership with
+<tt>r</tt>.</del> <ins><tt>shared_ptr<T>(r, const_cast<T*>(r.get())</tt>.</ins>
</p>
</blockquote>
-</blockquote>
-
-</li>
-</ul>
+<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="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>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-05</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>
+<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 href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a> does not propose
-any changes to <tt>shared_ptr</tt>. It needs to be updated to use a rvalue reference where appropriate
-and to interoperate with <tt>unique_ptr</tt> as it does with <tt>auto_ptr</tt>.
+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>
-
-<p><b>Proposed resolution:</b></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>
-Change 20.6.6.2 [util.smartptr.shared] as follows:
+after the aliasing constructor
</p>
-<blockquote>
-<pre>template<class Y> explicit shared_ptr(auto_ptr<Y><del>&</del><ins>&&</ins> r);
-<ins>private:
-template<class Y, class D> explicit shared_ptr(const unique_ptr<Y,D>& r);
-public:
-template<class Y, class D> explicit shared_ptr(unique_ptr<Y,D>&& r);</ins>
-...
-template<class Y> shared_ptr& operator=(auto_ptr<Y><del>&</del><ins>&&</ins> r);
-<ins>
-private:
-template<class Y, class D> shared_ptr& operator=(const unique_ptr<Y,D>& r);
-public:
-template<class Y, class D> shared_ptr& operator=(unique_ptr<Y,D>&& r);</ins></pre>
-</blockquote>
+<blockquote><pre>template<class Y> shared_ptr(shared_ptr<Y> const& r, T *p);
+</pre></blockquote>
<p>
-Change 20.6.6.2.1 [util.smartptr.shared.const] as follows:
+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>
-<blockquote>
-<pre><ins>template<class Y> shared_ptr(auto_ptr<Y><del>&</del><ins>&&</ins> r);</ins></pre>
-</blockquote>
-
<p>
-Add to 20.6.6.2.1 [util.smartptr.shared.const]:
+This is contradicted by the second sentence in the Returns clause of 20.6.6.2.5 [util.smartptr.shared.obs]:
</p>
<blockquote>
-<pre><ins>template<class Y, class D> shared_ptr(unique_ptr<Y, D>&& r);</ins></pre>
-<blockquote>
-
-<p><ins>
-<i>Effects:</i> Equivalent to <tt>shared_ptr( r.release(), r.get_deleter() )</tt> when <tt>D</tt> is
- not a reference type, <tt>shared_ptr( r.release(), ref( r.get_deleter() ) )</tt>
- otherwise.
-</ins></p>
-
-<p><ins>
-<i>Exception safety:</i> If an exception is thrown, the constructor has no effect.
-</ins></p>
+<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>
-</blockquote>
+
+<p><b>Proposed resolution:</b></p>
<p>
-Change 20.6.6.2.3 [util.smartptr.shared.assign] as follows:
+In keeping the N2351 spirit and obviously my preference, change 20.6.6.2.5 [util.smartptr.shared.obs]:
</p>
<blockquote>
-<pre>template<class Y> shared_ptr& operator=(auto_ptr<Y><del>&</del><ins>&&</ins> r);</pre>
+<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>
-Add to 20.6.6.2.3 [util.smartptr.shared.assign]:
+Alternative proposed resolution: (I won't be happy if we do this, but it's possible):
</p>
-<blockquote>
-<pre><ins>template<class Y, class D> shared_ptr& operator=(unique_ptr<Y,D>&& r);</ins></pre>
+<p>
+Change 20.6.6.2.1 [util.smartptr.shared.const]:
+</p>
<blockquote>
-<p><ins>
--4- <i>Effects:</i> Equivalent to <tt>shared_ptr(std::move(r)).swap(*this)</tt>.
-</ins></p>
-<p><ins>
--5- <i>Returns:</i> <tt>*this</tt>.
-</ins></p>
+<pre>template<class Y> shared_ptr(shared_ptr<Y> const& r, T *p);
+</pre>
+<blockquote>
+<p>
+<ins><i>Requires:</i> If <tt>r</tt> is empty, <tt>p</tt> shall be <tt>0</tt>.</ins>
+</p>
+<p>
+<del>[ <i>Note:</i> this constructor allows creation of an empty <tt>shared_ptr</tt>
+instance with a non-NULL stored pointer.
+-- <i>end note</i> ]</del>
+</p>
</blockquote>
-
</blockquote>
<hr>
-<h3><a name="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>
- <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>
+<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>
-James Hopkin pointed out to me that if <tt>vector<T></tt> move assignment is O(1)
-(just a <tt>swap</tt>) then containers such as <tt>vector<shared_ptr<ostream>></tt> might have
-the wrong semantics under move assignment when the source is not truly an rvalue, but a
-moved-from lvalue (destructors could run late).
+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>
-<blockquote><pre><tt>vector<shared_ptr<ostream>></tt> v1;
-<tt>vector<shared_ptr<ostream>></tt> v2;
-...
-v1 = v2; // #1
-v1 = std::move(v2); // #2
-</pre></blockquote>
+<p><b>Proposed resolution:</b></p>
<p>
-Move semantics means not caring what happens to the source (<tt>v2</tt> in this example).
-It doesn't mean not caring what happens to the target (<tt>v1</tt>). In the above example
-both assignments should have the same effect on <tt>v1</tt>. Any non-shared <tt>ostream</tt>'s
-<tt>v1</tt> owns before the assignment should be closed, whether <tt>v1</tt> is undergoing
-copy assignment or move assignment.
+In 25.3.1.1 [sort], change the complexity to "O(N log N)", and remove footnote 266:
</p>
+<blockquote>
<p>
-This implies that the semantics of move assignment of a generic container should be
-<tt>clear, swap</tt> instead of just swap. An alternative which could achieve the same
-effect would be to move assign each element. In either case, the complexity of move
-assignment needs to be relaxed to <tt>O(v1.size())</tt>.
+<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>
-The performance hit of this change is not nearly as drastic as it sounds.
-In practice, the target of a move assignment has always just been move constructed
-or move assigned <i>from</i>. Therefore under <tt>clear, swap</tt> semantics (in
-this common use case) we are still achieving O(1) complexity.
+<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 23.1 [container.requirements]:
+Change the complexity to "At most (last - first) applications of the corresponding predicate".
</p>
<blockquote>
-<table border="1">
-<caption>Table 86: Container requirements</caption>
-<tbody><tr>
-<th>expression</th><th>return type</th><th>operational semantics</th>
-<th>assertion/note pre/post-condition</th><th>complexity</th>
-</tr>
-<tr>
-<td><tt>a = rv;</tt></td><td><tt>X&</tt></td>
-<td><ins>All existing elements of <tt>a</tt> are either move assigned or destructed</ins></td>
-<td><tt>a</tt> shall be equal to the
-value that <tt>rv</tt> had
-before this construction
-</td>
-<td><del>constant</del> <ins>linear</ins></td>
-</tr>
-</tbody></table>
+<pre>template<class ForwardIterator, class Size, class T>
+ ForwardIterator
+ search_n(ForwardIterator first , ForwardIterator last , Size count ,
+ const T& value );
+
+template<class ForwardIterator, class Size, class T,
+ class BinaryPredicate>
+ ForwardIterator
+ search_n(ForwardIterator first , ForwardIterator last , Size count ,
+ const T& value , BinaryPredicate pred );
+</pre>
+<blockquote>
+<p>
+<i>Complexity:</i> At most <tt>(last - first ) <del>* count</del></tt> applications of the corresponding predicate
+<del>if <tt>count</tt> is positive, or 0 otherwise</del>.
+</p>
+</blockquote>
</blockquote>
<hr>
-<h3><a name="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>
- <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>
+<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>
-Move semantics are missing from the <tt>unordered</tt> containers. The proposed
-resolution below adds move-support consistent with
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1858.html">N1858</a>
-and the current working draft.
-</p>
-
-<p>
-The current proposed resolution simply lists the requirements for each function.
-These might better be hoisted into the requirements table for unordered associative containers.
-Futhermore a mild reorganization of the container requirements could well be in order.
-This defect report is purposefully ignoring these larger issues and just focusing
-on getting the unordered containers "moved".
+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<class ForwardIterator>
+ pair<ForwardIterator, ForwardIterator>
+ minmax_element(ForwardIterator first , ForwardIterator last);
+template<class ForwardIterator, class Compare>
+ pair<ForwardIterator, ForwardIterator>
+ minmax_element(ForwardIterator first , ForwardIterator last , Compare comp);
+</pre>
+<blockquote>
<p>
-Add to 23.4 [unord]:
+<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(⌊(3/2) (N-1)⌋, 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>
-<blockquote><pre>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
- unordered_map<Key, T, Hash, Pred, Alloc>& y);
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
- unordered_map<Key, T, Hash, Pred, Alloc>&& y);</ins>
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x,
- unordered_map<Key, T, Hash, Pred, Alloc>& y);</ins>
-template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
- unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
- unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);</ins>
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x,
- unordered_multimap<Key, T, Hash, Pred, Alloc>& y);</ins>
+<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>
-template <class Value, class Hash, class Pred, class Alloc>
- void swap(unordered_set<Value, Hash, Pred, Alloc>& x,
- unordered_set<Value, Hash, Pred, Alloc>& y);
+<blockquote><pre>CharacterClass ::
+[ [lookahead ∉ {^}] ClassRanges ]
+[ ^ ClassRanges ]
+</pre></blockquote>
-<ins>template <class Value, class Hash, class Pred, class Alloc>
- void swap(unordered_set<Value, Hash, Pred, Alloc>& x,
- unordered_set<Value, Hash, Pred, Alloc>&& y);</ins>
+</blockquote>
-<ins>template <class Value, class Hash, class Pred, class Alloc>
- void swap(unordered_set<Value, Hash, Pred, Alloc>&& x,
- unordered_set<Value, Hash, Pred, Alloc>& y);</ins>
+<p>
+This definition for <tt>CharacterClass</tt> appears to be exactly identical to that in ECMA-262.
+</p>
-template <class Value, class Hash, class Pred, class Alloc>
- void swap(unordered_multiset<Value, Hash, Pred, Alloc>& x,
- unordered_multiset<Value, Hash, Pred, Alloc>& y);
+<p>
+Was an actual modification intended here and accidentally omitted, or was this production accidentally included?
+</p>
-<ins>template <class Value, class Hash, class Pred, class Alloc>
- void swap(unordered_multiset<Value, Hash, Pred, Alloc>& x,
- unordered_multiset<Value, Hash, Pred, Alloc>&& y);</ins>
-<ins>template <class Value, class Hash, class Pred, class Alloc>
- void swap(unordered_multiset<Value, Hash, Pred, Alloc>&& x,
- unordered_multiset<Value, Hash, Pred, Alloc>& y);</ins>
+<p><b>Proposed resolution:</b></p>
+<p>
+Remove this mention of the CharacterClass production.
+</p>
+
+<blockquote><pre><del>CharacterClass ::
+[ [lookahead ∉ {^}] ClassRanges ]
+[ ^ ClassRanges ]</del>
</pre></blockquote>
-<p><b><tt>unordered_map</tt></b></p>
-<p>
-Change 23.4.1 [unord.map]:
-</p>
-<blockquote><pre>class unordered_map
-{
- ...
- unordered_map(const unordered_map&);
- <ins>unordered_map(unordered_map&&);</ins>
- ~unordered_map();
- unordered_map& operator=(const unordered_map&);
- <ins>unordered_map& operator=(unordered_map&&);</ins>
- ...
- // modifiers
- <del>std::</del>pair<iterator, bool> insert(const value_type& obj);
- <ins>template <class P> pair<iterator, bool> insert(P&& obj);</ins>
- iterator insert(iterator hint, const value_type& obj);
- <ins>template <class P> iterator insert(iterator hint, P&& obj);</ins>
- const_iterator insert(const_iterator hint, const value_type& obj);
- <ins>template <class P> const_iterator insert(const_iterator hint, P&& obj);</ins>
- ...
- void swap(unordered_map&<ins>&</ins>);
- ...
- mapped_type& operator[](const key_type& k);
- <ins>mapped_type& operator[](key_type&& k);</ins>
- ...
-};
-template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
- unordered_map<Key, T, Hash, Pred, Alloc>& y);
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
- unordered_map<Key, T, Hash, Pred, Alloc>&& y);</ins>
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x,
- unordered_map<Key, T, Hash, Pred, Alloc>& y);</ins>
-</pre></blockquote>
+<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&</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>
-Add to 23.4.1.1 [unord.map.cnstr]:
+Change 26.5.2.3 [valarray.access]:
</p>
<blockquote>
-<pre>template <class InputIterator>
- unordered_map(InputIterator f, InputIterator l,
- size_type n = <i>implementation-defined</i>,
- const hasher& hf = hasher(),
- const key_equal& eql = key_equal(),
- const allocator_type& a = allocator_type());
-</pre>
-
-<blockquote><p>
-<ins>
-<i>Requires:</i> If the iterator's dereference operator returns an
-lvalue or a const rvalue <tt>pair<key_type, mapped_type></tt>,
-then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be
-<tt>CopyConstructible</tt>.
-</ins>
-</p></blockquote>
-</blockquote>
+<p>
+-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>
-Add to 23.4.1.2 [unord.map.elem]:
+-3- The expression <tt>&a[i+j] == &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>
-<blockquote>
+<p>
+-4- Likewise, the expression <tt>&a[i] != &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>
-<pre>mapped_type& operator[](const key_type& k);</pre>
+<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>
-<p>...</p>
-<p><ins>
-<i>Requires:</i> <tt>key_type</tt> shall be <tt>CopyConstructible</tt>
-and <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>.
-</ins></p>
</blockquote>
-<pre><ins>mapped_type& operator[](key_type&& k);</ins></pre>
-<blockquote>
-<p><ins>
-<i>Effects:</i> If the <tt>unordered_map</tt> does not already contain an
-element whose key is equivalent to <tt>k</tt> , inserts the value
-<tt>std::pair<const key_type, mapped_type>(std::move(k), mapped_type())</tt>.
-</ins></p>
-<p><ins>
-<i>Requires:</i> <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>.
-</ins></p>
-<p><ins>
-<i>Returns:</i> A reference to <tt>x.second</tt>, where <tt>x</tt> is the
-(unique) element whose key is equivalent to <tt>k</tt>.
-</ins></p>
-</blockquote>
+<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>
-Add new section [unord.map.modifiers]:
+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>
-<blockquote>
-<pre><ins>pair<iterator, bool> insert(const value_type& x);</ins>
-<ins>template <class P> pair<iterator, bool> insert(P&& x);</ins>
-<ins>iterator insert(iterator hint, const value_type& x);</ins>
-<ins>template <class P> iterator insert(iterator hint, P&& x);</ins>
-<ins>const_iterator insert(const_iterator hint, const value_type& x);</ins>
-<ins>template <class P> const_iterator insert(const_iterator hint, P&& x);</ins>
-<ins>template <class InputIterator>
- void insert(InputIterator first, InputIterator last);</ins>
-</pre>
-<blockquote>
-<p><ins>
-<i>Requires:</i> Those signatures taking a <tt>const value_type&</tt> parameter
-requires both the <tt>key_type</tt> and the <tt>mapped_type</tt> to be
-<tt>CopyConstructible</tt>.
-</ins></p>
+<p><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>
-<p><ins>
-<tt>P</tt> shall be convertible to <tt>value_type</tt>.
- If <tt>P</tt> is instantiated as a reference
-type, then the argument <tt>x</tt> is copied from. Otherwise <tt>x</tt>
-is considered to be an rvalue as it is converted to <tt>value_type</tt>
-and inserted into the <tt>unordered_map</tt>. Specifically, in such
-cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or
-<tt>mapped_type</tt> unless the conversion from <tt>P</tt> specifically
-requires it (e.g. if <tt>P</tt> is a <tt>tuple<const key_type,
-mapped_type></tt>, then <tt>key_type</tt> must be
-<tt>CopyConstructible</tt>).
-</ins></p>
-<p><ins>
-The signature taking <tt>InputIterator</tt>
-parameters requires <tt>CopyConstructible</tt> of both
-<tt>key_type</tt> and <tt>mapped_type</tt> if the dereferenced
-<tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
-<tt>value_type</tt>.
-</ins></p>
-</blockquote>
-</blockquote>
+<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>
-Add to 23.4.1.3 [unord.map.swap]:
+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>
-<pre>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
- unordered_map<Key, T, Hash, Pred, Alloc>& y);
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_map<Key, T, Hash, Pred, Alloc>& x,
- unordered_map<Key, T, Hash, Pred, Alloc>&& y);</ins>
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_map<Key, T, Hash, Pred, Alloc>&& x,
- unordered_map<Key, T, Hash, Pred, Alloc>& y);</ins>
-</pre>
+<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><b><tt>unordered_multimap</tt></b></p>
+<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>
-Change 23.4.2 [unord.multimap]:
+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><pre>class unordered_multimap
-{
- ...
- unordered_multimap(const unordered_multimap&);
- <ins>unordered_multimap(unordered_multimap&&);</ins>
- ~unordered_multimap();
- unordered_multimap& operator=(const unordered_multimap&);
- <ins>unordered_multimap& operator=(unordered_multimap&&);</ins>
- ...
- // modifiers
- iterator insert(const value_type& obj);
- <ins>template <class P> iterator insert(P&& obj);</ins>
- iterator insert(iterator hint, const value_type& obj);
- <ins>template <class P> iterator insert(iterator hint, P&& obj);</ins>
- const_iterator insert(const_iterator hint, const value_type& obj);
- <ins>template <class P> const_iterator insert(const_iterator hint, P&& obj);</ins>
- ...
- void swap(unordered_multimap&<ins>&</ins>);
- ...
-};
+<blockquote>
+<ul>
+<li>at least one constexpr constructor other than the copy constructor,</li>
+</ul>
+</blockquote>
-template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
- unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
+<p>
+Here follows a simply example to demonstrate it's usefulness:
+</p>
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
- unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);</ins>
+<blockquote><pre>template <typename T>
+constexpr typename std::enable_if<std::is_literal<T>::value, T>::type
+abs(T x) {
+ return x < T() ? -x : x;
+}
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x,
- unordered_multimap<Key, T, Hash, Pred, Alloc>& y);</ins>
+template <typename T>
+typename std::enable_if<!std::is_literal<T>::value, T>::type
+abs(const T& x) {
+ return x < T() ? -x : x;
+}
</pre></blockquote>
<p>
-Add to 23.4.2.1 [unord.multimap.cnstr]:
+Here we have the possibility to provide a general <tt>abs</tt> function
+template that can be used in ICE's if it's argument is a literal
+type which's value is a constant expression, otherwise we
+have an optimized version for arguments which are expensive
+to copy and therefore need the usage of arguments of
+reference type (instead of <tt>const T&</tt> we could decide to
+use <tt>T&&</tt>, but that is another issue).
</p>
-<blockquote>
-<pre>template <class InputIterator>
- unordered_multimap(InputIterator f, InputIterator l,
- size_type n = <i>implementation-defined</i>,
- const hasher& hf = hasher(),
- const key_equal& eql = key_equal(),
- const allocator_type& a = allocator_type());
-</pre>
-<blockquote><p>
-<ins>
-<i>Requires:</i> If the iterator's dereference operator returns an
-lvalue or a const rvalue <tt>pair<key_type, mapped_type></tt>,
-then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be
-<tt>CopyConstructible</tt>.
-</ins>
-</p></blockquote>
-</blockquote>
+<p><b>Proposed resolution:</b></p>
<p>
-Add new section [unord.multimap.modifiers]:
+In 20.4.2 [meta.type.synop] in the group "type properties",
+just below the line
</p>
-<blockquote>
-<pre><ins>iterator insert(const value_type& x);</ins>
-<ins>template <class P> iterator insert(P&& x);</ins>
-<ins>iterator insert(iterator hint, const value_type& x);</ins>
-<ins>template <class P> iterator insert(iterator hint, P&& x);</ins>
-<ins>const_iterator insert(const_iterator hint, const value_type& x);</ins>
-<ins>template <class P> const_iterator insert(const_iterator hint, P&& x);</ins>
-<ins>template <class InputIterator>
- void insert(InputIterator first, InputIterator last);</ins>
-</pre>
+<blockquote><pre>template <class T> struct is_pod;
+</pre></blockquote>
-<blockquote>
-<p><ins>
-<i>Requires:</i> Those signatures taking a <tt>const value_type&</tt> parameter
-requires both the <tt>key_type</tt> and the <tt>mapped_type</tt> to be
-<tt>CopyConstructible</tt>.
-</ins></p>
+<p>
+add a new one:
+</p>
-<p><ins>
-<tt>P</tt> shall be convertible to <tt>value_type</tt>.
- If <tt>P</tt> is instantiated as a reference
-type, then the argument <tt>x</tt> is copied from. Otherwise <tt>x</tt>
-is considered to be an rvalue as it is converted to <tt>value_type</tt>
-and inserted into the <tt>unordered_multimap</tt>. Specifically, in such
-cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or
-<tt>mapped_type</tt> unless the conversion from <tt>P</tt> specifically
-requires it (e.g. if <tt>P</tt> is a <tt>tuple<const key_type,
-mapped_type></tt>, then <tt>key_type</tt> must be
-<tt>CopyConstructible</tt>).
-</ins></p>
+<blockquote><pre>template <class T> 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 <class T> struct is_literal;</tt></td>
+<td><tt>T</tt> is a literal type (3.9)</td>
+<td><tt>T</tt> shall be a complete type, an
+array of unknown bound, or
+(possibly cv-qualified) <tt>void</tt>.</td>
+</tr>
+</tbody></table>
+
+
+
+
+
+
+<hr>
+<h3><a name="720"></a>720. Omissions in constexpr usages</h3>
+<p><b>Section:</b> 23.2.1 [array], 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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<T,N>::empty() const</tt> should be a
+<tt>constexpr</tt> because this is easily to proof and to implement following it's operational
+semantics defined by Table 87 (Container requirements) which says: <tt>a.size() == 0</tt>.
+</li>
+<li>
+The member function <tt>bool bitset<N>::test() const</tt> must be a
+<tt>constexpr</tt> (otherwise it would violate the specification of <tt>constexpr
+bitset<N>::operator[](size_t) const</tt>, because it's return clause delegates to <tt>test()</tt>).
+</li>
+<li>
+I wonder how the constructor <tt>bitset<N>::bitset(unsigned long)</tt> can
+be declared as a <tt>constexpr</tt>. Current implementations usually have no such <tt>bitset</tt>
+c'tor which would fulfill the requirements of a <tt>constexpr</tt> c'tor because they have a
+non-empty c'tor body that typically contains for-loops or <tt>memcpy</tt> to compute the
+initialisation. What have I overlooked here?
+</li>
+</ol>
-<p><ins>
-The signature taking <tt>InputIterator</tt>
-parameters requires <tt>CopyConstructible</tt> of both
-<tt>key_type</tt> and <tt>mapped_type</tt> if the dereferenced
-<tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
-<tt>value_type</tt>.
-</ins></p>
-</blockquote>
-</blockquote>
+<p><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>
-Add to 23.4.2.2 [unord.multimap.swap]:
+and in 23.3.5.2 [bitset.members] change
</p>
-<blockquote>
-<pre>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
- unordered_multimap<Key, T, Hash, Pred, Alloc>& y);
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>& x,
- unordered_multimap<Key, T, Hash, Pred, Alloc>&& y);</ins>
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_multimap<Key, T, Hash, Pred, Alloc>&& x,
- unordered_multimap<Key, T, Hash, Pred, Alloc>& y);</ins>
-</pre>
-</blockquote>
+<blockquote><pre><ins>constexpr</ins> bool test(size_t pos ) const;
+</pre></blockquote>
+
+</li>
+</ol>
+
+
-<p><b><tt>unordered_set</tt></b></p>
+
+<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>
-Change 23.4.3 [unord.set]:
+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>
-<blockquote><pre>class unordered_set
+<p>
+How are we going to explain this code to beginning programmers?
+</p>
+
+<blockquote><pre>template<class I, class E, class S>
+struct codecvt : std::codecvt<I, E, S>
{
- ...
- unordered_set(const unordered_set&);
- <ins>unordered_set(unordered_set&&);</ins>
- ~unordered_set();
- unordered_set& operator=(const unordered_set&);
- <ins>unordered_set& operator=(unordered_set&&);</ins>
- ...
- // modifiers
- <del>std::</del>pair<iterator, bool> insert(const value_type& obj);
- <ins>pair<iterator, bool> insert(value_type&& obj);</ins>
- iterator insert(iterator hint, const value_type& obj);
- <ins>iterator insert(iterator hint, value_type&& obj);</ins>
- const_iterator insert(const_iterator hint, const value_type& obj);
- <ins>const_iterator insert(const_iterator hint, value_type&& obj);</ins>
- ...
- void swap(unordered_set&<ins>&</ins>);
- ...
+ ~codecvt()
+ { }
};
-template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x,
- unordered_set<Key, T, Hash, Pred, Alloc>& y);
+void main()
+{
+ std::wstring_convert<codecvt<wchar_t, char, std::mbstate_t> > compiles_ok;
+
+ std::wstring_convert<std::codecvt<wchar_t, char, std::mbstate_t> > not_ok;
+}
+</pre></blockquote>
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x,
- unordered_set<Key, T, Hash, Pred, Alloc>&& y);</ins>
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_set<Key, T, Hash, Pred, Alloc>&& x,
- unordered_set<Key, T, Hash, Pred, Alloc>& y);</ins>
-</pre></blockquote>
+<p><b>Proposed resolution:</b></p>
<p>
-Add to 23.4.3.1 [unord.set.cnstr]:
</p>
-<blockquote>
-<pre>template <class InputIterator>
- unordered_set(InputIterator f, InputIterator l,
- size_type n = <i>implementation-defined</i>,
- const hasher& hf = hasher(),
- const key_equal& eql = key_equal(),
- const allocator_type& a = allocator_type());
-</pre>
-<blockquote><p>
-<ins>
-<i>Requires:</i> If the iterator's dereference operator returns an
-lvalue or a const rvalue <tt>value_type</tt>, then the
-<tt>value_type</tt> shall be <tt>CopyConstructible</tt>.
-</ins>
-</p></blockquote>
-</blockquote>
+
+
+<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>
-Add new section [unord.set.modifiers]:
+In the listing of 26.7 [c.math], table 108: Header <tt><cmath></tt> synopsis I miss
+the following C99 functions (from 7.12.11.2):
</p>
-<blockquote>
-<pre><ins>pair<iterator, bool> insert(const value_type& x);</ins>
-<ins>pair<iterator, bool> insert(value_type&& x);</ins>
-<ins>iterator insert(iterator hint, const value_type& x);</ins>
-<ins>iterator insert(iterator hint, value_type&& x);</ins>
-<ins>const_iterator insert(const_iterator hint, const value_type& x);</ins>
-<ins>const_iterator insert(const_iterator hint, value_type&& x);</ins>
-<ins>template <class InputIterator>
- void insert(InputIterator first, InputIterator last);</ins>
-</pre>
+<blockquote><pre>float nanf(const char *tagp);
+long double nanl(const char *tagp);
+</pre></blockquote>
-<blockquote>
+<p>
+(Note: These functions cannot be overloaded and they are also not
+listed anywhere else)
+</p>
-<p><ins>
-<i>Requires:</i> Those signatures taking a <tt>const
-value_type&</tt> parameter requires the <tt>value_type</tt> to
-be <tt>CopyConstructible</tt>.
-</ins></p>
-<p><ins>
-The signature taking <tt>InputIterator</tt> parameters requires
-<tt>CopyConstructible</tt> of <tt>value_type</tt> if the dereferenced
-<tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
-<tt>value_type</tt>.
-</ins></p>
+<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>
+
-</blockquote>
-</blockquote>
+
+<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>
-Add to 23.4.3.2 [unord.set.swap]:
+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>
-<blockquote>
-<pre>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x,
- unordered_set<Key, T, Hash, Pred, Alloc>& y);
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_set<Key, T, Hash, Pred, Alloc>& x,
- unordered_set<Key, T, Hash, Pred, Alloc>&& y);</ins>
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_set<Key, T, Hash, Pred, Alloc>&& x,
- unordered_set<Key, T, Hash, Pred, Alloc>& y);</ins>
-</pre>
-</blockquote>
-
-<p><b><tt>unordered_multiset</tt></b></p>
+<p><b>Proposed resolution:</b></p>
+<ol type="a">
+<li>
<p>
-Change 23.4.4 [unord.multiset]:
+In the header <tt><regex></tt> synopsis 28.4 [re.syn], just below the function
+template <tt>swap</tt> add two further overloads:
+</p>
+<blockquote><pre>template <class charT, class traits>
+ void swap(basic_regex<charT, traits>& e1, basic_regex<charT, traits>& e2);
+<ins>template <class charT, class traits>
+ void swap(basic_regex<charT, traits>&& e1, basic_regex<charT, traits>& e2);
+template <class charT, class traits>
+ void swap(basic_regex<charT, traits>& e1, basic_regex<charT, traits>&& e2);</ins>
+</pre></blockquote>
+<p>
+In the class definition of <tt>basic_regex</tt>, just below 28.8 [re.regex]/3,
+perform the following changes:
</p>
+</li>
-<blockquote><pre>class unordered_multiset
-{
- ...
- unordered_multiset(const unordered_multiset&);
- <ins>unordered_multiset(unordered_multiset&&);</ins>
- ~unordered_multiset();
- unordered_multiset& operator=(const unordered_multiset&);
- <ins>unordered_multiset& operator=(unordered_multiset&&);</ins>
- ...
- // modifiers
- iterator insert(const value_type& obj);
- <ins>iterator insert(value_type&& obj);</ins>
- iterator insert(iterator hint, const value_type& obj);
- <ins>iterator insert(iterator hint, value_type&& obj);</ins>
- const_iterator insert(const_iterator hint, const value_type& obj);
- <ins>const_iterator insert(const_iterator hint, value_type&& obj);</ins>
- ...
- void swap(unordered_multiset&<ins>&</ins>);
- ...
-};
+<li>
+<p>Just after the copy c'tor:</p>
+<blockquote><pre>basic_regex(basic_regex&&);
+</pre></blockquote>
+</li>
-template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x,
- unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
+<li>
+<p>Just after the copy-assignment op.:</p>
+<blockquote><pre>basic_regex& operator=(basic_regex&&);
+</pre></blockquote>
+</li>
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x,
- unordered_multiset<Key, T, Hash, Pred, Alloc>&& y);</ins>
+<li>
+<p>Just after the first <tt>assign</tt> overload insert:</p>
+<blockquote><pre>basic_regex& assign(basic_regex&& that);
+</pre></blockquote>
+</li>
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>&& x,
- unordered_multiset<Key, T, Hash, Pred, Alloc>& y);</ins>
+<li>
+<p>Change the current <tt>swap</tt> function to read:</p>
+<blockquote><pre>void swap(basic_regex&&);
+</pre></blockquote>
+</li>
+
+<li>
+<p>In 28.8.2 [re.regex.construct], just below the copy c'tor add a
+corresponding member definition of:</p>
+<blockquote><pre>basic_regex(basic_regex&&);
+</pre></blockquote>
+</li>
+
+<li>
+<p>Also in 28.8.2 [re.regex.construct], just below the copy assignment
+c'tor add a corresponding member definition of:</p>
+<blockquote><pre>basic_regex& operator=(basic_regex&&);
+</pre></blockquote>
+</li>
+
+<li>
+<p>In 28.8.3 [re.regex.assign], just below the first <tt>assign</tt> overload add
+a corresponding member definition of:</p>
+<blockquote><pre>basic_regex& assign(basic_regex&& that);
+</pre></blockquote>
+</li>
+
+<li>
+<p>In 28.8.6 [re.regex.swap], change the signature of <tt>swap</tt> to
+say:</p>
+<blockquote><pre>void swap(basic_regex&& e);
+</pre></blockquote>
+</li>
+
+<li>
+<p>In 28.8.7.1 [re.regex.nmswap], just below the single binary <tt>swap</tt>
+function, add the two missing overloads:</p>
+<blockquote><pre>template <class charT, class traits>
+ void swap(basic_regex<charT, traits>&& e1, basic_regex<charT, traits>& e2);
+template <class charT, class traits>
+ void swap(basic_regex<charT, traits>& e1, basic_regex<charT, traits>&& e2);
</pre></blockquote>
+</li>
+</ol>
<p>
-Add to 23.4.4.1 [unord.multiset.cnstr]:
+Of course there would be need of corresponding proper standardese
+to describe these additions.
</p>
-<blockquote>
-<pre>template <class InputIterator>
- unordered_multiset(InputIterator f, InputIterator l,
- size_type n = <i>implementation-defined</i>,
- const hasher& hf = hasher(),
- const key_equal& eql = key_equal(),
- const allocator_type& a = allocator_type());
-</pre>
-<blockquote><p>
-<ins>
-<i>Requires:</i> If the iterator's dereference operator returns an
-lvalue or a const rvalue <tt>value_type</tt>, then the
-<tt>value_type</tt> shall be <tt>CopyConstructible</tt>.
-</ins>
-</p></blockquote>
-</blockquote>
+
+
+
+<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>
-Add new section [unord.multiset.modifiers]:
+In section 20.1.1 [utility.arg.requirements], before table 33, add the
+following table:
</p>
-<blockquote>
-<pre><ins>iterator insert(const value_type& x);</ins>
-<ins>iterator insert(value_type&& x);</ins>
-<ins>iterator insert(iterator hint, const value_type& x);</ins>
-<ins>iterator insert(iterator hint, value_type&& x);</ins>
-<ins>const_iterator insert(const_iterator hint, const value_type& x);</ins>
-<ins>const_iterator insert(const_iterator hint, value_type&& x);</ins>
-<ins>template <class InputIterator>
- void insert(InputIterator first, InputIterator last);</ins>
-</pre>
+<p style="text-align: center;" align="center">Table 33: <tt>DefaultConstructible</tt> requirements</p>
-<blockquote>
+<div align="center">
-<p><ins>
-<i>Requires:</i> Those signatures taking a <tt>const
-value_type&</tt> parameter requires the <tt>value_type</tt> to
-be <tt>CopyConstructible</tt>.
-</ins></p>
+<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>
-<p><ins>
-The signature taking <tt>InputIterator</tt> parameters requires
-<tt>CopyConstructible</tt> of <tt>value_type</tt> if the dereferenced
-<tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
-<tt>value_type</tt>.
-</ins></p>
+</div>
-</blockquote>
-</blockquote>
+
+
+
+
+<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>
-Add to 23.4.4.2 [unord.multiset.swap]:
+Surely that's meant to be "operational semantics?"
</p>
+
+
+<p><b>Proposed resolution:</b></p>
<blockquote>
-<pre>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x,
- unordered_multiset<Key, T, Hash, Pred, Alloc>& y);
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>& x,
- unordered_multiset<Key, T, Hash, Pred, Alloc>&& y);</ins>
-<ins>template <class Key, class T, class Hash, class Pred, class Alloc>
- void swap(unordered_multiset<Key, T, Hash, Pred, Alloc>&& x,
- unordered_multiset<Key, T, Hash, Pred, Alloc>& y);</ins>
-</pre>
+<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="677"></a>677. Weaknesses in seed_seq::randomize [rand.util.seedseq]</h3>
-<p><b>Section:</b> 2
6.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>
+<h3><a name="726"></a>726. Missing <tt>regex_replace()</tt> overloads</h3>
+<p><b>Section:</b> 2
8.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>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>
+Two overloads of <tt>regex_replace()</tt> are currently provided:
+</p>
+
+<blockquote><pre>template <class OutputIterator, class BidirectionalIterator,
+ class traits, class charT>
+ OutputIterator
+ regex_replace(OutputIterator out,
+ BidirectionalIterator first, BidirectionalIterator last,
+ const basic_regex<charT, traits>& e,
+ const basic_string<charT>& fmt,
+ regex_constants::match_flag_type flags =
+ regex_constants::match_default);
+
+template <class traits, class charT>
+ basic_string<charT>
+ regex_replace(const basic_string<charT>& s,
+ const basic_regex<charT, traits>& e,
+ const basic_string<charT>& fmt,
+ regex_constants::match_flag_type flags =
+ regex_constants::match_default);
+</pre></blockquote>
<ol>
+<li>Overloads taking <tt>const charT *</tt> are provided for <tt>regex_match()</tt> and
+<tt>regex_search()</tt>, but not <tt>regex_replace()</tt>. This is inconsistent.</li>
<li>
-<p> 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 <= 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 < 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 absence of <tt>const charT *</tt> overloads prevents ordinary-looking code from compiling, such as:</p>
+
+<blockquote><pre>const string s("kitten");
+const regex r("en");
+cout << regex_replace(s, r, "y") << endl;
+</pre></blockquote>
+
<p>
-The 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.
+The compiler error message will be something like "could not deduce
+template argument for 'const std::basic_string<_Elem> &' from 'const
+char[1]'".
</p>
+
<p>
-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>
+Users expect that anything taking a <tt>basic_string<charT></tt> can also take a
+<tt>const charT *</tt>. In their own code, when they write a function taking
+<tt>std::string</tt> (or <tt>std::wstring</tt>), they can pass a <tt>const char *</tt> (or <tt>const
+wchar_t *</tt>), thanks to <tt>basic_string</tt>'s implicit constructor. Because the
+regex algorithms are templated on <tt>charT</tt>, they can't rely on
+<tt>basic_string</tt>'s implicit constructor (as the compiler error message
+indicates, template argument deduction fails first).
</p>
+
<p>
-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>
+If a user figures out what the compiler error message means, workarounds
+are available - but they are all verbose. Explicit template arguments
+could be given to <tt>regex_replace()</tt>, allowing <tt>basic_string</tt>'s implicit
+constructor to be invoked - but <tt>charT</tt> is the last template argument, not
+the first, so this would be extremely verbose. Therefore, constructing
+a <tt>basic_string</tt> from each C string is the simplest workaround.
</p>
+</li>
+
+<li>
+There is an efficiency consideration: constructing <tt>basic_string</tt>s can
+impose performance costs that could be avoided by a library
+implementation taking C strings and dealing with them directly.
+(Currently, for replacement sources, C strings can be converted into
+iterator pairs at the cost of verbosity, but for format strings, there
+is no way to avoid constructing a <tt>basic_string</tt>.)
+</li>
+</ol>
+
+
+
+<p><b>Proposed resolution:</b></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 < 7</tt>).
+Provide additional overloads for <tt>regex_replace()</tt>: one additional
+overload of the iterator-based form (taking <tt>const charT* fmt</tt>), and three
+additional overloads of the convenience form (one taking <tt>const charT*
+str</tt>, another taking <tt>const charT* fmt</tt>, and the third taking both <tt>const
+charT* str</tt> and <tt>const charT* fmt</tt>). 28.11.4 [re.alg.replace]:
</p>
+
+<blockquote>
+<pre>template <class OutputIterator, class BidirectionalIterator,
+ class traits, class charT>
+ OutputIterator
+ regex_replace(OutputIterator out,
+ BidirectionalIterator first, BidirectionalIterator last,
+ const basic_regex<charT, traits>& e,
+ const basic_string<charT>& fmt,
+ regex_constants::match_flag_type flags =
+ regex_constants::match_default);
+
+<ins>template <class OutputIterator, class BidirectionalIterator,
+ class traits, class charT>
+ OutputIterator
+ regex_replace(OutputIterator out,
+ BidirectionalIterator first, BidirectionalIterator last,
+ const basic_regex<charT, traits>& e,
+ const charT* fmt,
+ regex_constants::match_flag_type flags =
+ regex_constants::match_default);</ins>
+</pre>
+<p>...</p>
+<pre>template <class traits, class charT>
+ basic_string<charT>
+ regex_replace(const basic_string<charT>& s,
+ const basic_regex<charT, traits>& e,
+ const basic_string<charT>& fmt,
+ regex_constants::match_flag_type flags =
+ regex_constants::match_default);
+
+<ins>template <class traits, class charT>
+ basic_string<charT>
+ regex_replace(const basic_string<charT>& s,
+ const basic_regex<charT, traits>& e,
+ const charT* fmt,
+ regex_constants::match_flag_type flags =
+ regex_constants::match_default);</ins>
+
+<ins>template <class traits, class charT>
+ basic_string<charT>
+ regex_replace(const charT* s,
+ const basic_regex<charT, traits>& e,
+ const basic_string<charT>& fmt,
+ regex_constants::match_flag_type flags =
+ regex_constants::match_default);</ins>
+
+<ins>template <class traits, class charT>
+ basic_string<charT>
+ regex_replace(const charT* s,
+ const basic_regex<charT, traits>& e,
+ const charT* fmt,
+ regex_constants::match_flag_type flags =
+ regex_constants::match_default);</ins>
+</pre>
+</blockquote>
+
+
+
+
+
+
+<hr>
+<h3><a name="727"></a>727. <tt>regex_replace()</tt> doesn't accept <tt>basic_string</tt>s with custom traits and allocators</h3>
+<p><b>Section:</b> 28.11.4 [re.alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
+ <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2007-09-22</p>
+<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re.alg.replace">active issues</a> in [re.alg.replace].</p>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.alg.replace">issues</a> in [re.alg.replace].</p>
+<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
+<p><b>Discussion:</b></p>
<p>
-Since <tt>seed_seq</tt> was introduced relatively recently there is little cost
-in making this incompatible improvement to it.
+<tt>regex_match()</tt> and <tt>regex_search()</tt> take <tt>const basic_string<charT, ST,
+SA>&</tt>. <tt>regex_replace()</tt> takes <tt>const basic_string<charT>&</tt>. This prevents
+<tt>regex_replace()</tt> from accepting <tt>basic_string</tt>s with custom traits and
+allocators.
</p>
<p><b>Proposed resolution:</b></p>
<p>
-The following is the proposed replacement of paragraph 8 of section
-26.4.7.1 [rand.util.seedseq]:
+Overloads of <tt>regex_replace()</tt> taking <tt>basic_string</tt> should be additionally
+templated on <tt>class ST, class SA</tt> and take <tt>const basic_string<charT, ST,
+SA>&</tt>. Consistency with <tt>regex_match()</tt> and <tt>regex_search()</tt> would place
+<tt>class ST, class SA</tt> as the first template arguments; compatibility with
+existing code using TR1 and giving explicit template arguments to
+<tt>regex_replace()</tt> would place <tt>class ST, class SA</tt> as the last template
+arguments.
+</p>
+
+
+
+
+
+<hr>
+<h3><a name="728"></a>728. Problem in [rand.eng.mers]/6</h3>
+<p><b>Section:</b> 26.4.3.2 [rand.eng.mers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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>
-<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>:
+I see two possible resolutions:
</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>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>
-<blockquote><pre><ins>
-fill(begin, end, 0x8b8b8b8b);
-
-if (n >= 623)
- t = 11;
-else if (n >= 68)
- t = 7;
-else if (n >= 39)
- t = 5;
-else if (n >= 7)
- t = 3;
-else
- t = (n-1)/2;
-
-p = (n-t)/2;
-q = p+t;
-
-m = max(s+1, n);
-for (k = 0; k < 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 <= s)
- r += v[k-1];
- begin[k+q] += r;
- begin[k] = r;
-}
+<p>
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for further discussion.
+</p>
-for (k = m; k < 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>
+
+<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="678"></a>678. Changes for [rand.req.eng]</h3>
+<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> 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>
+ <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>
-Section 26.4.1.3 [rand.req.eng] Random number engine requirements:
+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<X::result_type>(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>
-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>.
+<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<UintType>(s)</tt>, where <tt>UintType</tt> is an
+implementation specific unsigned integer type."
</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:
+Additionally, the definition of s in 26.4.1.3 [rand.req.eng]/1 c) could be restricted to unsigned integer types.
</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() > 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>
+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><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]:
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for further discussion.
</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> 2
3.2 [sequences] <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-06-11</p>
+<h3><a name="730"></a>730. Comment on [rand.req.adapt]/3 e)</h3>
+<p><b>Section:</b> 2
6.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>
-The C++98 standard specifies that one member function alone of the containers
-passes its parameter (<tt>T</tt>) by value instead of by const reference:
+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>
-<blockquote><pre>void resize(size_type sz, T c = T());
-</pre></blockquote>
-
<p>
-This fact has been discussed / debated repeatedly over the years, the first time
-being even before C++98 was ratified. The rationale for passing this parameter by
-value has been:
+<b>Posssible resolution:</b> [As above]
</p>
-<blockquote>
<p>
-So that self referencing statements are guaranteed to work, for example:
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for further discussion.
</p>
-<blockquote><pre>v.resize(v.size() + 1, v[0]);
-</pre></blockquote>
-</blockquote>
-<p>
-However this rationale is not convincing as the signature for <tt>push_back</tt> is:
-</p>
-<blockquote><pre>void push_back(const T& x);
-</pre></blockquote>
+<p><b>Proposed resolution:</b></p>
<p>
-And <tt>push_back</tt> has similar semantics to <tt>resize</tt> (append).
-And <tt>push_back</tt> must also work in the self referencing case:
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for the proposed resolution.
</p>
-<blockquote><pre>v.push_back(v[0]); // must work
-</pre></blockquote>
+
+
+
+<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 problem with passing <tt>T</tt> by value is that it can be significantly more
-expensive than passing by reference. The converse is also true, however when it is
-true it is usually far less dramatic (e.g. for scalar types).
+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>
-Even with move semantics available, passing this parameter by value can be expensive.
-Consider for example <tt>vector<vector<int>></tt>:
+<b>Possible resolution:</b>
</p>
-<blockquote><pre>std::vector<int> x(1000);
-std::vector<std::vector<int>> v;
-...
-v.resize(v.size()+1, x);
+<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 <typename T>
+struct is_seed_seq { static const bool value = false; }
</pre></blockquote>
+<p>and the specialization</p>
+<blockquote><pre>template <>
+struct is_seed_seq<seed_seq> { 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>
-In the pass-by-value case, <tt>x</tt> is copied once to the parameter of
-<tt>resize</tt>. And then internally, since the code can not know at compile
-time by how much <tt>resize</tt> is growing the <tt>vector</tt>, <tt>x</tt> is
-usually copied (not moved) a second time from <tt>resize</tt>'s parameter into its proper place
-within the <tt>vector</tt>.
+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>
-With pass-by-const-reference, the <tt>x</tt> in the above example need be copied
-only once. In this case, <tt>x</tt> has an expensive copy constructor and so any
-copies that can be saved represents a significant savings.
+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>
-If we can be efficient for <tt>push_back</tt>, we should be efficient for <tt>resize</tt>
-as well. The resize taking a reference parameter has been coded and shipped in the
-CodeWarrior library with no reports of problems which I am aware of.
+<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>
-Change 23.2.2 [deque], p2:
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for the proposed resolution.
</p>
-<blockquote><pre>class deque {
- ...
- void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c);
-</pre></blockquote>
+
+
+
+<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>
-Change 23.2.2.2 [deque.capacity], p3:
+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>
-<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c);
-</pre></blockquote>
-
-<p><b>Proposed resolution:</b></p>
<p>
-Change 23.2.3 [list], p2:
+<b>Proposed resolution:</b> I propose to drop this requirement.
</p>
-<blockquote><pre>class list {
- ...
- void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c);
-</pre></blockquote>
+<p><b>Proposed resolution:</b></p>
<p>
-Change 23.2.3.2 [list.capacity], p3:
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for the proposed resolution.
</p>
-<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c);
-</pre></blockquote>
-<p><b>Proposed resolution:</b></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>
-Change 23.2.5 [vector], p2:
+<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>
-<blockquote><pre>class vector {
- ...
- void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c);
-</pre></blockquote>
+<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>
-Change 23.2.5.2 [vector.capacity], p11:
+<b>Possible resolution:</b> For these reasons, I propose to change the type of the respective parameters
+to double.
</p>
-<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c);
-</pre></blockquote>
+<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="680"></a>680. move_iterator operator-> return</h3>
-<p><b>Section:</b> 2
4.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>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-06-11</p>
+<h3><a name="735"></a>735. Unfortunate naming</h3>
+<p><b>Section:</b> 2
6.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>
-<tt>move_iterator</tt>'s <tt>operator-></tt> return type <tt>pointer</tt>
-does not consistently match the type which is returned in the description
-in 24.4.3.3.5 [move.iter.op.ref].
+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>
-<blockquote><pre>template <class Iterator>
-class move_iterator {
-public:
- ...
- typedef typename iterator_traits<Iterator>::pointer pointer;
- ...
- pointer operator->() const {return current;}
- ...
-private:
- Iterator current; // exposition only
-};
-</pre></blockquote>
+<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>
-There are two possible fixes.
+<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>
-<ol>
-<li><tt>pointer operator->() const {return &*current;}</tt></li>
-<li><tt>typedef Iterator pointer;</tt></li>
-</ol>
+<p><b>Proposed resolution:</b></p>
<p>
-The first solution is the one chosen by <tt>reverse_iterator</tt>. A potential
-disadvantage of this is it may not work well with iterators which return a
-proxy on dereference and that proxy has overloaded <tt>operator&()</tt>. Proxy
-references often need to overloaad <tt>operator&()</tt> to return a proxy
-pointer. That proxy pointer may or may not be the same type as the iterator's
-<tt>pointer</tt> type.
+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>
-By simply returning the <tt>Iterator</tt> and taking advantage of the fact that
-the language forwards calls to <tt>operator-></tt> automatically until it
-finds a non-class type, the second solution avoids the issue of an overloaded
-<tt>operator&()</tt> entirely.
+<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>
-Change the synopsis in 24.4.3.1 [move.iterator]:
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for the proposed resolution.
</p>
-<blockquote><pre>typedef <del>typename iterator_traits<</del>Iterator<del>>::pointer</del> pointer;
-</pre></blockquote>
-
-
<hr>
-<h3><a name="681"></a>681. Operator functions impossible to compare are defined in [re.submatch.op]</h3>
-<p><b>Section:</b> 2
8.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>
+<h3><a name="737"></a>737. Comment on [rand.dist.samp.pconst]</h3>
+<p><b>Section:</b> 2
6.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>
-In 28.9.2 [re.submatch.op] of N2284,
-operator functions numbered 31-42 seem impossible to compare. E.g.:
+The design of the constructor
</p>
-
-<blockquote>
-<pre>template <class BiIter>
- bool operator==(typename iterator_traits<BiIter>::value_type const& lhs,
- const sub_match<BiIter>& rhs);
-</pre>
-<blockquote>
+<blockquote><pre>template <class InputIteratorB, class InputIteratorW>
+piecewise_constant_distribution( InputIteratorB firstB, InputIteratorB lastB,
+ InputIteratorW firstW);
+</pre></blockquote>
<p>
--31- <i>Returns:</i> <tt>lhs == rhs.str()</tt>.
+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>
-</blockquote>
-</blockquote>
+</li>
+</ol>
<p>
-When <tt>char*</tt> is used as <tt>BiIter</tt>, <tt>iterator_traits<BiIter>::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<char></tt>. However, the behaviour of comparison between
-these two types is not defined in 21.3.8 [string.nonmembers] of N2284.
- This applies when <tt>wchar_t*</tt> is used as <tt>BiIter</tt>.
+<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="682"></a>682. basic_regex ctor takes InputIterator or ForwardIterator?</h3>
-<p><b>Section:</b> 2
8.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>
+<h3><a name="738"></a>738. Editorial issue in [rand.adapt.disc]/3</h3>
+<p><b>Section:</b> 2
6.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>
-Looking at N2284, 28.8 [re.regex], p3 <tt>basic_regex</tt> class template synopsis shows this
-constructor:
+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>
-<blockquote><pre>template <class InputIterator>
- basic_regex(InputIterator first, InputIterator last,
- flag_type f = regex_constants::ECMAScript);
-</pre></blockquote>
+
+<p><b>Proposed resolution:</b></p>
<p>
-In 28.8.2 [re.regex.construct], p15, the constructor appears with this signature:
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for the proposed resolution.
</p>
-<blockquote><pre>template <class ForwardIterator>
- basic_regex(ForwardIterator first, ForwardIterator last,
- 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>
+<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>
-I think either could be implemented? Although an input iterator would
-probably require an internal copy of the string being made.
+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>
-I have no strong feelings either way, although I think my original intent
-was <tt>InputIterator</tt>.
+See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
+for further discussion.
</p>
-</blockquote>
+
<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="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>
- <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>
+<h3><a name="740"></a>740. Please remove <tt>*_ptr<T[N]></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>
-In 28.4 [re.syn] of N2284, two template functions
-are declared here:
+Please don't provide <tt>*_ptr<T[N]></tt>. It doesn't enable any useful
+bounds-checking (e.g., you could imagine that doing <tt>op++</tt> on a
+<tt>shared_ptr<T[N]></tt> yields a <tt>shared_ptr<T[N-1]></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>
-<blockquote><pre>// 28.10, class template match_results:
- <<i>snip</i>>
-// match_results comparisons
- template <class BidirectionalIterator, class Allocator>
- bool operator== (const match_results<BidirectionalIterator, Allocator>& m1,
- const match_results<BidirectionalIterator, Allocator>& m2);
- template <class BidirectionalIterator, class Allocator>
- bool operator!= (const match_results<BidirectionalIterator, Allocator>& m1,
- const match_results<BidirectionalIterator, Allocator>& m2);
-// 28.10.6, match_results swap:
-</pre></blockquote>
+<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><T[N]></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>
-But the details of these two bool operator functions (i.e., which members of
-<tt>match_results</tt> should be used in comparison) are not described in any
-following sections.
+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><i>[
-John adds:
-]</i></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<T[N]></tt> which equally makes the smart pointer more like
+<tt>std::array.</tt> :-)
+</p>
-<blockquote><p>
-That looks like a bug: <tt>operator==</tt> should return <tt>true</tt> only if
-the two objects refer to the same match - ie if one object was constructed as a
-copy of the other.
-</p></blockquote>
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the synopsis under 20.6.5 [unique.ptr] p2:
+</p>
+<blockquote><pre>...
+template<class T> struct default_delete;
+template<class T> struct default_delete<T[]>;
+<del>template<class T, size_t N> struct default_delete<T[N]>;</del>
+
+template<class T, class D = default_delete<T>> class unique_ptr;
+template<class T, class D> class unique_ptr<T[], D>;
+<del>template<class T, class D, size_t N> class unique_ptr<T[N], D>;</del>
+...
+</pre></blockquote>
+
+<p>
+Remove the entire section 20.6.5.1.3 [unique.ptr.dltr.dflt2] <b><tt>default_delete<T[N]></tt></b>.
+</p>
-<p><b>Proposed resolution:</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="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>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-06-10</p>
+<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>
-In C++03 the difference between two <tt>reverse_iterators</tt>
+The following issue was raised by Alf P. Steinbach in c.l.c++.mod:
</p>
-<blockquote><pre>ri1 - ri2
+
+<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<class D, class T> D* get_deleter(shared_ptr<T> const& p);
</pre></blockquote>
+
<p>
-is possible to compute only if both iterators have the same base
-iterator. The result type is the <tt>difference_type</tt> of the base iterator.
+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>
-In the current draft, the operator is defined as 24.4.1.3.19 [reverse.iter.opdiff]
+Replace the declarations of <tt>get_deleter</tt> in the header <tt><memory></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>
-<blockquote><pre>template<class Iterator1, class Iterator2>
-typename reverse_iterator<Iterator>::difference_type
- operator-(const reverse_iterator<Iterator1>& x,
- const reverse_iterator<Iterator2>& y);
+
+<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<class D, class T> const D* get_deleter(shared_ptr<T> const& p);
</pre></blockquote>
+</li>
+<li>
+Just remove the function.
+</li>
+</ol>
+
<p>
-The return type is the same as the C++03 one, based on the no longer
-present <tt>Iterator</tt> template parameter.
+Alberto Ganesh Barbati adds:
+</p>
+
+<ol start="3" type="A">
+<li>
+<p>
+Replace it with two functions:
</p>
+<blockquote><pre>template <class D, class T> D get_deleter(shared_ptr<T> const&);
+template <class D, class T> bool has_deleter(shared_ptr<T> const&);
+</pre></blockquote>
+
<p>
-Besides being slightly invalid, should this operator work only when
-<tt>Iterator1</tt> and <tt>Iterator2</tt> has the same <tt>difference_type</tt>? Or should the
-implementation choose one of them? Which one?
+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>
-The same problem now also appears in <tt>operator-()</tt> for <tt>move_iterator</tt>
-24.4.3.3.14 [move.iter.nonmember].
+My favorite option is "not a defect". A, B and C break useful code.
</p>
+</blockquote>
+
<p><b>Proposed resolution:</b></p>
<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>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2007-06-14</p>
+<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>
-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
-for example) the returned value is constrained to disallow
-unintended conversions to int. The standardese is
-</p>
-<blockquote><p>
-The return type shall not be convertible to <tt>int</tt>.
-</p></blockquote>
-<p>
-This constraint is omitted for <tt>unique_ptr</tt> and <tt>shared_ptr</tt>. It should be added for those.
+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><b>Proposed resolution:</b></p>
<p>
-To the <i>Returns</i> paragraph for <tt>operator <i>unspecified-bool-type</i>()
-const</tt>
-of 20.6.5.2.4 [unique.ptr.single.observers] paragraph 11 and 20.6.6.2.5
-[util.smartptr.shared.obs] paragraph 16, add the sentence:
+This issue seeks to widen the <tt>Swappable</tt> requirement to support proxy iterators. Here
+is example code:
</p>
-<blockquote><p>
-The return type shall not be convertible to <tt>int</tt>.
-</p></blockquote>
+<blockquote><pre>namespace Mine {
+
+template <class T>
+struct proxy {...};
+template <class T>
+struct proxied_iterator
+{
+ typedef T value_type;
+ typedef proxy<T> reference;
+ reference operator*() const;
+ ...
+};
+struct A
+{
+ // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
+ void swap(A&);
+ ...
+};
+void swap(A&, A&);
+void swap(proxy<A>, A&);
+void swap(A&, proxy<A>);
+void swap(proxy<A>, proxy<A>);
-<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>
- <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>Discussion:</b></p>
-<p>
-Since all conversions from <tt>shared_ptr<T></tt> to <tt>shared_ptr<U></tt> have the same
-rank regardless of the relationship between <tt>T</tt> and <tt>U</tt>, reasonable user
-code that works with raw pointers fails with <tt>shared_ptr</tt>:
-</p>
+} // Mine
-<blockquote><pre>void f( shared_ptr<void> );
-void f( shared_ptr<int> );
+...
-int main()
-{
- f( shared_ptr<double>() ); // ambiguous
-}
+Mine::proxied_iterator<Mine::A> i(...)
+Mine::A a;
+<b>swap(*i1, a);</b>
</pre></blockquote>
<p>
-Now that we officially have <tt>enable_if</tt>, we can constrain the constructor
-and the corresponding assignment operator to only participate in the
-overload resolution when the pointer types are compatible.
+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>
-In 20.6.6.2.1 [util.smartptr.shared.const], change:
+Change 20.1.1 [utility.arg.requirements]:
</p>
-<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
-to <tt>T*</tt>.
-</p></blockquote>
+<blockquote>
<p>
-In 20.6.6.3.1 [util.smartptr.weak.const], change:
+-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>
-<blockquote>
-<pre><del>template<class Y> weak_ptr(shared_ptr<Y> const& r);</del>
-<del>weak_ptr(weak_ptr const& r);</del>
-<del>template<class Y> weak_ptr(weak_ptr<Y> const& r);</del>
-<ins>weak_ptr(weak_ptr const& r);</ins>
-<ins>template<class Y> weak_ptr(weak_ptr<Y> const& r);</ins>
-<ins>template<class Y> weak_ptr(shared_ptr<Y> const& r);</ins>
-</pre>
-<blockquote><p>
--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>.
-</p></blockquote>
+<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="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>
- <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>
+<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>
-A <tt>reference_wrapper</tt> can be constructed from an rvalue, either by using
-the constructor, or via <tt>cref</tt> (and <tt>ref</tt> in some corner cases). This leads
-to a dangling reference being stored into the <tt>reference_wrapper</tt> object.
-Now that we have a mechanism to detect an rvalue, we can fix them to
-disallow this source of undefined behavior.
+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><b>Proposed resolution:</b></p>
<p>
-In 20.5.5 [refwrap], add:
+This issue was opened in response to that note.
</p>
-<blockquote><pre><ins>private:</ins>
-<ins> explicit reference_wrapper(T&&);</ins>
-</pre></blockquote>
-
<p>
-In 20.5.5.1 [refwrap.const], add:
+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>
-<blockquote>
-<pre><ins>explicit reference_wrapper(T&&);</ins>
-</pre>
-<blockquote><p>
-<ins>-?- Not defined to disallow creating a <tt>reference_wrapper</tt> from an rvalue.</ins>
-</p></blockquote>
-</blockquote>
+
+<p><b>Proposed resolution:</b></p>
<p>
-In the synopsis of <tt><functional></tt> (20.5.5 [refwrap]), change the declarations
-of <tt>ref</tt> and <tt>cref</tt> to:
+Change the synopsis in 20.6.6.2 [util.smartptr.shared]:
</p>
-<blockquote><pre>template<class T> reference_wrapper<T> ref(T&<ins>&</ins>);
-template<class T> reference_wrapper<const T> cref(<del>const</del> T&<ins>&</ins>);
+<blockquote><pre>void swap(shared_ptr&<ins>&</ins> r);
+...
+template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>& b);
+<ins>template<class T> void swap(shared_ptr<T>&& a, shared_ptr<T>& b);
+template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>&& b);</ins>
</pre></blockquote>
<p>
-In 20.5.5.5 [refwrap.helpers], change:
-</p>
-
-<blockquote>
-<pre>template<class T> reference_wrapper<T> ref(T&<ins>&</ins> t);
-</pre>
-<blockquote>
-<p>
-<ins>-1- <i>Requires:</i> <tt>t</tt> shall be an lvalue.</ins>
+Change 20.6.6.2.4 [util.smartptr.shared.mod]:
</p>
-</blockquote>
-</blockquote>
-<p>and change:</p>
+<blockquote><pre>void swap(shared_ptr&<ins>&</ins> r);
+</pre></blockquote>
-<blockquote>
-<pre>template<class T> reference_wrapper<const T> cref(<del>const</del> T&<ins>&</ins> t);
-</pre>
-<blockquote>
<p>
-<ins>-6- <i>Requires:</i> <tt>t</tt> shall be an lvalue.</ins>
+Change 20.6.6.2.9 [util.smartptr.shared.spec]:
</p>
-</blockquote>
-</blockquote>
+<blockquote><pre>template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>& b);
+<ins>template<class T> void swap(shared_ptr<T>&& a, shared_ptr<T>& b);
+template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>&& b);</ins>
+</pre></blockquote>
<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>
- <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>
+<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>
-The constructor of <tt>reference_wrapper</tt> is currently <tt>explicit</tt>. The primary
-motivation behind this is the safety problem with respect to rvalues,
-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.
+Without some lifetime guarantee, it is hard to know how this type can be
+used. 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>
-Remove the <tt>explicit</tt> from the constructor of <tt>reference_wrapper</tt>. If the
-proposed resolution of the previous issue is accepted, remove the
-<tt>explicit</tt> from the <tt>T&&</tt> constructor as well to keep them in sync.
</p>
<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>
+<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>
-Quoting the latest draft (n2135), 26.7 [c.math]:
+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. Instead it slices, which appears to be less
+useful, and a likely source of FAQ questions in the future.
</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?
+(Peter Dimov suggests NAD)
</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>
- <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>
+<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>
-The last version of TR1 does not include the following member
-functions
-for unordered containers:
+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>. For instance, the Core
+language for a failed new expression is:
</p>
-
-<blockquote><pre>const_local_iterator cbegin(size_type n) const;
-const_local_iterator cend(size_type n) const;
-</pre></blockquote>
-
+<blockquote>
<p>
-which looks like an oversight to me. I've checked th TR1 issues lists
-and the latest working draft of the C++0x std (N2284) and haven't
-found any mention to these menfuns or to their absence.
+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>
-Is this really an oversight, or am I missing something?
+I prefer the clause 17 approach myself, and maybe clean up any outstanding
+wording that could also rely on it.
</p>
<hr>
-<h3><a name="692"></a>692. <code>get_money</code> and <code>put_money</code> should be formatted I/O functions</h3>
-<p><b>Section:</b> 27.6.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</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>
+<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>
-In a private email Bill Plauger notes:
+We have 3 separate type traits to identify classes supporting no-throw
+operations, which are very useful when trying to provide exception safety
+guarantees. However, I'm not entirely clear on what the current wording
+requires of a conforming implementation. To quote from
+<tt>has_nothrow_default_constructor</tt>:
</p>
<blockquote><p>
-I believe that the function that implements <code>get_money</code>
-[from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2072.html">N2072</a>]
-should behave as a formatted input function, and the function that
-implements <code>put_money</code> should behave as a formatted output
-function. This has implications regarding the skipping of whitespace
-and the handling of errors, among other things.
+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>
-The words don't say that right now and I'm far from convinced that
-such a change is editorial.
-</p></blockquote>
+E.g.
+</p>
+
+<blockquote><pre>struct test{
+ int x;
+ test() : x() {}
+};
+</pre></blockquote>
<p>
-Martin's response:
+Should I expect a conforming compiler to
+ <tt>assert( has_nothrow_constructor<test>::value )</tt>
</p>
-<blockquote><p>
-I agree that the manipulators should handle exceptions the same way as
-formatted I/O functions do. The text in N2072 assumes so but the
-<i>Returns</i> clause explicitly omits exception handling for the sake
-of brevity. The spec should be clarified to that effect.
+<p>
+Is this a QoI issue?
</p>
<p>
-As for dealing with whitespace, I also agree it would make sense for
-the extractors and inserters involving the new manipulators to treat
-it the same way as formatted I/O.
-</p></blockquote>
+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>
-Add a new paragraph immediately above p4 of 27.6.4 [ext.manip] with the
-following text:
-</p>
-<blockquote><p>
-<i>Effects</i>: The expression <code><i>in</i> >> get_money(mon, intl)</code>
-described below behaves as a formatted input function (as
-described in 27.6.1.2.1 [istream.formatted.reqmts]).
-</p></blockquote>
-<p>
-Also change p4 of 27.6.4 [ext.manip] as follows:
</p>
-<blockquote><p>
-<i>Returns</i>: An object <code>s</code> of unspecified type such that
-if <code>in</code> is an object of type <code>basic_istream<charT,
-traits></code> then the expression <code><i>in</i> >> get_money(mon, intl)</code> behaves as <ins>a formatted input function
-that calls </ins><code>f(in, mon, intl)</code><del> were
-called</del>. The function <code>f</code> can be defined as...
-</p></blockquote>
<hr>
-<h3><a name="693"></a>693. <code>std::bitset::all()</code> missing</h3>
-<p><b>Section:</b> 2
3.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> 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>
+<h3><a name="748"></a>748. The is_abstract type trait is defined by reference to 10.4.</h3>
+<p><b>Section:</b> 2
0.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>
-The <code>bitset</code> class template provides the member function
-<code>any()</code> to determine whether an object of the type has any
-bits set, and the member function <code>none()</code> to determine
-whether all of an object's bits are clear. However, the template does
-not provide a corresponding function to discover whether a
-<code>bitset</code> object has all its bits set. While it is
-possible, even easy, to obtain this information by comparing the
-result of <code>count()</code> with the result of <code>size()</code>
-for equality (i.e., via <code>b.count() == b.size()</code>) the
-operation is less efficient than a member function designed
-specifically for that purpose could be. (<code>count()</code> must
-count all non-zero bits in a <code>bitset</code> a word at a time
-while <code>all()</code> could stop counting as soon as it encountered
-the first word with a zero bit).
+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:
+ abstract(){}
+ abstract( abstract const & ) {}
+ ~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>
-Add a declaration of the new member function <code>all()</code> to the
-defintion of the <code>bitset</code> template in 23.3.5 [template.bitset], p1,
-right above the declaration of <code>any()</code> as shown below:
</p>
-<blockquote><pre>bool operator!=(const bitset<N>& rhs) const;
-bool test(size_t pos) const;
-<ins>bool all() const;</ins>
-bool any() const;
-bool none() const;
-</pre></blockquote>
+
+
+
+<hr>
+<h3><a name="749"></a>749. Currently <tt>has_nothrow_copy_constructor<T>::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>
-Add a description of the new member function to the end of 23.3.5.2 [bitset.members] with the following text:
+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>
-<blockquote><p>
-<code>bool all() const;</code>
+<p>
+For instance:
</p>
<blockquote>
-<i>Returns</i>: <code>count() == b.size()</code>.
-</blockquote>
+<pre>struct awkward {
+ awkward( const awkward & ) throw() {}
+ awkward( awkward & ) { throw "oops"; } };
+</pre>
</blockquote>
+
+<p><b>Proposed resolution:</b></p>
<p>
-In addition, change the description of <code>any()</code> and
-<code>none()</code> for consistency with <code>all()</code> as
-follows:
-</p>
-<blockquote><p>
-<code>bool any() const;</code>
-</p>
-<blockquote>
-<p>
-<i>Returns</i>: <del><code>true</code> if any bit in <code>*this</code>
-is one</del><ins><code>count() != 0</code></ins>.
</p>
-</blockquote>
+
+
+
+
+
+<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>
-<code>bool none() const;</code>
+With the pending arrival of explicit conversion functions though, I'm
+wondering if we want an additional trait, <tt>is_explictly_convertible</tt>?
</p>
-<blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
<p>
-<i>Returns</i>: <del><code>true</code> if no bit in <code>*this</code>
-is one</del><ins><code>count() == 0</code></ins>.
</p>
-</blockquote>
-</blockquote>
<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>
- <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>
+<h3><a name="751"></a>751. change pass-by-reference members of <tt>vector<bool></tt> to pass-by-value?</h3>
+<p><b>Section:</b> 23.2.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>
-Objects of the <code>bitset</code> class template specializations can
-be constructed from and explicitly converted to values of the widest
-C++ integer type, <code>unsigned long</code>. With the introduction
-of <code>long long</code> into the language the template should be
-enhanced to make it possible to interoperate with values of this type
-as well, or perhaps <code>uintmax_t</code>. See c++std-lib-18274 for
-a brief discussion in support of this change.
+A number of vector<bool> members take const bool& as arguments.
+Is there any chance we could change them to pass-by-value or would I
+be wasting everyone's time if wrote up an issue?
</p>
<p><b>Proposed resolution:</b></p>
<p>
-For simplicity, instead of adding overloads for <code>unsigned long
-long</code> and dealing with possible ambiguities in the spec, replace
-the <code>bitset</code> ctor that takes an <code>unsigned long</code>
-argument with one taking <code>unsigned long long</code> in the
-definition of the template as shown below. (The standard permits
-implementations to add overloads on other integer types or employ
-template tricks to achieve the same effect provided they don't cause
-ambiguities or changes in behavior.)
</p>
-<blockquote>
-<pre>// [bitset.cons] constructors:
-bitset();
-bitset(unsigned <ins>long</ins> long val);
-template<class charT, class traits, class Allocator>
-explicit bitset(
- const basic_string<charT,traits,Allocator>& str,
- typename basic_string<charT,traits,Allocator>::size_type pos = 0,
- typename basic_string<charT,traits,Allocator>::size_type n =
- basic_string<charT,traits,Allocator>::npos);
-</pre>
-</blockquote>
+
+
+
+
+
+<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>
-Make a corresponding change in 23.3.5.1 [bitset.cons], p2:
+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>
-<blockquote>
<p>
-<code>bitset(unsigned <ins>long</ins> long val);</code>
+As I think I pointed out earlier, this is currently fiction for
+<tt>allocate()</tt> if it has to obtain memory from the OS, and it's unclear to
+me how to interpret this for <tt>construct()</tt> and <tt>destroy()</tt> if they deal with
+large objects. Would it be controversial to officially let these take
+time linear in the size of the object, as they already do in real life?
</p>
-<blockquote>
-<i>Effects</i>: Constructs an object of class bitset<N>,
-initializing the first <code><i>M</i></code> bit positions to the
-corresponding bit values in <code><i>val</i></code>.
-<code><i>M</i></code> is the smaller of <code><i>N</i></code> and the
-number of bits in the value representation (section [basic.types]) of
-<code>unsigned <ins> long</ins> long</code>. If <code><i>M</i> <
-<i>N</i></code> <ins>is <code>true</code></ins>, the remaining bit
-positions are initialized to zero.
-</blockquote>
-</blockquote>
-
<p>
-Additionally, introduce a new member function <code>to_ullong()</code>
-to make it possible to convert <code>bitset</code> to values of the
-new type. Add the following declaration to the definition of the
-template, immediate after the declaration of <code>to_ulong()</code>
-in 23.3.5 [template.bitset], p1, as shown below:
+<tt>Allocate()</tt> more blatantly takes time proportional to the size of the
+object if you mix in GC. But it's not really a new problem, and I think
+we'd be confusing things by leaving the bogus requirements there. The
+current requirement on <tt>allocate()</tt> is generally not important anyway,
+since it takes O(size) to construct objects in the resulting space.
+There are real performance issues here, but they're all concerned with
+the constants, not the asymptotic complexity.
</p>
-<blockquote>
-<pre>// element access:
-bool operator[](size_t pos) const; // for b[i];
-reference operator[](size_t pos); // for b[i];
-unsigned long to_ulong() const;
-<ins>unsigned long long to_ullong() const;</ins>
-template <class charT, class traits, class Allocator>
-basic_string<charT, traits, Allocator> to_string() const;
-</pre>
-</blockquote>
+
+
+<p><b>Proposed resolution:</b></p>
<p>
-And add a description of the new member function to 23.3.5.2 [bitset.members],
-below the description of the existing <code>to_ulong()</code> (if
-possible), with the following text:
+Change 20.1.2 [allocator.requirements]/2:
</p>
+
<blockquote>
<p>
-<code>unsigned long long to_ullong() const;</code>
+-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>
-<i>Throws</i>: <code>overflow_error</code> if the integral value
-<code><i>x</i></code> corresponding to the bits in <code>*this</code>
-cannot be represented as type <code>unsigned long long</code>.
-</blockquote>
-<blockquote>
-<i>Returns:</i> <code><i>x</i></code>.
-</blockquote>
</blockquote>
<hr>
-<h3><a name="695"></a>695. ctype<char>::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>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p>
+<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 <code>ctype<char>::classic_table()</code> static member
-function returns a pointer to an array of const
-<code>ctype_base::mask</code> objects (enums) that contains
-<code>ctype<char>::table_size</code> elements. The table
-describes the properties of the character set in the "C" locale (i.e.,
-whether a character at an index given by its value is alpha, digit,
-punct, etc.), and is typically used to initialize the
-<code>ctype<char></code> facet in the classic "C" locale (the
-protected <code>ctype<char></code> member function
-<code>table()</code> then returns the same value as
-<code>classic_table()</code>).
+The draft standard n2369 uses the term <i>move constructor</i> in a few
+places, but doesn't seem to define it.
</p>
+
<p>
-However, while <code>ctype<char>::table_size</code> (the size of
-the table) is a public static const member of the
-<code>ctype<char></code> specialization, the
-<code>classic_table()</code> static member function is protected. That
-makes getting at the classic data less than convenient (i.e., one has
-to create a whole derived class just to get at the masks array). It
-makes little sense to expose the size of the table in the public
-interface while making the table itself protected, especially when the
-table is a constant object.
+<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>
-The same argument can be made for the non-static protected member
-function <code>table()</code>.
+(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><b>Proposed resolution:</b></p>
<p>
-Make the <code>ctype<char>::classic_table()</code> and
-<code>ctype<char>::table()</code> member functions public by
-moving their declarations into the public section of the definition of
-specialization in 22.2.1.3 [facet.ctype.special] as shown below:
+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>
-<pre> static locale::id id;
- static const size_t table_size = IMPLEMENTATION_DEFINED;
-<del>protected:</del>
- const mask* table() const throw();
- static const mask* classic_table() throw();
-<ins>protected:</ins>
-~ctype(); // virtual
-virtual char do_toupper(char c) const;
-</pre>
+<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="696"></a>696. <code>istream::operator>>(int&)</code> broken</h3>
-<p><b>Section:</b> 2
7.6.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-23</p>
-<p><b>View 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>
+<h3><a name="754"></a>754. Ambiguous return clause for <tt>std::uninitialized_copy</tt></h3>
+<p><b>Section:</b> 2
0.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>
-From message c++std-lib-17897:
+14882-2003, [lib.uninitialized.copy] is currently written as follows:
</p>
+
+<blockquote>
+<pre>template <class InputIterator, class ForwardIterator>
+ ForwardIterator uninitialized_copy(InputIterator <i>first</i>, InputIterator <i>last</i>,
+ ForwardIterator <i>result</i>);
+</pre>
+<blockquote>
<p>
-The code shown in 27.6.1.2.2 [istream.formatted.arithmetic] as the "as if"
-implementation of the two arithmetic extractors that don't have a
-corresponding <code>num_get</code> interface (i.e., the
-<code>short</code> and <code>int</code> overloads) is subtly buggy in
-how it deals with <code>EOF</code>, overflow, and other similar
-conditions (in addition to containing a few typos).
+-1- <i>Effects:</i>
</p>
+<blockquote><pre>for (; first != last; ++result, ++first)
+ new (static_cast<void*>(&*result))
+ typename iterator_traits<ForwardIterator>::value_type(*first);
+</pre></blockquote>
<p>
-One problem is that if <code>num_get::get()</code> reaches the EOF
-after reading in an otherwise valid value that exceeds the limits of
-the narrower type (but not <code>LONG_MIN</code> or
-<code>LONG_MAX</code>), it will set <code><i>err</i></code> to
-<code>eofbit</code>. Because of the if condition testing for
-<code>(<i>err</i> == 0)</code>, the extractor won't set
-<code>failbit</code> (and presumably, return a bogus value to the
-caller).
+-2- <i>Returns:</i> <tt><i>result</i></tt>
</p>
+</blockquote>
+</blockquote>
+
<p>
-Another problem with the code is that it never actually sets the
-argument to the extracted value. It can't happen after the call to
-<code>setstate()</code> since the function may throw, so we need to
-show when and how it's done (we can't just punt as say: "it happens
-afterwards"). However, it turns out that showing how it's done isn't
-quite so easy since the argument is normally left unchanged by the
-facet on error except when the error is due to a misplaced thousands
-separator, which causes <code>failbit</code> to be set but doesn't
-prevent the facet from storing the value.
+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>
+
<!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>
<td align="left">Howard Hinnant <<a href="mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>></td>
</tr>
</tbody></table>
-<h1>C++ Standard Library 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>
<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>
<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>
<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>
<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>
<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>
<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>
<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>
<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>
<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>
</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.
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.
<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>
<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>
<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>
<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>
<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> <tt>void operator=(const valarray<T>&) 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> <tt>void operator=(const T&); </tt></p>
</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>
</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>
</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>
</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>
<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>
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>
<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>
<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>
<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>
<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>
<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>
<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>
<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>
<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>
<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>
<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
<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:
<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
]</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>
+
+
<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>
<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>
<hr>
<h3><a name="345"></a>345. type tm in <cwchar></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 <wchar.h>
-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
<cwchar>. 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>
<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>
<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)?->~T()
+</pre>
+
+<p>
+.... with the prerequisits coming from the preceding two paragraphs, especially
+from table 31:
+</p>
+
+<pre> alloc<T> a ;// an allocator for T
+ alloc<T>::pointer p ;// random access iterator
+ // (may be different from T*)
+ alloc<T>::reference r = *p;// T&
+ T const& 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<T>::pointer, so it would implicitely introduce extra
+requirements for alloc<T>::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)?->dtor_name" with
+"p?->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>
<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>
<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);
<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<class ForwardIterator>
+ <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<class ForwardIterator>
+ <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>
<hr>
<h3><a name="520"></a>520. Result_of and pointers to data members</h3>
-<p><b>Section:</b> 20.5.1
0.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.1
1.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>
<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<> 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>
<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 < 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
+> 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 < 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 > 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.1
0 [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.1
1 [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>
<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>
<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>
<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>
<hr>
<h3><a name="545"></a>545. When is a deleter deleted?</h3>
-<p><b>Section:</b> 20.6.6.2.1
0 [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.1
1 [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>
<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>
<hr>
-<h3><a name="559"></a>559. numeric_limits<const T></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>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#limits">issues</a> in [limits].</p>
+<h3><a name="551"></a>551. <ccomplex></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>
+<p>
+Previously xxx.h was parsable by C++. But in the case of C99's <complex.h>
+it isn't. Otherwise we could model it just like <string.h>, <cstring>, <string>:
+</p>
-18.2.1 [limits], p2 requires implementations to provide specializations of the
-<code>numeric_limits</code> template for each scalar type. While this
-could be interepreted to include cv-qualified forms of such types such
-an interepretation is not reflected in the synopsis of the
-<code><limits></code> header.
+<ul>
+<li><string> : C++ API in namespace std</li>
+<li><cstring> : C API in namespace std</li>
+<li><string.h> : C API in global namespace</li>
+</ul>
- </p>
- <p>
+<p>
+In the case of C's complex, the C API won't compile in C++. So we have:
+</p>
-The absence of specializations of the template on cv-qualified forms
-of fundamental types makes <code>numeric_limits</code> difficult to
-use in generic code where the constness (or volatility) of a type is
-not always immediately apparent. In such contexts, the primary
-template ends up being instantiated instead of the provided
-specialization, typically yielding unexpected behavior.
+<ul>
+<li><complex> : C++ API in namespace std</li>
+<li><ccomplex> : ?</li>
+<li><complex.h> : ?</li>
+</ul>
- </p>
- <p>
+<p>
+The ? can't refer to the C API. TR1 currently says:
+</p>
+
+<ul>
+<li><complex> : C++ API in namespace std</li>
+<li><ccomplex> : C++ API in namespace std</li>
+<li><complex.h> : 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><ccomplex></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><complex></tt>.</del>
+<ins>[<i>Note:</i> <tt><complex.h></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<const T></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>
+<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#limits">issues</a> in [limits].</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>
+
+18.2.1 [limits], p2 requires implementations to provide specializations of the
+<code>numeric_limits</code> template for each scalar type. While this
+could be interepreted to include cv-qualified forms of such types such
+an interepretation is not reflected in the synopsis of the
+<code><limits></code> header.
+
+ </p>
+ <p>
+
+The absence of specializations of the template on cv-qualified forms
+of fundamental types makes <code>numeric_limits</code> difficult to
+use in generic code where the constness (or volatility) of a type is
+not always immediately apparent. In such contexts, the primary
+template ends up being instantiated instead of the provided
+specialization, typically yielding unexpected behavior.
+
+ </p>
+ <p>
Require that specializations of <code>numeric_limits</code> on
cv-qualified fundamental types have the same semantics as those on the
<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 < 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 < 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 > 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>
<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 < *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 < *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>
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 <cwchar>' 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><cwchar></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 <limits>' contains two
+errors in the specialisation of numeric_limits<decimal::decimal128>:
+</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><limits></code>" change numeric_limits<decimal::decimal128> as follows:
+</p>
+<pre> template<> class numeric_limits<decimal::decimal128> {
+ 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 & d32);</del>
+ <del>decimal32 & operator=(const decimal32 & 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 & d32);</del>
+ <del>decimal32 & operator=(const decimal32 & 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 & d64);</del>
+ <del>decimal64 & operator=(const decimal64 & 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 & d64);</del>
+ <del>decimal64 & operator=(const decimal64 & 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 & d128);</del>
+ <del>decimal128 & operator=(const decimal128 & 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 & d128);</del>
+ <del>decimal128 & operator=(const decimal128 & 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<charT, InputIterator></del> <ins>std::locale</ins> & <i>b</i>, size_t <i>refs</i> = 0);
+
+ /* ... */
+
+ <del>// <i>const std::num_get<charT, InputIterator> & <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<charT, InputIterator></del> <ins>std::locale</ins> & <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<charT, InputIterator></del> <ins>std::locale</ins> & <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 &, ios_base::iostate &, bool &) const</code>, <i>et al</i> to
+</p>
+<blockquote><p>
+<b>Returns:</b> <code><del><i>base</i></del> <ins>std::use_facet<std::num_get<charT, InputIterator> >(<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<charT, OutputIterator></del> <ins>std::locale</ins> & <i>b</i>, size_t <i>refs</i> = 0);
+
+ /* ... */
+
+ <del>// <i>const std::num_put<charT, OutputIterator> & <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<charT, OutputIterator></del> <ins>std::locale</ins> & <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<charT, OutputIterator></del> <ins>std::locale</ins> & <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 &, char_type, bool &) const</code>, <i>et al</i> to
+</p>
+<blockquote><p>
+<b>Returns:</b> <code><del><i>base</i></del> <ins>std::use_facet<std::num_put<charT, OutputIterator> >(<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: <decfloat.h> 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 <decfloat.h> header. The
+contents of that header have been moved into <float.h>. 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><cdecfloat></code> and <code><decfloat.h></code>" to "Additions to headers <code><cfloat></code> and <code><float.h></code>."
+</p>
+<p>
+2. Change the text of subclause 3.4 as follows:
+</p>
+<blockquote>
+<p>
+<del>The standard C++ headers <code><cfloat></code> and <code><float.h></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><cdecfloat></code> and <code><decfloat.h></code> define characteristics of the decimal floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>. As well, <code><decfloat.h></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><cfloat></code> is described in [tr.c99.cfloat]. The header <code><float.h></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><float.h></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><cdecfloat></code> synopsis" to "Additions to header <code><cfloat></code> synopsis."
+</p>
+<p>
+4. Change the heading of subclause 3.4.2, "Header <code><decfloat.h></code> synopsis" to "Additions to header <code><float.h></code> synopsis."
+</p>
+<p>
+5. Change the contents of 3.4.2 as follows:
+</p>
+<pre> <del>#include <cdecfloat></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(&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<> class numeric_limits<float> {
+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<> class numeric_limits<bool> {
+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<charT>::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<charT>::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<class InputIterator>
+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 <class <del>ForwardIterator</del> <ins>InputIterator</ins>>
+ 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&</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>&<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&</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&</tt> to return something other
+than the address of <tt>*this</tt>.
+</p>
+
+<p>
+An example of when you want to overload <tt>operator&</tt> to return something
+other than the object's address is proxy references such as <tt>vector<bool></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&</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>&<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&</tt>.</ins>
+</p>
+</blockquote>
+
+<pre>const_pointer address(address(const_reference <i>x</i>) const;</pre>
+<blockquote>
+<p>
+-2- <i>Returns:</i> <del><tt>&<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&</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<<(long long val );
+operator<<(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<charT,char,typename traits::state_type> <i>a_codecvt</i> =
+ use_facet<codecvt<charT,char,typename traits::state_type> >(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<charT,char,typename traits::state_type><ins>&</ins> <i>a_codecvt</i> =
+ use_facet<codecvt<charT,char,typename traits::state_type> >(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<charT><ins>&</ins> <i>punct</i> = use_facet< numpunct<charT> >(<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<class Function2> <del>bool</del> <ins>void</ins> operator==(const function<Function2>&);
+ template<class Function2> <del>bool</del> <ins>void</ins> operator!=(const function<Function2>&);
+};
+</pre></blockquote>
+
+<p>
+Change X [func.wrap.func.undef]
+</p>
+
+<blockquote><pre>template<class Function2> <del>bool</del> <ins>void</ins> operator==(const function<Function2>&);
+template<class Function2> <del>bool</del> <ins>void</ins> operator!=(const function<Function2>&);
+</pre></blockquote>
+
+
+
+
+
+<hr>
+<h3><a name="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&) <ins>const</ins>;
+bool operator!=(const regex_token_iterator&) <ins>const</ins>;
+const value_type& operator*() <ins>const</ins>;
+const value_type* operator->() <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& right) <ins>const</ins>;
+bool operator!=(const regex_token_iterator& 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& operator*() <ins>const</ins>;
+const value_type* operator->() <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>>= -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&) <ins>const</ins>;
+bool operator!=(const regex_iterator&) <ins>const</ins>;
+const value_type& operator*() <ins>const</ins>;
+const value_type* operator->() <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& operator*() <ins>const</ins>;
+const value_type* operator->() <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& right) <ins>const</ins>;
+bool operator!=(const regex_iterator& 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 << x was
+subsequently read via is >> 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 <cassert>
+#include <ostream>
+#include <iostream>
+#include <iomanip>
+#include <sstream>
+
+class RanNumEngine {
+ int state;
+public:
+ RanNumEngine() : state(42) {}
+
+ bool operator==(RanNumEngine other) const {
+ return state == other.state;
+ }
+
+ template <typename Ch, typename Tr>
+ friend std::basic_ostream<Ch, Tr>& operator<<(std::basic_ostream<Ch, Tr>& os, RanNumEngine engine) {
+ Ch old = os.fill(os.widen(' ')); // Sets space character
+ std::ios_base::fmtflags f = os.flags();
+ os << std::dec << std::left << engine.state; // Adds ios_base::dec|ios_base::left
+ os.fill(old); // Undo
+ os.flags(f);
+ return os;
+ }
+
+ template <typename Ch, typename Tr>
+ friend std::basic_istream<Ch, Tr>& operator>>(std::basic_istream<Ch, Tr>& is, RanNumEngine& engine) {
+ // Uncomment only for the fix.
+
+ //std::ios_base::fmtflags f = is.flags();
+ //is >> std::dec;
+ is >> engine.state;
+ //is.flags(f);
+ return is;
+ }
+};
+
+int main() {
+ std::stringstream s;
+ s << std::setfill('#'); // No problem
+ s << std::oct; // Yikes!
+ // Here starts para 5 requirements:
+ RanNumEngine x;
+ s << x;
+ RanNumEngine v;
+ s >> 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<class RealType, class UniformRandomNumberGenerator,
+ size_t bits>
+result_type generate_canonical(UniformRandomNumberGenerator& 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 ... (|, &, ^) 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
+<functional> synopsis:</p>
+<blockquote>
+ <pre>template <class T> struct bit_and;
+template <class T> struct bit_or;
+template <class T> 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 <class T> struct bit_and : binary_function<T,T,T> {
+ T operator()(const T& x , const T& y ) const;
+};</pre>
+ <blockquote>
+ <p><code>operator()</code> returns<code> x & y</code> .</p>
+ </blockquote>
+ <pre>template <class T> struct bit_or : binary_function<T,T,T> {
+ T operator()(const T& x , const T& y ) const;
+};</pre>
+ <blockquote>
+ <p><code>operator()</code> returns <code>x | y</code> .</p>
+ </blockquote>
+ <pre>template <class T> struct bit_xor : binary_function<T,T,T> {
+ T operator()(const T& x , const T& 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 <= 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 < 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 < 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() > 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. E.g.:
+</p>
+
+<blockquote>
+<pre>
+template <class BiIter>
+ bool operator==(typename iterator_traits<BiIter>::value_type const& lhs,
+ const sub_match<BiIter>& 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<BiIter>::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<char></tt>. However, the behaviour of comparison between
+these two types is not defined in 21.3.8 [string.nonmembers] of N2284.
+ 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 <class InputIterator>
+ basic_regex(InputIterator first, InputIterator last,
+ 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 <class ForwardIterator>
+ basic_regex(ForwardIterator first, ForwardIterator last,
+ 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? 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
OSDN Git Service
