diff options
Diffstat (limited to 'libstdc++-v3')
| -rw-r--r-- | libstdc++-v3/ChangeLog | 7 | ||||
| -rw-r--r-- | libstdc++-v3/doc/html/ext/lwg-active.html | 9102 | ||||
| -rw-r--r-- | libstdc++-v3/doc/html/ext/lwg-closed.html | 1044 | ||||
| -rw-r--r-- | libstdc++-v3/doc/html/ext/lwg-defects.html | 3691 | ||||
| -rw-r--r-- | libstdc++-v3/doc/xml/manual/intro.xml | 12 |
5 files changed, 9204 insertions, 4652 deletions
diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog index cbb6671a568..c4a4926b1a0 100644 --- a/libstdc++-v3/ChangeLog +++ b/libstdc++-v3/ChangeLog @@ -1,3 +1,10 @@ +2008-09-22 Paolo Carlini <paolo.carlini@oracle.com> + + * doc/html/ext/lwg-closed.html: Update to Revision R59. + * doc/html/ext/lwg-active.html: Likewise. + * doc/html/ext/lwg-defects.html: Likewise. + * doc/xml/manual/intro.xml: Adjust. + 2008-09-21 Paolo Carlini <paolo.carlini@oracle.com> * include/bits/stl_algo.h (minmax(initializer_list<>): Use make_pair, diff --git a/libstdc++-v3/doc/html/ext/lwg-active.html b/libstdc++-v3/doc/html/ext/lwg-active.html index 27e0ed263e4..94b57c0a6aa 100644 --- a/libstdc++-v3/doc/html/ext/lwg-active.html +++ b/libstdc++-v3/doc/html/ext/lwg-active.html @@ -1,22 +1,24 @@ <!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> - +<html><head> +<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> +<title>C++ Standard Library Active Issues List</title> <style type="text/css"> p {text-align:justify} li {text-align:justify} ins {background-color:#A0FFA0} del {background-color:#FFA0A0} -</style></head><body> +</style> +</head><body> <table> <tbody><tr> <td align="left">Doc. no.</td> -<td align="left">N2612=08-0122</td> +<td align="left">N2727=08-0237</td> </tr> <tr> <td align="left">Date:</td> -<td align="left">2008-05-18</td> +<td align="left">2008-08-24</td> </tr> <tr> <td align="left">Project:</td> @@ -27,7 +29,7 @@ del {background-color:#FFA0A0} <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 R56)</h1> +<h1>C++ Standard Library Active Issues List (Revision R59)</h1> <p>Reference ISO/IEC IS 14882:1998(E)</p> <p>Also see:</p> @@ -94,6 +96,67 @@ del {background-color:#FFA0A0} <h2>Revision History</h2> <ul> +<li>R59: +2008-08-22 pre-San Francisco mailing. +<ul> +<li><b>Summary:</b><ul> +<li>192 open issues, up by 9.</li> +<li>686 closed issues, up by 0.</li> +<li>878 issues total, up by 9.</li> +</ul></li> +<li><b>Details:</b><ul> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#871">871</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#872">872</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#875">875</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#877">877</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>.</li> +</ul></li> +</ul> +</li> +<li>R58: +2008-07-28 mid-term mailing. +<ul> +<li><b>Summary:</b><ul> +<li>183 open issues, up by 12.</li> +<li>686 closed issues, down by 4.</li> +<li>869 issues total, up by 8.</li> +</ul></li> +<li><b>Details:</b><ul> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#864">864</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#869">869</a>.</li> +<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li> +<li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>.</li> +<li>Changed the following issues from WP to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>.</li> +<li>Changed the following issues from Pending NAD Editorial to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>.</li> +</ul></li> +</ul> +</li> +<li>R57: +2008-06-27 post-Sophia Antipolis mailing. +<ul> +<li><b>Summary:</b><ul> +<li>171 open issues, down by 20.</li> +<li>690 closed issues, up by 43.</li> +<li>861 issues total, up by 23.</li> +</ul></li> +<li><b>Details:</b><ul> +<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#840">840</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#858">858</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#861">861</a>.</li> +<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#839">839</a>.</li> +<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#852">852</a>.</li> +<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#851">851</a>.</li> +<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>.</li> +<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>.</li> +<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>.</li> +<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>.</li> +<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>.</li> +<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>.</li> +<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>.</li> +<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#829">829</a>.</li> +<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>.</li> +<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>.</li> +<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>.</li> +<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a>.</li> +<li>Changed the following issues from Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>.</li> +<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li> +</ul></li> +</ul> +</li> <li>R56: 2008-05-16 pre-Sophia Antipolis mailing. <ul> @@ -103,7 +166,7 @@ del {background-color:#FFA0A0} <li>838 issues total, up by 25.</li> </ul></li> <li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#826">826</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#831">831</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#838">838</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#838">838</a>.</li> <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>.</li> </ul></li> </ul> @@ -121,7 +184,7 @@ del {background-color:#FFA0A0} <li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#790">790</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#791">791</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#796">796</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#797">797</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#799">799</a>.</li> <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>.</li> <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#801">801</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a>.</li> -<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#798">798</a>.</li> +<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li> <li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>.</li> <li>Changed the following issues from NAD Future to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.</li> <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>.</li> @@ -130,13 +193,13 @@ del {background-color:#FFA0A0} <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li> <li>Changed the following issues from Review to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>.</li> <li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a>.</li> -<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>.</li> +<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>.</li> <li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>.</li> -<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li> +<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li> <li>Changed the following issues from Open to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#625">625</a>.</li> -<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#710">710</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#722">722</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#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#746">746</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#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#783">783</a>.</li> -<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#550">550</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#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a>.</li> -<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a>, <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#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#685">685</a>.</li> +<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>.</li> +<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>.</li> +<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>.</li> <li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>.</li> <li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>.</li> <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li> @@ -153,7 +216,7 @@ del {background-color:#FFA0A0} <li>787 issues total, up by 23.</li> </ul></li> <li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>.</li> <li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>.</li> <li>Changed the following issues from NAD Future to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>.</li> <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#697">697</a>.</li> @@ -171,7 +234,7 @@ del {background-color:#FFA0A0} <li>764 issues total, up by 10.</li> </ul></li> <li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>.</li> <li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>.</li> <li>Changed the following issues from Pending WP to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li> </ul></li> @@ -186,16 +249,16 @@ del {background-color:#FFA0A0} <li>754 issues total, up by 31.</li> </ul></li> <li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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-closed.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-closed.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-closed.html#754">754</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>.</li> <li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>.</li> <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>.</li> <li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a>.</li> -<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li> +<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li> <li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li> <li>Changed the following issues from New to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li> -<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li> +<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li> <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>.</li> -<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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-closed.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-closed.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 Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>.</li> <li>Changed the following issues from New to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#552">552</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>.</li> <li>Changed the following issues from Open to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#401">401</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>.</li> <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>.</li> @@ -211,7 +274,7 @@ del {background-color:#FFA0A0} <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-closed.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-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>.</li> </ul></li> </ul> </li> @@ -232,10 +295,10 @@ del {background-color:#FFA0A0} <li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li> <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>.</li> <li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>.</li> -<li>Changed the following issues from Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#644">644</a>.</li> +<li>Changed the following issues from Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>.</li> <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>.</li> <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>.</li> -<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a>.</li> +<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>.</li> <li>Changed the following issues from Ready to TRDec: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>.</li> <li>Changed the following issues from DR to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#453">453</a>.</li> <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>.</li> @@ -251,7 +314,7 @@ del {background-color:#FFA0A0} <li>696 issues total, up by 20.</li> </ul></li> <li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li> <li>Added the following Pending NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#683">683</a>.</li> <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#587">587</a>.</li> <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>.</li> @@ -268,7 +331,7 @@ del {background-color:#FFA0A0} <li>676 issues total, up by 20.</li> </ul></li> <li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>.</li> <li>Changed the following issues from Tentatively Ready to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>.</li> <li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li> <li>Changed the following issues from NAD to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#357">357</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#368">368</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a>.</li> @@ -278,7 +341,7 @@ del {background-color:#FFA0A0} <li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li> <li>Changed the following issues from Tentatively Ready to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>.</li> <li>Changed the following issues from Tentatively Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>.</li> -<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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 New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>.</li> <li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>.</li> <li>Changed the following issues from Ready to TRDec: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#598">598</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#599">599</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#600">600</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#601">601</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#602">602</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a>.</li> <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>.</li> @@ -295,9 +358,9 @@ del {background-color:#FFA0A0} <li>656 issues total, up by 37.</li> </ul></li> <li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li> <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li> -<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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 Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#614">614</a>.</li> <li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li> <li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>.</li> <li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>.</li> @@ -329,7 +392,7 @@ del {background-color:#FFA0A0} <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-defects.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li> +<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li> <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#598">598</a> - <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a> to Ready.</li> <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a> to Review.</li> <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>.</li> @@ -418,7 +481,7 @@ Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.ht Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a> from New to Open. Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> from New to Ready. Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD. -Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a> from New to Review. +Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a> from New to Review. </li> <li>R38: 2005-07-03 pre-Mont Tremblant mailing. @@ -753,11 +816,11 @@ format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64 <h2>Active Issues</h2> <hr> <h3><a name="23"></a>23. Num_get overflow result</h3> -<p><b>Section:</b> 22.2.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> +<p><b>Section:</b> 22.2.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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>The current description of numeric input does not account for the possibility of overflow. This is an implicit result of changing the @@ -1107,11 +1170,11 @@ retained for future reference.</p> <hr> <h3><a name="180"></a>180. Container member iterator arguments constness has unintended consequences</h3> -<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> +<p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 1999-07-01</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> <p><b>Discussion:</b></p> <p>It is the constness of the container which should control whether it can be modified through a member function such as erase(), not the @@ -1149,22 +1212,81 @@ single container? </p> </blockquote> +<p><i>[ +Sophia Antipolis: +]</i></p> + + +<blockquote> +<p> +This was a fix that was intended for all standard library containers, +and has been done for other containers, but string was missed. +</p> +<p> +The wording updated. +</p> +<p> +We did not make the change in <tt>replace</tt>, because this change would affect +the implementation because the string may be written into. This is an +issue that should be taken up by concepts. +</p> +<p> +We note that the supplied wording addresses the initializer list provided in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2679.pdf">N2679</a>. +</p> +</blockquote> + <p><b>Proposed resolution:</b></p> -<p>Change all non-const iterator parameters of standard library -container member functions to accept const_iterator parameters. -Note that this change applies to all library clauses, including -strings.</p> +<p> +Update the following signature in the <tt>basic_string</tt> class template definition in +21.3 [basic.string], p5: +</p> +<blockquote><pre>namespace std { + template<class charT, class traits = char_traits<charT>, + class Allocator = allocator<charT> > + class basic_string { -<p>For example, in 21.3.5.5 change:<br> -<br> - <tt>iterator erase(iterator p);</tt><br> -<br> -to:<br> - <tt>iterator erase(const_iterator p);</tt> + ... + + iterator insert(<ins>const_</ins>iterator p, charT c); + void insert(<ins>const_</ins>iterator p, size_type n, charT c); + template<class InputIterator> + void insert(<ins>const_</ins>iterator p, InputIterator first, InputIterator last); + void insert(<ins>const_</ins>iterator <ins>p</ins>, initializer_list<charT>); + + ... + + iterator erase(<ins>const_</ins>iterator <ins>const_</ins>position); + iterator erase(<ins>const_</ins>iterator first, <ins>const_</ins>iterator last); + + ... + + }; +} +</pre></blockquote> + +<p> +Update the following signatures in 21.3.6.4 [string::insert]: </p> +<blockquote><pre>iterator insert(<ins>const_</ins>iterator p, charT c); +void insert(<ins>const_</ins>iterator p, size_type n, charT c); +template<class InputIterator> + void insert(<ins>const_</ins>iterator p, InputIterator first, InputIterator last); +void insert(<ins>const_</ins>iterator <ins>p</ins>, initializer_list<charT>); +</pre></blockquote> + +<p> +Update the following signatures in 21.3.6.5 [string::erase]: +</p> + +<blockquote><pre>iterator erase(<ins>const_</ins>iterator <ins>const_</ins>position); +iterator erase(<ins>const_</ins>iterator first, <ins>const_</ins>iterator last); +</pre></blockquote> + + <p><b>Rationale:</b></p> <p>The issue was discussed at length. It was generally agreed that 1) @@ -1186,7 +1308,6 @@ standard. Also see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lw <h3><a name="190"></a>190. min() and max() functions should be std::binary_functions</h3> <p><b>Section:</b> 25.3.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Mark Rintoul <b>Date:</b> 1999-08-26</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.min.max">active issues</a> in [alg.min.max].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.min.max">issues</a> in [alg.min.max].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> <p><b>Discussion:</b></p> @@ -1294,7 +1415,7 @@ signature.</p> <hr> <h3><a name="290"></a>290. Requirements to for_each and its function object</h3> -<p><b>Section:</b> 25.1.1 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> +<p><b>Section:</b> 25.1.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 2001-01-03</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.foreach">issues</a> in [alg.foreach].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> @@ -2309,7 +2430,8 @@ imaginary part of a[i].</li> </blockquote> <p> -In 26.3.2 [complex] Add the member functions +In 26.3.2 [complex] and 26.3.3 [complex.special] add the following member functions +(changing <tt>T</tt> to concrete types as appropriate for the specializations). </p> <blockquote><pre>void real(T); @@ -2367,6 +2489,26 @@ Bellevue: Second half of proposed wording replaced and moved to Ready. </blockquote> +<p><i>[ +Pre-Sophia Antipolis, Howard adds: +]</i></p> + + +<blockquote> +Added the members to 26.3.3 [complex.special] and changed from Ready to Review. +</blockquote> + +<p><i>[ +Post-Sophia Antipolis: +]</i></p> + + +<blockquote> +Moved from WP back to Ready so that the "and 26.3.3 [complex.special]" in the proposed +resolution can be officially applied. +</blockquote> + + <p><b>Rationale:</b></p> <p>The LWG believes that C99 compatibility would be enough @@ -2484,11 +2626,10 @@ functions should be changed as proposed below. <hr> <h3><a name="396"></a>396. what are characters zero and one</h3> -<p><b>Section:</b> 23.3.5.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> +<p><b>Section:</b> 23.3.5.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-01-05</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#bitset.cons">active issues</a> in [bitset.cons].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.cons">issues</a> in [bitset.cons].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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#Ready">Ready</a> status.</p> <p><b>Discussion:</b></p> <p> 23.3.5.1, p6 [lib.bitset.cons] talks about a generic character @@ -2521,6 +2662,25 @@ http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#303 Also note the typo in 23.3.5.1, p6: the object under construction is a bitset, not a string. </p> + +<p><i>[ +Sophia Antipolis: +]</i></p> + + +<blockquote> +<p> +We note that <tt>bitset</tt> has been moved from section 23 to section 20, by +another issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#842">842</a>) previously resolved at this meeting. +</p> +<p> +Disposition: move to ready. +</p> +<p> +We request that Howard submit a separate issue regarding the three to_string overloads. +</p> +</blockquote> + <p><b>Proposed resolution:</b></p> @@ -2586,6 +2746,15 @@ post Bellevue: We are happy with the resolution as proposed, and we move this to Ready. </blockquote> +<p><i>[ +Howard adds: +]</i></p> + + +<blockquote> +The proposed wording neglects the 3 newer to_string overloads. +</blockquote> + @@ -3655,7 +3824,6 @@ reachability. <h3><a name="454"></a>454. basic_filebuf::open should accept wchar_t names</h3> <p><b>Section:</b> 27.8.1.4 [filebuf.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p> -<p><b>View 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#Open">Open</a> status.</p> <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a></p> @@ -3703,6 +3871,38 @@ Implementors are free to add specific overloads for non-char character types. </p> +<p><i>[ +Martin adds pre-Sophia Antipolis: +]</i></p> + + +<blockquote> +Please see <a href="http://wiki.dinkumware.com/twiki/pub/Wg21sophiaAntipolis/LibraryWorkingGroup/issue-454.html">issue 454: problems and solutions</a>. +</blockquote> + +<p><i>[ +Sophia Antipolis: +]</i></p> + + +<blockquote> +<p> +Beman is concerned that making these changes to <tt>basic_filebuf</tt> is not +usefully changed unless <tt>fstream</tt> is also changed; this also only handles +<tt>wchar_t</tt> and not other character types. +</p> +<p> +The TR2 filesystem library is a more complete solution, but is not available soon. +</p> +</blockquote> + +<p><i>[ +Martin adds: please reference +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2683.html">N2683</a> for +problems and solutions. +]</i></p> + + <p><b>Proposed resolution:</b></p> @@ -4341,10 +4541,10 @@ The expression <tt>delete get()</tt> is well formed. <hr> <h3><a name="471"></a>471. result of what() implementation-defined</h3> -<p><b>Section:</b> 18.6.1 [type.info] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> +<p><b>Section:</b> 18.6.1 [type.info] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-28</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#type.info">issues</a> in [type.info].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</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>[lib.exception] specifies the following:</p> @@ -4418,6 +4618,17 @@ Move to Ready as we are accepting words unmodified. </p> </blockquote> +<p><i>[ +Sophia Antipolis: +]</i></p> + + +<blockquote> +The issue was pulled from Ready. It needs to make clear that only homogenous copying +is intended to be supported. Not coping from a dervied to a base. +</blockquote> + + <p><b>Proposed resolution:</b></p> @@ -5059,80 +5270,12 @@ Berlin: Bill to provide wording. <hr> -<h3><a name="518"></a>518. Are insert and erase stable for unordered_multiset and unordered_multimap?</h3> -<p><b>Section:</b> 23.1.3 [unord.req], TR1 6.3.1 [tr.unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Matt Austern <b>Date:</b> 2005-07-03</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#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -Issue 371 deals with stability of multiset/multimap under insert and erase -(i.e. do they preserve the relative order in ranges of equal elements). -The same issue applies to unordered_multiset and unordered_multimap. -</p> -<p><i>[ -Moved to open (from review): There is no resolution. -]</i></p> - - -<p><i>[ -Toronto: We have a resolution now. Moved to Review. Some concern was noted -as to whether this conflicted with existing practice or not. An additional -concern was in specifying (partial) ordering for an unordered container. -]</i></p> - - - - -<p><b>Proposed resolution:</b></p> -<p> -Wording for the proposed resolution is taken from the equivalent text for associative containers. -</p> - -<p> -Change 23.1.3 [unord.req], Unordered associative containers, paragraph 6 to: -</p> - -<blockquote><p> -An unordered associative container supports <i>unique</i> keys if it may -contain at most one element for each key. Otherwise, it supports <i>equivalent -keys</i>. <tt>unordered_set</tt> and <tt>unordered_map</tt> support -unique keys. <tt>unordered_multiset</tt> and <tt>unordered_multimap</tt> -support equivalent keys. In containers that support equivalent keys, elements -with equivalent keys are adjacent to each other. <ins>For -<tt>unordered_multiset</tt> -and <tt>unordered_multimap</tt>,<tt> insert</tt> and <tt>erase</tt> -preserve the relative ordering of equivalent elements.</ins> -</p></blockquote> - -<p> -Change 23.1.3 [unord.req], Unordered associative containers, paragraph 8 to: -</p> - -<blockquote> -<p>The elements of an unordered associative container are organized into <i> -buckets</i>. Keys with the same hash code appear in the same bucket. The number -of buckets is automatically increased as elements are added to an unordered -associative container, so that the average number of elements per bucket is kept -below a bound. Rehashing invalidates iterators, changes ordering between -elements, and changes which buckets elements appear in, but does not invalidate -pointers or references to elements. <ins>For <tt>unordered_multiset</tt> -and <tt>unordered_multimap</tt>, rehashing -preserves the relative ordering of equivalent elements.</ins></p> -</blockquote> - - - - - - -<hr> <h3><a name="522"></a>522. Tuple doesn't define swap</h3> -<p><b>Section:</b> 20.3 [tuple], TR1 6.1 [tr.tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> +<p><b>Section:</b> 20.4 [tuple], TR1 6.1 [tr.tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Andy Koenig <b>Date:</b> 2005-07-03</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple">active issues</a> in [tuple].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple">issues</a> in [tuple].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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#Ready">Ready</a> status.</p> <p><b>Discussion:</b></p> <p> Tuple doesn't define swap(). It should. @@ -5160,7 +5303,7 @@ Bellevue: Alisdair provided wording. <p><b>Proposed resolution:</b></p> <p> -Add these signatures to 20.3 [tuple] +Add these signatures to 20.4 [tuple] </p> <blockquote><pre>template <class... Types> @@ -5172,7 +5315,7 @@ template <class... Types> </pre></blockquote> <p> -Add this signature to 20.3.1 [tuple.tuple] +Add this signature to 20.4.1 [tuple.tuple] </p> <blockquote><pre>void swap(tuple&&); @@ -5363,9 +5506,9 @@ Pete: Possible general problem with case insensitive ranges. <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#Review">Review</a> +<p><b>Section:</b> 26.6.3 [partial.sum] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Marc Schoolderman <b>Date:</b> 2006-02-06</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</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 some problems in the definition of partial_sum and @@ -5521,6 +5664,21 @@ The intent of the algorithms is to perform their calculations using the type of Proposed wording provided. </blockquote> +<p><i>[ +Sophia Antipolis: +]</i></p> + + +<blockquote> +We did not agree that the proposed resolution was correct. For example, +when the arguments are types <tt>(float*, float*, double*)</tt>, the +highest-quality solution would use double as the type of the +accumulator. If the intent of the wording is to require that the type of +the accumulator must be the <tt>input_iterator</tt>'s <tt>value_type</tt>, the wording +should specify it. +</blockquote> + + <p><b>Proposed resolution:</b></p> <p> @@ -5575,145 +5733,6 @@ list, so that people may use long long as a hash key. <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#Ready">Ready</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#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -Assuming we adopt the -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">C -compatibility package from C99</a> what should be the return type of the -following signature be: -</p> -<blockquote><pre>? pow(float, int); -</pre></blockquote> -<p> -C++03 says that the return type should be <tt>float</tt>. -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf"> -TR1</a> and C90/99 say the return type should be <tt>double</tt>. This can put -clients into a situation where C++03 provides answers that are not as high -quality as C90/C99/TR1. For example: -</p> -<blockquote><pre>#include <math.h> - -int main() -{ - float x = 2080703.375F; - double y = pow(x, 2); -} -</pre></blockquote> -<p> -Assuming an IEEE 32 bit float and IEEE 64 bit double, C90/C99/TR1 all suggest: -</p> - -<blockquote><pre>y = 4329326534736.390625 -</pre></blockquote> - -<p> -which is exactly right. While C++98/C++03 demands: -</p> - -<blockquote><pre>y = 4329326510080. -</pre></blockquote> - -<p> -which is only approximately right. -</p> - -<p> -I recommend that C++0X adopt the mixed mode arithmetic already adopted by -Fortran, C and TR1 and make the return type of <tt>pow(float,int)</tt> be -<tt>double</tt>. -</p> - -<p><i>[ -Kona (2007): Other functions that are affected by this issue include -<tt>ldexp</tt>, <tt>scalbln</tt>, and <tt>scalbn</tt>. We also believe that there is a typo in -26.7/10: <tt>float nexttoward(float, long double);</tt> [sic] should be <tt>float -nexttoward(float, float);</tt> Proposed Disposition: Review (the proposed -resolution appears above, rather than below, the heading "Proposed -resolution") -]</i></p> - - -<p><i>[ -<p> -Howard, post Kona: -</p> -<blockquote> -<p> -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. -</p> -<p> -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>. -</p> -<p> -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: -</p> -<blockquote> -<pre>float nexttoward(float, long double); -</pre> -</blockquote> -<p> -which is what both the C++0X working paper and C99 state (as far as I currently understand). -</p> -<p> -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. -</p> -</blockquote> -]</i></p> - - -<p><i>[ -Bellevue: -]</i></p> - - -<blockquote> -This signature was not picked up from C99. Instead, if one types -pow(2.0f,2), the promotion rules will invoke "double pow(double, -double)", which generally gives special treatment for integral -exponents, preserving full accuracy of the result. New proposed -wording provided. -</blockquote> - - -<p><b>Proposed resolution:</b></p> -<p> -Change 26.7 [c.math] p10: -</p> - -<blockquote> -<p> -The added signatures are: -</p> -<blockquote><pre>... -<del>float pow(float, int);</del> -... -<del>double pow(double, int);</del> -... -<del>long double pow(long double, int);</del> -</pre></blockquote> -</blockquote> - - - - - - -<hr> <h3><a name="556"></a>556. is Compare a BinaryPredicate?</h3> <p><b>Section:</b> 25.3 [alg.sorting] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-05</p> @@ -5933,66 +5952,6 @@ Add <tt>log2</tt> to the list of functions in TR1 8.16.4 [tr.c99.cmath.over] p1. <hr> -<h3><a name="570"></a>570. Request adding additional explicit specializations of char_traits</h3> -<p><b>Section:</b> 21.1 [char.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> - <b>Submitter:</b> Jack Reeves <b>Date:</b> 2006-04-06</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#char.traits">active issues</a> in [char.traits].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits">issues</a> in [char.traits].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> -<p><b>Discussion:</b></p> -<p> -Currently, the Standard Library specifies only a declaration for template class -char_traits<> and requires the implementation provide two explicit -specializations: char_traits<char> and char_traits<wchar_t>. I feel the Standard -should require explicit specializations for all built-in character types, i.e. -char, wchar_t, unsigned char, and signed char. -</p> -<p> -I have put together a paper -(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1985.htm">N1985</a>) -that describes this in more detail and -includes all the necessary wording. -</p> -<p><i>[ -Portland: Jack will rewrite -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1985.htm">N1985</a> -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><i>[ -post Bellevue: -]</i></p> - - -<blockquote> -<p> -We suggest that Jack be asked about the status of his paper, and if it -is not forthcoming, the work-item be assigned to someone else. If no one -steps forward to do the paper before the next meeting, we propose to -make this NAD without further discussion. We leave this Open for now, -but our recommendation is NAD. -</p> -<p> -Note: the issue statement should be updated, as the Toronto comment has -already been resolved. E.g., char_traits specializations for char16_t -and char32_t are now in the working paper. -</p> -</blockquote> - - - -<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#Open">Open</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-04-12</p> @@ -6047,58 +6006,6 @@ these definitions are horrible. Proposed Disposition: Open <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#Ready">Ready</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#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -lib.iostream.objects requires that the standard stream objects are never -destroyed, and it requires that they be destroyed. -</p> -<p> -DR 369 adds words to say that we really mean for ios_base::Init objects to force -construction of standard stream objects. It ends, though, with the phrase "these -stream objects shall be destroyed after the destruction of dynamically ...". -However, the rule for destruction is stated in the standard: "The objects are -not destroyed during program execution." -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Change 27.3 [iostream.objects]/1: -</p> - -<blockquote> -<p> --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><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="580"></a>580. unused allocator members</h3> <p><b>Section:</b> 20.1.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-14</p> @@ -6239,7 +6146,7 @@ post Oxford: This would be rendered NAD Editorial by acceptance of <hr> <h3><a name="582"></a>582. specialized algorithms and volatile storage</h3> -<p><b>Section:</b> 20.6.10.1 [uninitialized.copy] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> +<p><b>Section:</b> 20.7.10.1 [uninitialized.copy] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-14</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#uninitialized.copy">issues</a> in [uninitialized.copy].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> @@ -6637,298 +6544,6 @@ requirements? Alisdair will prepare a paper. Proposed Disposition: Open <hr> -<h3><a name="595"></a>595. TR1/C++0x: fabs(complex<T>) redundant / wrongly specified</h3> -<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.value.ops">active issues</a> in [complex.value.ops].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.value.ops">issues</a> in [complex.value.ops].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -TR1 introduced, in the C compatibility chapter, the function -fabs(complex<T>): -</p> -<blockquote><pre>----- SNIP ----- -8.1.1 Synopsis [tr.c99.cmplx.syn] - - namespace std { - namespace tr1 { -[...] - template<class T> complex<T> fabs(const complex<T>& x); - } // namespace tr1 - } // namespace std - -[...] - -8.1.8 Function fabs [tr.c99.cmplx.fabs] - -1 Effects: Behaves the same as C99 function cabs, defined in - subclause 7.3.8.1. ------ SNIP ----- -</pre></blockquote> - -<p> -The current C++0X draft document (n2009.pdf) adopted this -definition in chapter 26.3.1 (under the comment // 26.3.7 values) -and 26.3.7/7. -</p> -<p> -But in C99 (ISO/IEC 9899:1999 as well as the 9899:TC2 draft document -n1124), the referenced subclause reads -</p> - -<blockquote><pre>----- SNIP ----- -7.3.8.1 The cabs functions - - Synopsis - -1 #include <complex.h> - double cabs(double complex z); - float cabsf(float complex z); - long double cabsl(long double z); - - Description - -2 The cabs functions compute the complex absolute value (also called - norm, modulus, or magnitude) of z. - - Returns - -3 The cabs functions return the complex absolute value. ------ SNIP ----- -</pre></blockquote> - -<p> -Note that the return type of the cabs*() functions is not a complex -type. Thus, they are equivalent to the already well established - template<class T> T abs(const complex<T>& x); -(26.2.7/2 in ISO/IEC 14882:1998, 26.3.7/2 in the current draft -document n2009.pdf). -</p> -<p> -So either the return value of fabs() is specified wrongly, or fabs() -does not behave the same as C99's cabs*(). -</p> - -<b>Possible Resolutions</b> - -<p> -This depends on the intention behind the introduction of fabs(). -</p> -<p> -If the intention was to provide a /complex/ valued function that -calculates the magnitude of its argument, this should be -explicitly specified. In TR1, the categorization under "C -compatibility" is definitely wrong, since C99 does not provide -such a complex valued function. -</p> -<p> -Also, it remains questionable if such a complex valued function -is really needed, since complex<T> supports construction and -assignment from real valued arguments. There is no difference -in observable behaviour between -</p> -<blockquote><pre> complex<double> x, y; - y = fabs(x); - complex<double> z(fabs(x)); -</pre></blockquote> -<p> -and -</p> -<blockquote><pre> complex<double> x, y; - y = abs(x); - complex<double> z(abs(x)); -</pre></blockquote> -<p> -If on the other hand the intention was to provide the intended -functionality of C99, fabs() should be either declared deprecated -or (for C++0X) removed from the standard, since the functionality -is already provided by the corresponding overloads of abs(). -</p> - -<p><i>[ -Bellevue: -]</i></p> - - -<blockquote> -Bill believes that abs() is a suitable overload. We should remove fabs(). -</blockquote> - - -<p><b>Proposed resolution:</b></p> - -<p> -Change the synopsis in 26.3.1 [complex.synopsis]: -</p> - -<blockquote><pre><del>template<class T> complex<T> fabs(const complex<T>&);</del> -</pre></blockquote> - -<p> -Remove 26.3.7 [complex.value.ops], p7: -</p> - -<blockquote> -<pre><del>template<class T> complex<T> fabs(const complex<T>& <i>x</i>);</del> -</pre> -<blockquote> -<p> -<del>-7- <i>Effects:</i> Behaves the same as C99 function <tt>cabs</tt>, defined in subclause 7.3.8.1.</del> -</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#Ready">Ready</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#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -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> -and we expect the open to fail, because out|in|app is not listed in -Table 92, and just before the table we see very specific words: -</p> -<blockquote><p> - If mode is not some combination of flags shown in the table - then the open fails. -</p></blockquote> -<p> -But the corresponding table in the C standard, 7.19.5.3, provides two -modes "a+" and "a+b", to which the C++ modes out|in|app and -out|in|app|binary would presumably apply. -</p> -<p> -We would like to argue that the intent of Table 112 was to match the -semantics of 7.19.5.3 and that the omission of "a+" and "a+b" was -unintentional. (Otherwise there would be valid and useful behaviors -available in C file I/O which are unavailable using C++, for no -valid functional reason.) -</p> -<p> -We further request that the missing modes be explicitly restored to -the WP, for inclusion in C++0x. -</p> - -<p><i>[ -Martin adds: -]</i></p> - - -<p> -...besides "a+" and "a+b" the C++ table is also missing a row -for a lone app bit which in at least two current implementation -as well as in Classic Iostreams corresponds to the C stdio "a" -mode and has been traditionally documented as implying ios::out. -Which means the table should also have a row for in|app meaning -the same thing as "a+" already proposed in the issue. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Add to the table "File open modes" in 27.8.1.4 [filebuf.members]: -</p> - -<blockquote> -<table border="1"> -<caption> File open modes</caption> -<tbody><tr> -<th colspan="5"><tt>ios_base</tt> Flag combination</th> -<th><tt>stdio</tt> equivalent</th> -</tr> -<tr> -<th><tt>binary</tt></th><th><tt>in</tt></th><th><tt>out</tt></th><th><tt>trunc</tt></th><th><tt>app</tt></th><th><tt> </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> @@ -7078,61 +6693,6 @@ Redmond: We prefer explicit conversions for narrowing and implicit for widening. <hr> -<h3><a name="612"></a>612. numeric_limits::is_modulo insufficiently 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#Ready">Ready</a> - <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2006-11-10</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.limits.members">issues</a> in [numeric.limits.members].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -18.2.1.2 55 states that "A type is modulo if it is possible to add two -positive numbers together and have a result that wraps around to a -third number that is less". -This seems insufficient for the following reasons: -</p> - -<ol> -<li>Doesn't define what that value received is.</li> -<li>Doesn't state the result is repeatable</li> -<li> Doesn't require that doing addition, subtraction and other -operations on all values is defined behaviour.</li> -</ol> - -<p><i>[ -Batavia: Related to -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2144.pdf">N2144</a>. -Pete: is there an ISO definition of modulo? Underflow on signed behavior is undefined. -]</i></p> - - -<p><i>[ -Bellevue: accept resolution, move to ready status. -Does this mandate that is_modulo be true on platforms for which int -happens to b modulo? A: the standard already seems to require that. -]</i></p> - - - -<p><b>Proposed resolution:</b></p> -<p> -Suggest 18.2.1.2 [numeric.limits.members[numeric.limits.members], paragraph 57 is amended to: -</p> - -<blockquote><p> -A type is modulo if<ins>,</ins> <del>it is possible to add two positive numbers -and have a result that wraps around to a third number that is less.</del> -<ins>given any operation involving +,- or * on values of that type whose value -would fall outside the range <tt>[min(), max()]</tt>, then the value returned -differs from the true value by an integer multiple of <tt>(max() - min() + -1)</tt>.</ins> -</p></blockquote> - - - - - - -<hr> <h3><a name="614"></a>614. std::string allocator requirements still inconsistent</h3> <p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-05</p> @@ -7240,63 +6800,6 @@ std::array does have, but array isn't mentioned. <hr> -<h3><a name="618"></a>618. valarray::cshift() effects on empty array</h3> -<p><b>Section:</b> 26.5.2.7 [valarray.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</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#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -I would respectfully request an issue be opened with the intention to -clarify the wording for <tt>size() == 0</tt> for <tt>cshift</tt>. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -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>, <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>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="629"></a>629. complex<t> insertion and locale dependence</t></h3> <p><b>Section:</b> 26.3.6 [complex.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2007-01-28</p> @@ -7347,6 +6850,32 @@ And move this to READY status. </p> </blockquote> +<p><i>[ +Pre-Sophia Antipolis, Howard adds: +]</i></p> + + +<blockquote> +Changed "showbase" to "showpoint" and changed from Ready to Review. +</blockquote> + +<p><i>[ +Post-Sophia Antipolis: +]</i></p> + + +<blockquote> +<p> +I neglected to pull this issue from the formal motions page after the "showbase" to "showpoint" change. +In Sophia Antipolis this change was reviewed by the LWG and the issue was set to Ready. We subsequently +voted the footnote into the WP with "showbase". +</p> +<p> +I'm changing from WP back to Ready to pick up the "showbase" to "showpoint" change. +</p> +</blockquote> + + <p><b>Proposed resolution:</b></p> <p> @@ -7355,7 +6884,7 @@ Add a footnote to 26.3.6 [complex.ops] p16: <blockquote> [In a locale in which comma is being used as a decimal point character, -inserting "showbase" into the output stream forces all outputs to show +inserting <tt>showpoint</tt> into the output stream forces all outputs to show an explicit decimal point character; then all inserted complex sequences will extract unambiguously.] </blockquote> @@ -7368,6 +6897,7 @@ will extract unambiguously.] <h3><a name="630"></a>630. arrays of valarray</h3> <p><b>Section:</b> 26.5.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-28</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#valarray.cons">active issues</a> in [valarray.cons].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cons">issues</a> in [valarray.cons].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> <p><b>Discussion:</b></p> @@ -7505,6 +7035,46 @@ performing the assignment.</ins> </p> </blockquote> +<p><i>[ +pre-Sophia Antipolis, Martin adds the following compromise wording, but +prefers the original proposed resolution: +]</i></p> + + +<p> +Change 26.5.2.2 [valarray.assign], p1 as follows: +</p> + +<blockquote> +<p> + -1- <i>Requires:</i> <tt>size() == 0 || size() == x.size()</tt>. +</p> +<p> + -2- <i>Effects:</i> If <tt>size() == 0</tt> calls <tt>x.resize(x.size())</tt> first. + Each element of the <tt>*this</tt> array is assigned the value of the + corresponding element of the argument array. +</p> +<p> + -3- <i>Postcondition:</i> <tt>size() == x.size()</tt>. +</p> +</blockquote> + +<p> +Add the following paragraph to 26.5.2.2 [valarray.assign], immediately after +p4: +</p> + +<blockquote> +<p> + -?- When <tt>size() == 0</tt> and the length, <tt>N</tt> of the array referred to by + the argument is not equal to the length of <tt>*this</tt>, the operator + resizes <tt>*this</tt> to make the two arrays the same length, as if by + calling <tt>resize(N)</tt>, before performing the assignment. Otherwise, + when <tt>size() > 0</tt> and <tt>size() != N</tt>, the behavior is undefined. +</p> +</blockquote> + + <p><i>[ Kona (2007): Gaby to propose wording for an alternative resolution in @@ -7764,97 +7334,53 @@ no resolution to this issue was recorded. Moved to Open. <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#Ready">Ready</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#Ready">Ready</a> status.</p> +<h3><a name="644"></a>644. Possible typos in 'function' description</h3> +<p><b>Section:</b> X [func.wrap.func.undef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-02-25</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> <p><b>Discussion:</b></p> <p> -The standard states at 23.2.2.3 [deque.modifiers]/4: +X [func.wrap.func.undef] </p> -<blockquote><pre>deque erase(...) -</pre> - <p> -<i>Effects:</i> ... An erase at either end of the deque invalidates only -the iterators and the references to the erased elements. -</p> -</blockquote> <p> -This does not state that iterators to end will be invalidated. -It needs to be amended in such a way as to account for end invalidation. +The note in paragraph 2 refers to 'undefined void operators', while the +section declares a pair of operators returning bool. </p> -<p> -Something like: -</p> -<blockquote><p> -Any time the last element is erased, iterators to end are invalidated. -</p></blockquote> - -<p> -This would handle situations like: -</p> -<blockquote><pre>erase(begin(), end()) -erase(end() - 1) -pop_back() -resize(n, ...) where n < size() -pop_front() with size() == 1 - -</pre></blockquote> <p><i>[ -Post Kona, Steve LoBasso notes: +Post-Sophia Antipolis: ]</i></p> <blockquote> -My only issue with the proposed resolution is that it might not be clear -that <tt>pop_front()</tt> [where <tt>size() == 1</tt>] can invalidate past-the-end -iterators. +Changed from Pending WP to Open. This issue was voted to WP at the same time the operators were +changed from private to deleted. The two issues stepped on each other. What do we want the return +type of these deleted functions to be? </blockquote> <p><b>Proposed resolution:</b></p> <p> -Change 23.2.2.3 [deque.modifiers], p4: +Change 20.6.15.2 [func.wrap.func] </p> -<blockquote> -<pre>iterator erase(const_iterator position); -iterator erase(const_iterator first, const_iterator last); -</pre> +<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> -<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>. +Change X [func.wrap.func.undef] </p> -</blockquote> -</blockquote> - - - -<p><i>[ -Kona (2007): Proposed wording added and moved to Review. -]</i></p> - - -<p><i>[ -Bellevue: -]</i></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> -<blockquote> -Note that there is existing code that relies on iterators not being -invalidated, but there are also existing implementations that do -invalidate iterators. Thus, such code is not portable in any case. There -is a pop_front() note, which should possibly be a separate issue. Mike -Spertus to evaluate and, if need be, file an issue. -</blockquote> @@ -8144,7 +7670,10 @@ Bill to provide proposed wording and interpretation of existing wording. <p><b>Section:</b> 22.2.6.3 [locale.moneypunct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a></p> <p><b>Discussion:</b></p> + + <p> 22.2.6.3 [locale.moneypunct], para 2 says: </p> @@ -8259,538 +7788,12 @@ Kona (2007): Robert volunteers to propose wording. <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#Ready">Ready</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#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -The current <tt>Swappable</tt> is: -</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> -The Swappable requirement is met by satisfying one or more of the following conditions: -</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> - -<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. -</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> - -<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>. -</p> - - - -<p><b>Proposed resolution:</b></p> - -<p> -Change 20.1.1 [utility.arg.requirements]: -</p> - -<blockquote> - -<p> --1- The template definitions in the C++ Standard Library refer to various -named requirements whose details are set out in tables 31-38. In these -tables, <tt>T</tt> 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> - -<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="673"></a>673. <tt>unique_ptr</tt> update</h3> -<p><b>Section:</b> 20.6.11 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> 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#unique.ptr">active issues</a> in [unique.ptr].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr">issues</a> in [unique.ptr].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -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">example implmenation</a> -for all of these changes. -</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> - -<p> -This resolution also supports instantiations such as <tt>unique_ptr<void, free_deleter></tt> -which could be very useful to the client. -</p> - -</li> - -<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 (example 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> - - -<p><i>[ -Post Kona: Howard adds example user code related to the first bullet: -]</i></p> - - -<blockquote> -<pre>void legacy_code(void*, std::size_t); - -void foo(std::size_t N) -{ - std::unique_ptr<void, void(*)(void*)> ptr(std::malloc(N), std::free); - legacy_code(ptr.get(), N); -} // unique_ptr used for exception safety purposes -</pre> -</blockquote> - -<p> -I.e. <tt>unique_ptr<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><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.11.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> -Change 20.6.11.2.4 [unique.ptr.single.observers]: -</p> - -<blockquote><pre><del>T&</del> <ins>typename add_lvalue_reference<T>::type</ins> operator*() const; -</pre></blockquote> - -</li> - -<li> -<p> -Change 20.6.11.2 [unique.ptr.single]: -</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>); -}; -</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> shall be <tt>CopyConstructible</tt> -and <tt>CopyAssignable</tt>. -</ins> -</p> - -<p> -Change 20.6.11.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> -<del>must</del> <ins>shall</ins> be well formed and not throw an exception. If <tt>D</tt> is a -reference type, then <tt>E</tt> <del>must</del> <ins>shall</ins> be the same type as <tt>D</tt> -(diagnostic required). <del><tt>U*</tt></del> <ins><tt>unique_ptr<U,E>::pointer</tt></ins> -<del>must</del> <ins>shall</ins> 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> - -<p> -Change 20.6.11.2.3 [unique.ptr.single.asgn]: -</p> - -<blockquote> -<p> --8- <i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue -<tt>D</tt> <del>must</del> <ins>shall</ins> not throw an exception. <del><tt>U*</tt></del> -<ins><tt>unique_ptr<U,E>::pointer</tt></ins> <del>must</del> <ins>shall</ins> be implicitly -convertible to <del><tt>T*</tt></del> <ins>pointer</ins>. -</p> -</blockquote> - -<p> -Change 20.6.11.2.4 [unique.ptr.single.observers]: -</p> - -<blockquote> -<pre><del>T*</del> <ins>pointer</ins> operator->() const;</pre> -... -<pre><del>T*</del> <ins>pointer</ins> get() const;</pre> -</blockquote> - -<p> -Change 20.6.11.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> -Change 20.6.11.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.11.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> - -<p> -Change 20.6.11.3.3 [unique.ptr.runtime.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> (diagnostic -required). [<i>Note:</i> One implementation technique is to create a private -templated overload. <i>-- end note</i>] -</p> -</blockquote> - -</li> - -<li> - -<p> -Change 20.6.11.2.1 [unique.ptr.single.ctor]: -</p> - -<blockquote> -<pre>unique_ptr();</pre> -<blockquote> -<p> -<i>Requires:</i> <tt>D</tt> <del>must</del> <ins>shall</ins> be default constructible, and that -construction <del>must</del> <ins>shall</ins> not throw an exception. <tt>D</tt> <del>must</del> <ins>shall</ins> 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> -<i>Requires:</i> The expression <tt>D()(p)</tt> <del>must</del> <ins>shall</ins> be well formed. -The default constructor of <tt>D</tt> <del>must</del> <ins>shall</ins> not throw an exception. -<tt>D</tt> <del>must</del> <ins>shall</ins> not be a reference type <ins>or pointer type (diagnostic -required)</ins>. -</p> -</blockquote> -</blockquote> - -<p> -Change 20.6.11.2.1 [unique.ptr.single.ctor]: -</p> - -<blockquote> -<pre>unique_ptr();</pre> -<blockquote> -<p> -<i>Requires:</i> <tt>D</tt> <del>must</del> <ins>shall</ins> be default constructible, and that -construction <del>must</del> <ins>shall</ins> not throw an exception. <tt>D</tt> <del>must</del> <ins>shall</ins> 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> -<i>Requires:</i> The expression <tt>D()(p)</tt> <del>must</del> <ins>shall</ins> be well formed. -The default constructor of <tt>D</tt> <del>must</del> <ins>shall</ins> not throw an exception. -<tt>D</tt> <del>must</del> <ins>shall</ins> not be a reference type <ins>or pointer type (diagnostic -required)</ins>. -</p> -</blockquote> -</blockquote> - -</li> - -</ul> - - - - - - -<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#Open">Open</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#Review">Review</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-05</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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> James Hopkin pointed out to me that if <tt>vector<T></tt> move assignment is O(1) @@ -8837,27 +7840,43 @@ Change 23.1 [container.requirements]: <blockquote> <table border="1"> -<caption>Table 86: Container requirements</caption> +<caption>Table 89: Container requirements</caption> <tbody><tr> <th>expression</th><th>return type</th><th>operational semantics</th> <th>assertion/note pre/post-condition</th><th>complexity</th> </tr> <tr> <td><tt>a = rv;</tt></td><td><tt>X&</tt></td> -<td><ins>All existing elements of <tt>a</tt> are either move assigned or destructed</ins></td> +<td>All existing elements of <tt>a</tt> are either move assigned or destructed</td> <td><tt>a</tt> shall be equal to the value that <tt>rv</tt> had before this construction </td> -<td><del>constant</del> <ins>linear in <tt>a.size()</tt></ins></td> +<td><del>(Note C)</del> <ins>linear</ins></td> </tr> </tbody></table> + +<p> +Notes: the algorithms <tt>swap()</tt>, <tt>equal()</tt> and +<tt>lexicographical_compare()</tt> are defined in clause 25. Those +entries marked "(Note A)" should have constant complexity. Those entries +marked "(Note B)" have constant complexity unless +<tt>allocator_propagate_never<X::allocator_type>::value</tt> is +<tt>true</tt>, in which case they have linear complexity. +<del>Those entries +marked "(Note C)" have constant complexity if <tt>a.get_allocator() == +rv.get_allocator()</tt> or if either +<tt>allocator_propagate_on_move_assignment<X::allocator_type>::value</tt> +is <tt>true</tt> or +<tt>allocator_propagate_on_copy_assignment<X::allocator_type>::value</tt> +is <tt>true</tt> and linear complexity otherwise.</del> +</p> </blockquote> <p><i>[ -post Bellevute Howard adds: +post Bellevue Howard adds: ]</i></p> @@ -8870,6 +7889,11 @@ the wording right. The intent of this issue and N2525 are not in conflict. </p> </blockquote> +<p><i>[ +post Sophia Antipolis Howard updated proposed wording: +]</i></p> + + @@ -9512,117 +8536,8 @@ that it requires. Please put it back into Open status. <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#Ready">Ready</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#Ready">Ready</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(y.current - x.current)</ins>; -</pre> -</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(y.current - x.current)</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(x.base() - y.base())</ins>; -</pre> -</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(x.base() - y.base())</ins>; -</pre> -<blockquote> -<p> -<i>Returns:</i> <tt>x.base() - y.base()</tt>. -</p> -</blockquote> -</blockquote> - -<p><i>[ -Pre Bellevue: This issue needs to wait until the <tt>auto -> return</tt> language feature -goes in. -]</i></p> - - - - - - - -<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#Open">Open</a> +<p><b>Section:</b> 20.6.5.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#refwrap.const">issues</a> in [refwrap.const].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> @@ -9643,7 +8558,7 @@ Also please see the thread starting at c++std-lib-17398 for some good discussion <p><b>Proposed resolution:</b></p> <p> -In 20.5 [function.objects], add the following two signatures to the synopsis: +In 20.6 [function.objects], add the following two signatures to the synopsis: </p> <blockquote><pre>template <class T> void ref(const T&& t) = delete; @@ -9679,11 +8594,11 @@ the "special deduction rule" is disabled with the const T&& pattern. <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> +<p><b>Section:</b> 23.4 [unord], TR1 6.3 [tr.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Joaquín M López Muńoz <b>Date:</b> 2007-06-14</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord">active issues</a> in [unord].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord">issues</a> in [unord].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</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 last version of TR1 does not include the following member @@ -9709,7 +8624,7 @@ Is this really an oversight, or am I missing something? <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]: +requirements) in section 23.1.5 [unord.req]: </p> <blockquote> @@ -9766,11 +8681,11 @@ const_local_iterator cend(size_type n) const;</ins> <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> +<p><b>Section:</b> 27.6.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ext.manip">active issues</a> in [ext.manip].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ext.manip">issues</a> in [ext.manip].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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 a private email Bill Plauger notes: @@ -9891,10 +8806,10 @@ prevent the facet from storing the value. <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> +<h3><a name="698"></a>698. <tt>system_error</tt> needs <tt>const char*</tt> constructors</h3> +<p><b>Section:</b> 19.4.5.1 [syserr.syserr.overview] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-06-24</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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 19.4.5.1 [syserr.syserr.overview] we have the class definition of @@ -9916,7 +8831,53 @@ accepting a <tt>const char*</tt>. <p><b>Proposed resolution:</b></p> <p> +This proposed wording assumes issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a> has been accepted and applied to the working paper. +</p> + +<p> +Change 19.4.5.1 [syserr.syserr.overview] Class system_error overview, as indicated: +</p> + +<blockquote><pre>public: + system_error(error_code ec, const string& what_arg); + <ins>system_error(error_code ec, const char* what_arg);</ins> + system_error(error_code ec); + system_error(int ev, const error_category* ecat, + const string& what_arg); + <ins>system_error(int ev, const error_category* ecat, + const char* what_arg);</ins> + system_error(int ev, const error_category* ecat); +</pre></blockquote> + +<p> +To 19.4.5.2 [syserr.syserr.members] Class system_error members add: +</p> + +<blockquote> +<pre>system_error(error_code ec, const char* what_arg); +</pre> +<blockquote> +<p> +<i>Effects:</i> Constructs an object of class <tt>system_error</tt>. +</p> +<p> +<i>Postconditions:</i> <tt>code() == ec</tt> and <tt>strcmp(runtime_error::what(), what_arg) == 0</tt>. +</p> +</blockquote> + +<pre>system_error(int ev, const error_category* ecat, const char* what_arg); +</pre> + +<blockquote> +<p> +<i>Effects:</i> Constructs an object of class <tt>system_error</tt>. +</p> +<p> +<i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and <tt>strcmp(runtime_error::what(), what_arg) == 0</tt>. </p> +</blockquote> +</blockquote> + @@ -10009,15 +8970,13 @@ not omitted by mistake. <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>X u(rv)</tt></td><td><tt>array</tt> and containers with a <tt>propagate_never</tt> allocator require <tt>value_type</tt> to be <tt>MoveConstructible</tt></td></tr> <tr><td><tt>a = u</tt></td><td>Sequences require <tt>value_type</tt> to be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>. Associative containers require <tt>value_type</tt> to be <tt>CopyConstructible</tt>.</td></tr> <tr><td><tt>a = rv</tt></td><td><tt>array</tt> requires <tt>value_type</tt> to be <tt>MoveAssignable</tt>. - Sequences 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> + Sequences and Associative containers with <tt>propagate_never</tt> and <tt>propagate_on_copy_construction</tt> allocators require <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr> +<tr><td><tt>swap(a,u)</tt></td><td><tt>array</tt> and containers with <tt>propagate_never</tt> and + <tt>propagate_on_copy_construction</tt> allocators require <tt>value_type</tt> to be <tt>Swappable</tt>.</td></tr> </tbody></table> <p> @@ -10046,7 +9005,7 @@ not omitted by mistake. 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> + The sequence <tt>vector</tt> also requires the <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr> <tr><td><tt>a.resize(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr> </tbody></table> @@ -10182,151 +9141,77 @@ Kona (2007): Bill and Nick to provide wording. <hr> -<h3><a name="710"></a>710. Missing postconditions</h3> -<p><b>Section:</b> 20.6.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> 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#Ready">Ready</a> status.</p> +<h3><a name="709"></a>709. <tt>char_traits::not_eof</tt> has wrong signature</h3> +<p><b>Section:</b> 21.1.3 [char.traits.specializations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> + <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-13</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits.specializations">issues</a> in [char.traits.specializations].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p> <p><b>Discussion:</b></p> <p> -A discussion on -<a href="http://groups.google.com/group/comp.std.c++/browse_frm/thread/8e89dceb35cd7971">comp.std.c++</a> -has identified a contradiction in the <tt>shared_ptr</tt> specification. -The <tt>shared_ptr</tt> move constructor and the cast functions are -missing postconditions for the <tt>get()</tt> accessor. -</p> - -<p><i>[ -Bellevue: -]</i></p> - - -<blockquote> -<p> -Move to "ready", adopting the first (Peter's) proposed resolution. +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> -Note to the project editor: there is an editorial issue here. The -wording for the postconditions of the casts is slightly awkward, and the -editor should consider rewording "If w is the return value...", e. g. as -"For a return value w...". +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><b>Proposed resolution:</b></p> <p> -Add to 20.6.12.2.1 [util.smartptr.shared.const]: +Pete adds: </p> -<blockquote> -<pre>shared_ptr(shared_ptr&& r); -template<class Y> shared_ptr(shared_ptr<Y>&& r); -</pre> -<blockquote> -<p> -<i>Postconditions:</i> <tt>*this</tt> shall contain the old value of <tt>r</tt>. <tt>r</tt> -shall be empty. <ins><tt>r.get() == 0</tt>.</ins> -</p> -</blockquote> -</blockquote> +<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> -Add to 20.6.12.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> -<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>template<class T, class U> shared_ptr<T> dynamic_pointer_cast(shared_ptr<U> const& r); -</pre> -<blockquote> +<p><b>Proposed resolution:</b></p> <p> -<ins><i>Postconditions:</i> If <tt>w</tt> is the return value, <tt>w.get() == dynamic_cast<T*>(r.get())</tt>.</ins> +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> -<blockquote> -<pre>template<class T, class U> shared_ptr<T> const_pointer_cast(shared_ptr<U> const& r); -</pre> -<blockquote> -<p> -<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> +<blockquote><pre>static constexpr int_type not_eof(<del>char_type</del> <ins>int_type</ins> c); +</pre></blockquote> -<p> -Alberto Ganesh Barbati has written an -<a href="http://barbati.net/c++/shared_ptr.pdf">alternative proposal</a> -where he suggests (among other things) that the casts be respecified in terms of -the aliasing constructor as follows: -</p> -<p> -Change 20.6.12.2.10 [util.smartptr.shared.cast]: -</p> -<blockquote> -<p> --2- <i>Returns:</i> <del>If <tt>r</tt> is empty, an <tt>empty -shared_ptr<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> +<p><i>[ +Bellevue: +]</i></p> -<blockquote> -<p> --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> <blockquote> -<p> --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> +Resolution: NAD editorial - up to Pete's judgment </blockquote> -<p> -This takes care of the missing postconditions for the casts by bringing -in the aliasing constructor postcondition "by reference". -</p> +<p><i>[ +Post Sophia Antipolis +]</i></p> +<blockquote> +Moved from Pending NAD Editorial to Review. The proposed wording appears to be correct but non-editorial. +</blockquote> <hr> <h3><a name="711"></a>711. Contradiction in empty <tt>shared_ptr</tt></h3> -<p><b>Section:</b> 20.6.12.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> +<p><b>Section:</b> 20.7.12.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-08-24</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.obs">issues</a> in [util.smartptr.shared.obs].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</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 discussion on @@ -10355,7 +9240,7 @@ with a non-NULL stored pointer. </p> <p> -This is contradicted by the second sentence in the Returns clause of 20.6.12.2.5 [util.smartptr.shared.obs]: +This is contradicted by the second sentence in the Returns clause of 20.7.12.2.5 [util.smartptr.shared.obs]: </p> <blockquote> @@ -10390,10 +9275,48 @@ on it, but there isn't support for removing this feature at this time. </p> </blockquote> +<p><i>[ +Sophia Antipolis: +]</i></p> + + +<blockquote> +<p> +We heard from Peter Dimov, who explained his reason for preferring solution 1. +</p> +<p> +Because it doesn't seem to add anything. It simply makes the behavior +for p = 0 undefined. For programmers who don't create empty pointers +with p = 0, there is no difference. Those who do insist on creating them +presumably have a good reason, and it costs nothing for us to define the +behavior in this case. +</p> +<p> +The aliasing constructor is sharp enough as it is, so "protecting" users +doesn't make much sense in this particular case. +</p> +<p> +> Do you have a use case for r being empty and r being non-null? +</p> +<p> +I have received a few requests for it from "performance-conscious" +people (you should be familiar with this mindset) who don't like the +overhead of allocating and maintaining a control block when a null +deleter is used to approximate a raw pointer. It is obviously an "at +your own risk", low-level feature; essentially a raw pointer behind a +shared_ptr facade. +</p> +<p> +We could not agree upon a resolution to the issue; some of us thought +that Peter's description above is supporting an undesirable behavior. +</p> +</blockquote> + + <p><b>Proposed resolution:</b></p> <p> -In keeping the N2351 spirit and obviously my preference, change 20.6.12.2.5 [util.smartptr.shared.obs]: +In keeping the N2351 spirit and obviously my preference, change 20.7.12.2.5 [util.smartptr.shared.obs]: </p> <blockquote> @@ -10409,7 +9332,7 @@ Alternative proposed resolution: (I won't be happy if we do this, but it's possi </p> <p> -Change 20.6.12.2.1 [util.smartptr.shared.const]: +Change 20.7.12.2.1 [util.smartptr.shared.const]: </p> <blockquote> @@ -10434,9 +9357,9 @@ instance with a non-NULL stored pointer. <hr> <h3><a name="713"></a>713. <tt>sort()</tt> complexity is too lax</h3> -<p><b>Section:</b> 25.3.1.1 [sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 25.3.1.1 [sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-30</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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 complexity of <tt>sort()</tt> is specified as "Approximately <tt>N @@ -10461,8 +9384,8 @@ In 25.3.1.1 [sort], change the complexity to "O(N log N)", and remove footnote 2 <blockquote> <p> -<i>Complexity:</i> <del>Approximately</del> <ins>O(</ins><i>N</i> log(<i>N</i>)<ins>)</ins> <del>(where <i>N</i> == <i>last</i> - <i>first</i> ) -</del>comparisons<del> on the average</del>.<del><sup>266)</sup></del> +<i>Complexity:</i> <del>Approximately</del> <ins>O(</ins><i>N</i> log(<i>N</i>)<ins>)</ins> (where <i>N</i> == <i>last</i> - <i>first</i> ) +comparisons<del> on the average</del>.<del><sup>266)</sup></del> </p> <p> <del><sup>266)</sup> @@ -10478,13 +9401,13 @@ If the worst case behavior is important <tt>stable_sort()</tt> (25.3.1.2) or <tt <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> +<p><b>Section:</b> 25.1.12 [alg.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-30</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.search">issues</a> in [alg.search].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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 complexity for <tt>search_n</tt> (25.1.9 [alg.search] par 7) is specified as "At most +The complexity for <tt>search_n</tt> (25.1.12 [alg.search] par 7) is specified as "At most (last - first ) * count applications of the corresponding predicate if count is positive, or 0 otherwise." This is unnecessarily pessimistic. Regardless of the value of count, there is no reason to examine any @@ -10523,60 +9446,6 @@ template<class ForwardIterator, class Size, class T, <hr> -<h3><a name="715"></a>715. <tt>minmax_element</tt> complexity is too lax</h3> -<p><b>Section:</b> 25.3.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-30</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.min.max">active issues</a> in [alg.min.max].</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#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -The complexity for <tt>minmax_element</tt> (25.3.7 [alg.min.max] par 16) says "At most <tt>max(2 * -(last - first ) - 2, 0)</tt> applications of the corresponding comparisons", -i.e. the worst case complexity is no better than calling <tt>min_element</tt> and -<tt>max_element</tt> separately. This is gratuitously inefficient. There is a -well known technique that does better: see section 9.1 of CLRS -(Introduction to Algorithms, by Cormen, Leiserson, Rivest, and Stein). -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Change 25.3.7 [alg.min.max] to: -</p> - -<blockquote> -<pre>template<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> -<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 in <tt>[first, -last)</tt> such that no iterator in the range refers to a smaller element,</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 -in <tt>[first, last)</tt> such that no iterator in the range refers to a larger element</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> - - - - - - -<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> @@ -10642,7 +9511,7 @@ Sequence (23.1.1) and for a Reversible Container (23.1). </blockquote> <p> -First of all, 23.1.1 [sequence.reqmts] is no longer "Sequence" but "Sequence container". +First of all, 23.1.3 [sequence.reqmts] is no longer "Sequence" but "Sequence container". Secondly, after the resent changes to containers (<tt>emplace</tt>, <tt>push_back</tt>, <tt>const_iterator</tt> parameters to <tt>insert</tt> and <tt>erase</tt>), <tt>basic_string</tt> is not even close to conform to the current requirements. @@ -10689,7 +9558,7 @@ different, a string abstraction in its own right. <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#Open">Open</a> +<p><b>Section:</b> 20.5 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-25</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta">issues</a> in [meta].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> @@ -10720,7 +9589,7 @@ a new type category "literal", which is defined in 3.9 [basic.types]/p.11: <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: +literal types in 20.5.4.3 [meta.unary.prop] for several reasons: </p> <ol type="a"> @@ -10782,7 +9651,7 @@ These two issues should move to OPEN pending AM paper on type traits. <p><b>Proposed resolution:</b></p> <p> -In 20.4.2 [meta.type.synop] in the group "type properties", +In 20.5.2 [meta.type.synop] in the group "type properties", just below the line </p> @@ -10797,7 +9666,7 @@ add a new one: </pre></blockquote> <p> -In 20.4.4.3 [meta.unary.prop], table Type Property Predicates, just +In 20.5.4.3 [meta.unary.prop], table Type Property Predicates, just below the line for the <tt>is_pod</tt> property add a new line: </p> @@ -10821,11 +9690,11 @@ array of unknown bound, or <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#Open">Open</a> +<p><b>Section:</b> 23.2.1 [array], 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-25</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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#Ready">Ready</a> status.</p> <p><b>Discussion:</b></p> <ol> <li> @@ -10847,6 +9716,33 @@ initialisation. What have I overlooked here? </li> </ol> +<p><i>[ +Sophia Antipolis: +]</i></p> + + +<blockquote> +<p> +We handle this as two parts +</p> +<ol> +<li> +The proposed resolution is correct; move to ready. +</li> +<li> +The issue points out a real problem, but the issue is larger than just +this solution. We believe a paper is needed, applying the full new +features of C++ (including extensible literals) to update <tt>std::bitset</tt>. +We note that we do not consider this new work, and that is should be +handled by the Library Working Group. +</li> +</ol> +<p> +In order to have a consistent working paper, Alisdair and Daniel produced a new wording for the resolution. +</p> +</blockquote> + + <p><b>Proposed resolution:</b></p> <ol> @@ -10917,44 +9813,11 @@ void main() <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#Ready">Ready</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#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -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>float nanf(const char *tagp); -long double nanl(const char *tagp); -</pre></blockquote> - -<p> -(Note: These functions cannot be overloaded and they are also not -listed anywhere else) -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -In 26.7 [c.math], table 108, section "Functions", add <tt>nanf</tt> and <tt>nanl</tt> -just after the existing entry <tt>nan</tt>. -</p> - - - - - -<hr> <h3><a name="723"></a>723. <tt>basic_regex</tt> should be moveable</h3> -<p><b>Section:</b> 28.8 [re.regex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 28.8 [re.regex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-29</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.regex">issues</a> in [re.regex].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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> According to the current state of the standard draft, the class @@ -10966,6 +9829,15 @@ use cases, where a factory function returns regex values, which would take advantage of moveabilities. </p> +<p><i>[ +Sophia Antipolis: +]</i></p> + + +<blockquote> +Needs wording for the semantics, the idea is agreed upon. +</blockquote> + <p><b>Proposed resolution:</b></p> <ol type="a"> @@ -11154,11 +10026,11 @@ following table: <hr> <h3><a name="726"></a>726. Missing <tt>regex_replace()</tt> overloads</h3> -<p><b>Section:</b> 28.11.4 [re.alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 28.11.4 [re.alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2007-09-22</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re.alg.replace">active issues</a> in [re.alg.replace].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.alg.replace">issues</a> in [re.alg.replace].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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> Two overloads of <tt>regex_replace()</tt> are currently provided: @@ -11230,6 +10102,18 @@ is no way to avoid constructing a <tt>basic_string</tt>.) </li> </ol> +<p><i>[ +Sophia Antipolis: +]</i></p> + + +<blockquote> +We note that Boost already has these overloads. However, the proposed +wording is provided only for 28.11.4 [re.alg.replace]; wording is needed for the synopsis +as well. We also note that this has impact on <tt>match_results::format</tt>, +which may require further overloads. +</blockquote> + <p><b>Proposed resolution:</b></p> @@ -11335,10 +10219,10 @@ arguments. <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#Review">Review</a> +<p><b>Section:</b> 26.4.3.2 [rand.eng.mers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng.mers">issues</a> in [rand.eng.mers].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</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 <tt>mersenne_twister_engine</tt> is required to use a seeding method that is given @@ -11411,6 +10295,16 @@ proposed by Charles Karney should also be included in the proposed wording. </blockquote> +<p><i>[ +Sophia Antipolis: +]</i></p> + + +<blockquote> +Note the main part of the issue is resolved by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>. +</blockquote> + @@ -11489,9 +10383,9 @@ for the proposed resolution. <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#Open">Open</a> +<p><b>Section:</b> 26.4.8.4.3 [rand.dist.norm.chisq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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> <tt>chi_squared_distribution</tt>, <tt>fisher_f_distribution</tt> and <tt>student_t_distribution</tt> @@ -11528,6 +10422,27 @@ In N2424. Not wildly enthusiastic, not really felt necessary. Less frequently used in practice. Not terribly bad either. Move to OPEN. </blockquote> +<p><i>[ +Sophia Antipolis: +]</i></p> + + +<blockquote> +<p> +Marc Paterno: The generalizations were explicitly left out when designing the facility. It's harder to test. +</p> +<p> +Marc Paterno: Ask implementers whether floating-point is a significant burden. +</p> +<p> +Alisdair: It's neater to do it now, do ask Bill Plauger. +</p> +<p> +Disposition: move to review with the option for "NAD" if it's not straightforward to implement; unanimous consent. +</p> +</blockquote> + + <p><b>Proposed resolution:</b></p> <p> @@ -11615,103 +10530,6 @@ Replace both occurrences of "<tt>int n() const;</tt>" with "<tt>RealType n() con <hr> -<h3><a name="740"></a>740. Please remove <tt>*_ptr<T[N]></tt></h3> -<p><b>Section:</b> 20.6.11.4 [unique.ptr.compiletime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</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#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -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> - -<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> -If bounds checking is desired, consider a <tt>checked_*_ptr</tt> instead (e.g., -<tt>checked_shared_ptr</tt>). And make the interfaces otherwise identical so that -user code could easily <tt>#define/typedef</tt> between prepending <tt>checked_</tt> on -debug builds and not doing so on release builds (for example). -</p> - -<p> -Note that some may object that <tt>checked_*_ptr</tt> may seem to make the smart -pointer more like <tt>vector</tt>, and we don't want two ways to spell <tt>vector</tt>. I -don't agree, but if that were true that would be another reason to -remove <tt>*_ptr<T[N]></tt> which equally makes the smart pointer more like -<tt>std::array.</tt> :-) -</p> - -<p><i>[ -Bellevue: -]</i></p> - - -<blockquote> -<p>Suggestion that fixed-size array instantiations are going to fail at -compile time anyway (if we remove specialization) due to pointer decay, -at least that appears to be result from available compilers. -</p> -<p> -So concerns about about requiring static_assert seem unfounded. -</p> -<p>After a little more experimentation with compiler, it appears that -fixed size arrays would only work at all if we supply these explicit -specialization. So removing them appears less breaking than originally -thought. -</p> -<p> -straw poll unanimous move to Ready. -</p> -</blockquote> - - - -<p><b>Proposed resolution:</b></p> -<p> -Change the synopsis under 20.6.11 [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.11.1.3 [unique.ptr.dltr.dflt2] <b><tt>default_delete<T[N]></tt></b>. -</p> - -<p> -Remove the entire section 20.6.11.4 [unique.ptr.compiletime] <b><tt>unique_ptr</tt> for array objects with a compile time length</b> -and its subsections: 20.6.11.4.1 [unique.ptr.compiletime.dtor], 20.6.11.4.2 [unique.ptr.compiletime.observers], -20.6.11.4.3 [unique.ptr.compiletime.modifiers]. -</p> - - - - - - -<hr> <h3><a name="742"></a>742. Enabling <tt>swap</tt> for proxy iterators</h3> <p><b>Section:</b> 20.1.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-10-10</p> @@ -11720,7 +10538,7 @@ and its subsections: 20.6.11.4.1 [unique.ptr.compiletime.dtor], 20.6.11.4.2 [uni <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> <p><b>Discussion:</b></p> <p> -This issue was split from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#672">672</a>. <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#672">672</a> now just +This issue was split from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>. <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a> now just deals with changing the requirements of <tt>T</tt> in the <tt>Swappable</tt> requirement from <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt> to <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>. @@ -11871,224 +10689,9 @@ semantics described in this table. <hr> -<h3><a name="743"></a>743. rvalue <tt>swap</tt> for <tt>shared_ptr</tt></h3> -<p><b>Section:</b> 20.6.12.2.9 [util.smartptr.shared.spec] <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-10-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> -When the LWG looked at <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a> in Kona the following note was made: -</p> - -<blockquote><p> -We may need to open an issue to deal with the question of -whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>. -</p></blockquote> - -<p> -This issue was opened in response to that note. -</p> - -<p> -I believe allowing rvalue <tt>shared_ptr</tt>s to <tt>swap</tt> is both -appropriate, and consistent with how other library components are currently specified. -</p> - -<p><i>[ -Bellevue: -]</i></p> - - -<blockquote> -<p> -Concern that the three signatures for swap is needlessly complicated, -but this issue merely brings shared_ptr into equal complexity with the -rest of the library. Will open a new issue for concern about triplicate -signatures. -</p> -<p> -Adopt issue as written. -</p> -</blockquote> - - -<p><b>Proposed resolution:</b></p> -<p> -Change the synopsis in 20.6.12.2 [util.smartptr.shared]: -</p> - -<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> -Change 20.6.12.2.4 [util.smartptr.shared.mod]: -</p> - -<blockquote><pre>void swap(shared_ptr&<ins>&</ins> r); -</pre></blockquote> - -<p> -Change 20.6.12.2.9 [util.smartptr.shared.spec]: -</p> - -<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="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#Ready">Ready</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#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -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><i>[ -Bellevue: -]</i></p> - - -<blockquote> -<p> -Agree the issue is real. -</p> -<p> -Intent is lifetime is similar to a shared_ptr (and we might even want to -consider explicitly saying that it is a shared_ptr< unspecified type >). -</p> -<p> -We expect that most implementations will use shared_ptr, and the -standard should be clear that the exception_ptr type is intended to be -something whose semantics are smart-pointer-like so that the user does -not need to worry about lifetime management. We still need someone to -draught those words - suggest emailing Peter Dimov. -</p> -<p> -Move to Open. -</p> -</blockquote> - - -<p><b>Proposed resolution:</b></p> -<p> -Change 18.7.5 [propagation]/7: -</p> - -<blockquote> --7- Returns: An <tt>exception_ptr</tt> object that refers to the currently -handled exception or a copy of the currently handled exception, or a -null <tt>exception_ptr</tt> object if no exception is being handled. -<ins>The referenced object remains valid at least as long as there is an -<tt>exception_ptr</tt> that refers to it.</ins> -If the function needs to allocate memory and the attempt -fails, it returns an <tt>exception_ptr</tt> object that refers to an instance of -<tt>bad_alloc</tt>. It is unspecified whether the return values of two successive -calls to <tt>current_exception</tt> refer to the same exception object. [<i>Note:</i> -that is, it is unspecified whether <tt>current_exception</tt> creates a new copy -each time it is called. <i>--end note</i>] -</blockquote> - - - - - -<hr> -<h3><a name="746"></a>746. current_exception may fail with bad_alloc</h3> -<p><b>Section:</b> 18.7.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</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#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -I understand that the attempt to copy an exception may run out of memory, -but I believe this is the only part of the standard that mandates failure -with specifically <tt>bad_alloc</tt>, as opposed to allowing an -implementation-defined type derived from <tt>bad_alloc</tt>. For instance, the Core -language for a failed new expression is: -</p> -<blockquote> -<p> -Any other allocation function that fails to allocate storage shall indicate -failure only by throwing an exception of a type that would match a handler -(15.3) of type <tt>std::bad_alloc</tt> (18.5.2.1). -</p> -</blockquote> -<p> -I think we should allow similar freedom here (or add a blanket -compatible-exception freedom paragraph in 17) -</p> -<p> -I prefer the clause 17 approach myself, and maybe clean up any outstanding -wording that could also rely on it. -</p> -<p> -Although filed against a specific case, this issue is a problem throughout -the library. -</p> - -<p><i>[ -Bellevue: -]</i></p> - - -<blockquote> -<p> -Is issue bigger than library? -</p> -<p> -No - Core are already very clear about their wording, which is inspiration for the issue. -</p> -<p> -While not sold on the original 18.7.5 use case, the generalised 17.4.4.8 wording is the real issue. -</p> -<p> -Accept the broad view and move to ready -</p> -</blockquote> - - -<p><b>Proposed resolution:</b></p> -<p> -Add the following exemption clause to 17.4.4.8 [res.on.exception.handling]: -</p> - -<blockquote> -A function may throw a type not listed in its <i>Throws</i> clause so long as it is -derived from a class named in the <i>Throws</i> clause, and would be caught by an -exception handler for the base type. -</blockquote> - - - - - -<hr> <h3><a name="747"></a>747. We have 3 separate type traits to identify classes supporting no-throw operations</h3> -<p><b>Section:</b> 20.4.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> +<p><b>Section:</b> 20.5.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p> -<p><b>View 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#Open">Open</a> status.</p> <p><b>Discussion:</b></p> @@ -12160,80 +10763,9 @@ Move to OPEN. Need to talk to Core about this. <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#Ready">Ready</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#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -Unfortunately a class can have multiple copy constructors, and I believe to -be useful this trait should only return true is ALL copy constructors are -no-throw. -</p> -<p> -For instance: -</p> -<blockquote> -<pre>struct awkward { - awkward( const awkward & ) throw() {} - awkward( awkward & ) { throw "oops"; } }; -</pre> -</blockquote> - - -<p><b>Proposed resolution:</b></p> -<p> -Change 20.4.4.3 [meta.unary.prop]: -</p> - -<blockquote> -<pre>has_trivial_copy_constructor</pre> -<blockquote> -<tt>T</tt> is a trivial type (3.9) or a reference type or a class type <del>with a trivial copy constructor</del> -<ins>where all copy constructors are trivial</ins> (12.8). -</blockquote> -</blockquote> - -<blockquote> -<pre>has_trivial_assign</pre> -<blockquote> -<tt>T</tt> is neither <tt>const</tt> nor a reference type, and <tt>T</tt> is a trivial type (3.9) -or a class type <del>with a trivial copy assignment operator</del> <ins>where all copy assignment operators are trivial</ins> (12.8). -</blockquote> -</blockquote> - -<blockquote> -<pre>has_nothrow_copy_constructor</pre> -<blockquote> -<tt>has_trivial_copy_constructor<T>::value</tt> is <tt>true</tt> or <tt>T</tt> is a class type <del>with -a</del> <ins>where all</ins> copy constructor<ins>s</ins> <del>that is</del> <ins>are</ins> -known not to throw any exceptions or <tt>T</tt> is an -array of such a class type -</blockquote> -</blockquote> - -<blockquote> -<pre>has_nothrow_assign</pre> -<blockquote> -<tt>T</tt> is neither <tt>const</tt> nor a reference type, and -<tt>has_trivial_assign<T>::value</tt> is <tt>true</tt> or <tt>T</tt> is a class type <del>with a</del> -<ins>where all</ins> copy -assignment operator<ins>s</ins> tak<ins>e</ins><del>ing</del> an lvalue of type <tt>T</tt> that is known not to -throw any exceptions or <tt>T</tt> is an array of such a class type. -</blockquote> -</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#Open">Open</a> +<p><b>Section:</b> 20.5.5 [meta.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> <p><b>Discussion:</b></p> @@ -12321,11 +10853,11 @@ as-if rule. <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> +<p><b>Section:</b> 20.1.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Hans Boehm <b>Date:</b> 2007-10-11</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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> Did LWG recently discuss 20.1.2 [allocator.requirements]-2, which states that "All the operations @@ -12335,13 +10867,13 @@ on the allocators are expected to be amortized constant time."? 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 +large objects. Would it be controversial to officially let these take time linear in the size of the object, as they already do in real life? </p> <p> <tt>Allocate()</tt> more blatantly takes time proportional to the size of the -object if you mix in GC. But it's not really a new problem, and I think -we'd be confusing things by leaving the bogus requirements there. The +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 @@ -12357,10 +10889,8 @@ Change 20.1.2 [allocator.requirements]/2: <blockquote> <p> -2- Table 39 describes the requirements on types manipulated through -allocators. All the operations on the allocators are expected to be -amortized constant time<ins>, except that <tt>allocate</tt> and -<tt>construct</tt> may require time proportional to the size of the -object allocated or constructed</ins>. Table 40 describes the +allocators. <del>All the operations on the allocators are expected to be +amortized constant time.</del> Table 40 describes the requirements on allocator types. </p> </blockquote> @@ -12500,186 +11030,12 @@ unfortunately pulling it back to Open. But I'm drafting wording to atone for th <hr> -<h3><a name="755"></a>755. <tt>std::vector</tt> and <tt>std:string</tt> lack explicit shrink-to-fit operations</h3> -<p><b>Section:</b> 23.2.6.2 [vector.capacity], 21.3.4 [string.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Beman Dawes <b>Date:</b> 2007-10-31</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -A <tt>std::vector</tt> can be shrunk-to-fit via the swap idiom: -</p> - -<blockquote><pre>vector<int> v; -... -v.swap(vector<int>(v)); // shrink to fit -</pre> -<blockquote><p> -or: -</p></blockquote> -<pre>vector<int>(v).swap(v); // shrink to fit -</pre> -<blockquote><p> -or: -</p></blockquote> -<pre>swap(v, vector<int>(v)); // shrink to fit -</pre> -</blockquote> - -<p> -A non-binding request for shrink-to-fit can be made to a <tt>std::string</tt> via: -</p> - -<blockquote><pre>string s; -... -s.reserve(0); -</pre></blockquote> - -<p> -Neither of these is at all obvious to beginners, and even some -experienced C++ programmers are not aware that shrink-to-fit is -trivially available. -</p> -<p> -Lack of explicit functions to perform these commonly requested -operations makes vector and string less usable for non-experts. Because -the idioms are somewhat obscure, code readability is impaired. It is -also unfortunate that two similar vector-like containers use different -syntax for the same operation. -</p> -<p> -The proposed resolution addresses these concerns. The proposed function -takes no arguments to keep the solution simple and focused. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -To Class template basic_string 21.3 [basic.string] synopsis, -Class template vector 23.2.6 [vector] synopsis, and Class -vector<bool> 23.2.7 [vector.bool] synopsis, add: -</p> - -<blockquote><pre> -void shrink_to_fit(); -</pre></blockquote> - -<p> -To basic_string capacity 21.3.4 [string.capacity] and vector -capacity 23.2.6.2 [vector.capacity], add: -</p> - -<blockquote> -<pre>void shrink_to_fit(); -</pre> -<blockquote> -<i>Remarks:</i> <tt>shrink_to_fit</tt> is a non-binding request to reduce -<tt>capacity()</tt> to <tt>size()</tt>. [<i>Note:</i> The request is non-binding to -allow latitude for implementation-specific optimizations. -<i>-- end note</i>] -</blockquote> -</blockquote> - - - - - -<hr> -<h3><a name="756"></a>756. Container adaptors push</h3> -<p><b>Section:</b> 23.2.5 [container.adaptors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> - <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2007-10-31</p> -<p><b>View all 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> -After n2369 we have a single <tt>push_back</tt> overload in the sequence containers, -of the "emplace" type. At variance with that, still in n2461, we have -two separate overloads, the C++03 one + one taking an rvalue reference -in the container adaptors. Therefore, simply from a consistency point of -view, I was wondering whether the container adaptors should be aligned -with the specifications of the sequence container themselves: thus have -a single <tt>push</tt> along the lines: -</p> - -<blockquote><pre>template<typename... _Args> -void -push(_Args&&... __args) - { c.push_back(std::forward<_Args>(__args)...); } -</pre></blockquote> - -<p><i>[ -Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#767">767</a> -]</i></p> - - - -<p><b>Proposed resolution:</b></p> -<p> -Change 23.2.5.1.1 [queue.defn]: -</p> - -<blockquote><pre><del>void push(const value_type& x) { c.push_back(x); }</del> -<del>void push(value_type&& x) { c.push_back(std::move(x)); }</del> -<ins>template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }</ins> -</pre></blockquote> - -<p> -Change 23.2.5.2 [priority.queue]: -</p> - -<blockquote><pre><del>void push(const value_type& x) { c.push_back(x); }</del> -<del>void push(value_type&& x) { c.push_back(std::move(x)); }</del> -<ins>template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }</ins> -</pre></blockquote> - -<p> -Change 23.2.5.2.2 [priqueue.members]: -</p> - -<blockquote> -<pre><del>void push(const value_type& x);</del> -</pre> -<blockquote> -<p> -<del><i>Effects:</i></del> -</p> -<blockquote><pre><del>c.push_back(x);</del> -<del>push_heap(c.begin(), c.end(), comp);</del> -</pre></blockquote> -</blockquote> - -<pre><ins>template<class... Args></ins> void push(<del>value_type</del> <ins>Args</ins>&&<ins>...</ins> <del>x</del> <ins>args</ins>); -</pre> -<blockquote> -<p> -<i>Effects:</i> -</p> -<blockquote><pre>c.push_back(std::<del>move</del><ins>forward<Args></ins>(<del>x</del> <ins>args</ins>)<ins>...</ins>); -push_heap(c.begin(), c.end(), comp); -</pre></blockquote> -</blockquote> -</blockquote> - -<p> -Change 23.2.5.3.1 [stack.defn]: -</p> - -<blockquote><pre><del>void push(const value_type& x) { c.push_back(x); }</del> -<del>void push(value_type&& x) { c.push_back(std::move(x)); }</del> -<ins>template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }</ins> -</pre></blockquote> - - - - - - -<hr> <h3><a name="758"></a>758. <tt>shared_ptr</tt> and <tt>nullptr</tt></h3> -<p><b>Section:</b> 20.6.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> +<p><b>Section:</b> 20.7.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-10-31</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</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> Consider the following program: @@ -12774,7 +11130,7 @@ The following wording changes are less intrusive: </p> <p> -In 20.6.12.2.1 [util.smartptr.shared.const], add: +In 20.7.12.2.1 [util.smartptr.shared.const], add: </p> <blockquote><pre>shared_ptr(nullptr_t); @@ -12832,11 +11188,28 @@ unnecessary; this is effectively an alias for the default constructor. </p> </blockquote> +<p><i>[ +Sophia Antipolis: +]</i></p> + + +<blockquote> +<p> +We want to remove the reset functions from the proposed resolution. +</p> +<p> +The remaining proposed resolution text (addressing the constructors) are wanted. +</p> +<p> +Disposition: move to review. The review should check the wording in the then-current working draft. +</p> +</blockquote> + <p><b>Proposed resolution:</b></p> <p> -Add the following constructors to 20.6.12.2 [util.smartptr.shared]: +Add the following constructors to 20.7.12.2 [util.smartptr.shared]: </p> <blockquote><pre>shared_ptr(nullptr_t); @@ -12844,17 +11217,10 @@ template <class D> shared_ptr(nullptr_t, D d); template <class D, class A> shared_ptr(nullptr_t, D d, A a); </pre></blockquote> -<p> -Add the following methods to 20.6.12.2 [util.smartptr.shared]: -</p> -<blockquote><pre>void reset(nullptr_t); -template <class D> void reset(nullptr_t, D d); -template <class D, class A> void reset(nullptr_t, D d, A a); -</pre></blockquote> <p> -Add the following constructor definitions to 20.6.12.2.1 [util.smartptr.shared.const]: +Add the following constructor definitions to 20.7.12.2.1 [util.smartptr.shared.const]: </p> <blockquote> @@ -12905,92 +11271,9 @@ resource other than memory could not be obtained. </blockquote> </blockquote> -<p> -Add the following method definitions to 20.6.12.2.4 [util.smartptr.shared.mod]: -</p> - -<blockquote> -<pre>void reset(nullptr_t); -</pre> -<blockquote> -<p> -<i>Effects:</i> Equivalent to <tt>shared_ptr(nullptr).swap(*this)</tt>. -</p> -</blockquote> -</blockquote> - -<blockquote> -<pre>template <class D> void reset(nullptr_t, const D d) -</pre> -<blockquote> -<p> -<i>Effects:</i> Equivalent to <tt>shared_ptr(nullptr, d).swap(*this)</tt>. -</p> -</blockquote> -</blockquote> - -<blockquote> -<pre>template <class D, class A> void reset(nullptr_t, D d, A a); -</pre> -<blockquote> -<p> -<i>Effects:</i> Equivalent to <tt>shared_ptr(nullptr, d, a).swap(*this)</tt>. -</p> -</blockquote> -</blockquote> - - - - - - -<hr> -<h3><a name="759"></a>759. A reference is not an object</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> Jens Maurer <b>Date:</b> 2007-11-06</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -23.1 [container.requirements] says: -</p> - -<blockquote> --12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No -diagnostic required. -</blockquote> - -<p> -A reference is not an object, but this sentence appears to claim so. -</p> - -<p> -What is probably meant here: -</p> -<blockquote> -An object bound to an rvalue -reference parameter of a member function of a container shall not be -an element of that container; no diagnostic required. -</blockquote> -<p><b>Proposed resolution:</b></p> -<p> -Change 23.1 [container.requirements]: -</p> - -<blockquote> --12- <del>Objects passed to member functions of a container as rvalue references shall not be elements</del> -<ins>An object bound to an rvalue -reference parameter of a member function of a container shall not be -an element</ins> -of that container<del>.</del><ins>;</ins> <del>N</del><ins>n</ins>o -diagnostic required. -</blockquote> - - @@ -13015,7 +11298,7 @@ this problem, can be efficiently implemented anyway </p> <p><i>[ -Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#767">767</a> +Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a> ]</i></p> @@ -13062,68 +11345,11 @@ sub-objects of elements of the container. No diagnostic required. <hr> -<h3><a name="761"></a>761. <tt>unordered_map</tt> needs an <tt>at()</tt> member function</h3> -<p><b>Section:</b> 23.4.1.2 [unord.map.elem] <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-11-15</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -The new member function <tt>at()</tt> was recently added to <tt>std::map()</tt>. It acts -like <tt>operator[]()</tt>, except it throws an exception when the input key is -not found. It is useful when the <tt>map</tt> is <tt>const</tt>, the <tt>value_type</tt> of the -key doesn't have a default constructor, it is an error if the key is -not found, or the user wants to avoid accidentally adding an element to -the map. For exactly these same reasons, <tt>at()</tt> would be equally useful -in <tt>std::unordered_map</tt>. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Add the following functions to the definition of <tt>unordered_map</tt> under "lookup" (23.4.1 [unord.map]): -</p> - -<blockquote><pre>mapped_type& at(const key_type& k); -const mapped_type &at(const key_type &k) const; -</pre></blockquote> - -<p> -Add the following definitions to 23.4.1.2 [unord.map.elem]: -</p> - -<blockquote> -<pre>mapped_type& at(const key_type& k); -const mapped_type &at(const key_type &k) const; -</pre> -<blockquote> -<p> -<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>. -</p> -<p> -<i>Throws:</i> An exception object of type <tt>out_of_range</tt> if no such element -is present. -</p> -</blockquote> -</blockquote> - -<p><i>[ -Bellevue: Editorial note: the "(unique)" differs from map. -]</i></p> - - - - - - - -<hr> <h3><a name="762"></a>762. <tt>std::unique_ptr</tt> requires complete type?</h3> -<p><b>Section:</b> 20.6.11 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> +<p><b>Section:</b> 20.7.11 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-11-30</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr">active issues</a> in [unique.ptr].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr">issues</a> in [unique.ptr].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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#Ready">Ready</a> status.</p> <p><b>Discussion:</b></p> <p> In contrast to the proposed <tt>std::shared_ptr</tt>, <tt>std::unique_ptr</tt> @@ -13158,22 +11384,22 @@ produce new wording. <p><b>Proposed resolution:</b></p> <p> The proposed changes in the following revision refers to the current state of -N2521 including the assumption that 20.6.11.4 [unique.ptr.compiletime] will be removed -according to the current state of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#740">740</a>. +N2521 including the assumption that 20.7.11.4 [unique.ptr.compiletime] will be removed +according to the current state of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>. </p> <p> The specialization <tt>unique_ptr<T[]></tt> has some more restrictive constraints on type-completeness on <tt>T</tt> than <tt>unique_ptr<T></tt>. The following proposed wordings try to cope with that. If the committee sees less usefulness on relaxed constraints on <tt>unique_ptr<T[]></tt>, the alternative would be to stop this relaxation -e.g. by adding one further bullet to 20.6.11.3 [unique.ptr.runtime]/1: +e.g. by adding one further bullet to 20.7.11.3 [unique.ptr.runtime]/1: "<tt>T</tt> shall be a complete type, if used as template argument of <tt>unique_ptr<T[], D></tt> </p> <p> -This issue has some overlap with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a>, but it seems not to cause any +This issue has some overlap with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, but it seems not to cause any problems with this one, -because <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a> adds only optional requirements on <tt>D</tt> that do not conflict +because <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> adds only optional requirements on <tt>D</tt> that do not conflict with the here discussed ones, provided that <tt>D::pointer</tt>'s operations (including default construction, copy construction/assignment, @@ -13185,7 +11411,7 @@ current specification of <tt>unique_ptr</tt>. <ol> <li> <p> -In 20.6.11 [unique.ptr]/2 add as the last sentence to the existing para: +In 20.7.11 [unique.ptr]/2 add as the last sentence to the existing para: </p> <blockquote> @@ -13204,7 +11430,7 @@ function. -- <i>end note</i> ] <li> <p> -20.6.11.2.1 [unique.ptr.single.ctor]/1: No changes necessary. +20.7.11.2.1 [unique.ptr.single.ctor]/1: No changes necessary. </p> <blockquote> @@ -13218,14 +11444,14 @@ The current wording says just this. <li> <p> -In 20.6.11.2.1 [unique.ptr.single.ctor]/5 change the requires clause to say: +In 20.7.11.2.1 [unique.ptr.single.ctor]/5 change the requires clause to say: </p> <blockquote> <p> <i>Requires:</i> <del>The expression <tt>D()(p)</tt> shall be well formed. The default constructor of <tt>D</tt> shall not throw an exception.</del> -<tt>D</tt> <del>must</del> <ins>shall</ins> not be a reference type. +<del><tt>D</tt> must not be a reference type.</del> <ins> <tt>D</tt> shall be default constructible, and that construction shall not throw an exception. @@ -13255,7 +11481,7 @@ again requires Completeness of <tt>Y</tt>, if <tt>!SameType<X, Y></tt> <li> <p> -Merge 20.6.11.2.1 [unique.ptr.single.ctor]/12+13 thereby removing the sentence +Merge 20.7.11.2.1 [unique.ptr.single.ctor]/12+13 thereby removing the sentence of 12, but transferring the "requires" to 13: </p> @@ -13274,10 +11500,20 @@ pointer and the <tt>D</tt> deleter are well-formed and well-defined. </li> <li> -20.6.11.2.1 [unique.ptr.single.ctor]/17: No changes necessary. +20.7.11.2.1 [unique.ptr.single.ctor]/17: No changes necessary. </li> <li> -<p>20.6.11.2.1 [unique.ptr.single.ctor]/21: No changes necessary.</p> +<p>20.7.11.2.1 [unique.ptr.single.ctor]/21:</p> + +<blockquote> +<i>Requires:</i> If <tt>D</tt> is not a reference type, construction of +the deleter <tt>D</tt> from an rvalue of type <tt>E</tt> shall be well +formed and shall not throw an exception. If <tt>D</tt> is a reference +type, then <tt>E</tt> shall be the same type as <tt>D</tt> (diagnostic +required). <tt>U*</tt> shall be implicitly convertible to <tt>T*</tt>. +<ins>[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt> +be complete types. <i>-- end note</i>]</ins> +</blockquote> <p><i>[ N.B.: The current wording of 21 already implicitly guarantees that <tt>U</tt> @@ -13290,12 +11526,14 @@ e.g. "<tt>U</tt> shall be a complete type." <li> <p> -20.6.11.2.2 [unique.ptr.single.dtor]: Just before p1 add a new paragraph: +20.7.11.2.2 [unique.ptr.single.dtor]: Just before p1 add a new paragraph: </p> <blockquote> <p> <i>Requires:</i> The expression <tt>get_deleter()(get())</tt> shall be well-formed, shall have well-defined behavior, and shall not throw exceptions. +<ins>[<i>Note:</i> The use of <tt>default_delete</tt> requires <tt>T</tt> to +be a complete type. <i>-- end note</i>]</ins> </p> <p><i>[ N.B.: This requirement ensures that the whole responsibility on @@ -13307,7 +11545,7 @@ type-completeness of <tt>T</tt> is delegated to this expression. <li> <p> -20.6.11.2.3 [unique.ptr.single.asgn]/1: No changes necessary, except the +20.7.11.2.3 [unique.ptr.single.asgn]/1: No changes necessary, except the current editorial issue, that "must shall" has to be changed to "shall", but this change is not a special part of this resolution. </p> @@ -13321,8 +11559,17 @@ further requirements on the requirements of the effects clause <li> <p> -20.6.11.2.3 [unique.ptr.single.asgn]/6: No changes necessary. +20.7.11.2.3 [unique.ptr.single.asgn]/6: </p> + +<blockquote> +<i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue +<tt>D</tt> shall not throw an exception. <tt>U*</tt> shall be implicitly +convertible to <tt>T*</tt>. +<ins>[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt> +be complete types. <i>-- end note</i>]</ins> +</blockquote> + <p><i>[ N.B.: The current wording of p. 6 already implicitly guarantees that <tt>U</tt> is completely defined, because it requires that <tt>Convertible<U*, T*></tt> @@ -13333,7 +11580,7 @@ is true, see (6)+(8). <li> <p> -20.6.11.2.3 [unique.ptr.single.asgn]/11: No changes necessary. +20.7.11.2.3 [unique.ptr.single.asgn]/11: No changes necessary. </p> <p><i>[ N.B.: Delegation to requirements of effects clause is sufficient. @@ -13342,16 +11589,23 @@ N.B.: Delegation to requirements of effects clause is sufficient. </li> <li> -20.6.11.2.4 [unique.ptr.single.observers]/1+4+7+9+11: No changes necessary. +20.7.11.2.4 [unique.ptr.single.observers]/1+4+7+9+11: </li> +<blockquote> +<pre>T* operator->() const;</pre> +<blockquote> +<ins><i>Note:</i> Use typically requires <tt>T</tt> shall be complete. <i>-- end note</i>]</ins> +</blockquote> +</blockquote> + <li> -20.6.11.2.5 [unique.ptr.single.modifiers]/1: No changes necessary. +20.7.11.2.5 [unique.ptr.single.modifiers]/1: No changes necessary. </li> <li> <p> -20.6.11.2.5 [unique.ptr.single.modifiers]/4: Just before p. 4 add a new paragraph: +20.7.11.2.5 [unique.ptr.single.modifiers]/4: Just before p. 4 add a new paragraph: </p> <blockquote> <i>Requires:</i> The expression <tt>get_deleter()(get())</tt> shall be well-formed, @@ -13360,54 +11614,28 @@ shall have well-defined behavior, and shall not throw exceptions. </li> <li> -20.6.11.2.5 [unique.ptr.single.modifiers]/7: No changes necessary. +20.7.11.2.5 [unique.ptr.single.modifiers]/7: No changes necessary. </li> <li> <p> -20.6.11.3.1 [unique.ptr.runtime.ctor]: Add one additional paragraph just -before the current one: +20.7.11.3 [unique.ptr.runtime]: Add one additional bullet on paragraph 1: </p> <blockquote> <p> -<i>Requires:</i> <tt>T</tt> shall be a complete type. +A specialization for array types is provided with a slightly altered interface. </p> -<p><i>[ -N.B.: We need this requirement, because otherwise it is not -guaranteed that the c'tors can fulfill their requirements to reject -any type that is convertible to <tt>T*</tt>. -]</i></p> - -</blockquote> -</li> +<ul> <li> -20.6.11.3.2 [unique.ptr.runtime.observers]/1: Change the clause to says: +... </li> - -<blockquote> -<i>Requires:</i> <tt>i <</tt> the size of the array to which the stored pointer -points. <tt>T</tt> shall be a complete type. -</blockquote> - <li> -<p> -20.6.11.3.3 [unique.ptr.runtime.modifiers]/1: Change the first sentence of the -paragraph to say: -</p> -<blockquote> -<p> -<i>Requires:</i> <tt>T</tt> shall be a complete type. Does not accept pointer types -which are convertible to <tt>T*</tt> (diagnostic required). [ Note: ...] -</p> -<p><i>[ -N.B. Similar to (15) we need this requirement such that <tt>reset</tt> can -reject types which are convertible to <tt>T*</tt> -]</i></p> - +<ins><tt>T</tt> shall be a complete type.</ins> +</li> +</ul> </blockquote> - </li> </ol> @@ -13507,554 +11735,13 @@ popular implementations for some standard <code>Containers</code>. <hr> -<h3><a name="766"></a>766. Inconsistent exception guarantees between ordered and unordered associative containers</h3> -<p><b>Section:</b> 23.1 [container.requirements], 23.1.3.1 [unord.req.except] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Ion Gaztańaga <b>Date:</b> 2007-12-22</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -23.1 [container.requirements]p10 states: -</p> - -<blockquote> -<p> -Unless otherwise specified (see 23.2.2.3 and 23.2.5.4) all container types defined in this clause meet the following -additional requirements: -</p> -<ul> - -<li>[...]</li> - -<li>no <tt>erase()</tt>, <tt>pop_back()</tt> or <tt>pop_front()</tt> function throws an exception.</li> - -</ul> -</blockquote> - -<p> -23.2.2.3 [deque.modifiers] and 23.2.6.4 [vector.modifiers] offer -additional guarantees for <tt>deque</tt>/<tt>vector insert()</tt> and -<tt>erase()</tt> members. However, 23.1 [container.requirements]p10 -does not mention 23.1.3.1 [unord.req.except] that specifies exception -safety guarantees -for unordered containers. In addition, 23.1.3.1 [unord.req.except]p1 -offers the following guaratee for -<tt>erase()</tt>: -</p> - -<blockquote> -No <tt>erase()</tt> function throws an exception unless that exception -is thrown by the container's Hash or Pred object (if any). -</blockquote> - -<p> -Summary: -</p> - -<p> -According to 23.1 [container.requirements]p10 no -<tt>erase()</tt> function should throw an exception unless otherwise -specified. Although does not explicitly mention 23.1.3.1 [unord.req.except], this section offers additional guarantees -for unordered containers, allowing <tt>erase()</tt> to throw if -predicate or hash function throws. -</p> - -<p> -In contrast, associative containers have no exception safety guarantees -section so no <tt>erase()</tt> function should throw, <em>including -<tt>erase(k)</tt></em> that needs to use the predicate function to -perform its work. This means that the predicate of an associative -container is not allowed to throw. -</p> - -<p> -So: -</p> - -<ol> -<li> -<tt>erase(k)</tt> for associative containers is not allowed to throw. On -the other hand, <tt>erase(k)</tt> for unordered associative containers -is allowed to throw. -</li> -<li> -<tt>erase(q)</tt> for associative containers is not allowed to throw. On -the other hand, <tt>erase(q)</tt> for unordered associative containers -is allowed to throw if it uses the hash or predicate. -</li> -<li> -To fulfill 1), predicates of associative containers are not allowed to throw. -Predicates of unordered associative containers are allowed to throw. -</li> -<li> -2) breaks a widely used programming pattern (flyweight pattern) for -unordered containers, where objects are registered in a global map in -their constructors and unregistered in their destructors. If <tt>erase(q)</tt> is -allowed to throw, the destructor of the object would need to rethrow the -exception or swallow it, leaving the object registered. -</li> -</ol> - - -<p><b>Proposed resolution:</b></p> -<p> -Create a new sub-section of 23.1.2 [associative.reqmts] (perhaps [associative.req.except]) titled "Exception -safety guarantees". -</p> - -<blockquote> -<p> -1 For associative containers, no <tt>clear()</tt> function throws an exception. -<tt>erase(k)</tt> does not throw an exception unless that exception is thrown by -the container's Pred object (if any). -</p> - -<p> -2 For associative containers, if an exception is thrown by any operation -from within an <tt>insert()</tt> function inserting a single element, the -<tt>insert()</tt> function has no effect. -</p> - -<p> -3 For associative containers, no <tt>swap</tt> function throws an exception -unless that exception is thrown by the copy constructor or copy -assignment operator of the container's Pred object (if any). -</p> -</blockquote> - -<p> -Change 23.1.3.1 [unord.req.except]p1: -</p> - -<blockquote> -For unordered associative containers, no <tt>clear()</tt> function -throws an exception. <del>No</del> <tt>erase(<ins>k</ins>)</tt> -<del>function</del> <ins>does not</ins> throw<del>s</del> an exception -unless that exception is thrown by the container's Hash or Pred object -(if any). -</blockquote> - -<p> -Change 23.1 [container.requirements]p10 to add references to new sections: -</p> - -<blockquote> -Unless otherwise specified (see [deque.modifiers]<ins>,</ins> -<del>and</del> [vector.modifiers]<ins>, [associative.req.except], -[unord.req.except]</ins>) all container types defined in this clause meet -the following additional requirements: -</blockquote> - -<p> -Change 23.1 [container.requirements]p10 referring to <tt>swap</tt>: -</p> - -<blockquote> -<ul> -<li> -no <tt>swap()</tt> function throws an exception<del> unless that exception is thrown -by the copy constructor or assignment operator of the container's -Compare object (if any; see [associative.reqmts])</del>. -</li> -</ul> -</blockquote> - - - - - - -<hr> -<h3><a name="767"></a>767. Forwarding and backward compatibility</h3> -<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> - <b>Submitter:</b> Sylvain Pion <b>Date:</b> 2007-12-28</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> -<p><b>Discussion:</b></p> -<p> -Playing with g++'s C++0X mode, I noticed that the following -code, which used to compile: -</p> - -<blockquote><pre>#include <vector> - -int main() -{ - std::vector<char *> v; - v.push_back(0); -} -</pre></blockquote> - -<p> -now fails with the following error message: -</p> - -<blockquote>.../include/c++/4.3.0/ext/new_allocator.h: In member -function 'void __gnu_cxx::new_allocator<_Tp>::construct(_Tp*, -_Args&& ...) [with _Args = int, _Tp = char*]': -.../include/c++/4.3.0/bits/stl_vector.h:707: instantiated from 'void -std::vector<_Tp, _Alloc>::push_back(_Args&& ...) [with -_Args = int, _Tp = char*, _Alloc = std::allocator<char*>]' -test.cpp:6: instantiated from here -.../include/c++/4.3.0/ext/new_allocator.h:114: error: invalid -conversion from 'int' to 'char*' -</blockquote> - -<p> -As far as I know, g++ follows the current draft here. -</p> -<p> -Does the committee really intend to break compatibility for such cases? -</p> - -<p><i>[ -Sylvain adds: -]</i></p> - - -<blockquote> -<p> -I just noticed that <tt>std::pair</tt> has the same issue. -The following now fails with GCC's -std=c++0x mode: -</p> - -<blockquote><pre>#include <utility> - -int main() -{ - std::pair<char *, char *> p (0,0); -} -</pre></blockquote> - -<p> -I have not made any general audit for such problems elsewhere. -</p> -</blockquote> - -<p><i>[ -Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#756">756</a> -]</i></p> - - -<p><i>[ -Bellevue: -]</i></p> - - -<blockquote> -<p> -Motivation is to handle the old-style int-zero-valued NULL pointers. -Problem: this solution requires concepts in some cases, which some users -will be slow to adopt. Some discussion of alternatives involving -prohibiting variadic forms and additional library-implementation -complexity. -</p> -<p> -Discussion of "perfect world" solutions, the only such solution put -forward being to retroactively prohibit use of the integer zero for a -NULL pointer. This approach was deemed unacceptable given the large -bodies of pre-existing code that do use integer zero for a NULL pointer. -</p> -<p> -Another approach is to change the member names. Yet another approach is -to forbid the extension in absence of concepts. -</p> -<p> -Resolution: These issues (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>) will be subsumed into a -paper to be produced by Alan Talbot in time for review at the 2008 -meeting in France. Once this paper is produced, these issues will be -moved to NAD. -</p> -</blockquote> - - - -<p><b>Proposed resolution:</b></p> -<p> -Add the following rows to Table 90 "Optional sequence container operations", 23.1.1 [sequence.reqmts]: -</p> - -<blockquote> -<table border="1"> -<tbody><tr> -<th>expression</th> <th>return type</th> <th>assertion/note<br>pre-/post-condition</th> <th>container</th> -</tr> - -<tr> -<td> -<tt>a.push_front(t)</tt> -</td> -<td> -<tt>void</tt> -</td> -<td> -<tt>a.insert(a.begin(), t)</tt><br> -<i>Requires:</i> <tt>T</tt> shall be <tt>CopyConstructible</tt>. -</td> -<td> -<tt>list, deque</tt> -</td> -</tr> - -<tr> -<td> -<tt>a.push_front(rv)</tt> -</td> -<td> -<tt>void</tt> -</td> -<td> -<tt>a.insert(a.begin(), rv)</tt><br> -<i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt>. -</td> -<td> -<tt>list, deque</tt> -</td> -</tr> - -<tr> -<td> -<tt>a.push_back(t)</tt> -</td> -<td> -<tt>void</tt> -</td> -<td> -<tt>a.insert(a.end(), t)</tt><br> -<i>Requires:</i> <tt>T</tt> shall be <tt>CopyConstructible</tt>. -</td> -<td> -<tt>list, deque, vector, basic_string</tt> -</td> -</tr> - -<tr> -<td> -<tt>a.push_back(rv)</tt> -</td> -<td> -<tt>void</tt> -</td> -<td> -<tt>a.insert(a.end(), rv)</tt><br> -<i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt>. -</td> -<td> -<tt>list, deque, vector, basic_string</tt> -</td> -</tr> - -</tbody></table> -</blockquote> - -<p> -Change the synopsis in 23.2.2 [deque]: -</p> - -<blockquote><pre><ins>void push_front(const T& x);</ins> -<ins>void push_front(T&& x);</ins> -<ins>void push_back(const T& x);</ins> -<ins>void push_back(T&& x);</ins> -template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args); -template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args); -</pre></blockquote> - -<p> -Change 23.2.2.3 [deque.modifiers]: -</p> - -<blockquote><pre><ins>void push_front(const T& x);</ins> -<ins>void push_front(T&& x);</ins> -<ins>void push_back(const T& x);</ins> -<ins>void push_back(T&& x);</ins> -template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args); -template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args); -</pre></blockquote> - -<p> -Change the synopsis in 23.2.4 [list]: -</p> - -<blockquote><pre><ins>void push_front(const T& x);</ins> -<ins>void push_front(T&& x);</ins> -<ins>void push_back(const T& x);</ins> -<ins>void push_back(T&& x);</ins> -template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args); -template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args); -</pre></blockquote> - -<p> -Change 23.2.4.3 [list.modifiers]: -</p> - -<blockquote><pre><ins>void push_front(const T& x);</ins> -<ins>void push_front(T&& x);</ins> -<ins>void push_back(const T& x);</ins> -<ins>void push_back(T&& x);</ins> -template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args); -template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args); -</pre></blockquote> - -<p> -Change the synopsis in 23.2.6 [vector]: -</p> - -<blockquote><pre><ins>void push_back(const T& x);</ins> -<ins>void push_back(T&& x);</ins> -template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args); -</pre></blockquote> - -<p> -Change 23.2.6.4 [vector.modifiers]: -</p> - -<blockquote><pre><ins>void push_back(const T& x);</ins> -<ins>void push_back(T&& x);</ins> -template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args); -</pre></blockquote> - - - - - - - -<hr> -<h3><a name="768"></a>768. Typos in [atomics]?</h3> -<p><b>Section:</b> 29.4.3 [atomics.types.generic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Alberto Ganesh Barbati <b>Date:</b> 2007-12-28</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -in the latest publicly available draft, paper -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">N2641</a>, -in section 29.4.3 [atomics.types.generic], the following specialization of the template -<tt>atomic<></tt> is provided for pointers: -</p> - -<blockquote><pre>template <class T> struct atomic<T*> : atomic_address { - T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; - T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; - - atomic() = default; - constexpr explicit atomic(T); - atomic(const atomic&) = delete; - atomic& operator=(const atomic&) = delete; - - T* operator=(T*) volatile; - T* operator++(int) volatile; - T* operator--(int) volatile; - T* operator++() volatile; - T* operator--() volatile; - T* operator+=(ptrdiff_t) volatile; - T* operator-=(ptrdiff_t) volatile; -}; -</pre></blockquote> - -<p> -First of all, there is a typo in the non-default constructor which -should take a <tt>T*</tt> rather than a <tt>T</tt>. -</p> - -<p> -As you can see, the specialization redefine and therefore hide a few -methods from the base class <tt>atomic_address</tt>, namely <tt>fetch_add</tt>, <tt>fetch_sub</tt>, -<tt>operator=</tt>, <tt>operator+=</tt> and <tt>operator-=</tt>. That's good, but... what happened -to the other methods, in particular these ones: -</p> - -<blockquote><pre>void store(T*, memory_order = memory_order_seq_cst) volatile; -T* load( memory_order = memory_order_seq_cst ) volatile; -T* swap( T*, memory_order = memory_order_seq_cst ) volatile; -bool compare_swap( T*&, T*, memory_order, memory_order ) volatile; -bool compare_swap( T*&, T*, memory_order = memory_order_seq_cst ) volatile; -</pre></blockquote> - -<p> -By reading paper -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html">N2427 "C++ Atomic Types and Operations"</a>, -I see that the -definition of the specialization <tt>atomic<T*></tt> matches the one in the -draft, but in the example implementation the methods <tt>load()</tt>, <tt>swap()</tt> -and <tt>compare_swap()</tt> are indeed present. -</p> - -<p> -Strangely, the example implementation does not redefine the method -<tt>store()</tt>. It's true that a <tt>T*</tt> is always convertible to <tt>void*</tt>, but not -hiding the <tt>void*</tt> signature from the base class makes the class -error-prone to say the least: it lets you assign pointers of any type to -a <tt>T*</tt>, without any hint from the compiler. -</p> - -<p> -Is there a true intent to remove them from the specialization or are -they just missing from the definition because of a mistake? -</p> - -<p><i>[ -Bellevue: -]</i></p> - - -<blockquote> -<p> -The proposed revisions are accepted. -</p> -<p> -Further discussion: why is the ctor labeled "constexpr"? Lawrence said -this permits the object to be statically initialized, and that's -important because otherwise there would be a race condition on -initialization. -</p> -</blockquote> - - -<p><b>Proposed resolution:</b></p> -<p> -Change the synopsis in 29.4.3 [atomics.types.generic]: -</p> - -<blockquote><pre>template <class T> struct atomic<T*> : atomic_address { - <ins>void store(T*, memory_order = memory_order_seq_cst) volatile;</ins> - <ins>T* load( memory_order = memory_order_seq_cst ) volatile;</ins> - <ins>T* swap( T*, memory_order = memory_order_seq_cst ) volatile;</ins> - <ins>bool compare_swap( T*&, T*, memory_order, memory_order ) volatile;</ins> - <ins>bool compare_swap( T*&, T*, memory_order = memory_order_seq_cst ) volatile;</ins> - - T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; - T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; - - atomic() = default; - constexpr explicit atomic(T<ins>*</ins>); - atomic(const atomic&) = delete; - atomic& operator=(const atomic&) = delete; - - T* operator=(T*) volatile; - T* operator++(int) volatile; - T* operator--(int) volatile; - T* operator++() volatile; - T* operator--() volatile; - T* operator+=(ptrdiff_t) volatile; - T* operator-=(ptrdiff_t) volatile; -}; -</pre></blockquote> - - - - - - -<hr> <h3><a name="769"></a>769. std::function should use nullptr_t instead of "unspecified-null-pointer-type"</h3> -<p><b>Section:</b> 20.5.15.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 20.6.15.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-10</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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> -N2461 already replaced in 20.5.15.2 [func.wrap.func] it's originally proposed +N2461 already replaced in 20.6.15.2 [func.wrap.func] it's originally proposed (implicit) conversion operator to "unspecified-bool-type" by the new explicit bool conversion, but the inverse conversion should also use the new <tt>std::nullptr_t</tt> type instead of "unspecified-null-pointer- @@ -14065,7 +11752,7 @@ type". <p><b>Proposed resolution:</b></p> <p> -In 20.5 [function.objects], header <tt><functional></tt> synopsis replace: +In 20.6 [function.objects], header <tt><functional></tt> synopsis replace: </p> <blockquote><pre>template<class R, class... ArgTypes> @@ -14079,7 +11766,7 @@ template<class R, class... ArgTypes> </pre></blockquote> <p> -In the class function synopsis of 20.5.15.2 [func.wrap.func] replace +In the class function synopsis of 20.6.15.2 [func.wrap.func] replace </p> <blockquote><pre>function(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>); @@ -14088,7 +11775,7 @@ function& operator=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t< </pre></blockquote> <p> -In 20.5.15.2 [func.wrap.func], "Null pointer comparisons" replace: +In 20.6.15.2 [func.wrap.func], "Null pointer comparisons" replace: </p> <blockquote><pre>template <class R, class... ArgTypes> @@ -14102,7 +11789,7 @@ template <class R, class... ArgTypes> </pre></blockquote> <p> -In 20.5.15.2.1 [func.wrap.func.con], replace +In 20.6.15.2.1 [func.wrap.func.con], replace </p> <blockquote><pre>function(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>); @@ -14111,7 +11798,7 @@ function& operator=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t< </pre></blockquote> <p> -In 20.5.15.2.6 [func.wrap.func.nullptr], replace +In 20.6.15.2.6 [func.wrap.func.nullptr], replace </p> <blockquote><pre>template <class R, class... ArgTypes> @@ -14136,80 +11823,12 @@ template <class R, class... ArgTypes> <hr> -<h3><a name="770"></a>770. std::function should use rvalue swap</h3> -<p><b>Section:</b> 20.5.15 [func.wrap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-10</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -It is expected that typical implementations of <tt>std::function</tt> will -use dynamic memory allocations at least under given conditions, -so it seems appropriate to change the current lvalue swappabilty of -this class to rvalue swappability. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -In 20.5 [function.objects], header <tt><functional></tt> synopsis, just below of -</p> - -<blockquote><pre>template<class R, class... ArgTypes> - void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&); -<ins>template<class R, class... ArgTypes> - void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&); -template<class R, class... ArgTypes> - void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&&);</ins> -</pre></blockquote> - -<p> -In 20.5.15.2 [func.wrap.func] class <tt>function</tt> definition, change -</p> - -<blockquote><pre>void swap(function&<ins>&</ins>); -</pre></blockquote> - -<p> -In 20.5.15.2 [func.wrap.func], just below of -</p> - -<blockquote><pre>template <class R, class... ArgTypes> - void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&); -<ins>template <class R, class... ArgTypes> - void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&); -template <class R, class... ArgTypes> - void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&&);</ins> -</pre></blockquote> - -<p> -In 20.5.15.2.2 [func.wrap.func.mod] change -</p> - -<blockquote><pre>void swap(function&<ins>&</ins> other); -</pre></blockquote> - -<p> -In 20.5.15.2.7 [func.wrap.func.alg] add the two overloads -</p> - -<blockquote><pre><ins>template<class R, class... ArgTypes> - void swap(function<R(ArgTypes...)>&& f1, function<R(ArgTypes...)>& f2); -template<class R, class... ArgTypes> - void swap(function<R(ArgTypes...)>& f1, function<R(ArgTypes...)>&& f2);</ins> -</pre></blockquote> - - - - - - -<hr> <h3><a name="771"></a>771. Impossible throws clause in [string.conversions]</h3> -<p><b>Section:</b> 21.4 [string.conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> +<p><b>Section:</b> 21.4 [string.conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-13</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#string.conversions">active issues</a> in [string.conversions].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.conversions">issues</a> in [string.conversions].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</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 new <tt>to_string</tt> and <tt>to_wstring</tt> functions described in 21.4 [string.conversions] @@ -14272,11 +11891,11 @@ string to_string(long double val); <hr> <h3><a name="772"></a>772. Impossible return clause in [string.conversions]</h3> -<p><b>Section:</b> 21.4 [string.conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 21.4 [string.conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-13</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#string.conversions">active issues</a> in [string.conversions].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.conversions">issues</a> in [string.conversions].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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 return clause 21.4 [string.conversions]/paragraph 15 of the new <tt>to_wstring</tt> @@ -14432,198 +12051,12 @@ Wording provided in <hr> -<h3><a name="775"></a>775. Tuple indexing should be unsigned?</h3> -<p><b>Section:</b> 20.3.1.4 [tuple.helper] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-01-16</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 tuple element access API identifies the element in the sequence -using signed integers, and then goes on to enforce the requirement that -I be >= 0. There is a much easier way to do this - declare I as -<tt>unsigned</tt>. -</p> -<p> -In fact the proposal is to use <code>std::size_t</code>, matching the type used in the <tt>tuple_size</tt> API. -</p> -<p> -A second suggestion is that it is hard to imagine an API that deduces -and index at compile time and returns a reference throwing an exception. -Add a specific <em>Throws:</em> Nothing paragraph to each element -access API. -</p> -<p> -In addition to <code>tuple</code>, update the API applies to -<code>pair</code> and <code>array</code>, and should be updated -accordingly. -</p> - -<p> -A third observation is that the return type of the <code>get</code> -functions for <code>std::pair</code> is pseudo-code, but it is not -clearly marked as such. There is actually no need for pseudo-code as -the return type can be specified precisely with a call to -<code>tuple_element</code>. This is already done for -<code>std::tuple</code>, and <code>std::array</code> does not have a -problem as all elements are of type <code>T</code>. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Update header <utility> synopsis in 20.2 [utility] -</p> -<pre><em>// 20.2.3, tuple-like access to pair:</em> -template <class T> class tuple_size; -template <<del>int</del><ins>size_t</ins> I, class T> class tuple_element; - -template <class T1, class T2> struct tuple_size<std::pair<T1, T2> >; -template <class T1, class T2> struct tuple_element<0, std::pair<T1, T2> >; -template <class T1, class T2> struct tuple_element<1, std::pair<T1, T2> >; - -template<<del>int</del><ins>size_t</ins> I, class T1, class T2> - <del>P</del><ins>typename tuple_element<I, std::pair<T1, T2> >::type </ins>& get(std::pair<T1, T2>&); -template<<del>int</del><ins>size_t</ins> I, class T1, class T2> - const <del>P</del><ins>typename tuple_element<I, std::pair<T1, T2> >::type </ins>& get(const std::pair<T1, T2>&); -</pre> -<p> -Update <strong>20.2.3 [pairs] Pairs</strong> -</p> -<pre>template<<del>int</del><ins>size_t</ins> I, class T1, class T2> - <del>P</del><ins>typename tuple_element<I, std::pair<T1, T2> >::type </ins>& get(pair<T1, T2>&); -template<<del>int</del><ins>size_t</ins> I, class T1, class T2> - const <del>P</del><ins>typename tuple_element<I, std::pair<T1, T2> >::type </ins>& get(const pair<T1, T2>&); -</pre> -<p> -<del>24 <em>Return type:</em> If <code>I == 0</code> then <code>P</code> is <code>T1</code>, if <code>I == 1</code> then <code>P</code> is <code>T2</code>, and otherwise the program is ill-formed.</del> -</p> -<p> -25 <em>Returns:</em> If <code>I == 0</code> returns <code>p.first</code>, <del>otherwise</del> <ins>if <code>I == 1</code></ins> returns <code>p.second</code><ins>, and otherwise the program is ill-formed</ins>. -</p> -<p> -<ins><em>Throws:</em> Nothing.</ins> -</p> - - -<p> -Update header <tuple> synopsis in 20.3 [tuple] with a APIs as below: -</p> -<pre>template <<del>int</del><ins>size_t</ins> I, class T> class tuple_element; <em>// undefined</em> -template <<del>int</del><ins>size_t</ins> I, class... Types> class tuple_element<I, tuple<Types...> >; - -<em>// 20.3.1.4, element access:</em> -template <<del>int</del><ins>size_t</ins> I, class... Types> - typename tuple_element<I, tuple<Types...> >::type& get(tuple<Types...>&); -template <<del>int</del><ins>size_t</ins> I, class ... types> - typename tuple_element<I, tuple<Types...> >::type const& get(const tuple<Types...>&); -</pre> - -<p> -Update <strong>20.3.1.4 [tuple.helper] Tuple helper classes</strong> -</p> -<pre>template <<del>int</del><ins>size_t</ins> I, class... Types> -class tuple_element<I, tuple<Types...> > { -public: - typedef TI type; -};</pre> -<p> -1 <em>Requires:</em> <code><del>0 <= I and </del>I < sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds. -</p> -<p> -2 <em>Type:</em> <code>TI</code> is the type of the <code>I</code>th element of <code>Types</code>, where indexing is zero-based. -</p> -<p> -Update <strong>20.3.1.5 [tuple.elem] Element access</strong> -</p> -<pre>template <<del>int</del><ins>size_t</ins> I, class... types > -typename tuple_element<I, tuple<Types...> >::type& get(tuple<Types...>& t); -</pre> -1 <em>Requires:</em> <code><del>0 <= I and </del>I < sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds. -<p> -2 <em>Returns:</em> A reference to the <code>I</code>th element of <code>t</code>, where indexing is zero-based. -</p> -<ins><em>Throws:</em> Nothing.</ins> -<pre>template <<del>int</del><ins>size_t</ins> I, class... types> -typename tuple_element<I, tuple<Types...> >::type const& get(const tuple<Types...>& t); -</pre> -<p> -3 <em>Requires:</em> <code><del>0 <= I and </del>I < sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds. -</p> -<p> -4 <em>Returns:</em> A const reference to the <code>I</code>th element of <code>t</code>, where indexing is zero-based. -</p> -<p> -<ins><em>Throws:</em> Nothing.</ins> -</p> - - -<p> -Update header <array> synopsis in 20.2 [utility] -</p> -<pre>template <class T> class tuple_size; <em>// forward declaration</em> -template <<del>int</del><ins>size_t</ins> I, class T> class tuple_element; <em>// forward declaration</em> -template <class T, size_t N> - struct tuple_size<array<T, N> >; -template <<del>int</del><ins>size_t</ins> I, class T, size_t N> - struct tuple_element<I, array<T, N> >; -template <<del>int</del><ins>size_t</ins> I, class T, size_t N> - T& get(array<T, N>&); -template <<del>int</del><ins>size_t</ins> I, class T, size_t N> - const T& get(const array<T, N>&); -</pre> - -<p> -Update <strong>23.2.1.6 [array.tuple] Tuple interface to class template array</strong> -</p> -<pre>tuple_element<<ins>size_t </ins>I, array<T, N> >::type -</pre> -<p> -3 <em>Requires:</em> <code><del>0 <= </del>I < N.</code> The program is ill-formed if <code>I</code> is out of bounds. -</p> -<p> -4 <em>Value:</em> The type <code>T</code>. -</p> -<pre>template <<del>int</del><ins>size_t</ins> I, class T, size_t N> T& get(array<T, N>& a); -</pre> -<p> -5 <em>Requires:</em> <code><del>0 <= </del>I < N</code>. The program is ill-formed if <code>I</code> is out of bounds. -</p> -<p> -<em>Returns:</em> A reference to the <code>I</code>th element of <code>a</code>, where indexing is zero-based. -</p> -<p> -<ins><em>Throws:</em> Nothing.</ins> -</p> -<pre>template <<del>int</del><ins>size_t</ins> I, class T, size_t N> const T& get(const array<T, N>& a); -</pre> -<p> -6 <em>Requires:</em> <code><del>0 <= </del>I < N</code>. The program is ill-formed if <code>I</code> is out of bounds. -</p> -<p> -7 <em>Returns:</em> A const reference to the <code>I</code>th element of <code>a</code>, where indexing is zero-based. -</p> -<p> -<ins><em>Throws:</em> Nothing.</ins> -</p> - - -<p><i>[ -Bellevue: Note also that the phrase "The program is ill-formed if I is -out of bounds" in the requires clauses are probably unnecessary, and -could be removed at the editor's discretion. Also std:: qualification -for pair is also unnecessary. -]</i></p> - - - - -<hr> <h3><a name="776"></a>776. Undescribed assign function of std::array</h3> -<p><b>Section:</b> 23.2.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</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#Ready">Ready</a> <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-20</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</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 class template array synopsis in 23.2.1 [array]/3 declares a member @@ -14712,135 +12145,11 @@ Set state to Review given substitution of "fill" for "assign". <hr> -<h3><a name="777"></a>777. Atomics Library Issue</h3> -<p><b>Section:</b> 29.4.4 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-01-21</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 load functions are defined as -</p> - -<blockquote><pre>C atomic_load(volatile A* object); -C atomic_load_explicit(volatile A* object, memory_order); -C A::load(memory_order order = memory_order_seq_cst) volatile; -</pre></blockquote> - -<p> -which prevents their use in <tt>const</tt> contexts. -</p> - -<p><i>[ -post Bellevue Peter adds: -]</i></p> - - -<blockquote> -<p> -Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#777">777</a> suggests making <tt>atomic_load</tt> operate on <tt>const</tt> objects. There is a -subtle point here. Atomic loads do not generally write to the object, except -potentially for the <tt>memory_order_seq_cst</tt> constraint. Depending on the -architecture, a dummy write with the same value may be required to be issued -by the atomic load to maintain sequential consistency. This, in turn, may -make the following code: -</p> - -<blockquote><pre>const atomic_int x{}; - -int main() -{ - x.load(); -} -</pre></blockquote> - -<p> -dump core under a straightforward implementation that puts const objects in -a read-only section. -</p> -<p> -There are ways to sidestep the problem, but it needs to be considered. -</p> -<p> -The tradeoff is between making the data member of the atomic types -mutable and requiring the user to explicitly mark atomic members as -mutable, as is already the case with mutexes. -</p> -</blockquote> - - - -<p><b>Proposed resolution:</b></p> -<p> -Add the <tt>const</tt> qualifier to <tt>*object</tt> and <tt>*this</tt>. -</p> - -<blockquote><pre>C atomic_load(<ins>const</ins> volatile A* object); -C atomic_load_explicit(<ins>const</ins> volatile A* object, memory_order); -C A::load(memory_order order = memory_order_seq_cst) <ins>const</ins> volatile; -</pre></blockquote> - - - - - - -<hr> -<h3><a name="778"></a>778. std::bitset does not have any constructor taking a string literal</h3> -<p><b>Section:</b> 23.3.5.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2008-01-24</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#bitset.cons">active issues</a> in [bitset.cons].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.cons">issues</a> in [bitset.cons].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a></p> -<p><b>Discussion:</b></p> -<p> -A small issue with <tt>std::bitset</tt>: it does not have any constructor -taking a string literal, which is clumsy and looks like an oversigt when -we tried to enable uniform use of <tt>string</tt> and <tt>const char*</tt> in the library. -</p> - -<p> -Suggestion: Add -</p> - -<blockquote><pre>explicit bitset( const char* str ); -</pre></blockquote> - -<p> -to std::bitset. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Add to synopsis in 23.3.5 [template.bitset] -</p> - -<blockquote><pre>explicit bitset( const char* str ); -</pre></blockquote> - -<p> -Add to synopsis in 23.3.5.1 [bitset.cons] -</p> - -<blockquote><pre>explicit bitset( const char* str ); -</pre> -<p> -<i>Effects:</i> Constructs a <tt>bitset</tt> as if <tt>bitset(string(str))</tt>. -</p> -</blockquote> - - - - - - -<hr> <h3><a name="779"></a>779. Resolution of #283 incomplete</h3> -<p><b>Section:</b> 25.2.8 [alg.remove] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 25.2.8 [alg.remove] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-25</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.remove">issues</a> in [alg.remove].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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 resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a> did not resolve similar necessary changes for algorithm @@ -14851,7 +12160,7 @@ which seems to be an oversight. <p><b>Proposed resolution:</b></p> <p> -In 25.2.8 [alg.remove]/p.6, replace the N2461 requires clause with one of: +In 25.2.8 [alg.remove]/p.6, replace the N2461 requires clause with: </p> <blockquote> @@ -14860,17 +12169,6 @@ and <tt>[result,result + (last - first))</tt> shall not overlap. <ins>The expres valid.</ins> </blockquote> -<p> -or -</p> - -<blockquote> -<i>Requires:</i> <del>Type <tt>T</tt> is <tt>EqualityComparable</tt> (31).</del> The ranges <tt>[first,last)</tt> -and <tt>[result,result + (last - first))</tt> shall not overlap. -<ins>The result of the expression <tt>*first</tt> shall -be writable to the output iterator.</ins> -</blockquote> - @@ -14958,336 +12256,6 @@ other parts of <tt><algorithm></tt> show, just a matter of consistency] <hr> -<h3><a name="781"></a>781. <tt>std::complex</tt> should add missing C99 functions</h3> -<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> Daniel Krügler <b>Date:</b> 2008-01-26</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#complex.value.ops">active issues</a> in [complex.value.ops].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.value.ops">issues</a> in [complex.value.ops].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -A comparision of the N2461 header <tt><complex></tt> synopsis ([complex.synopsis]) -with the C99 standard (ISO 9899, 2nd edition and the two corrigenda) show -some complex functions that are missing in C++. These are: -</p> - -<ol> -<li> -7.3.9.4: (required elements of the C99 library)<br> -The <tt>cproj</tt> functions -</li> -<li> -7.26.1: (optional elements of the C99 library)<br> -<pre>cerf cerfc cexp2 -cexpm1 clog10 clog1p -clog2 clgamma ctgamma -</pre> -</li> -</ol> - -<p> -I propose that at least the required <tt>cproj</tt> overloads are provided as equivalent -C++ functions. This addition is easy to do in one sentence (delegation to C99 -function). -</p> - -<p> -Please note also that the current entry <tt>polar</tt> -in 26.3.9 [cmplx.over]/1 -should be removed from the mentioned overload list. It does not make sense to require that a -function already expecting <em>scalar</em> arguments -should cast these arguments into corresponding -<tt>complex<T></tt> arguments, which are not accepted by -this function. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -In 26.3.1 [complex.synopsis] add just between the declaration of <tt>conj</tt> and <tt>fabs</tt>: -</p> - -<blockquote><pre>template<class T> complex<T> conj(const complex<T>&); -<ins>template<class T> complex<T> proj(const complex<T>&);</ins> -template<class T> complex<T> fabs(const complex<T>&); -</pre></blockquote> - -<p> -In 26.3.7 [complex.value.ops] just after p.6 (return clause of <tt>conj</tt>) add: -</p> - -<blockquote> -<pre>template<class T> complex<T> proj(const complex<T>& x); -</pre> -<blockquote> - -<i>Effects:</i> Behaves the same as C99 function <tt>cproj</tt>, defined in -subclause 7.3.9.4." -</blockquote> -</blockquote> - -<p> -In 26.3.9 [cmplx.over]/1, add one further entry <tt>proj</tt> to -the overload list. -</p> - -<blockquote> -<p> -The following function templates shall have additional overloads: -</p> -<blockquote><pre>arg norm -conj <del>polar</del> <ins>proj</ins> -imag real -</pre></blockquote> -</blockquote> - - - - - - -<hr> -<h3><a name="782"></a>782. Extended <tt>seed_seq</tt> constructor is useless</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#Ready">Ready</a> - <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-27</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#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -Part of the resolution of n2423, issue 8 was the proposal to -extend the <tt>seed_seq</tt> constructor accepting an input range -as follows (which is now part of N2461): -</p> - -<blockquote><pre>template<class InputIterator, -size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits> -seed_seq(InputIterator begin, InputIterator end); -</pre></blockquote> - -<p> -First, the expression <tt>iterator_traits<InputIterator>::value_type</tt> -is invalid due to missing <tt>typename</tt> keyword, which is easy to -fix. -</p> - -<p> -Second (and worse), while the language now supports default -template arguments of function templates, this customization -point via the second <tt>size_t</tt> template parameter is of no advantage, -because <tt>u</tt> can never be deduced, and worse - because it is a -constructor function template - it can also never be explicitly -provided (14.8.1 [temp.arg.explicit]/7). -</p> - -<p> -The question arises, which advantages result from a compile-time -knowledge of <tt>u</tt> versus a run time knowledge? If run time knowledge -suffices, this parameter should be provided as normal function -default argument [Resolution marked (A)], if compile-time knowledge -is important, this could be done via a tagging template or more -user-friendly via a standardized helper generator function -(<tt>make_seed_seq</tt>), which allows this [Resolution marked (B)]. -</p> - -<p><i>[ -Bellevue: -]</i></p> - - -<blockquote> -<p> -Fermilab does not have a strong opinion. Would prefer to go with -solution A. Bill agrees that solution A is a lot simpler and does the -job. -</p> -<p> -Proposed Resolution: Accept Solution A. -</p> -</blockquote> - -<p> -Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a> claims to make this issue moot. -</p> - - - -<p><b>Proposed resolution:</b></p> -<ol type="A"> -<li> -<p> -In 26.4.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis replace: -</p> - -<blockquote><pre>class seed_seq -{ -public: - ... - template<class InputIterator<del>, - size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits</del>> - seed_seq(InputIterator begin, InputIterator end<ins>, - size_t u = numeric_limits<typename iterator_traits<InputIterator>::value_type>::digits</ins>); - ... -}; -</pre></blockquote> - -<p> -and do a similar replacement in the member description between -p.3 and p.4. -</p> -</li> - -<li> -<p> -In 26.4.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis <em>and</em> in the -member description between p.3 and p.4 replace: -</p> - -<blockquote><pre>template<class InputIterator<del>, - size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits</del>> - seed_seq(InputIterator begin, InputIterator end); -<ins>template<class InputIterator, size_t u> -seed_seq(InputIterator begin, InputIterator end, <i>implementation-defined</i> s);</ins> -</pre></blockquote> - -<p> -In 26.4.2 [rand.synopsis], header <tt><random></tt> synopsis, immediately after the -class <tt>seed_seq</tt> declaration <em>and</em> in 26.4.7.1 [rand.util.seedseq]/2, immediately -after the class <tt>seed_seq</tt> definition add: -</p> - -<blockquote><pre>template<size_t u, class InputIterator> - seed_seq make_seed_seq(InputIterator begin, InputIterator end); -</pre></blockquote> - -<p> -In 26.4.7.1 [rand.util.seedseq], just before p.5 insert two paragraphs: -</p> - -<blockquote> -<p> -The first constructor behaves as if it would provide an -integral constant expression <tt>u</tt> of type <tt>size_t</tt> of value -<tt>numeric_limits<typename iterator_traits<InputIterator>::value_type>::digits</tt>. -</p> -<p> -The second constructor uses an implementation-defined mechanism -to provide an integral constant expression <tt>u</tt> of type <tt>size_t</tt> and -is called by the function <tt>make_seed_seq</tt>. -</p> -</blockquote> - -<p> -In 26.4.7.1 [rand.util.seedseq], just after the last paragraph add: -</p> - -<blockquote> -<pre>template<size_t u, class InputIterator> - seed_seq make_seed_seq(InputIterator begin, InputIterator end); -</pre> -<blockquote> -<p> -where <tt>u</tt> is used to construct an object <tt>s</tt> of implementation-defined type. -</p> -<p> -<i>Returns:</i> <tt>seed_seq(begin, end, s)</tt>; -</p> -</blockquote> -</blockquote> - -</li> -</ol> - - - - - - -<hr> -<h3><a name="783"></a>783. <tt>thread::id</tt> reuse</h3> -<p><b>Section:</b> 30.2.1.1 [thread.thread.id] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Hans Boehm <b>Date:</b> 2008-02-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> -The current working paper -(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2497.html">N2497</a>, -integrated just before Bellevue) is -not completely clear whether a given <tt>thread::id</tt> value may be reused once -a thread has exited and has been joined or detached. Posix allows -thread ids (<tt>pthread_t</tt> values) to be reused in this case. Although it is -not completely clear whether this originally was the right decision, it -is clearly the established practice, and we believe it was always the -intent of the C++ threads API to follow Posix and allow this. Howard -Hinnant's example implementation implicitly relies on allowing reuse -of ids, since it uses Posix thread ids directly. -</p> - -<p> -It is important to be clear on this point, since it the reuse of thread -ids often requires extra care in client code, which would not be -necessary if thread ids were unique across all time. For example, a -hash table indexed by thread id may have to be careful not to associate -data values from an old thread with a new one that happens to reuse the -id. Simply removing the old entry after joining a thread may not be -sufficient, if it creates a visible window between the join and removal -during which a new thread with the same id could have been created and -added to the table. -</p> - -<p><i>[ -post Bellevue Peter adds: -]</i></p> - - -<blockquote> -<p> -There is a real issue with <tt>thread::id</tt> reuse, but I urge the LWG to -reconsider fixing this by disallowing reuse, rather than explicitly allowing -it. Dealing with thread id reuse is an incredibly painful exercise that -would just force the world to reimplement a non-conflicting <tt>thread::id</tt> over -and over. -</p> -<p> -In addition, it would be nice if a <tt>thread::id</tt> could be manipulated -atomically in a lock-free manner, as motivated by the recursive lock -example: -</p> - -<p> -<a href="http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html">http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html</a> -</p> -</blockquote> - - - -<p><b>Proposed resolution:</b></p> -<p> -Add a sentence to 30.2.1.1 [thread.thread.id]/p1: -</p> - -<blockquote> -<p> -An object of type <code>thread::id</code> provides -a unique identifier for each thread of execution -and a single distinct value for all thread objects -that do not represent a thread of execution ([thread.threads.class]). -Each thread of execution has a <code>thread::id</code> -that is not equal to the <code>thread::id</code> -of other threads of execution -and that is not equal to -the <code>thread::id</code> of <code>std::thread</code> objects -that do not represent threads of execution. -<ins>The library may reuse the value of a <code>thread::id</code> of a -terminated thread that can no longer be joined.</ins> -</p> -</blockquote> - - - - - -<hr> <h3><a name="785"></a>785. Random Number Requirements in TR1</h3> <p><b>Section:</b> TR1 5.1.4.5 [tr.rand.eng.disc], TR1 5.1.4.6 [tr.rand.eng.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> John Maddock <b>Date:</b> 2008-01-15</p> @@ -15351,131 +12319,10 @@ functions appears to be an oversight. <hr> -<h3><a name="786"></a>786. Thread library timed waits, UTC and monotonic clocks</h3> -<p><b>Section:</b> X [datetime.system] <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, Jeff Garland <b>Date:</b> 2008-02-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> -The draft C++0x thread library requires that the time points of type -<tt>system_time</tt> and returned by <tt>get_system_time()</tt> represent Coordinated -Universal Time (UTC) (section X [datetime.system]). This can lead to -surprising behavior when a library user performs a duration-based wait, -such as <tt>condition_variable::timed_wait()</tt>. A complete explanation of the -problem may be found in the -<a href="http://www.opengroup.org/onlinepubs/009695399/xrat/xsh_chap02.html#tag_03_02_08_19">Rationale for the Monotonic Clock</a> -section in POSIX, but in summary: -</p> - -<ul> -<li> -Operations such as <tt>condition_variable::timed_wait()</tt> (and its POSIX -equivalent, <tt>pthread_cond_timedwait()</tt>) are specified using absolute times -to address the problem of spurious wakeups. -</li> - -<li> -The typical use of the timed wait operations is to perform a relative -wait. This may be achieved by first calculating an absolute time as the -sum of the current time and the desired duration. In fact, the C++0x -thread library includes duration-based overloads of -<tt>condition_variable::timed_wait()</tt> that behave as if by calling the -corresponding absolute time overload with a time point value of -<tt>get_system_time() + rel_time</tt>. -</li> - -<li> -A UTC clock may be affected by changes to the system time, such as -synchronization with an external source, leap seconds, or manual changes -to the clock. -</li> - -<li> -Should the clock change during a timed wait operation, the actual -duration of the wait will not be the expected length. For example, a -user may intend a timed wait of one second duration but, due to an -adjustment of the system clock backwards by a minute, the wait instead -takes 61 seconds. -</li> -</ul> - -<p> -POSIX solves the problem by introducing a new monotonic clock, which is -unaffected by changes to the system time. When a condition variable is -initialized, the user may specify whether the monotonic clock is to be -used. (It is worth noting that on POSIX systems it is not possible to -use <tt>condition_variable::native_handle()</tt> to access this facility, since -the desired clock type must be specified during construction of the -condition variable object.) -</p> - -<p> -In the context of the C++0x thread library, there are added dimensions -to the problem due to the need to support platforms other than POSIX: -</p> - -<ul> -<li> -Some environments (such as embedded systems) do not have a UTC clock, but do have a monotonic clock. -</li> - -<li> -Some environments do not have a monotonic clock, but do have a UTC clock. -</li> - -<li> -The Microsoft Windows API's synchronization functions use relative -timeouts based on an implied monotonic clock. A program that switches -from the Windows API to the C++0x thread library will now find itself -susceptible to clock changes. -</li> -</ul> - -<p> -One possible minimal solution: -</p> - -<ul> -<li> -Strike normative references to UTC and an epoch based on 1970-01-01. -</li> - -<li> -Make the semantics of <tt>system_time</tt> and <tt>get_system_time()</tt> -implementation-defined (i.e standard library implementors may choose the -appropriate underlying clock based on the capabilities of the target -platform). -</li> - -<li> -Add a non-normative note encouraging use of a monotonic clock. -</li> - -<li> -Remove <tt>system_time::seconds_since_epoch()</tt>. -</li> - -<li> -Change the constructor <tt>explicit system_time(time_t secs, nanoseconds ns -= 0)</tt> to <tt>explicit system_time(nanoseconds ns)</tt>. -</li> -</ul> - - - -<p><b>Proposed resolution:</b></p> -<p> -</p> - - - - - -<hr> <h3><a name="787"></a>787. complexity of <tt>binary_search</tt></h3> -<p><b>Section:</b> 25.3.3.4 [binary.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 25.3.3.4 [binary.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-09-08</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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> In 25.3.3.4 [binary.search]/3 the complexity of <tt>binary_search</tt> is described as @@ -15499,6 +12346,18 @@ be brought in-line with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg to <tt>+ O(1)</tt>. </p> +<p><i>[ +Sophia Antipolis: +]</i></p> + + +<blockquote> +Alisdair prefers to apply an upper bound instead of O(1), but that would +require fixing for <tt>lower_bound</tt>, <tt>upper_bound</tt> etc. as well. If he really +cares about it, he'll send an issue to Howard. +</blockquote> + + <p><b>Proposed resolution:</b></p> <p> @@ -15590,14 +12449,24 @@ is used a new value is read. <hr> -<h3><a name="789"></a>789. <tt>xor_combine_engine(result_type)</tt> should be explicit</h3> -<p><b>Section:</b> 26.4.4.4 [rand.adapt.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> +<h3><a name="793"></a>793. <tt>discrete_distribution</tt> missing constructor</h3> +<p><b>Section:</b> 26.4.8.5.1 [rand.dist.samp.discrete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.adapt.xor">issues</a> in [rand.adapt.xor].</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>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.discrete">active issues</a> in [rand.dist.samp.discrete].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.discrete">issues</a> in [rand.dist.samp.discrete].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> <p><b>Discussion:</b></p> <p> -<tt>xor_combine_engine(result_type)</tt> should be <tt>explicit</tt>. (Obvious oversight.) +<tt>discrete_distribution</tt> should have a constructor like: +</p> + +<blockquote><pre>template<class _Fn> + discrete_distribution(result_type _Count, double _Low, double _High, + _Fn& _Func); +</pre></blockquote> + +<p> +(Makes it easier to fill a histogram with function values over a range.) </p> <p><i>[ @@ -15606,88 +12475,139 @@ Bellevue: <blockquote> -Non-controversial. Bill is right, but Fermilab believes that this is -easy to use badly and hard to use right, and so it should be removed -entirely. Got into TR1 by well defined route, do we have permission to -remove stuff? Should probably check with Jens, as it is believed he is -the originator. Broad consensus that this is not a robust engine -adapter. +How do you specify the function so that it does not return negative +values? If you do it is a bad construction. This requirement is already +there. Where in each bin does one evaluate the function? In the middle. +Need to revisit tomorrow. </blockquote> +<p><i>[ +Sophia Antipolis: +]</i></p> -<p><b>Proposed resolution:</b></p> + +<blockquote> <p> -Remove xor_combine_engine from synopsis of 26.4.2 [rand.synopsis]. +Bill is not requesting this. </p> <p> -Remove 26.4.4.4 [rand.adapt.xor] <tt>xor_combine_engine</tt>. +Marc Paterno: <tt>_Fn</tt> cannot return negative values at the points where the +function is sampled. It is sampled in the middle of each bin. <tt>_Fn</tt> cannot +return 0 everywhere it is sampled. </p> - - - - - -<hr> -<h3><a name="792"></a>792. <tt>piecewise_constant_distribution</tt> is undefined for a range with just one endpoint</h3> -<p><b>Section:</b> 26.4.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.pconst">active issues</a> in [rand.dist.samp.pconst].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> <p> -<tt>piecewise_constant_distribution</tt> is undefined for a range with just one -endpoint. (Probably should be the same as an empty range.) +Jens: lambda expressions are rvalues +</p> +<p> +Add a library issue to provide an +<tt>initializer_list<double></tt> constructor for +<tt>discrete_distribution</tt>. +</p> +<p> +Marc Paterno: dislikes reference for <tt>_Fn</tt> parameter. Make it pass-by-value (to use lambda), +use <tt>std::ref</tt> to wrap giant-state function objects. </p> - - -<p><b>Proposed resolution:</b></p> <p> -Change 26.4.8.5.2 [rand.dist.samp.pconst] paragraph 3b: +Daniel: See <tt>random_shuffle</tt>, pass-by-rvalue-reference. </p> +<p> +Daniel to draft wording. +</p> +</blockquote> + +<p><i>[ +Pre San Francisco, Daniel provided wording: +]</i></p> + <blockquote> -b) If <tt>firstB == lastB</tt> <ins>or the sequence <tt>w</tt> has the length zero</ins>, +The here proposed changes of the WP refer to the current state of +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>. +During the Sophia Antipolis meeting two different proposals came up +regarding the functor argument type, either by value or by rvalue-reference. +For consistence with existing conventions (state-free algorithms and the +<tt>general_pdf_distribution</tt> c'tor signature) the author decided to propose a +function argument that is provided by value. If severe concerns exists that +stateful functions would be of dominant relevance, it should be possible to +replace the two occurrences of <tt>Func</tt> by <tt>Func&&</tt> in this proposal as part +of an editorial process. </blockquote> +<p><b>Proposed resolution:</b></p> +<ol> +<li> +<p> +In 26.4.8.5.1 [rand.dist.samp.discrete]/1, class <tt>discrete_distribution</tt>, just +<em>before</em> the member declaration +</p> +<blockquote><pre>explicit discrete_distribution(const param_type& parm); +</pre></blockquote> -<hr> -<h3><a name="793"></a>793. <tt>discrete_distribution</tt> missing constructor</h3> -<p><b>Section:</b> 26.4.8.5.1 [rand.dist.samp.discrete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> - <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.discrete">issues</a> in [rand.dist.samp.discrete].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> -<p><b>Discussion:</b></p> <p> -<tt>discrete_distribution</tt> should have a constructor like: +insert: </p> -<blockquote><pre>template<class _Fn> - discrete_distribution(result_type _Count, double _Low, double _High, - _Fn& _Func); + +<blockquote><pre>template<typename Func> +discrete_distribution(result_type nf, double xmin, double xmax, Func fw); </pre></blockquote> +</li> +<li> <p> -(Makes it easier to fill a histogram with function vaues over a range.) +Between p.4 and p.5 insert a series of new paragraphs as part of the +new member description:: </p> +<blockquote><pre>template<typename Func> +discrete_distribution(result_type nf, double xmin, double xmax, Func fw); +</pre> -<p><i>[ -Bellevue: -]</i></p> +<p> +<i>Complexity:</i> Exactly nf invocations of fw. +</p> +<p> +<i>Requires:</i> +</p> +<ol type="a"> +<li> +fw shall be callable with one argument of type double, and shall +return values of a type convertible to double;</li> +<li>If nf > 0, the relation <tt><i>x</i><sub><i>min</i></sub></tt> < <tt><i>x</i><sub><i>max</i></sub></tt> shall hold, and for all sample values +<tt><i>x</i><sub><i>k</i></sub></tt>, fw(<tt><i>x</i><sub><i>k</i></sub></tt>) shall return a weight value <tt><i>w</i><sub><i>k</i></sub></tt> that is non-negative, non-NaN, +and non-infinity;</li> -<blockquote> -How do you specify the function so that it does not return negative -values? If you do it is a bad construction. This requirement is already -there. Where in each bin does one evaluate the function? In the middle. -Need to revisit tomorrow. -</blockquote> +<li>The following relations shall hold: nf ≥ 0, and 0 < S = <tt><i>w</i><sub><i>0</i></sub></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.</li> +</ol> -<p><b>Proposed resolution:</b></p> +<p> +<i>Effects:</i> +</p> +<ol type="a"> +<li>If nf == 0, sets n = 1 and lets the sequence w have length n = 1 and + consist of the single value <tt><i>w</i><sub><i>0</i></sub></tt> = 1.</li> + +<li> +<p>Otherwise, sets n = nf, deltax = (<tt><i>x</i><sub><i>max</i></sub></tt> - <tt><i>x</i><sub><i>min</i></sub></tt>)/n and <tt><i>x</i><sub><i>cent</i></sub></tt> = <tt><i>x</i><sub><i>min</i></sub></tt> + +0.5 * deltax.</p> +<blockquote><pre>For each k = 0, . . . ,n-1, calculates: + <tt><i>x</i><sub><i>k</i></sub></tt> = <tt><i>x</i><sub><i>cent</i></sub></tt> + k * deltax + <tt><i>w</i><sub><i>k</i></sub></tt> = fw(<tt><i>x</i><sub><i>k</i></sub></tt>) +</pre></blockquote> +</li> +<li> +<p>Constructs a discrete_distribution object with probabilities:</p> +<blockquote><pre><tt><i>p</i><sub><i>k</i></sub></tt> = <tt><i>w</i><sub><i>k</i></sub></tt>/S for k = 0, . . . , n-1. +</pre></blockquote> +</li> +</ol> +</blockquote> +</li> +</ol> @@ -15695,11 +12615,11 @@ Need to revisit tomorrow. <hr> <h3><a name="794"></a>794. <tt>piecewise_constant_distribution</tt> missing constructor</h3> -<p><b>Section:</b> 26.4.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 26.4.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.pconst">active issues</a> in [rand.dist.samp.pconst].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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> <tt>piecewise_constant_distribution</tt> should have a constructor like: @@ -15711,100 +12631,149 @@ Need to revisit tomorrow. </pre></blockquote> <p> -(Makes it easier to fill a histogram with function vaues over a range. +(Makes it easier to fill a histogram with function values over a range. The two (reference <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>) make a sensible replacement for <tt>general_pdf_distribution</tt>.) </p> +<p><i>[ +Sophia Antipolis: +]</i></p> -<p><b>Proposed resolution:</b></p> +<blockquote> +<p> +Marc: uses variable width of bins and weight for each bin. This is not +giving enough flexibility to control both variables. +</p> +<p> +Add a library issue to provide an constructor taking an +<tt>initializer_list<double></tt> and <tt>_Fn</tt> for <tt>piecewise_constant_distribution</tt>. +</p> +<p> +Daniel to draft wording. +</p> +</blockquote> +<p><i>[ +Pre San Francisco, Daniel provided wording. +]</i></p> +<blockquote> +The here proposed changes of the WP refer to the current state of +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>. +For reasons explained in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>, the author decided to propose a function +argument that is provided by value. The issue proposes a c'tor signature, +that does not take advantage of the full flexibility of +<tt>piecewise_constant_distribution</tt>, +because it restricts on a constant bin width, but the use-case seems to +be popular enough to justify it's introduction. +</blockquote> -<hr> -<h3><a name="798"></a>798. Refactoring of binders lead to interface breakage</h3> -<p><b>Section:</b> D.8 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-02-14</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.lib.binders">issues</a> in [depr.lib.binders].</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/2008/n2521.pdf">N2521</a> -and its earlier predecessors have moved the old binders from -[lib.binders] to D.8 [depr.lib.binders] thereby introducing some renaming -of the template parameter names (<tt>Operation -> Fn</tt>). During this -renaming process the <em>protected</em> data member <tt>op</tt> was also renamed to -<tt>fn</tt>, which seems as an unnecessary interface breakage to me - even if -this user access point is probably rarely used. -</p> <p><b>Proposed resolution:</b></p> -<p> -Change D.8.1 [depr.lib.binder.1st]: -</p> -<blockquote> -<pre>template <class Fn> -class binder1st - : public unary_function<typename Fn::second_argument_type, - typename Fn::result_type> { -protected: - Fn <del>fn</del> <ins>op</ins>; - typename Fn::first_argument_type value; -public: - binder1st(const Fn& x, - const typename Fn::first_argument_type& y); - typename Fn::result_type - operator()(const typename Fn::second_argument_type& x) const; - typename Fn::result_type - operator()(typename Fn::second_argument_type& x) const; -}; -</pre> - -<blockquote> +<ol> +<li> <p> --1- The constructor initializes <del><tt>fn</tt></del> <ins><tt>op</tt></ins> with <tt>x</tt> and <tt>value</tt> with <tt>y</tt>. +In 26.4.8.5.2 [rand.dist.samp.pconst]/1, class <tt>piecewise_constant_distribution</tt>, +just <em>before</em> the member declaration </p> + +<blockquote><pre>explicit piecewise_constant_distribution(const param_type& parm); +</pre></blockquote> <p> --2- <tt>operator()</tt> returns <tt><del>fn</del><ins>op</ins>(value,x)</tt>. +insert: </p> -</blockquote> -</blockquote> +<blockquote><pre>template<typename Func> +piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw); +</pre></blockquote> +</li> +<li> <p> -Change D.8.3 [depr.lib.binder.2nd]: +Between p.4 and p.5 insert a new sequence of paragraphs nominated +below as [p5_1], [p5_2], +[p5_3], and [p5_4] as part of the new member description: </p> -<blockquote> -<pre>template <class Fn> -class binder2nd - : public unary_function<typename Fn::first_argument_type, - typename Fn::result_type> { -protected: - Fn <del>fn</del> <ins>op</ins>; - typename Fn::second_argument_type value; -public: - binder2nd(const Fn& x, - const typename Fn::second_argument_type& y); - typename Fn::result_type - operator()(const typename Fn::first_argument_type& x) const; - typename Fn::result_type - operator()(typename Fn::first_argument_type& x) const; -}; +<blockquote><pre>template<typename Func> +piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw); </pre> - <blockquote> <p> --1- The constructor initializes <del><tt>fn</tt></del> <ins><tt>op</tt></ins> with <tt>x</tt> and <tt>value</tt> with <tt>y</tt>. +[p5_1] <i>Complexity:</i> Exactly <tt>nf</tt> invocations of <tt>fw</tt>. +</p> +<p> +[p5_2] <i>Requires:</i> +</p> +<ol type="a"> +<li><tt>fw</tt> shall be callable with one argument of type <tt>RealType</tt>, and shall +return values of a type convertible to double; +</li> +<li> +For all sample values <tt><i>x<sub>k</sub></i></tt> defined below, fw(<tt><i>x<sub>k</sub></i></tt>) shall return a weight +value <tt><i>w<sub>k</sub></i></tt> that is non-negative, non-NaN, and non-infinity; +</li> +<li> +The following relations shall hold: <tt><i>x<sub>min</sub></i></tt> < <tt><i>x<sub>max</sub></i></tt>, and +0 < S = <tt><i>w<sub>0</sub></i></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>. +</li> +</ol> +<p> +[p5_3] <i>Effects:</i> </p> +<ol type="a"> +<li> +<p>If nf == 0,</p> + <ol type="a"> + <li> +sets deltax = <tt><i>x<sub>max</sub></i></tt> - <tt><i>x<sub>min</sub></i></tt>, and</li> +<li> lets the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist of the single + value <tt><i>w<sub>0</sub></i></tt> = 1, and</li> +<li> lets the sequence <tt>b</tt> have length <tt>n+1</tt> with <tt><i>b<sub>0</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> and + <tt><i>b<sub>1</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt> +</li> +</ol> +</li> +<li> +<p>Otherwise,</p> +<ol type="a"> +<li> sets <tt>n = nf</tt>, <tt>deltax = </tt>(<tt><i>x<sub>max</sub></i></tt> - <tt><i>x<sub>min</sub></i></tt>)/n, + <tt><i>x<sub>cent</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> + 0.5 * deltax, and +</li> +<li><p>lets the sequences <tt>w</tt> and <tt>b</tt> have length <tt>n</tt> and <tt>n+1</tt>, resp. and</p> +<blockquote><pre>for each k = 0, . . . ,n-1, calculates: + <tt><i>dx<sub>k</sub></i></tt> = k * deltax + <tt><i>b<sub>k</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> + <tt><i>dx<sub>k</sub></i></tt> + <tt><i>x<sub>k</sub></i></tt> = <tt><i>x<sub>cent</sub></i></tt> + <tt><i>dx<sub>k</sub></i></tt> + <tt><i>w<sub>k</sub></i></tt> = fw(<tt><i>x<sub>k</sub></i></tt>), +</pre></blockquote> +<p> and</p> +</li> +<li> sets <tt><i>b<sub>n</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt></li> +</ol> +</li> +<li> <p> --2- <tt>operator()</tt> returns <tt><del>fn</del><ins>op</ins>(value,x)</tt>. +Constructs a <tt>piecewise_constant_distribution</tt> object with +the above computed sequence <tt>b</tt> as the interval boundaries +and with the probability densities: </p> +<blockquote><pre><tt><i>ρ<sub>k</sub></i></tt> = <tt><i>w<sub>k</sub></i></tt>/(S * deltax) for k = 0, . . . , n-1. +</pre></blockquote> +</li> +</ol> +<p> +[p5_4] <i>Remarks:</i> In this context, the subintervals [<tt><i>b<sub>k</sub></i></tt>, <tt><i>b<sub>k+1</sub></i></tt>) are commonly + known as the <i>bins</i> of a histogram. + </p> </blockquote> </blockquote> +</li> +</ol> @@ -15894,7 +12863,7 @@ algorithm: <hr> <h3><a name="801"></a>801. <tt>tuple</tt> and <tt>pair</tt> trivial members</h3> -<p><b>Section:</b> 20.3 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> +<p><b>Section:</b> 20.4 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-02-18</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple">active issues</a> in [tuple].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple">issues</a> in [tuple].</p> @@ -16001,11 +12970,11 @@ tabled until Alisdair's proposals are disposed of. <hr> <h3><a name="803"></a>803. Simplification of <tt>seed_seq::seq_seq</tt></h3> -<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> +<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Charles Karney <b>Date:</b> 2008-02-22</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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> <tt>seed_seq(InputIterator begin, InputIterator end);</tt> constructs a <tt>seed_seq</tt> @@ -16156,7 +13125,7 @@ seed_seq q(s, s+4); </ul> <p> -Note: this proposal renders moot issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#782">782</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>. +Note: this proposal renders moot issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>. </p> <p><i>[ @@ -16168,6 +13137,35 @@ Bellevue: Walter needs to ask Fermilab for guidance. Defer till tomorrow. Bill likes the proposed resolution. </blockquote> +<p><i>[ +Sophia Antipolis: +]</i></p> + + +<blockquote> +<p> +Marc Paterno wants portable behavior between 32bit and 64bit machines; +we've gone to significant trouble to support portability of engines and +their values. +</p> +<p> +Jens: the new algorithm looks perfectly portable +</p> +<p> +Marc Paterno to review off-line. +</p> +<p> +Modify the proposed resolution to read "Constructs a seed_seq object by the following algorithm ..." +</p> +<p> +Disposition: move to review; unanimous consent. +</p> +<p> +(moots <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>) +</p> +</blockquote> + + <p><b>Proposed resolution:</b></p> <p> @@ -16185,7 +13183,7 @@ Change 26.4.7.1 [rand.util.seedseq]: such that <tt>iterator_traits<InputIterator>::value_type</tt> shall denote an integral type. </p> <p> --6- Constructs a <tt>seed_seq</tt> object by <del>rearranging some or all of the bits of the supplied sequence +-6- Constructs a <tt>seed_seq</tt> object by <ins>the following algorithm</ins> <del>rearranging some or all of the bits of the supplied sequence <tt>[begin,end)</tt> of w-bit quantities into 32-bit units, as if by the following: </del> </p> <p> @@ -16219,11 +13217,11 @@ for (InputIterator s = begin; s != end; ++s) <hr> <h3><a name="804"></a>804. Some problems with classes <tt>error_code</tt>/<tt>error_condition</tt></h3> -<p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-02-24</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#syserr">active issues</a> in [syserr].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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> <ol type="A"> <li> @@ -16274,49 +13272,52 @@ conditions (see related issue <a href="http://www.open-std.org/jtc1/sc22/wg21/do </li> </ol> +<p><i>[ +Sophia Antipolis: +]</i></p> -<p><b>Proposed resolution:</b></p> -<p> -In 19.4.1.2 [syserr.errcat.virtuals], remove the throws clause p. 10. -</p> - -<blockquote> -<pre>virtual string message(int ev) const = 0; -</pre> <blockquote> <p> -<i>Returns:</i> A string that describes the error condition denoted by <tt>ev</tt>. +Part A: NAD (editorial), cleared by the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>. </p> <p> -<del><i>Throws:</i> Nothing.</del> +Part B: Technically correct, save for typo. Rendered moot by the concept proposal +(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2620.html">N2620</a>) NAD (editorial). +</p> +<p> +Part C: We agree; this is consistent with the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>. +</p> +<p> +Howard: please ping Beman, asking him to clear away parts A and B from +the wording in the proposed resolution, so it is clear to the editor +what needs to be applied to the working paper. +</p> +<p> +Beman provided updated wording. Since issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a> is not going +forward, the provided wording includes resolution of part A. </p> -</blockquote> </blockquote> + + +<p><b>Proposed resolution:</b></p> + <p> -In 19.4.2.1 [syserr.errcode.overview]/1, class <tt>error_code</tt> synopsis, modifiers section, -replace the current <tt>operator=</tt> overload by the following: +Resolution of part A: </p> - <blockquote> -<pre>template <class ErrorCodeEnum> - typename enable_if<is_error_code_enum<ErrorCodeEnum>::value<ins>, error_code</ins>>::type& - operator=(ErrorCodeEnum e); -</pre> -</blockquote> - <p> -In the private section of the same class replace the current -data member <tt>cat_</tt> definition by: +Change 19.4.2.1 [syserr.errcode.overview] Class error_code overview synopsis as indicated: </p> -<blockquote> -const error_category<del>&</del><ins>*</ins> cat_; // exposition only -</blockquote> +<blockquote><pre>private: + int val_; // exposition only + const error_category<del>&</del><ins>*</ins> cat_; // exposition only +</pre></blockquote> <p> -In 19.4.2.2 [syserr.errcode.constructors], change p. 2 to read: +Change 19.4.2.2 [syserr.errcode.constructors] Class error_code constructors as indicated: </p> <blockquote> @@ -16324,31 +13325,32 @@ In 19.4.2.2 [syserr.errcode.constructors], change p. 2 to read: </pre> <blockquote> <p> -</p><p>...</p> - +<i>Effects:</i> Constructs an object of type <tt>error_code</tt>. +</p> <p> <i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&</ins>system_category</tt>. </p> -</blockquote> -</blockquote> - <p> -Change 19.4.2.2 [syserr.errcode.constructors] p. 5 to read: +<i>Throws:</i> Nothing. </p> - -<blockquote> +</blockquote> <pre>error_code(int val, const error_category& cat); </pre> <blockquote> -<p>...</p> +<p> +<i>Effects:</i> Constructs an object of type <tt>error_code</tt>. +</p> <p> <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&</ins>cat</tt>. </p> +<p> +<i>Throws:</i> Nothing. +</p> </blockquote> </blockquote> <p> -In 19.4.2.3 [syserr.errcode.modifiers], change p. 1 to read: +Change 19.4.2.3 [syserr.errcode.modifiers] Class error_code modifiers as indicated: </p> <blockquote> @@ -16356,161 +13358,148 @@ In 19.4.2.3 [syserr.errcode.modifiers], change p. 1 to read: </pre> <blockquote> <p> -</p><p>...</p> - -<p> <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&</ins>cat</tt>. </p> -</blockquote> -</blockquote> - <p> -In 19.4.2.3 [syserr.errcode.modifiers], change the <tt>operator=</tt> signature to read: +<i>Throws:</i> Nothing. </p> - -<blockquote> -<pre>template <class ErrorCodeEnum> - typename enable_if<is_error_code_enum<ErrorCodeEnum>::value<ins>, error_code</ins>>::type& - operator=(ErrorCodeEnum e); -</pre> +</blockquote> </blockquote> <p> -In 19.4.2.4 [syserr.errcode.observers], change p. 3 to read: +Change 19.4.2.4 [syserr.errcode.observers] Class error_code observers as indicated: </p> <blockquote> -<pre>const error_category& category() const; -</pre> +const error_category& category() const; <blockquote> <p> -</p><p>...</p> - -<p> <i>Returns:</i> <tt><ins>*</ins>cat_</tt>. </p> +<p> +<i>Throws:</i> Nothing. +</p> </blockquote> </blockquote> <p> -In 19.4.2.4 [syserr.errcode.observers], remove the throws clause p. 8. +Change 19.4.3.1 [syserr.errcondition.overview] Class error_condition overview synopsis as indicated: </p> -<blockquote> -<pre>string message() const; -</pre> -<blockquote> -<p> -</p><p>...</p> +<blockquote><pre>private: + int val_; // exposition only + const error_category<del>&</del><ins>*</ins> cat_; // exposition only +</pre></blockquote> <p> -<del><i>Throws:</i> Nothing.</del> +Change 19.4.3.2 [syserr.errcondition.constructors] Class error_condition constructors as indicated: </p> -</blockquote> -</blockquote> +<p><i>[ +(If the proposed resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a> has already been applied, the +name <tt>posix_category</tt> will have been changed to <tt>generic_category</tt>. That has +no effect on this resolution.) +]</i></p> -<p> -In 19.4.3.1 [syserr.errcondition.overview]/1, class <tt>error_condition</tt> -synopsis, constructors section, replace the template constructor -overload declaration by one with an added "::value" -</p> <blockquote> -<pre>template <class ErrorConditionEnum> - error_condition(ErrorConditionEnum e, - typename enable_if<is_error_condition_enum<ErrorConditionEnum><ins>::value</ins>>::type* = 0); +<pre>error_condition(); </pre> -</blockquote> - +<blockquote> <p> -In 19.4.3.1 [syserr.errcondition.overview]/1, class <tt>error_condition</tt> synopsis, -modifiers section, -replace the <tt>operator=</tt> overload declaration by: +<i>Effects:</i> Constructs an object of type <tt>error_condition</tt>. </p> - -<blockquote> -<pre>template<typename ErrorConditionEnum> - typename enable_if<is_error_condition_enum<ErrorConditionEnum><ins>::value</ins>, <del>error_code</del> <ins>error_condition</ins>>::type & - operator=( ErrorConditionEnum e ); -</pre> -</blockquote> - <p> -In the private section of the same class replace the current -data member <tt>cat_</tt> definition by: +<i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&</ins>posix_category</tt>. </p> - -<blockquote><pre>const error_category<del>&</del><ins>*</ins> cat_; // exposition only -</pre></blockquote> - <p> -In 19.4.3.2 [syserr.errcondition.constructors], change p. 2 to read: +<i>Throws:</i> Nothing. </p> - -<blockquote> -<pre>error_condition(); +</blockquote> +<pre>error_condition(int val, const error_category& cat); </pre> <blockquote> <p> -</p><p>...</p> - +<i>Effects:</i> Constructs an object of type <tt>error_condition</tt>. +</p> <p> -<i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&</ins>posix_category</tt>. +<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&</ins>cat</tt>. +</p> +<p> +<i>Throws:</i> Nothing. </p> </blockquote> </blockquote> <p> -In the same section, change p. 5 to read: +Change 19.4.3.3 [syserr.errcondition.modifiers] Class error_condition modifiers as indicated: </p> <blockquote> -<pre>error_condition(int val, const error_category& cat); -</pre> +void assign(int val, const error_category& cat); <blockquote> <p> -</p><p>...</p> - -<p> <i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&</ins>cat</tt>. </p> +<p> +<i>Throws:</i> Nothing. +</p> </blockquote> </blockquote> <p> -In 19.4.3.3 [syserr.errcondition.modifiers], change p. 1 to read: +Change 19.4.3.4 [syserr.errcondition.observers] Class error_condition observers as indicated: </p> <blockquote> -<pre>void assign(int val, const error_category& cat); -</pre> +const error_category& category() const; <blockquote> <p> -<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&</ins>cat</tt>. +<i>Returns:</i> <tt><ins>*</ins>cat_</tt>. </p> +<p> +<i>Throws:</i> Nothing. +</p> +</blockquote> </blockquote> </blockquote> <p> -In the same section replace the current <tt>operator=</tt> overload declaration by: +Resolution of part C: </p> <blockquote> -<pre>template <class ErrorConditionEnum> - typename enable_if<is_error_condition_enum<ErrorConditionEnum>::value<ins>, error_condition</ins>>::type& - operator=(ErrorConditionEnum e); -</pre></blockquote> <p> -In 19.4.3.4 [syserr.errcondition.observers], change p. 3 to read: +In 19.4.1.2 [syserr.errcat.virtuals], remove the throws clause p. 10. +</p> + +<blockquote> +<pre>virtual string message(int ev) const = 0; +</pre> + +<blockquote> +<p> +<i>Returns:</i> A string that describes the error condition denoted by <tt>ev</tt>. +</p> +<p> +<del><i>Throws:</i> Nothing.</del> +</p> +</blockquote> +</blockquote> + +<p> +In 19.4.2.4 [syserr.errcode.observers], remove the throws clause p. 8. </p> <blockquote> -<pre>const error_category& category() const; +<pre>string message() const; </pre> <blockquote> <p> -<i>Returns:</i> <tt><ins>*</ins>cat_</tt>. +<i>Returns:</i> <tt>category().message(value())</tt>. +</p> +<p> +<del><i>Throws:</i> Nothing.</del> </p> </blockquote> </blockquote> @@ -16524,14 +13513,15 @@ In 19.4.3.4 [syserr.errcondition.observers], remove the throws clause p. 6. </pre> <blockquote> <p> -</p><p>...</p> - +<i>Returns:</i> <tt>category().message(value())</tt>. +</p> <p> <del><i>Throws:</i> Nothing.</del> </p> </blockquote> </blockquote> +</blockquote> @@ -16540,11 +13530,11 @@ In 19.4.3.4 [syserr.errcondition.observers], remove the throws clause p. 6. <hr> <h3><a name="805"></a>805. <tt>posix_error::posix_errno</tt> concerns</h3> -<p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-02-24</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#syserr">active issues</a> in [syserr].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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> 19.4 [syserr] @@ -16793,9 +13783,9 @@ intuitive. There are no uses of <tt>errc</tt> in the current C++ standard. <hr> <h3><a name="806"></a>806. <tt>unique_ptr::reset</tt> effects incorrect, too permissive</h3> -<p><b>Section:</b> 20.6.11.2.5 [unique.ptr.single.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> 20.7.11.2.5 [unique.ptr.single.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-03-13</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> <p><b>Discussion:</b></p> <p> <tt>void unique_ptr::reset(T* p = 0)</tt> is currently specified as: @@ -16845,7 +13835,7 @@ scenario, as it definitely doesn't when <tt>p</tt> and <tt>q</tt> are separate. <p><b>Proposed resolution:</b></p> <p> -Change 20.6.11.2.5 [unique.ptr.single.modifiers]: +Change 20.7.11.2.5 [unique.ptr.single.modifiers]: </p> <blockquote> @@ -16857,7 +13847,7 @@ Change 20.6.11.2.5 [unique.ptr.single.modifiers]: </blockquote> <p> -Change 20.6.11.3.3 [unique.ptr.runtime.modifiers]: +Change 20.7.11.3.3 [unique.ptr.runtime.modifiers]: </p> <blockquote> @@ -16878,9 +13868,9 @@ Change 20.6.11.3.3 [unique.ptr.runtime.modifiers]: <hr> <h3><a name="807"></a>807. <tt>tuple</tt> construction should not fail unless its element's construction fails</h3> -<p><b>Section:</b> 20.3.1.2 [tuple.cnstr] <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.4.1.2 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-03-13</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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/lwg-defects.html#527">527</a> Added a throws clause to <tt>bind</tt> constructors. I believe the same throws clause @@ -16890,7 +13880,7 @@ should be added to <tt>tuple</tt> except it ought to take into account move cons <p><b>Proposed resolution:</b></p> <p> -Add to 20.3.1.2 [tuple.cnstr]: +Add to 20.4.1.2 [tuple.cnstr]: </p> <blockquote> @@ -16906,11 +13896,11 @@ or assignment of one of the types in <tt>Types</tt> throws an exception. <hr> <h3><a name="808"></a>808. [forward] incorrect redundant specification</h3> -<p><b>Section:</b> 20.2.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 20.2.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-03-13</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forward">active issues</a> in [forward].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward">issues</a> in [forward].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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> p4 (forward) says: @@ -16987,10 +13977,10 @@ In both cases, <tt>A2</tt> is deduced as double, so 1.414 is forwarded to <tt>A< <hr> <h3><a name="809"></a>809. std::swap should be overloaded for array types</h3> -<p><b>Section:</b> 25.2.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 25.2.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Niels Dekker <b>Date:</b> 2008-02-28</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.swap">issues</a> in [alg.swap].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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> For the sake of generic programming, the header <code><algorithm></code> should provide an @@ -17277,14 +14267,14 @@ Thread-Safety in the Standard Library (Rev 1). <hr> <h3><a name="813"></a>813. "empty" undefined for <tt>shared_ptr</tt></h3> -<p><b>Section:</b> 20.6.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 20.7.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 2008-02-26</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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> -Several places in 20.6.12.2 [util.smartptr.shared] refer to an "empty" <tt>shared_ptr</tt>. +Several places in 20.7.12.2 [util.smartptr.shared] refer to an "empty" <tt>shared_ptr</tt>. However, that term is nowhere defined. The closest thing we have to a definition is that the default constructor creates an empty <tt>shared_ptr</tt> and that a copy of a default-constructed <tt>shared_ptr</tt> is empty. Are any @@ -17406,7 +14396,7 @@ Alisdair's wording is fine. <p><b>Proposed resolution:</b></p> <p> -Append the following sentance to 20.6.12.2 [util.smartptr.shared] +Append the following sentance to 20.7.12.2 [util.smartptr.shared] </p> <blockquote> The <code>shared_ptr</code> class template stores a pointer, usually obtained @@ -17444,15 +14434,27 @@ a pointer is said to be <i>empty</i>.</ins> <hr> <h3><a name="815"></a>815. <tt>std::function</tt> and <tt>reference_closure</tt> do not use perfect forwarding</h3> -<p><b>Section:</b> 20.5.15.2.4 [func.wrap.func.inv] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 20.6.15.2.4 [func.wrap.func.inv] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-16</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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> <tt>std::function</tt> and <tt>reference_closure</tt> should use "perfect forwarding" as described in the rvalue core proposal. </p> +<p><i>[ +Sophia Antipolis: +]</i></p> + + +<blockquote> +According to Doug Gregor, as far as <tt>std::function</tt> is concerned, perfect +forwarding can not be obtained because of type erasure. Not everyone +agreed with this diagnosis of forwarding. +</blockquote> + + <p><b>Proposed resolution:</b></p> <p> @@ -17464,7 +14466,7 @@ described in the rvalue core proposal. <hr> <h3><a name="816"></a>816. Should <tt>bind()</tt>'s returned functor have a nofail copy ctor when <tt>bind()</tt> is nofail?</h3> -<p><b>Section:</b> 20.5.11.1.3 [func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 20.6.11.1.3 [func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2008-02-08</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.bind.bind">active issues</a> in [func.bind.bind].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p> @@ -17510,7 +14512,7 @@ Howard adds: <hr> <h3><a name="817"></a>817. <tt>bind</tt> needs to be moved</h3> -<p><b>Section:</b> 20.5.11.1.3 [func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 20.6.11.1.3 [func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-03-17</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.bind.bind">active issues</a> in [func.bind.bind].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p> @@ -17607,7 +14609,7 @@ the other normative text. </p> <p> -Double-check 29.4.4 [atomics.types.operations] that each +Double-check 29.4 [atomics.types.operations] that each operation clearly says whether it's a load or a store operation, or both. (It could be clearer, IMO. Solution not in current proposed resolution.) </p> @@ -17618,7 +14620,7 @@ both. (It could be clearer, IMO. Solution not in current proposed resolution.) </p> <p> -And why does 29.4.4 [atomics.types.operations] p9 for "load" say: +And why does 29.4 [atomics.types.operations] p9 for "load" say: </p> @@ -17632,7 +14634,7 @@ nor <tt>memory_order_acq_rel</tt>. </p> <p> -And then: 29.4.4 [atomics.types.operations] p12: +And then: 29.4 [atomics.types.operations] p12: </p> <blockquote> @@ -17693,7 +14695,7 @@ those is already included in the happens before ordering. <i>-- end note</i>] </blockquote> <p> -Rephrase 29.4.4 [atomics.types.operations] p12 as: +Rephrase 29.4 [atomics.types.operations] p12 as: </p> <blockquote> @@ -17848,12 +14850,12 @@ infinite recursion. <i>-- end note.</i>] <hr> <h3><a name="821"></a>821. Minor cleanup : <tt>unique_ptr</tt></h3> -<p><b>Section:</b> 20.6.11.3.3 [unique.ptr.runtime.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 20.7.11.3.3 [unique.ptr.runtime.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-30</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> <p><b>Discussion:</b></p> <p> -Reading resolution of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a> I noticed the following: +Reading resolution of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> I noticed the following: </p> <blockquote> @@ -17877,7 +14879,7 @@ to be a stronger match than the deleted overload. Words... <p><b>Proposed resolution:</b></p> <p> -Add to class template definition in 20.6.11.3 [unique.ptr.runtime] +Add to class template definition in 20.7.11.3 [unique.ptr.runtime] </p> <blockquote> @@ -17891,7 +14893,7 @@ void swap(unique_ptr&& u); </blockquote> <p> -Update 20.6.11.3.3 [unique.ptr.runtime.modifiers] +Update 20.7.11.3.3 [unique.ptr.runtime.modifiers] </p> <blockquote> @@ -17912,7 +14914,7 @@ templated overload. <i>-- end note</i>]</del> </blockquote> <p><i>[ -Note this wording incorporates resolutions for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a> (New) and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a> (Ready). +Note this wording incorporates resolutions for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a> (New) and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> (Ready). ]</i></p> @@ -18002,11 +15004,11 @@ In 20.1.1 [utility.arg.requirements] change Table 34: <tt>CopyConstructible</tt> <hr> <h3><a name="823"></a>823. <tt>identity<void></tt> seems broken</h3> -<p><b>Section:</b> 20.2.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 20.2.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 2008-04-09</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forward">active issues</a> in [forward].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward">issues</a> in [forward].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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> N2588 seems to have added an <tt>operator()</tt> member function to the @@ -18020,9 +15022,50 @@ Suggested resolution: Specialize <tt>identity<void></tt> so as not to req the member function's presence. </p> +<p><i>[ +Sophia Antipolis: +]</i></p> + + +<blockquote> +<p> +Jens: suggests to add a requires clause to avoid specializing on <tt>void</tt>. +</p> +<p> +Alisdair: also consider cv-qualified <tt>void</tt>. +</p> +<p> +Alberto provided proposed wording. +</p> +</blockquote> + <p><b>Proposed resolution:</b></p> <p> +Change definition of <tt>identity</tt> in 20.2.2 [forward], paragraph 2, to: +</p> + +<blockquote><pre>template <class T> struct identity { + typedef T type; + + <ins>requires ReferentType<T></ins> + const T& operator()(const T& x) const; + }; +</pre></blockquote> +<p>...</p> +<blockquote><pre> <ins>requires ReferentType<T></ins> + const T& operator()(const T& x) const; +</pre></blockquote> + + +<p><b>Rationale:</b></p> +<p> +The point here is to able to write <tt>T&</tt> given <tt>T</tt> and <tt>ReferentType</tt> is +precisely the concept that guarantees so, according to N2677 +(Foundational concepts). Because of this, it seems preferable than an +explicit check for <tt>cv void</tt> using <tt>SameType/remove_cv</tt> as it was suggested +in Sophia. In particular, Daniel remarked that there may be types other +than <tt>cv void</tt> which aren't referent types (<tt>int[]</tt>, perhaps?). </p> @@ -18031,10 +15074,10 @@ the member function's presence. <hr> <h3><a name="824"></a>824. rvalue ref issue with <tt>basic_string</tt> inserter</h3> -<p><b>Section:</b> 21.3.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 21.3.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-04-10</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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> In the current working paper, the <tt><string></tt> header synopsis at the end of @@ -18071,20 +15114,32 @@ signatures in 21.3.8.9 [string.io] should be deleted. <p><b>Proposed resolution:</b></p> <p> +Delete the first of the two signatures in 21.3.8.9 [string.io]: </p> +<blockquote><pre><del>template<class charT, class traits, class Allocator> + basic_ostream<charT, traits>& + operator<<(basic_ostream<charT, traits>& os, + const basic_string<charT,traits,Allocator>& str);</del> + +template<class charT, class traits, class Allocator> + basic_ostream<charT, traits>& + operator<<(basic_ostream<charT, traits>&& os, + const basic_string<charT,traits,Allocator>& str); +</pre></blockquote> + <hr> <h3><a name="825"></a>825. Missing rvalues reference stream insert/extract operators?</h3> -<p><b>Section:</b> 19.4.2.1 [syserr.errcode.overview], 20.6.12.2.8 +<p><b>Section:</b> 19.4.2.1 [syserr.errcode.overview], 20.7.12.2.8 [util.smartptr.shared.io], 22.2.8 [facets.examples], 23.3.5.3 [bitset.operators], 26.3.6 [complex.ops], 27.5 [stream.buffers], 28.9 -[re.submatch] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +[re.submatch] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-04-10</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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> Should the following use rvalues references to stream in insert/extract @@ -18093,7 +15148,7 @@ operators? <ul> <li>19.4.2.1 [syserr.errcode.overview]</li> -<li>20.6.12.2.8 [util.smartptr.shared.io]</li> +<li>20.7.12.2.8 [util.smartptr.shared.io]</li> <li>22.2.8 [facets.examples]</li> <li>23.3.5.3 [bitset.operators]</li> <li>26.3.6 [complex.ops]</li> @@ -18103,55 +15158,15 @@ operators? <li>28.9 [re.submatch]</li> </ul> - -<p><b>Proposed resolution:</b></p> -<p> -</p> - - - - - -<hr> -<h3><a name="826"></a>826. Equivalent of <tt>%'d</tt>, or rather, lack thereof?</h3> -<p><b>Section:</b> 22.2.2.2 [locale.nm.put] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> - <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-04-07</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> -<p><b>Discussion:</b></p> -<p> -In the spirit of <tt>printf vs iostream</tt>... -</p> - -<p> -POSIX <tt>printf</tt> says that <tt>%'d</tt> should insert grouping characters (and the -implication is that in the absence of <tt>'</tt> no grouping characters are -inserted). The <tt>num_put</tt> facet, on the other hand, seems to always insert -grouping characters. Can this be considered a defect worth fixing for -C++0x? Maybe <tt>ios_base</tt> needs an additional flag? -</p> - <p><i>[ -Pablo Halpern: +Sophia Antipolis ]</i></p> <blockquote> -I'm not sure it constitutes a defect, but I would be in favor of adding -another flag (and corresponding manipulator). +Agree with the idea in the issue, Alisdair to provide wording. </blockquote> -<p><i>[ -Martin Sebor: -]</i></p> - - -<blockquote> -I don't know if it qualifies as a defect but I agree that there -should be an easy way to control whether the thousands separator -should or shouldn't be inserted. A new flag would be in line with -the current design of iostreams (like <tt>boolalpha</tt>, <tt>showpos</tt>, or -<tt>showbase</tt>). -</blockquote> <p><b>Proposed resolution:</b></p> @@ -18164,7 +15179,7 @@ the current design of iostreams (like <tt>boolalpha</tt>, <tt>showpos</tt>, or <hr> <h3><a name="827"></a>827. <tt>constexpr shared_ptr::shared_ptr()?</tt></h3> -<p><b>Section:</b> 20.6.12.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 20.7.12.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-04-11</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> @@ -18187,9 +15202,9 @@ unfair advantage of raw pointers. <hr> <h3><a name="828"></a>828. Static initialization for <tt>std::mutex</tt>?</h3> -<p><b>Section:</b> 30.3.1.1 [thread.mutex.class] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 30.3.1.1 [thread.mutex.class] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-04-18</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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> [Note: I'm assuming here that 3.6.2 [basic.start.init]/1 will be fixed.] @@ -18202,22 +15217,51 @@ possible, both to ease migration and to not provide incentives to (or force) people to forego the C++ primitives in favor of pthreads. </p> +<p><i>[ +Sophia Antipolis: +]</i></p> + + +<blockquote> +<p> +We believe this is implementable on POSIX, because the initializer-list +feature and the constexpr feature make this work. Double-check core +language about static initialization for this case. Ask core for a core +issue about order of destruction of statically-initialized objects wrt. +dynamically-initialized objects (should come afterwards). Check +non-POSIX systems for implementability. +</p> +<p> +If ubiquitous implementability cannot be assured, plan B is to introduce +another constructor, make this constexpr, which is +conditionally-supported. To avod ambiguities, this new constructor needs +to have an additional parameter. +</p> +</blockquote> + <p><b>Proposed resolution:</b></p> <p> +Change 30.3.1.1 [thread.mutex.class]: </p> +<blockquote><pre>class mutex { +public: + <ins>constexpr</ins> mutex(); + ... +</pre></blockquote> + <hr> <h3><a name="829"></a>829. current_exception wording unclear about exception type</h3> -<p><b>Section:</b> 18.7.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 18.7.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-04-20</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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>Consider this code:</p> @@ -18284,7 +15328,7 @@ After 18.7.5 [propagation] , paragraph 7, add the indicated text: <blockquote> <p> <i>Returns:</i> <code>exception_ptr</code> object that refers -to the currently handled exception or a copy of the currently handled +to the currently handled exception <ins>(15.3 [except.handle])</ins> or a copy of the currently handled exception, or a null <code>exception_ptr</code> object if no exception is being handled. If the function needs to allocate memory and the attempt fails, it returns an <code>exception_ptr</code> object that refers to an instance of <code>bad_alloc</code>. @@ -18297,12 +15341,6 @@ creates a new copy each time it is called. </p> <p> -<ins><i>Remarks:</i> The type of the exception object -referred to by the returned <code>exception_ptr</code> is the most-derived -type of the currently handled exception.</ins> -</p> - -<p> <i>Throws:</i> nothing. </p> @@ -18316,11 +15354,10 @@ type of the currently handled exception.</ins> <hr> <h3><a name="830"></a>830. Incomplete list of char_traits specializations</h3> -<p><b>Section:</b> 21.1 [char.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 21.1 [char.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2008-04-23</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#char.traits">active issues</a> in [char.traits].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits">issues</a> in [char.traits].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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> Paragraph 4 of 21.1 [char.traits] mentions that this @@ -18342,6 +15379,21 @@ should also be added to <tt><ios_fwd></tt> in 27.2 [iostream.forward], and taking a <tt>char_traits</tt> parameter in that header. </blockquote> +<p><i>[ +Sophia Antipolis: +]</i></p> + + +<blockquote> +<p> +Idea of the issue is ok. +</p> +<p> +Alisdair to provide wording, once that wording arrives, move to review. +</p> +</blockquote> + + <p><b>Proposed resolution:</b></p> <p> @@ -18362,49 +15414,12 @@ taking a <tt>char_traits</tt> parameter in that header. <hr> -<h3><a name="831"></a>831. wrong type for not_eof()</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> Dietmar Kühl <b>Date:</b> 2008-04-23</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits.specializations">issues</a> in [char.traits.specializations].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> -<p><b>Discussion:</b></p> -<p> - In Table 56 (Traits requirements) the <tt>not_eof()</tt> member function - is using an argument of type <i>e</i> which denotes an object of - type <code>X::int_type</code>. However, the specializations in - 21.1.3 [char.traits.specializations] all use <code>char_type</code>. - This would effectively mean that the argument type actually can't - represent EOF in the first place. I'm pretty sure that the type used - to be <code>int_type</code> which is quite obviously the only sensible - argument. -</p> -<p> - This issue is close to being editorial. I suspect that the proposal - changing this section to include the specializations for <code>char16_t</code> - and <code>char32_t</code> accidentally used the wrong type. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> - 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 - [char.traits.specializations.wchar_t] correct the - argument type from <code>char_type</code> to <code>int_type</code>. -</p> - - - - - -<hr> <h3><a name="832"></a>832. Applying constexpr to System error support</h3> -<p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-05-14</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#syserr">active issues</a> in [syserr].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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> Initialization of objects of class <tt>error_code</tt> @@ -18444,6 +15459,35 @@ proposed resolution thus changes the private member to a pointer, which also brings it in sync with real implementations. </p> +<p><i>[ +Sophia Antipolis: +]</i></p> + + +<blockquote> +On going question of extern pointer vs. inline functions for interface. +</blockquote> + +<p><i>[ +Pre-San Francisco: +]</i></p> + + +<blockquote> +<p> +Beman Dawes reports that this proposal is unimplementable, and thus NAD. +</p> +<p> +Implementation would require <tt>constexpr</tt> objects of classes derived +from class <tt>error_category</tt>, which has virtual functions, and that is +not allowed by the core language. This was determined when trying to +implement the proposal using a constexpr enabled compiler provided +by Gabriel Dos Reis, and subsequently verified in discussions with +Gabriel and Jens Maurer. +</p> + +</blockquote> + <p><b>Proposed resolution:</b></p> <p> @@ -18606,7 +15650,7 @@ Change 19.4.3.2 [syserr.errcondition.constructors] Class <tt>error_condition</tt </p> <blockquote> -<pre>constexpr error_condition(int val, const error_category<del>&</del><ins>*</ins> cat); +<pre><ins>constexpr</ins> error_condition(int val, const error_category<del>&</del><ins>*</ins> cat); </pre> <p> <i>Effects:</i> Constructs an object of type <tt>error_condition</tt>. @@ -18660,15 +15704,58 @@ paragraphs 2 and 4, change "<tt>category.equivalent(</tt>" to "<tt>category()->equivalent(</tt>". </p> +<p> +Change 19.4.5.1 [syserr.syserr.overview] Class system_error overview as indicated: +</p> + +<blockquote><pre>public: + system_error(error_code ec, const string& what_arg); + system_error(error_code ec); + system_error(int ev, const error_category<del>&</del><ins>*</ins> ecat, + const string& what_arg); + system_error(int ev, const error_category<del>&</del><ins>*</ins> ecat); +</pre></blockquote> + +<p> +Change 19.4.5.2 [syserr.syserr.members] Class system_error members as indicated: +</p> + +<blockquote> +<pre>system_error(int ev, const error_category<del>&</del><ins>*</ins> ecat, const string& what_arg); +</pre> +<blockquote> +<p> +<i>Effects:</i> Constructs an object of class <tt>system_error</tt>. +</p> +<p> +<i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and +<tt>strcmp(runtime_error::what(), what_arg.c_str()) == 0</tt>. +</p> +</blockquote> + +<pre>system_error(int ev, const error_category<del>&</del><ins>*</ins> ecat); +</pre> +<blockquote> +<p> +<i>Effects:</i> Constructs an object of class <tt>system_error</tt>. +</p> +<p> +<i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and +<tt>strcmp(runtime_error::what(), "") == 0</tt>. +</p> +</blockquote> +</blockquote> + + <hr> <h3><a name="833"></a>833. Freestanding implementations header list needs review for C++0x</h3> -<p><b>Section:</b> 17.4.1.3 [compliance] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 17.4.1.3 [compliance] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-05-14</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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> Once the C++0x standard library is feature complete, the LWG needs to @@ -18685,12 +15772,12 @@ ensure it reflects LWG consensus. <hr> <h3><a name="834"></a>834. Unique_ptr::pointer requirements underspecified</h3> -<p><b>Section:</b> 20.6.11.2 [unique.ptr.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> 20.7.11.2 [unique.ptr.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-05-14</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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> -Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a> (including recent updates by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#821">821</a>) proposes a useful +Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> (including recent updates by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#821">821</a>) proposes a useful extension point for <tt>unique_ptr</tt> by granting support for an optional <tt>deleter_type::pointer</tt> to act as pointer-like replacement for <tt>element_type*</tt> (In the following: <tt>pointer</tt>). @@ -18722,11 +15809,27 @@ that all of the expressions of <tt>pointer</tt> used to define semantics are req be well-formed and well-defined (also as back-end for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>). </p> +<p><i>[ +Sophia Antipolis: +]</i></p> + + +<blockquote> +<p> +Howard: We maybe need a core concept <tt>PointerLike</tt>, but we don't need the +arithmetic (see <tt>shared_ptr</tt> vs. <tt>vector<T>::iterator</tt>. +</p> +<p> +Howard will go through and enumerate the individual requirements wrt. <tt>pointer</tt> for each member function. +</p> +</blockquote> + + <p><b>Proposed resolution:</b></p> <p> Add the following sentence just at the end of the newly proposed -20.6.11.2 [unique.ptr.single]/p. 3: +20.7.11.2 [unique.ptr.single]/p. 3: </p> <blockquote> @@ -18842,6 +15945,7 @@ calls <del>os.flush()</del> <ins><code>os.rdbuf()->pubsync()</code></ins>. <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a></p> <p><b>Discussion:</b></p> <p> @@ -19212,5 +16316,3403 @@ return tmp; +<hr> +<h3><a name="839"></a>839. Maps and sets missing splice operation</h3> +<p><b>Section:</b> 23.3 [associative], 23.4 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Alan Talbot <b>Date:</b> 2008-05-18</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Splice is a very useful feature of <tt>list</tt>. This functionality is also very +useful for any other node based container, and I frequently wish it were +available for maps and sets. It seems like an omission that these +containers lack this capability. Although the complexity for a splice is +the same as for an insert, the actual time can be much less since the +objects need not be reallocated and copied. When the element objects are +heavy and the compare operations are fast (say a <tt>map<int, huge_thingy></tt>) +this can be a big win. +</p> + +<p> +<b>Suggested resolution:</b> +</p> + +<p> +Add the following signatures to map, set, multimap, multiset, and the unordered associative containers: +</p> +<blockquote><pre> +void splice(list<T,Allocator>&& x); +void splice(list<T,Allocator>&& x, const_iterator i); +void splice(list<T,Allocator>&& x, const_iterator first, const_iterator last); +</pre></blockquote> + +<p> +Hint versions of these are also useful to the extent hint is useful. +(I'm looking for guidance about whether hints are in fact useful.) +</p> + +<blockquote><pre> +void splice(const_iterator position, list<T,Allocator>&& x); +void splice(const_iterator position, list<T,Allocator>&& x, const_iterator i); +void splice(const_iterator position, list<T,Allocator>&& x, const_iterator first, const_iterator last); +</pre></blockquote> + +<p><i>[ +Sophia Antipolis: +]</i></p> + + +<blockquote> +<p> +Don't try to <tt>splice "list"</tt> into the other containers, it should be container-type. +</p> +<p> +<tt>forward_list</tt> already has <tt>splice_after</tt>. +</p> +<p> +Would "<tt>splice</tt>" make sense for an <tt>unordered_map</tt>? +</p> +<p> +Jens, Robert: "<tt>splice</tt>" is not the right term, it implies maintaining ordering in <tt>list</tt>s. +</p> +<p> +Howard: <tt>adopt</tt>? +</p> +<p> +Jens: <tt>absorb</tt>? +</p> +<p> +Alan: <tt>subsume</tt>? +</p> +<p> +Robert: <tt>recycle</tt>? +</p> +<p> +Howard: <tt>transfer</tt>? (but no direction) +</p> +<p> +Jens: <tt>transfer_from</tt>. No. +</p> +<p> +Alisdair: Can we give a nothrow guarantee? If your <tt>compare()</tt> and <tt>hash()</tt> doesn't throw, yes. +</p> +<p> +Daniel: For <tt>unordered_map</tt>, we can't guarantee nothrow. +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="841"></a>841. cstdint.syn inconsistent with C99</h3> +<p><b>Section:</b> 18.3.1 [cstdint.syn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint.syn">issues</a> in [cstdint.syn].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +In specifying the names of macros and types defined in +header <code><stdint.h></code>, C99 makes use of the +symbol <code><i>N</i></code> to accommodate unusual platforms with +word sizes that aren't powers of two. C99 +permits <code><i>N</i></code> to take on any positive integer value +(including, for example, 24). + + </p> + <p> + +In cstdint.syn Header <code><cstdint></code> +synopsis, C++ on the other hand, fixes the value +of <code><i>N</i></code> to 8, 16, 32, and 64, and specifies only +types with these exact widths. + + </p> + <p> + </p> + +In addition, paragraph 1 of the same section makes use of a rather +informal shorthand notation to specify sets of macros. When +interpreted strictly, the notation specifies macros such +as <code>INT_8_MIN</code> that are not intended to be specified. + + <p> + +Finally, the section is missing the usual table of symbols defined +in that header, making it inconsistent with the rest of the +specification. + + </p> + + <p><b>Proposed resolution:</b></p> + <p> + +I propose to use the same approach in the C++ spec as C99 uses, that +is, to specify the header synopsis in terms of "exposition only" types +that make use of the symbol <code><i>N</i></code> to denote one or +more of a theoretically unbounded set of widths. + + </p> + <p> + +Further, I propose to add a new table to section listing the symbols +defined in the header using a more formal notation that avoids +introducing inconsistencies. + + </p> + <p> + +To this effect, in cstdint.syn +Header <code><cstdint></code> synopsis, replace both the +synopsis and paragraph 1 with the following text: + + </p> + <blockquote> + <p> + </p><ol> + <li> + +In the names defined in the <code><cstdint></code> header, the +symbol <code><i>N</i></code> represents a positive decimal integer +with no leading zeros (e.g., 8 or 24, but not 0, 04, or 048). With the +exception of exact-width types, macros and types for values +of <code><i>N</i></code> in the set of 8, 16, 32, and 64 are +required. Exact-width types, and any macros and types for values +of <code><i>N</i></code> other than 8, 16, 32, and 64 are +optional. However, if an implementation provides integer types with +widths of 8, 16, 32, or 64 bits, the corresponding exact-width types +and macros are required. + + </li> + </ol> + + <pre>namespace std { + + // required types + + // Fastest minimum-width integer types + typedef <i>signed integer type</i> int_fast8_t; + typedef <i>signed integer type</i> int_fast16_t; + typedef <i>signed integer type</i> int_fast32_t; + typedef <i>signed integer type</i> int_fast64_t; + + typedef <i>unsigned integer type</i> uint_fast8_t; + typedef <i>unsigned integer type</i> uint_fast16_t; + typedef <i>unsigned integer type</i> uint_fast32_t; + typedef <i>unsigned integer type</i> uint_fast64_t; + + // Minimum-width integer types + typedef <i>signed integer type</i> int_least8_t; + typedef <i>signed integer type</i> int_least16_t; + typedef <i>signed integer type</i> int_least32_t; + typedef <i>signed integer type</i> int_least64_t; + + typedef <i>unsigned integer type</i> uint_least8_t; + typedef <i>unsigned integer type</i> uint_least16_t; + typedef <i>unsigned integer type</i> uint_least32_t; + typedef <i>unsigned integer type</i> uint_least64_t; + + // Greatest-width integer types + typedef <i>signed integer type</i> intmax_t; + typedef <i>unsigned integer type</i> uintmax_t; + + // optionally defined types + + // Exact-width integer types + typedef <i>signed integer type</i> int<i>N</i>_t; + typedef <i>unsigned integer type</i> uint<i>N</i>_t; + + // Fastest minimum-width integer types for values + // of <i>N</i> other than 8, 16, 32, and 64 + typedef <i>signed integer type</i> uint_fast<i>N</i>_t; + typedef <i>unsigned integer type</i> uint_fast<i>N</i>_t; + + // Minimum-width integer types for values + // of <i>N</i> other than 8, 16, 32, and 64 + typedef <i>signed integer type</i> uint_least<i>N</i>_t; + typedef <i>unsigned integer type</i> uint_least<i>N</i>_t; + + // Integer types capable of holding object pointers + typedef <i>signed integer type</i> intptr_t; + typedef <i>signed integer type</i> intptr_t; + +}</pre> + </blockquote> + <p> + +[Note to editor: Remove all of the existing paragraph 1 from cstdint.syn.] + + </p> + <blockquote> + Table ??: Header <code><cstdint></code> synopsis + <table border="1"> + <thead> + <tr> + <th>Type</th> + <th colspan="3">Name(s)</th> + </tr> + </thead> + <tbody> + <tr> + <td rowspan="11"><b>Macros:</b></td> + <td><tt>INT<i>N</i>_MIN</tt></td> + <td><tt>INT<i>N</i>_MAX</tt></td> + <td><tt>UINT<i>N</i>_MAX</tt></td> + </tr> + <tr> + <td><tt>INT_FAST<i>N</i>_MIN</tt></td> + <td><tt>INT_FAST<i>N</i>_MAX</tt></td> + <td><tt>UINT_FAST<i>N</i>_MAX</tt></td> + </tr> + <tr> + <td><tt>INT_LEAST<i>N</i>_MIN</tt></td> + <td><tt>INT_LEAST<i>N</i>_MAX</tt></td> + <td><tt>UINT_LEAST<i>N</i>_MAX</tt></td> + </tr> + <tr> + <td><tt>INTPTR_MIN</tt></td> + <td><tt>INTPTR_MAX</tt></td> + <td><tt>UINTPTR_MAX</tt></td> + </tr> + <tr> + <td><tt>INTMAX_MIN</tt></td> + <td><tt>INTMAX_MAX</tt></td> + <td><tt>UINTMAX_MAX</tt></td> + </tr> + <tr> + <td><tt>PTRDIFF_MIN</tt></td> + <td><tt>PTRDIFF_MAX</tt></td> + <td><tt>PTRDIFF_MAX</tt></td> + </tr> + <tr> + <td><tt>SIG_ATOMIC_MIN</tt></td> + <td><tt>SIG_ATOMIC_MAX</tt></td> + <td><tt>SIZE_MAX</tt></td> + </tr> + <tr> + <td><tt>WCHAR_MIN</tt></td> + <td><tt>WCHAR_MAX</tt></td> + <td></td> + </tr> + <tr> + <td><tt>WINT_MIN</tt></td> + <td><tt>WINT_MAX</tt></td> + <td></td> + </tr> + <tr> + <td><tt>INT<i>N</i>_C()</tt></td> + <td><tt>UINT<i>N</i>_C()</tt></td> + <td></td> + </tr> + <tr> + <td><tt>INTMAX_C()</tt></td> + <td><tt>UINTMAX_C()</tt></td> + <td></td> + </tr> + <tr> + <td rowspan="5"><b>Types:</b></td> + <td><tt>int<i>N</i>_t</tt></td> + <td><tt>uint<i>N</i>_t</tt></td> + <td></td> + </tr> + <tr> + <td><tt>int_fast<i>N</i>_t</tt></td> + <td><tt>uint_fast<i>N</i>_t</tt></td> + <td></td> + </tr> + <tr> + <td><tt>int_least<i>N</i>_t</tt></td> + <td><tt>uint_least<i>N</i>_t</tt></td> + <td></td> + </tr> + <tr> + <td><tt>intptr_t</tt></td> + <td><tt>uintptr_t</tt></td> + <td></td> + </tr> + <tr> + <td><tt>intmax_t</tt></td> + <td><tt>uintmax_t</tt></td> + <td></td> + </tr> + </tbody> + </table> + </blockquote> + + + + + +<hr> +<h3><a name="842"></a>842. ConstructibleAsElement and bit containers</h3> +<p><b>Section:</b> 23.1 [container.requirements], 23.2.7 [vector.bool], 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-06-03</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> +<p><b>Discussion:</b></p> +<p> +23.1 [container.requirements]/p3 says: +</p> + +<blockquote> +Objects stored in these components shall be constructed using +<tt>construct_element</tt> (20.6.9). For each operation that inserts an +element of type <tt>T</tt> into a container (<tt>insert</tt>, +<tt>push_back</tt>, <tt>push_front</tt>, <tt>emplace</tt>, etc.) with +arguments <tt>args... T</tt> shall be <tt>ConstructibleAsElement</tt>, +as described in table 88. [<i>Note:</i> If the component is instantiated +with a scoped allocator of type <tt>A</tt> (i.e., an allocator for which +<tt>is_scoped_allocator<A>::value</tt> is <tt>true</tt>), then +<tt>construct_element</tt> may pass an inner allocator argument to +<tt>T</tt>'s constructor. <i>-- end note</i>] +</blockquote> + +<p> +However <tt>vector<bool, A></tt> (23.2.7 [vector.bool]) and <tt>bitset<N></tt> +(23.3.5 [template.bitset]) store bits, not <tt>bool</tt>s, and <tt>bitset<N></tt> +does not even have an allocator. But these containers are governed by this clause. Clearly this +is not implementable. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 23.1 [container.requirements]/p3: +</p> + +<blockquote> +Objects stored in these components shall be constructed using +<tt>construct_element</tt> (20.6.9)<ins>, unless otherwise specified</ins>. +For each operation that inserts an +element of type <tt>T</tt> into a container (<tt>insert</tt>, +<tt>push_back</tt>, <tt>push_front</tt>, <tt>emplace</tt>, etc.) with +arguments <tt>args... T</tt> shall be <tt>ConstructibleAsElement</tt>, +as described in table 88. [<i>Note:</i> If the component is instantiated +with a scoped allocator of type <tt>A</tt> (i.e., an allocator for which +<tt>is_scoped_allocator<A>::value</tt> is <tt>true</tt>), then +<tt>construct_element</tt> may pass an inner allocator argument to +<tt>T</tt>'s constructor. <i>-- end note</i>] +</blockquote> + +<p> +Change 23.2.7 [vector.bool]/p2: +</p> + +<blockquote> +Unless described below, all operations have the same requirements and semantics as the primary <tt>vector</tt> template, +except that operations dealing with the <tt>bool</tt> value type map to bit values in the container storage<ins>, +and <tt>construct_element</tt> (23.1 [container.requirements]) is not used to construct these values</ins>. +</blockquote> + +<p> +Move 23.3.5 [template.bitset] to clause 20. +</p> + + + + + + +<hr> +<h3><a name="843"></a>843. Reference Closure</h3> +<p><b>Section:</b> 20.6.17.1 [func.referenceclosure.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-06-02</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The <tt>std::reference_closure</tt> type has a deleted copy assignment operator +under the theory that references cannot be assigned, and hence the +assignment of its reference member must necessarily be ill-formed. +</p> +<p> +However, other types, notably <tt>std::reference_wrapper</tt> and <tt>std::function</tt> +provide for the "copying of references", and thus the current definition +of <tt>std::reference_closure</tt> seems unnecessarily restrictive. In particular, +it should be possible to write generic functions using both <tt>std::function</tt> +and <tt>std::reference_closure</tt>, but this generality is much harder when +one such type does not support assignment. +</p> +<p> +The definition of <tt>reference_closure</tt> does not necessarily imply direct +implementation via reference types. Indeed, the <tt>reference_closure</tt> is +best implemented via a frame pointer, for which there is no standard +type. +</p> +<p> +The semantics of assignment are effectively obtained by use of the +default destructor and default copy assignment operator via +</p> + +<blockquote><pre>x.~reference_closure(); new (x) reference_closure(y); +</pre></blockquote> + +<p> +So the copy assignment operator generates no significant real burden +to the implementation. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 20.6.17 [func.referenceclosure] Class template reference_closure, +replace the <tt>=delete</tt> in the copy assignment operator in the synopsis +with <tt>=default</tt>. +</p> + +<blockquote><pre>template<class R , class... ArgTypes > + class reference_closure<R (ArgTypes...)> { + public: + ... + reference_closure& operator=(const reference_closure&) = <del>delete</del> <ins>default</ins>; + ... +</pre></blockquote> + +<p> +In 20.6.17.1 [func.referenceclosure.cons] Construct, copy, destroy, +add the member function description +</p> + +<blockquote> +<pre>reference_closure& operator=(const reference_closure& f) +</pre> +<blockquote> +<p> +<i>Postcondition:</i> <tt>*this</tt> is a copy of <tt>f</tt>. +</p> +<p> +<i>Returns:</i> <tt>*this</tt>. +</p> +</blockquote> +</blockquote> + + + + + + + +<hr> +<h3><a name="844"></a>844. <tt>complex pow</tt> return type is ambiguous</h3> +<p><b>Section:</b> 26.3.9 [cmplx.over] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-06-03</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The current working draft is in an inconsistent state. +</p> + +<p> +26.3.8 [complex.transcendentals] says that: +</p> + +<blockquote> +<tt>pow(complex<float>(), int())</tt> returns a <tt>complex<float></tt>. +</blockquote> + +<p> +26.3.9 [cmplx.over] says that: +</p> + +<blockquote> +<tt>pow(complex<float>(), int())</tt> returns a <tt>complex<double></tt>. +</blockquote> + +<p><i>[ +Sophia Antipolis: +]</i></p> + + +<blockquote> +<p> +Since <tt>int</tt> promotes to <tt>double</tt>, and C99 doesn't have an <tt>int</tt>-based +overload for <tt>pow</tt>, the C99 result is <tt>complex<double></tt>, see also C99 +7.22, see also library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>. +</p> +<p> +Special note: ask P.J. Plauger. +</p> +<blockquote> +Looks fine. +</blockquote> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Strike this <tt>pow</tt> overload in 26.3.1 [complex.synopsis] and in 26.3.8 [complex.transcendentals]: +</p> + +<blockquote><pre><del>template<class T> complex<T> pow(const complex<T>& x, int y);</del> +</pre></blockquote> + + + + + +<hr> +<h3><a name="845"></a>845. atomics cannot support aggregate initialization</h3> +<p><b>Section:</b> 29.3 [atomics.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-06-03</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics.types">active issues</a> in [atomics.types].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types">issues</a> in [atomics.types].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The atomic classes (and class templates) are required to support aggregate +initialization (29.3.1 [atomics.types.integral]p2 / 29.3.2 [atomics.types.address]p1) +yet also have user declared constructors, so cannot be aggregates. +</p> +<p> +This problem might be solved with the introduction of the proposed +initialization syntax at Antipolis, but the wording above should be altered. +Either strike the sentence as redundant with new syntax, or refer to 'brace +initialization'. +</p> + +<p><i>[ +Jens adds: +]</i></p> + + +<blockquote> +<p> +Note that +</p> +<blockquote><pre>atomic_itype a1 = { 5 }; +</pre></blockquote> +<p> +would be aggregate-initialization syntax (now coming under the disguise +of brace initialization), but would be ill-formed, because the corresponding +constructor for atomic_itype is explicit. This works, though: +</p> +<blockquote><pre>atomic_itype a2 { 6 }; +</pre></blockquote> + +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +In 29.3.1 [atomics.types.integral], strike the following sentence from paragraph 2: +</p> + +<blockquote> +The atomic integral types shall have standard layout. They shall each have a trivial default constructor, a constexpr +explicit value constructor, a deleted copy constructor, a deleted copy assignment operator, and a trivial destructor. +<del>They shall each support aggregate initialization syntax.</del> +</blockquote> + +<p><i>[ +2008-08-18, Lawrence adds: +]</i></p> + +<blockquote> +The syntactic compatibility of initialization with C is important. +I suggest a different resolution; remove the explicit from the +constructor. For the same reasons we can have implicit conversions, +we can also have implicit constructors. +</blockquote> + + + + + +<hr> +<h3><a name="846"></a>846. No definition for constructor</h3> +<p><b>Section:</b> 29.3 [atomics.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-06-03</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics.types">active issues</a> in [atomics.types].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types">issues</a> in [atomics.types].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The atomic classes and class templates (29.3.1 [atomics.types.integral] / +29.3.2 [atomics.types.address]) have a constexpr +constructor taking a value of the appropriate type for that atomic. +However, neither clause provides semantics or a definition for this +constructor. I'm not sure if the initialization is implied by use of +constexpr keyword (which restricts the form of a constructor) but even if +that is the case, I think it is worth spelling out explicitly as the +inference would be far too subtle in that case. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="847"></a>847. string exception safety guarantees</h3> +<p><b>Section:</b> 21.3.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Hervé Brönnimann <b>Date:</b> 2008-06-05</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.require">issues</a> in [string.require].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In March, on comp.lang.c++.moderated, I asked what were the +string exception safety guarantees are, because I cannot see +*any* in the working paper, and any implementation I know offers +the strong exception safety guarantee (string unchanged if a +member throws exception). The closest the current draft comes to +offering any guarantees is 21.3 [basic.string], para 3: +</p> + +<blockquote> +The class template <tt>basic_string</tt> conforms to the requirements +for a Sequence Container (23.1.1), for a Reversible Container (23.1), +and for an Allocator-aware container (91). The iterators supported by +<tt>basic_string</tt> are random access iterators (24.1.5). +</blockquote> + +<p> +However, the chapter 23 only says, on the topic of exceptions: 23.1 [container.requirements], +para 10: +</p> + +<blockquote> +<p> +Unless otherwise specified (see 23.2.2.3 and 23.2.6.4) all container types defined in this clause meet the following +additional requirements: +</p> + +<ul> +<li>if an exception is thrown by...</li> +</ul> +</blockquote> + +<p> +I take it as saying that this paragraph has *no* implication on +<tt>std::basic_string</tt>, as <tt>basic_string</tt> isn't defined in Clause 23 and +this paragraph does not define a *requirement* of Sequence +nor Reversible Container, just of the models defined in Clause 23. +In addition, LWG Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a> proposes to remove 23.1 [container.requirements], para 3. +</p> + +<p> +Finally, the fact that no operation on Traits should throw +exceptions has no bearing, except to suggest (since the only +other throws should be allocation, <tt>out_of_range</tt>, or <tt>length_error</tt>) +that the strong exception guarantee can be achieved. +</p> + +<p> +The reaction in that group by Niels Dekker, Martin Sebor, and +Bo Persson, was all that this would be worth an LWG issue. +</p> + +<p> +A related issue is that <tt>erase()</tt> does not throw. This should be +stated somewhere (and again, I don't think that the 23.1 [container.requirements], para 1 +applies here). +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Add a blanket statement in 21.3.1 [string.require]: +</p> + +<blockquote> +<p> +- if any member function or operator of <tt>basic_string<charT, traits, Allocator></tt> +throws, that function or operator has no effect. +</p> +<p> +- no <tt>erase()</tt> or <tt>pop_back()</tt> function throws. +</p> +</blockquote> + +<p> +As far as I can tell, this is achieved by any implementation. If I made a +mistake and it is not possible to offer this guarantee, then +either state all the functions for which this is possible +(certainly at least <tt>operator+=</tt>, <tt>append</tt>, <tt>assign</tt>, and <tt>insert</tt>), +or add paragraphs to Effects clauses wherever appropriate. +</p> + + + + + +<hr> +<h3><a name="848"></a>848. missing <tt>std::hash</tt> specializations for <tt>std::bitset/std::vector<bool></tt></h3> +<p><b>Section:</b> 20.6.16 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> + <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2008-06-05</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In the current working draft, <tt>std::hash<T></tt> is specialized for builtin +types and a few other types. Bitsets seems like one that is missing from +the list, not because it cannot not be done by the user, but because it +is hard or impossible to write an efficient implementation that works on +32bit/64bit chunks at a time. For example, <tt>std::bitset</tt> is too much +encapsulated in this respect. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add the following to the synopsis in 20.6 [function.objects]/2: +</p> + +<blockquote><pre>template<class Allocator> struct hash<std::vector<bool,Allocator>>; +template<size_t N> struct hash<std::bitset<N>>; +</pre></blockquote> + +<p> +Modify the last sentence of 20.6.16 [unord.hash]/1 to end with: +</p> + +<blockquote> +... and <tt>std::string</tt>, <tt>std::u16string</tt>, <tt>std::u32string</tt>, <tt>std::wstring</tt>, +<tt>std::error_code</tt>, <tt>std::thread::id</tt>, <tt>std::bitset</tt>, <tt>and std::vector<bool></tt>. +</blockquote> + + + + + + +<hr> +<h3><a name="849"></a>849. missing type traits to compute root class and derived class of types in a class hierachy</h3> +<p><b>Section:</b> 20.5.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2008-06-05</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.trans.other">active issues</a> in [meta.trans.other].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The type traits library contains various traits to dealt with +polymorphic types, e.g. <tt>std::has_virtual_destructor</tt>, <tt>std::is_polymorphic</tt> +and <tt>std::is_base_of</tt>. However, there is no way to compute the unique +public base class of a type if such one exists. Such a trait could be +very useful if one needs to instantiate a specialization made for the +root class whenever a derived class is passed as parameter. For example, +imagine that you wanted to specialize <tt>std::hash</tt> for a class +hierarchy---instead of specializing each class, you could specialize the +<tt>std::hash<root_class></tt> and provide a partial specialization that worked +for all derived classes. +</p> + +<p> +This ability---to specify operations in terms of their equivalent in the +root class---can be done with e.g. normal functions, but there is, +AFAIK, no way to do it for class templates. Being able to access +compile-time information about the type-hierachy can be very powerful, +and I therefore also suggest traits that computes the directly derived +class whenever that is possible. +</p> + +<p> +If the computation can not be done, the traits should fall back on an +identity transformation. I expect this gives the best overall usability. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add the following to the synopsis in 20.5.2 [meta.type.synop] under "other transformations": +</p> + +<blockquote><pre>template< class T > struct direct_base_class; +template< class T > struct direct_derived_class; +template< class T > struct root_base_class; +</pre></blockquote> + +<p> +Add three new entries to table 51 (20.5.7 [meta.trans.other]) with the following content +</p> + +<blockquote> +<table border="1"> +<tbody><tr> +<th>Template</th><th>Condition</th><th>Comments</th> +</tr> +<tr> +<td><tt>template< class T > struct direct_base_class;</tt></td> +<td><tt>T</tt> shall be a complete type.</td> +<td>The member typedef <tt>type</tt> shall equal the accessible unambiguous direct base class of <tt>T</tt>. +If no such type exists, the member typedef <tt>type</tt> shall equal <tt>T</tt>.</td> +</tr> +<tr> +<td><tt>template< class T > struct direct_derived_class;</tt></td> +<td><tt>T</tt> shall be a complete type.</td> +<td>The member typedef <tt>type</tt> shall equal the unambiguous type which has <tt>T</tt> +as an accessible unambiguous direct base class. If no such type exists, the member typedef +<tt>type</tt> shall equal <tt>T</tt>.</td> +</tr> +<tr> +<td><tt>template< class T > struct root_base_class;</tt></td> +<td><tt>T</tt> shall be a complete type.</td> +<td>The member typedef <tt>type</tt> shall equal the accessible unambiguous most indirect base class of +<tt>T</tt>. If no such type exists, the member typedef type shall equal <tt>T</tt>.</td> +</tr> +</tbody></table> +</blockquote> + + + + + + +<hr> +<h3><a name="850"></a>850. Should <tt>shrink_to_fit</tt> apply to <tt>std::deque</tt>?</h3> +<p><b>Section:</b> 23.2.2.2 [deque.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> + <b>Submitter:</b> Niels Dekker <b>Date:</b> 2008-06-05</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#deque.capacity">active issues</a> in [deque.capacity].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#deque.capacity">issues</a> in [deque.capacity].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a> added a <tt>shrink_to_fit</tt> function to <tt>std::vector</tt> and <tt>std::string</tt>. +It did not yet deal with <tt>std::deque</tt>, because of the fundamental +difference between <tt>std::deque</tt> and the other two container types. The +need for <tt>std::deque</tt> may seem less evident, because one might think that +for this container, the overhead is a small map, and some number of +blocks that's bounded by a small constant. +</p> +<p> +The container overhead can in fact be arbitrarily large (i.e. is not +necessarily O(N) where N is the number of elements currently held by the +<tt>deque</tt>). As Bill Plauger noted in a reflector message, unless the map of +block pointers is shrunk, it must hold at least maxN/B pointers where +maxN is the maximum of N over the lifetime of the <tt>deque</tt> since its +creation. This is independent of how the map is implemented +(<tt>vector</tt>-like circular buffer and all), and maxN bears no relation to N, +the number of elements it currently holds. +</p> +<p> +Hervé Brönnimann reports a situation where a <tt>deque</tt> of requests grew very +large due to some temporary backup (the front request hanging), and the +map of the <tt>deque</tt> grew quite large before getting back to normal. Just +to put some color on it, assuming a <tt>deque</tt> with 1K pointer elements in +steady regime, that held, at some point in its lifetime, maxN=10M +pointers, with one block holding 128 elements, the spine must be at +least (maxN / 128), in that case 100K. In that case, shrink-to-fit +would allow to reuse about 100K which would otherwise never be reclaimed +in the lifetime of the <tt>deque</tt>. +</p> +<p> +An added bonus would be that it *allows* implementations to hang on to +empty blocks at the end (but does not care if they do or not). A +<tt>shrink_to_fit</tt> would take care of both shrinks, and guarantee that at +most O(B) space is used in addition to the storage to hold the N +elements and the N/B block pointers. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +To Class template deque 23.2.2 [deque] synopsis, add: +</p> +<blockquote><pre>void shrink_to_fit(); +</pre></blockquote> + +<p> +To deque capacity 23.2.2.2 [deque.capacity], add: +</p> +<blockquote><pre>void shrink_to_fit(); +</pre> + +<blockquote> +<i>Remarks:</i> <tt>shrink_to_fit</tt> is a non-binding request to reduce memory +use. [<i>Note:</i> The request is non-binding to allow latitude for +implementation-specific optimizations. -- <i>end note</i>] +</blockquote> +</blockquote> + + + + + +<hr> +<h3><a name="851"></a>851. simplified array construction</h3> +<p><b>Section:</b> 23.2.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> + <b>Submitter:</b> Benjamin Kosnik <b>Date:</b> 2008-06-05</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p> +<p><b>Discussion:</b></p> +<p> +This is an issue that came up on the libstdc++ list, where a +discrepency between "C" arrays and C++0x's <tt>std::array</tt> was pointed +out. +</p> + +<p> +In "C," this array usage is possible: +</p> + +<blockquote><pre>int ar[] = {1, 4, 6}; +</pre></blockquote> + +<p> +But for C++, +</p> + +<blockquote><pre>std::array<int> a = { 1, 4, 6 }; // error +</pre></blockquote> + +<p> +Instead, the second parameter of the <tt>array</tt> template must be +explicit, like so: +</p> + +<blockquote><pre>std::array<int, 3> a = { 1, 4, 6 }; +</pre></blockquote> + +<p> +Doug Gregor proposes the following solution, that assumes +generalized initializer lists. +</p> + +<blockquote><pre>template<typename T, typename... Args> +inline array<T, sizeof...(Args)> +make_array(Args&&... args) +{ return { std::forward<Args>(args)... }; } +</pre></blockquote> + +<p> +Then, the way to build an <tt>array</tt> from a list of unknown size is: +</p> + +<blockquote><pre>auto a = make_array<T>(1, 4, 6); +</pre></blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Add to the <tt>array</tt> synopis in 23.2 [sequences]: +</p> + +<blockquote><pre>template<typename T, typename... Args> + requires Convertible<Args, T>... + array<T, sizeof...(Args)> + make_array(Args&&... args); +</pre></blockquote> + +<p> +Append after 23.2.1.6 [array.tuple] Tuple interface to class template <tt>array</tt> the +following new section. +</p> + +<blockquote> +<p> +23.2.1.7 Convenience interface to class template <tt>array</tt> [array.tuple] +</p> + +<pre>template<typename T, typename... Args> + requires Convertible<Args, T>... + array<T, sizeof...(Args)> + make_array(Args&&... args); +</pre> + +<blockquote> +<p> +<i>Returns:</i> <tt>{std::forward<Args>(args)...}</tt> +</p> +</blockquote> +</blockquote> + + + + + +<hr> +<h3><a name="852"></a>852. unordered containers <tt>begin(n)</tt> mistakenly <tt>const</tt></h3> +<p><b>Section:</b> 23.4 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> + <b>Submitter:</b> Robert Klarer <b>Date:</b> 2008-06-12</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord">active issues</a> in [unord].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord">issues</a> in [unord].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In 3 of the four unordered containers the local <tt>begin</tt> member is mistakenly declared <tt>const</tt>: +</p> + +<blockquote><pre>local_iterator begin(size_type n) const; +</pre></blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change the synopsis in 23.4.1 [unord.map], 23.4.2 [unord.multimap], and 23.4.4 [unord.multiset]: +</p> + +<blockquote><pre>local_iterator begin(size_type n)<del> const</del>; +</pre></blockquote> + + + + + +<hr> +<h3><a name="853"></a>853. <tt>to_string</tt> needs updating with <tt>zero</tt> and <tt>one</tt></h3> +<p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-06-18</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#396">396</a> adds defaulted arguments to the <tt>to_string</tt> member, but neglects to update +the three newer <tt>to_string</tt> overloads. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change the synopsis in 23.3.5 [template.bitset], and the signatures in 23.3.5.2 [bitset.members] to: +</p> + +<blockquote><pre>template <class charT, class traits> + basic_string<charT, traits, allocator<charT> > to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const; +template <class charT> + basic_string<charT, char_traits<charT>, allocator<charT> > to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const; +basic_string<char, char_traits<char>, allocator<char> > to_string(<ins>char zero = '0', char one = '1'</ins>) const; +</pre></blockquote> + + + + + +<hr> +<h3><a name="854"></a>854. <tt>default_delete</tt> converting constructor underspecified</h3> +<p><b>Section:</b> 20.7.11.1.1 [unique.ptr.dltr.dflt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-06-18</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +No relationship between <tt>U</tt> and <tt>T</tt> in the converting constructor for <tt>default_delete</tt> template. +</p> +<p> +Requirements: <tt>U*</tt> is convertible to <tt>T*</tt> and <tt>has_virtual_destructor<T></tt>; +the latter should also become a concept. +</p> +<p> +Rules out cross-casting. +</p> +<p> +The requirements for <tt>unique_ptr</tt> conversions should be the same as those on the deleter. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 20.7.11.1.1 [unique.ptr.dltr.dflt]: +</p> + +<blockquote><pre>namespace std { + template <class T> struct default_delete { + default_delete(); + template <class U> + <ins>requires Convertible<U*, T*> && HasVirtualDestructor<T></ins> + default_delete(const default_delete<U>&); + void operator()(T*) const; + }; +} +</pre></blockquote> + +<p> +... +</p> + +<blockquote><pre>template <class U> + <ins>requires Convertible<U*, T*> && HasVirtualDestructor<T></ins> + default_delete(const default_delete<U>& other); +</pre></blockquote> + + + + + + +<hr> +<h3><a name="855"></a>855. capacity() and reserve() for deque?</h3> +<p><b>Section:</b> 23.2.2.2 [deque.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Hervé Brönnimann <b>Date:</b> 2008-06-11</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#deque.capacity">active issues</a> in [deque.capacity].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#deque.capacity">issues</a> in [deque.capacity].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The main point is that <tt>capacity</tt> can be viewed as a mechanism to +guarantee the validity of <tt>iterators</tt> when only <tt>push_back/pop_back</tt> +operations are used. For <tt>vector</tt>, this goes with reallocation. For +<tt>deque</tt>, this is a bit more subtle: <tt>capacity()</tt> of a <tt>deque</tt> may shrink, +whereas that of <tt>vector</tt> doesn't. In a circular buffer impl. of the +map, as Howard did, there is very similar notion of capacity: as long +as <tt>size()</tt> is less than <tt>B * (</tt>total size of the map <tt>- 2)</tt>, it is +guaranteed that no <tt>iterator</tt> is invalidated after any number of +<tt>push_front/back</tt> and <tt>pop_front/back</tt> operations. But this does not +hold for other implementations. +</p> +<p> +Still, I believe, <tt>capacity()</tt> can be defined by <tt>size() +</tt> how many +<tt>push_front/back</tt> minus <tt>pop_front/back</tt> that can be performed before +terators are invalidated. In a classical impl., <tt>capacity() = size() ++ </tt> the min distance to either "physical" end of the deque (i.e., +counting the empty space in the last block plus all the blocks until +the end of the map of block pointers). In Howard's circular buffer +impl., <tt>capacity() = B * (</tt>total size of the map <tt>- 2)</tt> still works with +this definition, even though the guarantee could be made stronger. +</p> +<p> +A simple picture of a deque: +</p> +<blockquote><pre>A-----|----|-----|---F+|++++|++B--|-----|-----Z +</pre></blockquote> +<p> +(A,Z mark the beginning/end, | the block boundaries, F=front, B=back, +and - are uninitialized, + are initialized) +In that picture: <tt>capacity = size() + min(dist(A,F),dist(B,Z)) = min +(dist(A,B),dist(F,Z))</tt>. +</p> +<p> +<tt>Reserve(n)</tt> can grow the map of pointers and add possibly a number of +empty blocks to it, in order to guarantee that the next <tt>n-size() +push_back/push_front</tt> operations will not invalidate iterators, and +also will not allocate (i.e. cannot throw). The second guarantee is +not essential and can be left as a QoI. I know well enough existing +implementations of <tt>deque</tt> (sgi/stl, roguewave, stlport, and +dinkumware) to know that either can be implemented with no change to +the existing class layout and code, and only a few modifications if +blocks are pre-allocated (instead of always allocating a new block, +check if the next entry in the map of block pointers is not zero). +</p> +<p> +Due to the difference with <tt>vector</tt>, wording is crucial. Here's a +proposed wording to make things concrete; I tried to be reasonably +careful but please double-check me: +</p> + + + +<p><b>Proposed resolution:</b></p> + +<p> +Add new signatures to synopsis in 23.2.2 [deque]: +</p> + +<blockquote><pre>size_type capacity() const; +bool reserve(size_type n); +</pre></blockquote> + +<p> +Add new signatures to 23.2.2.2 [deque.capacity]: +</p> + +<blockquote> +<pre>size_type capacity() const; +</pre> +<blockquote> +<p> +1 <i>Returns:</i> An upper bound on <tt>n + max(n_f - m_f, n_b - m_b)</tt> such +that, for any sequence of <tt>n_f push_front</tt>, <tt>m_f pop_front</tt>, <tt>n_b +push_back</tt>, and <tt>m_b pop_back</tt> operations, interleaved in any order, +starting with the current <tt>deque</tt> of size <tt>n</tt>, the <tt>deque</tt> does not +invalidate any of its iterators except to the erased elements. +</p> +<p> +2 <i>Remarks:</i> Unlike a <tt>vector</tt>'s capacity, the capacity of a <tt>deque</tt> can +decrease after a sequence of insertions at both ends, even if none of +the operations caused the <tt>deque</tt> to invalidate any of its iterators +except to the erased elements. +</p> +</blockquote> +</blockquote> + +<blockquote> +<pre>bool reserve(size_type n); +</pre> +<blockquote> +<p> +2 <i>Effects:</i> A directive that informs a <tt>deque</tt> of a planned sequence of +<tt>push_front</tt>, <tt>pop_front</tt>, <tt>push_back</tt>, and <tt>pop_back</tt> operations, so that it +can manage iterator invalidation accordingly. After <tt>reserve()</tt>, +<tt>capacity()</tt> is greater or equal to the argument of <tt>reserve</tt> if this +operation returns <tt>true</tt>; and equal to the previous value of <tt>capacity()</tt> +otherwise. If an exception is thrown, there are no effects. +</p> +<p> +3 <i>Returns:</i> <tt>true</tt> if iterators are invalidated as a result of this +operation, and false otherwise. +</p> +<p> +4 <i>Complexity:</i> It does not change the size of the sequence and takes +at most linear time in <tt>n</tt>. +</p> +<p> +5 <i>Throws:</i> <tt>length_error</tt> if <tt>n > max_size()</tt>. +</p> +<p> +6 <i>Remarks:</i> It is guaranteed that no invalidation takes place during a +sequence of <tt>insert</tt> or <tt>erase</tt> operations at either end that happens +after a call to <tt>reserve()</tt> except to the erased elements, until the +time when an insertion would make <tt>max(n_f-m_f, n_b-m_b)</tt> larger than +<tt>capacity()</tt>, where <tt>n_f</tt> is the number of <tt>push_front</tt>, <tt>m_f</tt> of <tt>pop_front</tt>, +<tt>n_b</tt> of <tt>push_back</tt>, and <tt>m_b</tt> of <tt>pop_back</tt> operations since the call to +<tt>reserve()</tt>. +</p> +<p> +7 An implementation is free to pre-allocate buffers so as to +offer the additional guarantee that no exception will be thrown +during such a sequence other than by the element constructors. +</p> +</blockquote> +</blockquote> + +<p> +And 23.2.2.3 [deque.modifiers] para 1, can be enhanced: +</p> + +<blockquote> +1 <i>Effects:</i> An insertion in the middle of the deque invalidates all the iterators and references to elements of the +deque. An insertion at either end of the deque invalidates all the iterators to the deque, +<ins>unless provisions have been made with reserve,</ins> +but has no effect on the validity of references to elements of the deque. +</blockquote> + + + + + +<hr> +<h3><a name="856"></a>856. Removal of <tt>aligned_union</tt></h3> +<p><b>Section:</b> 20.5.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-06-12</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.trans.other">active issues</a> in [meta.trans.other].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +With the arrival of extended unions +(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2544.pdf">N2544</a>), +there is no +known use of <tt>aligned_union</tt> that couldn't be handled by +the "extended unions" core-language facility. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Remove the following signature from 20.5.2 [meta.type.synop]: +</p> +<blockquote><pre>template <std::size_t Len, class... Types> struct aligned_union; +</pre></blockquote> + +<p> +Remove the second row from table 51 in 20.5.7 [meta.trans.other], +starting with: +</p> + +<blockquote><pre>template <std::size_t Len, +class... Types> +struct aligned_union; +</pre></blockquote> + + + + + +<hr> +<h3><a name="857"></a>857. <tt>condition_variable::time_wait</tt> return <tt>bool</tt> error prone</h3> +<p><b>Section:</b> 30.4.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-06-13</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The meaning of the <tt>bool</tt> returned by <tt>condition_variable::timed_wait</tt> is so +obscure that even the class' designer can't deduce it correctly. Several +people have independently stumbled on this issue. +</p> +<p> +It might be simpler to change the return type to a scoped enum: +</p> +<blockquote><pre>enum class timeout { not_reached, reached }; +</pre></blockquote> + +<p> +That's the same cost as returning a <tt>bool</tt>, but not subject to mistakes. Your example below would be: +</p> + +<blockquote><pre>if (cv.wait_until(lk, time_limit) == timeout::reached ) + throw time_out(); +</pre></blockquote> + +<p><i>[ +Beman to supply exact wording. +]</i></p> + + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="858"></a>858. Wording for Minimal Support for Garbage Collection</h3> +<p><b>Section:</b> X [garbage.collection] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Pete Becker <b>Date:</b> 2008-06-21</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The first sentence of the Effects clause for <tt>undeclare_reachable</tt> seems +to be missing some words. I can't parse +</p> +<blockquote> +... for all non-null <tt>p</tt> referencing the argument is no longer declared reachable... +</blockquote> +<p> +I take it the intent is that <tt>undeclare_reachable</tt> should be called only +when there has been a corresponding call to <tt>declare_reachable</tt>. In +particular, although the wording seems to allow it, I assume that code +shouldn't call <tt>declare_reachable</tt> once then call <tt>undeclare_reachable</tt> +twice. +</p> +<p> +I don't know what "shall be live" in the Requires clause means. +</p> +<p> +In the final Note for <tt>undeclare_reachable</tt>, what does "cannot be +deallocated" mean? Is this different from "will not be able to collect"? +</p> + +<p> +For the wording on nesting of <tt>declare_reachable</tt> and +<tt>undeclare_reachable</tt>, the words for locking and unlocking recursive +mutexes probably are a good model. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="859"></a>859. Monotonic Clock is Conditionally Supported?</h3> +<p><b>Section:</b> X [datetime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Pete Becker <b>Date:</b> 2008-06-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.html">N2661</a> +says that there is a class named <tt>monotonic_clock</tt>. It also says that this +name may be a synonym for <tt>system_clock</tt>, and that it's conditionally +supported. So the actual requirement is that it can be monotonic or not, +and you can tell by looking at <tt>is_monotonic</tt>, or it might not exist at +all (since it's conditionally supported). Okay, maybe too much +flexibility, but so be it. +</p> +<p> +A problem comes up in the threading specification, where several +variants of <tt>wait_for</tt> explicitly use <tt>monotonic_clock::now()</tt>. What is the +meaning of an effects clause that says +</p> + +<blockquote><pre>wait_until(lock, chrono::monotonic_clock::now() + rel_time) +</pre></blockquote> + +<p> +when <tt>monotonic_clock</tt> is not required to exist? +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="860"></a>860. Floating-Point State</h3> +<p><b>Section:</b> 26 [numerics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-06-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +There are a number of functions that affect the floating point state. +These function need to be thread-safe, but I'm unsure of the right +approach in the standard, as we inherit them from C. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="861"></a>861. Incomplete specification of EqualityComparable for std::forward_list</h3> +<p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-06-24</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Table 89, Container requirements, defines <tt>operator==</tt> in terms of the container +member function <tt>size()</tt> and the algorithm <tt>std::equal</tt>: +</p> + +<blockquote> +<tt>==</tt> is an equivalence relation. <tt>a.size() == b.size() && +equal(a.begin(), a.end(), b.begin()</tt> +</blockquote> + +<p> +The new container <tt>forward_list</tt> does not provide a <tt>size</tt> member function +by design but does provide <tt>operator==</tt> and <tt>operator!=</tt> without specifying it's semantic. +</p> +<p> +Other parts of the (sequence) container requirements do also depend on +<tt>size()</tt>, e.g. <tt>empty()</tt> +or <tt>clear()</tt>, but this issue explicitly attempts to solve the missing +<tt>EqualityComparable</tt> specification, +because of the special design choices of <tt>forward_list</tt>. +</p> +<p> +I propose to apply one of the following resolutions, which are described as: +</p> + +<ol type="A"> +<li> +Provide a definition, which is optimal for this special container without +previous size test. This choice prevents two <tt>O(N)</tt> calls of <tt>std::distance()</tt> +with the corresponding container ranges and instead uses a special +<tt>equals</tt> implementation which takes two container ranges instead of 1 1/2. +</li> +<li> +The simple fix where the usual test is adapted such that <tt>size()</tt> is replaced +by <tt>distance</tt> with corresponding performance disadvantages. +</li> +</ol> +<p> +Both proposal choices are discussed, the preferred choice of the author is +to apply (A). +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Common part: +</p> +<ul> +<li> +<p> +Just betwen 23.2.3.5 [forwardlist.ops] and 23.2.3.6 [forwardlist.spec] +add a new +section "forwardlist comparison operators" [forwardlist.compare] (and +also add the +new section number to 23.2.3 [forwardlist]/2 in front of "Comparison operators"): +</p> +<blockquote> +forwardlist comparison operators [forwardlist.compare] +</blockquote> +</li> +</ul> + +<p> +Option (A): +</p> +<blockquote> +<ul> +<li> +<p> +Add to the new section [forwardlist.compare] the following paragraphs: +</p> + +<blockquote> +<pre>template <class T, class Allocator> +bool operator==(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y); +</pre> +<blockquote> +<p> +<i>Requires:</i> Type <tt>T</tt> is <tt>EqualityComparable</tt> ([equalitycomparable]). +</p> +<p> +<i>Returns:</i> <tt>true</tt> if +</p> +<ul> +<li> +<p> +for every iterator <tt>i</tt> in the range <tt>[x.begin(), E)</tt>, where <tt>E == +x.begin() + M</tt> and <tt>M == + min(distance(x.begin(), x.end()), distance(y.begin(), y.end()))</tt>, +the following condition holds: +</p> +<blockquote><pre>*i == *(y.begin() + (i - x.begin())). +</pre></blockquote> +</li> +<li> +if <tt>i == E</tt> then <tt>i == x.end() && (y.begin() + (i - x.begin())) == y.end()</tt>. +</li> +<li> +Otherwise, returns <tt>false</tt>. +</li> +</ul> +<p> +<i>Throws:</i> Nothing unless an exception is thrown by the equality comparison. +</p> +<p> +<i>Complexity:</i> At most <tt>M</tt> comparisons. +</p> +</blockquote> +<pre>template <class T, class Allocator> +bool operator!=(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y); +</pre> +<blockquote> +<i>Returns:</i> <tt>!(x == y)</tt>. +</blockquote> +</blockquote> +</li> +</ul> +</blockquote> + +<p> +Option (B): +</p> +<blockquote> +<ul> +<li> +<p> +Add to the new section [forwardlist.compare] the following paragraphs: +</p> +<blockquote> +<pre>template <class T, class Allocator> +bool operator==(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y); +</pre> +<blockquote> +<p> +<i>Requires:</i> Type <tt>T</tt> is <tt>EqualityComparable</tt> ([equalitycomparable]). +</p> +<p> +<i>Returns:</i> <tt>distance(x.begin(), x.end()) == distance(y.begin(), y.end()) +&& equal(x.begin(), x.end(), y.begin())</tt>. +</p> +</blockquote> +<pre>template <class T, class Allocator> +bool operator!=(const forward_list<T,Allocator>& x, const forward_list<T,Allocator>& y); +</pre> +<blockquote> +<i>Returns:</i> <tt>!(x == y)</tt>. +</blockquote> +</blockquote> +</li> +</ul> +</blockquote> + + + + + +<hr> +<h3><a name="862"></a>862. Impossible complexity for 'includes'</h3> +<p><b>Section:</b> 25.3.5.1 [includes] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-07-02</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In 25.3.5.1 [includes] the complexity is "at most -1 comparisons" if passed +two empty ranges. I don't know how to perform a negative number of +comparisions! +</p> + +<p> +This same issue also applies to: +</p> + +<ul> +<li><tt>set_union</tt></li> +<li><tt>set_intersection</tt></li> +<li><tt>set_difference</tt></li> +<li><tt>set_symmetric_difference</tt></li> +<li><tt>merge</tt></li> +</ul> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="863"></a>863. What is the state of a stream after close() succeeds</h3> +<p><b>Section:</b> 27.8.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Steve Clamage <b>Date:</b> 2008-07-08</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fstreams">issues</a> in [fstreams].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Suppose writing to an <tt>[o]fstream</tt> fails and you later close the <tt>stream</tt>. +The <tt>overflow()</tt> function is called to flush the buffer (if it exists). +Then the file is unconditionally closed, as if by calling <tt>flcose</tt>. +</p> +<p> +If either <tt>overflow</tt> or <tt>fclose</tt> fails, <tt>close()</tt> reports failure, and clearly +the <tt>stream</tt> should be in a failed or bad state. +</p> +<p> +Suppose the buffer is empty or non-existent (so that <tt>overflow()</tt> does not +fail), and <tt>fclose</tt> succeeds. The <tt>close()</tt> function reports success, but +what is the state of the <tt>stream</tt>? +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="864"></a>864. Defect in atomic wording</h3> +<p><b>Section:</b> 29.4 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Anthony Williams <b>Date:</b> 2008-07-10</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.operations">issues</a> in [atomics.types.operations].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +There's an error in 29.4 [atomics.types.operations]/p9: +</p> + +<blockquote> +<pre>C atomic_load(const volatile A * object); +C atomic_load_explicit(const volatile A * object, memory_order); +C A ::load(memory_order order = memory_order_seq_cst) const volatile; +</pre> +<blockquote> +<p> +<i>Requires:</i> The <tt>order</tt> argument shall not be <tt>memory_order_acquire</tt> nor +<tt>memory_order_acq_rel</tt>. +</p> +</blockquote> +</blockquote> + +<p> +I believe that this should state +</p> +<blockquote> +shall not be <tt>memory_order_release</tt>. +</blockquote> + +<p> +There's also an error in 29.4 [atomics.types.operations]/p17: +</p> + +<blockquote> +... When only one <tt>memory_order</tt> argument is supplied, the value of success +is <tt>order</tt>, and +the value of failure is <tt>order</tt> except that a value of +<tt>memory_order_acq_rel</tt> shall be replaced by the value +<tt>memory_order_require</tt> ... +</blockquote> +<p> +I believe this should state +</p> +<blockquote> +shall be replaced by the value <tt>memory_order_acquire</tt> ... +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 29.4 [atomics.types.operations]/p9: +</p> + +<blockquote> +<pre>C atomic_load(const volatile A * object); +C atomic_load_explicit(const volatile A * object, memory_order); +C A ::load(memory_order order = memory_order_seq_cst) const volatile; +</pre> +<blockquote> +<p> +<i>Requires:</i> The <tt>order</tt> argument shall not be <del><tt>memory_order_acquire</tt></del> +<ins><tt>memory_order_release</tt></ins> nor <tt>memory_order_acq_rel</tt>. +</p> +</blockquote> +</blockquote> + +<p> +Change 29.4 [atomics.types.operations]/p17: +</p> + +<blockquote> +... When only one <tt>memory_order</tt> argument is supplied, the value of success +is <tt>order</tt>, and +the value of failure is <tt>order</tt> except that a value of +<tt>memory_order_acq_rel</tt> shall be replaced by the value +<del><tt>memory_order_require</tt></del> <ins><tt>memory_order_acquire</tt></ins> ... +</blockquote> + + + + + + +<hr> +<h3><a name="865"></a>865. More algorithms that throw away information</h3> +<p><b>Section:</b> 25.2.6 [alg.fill], 25.2.7 [alg.generate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-07-13</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In regard to library defect <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a> I found some more algorithms which +unnecessarily throw away information. These are typically algorithms, +which sequentially write into an <tt>OutputIterator</tt>, but do not return the +final value of this output iterator. These cases are: +</p> + +<ol> +<li> +<pre>template<class OutputIterator, class Size, class T> +void fill_n(OutputIterator first, Size n, const T& value);</pre></li> + +<li> +<pre>template<class OutputIterator, class Size, class Generator> +void generate_n(OutputIterator first, Size n, Generator gen);</pre></li> +</ol> +<p> +In both cases the minimum requirements on the iterator are +<tt>OutputIterator</tt>, which means according to the requirements of +24.1.2 [output.iterators]/2 that only single-pass iterations are guaranteed. +So, if users of <tt>fill_n</tt> and <tt>generate_n</tt> have *only* an <tt>OutputIterator</tt> +available, they have no chance to continue pushing further values +into it, which seems to be a severe limitation to me. +</p> + + +<p><b>Proposed resolution:</b></p> +<ol> +<li> +<p> +Replace the current declaration of <tt>fill_n</tt> in 25 [algorithms]/2, header +<tt><algorithm></tt> synopsis and in 25.2.6 [alg.fill] by +</p> + +<blockquote><pre>template<class OutputIterator, class Size, class T> +<del>void</del> <ins>OutputIterator</ins> fill_n(OutputIterator first, Size n, const T& value); +</pre></blockquote> +<p> +Just after the effects clause p.2 add a new returns clause saying: +</p> +<blockquote> +<i>Returns:</i> <tt>first + n</tt> for <tt>fill_n</tt>. +</blockquote> +</li> +<li> +<p> +Replace the current declaration of <tt>generate_n</tt> in 25 [algorithms]/2, header +<tt><algorithm></tt> synopsis and in 25.2.7 [alg.generate] by +</p> +<blockquote><pre>template<class OutputIterator, class Size, class Generator> +<del>void</del> <ins>OutputIterator</ins> generate_n(OutputIterator first, Size n, Generator gen); +</pre></blockquote> +<p> +Just after the effects clause p.1 add a new returns clause saying: +</p> +<blockquote> +<i>Returns:</i> <tt>first + n</tt> for <tt>generate_n</tt>. +</blockquote> +</li> +</ol> + + + + + +<hr> +<h3><a name="866"></a>866. Qualification of placement new-expressions</h3> +<p><b>Section:</b> 20.7.10 [specialized.algorithms], 20.7.12.2.6 [util.smartptr.shared.create] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Alberto Ganesh Barbati <b>Date:</b> 2008-07-14</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a> replaced "<tt>new</tt>" with "<tt>::new</tt>" in the placement +new-expression in 20.7.5.1 [allocator.members]. I believe the rationale +given in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a> applies also to the following other contexts: +</p> +<ul> +<li> +<p> +in 20.7.10 [specialized.algorithms], all four algorithms <tt>unitialized_copy</tt>, +<tt>unitialized_copy_n</tt>, <tt>unitialized_fill</tt> and <tt>unitialized_fill_n</tt> use +the unqualified placement new-expression in some variation of the form: +</p> +<blockquote><pre>new (static_cast<void*>(&*result)) typename iterator_traits<ForwardIterator>::value_type(*first); +</pre></blockquote> +</li> +<li> +<p> +in 20.7.12.2.6 [util.smartptr.shared.create] there is a reference to the unqualified placement new-expression: +</p> +<blockquote><pre>new (pv) T(std::forward<Args>(args)...), +</pre></blockquote> +</li> +</ul> +<p> +I suggest to add qualification in all those places. As far as I know, +these are all the remaining places in the whole library that explicitly +use a placement new-expression. Should other uses come out, they should +be qualified as well. +</p> +<p> +As an aside, a qualified placement new-expression does not need +additional requirements to be compiled in a constrained context. By +adding qualification, the <tt>HasPlacementNew</tt> concept introduced recently in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2677.pdf">N2677 (Foundational Concepts)</a> +would no longer be needed by library and +should therefore be removed. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Replace "<tt>new</tt>" with "<tt>::new</tt>" in: +</p> +<ul> +<li> +20.7.10.1 [uninitialized.copy], paragraphs 1 and 3 +</li> +<li> +20.7.10.2 [uninitialized.fill] paragraph 1 +</li> +<li> +20.7.10.3 [uninitialized.fill.n] paragraph 1 +</li> +<li> +20.7.12.2.6 [util.smartptr.shared.create] once in paragraph 1 and twice in paragraph 2. +</li> +</ul> + + + + + + +<hr> +<h3><a name="867"></a>867. Valarray and value-initialization</h3> +<p><b>Section:</b> 26.5.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Alberto Ganesh Barbati <b>Date:</b> 2008-07-20</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#valarray.cons">active issues</a> in [valarray.cons].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cons">issues</a> in [valarray.cons].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +From 26.5.2.1 [valarray.cons], paragraph 2: +</p> + +<blockquote><pre>explicit valarray(size_t); +</pre> +<blockquote> +The array created by this constructor has a length equal to the value of the argument. The elements +of the array are constructed using the default constructor for the instantiating type <tt>T</tt>. +</blockquote> +</blockquote> + +<p> +The problem is that the most obvious <tt>T</tt>s for <tt>valarray</tt> are <tt>float</tt> +and <tt>double</tt>, they don't have a default constructor. I guess the intent is to value-initialize +the elements, so I suggest replacing: +</p> + +<blockquote> +The elements of the array are constructed using the default constructor for the instantiating type <tt>T</tt>. +</blockquote> +<p> +with +</p> +<blockquote> +The elements of the array are value-initialized. +</blockquote> + +<p> +There is another reference to the default constructor of <tt>T</tt> in the non-normative note in paragraph 9. +That reference should also be replaced. (The normative wording in paragraph 8 refers to <tt>T()</tt> +and so it doesn't need changes). +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 26.5.2.1 [valarray.cons], paragraph 2: +</p> + +<blockquote> +<pre>explicit valarray(size_t); +</pre> +<blockquote> +The array created by this constructor has a length equal to the value of the argument. The elements +of the array are <del>constructed using the default constructor for the instantiating type <tt>T</tt></del> +<ins>value-initialized (8.5 [dcl.init])</ins>. +</blockquote> +</blockquote> + +<p> +Change 26.5.2.7 [valarray.members], paragraph 9: +</p> + +<blockquote> +[<i>Example:</i> If the argument has the value -2, the first two elements of the result will be <del>constructed using the +default constructor</del> +<ins>value-initialized (8.5 [dcl.init])</ins>; +the third element of the result will be assigned the value of the first element of the argument; etc. <i>-- end example</i>] +</blockquote> + + + + + + +<hr> +<h3><a name="868"></a>868. default construction and value-initialization</h3> +<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Alberto Ganesh Barbati <b>Date:</b> 2008-07-22</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The term "default constructed" is often used in wording that predates +the introduction of the concept of value-initialization. In a few such +places the concept of value-initialization is more correct than the +current wording (for example when the type involved can be a built-in) +so a replacement is in order. Two of such places are already covered by +issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</a>. This issue deliberately addresses the hopefully +non-controversial changes in the attempt of being approved more quickly. +A few other occurrences (for example in <tt>std::tuple</tt>, +<tt>std::reverse_iterator</tt> and <tt>std::move_iterator</tt>) are left to separate +issues. For <tt>std::reverse_iterator</tt>, see also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#408">408</a>. This issue is +related with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 20.1.1 [utility.arg.requirements], paragraph 2: +</p> + +<blockquote> +In general, a default constructor is not required. Certain container class member function signatures specify +<del>the default constructor</del> +<ins><tt>T()</tt></ins> +as a default argument. <tt>T()</tt> shall be a well-defined expression (8.5 [dcl.init]) if one of +those signatures is called using the default argument (8.3.6 [dcl.fct.default]). +</blockquote> + +<p> +In all the following paragraphs in clause 23 [containers], replace "default constructed" with "value-initialized +(8.5 [dcl.init])": +</p> + +<ul> +<li>23.2.2.1 [deque.cons] para 2</li> +<li>23.2.2.2 [deque.capacity] para 1</li> +<li>23.2.3.1 [forwardlist.cons] para 3</li> +<li>23.2.3.4 [forwardlist.modifiers] para 21</li> +<li>23.2.4.1 [list.cons] para 3</li> +<li>23.2.4.2 [list.capacity] para 1</li> +<li>23.2.6.1 [vector.cons] para 3</li> +<li>23.2.6.2 [vector.capacity] para 10</li> +</ul> + + + + + +<hr> +<h3><a name="869"></a>869. Bucket (local) iterators and iterating past end</h3> +<p><b>Section:</b> 23.1.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Sohail Somani <b>Date:</b> 2008-07-22</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Is there any language in the current draft specifying the behaviour of the following snippet? +</p> + +<blockquote><pre>unordered_set<int> s; +unordered_set<int>::local_iterator it = s.end(0); + +// Iterate past end - the unspecified part +it++; +</pre></blockquote> + +<p> +I don't think there is anything about <tt>s.end(n)</tt> being considered an +iterator for the past-the-end value though (I think) it should be. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change Table 97 "Unordered associative container requirements" in 23.1.5 [unord.req]: +</p> + +<blockquote> +<table border="1"> +<caption>Table 97: Unordered associative container requirements</caption> +<tbody><tr> +<th>expression</th><th>return type</th><th>assertion/note pre/post-condition</th><th>complexity</th> +</tr> +<tr> +<td><tt>b.begin(n)</tt></td> +<td><tt>local_iterator</tt><br><tt>const_local_iterator</tt> for const <tt>b</tt>.</td> +<td>Pre: n shall be in the range [0,b.bucket_count()). <del>Note: [b.begin(n), b.end(n)) is a +valid range containing all of the elements in the n<sup>th</sup> bucket.</del> +<ins><tt>b.begin(n)</tt> returns an iterator referring to the first element in the bucket. +If the bucket is empty, then <tt>b.begin(n) == b.end(n)</tt>.</ins></td> +<td>Constant</td> +</tr> +<tr> +<td><tt>b.end(n)</tt></td> +<td><tt>local_iterator</tt><br><tt>const_local_iterator</tt> for const <tt>b</tt>.</td> +<td>Pre: n shall be in the range <tt>[0, b.bucket_count())</tt>. +<ins><tt>b.end(n)</tt> returns an iterator which is the past-the-end value for the bucket.</ins></td> +<td>Constant</td> +</tr> +</tbody></table> +</blockquote> + + + + + + +<hr> +<h3><a name="870"></a>870. Do unordered containers not support function pointers for predicate/hasher?</h3> +<p><b>Section:</b> 23.1.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-08-17</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Good ol' associative containers allow both function pointers and +function objects as feasible +comparators, as described in 23.1.4 [associative.reqmts]/2: +</p> + +<blockquote> +Each associative container is parameterized on <tt>Key</tt> and an ordering +relation <tt>Compare</tt> that +induces a strict weak ordering (25.3) on elements of Key. [..]. The +object of type <tt>Compare</tt> is +called the comparison object of a container. This comparison object +may be a pointer to +function or an object of a type with an appropriate function call operator.[..] +</blockquote> + +<p> +The corresponding wording for unordered containers is not so clear, +but I read it to disallow +function pointers for the hasher and I miss a clear statement for the +equality predicate, see +23.1.5 [unord.req]/3+4+5: +</p> + +<blockquote> +<p> +Each unordered associative container is parameterized by <tt>Key</tt>, by a +function object <tt>Hash</tt> that +acts as a hash function for values of type <tt>Key</tt>, and by a binary +predicate <tt>Pred</tt> that induces an +equivalence relation on values of type <tt>Key</tt>.[..] +</p> +<p> +A hash function is a function object that takes a single argument of +type <tt>Key</tt> and returns a +value of type <tt>std::size_t</tt>. +</p> +<p> +Two values <tt>k1</tt> and <tt>k2</tt> of type <tt>Key</tt> are considered equal if the +container's equality function object +returns <tt>true</tt> when passed those values.[..] +</p> +</blockquote> + +<p> +and table 97 says in the column "assertion...post-condition" for the +expression X::hasher: +</p> + +<blockquote> +<tt>Hash</tt> shall be a unary function object type such that the expression +<tt>hf(k)</tt> has type <tt>std::size_t</tt>. +</blockquote> + +<p> +Note that 20.6 [function.objects]/1 defines as "Function objects are +objects with an <tt>operator()</tt> defined.[..]" +</p> +<p> +Does this restriction exist by design or is it an oversight? If an +oversight, I suggest that to apply +the following +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 23.1.5 [unord.req]/3, just after the second sentence which is written as +</p> + +<blockquote> +Additionally, <tt>unordered_map</tt> and <tt>unordered_multimap</tt> associate an +arbitrary mapped type <tt>T</tt> with the <tt>Key</tt>. +</blockquote> + +<p> +add one further sentence: +</p> + +<blockquote> +Both <tt>Hash</tt> and <tt>Pred</tt> may be pointers to function or objects of a type +with an appropriate function call operator. +</blockquote> + +<p> +[Note1: Since the detailed requirements for <tt>Pred</tt> and <tt>Hash</tt> are given in +p.4 and p.5, it an alternative resolution +would be to insert a new paragraph just after p.5, which contains the +above proposed sentence] +</p> +<p> +[Note2: I do not propose a change of above quoted element in table 97, +because the mis-usage of the +notion of "function object" seems already present in the standard at +several places, even if it includes +function pointers, see e.g. 25 [algorithms]/7. The important point is +that in those places a statement is +given that the actually used symbol, like "Predicate" applies for +function pointers as well] +</p> + + + + + +<hr> +<h3><a name="871"></a>871. Iota's requirements on T are too strong</h3> +<p><b>Section:</b> 26.6.5 [numeric.iota] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-08-20</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +According to the recent WP +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>, +26.6.5 [numeric.iota]/1, the requires clause +of <tt>std::iota</tt> says: +</p> + +<blockquote> +<tt>T</tt> shall meet the requirements of <tt>CopyConstructible</tt> and <tt>Assignable</tt> types, and +shall be convertible to <tt>ForwardIterator</tt>'s value type.[..] +</blockquote> + +<p> +Neither <tt>CopyConstructible</tt> nor <tt>Assignable</tt> is needed, instead <tt>MoveConstructible</tt> +seems to be the correct choice. I guess the current wording resulted as an +artifact from comparing it with similar numerical algorithms like <tt>accumulate</tt>. +</p> + +<p> +Note: If this function will be conceptualized, the here proposed +<tt>MoveConstructible</tt> +requirement can be removed, because this is an implied requirement of +function arguments, see +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2710.pdf">N2710</a>/[temp.req.impl]/3, last bullet. +</p> + + + +<p><b>Proposed resolution:</b></p> + +<p> +Change the first sentence of 26.6.5 [numeric.iota]/1: +</p> + +<blockquote> +<i>Requires:</i> <tt>T</tt> shall <del>meet the requirements of +<tt>CopyConstructible</tt> and <tt>Assignable</tt> types,</del> +<ins> +be <tt>MoveConstructible</tt> (Table 34) +</ins> +and shall be +convertible to <tt>ForwardIterator</tt>'s value type. [..] +</blockquote> + + + + + + +<hr> +<h3><a name="872"></a>872. <tt>move_iterator::operator[]</tt> has wrong return type</h3> +<p><b>Section:</b> 24.4.3.3.12 [move.iter.op.index] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Doug Gregor <b>Date:</b> 2008-08-21</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +<tt>move_iterator</tt>'s <tt>operator[]</tt> is declared as: +</p> + +<blockquote><pre>reference operator[](difference_type n) const; +</pre></blockquote> + +<p> +This has the same problem that <tt>reverse_iterator</tt>'s <tt>operator[]</tt> used to +have: if the underlying iterator's <tt>operator[]</tt> returns a proxy, the +implicit conversion to <tt>value_type&&</tt> could end up referencing a temporary +that has already been destroyed. This is essentially the same issue that +we dealt with for <tt>reverse_iterator</tt> in DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#386">386</a>. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 24.4.3.1 [move.iterator] and 24.4.3.3.12 [move.iter.op.index], change the declaration of +<tt>move_iterator</tt>'s <tt>operator[]</tt> to: +</p> + +<blockquote><pre><del>reference</del> <ins><i>unspecified</i></ins> operator[](difference_type n) const; +</pre></blockquote> + + + + + + +<hr> +<h3><a name="873"></a>873. signed integral type and unsigned integral type are not clearly defined</h3> +<p><b>Section:</b> 3.9.1 [basic.fundamental] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Travis Vitek <b>Date:</b> 2008-06-30</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> + <p> + Neither the term "signed integral type" nor the term "unsigned + integral type" is defined in the core language section of the + standard, therefore the library section should avoid its use. The + terms <i>signed integer type</i> and <i>unsigned integer type</i> are + indeed defined (in 3.9.1 [basic.fundamental]), thus the usages should be + replaced accordingly. + </p> + + <p> + Note that the key issue here is that "signed" + "integral type" != + "signed integral type". + + The types <code>bool</code>, <code>char</code>, <code>char16_t</code>, + <code>char32_t</code> and <code>wchar_t</code> are all listed as + integral types, but are neither of <i>signed integer type</i> or + <i>unsigned integer type</i>. According to 3.9 [basic.types] p7, a synonym for + integral type is <i>integer type</i>. + + Given this, one may choose to assume that an <i>integral type</i> that + can represent values less than zero is a <i>signed integral type</i>. + Unfortunately this can cause ambiguities. + + As an example, if <code>T</code> is <code>unsigned char</code>, the + expression <code>make_signed<T>::type</code>, is supposed to + name a signed integral type. There are potentially two types that + satisfy this requirement, namely <code>signed char</code> and + <code>char</code> (assuming <code>CHAR_MIN < 0</code>). + </p> + + + <p><b>Proposed resolution:</b></p> + <p> + I propose to use the terms "signed integer type" and "unsigned integer + type" in place of "signed integral type" and "unsigned integral type" + to eliminate such ambiguities. + </p> + + <p> + The proposed change makes it absolutely clear that the difference + between two pointers cannot be <tt>char</tt> or <tt>wchar_t</tt>, + but could be any of the signed integer types. + 5.7 [expr.add] paragraph 6... + </p> + <blockquote> + <p> + </p><ol> + <li> + When two pointers to elements of the same array object are + subtracted, the result is the difference of the subscripts of + the two array elements. The type of the result is an + implementation-defined <del>signed integral + type</del><ins>signed integer type</ins>; this type shall be the + same type that is defined as <code>std::ptrdiff_t</code> in the + <code><cstdint></code> header (18.1)... + </li> + </ol> + + </blockquote> + + <p> + The proposed change makes it clear that <tt>X::size_type</tt> and + <tt>X::difference_type</tt> cannot be <tt>char</tt> or + <tt>wchar_t</tt>, but could be one of the signed or unsigned integer + types as appropriate. + 20.1.2 [allocator.requirements] table 40... + </p> + <blockquote> + Table 40: Allocator requirements + <table border="1"> + <thead> + <tr> + <th>expression</th> + <th>return type</th> + <th>assertion/note/pre/post-condition</th> + </tr> + </thead> + <tbody> + <tr> + <td><tt>X::size_type</tt></td> + <td> + <del>unsigned integral type</del> + <ins>unsigned integer type</ins> + </td> + <td>a type that can represent the size of the largest object in + the allocation model.</td> + </tr> + <tr> + <td><tt>X::difference_type</tt></td> + <td> + <del>signed integral type</del> + <ins>signed integer type</ins> + </td> + <td>a type that can represent the difference between any two + pointers in the allocation model.</td> + </tr> + </tbody> + </table> + </blockquote> + + <p> + The proposed change makes it clear that <tt>make_signed<T>::type</tt> + must be one of the signed integer types as defined in 3.9.1. Ditto for + <tt>make_unsigned<T>type</tt> and unsigned integer types. + 20.5.6.3 [meta.trans.sign] table 48... + </p> + <blockquote> + Table 48: Sign modifications + <table border="1"> + <thead> + <tr> + <th>Template</th> + <th>Comments</th> + </tr> + </thead> + <tbody> + <tr> + <td> + <tt>template <class T> struct make_signed;</tt> + </td> + <td> + If <code>T</code> names a (possibly cv-qualified) <del>signed + integral type</del><ins>signed integer type</ins> (3.9.1) then + the member typedef <code>type</code> shall name the type + <code>T</code>; otherwise, if <code>T</code> names a (possibly + cv-qualified) <del>unsigned integral type</del><ins>unsigned + integer type</ins> then <code>type</code> shall name the + corresponding <del>signed integral type</del><ins>signed + integer type</ins>, with the same cv-qualifiers as + <code>T</code>; otherwise, <code>type</code> shall name the + <del>signed integral type</del><ins>signed integer type</ins> + with the smallest rank (4.13) for which <code>sizeof(T) == + sizeof(type)</code>, with the same cv-qualifiers as + <code>T</code>. + + <i>Requires:</i> <code>T</code> shall be a (possibly + cv-qualified) integral type or enumeration but not a + <code>bool</code> type. + </td> + </tr> + <tr> + <td> + <tt>template <class T> struct make_unsigned;</tt> + </td> + <td> + If <code>T</code> names a (possibly cv-qualified) + <del>unsigned integral type</del><ins>unsigned integer + type</ins> (3.9.1) then the member typedef <code>type</code> + shall name the type <code>T</code>; otherwise, if + <code>T</code> names a (possibly cv-qualified) <del>signed + integral type</del><ins>signed integer type</ins> then + <code>type</code> shall name the corresponding <del>unsigned + integral type</del><ins>unsigned integer type</ins>, with the + same cv-qualifiers as <code>T</code>; otherwise, + <code>type</code> shall name the <del>unsigned integral + type</del><ins>unsigned integer type</ins> with the smallest + rank (4.13) for which <code>sizeof(T) == sizeof(type)</code>, + with the same cv-qualifiers as <code>T</code>. + + <i>Requires:</i> <code>T</code> shall be a (possibly + cv-qualified) integral type or enumeration but not a + <code>bool</code> type. + </td> + </tr> + </tbody> + </table> + </blockquote> + + + <p> + Note: I believe that the basefield values should probably be + prefixed with <tt>ios_base::</tt> as they are in 22.2.2.2.2 [facet.num.put.virtuals] + + The listed virtuals are all overloaded on signed and unsigned integer + types, the new wording just maintains consistency. + + 22.2.2.1.2 [facet.num.get.virtuals] table 78... + </p> + <blockquote> + Table 78: Integer Conversions + <table border="1"> + <thead> + <tr> + <th>State</th> + <th><tt>stdio</tt> equivalent</th> + </tr> + </thead> + <tbody> + <tr> + <td><tt>basefield == oct</tt></td> + <td><tt>%o</tt></td> + </tr> + <tr> + <td><tt>basefield == hex</tt></td> + <td><tt>%X</tt></td> + </tr> + <tr> + <td><tt>basefield == 0</tt></td> + <td><tt>%i</tt></td> + </tr> + <tr> + <td><del>signed integral type</del><ins>signed integer + type</ins></td> + <td><tt>%d</tt></td> + </tr> + <tr> + <td><del>unsigned integral type</del><ins>unsigned integer + type</ins></td> + <td><tt>%u</tt></td> + </tr> + </tbody> + </table> + </blockquote> + + + + <p> + Rationale is same as above. + 22.2.2.2.2 [facet.num.put.virtuals] table 80... + </p> + <blockquote> + Table 80: Integer Conversions + <table border="1"> + <thead> + <tr> + <th>State</th> + <th><tt>stdio</tt> equivalent</th> + </tr> + </thead> + <tbody> + <tr> + <td><tt>basefield == ios_base::oct</tt></td> + <td><tt>%o</tt></td> + </tr> + <tr> + <td><tt>(basefield == ios_base::hex) && + !uppercase</tt></td> + <td><tt>%x</tt></td> + </tr> + <tr> + <td><tt>(basefield == ios_base::hex)</tt></td> + <td><tt>%X</tt></td> + </tr> + <tr> + <td><tt>basefield == 0</tt></td> + <td><tt>%i</tt></td> + </tr> + <tr> + <td>for a <del>signed integral type</del><ins>signed integer + type</ins></td> + <td><tt>%d</tt></td> + </tr> + <tr> + <td>for a <del>unsigned integral type</del><ins>unsigned integer + type</ins></td> + <td><tt>%u</tt></td> + </tr> + </tbody> + </table> + </blockquote> + + + <p> + 23.1 [container.requirements] table 80... + </p> + <blockquote> + Table 89: Container requirements + <table border="1"> + <thead> + <tr> + <th>expression</th> + <th>return type</th> + <th>operational semantics</th> + <th>assertion/note/pre/post-condition</th> + <th>complexity</th> + </tr> + </thead> + <tbody> + <tr> + <td><tt>X::difference_type</tt></td> + <td><del>signed integral type</del><ins>signed integer type</ins></td> + <td> </td> + <td>is identical to the difference type of <tt>X::iterator</tt> + and <tt>X::const_iterator</tt></td> + <td>compile time</td> + </tr> + <tr> + <td><tt>X::size_type</tt></td> + <td><del>unsigned integral type</del><ins>unsigned integer type</ins></td> + <td> </td> + <td><tt>size_type</tt> can represent any non-negative value of + <tt>difference_type</tt></td> + <td>compile time</td> + </tr> + </tbody> + </table> + </blockquote> + + <p> + 24.1 [iterator.requirements] paragraph 1... + </p> + <blockquote> + Iterators are a generalization of pointers that allow a C++ program to + work with different data structures (containers) in a uniform manner. + To be able to construct template algorithms that work correctly and + efficiently on different types of data structures, the library + formalizes not just the interfaces but also the semantics and + complexity assumptions of iterators. All input iterators + <code>i</code> support the expression <code>*i</code>, resulting in a + value of some class, enumeration, or built-in type <code>T</code>, + called the <i>value type</i> of the iterator. All output iterators + support the expression <code>*i = o</code> where <code>o</code> is a + value of some type that is in the set of types that are + <i>writable</i> to the particular iterator type of <code>i</code>. All + iterators <code>i</code> for which the expression <code>(*i).m</code> + is well-defined, support the expression <code>i->m</code> with the + same semantics as <code>(*i).m</code>. For every iterator type + <code>X</code> for which equality is defined, there is a corresponding + <del>signed integral type</del> <ins>signed integer type</ins> called + the <i>difference type</i> of the iterator. + </blockquote> + + <p> + I'm a little unsure of this change. Previously this paragraph would + allow instantiations of <tt>linear_congruential_engine</tt> on + <tt>char</tt>, <tt>wchar_t</tt>, <tt>bool</tt>, and other types. The + new wording prohibits this. + 26.4.3.1 [rand.eng.lcong] paragraph 2... + </p> + <blockquote> + The template parameter <code>UIntType</code> shall denote an + <del>unsigned integral type</del><ins>unsigned integer type</ins> + large enough to store values as large as <code>m - 1</code>. If the + template parameter <code>m</code> is 0, the modulus <code>m</code> + used throughout this section 26.4.3.1 is + <code>numeric_limits<result_type>::max()</code> plus 1. [Note: + The result need not be representable as a value of type + <code>result_type</code>. --end note] Otherwise, the following + relations shall hold: <code>a < m</code> and <code>c < + m</code>. + </blockquote> + + <p> + Same rationale as the previous change. + 26.4.4.4 [rand.adapt.xor] paragraph 6... + </p> + <blockquote> + Both <code>Engine1::result_type</code> and + <code>Engine2::result_type</code> shall denote (possibly different) + <del>unsigned integral types</del><ins>unsigned integer types</ins>. + The member <i>result_type</i> shall denote either the type + <i>Engine1::result_type</i> or the type <i>Engine2::result_type</i>, + whichever provides the most storage according to clause 3.9.1. + </blockquote> + + <p> + 26.4.7.1 [rand.util.seedseq] paragraph 7... + </p> + <blockquote> + <i>Requires:</i><code>RandomAccessIterator</code> shall meet the + requirements of a random access iterator (24.1.5) such that + <code>iterator_traits<RandomAccessIterator>::value_type</code> + shall denote an <del>unsigned integral type</del><ins>unsigned integer + type</ins> capable of accomodating 32-bit quantities. + </blockquote> + + <p> + By making this change, integral types that happen to have a signed + representation, but are not signed integer types, would no longer be + required to use a two's complement representation. This may go against + the original intent, and should be reviewed. + 29.4 [atomics.types.operations] paragraph 24... + </p> + <blockquote> + <i>Remark:</i> For <del>signed integral types</del><ins>signed integer + types</ins>, arithmetic is defined using two's complement + representation. There are no undefined results. For address types, the + result may be an undefined address, but the operations otherwise have + no undefined behavior. + </blockquote> + + + + + + +<hr> +<h3><a name="874"></a>874. Missing <tt>initializer_list</tt> constructor for <tt>discrete_distribution</tt></h3> +<p><b>Section:</b> 26.4.8.5.1 [rand.dist.samp.discrete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-08-22</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.discrete">active issues</a> in [rand.dist.samp.discrete].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.discrete">issues</a> in [rand.dist.samp.discrete].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +During the Sophia Antipolis meeting it was decided to separate from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a> a +subrequest that adds initializer list support to +<tt>discrete_distribution</tt>, specifically, +the issue proposed to add a c'tor taking a <tt>initializer_list<double></tt>. +</p> + + + +<p><b>Proposed resolution:</b></p> +<ol> +<li> +<p> +In 26.4.8.5.1 [rand.dist.samp.discrete]/1, class <tt>discrete_distribution</tt>, +just <em>before</em> the member declaration +</p> + +<blockquote><pre>explicit discrete_distribution(const param_type& parm); +</pre></blockquote> + +<p> +insert +</p> + +<blockquote><pre>discrete_distribution(initializer_list<double> wl); +</pre></blockquote> +</li> + +<li> +<p> +Between p.4 and p.5 of the same section insert a new +paragraph as part of the new member description: +</p> + +<blockquote><pre>discrete_distribution(initializer_list<double> wl); +</pre> + +<blockquote> +<i>Effects:</i> Same as <tt>discrete_distribution(wl.begin(), wl.end())</tt>. +</blockquote> +</blockquote> +</li> +</ol> + + + + + +<hr> +<h3><a name="875"></a>875. Missing <tt>initializer_list</tt> constructor for <tt>piecewise_constant_distribution</tt></h3> +<p><b>Section:</b> 26.4.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-08-22</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.pconst">active issues</a> in [rand.dist.samp.pconst].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +During the Sophia Antipolis meeting it was decided to separate from +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#794">794</a> a subrequest that adds initializer list support to +<tt>piecewise_constant_distribution</tt>, specifically, the issue proposed +to add a c'tor taking a <tt>initializer_list<double></tt> and a <tt>Callable</tt> to evaluate +weight values. For consistency with the remainder of this class and +the remainder of the <tt>initializer_list</tt>-aware library the author decided to +change the list argument type to the template parameter <tt>RealType</tt> +instead. For the reasoning to use <tt>Func</tt> instead of <tt>Func&&</tt> as c'tor +function argument see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>. +</p> + + +<p><b>Proposed resolution:</b></p> +<ol> +<li> +<p> +In 26.4.8.5.2 [rand.dist.samp.pconst]/1, class <tt>piecewise_constant_distribution</tt>, +just <em>before</em> the member declaration +</p> + +<blockquote><pre>explicit piecewise_constant_distribution(const param_type& parm); +</pre></blockquote> + +<p> +insert +</p> + +<blockquote><pre>template<typename Func> +piecewise_constant_distribution(initializer_list<RealType> bl, Func fw); +</pre></blockquote> +</li> + +<li> +<p> +Between p.4 and p.5 of the same section insert a series of +new paragraphs nominated below as [p5_1], [p5_2], and [p5_3] +as part of the new member description: +</p> + +<blockquote><pre>template<typename Func> +piecewise_constant_distribution(initializer_list<RealType> bl, Func fw); +</pre> + +<blockquote> + +<p> +[p5_1] <i>Complexity:</i> Exactly <tt>nf = max(bl.size(), 1) - 1</tt> invocations of <tt>fw</tt>. +</p> + +<p> +[p5_2] <i>Requires:</i> +</p> + +<ol type="a"> +<li> +<tt>fw</tt> shall be callable with one argument of type <tt>RealType</tt>, and shall + return values of a type convertible to <tt>double</tt>; +</li> +<li> +The relation <tt>0 < S = w<sub>0</sub>+. . .+w<sub>n-1</sub></tt> shall hold. +For all sampled values <tt><i>x<sub>k</sub></i></tt> defined below, <tt>fw(<i>x<sub>k</sub></i>)</tt> shall return a weight + value <tt><i>w<sub>k</sub></i></tt> that is non-negative, non-NaN, and non-infinity; +</li> +<li> +If <tt>nf > 0</tt> let <tt>b<sub><i>k</i></sub> = *(bl.begin() + k), k = 0, . . . , bl.size()-1</tt> and the +following relations shall hold for <tt>k = 0, . . . , nf-1: b<sub><i>k</i></sub> < b<sub><i>k+1</i></sub></tt>. +</li> +</ol> + +<p> +[p5_3] <i>Effects:</i> +</p> + +<ol type="a"> +<li> +<p>If <tt>nf == 0</tt>,</p> +<ol type="a"> +<li> +lets the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist of the single + value <tt>w<sub>0</sub> = 1</tt>, and +</li> +<li> +lets the sequence <tt>b</tt> have length <tt>n+1</tt> with <tt>b<sub>0</sub> = 0</tt> and <tt>b<sub>1</sub> = 1</tt>. +</li> +</ol> +</li> + +<li> +<p>Otherwise,</p> +<ol type="a"> +<li> +sets <tt>n = nf</tt>, and <tt>[bl.begin(), bl.end())</tt> shall form the sequence <tt>b</tt> of +length <tt>n+1</tt>, and +</li> +<li> +<p>lets the sequences <tt>w</tt> have length <tt>n</tt> and for each <tt>k = 0, . . . ,n-1</tt>, + calculates:</p> +<blockquote><pre>x<sub><i>k</i></sub> = 0.5*(b<sub><i>k+1</i></sub> + b<sub><i>k</i></sub>) +w<sub><i>k</i></sub> = fw(x<sub><i>k</i></sub>) +</pre></blockquote> +</li> +</ol> +</li> + +<li> +<p> +Constructs a <tt>piecewise_constant_distribution</tt> object with +the above computed sequence <tt>b</tt> as the interval boundaries +and with the probability densities: +</p> +<blockquote><pre>ρ<sub><i>k</i></sub> = w<sub><i>k</i></sub>/(S * (b<sub><i>k+1</i></sub> - b<sub><i>k</i></sub>)) for k = 0, . . . , n-1. +</pre></blockquote> + +</li> +</ol> + +</blockquote> +</blockquote> +</li> +</ol> + + + + + +<hr> +<h3><a name="876"></a>876. <tt>basic_string</tt> access operations should give stronger guarantees</h3> +<p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-08-22</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +During the Sophia Antipolis meeting it was decided to split-off some +parts of the +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2647.html">n2647</a> +("Concurrency modifications for <tt>basic_string</tt>") +proposal into a separate issue, because these weren't actually +concurrency-related. The here proposed changes refer to the recent +update document +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2668.htm">n2668</a> +and attempt to take advantage of the +stricter structural requirements. +</p> +<p> +Indeed there exists some leeway for more guarantees that would be +very useful for programmers, especially if interaction with transactionary +or exception-unaware C API code is important. This would also allow +compilers to take advantage of more performance optimizations, because +more functions can have throw() specifications. This proposal uses the +form of "Throws: Nothing" clauses to reach the same effect, because +there already exists a different issue in progress to clean-up the current +existing "schizophrenia" of the standard in this regard. +</p> +<p> +Due to earlier support for copy-on-write, we find the following +unnecessary limitations for C++0x: +</p> + +<ol> +<li> +Missing no-throw guarantees: <tt>data()</tt> and <tt>c_str()</tt> simply return +a pointer to their guts, which is a non-failure operation. This should +be spelled out. It is also noteworthy to mention that the same +guarantees should also be given by the size query functions, +because the combination of pointer to content and the length is +typically needed during interaction with low-level API. +</li> +<li> +Missing complexity guarantees: <tt>data()</tt> and <tt>c_str()</tt> simply return +a pointer to their guts, which is guaranteed O(1). This should be +spelled out. +</li> +<li> +Missing reading access to the terminating character: Only the +const overload of <tt>operator[]</tt> allows reading access to the terminator +char. For more intuitive usage of strings, reading access to this +position should be extended to the non-const case. In contrast +to C++03 this reading access should now be homogeneously +an lvalue access. +</li> +</ol> + +<p> +The proposed resolution is split into a main part (A) and a +secondary part (B) (earlier called "Adjunct Adjunct Proposal"). +(B) extends (A) by also making access to index position +size() of the at() overloads a no-throw operation. This was +separated, because this part is theoretically observable in +specifically designed test programs. +</p> + + +<p><b>Proposed resolution:</b></p> +<ol type="A"> +<li> +<ol> +<li> +<p>In 21.3.4 [string.capacity], just after p. 1 add a new paragraph: +</p> +<blockquote> +<i>Throws:</i> Nothing. +</blockquote> + +</li> +<li> +<p> +In 21.3.5 [string.access] <em>replace</em> p. 1 by the following <em>4</em> paragraghs: +</p> + +<blockquote> +<p> +<i>Requires:</i> <tt>pos ≤ size()</tt>. +</p> +<p> +<i>Returns:</i> If <tt>pos < size()</tt>, returns <tt>*(begin() + pos)</tt>. Otherwise, returns +a reference to a <tt>charT()</tt> that shall not be modified. +</p> +<p> +<i>Throws:</i> Nothing. +</p> +<p> +<i>Complexity:</i> Constant time. +</p> +</blockquote> + +</li> +<li> +<p> +In 21.3.7.1 [string.accessors] replace the now <em>common</em> returns +clause of <tt>c_str()</tt> and <tt>data()</tt> by the following <em>three</em> paragraphs: +</p> +<blockquote> +<p> +<i>Returns:</i> A pointer <tt>p</tt> such that <tt>p+i == &operator[](i)</tt> for each <tt>i</tt> +in <tt>[0, size()]</tt>. +</p> +<p> +<i>Throws:</i> Nothing. +</p> +<p> +<i>Complexity:</i> Constant time. +</p> +</blockquote> +</li> +</ol> +</li> +<li> +<ol start="4"> +<li> +<p> +In 21.3.5 [string.access] <em>replace</em> p.2 and p.3 by: +</p> +<blockquote> +<p> +<i>Requires:</i> <tt>pos ≤ size()</tt> +</p> +<p> +<i>Throws:</i> <tt>out_of_range</tt> if <tt>pos > size()</tt>. +</p> +</blockquote> +</li> +</ol> +</li> +</ol> + + + + + + +<hr> +<h3><a name="877"></a>877. to <tt>throw()</tt> or to <i>Throw:</i> Nothing.</h3> +<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-08-23</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +Recent changes to +the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">working +draft</a> have introduced a gratuitous inconsistency with the C++ 2003 +version of the specification with respect to exception guarantees +provided by standard functions. While the C++ 2003 standard +consistenly uses the empty exception specification, <tt>throw()</tt>, +to declare functions that are guaranteed not to throw exceptions, the +current working draft contains a number of "<i>Throws:</i> Nothing." +clause to specify essentially the same requirement. The difference +between the two approaches is that the former specifies the behavior +of programs that violate the requirement (<tt>std::unexpected()</tt> +is called) while the latter leaves the behavior undefined. + + </p> + <p> + +A survey of the working draft reveals that there are a total of 209 +occurrences of <tt>throw()</tt> in the library portion of the spec, +the majority in clause 18, a couple (literally) in 19, a handful in +20, a bunch in 22, four in 24, one in 27, and about a dozen in D.9. + + </p> + <p> + +There are also 203 occurrences of "<i>Throws:</i> Nothing." scattered +throughout the spec. + + </p> + <p> + +While sometimes there are good reasons to use the "<i>Throws:</i> +Nothing." approach rather than making use of <tt>throw()</tt>, these +reasons do not apply in most of the cases where this new clause has +been introduced and the empty exception specification would be a +better approach. + + </p> + <p> + +First, functions declared with the empty exception specification +permit compilers to generate better code for calls to such +functions. In some cases, the compiler might even be able to eliminate +whole chunks of user-written code when instantiating a generic +template on a type whose operations invoked from the template +specialization are known not to throw. The prototypical example are +the <tt>std::uninitialized_copy()</tt> +and <tt>std::uninitialized_fill()</tt> algorithms where the +entire <tt>catch(...)</tt> block can be optimized away. + + </p> + <p> + +For example, given the following definition of +the <tt>std::uninitialized_copy</tt> function template and a +user-defined type <tt>SomeType</tt>: + + </p> + <blockquote> + <pre>template <class InputIterator, class ForwardIterator> +ForwardIterator +uninitialized_copy (InputIterator first, InputIterator last, ForwardIterator res) +{ + typedef iterator_traits<ForwardIterator>::value_type ValueType; + + ForwardIterator start = res; + + try { + for (; first != last; ++first, ++res) + ::new (&*res) ValueType (*first); + } + catch (...) { + for (; start != res; --start) + (&*start)->~ValueType (); + throw; + } + return res; +} + +struct SomeType { + SomeType (const SomeType&) <ins>throw ()</ins>; +}</pre> + </blockquote> + <p> + +compilers are able to emit the following efficient specialization +of <tt>std::uninitialized_copy<const SomeType*, SomeType*></tt> +(note that the <tt>catch</tt> block has been optimized away): + + </p> + <blockquote> + <pre>template <> SomeType* +uninitialized_copy (const SomeType *first, const SomeType *last, SomeType *res) +{ + for (; first != last; ++first, ++res) + ::new (res) SomeType (*first); + + return res; +}</pre> + </blockquote> + <p> + +Another general example is default constructors which, when decorated +with <tt>throw()</tt>, allow the compiler to eliminate the +implicit <tt>try</tt> and <tt>catch</tt> blocks that it otherwise must +emit around each the invocation of the constructor +in <i>new-expressions</i>. + + </p> + <p> + +For example, given the following definitions of +class <tt>MayThrow</tt> and <tt>WontThrow</tt> and the two +statements below: + + </p> + <blockquote> + <pre>struct MayThrow { + MayThrow (); +}; + +struct WontThrow { + WontThrow () <ins>throw ()</ins>; +}; + +MayThrow *a = new MayThrow [N]; +WontThrow *b = new WontThrow [N];</pre> + + </blockquote> + <p> + +the compiler generates the following code for the first statement: + + </p> + <blockquote> + <pre>MayThrow *a; +{ + MayThrow *first = operator new[] (N * sizeof (*a)); + MayThrow *last = first + N; + MayThrow *next = first; + try { + for ( ; next != last; ++next) + new (next) MayThrow; + } + catch (...) { + for ( ; first != first; --next) + next->~MayThrow (); + operator delete[] (first); + throw; + } + a = first; +}</pre> + </blockquote> + <p> + +but it is can generate much more compact code for the second statement: + + </p> + <blockquote> + <pre>WontThrow *b = operator new[] (N * sizeof (*b)); +WontThrow *last = b + N; +for (WontThrow *next = b; next != last; ++next) + new (next) WontThrow; +</pre> + </blockquote> + <p> + +Second, in order for users to get the maximum benefit out of the new +<tt>std::has_nothrow_xxx</tt> traits when using standard library types +it will be important for implementations to decorate all non throwing +copy constructors and assignment operators with <tt>throw()</tt>. Note +that while an optimizer may be able to tell whether a function without +an explicit exception specification can throw or not based on its +definition, it can only do so when it can see the source code of the +definition. When it can't it must assume that the function may +throw. To prevent violating the One Definition Rule, +the <tt>std::has_nothrow_xxx</tt> trait must return the most +pessimistic guess across all translation units in the program, meaning +that <tt>std::has_nothrow_xxx<T>::value</tt> must evaluate to +<tt>false</tt> for any <tt>T</tt> whose <tt>xxx</tt> +(where <tt>xxx</tt> is default or copy ctor, or assignment operator) +is defined out-of-line. + + </p> + <p> + +<b>Counterarguments:</b> + + </p> + <p> + +During the discussion of this issue +on <a href="mailto:c++std-lib@accu.org">c++std-lib@accu.org</a> +(starting with post <tt>c++std-lib-21950</tt>) the following arguments +in favor of the "<i>Throws:</i> Nothing." style have been made. + + </p> + <p> + </p><ol> + <li> + +Decorating functions that cannot throw with the empty exception +specification can cause the compiler to generate suboptimal code for +the implementation of the function when it calls other functions that +aren't known to the compiler not to throw (i.e., that aren't decorated +with <tt>throw()</tt> even if they don't actually throw). This is a +common situation when the called function is a C or POSIX function. + + </li> + <li> + +Alternate, proprietary mechanisms exist (such as +GCC <a href="http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Function-Attributes.html#index-g_t_0040code_007bnothrow_007d-function-attribute-2160"><tt>__attribute__((nothrow))</tt></a> +or Visual +C++ <a href="http://msdn.microsoft.com/en-us/library/49147z04%28VS.80%29.aspx"><tt>__declspec(nothrow)</tt></a>) +that let implementers mark up non-throwing functions, often without +the penalty mentioned in (1) above. The C++ standard shouldn't +preclude the use of these potentially more efficient mechanisms. + + </li> + <li> + +There are functions, especially function templates, that invoke +user-defined functions that may or may not be +declared <tt>throw()</tt>. Declaring such functions with the empty +exception specification will cause compilers to generate suboptimal +code when the user-defined function isn't also declared not to throw. + + </li> + </ol> + + <p> + +The answer to point (1) above is that implementers can (and some have) +declare functions with <tt>throw()</tt> to indicate to the compiler +that calls to the function can safely be assumed not to throw in order +to allow it to generate efficient code at the call site without also +having to define the functions the same way and causing the compiler +to generate suboptimal code for the function definition. That is, the +function is declared with <tt>throw()</tt> in a header but it's +defined without it in the source file. The <tt>throw()</tt> +declaration is suppressed when compiling the definition to avoid +compiler errors. This technique, while strictly speaking no permitted +by the language, is safe and has been employed in practice. For +example, the GNU C library takes this approach. Microsoft Visual C++ +takes a similar approach by simply assuming that no function with C +language linkage can throw an exception unless it's explicitly +declared to do so using the language extension <tt>throw(...)</tt>. + + </p> + <p> + +Our answer to point (2) above is that there is no existing practice +where C++ Standard Library implementers have opted to make use of the +proprietary mechanisms to declare functions that don't throw. The +language provides a mechanism specifically designed for this +purpose. Avoiding its use in the specification itself in favor of +proprietary mechanisms defeats the purpose of the feature. In +addition, making use of the empty exception specification +inconsistently, in some areas of the standard, while conspicuously +avoiding it and making use of the "<i>Throws:</i> Nothing." form in +others is confusing to users. + + </p> + <p> + +The answer to point (3) is simply to exercise caution when declaring +functions and especially function templates with the empty exception +specification. Functions that required not to throw but that may call +back into user code are poor candidates for the empty exception +specification and should instead be specified using "<i>Throws:</i> +Nothing." clause. + + </p> + + <p><b>Proposed resolution:</b></p> + <p> + +We propose two possible solutions. Our recommendation is to adopt +Option 1 below. + + </p> + <p> + +<b>Option 1:</b> + + </p> + <p> + +Except for functions or function templates that make calls back to +user-defined functions that may not be declared <tt>throw()</tt> +replace all occurrences of the "<i>Throws:</i> Nothing." clause with +the empty exception specification. Functions that are required not to +throw but that make calls back to user code should be specified to +"<i>Throw:</i> Nothing." + + </p> + <p> + +<b>Option 2:</b> + + </p> + <p> + +For consistency, replace all occurrences of the empty exception +specification with a "<i>Throws:</i> Nothing." clause. + + </p> + + + + +<hr> +<h3><a name="878"></a>878. <tt>forward_list</tt> preconditions</h3> +<p><b>Section:</b> 23.2.3 [forwardlist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-08-23</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +<tt>forward_list</tt> member functions that take +a <tt>forward_list::iterator</tt> (denoted <tt>position</tt> in the +function signatures) argument have the following precondition: + + </p> + <blockquote> + +<i>Requires:</i> <tt>position</tt> is dereferenceable or equal +to <tt>before_begin()</tt>. + + </blockquote> + <p> + +I believe what's actually intended is this: + + </p> + <blockquote> + +<i>Requires:</i> <tt>position</tt> is in the range +[<tt>before_begin()</tt>, <tt>end()</tt>). + + </blockquote> + <p> + +That is, when it's dereferenceable, <tt>position</tt> must point +into <tt>*this</tt>, not just any <tt>forward_list</tt> object. + + </p> + + <p><b>Proposed resolution:</b></p> + <p> + +Change the <i>Requires</i> clause as follows: + + </p> + <blockquote> + +<i>Requires:</i> <tt>position</tt> is <ins>in the range +[<tt>before_begin()</tt>, <tt>end()</tt>)</ins> <del>dereferenceable +or equal to <tt>before_begin()</tt></del>. + + </blockquote> + + + </body></html>
\ No newline at end of file diff --git a/libstdc++-v3/doc/html/ext/lwg-closed.html b/libstdc++-v3/doc/html/ext/lwg-closed.html index 68bca503aa2..a056c3ee249 100644 --- a/libstdc++-v3/doc/html/ext/lwg-closed.html +++ b/libstdc++-v3/doc/html/ext/lwg-closed.html @@ -1,22 +1,24 @@ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> -<html><head><title>C++ Standard Library Closed Issues List</title> - +<html><head> +<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> +<title>C++ Standard Library Closed Issues List</title> <style type="text/css"> p {text-align:justify} li {text-align:justify} ins {background-color:#A0FFA0} del {background-color:#FFA0A0} -</style></head><body> +</style> +</head><body> <table> <tbody><tr> <td align="left">Doc. no.</td> -<td align="left">N2614=08-0124</td> +<td align="left">N2729=08-0239</td> </tr> <tr> <td align="left">Date:</td> -<td align="left">2008-05-18</td> +<td align="left">2008-08-24</td> </tr> <tr> <td align="left">Project:</td> @@ -27,7 +29,7 @@ del {background-color:#FFA0A0} <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 Closed Issues List (Revision R56)</h1> +<h1>C++ Standard Library Closed Issues List (Revision R59)</h1> <p>Reference ISO/IEC IS 14882:1998(E)</p> <p>Also see:</p> @@ -49,6 +51,67 @@ del {background-color:#FFA0A0} <h2>Revision History</h2> <ul> +<li>R59: +2008-08-22 pre-San Francisco mailing. +<ul> +<li><b>Summary:</b><ul> +<li>192 open issues, up by 9.</li> +<li>686 closed issues, up by 0.</li> +<li>878 issues total, up by 9.</li> +</ul></li> +<li><b>Details:</b><ul> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#871">871</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#872">872</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#875">875</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#877">877</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>.</li> +</ul></li> +</ul> +</li> +<li>R58: +2008-07-28 mid-term mailing. +<ul> +<li><b>Summary:</b><ul> +<li>183 open issues, up by 12.</li> +<li>686 closed issues, down by 4.</li> +<li>869 issues total, up by 8.</li> +</ul></li> +<li><b>Details:</b><ul> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#864">864</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#869">869</a>.</li> +<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li> +<li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>.</li> +<li>Changed the following issues from WP to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>.</li> +<li>Changed the following issues from Pending NAD Editorial to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>.</li> +</ul></li> +</ul> +</li> +<li>R57: +2008-06-27 post-Sophia Antipolis mailing. +<ul> +<li><b>Summary:</b><ul> +<li>171 open issues, down by 20.</li> +<li>690 closed issues, up by 43.</li> +<li>861 issues total, up by 23.</li> +</ul></li> +<li><b>Details:</b><ul> +<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#840">840</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#858">858</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#861">861</a>.</li> +<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#839">839</a>.</li> +<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#852">852</a>.</li> +<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#851">851</a>.</li> +<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>.</li> +<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>.</li> +<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>.</li> +<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>.</li> +<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>.</li> +<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>.</li> +<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>.</li> +<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#829">829</a>.</li> +<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>.</li> +<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>.</li> +<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>.</li> +<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a>.</li> +<li>Changed the following issues from Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>.</li> +<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li> +</ul></li> +</ul> +</li> <li>R56: 2008-05-16 pre-Sophia Antipolis mailing. <ul> @@ -58,7 +121,7 @@ del {background-color:#FFA0A0} <li>838 issues total, up by 25.</li> </ul></li> <li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#826">826</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#831">831</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#838">838</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#838">838</a>.</li> <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>.</li> </ul></li> </ul> @@ -76,7 +139,7 @@ del {background-color:#FFA0A0} <li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#790">790</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#791">791</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#796">796</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#797">797</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#799">799</a>.</li> <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>.</li> <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#801">801</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a>.</li> -<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#798">798</a>.</li> +<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li> <li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>.</li> <li>Changed the following issues from NAD Future to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.</li> <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>.</li> @@ -85,13 +148,13 @@ del {background-color:#FFA0A0} <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li> <li>Changed the following issues from Review to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>.</li> <li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a>.</li> -<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>.</li> +<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>.</li> <li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>.</li> -<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li> +<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li> <li>Changed the following issues from Open to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#625">625</a>.</li> -<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#710">710</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#722">722</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#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#746">746</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#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#783">783</a>.</li> -<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#550">550</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#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a>.</li> -<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a>, <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#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#685">685</a>.</li> +<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>.</li> +<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>.</li> +<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>.</li> <li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>.</li> <li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>.</li> <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li> @@ -108,7 +171,7 @@ del {background-color:#FFA0A0} <li>787 issues total, up by 23.</li> </ul></li> <li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>.</li> <li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>.</li> <li>Changed the following issues from NAD Future to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>.</li> <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#697">697</a>.</li> @@ -126,7 +189,7 @@ del {background-color:#FFA0A0} <li>764 issues total, up by 10.</li> </ul></li> <li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>.</li> <li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>.</li> <li>Changed the following issues from Pending WP to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li> </ul></li> @@ -141,16 +204,16 @@ del {background-color:#FFA0A0} <li>754 issues total, up by 31.</li> </ul></li> <li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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-closed.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-closed.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-closed.html#754">754</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>.</li> <li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>.</li> <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>.</li> <li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a>.</li> -<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li> +<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li> <li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li> <li>Changed the following issues from New to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li> -<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li> +<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li> <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>.</li> -<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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-closed.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-closed.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 Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>.</li> <li>Changed the following issues from New to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#552">552</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>.</li> <li>Changed the following issues from Open to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#401">401</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>.</li> <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>.</li> @@ -166,7 +229,7 @@ del {background-color:#FFA0A0} <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-closed.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-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>.</li> </ul></li> </ul> </li> @@ -187,10 +250,10 @@ del {background-color:#FFA0A0} <li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li> <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>.</li> <li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>.</li> -<li>Changed the following issues from Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#644">644</a>.</li> +<li>Changed the following issues from Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>.</li> <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>.</li> <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>.</li> -<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a>.</li> +<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>.</li> <li>Changed the following issues from Ready to TRDec: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>.</li> <li>Changed the following issues from DR to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#453">453</a>.</li> <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>.</li> @@ -206,7 +269,7 @@ del {background-color:#FFA0A0} <li>696 issues total, up by 20.</li> </ul></li> <li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li> <li>Added the following Pending NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#683">683</a>.</li> <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#587">587</a>.</li> <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>.</li> @@ -223,7 +286,7 @@ del {background-color:#FFA0A0} <li>676 issues total, up by 20.</li> </ul></li> <li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>.</li> <li>Changed the following issues from Tentatively Ready to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>.</li> <li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li> <li>Changed the following issues from NAD to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#357">357</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#368">368</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a>.</li> @@ -233,7 +296,7 @@ del {background-color:#FFA0A0} <li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li> <li>Changed the following issues from Tentatively Ready to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>.</li> <li>Changed the following issues from Tentatively Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>.</li> -<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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 New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>.</li> <li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>.</li> <li>Changed the following issues from Ready to TRDec: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#598">598</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#599">599</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#600">600</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#601">601</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#602">602</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a>.</li> <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>.</li> @@ -250,9 +313,9 @@ del {background-color:#FFA0A0} <li>656 issues total, up by 37.</li> </ul></li> <li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li> <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li> -<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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 Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#614">614</a>.</li> <li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li> <li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>.</li> <li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>.</li> @@ -284,7 +347,7 @@ del {background-color:#FFA0A0} <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-defects.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li> +<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li> <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#598">598</a> - <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a> to Ready.</li> <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a> to Review.</li> <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>.</li> @@ -373,7 +436,7 @@ Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.ht Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a> from New to Open. Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> from New to Ready. Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD. -Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a> from New to Review. +Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a> from New to Review. </li> <li>R38: 2005-07-03 pre-Mont Tremblant mailing. @@ -617,7 +680,7 @@ exists.)</p> <p><b>Proposed resolution:</b></p> -<p>Change 20.4.4.3 [meta.unary.prop] paragraph 1 Effects from +<p>Change 20.5.4.3 [meta.unary.prop] paragraph 1 Effects from "Calls p->release()" to "Calls p.release()".</p> @@ -980,7 +1043,7 @@ otherwise possible. </p> <hr> <h3><a name="82"></a>82. Missing constant for set elements</h3> -<p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> +<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> @@ -1212,7 +1275,7 @@ may be provided by a non-Standard implementation class:</p> <p><b>Proposed resolution:</b></p> -<p>Add a new subclause [presumably 17.4.4.9] following 17.4.4.8 [res.on.exception.handling]:</p> +<p>Add a new subclause [presumably 17.4.4.9] following 17.4.4.9 [res.on.exception.handling]:</p> <blockquote> <p>17.4.4.9 Template Parameters</p> <p>A specialization of a @@ -1385,7 +1448,7 @@ expressed in a single line of code (where <tt>v</tt> is <hr> <h3><a name="102"></a>102. Bug in insert range in associative containers</h3> -<p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> +<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> @@ -1579,7 +1642,7 @@ desired functionality.</p> <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-11-06</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#Dup">Dup</a> status.</p> -<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#778">778</a></p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a></p> <p><b>Discussion:</b></p> @@ -1958,7 +2021,7 @@ set. Consider Arabic or Hebrew, for example. See 22.2.2.2.2 [facet.num.put.virtu <hr> <h3><a name="149"></a>149. Insert should return iterator to first element inserted</h3> -<p><b>Section:</b> 23.1.1 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a> +<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-06-28</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#NAD%20Future">NAD Future</a> status.</p> @@ -2297,7 +2360,7 @@ iterators.</p> <hr> <h3><a name="192"></a>192. a.insert(p,t) is inefficient and overconstrained</h3> -<p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> +<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Ed Brey <b>Date:</b> 1999-06-06</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> @@ -2343,7 +2406,7 @@ providing no disadvantage to the container implementation.</p> <p><b>Proposed resolution:</b></p> -<p>In 23.1.2 [associative.reqmts] paragraph 7, replace the row in table 69 +<p>In 23.1.4 [associative.reqmts] paragraph 7, replace the row in table 69 for a.insert(p,t) with the following two rows:</p> <table border="1" cellpadding="5"> <tbody><tr> @@ -2703,7 +2766,6 @@ paragraphs.</p> <h3><a name="213"></a>213. Math function overloads ambiguous</h3> <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 2000-02-26</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> <p><b>Discussion:</b></p> @@ -2728,7 +2790,7 @@ or write floating point expressions as arguments.</p> <hr> <h3><a name="215"></a>215. Can a map's key_type be const?</h3> -<p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> +<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-02-29</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> @@ -2753,7 +2815,7 @@ too.</p> <p><b>Rationale:</b></p> <p>The "key is assignable" requirement from table 69 in -23.1.2 [associative.reqmts] already implies the key cannot be const.</p> +23.1.4 [associative.reqmts] already implies the key cannot be const.</p> @@ -2847,7 +2909,7 @@ operator<.</p> <hr> <h3><a name="219"></a>219. find algorithm missing version that takes a binary predicate argument</h3> -<p><b>Section:</b> 25.1.2 [alg.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a> +<p><b>Section:</b> 25.1.5 [alg.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a> <b>Submitter:</b> Pablo Halpern <b>Date:</b> 2000-03-06</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find">issues</a> in [alg.find].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p> @@ -2863,7 +2925,7 @@ simple, alternative interface to find.</p> <p><b>Proposed resolution:</b></p> <blockquote> -<p>In section 25.1.2 [alg.find], add a second prototype for find +<p>In section 25.1.5 [alg.find], add a second prototype for find (between the existing prototype and the prototype for find_if), as follows:</p> <pre> template<class InputIterator, class T, class BinaryPredicate> @@ -2928,7 +2990,7 @@ ie. the <tt>do_is()</tt> method as described in 22.2.1.1.2 [locale.ctype.virtual <hr> <h3><a name="244"></a>244. Must <tt>find</tt>'s third argument be CopyConstructible?</h3> -<p><b>Section:</b> 25.1.2 [alg.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> +<p><b>Section:</b> 25.1.5 [alg.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2000-05-02</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find">issues</a> in [alg.find].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> @@ -3003,7 +3065,7 @@ how many times find may invoke operator++.</p> <hr> <h3><a name="246"></a>246. <tt>a.insert(p,t)</tt> is incorrectly specified</h3> -<p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> +<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Mark Rodgers <b>Date:</b> 2000-05-19</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> @@ -3133,7 +3195,7 @@ code.</p> <hr> <h3><a name="257"></a>257. STL functional object and iterator inheritance.</h3> -<p><b>Section:</b> 20.5.3 [base], 24.3.2 [iterator.basic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> +<p><b>Section:</b> 20.6.3 [base], 24.3.2 [iterator.basic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Robert Dick <b>Date:</b> 2000-08-17</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> @@ -3558,7 +3620,6 @@ version of <tt>setf</tt>, to avoid unexpected behavior. <h3><a name="289"></a>289. <cmath> requirements missing C float and long double versions</h3> <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-12-30</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> <p><b>Discussion:</b></p> @@ -3941,7 +4002,6 @@ about when terminate() is called; it merely specifies which <h3><a name="323"></a>323. abs() overloads in different headers</h3> <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2001-06-04</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> <p><b>Discussion:</b></p> @@ -4228,7 +4288,7 @@ operator< on any pair type which contains a pointer. <hr> <h3><a name="350"></a>350. allocator<>::address</h3> -<p><b>Section:</b> 20.6.5.1 [allocator.members], 20.1.2 [allocator.requirements], 17.4.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> +<p><b>Section:</b> 20.7.5.1 [allocator.members], 20.1.2 [allocator.requirements], 17.4.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 2001-10-25</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> @@ -4313,15 +4373,15 @@ exhibiting a problem.</p> <hr> <h3><a name="351"></a>351. unary_negate and binary_negate: struct or class?</h3> -<p><b>Section:</b> 20.5 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> +<p><b>Section:</b> 20.6 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> <b>Submitter:</b> Dale Riley <b>Date:</b> 2001-11-12</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> <p><b>Discussion:</b></p> <p> -In 20.5 [function.objects] the header <functional> synopsis declares +In 20.6 [function.objects] the header <functional> synopsis declares the unary_negate and binary_negate function objects as struct. -However in 20.5.10 [negators] the unary_negate and binary_negate +However in 20.6.10 [negators] the unary_negate and binary_negate function objects are defined as class. Given the context, they are not "basic function objects" like negate, so this is either a typo or an editorial oversight. @@ -4332,7 +4392,7 @@ an editorial oversight. <p><b>Proposed resolution:</b></p> -<p>Change the synopsis to reflect the useage in 20.5.10 [negators]</p> +<p>Change the synopsis to reflect the useage in 20.6.10 [negators]</p> <p><i>[Curaçao: Since the language permits "struct", the LWG views this as NAD. They suggest, however, that the Project Editor @@ -4558,7 +4618,6 @@ to see which interpretation is being used.</p> <h3><a name="357"></a>357. <cmath> float functions cannot return HUGE_VAL</h3> <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-02-26</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> <p><b>Discussion:</b></p> @@ -4865,13 +4924,13 @@ part of the "Effects" paragraph. <hr> <h3><a name="372"></a>372. Inconsistent description of stdlib exceptions</h3> -<p><b>Section:</b> 17.4.4.8 [res.on.exception.handling], 18.6.1 [type.info] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> +<p><b>Section:</b> 17.4.4.9 [res.on.exception.handling], 18.6.1 [type.info] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Randy Maddox <b>Date:</b> 2002-07-22</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.exception.handling">issues</a> in [res.on.exception.handling].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> <p><b>Discussion:</b></p> -<p>Paragraph 3 under clause 17.4.4.8 [res.on.exception.handling], Restrictions on +<p>Paragraph 3 under clause 17.4.4.9 [res.on.exception.handling], Restrictions on Exception Handling, states that "Any other functions defined in the C++ Standard Library that do not have an exception-specification may throw implementation-defined exceptions unless otherwise specified." @@ -5021,7 +5080,7 @@ out of scope? <p> Many function templates have parameters that are passed by value; a typical example is <tt>find_if</tt>'s <i>pred</i> parameter in -25.1.2 [alg.find]. Are the corresponding template parameters +25.1.5 [alg.find]. Are the corresponding template parameters (<tt>Predicate</tt> in this case) implicitly required to be CopyConstructible, or does that need to be spelled out explicitly? </p> @@ -5296,10 +5355,10 @@ of input iterators.</p> <hr> <h3><a name="393"></a>393. do_in/do_out operation on state unclear</h3> -<p><b>Section:</b> 22.2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a> +<p><b>Section:</b> 22.2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> <b>Submitter:</b> Alberto Barbati <b>Date:</b> 2002-12-24</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.virtuals">issues</a> in [locale.codecvt.virtuals].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> <p><b>Discussion:</b></p> <p> this DR follows the discussion on the previous thread "codecvt::do_in @@ -5427,8 +5486,8 @@ is not so clear (see list 3). List 1 -- Examples of (presumably) normative Notes: <br> -20.6.5.1 [allocator.members], p3,<br> -20.6.5.1 [allocator.members], p10,<br> +20.7.5.1 [allocator.members], p3,<br> +20.7.5.1 [allocator.members], p10,<br> 21.3.2 [string.cons], p11,<br> 22.1.1.2 [locale.cons], p11,<br> 23.2.2.3 [deque.modifiers], p2,<br> @@ -5443,7 +5502,7 @@ List 2 -- Examples of (presumably) informative Notes: 18.5.1.3 [new.delete.placement], p3,<br> 21.3.6.6 [string::replace], p14,<br> 22.2.1.4.2 [locale.codecvt.virtuals], p3,<br> -25.1.1 [alg.foreach], p4,<br> +25.1.4 [alg.foreach], p4,<br> 26.3.5 [complex.member.ops], p1,<br> 27.4.2.5 [ios.base.storage], p6.<br> <br> @@ -5785,7 +5844,7 @@ table, in this regard. <hr> <h3><a name="451"></a>451. Associative erase should return an iterator</h3> -<p><b>Section:</b> 23.1.2 [associative.reqmts], 23.3 [associative] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> +<p><b>Section:</b> 23.1.4 [associative.reqmts], 23.3 [associative] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> @@ -6284,7 +6343,7 @@ support that the eventual solution should make this code well formed. <hr> <h3><a name="480"></a>480. unary_function and binary_function should have protected nonvirtual destructors</h3> -<p><b>Section:</b> 20.5.3 [base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> +<p><b>Section:</b> 20.6.3 [base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Joe Gottman <b>Date:</b> 2004-08-19</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> @@ -6386,7 +6445,7 @@ explicit, but it's hard to think that's a major problem.</p> <hr> <h3><a name="482"></a>482. Swapping pairs</h3> -<p><b>Section:</b> 20.2.3 [pairs], 20.3 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> +<p><b>Section:</b> 20.2.3 [pairs], 20.4 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2004-09-14</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> @@ -6535,7 +6594,6 @@ operator that takes a T, or a T may be convertible to the type of *i. <h3><a name="486"></a>486. min/max CopyConstructible requirement is too strict</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#Dup">Dup</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2004-10-13</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.min.max">active issues</a> in [alg.min.max].</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#Dup">Dup</a> status.</p> <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#281">281</a></p> @@ -7294,7 +7352,7 @@ not guarantee the substitution property or referential transparency).</p> <hr> <h3><a name="494"></a>494. Wrong runtime complexity for associative container's insert and delete</h3> -<p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> +<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Hans B os <b>Date:</b> 2004-12-19</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> @@ -7447,7 +7505,7 @@ Contradiction. <hr> <h3><a name="501"></a>501. Proposal: strengthen guarantees of lib.comparisons</h3> -<p><b>Section:</b> 20.5.3 [base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> +<p><b>Section:</b> 20.6.3 [base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Me <anti_spam_email2003@yahoo.com> <b>Date:</b> 2005-06-07</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> @@ -8129,7 +8187,7 @@ Berlin: N1932 considers this NAD. This is a QOI issue. <hr> <h3><a name="525"></a>525. type traits definitions not clear</h3> -<p><b>Section:</b> 20.4.4 [meta.unary], TR1 4.5 [tr.meta.unary] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> +<p><b>Section:</b> 20.5.4 [meta.unary], TR1 4.5 [tr.meta.unary] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> <b>Submitter:</b> Robert Klarer <b>Date:</b> 2005-07-11</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> <p><b>Discussion:</b></p> @@ -8164,7 +8222,7 @@ in the WP. <hr> <h3><a name="526"></a>526. Is it undefined if a function in the standard changes in parameters?</h3> -<p><b>Section:</b> 23.1.1 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> +<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2005-09-14</p> <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#NAD">NAD</a> status.</p> @@ -8299,7 +8357,7 @@ doesn't give permission for it not to work.</li> <li><tt>list::remove(value)</tt> is required to work because the standard doesn't give permission for it not to work.</li> <li><tt>vector::insert(iter, iter, iter)</tt> is not required to work because -23.1.1 [sequence.reqmts], p4 says so.</li> +23.1.3 [sequence.reqmts], p4 says so.</li> <li><tt>copy</tt> has to work, except where 25.2.1 [alg.copy] says it doesn't have to work. While a language lawyer can tear this wording apart, it is felt that the wording is not prone to accidental interpretation.</li> @@ -8391,7 +8449,7 @@ chapter 17 wording. <hr> <h3><a name="529"></a>529. The standard encourages redundant and confusing preconditions</h3> -<p><b>Section:</b> 17.4.3.9 [res.on.required] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> +<p><b>Section:</b> 17.4.3.10 [res.on.required] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> <b>Submitter:</b> David Abrahams <b>Date:</b> 2005-10-25</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> <p><b>Discussion:</b></p> @@ -8485,7 +8543,7 @@ Alan provided the survey <hr> <h3><a name="532"></a>532. Tuple comparison</h3> -<p><b>Section:</b> 20.3.1.6 [tuple.rel], TR1 6.1.3.5 [tr.tuple.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a> +<p><b>Section:</b> 20.4.1.6 [tuple.rel], TR1 6.1.3.5 [tr.tuple.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a> <b>Submitter:</b> David Abrahams <b>Date:</b> 2005-11-29</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p> <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a></p> @@ -8782,6 +8840,7 @@ Portland: Subsumed by N2111. <h3><a name="553"></a>553. very minor editorial change intptr_t / uintptr_t</h3> <p><b>Section:</b> 18.3.1 [cstdint.syn], TR1 8.22.1 [tr.c99.cstdint.syn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-01-30</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint.syn">issues</a> in [cstdint.syn].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> <p><b>Discussion:</b></p> <p> @@ -8914,10 +8973,10 @@ Redmond: Editorial. <hr> <h3><a name="557"></a>557. TR1: div(_Longlong, _Longlong) vs div(intmax_t, intmax_t)</h3> -<p><b>Section:</b> 18.3 [cstdint], TR1 8.22 [tr.c99.cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a> +<p><b>Section:</b> 18.3 [cstdint], TR1 8.22 [tr.c99.cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-02-06</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint">issues</a> in [cstdint].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> <p><b>Discussion:</b></p> <p> I'm seeing a problem with such overloads: when, _Longlong == intmax_t == @@ -9230,6 +9289,73 @@ committee meant. <hr> +<h3><a name="570"></a>570. Request adding additional explicit specializations of char_traits</h3> +<p><b>Section:</b> 21.1 [char.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Jack Reeves <b>Date:</b> 2006-04-06</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits">issues</a> in [char.traits].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Currently, the Standard Library specifies only a declaration for template class +char_traits<> and requires the implementation provide two explicit +specializations: char_traits<char> and char_traits<wchar_t>. I feel the Standard +should require explicit specializations for all built-in character types, i.e. +char, wchar_t, unsigned char, and signed char. +</p> +<p> +I have put together a paper +(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1985.htm">N1985</a>) +that describes this in more detail and +includes all the necessary wording. +</p> +<p><i>[ +Portland: Jack will rewrite +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1985.htm">N1985</a> +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><i>[ +post Bellevue: +]</i></p> + + +<blockquote> +<p> +We suggest that Jack be asked about the status of his paper, and if it +is not forthcoming, the work-item be assigned to someone else. If no one +steps forward to do the paper before the next meeting, we propose to +make this NAD without further discussion. We leave this Open for now, +but our recommendation is NAD. +</p> +<p> +Note: the issue statement should be updated, as the Toronto comment has +already been resolved. E.g., char_traits specializations for char16_t +and char32_t are now in the working paper. +</p> +</blockquote> + +<p><i>[ +Sophia Antipolis: +]</i></p> + + +<blockquote> +Nobody has submitted the requested paper, so we move to NAD, as suggested by the decision at the last meeting. +</blockquote> + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> <h3><a name="571"></a>571. Update C90 references to C99?</h3> <p><b>Section:</b> 1.2 [intro.refs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-04-08</p> @@ -9303,8 +9429,9 @@ is adopted. <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#NAD">NAD</a> +<p><b>Section:</b> 23.1.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</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#NAD">NAD</a> status.</p> <p><b>Discussion:</b></p> @@ -9392,7 +9519,6 @@ uses depend on the iterator being returned. <h3><a name="583"></a>583. div() for unsigned integral types</h3> <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-06-15</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> <p><b>Discussion:</b></p> @@ -9431,7 +9557,6 @@ behavior and thus does not need this treatment. <h3><a name="584"></a>584. missing int pow(int,int) functionality</h3> <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-06-15</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> <p><b>Discussion:</b></p> @@ -9493,7 +9618,7 @@ post Oxford: Noted that it is already fixed in <hr> <h3><a name="590"></a>590. Type traits implementation latitude should be removed for C++0x</h3> -<p><b>Section:</b> 20.4 [meta], TR1 4.9 [tr.meta.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> +<p><b>Section:</b> 20.5 [meta], TR1 4.9 [tr.meta.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-08-10</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta">issues</a> in [meta].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> @@ -9603,10 +9728,10 @@ Recommend NAD / Editorial. The proposed resolution is accepted as editorial. <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#NAD%20Editorial">Pending NAD Editorial</a> +<p><b>Section:</b> 27.8.1.9 [ifstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> <b>Submitter:</b> Christopher Kohlhoff <b>Date:</b> 2006-08-17</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ifstream.members">issues</a> in [ifstream.members].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> <p><b>Discussion:</b></p> <p> I just spotted a minor problem in 27.8.1.7 @@ -9959,6 +10084,12 @@ Bellevue: Marked as NAD Editorial. ]</i></p> +<p><i>[ +Post-Sophia Antipolis: Martin indicates there is still work to be done on this issue. +Reopened. +]</i></p> + + <p><b>Proposed resolution:</b></p> @@ -10046,12 +10177,12 @@ its resource limits", so no further escape hatch is necessary. <hr> <h3><a name="633"></a>633. Return clause mentions undefined "type()"</h3> -<p><b>Section:</b> 20.5.15.2.5 [func.wrap.func.targ] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> +<p><b>Section:</b> 20.6.15.2.5 [func.wrap.func.targ] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-03</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> <p><b>Discussion:</b></p> <p> -20.5.15.2.5 [func.wrap.func.targ], p4 says: +20.6.15.2.5 [func.wrap.func.targ], p4 says: </p> <blockquote><p> <i>Returns:</i> If <tt>type() == typeid(T)</tt>, a pointer to the stored @@ -10067,7 +10198,7 @@ function <tt>type()</tt> in class template function nor in the global or <li> Assuming that <tt>type</tt> should have been <tt>target_type()</tt>, this description would lead to false results, if <tt>T = <i>cv</i> -void</tt> due to returns clause 20.5.15.2.5 [func.wrap.func.targ], p1. +void</tt> due to returns clause 20.6.15.2.5 [func.wrap.func.targ], p1. </li> </ol> @@ -10075,7 +10206,7 @@ void</tt> due to returns clause 20.5.15.2.5 [func.wrap.func.targ], p1. <p><b>Proposed resolution:</b></p> <p> -Change 20.5.15.2.5 [func.wrap.func.targ], p4: +Change 20.6.15.2.5 [func.wrap.func.targ], p4: </p> <blockquote><p> @@ -10127,7 +10258,6 @@ Pete recommends editorial fix. <h3><a name="637"></a>637. [c.math]/10 inconsistent return values</h3> <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-02-13</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> <p><b>Discussion:</b></p> @@ -10949,13 +11079,13 @@ unlikely to be better than what's already in the standard. <hr> <h3><a name="658"></a>658. Two unspecified function comparators in [function.objects]</h3> -<p><b>Section:</b> 20.5 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> +<p><b>Section:</b> 20.6 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-19</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> <p><b>Discussion:</b></p> <p> -The header <tt><functional></tt> synopsis in 20.5 [function.objects] +The header <tt><functional></tt> synopsis in 20.6 [function.objects] contains the following two free comparison operator templates for the <tt>function</tt> class template </p> @@ -10969,7 +11099,7 @@ void operator!=(const function<Function1>&, const function<Function <p> which are nowhere described. I assume that they are relicts before the corresponding two private and undefined member templates in the function -template (see 20.5.15.2 [func.wrap.func] and X [func.wrap.func.undef]) have been introduced. The original free +template (see 20.6.15.2 [func.wrap.func] and X [func.wrap.func.undef]) have been introduced. The original free function templates should be removed, because using an undefined entity would lead to an ODR violation of the user. </p> @@ -10978,7 +11108,7 @@ would lead to an ODR violation of the user. <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]) +the header <tt><functional></tt> synopsis (20.6 [function.objects]) </p> <blockquote><pre><del>template<class Function1, class Function2> @@ -11328,13 +11458,13 @@ Bellevue: Proposed wording now in WP. <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.11.2.4 [unique.ptr.single.observers], 20.6.12.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> +<p><b>Section:</b> 20.7.11.2.4 [unique.ptr.single.observers], 20.7.12.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</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#NAD">NAD</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 +five places. In three of those places (20.6.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> @@ -11362,8 +11492,8 @@ makes it irrelevant. <p> To the <i>Returns</i> paragraph for <tt>operator <i>unspecified-bool-type</i>() const</tt> -of 20.6.11.2.4 [unique.ptr.single.observers] paragraph 11 and -20.6.12.2.5 [util.smartptr.shared.obs] paragraph 16, add the sentence: +of 20.7.11.2.4 [unique.ptr.single.observers] paragraph 11 and +20.7.12.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>. @@ -11382,7 +11512,6 @@ Kona (2007): Uncertain if <tt>nullptr</tt> will address this issue. <h3><a name="690"></a>690. abs(long long) should return long long</h3> <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> <b>Submitter:</b> Niels Dekker <b>Date:</b> 2007-06-10</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#c.math">active issues</a> in [c.math].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> <p><b>Discussion:</b></p> @@ -11542,63 +11671,6 @@ implementation details. <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#NAD%20Editorial">Pending NAD Editorial</a> - <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-13</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits.specializations">issues</a> in [char.traits.specializations].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -The changes made for <tt>constexpr</tt> in 21.1.3 [char.traits.specializations] have -not only changed the <tt>not_eof</tt> function from pass by const reference to -pass by value, it has also changed the parameter type from <tt>int_type</tt> to -<tt>char_type</tt>. -</p> -<p> -This doesn't work for type <tt>char</tt>, and is inconsistent with the -requirements in Table 56, Traits requirements, 21.1.1 [char.traits.require]. -</p> - -<p> -Pete adds: -</p> - -<blockquote><p> -For what it's worth, that may not have been an intentional change. -N2349, which detailed the changes for adding constant expressions to -the library, has strikeout bars through the <tt>const</tt> and the <tt>&</tt> that -surround the <tt>char_type</tt> argument, but none through <tt>char_type</tt> itself. -So the intention may have been just to change to pass by value, with -text incorrectly copied from the standard. -</p></blockquote> - - - -<p><b>Proposed resolution:</b></p> -<p> -Change the signature in 21.1.3.1 [char.traits.specializations.char], -21.1.3.2 [char.traits.specializations.char16_t], 21.1.3.3 [char.traits.specializations.char32_t], -and 21.1.3.4 [char.traits.specializations.wchar.t] to -</p> - -<blockquote><pre>static constexpr int_type not_eof(<del>char_type</del> <ins>int_type</ins> c); -</pre></blockquote> - - - -<p><i>[ -Bellevue: -]</i></p> - - -<blockquote> -Resolution: NAD editorial - up to Pete's judgment -</blockquote> - - - - -<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#NAD%20Editorial">Pending NAD Editorial</a> <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-27</p> @@ -11660,7 +11732,7 @@ of that array ends, whichever happens first. <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#NAD%20Editorial">Pending NAD Editorial</a> +<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a> <b>Submitter:</b> David Abrahams <b>Date:</b> 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#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p> @@ -12025,6 +12097,7 @@ for the proposed resolution. <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#NAD">NAD</a> <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.discrete">active issues</a> in [rand.dist.samp.discrete].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.discrete">issues</a> in [rand.dist.samp.discrete].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> <p><b>Discussion:</b></p> @@ -12372,7 +12445,7 @@ for the proposed resolution. <hr> <h3><a name="741"></a>741. Const-incorrect <tt>get_deleter</tt> function for <tt>shared_ptr</tt></h3> -<p><b>Section:</b> 20.6.12.2.11 [util.smartptr.getdeleter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> +<p><b>Section:</b> 20.7.12.2.11 [util.smartptr.getdeleter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-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#NAD">NAD</a> status.</p> @@ -12383,7 +12456,7 @@ The following issue was raised by Alf P. Steinbach in c.l.c++.mod: <p> According to the recent draft N2369, both the header memory synopsis -of 20.6 [memory] and 20.6.12.2.11 [util.smartptr.getdeleter] declare: +of 20.7 [memory] and 20.7.12.2.11 [util.smartptr.getdeleter] declare: </p> <blockquote><pre>template<class D, class T> D* get_deleter(shared_ptr<T> const& p); @@ -12398,7 +12471,7 @@ 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 +synopsis 20.6.15.2 [func.wrap.func] or in 20.6.15.2.5 [func.wrap.func.targ] - do properly mirror the const-state of the owner. </p> @@ -12406,7 +12479,7 @@ properly mirror the const-state of the owner. <p> Replace the declarations of <tt>get_deleter</tt> in the header <tt><memory></tt> -synopsis of 20.6 [memory] and in 20.6.12.2.11 [util.smartptr.getdeleter] by one of the +synopsis of 20.7 [memory] and in 20.7.12.2.11 [util.smartptr.getdeleter] by one of the following alternatives (A) or (B): </p> @@ -12519,9 +12592,8 @@ slicing involved. <hr> <h3><a name="748"></a>748. The is_abstract type trait is defined by reference to 10.4.</h3> -<p><b>Section:</b> 20.4.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> +<p><b>Section:</b> 20.5.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</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#NAD">NAD</a> status.</p> <p><b>Discussion:</b></p> @@ -12556,10 +12628,10 @@ Core has clarified that the definition abstract is adequate. Issue withdrawn by <hr> <h3><a name="754"></a>754. Ambiguous return clause for <tt>std::uninitialized_copy</tt></h3> -<p><b>Section:</b> 20.6.10.1 [uninitialized.copy] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a> +<p><b>Section:</b> 20.7.10.1 [uninitialized.copy] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-10-15</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#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> <p><b>Discussion:</b></p> <p> 14882-2003, [lib.uninitialized.copy] is currently written as follows: @@ -12586,7 +12658,7 @@ Core has clarified that the definition abstract is adequate. Issue withdrawn by <p> similarily for N2369, and its corresponding section -20.6.10.1 [uninitialized.copy]. +20.7.10.1 [uninitialized.copy]. </p> <p> @@ -12634,7 +12706,7 @@ for <tt>std::copy</tt>. <p><b>Proposed resolution:</b></p> <p> -Change the wording of the return clause to say (20.6.10.1 [uninitialized.copy]): +Change the wording of the return clause to say (20.7.10.1 [uninitialized.copy]): </p> <blockquote> @@ -12659,11 +12731,107 @@ occur. <hr> +<h3><a name="756"></a>756. Container adaptors push</h3> +<p><b>Section:</b> 23.2.5 [container.adaptors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2007-10-31</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +After n2369 we have a single <tt>push_back</tt> overload in the sequence containers, +of the "emplace" type. At variance with that, still in n2461, we have +two separate overloads, the C++03 one + one taking an rvalue reference +in the container adaptors. Therefore, simply from a consistency point of +view, I was wondering whether the container adaptors should be aligned +with the specifications of the sequence container themselves: thus have +a single <tt>push</tt> along the lines: +</p> + +<blockquote><pre>template<typename... _Args> +void +push(_Args&&... __args) + { c.push_back(std::forward<_Args>(__args)...); } +</pre></blockquote> + +<p><i>[ +Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a> +]</i></p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change 23.2.5.1.1 [queue.defn]: +</p> + +<blockquote><pre><del>void push(const value_type& x) { c.push_back(x); }</del> +<del>void push(value_type&& x) { c.push_back(std::move(x)); }</del> +<ins>template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }</ins> +</pre></blockquote> + +<p> +Change 23.2.5.2 [priority.queue]: +</p> + +<blockquote><pre><del>void push(const value_type& x) { c.push_back(x); }</del> +<del>void push(value_type&& x) { c.push_back(std::move(x)); }</del> +<ins>template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }</ins> +</pre></blockquote> + +<p> +Change 23.2.5.2.2 [priqueue.members]: +</p> + +<blockquote> +<pre><del>void push(const value_type& x);</del> +</pre> +<blockquote> +<p> +<del><i>Effects:</i></del> +</p> +<blockquote><pre><del>c.push_back(x);</del> +<del>push_heap(c.begin(), c.end(), comp);</del> +</pre></blockquote> +</blockquote> + +<pre><ins>template<class... Args></ins> void push(<del>value_type</del> <ins>Args</ins>&&<ins>...</ins> <del>x</del> <ins>args</ins>); +</pre> +<blockquote> +<p> +<i>Effects:</i> +</p> +<blockquote><pre>c.push_back(std::<del>move</del><ins>forward<Args></ins>(<del>x</del> <ins>args</ins>)<ins>...</ins>); +push_heap(c.begin(), c.end(), comp); +</pre></blockquote> +</blockquote> +</blockquote> + +<p> +Change 23.2.5.3.1 [stack.defn]: +</p> + +<blockquote><pre><del>void push(const value_type& x) { c.push_back(x); }</del> +<del>void push(value_type&& x) { c.push_back(std::move(x)); }</del> +<ins>template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }</ins> +</pre></blockquote> + + + +<p><b>Rationale:</b></p> +<p> +Addressed by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2680.pdf">N2680 Proposed Wording for Placement Insert (Revision 1)</a>. +</p> + + + + + +<hr> <h3><a name="757"></a>757. Typo in the synopsis of vector</h3> -<p><b>Section:</b> 23.2.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a> +<p><b>Section:</b> 23.2.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2007-11-04</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> <p><b>Discussion:</b></p> <p> In the synopsis 23.2.6 [vector], there is the signature: @@ -12702,7 +12870,7 @@ void insert(const_iterator position, size_type n, const T& x); <hr> <h3><a name="763"></a>763. Renaming <tt>emplace()</tt> overloads</h3> -<p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> +<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Sylvain Pion <b>Date:</b> 2007-12-04</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> @@ -12721,7 +12889,7 @@ a <tt>const_iterator</tt> as first argument. </p> <p><i>[ -Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#767">767</a> +Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a> ]</i></p> @@ -12754,8 +12922,9 @@ For example to <tt>emplace_here</tt>, <tt>hint_emplace</tt>... <hr> <h3><a name="764"></a>764. <tt>equal_range</tt> on unordered containers should return a <tt>pair</tt> of <tt>local_iterators</tt></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#NAD">NAD</a> +<p><b>Section:</b> 23.1.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-11-29</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#NAD">NAD</a> status.</p> <p><b>Discussion:</b></p> @@ -12812,7 +12981,7 @@ for dubious benefit, and iterators are already constant time. <p><b>Proposed resolution:</b></p> <p> -Change the entry for <tt>equal_range</tt> in Table 93 (23.1.3 [unord.req]) as follows: +Change the entry for <tt>equal_range</tt> in Table 93 (23.1.5 [unord.req]) as follows: </p> <table border="1"> <tbody><tr> @@ -12832,6 +13001,273 @@ Change the entry for <tt>equal_range</tt> in Table 93 (23.1.3 [unord.req]) as fo <hr> +<h3><a name="767"></a>767. Forwarding and backward compatibility</h3> +<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Sylvain Pion <b>Date:</b> 2007-12-28</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Playing with g++'s C++0X mode, I noticed that the following +code, which used to compile: +</p> + +<blockquote><pre>#include <vector> + +int main() +{ + std::vector<char *> v; + v.push_back(0); +} +</pre></blockquote> + +<p> +now fails with the following error message: +</p> + +<blockquote>.../include/c++/4.3.0/ext/new_allocator.h: In member +function 'void __gnu_cxx::new_allocator<_Tp>::construct(_Tp*, +_Args&& ...) [with _Args = int, _Tp = char*]': +.../include/c++/4.3.0/bits/stl_vector.h:707: instantiated from 'void +std::vector<_Tp, _Alloc>::push_back(_Args&& ...) [with +_Args = int, _Tp = char*, _Alloc = std::allocator<char*>]' +test.cpp:6: instantiated from here +.../include/c++/4.3.0/ext/new_allocator.h:114: error: invalid +conversion from 'int' to 'char*' +</blockquote> + +<p> +As far as I know, g++ follows the current draft here. +</p> +<p> +Does the committee really intend to break compatibility for such cases? +</p> + +<p><i>[ +Sylvain adds: +]</i></p> + + +<blockquote> +<p> +I just noticed that <tt>std::pair</tt> has the same issue. +The following now fails with GCC's -std=c++0x mode: +</p> + +<blockquote><pre>#include <utility> + +int main() +{ + std::pair<char *, char *> p (0,0); +} +</pre></blockquote> + +<p> +I have not made any general audit for such problems elsewhere. +</p> +</blockquote> + +<p><i>[ +Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a> +]</i></p> + + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +Motivation is to handle the old-style int-zero-valued NULL pointers. +Problem: this solution requires concepts in some cases, which some users +will be slow to adopt. Some discussion of alternatives involving +prohibiting variadic forms and additional library-implementation +complexity. +</p> +<p> +Discussion of "perfect world" solutions, the only such solution put +forward being to retroactively prohibit use of the integer zero for a +NULL pointer. This approach was deemed unacceptable given the large +bodies of pre-existing code that do use integer zero for a NULL pointer. +</p> +<p> +Another approach is to change the member names. Yet another approach is +to forbid the extension in absence of concepts. +</p> +<p> +Resolution: These issues (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>) will be subsumed into a +paper to be produced by Alan Talbot in time for review at the 2008 +meeting in France. Once this paper is produced, these issues will be +moved to NAD. +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Add the following rows to Table 90 "Optional sequence container operations", 23.1.3 [sequence.reqmts]: +</p> + +<blockquote> +<table border="1"> +<tbody><tr> +<th>expression</th> <th>return type</th> <th>assertion/note<br>pre-/post-condition</th> <th>container</th> +</tr> + +<tr> +<td> +<tt>a.push_front(t)</tt> +</td> +<td> +<tt>void</tt> +</td> +<td> +<tt>a.insert(a.begin(), t)</tt><br> +<i>Requires:</i> <tt>T</tt> shall be <tt>CopyConstructible</tt>. +</td> +<td> +<tt>list, deque</tt> +</td> +</tr> + +<tr> +<td> +<tt>a.push_front(rv)</tt> +</td> +<td> +<tt>void</tt> +</td> +<td> +<tt>a.insert(a.begin(), rv)</tt><br> +<i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt>. +</td> +<td> +<tt>list, deque</tt> +</td> +</tr> + +<tr> +<td> +<tt>a.push_back(t)</tt> +</td> +<td> +<tt>void</tt> +</td> +<td> +<tt>a.insert(a.end(), t)</tt><br> +<i>Requires:</i> <tt>T</tt> shall be <tt>CopyConstructible</tt>. +</td> +<td> +<tt>list, deque, vector, basic_string</tt> +</td> +</tr> + +<tr> +<td> +<tt>a.push_back(rv)</tt> +</td> +<td> +<tt>void</tt> +</td> +<td> +<tt>a.insert(a.end(), rv)</tt><br> +<i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt>. +</td> +<td> +<tt>list, deque, vector, basic_string</tt> +</td> +</tr> + +</tbody></table> +</blockquote> + +<p> +Change the synopsis in 23.2.2 [deque]: +</p> + +<blockquote><pre><ins>void push_front(const T& x);</ins> +<ins>void push_front(T&& x);</ins> +<ins>void push_back(const T& x);</ins> +<ins>void push_back(T&& x);</ins> +template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args); +template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args); +</pre></blockquote> + +<p> +Change 23.2.2.3 [deque.modifiers]: +</p> + +<blockquote><pre><ins>void push_front(const T& x);</ins> +<ins>void push_front(T&& x);</ins> +<ins>void push_back(const T& x);</ins> +<ins>void push_back(T&& x);</ins> +template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args); +template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args); +</pre></blockquote> + +<p> +Change the synopsis in 23.2.4 [list]: +</p> + +<blockquote><pre><ins>void push_front(const T& x);</ins> +<ins>void push_front(T&& x);</ins> +<ins>void push_back(const T& x);</ins> +<ins>void push_back(T&& x);</ins> +template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args); +template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args); +</pre></blockquote> + +<p> +Change 23.2.4.3 [list.modifiers]: +</p> + +<blockquote><pre><ins>void push_front(const T& x);</ins> +<ins>void push_front(T&& x);</ins> +<ins>void push_back(const T& x);</ins> +<ins>void push_back(T&& x);</ins> +template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args); +template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args); +</pre></blockquote> + +<p> +Change the synopsis in 23.2.6 [vector]: +</p> + +<blockquote><pre><ins>void push_back(const T& x);</ins> +<ins>void push_back(T&& x);</ins> +template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args); +</pre></blockquote> + +<p> +Change 23.2.6.4 [vector.modifiers]: +</p> + +<blockquote><pre><ins>void push_back(const T& x);</ins> +<ins>void push_back(T&& x);</ins> +template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args); +</pre></blockquote> + + + + +<p><b>Rationale:</b></p> +<p> +Addressed by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2680.pdf">N2680 Proposed Wording for Placement Insert (Revision 1)</a>. +</p> + +<p> +If there is still an issue with pair, Howard should submit another issue. +</p> + + + + + +<hr> <h3><a name="773"></a>773. issues with random</h3> <p><b>Section:</b> 26.4.8.1 [rand.dist.uni] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-01-14</p> @@ -12949,6 +13385,132 @@ Change 30.3.3.2.3 [thread.lock.unique.mod]: <hr> +<h3><a name="786"></a>786. Thread library timed waits, UTC and monotonic clocks</h3> +<p><b>Section:</b> X [datetime.system] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Christopher Kohlhoff, Jeff Garland <b>Date:</b> 2008-02-03</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The draft C++0x thread library requires that the time points of type +<tt>system_time</tt> and returned by <tt>get_system_time()</tt> represent Coordinated +Universal Time (UTC) (section X [datetime.system]). This can lead to +surprising behavior when a library user performs a duration-based wait, +such as <tt>condition_variable::timed_wait()</tt>. A complete explanation of the +problem may be found in the +<a href="http://www.opengroup.org/onlinepubs/009695399/xrat/xsh_chap02.html#tag_03_02_08_19">Rationale for the Monotonic Clock</a> +section in POSIX, but in summary: +</p> + +<ul> +<li> +Operations such as <tt>condition_variable::timed_wait()</tt> (and its POSIX +equivalent, <tt>pthread_cond_timedwait()</tt>) are specified using absolute times +to address the problem of spurious wakeups. +</li> + +<li> +The typical use of the timed wait operations is to perform a relative +wait. This may be achieved by first calculating an absolute time as the +sum of the current time and the desired duration. In fact, the C++0x +thread library includes duration-based overloads of +<tt>condition_variable::timed_wait()</tt> that behave as if by calling the +corresponding absolute time overload with a time point value of +<tt>get_system_time() + rel_time</tt>. +</li> + +<li> +A UTC clock may be affected by changes to the system time, such as +synchronization with an external source, leap seconds, or manual changes +to the clock. +</li> + +<li> +Should the clock change during a timed wait operation, the actual +duration of the wait will not be the expected length. For example, a +user may intend a timed wait of one second duration but, due to an +adjustment of the system clock backwards by a minute, the wait instead +takes 61 seconds. +</li> +</ul> + +<p> +POSIX solves the problem by introducing a new monotonic clock, which is +unaffected by changes to the system time. When a condition variable is +initialized, the user may specify whether the monotonic clock is to be +used. (It is worth noting that on POSIX systems it is not possible to +use <tt>condition_variable::native_handle()</tt> to access this facility, since +the desired clock type must be specified during construction of the +condition variable object.) +</p> + +<p> +In the context of the C++0x thread library, there are added dimensions +to the problem due to the need to support platforms other than POSIX: +</p> + +<ul> +<li> +Some environments (such as embedded systems) do not have a UTC clock, but do have a monotonic clock. +</li> + +<li> +Some environments do not have a monotonic clock, but do have a UTC clock. +</li> + +<li> +The Microsoft Windows API's synchronization functions use relative +timeouts based on an implied monotonic clock. A program that switches +from the Windows API to the C++0x thread library will now find itself +susceptible to clock changes. +</li> +</ul> + +<p> +One possible minimal solution: +</p> + +<ul> +<li> +Strike normative references to UTC and an epoch based on 1970-01-01. +</li> + +<li> +Make the semantics of <tt>system_time</tt> and <tt>get_system_time()</tt> +implementation-defined (i.e standard library implementors may choose the +appropriate underlying clock based on the capabilities of the target +platform). +</li> + +<li> +Add a non-normative note encouraging use of a monotonic clock. +</li> + +<li> +Remove <tt>system_time::seconds_since_epoch()</tt>. +</li> + +<li> +Change the constructor <tt>explicit system_time(time_t secs, nanoseconds ns += 0)</tt> to <tt>explicit system_time(nanoseconds ns)</tt>. +</li> +</ul> + + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + +<p><b>Rationale:</b></p> +Addressed by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.html">N2661: A Foundation to Sleep On</a>. + + + + + +<hr> <h3><a name="790"></a>790. <tt>xor_combine::seed</tt> not specified</h3> <p><b>Section:</b> 26.4.4.4 [rand.adapt.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p> @@ -12967,7 +13529,7 @@ Bellevue: <blockquote> -Overcome by the previous proposal. NAD mooted by resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#789">789</a>. +Overcome by the previous proposal. NAD mooted by resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>. </blockquote> @@ -13306,5 +13868,149 @@ Bellevue: Submitter withdraws defect. "We got the wrong value for entirely the r +<hr> +<h3><a name="826"></a>826. Equivalent of <tt>%'d</tt>, or rather, lack thereof?</h3> +<p><b>Section:</b> 22.2.2.2 [locale.nm.put] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-04-07</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In the spirit of <tt>printf vs iostream</tt>... +</p> + +<p> +POSIX <tt>printf</tt> says that <tt>%'d</tt> should insert grouping characters (and the +implication is that in the absence of <tt>'</tt> no grouping characters are +inserted). The <tt>num_put</tt> facet, on the other hand, seems to always insert +grouping characters. Can this be considered a defect worth fixing for +C++0x? Maybe <tt>ios_base</tt> needs an additional flag? +</p> + +<p><i>[ +Pablo Halpern: +]</i></p> + + +<blockquote> +I'm not sure it constitutes a defect, but I would be in favor of adding +another flag (and corresponding manipulator). +</blockquote> + +<p><i>[ +Martin Sebor: +]</i></p> + + +<blockquote> +I don't know if it qualifies as a defect but I agree that there +should be an easy way to control whether the thousands separator +should or shouldn't be inserted. A new flag would be in line with +the current design of iostreams (like <tt>boolalpha</tt>, <tt>showpos</tt>, or +<tt>showbase</tt>). +</blockquote> + +<p><i>[ +Sophia Antipolis: +]</i></p> + + +<blockquote> +This is not a part of C99. LWG suggests submitting a paper may be appropriate. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="831"></a>831. wrong type for not_eof()</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#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2008-04-23</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits.specializations">issues</a> in [char.traits.specializations].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> + In Table 56 (Traits requirements) the <tt>not_eof()</tt> member function + is using an argument of type <i>e</i> which denotes an object of + type <code>X::int_type</code>. However, the specializations in + 21.1.3 [char.traits.specializations] all use <code>char_type</code>. + This would effectively mean that the argument type actually can't + represent EOF in the first place. I'm pretty sure that the type used + to be <code>int_type</code> which is quite obviously the only sensible + argument. +</p> +<p> + This issue is close to being editorial. I suspect that the proposal + changing this section to include the specializations for <code>char16_t</code> + and <code>char32_t</code> accidentally used the wrong type. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> + 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 + [char.traits.specializations.wchar_t] correct the + argument type from <code>char_type</code> to <code>int_type</code>. +</p> + + +<p><b>Rationale:</b></p> +Already fixed in WP. + + + + + +<hr> +<h3><a name="840"></a>840. <tt>pair</tt> default template argument</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#NAD">NAD</a> + <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2008-05-23</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +I have one issue with <tt>std::pair</tt>. Well, it might just be a very annoying +historical accident, but why is there no default template argument for +the second template argument? This is so annoying when the type in +question is looong and hard to write (type deduction with <tt>auto</tt> won't +help those cases where we use it as a return or argument type). +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change the synopsis in 20.2 [utility] to read: +</p> + +<blockquote><pre>template <class T1, class T2 <ins>= T1</ins>> struct pair; +</pre></blockquote> + +<p> +Change 20.2.3 [pairs] to read: +</p> + +<blockquote><pre>namespace std { + template <class T1, class T2 <ins>= T1</ins>> + struct pair { + typedef T1 first_type; + typedef T2 second_type; + ... +</pre></blockquote> + + +<p><b>Rationale:</b></p> +<tt>std::pair</tt> is a heterogeneous container. + + + + </body></html>
\ No newline at end of file diff --git a/libstdc++-v3/doc/html/ext/lwg-defects.html b/libstdc++-v3/doc/html/ext/lwg-defects.html index 01335032884..5951a9821e2 100644 --- a/libstdc++-v3/doc/html/ext/lwg-defects.html +++ b/libstdc++-v3/doc/html/ext/lwg-defects.html @@ -1,22 +1,24 @@ <!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> - +<html><head> +<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> +<title>C++ Standard Library Defect Report List</title> <style type="text/css"> p {text-align:justify} li {text-align:justify} ins {background-color:#A0FFA0} del {background-color:#FFA0A0} -</style></head><body> +</style> +</head><body> <table> <tbody><tr> <td align="left">Doc. no.</td> -<td align="left">N2613=08-0123</td> +<td align="left">N2728=08-0238</td> </tr> <tr> <td align="left">Date:</td> -<td align="left">2008-05-18</td> +<td align="left">2008-08-24</td> </tr> <tr> <td align="left">Project:</td> @@ -27,7 +29,7 @@ del {background-color:#FFA0A0} <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 R56)</h1> +<h1>C++ Standard Library Defect Report List (Revision R59)</h1> <p>Reference ISO/IEC IS 14882:1998(E)</p> <p>Also see:</p> @@ -49,6 +51,67 @@ del {background-color:#FFA0A0} <h2>Revision History</h2> <ul> +<li>R59: +2008-08-22 pre-San Francisco mailing. +<ul> +<li><b>Summary:</b><ul> +<li>192 open issues, up by 9.</li> +<li>686 closed issues, up by 0.</li> +<li>878 issues total, up by 9.</li> +</ul></li> +<li><b>Details:</b><ul> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#871">871</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#872">872</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#875">875</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#877">877</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>.</li> +</ul></li> +</ul> +</li> +<li>R58: +2008-07-28 mid-term mailing. +<ul> +<li><b>Summary:</b><ul> +<li>183 open issues, up by 12.</li> +<li>686 closed issues, down by 4.</li> +<li>869 issues total, up by 8.</li> +</ul></li> +<li><b>Details:</b><ul> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#864">864</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#869">869</a>.</li> +<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li> +<li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>.</li> +<li>Changed the following issues from WP to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>.</li> +<li>Changed the following issues from Pending NAD Editorial to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>.</li> +</ul></li> +</ul> +</li> +<li>R57: +2008-06-27 post-Sophia Antipolis mailing. +<ul> +<li><b>Summary:</b><ul> +<li>171 open issues, down by 20.</li> +<li>690 closed issues, up by 43.</li> +<li>861 issues total, up by 23.</li> +</ul></li> +<li><b>Details:</b><ul> +<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#840">840</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#858">858</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#861">861</a>.</li> +<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#839">839</a>.</li> +<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#852">852</a>.</li> +<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#851">851</a>.</li> +<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>.</li> +<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>.</li> +<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>.</li> +<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>.</li> +<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>.</li> +<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>.</li> +<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>.</li> +<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#829">829</a>.</li> +<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>.</li> +<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>.</li> +<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>.</li> +<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a>.</li> +<li>Changed the following issues from Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>.</li> +<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li> +</ul></li> +</ul> +</li> <li>R56: 2008-05-16 pre-Sophia Antipolis mailing. <ul> @@ -58,7 +121,7 @@ del {background-color:#FFA0A0} <li>838 issues total, up by 25.</li> </ul></li> <li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#826">826</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#831">831</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#838">838</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#838">838</a>.</li> <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>.</li> </ul></li> </ul> @@ -76,7 +139,7 @@ del {background-color:#FFA0A0} <li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#790">790</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#791">791</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#796">796</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#797">797</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#799">799</a>.</li> <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>.</li> <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#801">801</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a>.</li> -<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#798">798</a>.</li> +<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li> <li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>.</li> <li>Changed the following issues from NAD Future to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.</li> <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>.</li> @@ -85,13 +148,13 @@ del {background-color:#FFA0A0} <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li> <li>Changed the following issues from Review to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>.</li> <li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a>.</li> -<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>.</li> +<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>.</li> <li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>.</li> -<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li> +<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li> <li>Changed the following issues from Open to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#625">625</a>.</li> -<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#710">710</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#722">722</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#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#746">746</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#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#783">783</a>.</li> -<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#550">550</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#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a>.</li> -<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a>, <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#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#685">685</a>.</li> +<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>.</li> +<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>.</li> +<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>.</li> <li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>.</li> <li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>.</li> <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li> @@ -108,7 +171,7 @@ del {background-color:#FFA0A0} <li>787 issues total, up by 23.</li> </ul></li> <li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>.</li> <li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>.</li> <li>Changed the following issues from NAD Future to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>.</li> <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#697">697</a>.</li> @@ -126,7 +189,7 @@ del {background-color:#FFA0A0} <li>764 issues total, up by 10.</li> </ul></li> <li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>.</li> <li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>.</li> <li>Changed the following issues from Pending WP to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li> </ul></li> @@ -141,16 +204,16 @@ del {background-color:#FFA0A0} <li>754 issues total, up by 31.</li> </ul></li> <li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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-closed.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-closed.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-closed.html#754">754</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>.</li> <li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>.</li> <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>.</li> <li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a>.</li> -<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li> +<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li> <li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li> <li>Changed the following issues from New to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li> -<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li> +<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li> <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>.</li> -<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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-closed.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-closed.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 Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>.</li> <li>Changed the following issues from New to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#552">552</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>.</li> <li>Changed the following issues from Open to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#401">401</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>.</li> <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>.</li> @@ -166,7 +229,7 @@ del {background-color:#FFA0A0} <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-closed.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-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>.</li> </ul></li> </ul> </li> @@ -187,10 +250,10 @@ del {background-color:#FFA0A0} <li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li> <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>.</li> <li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>.</li> -<li>Changed the following issues from Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#644">644</a>.</li> +<li>Changed the following issues from Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>.</li> <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>.</li> <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>.</li> -<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a>.</li> +<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>.</li> <li>Changed the following issues from Ready to TRDec: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>.</li> <li>Changed the following issues from DR to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#453">453</a>.</li> <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>.</li> @@ -206,7 +269,7 @@ del {background-color:#FFA0A0} <li>696 issues total, up by 20.</li> </ul></li> <li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li> <li>Added the following Pending NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#683">683</a>.</li> <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#587">587</a>.</li> <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>.</li> @@ -223,7 +286,7 @@ del {background-color:#FFA0A0} <li>676 issues total, up by 20.</li> </ul></li> <li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>.</li> <li>Changed the following issues from Tentatively Ready to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>.</li> <li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li> <li>Changed the following issues from NAD to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#357">357</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#368">368</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a>.</li> @@ -233,7 +296,7 @@ del {background-color:#FFA0A0} <li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li> <li>Changed the following issues from Tentatively Ready to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>.</li> <li>Changed the following issues from Tentatively Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>.</li> -<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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 New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>.</li> <li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>.</li> <li>Changed the following issues from Ready to TRDec: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#598">598</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#599">599</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#600">600</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#601">601</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#602">602</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a>.</li> <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>.</li> @@ -250,9 +313,9 @@ del {background-color:#FFA0A0} <li>656 issues total, up by 37.</li> </ul></li> <li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li> <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li> -<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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 Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#614">614</a>.</li> <li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li> <li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>.</li> <li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>.</li> @@ -284,7 +347,7 @@ del {background-color:#FFA0A0} <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-defects.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li> +<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li> <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#598">598</a> - <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a> to Ready.</li> <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a> to Review.</li> <li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>.</li> @@ -373,7 +436,7 @@ Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.ht Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a> from New to Open. Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> from New to Ready. Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD. -Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a> from New to Review. +Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a> from New to Review. </li> <li>R38: 2005-07-03 pre-Mont Tremblant mailing. @@ -4092,7 +4155,7 @@ for <tt>*r++</tt> from <tt>T</tt> to "convertible to T".</p> <hr> <h3><a name="103"></a>103. set::iterator is required to be modifiable, but this allows modification of keys</h3> -<p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> +<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</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> @@ -4124,7 +4187,7 @@ goes in line with trusting user knows what he is doing. </p> <p><b>Other Options Evaluated:</b> </p> -<p>Option A. In 23.1.2 [associative.reqmts], paragraph 2, after +<p>Option A. In 23.1.4 [associative.reqmts], paragraph 2, after first sentence, and before "In addition,...", add one line: </p> @@ -4132,7 +4195,7 @@ first sentence, and before "In addition,...", add one line: <p>Modification of keys shall not change their strict weak ordering. </p> </blockquote> -<p>Option B. Add three new sentences to 23.1.2 [associative.reqmts]:</p> +<p>Option B. Add three new sentences to 23.1.4 [associative.reqmts]:</p> <blockquote> <p>At the end of paragraph 5: "Keys in an associative container @@ -4144,7 +4207,7 @@ first sentence, and before "In addition,...", add one line: type."</p> </blockquote> -<p>Option C. To 23.1.2 [associative.reqmts], paragraph 3, which +<p>Option C. To 23.1.4 [associative.reqmts], paragraph 3, which currently reads:</p> <blockquote> @@ -4170,7 +4233,7 @@ currently reads:</p> <p><b>Proposed resolution:</b></p> -<p>Add the following to 23.1.2 [associative.reqmts] at +<p>Add the following to 23.1.4 [associative.reqmts] at the indicated location:</p> <blockquote> @@ -4717,12 +4780,12 @@ operator>>(int& val);</pre> <hr> <h3><a name="119"></a>119. Should virtual functions be allowed to strengthen the exception specification?</h3> -<p><b>Section:</b> 17.4.4.8 [res.on.exception.handling] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> +<p><b>Section:</b> 17.4.4.9 [res.on.exception.handling] <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> 1998-12-15</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.exception.handling">issues</a> in [res.on.exception.handling].</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> -<p>Section 17.4.4.8 [res.on.exception.handling] states: </p> +<p>Section 17.4.4.9 [res.on.exception.handling] states: </p> <p>"An implementation may strengthen the exception-specification for a function by removing listed exceptions." </p> @@ -4746,7 +4809,7 @@ public: <p><b>Proposed resolution:</b></p> -<p>Change Section 17.4.4.8 [res.on.exception.handling] from:</p> +<p>Change Section 17.4.4.9 [res.on.exception.handling] from:</p> <p> "may strengthen the exception-specification for a function"</p> @@ -5156,7 +5219,7 @@ object parameter may be bound to an rvalue [13.3.3.1.4/3] <p>Tokyo: The LWG removed the following from the proposed resolution:</p> - <p>In 20.4.4 [meta.unary], paragraph 2, and 20.4.4.3 [meta.unary.prop], + <p>In 20.5.4 [meta.unary], paragraph 2, and 20.5.4.3 [meta.unary.prop], paragraph 2, make the conversion to auto_ptr_ref const:</p> <blockquote> <pre>template<class Y> operator auto_ptr_ref<Y>() const throw();</pre> @@ -5164,17 +5227,17 @@ object parameter may be bound to an rvalue [13.3.3.1.4/3] <p><b>Proposed resolution:</b></p> -<p>In 20.4.4 [meta.unary], paragraph 2, move +<p>In 20.5.4 [meta.unary], paragraph 2, move the <tt>auto_ptr_ref</tt> definition to namespace scope.</p> -<p>In 20.4.4 [meta.unary], paragraph 2, add +<p>In 20.5.4 [meta.unary], paragraph 2, add a public assignment operator to the <tt>auto_ptr</tt> definition: </p> <blockquote> <pre>auto_ptr& operator=(auto_ptr_ref<X> r) throw();</pre> </blockquote> -<p>Also add the assignment operator to 20.4.4.3 [meta.unary.prop]: </p> +<p>Also add the assignment operator to 20.5.4.3 [meta.unary.prop]: </p> <blockquote> <pre>auto_ptr& operator=(auto_ptr_ref<X> r) throw()</pre> @@ -5227,7 +5290,7 @@ stream state in case of failure.</p> <hr> <h3><a name="130"></a>130. Return type of container::erase(iterator) differs for associative containers</h3> -<p><b>Section:</b> 23.1.2 [associative.reqmts], 23.1.1 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> +<p><b>Section:</b> 23.1.4 [associative.reqmts], 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-03-02</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</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> @@ -5244,7 +5307,7 @@ fail to meet the requirements for containers.</p> <p><b>Proposed resolution:</b></p> <p> -In 23.1.2 [associative.reqmts], in Table 69 Associative container +In 23.1.4 [associative.reqmts], in Table 69 Associative container requirements, change the return type of <tt>a.erase(q)</tt> from <tt>void</tt> to <tt>iterator</tt>. Change the assertion/not/pre/post-condition from "erases the element pointed to @@ -5255,7 +5318,7 @@ is returned." </p> <p> -In 23.1.2 [associative.reqmts], in Table 69 Associative container +In 23.1.4 [associative.reqmts], in Table 69 Associative container requirements, change the return type of <tt>a.erase(q1, q2)</tt> from <tt>void</tt> to <tt>iterator</tt>. Change the assertion/not/pre/post-condition from "erases the elements in the @@ -5518,7 +5581,7 @@ in the standard.</p> <hr> <h3><a name="139"></a>139. Optional sequence operation table description unclear</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#TC">TC</a> +<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-03-30</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#TC">TC</a> status.</p> @@ -5855,7 +5918,7 @@ two places:</p> <hr> <h3><a name="150"></a>150. Find_first_of says integer instead of iterator </h3> -<p><b>Section:</b> 25.1.4 [alg.find.first.of] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> +<p><b>Section:</b> 25.1.7 [alg.find.first.of] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt McClure <b>Date:</b> 1999-06-30</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find.first.of">issues</a> in [alg.find.first.of].</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> @@ -5863,7 +5926,7 @@ two places:</p> <p><b>Proposed resolution:</b></p> -<p>Change 25.1.4 [alg.find.first.of] paragraph 2 from:</p> +<p>Change 25.1.7 [alg.find.first.of] paragraph 2 from:</p> <blockquote> <p>Returns: The first iterator i in the range [first1, last1) such @@ -5882,7 +5945,7 @@ that for some iterator j in the range [first2, last2) ...</p> <hr> <h3><a name="151"></a>151. Can't currently clear() empty container</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#TC">TC</a> +<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Ed Brey <b>Date:</b> 1999-06-21</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#TC">TC</a> status.</p> @@ -7263,12 +7326,12 @@ Josuttis provided the above wording.]</i></p> <hr> <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> +<p><b>Section:</b> 20.6 [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 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>Paragraph 4 of 20.5 [function.objects] says:</p> +<p>Paragraph 4 of 20.6 [function.objects] says:</p> <blockquote> <p> [Example: To negate every element of a: transform(a.begin(), a.end(), a.begin(), negate<double>()); The corresponding functions will inline @@ -7295,17 +7358,17 @@ not required elsewhere.</p> <p><b>Proposed resolution:</b></p> -<p>In 20.5 [function.objects] paragraph 1, remove the sentence:</p> +<p>In 20.6 [function.objects] paragraph 1, remove the sentence:</p> <blockquote> <p>They are important for the effective use of the library.</p> </blockquote> -<p>Remove 20.5 [function.objects] paragraph 2, which reads:</p> +<p>Remove 20.6 [function.objects] paragraph 2, which reads:</p> <blockquote> <p> Using function objects together with function templates increases the expressive power of the library as well as making the resulting code much more efficient.</p> </blockquote> -<p>In 20.5 [function.objects] paragraph 4, remove the sentence:</p> +<p>In 20.6 [function.objects] paragraph 4, remove the sentence:</p> <blockquote> <p>The corresponding functions will inline the addition and the negation.</p> @@ -8461,7 +8524,6 @@ is.setstate(ios::failbit) which may throw ios_base::failure <h3><a name="212"></a>212. Empty range behavior unclear for several algorithms</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#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 2000-02-26</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.min.max">active issues</a> in [alg.min.max].</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#TC">TC</a> status.</p> <p><b>Discussion:</b></p> @@ -8760,7 +8822,7 @@ footnote.</p> <hr> <h3><a name="224"></a>224. clear() complexity for associative containers refers to undefined N</h3> -<p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> +<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Ed Brey <b>Date:</b> 2000-03-23</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</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> @@ -9401,7 +9463,7 @@ change "T is Assignable" to "T is CopyConstructible and Assignable" </p> -<p>In 23.1.2 [associative.reqmts] table 69 X::key_type; change +<p>In 23.1.4 [associative.reqmts] table 69 X::key_type; change "Key is Assignable" to "Key is CopyConstructible and Assignable"<br> </p> @@ -9585,7 +9647,7 @@ rationale.]</i></p> <hr> <h3><a name="233"></a>233. Insertion hints in associative containers</h3> -<p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> +<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2000-04-30</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</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> @@ -9693,7 +9755,7 @@ is no longer needed (or reflected in the proposed wording below). <p> Change the indicated rows of the "Associative container requirements" Table in -23.1.2 [associative.reqmts] to: +23.1.4 [associative.reqmts] to: </p> <p></p><center> @@ -9736,7 +9798,7 @@ logarithmic in general, but amortized constant if <tt>t</tt> is inserted right < <hr> <h3><a name="234"></a>234. Typos in allocator definition</h3> -<p><b>Section:</b> 20.6.5.1 [allocator.members] <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.7.5.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> Dietmar Kühl <b>Date:</b> 2000-04-24</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> @@ -9888,7 +9950,7 @@ applications of the corresponding predicate.</p></blockquote> <hr> <h3><a name="240"></a>240. Complexity of adjacent_find() is meaningless</h3> -<p><b>Section:</b> 25.1.5 [alg.adjacent.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> +<p><b>Section:</b> 25.1.8 [alg.adjacent.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 2000-05-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> @@ -9928,7 +9990,7 @@ an "as-if" specification.</p> <p><b>Proposed resolution:</b></p> -<p>Change the complexity section in 25.1.5 [alg.adjacent.find] to:</p> +<p>Change the complexity section in 25.1.8 [alg.adjacent.find] to:</p> <blockquote><p> For a nonempty range, exactly <tt>min((<i>i</i> - <i>first</i>) + 1, (<i>last</i> - <i>first</i>) - 1)</tt> applications of the @@ -10519,6 +10581,7 @@ issue is stylistic rather than a matter of correctness.</p> <h3><a name="253"></a>253. valarray helper functions are almost entirely useless</h3> <p><b>Section:</b> 26.5.2.1 [valarray.cons], 26.5.2.2 [valarray.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Robert Klarer <b>Date:</b> 2000-07-31</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#WP">WP</a> status.</p> <p><b>Discussion:</b></p> @@ -11471,7 +11534,7 @@ Change the following sentence in 21.3 paragraph 5 from <hr> <h3><a name="264"></a>264. Associative container <tt>insert(i, j)</tt> complexity requirements are not feasible.</h3> -<p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> +<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> John Potter <b>Date:</b> 2000-09-07</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</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> @@ -12425,7 +12488,6 @@ this solution is safe and correct. <h3><a name="281"></a>281. std::min() and max() requirements overly restrictive</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#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-12-02</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#alg.min.max">active issues</a> in [alg.min.max].</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#WP">WP</a> status.</p> <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#486">486</a></p> @@ -12675,11 +12737,11 @@ imposing a greater restriction that what the standard currently says <hr> <h3><a name="284"></a>284. unportable example in 20.3.7, p6</h3> -<p><b>Section:</b> 20.5.7 [comparisons] <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.7 [comparisons] <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-12-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>The example in 20.5.7 [comparisons], p6 shows how to use the C +<p>The example in 20.6.7 [comparisons], p6 shows how to use the C library function <tt>strcmp()</tt> with the function pointer adapter <tt>ptr_fun()</tt>. But since it's unspecified whether the C library functions have <tt>extern "C"</tt> or <tt>extern @@ -12691,7 +12753,7 @@ well-formed is unspecified. <p><b>Proposed resolution:</b></p> -<p>Change 20.5.7 [comparisons] paragraph 6 from:</p> +<p>Change 20.6.7 [comparisons] paragraph 6 from:</p> <blockquote> <p>[<i>Example:</i></p> <pre> replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), "C")), "C++"); @@ -13035,7 +13097,6 @@ it isn't stringent enough.</p> <h3><a name="295"></a>295. Is abs defined in <cmath>?</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#WP">WP</a> <b>Submitter:</b> Jens Maurer <b>Date:</b> 2001-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#WP">WP</a> status.</p> <p><b>Discussion:</b></p> @@ -13072,7 +13133,7 @@ putting in <cstdlib>. That's issue <a href="http://www.open-std.org/jtc1/ <hr> <h3><a name="297"></a>297. const_mem_fun_t<>::argument_type should be const T*</h3> -<p><b>Section:</b> 20.5.8 [logical.operations] <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.8 [logical.operations] <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> 2001-01-06</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> @@ -14044,7 +14105,7 @@ comment in c++std-lib-8939. <p><b>Discussion:</b></p> <p>Table 27 in section 20 lists the header <memory> (only) for Memory (lib.memory) but neglects to mention the headers -<cstdlib> and <cstring> that are discussed in 20.4.5 [meta.rel].</p> +<cstdlib> and <cstring> that are discussed in 20.5.5 [meta.rel].</p> <p><b>Proposed resolution:</b></p> @@ -14084,7 +14145,7 @@ Change the "range" from (last - first) to [first, last). <hr> <h3><a name="316"></a>316. Vague text in Table 69</h3> -<p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> +<p><b>Section:</b> 23.1.4 [associative.reqmts] <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> 2001-05-04</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</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> @@ -14306,7 +14367,7 @@ Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't. <p>Effects: Replaces the contents of the list with the range [first, last).</p> </blockquote> -<p>In 23.1.1 [sequence.reqmts], in Table 67 (sequence requirements), +<p>In 23.1.3 [sequence.reqmts], in Table 67 (sequence requirements), add two new rows:</p> <pre> a.assign(i,j) void pre: i,j are not iterators into a. Replaces elements in a with a copy @@ -14791,7 +14852,7 @@ reallocation guarantees was inadvertant.</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> -With the change in 17.4.4.8 [res.on.exception.handling] to state +With the change in 17.4.4.9 [res.on.exception.handling] to state "An implementation may strengthen the exception-specification for a non-virtual function by removing listed exceptions." (issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#119">119</a>) @@ -15093,7 +15154,7 @@ library (though a deprecated one).</p> <li>17.4.1.2 [headers] Headers/4</li> <li>17.4.3.5 [replacement.functions] Replacement functions/1</li> <li>17.4.4.3 [global.functions] Global or non-member functions/2</li> -<li>17.4.4.6 [protection.within.classes] Protection within classes/1</li> +<li>17.4.4.7 [protection.within.classes] Protection within classes/1</li> </ul> @@ -15687,7 +15748,7 @@ be considered NAD.</p> <hr> <h3><a name="354"></a>354. Associative container lower/upper bound requirements</h3> -<p><b>Section:</b> 23.1.2 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> +<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Hans Aberg <b>Date:</b> 2001-12-17</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</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> @@ -15727,7 +15788,7 @@ the intention (and not possible with the "const" versions). <p><b>Proposed resolution:</b></p> -<p>Change Table 69 of section 23.1.2 [associative.reqmts] indicated entries +<p>Change Table 69 of section 23.1.4 [associative.reqmts] indicated entries to:</p> <blockquote> @@ -15753,7 +15814,7 @@ key greater than k, or a.end() if such an element is not found. <hr> <h3><a name="355"></a>355. Operational semantics for a.back()</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#WP">WP</a> +<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Yaroslav Mironov <b>Date:</b> 2002-01-23</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#WP">WP</a> status.</p> @@ -16453,7 +16514,7 @@ erase_if() member function that much greater. <p><b>Proposed resolution:</b></p> -<p>Add the following to the end of 23.1.2 [associative.reqmts] paragraph 4: +<p>Add the following to the end of 23.1.4 [associative.reqmts] paragraph 4: "For <tt>multiset</tt> and <tt>multimap</tt>, <tt>insert</tt>and <tt>erase</tt> are <i>stable</i>: they preserve the relative ordering of equivalent elements.</p> @@ -17052,7 +17113,6 @@ const in the header file synopsis in section 22.1 [locales]. <h3><a name="395"></a>395. inconsistencies in the definitions of rand() and random_shuffle()</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#WP">WP</a> <b>Submitter:</b> James Kanze <b>Date:</b> 2003-01-03</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#WP">WP</a> status.</p> <p><b>Discussion:</b></p> @@ -17105,13 +17165,13 @@ implementation is permitted to use <tt>rand</tt>.] <hr> <h3><a name="400"></a>400. redundant type cast in lib.allocator.members</h3> -<p><b>Section:</b> 20.6.5.1 [allocator.members] <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.7.5.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> <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>Discussion:</b></p> <p> -20.6.5.1 [allocator.members] allocator members, contains +20.7.5.1 [allocator.members] allocator members, contains the following 3 lines: </p> @@ -17223,7 +17283,7 @@ issue to Ready status to be voted into the WP at Kona. <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.5.1 [allocator.members] <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.1.2 [allocator.requirements], 20.7.5.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> <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> @@ -17231,13 +17291,13 @@ issue to Ready status to be voted into the WP at Kona. <p><b>Discussion:</b></p> <p> This applies to the new expression that is contained in both par12 of -20.6.5.1 [allocator.members] and in par2 (table 32) of [default.con.req]. +20.7.5.1 [allocator.members] and in par2 (table 32) of [default.con.req]. I think this new expression is wrong, involving unintended side effects. </p> -<p>20.6.5.1 [allocator.members] contains the following 3 lines:</p> +<p>20.7.5.1 [allocator.members] contains the following 3 lines:</p> <pre> 11 Returns: the largest value N for which the call allocate(N,0) might succeed. void construct(pointer p, const_reference val); @@ -18094,7 +18154,7 @@ use the right wording.]</i></p> <hr> <h3><a name="425"></a>425. return value of std::get_temporary_buffer</h3> -<p><b>Section:</b> 20.6.8 [temporary.buffer] <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.7.8 [temporary.buffer] <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 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> @@ -18109,7 +18169,7 @@ is when the argument is less than 0. <p><b>Proposed resolution:</b></p> -<p>Change 20.4.3 [meta.help] paragraph 2 from "...or a pair of 0 +<p>Change 20.5.3 [meta.help] paragraph 2 from "...or a pair of 0 values if no storage can be obtained" to "...or a pair of 0 values if no storage can be obtained or if <i>n</i> <= 0."</p> <p><i>[Kona: Matt provided wording]</i></p> @@ -18120,7 +18180,7 @@ no storage can be obtained or if <i>n</i> <= 0."</p> <hr> <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> +<p><b>Section:</b> 25.1.12 [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> @@ -18677,13 +18737,13 @@ text.]</i></p> <hr> <h3><a name="438"></a>438. Ambiguity in the "do the right thing" clause</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#DR">DR</a> +<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2003-10-20</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#DR">DR</a> status.</p> <p><b>Discussion:</b></p> -<p>Section 23.1.1 [sequence.reqmts], paragraphs 9-11, fixed up the problem +<p>Section 23.1.3 [sequence.reqmts], paragraphs 9-11, fixed up the problem noticed with statements like:</p> <pre>vector<int> v(10, 1); </pre> @@ -18881,7 +18941,7 @@ T implicit_cast(const U& u) <p><b>Proposed resolution:</b></p> -<p>Replace 23.1.1 [sequence.reqmts] paragraphs 9 - 11 with:</p> +<p>Replace 23.1.3 [sequence.reqmts] paragraphs 9 - 11 with:</p> <p>For every sequence defined in this clause and in clause lib.strings:</p> @@ -19068,7 +19128,6 @@ of <tt>sentry::operator bool()</tt> to const. <h3><a name="443"></a>443. filebuf::close() inconsistent use of EOF</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#WP">WP</a> <b>Submitter:</b> Vincent Leloup <b>Date:</b> 2003-11-20</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#WP">WP</a> status.</p> <p><b>Discussion:</b></p> @@ -19607,7 +19666,6 @@ names within the namespace <tt>std</tt>.</ins> <i>-- end example</i>] <h3><a name="457"></a>457. bitset constructor: incorrect number of initialized bits</h3> <p><b>Section:</b> 23.3.5.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Dag Henriksson <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#bitset.cons">active issues</a> in [bitset.cons].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.cons">issues</a> in [bitset.cons].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p> <p><b>Discussion:</b></p> @@ -20084,7 +20142,7 @@ I propose to strike the Footnote. <hr> <h3><a name="475"></a>475. May the function object passed to for_each modify the elements of the iterated sequence?</h3> -<p><b>Section:</b> 25.1.1 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> +<p><b>Section:</b> 25.1.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Stephan T. Lavavej, Jaakko Jarvi <b>Date:</b> 2004-07-09</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.foreach">issues</a> in [alg.foreach].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> @@ -20149,7 +20207,7 @@ passed to for_each modify its argument.</p> <p><b>Proposed resolution:</b></p> -<p>Add a nonnormative note to the Effects in 25.1.1 [alg.foreach]: If +<p>Add a nonnormative note to the Effects in 25.1.4 [alg.foreach]: If the type of 'first' satisfies the requirements of a mutable iterator, 'f' may apply nonconstant functions through the dereferenced iterators passed to it. @@ -20653,6 +20711,75 @@ just above paragraph 5. <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.5 [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#WP">WP</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Issue 371 deals with stability of multiset/multimap under insert and erase +(i.e. do they preserve the relative order in ranges of equal elements). +The same issue applies to unordered_multiset and unordered_multimap. +</p> +<p><i>[ +Moved to open (from review): There is no resolution. +]</i></p> + + +<p><i>[ +Toronto: We have a resolution now. Moved to Review. Some concern was noted +as to whether this conflicted with existing practice or not. An additional +concern was in specifying (partial) ordering for an unordered container. +]</i></p> + + + + +<p><b>Proposed resolution:</b></p> +<p> +Wording for the proposed resolution is taken from the equivalent text for associative containers. +</p> + +<p> +Change 23.1.5 [unord.req], Unordered associative containers, paragraph 6 to: +</p> + +<blockquote><p> +An unordered associative container supports <i>unique</i> keys if it may +contain at most one element for each key. Otherwise, it supports <i>equivalent +keys</i>. <tt>unordered_set</tt> and <tt>unordered_map</tt> support +unique keys. <tt>unordered_multiset</tt> and <tt>unordered_multimap</tt> +support equivalent keys. In containers that support equivalent keys, elements +with equivalent keys are adjacent to each other. <ins>For +<tt>unordered_multiset</tt> +and <tt>unordered_multimap</tt>,<tt> insert</tt> and <tt>erase</tt> +preserve the relative ordering of equivalent elements.</ins> +</p></blockquote> + +<p> +Change 23.1.5 [unord.req], Unordered associative containers, paragraph 8 to: +</p> + +<blockquote> +<p>The elements of an unordered associative container are organized into <i> +buckets</i>. Keys with the same hash code appear in the same bucket. The number +of buckets is automatically increased as elements are added to an unordered +associative container, so that the average number of elements per bucket is kept +below a bound. Rehashing invalidates iterators, changes ordering between +elements, and changes which buckets elements appear in, but does not invalidate +pointers or references to elements. <ins>For <tt>unordered_multiset</tt> +and <tt>unordered_multimap</tt>, rehashing +preserves the relative ordering of equivalent elements.</ins></p> +</blockquote> + + + + + + +<hr> <h3><a name="519"></a>519. Data() undocumented</h3> <p><b>Section:</b> 23.2.1 [array], TR1 6.2.2 [tr.array.array] <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> @@ -20689,7 +20816,7 @@ of <tt>data()</tt> is unspecified. <hr> <h3><a name="520"></a>520. Result_of and pointers to data members</h3> -<p><b>Section:</b> 20.5.11.1 [func.bind], TR1 3.6 [tr.func.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> +<p><b>Section:</b> 20.6.11.1 [func.bind], TR1 3.6 [tr.func.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Pete Becker <b>Date:</b> 2005-07-03</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> <p><b>Discussion:</b></p> @@ -20732,7 +20859,7 @@ Peter provided wording. <hr> <h3><a name="521"></a>521. Garbled requirements for argument_type in reference_wrapper</h3> -<p><b>Section:</b> 20.5.5 [refwrap], TR1 2.1.2 [tr.util.refwrp.refwrp] <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.5 [refwrap], TR1 2.1.2 [tr.util.refwrp.refwrp] <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> @@ -20881,7 +21008,7 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a <hr> <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#WP">WP</a> +<p><b>Section:</b> 20.6.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#WP">WP</a> <b>Submitter:</b> Peter Dimov <b>Date:</b> 2005-10-01</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.bind.bind">active issues</a> in [func.bind.bind].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p> @@ -20949,7 +21076,7 @@ throws an exception. <p><b>Proposed resolution:</b></p> <p> -In 20.5.11.1.3 [func.bind.bind], add a new paragraph after p2: +In 20.6.11.1.3 [func.bind.bind], add a new paragraph after p2: </p> <blockquote> @@ -20958,7 +21085,7 @@ in the <tt>BoundArgs...</tt> pack expansion throws an exception. </blockquote> <p> -In 20.5.11.1.3 [func.bind.bind], add a new paragraph after p4: +In 20.6.11.1.3 [func.bind.bind], add a new paragraph after p4: </p> <blockquote> @@ -21103,7 +21230,7 @@ writing to out of bounds memory when <tt>n == 0</tt>. Martin provided fix. <hr> <h3><a name="533"></a>533. typo in 2.2.3.10/1</h3> -<p><b>Section:</b> 20.6.12.2.11 [util.smartptr.getdeleter], TR1 2.2.3.10 [tr.util.smartptr.getdeleter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> +<p><b>Section:</b> 20.7.12.2.11 [util.smartptr.getdeleter], TR1 2.2.3.10 [tr.util.smartptr.getdeleter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2005-11-09</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.getdeleter">issues</a> in [util.smartptr.getdeleter].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p> @@ -21428,7 +21555,7 @@ Otherwise CopyConstructible is not required. <hr> <h3><a name="540"></a>540. shared_ptr<void>::operator*()</h3> -<p><b>Section:</b> 20.6.12.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] <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.7.12.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] <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-15</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#WP">WP</a> status.</p> @@ -21486,7 +21613,7 @@ definition) of the function shall be well-formed.</ins> <hr> <h3><a name="541"></a>541. shared_ptr template assignment and void</h3> -<p><b>Section:</b> 20.6.12.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> +<p><b>Section:</b> 20.7.12.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> @@ -21567,7 +21694,7 @@ public: <hr> <h3><a name="542"></a>542. shared_ptr observers</h3> -<p><b>Section:</b> 20.6.12.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] <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.7.12.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] <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-18</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#WP">WP</a> status.</p> @@ -21607,7 +21734,7 @@ capture the intent. <p><b>Proposed resolution:</b></p> <p> -Change 20.6.12.2.5 [util.smartptr.shared.obs] p12: +Change 20.7.12.2.5 [util.smartptr.shared.obs] p12: </p> <blockquote><p> [<i>Note:</i> <tt>use_count()</tt> is not necessarily efficient. <del>Use only for @@ -21615,7 +21742,7 @@ debugging and testing purposes, not for production code.</del> --<i>end note</i> </p></blockquote> <p> -Change 20.6.12.3.5 [util.smartptr.weak.obs] p3: +Change 20.7.12.3.5 [util.smartptr.weak.obs] p3: </p> <blockquote><p> [<i>Note:</i> <tt>use_count()</tt> is not necessarily efficient. <del>Use only for @@ -21704,7 +21831,7 @@ lengths, and strides, as explained in the previous section. <hr> <h3><a name="545"></a>545. When is a deleter deleted?</h3> -<p><b>Section:</b> 20.6.12.2.11 [util.smartptr.getdeleter], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> +<p><b>Section:</b> 20.7.12.2.11 [util.smartptr.getdeleter], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.getdeleter">issues</a> in [util.smartptr.getdeleter].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> @@ -21722,7 +21849,7 @@ instances). We should say which it is. <p><b>Proposed resolution:</b></p> <p> -Add after the first sentence of 20.6.12.2.11 [util.smartptr.getdeleter]/1: +Add after the first sentence of 20.7.12.2.11 [util.smartptr.getdeleter]/1: </p> <blockquote> <p> @@ -21741,6 +21868,144 @@ This can happen if the implementation doesn't destroy the deleter until all <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#WP">WP</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-01-12</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Assuming we adopt the +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">C +compatibility package from C99</a> what should be the return type of the +following signature be: +</p> +<blockquote><pre>? pow(float, int); +</pre></blockquote> +<p> +C++03 says that the return type should be <tt>float</tt>. +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf"> +TR1</a> and C90/99 say the return type should be <tt>double</tt>. This can put +clients into a situation where C++03 provides answers that are not as high +quality as C90/C99/TR1. For example: +</p> +<blockquote><pre>#include <math.h> + +int main() +{ + float x = 2080703.375F; + double y = pow(x, 2); +} +</pre></blockquote> +<p> +Assuming an IEEE 32 bit float and IEEE 64 bit double, C90/C99/TR1 all suggest: +</p> + +<blockquote><pre>y = 4329326534736.390625 +</pre></blockquote> + +<p> +which is exactly right. While C++98/C++03 demands: +</p> + +<blockquote><pre>y = 4329326510080. +</pre></blockquote> + +<p> +which is only approximately right. +</p> + +<p> +I recommend that C++0X adopt the mixed mode arithmetic already adopted by +Fortran, C and TR1 and make the return type of <tt>pow(float,int)</tt> be +<tt>double</tt>. +</p> + +<p><i>[ +Kona (2007): Other functions that are affected by this issue include +<tt>ldexp</tt>, <tt>scalbln</tt>, and <tt>scalbn</tt>. We also believe that there is a typo in +26.7/10: <tt>float nexttoward(float, long double);</tt> [sic] should be <tt>float +nexttoward(float, float);</tt> Proposed Disposition: Review (the proposed +resolution appears above, rather than below, the heading "Proposed +resolution") +]</i></p> + + +<p><i>[ +<p> +Howard, post Kona: +</p> +<blockquote> +<p> +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. +</p> +<p> +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>. +</p> +<p> +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: +</p> +<blockquote> +<pre>float nexttoward(float, long double); +</pre> +</blockquote> +<p> +which is what both the C++0X working paper and C99 state (as far as I currently understand). +</p> +<p> +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. +</p> +</blockquote> +]</i></p> + + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +This signature was not picked up from C99. Instead, if one types +pow(2.0f,2), the promotion rules will invoke "double pow(double, +double)", which generally gives special treatment for integral +exponents, preserving full accuracy of the result. New proposed +wording provided. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 26.7 [c.math] p10: +</p> + +<blockquote> +<p> +The added signatures are: +</p> +<blockquote><pre>... +<del>float pow(float, int);</del> +... +<del>double pow(double, int);</del> +... +<del>long double pow(long double, int);</del> +</pre></blockquote> +</blockquote> + + + + + + +<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#WP">WP</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-01-23</p> @@ -22376,8 +22641,60 @@ Kona (2007): Proposed Disposition: Ready <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#WP">WP</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +lib.iostream.objects requires that the standard stream objects are never +destroyed, and it requires that they be destroyed. +</p> +<p> +DR 369 adds words to say that we really mean for ios_base::Init objects to force +construction of standard stream objects. It ends, though, with the phrase "these +stream objects shall be destroyed after the destruction of dynamically ...". +However, the rule for destruction is stated in the standard: "The objects are +not destroyed during program execution." +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 27.3 [iostream.objects]/1: +</p> + +<blockquote> +<p> +-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><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="575"></a>575. the specification of ~shared_ptr is MT-unfriendly, makes implementation assumptions</h3> -<p><b>Section:</b> 20.6.12.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> +<p><b>Section:</b> 20.7.12.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> <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> @@ -22455,7 +22772,7 @@ after <tt>*this</tt> is destroyed. <i>--end note</i>] <hr> <h3><a name="576"></a>576. find_first_of is overconstrained</h3> -<p><b>Section:</b> 25.1.4 [alg.find.first.of] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> +<p><b>Section:</b> 25.1.7 [alg.find.first.of] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Doug Gregor <b>Date:</b> 2006-04-25</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find.first.of">issues</a> in [alg.find.first.of].</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> @@ -22558,7 +22875,7 @@ conditions hold: <tt>!(value < *j)</tt> or <tt><i>comp</i>(<i>value</i>, *j) <hr> <h3><a name="578"></a>578. purpose of hint to allocator::allocate()</h3> -<p><b>Section:</b> 20.6.5.1 [allocator.members] <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.7.5.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> <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> @@ -22867,6 +23184,296 @@ particular, the symbols __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS <hr> +<h3><a name="595"></a>595. TR1/C++0x: fabs(complex<T>) redundant / wrongly specified</h3> +<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#WP">WP</a> + <b>Submitter:</b> Stefan Große Pawig <b>Date:</b> 2006-09-24</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.value.ops">issues</a> in [complex.value.ops].</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> +TR1 introduced, in the C compatibility chapter, the function +fabs(complex<T>): +</p> +<blockquote><pre>----- SNIP ----- +8.1.1 Synopsis [tr.c99.cmplx.syn] + + namespace std { + namespace tr1 { +[...] + template<class T> complex<T> fabs(const complex<T>& x); + } // namespace tr1 + } // namespace std + +[...] + +8.1.8 Function fabs [tr.c99.cmplx.fabs] + +1 Effects: Behaves the same as C99 function cabs, defined in + subclause 7.3.8.1. +----- SNIP ----- +</pre></blockquote> + +<p> +The current C++0X draft document (n2009.pdf) adopted this +definition in chapter 26.3.1 (under the comment // 26.3.7 values) +and 26.3.7/7. +</p> +<p> +But in C99 (ISO/IEC 9899:1999 as well as the 9899:TC2 draft document +n1124), the referenced subclause reads +</p> + +<blockquote><pre>----- SNIP ----- +7.3.8.1 The cabs functions + + Synopsis + +1 #include <complex.h> + double cabs(double complex z); + float cabsf(float complex z); + long double cabsl(long double z); + + Description + +2 The cabs functions compute the complex absolute value (also called + norm, modulus, or magnitude) of z. + + Returns + +3 The cabs functions return the complex absolute value. +----- SNIP ----- +</pre></blockquote> + +<p> +Note that the return type of the cabs*() functions is not a complex +type. Thus, they are equivalent to the already well established + template<class T> T abs(const complex<T>& x); +(26.2.7/2 in ISO/IEC 14882:1998, 26.3.7/2 in the current draft +document n2009.pdf). +</p> +<p> +So either the return value of fabs() is specified wrongly, or fabs() +does not behave the same as C99's cabs*(). +</p> + +<b>Possible Resolutions</b> + +<p> +This depends on the intention behind the introduction of fabs(). +</p> +<p> +If the intention was to provide a /complex/ valued function that +calculates the magnitude of its argument, this should be +explicitly specified. In TR1, the categorization under "C +compatibility" is definitely wrong, since C99 does not provide +such a complex valued function. +</p> +<p> +Also, it remains questionable if such a complex valued function +is really needed, since complex<T> supports construction and +assignment from real valued arguments. There is no difference +in observable behaviour between +</p> +<blockquote><pre> complex<double> x, y; + y = fabs(x); + complex<double> z(fabs(x)); +</pre></blockquote> +<p> +and +</p> +<blockquote><pre> complex<double> x, y; + y = abs(x); + complex<double> z(abs(x)); +</pre></blockquote> +<p> +If on the other hand the intention was to provide the intended +functionality of C99, fabs() should be either declared deprecated +or (for C++0X) removed from the standard, since the functionality +is already provided by the corresponding overloads of abs(). +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Bill believes that abs() is a suitable overload. We should remove fabs(). +</blockquote> + + +<p><b>Proposed resolution:</b></p> + +<p> +Change the synopsis in 26.3.1 [complex.synopsis]: +</p> + +<blockquote><pre><del>template<class T> complex<T> fabs(const complex<T>&);</del> +</pre></blockquote> + +<p> +Remove 26.3.7 [complex.value.ops], p7: +</p> + +<blockquote> +<pre><del>template<class T> complex<T> fabs(const complex<T>& <i>x</i>);</del> +</pre> +<blockquote> +<p> +<del>-7- <i>Effects:</i> Behaves the same as C99 function <tt>cabs</tt>, defined in subclause 7.3.8.1.</del> +</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#WP">WP</a> + <b>Submitter:</b> Thomas Plum <b>Date:</b> 2006-09-26</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +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> +and we expect the open to fail, because out|in|app is not listed in +Table 92, and just before the table we see very specific words: +</p> +<blockquote><p> + If mode is not some combination of flags shown in the table + then the open fails. +</p></blockquote> +<p> +But the corresponding table in the C standard, 7.19.5.3, provides two +modes "a+" and "a+b", to which the C++ modes out|in|app and +out|in|app|binary would presumably apply. +</p> +<p> +We would like to argue that the intent of Table 112 was to match the +semantics of 7.19.5.3 and that the omission of "a+" and "a+b" was +unintentional. (Otherwise there would be valid and useful behaviors +available in C file I/O which are unavailable using C++, for no +valid functional reason.) +</p> +<p> +We further request that the missing modes be explicitly restored to +the WP, for inclusion in C++0x. +</p> + +<p><i>[ +Martin adds: +]</i></p> + + +<p> +...besides "a+" and "a+b" the C++ table is also missing a row +for a lone app bit which in at least two current implementation +as well as in Classic Iostreams corresponds to the C stdio "a" +mode and has been traditionally documented as implying ios::out. +Which means the table should also have a row for in|app meaning +the same thing as "a+" already proposed in the issue. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add to the table "File open modes" in 27.8.1.4 [filebuf.members]: +</p> + +<blockquote> +<table border="1"> +<caption> File open modes</caption> +<tbody><tr> +<th colspan="5"><tt>ios_base</tt> Flag combination</th> +<th><tt>stdio</tt> equivalent</th> +</tr> +<tr> +<th><tt>binary</tt></th><th><tt>in</tt></th><th><tt>out</tt></th><th><tt>trunc</tt></th><th><tt>app</tt></th><th><tt> </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="598"></a>598. Decimal: Conversion to integral should truncate, not round.</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#TRDec">TRDec</a> <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p> @@ -23530,7 +24137,7 @@ and accept my apologies for the oversight. <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> +<p><b>Section:</b> 20.6.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> @@ -23668,6 +24275,61 @@ component</ins>. </li> <hr> +<h3><a name="612"></a>612. numeric_limits::is_modulo insufficiently 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#WP">WP</a> + <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2006-11-10</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.limits.members">issues</a> in [numeric.limits.members].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +18.2.1.2 55 states that "A type is modulo if it is possible to add two +positive numbers together and have a result that wraps around to a +third number that is less". +This seems insufficient for the following reasons: +</p> + +<ol> +<li>Doesn't define what that value received is.</li> +<li>Doesn't state the result is repeatable</li> +<li> Doesn't require that doing addition, subtraction and other +operations on all values is defined behaviour.</li> +</ol> + +<p><i>[ +Batavia: Related to +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2144.pdf">N2144</a>. +Pete: is there an ISO definition of modulo? Underflow on signed behavior is undefined. +]</i></p> + + +<p><i>[ +Bellevue: accept resolution, move to ready status. +Does this mandate that is_modulo be true on platforms for which int +happens to b modulo? A: the standard already seems to require that. +]</i></p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Suggest 18.2.1.2 [numeric.limits.members], paragraph 57 is amended to: +</p> + +<blockquote><p> +A type is modulo if<ins>,</ins> <del>it is possible to add two positive numbers +and have a result that wraps around to a third number that is less.</del> +<ins>given any operation involving +,- or * on values of that type whose value +would fall outside the range <tt>[min(), max()]</tt>, then the value returned +differs from the true value by an integer multiple of <tt>(max() - min() + +1)</tt>.</ins> +</p></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> @@ -23795,8 +24457,65 @@ as this is a dependent type, it should obviously be <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#WP">WP</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +I would respectfully request an issue be opened with the intention to +clarify the wording for <tt>size() == 0</tt> for <tt>cshift</tt>. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +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>, <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>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="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> +<p><b>Section:</b> 18.9 [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> @@ -23804,7 +24523,7 @@ as this is a dependent type, it should obviously be The wording for <tt>longjmp</tt> is confusing. </p> <p> -18.8 [support.runtime] -4- Other runtime support +18.9 [support.runtime] -4- Other runtime support </p> <blockquote><p> The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more restricted @@ -23830,7 +24549,7 @@ caught only at the point of the setjmp, the behavior is undefined." 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 +In 18.9 [support.runtime] paragraph 4, change </p> <blockquote><p> @@ -23852,6 +24571,7 @@ undefined behavior if replacing the <tt>setjmp</tt> and <tt>longjmp</tt> by <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#WP">WP</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#WP">WP</a> status.</p> <p><b>Discussion:</b></p> @@ -24053,7 +24773,7 @@ dtor? Should the dtor catch and swallow it or should it propagate it to the caller? The text doesn't seem to provide any guidance in this regard other than the general restriction on throwing (but not propagating) exceptions from destructors of library classes in -17.4.4.8 [res.on.exception.handling]. +17.4.4.9 [res.on.exception.handling]. </p> <p> @@ -24168,7 +24888,7 @@ And to make the following edits in 27.8.1.2 [filebuf.cons]. <code>close()</code>. <ins>If an exception occurs during the destruction of the object, including the call to <code>close()</code>, the exception is caught but not rethrown (see -17.4.4.8 [res.on.exception.handling]).</ins> +17.4.4.9 [res.on.exception.handling]).</ins> </p> </blockquote> @@ -24379,7 +25099,7 @@ Change 28.8.2 [re.regex.construct]: <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.5.1 [allocator.members] <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.7.5.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> @@ -24387,7 +25107,7 @@ Change 28.8.2 [re.regex.construct]: <p><b>Discussion:</b></p> <p> -20.6.5.1 [allocator.members] says: +20.7.5.1 [allocator.members] says: </p> <blockquote> <pre>pointer address(reference <i>x</i>) const;</pre> @@ -24399,7 +25119,7 @@ Change 28.8.2 [re.regex.construct]: </blockquote> <p> -20.6.5.1 [allocator.members] defines <tt>CopyConstructible</tt> which currently not +20.7.5.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 @@ -24430,7 +25150,7 @@ is expected to make use of <tt>allocator::address</tt> mandatory for containers. <p><b>Proposed resolution:</b></p> <p> -Change 20.6.5.1 [allocator.members]: +Change 20.7.5.1 [allocator.members]: </p> <blockquote> @@ -24471,6 +25191,102 @@ issue to Ready status to be voted into the WP at Kona. <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#WP">WP</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The standard states at 23.2.2.3 [deque.modifiers]/4: +</p> +<blockquote><pre>deque erase(...) +</pre> + <p> +<i>Effects:</i> ... An erase at either end of the deque invalidates only +the iterators and the references to the erased elements. +</p> +</blockquote> +<p> +This does not state that iterators to end will be invalidated. +It needs to be amended in such a way as to account for end invalidation. +</p> +<p> +Something like: +</p> +<blockquote><p> +Any time the last element is erased, iterators to end are invalidated. +</p></blockquote> + +<p> +This would handle situations like: +</p> +<blockquote><pre>erase(begin(), end()) +erase(end() - 1) +pop_back() +resize(n, ...) where n < size() +pop_front() with size() == 1 + +</pre></blockquote> + +<p><i>[ +Post Kona, Steve LoBasso notes: +]</i></p> + + +<blockquote> +My only issue with the proposed resolution is that it might not be clear +that <tt>pop_front()</tt> [where <tt>size() == 1</tt>] can invalidate past-the-end +iterators. +</blockquote> + + + +<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> + + + +<p><i>[ +Kona (2007): Proposed wording added and moved to Review. +]</i></p> + + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Note that there is existing code that relies on iterators not being +invalidated, but there are also existing implementations that do +invalidate iterators. Thus, such code is not portable in any case. There +is a pop_front() note, which should possibly be a separate issue. Mike +Spertus to evaluate and, if need be, file an issue. +</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#WP">WP</a> <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-17</p> @@ -24586,45 +25402,6 @@ A local variable <tt><i>punct</i></tt> is initialized via <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>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> @@ -24985,12 +25762,12 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a <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> +<p><b>Section:</b> 20.6 [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> +<p>Section 20.6 [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 @@ -25009,7 +25786,7 @@ 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 +<p>To 20.6 [function.objects], Function objects, paragraph 2, add to the header <functional> synopsis:</p> <blockquote> <pre>template <class T> struct bit_and; @@ -25284,8 +26061,509 @@ four characters long, usually three letters and a space. <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#WP">WP</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The current <tt>Swappable</tt> is: +</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> +The Swappable requirement is met by satisfying one or more of the following conditions: +</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> + +<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. +</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> + +<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>. +</p> + + + +<p><b>Proposed resolution:</b></p> + +<p> +Change 20.1.1 [utility.arg.requirements]: +</p> + +<blockquote> + +<p> +-1- The template definitions in the C++ Standard Library refer to various +named requirements whose details are set out in tables 31-38. In these +tables, <tt>T</tt> 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> + +<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="673"></a>673. <tt>unique_ptr</tt> update</h3> +<p><b>Section:</b> 20.7.11 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</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#unique.ptr">issues</a> in [unique.ptr].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</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">example implmenation</a> +for all of these changes. +</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> + +<p> +This resolution also supports instantiations such as <tt>unique_ptr<void, free_deleter></tt> +which could be very useful to the client. +</p> + +</li> + +<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 (example 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> + + +<p><i>[ +Post Kona: Howard adds example user code related to the first bullet: +]</i></p> + + +<blockquote> +<pre>void legacy_code(void*, std::size_t); + +void foo(std::size_t N) +{ + std::unique_ptr<void, void(*)(void*)> ptr(std::malloc(N), std::free); + legacy_code(ptr.get(), N); +} // unique_ptr used for exception safety purposes +</pre> +</blockquote> + +<p> +I.e. <tt>unique_ptr<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><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.7.11.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> +Change 20.7.11.2.4 [unique.ptr.single.observers]: +</p> + +<blockquote><pre><del>T&</del> <ins>typename add_lvalue_reference<T>::type</ins> operator*() const; +</pre></blockquote> + +</li> + +<li> +<p> +Change 20.7.11.2 [unique.ptr.single]: +</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>); +}; +</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> shall be <tt>CopyConstructible</tt> +and <tt>CopyAssignable</tt>. +</ins> +</p> + +<p> +Change 20.7.11.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> +<del>must</del> <ins>shall</ins> be well formed and not throw an exception. If <tt>D</tt> is a +reference type, then <tt>E</tt> <del>must</del> <ins>shall</ins> be the same type as <tt>D</tt> +(diagnostic required). <del><tt>U*</tt></del> <ins><tt>unique_ptr<U,E>::pointer</tt></ins> +<del>must</del> <ins>shall</ins> 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> + +<p> +Change 20.7.11.2.3 [unique.ptr.single.asgn]: +</p> + +<blockquote> +<p> +-8- <i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue +<tt>D</tt> <del>must</del> <ins>shall</ins> not throw an exception. <del><tt>U*</tt></del> +<ins><tt>unique_ptr<U,E>::pointer</tt></ins> <del>must</del> <ins>shall</ins> be implicitly +convertible to <del><tt>T*</tt></del> <ins>pointer</ins>. +</p> +</blockquote> + +<p> +Change 20.7.11.2.4 [unique.ptr.single.observers]: +</p> + +<blockquote> +<pre><del>T*</del> <ins>pointer</ins> operator->() const;</pre> +... +<pre><del>T*</del> <ins>pointer</ins> get() const;</pre> +</blockquote> + +<p> +Change 20.7.11.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> +Change 20.7.11.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.7.11.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> + +<p> +Change 20.7.11.3.3 [unique.ptr.runtime.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> (diagnostic +required). [<i>Note:</i> One implementation technique is to create a private +templated overload. <i>-- end note</i>] +</p> +</blockquote> + +</li> + +<li> + +<p> +Change 20.7.11.2.1 [unique.ptr.single.ctor]: +</p> + +<blockquote> +<pre>unique_ptr();</pre> +<blockquote> +<p> +<i>Requires:</i> <tt>D</tt> <del>must</del> <ins>shall</ins> be default constructible, and that +construction <del>must</del> <ins>shall</ins> not throw an exception. <tt>D</tt> <del>must</del> <ins>shall</ins> 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> +<i>Requires:</i> The expression <tt>D()(p)</tt> <del>must</del> <ins>shall</ins> be well formed. +The default constructor of <tt>D</tt> <del>must</del> <ins>shall</ins> not throw an exception. +<tt>D</tt> <del>must</del> <ins>shall</ins> not be a reference type <ins>or pointer type (diagnostic +required)</ins>. +</p> +</blockquote> +</blockquote> + +</li> + +</ul> + + + + + + +<hr> <h3><a name="674"></a>674. <tt>shared_ptr</tt> interface changes for consistency with N1856</h3> -<p><b>Section:</b> 20.6.12.2 [util.smartptr.shared] <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.7.12.2 [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> 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> @@ -25301,7 +26579,7 @@ and to interoperate with <tt>unique_ptr</tt> as it does with <tt>auto_ptr</tt>. <p><b>Proposed resolution:</b></p> <p> -Change 20.6.12.2 [util.smartptr.shared] as follows: +Change 20.7.12.2 [util.smartptr.shared] as follows: </p> <blockquote> @@ -25315,7 +26593,7 @@ template<class Y, class D> shared_ptr& operator=(unique_ptr<Y,D> </blockquote> <p> -Change 20.6.12.2.1 [util.smartptr.shared.const] as follows: +Change 20.7.12.2.1 [util.smartptr.shared.const] as follows: </p> <blockquote> @@ -25323,7 +26601,7 @@ Change 20.6.12.2.1 [util.smartptr.shared.const] as follows: </blockquote> <p> -Add to 20.6.12.2.1 [util.smartptr.shared.const]: +Add to 20.7.12.2.1 [util.smartptr.shared.const]: </p> <blockquote> @@ -25344,7 +26622,7 @@ Add to 20.6.12.2.1 [util.smartptr.shared.const]: </blockquote> <p> -Change 20.6.12.2.3 [util.smartptr.shared.assign] as follows: +Change 20.7.12.2.3 [util.smartptr.shared.assign] as follows: </p> <blockquote> @@ -25352,7 +26630,7 @@ Change 20.6.12.2.3 [util.smartptr.shared.assign] as follows: </blockquote> <p> -Add to 20.6.12.2.3 [util.smartptr.shared.assign]: +Add to 20.7.12.2.3 [util.smartptr.shared.assign]: </p> <blockquote> @@ -25372,7 +26650,7 @@ Add to 20.6.12.2.3 [util.smartptr.shared.assign]: <p><i>[ -Kona (2007): We may need to open an issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#743">743</a>) to deal with the question of +Kona (2007): We may need to open an issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>) to deal with the question of whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>. ]</i></p> @@ -25850,8 +27128,117 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a <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#WP">WP</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#WP">WP</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(y.current - x.current)</ins>; +</pre> +</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(y.current - x.current)</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(x.base() - y.base())</ins>; +</pre> +</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(x.base() - y.base())</ins>; +</pre> +<blockquote> +<p> +<i>Returns:</i> <tt>x.base() - y.base()</tt>. +</p> +</blockquote> +</blockquote> + +<p><i>[ +Pre Bellevue: This issue needs to wait until the <tt>auto -> return</tt> language feature +goes in. +]</i></p> + + + + + + + +<hr> <h3><a name="687"></a>687. shared_ptr conversion constructor not constrained</h3> -<p><b>Section:</b> 20.6.12.2.1 [util.smartptr.shared.const], 20.6.12.3.1 [util.smartptr.weak.const] <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.7.12.2.1 [util.smartptr.shared.const], 20.7.12.3.1 [util.smartptr.weak.const] <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> 2007-05-10</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> @@ -25880,7 +27267,7 @@ overload resolution when the pointer types are compatible. <p><b>Proposed resolution:</b></p> <p> -In 20.6.12.2.1 [util.smartptr.shared.const], change: +In 20.7.12.2.1 [util.smartptr.shared.const], change: </p> <blockquote><p> @@ -25891,7 +27278,7 @@ to <tt>T*</tt>. </p></blockquote> <p> -In 20.6.12.3.1 [util.smartptr.weak.const], change: +In 20.7.12.3.1 [util.smartptr.weak.const], change: </p> <blockquote> @@ -25917,7 +27304,7 @@ overload resolution unless</ins> <tt>Y*</tt> <del>shall be</del> <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#WP">WP</a> +<p><b>Section:</b> 20.6.5.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#refwrap.const">issues</a> in [refwrap.const].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> @@ -26297,12 +27684,14 @@ Add the following to the specification of <tt>map::at()</tt>, 23.3.1.2 [map.acce <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#WP">WP</a> +<p><b>Section:</b> 20.5.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2007-07-08</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.trans.other">active issues</a> in [meta.trans.other].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</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]. +The current working draft has a type-trait <tt>decay</tt> in 20.5.7 [meta.trans.other]. </p> <p> @@ -26316,7 +27705,7 @@ cv-qualification, as pass-by-value does. <p><b>Proposed resolution:</b></p> <p> -In 20.4.7 [meta.trans.other] change the last sentence: +In 20.5.7 [meta.trans.other] change the last sentence: </p> <blockquote><p> @@ -26324,7 +27713,7 @@ Otherwise the member typedef <tt>type</tt> equals <tt><ins>remove_cv<</ins>U </p></blockquote> <p> -In 20.3.1.3 [tuple.creation]/1 change: +In 20.4.1.3 [tuple.creation]/1 change: </p> <blockquote><p> @@ -26354,7 +27743,7 @@ is <tt>X&</tt> if <tt>Ui</tt> equals <p><b>Discussion:</b></p> <p> The current draft has <tt>make_pair()</tt> in 20.2.3 [pairs]/16 -and <tt>make_tuple()</tt> in 20.3.1.3 [tuple.creation]. +and <tt>make_tuple()</tt> in 20.4.1.3 [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 @@ -26395,6 +27784,146 @@ Then change the 20.2.3 [pairs]/17 to: <hr> +<h3><a name="710"></a>710. Missing postconditions</h3> +<p><b>Section:</b> 20.7.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +A discussion on +<a href="http://groups.google.com/group/comp.std.c++/browse_frm/thread/8e89dceb35cd7971">comp.std.c++</a> +has identified a contradiction in the <tt>shared_ptr</tt> specification. +The <tt>shared_ptr</tt> move constructor and the cast functions are +missing postconditions for the <tt>get()</tt> accessor. +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +Move to "ready", adopting the first (Peter's) proposed resolution. +</p> +<p> +Note to the project editor: there is an editorial issue here. The +wording for the postconditions of the casts is slightly awkward, and the +editor should consider rewording "If w is the return value...", e. g. as +"For a return value w...". +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Add to 20.7.12.2.1 [util.smartptr.shared.const]: +</p> + +<blockquote> +<pre>shared_ptr(shared_ptr&& r); +template<class Y> shared_ptr(shared_ptr<Y>&& r); +</pre> +<blockquote> +<p> +<i>Postconditions:</i> <tt>*this</tt> shall contain the old value of <tt>r</tt>. <tt>r</tt> +shall be empty. <ins><tt>r.get() == 0</tt>.</ins> +</p> +</blockquote> +</blockquote> + +<p> +Add to 20.7.12.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> +<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>template<class T, class U> shared_ptr<T> dynamic_pointer_cast(shared_ptr<U> const& r); +</pre> +<blockquote> +<p> +<ins><i>Postconditions:</i> If <tt>w</tt> is the return value, <tt>w.get() == dynamic_cast<T*>(r.get())</tt>.</ins> +</p> +</blockquote> +</blockquote> + +<blockquote> +<pre>template<class T, class U> shared_ptr<T> const_pointer_cast(shared_ptr<U> const& r); +</pre> +<blockquote> +<p> +<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> +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.7.12.2.10 [util.smartptr.shared.cast]: +</p> + +<blockquote> +<p> +-2- <i>Returns:</i> <del>If <tt>r</tt> is empty, an <tt>empty +shared_ptr<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> +-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> + +<blockquote> +<p> +-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> + +<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="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> @@ -26438,4 +27967,1812 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a +<hr> +<h3><a name="715"></a>715. <tt>minmax_element</tt> complexity is too lax</h3> +<p><b>Section:</b> 25.3.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The complexity for <tt>minmax_element</tt> (25.3.7 [alg.min.max] par 16) says "At most <tt>max(2 * +(last - first ) - 2, 0)</tt> applications of the corresponding comparisons", +i.e. the worst case complexity is no better than calling <tt>min_element</tt> and +<tt>max_element</tt> separately. This is gratuitously inefficient. There is a +well known technique that does better: see section 9.1 of CLRS +(Introduction to Algorithms, by Cormen, Leiserson, Rivest, and Stein). +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 25.3.7 [alg.min.max] to: +</p> + +<blockquote> +<pre>template<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> +<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 in <tt>[first, +last)</tt> such that no iterator in the range refers to a smaller element,</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 +in <tt>[first, last)</tt> such that no iterator in the range refers to a larger element</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> + + + + + + +<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#WP">WP</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#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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +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>float nanf(const char *tagp); +long double nanl(const char *tagp); +</pre></blockquote> + +<p> +(Note: These functions cannot be overloaded and they are also not +listed anywhere else) +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 26.7 [c.math], table 108, section "Functions", add <tt>nanf</tt> and <tt>nanl</tt> +just after the existing entry <tt>nan</tt>. +</p> + + + + + +<hr> +<h3><a name="740"></a>740. Please remove <tt>*_ptr<T[N]></tt></h3> +<p><b>Section:</b> 20.7.11.4 [unique.ptr.compiletime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +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> + +<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> +If bounds checking is desired, consider a <tt>checked_*_ptr</tt> instead (e.g., +<tt>checked_shared_ptr</tt>). And make the interfaces otherwise identical so that +user code could easily <tt>#define/typedef</tt> between prepending <tt>checked_</tt> on +debug builds and not doing so on release builds (for example). +</p> + +<p> +Note that some may object that <tt>checked_*_ptr</tt> may seem to make the smart +pointer more like <tt>vector</tt>, and we don't want two ways to spell <tt>vector</tt>. I +don't agree, but if that were true that would be another reason to +remove <tt>*_ptr<T[N]></tt> which equally makes the smart pointer more like +<tt>std::array.</tt> :-) +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p>Suggestion that fixed-size array instantiations are going to fail at +compile time anyway (if we remove specialization) due to pointer decay, +at least that appears to be result from available compilers. +</p> +<p> +So concerns about about requiring static_assert seem unfounded. +</p> +<p>After a little more experimentation with compiler, it appears that +fixed size arrays would only work at all if we supply these explicit +specialization. So removing them appears less breaking than originally +thought. +</p> +<p> +straw poll unanimous move to Ready. +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change the synopsis under 20.7.11 [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.7.11.1.3 [unique.ptr.dltr.dflt2] <b><tt>default_delete<T[N]></tt></b>. +</p> + +<p> +Remove the entire section 20.7.11.4 [unique.ptr.compiletime] <b><tt>unique_ptr</tt> for array objects with a compile time length</b> +and its subsections: 20.7.11.4.1 [unique.ptr.compiletime.dtor], 20.7.11.4.2 [unique.ptr.compiletime.observers], +20.7.11.4.3 [unique.ptr.compiletime.modifiers]. +</p> + + + + + + +<hr> +<h3><a name="743"></a>743. rvalue <tt>swap</tt> for <tt>shared_ptr</tt></h3> +<p><b>Section:</b> 20.7.12.2.9 [util.smartptr.shared.spec] <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-10-10</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> +When the LWG looked at <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a> in Kona the following note was made: +</p> + +<blockquote><p> +We may need to open an issue to deal with the question of +whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>. +</p></blockquote> + +<p> +This issue was opened in response to that note. +</p> + +<p> +I believe allowing rvalue <tt>shared_ptr</tt>s to <tt>swap</tt> is both +appropriate, and consistent with how other library components are currently specified. +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +Concern that the three signatures for swap is needlessly complicated, +but this issue merely brings shared_ptr into equal complexity with the +rest of the library. Will open a new issue for concern about triplicate +signatures. +</p> +<p> +Adopt issue as written. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change the synopsis in 20.7.12.2 [util.smartptr.shared]: +</p> + +<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> +Change 20.7.12.2.4 [util.smartptr.shared.mod]: +</p> + +<blockquote><pre>void swap(shared_ptr&<ins>&</ins> r); +</pre></blockquote> + +<p> +Change 20.7.12.2.9 [util.smartptr.shared.spec]: +</p> + +<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="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#WP">WP</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +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><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +Agree the issue is real. +</p> +<p> +Intent is lifetime is similar to a shared_ptr (and we might even want to +consider explicitly saying that it is a shared_ptr< unspecified type >). +</p> +<p> +We expect that most implementations will use shared_ptr, and the +standard should be clear that the exception_ptr type is intended to be +something whose semantics are smart-pointer-like so that the user does +not need to worry about lifetime management. We still need someone to +draught those words - suggest emailing Peter Dimov. +</p> +<p> +Move to Open. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 18.7.5 [propagation]/7: +</p> + +<blockquote> +-7- Returns: An <tt>exception_ptr</tt> object that refers to the currently +handled exception or a copy of the currently handled exception, or a +null <tt>exception_ptr</tt> object if no exception is being handled. +<ins>The referenced object remains valid at least as long as there is an +<tt>exception_ptr</tt> that refers to it.</ins> +If the function needs to allocate memory and the attempt +fails, it returns an <tt>exception_ptr</tt> object that refers to an instance of +<tt>bad_alloc</tt>. It is unspecified whether the return values of two successive +calls to <tt>current_exception</tt> refer to the same exception object. [<i>Note:</i> +that is, it is unspecified whether <tt>current_exception</tt> creates a new copy +each time it is called. <i>--end note</i>] +</blockquote> + + + + + +<hr> +<h3><a name="746"></a>746. current_exception may fail with bad_alloc</h3> +<p><b>Section:</b> 18.7.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +I understand that the attempt to copy an exception may run out of memory, +but I believe this is the only part of the standard that mandates failure +with specifically <tt>bad_alloc</tt>, as opposed to allowing an +implementation-defined type derived from <tt>bad_alloc</tt>. For instance, the Core +language for a failed new expression is: +</p> +<blockquote> +<p> +Any other allocation function that fails to allocate storage shall indicate +failure only by throwing an exception of a type that would match a handler +(15.3) of type <tt>std::bad_alloc</tt> (18.5.2.1). +</p> +</blockquote> +<p> +I think we should allow similar freedom here (or add a blanket +compatible-exception freedom paragraph in 17) +</p> +<p> +I prefer the clause 17 approach myself, and maybe clean up any outstanding +wording that could also rely on it. +</p> +<p> +Although filed against a specific case, this issue is a problem throughout +the library. +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +Is issue bigger than library? +</p> +<p> +No - Core are already very clear about their wording, which is inspiration for the issue. +</p> +<p> +While not sold on the original 18.7.5 use case, the generalised 17.4.4.8 wording is the real issue. +</p> +<p> +Accept the broad view and move to ready +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Add the following exemption clause to 17.4.4.9 [res.on.exception.handling]: +</p> + +<blockquote> +A function may throw a type not listed in its <i>Throws</i> clause so long as it is +derived from a class named in the <i>Throws</i> clause, and would be caught by an +exception handler for the base type. +</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.5.4.3 [meta.unary.prop] <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> 2007-10-10</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Unfortunately a class can have multiple copy constructors, and I believe to +be useful this trait should only return true is ALL copy constructors are +no-throw. +</p> +<p> +For instance: +</p> +<blockquote> +<pre>struct awkward { + awkward( const awkward & ) throw() {} + awkward( awkward & ) { throw "oops"; } }; +</pre> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 20.5.4.3 [meta.unary.prop]: +</p> + +<blockquote> +<pre>has_trivial_copy_constructor</pre> +<blockquote> +<tt>T</tt> is a trivial type (3.9) or a reference type or a class type <del>with a trivial copy constructor</del> +<ins>where all copy constructors are trivial</ins> (12.8). +</blockquote> +</blockquote> + +<blockquote> +<pre>has_trivial_assign</pre> +<blockquote> +<tt>T</tt> is neither <tt>const</tt> nor a reference type, and <tt>T</tt> is a trivial type (3.9) +or a class type <del>with a trivial copy assignment operator</del> <ins>where all copy assignment operators are trivial</ins> (12.8). +</blockquote> +</blockquote> + +<blockquote> +<pre>has_nothrow_copy_constructor</pre> +<blockquote> +<tt>has_trivial_copy_constructor<T>::value</tt> is <tt>true</tt> or <tt>T</tt> is a class type <del>with +a</del> <ins>where all</ins> copy constructor<ins>s</ins> <del>that is</del> <ins>are</ins> +known not to throw any exceptions or <tt>T</tt> is an +array of such a class type +</blockquote> +</blockquote> + +<blockquote> +<pre>has_nothrow_assign</pre> +<blockquote> +<tt>T</tt> is neither <tt>const</tt> nor a reference type, and +<tt>has_trivial_assign<T>::value</tt> is <tt>true</tt> or <tt>T</tt> is a class type <del>with a</del> +<ins>where all</ins> copy +assignment operator<ins>s</ins> tak<ins>e</ins><del>ing</del> an lvalue of type <tt>T</tt> that is known not to +throw any exceptions or <tt>T</tt> is an array of such a class type. +</blockquote> +</blockquote> + + + + + + +<hr> +<h3><a name="755"></a>755. <tt>std::vector</tt> and <tt>std:string</tt> lack explicit shrink-to-fit operations</h3> +<p><b>Section:</b> 23.2.6.2 [vector.capacity], 21.3.4 [string.capacity] <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-10-31</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</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 <tt>std::vector</tt> can be shrunk-to-fit via the swap idiom: +</p> + +<blockquote><pre>vector<int> v; +... +v.swap(vector<int>(v)); // shrink to fit +</pre> +<blockquote><p> +or: +</p></blockquote> +<pre>vector<int>(v).swap(v); // shrink to fit +</pre> +<blockquote><p> +or: +</p></blockquote> +<pre>swap(v, vector<int>(v)); // shrink to fit +</pre> +</blockquote> + +<p> +A non-binding request for shrink-to-fit can be made to a <tt>std::string</tt> via: +</p> + +<blockquote><pre>string s; +... +s.reserve(0); +</pre></blockquote> + +<p> +Neither of these is at all obvious to beginners, and even some +experienced C++ programmers are not aware that shrink-to-fit is +trivially available. +</p> +<p> +Lack of explicit functions to perform these commonly requested +operations makes vector and string less usable for non-experts. Because +the idioms are somewhat obscure, code readability is impaired. It is +also unfortunate that two similar vector-like containers use different +syntax for the same operation. +</p> +<p> +The proposed resolution addresses these concerns. The proposed function +takes no arguments to keep the solution simple and focused. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +To Class template basic_string 21.3 [basic.string] synopsis, +Class template vector 23.2.6 [vector] synopsis, and Class +vector<bool> 23.2.7 [vector.bool] synopsis, add: +</p> + +<blockquote><pre> +void shrink_to_fit(); +</pre></blockquote> + +<p> +To basic_string capacity 21.3.4 [string.capacity] and vector +capacity 23.2.6.2 [vector.capacity], add: +</p> + +<blockquote> +<pre>void shrink_to_fit(); +</pre> +<blockquote> +<i>Remarks:</i> <tt>shrink_to_fit</tt> is a non-binding request to reduce +<tt>capacity()</tt> to <tt>size()</tt>. [<i>Note:</i> The request is non-binding to +allow latitude for implementation-specific optimizations. +<i>-- end note</i>] +</blockquote> +</blockquote> + +<p><i>[ +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#850">850</a> has been added to deal with this issue with respect to <tt>deque</tt>. +]</i></p> + + + + + + +<hr> +<h3><a name="759"></a>759. A reference is not an object</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#WP">WP</a> + <b>Submitter:</b> Jens Maurer <b>Date:</b> 2007-11-06</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +23.1 [container.requirements] says: +</p> + +<blockquote> +-12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No +diagnostic required. +</blockquote> + +<p> +A reference is not an object, but this sentence appears to claim so. +</p> + +<p> +What is probably meant here: +</p> +<blockquote> +An object bound to an rvalue +reference parameter of a member function of a container shall not be +an element of that container; no diagnostic required. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change 23.1 [container.requirements]: +</p> + +<blockquote> +-12- <del>Objects passed to member functions of a container as rvalue references shall not be elements</del> +<ins>An object bound to an rvalue +reference parameter of a member function of a container shall not be +an element</ins> +of that container<del>.</del><ins>;</ins> <del>N</del><ins>n</ins>o +diagnostic required. +</blockquote> + + + + + + +<hr> +<h3><a name="761"></a>761. <tt>unordered_map</tt> needs an <tt>at()</tt> member function</h3> +<p><b>Section:</b> 23.4.1.2 [unord.map.elem] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-11-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> +The new member function <tt>at()</tt> was recently added to <tt>std::map()</tt>. It acts +like <tt>operator[]()</tt>, except it throws an exception when the input key is +not found. It is useful when the <tt>map</tt> is <tt>const</tt>, the <tt>value_type</tt> of the +key doesn't have a default constructor, it is an error if the key is +not found, or the user wants to avoid accidentally adding an element to +the map. For exactly these same reasons, <tt>at()</tt> would be equally useful +in <tt>std::unordered_map</tt>. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add the following functions to the definition of <tt>unordered_map</tt> under "lookup" (23.4.1 [unord.map]): +</p> + +<blockquote><pre>mapped_type& at(const key_type& k); +const mapped_type &at(const key_type &k) const; +</pre></blockquote> + +<p> +Add the following definitions to 23.4.1.2 [unord.map.elem]: +</p> + +<blockquote> +<pre>mapped_type& at(const key_type& k); +const mapped_type &at(const key_type &k) const; +</pre> +<blockquote> +<p> +<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>. +</p> +<p> +<i>Throws:</i> An exception object of type <tt>out_of_range</tt> if no such element +is present. +</p> +</blockquote> +</blockquote> + +<p><i>[ +Bellevue: Editorial note: the "(unique)" differs from map. +]</i></p> + + + + + + + +<hr> +<h3><a name="766"></a>766. Inconsistent exception guarantees between ordered and unordered associative containers</h3> +<p><b>Section:</b> 23.1 [container.requirements], 23.1.5.1 [unord.req.except] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Ion Gaztańaga <b>Date:</b> 2007-12-22</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +23.1 [container.requirements]p10 states: +</p> + +<blockquote> +<p> +Unless otherwise specified (see 23.2.2.3 and 23.2.5.4) all container types defined in this clause meet the following +additional requirements: +</p> +<ul> + +<li>[...]</li> + +<li>no <tt>erase()</tt>, <tt>pop_back()</tt> or <tt>pop_front()</tt> function throws an exception.</li> + +</ul> +</blockquote> + +<p> +23.2.2.3 [deque.modifiers] and 23.2.6.4 [vector.modifiers] offer +additional guarantees for <tt>deque</tt>/<tt>vector insert()</tt> and +<tt>erase()</tt> members. However, 23.1 [container.requirements]p10 +does not mention 23.1.5.1 [unord.req.except] that specifies exception +safety guarantees +for unordered containers. In addition, 23.1.5.1 [unord.req.except]p1 +offers the following guaratee for +<tt>erase()</tt>: +</p> + +<blockquote> +No <tt>erase()</tt> function throws an exception unless that exception +is thrown by the container's Hash or Pred object (if any). +</blockquote> + +<p> +Summary: +</p> + +<p> +According to 23.1 [container.requirements]p10 no +<tt>erase()</tt> function should throw an exception unless otherwise +specified. Although does not explicitly mention 23.1.5.1 [unord.req.except], this section offers additional guarantees +for unordered containers, allowing <tt>erase()</tt> to throw if +predicate or hash function throws. +</p> + +<p> +In contrast, associative containers have no exception safety guarantees +section so no <tt>erase()</tt> function should throw, <em>including +<tt>erase(k)</tt></em> that needs to use the predicate function to +perform its work. This means that the predicate of an associative +container is not allowed to throw. +</p> + +<p> +So: +</p> + +<ol> +<li> +<tt>erase(k)</tt> for associative containers is not allowed to throw. On +the other hand, <tt>erase(k)</tt> for unordered associative containers +is allowed to throw. +</li> +<li> +<tt>erase(q)</tt> for associative containers is not allowed to throw. On +the other hand, <tt>erase(q)</tt> for unordered associative containers +is allowed to throw if it uses the hash or predicate. +</li> +<li> +To fulfill 1), predicates of associative containers are not allowed to throw. +Predicates of unordered associative containers are allowed to throw. +</li> +<li> +2) breaks a widely used programming pattern (flyweight pattern) for +unordered containers, where objects are registered in a global map in +their constructors and unregistered in their destructors. If <tt>erase(q)</tt> is +allowed to throw, the destructor of the object would need to rethrow the +exception or swallow it, leaving the object registered. +</li> +</ol> + + +<p><b>Proposed resolution:</b></p> +<p> +Create a new sub-section of 23.1.4 [associative.reqmts] (perhaps [associative.req.except]) titled "Exception +safety guarantees". +</p> + +<blockquote> +<p> +1 For associative containers, no <tt>clear()</tt> function throws an exception. +<tt>erase(k)</tt> does not throw an exception unless that exception is thrown by +the container's Pred object (if any). +</p> + +<p> +2 For associative containers, if an exception is thrown by any operation +from within an <tt>insert()</tt> function inserting a single element, the +<tt>insert()</tt> function has no effect. +</p> + +<p> +3 For associative containers, no <tt>swap</tt> function throws an exception +unless that exception is thrown by the copy constructor or copy +assignment operator of the container's Pred object (if any). +</p> +</blockquote> + +<p> +Change 23.1.5.1 [unord.req.except]p1: +</p> + +<blockquote> +For unordered associative containers, no <tt>clear()</tt> function +throws an exception. <del>No</del> <tt>erase(<ins>k</ins>)</tt> +<del>function</del> <ins>does not</ins> throw<del>s</del> an exception +unless that exception is thrown by the container's Hash or Pred object +(if any). +</blockquote> + +<p> +Change 23.1 [container.requirements]p10 to add references to new sections: +</p> + +<blockquote> +Unless otherwise specified (see [deque.modifiers]<ins>,</ins> +<del>and</del> [vector.modifiers]<ins>, [associative.req.except], +[unord.req.except]</ins>) all container types defined in this clause meet +the following additional requirements: +</blockquote> + +<p> +Change 23.1 [container.requirements]p10 referring to <tt>swap</tt>: +</p> + +<blockquote> +<ul> +<li> +no <tt>swap()</tt> function throws an exception<del> unless that exception is thrown +by the copy constructor or assignment operator of the container's +Compare object (if any; see [associative.reqmts])</del>. +</li> +</ul> +</blockquote> + + + + + + +<hr> +<h3><a name="768"></a>768. Typos in [atomics]?</h3> +<p><b>Section:</b> 29.3.3 [atomics.types.generic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Alberto Ganesh Barbati <b>Date:</b> 2007-12-28</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 publicly available draft, paper +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">N2641</a>, +in section 29.3.3 [atomics.types.generic], the following specialization of the template +<tt>atomic<></tt> is provided for pointers: +</p> + +<blockquote><pre>template <class T> struct atomic<T*> : atomic_address { + T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; + T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; + + atomic() = default; + constexpr explicit atomic(T); + atomic(const atomic&) = delete; + atomic& operator=(const atomic&) = delete; + + T* operator=(T*) volatile; + T* operator++(int) volatile; + T* operator--(int) volatile; + T* operator++() volatile; + T* operator--() volatile; + T* operator+=(ptrdiff_t) volatile; + T* operator-=(ptrdiff_t) volatile; +}; +</pre></blockquote> + +<p> +First of all, there is a typo in the non-default constructor which +should take a <tt>T*</tt> rather than a <tt>T</tt>. +</p> + +<p> +As you can see, the specialization redefine and therefore hide a few +methods from the base class <tt>atomic_address</tt>, namely <tt>fetch_add</tt>, <tt>fetch_sub</tt>, +<tt>operator=</tt>, <tt>operator+=</tt> and <tt>operator-=</tt>. That's good, but... what happened +to the other methods, in particular these ones: +</p> + +<blockquote><pre>void store(T*, memory_order = memory_order_seq_cst) volatile; +T* load( memory_order = memory_order_seq_cst ) volatile; +T* swap( T*, memory_order = memory_order_seq_cst ) volatile; +bool compare_swap( T*&, T*, memory_order, memory_order ) volatile; +bool compare_swap( T*&, T*, memory_order = memory_order_seq_cst ) volatile; +</pre></blockquote> + +<p> +By reading paper +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html">N2427 "C++ Atomic Types and Operations"</a>, +I see that the +definition of the specialization <tt>atomic<T*></tt> matches the one in the +draft, but in the example implementation the methods <tt>load()</tt>, <tt>swap()</tt> +and <tt>compare_swap()</tt> are indeed present. +</p> + +<p> +Strangely, the example implementation does not redefine the method +<tt>store()</tt>. It's true that a <tt>T*</tt> is always convertible to <tt>void*</tt>, but not +hiding the <tt>void*</tt> signature from the base class makes the class +error-prone to say the least: it lets you assign pointers of any type to +a <tt>T*</tt>, without any hint from the compiler. +</p> + +<p> +Is there a true intent to remove them from the specialization or are +they just missing from the definition because of a mistake? +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +The proposed revisions are accepted. +</p> +<p> +Further discussion: why is the ctor labeled "constexpr"? Lawrence said +this permits the object to be statically initialized, and that's +important because otherwise there would be a race condition on +initialization. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change the synopsis in 29.3.3 [atomics.types.generic]: +</p> + +<blockquote><pre>template <class T> struct atomic<T*> : atomic_address { + <ins>void store(T*, memory_order = memory_order_seq_cst) volatile;</ins> + <ins>T* load( memory_order = memory_order_seq_cst ) volatile;</ins> + <ins>T* swap( T*, memory_order = memory_order_seq_cst ) volatile;</ins> + <ins>bool compare_swap( T*&, T*, memory_order, memory_order ) volatile;</ins> + <ins>bool compare_swap( T*&, T*, memory_order = memory_order_seq_cst ) volatile;</ins> + + T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; + T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile; + + atomic() = default; + constexpr explicit atomic(T<ins>*</ins>); + atomic(const atomic&) = delete; + atomic& operator=(const atomic&) = delete; + + T* operator=(T*) volatile; + T* operator++(int) volatile; + T* operator--(int) volatile; + T* operator++() volatile; + T* operator--() volatile; + T* operator+=(ptrdiff_t) volatile; + T* operator-=(ptrdiff_t) volatile; +}; +</pre></blockquote> + + + + + + +<hr> +<h3><a name="770"></a>770. std::function should use rvalue swap</h3> +<p><b>Section:</b> 20.6.15 [func.wrap] <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> 2008-01-10</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +It is expected that typical implementations of <tt>std::function</tt> will +use dynamic memory allocations at least under given conditions, +so it seems appropriate to change the current lvalue swappabilty of +this class to rvalue swappability. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 20.6 [function.objects], header <tt><functional></tt> synopsis, just below of +</p> + +<blockquote><pre>template<class R, class... ArgTypes> + void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&); +<ins>template<class R, class... ArgTypes> + void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&); +template<class R, class... ArgTypes> + void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&&);</ins> +</pre></blockquote> + +<p> +In 20.6.15.2 [func.wrap.func] class <tt>function</tt> definition, change +</p> + +<blockquote><pre>void swap(function&<ins>&</ins>); +</pre></blockquote> + +<p> +In 20.6.15.2 [func.wrap.func], just below of +</p> + +<blockquote><pre>template <class R, class... ArgTypes> + void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&); +<ins>template <class R, class... ArgTypes> + void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&); +template <class R, class... ArgTypes> + void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&&);</ins> +</pre></blockquote> + +<p> +In 20.6.15.2.2 [func.wrap.func.mod] change +</p> + +<blockquote><pre>void swap(function&<ins>&</ins> other); +</pre></blockquote> + +<p> +In 20.6.15.2.7 [func.wrap.func.alg] add the two overloads +</p> + +<blockquote><pre><ins>template<class R, class... ArgTypes> + void swap(function<R(ArgTypes...)>&& f1, function<R(ArgTypes...)>& f2); +template<class R, class... ArgTypes> + void swap(function<R(ArgTypes...)>& f1, function<R(ArgTypes...)>&& f2);</ins> +</pre></blockquote> + + + + + + +<hr> +<h3><a name="775"></a>775. Tuple indexing should be unsigned?</h3> +<p><b>Section:</b> 20.4.1.4 [tuple.helper] <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> 2008-01-16</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 tuple element access API identifies the element in the sequence +using signed integers, and then goes on to enforce the requirement that +I be >= 0. There is a much easier way to do this - declare I as +<tt>unsigned</tt>. +</p> +<p> +In fact the proposal is to use <code>std::size_t</code>, matching the type used in the <tt>tuple_size</tt> API. +</p> +<p> +A second suggestion is that it is hard to imagine an API that deduces +and index at compile time and returns a reference throwing an exception. +Add a specific <em>Throws:</em> Nothing paragraph to each element +access API. +</p> +<p> +In addition to <code>tuple</code>, update the API applies to +<code>pair</code> and <code>array</code>, and should be updated +accordingly. +</p> + +<p> +A third observation is that the return type of the <code>get</code> +functions for <code>std::pair</code> is pseudo-code, but it is not +clearly marked as such. There is actually no need for pseudo-code as +the return type can be specified precisely with a call to +<code>tuple_element</code>. This is already done for +<code>std::tuple</code>, and <code>std::array</code> does not have a +problem as all elements are of type <code>T</code>. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Update header <utility> synopsis in 20.2 [utility] +</p> +<pre><em>// 20.2.3, tuple-like access to pair:</em> +template <class T> class tuple_size; +template <<del>int</del><ins>size_t</ins> I, class T> class tuple_element; + +template <class T1, class T2> struct tuple_size<std::pair<T1, T2> >; +template <class T1, class T2> struct tuple_element<0, std::pair<T1, T2> >; +template <class T1, class T2> struct tuple_element<1, std::pair<T1, T2> >; + +template<<del>int</del><ins>size_t</ins> I, class T1, class T2> + <del>P</del><ins>typename tuple_element<I, std::pair<T1, T2> >::type </ins>& get(std::pair<T1, T2>&); +template<<del>int</del><ins>size_t</ins> I, class T1, class T2> + const <del>P</del><ins>typename tuple_element<I, std::pair<T1, T2> >::type </ins>& get(const std::pair<T1, T2>&); +</pre> +<p> +Update <strong>20.2.3 [pairs] Pairs</strong> +</p> +<pre>template<<del>int</del><ins>size_t</ins> I, class T1, class T2> + <del>P</del><ins>typename tuple_element<I, std::pair<T1, T2> >::type </ins>& get(pair<T1, T2>&); +template<<del>int</del><ins>size_t</ins> I, class T1, class T2> + const <del>P</del><ins>typename tuple_element<I, std::pair<T1, T2> >::type </ins>& get(const pair<T1, T2>&); +</pre> +<p> +<del>24 <em>Return type:</em> If <code>I == 0</code> then <code>P</code> is <code>T1</code>, if <code>I == 1</code> then <code>P</code> is <code>T2</code>, and otherwise the program is ill-formed.</del> +</p> +<p> +25 <em>Returns:</em> If <code>I == 0</code> returns <code>p.first</code>, <del>otherwise</del> <ins>if <code>I == 1</code></ins> returns <code>p.second</code><ins>, and otherwise the program is ill-formed</ins>. +</p> +<p> +<ins><em>Throws:</em> Nothing.</ins> +</p> + + +<p> +Update header <tuple> synopsis in 20.4 [tuple] with a APIs as below: +</p> +<pre>template <<del>int</del><ins>size_t</ins> I, class T> class tuple_element; <em>// undefined</em> +template <<del>int</del><ins>size_t</ins> I, class... Types> class tuple_element<I, tuple<Types...> >; + +<em>// 20.3.1.4, element access:</em> +template <<del>int</del><ins>size_t</ins> I, class... Types> + typename tuple_element<I, tuple<Types...> >::type& get(tuple<Types...>&); +template <<del>int</del><ins>size_t</ins> I, class ... types> + typename tuple_element<I, tuple<Types...> >::type const& get(const tuple<Types...>&); +</pre> + +<p> +Update <strong>20.4.1.4 [tuple.helper] Tuple helper classes</strong> +</p> +<pre>template <<del>int</del><ins>size_t</ins> I, class... Types> +class tuple_element<I, tuple<Types...> > { +public: + typedef TI type; +};</pre> +<p> +1 <em>Requires:</em> <code><del>0 <= I and </del>I < sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds. +</p> +<p> +2 <em>Type:</em> <code>TI</code> is the type of the <code>I</code>th element of <code>Types</code>, where indexing is zero-based. +</p> +<p> +Update <strong>20.4.1.5 [tuple.elem] Element access</strong> +</p> +<pre>template <<del>int</del><ins>size_t</ins> I, class... types > +typename tuple_element<I, tuple<Types...> >::type& get(tuple<Types...>& t); +</pre> +1 <em>Requires:</em> <code><del>0 <= I and </del>I < sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds. +<p> +2 <em>Returns:</em> A reference to the <code>I</code>th element of <code>t</code>, where indexing is zero-based. +</p> +<ins><em>Throws:</em> Nothing.</ins> +<pre>template <<del>int</del><ins>size_t</ins> I, class... types> +typename tuple_element<I, tuple<Types...> >::type const& get(const tuple<Types...>& t); +</pre> +<p> +3 <em>Requires:</em> <code><del>0 <= I and </del>I < sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds. +</p> +<p> +4 <em>Returns:</em> A const reference to the <code>I</code>th element of <code>t</code>, where indexing is zero-based. +</p> +<p> +<ins><em>Throws:</em> Nothing.</ins> +</p> + + +<p> +Update header <array> synopsis in 20.2 [utility] +</p> +<pre>template <class T> class tuple_size; <em>// forward declaration</em> +template <<del>int</del><ins>size_t</ins> I, class T> class tuple_element; <em>// forward declaration</em> +template <class T, size_t N> + struct tuple_size<array<T, N> >; +template <<del>int</del><ins>size_t</ins> I, class T, size_t N> + struct tuple_element<I, array<T, N> >; +template <<del>int</del><ins>size_t</ins> I, class T, size_t N> + T& get(array<T, N>&); +template <<del>int</del><ins>size_t</ins> I, class T, size_t N> + const T& get(const array<T, N>&); +</pre> + +<p> +Update <strong>23.2.1.6 [array.tuple] Tuple interface to class template array</strong> +</p> +<pre>tuple_element<<ins>size_t </ins>I, array<T, N> >::type +</pre> +<p> +3 <em>Requires:</em> <code><del>0 <= </del>I < N.</code> The program is ill-formed if <code>I</code> is out of bounds. +</p> +<p> +4 <em>Value:</em> The type <code>T</code>. +</p> +<pre>template <<del>int</del><ins>size_t</ins> I, class T, size_t N> T& get(array<T, N>& a); +</pre> +<p> +5 <em>Requires:</em> <code><del>0 <= </del>I < N</code>. The program is ill-formed if <code>I</code> is out of bounds. +</p> +<p> +<em>Returns:</em> A reference to the <code>I</code>th element of <code>a</code>, where indexing is zero-based. +</p> +<p> +<ins><em>Throws:</em> Nothing.</ins> +</p> +<pre>template <<del>int</del><ins>size_t</ins> I, class T, size_t N> const T& get(const array<T, N>& a); +</pre> +<p> +6 <em>Requires:</em> <code><del>0 <= </del>I < N</code>. The program is ill-formed if <code>I</code> is out of bounds. +</p> +<p> +7 <em>Returns:</em> A const reference to the <code>I</code>th element of <code>a</code>, where indexing is zero-based. +</p> +<p> +<ins><em>Throws:</em> Nothing.</ins> +</p> + + +<p><i>[ +Bellevue: Note also that the phrase "The program is ill-formed if I is +out of bounds" in the requires clauses are probably unnecessary, and +could be removed at the editor's discretion. Also std:: qualification +for pair is also unnecessary. +]</i></p> + + + + +<hr> +<h3><a name="777"></a>777. Atomics Library Issue</h3> +<p><b>Section:</b> 29.4 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-01-21</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.operations">issues</a> in [atomics.types.operations].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The load functions are defined as +</p> + +<blockquote><pre>C atomic_load(volatile A* object); +C atomic_load_explicit(volatile A* object, memory_order); +C A::load(memory_order order = memory_order_seq_cst) volatile; +</pre></blockquote> + +<p> +which prevents their use in <tt>const</tt> contexts. +</p> + +<p><i>[ +post Bellevue Peter adds: +]</i></p> + + +<blockquote> +<p> +Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a> suggests making <tt>atomic_load</tt> operate on <tt>const</tt> objects. There is a +subtle point here. Atomic loads do not generally write to the object, except +potentially for the <tt>memory_order_seq_cst</tt> constraint. Depending on the +architecture, a dummy write with the same value may be required to be issued +by the atomic load to maintain sequential consistency. This, in turn, may +make the following code: +</p> + +<blockquote><pre>const atomic_int x{}; + +int main() +{ + x.load(); +} +</pre></blockquote> + +<p> +dump core under a straightforward implementation that puts const objects in +a read-only section. +</p> +<p> +There are ways to sidestep the problem, but it needs to be considered. +</p> +<p> +The tradeoff is between making the data member of the atomic types +mutable and requiring the user to explicitly mark atomic members as +mutable, as is already the case with mutexes. +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Add the <tt>const</tt> qualifier to <tt>*object</tt> and <tt>*this</tt>. +</p> + +<blockquote><pre>C atomic_load(<ins>const</ins> volatile A* object); +C atomic_load_explicit(<ins>const</ins> volatile A* object, memory_order); +C A::load(memory_order order = memory_order_seq_cst) <ins>const</ins> volatile; +</pre></blockquote> + + + + + + +<hr> +<h3><a name="778"></a>778. std::bitset does not have any constructor taking a string literal</h3> +<p><b>Section:</b> 23.3.5.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2008-01-24</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.cons">issues</a> in [bitset.cons].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a></p> +<p><b>Discussion:</b></p> +<p> +A small issue with <tt>std::bitset</tt>: it does not have any constructor +taking a string literal, which is clumsy and looks like an oversigt when +we tried to enable uniform use of <tt>string</tt> and <tt>const char*</tt> in the library. +</p> + +<p> +Suggestion: Add +</p> + +<blockquote><pre>explicit bitset( const char* str ); +</pre></blockquote> + +<p> +to std::bitset. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add to synopsis in 23.3.5 [template.bitset] +</p> + +<blockquote><pre>explicit bitset( const char* str ); +</pre></blockquote> + +<p> +Add to synopsis in 23.3.5.1 [bitset.cons] +</p> + +<blockquote><pre>explicit bitset( const char* str ); +</pre> +<p> +<i>Effects:</i> Constructs a <tt>bitset</tt> as if <tt>bitset(string(str))</tt>. +</p> +</blockquote> + + + + + + +<hr> +<h3><a name="781"></a>781. <tt>std::complex</tt> should add missing C99 functions</h3> +<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#WP">WP</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-26</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.value.ops">issues</a> in [complex.value.ops].</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 comparision of the N2461 header <tt><complex></tt> synopsis ([complex.synopsis]) +with the C99 standard (ISO 9899, 2nd edition and the two corrigenda) show +some complex functions that are missing in C++. These are: +</p> + +<ol> +<li> +7.3.9.4: (required elements of the C99 library)<br> +The <tt>cproj</tt> functions +</li> +<li> +7.26.1: (optional elements of the C99 library)<br> +<pre>cerf cerfc cexp2 +cexpm1 clog10 clog1p +clog2 clgamma ctgamma +</pre> +</li> +</ol> + +<p> +I propose that at least the required <tt>cproj</tt> overloads are provided as equivalent +C++ functions. This addition is easy to do in one sentence (delegation to C99 +function). +</p> + +<p> +Please note also that the current entry <tt>polar</tt> +in 26.3.9 [cmplx.over]/1 +should be removed from the mentioned overload list. It does not make sense to require that a +function already expecting <em>scalar</em> arguments +should cast these arguments into corresponding +<tt>complex<T></tt> arguments, which are not accepted by +this function. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 26.3.1 [complex.synopsis] add just between the declaration of <tt>conj</tt> and <tt>fabs</tt>: +</p> + +<blockquote><pre>template<class T> complex<T> conj(const complex<T>&); +<ins>template<class T> complex<T> proj(const complex<T>&);</ins> +template<class T> complex<T> fabs(const complex<T>&); +</pre></blockquote> + +<p> +In 26.3.7 [complex.value.ops] just after p.6 (return clause of <tt>conj</tt>) add: +</p> + +<blockquote> +<pre>template<class T> complex<T> proj(const complex<T>& x); +</pre> +<blockquote> + +<i>Effects:</i> Behaves the same as C99 function <tt>cproj</tt>, defined in +subclause 7.3.9.4." +</blockquote> +</blockquote> + +<p> +In 26.3.9 [cmplx.over]/1, add one further entry <tt>proj</tt> to +the overload list. +</p> + +<blockquote> +<p> +The following function templates shall have additional overloads: +</p> +<blockquote><pre>arg norm +conj <del>polar</del> <ins>proj</ins> +imag real +</pre></blockquote> +</blockquote> + + + + + + +<hr> +<h3><a name="782"></a>782. Extended <tt>seed_seq</tt> constructor is useless</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> Daniel Krügler <b>Date:</b> 2008-01-27</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Part of the resolution of n2423, issue 8 was the proposal to +extend the <tt>seed_seq</tt> constructor accepting an input range +as follows (which is now part of N2461): +</p> + +<blockquote><pre>template<class InputIterator, +size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits> +seed_seq(InputIterator begin, InputIterator end); +</pre></blockquote> + +<p> +First, the expression <tt>iterator_traits<InputIterator>::value_type</tt> +is invalid due to missing <tt>typename</tt> keyword, which is easy to +fix. +</p> + +<p> +Second (and worse), while the language now supports default +template arguments of function templates, this customization +point via the second <tt>size_t</tt> template parameter is of no advantage, +because <tt>u</tt> can never be deduced, and worse - because it is a +constructor function template - it can also never be explicitly +provided (14.8.1 [temp.arg.explicit]/7). +</p> + +<p> +The question arises, which advantages result from a compile-time +knowledge of <tt>u</tt> versus a run time knowledge? If run time knowledge +suffices, this parameter should be provided as normal function +default argument [Resolution marked (A)], if compile-time knowledge +is important, this could be done via a tagging template or more +user-friendly via a standardized helper generator function +(<tt>make_seed_seq</tt>), which allows this [Resolution marked (B)]. +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +Fermilab does not have a strong opinion. Would prefer to go with +solution A. Bill agrees that solution A is a lot simpler and does the +job. +</p> +<p> +Proposed Resolution: Accept Solution A. +</p> +</blockquote> + +<p> +Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a> claims to make this issue moot. +</p> + + + +<p><b>Proposed resolution:</b></p> +<ol type="A"> +<li> +<p> +In 26.4.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis replace: +</p> + +<blockquote><pre>class seed_seq +{ +public: + ... + template<class InputIterator<del>, + size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits</del>> + seed_seq(InputIterator begin, InputIterator end<ins>, + size_t u = numeric_limits<typename iterator_traits<InputIterator>::value_type>::digits</ins>); + ... +}; +</pre></blockquote> + +<p> +and do a similar replacement in the member description between +p.3 and p.4. +</p> +</li> + +<li> +<p> +In 26.4.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis <em>and</em> in the +member description between p.3 and p.4 replace: +</p> + +<blockquote><pre>template<class InputIterator<del>, + size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits</del>> + seed_seq(InputIterator begin, InputIterator end); +<ins>template<class InputIterator, size_t u> +seed_seq(InputIterator begin, InputIterator end, <i>implementation-defined</i> s);</ins> +</pre></blockquote> + +<p> +In 26.4.2 [rand.synopsis], header <tt><random></tt> synopsis, immediately after the +class <tt>seed_seq</tt> declaration <em>and</em> in 26.4.7.1 [rand.util.seedseq]/2, immediately +after the class <tt>seed_seq</tt> definition add: +</p> + +<blockquote><pre>template<size_t u, class InputIterator> + seed_seq make_seed_seq(InputIterator begin, InputIterator end); +</pre></blockquote> + +<p> +In 26.4.7.1 [rand.util.seedseq], just before p.5 insert two paragraphs: +</p> + +<blockquote> +<p> +The first constructor behaves as if it would provide an +integral constant expression <tt>u</tt> of type <tt>size_t</tt> of value +<tt>numeric_limits<typename iterator_traits<InputIterator>::value_type>::digits</tt>. +</p> +<p> +The second constructor uses an implementation-defined mechanism +to provide an integral constant expression <tt>u</tt> of type <tt>size_t</tt> and +is called by the function <tt>make_seed_seq</tt>. +</p> +</blockquote> + +<p> +In 26.4.7.1 [rand.util.seedseq], just after the last paragraph add: +</p> + +<blockquote> +<pre>template<size_t u, class InputIterator> + seed_seq make_seed_seq(InputIterator begin, InputIterator end); +</pre> +<blockquote> +<p> +where <tt>u</tt> is used to construct an object <tt>s</tt> of implementation-defined type. +</p> +<p> +<i>Returns:</i> <tt>seed_seq(begin, end, s)</tt>; +</p> +</blockquote> +</blockquote> + +</li> +</ol> + + + + + + +<hr> +<h3><a name="783"></a>783. <tt>thread::id</tt> reuse</h3> +<p><b>Section:</b> 30.2.1.1 [thread.thread.id] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Hans Boehm <b>Date:</b> 2008-02-01</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 working paper +(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2497.html">N2497</a>, +integrated just before Bellevue) is +not completely clear whether a given <tt>thread::id</tt> value may be reused once +a thread has exited and has been joined or detached. Posix allows +thread ids (<tt>pthread_t</tt> values) to be reused in this case. Although it is +not completely clear whether this originally was the right decision, it +is clearly the established practice, and we believe it was always the +intent of the C++ threads API to follow Posix and allow this. Howard +Hinnant's example implementation implicitly relies on allowing reuse +of ids, since it uses Posix thread ids directly. +</p> + +<p> +It is important to be clear on this point, since it the reuse of thread +ids often requires extra care in client code, which would not be +necessary if thread ids were unique across all time. For example, a +hash table indexed by thread id may have to be careful not to associate +data values from an old thread with a new one that happens to reuse the +id. Simply removing the old entry after joining a thread may not be +sufficient, if it creates a visible window between the join and removal +during which a new thread with the same id could have been created and +added to the table. +</p> + +<p><i>[ +post Bellevue Peter adds: +]</i></p> + + +<blockquote> +<p> +There is a real issue with <tt>thread::id</tt> reuse, but I urge the LWG to +reconsider fixing this by disallowing reuse, rather than explicitly allowing +it. Dealing with thread id reuse is an incredibly painful exercise that +would just force the world to reimplement a non-conflicting <tt>thread::id</tt> over +and over. +</p> +<p> +In addition, it would be nice if a <tt>thread::id</tt> could be manipulated +atomically in a lock-free manner, as motivated by the recursive lock +example: +</p> + +<p> +<a href="http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html">http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html</a> +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Add a sentence to 30.2.1.1 [thread.thread.id]/p1: +</p> + +<blockquote> +<p> +An object of type <code>thread::id</code> provides +a unique identifier for each thread of execution +and a single distinct value for all thread objects +that do not represent a thread of execution ([thread.threads.class]). +Each thread of execution has a <code>thread::id</code> +that is not equal to the <code>thread::id</code> +of other threads of execution +and that is not equal to +the <code>thread::id</code> of <code>std::thread</code> objects +that do not represent threads of execution. +<ins>The library may reuse the value of a <code>thread::id</code> of a +terminated thread that can no longer be joined.</ins> +</p> +</blockquote> + + + + + +<hr> +<h3><a name="789"></a>789. <tt>xor_combine_engine(result_type)</tt> should be explicit</h3> +<p><b>Section:</b> 26.4.4.4 [rand.adapt.xor] <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> 2008-02-09</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.adapt.xor">issues</a> in [rand.adapt.xor].</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> +<tt>xor_combine_engine(result_type)</tt> should be <tt>explicit</tt>. (Obvious oversight.) +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Non-controversial. Bill is right, but Fermilab believes that this is +easy to use badly and hard to use right, and so it should be removed +entirely. Got into TR1 by well defined route, do we have permission to +remove stuff? Should probably check with Jens, as it is believed he is +the originator. Broad consensus that this is not a robust engine +adapter. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Remove xor_combine_engine from synopsis of 26.4.2 [rand.synopsis]. +</p> +<p> +Remove 26.4.4.4 [rand.adapt.xor] <tt>xor_combine_engine</tt>. +</p> + + + + + +<hr> +<h3><a name="792"></a>792. <tt>piecewise_constant_distribution</tt> is undefined for a range with just one endpoint</h3> +<p><b>Section:</b> 26.4.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.pconst">active issues</a> in [rand.dist.samp.pconst].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +<tt>piecewise_constant_distribution</tt> is undefined for a range with just one +endpoint. (Probably should be the same as an empty range.) +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 26.4.8.5.2 [rand.dist.samp.pconst] paragraph 3b: +</p> + +<blockquote> +b) If <tt>firstB == lastB</tt> <ins>or the sequence <tt>w</tt> has the length zero</ins>, +</blockquote> + + + + + +<hr> +<h3><a name="798"></a>798. Refactoring of binders lead to interface breakage</h3> +<p><b>Section:</b> D.8 [depr.lib.binders] <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> 2008-02-14</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.lib.binders">issues</a> in [depr.lib.binders].</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/2008/n2521.pdf">N2521</a> +and its earlier predecessors have moved the old binders from +[lib.binders] to D.8 [depr.lib.binders] thereby introducing some renaming +of the template parameter names (<tt>Operation -> Fn</tt>). During this +renaming process the <em>protected</em> data member <tt>op</tt> was also renamed to +<tt>fn</tt>, which seems as an unnecessary interface breakage to me - even if +this user access point is probably rarely used. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change D.8.1 [depr.lib.binder.1st]: +</p> + +<blockquote> +<pre>template <class Fn> +class binder1st + : public unary_function<typename Fn::second_argument_type, + typename Fn::result_type> { +protected: + Fn <del>fn</del> <ins>op</ins>; + typename Fn::first_argument_type value; +public: + binder1st(const Fn& x, + const typename Fn::first_argument_type& y); + typename Fn::result_type + operator()(const typename Fn::second_argument_type& x) const; + typename Fn::result_type + operator()(typename Fn::second_argument_type& x) const; +}; +</pre> + +<blockquote> +<p> +-1- The constructor initializes <del><tt>fn</tt></del> <ins><tt>op</tt></ins> with <tt>x</tt> and <tt>value</tt> with <tt>y</tt>. +</p> +<p> +-2- <tt>operator()</tt> returns <tt><del>fn</del><ins>op</ins>(value,x)</tt>. +</p> +</blockquote> +</blockquote> + +<p> +Change D.8.3 [depr.lib.binder.2nd]: +</p> + +<blockquote> +<pre>template <class Fn> +class binder2nd + : public unary_function<typename Fn::first_argument_type, + typename Fn::result_type> { +protected: + Fn <del>fn</del> <ins>op</ins>; + typename Fn::second_argument_type value; +public: + binder2nd(const Fn& x, + const typename Fn::second_argument_type& y); + typename Fn::result_type + operator()(const typename Fn::first_argument_type& x) const; + typename Fn::result_type + operator()(typename Fn::first_argument_type& x) const; +}; +</pre> + +<blockquote> +<p> +-1- The constructor initializes <del><tt>fn</tt></del> <ins><tt>op</tt></ins> with <tt>x</tt> and <tt>value</tt> with <tt>y</tt>. +</p> +<p> +-2- <tt>operator()</tt> returns <tt><del>fn</del><ins>op</ins>(value,x)</tt>. +</p> +</blockquote> +</blockquote> + + + + + + </body></html>
\ No newline at end of file diff --git a/libstdc++-v3/doc/xml/manual/intro.xml b/libstdc++-v3/doc/xml/manual/intro.xml index 8cca6f39842..b64b969590f 100644 --- a/libstdc++-v3/doc/xml/manual/intro.xml +++ b/libstdc++-v3/doc/xml/manual/intro.xml @@ -611,7 +611,7 @@ <listitem><para>Follow the straightforward proposed resolution. </para></listitem></varlistentry> - <varlistentry><term><ulink url="../ext/lwg-active.html#550">550</ulink>: + <varlistentry><term><ulink url="../ext/lwg-defects.html#550">550</ulink>: <emphasis>What should the return type of pow(float,int) be?</emphasis> </term> <listitem><para>In C++0x mode, remove the pow(float,int), etc., signatures. @@ -623,7 +623,7 @@ <listitem><para>Change it to be a formatted output function (i.e. catch exceptions). </para></listitem></varlistentry> - <varlistentry><term><ulink url="../ext/lwg-active.html#596">596</ulink>: + <varlistentry><term><ulink url="../ext/lwg-defects.html#596">596</ulink>: <emphasis>27.8.1.3 Table 112 omits "a+" and "a+b" modes</emphasis> </term> <listitem><para>Add the missing modes to fopen_mode. @@ -654,13 +654,13 @@ <listitem><para>Make the member functions table and classic_table public. </para></listitem></varlistentry> - <varlistentry><term><ulink url="../ext/lwg-active.html#761">761</ulink>: + <varlistentry><term><ulink url="../ext/lwg-defects.html#761">761</ulink>: <emphasis>unordered_map needs an at() member function</emphasis> </term> <listitem><para>In C++0x mode, add at() and at() const. </para></listitem></varlistentry> - <varlistentry><term><ulink url="../ext/lwg-active.html#775">775</ulink>: + <varlistentry><term><ulink url="../ext/lwg-defects.html#775">775</ulink>: <emphasis>Tuple indexing should be unsigned?</emphasis> </term> <listitem><para>Implement the int -> size_t replacements. @@ -672,14 +672,14 @@ <listitem><para>In C++0x mode, remove assign, add fill. </para></listitem></varlistentry> - <varlistentry><term><ulink url="../ext/lwg-active.html#778">778</ulink>: + <varlistentry><term><ulink url="../ext/lwg-defects.html#778">778</ulink>: <emphasis>std::bitset does not have any constructor taking a string literal</emphasis> </term> <listitem><para>Add it. </para></listitem></varlistentry> - <varlistentry><term><ulink url="../ext/lwg-active.html#781">781</ulink>: + <varlistentry><term><ulink url="../ext/lwg-defects.html#781">781</ulink>: <emphasis>std::complex should add missing C99 functions</emphasis> </term> <listitem><para>In C++0x mode, add std::proj. |