diff options
| -rw-r--r-- | libstdc++-v3/ChangeLog | 6 | ||||
| -rw-r--r-- | libstdc++-v3/doc/html/ext/lwg-active.html | 12764 | ||||
| -rw-r--r-- | libstdc++-v3/doc/html/ext/lwg-closed.html | 3533 | ||||
| -rw-r--r-- | libstdc++-v3/doc/html/ext/lwg-defects.html | 2455 |
4 files changed, 14062 insertions, 4696 deletions
diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog index c2b2ea6..85195fb 100644 --- a/libstdc++-v3/ChangeLog +++ b/libstdc++-v3/ChangeLog @@ -1,3 +1,9 @@ +2008-05-21 Paolo Carlini <paolo.carlini@oracle.com> + + * doc/html/ext/lwg-active.html: Update to Revision R56. + * doc/html/ext/lwg-closed.html: Likewise. + * doc/html/ext/lwg-defects.html: Likewise. + 2008-05-20 Paolo Carlini <paolo.carlini@oracle.com> PR c++/33979 (partial) diff --git a/libstdc++-v3/doc/html/ext/lwg-active.html b/libstdc++-v3/doc/html/ext/lwg-active.html index 29e0d77..27e0ed2 100644 --- a/libstdc++-v3/doc/html/ext/lwg-active.html +++ b/libstdc++-v3/doc/html/ext/lwg-active.html @@ -12,11 +12,11 @@ del {background-color:#FFA0A0} <table> <tbody><tr> <td align="left">Doc. no.</td> -<td align="left">N2456=07-0326</td> +<td align="left">N2612=08-0122</td> </tr> <tr> <td align="left">Date:</td> -<td align="left">2007-10-20</td> +<td align="left">2008-05-18</td> </tr> <tr> <td align="left">Project:</td> @@ -27,7 +27,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 R52)</h1> +<h1>C++ Standard Library Active Issues List (Revision R56)</h1> <p>Reference ISO/IEC IS 14882:1998(E)</p> <p>Also see:</p> @@ -94,6 +94,89 @@ del {background-color:#FFA0A0} <h2>Revision History</h2> <ul> +<li>R56: +2008-05-16 pre-Sophia Antipolis mailing. +<ul> +<li><b>Summary:</b><ul> +<li>191 open issues, up by 24.</li> +<li>647 closed issues, up by 1.</li> +<li>838 issues total, up by 25.</li> +</ul></li> +<li><b>Details:</b><ul> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>.</li> +</ul></li> +</ul> +</li> +<li>R55: +2008-03-14 post-Bellevue mailing. +<ul> +<li><b>Summary:</b><ul> +<li>167 open issues, down by 39.</li> +<li>646 closed issues, up by 65.</li> +<li>813 issues total, up by 26.</li> +</ul></li> +<li><b>Details:</b><ul> +<li>Added the following Dup issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a>.</li> +<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#790">790</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#791">791</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#796">796</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#797">797</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#799">799</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>.</li> +<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#801">801</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a>.</li> +<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>.</li> +<li>Changed the following issues from NAD Future to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.</li> +<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>.</li> +<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#462">462</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>.</li> +<li>Changed the following issues from NAD Future to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li> +<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li> +<li>Changed the following issues from Review to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>.</li> +<li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a>.</li> +<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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 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 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 Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>.</li> +<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>.</li> +<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li> +<li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>.</li> +</ul></li> +</ul> +</li> +<li>R54: +2008-02-01 pre-Bellevue mailing. +<ul> +<li><b>Summary:</b><ul> +<li>206 open issues, up by 23.</li> +<li>581 closed issues, up by 0.</li> +<li>787 issues total, up by 23.</li> +</ul></li> +<li><b>Details:</b><ul> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>.</li> +<li>Changed the following issues from NAD Future to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>.</li> +<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#697">697</a>.</li> +<li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>.</li> +<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>.</li> +</ul></li> +</ul> +</li> +<li>R53: +2007-12-09 mid-term mailing. +<ul> +<li><b>Summary:</b><ul> +<li>183 open issues, up by 11.</li> +<li>581 closed issues, down by 1.</li> +<li>764 issues total, up by 10.</li> +</ul></li> +<li><b>Details:</b><ul> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>.</li> +<li>Changed the following issues from Pending WP to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li> +</ul></li> +</ul> +</li> <li>R52: 2007-10-19 post-Kona mailing. <ul> @@ -103,16 +186,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-active.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#754">754</a>.</li> +<li>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>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>.</li> <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>.</li> <li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a>.</li> -<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li> +<li>Changed the following issues from New to 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 Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li> <li>Changed the following issues from New to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li> -<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#706">706</a>.</li> -<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#680">680</a>.</li> -<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>.</li> +<li>Changed the following issues from New to 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 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 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> @@ -128,7 +211,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-active.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>.</li> +<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> </ul></li> </ul> </li> @@ -141,13 +224,13 @@ del {background-color:#FFA0A0} <li>708 issues total, up by 12.</li> </ul></li> <li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#697">697</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#697">697</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li> <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#584">584</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>.</li> <li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</a>.</li> <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>.</li> <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>.</li> <li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li> -<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#680">680</a>.</li> +<li>Changed the following issues from 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 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> @@ -168,7 +251,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-active.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li> +<li>Added the following 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 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> @@ -185,12 +268,12 @@ 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-active.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>.</li> +<li>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>Changed the following issues from Tentatively Ready to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>.</li> -<li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li> +<li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li> <li>Changed the following issues from NAD to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#357">357</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#368">368</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a>.</li> <li>Changed the following issues from Tentatively Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>.</li> -<li>Changed the following issues from NAD_Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li> +<li>Changed the following issues from NAD_Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li> <li>Changed the following issues from Tentatively Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>.</li> <li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li> <li>Changed the following issues from Tentatively Ready to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>.</li> @@ -212,11 +295,11 @@ 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-active.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li> -<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#626">626</a>.</li> +<li>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 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 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-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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 Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>.</li> <li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>.</li> </ul></li> </ul> @@ -246,7 +329,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-active.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li> +<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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> @@ -290,9 +373,9 @@ del {background-color:#FFA0A0} <li>574 issues total, up by 8.</li> </ul></li> <li><b>Details:</b><ul> -<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#567">567</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li> +<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li> <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#501">501</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#517">517</a> to NAD.</li> -<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a> to Open.</li> +<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a> to Open.</li> <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a> to Ready.</li> <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> to WP.</li> <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li> @@ -323,7 +406,7 @@ del {background-color:#FFA0A0} <li>535 issues total.</li> </ul></li> <li><b>Details:</b><ul> -<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#529">529</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>.</li> +<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>.</li> </ul></li> </ul> </li> @@ -368,12 +451,12 @@ new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html# <li>R31: 2004-07 mid-term mailing: reflects new proposed resolutions and new issues received after the post-Sydney mailing. Added -new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>. +new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>. </li> <li>R30: Post-Sydney mailing: reflects decisions made at the Sydney meeting. Voted all "Ready" issues from R29 into the working paper. -Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#462">462</a>. +Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#462">462</a>. </li> <li>R29: Pre-Sydney mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>. @@ -518,7 +601,7 @@ of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3 <li>R10: pre-Kona updated. Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>, -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a> to +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99) </li> <li>R9: @@ -537,7 +620,7 @@ pre-Dublin updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a> (31 Mar 99) </li> <li>R6: -pre-Dublin mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>, +pre-Dublin mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>, and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>. (99-0007/N1194, 22 Feb 99) </li> <li>R5: @@ -869,7 +952,7 @@ is assigned to <i>err</i>.</ins> <hr> <h3><a name="96"></a>96. Vector<bool> is not a container</h3> -<p><b>Section:</b> 23.2.5 [vector] <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.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> @@ -965,6 +1048,172 @@ users who want to continue using a bit-packed container. Alan and Beman to work <hr> +<h3><a name="128"></a>128. Need open_mode() function for file stream, string streams, file buffers, and string buffers</h3> +<p><b>Section:</b> 27.7 [string.streams], 27.8 [file.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-02-22</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.streams">issues</a> in [string.streams].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> +<p><b>Discussion:</b></p> +<p>The following question came from Thorsten Herlemann:</p> + +<blockquote> + <p>You can set a mode when constructing or opening a file-stream or + filebuf, e.g. ios::in, ios::out, ios::binary, ... But how can I get + that mode later on, e.g. in my own operator << or operator + >> or when I want to check whether a file-stream or + file-buffer object passed as parameter is opened for input or output + or binary? Is there no possibility? Is this a design-error in the + standard C++ library? </p> +</blockquote> + +<p>It is indeed impossible to find out what a stream's or stream +buffer's open mode is, and without that knowledge you don't know +how certain operations behave. Just think of the append mode. </p> + +<p>Both streams and stream buffers should have a <tt>mode()</tt> function that returns the +current open mode setting. </p> + +<p><i>[ +post Bellevue: Alisdair requested to re-Open. +]</i></p> + + + + +<p><b>Proposed resolution:</b></p> +<p>For stream buffers, add a function to the base class as a non-virtual function +qualified as const to 27.5.2 [streambuf]:</p> + +<p> <tt>openmode mode() const</tt>;</p> + +<p><b> Returns</b> the current open mode.</p> + +<p>With streams, I'm not sure what to suggest. In principle, the mode +could already be returned by <tt>ios_base</tt>, but the mode is only +initialized for file and string stream objects, unless I'm overlooking +anything. For this reason it should be added to the most derived +stream classes. Alternatively, it could be added to <tt>basic_ios</tt> +and would be default initialized in <tt>basic_ios<>::init()</tt>.</p> + + +<p><b>Rationale:</b></p> +<p>This might be an interesting extension for some future, but it is +not a defect in the current standard. The Proposed Resolution is +retained for future reference.</p> + + + + + +<hr> +<h3><a name="180"></a>180. Container member iterator arguments constness has unintended consequences</h3> +<p><b>Section:</b> 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> 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>Discussion:</b></p> +<p>It is the constness of the container which should control whether +it can be modified through a member function such as erase(), not the +constness of the iterators. The iterators only serve to give +positioning information.</p> + +<p>Here's a simple and typical example problem which is currently very +difficult or impossible to solve without the change proposed +below.</p> + +<p>Wrap a standard container C in a class W which allows clients to +find and read (but not modify) a subrange of (C.begin(), C.end()]. The +only modification clients are allowed to make to elements in this +subrange is to erase them from C through the use of a member function +of W.</p> + +<p><i>[ +post Bellevue, Alisdair adds: +]</i></p> + + +<blockquote> +<p> +This issue was implemented by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2350.pdf">N2350</a> +for everything but <tt>basic_string</tt>. +</p> + +<p> +Note that the specific example in this issue (<tt>basic_string</tt>) is the one place +we forgot to amend in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2350.pdf">N2350</a>, +so we might open this issue for that +single container? +</p> +</blockquote> + + + +<p><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>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> +</p> + + +<p><b>Rationale:</b></p> +<p>The issue was discussed at length. It was generally agreed that 1) +There is no major technical argument against the change (although +there is a minor argument that some obscure programs may break), and +2) Such a change would not break const correctness. The concerns about +making the change were 1) it is user detectable (although only in +boundary cases), 2) it changes a large number of signatures, and 3) it +seems more of a design issue that an out-and-out defect.</p> + +<p>The LWG believes that this issue should be considered as part of a +general review of const issues for the next revision of the +standard. Also see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>.</p> + + + + +<hr> +<h3><a name="190"></a>190. min() and max() functions should be std::binary_functions</h3> +<p><b>Section:</b> 25.3.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Mark Rintoul <b>Date:</b> 1999-08-26</p> +<p><b>View 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> +<p>Both std::min and std::max are defined as template functions. This +is very different than the definition of std::plus (and similar +structs) which are defined as function objects which inherit +std::binary_function.<br> +<br> + This lack of inheritance leaves std::min and std::max somewhat useless in standard library algorithms which require +a function object that inherits std::binary_function.</p> + +<p><i>[ +post Bellevue: Alisdair requested to re-Open. +]</i></p> + + + + +<p><b>Rationale:</b></p> +<p>Although perhaps an unfortunate design decision, the omission is not a defect +in the current standard. A future standard may wish to consider additional +function objects.</p> + + + + +<hr> <h3><a name="255"></a>255. Why do <tt>basic_streambuf<>::pbump()</tt> and <tt>gbump()</tt> take an int?</h3> <p><b>Section:</b> 27.5.2 [streambuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-08-12</p> @@ -1210,7 +1459,6 @@ with a return type of convertible to <tt>T</tt> and operational semantics of <h3><a name="309"></a>309. Does sentry catch exceptions?</h3> <p><b>Section:</b> 27.6 [iostream.format] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-03-19</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iostream.format">active issues</a> in [iostream.format].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.format">issues</a> in [iostream.format].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> <p><b>Discussion:</b></p> @@ -1759,6 +2007,19 @@ think that there are cases such as some of those above where it would be desirable to allow implementations to include only as much as necessary and not more.</p> +<p><i>[ +post Bellevue: +]</i></p> + + +<blockquote> +Position taken in prior reviews is that the idea of a table of header +dependencies is a good one. Our view is that a full paper is needed to +do justice to this, and we've made that recommendation to the issue +author. +</blockquote> + + <p><b>Proposed resolution:</b></p> <p> @@ -1982,10 +2243,10 @@ partial can only occur if (from_next != from_end)? <hr> <h3><a name="387"></a>387. std::complex over-encapsulated</h3> -<p><b>Section:</b> 26.3 [complex.numbers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> +<p><b>Section:</b> 26.3 [complex.numbers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2002-11-08</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.numbers">issues</a> in [complex.numbers].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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> The absence of explicit description of std::complex<T> layout @@ -2027,9 +2288,9 @@ of std::complex<> is not justified. <ul> <li>the expression reinterpret_cast<cv T(&)[2]>(z) is well-formed; and</li> -<li>reinterpret_cast<cvT(&)[2]>(z)[0]designates the +<li>reinterpret_cast<cv T(&)[2]>(z)[0]designates the real part of z; and</li> -<li>reinterpret_cast<cvT(&)[2]>(z)[1]designates the +<li>reinterpret_cast<cv T(&)[2]>(z)[1]designates the imaginary part of z.</li> </ul> @@ -2040,45 +2301,47 @@ i then: </p> <ul> -<li>reinterpret_cast<cvT*>(a)[2+i] designates the real +<li>reinterpret_cast<cv T*>(a)[2*i] designates the real part of a[i]; and</li> -<li>reinterpret_cast<cv T*>(a)[2+i+1] designates the +<li>reinterpret_cast<cv T*>(a)[2*i+1] designates the imaginary part of a[i].</li> </ul> </blockquote> -<p>In the header synopsis in 26.3.1 [complex.synopsis], replace</p> -<pre> template<class T> T real(const complex<T>&); - template<class T> T imag(const complex<T>&); -</pre> +<p> +In 26.3.2 [complex] Add the member functions +</p> -<p>with</p> +<blockquote><pre>void real(T); +void imag(T); +</pre></blockquote> -<pre> template<class T> const T& real(const complex<T>&); - template<class T> T& real( complex<T>&); - template<class T> const T& imag(const complex<T>&); - template<class T> T& imag( complex<T>&); -</pre> +<p> +Add to 26.3.4 [complex.members] +</p> -<p>In 26.3.7 [complex.value.ops] paragraph 1, change</p> -<pre> template<class T> T real(const complex<T>&); +<blockquote> +<pre>T real() const; </pre> -<p>to</p> -<pre> template<class T> const T& real(const complex<T>&); - template<class T> T& real( complex<T>&); +<blockquote> +<i>Returns:</i> the value of the real component +</blockquote> +<pre>void real(T val); </pre> -<p>and change the <b>Returns</b> clause to "<b>Returns:</b> The real -part of <i>x</i>.</p> - -<p>In 26.3.7 [complex.value.ops] paragraph 2, change</p> -<pre> template<class T> T imag(const complex<T>&); +<blockquote> +Assigns val to the real component. +</blockquote> +<pre>T imag() const; </pre> -<p>to</p> -<pre> template<class T> const T& imag(const complex<T>&); - template<class T> T& imag( complex<T>&); +<blockquote> +<i>Returns:</i> the value of the imaginary component +</blockquote> +<pre>void imag(T val); </pre> -<p>and change the <b>Returns</b> clause to "<b>Returns:</b> The imaginary -part of <i>x</i>.</p> +<blockquote> +Assigns val to the imaginary component. +</blockquote> +</blockquote> <p><i>[Kona: The layout guarantee is absolutely necessary for C compatibility. However, there was disagreement about the other part @@ -2095,6 +2358,14 @@ part of <i>x</i>.</p> <p><i>[pre-Sydney: Howard summarized the options in n1589.]</i></p> +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Second half of proposed wording replaced and moved to Ready. +</blockquote> <p><b>Rationale:</b></p> @@ -2215,6 +2486,7 @@ functions should be changed as proposed below. <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> <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>Discussion:</b></p> @@ -2305,6 +2577,15 @@ is <i>zero</i>. Otherwise, the element has the value 1.</p> +<p><i>[ +post Bellevue: +]</i></p> + + +<blockquote> +We are happy with the resolution as proposed, and we move this to Ready. +</blockquote> + @@ -2348,7 +2629,7 @@ sentry::~sentry() should internally catch any exceptions it might cause. <p><i>[ -See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#418">418</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#622">622</a> for related issues. +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#418">418</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a> for related issues. ]</i></p> @@ -2661,7 +2942,7 @@ object throws. <p><i>[ -See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#397">397</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#622">622</a> for related issues. +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#397">397</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a> for related issues. ]</i></p> @@ -3024,88 +3305,6 @@ ostream::write(). <hr> -<h3><a name="424"></a>424. normative notes</h3> -<p><b>Section:</b> 17.3.1.1 [structure.summary] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> - <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> -<p><b>Discussion:</b></p> - -<p> -The text in 17.3.1.1, p1 says: -<br> - -"Paragraphs labelled "Note(s):" or "Example(s):" are informative, other -paragraphs are normative." -<br> - -The library section makes heavy use of paragraphs labeled "Notes(s)," -some of which are clearly intended to be normative (see list 1), while -some others are not (see list 2). There are also those where the intent -is not so clear (see list 3). -<br><br> - -List 1 -- Examples of (presumably) normative Notes: -<br> - -20.6.1.1 [allocator.members], p3,<br> -20.6.1.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> -25.3.7 [alg.min.max], p3,<br> -26.3.6 [complex.ops], p15,<br> -27.5.2.4.3 [streambuf.virt.get], p7.<br> -<br> - -List 2 -- Examples of (presumably) informative Notes: -<br> - -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> -26.3.5 [complex.member.ops], p1,<br> -27.4.2.5 [ios.base.storage], p6.<br> -<br> - -List 3 -- Examples of Notes that are not clearly either normative -or informative: -<br> - -22.1.1.2 [locale.cons], p8,<br> -22.1.1.5 [locale.statics], p6,<br> -27.5.2.4.5 [streambuf.virt.put], p4.<br> -<br> - -None of these lists is meant to be exhaustive. -</p> - -<p><i>[Definitely a real problem. The big problem is there's material - that doesn't quite fit any of the named paragraph categories - (e.g. <b>Effects</b>). Either we need a new kind of named - paragraph, or we need to put more material in unnamed paragraphs - jsut after the signature. We need to talk to the Project Editor - about how to do this. -]</i></p> - - - -<p><b>Proposed resolution:</b></p> -<p><i>[Pete: I changed the paragraphs marked "Note" and "Notes" to use "Remark" and "Remarks". -Fixed as editorial. This change has been in the WD since the post-Redmond mailing, in 2004. -Recommend NAD.]</i></p> - -<p><i>[ -Batavia: We feel that the references in List 2 above should be changed from <i>Remarks</i> -to <i>Notes</i>. We also feel that those items in List 3 need to be double checked for -the same change. Alan and Pete to review. -]</i></p> - - - - - -<hr> <h3><a name="427"></a>427. stage 2 and rationale of DR 221</h3> <p><b>Section:</b> 22.2.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p> @@ -3184,8 +3383,155 @@ object (e.g., slice (2, 1, 1) for a valarray of size 1). need wording to express this decision.]</i></p> +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Please note that the standard also fails to specify the behavior of +slice_array and gslice_array in the valid case. Bill Plauger will +endeavor to provide revised wording for slice_array and gslice_array. +</blockquote> + +<p><i>[ +post-Bellevue: Bill provided wording. +]</i></p> + + <p><b>Proposed resolution:</b></p> +<p> +Insert after 26.5.2.4 [valarray.sub], paragraph 1: +</p> + +<blockquote> +<p> +The member operator is overloaded to provide several ways to select +sequences +of elements from among those controlled by <tt>*this</tt>. The first group of five +member operators work in conjunction with various overloads of <tt>operator=</tt> +(and other assigning operators) to allow selective replacement (slicing) of +the controlled sequence. The selected elements must exist. +</p> +<p> +The first member operator selects element off. For example: +</p> + +<blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16); +v0[3] = 'A'; +// v0 == valarray<char>("abcAefghijklmnop", 16) +</pre></blockquote> + +<p> +The second member operator selects those elements of the controlled sequence +designated by <tt>slicearr</tt>. For example: +</p> + +<blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16); +valarray<char> v1("ABCDE", 5); +v0[slice(2, 5, 3)] = v1; +// v0 == valarray<char>("abAdeBghCjkDmnEp", 16) +</pre></blockquote> + +<p> +The third member operator selects those elements of the controlled sequence +designated by <tt>gslicearr</tt>. For example: +</p> + +<blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16); +valarray<char> v1("ABCDEF", 6); +const size_t lv[] = {2, 3}; +const size_t dv[] = {7, 2}; +const valarray<size_t> len(lv, 2), str(dv, 2); +v0[gslice(3, len, str)] = v1; +// v0 == valarray<char>("abcAeBgCijDlEnFp", 16) +</pre></blockquote> + +<p> +The fourth member operator selects those elements of the controlled sequence +designated by <tt>boolarr</tt>. For example: +</p> + +<blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16); +valarray<char> v1("ABC", 3); +const bool vb[] = {false, false, true, true, false, true}; +v0[valarray<bool>(vb, 6)] = v1; +// v0 == valarray<char>("abABeCghijklmnop", 16) +</pre></blockquote> + +<p> +The fifth member operator selects those elements of the controlled sequence +designated by indarr. For example: +</p> + +<blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16); +valarray<char> v1("ABCDE", 5); +const size_t vi[] = {7, 5, 2, 3, 8}; +v0[valarray<size_t>(vi, 5)] = v1; +// v0 == valarray<char>("abCDeBgAEjklmnop", 16) +</pre></blockquote> + +<p> +The second group of five member operators each construct an object that +represents the value(s) selected. The selected elements must exist. +</p> + +<p> +The sixth member operator returns the value of element off. For example: +</p> + +<blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16); +// v0[3] returns 'd' +</pre></blockquote> + +<p> +The seventh member operator returns an object of class <tt>valarray<Ty></tt> +containing those elements of the controlled sequence designated by <tt>slicearr</tt>. +For example: +</p> + +<blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16); +// v0[slice(2, 5, 3)] returns valarray<char>("cfilo", 5) +</pre></blockquote> + +<p> +The eighth member operator selects those elements of the controlled sequence +designated by <tt>gslicearr</tt>. For example: +</p> + +<blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16); +const size_t lv[] = {2, 3}; +const size_t dv[] = {7, 2}; +const valarray<size_t> len(lv, 2), str(dv, 2); +// v0[gslice(3, len, str)] returns +// valarray<char>("dfhkmo", 6) +</pre></blockquote> + +<p> +The ninth member operator selects those elements of the controlled sequence +designated by <tt>boolarr</tt>. For example: +</p> + +<blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16); +const bool vb[] = {false, false, true, true, false, true}; +// v0[valarray<bool>(vb, 6)] returns +// valarray<char>("cdf", 3) +</pre></blockquote> + +<p> +The last member operator selects those elements of the controlled sequence +designated by <tt>indarr</tt>. For example: +</p> + +<blockquote><pre>valarray<char> v0("abcdefghijklmnop", 16); +const size_t vi[] = {7, 5, 2, 3, 8}; +// v0[valarray<size_t>(vi, 5)] returns +// valarray<char>("hfcdi", 5) +</pre></blockquote> + +</blockquote> + @@ -3312,6 +3658,7 @@ reachability. <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> <p><b>Discussion:</b></p> <pre> basic_filebuf *basic_filebuf::open(const char *, ios_base::open_mode); </pre> @@ -3421,6 +3768,33 @@ std::basic_string? (3) We might want to wait until we see Beman's filesystem library; we might decide that it obviates this.]</i></p> +<p><i>[ +post Bellevue: +]</i></p> + + +<blockquote> +<p> +Move again to Ready. +</p> +<p> +There is a timing issue here. Since the filesystem library will not be +in C++0x, this should be brought forward. This solution would remain +valid in the context of the proposed filesystem. +</p> +<p> +This issue has been kicking around for a while, and the wchar_t addition +alone would help many users. Thus, we suggest putting this on the +reflector list with an invitation for someone to produce proposed +wording that covers basic_fstream. In the meantime, we suggest that the +proposed wording be adopted as-is. +</p> +<p> +If more of the Lillehammer questions come back, they should be +introduced as separate issues. +</p> +</blockquote> + @@ -3563,146 +3937,403 @@ technique to perform the comparison:</p> <hr> -<h3><a name="462"></a>462. Destroying objects with static storage duration</h3> -<p><b>Section:</b> 3.6.3 [basic.start.term], 18.3 [cstdint] <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-03-23</p> +<h3><a name="463"></a>463. auto_ptr usability issues</h3> +<p><b>Section:</b> D.9.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Rani Sharoni <b>Date:</b> 2003-12-07</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#auto.ptr">issues</a> in [auto.ptr].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> <p><b>Discussion:</b></p> + +<p> +TC1 CWG DR #84 effectively made the template<class Y> operator auto_ptr<Y>() +member of auto_ptr (20.4.5.3/4) obsolete. +</p> + +<p> +The sole purpose of this obsolete conversion member is to enable copy +initialization base from r-value derived (or any convertible types like +cv-types) case: +</p> +<pre>#include <memory> +using std::auto_ptr; + +struct B {}; +struct D : B {}; + +auto_ptr<D> source(); +int sink(auto_ptr<B>); +int x1 = sink( source() ); // #1 EDG - no suitable copy constructor +</pre> + +<p> +The excellent analysis of conversion operations that was given in the final +auto_ptr proposal +(http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/1997/N1128.pdf) +explicitly specifies this case analysis (case 4). DR #84 makes the analysis +wrong and actually comes to forbid the loophole that was exploited by the +auto_ptr designers. +</p> + +<p> +I didn't encounter any compliant compiler (e.g. EDG, GCC, BCC and VC) that +ever allowed this case. This is probably because it requires 3 user defined +conversions and in fact current compilers conform to DR #84. +</p> + +<p> +I was surprised to discover that the obsolete conversion member actually has +negative impact of the copy initialization base from l-value derived +case:</p> +<pre>auto_ptr<D> dp; +int x2 = sink(dp); // #2 EDG - more than one user-defined conversion applies +</pre> + +<p> +I'm sure that the original intention was allowing this initialization using +the template<class Y> auto_ptr(auto_ptr<Y>& a) constructor (20.4.5.1/4) but +since in this copy initialization it's merely user defined conversion (UDC) +and the obsolete conversion member is UDC with the same rank (for the early +overloading stage) there is an ambiguity between them. +</p> + +<p> +Removing the obsolete member will have impact on code that explicitly +invokes it: +</p> +<pre>int y = sink(source().operator auto_ptr<B>()); +</pre> + +<p> +IMHO no one ever wrote such awkward code and the reasonable workaround for +#1 is: +</p> +<pre>int y = sink( auto_ptr<B>(source()) ); +</pre> + +<p> +I was even more surprised to find out that after removing the obsolete +conversion member the initialization was still ill-formed: +int x3 = sink(dp); // #3 EDG - no suitable copy constructor +</p> + +<p> +This copy initialization semantically requires copy constructor which means +that both template conversion constructor and the auto_ptr_ref conversion +member (20.4.5.3/3) are required which is what was explicitly forbidden in +DR #84. This is a bit amusing case in which removing ambiguity results with +no candidates. +</p> + +<p> +I also found exception safety issue with auto_ptr related to auto_ptr_ref: +</p> +<pre>int f(auto_ptr<B>, std::string); +auto_ptr<B> source2(); + +// string constructor throws while auto_ptr_ref +// "holds" the pointer +int x4 = f(source2(), "xyz"); // #4 +</pre> + +<p> +The theoretic execution sequence that will cause a leak: +</p> +<ol> +<li>call auto_ptr<B>::operator auto_ptr_ref<B>()</li> +<li>call string::string(char const*) and throw</li> +</ol> + +<p> +According to 20.4.5.3/3 and 20.4.5/2 the auto_ptr_ref conversion member +returns auto_ptr_ref<Y> that holds *this and this is another defect since +the type of *this is auto_ptr<X> where X might be different from Y. Several +library vendors (e.g. SGI) implement auto_ptr_ref<Y> with Y* as member which +is much more reasonable. Other vendor implemented auto_ptr_ref as +defectively required and it results with awkward and catastrophic code: +int oops = sink(auto_ptr<B>(source())); // warning recursive on all control +paths +</p> + +<p> +Dave Abrahams noticed that there is no specification saying that +auto_ptr_ref copy constructor can't throw. +</p> + +<p> +My proposal comes to solve all the above issues and significantly simplify +auto_ptr implementation. One of the fundamental requirements from auto_ptr +is that it can be constructed in an intuitive manner (i.e. like ordinary +pointers) but with strict ownership semantics which yield that source +auto_ptr in initialization must be non-const. My idea is to add additional +constructor template with sole propose to generate ill-formed, diagnostic +required, instance for const auto_ptr arguments during instantiation of +declaration. This special constructor will not be instantiated for other +types which is achievable using 14.8.2/2 (SFINAE). Having this constructor +in hand makes the constructor template<class Y> auto_ptr(auto_ptr<Y> const&) +legitimate since the actual argument can't be const yet non const r-value +are acceptable. +</p> + +<p> +This implementation technique makes the "private auxiliary class" +auto_ptr_ref obsolete and I found out that modern C++ compilers (e.g. EDG, +GCC and VC) consume the new implementation as expected and allow all +intuitive initialization and assignment cases while rejecting illegal cases +that involve const auto_ptr arguments. +</p> + +<p>The proposed auto_ptr interface:</p> + +<pre>namespace std { + template<class X> class auto_ptr { + public: + typedef X element_type; + + // 20.4.5.1 construct/copy/destroy: + explicit auto_ptr(X* p=0) throw(); + auto_ptr(auto_ptr&) throw(); + template<class Y> auto_ptr(auto_ptr<Y> const&) throw(); + auto_ptr& operator=(auto_ptr&) throw(); + template<class Y> auto_ptr& operator=(auto_ptr<Y>) throw(); + ~auto_ptr() throw(); + + // 20.4.5.2 members: + X& operator*() const throw(); + X* operator->() const throw(); + X* get() const throw(); + X* release() throw(); + void reset(X* p=0) throw(); + + private: + template<class U> + auto_ptr(U& rhs, typename +unspecified_error_on_const_auto_ptr<U>::type = 0); + }; +} +</pre> + +<p> +One compliant technique to implement the unspecified_error_on_const_auto_ptr +helper class is using additional private auto_ptr member class template like +the following: +</p> +<pre>template<typename T> struct unspecified_error_on_const_auto_ptr; + +template<typename T> +struct unspecified_error_on_const_auto_ptr<auto_ptr<T> const> +{ typedef typename auto_ptr<T>::const_auto_ptr_is_not_allowed type; }; +</pre> + +<p> +There are other techniques to implement this helper class that might work +better for different compliers (i.e. better diagnostics) and therefore I +suggest defining its semantic behavior without mandating any specific +implementation. IMO, and I didn't found any compiler that thinks otherwise, +14.7.1/5 doesn't theoretically defeat the suggested technique but I suggest +verifying this with core language experts. +</p> + +<p><b>Further changes in standard text:</b></p> +<p>Remove section 20.4.5.3</p> + +<p>Change 20.4.5/2 to read something like: +Initializing auto_ptr<X> from const auto_ptr<Y> will result with unspecified +ill-formed declaration that will require unspecified diagnostic.</p> + +<p>Change 20.4.5.1/4,5,6 to read:</p> + +<pre>template<class Y> auto_ptr(auto_ptr<Y> const& a) throw();</pre> +<p> 4 Requires: Y* can be implicitly converted to X*.</p> +<p> 5 Effects: Calls const_cast<auto_ptr<Y>&>(a).release().</p> +<p> 6 Postconditions: *this holds the pointer returned from a.release().</p> + +<p>Change 20.4.5.1/10</p> +<pre>template<class Y> auto_ptr& operator=(auto_ptr<Y> a) throw(); +</pre> <p> -3.6.3 Termination spells out in detail the interleaving of static -destructor calls and calls to functions registered with atexit. To -match this behavior requires intimate cooperation between the code -that calls destructors and the exit/atexit machinery. The former -is tied tightly to the compiler; the latter is a primitive mechanism -inherited from C that traditionally has nothing to do with static -construction and destruction. The benefits of intermixing destructor -calls with atexit handler calls is questionable at best, and <i>very</i> -difficult to get right, particularly when mixing third-party C++ -libraries with different third-party C++ compilers and C libraries -supplied by still other parties. +10 Requires: Y* can be implicitly converted to X*. The expression delete +get() is well formed. </p> +<p>LWG TC DR #127 is obsolete.</p> + <p> -I believe the right thing to do is defer all static destruction -until after all atexit handlers are called. This is a change in -behavior, but one that is likely visible only to perverse test -suites. At the very least, we should <i>permit</i> deferred destruction -even if we don't require it. +Notice that the copy constructor and copy assignment operator should remain +as before and accept non-const auto_ptr& since they have effect on the form +of the implicitly declared copy constructor and copy assignment operator of +class that contains auto_ptr as member per 12.8/5,10: </p> +<pre>struct X { + // implicit X(X&) + // implicit X& operator=(X&) + auto_ptr<D> aptr_; +}; +</pre> -<p><i>[If this is to be changed, it should probably be changed by CWG. - At this point, however, the LWG is leaning toward NAD. Implementing - what the standard says is hard work, but it's not impossible and - most vendors went through that pain years ago. Changing this - behavior would be a user-visible change, and would break at least - one real application.]</i></p> +<p> +In most cases this indicates about sloppy programming but preserves the +current auto_ptr behavior. +</p> + +<p> +Dave Abrahams encouraged me to suggest fallback implementation in case that +my suggestion that involves removing of auto_ptr_ref will not be accepted. +In this case removing the obsolete conversion member to auto_ptr<Y> and +20.4.5.3/4,5 is still required in order to eliminate ambiguity in legal +cases. The two constructors that I suggested will co exist with the current +members but will make auto_ptr_ref obsolete in initialization contexts. +auto_ptr_ref will be effective in assignment contexts as suggested in DR +#127 and I can't see any serious exception safety issues in those cases +(although it's possible to synthesize such). auto_ptr_ref<X> semantics will +have to be revised to say that it strictly holds pointer of type X and not +reference to an auto_ptr for the favor of cases in which auto_ptr_ref<Y> is +constructed from auto_ptr<X> in which X is different from Y (i.e. assignment +from r-value derived to base). +</p> + +<p><i>[Redmond: punt for the moment. We haven't decided yet whether we + want to fix auto_ptr for C++-0x, or remove it and replace it with + move_ptr and unique_ptr.]</i></p> <p><i>[ -Batavia: Send to core with our recommendation that we should permit deferred -destruction but not require it. +Oxford 2007: Recommend NAD. We're just going to deprecate it. It still works for simple use cases +and people know how to deal with it. Going forward <tt>unique_ptr</tt> is the recommended +tool. ]</i></p> <p><i>[ -Howard: The course of action recommended in Batavia would undo LWG -issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3">3</a> and break current code implementing the "phoenix -singleton". Search the net for "phoenix singleton atexit" to get a feel -for the size of the adverse impact this change would have. Below is -sample code which implements the phoenix singleton and would break if -<tt>atexit</tt> is changed in this way: +2007-11-09: Reopened at the request of David Abrahams, Alisdair Meredith and Gabriel Dos Reis. ]</i></p> -<blockquote><pre>#include <cstdlib> -#include <iostream> -#include <type_traits> -#include <new> -class A -{ - bool alive_; - A(const A&); - A& operator=(const A&); -public: - A() : alive_(true) {std::cout << "A()\n";} - ~A() {alive_ = false; std::cout << "~A()\n";} - void use() - { - if (alive_) - std::cout << "A is alive\n"; - else - std::cout << "A is dead\n"; - } -}; -void deallocate_resource(); +<p><b>Proposed resolution:</b></p> +<p> +Change the synopsis in D.9.1 [auto.ptr]: +</p> -// This is the phoenix singleton pattern -A& get_resource(bool create = true) -{ - static std::aligned_storage<sizeof(A), std::alignment_of<A>::value>::type buf; - static A* a; - if (create) - { - if (a != (A*)&buf) - { - a = ::new (&buf) A; - std::atexit(deallocate_resource); - } - } - else - { - a->~A(); - a = (A*)&buf + 1; - } - return *a; -} +<blockquote><pre>namespace std { + <del>template <class Y> struct auto_ptr_ref {};</del> -void deallocate_resource() -{ - get_resource(false); -} + <ins>// exposition only</ins> + <ins>template <class T> struct constant_object;</ins> -void use_A(const char* message) -{ - A& a = get_resource(); - std::cout << "Using A " << message << "\n"; - a.use(); -} + <ins>// exposition only</ins> + <ins>template <class T></ins> + <ins>struct cannot_transfer_ownership_from</ins> + <ins>: constant_object<T> {};</ins> -struct B -{ - ~B() {use_A("from ~B()");} -}; + template <class X> class auto_ptr { + public: + typedef X element_type; -B b; + // D.9.1.1 construct/copy/destroy: + explicit auto_ptr(X* p =0) throw(); + auto_ptr(auto_ptr&) throw(); + template<class Y> auto_ptr(auto_ptr<Y><ins> const</ins>&) throw(); + auto_ptr& operator=(auto_ptr&) throw(); + template<class Y> auto_ptr& operator=(auto_ptr<Y><del>&</del>) throw(); + <del>auto_ptr& operator=(auto_ptr_ref<X> r) throw();</del> + ~auto_ptr() throw(); + + // D.9.1.2 members: + X& operator*() const throw(); + X* operator->() const throw(); + X* get() const throw(); + X* release() throw(); + void reset(X* p =0) throw(); + + <del>// D.9.1.3 conversions:</del> + <del>auto_ptr(auto_ptr_ref<X>) throw();</del> + <del>template<class Y> operator auto_ptr_ref<Y>() throw();</del> + <del>template<class Y> operator auto_ptr<Y>() throw();</del> + + <ins>// exposition only</ins> + <ins>template<class U></ins> + <ins>auto_ptr(U& rhs, typename cannot_transfer_ownership_from<U>::error = 0);</ins> + }; + + template <> class auto_ptr<void> + { + public: + typedef void element_type; + }; -int main() -{ - use_A("from main()"); } </pre></blockquote> <p> -The correct output is: +Remove D.9.1.3 [auto.ptr.conv]. </p> -<blockquote><pre>A() -Using A from main() -A is alive -~A() -A() -Using A from ~B() -A is alive -~A() -</pre></blockquote> +<p> +Change D.9.1 [auto.ptr], p3: +</p> +<blockquote> +The <tt>auto_ptr</tt> provides a semantics of strict ownership. An +<tt>auto_ptr</tt> owns the object it holds a pointer to. Copying an +<tt>auto_ptr</tt> copies the pointer and transfers ownership to the +destination. If more than one <tt>auto_ptr</tt> owns the same object at +the same time the behavior of the program is undefined. <ins>Templates +<tt>constant_object</tt> and <tt>cannot_transfer_ownership_from</tt>, +and the final constructor of <tt>auto_ptr</tt> are for exposition only. +For any types <tt>X</tt> and <tt>Y</tt>, initializing +<tt>auto_ptr<X></tt> from <tt>const auto_ptr<Y></tt> is +ill-formed, diagnostic required.</ins> [<i>Note:</i> The uses of +<tt>auto_ptr</tt> include providing temporary exception-safety for +dynamically allocated memory, passing ownership of dynamically allocated +memory to a function, and returning dynamically allocated memory from a +function. <tt>auto_ptr</tt> does not meet the <tt>CopyConstructible</tt> +and <tt>Assignable</tt> requirements for Standard Library container +elements and thus instantiating a Standard Library container with an +<tt>auto_ptr</tt> results in undefined behavior. <i>-- end note</i>] +</blockquote> +<p> +Change D.9.1.1 [auto.ptr.cons], p5: +</p> -<p><b>Proposed resolution:</b></p> +<blockquote> +<pre>template<class Y> auto_ptr(auto_ptr<Y><ins> const</ins>& a) throw(); +</pre> +<blockquote> +<p> +<i>Requires:</i> <tt>Y*</tt> can be implicitly converted to <tt>X*</tt>. +</p> +<p> +<i>Effects:</i> Calls <ins><tt>const_cast<auto_ptr<Y>&>(</tt></ins><tt>a</tt><ins><tt>)</tt></ins><tt>.release()</tt>. +</p> <p> +<i>Postconditions:</i> <tt>*this</tt> holds the pointer returned from <tt>a.release()</tt>. </p> +</blockquote> +</blockquote> + +<p> +Change D.9.1.1 [auto.ptr.cons], p10: +</p> + +<blockquote> +<pre>template<class Y> auto_ptr& operator=(auto_ptr<Y><del>&</del> a) throw(); +</pre> +<blockquote> +<p> +<i>Requires:</i> <tt>Y*</tt> can be implicitly converted to <tt>X*</tt>. +The expression <tt>delete get()</tt> is well formed. +</p> +<p> +<i>Effects:</i> Calls <tt>reset(a.release())</tt>. +</p> +<p> +<i>Returns:</i> <tt>*this</tt>. +</p> +</blockquote> +</blockquote> + @@ -3710,10 +4341,10 @@ A is alive <hr> <h3><a name="471"></a>471. result of what() implementation-defined</h3> -<p><b>Section:</b> 18.6.1 [type.info] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> +<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> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-28</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#type.info">issues</a> in [type.info].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> +<p><b>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.exception] specifies the following:</p> @@ -3757,6 +4388,36 @@ Batavia: Howard provided wording. ]</i></p> +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +Eric concerned this is unimplementable, due to nothrow guarantees. +Suggested implementation would involve reference counting. +</p> +<p> +Is the implied reference counting subtle enough to call out a note on +implementation? Probably not. +</p> +<p> +If reference counting required, could we tighten specification further +to require same pointer value? Probably an overspecification, especially +if exception classes defer evalutation of final string to calls to +what(). +</p> +<p> +Remember issue moved open and not resolved at Batavia, but cannot +remember who objected to canvas a disenting opinion - please speak up if +you disagree while reading these minutes! +</p> +<p> +Move to Ready as we are accepting words unmodified. +</p> +</blockquote> + <p><b>Proposed resolution:</b></p> @@ -3980,6 +4641,7 @@ wording (I believe) x,a,b,c could be written to in any order. <h3><a name="492"></a>492. Invalid iterator arithmetic expressions</h3> <p><b>Section:</b> 23 [containers], 24 [iterators], 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Thomas Mang <b>Date:</b> 2004-12-12</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> <p><b>Discussion:</b></p> @@ -4142,6 +4804,16 @@ See DR 237. The resolution could then also read "Linear in last - first". </p> +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Keep open and ask Bill to provide wording. +</blockquote> + + <p><b>Proposed resolution:</b></p> <p><i>[Lillehammer: Minor issue, but real. We have a blanket statement @@ -4388,11 +5060,10 @@ 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#Review">Review</a> +<p><b>Section:</b> 23.1.3 [unord.req], TR1 6.3.1 [tr.unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</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#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> Issue 371 deals with stability of multiset/multimap under insert and erase @@ -4459,6 +5130,8 @@ preserves the relative ordering of equivalent elements.</ins></p> <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> <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>Discussion:</b></p> <p> @@ -4477,10 +5150,80 @@ Toronto: Howard to provide wording (really this time). ]</i></p> +<p><i>[ +Bellevue: Alisdair provided wording. +]</i></p> + + <p><b>Proposed resolution:</b></p> +<p> +Add these signatures to 20.3 [tuple] +</p> + +<blockquote><pre>template <class... Types> + void swap(tuple<Types...>& x, tuple<Types...>& y); +template <class... Types> + void swap(tuple<Types...>&& x, tuple<Types...>& y); +template <class... Types> + void swap(tuple<Types...>& x, tuple<Types...>&& y); +</pre></blockquote> + +<p> +Add this signature to 20.3.1 [tuple.tuple] +</p> + +<blockquote><pre>void swap(tuple&&); +</pre></blockquote> + +<p> +Add the following two sections to the end of the tuple clauses +</p> + +<blockquote> +<p> +20.3.1.7 tuple swap [tuple.swap] +</p> + +<pre>void swap(tuple&& rhs); +</pre> + +<blockquote> +<p> +<i>Requires:</i> Each type in <tt>Types</tt> shall be <tt>Swappable</tt>. +</p> +<p> +<i>Effects:</i> Calls <tt>swap</tt> for each element in <tt>*this</tt> and its corresponding element +in <tt>rhs</tt>. +</p> +<p> +<i>Throws:</i> Nothing, unless one of the element-wise <tt>swap</tt> calls throw an +exception. +</p> +</blockquote> + +<p> +20.3.1.8 tuple specialized algorithms [tuple.special] +</p> + +<pre>template <class... Types> + void swap(tuple<Types...>& x, tuple<Types...>& y); +template <class... Types> + void swap(tuple<Types...>&& x, tuple<Types...>& y); +template <class... Types> + void swap(tuple<Types...>& x, tuple<Types...>&& y); +</pre> + +<blockquote> +<p> +<i>Effects:</i> x.swap(y) +</p> +</blockquote> +</blockquote> + + @@ -4619,154 +5362,10 @@ Pete: Possible general problem with case insensitive ranges. <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#Open">Open</a> - <b>Submitter:</b> Peter Dimov <b>Date:</b> 2005-10-01</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> -<p><b>Discussion:</b></p> -<p> -The original bind proposal gives the guarantee that tr1::bind(f, t1, -..., tN) does not throw when the copy constructors of f, t1, ..., tN -don't. -</p> - -<p> -This guarantee is not present in the final version of TR1. -</p> - -<p> -I'm pretty certain that we never removed it on purpose. Editorial omission? :-) -</p> - -<p><i>[ -Berlin: not quite editorial, needs proposed wording. -]</i></p> - -<p><i>[ -Batavia: Doug to translate wording to variadic templates. -]</i></p> - - -<p><i>[ -Toronto: We agree but aren't quite happy with the wording. The "t"'s no -longer refer to anything. Alan to provide improved wording. -]</i></p> - - - - -<p><b>Proposed resolution:</b></p> -<p> -In 20.5.10.1.3 [lib.func.bind.bind] ([tr.func.bind.bind]), add a new paragraph after p2: -</p> -<blockquote><p> -<i>Throws:</i> Nothing unless one of the copy constructors of <tt>f, t1, t2, ..., tN</tt> -throws an exception. -</p></blockquote> - -<p> -Add a new paragraph after p4: -</p> -<blockquote><p> -<i>Throws:</i> nothing unless one of the copy constructors of <tt>f, t1, t2, ..., tN</tt> -throws an exception. -</p></blockquote> - - - - - -<hr> -<h3><a name="529"></a>529. The standard encourages redundant and confusing preconditions</h3> -<p><b>Section:</b> 17.4.3.8 [res.on.required] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> - <b>Submitter:</b> David Abrahams <b>Date:</b> 2005-10-25</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> -<p><b>Discussion:</b></p> -<p> -17.4.3.8/1 says: -</p> - -<blockquote><p> -Violation of the preconditions specified in a function's -Required behavior: paragraph results in undefined behavior unless the -function's Throws: paragraph specifies throwing an exception when the -precondition is violated. -</p></blockquote> - -<p> -This implies that a precondition violation can lead to defined -behavior. That conflicts with the only reasonable definition of -precondition: that a violation leads to undefined behavior. Any other -definition muddies the waters when it comes to analyzing program -correctness, because precondition violations may be routinely done in -correct code (e.g. you can use std::vector::at with the full -expectation that you'll get an exception when your index is out of -range, catch the exception, and continue). Not only is it a bad -example to set, but it encourages needless complication and redundancy -in the standard. For example: -</p> - -<blockquote><pre> 21 Strings library - 21.3.3 basic_string capacity - - void resize(size_type n, charT c); - - 5 Requires: n <= max_size() - 6 Throws: length_error if n > max_size(). - 7 Effects: Alters the length of the string designated by *this as follows: -</pre></blockquote> - -<p> -The Requires clause is entirely redundant and can be dropped. We -could make that simplifying change (and many others like it) even -without changing 17.4.3.8/1; the wording there just seems to encourage -the redundant and error-prone Requires: clause. -</p> - -<p><i>[ -Batavia: Alan and Pete to work. -]</i></p> - - - -<p><b>Proposed resolution:</b></p> -<p> -1. Change 17.4.3.8/1 to read: -</p> - -<blockquote><p> -Violation of the preconditions specified in a function's -<i>Required behavior:</i> paragraph results in undefined behavior -<del>unless the function's <i>Throws:</i> paragraph specifies throwing -an exception when the precondition is violated</del>. -</p></blockquote> - -<p> -2. Go through and remove redundant Requires: clauses. Specifics to be - provided by Dave A. -</p> - -<p><i>[ -Berlin: The LWG requests a detailed survey of part 2 of the proposed resolution. -]</i></p> - - -<p><i>[ -Alan provided the survey -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2121.html">N2121</a>. -]</i></p> - - - - - - - -<hr> <h3><a name="539"></a>539. partial_sum and adjacent_difference should mention requirements</h3> -<p><b>Section:</b> 26.6.3 [partial.sum] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> +<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> <b>Submitter:</b> Marc Schoolderman <b>Date:</b> 2006-02-06</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> +<p><b>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> There are some problems in the definition of partial_sum and @@ -4912,12 +5511,38 @@ adding signatures to allow user to specify "accumulator". ]</i></p> +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +The intent of the algorithms is to perform their calculations using the type of the input iterator. +Proposed wording provided. +</blockquote> <p><b>Proposed resolution:</b></p> <p> +Add to section 26.6.3 [partial.sum] paragraph 4 the following two sentences: </p> +<blockquote> +The type of <tt>*first</tt> shall meet the requirements of <tt>CopyConstructible</tt>? +(20.1.3?) and <tt>Assignable</tt> (23.1?) types. The result of <tt>*i + *(i+1)</tt> or +<tt>binary_op(*i, *(i+1))</tt> shall be convertible to this type. +</blockquote> + +<p> +Add to section 26.6.4 [adjacent.difference] paragraph 2 the following sentence: +</p> + +<blockquote> +The type of <tt>*first</tt> shall meet the requirements of <tt>CopyConstructible</tt>? +(20.1.3) and <tt>Assignable</tt> (23.1) types. +</blockquote> + + @@ -4951,11 +5576,11 @@ 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#Open">Open</a> +<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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#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> Assuming we adopt the @@ -5015,52 +5640,73 @@ resolution") <p><i>[ -</i></p><p> -<i>Howard, post Kona: -</i></p> +<p> +Howard, post Kona: +</p> <blockquote> <p> -<i>Unfortunately I strongly disagree with a part of the resolution +Unfortunately I strongly disagree with a part of the resolution from Kona. I am moving from New to Open instead of to Review because I do not believe we have consensus on the intent of the resolution. -</i></p> +</p> <p> -<i>This issue does not include <tt>ldexp</tt>, <tt>scalbln</tt>, and <tt>scalbn</tt> because +This issue does not include <tt>ldexp</tt>, <tt>scalbln</tt>, and <tt>scalbn</tt> because the second integral parameter in each of these signatures (from C99) is <b>not</b> a <i>generic parameter</i> according to C99 7.22p2. The corresponding C++ overloads are intended (as far as I know) to correspond directly to C99's definition of <i>generic parameter</i>. -</i></p> +</p> <p> -<i>For similar reasons, I do not believe that the second <tt>long double</tt> parameter of +For similar reasons, I do not believe that the second <tt>long double</tt> parameter of <tt>nexttoward</tt>, nor the return type of this function, is in error. I believe the correct signature is: -</i></p> +</p> <blockquote> -<pre><i>float nexttoward(float, long double); -</i></pre> +<pre>float nexttoward(float, long double); +</pre> </blockquote> <p> -<i>which is what both the C++0X working paper and C99 state (as far as I currently understand). -</i></p> +which is what both the C++0X working paper and C99 state (as far as I currently understand). +</p> <p> -<i>This is really <b>only</b> about <tt>pow(float, int)</tt>. And this is because C++98 took one +This is really <b>only</b> about <tt>pow(float, int)</tt>. And this is because C++98 took one route (with <tt>pow</tt> only) and C99 took another (with many math functions in <tt><tgmath.h></tt>. The proposed resolution basically says: C++98 got it wrong and C99 got it right; let's go with C99. -</i></p> +</p> </blockquote> -<i>]</i> +]</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] +Change 26.7 [c.math] p10: </p> -<blockquote><pre>float pow(float, float); -<del>float</del> <ins>double</ins> pow(float, int); +<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> @@ -5129,405 +5775,9 @@ destroyed. <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#Open">Open</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#Open">Open</a> status.</p> -<p><b>Discussion:</b></p> -<p> -I'm seeing a problem with such overloads: when, _Longlong == intmax_t == -long long we end up, essentially, with the same arguments and different -return types (lldiv_t and imaxdiv_t, respectively). Similar issue with -abs(_Longlong) and abs(intmax_t), of course. -</p> -<p> -Comparing sections 8.25 and 8.11, I see an important difference, -however: 8.25.3 and 8.25.4 carefully describe div and abs for _Longlong -types (rightfully, because not moved over directly from C99), whereas -there is no equivalent in 8.11: the abs and div overloads for intmax_t -types appear only in the synopsis and are not described anywhere, in -particular no mention in 8.11.2 (at variance with 8.25.2). -</p> -<p> -I'm wondering whether we really, really, want div and abs for intmax_t... -</p> - - - -<p><b>Proposed resolution:</b></p> - - - -<p><i>[ -Portland: no consensus. -]</i></p> - - -<p><b>Rationale:</b></p> -<p><i>[ -Batavia, Bill: The <tt><cstdint></tt> synopsis in TR1 8.11.1 [tr.c99.cinttypes.syn] contains: -]</i></p> - -<blockquote><pre>intmax_t imaxabs(intmax_t i); -intmax_t abs(intmax_t i); - -imaxdiv_t imaxdiv(intmax_t numer, intmax_t denom); -imaxdiv_t div(intmax_t numer, intmax_t denom); -</pre></blockquote> - -<p><i>[ -and in TR1 8.11.2 [tr.c99.cinttypes.def]: -]</i></p> - - -<blockquote><p> -The header defines all functions, types, and macros the same as C99 -subclause 7.8. -</p></blockquote> - -<p><i>[ -This is as much definition as we give for most other C99 functions, -so nothing need change. We might, however, choose to add the footnote: -]</i></p> - - -<blockquote><p> -[<i>Note:</i> These overloads for <tt>abs</tt> and <tt>div</tt> may well be equivalent to -those that take <tt>long long</tt> arguments. If so, the implementation is -responsible for avoiding conflicting declarations. -- <i>end note</i>] -</p></blockquote> - - - - - - -<hr> -<h3><a name="561"></a>561. inserter overly generic</h3> -<p><b>Section:</b> 24.4.2.6.5 [inserter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-02-21</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -The declaration of <tt>std::inserter</tt> is: -</p> - -<blockquote><pre>template <class Container, class Iterator> -insert_iterator<Container> -inserter(Container& x, Iterator i); -</pre></blockquote> - -<p> -The template parameter <tt>Iterator</tt> in this function is completely unrelated -to the template parameter <tt>Container</tt> when it doesn't need to be. This -causes the code to be overly generic. That is, any type at all can be deduced -as <tt>Iterator</tt>, whether or not it makes sense. Now the same is true of -<tt>Container</tt>. However, for every free (unconstrained) template parameter -one has in a signature, the opportunity for a mistaken binding grows geometrically. -</p> - -<p> -It would be much better if <tt>inserter</tt> had the following signature instead: -</p> - -<blockquote><pre>template <class Container> -insert_iterator<Container> -inserter(Container& x, typename Container::iterator i); -</pre></blockquote> - -<p> -Now there is only one free template parameter. And the second argument to -<tt>inserter</tt> must be implicitly convertible to the container's iterator, -else the call will not be a viable overload (allowing other functions in the -overload set to take precedence). Furthermore, the first parameter must have a -nested type named <tt>iterator</tt>, or again the binding to <tt>std::inserter</tt> -is not viable. Contrast this with the current situation -where any type can bind to <tt>Container</tt> or <tt>Iterator</tt> and those -types need not be anything closely related to containers or iterators. -</p> - -<p> -This can adversely impact well written code. Consider: -</p> - -<blockquote><pre>#include <iterator> -#include <string> - -namespace my -{ - -template <class String> -struct my_type {}; - -struct my_container -{ -template <class String> -void push_back(const my_type<String>&); -}; - -template <class String> -void inserter(const my_type<String>& m, my_container& c) {c.push_back(m);} - -} // my - -int main() -{ - my::my_container c; - my::my_type<std::string> m; - inserter(m, c); -} -</pre></blockquote> - -<p> -Today this code fails because the call to <tt>inserter</tt> binds to -<tt>std::inserter</tt> instead of to <tt>my::inserter</tt>. However with the -proposed change <tt>std::inserter</tt> will no longer be a viable function which -leaves only <tt>my::inserter</tt> in the overload resolution set. Everything -works as the client intends. -</p> - -<p> -To make matters a little more insidious, the above example works today if you -simply change the first argument to an rvalue: -</p> - -<blockquote><pre> inserter(my::my_type(), c); -</pre></blockquote> - -<p> -It will also work if instantiated with some string type other than -<tt>std::string</tt> (or any other <tt>std</tt> type). It will also work if -<tt><iterator></tt> happens to not get included. -</p> - -<p> -And it will fail again for such inocuous reaons as <tt>my_type</tt> or -<tt>my_container</tt> privately deriving from any <tt>std</tt> type. -</p> - -<p> -It seems unfortunate that such simple changes in the client's code can result -in such radically differing behavior. -</p> - - - -<p><b>Proposed resolution:</b></p> -<p> -Change 24.2: -</p> - -<blockquote><p> -<b>24.2 Header</b> <tt><iterator></tt> <b>synopsis</b> -</p> -<blockquote><pre>... -template <class Container<del>, class Iterator</del>> - insert_iterator<Container> inserter(Container& x, <del>Iterator</del> <ins>typename Container::iterator</ins> i); -... -</pre></blockquote> -</blockquote> - -<p> -Change 24.4.2.5: -</p> - -<blockquote><p> -<b>24.4.2.5 Class template</b> <tt>insert_iterator</tt></p> -<blockquote><pre>... -template <class Container<del>, class Iterator</del>> - insert_iterator<Container> inserter(Container& x, <del>Iterator</del> <ins>typename Container::iterator</ins> i); -... -</pre></blockquote> -</blockquote> - -<p> -Change 24.4.2.6.5: -</p> - -<blockquote> -<p> -<b>24.4.2.6.5</b> <tt>inserter</tt> -</p> -<pre>template <class Container<del>, class Inserter</del>> - insert_iterator<Container> inserter(Container& x, <del>Inserter</del> <ins>typename Container::iterator</ins> i); -</pre> -<blockquote><p> --1- <i>Returns:</i> <tt>insert_iterator<Container>(x,<del>typename Container::iterator(</del>i<del>)</del>)</tt>. -</p></blockquote> -</blockquote> - - - -<p><i>[ -Kona (2007): This issue will probably be addressed as a part of the -concepts overhaul of the library anyway, but the proposed resolution is -correct in the absence of concepts. Proposed Disposition: Ready -]</i></p> - - - - - -<hr> -<h3><a name="562"></a>562. stringbuf ctor inefficient</h3> -<p><b>Section:</b> 27.7 [string.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.streams">issues</a> in [string.streams].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> - <p> - -For better efficiency, the requirement on the stringbuf ctor that -takes a string argument should be loosened up to let it set -<code>epptr()</code> beyond just one past the last initialized -character just like <code>overflow()</code> has been changed to be -allowed to do (see issue 432). That way the first call to -<code>sputc()</code> on an object won't necessarily cause a call to -<code>overflow</code>. The corresponding change should be made to the -string overload of the <code>str()</code> member function. - - </p> - - -<p><b>Proposed resolution:</b></p> - <p> - -Change 27.7.1.1, p3 of the Working Draft, N1804, as follows: - - </p> - -<blockquote><pre>explicit basic_stringbuf(const basic_string<charT,traits,Allocator>& <i>s<del>tr</del></i>, - ios_base::openmode <i>which</i> = ios_base::in | ios_base::out); -</pre> - -<p> --3- <i>Effects:</i> Constructs an object of class <tt>basic_stringbuf</tt>, -initializing the base class with <tt>basic_streambuf()</tt> -(27.5.2.1), and initializing <tt><i>mode</i></tt> with <tt><i>which</i></tt>. -Then <ins>calls <tt>str(<i>s</i>)</tt>.</ins> <del>copies the content of -<i>str</i> into the <tt>basic_stringbuf</tt> underlying character -sequence. If <tt><i>which</i> & ios_base::out</tt> is true, initializes the -output sequence such that <tt>pbase()</tt> points to the first underlying -character, <tt>epptr()</tt> points one past the last underlying character, and -<tt>pptr()</tt> is equal to <tt>epptr()</tt> if <tt><i>which</i> & ios_base::ate</tt> -is true, otherwise <tt>pptr()</tt> is equal to <tt>pbase()</tt>. If -<tt>which & ios_base::in</tt> is true, initializes the input sequence such -that <tt>eback()</tt> and <tt>gptr()</tt> point to the first underlying -character and <tt>egptr()</tt> points one past the last underlying character.</del> -</p> -</blockquote> - - <p> - -Change the Effects clause of the <code>str()</code> in 27.7.1.2, p2 to -read: - - </p> -<blockquote> -<p> --2- <i>Effects:</i> Copies the content<ins>s</ins> of <tt><i>s</i></tt> into the -<tt>basic_stringbuf</tt> underlying character sequence <ins>and -initializes the input and output sequences according to <tt><i>mode</i></tt></ins>. -<del>If -<tt><i>mode</i> & ios_base::out</tt> is true, initializes the output -sequence such that <tt>pbase()</tt> points to the first underlying character, -<tt>epptr()</tt> points one past the last underlying character, and <tt>pptr()</tt> -is equal to <tt>epptr()</tt> if <tt><i>mode</i> & ios_base::in</tt> -is true, otherwise <tt>pptr()</tt> is equal to <tt>pbase()</tt>. If -<tt>mode & ios_base::in</tt> is true, initializes the input sequence -such that <tt>eback()</tt> and <tt>gptr()</tt> point to the first underlying -character and <tt>egptr()</tt> points one past the last underlying character.</del> -</p> - - <p> - -<ins>-3- <i>Postconditions:</i> If <code>mode & ios_base::out</code> is true, -<code>pbase()</code> points to the first underlying character and -<code>(epptr() >= pbase() + s.size())</code> holds; in addition, if -<code>mode & ios_base::in</code> is true, <code>(pptr() == pbase() -+ s.data())</code> holds, otherwise <code>(pptr() == pbase())</code> -is true. If <code>mode & ios_base::in</code> is true, -<code>eback()</code> points to the first underlying character, and -<code>(gptr() == eback())</code> and <code>(egptr() == eback() + -s.size())</code> hold.</ins> - - </p> -</blockquote> - - -<p><i>[ -Kona (2007) Moved to Ready. -]</i></p> - - - - - -<hr> -<h3><a name="563"></a>563. stringbuf seeking from end</h3> -<p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#stringbuf.virtuals">active issues</a> in [stringbuf.virtuals].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -According to Table 92 (unchanged by issue 432), when <code>(way == -end)</code> the <code>newoff</code> value in out mode is computed as -the difference between <code>epptr()</code> and <code>pbase()</code>. -</p> - <p> - -This value isn't meaningful unless the value of <code>epptr()</code> -can be precisely controlled by a program. That used to be possible -until we accepted the resolution of issue 432, but since then the -requirements on <code>overflow()</code> have been relaxed to allow it -to make more than 1 write position available (i.e., by setting -<code>epptr()</code> to some unspecified value past -<code>pptr()</code>). So after the first call to -<code>overflow()</code> positioning the output sequence relative to -end will have unspecified results. - - </p> - <p> - -In addition, in <code>in|out</code> mode, since <code>(egptr() == -epptr())</code> need not hold, there are two different possible values -for <code>newoff</code>: <code>epptr() - pbase()</code> and -<code>egptr() - eback()</code>. - - </p> - - -<p><b>Proposed resolution:</b></p> - <p> - -Change the <code>newoff</code> column in the last row of Table 94 to -read: - - </p> -<blockquote><p> - -the <del>end</del> <ins>high mark</ins> pointer minus the beginning -pointer (<code><del>xend</del> <ins>high_mark</ins> - xbeg</code>). - -</p></blockquote> - - -<p><i>[ -Kona (2007) Moved to Ready. -]</i></p> - - - - - -<hr> <h3><a name="564"></a>564. stringbuf seekpos underspecified</h3> <p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#stringbuf.virtuals">active issues</a> in [stringbuf.virtuals].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> <p><b>Discussion:</b></p> @@ -5659,74 +5909,6 @@ proposed wording doesn't accomplish that. Proposed Disposition: Open <hr> -<h3><a name="567"></a>567. streambuf inserter and extractor should be unformatted</h3> -<p><b>Section:</b> 27.6 [iostream.format] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-25</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iostream.format">active issues</a> in [iostream.format].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.format">issues</a> in [iostream.format].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> - <p> - -Issue 60 explicitly made the extractor and inserter operators that -take a <tt>basic_streambuf*</tt> argument formatted input and output -functions, respectively. I believe that's wrong, certainly in the -case of the extractor, since formatted functions begin by extracting -and discarding whitespace. The extractor should not discard any -characters. - - </p> - - -<p><b>Proposed resolution:</b></p> - <p> - -I propose to change each operator to behave as unformatted input and -output function, respectively. The changes below are relative to the -working draft document number N1804. - - </p> - <p> - -Specifically, change 27.6.1.2.3, p14 as follows: - - </p> - - <blockquote> - <p> - -<i>Effects</i>: Behaves as a<ins>n un</ins>formatted input function -(as described in <del>27.6.1.2.1</del><ins>27.6.1.3, paragraph -1</ins>). - - </p> - </blockquote> - <p> - -And change 27.6.2.5.3, p7 as follows: - - </p> - - <blockquote> - <p> - -<i>Effects</i>: Behaves as a<ins>n un</ins>formatted output function -(as described in <del>27.6.2.5.1</del><ins>27.6.2.6, paragraph -1</ins>). - - </p> - </blockquote> - - -<p><i>[ -Kona (2007): Proposed Disposition: Ready -]</i></p> - - - - - -<hr> <h3><a name="568"></a>568. log2 overloads missing</h3> <p><b>Section:</b> TR1 8.16.4 [tr.c99.cmath.over] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-03-07</p> @@ -5754,6 +5936,8 @@ Add <tt>log2</tt> to the list of functions in TR1 8.16.4 [tr.c99.cmath.over] p1. <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> @@ -5780,6 +5964,27 @@ 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> @@ -5843,10 +6048,10 @@ 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#Review">Review</a> +<p><b>Section:</b> 27.3 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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#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> lib.iostream.objects requires that the standard stream objects are never @@ -5894,81 +6099,6 @@ Disposition: Review <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#Open">Open</a> - <b>Submitter:</b> Joaquín M López Muñoz <b>Date:</b> 2006-06-13</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> -<p><b>Discussion:</b></p> -<p> -See -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2023.pdf">N2023</a> -for full discussion. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Option 1: -</p> - -<p> -The problem can be eliminated by omitting the requirement that <tt>a.erase(q)</tt> return an -iterator. This is, however, in contrast with the equivalent requirements for other -standard containers. -</p> - -<p> -Option 2: -</p> - -<p> -<tt>a.erase(q)</tt> can be made to compute the next iterator only when explicitly requested: -the technique consists in returning a proxy object implicitly convertible to <tt>iterator</tt>, so -that -</p> - -<blockquote><pre>iterator q1=a.erase(q); -</pre></blockquote> - -<p> -works as expected, while -</p> - -<blockquote><pre>a.erase(q); -</pre></blockquote> - -<p> -does not ever invoke the conversion-to-iterator operator, thus avoiding the associated -computation. To allow this technique, some sections of TR1 along the line "return value -is an iterator..." should be changed to "return value is an unspecified object implicitly -convertible to an iterator..." Although this trick is expected to work transparently, it can -have some collateral effects when the expression <tt>a.erase(q)</tt> is used inside generic -code. -</p> - - - -<p><b>Rationale:</b></p> -<p> -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2023.pdf">N2023</a> -was discussed in Portland and the consensus was that there appears to be -no need for either change proposed in the paper. The consensus opinion -was that since the iterator could serve as its own proxy, there appears -to be no need for the change. In general, "converts to" is undesirable -because it interferes with template matching. -</p> - -<p> -Post Toronto: There does not at this time appear to be consensus with the Portland consensus. -</p> - - - - - -<hr> <h3><a name="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> @@ -6017,92 +6147,80 @@ pre-Oxford: Martin provided wording. <p><b>Proposed resolution:</b></p> - <p> + <p> Specifically, I propose to change 23.1 [container.requirements], p9 as follows: - </p> - <blockquote> + </p> + <blockquote> <p> --9- Copy constructors for all container types defined in this clause -<ins>that are parametrized on <code>Allocator</code></ins> copy -<del>an</del><ins>the</ins> allocator argument from their respective +-9- Copy constructors for all container types defined in this clause +<ins>that are parametrized on <code>Allocator</code></ins> copy +<del>an</del><ins>the</ins> allocator argument from their respective first parameters. -All other constructors for these container types take a<del>n</del> -<ins>const</ins> <code>Allocator&</code> argument (20.1.6), an +All other constructors for these container types take a<del>n</del> +<ins>const</ins> <code>Allocator&</code> argument (20.1.6), an allocator whose <code>value_type</code> is the same as the container's <code>value_type</code>. -A copy of this argument <del>is</del><ins>shall be</ins> used for any -memory allocation <ins> and deallocation</ins> performed<del>,</del> -by these constructors and by all member functions<del>,</del> during -the lifetime of each container object. <ins>Allocation shall be -performed "as if" by calling the <code>allocate()</code> member -function on a copy of the allocator object of the appropriate type -<sup>New Footnote)</sup>, and deallocation "as if" by calling -<code>deallocate()</code> on a copy of the same allocator object of +A copy of this argument <del>is</del><ins>shall be</ins> used for any +memory allocation <ins> and deallocation</ins> performed<del>,</del> +by these constructors and by all member functions<del>,</del> during +the lifetime of each container object. <ins>Allocation shall be +performed "as if" by calling the <code>allocate()</code> member +function on a copy of the allocator object of the appropriate type +<sup>New Footnote)</sup>, and deallocation "as if" by calling +<code>deallocate()</code> on a copy of the same allocator object of the corresponding type.</ins> -<ins>A copy of this argument shall also be used to construct and -destroy objects whose lifetime is managed by the container, including -but not limited to those of the container's <code>value_type</code>, -and to obtain their address. All objects residing in storage -allocated by a container's allocator shall be constructed "as if" by -calling the <code>construct()</code> member function on a copy of the -allocator object of the appropriate type. The same objects shall be -destroyed "as if" by calling <code>destroy()</code> on a copy of the -same allocator object of the same type. The address of such objects +<ins>A copy of this argument shall also be used to construct and +destroy objects whose lifetime is managed by the container, including +but not limited to those of the container's <code>value_type</code>, +and to obtain their address. All objects residing in storage +allocated by a container's allocator shall be constructed "as if" by +calling the <code>construct()</code> member function on a copy of the +allocator object of the appropriate type. The same objects shall be +destroyed "as if" by calling <code>destroy()</code> on a copy of the +same allocator object of the same type. The address of such objects shall be obtained "as if" by calling the <code>address()</code> member -function on a copy of the allocator object of the appropriate +function on a copy of the allocator object of the appropriate type.</ins> -<ins>Finally, a copy of this argument shall be used by its container -object to determine the maximum number of objects of the container's -<code>value_type</code> the container may store at the same time. The -container member function <code>max_size()</code> -obtains this number -from the - value - returned by - a call - to +<ins>Finally, a copy of this argument shall be used by its container +object to determine the maximum number of objects of the container's +<code>value_type</code> the container may store at the same time. The +container member function <code>max_size()</code> obtains this number +from the value returned by a call to <code>get_allocator().max_size()</code>.</ins> -In all container types defined in this clause <ins>that are -parametrized on <code>Allocator</code></ins>, the member -<code>get_allocator()</code> returns - a copy - of the -<code>Allocator</code> object - used to - construct the +In all container types defined in this clause <ins>that are +parametrized on <code>Allocator</code></ins>, the member +<code>get_allocator()</code> returns a copy of the +<code>Allocator</code> object used to construct the container.<sup>258)</sup> </p> <p> -New Footnote: This type may be different from <code>Allocator</code>: -it may be - derived from - <code>Allocator</code> via -<code>Allocator::rebind<U>::other</code> for the appropriate +New Footnote: This type may be different from <code>Allocator</code>: +it may be derived from <code>Allocator</code> via +<code>Allocator::rebind<U>::other</code> for the appropriate type <code>U</code>. </p> - </blockquote> - <p> + </blockquote> + <p> + The proposed wording seems cumbersome but I couldn't think of a better -way to describe the - requirement that containers use - their -<code>Allocator</code> to manage only objects (regardless of their -type) that persist over their lifetimes and not, for example, -temporaries created on the stack. That is, containers shouldn't be -required to call <code>Allocator::construct(Allocator::allocate(1), -elem)</code> just to construct a temporary copy of an element, or -<code>Allocator::destroy(Allocator::address(temp), 1)</code> to +way to describe the requirement that containers use their +<code>Allocator</code> to manage only objects (regardless of their +type) that persist over their lifetimes and not, for example, +temporaries created on the stack. That is, containers shouldn't be +required to call <code>Allocator::construct(Allocator::allocate(1), +elem)</code> just to construct a temporary copy of an element, or +<code>Allocator::destroy(Allocator::address(temp), 1)</code> to destroy temporaries. - </p> + </p> <p><i>[ @@ -6120,74 +6238,9 @@ post Oxford: This would be rendered NAD Editorial by acceptance of <hr> -<h3><a name="581"></a>581. <code>flush()</code> not unformatted function</h3> -<p><b>Section:</b> 27.6.2.7 [ostream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-14</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.unformatted">issues</a> in [ostream.unformatted].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> - <p> - -The resolution of issue 60 changed <code>basic_ostream::flush()</code> -so as not to require it to behave as an unformatted output function. -That has at least two in my opinion problematic consequences: - - </p> - <p> - -First, <code>flush()</code> now calls <code>rdbuf()->pubsync()</code> -unconditionally, without regard to the state of the stream. I can't -think of any reason why <code>flush()</code> should behave differently -from the vast majority of stream functions in this respect. - - </p> - <p> - -Second, <code>flush()</code> is not required to catch exceptions from -<code>pubsync()</code> or set <code>badbit</code> in response to such -events. That doesn't seem right either, as most other stream functions -do so. - - </p> - - - <p><b>Proposed resolution:</b></p> - <p> - -I propose to revert the resolution of issue 60 with respect to -<code>flush()</code>. Specifically, I propose to change 27.6.2.6, p7 -as follows: - - </p> - -<p> -Effects: <ins>Behaves as an unformatted output function (as described -in 27.6.2.6, paragraph 1). </ins>If <code>rdbuf()</code> is not a null -pointer, <ins>constructs a sentry object. If this object returns -<code>true</code> when converted to a value of type bool the function -</ins>calls <code>rdbuf()->pubsync()</code>. If that function returns --1 calls <code>setstate(badbit)</code> (which may throw -<code>ios_base::failure</code> (27.4.4.3)). <ins>Otherwise, if the -sentry object returns <code>false</code>, does nothing.</ins><del>Does -not behave as an unformatted output function (as described in -27.6.2.6, paragraph 1).</del> -</p> - - - -<p><i>[ -Kona (2007): Proposed Disposition: Ready -]</i></p> - - - - - -<hr> <h3><a name="582"></a>582. specialized algorithms and volatile storage</h3> -<p><b>Section:</b> 20.6.4.1 [uninitialized.copy] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> +<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> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-14</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#uninitialized.copy">active issues</a> in [uninitialized.copy].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#uninitialized.copy">issues</a> in [uninitialized.copy].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> <p><b>Discussion:</b></p> @@ -6587,6 +6640,8 @@ requirements? Alisdair will prepare a paper. Proposed Disposition: Open <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> @@ -6691,6 +6746,14 @@ 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> @@ -6699,19 +6762,19 @@ is already provided by the corresponding overloads of abs(). Change the synopsis in 26.3.1 [complex.synopsis]: </p> -<blockquote><pre>template<class T> <del>complex<</del>T<del>></del> fabs(const complex<T>&); +<blockquote><pre><del>template<class T> complex<T> fabs(const complex<T>&);</del> </pre></blockquote> <p> -Change 26.3.7 [complex.value.ops], p7: +Remove 26.3.7 [complex.value.ops], p7: </p> <blockquote> -<pre>template<class T> <del>complex<</del>T<del>></del> fabs(const complex<T>& <i>x</i>); +<pre><del>template<class T> complex<T> fabs(const complex<T>& <i>x</i>);</del> </pre> <blockquote> <p> --7- <i>Effects:</i> Behaves the same as C99 function <tt>cabs</tt>, defined in subclause 7.3.8.1. +<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> @@ -6729,11 +6792,11 @@ Proposed Disposition: Ready <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#Review">Review</a> +<p><b>Section:</b> 27.8.1.4 [filebuf.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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#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> In testing 27.8.1.4 [filebuf.members], Table 112 (in the latest N2009 draft), we invoke @@ -6916,7 +6979,8 @@ better than the other. <p> Robert comments: </p> -<p>In general, a library of arithmetic types cannot exactly emulate the +<p> +In general, a library of arithmetic types cannot exactly emulate the behavior of the intrinsic numeric types. There are several ways to tell whether an implementation of the decimal types uses compiler intrinisics or a library. For example: @@ -7014,21 +7078,21 @@ Redmond: We prefer explicit conversions for narrowing and implicit for widening. <hr> -<h3><a name="612"></a>612. numeric_limits::is_modulo insufficently defined</h3> -<p><b>Section:</b> 18.2.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> +<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#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> 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 insufficent for the following reasons: +This seems insufficient for the following reasons: </p> <ol> -<li>Doesn't define what that value recieved is.</li> +<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> @@ -7041,10 +7105,17 @@ Pete: is there an ISO definition of modulo? Underflow on signed behavior is und ]</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 ammeded to: +Suggest 18.2.1.2 [numeric.limits.members[numeric.limits.members], paragraph 57 is amended to: </p> <blockquote><p> @@ -7118,6 +7189,12 @@ all member functions, during the lifetime of each container object. ]</i></p> +<p><i>[ +post Bellevue: We re-confirm that the issue is real. Pablo will provide wording. +]</i></p> + + + <p><b>Proposed resolution:</b></p> <p> @@ -7129,11 +7206,11 @@ all member functions, during the lifetime of each container object. <hr> <h3><a name="617"></a>617. std::array is a sequence that doesn't satisfy the sequence requirements?</h3> -<p><b>Section:</b> 23.2.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 23.2.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-30</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> <p><b>Discussion:</b></p> <p> The <tt><array></tt> header is given under 23.2 [sequences]. @@ -7164,9 +7241,9 @@ std::array does have, but array isn't mentioned. <hr> <h3><a name="618"></a>618. valarray::cshift() effects on empty array</h3> -<p><b>Section:</b> 26.5.2.7 [valarray.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> +<p><b>Section:</b> 26.5.2.7 [valarray.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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#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> I would respectfully request an issue be opened with the intention to @@ -7220,728 +7297,77 @@ Kona (2007) Changed proposed wording, added rationale and set to Review. <hr> -<h3><a name="620"></a>620. valid uses of empty valarrays</h3> -<p><b>Section:</b> 26.5.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#valarray.cons">active issues</a> in [valarray.cons].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cons">issues</a> in [valarray.cons].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> - <p> - -The <i>Effects</i> clause for the default <code>valarray</code> ctor -suggests that it is possible to increase the size of an empty -<code>valarray</code> object by calling other non-const member -functions of the class besides <code>resize()</code>. However, such an -interpretation would be contradicted by the requirement on the copy -assignment operator (and apparently also that on the computed -assignments) that the assigned arrays be the same size. See the -reflector discussion starting with c++std-lib-17871. - - </p> - <p> - -In addition, <i>Footnote</i> 280 uses some questionable normative -language. - - </p> - - -<p><b>Proposed resolution:</b></p> - <p> - -Reword the <i>Effects</i> clause and <i>Footnote 280</i> as follows (26.5.2.1 [valarray.cons]): - - </p> - <blockquote> - <p> - -<code>valarray();</code> - - </p> - <p> - -<i>Effects</i>: Constructs an object of class -<code>valarray<T></code>,<sup>279)</sup> which has zero -length<del> until it is passed into a library function as a modifiable -lvalue or through a non-constant this pointer</del>.<sup>280)</sup> - - </p> - <p> - -<ins><i>Postcondition</i>: <code>size() == 0</code>.</ins> - - </p> - <p> - -<i>Footnote 280</i>: This default constructor is essential, since -arrays of <code>valarray</code> <del>are likely to prove useful. -There shall also be a way to change the size of an array after -initialization; this is supplied by the semantics</del> <ins>may be -useful. The length of an empty array can be increased after -initialization by means</ins> of the <code>resize()</code> member -function. - - </p> - </blockquote> - - - - - -<hr> -<h3><a name="621"></a>621. non-const copy assignment operators of helper arrays</h3> -<p><b>Section:</b> 26.5 [numarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numarray">issues</a> in [numarray].</p> +<h3><a name="629"></a>629. complex<t> insertion and locale dependence</t></h3> +<p><b>Section:</b> 26.3.6 [complex.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> + <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2007-01-28</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.ops">issues</a> in [complex.ops].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> <p><b>Discussion:</b></p> - <p> - -The computed and "fill" assignment operators of <code>valarray</code> -helper array class templates (<code>slice_array</code>, -<code>gslice_array</code>, <code>mask_array</code>, and -<code>indirect_array</code>) are const member functions of each class -template (the latter by the resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#123">123</a> -since they have reference semantics and thus do not affect -the state of the object on which they are called. However, the copy -assignment operators of these class templates, which also have -reference semantics, are non-const. The absence of constness opens -the door to speculation about whether they really are intended to have -reference semantics (existing implementations vary widely). - - </p> - <p> -Pre-Kona, Martin adds: -</p> - -<p> -I realized that adding the const qualifier to the -functions as I suggested would break the const correctness of the -classes. A few possible solutions come to mind: +is there an issue opened for (0,3) as complex number with +the French local? With the English local, the above parses as an +imaginery complex number. With the French locale it parses as a +real complex number. </p> -<ol> -<li>Add the const qualifier to the return types of these functions.</li> -<li>Change the return type of all the functions to void to match -the signatures of all the other assignment operators these classes -define.</li> -<li>Prohibit the copy assignment of these classes by declaring the -copy assignment operators private (as is done and documented by -some implementations).</li> -</ol> - - - -<p><b>Proposed resolution:</b></p> - <p> - -Declare the copy assignment operators of all four helper array -class templates const. - - </p> - <p> - -Specifically, make the following edits: - - </p> - <p> - -Change the signature in 26.5.5 [template.slice.array] and -26.5.5.1 [slice.arr.assign] as follows: - - </p> - <blockquote><pre> -<code><ins>const</ins> slice_array& operator= (const slice_array&)<ins> const</ins>;</code> - - </pre></blockquote> - <p> - -Change the signature in 26.5.7 [template.gslice.array] and -26.5.7.1 [gslice.array.assign] as follows: - - </p> - <blockquote><pre> -<code><ins>const</ins> gslice_array& operator= (const gslice_array&)<ins> const</ins>;</code> - - </pre></blockquote> - <p> - -Change the signature in 26.5.8 [template.mask.array] and 26.5.8.1 [mask.array.assign] as -follows: - - </p> - <blockquote><pre> -<code><ins>const</ins> mask_array& operator= (const mask_array&)<ins> const</ins>;</code> - - </pre></blockquote> - <p> - -Change the signature in 26.5.9 [template.indirect.array] and -26.5.9.1 [indirect.array.assign] as follows: - - </p> - <blockquote><pre> -<code><ins>const</ins> indirect_array& operator= (const indirect_array&)<ins> const</ins>;</code> - - </pre></blockquote> - - -<p><i>[ -Kona (2007) Added const qualification to the return types and set to Ready. -]</i></p> - - - - - -<hr> -<h3><a name="622"></a>622. behavior of <code>filebuf</code> dtor and <code>close</code> on error</h3> -<p><b>Section:</b> 27.8.1.17 [fstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> - <p> - -<code>basic_filebuf</code> dtor is specified to have the following -straightforward effects: - - </p> - <blockquote><p> - -<i>Effects</i>: Destroys an object of class -<code>basic_filebuf</code>. Calls <code>close()</code>. - - </p></blockquote> - <p> - -<code>close()</code> does a lot of potentially complicated processing, -including calling <code>overflow()</code> to write out the termination -sequence (to bring the output sequence to its initial shift -state). Since any of the functions called during the processing can -throw an exception, what should the effects of an exception be on the -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]. - - </p> - <p> - -Further, the last thing <code>close()</code> is specified to do is -call <code>fclose()</code> to close the <code>FILE</code> pointer. The -last sentence of the <i>Effects</i> clause reads: - - </p> - <blockquote><p> - -... If any of the calls to <code>overflow</code> or -<code>std::fclose</code> fails then <code>close</code> fails. - - </p></blockquote> - <p> - -This suggests that <code>close()</code> might be required to call -<code>fclose()</code> if and only if none of the calls to -<code>overflow()</code> fails, and avoid closing the <code>FILE</code> -otherwise. This way, if <code>overflow()</code> failed to flush out -the data, the caller would have the opportunity to try to flush it -again (perhaps after trying to deal with whatever problem may have -caused the failure), rather than losing it outright. - - </p> - <p> - -On the other hand, the function's <i>Postcondition</i> specifies that -<code>is_open() == false</code>, which suggests that it should call -<code>fclose()</code> unconditionally. However, since -<i>Postcondition</i> clauses are specified for many functions in the -standard, including constructors where they obviously cannot apply -after an exception, it's not clear whether this <i>Postcondition</i> -clause is intended to apply even after an exception. - - </p> - <p> - -It might be worth noting that the traditional behavior (Classic -Iostreams <code>fstream::close()</code> and C <code>fclose()</code>) -is to close the <code>FILE</code> unconditionally, regardless of -errors. - - </p> - -<p><i>[ -See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#397">397</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#418">418</a> for related issues. -]</i></p> - - - - -<p><b>Proposed resolution:</b></p> - <p> - -After discussing this on the reflector (see the thread starting with -c++std-lib-17650) we propose that <code>close()</code> be clarified to -match the traditional behavior, that is to close the <code>FILE</code> -unconditionally, even after errors or exceptions. In addition, we -propose the dtor description be amended so as to explicitly require it -to catch and swallow any exceptions thrown by <code>close()</code>. - - </p> - <p> - -Specifically, we propose to make the following edits in -27.8.1.4 [filebuf.members]: - - </p> - <blockquote> - <pre> -<code>basic_filebuf<charT,traits>* close();</code> - - </pre> - <p> - -<i>Effects</i>: If <code>is_open() == false</code>, returns a null -pointer. If a put area exists, calls -<code>overflow(traits::eof())</code> to flush characters. If the last -virtual member function called on <code>*this</code> (between -<code>underflow</code>, <code>overflow</code>, <code>seekoff</code>, -and <code>seekpos</code>) was <code>overflow</code> then calls -<code>a_codecvt.unshift</code> (possibly several times) to determine a -termination sequence, inserts those characters and calls -<code>overflow(traits::eof())</code> again. Finally<ins>, regardless -of whether any of the preceding calls fails or throws an exception, -the function</ins> <del>it</del> closes the file ("as if" by calling -<code>std::fclose(file)</code>).<sup>334)</sup> If any of the calls -<ins>made by the function</ins><del>to <code>overflow</code> -or</del><ins>, including </ins><code>std::fclose</code><ins>, </ins> -fails then <code>close</code> fails<ins> by returning a null pointer. -If one of these calls throws an exception, the exception is caught and -rethrown after closing the file.</ins> - - </p> - </blockquote> - <p> - -And to make the following edits in 27.8.1.2 [filebuf.cons]. - - </p> - <blockquote> - <pre> -<code>virtual ~basic_filebuf();</code> - - </pre> - <p> - -<i>Effects</i>: Destroys an object of class -<code>basic_filebuf<charT,traits></code>. Calls -<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> - - </p> - </blockquote> - - - - - -<hr> -<h3><a name="623"></a>623. <code>pubimbue</code> forbidden to call <code>imbue</code></h3> -<p><b>Section:</b> 27.1.1 [iostream.limits.imbue] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> - <p> - -27.1.1 [iostream.limits.imbue] specifies that "no function described in -clause 27 except for <code>ios_base::imbue</code> causes any instance -of <code>basic_ios::imbue</code> or -<code>basic_streambuf::imbue</code> to be called." - - </p> - <p> - -That contradicts the <i>Effects</i> clause for -<code>basic_streambuf::pubimbue()</code> which requires the function -to do just that: call <code>basic_streambuf::imbue()</code>. - - </p> - - -<p><b>Proposed resolution:</b></p> - <p> - -To fix this, rephrase the sentence above to allow -<code>pubimbue</code> to do what it was designed to do. Specifically. -change 27.1.1 [iostream.limits.imbue], p1 to read: - - </p> - <blockquote><p> - -No function described in clause 27 except for -<code>ios_base::imbue</code> <ins>and <code>basic_filebuf::pubimbue</code></ins> -causes any instance of <code>basic_ios::imbue</code> or -<code>basic_streambuf::imbue</code> to be called. ... - - </p></blockquote> - - - - - -<hr> -<h3><a name="624"></a>624. <code>valarray</code> assignment and arrays of unequal length</h3> -<p><b>Section:</b> 26.5.2.2 [valarray.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> - <p> - -The behavior of the <code>valarray</code> copy assignment operator is -defined only when both sides have the same number of elements and the -spec is explicit about assignments of arrays of unequal lengths having -undefined behavior. - - </p> - <p> - -However, the generalized subscripting assignment operators overloaded -on <code>slice_array</code> et al (26.5.2.2 [valarray.assign]) don't have any -such restriction, leading the reader to believe that the behavior of -these overloads is well defined regardless of the lengths of the -arguments. - - </p> - <p> - -For example, based on the reading of the spec the behavior of the -snippet below can be expected to be well-defined: - - </p> - <pre> const std::slice from_0_to_3 (0, 3, 1); // refers to elements 0, 1, 2 - const std::valarray<int> a (1, 3); // a = { 1, 1, 1 } - std::valarray<int> b (2, 4); // b = { 2, 2, 2, 2 } - - b = a [from_0_to_3]; - </pre> - <p> - -In practice, <code>b</code> may end up being <code>{ 1, 1, 1 }</code>, -<code>{ 1, 1, 1, 2 }</code>, or anything else, indicating that -existing implementations vary. - - </p> - <p> -Quoting from Section 3.4, Assignment operators, of Al Vermeulen's -Proposal for Standard C++ Array Classes (see c++std-lib-704; -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0308.asc">N0308</a>): +Further notes/ideas from the lib-reflector, messages 17982-17984: </p> -<blockquote><p> - ...if the size of the array on the right hand side of the equal - sign differs from the size of the array on the left, a run time - error occurs. How this error is handled is implementation - dependent; for compilers which support it, throwing an exception - would be reasonable. -</p></blockquote> +<blockquote> <p> -And see more history in -<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/1993/N0280.pdf">N0280</a>. +Add additional entries in num_punct to cover the complex separator (French would be ';'). </p> - - <p> - -It has been argued in discussions on the committee's reflector that -the semantics of all <code>valarray</code> assignment operators should -be permitted to be undefined unless the length of the arrays being -assigned is the same as the length of the one being assigned from. See -the thread starting at c++std-lib-17786. - - </p> - <p> - -In order to reflect such views, the standard must specify that the -size of the array referred to by the argument of the assignment must -match the size of the array under assignment, for example by adding a -<i>Requires</i> clause to 26.5.2.2 [valarray.assign] as follows: - - </p> - <blockquote><p> - -<i>Requires</i>: The length of the array to which the argument refers -equals <code>size()</code>. - - </p></blockquote> - - <p> - -Note that it's far from clear that such leeway is necessary in order -to implement <code>valarray</code> efficiently. - - </p> - - -<p><b>Proposed resolution:</b></p> <p> -Insert new paragraph into 26.5.2.2 [valarray.assign]: +Insert a space before the comma, which should eliminate the ambiguity. </p> - -<blockquote> -<pre>valarray<T>& operator=(const slice_array<T>&); -valarray<T>& operator=(const gslice_array<T>&); -valarray<T>& operator=(const mask_array<T>&); -valarray<T>& operator=(const indirect_array<T>&); -</pre> -<blockquote> -<p><ins> -<i>Requires</i>: The length of the array to which the argument refers -equals <code>size()</code>. -</ins></p> <p> -These operators allow the results of a generalized subscripting operation to be assigned directly to a <tt>valarray</tt>. +Solve the problem for ordered sequences in general, perhaps with a +dedicated facet. Then complex should use that solution. </p> </blockquote> -</blockquote> - - - - -<hr> -<h3><a name="625"></a>625. mixed up <i>Effects</i> and <i>Returns</i> clauses</h3> -<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> - <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p> -<p><b>View 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#Open">Open</a> status.</p> -<p><b>Discussion:</b></p> - <p> - -Many member functions of <code>basic_string</code> are overloaded, -with some of the overloads taking a <code>string</code> argument, -others <code>value_type*</code>, others <code>size_type</code>, and -others still <code>iterators</code>. Often, the requirements on one of -the overloads are expressed in the form of <i>Effects</i>, -<i>Throws</i>, and in the Working Paper -(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>) -also <i>Remark</i> clauses, while those on the rest of the overloads -via a reference to this overload and using a <i>Returns</i> clause. - - </p><p> - </p> - -The difference between the two forms of specification is that per -17.3.1.3 [structure.specifications], p3, an <i>Effects</i> clause specifies -<i>"actions performed by the functions,"</i> i.e., its observable -effects, while a <i>Returns</i> clause is <i>"a description of the -return value(s) of a function"</i> that does not impose any -requirements on the function's observable effects. - - <p> - </p> - -Since only <i>Notes</i> are explicitly defined to be informative and -all other paragraphs are explicitly defined to be normative, like -<i>Effects</i> and <i>Returns</i>, the new <i>Remark</i> clauses also -impose normative requirements. - - <p> - </p> - -So by this strict reading of the standard there are some member -functions of <code>basic_string</code> that are required to throw an -exception under some conditions or use specific traits members while -many other otherwise equivalent overloads, while obliged to return the -same values, aren't required to follow the exact same requirements -with regards to the observable effects. - - <p> - </p> - -Here's an example of this problem that was precipitated by the change -from informative Notes to normative <i>Remark</i>s (presumably made to -address <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#424">424</a>): - - <p> - </p> - -In the Working Paper, <code>find(string, size_type)</code> contains a -<i>Remark</i> clause (which is just a <i>Note</i> in the current -standard) requiring it to use <code>traits::eq()</code>. - - <p> - </p> - -<code>find(const charT *s, size_type pos)</code> is specified to -return <code>find(string(s), pos)</code> by a <i>Returns</i> clause -and so it is not required to use <code>traits::eq()</code>. However, -the Working Paper has replaced the original informative <i>Note</i> -about the function using <code>traits::length()</code> with a -normative requirement in the form of a <i>Remark</i>. Calling -<code>traits::length()</code> may be suboptimal, for example when the -argument is a very long array whose initial substring doesn't appear -anywhere in <code>*this</code>. - - <p> - </p> - -Here's another similar example, one that existed even prior to the -introduction of <i>Remark</i>s: - - <p> - </p> - -<code> insert(size_type pos, string, size_type, size_type)</code> is -required to throw <code>out_of_range</code> if <code>pos > -size()</code>. - - <p> - </p> - -<code>insert(size_type pos, string str)</code> is specified to return -<code>insert(pos, str, 0, npos)</code> by a <i>Returns</i> clause and -so its effects when <code>pos > size()</code> are strictly speaking -unspecified. - - - <p> - -I believe a careful review of the current <i>Effects</i> and -<i>Returns</i> clauses is needed in order to identify all such -problematic cases. In addition, a review of the Working Paper should -be done to make sure that the newly introduced normative <i>Remark</i> -clauses do not impose any undesirable normative requirements in place -of the original informative <i>Notes</i>. - - </p> <p><i>[ -Batavia: Alan and Pete to work. +Bellevue: ]</i></p> - -<p><b>Proposed resolution:</b></p> +<blockquote> <p> +After much discussion, we agreed on the following: Add a footnote: </p> - - - - - -<hr> -<h3><a name="626"></a>626. new <i>Remark</i> clauses not documented</h3> -<p><b>Section:</b> 17.3.1.3 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> - <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#structure.specifications">issues</a> in [structure.specifications].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> -<p><b>Discussion:</b></p> - <p> - -The <i>Remark</i> clauses newly introduced into the Working Paper -(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>) -are not mentioned in 17.3.1.3 [structure.specifications] where we list the -meaning of <i>Effects</i>, <i>Requires</i>, and other clauses (with -the exception of <i>Notes</i> which are documented as informative in -17.3.1.1 [structure.summary], p2, and which they replace in many cases). - - </p> - <p> - -Propose add a bullet for <i>Remarks</i> along with a brief description. - - </p> -<p><i>[ -Batavia: Alan and Pete to work. -]</i></p> - - - -<p><b>Proposed resolution:</b></p> <p> +[In a locale in which comma is being used as a decimal point character, +inserting "showbase" into the output stream forces all outputs to show +an explicit decimal point character; then all inserted complex sequences +will extract unambiguously.] </p> - - - - - -<hr> -<h3><a name="627"></a>627. Low memory and exceptions</h3> -<p><b>Section:</b> 18.5.1.1 [new.delete.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> - <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2007-01-23</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete.single">issues</a> in [new.delete.single].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> -<p><b>Discussion:</b></p> <p> -I recognize the need for nothrow guarantees in the exception reporting -mechanism, but I strongly believe that implementors also need an escape hatch -when memory gets really low. (Like, there's not enough heap to construct and -copy exception objects, or not enough stack to process the throw.) I'd like to -think we can put this escape hatch in 18.5.1.1 [new.delete.single], -<tt>operator new</tt>, but I'm not sure how to do it. We need more than a -footnote, but the wording has to be a bit vague. The idea is that if -<tt>new</tt> can't allocate something sufficiently small, it has the right to -<tt>abort</tt>/call <tt>terminate</tt>/call <tt>unexpected</tt>. +And move this to READY status. </p> +</blockquote> <p><b>Proposed resolution:</b></p> <p> -</p> - - - - - -<hr> -<h3><a name="629"></a>629. complex<t> insertion and locale dependence</t></h3> -<p><b>Section:</b> 26.3.6 [complex.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> - <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2007-01-28</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.ops">issues</a> in [complex.ops].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> -<p><b>Discussion:</b></p> -<p> -is there an issue opened for (0,3) as complex number with -the French local? With the English local, the above parses as an -imaginery complex number. With the French locale it parses as a -real complex number. -</p> - -<p> -Further notes/ideas from the lib-reflector, messages 17982-17984: +Add a footnote to 26.3.6 [complex.ops] p16: </p> <blockquote> -<p> -Add additional entries in num_punct to cover the complex separator (French would be ';'). -</p> -<p> -Insert a space before the comma, which should eliminate the ambiguity. -</p> -<p> -Solve the problem for ordered sequences in general, perhaps with a -dedicated facet. Then complex should use that solution. -</p> +[In a locale in which comma is being used as a decimal point character, +inserting "showbase" into the output stream forces all outputs to show +an explicit decimal point character; then all inserted complex sequences +will extract unambiguously.] </blockquote> -<p><b>Proposed resolution:</b></p> -<p> -</p> - - - <hr> <h3><a name="630"></a>630. arrays of valarray</h3> <p><b>Section:</b> 26.5.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-28</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#valarray.cons">active issues</a> in [valarray.cons].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cons">issues</a> in [valarray.cons].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> <p><b>Discussion:</b></p> @@ -8012,6 +7438,16 @@ assignment operator. </p> +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +If no proposed wording by June meeting, this issue should be closed NAD. +</blockquote> + + <p><b>Proposed resolution:</b></p> <p> @@ -8216,6 +7652,7 @@ away. </p> + <p><b>Proposed resolution:</b></p> <p> </p> @@ -8229,6 +7666,17 @@ O(1). Alan has volunteered to provide wording. ]</i></p> +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Mandating O(1) size will not fly, too many implementations would be +invalidated. Alan to provide wording that toughens wording, but that +does not absolutely mandate O(1). +</blockquote> + @@ -8317,9 +7765,9 @@ 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#Review">Review</a> +<p><b>Section:</b> 23.2.2.3 [deque.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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#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 standard states at 23.2.2.3 [deque.modifiers]/4: @@ -8353,6 +7801,17 @@ 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> @@ -8384,189 +7843,19 @@ Kona (2007): Proposed wording added and moved to Review. ]</i></p> - - - -<hr> -<h3><a name="645"></a>645. Missing members in match_results</h3> -<p><b>Section:</b> 28.10 [re.results] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> - <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-26</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re.results">active issues</a> in [re.results].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.results">issues</a> in [re.results].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p> -<p><b>Discussion:</b></p> -<p> -According to the description given in 28.10 [re.results]/2 the class template -match_results "shall satisfy the requirements of a Sequence, [..], -except that only operations defined for const-qualified Sequences -are supported". -Comparing the provided operations from 28.10 [re.results]/3 with the -sequence/container tables 80 and 81 one recognizes the following -missing operations: -</p> - -<p> -1) The members -</p> - -<blockquote><pre>const_iterator rbegin() const; -const_iterator rend() const; -</pre></blockquote> - -<p> -should exists because 23.1/10 demands these for containers -(all sequences are containers) which support bidirectional -iterators. Aren't these supported by match_result? This is not -explicitely expressed, but it's somewhat implied by two arguments: -</p> -<p> -(a) Several typedefs delegate to -<tt>iterator_traits<BidirectionalIterator></tt>. -</p> -<p> -(b) The existence of <tt>const_reference operator[](size_type n) const</tt> -implies even random-access iteration. -I also suggest, that <tt>match_result</tt> should explicitly mention, -which minimum iterator category is supported and if this does -not include random-access the existence of <tt>operator[]</tt> is -somewhat questionable. -</p> -<p> -2) The new "convenience" members -</p> -<blockquote><pre>const_iterator cbegin() const; -const_iterator cend() const; -const_iterator crbegin() const; -const_iterator crend() const; -</pre></blockquote> -<p> -should be added according to tables 80/81. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Add the following members to the <tt>match_results</tt> synopsis after <tt>end()</tt> in 28.10 [re.results] -para 3: -</p> - -<blockquote><pre>const_iterator cbegin() const; -const_iterator cend() const; -</pre></blockquote> - -<p> -In section 28.10.3 [re.results.acc] change: -</p> - -<blockquote> -<pre>const_iterator begin() const; -<ins>const_iterator cbegin() const;</ins> -</pre> -<blockquote> -<p> --7- <i>Returns:</i> A starting iterator that enumerates over all the sub-expressions stored in <tt>*this</tt>. -</p> -</blockquote> - -<pre>const_iterator end() const; -<ins>const_iterator cend() const;</ins> -</pre> -<blockquote> -<p> --8- <i>Returns:</i> A terminating iterator that enumerates over all the sub-expressions stored in <tt>*this</tt>. -</p> -</blockquote> -</blockquote> - - - <p><i>[ -Kona (2007): Voted to adopt proposed wording in -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a> -except removing the entry in the table container requirements. Moved to Review. +Bellevue: ]</i></p> - - - -<hr> -<h3><a name="653"></a>653. Library reserved names</h3> -<p><b>Section:</b> 1.2 [intro.refs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> - <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-03-08</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#intro.refs">issues</a> in [intro.refs].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> -<p><b>Discussion:</b></p> -<p> -</p> <blockquote> -<p> -1.2 [intro.refs] Normative references -</p> - -<p> -The following standards contain provisions which, through reference in -this text, constitute provisions of this Interna- tional Standard. At -the time of publication, the editions indicated were valid. All -standards are subject to revision, and parties to agreements based on -this International Standard are encouraged to investigate the -possibility of applying the most recent editions of the standards -indicated below. Members of IEC and ISO maintain registers of currently -valid International Standards. -</p> - -<ul> -<li>Ecma International, ECMAScript Language Specification, Standard -Ecma-262, third edition, 1999.</li> -<li>ISO/IEC 2382 (all parts), Information technology - Vocabulary</li> -<li>ISO/IEC 9899:1990, Programming languages - C</li> -<li>ISO/IEC 9899/Amd.1:1995, Programming languages - C, AMENDMENT 1: C -Integrity</li> -<li>ISO/IEC 9899:1999, Programming languages - C</li> -<li>ISO/IEC 9899:1999/Cor.1:2001 Programming languages - C</li> -<li>ISO/IEC 9899:1999/Cor.2:2004 Programming languages - C</li> -<li>ISO/IEC 9945:2003, Information Technology-Portable Operating System -Interface (POSIX)</li> -<li>ISO/IEC 10646-1:1993 Information technology - Universal Multiple-Octet -Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual -Plane</li> -</ul> +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> -<p> -I'm not sure how many of those reserve naming patterns that might affect -us, but I am equally sure I don't own a copy of any of these to check! -</p> -<p> -The point is to list the reserved naming patterns, rather than the -individual names themselves - although we may want to list C keywords -that are valid identifiers in C++ but likely to cause trouble in shared -headers (e.g. restrict) -</p> - -<p><i>[ -Kona (2007): Recommend NAD. No one has identified a specific defect, just the possibility of one. -]</i></p> - - -<p><i>[ -Post-Kona: Alisdair request Open. A good example of the problem was a -discussion of the system error proposal, where it was pointed out an all-caps -identifier starting with a capital E conflicted with reserved macro names for -both Posix and C. I had absolutely no idea of this rule, and suspect I was -not the only one in the room.<br> -<br> -Resolution will require someone with access to all the listed documents to -research their respective name reservation rules, or people with access to -specific documents add their rules to this issue until the list is complete. -]</i></p> - - - - -<p><b>Proposed resolution:</b></p> - - @@ -8581,26 +7870,26 @@ specific documents add their rules to this issue until the list is complete. Greg Herlihy has clearly demonstrated that a user defined input iterator should have an operator->(), even if its value type is a built-in type (comp.std.c++, "Re: Should any iterator -have an operator->() in C++0x?", March 2007). And as Howard +have an operator->() in C++0x?", March 2007). And as Howard Hinnant remarked in the same thread that the input iterator <tt>istreambuf_iterator</tt> doesn't have one, this must be a defect! </p> <p> Based on Greg's example, the following code demonstrates the issue: -</p><pre> #include <iostream> - #include <fstream> - #include <streambuf> - - typedef char C; - int main () - { - std::ifstream s("filename", std::ios::in); - std::istreambuf_iterator<char> i(s); - - (*i).~C(); // This is well-formed... - i->~C(); // ... so this should be supported! - } +</p><pre> #include <iostream> + #include <fstream> + #include <streambuf> + + typedef char C; + int main () + { + std::ifstream s("filename", std::ios::in); + std::istreambuf_iterator<char> i(s); + + (*i).~C(); // This is well-formed... + i->~C(); // ... so this should be supported! + } </pre> <p> @@ -8608,9 +7897,9 @@ Of course, operator-> is also needed when the value_type of istreambuf_iterator is a class. </p> <p> -The operator-> could be implemented in various ways. For instance, +The operator-> could be implemented in various ways. For instance, by storing the current value inside the iterator, and returning its -address. Or by returning a proxy, like operator_arrow_proxy, from +address. Or by returning a proxy, like operator_arrow_proxy, from <a href="http://www.boost.org/boost/iterator/iterator_facade.hpp">http://www.boost.org/boost/iterator/iterator_facade.hpp</a> </p> <p> @@ -8671,14 +7960,14 @@ may in fact be a proxy. AFAIK, the resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#445">445</a> ("<tt>iterator_traits::reference</tt> unspecified for some iterator categories") implies that for any iterator class <tt>Iter</tt>, the return type of <tt>operator->()</tt> is <tt>Iter::pointer</tt>, by -definition. I don't think <tt>Iter::pointer</tt> needs to be a raw pointer. +definition. I don't think <tt>Iter::pointer</tt> needs to be a raw pointer. </p> <p> Still I wouldn't mind if the text "<tt>operator-></tt> may return a proxy" would be removed from the resolution. I think it's up to the library -implementation, how to implement <tt>istreambuf_iterator::operator->()</tt>. As +implementation, how to implement <tt>istreambuf_iterator::operator->()</tt>. As longs as it behaves as expected: <tt>i->m</tt> should have the same effect as -<tt>(*i).m</tt>. Even for an explicit destructor call, <tt>i->~C()</tt>. The main issue +<tt>(*i).m</tt>. Even for an explicit destructor call, <tt>i->~C()</tt>. The main issue is just: <tt>istreambuf_iterator</tt> should have an <tt>operator->()</tt>! </p> </blockquote> @@ -8687,248 +7976,6 @@ is just: <tt>istreambuf_iterator</tt> should have an <tt>operator->()</tt>! <hr> -<h3><a name="661"></a>661. New 27.6.1.2.2 changes make special extractions useless</h3> -<p><b>Section:</b> 27.6.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-04-01</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.formatted.arithmetic">active issues</a> in [istream.formatted.arithmetic].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -To the more drastic changes of 27.6.1.2.2 [istream.formatted.arithmetic] in the current draft N2134 belong -the explicit description of the extraction of the types short and int in -terms of as-if code fragments. -</p> - -<ol> -<li> -The corresponding as-if extractions in paragraph 2 and 3 will never -result in a change of the operator>> argument val, because the -contents of the local variable lval is in no case written into val. -Furtheron both fragments need a currently missing parentheses in the -beginning of the if-statement to be valid C++. -</li> -<li>I would like to ask whether the omission of a similar explicit -extraction of unsigned short and unsigned int in terms of long - -compared to their corresponding new insertions, as described in -27.6.2.6.2 [ostream.inserters.arithmetic], is a deliberate decision or -an -oversight. -</li> -</ol> - - -<p><b>Proposed resolution:</b></p> -<ol> -<li> -<p> -In 27.6.1.2.2 [istream.formatted.arithmetic]/2 change the current as-if code fragment -</p> -<blockquote><pre>typedef num_get<charT,istreambuf_iterator<charT,traits> > numget; -iostate err = 0; -long lval; -use_facet<numget>(loc).get(*this, 0, *this, err, lval ); -if (err == 0) <ins>{</ins> - <del>&&</del> <ins>if</ins> (lval < numeric_limits<short>::min() || numeric_limits<short>::max() < lval)<del>)</del> - err = ios_base::failbit; - <ins>else - val = static_cast<short>(lval); -}</ins> -setstate(err); -</pre></blockquote> - -<p> -Similarily in 27.6.1.2.2 [istream.formatted.arithmetic]/3 change the current as-if fragment -</p> - -<blockquote><pre>typedef num_get<charT,istreambuf_iterator<charT,traits> > numget; -iostate err = 0; -long lval; -use_facet<numget>(loc).get(*this, 0, *this, err, lval ); -if (err == 0) <ins>{</ins> - <del>&&</del> <ins>if</ins> (lval < numeric_limits<int>::min() || numeric_limits<int>::max() < lval)<del>)</del> - err = ios_base::failbit; - <ins>else - val = static_cast<int>(lval); -}</ins> -setstate(err); -</pre></blockquote> -</li> -<li> ---- -</li> -</ol> - - -<p><i>[ -Kona (2007): Note to the editor: the name lval in the call to <tt>use_facet</tt> -is incorrectly italicized in the code fragments corresponding to -<tt>operator>>(short &)</tt> and <tt>operator >>(int &)</tt>. Also, val -- which appears -twice on the line with the <tt>static_cast</tt> in the proposed resolution -- -should be italicized. Also, in response to part two of the issue: this -is deliberate. -]</i></p> - - - - - -<hr> -<h3><a name="664"></a>664. <tt>do_unshift</tt> for <tt>codecvt<char, char, mbstate_t></tt></h3> -<p><b>Section:</b> 22.2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.codecvt.virtuals">active issues</a> in [locale.codecvt.virtuals].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.virtuals">issues</a> in [locale.codecvt.virtuals].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -22.2.1.4.2 [locale.codecvt.virtuals], para 7 says (regarding <tt>do_unshift</tt>): -</p> - -<blockquote><p> -<i>Effects:</i> Places characters starting at to that should be appended to -terminate a sequence when the current <tt>stateT</tt> is given by -<tt><i>state</i></tt>.<sup>237)</sup> Stores no more than <tt>(<i>to_limit</i> - -<i>to</i>)</tt> destination elements, and leaves the <tt><i>to_next</i></tt> -pointer pointing one beyond the last element successfully stored. -<em><tt>codecvt<char, char, mbstate_t></tt> stores no characters.</em> -</p></blockquote> - -<p> -The following objection has been raised: -</p> - -<blockquote><p> -Since the C++ Standard permits a nontrivial conversion for the required -instantiations of <tt>codecvt</tt>, it is overly restrictive to say that -<tt>do_unshift</tt> must store no characters and return <tt>noconv</tt>. -</p></blockquote> - -<p> -[Plum ref _222152Y50] -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Change 22.2.1.4.2 [locale.codecvt.virtuals], p7: -</p> - -<blockquote> -<p> -<i>Effects:</i> Places characters starting at <i>to</i> that should be -appended to terminate a sequence when the current <tt>stateT</tt> is -given by state.<sup>237)</sup> Stores no more than (<i>to_limit -to</i>) -destination elements, and leaves the <i>to_next</i> pointer pointing one -beyond the last element successfully stored. <del><tt>codecvt<char, char, -mbstate_t></tt> stores no characters.</del> -</p> -</blockquote> - - - - - -<hr> -<h3><a name="665"></a>665. <tt>do_unshift</tt> return value</h3> -<p><b>Section:</b> 22.2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.codecvt.virtuals">active issues</a> in [locale.codecvt.virtuals].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.virtuals">issues</a> in [locale.codecvt.virtuals].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -22.2.1.4.2 [locale.codecvt.virtuals], para 8 says: -</p> - -<blockquote><p> -<tt>codecvt<char,char,mbstate_t></tt>, returns <tt>noconv</tt>. -</p></blockquote> - -<p> -The following objection has been raised: -</p> - -<blockquote><p> -Despite what the C++ Standard -says, <tt>unshift</tt> can't always return <tt>noconv</tt> for the default facets, since -they can be nontrivial. At least one implementation does whatever the -C functions do. -</p></blockquote> - -<p> -[Plum ref _222152Y62] -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Change 22.2.1.4.2 [locale.codecvt.virtuals], p8: -</p> - -<blockquote> -<p><i>Returns:</i> An enumeration value, as summarized in Table 76:</p> -<p>...</p> -<p> -<del><tt>codecvt<char,char,mbstate_t></tt>, returns <tt>noconv</tt>.</del> -</p> -</blockquote> - - - - - - -<hr> -<h3><a name="666"></a>666. <tt>moneypunct::do_curr_symbol()</tt></h3> -<p><b>Section:</b> 22.2.6.3.2 [locale.moneypunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.moneypunct.virtuals">issues</a> in [locale.moneypunct.virtuals].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -22.2.6.3.2 [locale.moneypunct.virtuals], para 4 footnote 257 says -</p> - -<blockquote><p> -<sup>257)</sup> For international -specializations (second template parameter <tt>true</tt>) this is always four -characters long, usually three letters and a space. -</p></blockquote> - -<p> -The following objection has been raised: -</p> - -<blockquote><p> -The international currency -symbol is whatever the underlying locale says it is, not necessarily -four characters long. -</p></blockquote> - -<p> -[Plum ref _222632Y41] -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Change footnote 253 in 22.2.6.3.2 [locale.moneypunct.virtuals]: -</p> - -<blockquote> -<p> -<sup>253)</sup> For international specializations (second template -parameter <tt>true</tt>) this is <del>always</del> <ins>typically</ins> -four characters long, usually three letters and a space. -</p> -</blockquote> - - - - - -<hr> <h3><a name="667"></a>667. <tt>money_get</tt>'s widened minus sign</h3> <p><b>Section:</b> 22.2.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p> @@ -8941,9 +7988,9 @@ four characters long, usually three letters and a space. </p> <blockquote><p> -The result is returned as an integral value -stored in <tt>units</tt> or as a sequence of digits possibly preceded by a -minus sign (as produced by <tt>ct.widen(c)</tt> where <tt>c</tt> is '-' or in the range +The result is returned as an integral value +stored in <tt>units</tt> or as a sequence of digits possibly preceded by a +minus sign (as produced by <tt>ct.widen(c)</tt> where <tt>c</tt> is '-' or in the range from '0' through '9', inclusive) stored in <tt>digits</tt>. </p></blockquote> @@ -8956,10 +8003,10 @@ objection has been raised: Some implementations interpret this to mean that a facet derived from <tt>ctype<wchar_t></tt> can provide its own member <tt>do_widen(char)</tt> which produces e.g. <tt>L'@'</tt> for the "widened" minus sign, and that the -<tt>'@'</tt> symbol will appear in the resulting sequence of digits. Other +<tt>'@'</tt> symbol will appear in the resulting sequence of digits. Other implementations have assumed that one or more places in the standard permit the -implementation to "hard-wire" <tt>L'-'</tt> as the "widened" minus sign. Are -both interpretations permissible, or only one? +implementation to "hard-wire" <tt>L'-'</tt> as the "widened" minus sign. Are +both interpretations permissible, or only one? </p></blockquote> <p> @@ -8976,6 +8023,18 @@ Kona (2007): Bill and Dietmar to provide proposed wording. ]</i></p> +<p><i>[ +post Bellevue: Bill adds: +]</i></p> + + +<blockquote> +The Standard is clear that the minus sign stored in <tt>digits</tt> is <tt>ct.widen('-')</tt>. +The subject string must contain characters <tt>c</tt> in the set <tt>[-0123456789]</tt> +which are translated by <tt>ct.widen(c)</tt> calls before being stored in <tt>digits</tt>; +the widened characters are not relevant to the parsing of the subject string. +</blockquote> + <p><b>Proposed resolution:</b></p> <p> @@ -8999,7 +8058,7 @@ Kona (2007): Bill and Dietmar to provide proposed wording. <blockquote><p> If <tt>pos</tt> or <tt>neg</tt> is empty, the sign component is -optional, and if no sign is detected, the result is given the sign +optional, and if no sign is detected, the result is given the sign that corresponds to the source of the empty string. </p></blockquote> @@ -9009,8 +8068,8 @@ objection has been raised: </p> <blockquote><p> -A <tt>negative_sign</tt> of "" means "there is no -way to write a negative sign" not "any null sequence is a negative +A <tt>negative_sign</tt> of "" means "there is no +way to write a negative sign" not "any null sequence is a negative sign, so it's always there when you look for it". </p></blockquote> @@ -9046,14 +8105,14 @@ Kona (2007): Bill to provide proposed wording and interpretation of existing wor </p> <blockquote><p> -If the first character of <tt>pos</tt> is equal to the first character of <tt>neg</tt>, +If the first character of <tt>pos</tt> is equal to the first character of <tt>neg</tt>, or if both strings are empty, the result is given a positive sign. </p></blockquote> <p> One interpretation is that an input sequence must match either the positive pattern or the negative pattern, and then in either event it -is interpreted as positive. The following objections has been raised: +is interpreted as positive. The following objections has been raised: </p> <blockquote><p> @@ -9091,7 +8150,7 @@ Bill to provide proposed wording and interpretation of existing wording. </p> <blockquote><p> -The value <tt>space</tt> indicates that at least one space is required at +The value <tt>space</tt> indicates that at least one space is required at that position. </p></blockquote> @@ -9100,7 +8159,7 @@ The following objection has been raised: </p> <blockquote><p> -Whitespace is optional when matching space. (See 22.2.6.1.2 [locale.money.get.virtuals], para 2.) +Whitespace is optional when matching space. (See 22.2.6.1.2 [locale.money.get.virtuals], para 2.) </p></blockquote> <p> @@ -9201,11 +8260,11 @@ 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#Review">Review</a> +<p><b>Section:</b> 20.1.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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#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 current <tt>Swappable</tt> is: @@ -9361,16 +8420,18 @@ swap to be rvalues). <hr> <h3><a name="673"></a>673. <tt>unique_ptr</tt> update</h3> -<p><b>Section:</b> 20.6.5 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> +<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 all 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#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">reference implmenation</a> +<a href="http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html">example implmenation</a> for all of these changes. </p> @@ -9405,7 +8466,7 @@ pointer type is actually a <tt>T*</tt>. This can easily be accomplished for <tt>unique_ptr</tt> by having the deleter define the pointer type: <tt>D::pointer</tt>. Furthermore this type can easily be defaulted to <tt>T*</tt> should the deleter <tt>D</tt> choose not to define a pointer -type (reference implementation +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) @@ -9482,7 +8543,7 @@ the proposed resolutions below. <li> <p> -Change 20.6.5.2 [unique.ptr.single]: +Change 20.6.11.2 [unique.ptr.single]: </p> <blockquote><pre>template <class T, class D = default_delete<T>> class unique_ptr { @@ -9493,7 +8554,7 @@ Change 20.6.5.2 [unique.ptr.single]: </pre></blockquote> <p> -Change 20.6.5.2.4 [unique.ptr.single.observers]: +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; @@ -9503,7 +8564,7 @@ Change 20.6.5.2.4 [unique.ptr.single.observers]: <li> <p> -Change 20.6.5.2 [unique.ptr.single]: +Change 20.6.11.2 [unique.ptr.single]: </p> <blockquote><pre>template <class T, class D = default_delete<T>> class unique_ptr { @@ -9529,13 +8590,13 @@ public: exists, then <tt>unique_ptr<T, D>::pointer</tt> is a typedef to <tt>remove_reference<D>::type::pointer</tt>. Otherwise <tt>unique_ptr<T, D>::pointer</tt> is a typedef to <tt>T*</tt>. -The type <tt>unique_ptr<T, D>::pointer</tt> must be <tt>CopyConstructible</tt> +The type <tt>unique_ptr<T, D>::pointer</tt> shall be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>. </ins> </p> <p> -Change 20.6.5.2.1 [unique.ptr.single.ctor]: +Change 20.6.11.2.1 [unique.ptr.single.ctor]: </p> <blockquote><pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p); @@ -9557,10 +8618,10 @@ unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A&& d); <p> -23- <i>Requires:</i> If <tt>D</tt> is not a reference type, construction of the deleter <tt>D</tt> from an rvalue of type <tt>E</tt> -must be well formed and not throw an exception. If <tt>D</tt> is a -reference type, then <tt>E</tt> must be the same type as <tt>D</tt> +<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> -must be implicitly convertible to <del><tt>T*</tt></del> +<del>must</del> <ins>shall</ins> be implicitly convertible to <del><tt>T*</tt></del> <ins>pointer</ins>. </p> @@ -9575,20 +8636,20 @@ internally stored deleter which was constructed from </p> <p> -Change 20.6.5.2.3 [unique.ptr.single.asgn]: +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> must not throw an exception. <del><tt>U*</tt></del> -<ins><tt>unique_ptr<U,E>::pointer</tt></ins> must be implicitly +<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.5.2.4 [unique.ptr.single.observers]: +Change 20.6.11.2.4 [unique.ptr.single.observers]: </p> <blockquote> @@ -9598,7 +8659,7 @@ Change 20.6.5.2.4 [unique.ptr.single.observers]: </blockquote> <p> -Change 20.6.5.2.5 [unique.ptr.single.modifiers]: +Change 20.6.11.2.5 [unique.ptr.single.modifiers]: </p> <blockquote> @@ -9608,7 +8669,7 @@ Change 20.6.5.2.5 [unique.ptr.single.modifiers]: </blockquote> <p> -Change 20.6.5.3 [unique.ptr.runtime]: +Change 20.6.11.3 [unique.ptr.runtime]: </p> <blockquote><pre>template <class T, class D> class unique_ptr<T[], D> { @@ -9628,7 +8689,7 @@ public: </pre></blockquote> <p> -Change 20.6.5.3.1 [unique.ptr.runtime.ctor]: +Change 20.6.11.3.1 [unique.ptr.runtime.ctor]: </p> <blockquote> @@ -9647,7 +8708,7 @@ these members. <i>-- end note</i>] </blockquote> <p> -Change 20.6.5.3.3 [unique.ptr.runtime.modifiers]: +Change 20.6.11.3.3 [unique.ptr.runtime.modifiers]: </p> <blockquote> @@ -9662,89 +8723,53 @@ templated overload. <i>-- end note</i>] </p> </blockquote> -<p> -Change 20.6.5.4 [unique.ptr.compiletime]: -</p> - -<blockquote><pre>template <class T, class D, size_t N> class unique_ptr<T[N], D> { -public: - <ins>typedef <i>implementation</i> pointer;</ins> - ... - explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p); - ... - unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d); - unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d); - ... - <del>T*</del> <ins>pointer</ins> get() const; - ... - <del>T*</del> <ins>pointer</ins> release(); - void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>); -}; -</pre></blockquote> - -<p> -Change 20.6.5.4.3 [unique.ptr.compiletime.modifiers]: -</p> - -<blockquote> -<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>); -</pre> - -<p> --1- <i>Requires:</i> Does not accept pointer types which are convertible -to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (dignostic required). [<i>Note:</i> One implementation -technique is to create a private templated overload. <i>--end note</i>] -</p> - -</blockquote> - </li> <li> <p> -Change 20.6.5.2.1 [unique.ptr.single.ctor]: +Change 20.6.11.2.1 [unique.ptr.single.ctor]: </p> <blockquote> <pre>unique_ptr();</pre> <blockquote> <p> -<i>Requires:</i> <tt>D</tt> must be default constructible, and that -construction must not throw an exception. <tt>D</tt> must not be a +<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> must be well formed. -The default constructor of <tt>D</tt> must not throw an exception. -<tt>D</tt> must not be a reference type <ins>or pointer type (diagnostic +<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.5.2.1 [unique.ptr.single.ctor]: +Change 20.6.11.2.1 [unique.ptr.single.ctor]: </p> <blockquote> <pre>unique_ptr();</pre> <blockquote> <p> -<i>Requires:</i> <tt>D</tt> must be default constructible, and that -construction must not throw an exception. <tt>D</tt> must not be a +<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> must be well formed. -The default constructor of <tt>D</tt> must not throw an exception. -<tt>D</tt> must not be a reference type <ins>or pointer type (diagnostic +<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> @@ -9760,109 +8785,12 @@ required)</ins>. <hr> -<h3><a name="674"></a>674. <tt>shared_ptr</tt> interface changes for consistency with N1856</h3> -<p><b>Section:</b> 20.6.6.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-05</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a> does not propose -any changes to <tt>shared_ptr</tt>. It needs to be updated to use a rvalue reference where appropriate -and to interoperate with <tt>unique_ptr</tt> as it does with <tt>auto_ptr</tt>. -</p> - - -<p><b>Proposed resolution:</b></p> - -<p> -Change 20.6.6.2 [util.smartptr.shared] as follows: -</p> - -<blockquote> -<pre>template<class Y> explicit shared_ptr(auto_ptr<Y><del>&</del><ins>&&</ins> r); -<ins>template<class Y, class D> explicit shared_ptr(const unique_ptr<Y,D>& r) = delete; -template<class Y, class D> explicit shared_ptr(unique_ptr<Y,D>&& r);</ins> -... -template<class Y> shared_ptr& operator=(auto_ptr<Y><del>&</del><ins>&&</ins> r); -<ins>template<class Y, class D> shared_ptr& operator=(const unique_ptr<Y,D>& r) = delete; -template<class Y, class D> shared_ptr& operator=(unique_ptr<Y,D>&& r);</ins></pre> -</blockquote> - -<p> -Change 20.6.6.2.1 [util.smartptr.shared.const] as follows: -</p> - -<blockquote> -<pre><ins>template<class Y> shared_ptr(auto_ptr<Y><del>&</del><ins>&&</ins> r);</ins></pre> -</blockquote> - -<p> -Add to 20.6.6.2.1 [util.smartptr.shared.const]: -</p> - -<blockquote> -<pre><ins>template<class Y, class D> shared_ptr(unique_ptr<Y, D>&& r);</ins></pre> -<blockquote> - -<p><ins> -<i>Effects:</i> Equivalent to <tt>shared_ptr( r.release(), r.get_deleter() )</tt> when <tt>D</tt> is - not a reference type, <tt>shared_ptr( r.release(), ref( r.get_deleter() ) )</tt> - otherwise. -</ins></p> - -<p><ins> -<i>Exception safety:</i> If an exception is thrown, the constructor has no effect. -</ins></p> -</blockquote> - -</blockquote> - -<p> -Change 20.6.6.2.3 [util.smartptr.shared.assign] as follows: -</p> - -<blockquote> -<pre>template<class Y> shared_ptr& operator=(auto_ptr<Y><del>&</del><ins>&&</ins> r);</pre> -</blockquote> - -<p> -Add to 20.6.6.2.3 [util.smartptr.shared.assign]: -</p> - -<blockquote> -<pre><ins>template<class Y, class D> shared_ptr& operator=(unique_ptr<Y,D>&& r);</ins></pre> - -<blockquote> -<p><ins> --4- <i>Effects:</i> Equivalent to <tt>shared_ptr(std::move(r)).swap(*this)</tt>. -</ins></p> -<p><ins> --5- <i>Returns:</i> <tt>*this</tt>. -</ins></p> -</blockquote> - -</blockquote> - - - -<p><i>[ -Kona (2007): We may need to open an issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#743">743</a>) to deal with the question of -whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>. -]</i></p> - - - - - -<hr> <h3><a name="675"></a>675. Move assignment of containers</h3> -<p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> +<p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-05</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</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) @@ -9928,16 +8856,30 @@ before this construction +<p><i>[ +post Bellevute Howard adds: +]</i></p> + + +<blockquote> +<p> +This issue was voted to WP in Bellevue, but accidently got stepped on by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a> +which was voted to WP simulataneously. Moving back to Open for the purpose of getting +the wording right. The intent of this issue and N2525 are not in conflict. +</p> +</blockquote> + <hr> <h3><a name="676"></a>676. Moving the unordered containers</h3> -<p><b>Section:</b> 23.4 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> +<p><b>Section:</b> 23.4 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-05</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord">active issues</a> in [unord].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord">issues</a> in [unord].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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> Move semantics are missing from the <tt>unordered</tt> containers. The proposed @@ -10535,311 +9477,45 @@ Add to 23.4.4.2 [unord.multiset.swap]: - - - -<hr> -<h3><a name="679"></a>679. resize parameter by value</h3> -<p><b>Section:</b> 23.2 [sequences] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-06-11</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -The C++98 standard specifies that one member function alone of the containers -passes its parameter (<tt>T</tt>) by value instead of by const reference: -</p> - -<blockquote><pre>void resize(size_type sz, T c = T()); -</pre></blockquote> - -<p> -This fact has been discussed / debated repeatedly over the years, the first time -being even before C++98 was ratified. The rationale for passing this parameter by -value has been: -</p> - -<blockquote> -<p> -So that self referencing statements are guaranteed to work, for example: -</p> -<blockquote><pre>v.resize(v.size() + 1, v[0]); -</pre></blockquote> -</blockquote> - -<p> -However this rationale is not convincing as the signature for <tt>push_back</tt> is: -</p> - -<blockquote><pre>void push_back(const T& x); -</pre></blockquote> - -<p> -And <tt>push_back</tt> has similar semantics to <tt>resize</tt> (append). -And <tt>push_back</tt> must also work in the self referencing case: -</p> - -<blockquote><pre>v.push_back(v[0]); // must work -</pre></blockquote> - -<p> -The problem with passing <tt>T</tt> by value is that it can be significantly more -expensive than passing by reference. The converse is also true, however when it is -true it is usually far less dramatic (e.g. for scalar types). -</p> - -<p> -Even with move semantics available, passing this parameter by value can be expensive. -Consider for example <tt>vector<vector<int>></tt>: -</p> - -<blockquote><pre>std::vector<int> x(1000); -std::vector<std::vector<int>> v; -... -v.resize(v.size()+1, x); -</pre></blockquote> - -<p> -In the pass-by-value case, <tt>x</tt> is copied once to the parameter of -<tt>resize</tt>. And then internally, since the code can not know at compile -time by how much <tt>resize</tt> is growing the <tt>vector</tt>, <tt>x</tt> is -usually copied (not moved) a second time from <tt>resize</tt>'s parameter into its proper place -within the <tt>vector</tt>. -</p> - -<p> -With pass-by-const-reference, the <tt>x</tt> in the above example need be copied -only once. In this case, <tt>x</tt> has an expensive copy constructor and so any -copies that can be saved represents a significant savings. -</p> - -<p> -If we can be efficient for <tt>push_back</tt>, we should be efficient for <tt>resize</tt> -as well. The resize taking a reference parameter has been coded and shipped in the -CodeWarrior library with no reports of problems which I am aware of. -</p> - - - -<p><b>Proposed resolution:</b></p> -<p> -Change 23.2.2 [deque], p2: -</p> - -<blockquote><pre>class deque { - ... - void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c); -</pre></blockquote> - -<p> -Change 23.2.2.2 [deque.capacity], p3: -</p> - -<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c); -</pre></blockquote> - -<p> -Change 23.2.3 [list], p2: -</p> - -<blockquote><pre>class list { - ... - void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c); -</pre></blockquote> - -<p> -Change 23.2.3.2 [list.capacity], p3: -</p> - -<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c); -</pre></blockquote> - -<p> -Change 23.2.5 [vector], p2: -</p> - -<blockquote><pre>class vector { - ... - void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c); -</pre></blockquote> - -<p> -Change 23.2.5.2 [vector.capacity], p11: -</p> - -<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c); -</pre></blockquote> - - - - - - -<hr> -<h3><a name="680"></a>680. move_iterator operator-> return</h3> -<p><b>Section:</b> 24.4.3.1 [move.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-06-11</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -<tt>move_iterator</tt>'s <tt>operator-></tt> return type <tt>pointer</tt> -does not consistently match the type which is returned in the description -in 24.4.3.3.5 [move.iter.op.ref]. -</p> - -<blockquote><pre>template <class Iterator> -class move_iterator { -public: - ... - typedef typename iterator_traits<Iterator>::pointer pointer; - ... - pointer operator->() const {return current;} - ... -private: - Iterator current; // exposition only -}; -</pre></blockquote> - - -<p> -There are two possible fixes. -</p> - -<ol> -<li><tt>pointer operator->() const {return &*current;}</tt></li> -<li><tt>typedef Iterator pointer;</tt></li> -</ol> - -<p> -The first solution is the one chosen by <tt>reverse_iterator</tt>. A potential -disadvantage of this is it may not work well with iterators which return a -proxy on dereference and that proxy has overloaded <tt>operator&()</tt>. Proxy -references often need to overloaad <tt>operator&()</tt> to return a proxy -pointer. That proxy pointer may or may not be the same type as the iterator's -<tt>pointer</tt> type. -</p> - -<p> -By simply returning the <tt>Iterator</tt> and taking advantage of the fact that -the language forwards calls to <tt>operator-></tt> automatically until it -finds a non-class type, the second solution avoids the issue of an overloaded -<tt>operator&()</tt> entirely. -</p> - -<p><b>Proposed resolution:</b></p> -<p> -Change the synopsis in 24.4.3.1 [move.iterator]: -</p> - -<blockquote><pre>typedef <del>typename iterator_traits<</del>Iterator<del>>::pointer</del> pointer; -</pre></blockquote> - - - - - - -<hr> -<h3><a name="684"></a>684. Unclear which members of match_results should be used in comparison</h3> -<p><b>Section:</b> 28.10 [re.results] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> - <b>Submitter:</b> Nozomu Katoo <b>Date:</b> 2007-05-27</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re.results">active issues</a> in [re.results].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.results">issues</a> in [re.results].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p> -<p><b>Discussion:</b></p> -<p> -In 28.4 [re.syn] of N2284, two template functions -are declared here: -</p> -<blockquote><pre>// 28.10, class template match_results: - <<i>snip</i>> -// match_results comparisons - template <class BidirectionalIterator, class Allocator> - bool operator== (const match_results<BidirectionalIterator, Allocator>& m1, - const match_results<BidirectionalIterator, Allocator>& m2); - template <class BidirectionalIterator, class Allocator> - bool operator!= (const match_results<BidirectionalIterator, Allocator>& m1, - const match_results<BidirectionalIterator, Allocator>& m2); - -// 28.10.6, match_results swap: -</pre></blockquote> - -<p> -But the details of these two bool operator functions (i.e., which members of -<tt>match_results</tt> should be used in comparison) are not described in any -following sections. -</p> - <p><i>[ -John adds: +Voted to WP in Bellevue. ]</i></p> -<blockquote><p> -That looks like a bug: <tt>operator==</tt> should return <tt>true</tt> only if -the two objects refer to the same match - ie if one object was constructed as a -copy of the other. -</p></blockquote> - <p><i>[ -Kona (2007): Bill and Pete to add minor wording to that proposed in -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>. +post Bellevue, Pete notes: ]</i></p> - -<p><b>Proposed resolution:</b></p> -<p> -Add a new section after 28.10.6 [re.results.swap], which reads: -</p> -<p> -28.10.7 match_results non-member functions. -</p> - -<blockquote> -<pre>template<class BidirectionalIterator, class Allocator> - bool operator==(const match_results<BidirectionalIterator, Allocator>& m1, - const match_results<BidirectionalIterator, Allocator>& m2); -</pre> -<blockquote> -<p> -<i>Returns:</i> <tt>true</tt> only if the two objects refer to the same match. -</p> -</blockquote> -</blockquote> - -<blockquote> -<pre>template<class BidirectionalIterator, class Allocator> - bool operator!=(const match_results<BidirectionalIterator, Allocator>& m1, - const match_results<BidirectionalIterator, Allocator>& m2); -</pre> <blockquote> <p> -<i>Returns:</i> <tt>!(m1 == m2)</tt>. +Please remind people who are reviewing issues to check that the text +modifications match the current draft. Issue 676, for example, adds two +overloads for unordered_map::insert taking a hint. One takes a +const_iterator and returns a const_iterator, and the other takes an +iterator and returns an iterator. This was correct at the time the issue +was written, but was changed in Toronto so there is only one hint +overload, taking a const_iterator and returning an iterator. </p> -</blockquote> -</blockquote> - -<blockquote> -<pre>template<class BidirectionalIterator, class Allocator> - void swap(match_results<BidirectionalIterator, Allocator>& m1, - match_results<BidirectionalIterator, Allocator>& m2); -</pre> -<blockquote> <p> -<i>Returns:</i> <tt>m1.swap(m2)</tt>. +This issue is not ready. In addition to the relatively minor signature +problem I mentioned earlier, it puts requirements in the wrong places. +Instead of duplicating requirements throughout the template +specifications, it should put them in the front matter that talks about +requirements for unordered containers in general. This presentation +problem is editorial, but I'm not willing to do the extensive rewrite +that it requires. Please put it back into Open status. </p> </blockquote> -</blockquote> - <hr> <h3><a name="685"></a>685. reverse_iterator/move_iterator difference has invalid signatures</h3> -<p><b>Section:</b> 24.4.1.3.19 [reverse.iter.opdiff], 24.4.3.3.14 [move.iter.nonmember] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> +<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#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> In C++03 the difference between two <tt>reverse_iterators</tt> @@ -10855,8 +9531,8 @@ In the current draft, the operator is defined as 24.4.1.3.19 [reverse.iter.opdif </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); + 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 @@ -10882,13 +9558,8 @@ Change the synopsis in 24.4.1.1 [reverse.iterator]: <pre>template <class Iterator1, class Iterator2> <del>typename reverse_iterator<Iterator>::difference_type</del> <ins>auto</ins> operator-( const reverse_iterator<Iterator1>& x, - const reverse_iterator<Iterator2>& y)<ins> -> decltype(operator-(Iterator1, Iterator2))</ins>; + 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> @@ -10899,7 +9570,7 @@ Change 24.4.1.3.19 [reverse.iter.opdiff]: <pre>template <class Iterator1, class Iterator2> <del>typename reverse_iterator<Iterator>::difference_type</del> <ins>auto</ins> operator-( const reverse_iterator<Iterator1>& x, - const reverse_iterator<Iterator2>& y)<ins> -> decltype(operator-(Iterator1, Iterator2))</ins>; + const reverse_iterator<Iterator2>& y)<ins> -> decltype(y.current - x.current)</ins>; </pre> <blockquote> <p> @@ -10917,13 +9588,8 @@ Change the synopsis in 24.4.3.1 [move.iterator]: <pre>template <class Iterator1, class Iterator2> <del>typename move_iterator<Iterator>::difference_type</del> <ins>auto</ins> operator-( const move_iterator<Iterator1>& x, - const move_iterator<Iterator2>& y)<ins> -> decltype(operator-(Iterator1, Iterator2))</ins>; + const move_iterator<Iterator2>& y)<ins> -> decltype(x.base() - y.base())</ins>; </pre> -<blockquote> -<p> -<i>Returns:</i> <tt>y.current - x.current</tt>. -</p> -</blockquote> </blockquote> <p> @@ -10934,7 +9600,7 @@ Change 24.4.3.3.14 [move.iter.nonmember]: <pre>template <class Iterator1, class Iterator2> <del>typename move_iterator<Iterator>::difference_type</del> <ins>auto</ins> operator-( const move_iterator<Iterator1>& x, - const move_iterator<Iterator2>& y)<ins> -> decltype(operator-(Iterator1, Iterator2))</ins>; + const move_iterator<Iterator2>& y)<ins> -> decltype(x.base() - y.base())</ins>; </pre> <blockquote> <p> @@ -10943,122 +9609,23 @@ Change 24.4.3.3.14 [move.iter.nonmember]: </blockquote> </blockquote> - - - - -<hr> -<h3><a name="686"></a>686. Unique_ptr and shared_ptr fail to specify non-convertibility to int for unspecified-bool-type</h3> -<p><b>Section:</b> 20.6.5.2.4 [unique.ptr.single.observers], 20.6.6.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> - <b>Submitter:</b> Beman Dawes <b>Date:</b> 2007-06-14</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> -<p><b>Discussion:</b></p> -<p> -The standard library uses the <tt>operator <i>unspecified-bool-type</i>() const</tt> idiom in -five places. In three of those places (20.5.15.2.3 [func.wrap.func.cap], function capacity -for example) the returned value is constrained to disallow -unintended conversions to int. The standardese is -</p> -<blockquote><p> -The return type shall not be convertible to <tt>int</tt>. -</p></blockquote> -<p> -This constraint is omitted for <tt>unique_ptr</tt> and <tt>shared_ptr</tt>. It should be added for those. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -To the <i>Returns</i> paragraph for <tt>operator <i>unspecified-bool-type</i>() -const</tt> -of 20.6.5.2.4 [unique.ptr.single.observers] paragraph 11 and 20.6.6.2.5 -[util.smartptr.shared.obs] paragraph 16, add the sentence: -</p> -<blockquote><p> -The return type shall not be convertible to <tt>int</tt>. -</p></blockquote> - - <p><i>[ -Kona (2007): Uncertain if <tt>nullptr</tt> will address this issue. +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.6.2.1 [util.smartptr.shared.const], 20.6.6.3.1 [util.smartptr.weak.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -Since all conversions from <tt>shared_ptr<T></tt> to <tt>shared_ptr<U></tt> have the same -rank regardless of the relationship between <tt>T</tt> and <tt>U</tt>, reasonable user -code that works with raw pointers fails with <tt>shared_ptr</tt>: -</p> - -<blockquote><pre>void f( shared_ptr<void> ); -void f( shared_ptr<int> ); - -int main() -{ - f( shared_ptr<double>() ); // ambiguous -} -</pre></blockquote> - -<p> -Now that we officially have <tt>enable_if</tt>, we can constrain the constructor -and the corresponding assignment operator to only participate in the -overload resolution when the pointer types are compatible. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -In 20.6.6.2.1 [util.smartptr.shared.const], change: -</p> - -<blockquote><p> --14- <i>Requires:</i> <del>For the second constructor</del> <ins>The -second constructor shall not participate in the overload resolution -unless</ins> <tt>Y*</tt> <del>shall be</del> <ins>is implicitly</ins> convertible -to <tt>T*</tt>. -</p></blockquote> - -<p> -In 20.6.6.3.1 [util.smartptr.weak.const], change: -</p> - -<blockquote> -<pre><del>template<class Y> weak_ptr(shared_ptr<Y> const& r);</del> -<del>weak_ptr(weak_ptr const& r);</del> -<del>template<class Y> weak_ptr(weak_ptr<Y> const& r);</del> -<ins>weak_ptr(weak_ptr const& r);</ins> -<ins>template<class Y> weak_ptr(weak_ptr<Y> const& r);</ins> -<ins>template<class Y> weak_ptr(shared_ptr<Y> const& r);</ins> -</pre> -<blockquote><p> --4- <i>Requires:</i> <del>For</del> <del>t</del><ins>T</ins>he second and -third constructors<del>,</del> <ins>shall not participate in the -overload resolution unless</ins> <tt>Y*</tt> <del>shall be</del> -<ins>is implicitly</ins> convertible to <tt>T*</tt>. -</p></blockquote> -</blockquote> - - - - <hr> <h3><a name="688"></a>688. reference_wrapper, cref unsafe, allow binding to rvalues</h3> -<p><b>Section:</b> 20.5.5.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> +<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> <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#refwrap.const">active issues</a> in [refwrap.const].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#refwrap.const">issues</a> in [refwrap.const].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> <p><b>Discussion:</b></p> <p> A <tt>reference_wrapper</tt> can be constructed from an rvalue, either by using @@ -11076,60 +9643,13 @@ 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.5 [refwrap], add: +In 20.5 [function.objects], add the following two signatures to the synopsis: </p> -<blockquote><pre><ins>private:</ins> -<ins> explicit reference_wrapper(T&&);</ins> +<blockquote><pre>template <class T> void ref(const T&& t) = delete; +template <class T> void cref(const T&& t) = delete; </pre></blockquote> -<p> -In 20.5.5.1 [refwrap.const], add: -</p> - -<blockquote> -<pre><ins>explicit reference_wrapper(T&&);</ins> -</pre> -<blockquote><p> -<ins>-?- Not defined to disallow creating a <tt>reference_wrapper</tt> from an rvalue.</ins> -</p></blockquote> -</blockquote> - -<p> -In the synopsis of <tt><functional></tt> (20.5.5 [refwrap]), change the declarations -of <tt>ref</tt> and <tt>cref</tt> to: -</p> - -<blockquote><pre>template<class T> reference_wrapper<T> ref(T&<ins>&</ins>); -template<class T> reference_wrapper<const T> cref(<del>const</del> T&<ins>&</ins>); -</pre></blockquote> - -<p> -In 20.5.5.5 [refwrap.helpers], change: -</p> - -<blockquote> -<pre>template<class T> reference_wrapper<T> ref(T&<ins>&</ins> t); -</pre> -<blockquote> -<p> -<ins>-1- <i>Requires:</i> <tt>t</tt> shall be an lvalue.</ins> -</p> -</blockquote> -</blockquote> - -<p>and change:</p> - -<blockquote> -<pre>template<class T> reference_wrapper<const T> cref(<del>const</del> T&<ins>&</ins> t); -</pre> -<blockquote> -<p> -<ins>-6- <i>Requires:</i> <tt>t</tt> shall be an lvalue.</ins> -</p> -</blockquote> -</blockquote> - <p><i>[ @@ -11138,35 +9658,20 @@ addresses the first part of the resolution but not the second. ]</i></p> +<p><i>[ +Bellevue: Doug noticed problems with the current wording. +]</i></p> - -<hr> -<h3><a name="689"></a>689. reference_wrapper constructor overly constrained</h3> -<p><b>Section:</b> 20.5.5.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#refwrap.const">active issues</a> in [refwrap.const].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#refwrap.const">issues</a> in [refwrap.const].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -The constructor of <tt>reference_wrapper</tt> is currently <tt>explicit</tt>. The primary -motivation behind this is the safety problem with respect to rvalues, -which is addressed by the proposed resolution of the previous issue. -Therefore we should consider relaxing the requirements on the -constructor since requests for the implicit conversion keep resurfacing. -</p> -<p> -Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject. -</p> +<p><i>[ +post Bellevue: Howard and Peter provided revised wording. +]</i></p> -<p><b>Proposed resolution:</b></p> -<p> -Remove the <tt>explicit</tt> from the constructor of <tt>reference_wrapper</tt>. If the -proposed resolution of the previous issue is accepted, remove the -<tt>explicit</tt> from the <tt>T&&</tt> constructor as well to keep them in sync. -</p> +<p><i>[ +This resolution depends on a "favorable" resolution of CWG 606: that is, +the "special deduction rule" is disabled with the const T&& pattern. +]</i></p> @@ -11260,9 +9765,10 @@ 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> +<h3><a name="692"></a>692. <code>get_money</code> and <code>put_money</code> should be formatted I/O functions</h3> <p><b>Section:</b> 27.6.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ext.manip">active issues</a> in [ext.manip].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ext.manip">issues</a> in [ext.manip].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> <p><b>Discussion:</b></p> @@ -11270,15 +9776,15 @@ const_local_iterator cend(size_type n) const;</ins> In a private email Bill Plauger notes: </p> <blockquote><p> -I believe that the function that implements <code>get_money</code> +I believe that the function that implements <code>get_money</code> [from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2072.html">N2072</a>] -should behave as a formatted input function, and the function that -implements <code>put_money</code> should behave as a formatted output -function. This has implications regarding the skipping of whitespace +should behave as a formatted input function, and the function that +implements <code>put_money</code> should behave as a formatted output +function. This has implications regarding the skipping of whitespace and the handling of errors, among other things. </p> <p> -The words don't say that right now and I'm far from convinced that +The words don't say that right now and I'm far from convinced that such a change is editorial. </p></blockquote> <p> @@ -11291,19 +9797,19 @@ formatted I/O functions do. The text in N2072 assumes so but the of brevity. The spec should be clarified to that effect. </p> <p> -As for dealing with whitespace, I also agree it would make sense for -the extractors and inserters involving the new manipulators to treat +As for dealing with whitespace, I also agree it would make sense for +the extractors and inserters involving the new manipulators to treat it the same way as formatted I/O. </p></blockquote> <p><b>Proposed resolution:</b></p> <p> -Add a new paragraph immediately above p4 of 27.6.4 [ext.manip] with the +Add a new paragraph immediately above p4 of 27.6.4 [ext.manip] with the following text: </p> <blockquote><p> -<i>Effects</i>: The expression <code><i>in</i> >> get_money(mon, intl)</code> +<i>Effects</i>: The expression <code><i>in</i> >> get_money(mon, intl)</code> described below behaves as a formatted input function (as described in 27.6.1.2.1 [istream.formatted.reqmts]). </p></blockquote> @@ -11312,262 +9818,33 @@ Also change p4 of 27.6.4 [ext.manip] as follows: </p> <blockquote><p> <i>Returns</i>: An object <code>s</code> of unspecified type such that -if <code>in</code> is an object of type <code>basic_istream<charT, -traits></code> then the expression <code><i>in</i> >> get_money(mon, intl)</code> behaves as <ins>a formatted input function -that calls </ins><code>f(in, mon, intl)</code><del> were +if <code>in</code> is an object of type <code>basic_istream<charT, +traits></code> then the expression <code><i>in</i> >> get_money(mon, intl)</code> behaves as <ins>a formatted input function +that calls </ins><code>f(in, mon, intl)</code><del> were called</del>. The function <code>f</code> can be defined as... </p></blockquote> +<p><i>[ +post Bellevue: +]</i></p> - -<hr> -<h3><a name="693"></a>693. <code>std::bitset::all()</code> missing</h3> -<p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -The <code>bitset</code> class template provides the member function -<code>any()</code> to determine whether an object of the type has any -bits set, and the member function <code>none()</code> to determine -whether all of an object's bits are clear. However, the template does -not provide a corresponding function to discover whether a -<code>bitset</code> object has all its bits set. While it is -possible, even easy, to obtain this information by comparing the -result of <code>count()</code> with the result of <code>size()</code> -for equality (i.e., via <code>b.count() == b.size()</code>) the -operation is less efficient than a member function designed -specifically for that purpose could be. (<code>count()</code> must -count all non-zero bits in a <code>bitset</code> a word at a time -while <code>all()</code> could stop counting as soon as it encountered -the first word with a zero bit). -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Add a declaration of the new member function <code>all()</code> to the -defintion of the <code>bitset</code> template in 23.3.5 [template.bitset], p1, -right above the declaration of <code>any()</code> as shown below: -</p> - -<blockquote><pre>bool operator!=(const bitset<N>& rhs) const; -bool test(size_t pos) const; -<ins>bool all() const;</ins> -bool any() const; -bool none() const; -</pre></blockquote> - -<p> -Add a description of the new member function to the end of 23.3.5.2 [bitset.members] with the following text: -</p> -<blockquote><p> -<code>bool all() const;</code> -</p> -<blockquote> -<i>Returns</i>: <code>count() == size()</code>. -</blockquote> -</blockquote> - -<p> -In addition, change the description of <code>any()</code> and -<code>none()</code> for consistency with <code>all()</code> as -follows: -</p> -<blockquote><p> -<code>bool any() const;</code> -</p> -<blockquote> -<p> -<i>Returns</i>: <del><code>true</code> if any bit in <code>*this</code> -is one</del><ins><code>count() != 0</code></ins>. -</p> -</blockquote> -<p> -<code>bool none() const;</code> -</p> -<blockquote> -<p> -<i>Returns</i>: <del><code>true</code> if no bit in <code>*this</code> -is one</del><ins><code>count() == 0</code></ins>. -</p> -</blockquote> -</blockquote> - - - - - -<hr> -<h3><a name="694"></a>694. <code>std::bitset</code> and <code>long long</code></h3> -<p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -Objects of the <code>bitset</code> class template specializations can -be constructed from and explicitly converted to values of the widest -C++ integer type, <code>unsigned long</code>. With the introduction -of <code>long long</code> into the language the template should be -enhanced to make it possible to interoperate with values of this type -as well, or perhaps <code>uintmax_t</code>. See c++std-lib-18274 for -a brief discussion in support of this change. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -For simplicity, instead of adding overloads for <code>unsigned long -long</code> and dealing with possible ambiguities in the spec, replace -the <code>bitset</code> ctor that takes an <code>unsigned long</code> -argument with one taking <code>unsigned long long</code> in the -definition of the template as shown below. (The standard permits -implementations to add overloads on other integer types or employ -template tricks to achieve the same effect provided they don't cause -ambiguities or changes in behavior.) -</p> -<blockquote> -<pre>// [bitset.cons] constructors: -bitset(); -bitset(unsigned <ins>long</ins> long val); -template<class charT, class traits, class Allocator> -explicit bitset( - const basic_string<charT,traits,Allocator>& str, - typename basic_string<charT,traits,Allocator>::size_type pos = 0, - typename basic_string<charT,traits,Allocator>::size_type n = - basic_string<charT,traits,Allocator>::npos); -</pre> -</blockquote> -<p> -Make a corresponding change in 23.3.5.1 [bitset.cons], p2: -</p> -<blockquote> -<p> -<code>bitset(unsigned <ins>long</ins> long val);</code> -</p> -<blockquote> -<i>Effects</i>: Constructs an object of class bitset<N>, -initializing the first <code><i>M</i></code> bit positions to the -corresponding bit values in <code><i>val</i></code>. -<code><i>M</i></code> is the smaller of <code><i>N</i></code> and the -number of bits in the value representation (section [basic.types]) of -<code>unsigned <ins> long</ins> long</code>. If <code><i>M</i> < -<i>N</i></code> <ins>is <code>true</code></ins>, the remaining bit -positions are initialized to zero. -</blockquote> -</blockquote> - -<p> -Additionally, introduce a new member function <code>to_ullong()</code> -to make it possible to convert <code>bitset</code> to values of the -new type. Add the following declaration to the definition of the -template, immediate after the declaration of <code>to_ulong()</code> -in 23.3.5 [template.bitset], p1, as shown below: -</p> -<blockquote> -<pre>// element access: -bool operator[](size_t pos) const; // for b[i]; -reference operator[](size_t pos); // for b[i]; -unsigned long to_ulong() const; -<ins>unsigned long long to_ullong() const;</ins> -template <class charT, class traits, class Allocator> -basic_string<charT, traits, Allocator> to_string() const; -</pre> -</blockquote> -<p> -And add a description of the new member function to 23.3.5.2 [bitset.members], -below the description of the existing <code>to_ulong()</code> (if -possible), with the following text: -</p> -<blockquote> -<p> -<code>unsigned long long to_ullong() const;</code> -</p> -<blockquote> -<i>Throws</i>: <code>overflow_error</code> if the integral value -<code><i>x</i></code> corresponding to the bits in <code>*this</code> -cannot be represented as type <code>unsigned long long</code>. -</blockquote> -<blockquote> -<i>Returns:</i> <code><i>x</i></code>. -</blockquote> -</blockquote> - - - - - -<hr> -<h3><a name="695"></a>695. ctype<char>::classic_table() not accessible</h3> -<p><b>Section:</b> 22.2.1.3 [facet.ctype.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -The <code>ctype<char>::classic_table()</code> static member -function returns a pointer to an array of const -<code>ctype_base::mask</code> objects (enums) that contains -<code>ctype<char>::table_size</code> elements. The table -describes the properties of the character set in the "C" locale (i.e., -whether a character at an index given by its value is alpha, digit, -punct, etc.), and is typically used to initialize the -<code>ctype<char></code> facet in the classic "C" locale (the -protected <code>ctype<char></code> member function -<code>table()</code> then returns the same value as -<code>classic_table()</code>). -</p> -<p> -However, while <code>ctype<char>::table_size</code> (the size of -the table) is a public static const member of the -<code>ctype<char></code> specialization, the -<code>classic_table()</code> static member function is protected. That -makes getting at the classic data less than convenient (i.e., one has -to create a whole derived class just to get at the masks array). It -makes little sense to expose the size of the table in the public -interface while making the table itself protected, especially when the -table is a constant object. -</p> -<p> -The same argument can be made for the non-static protected member -function <code>table()</code>. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Make the <code>ctype<char>::classic_table()</code> and -<code>ctype<char>::table()</code> member functions public by -moving their declarations into the public section of the definition of -specialization in 22.2.1.3 [facet.ctype.special] as shown below: -</p> <blockquote> -<pre> static locale::id id; - static const size_t table_size = IMPLEMENTATION_DEFINED; -<del>protected:</del> - const mask* table() const throw(); - static const mask* classic_table() throw(); -<ins>protected:</ins> - -~ctype(); // virtual -virtual char do_toupper(char c) const; -</pre> +We recommend moving immediately to Review. We've looked at the issue and +have a consensus that the proposed resolution is correct, but want an +iostream expert to sign off. Alisdair has taken the action item to putt +this up on the reflector for possible movement by Howard to Tenatively +Ready. </blockquote> - <hr> <h3><a name="696"></a>696. <code>istream::operator>>(int&)</code> broken</h3> <p><b>Section:</b> 27.6.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-23</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.formatted.arithmetic">active issues</a> in [istream.formatted.arithmetic].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> <p><b>Discussion:</b></p> @@ -11614,66 +9891,6 @@ prevent the facet from storing the value. <hr> -<h3><a name="697"></a>697. New <tt><system_error></tt> header leads to name clashes</h3> -<p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> - <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-06-24</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> -<p><b>Discussion:</b></p> -<p> -The most recent state of -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html">N2241</a> -as well as the current draft -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a> -(section 19.4 [syserr], p.2) proposes a -new -enumeration type <tt>posix_errno</tt> immediatly in the namespace <tt>std</tt>. One of -the enumerators has the name <tt>invalid_argument</tt>, or fully qualified: -<tt>std::invalid_argument</tt>. This name clashes with the exception type -<tt>std::invalid_argument</tt>, see 19.1 [std.exceptions]/p.3. This clash makes -e.g. the following snippet invalid: -</p> - -<blockquote><pre>#include <system_error> -#include <stdexcept> - -void foo() { throw std::invalid_argument("Don't call us - we call you!"); } -</pre></blockquote> - -<p> -I propose that this enumeration type (and probably the remaining parts -of -<tt><system_error></tt> as well) should be moved into one additional inner -namespace, e.g. <tt>sys</tt> or <tt>system</tt> to reduce foreseeable future clashes -due -to the great number of members that <tt>std::posix_errno</tt> already contains -(Btw.: Why has the already proposed <tt>std::sys</tt> sub-namespace from -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2066.html">N2066</a> -been rejected?). A further clash <em>candidate</em> seems to be -<tt>std::protocol_error</tt> -(a reasonable name for an exception related to a std network library, -I guess). -</p> - -<p> -Another possible resolution would rely on the proposed strongly typed -enums, -as described in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2213.pdf">N2213</a>. -But maybe the forbidden implicit conversion to integral types would -make -these enumerators less attractive in this special case? -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -</p> - - - - - - -<hr> <h3><a name="698"></a>698. Some system_error issues</h3> <p><b>Section:</b> 19.4.5.1 [syserr.syserr.overview] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-06-24</p> @@ -11706,50 +9923,6 @@ accepting a <tt>const char*</tt>. <hr> -<h3><a name="700"></a>700. N1856 defines struct <tt>identity</tt></h3> -<p><b>Section:</b> 20.2.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2007-07-01</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a> -defines struct <tt>identity</tt> in <tt><utility></tt> which clashes with -the traditional definition of struct <tt>identity</tt> in <tt><functional></tt> -(not standard, but a common extension from old STL). Be nice -if we could avoid this name clash for backward compatibility. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Change 20.2.2 [forward]: -</p> - -<blockquote> -<pre>template <class T> struct identity -{ - typedef T type; - <ins>const T& operator()(const T& x) const;</ins> -}; -</pre> -<blockquote> -<pre><ins>const T& operator()(const T& x) const;</ins> -</pre> -<blockquote> -<p> -<ins><i>Returns:</i> <tt>x</tt>.</ins> -</p> -</blockquote> -</blockquote> - -</blockquote> - - - - - - -<hr> <h3><a name="701"></a>701. assoc laguerre poly's</h3> <p><b>Section:</b> TR1 5.2.1.1 [tr.num.sf.Lnm] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Christopher Crawford <b>Date:</b> 2007-06-30</p> @@ -11761,11 +9934,11 @@ polynomials TR1 5.2.1.1 [tr.num.sf.Lnm] has been corrected since <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1687.pdf">N1687</a>. However, the draft standard only specifies ranks of integer value <tt>m</tt>, while the associated Laguerre polynomials are actually valid for real -values of <tt>m > -1</tt>. In the case of non-integer values of <tt>m</tt>, the -definition <tt><i>L</i><sub>n</sub><sup>(m)</sup> = (1/n!)e<sup>x</sup>x<sup>-m</sup> (d/dx)<sup>n</sup> (e<sup>-x</sup>x<sup>m+n</sup>)</tt> -must be used, which also holds for integer values of <tt>m</tt>. See +values of <tt>m > -1</tt>. In the case of non-integer values of <tt>m</tt>, the +definition <tt><i>L</i><sub>n</sub><sup>(m)</sup> = (1/n!)e<sup>x</sup>x<sup>-m</sup> (d/dx)<sup>n</sup> (e<sup>-x</sup>x<sup>m+n</sup>)</tt> +must be used, which also holds for integer values of <tt>m</tt>. See Abramowitz & Stegun, 22.11.6 for the general case, and 22.5.16-17 for -the integer case. In fact fractional values are most commonly used in +the integer case. In fact fractional values are most commonly used in physics, for example to <tt>m = +/- 1/2</tt> to describe the harmonic oscillator in 1 dimension, and <tt>1/2, 3/2, 5/2, ...</tt> in 3 dimensions. @@ -11773,7 +9946,7 @@ dimensions. <p> If I am correct, the calculation of the more general case is no more difficult, and is in fact the function implemented in the GNU -Scientific Library. I would urge you to consider upgrading the +Scientific Library. I would urge you to consider upgrading the standard, either adding extra functions for real <tt>m</tt> or switching the current ones to <tt>double</tt>. </p> @@ -11794,7 +9967,7 @@ current ones to <tt>double</tt>. <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> <p><b>Discussion:</b></p> <p> -One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should be +One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should be <tt>|x| <= 1</tt>, not <tt>x >= 0</tt>.</p> @@ -11807,32 +9980,6 @@ One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should&nb <hr> -<h3><a name="703"></a>703. <tt>map::at()</tt> need a complexity specification</h3> -<p><b>Section:</b> 23.3.1.2 [map.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-07-03</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map.access">issues</a> in [map.access].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -<tt>map::at()</tt> need a complexity specification. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Add the following to the specification of <tt>map::at()</tt>, 23.3.1.2 [map.access]: -</p> -<blockquote> -<p> -<i>Complexity:</i> logarithmic. -</p> -</blockquote> - - - - - -<hr> <h3><a name="704"></a>704. MoveAssignable requirement for container value type overly strict</h3> <p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-20</p> @@ -11970,108 +10117,14 @@ Kona (2007): Howard and Alan to update requirements table in issue with emplace ]</i></p> +<p><i>[ +Bellevue: This should be handled as part of the concepts work. +]</i></p> -<p><b>Proposed resolution:</b></p> - - - - - - -<hr> -<h3><a name="705"></a>705. type-trait <tt>decay</tt> incompletely specified</h3> -<p><b>Section:</b> 20.4.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2007-07-08</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -The current working draft has a type-trait <tt>decay</tt> in 20.4.7 [meta.trans.other]. -</p> - -<p> -Its use is to turn C++03 pass-by-value parameters into efficient C++0x -pass-by-rvalue-reference parameters. However, the current definition -introduces an incompatible change where the cv-qualification of the -parameter type is retained. The deduced type should loose such -cv-qualification, as pass-by-value does. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -In 20.4.7 [meta.trans.other] change the last sentence: -</p> - -<blockquote><p> -Otherwise the member typedef <tt>type</tt> equals <tt><ins>remove_cv<</ins>U<ins>>::type</ins></tt>. -</p></blockquote> - -<p> -In 20.3.1.2 [tuple.creation]/1 change: -</p> - -<blockquote><p> -<del>where each <tt>Vi</tt> in <tt>VTypes</tt> is <tt>X&</tt> if, for the -corresponding type <tt>Ti</tt> in <tt>Types</tt>, -<tt>remove_cv<remove_reference<Ti>::type>::type</tt> equals -<tt>reference_wrapper<X></tt>, otherwise <tt>Vi</tt> is -<tt>decay<Ti>::type</tt>.</del> -<ins>Let <tt>Ui</tt> be <tt>decay<Ti>::type</tt> for each -<tt>Ti</tt> in <tt>Types</tt>. Then each <tt>Vi</tt> in <tt>VTypes</tt> -is <tt>X&</tt> if <tt>Ui</tt> equals -<tt>reference_wrapper<X></tt>, otherwise <tt>Vi</tt> is -<tt>Ui</tt>.</ins> -</p></blockquote> - - - - - - -<hr> -<h3><a name="706"></a>706. <tt>make_pair()</tt> should behave as <tt>make_tuple()</tt> wrt. <tt>reference_wrapper()</tt></h3> -<p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> - <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2007-07-08</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p> -<p><b>Discussion:</b></p> -<p> -The current draft has <tt>make_pair()</tt> in 20.2.3 [pairs]/16 -and <tt>make_tuple()</tt> in 20.3.1.2 [tuple.creation]. -<tt>make_tuple()</tt> detects the presence of -<tt>reference_wrapper<X></tt> arguments and "unwraps" the reference in -such cases. <tt>make_pair()</tt> would OTOH create a -<tt>reference_wrapper<X></tt> member. I suggest that the two -functions are made to behave similar in this respect to minimize -confusion. -</p> <p><b>Proposed resolution:</b></p> -<p> -In 20.2 [utility] change the synopsis for make_pair() to read -</p> - -<blockquote><pre>template <class T1, class T2> - pair<<del>typename decay<T1>::type</del> <ins>V1</ins>, <del>typename decay<T2>::type</del> <ins>V2</ins>> make_pair(T1&&, T2&&); -</pre></blockquote> - -<p> -In 20.2.3 [pairs]/16 change the declaration to match the above synopsis. -Then change the 20.2.3 [pairs]/17 to: -</p> - -<blockquote> -<p> -<i>Returns:</i> <tt>pair<<del>typename decay<T1>::type</del> <ins>V1</ins>,<del>typename decay<T2>::type</del> <ins>V2</ins>>(forward<T1>(x),forward<T2>(y))</tt> <ins>where <tt>V1</tt> and -<tt>V2</tt> are determined as follows: Let <tt>Ui</tt> be -<tt>decay<Ti>::type</tt> for each <tt>Ti</tt>. Then each -<tt>Vi</tt> is <tt>X&</tt> if <tt>Ui</tt> equals -<tt>reference_wrapper<X></tt>, otherwise <tt>Vi</tt> is -<tt>Ui</tt>.</ins> -</p> -</blockquote> @@ -12079,45 +10132,6 @@ Then change the 20.2.3 [pairs]/17 to: <hr> -<h3><a name="707"></a>707. null pointer constant for <tt>exception_ptr</tt></h3> -<p><b>Section:</b> 18.7.1 [exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> - <b>Submitter:</b> Jens Maurer <b>Date:</b> 2007-07-20</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> -<p><b>Discussion:</b></p> - -<p> -From the Toronto Core wiki: -</p> - -<p> -What do you mean by "null pointer constant"? How do you guarantee that -<tt>exception_ptr() == 1</tt> doesn't work? Do you even want to prevent that? -What's the semantics? What about <tt>void *p = 0; exception_ptr() == p</tt>? -Maybe disallow those in the interface, but how do you do that with -portable C++? Could specify just "make it work". -</p> - -<p> -Peter's response: -</p> - -<p> -null pointer constant as defined in 4.10 [conv.ptr]. Intent is "just make it -work", can be implemented as assignment operator taking a unique pointer -to member, as in the unspecified bool type idiom. -</p> - - - -<p><b>Proposed resolution:</b></p> -<p> -</p> - - - - - -<hr> <h3><a name="708"></a>708. Locales need to be per thread and updated for POSIX changes</h3> <p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-07-28</p> @@ -12168,59 +10182,12 @@ Kona (2007): Bill and Nick to provide wording. <hr> -<h3><a name="709"></a>709. <tt>char_traits::not_eof</tt> has wrong signature</h3> -<p><b>Section:</b> 21.1.3 [char.traits.specializations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> - <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-13</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> -<p><b>Discussion:</b></p> -<p> -The changes made for <tt>constexpr</tt> in 21.1.3 [char.traits.specializations] have -not only changed the <tt>not_eof</tt> function from pass by const reference to -pass by value, it has also changed the parameter type from <tt>int_type</tt> to -<tt>char_type</tt>. -</p> -<p> -This doesn't work for type <tt>char</tt>, and is inconsistent with the -requirements in Table 56, Traits requirements, 21.1.1 [char.traits.require]. -</p> - -<p> -Pete adds: -</p> - -<blockquote><p> -For what it's worth, that may not have been an intentional change. -N2349, which detailed the changes for adding constant expressions to -the library, has strikeout bars through the <tt>const</tt> and the <tt>&</tt> that -surround the <tt>char_type</tt> argument, but none through <tt>char_type</tt> itself. -So the intention may have been just to change to pass by value, with -text incorrectly copied from the standard. -</p></blockquote> - - - -<p><b>Proposed resolution:</b></p> -<p> -Change the signature in 21.1.3.1 [char.traits.specializations.char], -21.1.3.2 [char.traits.specializations.char16_t], 21.1.3.3 [char.traits.specializations.char32_t], -and 21.1.3.4 [char.traits.specializations.wchar.t] to -</p> - -<blockquote><pre>static constexpr int_type not_eof(<del>char_type</del> <ins>int_type</ins> c); -</pre></blockquote> - - - - - - -<hr> <h3><a name="710"></a>710. Missing postconditions</h3> -<p><b>Section:</b> 20.6.6.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<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#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 discussion on @@ -12230,10 +10197,27 @@ 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.6.6.2.1 [util.smartptr.shared.const]: +Add to 20.6.12.2.1 [util.smartptr.shared.const]: </p> <blockquote> @@ -12249,7 +10233,7 @@ shall be empty. <ins><tt>r.get() == 0</tt>.</ins> </blockquote> <p> -Add to 20.6.6.2.10 [util.smartptr.shared.cast]: +Add to 20.6.12.2.10 [util.smartptr.shared.cast]: </p> <blockquote> @@ -12292,7 +10276,7 @@ the aliasing constructor as follows: </p> <p> -Change 20.6.6.2.10 [util.smartptr.shared.cast]: +Change 20.6.12.2.10 [util.smartptr.shared.cast]: </p> <blockquote> @@ -12339,10 +10323,10 @@ in the aliasing constructor postcondition "by reference". <hr> <h3><a name="711"></a>711. Contradiction in empty <tt>shared_ptr</tt></h3> -<p><b>Section:</b> 20.6.6.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<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> <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-08-24</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.obs">issues</a> in [util.smartptr.shared.obs].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>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 @@ -12371,7 +10355,7 @@ with a non-NULL stored pointer. </p> <p> -This is contradicted by the second sentence in the Returns clause of 20.6.6.2.5 [util.smartptr.shared.obs]: +This is contradicted by the second sentence in the Returns clause of 20.6.12.2.5 [util.smartptr.shared.obs]: </p> <blockquote> @@ -12382,11 +10366,34 @@ This is contradicted by the second sentence in the Returns clause of 20.6.6.2.5 </p></blockquote> </blockquote> +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +Adopt option 1 and move to review, not ready. +</p> +<p> +There was a lot of confusion about what an empty <tt>shared_ptr</tt> is (the term +isn't defined anywhere), and whether we have a good mental model for how +one behaves. We think it might be possible to deduce what the definition +should be, but the words just aren't there. We need to open an issue on +the use of this undefined term. (The resolution of that issue might +affect the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>.) +</p> +<p> +The LWG is getting more uncomfortable with the aliasing proposal (N2351) +now that we realize some of its implications, and we need to keep an eye +on it, but there isn't support for removing this feature at this time. +</p> +</blockquote> <p><b>Proposed resolution:</b></p> <p> -In keeping the N2351 spirit and obviously my preference, change 20.6.6.2.5 [util.smartptr.shared.obs]: +In keeping the N2351 spirit and obviously my preference, change 20.6.12.2.5 [util.smartptr.shared.obs]: </p> <blockquote> @@ -12402,7 +10409,7 @@ Alternative proposed resolution: (I won't be happy if we do this, but it's possi </p> <p> -Change 20.6.6.2.1 [util.smartptr.shared.const]: +Change 20.6.12.2.1 [util.smartptr.shared.const]: </p> <blockquote> @@ -12517,10 +10524,11 @@ 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#New">New</a> +<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#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>minmax_element</tt> (25.3.7 [alg.min.max] par 16) says "At most <tt>max(2 * @@ -12549,12 +10557,11 @@ template<class ForwardIterator, class Compare> <p> <i>Returns:</i> <tt>make_pair(m, M)</tt>, where <tt>m</tt> is <del><tt>min_element(first, last)</tt> or <tt>min_element(first, last, -comp)</tt></del> <ins>the first iterator <tt>i</tt> in <tt>[first, -last)</tt> such that no other element in the range is smaller,</ins> and +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 -<tt>i</tt> in <tt>[first, last)</tt> such that no other element in the -range is larger</ins>. +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> @@ -12616,72 +10623,12 @@ Remove this mention of the CharacterClass production. <hr> -<h3><a name="717"></a>717. Incomplete <tt>valarray::operator[]</tt> specification in [valarray.access]</h3> -<p><b>Section:</b> 26.5.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> - <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-27</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.access">issues</a> in [valarray.access].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> -<p><b>Discussion:</b></p> -<p> -Since the return type of <tt>valarray</tt>'s <tt>operator[] const</tt> overload has been -changed to <tt>const T&</tt> as described in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> several paragraphs of -the section 26.5.2.3 [valarray.access] are now -incompletely -specified, because many requirements and guarantees should now also -apply to the const overload. Most notably, the address and reference -guarantees should be extended to the const overload case. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Change 26.5.2.3 [valarray.access]: -</p> - -<blockquote> -<p> --1- <del>When applied to a constant array, the subscript operator returns a -reference to the corresponding element of the array. When applied to a -non-constant array, t</del><ins>T</ins>he subscript operator returns a -reference to the corresponding element of the array. -</p> - -<p> --3- The expression <tt>&a[i+j] == &a[i] + j</tt> evaluates as <tt>true</tt> for all <tt>size_t i</tt> -and <tt>size_t j</tt> such that <tt>i+j</tt> is less -than the length of the <del>non-constant</del> array <tt>a</tt>. -</p> - -<p> --4- Likewise, the expression <tt>&a[i] != &b[j]</tt> evaluates -as <tt>true</tt> for any two <del>non-constant</del> arrays <tt>a</tt> and -<tt>b</tt> and for any <tt>size_t i</tt> and <tt>size_t j</tt> such that -<tt>i</tt> is less than the length of <tt>a</tt> and <tt>j</tt> is less -than the length of <tt>b</tt>. This property indicates an absence of -aliasing and may be used to advantage by optimizing -compilers.<sup>281)</sup> -</p> - -<p> --5- The reference returned by the subscript operator for a<ins>n</ins> <del>non-constant</del> array is guaranteed to be valid until -the member function <tt>resize(size_t, T)</tt> (26.5.2.7) is called for that array or until the lifetime -of that array ends, whichever happens first. -</p> - -</blockquote> - - - - - - -<hr> <h3><a name="718"></a>718. <tt>basic_string</tt> is not a sequence</h3> -<p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-18</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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 21.3 [basic.string]/3 states: @@ -12701,6 +10648,33 @@ Secondly, after the resent changes to containers (<tt>emplace</tt>, <tt>push_bac even close to conform to the current requirements. </p> +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<ul> +<li>emplace, for example, may not make sense for strings. Is also likely suboptimal</li> +<li>with concepts do we need to maintain string as sequence container?</li> +<li>One approach might be to say something like: string is a sequence except it doesn't have these functions</li> +</ul> +<ul> +<li>basic_string already has push_back</li> +<li>const_iterator parameters to insert and erase should be added to basic_string</li> +<li>this leaves emplace to handle -- we have the following options: +<ul> +<li>option 1: add it to string even though it's optional</li> +<li>option 2: make emplace optional to sequences (move from table 89 to 90)</li> +<li>option 3: say string not sequence (the proposal),</li> +<li>option 4: add an exception to basic string wording.</li> +</ul> +</li> +</ul> +General consensus is to suggest option 2. +</blockquote> + + <p><b>Proposed resolution:</b></p> <p> @@ -12715,10 +10689,10 @@ 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#New">New</a> +<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> <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-25</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta">issues</a> in [meta].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> <p><b>Discussion:</b></p> <p> Since the inclusion of <tt>constexpr</tt> in the standard draft N2369 we have @@ -12796,6 +10770,14 @@ reference type (instead of <tt>const T&</tt> we could decide to use <tt>T&&</tt>, but that is another issue). </p> +<p><i>[ +Alisdair is considering preparing a paper listing a number of missing +type traits, and feels that it might be useful to handle them all +together rather than piecemeal. This would affect issue 719 and 750. +These two issues should move to OPEN pending AM paper on type traits. +]</i></p> + + <p><b>Proposed resolution:</b></p> @@ -12839,11 +10821,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#New">New</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#Open">Open</a> <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-08-25</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> <p><b>Discussion:</b></p> <ol> <li> @@ -12936,11 +10918,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#New">New</a> +<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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#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 listing of 26.7 [c.math], table 108: Header <tt><cmath></tt> synopsis I miss @@ -13080,11 +11062,11 @@ to describe these additions. <hr> <h3><a name="724"></a>724. <tt>DefaultConstructible</tt> is not defined</h3> -<p><b>Section:</b> 20.1.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 20.1.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Pablo Halpern <b>Date:</b> 2007-09-12</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> <p><b>Discussion:</b></p> <p> The <tt>DefaultConstructible</tt> requirement is referenced in @@ -13093,6 +11075,43 @@ several places in the August 2007 working draft but is not defined anywhere. </p> +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +Walking into the default/value-initialization mess... +</p> +<p> +Why two lines? Because we need both expressions to be valid. +</p> +<p> +AJM not sure what the phrase "default constructed" means. This is +unfortunate, as the phrase is already used 24 times in the library! +</p> +<p> +Example: const int would not accept first line, but will accept the second. +</p> +<p> +This is an issue that must be solved by concepts, but we might need to solve it independantly first. +</p> +<p> +It seems that the requirements are the syntax in the proposed first +column is valid, but not clear what semantics we need. +</p> +<p> +A table where there is no post-condition seems odd, but appears to sum up our position best. +</p> +<p> +At a minimum an object is declared and is destuctible. +</p> +<p> +Move to open, as no-one happy to produce wording on the fly. +</p> +</blockquote> + <p><b>Proposed resolution:</b></p> <p> @@ -13134,42 +11153,6 @@ following table: <hr> -<h3><a name="725"></a>725. Optional sequence container requirements column label</h3> -<p><b>Section:</b> 23.1.1 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> - <b>Submitter:</b> David Abrahams <b>Date:</b> 2007-09-16</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> -<p><b>Discussion:</b></p> -<p> -Table 90: (Optional sequence container operations) states the -"assertion note pre/post-condition" of <tt>operator[]</tt> to be -</p> - -<blockquote><pre>*(a.begin() + n) -</pre></blockquote> - -<p> -Surely that's meant to be "operational semantics?" -</p> - - - -<p><b>Proposed resolution:</b></p> -<blockquote> -<table border="1"> -<caption>Table 90: Optional sequence container operations</caption> -<tbody><tr> -<th>expression</th> <th>return type</th> <th><del>assertion/note<br>pre/post-condition</del><br> <ins>operational semantics</ins></th> <th>container</th> -</tr> -</tbody></table> -</blockquote> - - - - - - -<hr> <h3><a name="726"></a>726. Missing <tt>regex_replace()</tt> overloads</h3> <p><b>Section:</b> 28.11.4 [re.alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2007-09-22</p> @@ -13190,7 +11173,7 @@ Two overloads of <tt>regex_replace()</tt> are currently provided: const basic_string<charT>& fmt, regex_constants::match_flag_type flags = regex_constants::match_default); - + template <class traits, class charT> basic_string<charT> regex_replace(const basic_string<charT>& s, @@ -13202,7 +11185,7 @@ template <class traits, class charT> <ol> <li>Overloads taking <tt>const charT *</tt> are provided for <tt>regex_match()</tt> and -<tt>regex_search()</tt>, but not <tt>regex_replace()</tt>. This is inconsistent.</li> +<tt>regex_search()</tt>, but not <tt>regex_replace()</tt>. This is inconsistent.</li> <li> <p>The absence of <tt>const charT *</tt> overloads prevents ordinary-looking code from compiling, such as:</p> @@ -13219,9 +11202,9 @@ char[1]'". <p> Users expect that anything taking a <tt>basic_string<charT></tt> can also take a -<tt>const charT *</tt>. In their own code, when they write a function taking +<tt>const charT *</tt>. In their own code, when they write a function taking <tt>std::string</tt> (or <tt>std::wstring</tt>), they can pass a <tt>const char *</tt> (or <tt>const -wchar_t *</tt>), thanks to <tt>basic_string</tt>'s implicit constructor. Because the +wchar_t *</tt>), thanks to <tt>basic_string</tt>'s implicit constructor. Because the regex algorithms are templated on <tt>charT</tt>, they can't rely on <tt>basic_string</tt>'s implicit constructor (as the compiler error message indicates, template argument deduction fails first). @@ -13229,10 +11212,10 @@ indicates, template argument deduction fails first). <p> If a user figures out what the compiler error message means, workarounds -are available - but they are all verbose. Explicit template arguments +are available - but they are all verbose. Explicit template arguments could be given to <tt>regex_replace()</tt>, allowing <tt>basic_string</tt>'s implicit constructor to be invoked - but <tt>charT</tt> is the last template argument, not -the first, so this would be extremely verbose. Therefore, constructing +the first, so this would be extremely verbose. Therefore, constructing a <tt>basic_string</tt> from each C string is the simplest workaround. </p> </li> @@ -13240,7 +11223,7 @@ a <tt>basic_string</tt> from each C string is the simplest workaround. <li> There is an efficiency consideration: constructing <tt>basic_string</tt>s can impose performance costs that could be avoided by a library -implementation taking C strings and dealing with them directly. +implementation taking C strings and dealing with them directly. (Currently, for replacement sources, C strings can be converted into iterator pairs at the cost of verbosity, but for format strings, there is no way to avoid constructing a <tt>basic_string</tt>.) @@ -13329,7 +11312,7 @@ charT* str</tt> and <tt>const charT* fmt</tt>). 28.11.4 [re.alg.replace]: <p><b>Discussion:</b></p> <p> <tt>regex_match()</tt> and <tt>regex_search()</tt> take <tt>const basic_string<charT, ST, -SA>&</tt>. <tt>regex_replace()</tt> takes <tt>const basic_string<charT>&</tt>. This prevents +SA>&</tt>. <tt>regex_replace()</tt> takes <tt>const basic_string<charT>&</tt>. This prevents <tt>regex_replace()</tt> from accepting <tt>basic_string</tt>s with custom traits and allocators. </p> @@ -13339,7 +11322,7 @@ allocators. <p> Overloads of <tt>regex_replace()</tt> taking <tt>basic_string</tt> should be additionally templated on <tt>class ST, class SA</tt> and take <tt>const basic_string<charT, ST, -SA>&</tt>. Consistency with <tt>regex_match()</tt> and <tt>regex_search()</tt> would place +SA>&</tt>. Consistency with <tt>regex_match()</tt> and <tt>regex_search()</tt> would place <tt>class ST, class SA</tt> as the first template arguments; compatibility with existing code using TR1 and giving explicit template arguments to <tt>regex_replace()</tt> would place <tt>class ST, class SA</tt> as the last template @@ -13352,9 +11335,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#New">New</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#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#New">New</a> status.</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>Discussion:</b></p> <p> The <tt>mersenne_twister_engine</tt> is required to use a seeding method that is given @@ -13379,184 +11363,66 @@ order) and always employ the 32-bit algorithm for seeding </ol> <p> -See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a> for further discussion. </p> +<p><i>[ +Bellevue: +]</i></p> -<p><b>Proposed resolution:</b></p> - -<p> -See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> -for the proposed resolution. -</p> - - - - - - -<hr> -<h3><a name="729"></a>729. Problem in [rand.req.eng]/3</h3> -<p><b>Section:</b> 26.4.1.3 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> - <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req.eng">issues</a> in [rand.req.eng].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> -<p><b>Discussion:</b></p> -<p> -The 3rd table row in 26.4.1.3 [rand.req.eng]/3 requires random number engines to accept any -arithmetic type as a seed, which is then casted to the engine's <tt>result_type</tt> and subsequently -used for seeding the state of the engine. The requirement stated as "Creates an engine with -initial state determined by <tt>static_cast<X::result_type>(s)</tt>" forces random number engines -to either use a seeding method that completely depends on the <tt>result_type</tt> (see the discussion -of seeding for the <tt>mersenne_twister_engine</tt> in point T2 above) or at least to throw away "bits -of randomness" in the seed value if the <tt>result_type</tt> is smaller than the seed type. This seems -to be inappropriate for many modern random number generators, in particular F2-linear or -cryptographic ones, which operate on an internal bit array that in principle is independent of the -type of numbers returned. -</p> - -<p> -<b>Posible resolution:</b> I propose to change the wording to a version similar to "Creates an -engine with initial state determined by <tt>static_cast<UintType>(s)</tt>, where <tt>UintType</tt> is an -implementation specific unsigned integer type." -</p> - +<blockquote> <p> -Additionally, the definition of s in 26.4.1.3 [rand.req.eng]/1 c) could be restricted to unsigned integer types. +Stephan Tolksdorf has additional comments on N2424. He comments: "there +is a typo in the required behaviour for mt19937_64: It should be the +10000th (not 100000th) invocation whose value is given, and the value +should be 9981545732273789042 (not 14002232017267485025)." These values +need checking. </p> - <p> -Similarly, the type of the seed in 26.4.1.4 [rand.req.adapt]/3 e) could be left unspecified. +Take the proposed recommendation in N2424 and move to REVIEW. </p> +</blockquote> -<p> -See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> -for further discussion. -</p> <p><b>Proposed resolution:</b></p> -<p> -See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> -for further discussion. -</p> - - - - - - -<hr> -<h3><a name="730"></a>730. Comment on [rand.req.adapt]/3 e)</h3> -<p><b>Section:</b> 26.4.1.4 [rand.req.adapt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> - <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> -<p><b>Discussion:</b></p> -<p> -If an engine adaptor is invoked with an argument of type <tt>seed_seq</tt>, then all base -engines are specified to be seeded with this <tt>seed_seq</tt>. As <tt>seed_seq</tt>'s randomization method is -qualified as constant, this procedure will ef fectively initialize all base engines with the same seed -(though the resulting state might still dif fer to a certain degree if the engines are of different types). -It is not clear whether this mode of operation is in general appropriate, hence -- as far as the -stated requirements are of general nature and not just specific to the engine adaptors provided by -the library -- it might be better to leave the behaviour unspecified, since the current definition of -<tt>seed_seq</tt> does not allow for a generally satisfying specification. -</p> - -<p> -<b>Posssible resolution:</b> [As above] -</p> <p> -See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> -for further discussion. -</p> - - - -<p><b>Proposed resolution:</b></p> -<p> -See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a> for the proposed resolution. </p> +<p><i>[ +Stephan Tolksdorf adds pre-Bellevue: +]</i></p> +<blockquote> +I support the proposed resolution in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>, +but there is a typo in the +required behaviour for <tt>mt19937_64</tt>: It should be the 10000<sup>th</sup> (not +100000<sup>th</sup>) invocation whose value is given, and the value should be +9981545732273789042 (not 14002232017267485025). The change to para. 8 +proposed by Charles Karney should also be included in the proposed +wording. +</blockquote> -<hr> -<h3><a name="731"></a>731. proposal for a customizable <tt>seed_seq</tt></h3> -<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> - <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> -<p><b>Discussion:</b></p> -<p> -The proper way to seed random number engines seems to be the most frequently -discussed issue of the 26.4 [rand] proposal. While the new <tt>seed_seq</tt> approach is already rather -general and probably sufficient for most situations, it is unlikely to be optimal in every case (one -problem was pointed out in point T5 above). In some situations it might, for instance, be better to -seed the state with a cryptographic generator. -</p> -<p> -In my opinion this is a pretty strong argument for extending the standard with a simple facility to -customize the seeding procedure. This could, for example, be done with the following minimal -changes: -</p> - -<p> -<b>Possible resolution:</b> -</p> - -<ol type="a"> -<li> -Turn the interface specification of 26.4.7.1 [rand.util.seedseq]/2 into a "SeedSeq" requirement, where the -exact behaviour of the constructors and the randomize method are left unspecified and where the -const qualification for randomize is removed. Classes implementing this interface are additionally -required to specialize the traits class in c). -</li> -<li> -Provide the class <tt>seed_seq</tt> as a default implementation of the SeedSeq interface. -</li> -<li> -<p> -Supplement the <tt>seed_seq</tt> with a traits class -</p> -<blockquote><pre>template <typename T> -struct is_seed_seq { static const bool value = false; } -</pre></blockquote> -<p>and the specialization</p> -<blockquote><pre>template <> -struct is_seed_seq<seed_seq> { static const bool value = true; } -</pre></blockquote> -<p>which users can supplement with further specializations.</p> -</li> -<li> -Change 26.4.1.3 [rand.req.eng]/1 d) to "q is an lvalue of a type that fulfils the SeedSeq requirements", and -modify the constructors and seed methods in 26.4.3 [rand.eng] appropriately (the actual implementation -could be done using the SFINAE technique). -</li> -</ol> - - -<p><b>Proposed resolution:</b></p> -<p> -See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> -for the proposed resolution. -</p> - <hr> <h3><a name="732"></a>732. Defect in [rand.dist.samp.genpdf]</h3> -<p><b>Section:</b> 26.4.8.5.3 [rand.dist.samp.genpdf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 26.4.8.5.3 [rand.dist.samp.genpdf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p> -<p><b>View all 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 other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.genpdf">issues</a> in [rand.dist.samp.genpdf].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a></p> <p><b>Discussion:</b></p> <p> 26.4.8.5.3 [rand.dist.samp.genpdf] describes the interface for a distribution template that is @@ -13574,41 +11440,46 @@ nightmare. <b>Possible resolution:</b> For these reasons, I propose to delete section 26.4.8.5.3 [rand.dist.samp.genpdf]. </p> +<p><i>[ +Bellevue: +]</i></p> + -<p><b>Proposed resolution:</b></p> +<blockquote> <p> -See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> -for the proposed resolution. +Disagreement persists. </p> - - - - - -<hr> -<h3><a name="733"></a>733. Comment on [rand.req.dist]/9</h3> -<p><b>Section:</b> 26.4.1.5 [rand.req.dist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> - <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> -<p><b>Discussion:</b></p> <p> -The requirement "P shall have a declaration of the form <tt>typedef X distribution_- -type</tt>" effectively makes the use of inheritance for implementing distributions very inconvenient, -because the child of a distribution class in general will not satisfy this requirement. In my opinion -the benefits of having a typedef in the parameter class pointing back to the distribution class are -not worth the hassle this requirement causes. [In my code base I never made use of the nested -typedef but on several occasions could have profited from being able to use simple inheritance for -the implementation of a distribution class.] +Objection to this issue is that this function takes a general functor. +The general approach would be to normalize this function, integrate it, +and take the inverse of the integral, which is not possible in general. +An example function is sin(1+n*x) -- for any spatial frequency that the +implementor chooses, there is a value of n that renders that choice +arbitrarily erroneous. +</p> +<p> +Correction: The formula above should instead read 1+sin(n*x). </p> - <p> -<b>Proposed resolution:</b> I propose to drop this requirement. +Objector proposes the following possible compromise positions: </p> +<ul> +<li> +rand.dist.samp.genpdf takes an number of points so that implementor need not guess. +</li> +<li>replace rand.disk.samp.genpdf with an extension to either or both +of the discrete functions to take arguments that take a functor and +number of points in place of the list of probabilities. Reference +issues 793 and 794. +</li> +</ul> +</blockquote> + <p><b>Proposed resolution:</b></p> <p> -See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a> for the proposed resolution. </p> @@ -13618,9 +11489,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#New">New</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#Open">Open</a> <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>View all issues with</b> <a 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>chi_squared_distribution</tt>, <tt>fisher_f_distribution</tt> and <tt>student_t_distribution</tt> @@ -13647,187 +11518,97 @@ log-factorial function). to double. </p> +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +In N2424. Not wildly enthusiastic, not really felt necessary. Less +frequently used in practice. Not terribly bad either. Move to OPEN. +</blockquote> + <p><b>Proposed resolution:</b></p> <p> -See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a> for the proposed resolution. </p> +<p><i>[ +Stephan Tolksdorf adds pre-Bellevue: +]</i></p> - - -<hr> -<h3><a name="735"></a>735. Unfortunate naming</h3> -<p><b>Section:</b> 26.4.8.2.2 [rand.dist.bern.bin], 26.4.8.2.4 [rand.dist.bern.negbin] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> - <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> -<p><b>Discussion:</b></p> +<blockquote> <p> -In my opinion the choice of name for the <tt>t</tt> parameter of the <tt>binomial_distribution</tt> -is very unfortunate. In virtually every internet reference, book and software implementation -this parameter is called <tt>n</tt> instead, see for example Wikipedia, Mathworld, Evans et al. (1993) -Statistical Distributions, 2nd E., Wiley, p. 38, the R statistical computing language, p. 926, -Mathematica and Matlab. +In 26.4.8.4.3 [rand.dist.norm.chisq]: </p> +<blockquote> <p> -Similarly, the choice of <tt>k</tt> for the parameter of the negative binomial distributions is rather unusual. -The most common choice for the negative binomial distribution seems to be <tt>r</tt> instead. +Delete ", where <tt>n</tt> is a positive integer" in the first paragraph. </p> <p> -Choosing unusual names for the parameters causes confusion among users and makes the -interface unnecessarily inconvenient to use. +Replace both occurrences of "<tt>explicit chi_squared_distribution(int n = 1);</tt>" +with "<tt>explicit chi_squared_distribution(RealType n = 1);</tt>". </p> <p> -<b>Possible resolution:</b> For these reasons, I propose to change the name of the respective parameters -to <tt>n</tt> and <tt>r</tt>. +Replace both occurrences of "<tt>int n() const;</tt>" with "<tt>RealType n() const;</tt>". </p> - -<p><b>Proposed resolution:</b></p> -<p> -See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> -for the proposed resolution. -</p> - - - - - -<hr> -<h3><a name="736"></a>736. Comment on [rand.dist.samp.discrete]</h3> -<p><b>Section:</b> 26.4.8.5.1 [rand.dist.samp.discrete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> - <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> -<p><b>Discussion:</b></p> -<ol type="a"> -<li> -The specification for <tt>discrete_distribution</tt> requires the member <tt>probabilities()</tt> -to return a vector of <i>standardized</i> probabilities, which forces the implementation every time to -divide each probability by the sum of all probabilities, as the sum will in practice almost never be -exactly 1.0. This is unnecessarily inef ficient as the implementation would otherwise not need to -compute the standardized probabilities at all and could instead work with the non-standardized -probabilities and the sum. If there was no standardization the user would just get back the -probabilities that were previously supplied to the distribution object, which to me seems to be the -more obvious solution. -</li> -<li> -The behaviour of <tt>discrete_distribution</tt> is not specified in case the number of given -probabilities is larger than the maximum number representable by the IntType. -</li> -</ol> +</blockquote> <p> -<b>Possible resolution:</b> I propose to change the specification such that the non-standardized -probabilities need to be returned and that an additional requirement is included for the number -of probabilities to be smaller than the maximum of IntType. +In 26.4.8.4.5 [rand.dist.norm.f]: </p> - - -<p><b>Proposed resolution:</b></p> +<blockquote> <p> -See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> -for the proposed resolution. +Delete ", where <tt>m</tt> and <tt>n</tt> are positive integers" in the first paragraph. </p> - - - - -<hr> -<h3><a name="737"></a>737. Comment on [rand.dist.samp.pconst]</h3> -<p><b>Section:</b> 26.4.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> - <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> -<p><b>Discussion:</b></p> -<ol type="a"> -<li> -The discussion in point T11 above regarding <tt>probabilities()</tt> similarly applies -to the method <tt>densities()</tt> of <tt>piecewise_constant_distribution</tt>. -</li> -<li> <p> -The design of the constructor +Replace both occurrences of </p> -<blockquote><pre>template <class InputIteratorB, class InputIteratorW> -piecewise_constant_distribution( InputIteratorB firstB, InputIteratorB lastB, - InputIteratorW firstW); +<blockquote><pre>explicit fisher_f_distribution(int m = 1, int n = 1); </pre></blockquote> <p> -is unnecessarily unsafe, as there is no separate end-iterator given for the weights. I can't see -any performance or convenience reasons that would justify the risks inherent in such a function -interface, in particular the risk that input error might go unnoticed. +with </p> -</li> -</ol> +<blockquote><pre>explicit fisher_f_distribution(RealType m = 1, RealType n = 1); +</pre></blockquote> <p> -<b>Possible resolution:</b> I propose to add an <tt>InputIteratorW lastW</tt> argument to the interface. +Replace both occurrences of "<tt>int m() const;" with "RealType m() const;</tt>". </p> - -<p><b>Proposed resolution:</b></p> <p> -See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> -for the proposed resolution. +Replace both occurrences of "<tt>int n() const;" with "RealType n() const;</tt>". </p> +</blockquote> - - - - -<hr> -<h3><a name="738"></a>738. Editorial issue in [rand.adapt.disc]/3</h3> -<p><b>Section:</b> 26.4.4.1 [rand.adapt.disc] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> - <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> -<p><b>Discussion:</b></p> <p> -Since the template parameter <tt>p</tt> and <tt>r</tt> are of type <tt>size_t</tt>, the member <tt>n</tt> in the class -exposition should have type <tt>size_t</tt>, too. +In 26.4.8.4.6 [rand.dist.norm.t]: </p> - -<p><b>Proposed resolution:</b></p> +<blockquote> <p> -See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> -for the proposed resolution. +Delete ", where <tt>n</tt> is a positive integer" in the first paragraph. </p> - - - - -<hr> -<h3><a name="739"></a>739. Defect in [rand.util.canonical]/3</h3> -<p><b>Section:</b> 26.4.7.2 [rand.util.canonical] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> - <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.canonical">issues</a> in [rand.util.canonical].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> -<p><b>Discussion:</b></p> <p> -The complexity of <tt>generate_canonical</tt> is specified to be "exactly k=max(1, ceil(b/log2 -R)) invocations of g". This terms involves a logarithm that is not rounded and hence can not (in -general) be computed at compile time. As this function template is performance critical, I propose -to replace ceil(b/log2 R) with ceil(b/floor(log2 R)). +Replace both occurrences of "<tt>explicit student_t_distribution(int n = 1);</tt>" +with "<tt>explicit student_t_distribution(RealType n = 1);</tt>". </p> <p> -See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> -for further discussion. +Replace both occurrences of "<tt>int n() const;</tt>" with "<tt>RealType n() const;</tt>". </p> +</blockquote> - - -<p><b>Proposed resolution:</b></p> -<p> -See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> -for the proposed resolution. -</p> +</blockquote> @@ -13835,9 +11616,9 @@ for the proposed resolution. <hr> <h3><a name="740"></a>740. Please remove <tt>*_ptr<T[N]></tt></h3> -<p><b>Section:</b> 20.6.5.4 [unique.ptr.compiletime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<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#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> Please don't provide <tt>*_ptr<T[N]></tt>. It doesn't enable any useful @@ -13874,129 +11655,57 @@ remove <tt>*_ptr<T[N]></tt> which equally makes the smart pointer more lik <tt>std::array.</tt> :-) </p> +<p><i>[ +Bellevue: +]</i></p> -<p><b>Proposed resolution:</b></p> -<p> -Change the synopsis under 20.6.5 [unique.ptr] p2: -</p> - -<blockquote><pre>... -template<class T> struct default_delete; -template<class T> struct default_delete<T[]>; -<del>template<class T, size_t N> struct default_delete<T[N]>;</del> - -template<class T, class D = default_delete<T>> class unique_ptr; -template<class T, class D> class unique_ptr<T[], D>; -<del>template<class T, class D, size_t N> class unique_ptr<T[N], D>;</del> -... -</pre></blockquote> -<p> -Remove the entire section 20.6.5.1.3 [unique.ptr.dltr.dflt2] <b><tt>default_delete<T[N]></tt></b>. +<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> -Remove the entire section 20.6.5.4 [unique.ptr.compiletime] <b><tt>unique_ptr</tt> for array objects with a compile time length</b> -and its subsections: 20.6.5.4.1 [unique.ptr.compiletime.dtor], 20.6.5.4.2 [unique.ptr.compiletime.observers], -20.6.5.4.3 [unique.ptr.compiletime.modifiers]. +So concerns about about requiring static_assert seem unfounded. </p> - - - - - - -<hr> -<h3><a name="741"></a>741. Const-incorrect <tt>get_deleter</tt> function for <tt>shared_ptr</tt></h3> -<p><b>Section:</b> 20.6.6.2.11 [util.smartptr.getdeleter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> - <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-09-27</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.getdeleter">issues</a> in [util.smartptr.getdeleter].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> -<p><b>Discussion:</b></p> -<p> -The following issue was raised by Alf P. Steinbach in c.l.c++.mod: +<p>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> -According to the recent draft N2369, both the header memory synopsis -of 20.6 [memory] and 20.6.6.2.11 [util.smartptr.getdeleter] declare: +straw poll unanimous move to Ready. </p> +</blockquote> -<blockquote><pre>template<class D, class T> D* get_deleter(shared_ptr<T> const& p); -</pre></blockquote> - -<p> -This allows to retrieve the pointer to a mutable deleter of a <tt>const -shared_ptr</tt> (if that owns one) and therefore contradicts the usual -philosophy that associated functors are either read-only (e.g. -<tt>key_comp</tt> or <tt>value_comp</tt> of <tt>std::map</tt>) or do at least reflect -the mutability of the owner (as seen for the both overloads of -<tt>unique_ptr::get_deleter</tt>). -Even the next similar counter-part of <tt>get_deleter</tt> - the two -overloads of <tt>function::target</tt> in the class template function -synopsis 20.5.15.2 [func.wrap.func] or in 20.5.15.2.5 [func.wrap.func.targ] - do -properly mirror the const-state of the owner. -</p> -<b>Possible proposed resolutions:</b> +<p><b>Proposed resolution:</b></p> <p> -Replace the declarations of <tt>get_deleter</tt> in the header <tt><memory></tt> -synopsis of 20.6 [memory] and in 20.6.6.2.11 [util.smartptr.getdeleter] by one of the -following alternatives (A) or (B): +Change the synopsis under 20.6.11 [unique.ptr] p2: </p> -<ol type="A"> -<li> -Provide <b>only</b> the immutable variant. This would reflect the -current praxis of <tt>container::get_allocator()</tt>, <tt>map::key_comp()</tt>, or -<tt>map::value_comp</tt>. - -<blockquote><pre>template<class D, class T> const D* get_deleter(shared_ptr<T> const& p); -</pre></blockquote> -</li> -<li> -Just remove the function. -</li> -</ol> - -<p> -Alberto Ganesh Barbati adds: -</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> -<ol start="3" type="A"> -<li> -<p> -Replace it with two functions: -</p> -<blockquote><pre>template <class D, class T> D get_deleter(shared_ptr<T> const&); -template <class D, class T> bool has_deleter(shared_ptr<T> const&); +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> -The first one would throw if <tt>D</tt> is the wrong type, while the latter would -never throw. This approach would reflect the current praxis of -<tt>use_facet/has_facet</tt>, with the twist of returning the deleter by value as -<tt>container::get_allocator()</tt> do. +Remove the entire section 20.6.11.1.3 [unique.ptr.dltr.dflt2] <b><tt>default_delete<T[N]></tt></b>. </p> -</li> -</ol> <p> -Peter Dimov adds: +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> -<blockquote> -<p> -My favorite option is "not a defect". A, B and C break useful code. -</p> -</blockquote> - - - -<p><b>Proposed resolution:</b></p> -<p> -</p> @@ -14004,11 +11713,11 @@ My favorite option is "not a defect". A, B and C break useful code. <hr> <h3><a name="742"></a>742. Enabling <tt>swap</tt> for proxy iterators</h3> -<p><b>Section:</b> 20.1.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 20.1.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-10-10</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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> 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 @@ -14071,6 +11780,37 @@ That is, no standard library code needs to change. We simply need to have a mor definition of <tt>Swappable</tt>. </p> +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +While we believe Concepts work will define a swappable concept, we +should still resolve this issue if possible to give guidance to the +Concepts work. +</p> +<p> +Would an ambiguous swap function in two namespaces found by ADL break +this wording? Suggest that the phrase "valid expression" means such a +pair of types would still not be swappable. +</p> +<p> +Motivation is proxy-iterators, but facility is considerably more +general. Are we happy going so far? +</p> +<p> +We think this wording is probably correct and probably an improvement on +what's there in the WP. On the other hand, what's already there in the +WP is awfully complicated. Why do we need the two bullet points? They're +too implementation-centric. They don't add anything to the semantics of +what swap() means, which is there in the post-condition. What's wrong +with saying that types are swappable if you can call swap() and it +satisfies the semantics of swapping? +</p> +</blockquote> + <p><b>Proposed resolution:</b></p> @@ -14132,12 +11872,12 @@ 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.6.2.9 [util.smartptr.shared.spec] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<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#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> -When the LWG looked at <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#674">674</a> in Kona the following note was made: +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> @@ -14154,11 +11894,27 @@ 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.6.2 [util.smartptr.shared]: +Change the synopsis in 20.6.12.2 [util.smartptr.shared]: </p> <blockquote><pre>void swap(shared_ptr&<ins>&</ins> r); @@ -14169,14 +11925,14 @@ template<class T> void swap(shared_ptr<T>& a, shared_ptr<T> </pre></blockquote> <p> -Change 20.6.6.2.4 [util.smartptr.shared.mod]: +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.6.2.9 [util.smartptr.shared.spec]: +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); @@ -14190,15 +11946,15 @@ template<class T> void swap(shared_ptr<T>& a, shared_ptr<T> <hr> <h3><a name="744"></a>744. What is the lifetime of an exception pointed to by an exception_ptr?</h3> -<p><b>Section:</b> 18.7.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<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#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> 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 +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. @@ -14208,55 +11964,68 @@ API. explain?) </p> +<p><i>[ +Bellevue: +]</i></p> -<p><b>Proposed resolution:</b></p> + +<blockquote> <p> +Agree the issue is real. </p> - - - - - -<hr> -<h3><a name="745"></a>745. copy_exception API slices.</h3> -<p><b>Section:</b> 18.7.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> - <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> -<p><b>Discussion:</b></p> <p> -It could be I did not understand the design rationale, but I thought -copy_exception would produce an exception_ptr to the most-derived (dynamic) -type of the passed exception. Instead it slices, which appears to be less -useful, and a likely source of FAQ questions in the future. +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> -(Peter Dimov suggests NAD) +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#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> Alisdair Meredith <b>Date:</b> 2007-10-10</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>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 +implementation-defined type derived from <tt>bad_alloc</tt>. For instance, the Core language for a failed new expression is: </p> <blockquote> @@ -14274,29 +12043,60 @@ compatible-exception freedom paragraph in 17) 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#New">New</a> +<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> <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> <p><b>Discussion:</b></p> <p> We have 3 separate type traits to identify classes supporting no-throw operations, which are very useful when trying to provide exception safety -guarantees. However, I'm not entirely clear on what the current wording -requires of a conforming implementation. To quote from +guarantees. However, I'm not entirely clear on what the current wording +requires of a conforming implementation. To quote from <tt>has_nothrow_default_constructor</tt>: </p> <blockquote><p> @@ -14311,13 +12111,13 @@ E.g. </p> <blockquote><pre>struct test{ - int x; - test() : x() {} + int x; + test() : x() {} }; </pre></blockquote> <p> Should I expect a conforming compiler to - <tt>assert( has_nothrow_constructor<test>::value )</tt> + <tt>assert( has_nothrow_constructor<test>::value )</tt> </p> <p> Is this a QoI issue? @@ -14339,41 +12139,16 @@ but right now I don't know what to suggest putting in the footnote. Open if QoI should be allowed to detect further) </p> - -<p><b>Proposed resolution:</b></p> -<p> -</p> - - - +<p><i>[ +Bellevue: +]</i></p> -<hr> -<h3><a name="748"></a>748. The is_abstract type trait is defined by reference to 10.4.</h3> -<p><b>Section:</b> 20.4.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> - <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> -<p><b>Discussion:</b></p> -<p> -I am trying to decide is a pure virtual function is a <i>necessary</i> as well as -sufficient requirement to be classified as abstract? -</p> -<p> -For instance, is the following (non-polymorphic) type considered abstract? -</p> -<blockquote><pre>struct abstract { -protected: - abstract(){} - abstract( abstract const & ) {} - ~abstract() {} -}; -</pre></blockquote> -<p> -(Suggested that this may be NAD, with an editorial fix-up from Pete on the -core wording to make clear that abstract requires a pure virtual function) -</p> +<blockquote> +This looks like a QoI issue. +In the case of trivial and nothrow it is known. Static analysis of the program is definitely into QoI. +Move to OPEN. Need to talk to Core about this. +</blockquote> <p><b>Proposed resolution:</b></p> @@ -14386,11 +12161,11 @@ core wording to make clear that abstract requires a pure virtual function) <hr> <h3><a name="749"></a>749. Currently <tt>has_nothrow_copy_constructor<T>::value</tt> is true if T has 'a' nothrow copy constructor.</h3> -<p><b>Section:</b> 20.4.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<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#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> Unfortunately a class can have multiple copy constructors, and I believe to @@ -14402,16 +12177,55 @@ For instance: </p> <blockquote> <pre>struct awkward { - awkward( const awkward & ) throw() {} - awkward( awkward & ) { throw "oops"; } }; + 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> + + @@ -14419,15 +12233,27 @@ For instance: <hr> <h3><a name="750"></a>750. The current definition for <tt>is_convertible</tt> requires that the type be implicitly convertible, so explicit constructors are ignored.</h3> -<p><b>Section:</b> 20.4.5 [meta.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<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> <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> <p><b>Discussion:</b></p> <p> With the pending arrival of explicit conversion functions though, I'm wondering if we want an additional trait, <tt>is_explictly_convertible</tt>? </p> +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Alisdair is considering preparing a paper listing a number of missing +type traits, and feels that it might be useful to handle them all +together rather than piecemeal. This would affect issue 719 and 750. +These two issues should move to OPEN pending AM paper on type traits. +</blockquote> + <p><b>Proposed resolution:</b></p> <p> @@ -14439,8 +12265,10 @@ wondering if we want an additional trait, <tt>is_explictly_convertible</tt>? <hr> <h3><a name="751"></a>751. change pass-by-reference members of <tt>vector<bool></tt> to pass-by-value?</h3> -<p><b>Section:</b> 23.2.6 [vector.bool] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 23.2.7 [vector.bool] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#vector.bool">active issues</a> in [vector.bool].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.bool">issues</a> in [vector.bool].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> <p><b>Discussion:</b></p> <p> @@ -14449,6 +12277,39 @@ Is there any chance we could change them to pass-by-value or would I be wasting everyone's time if wrote up an issue? </p> +<p><i>[ +post Bellevue: +]</i></p> + + +<blockquote> +<p> +As we understand it, the original requester (Martin Sebor) would like +for implementations to be permitted to pass-by-value. Alisdair suggests +that if this is to be resolved, it should be resolved more generally, +e.g. in other containers as well. +</p> +<p> +We note that this would break ABI. However, we also suspect that this +might be covered under the "as-if" rule in section 1.9. +</p> +<p> +Many in the group feel that for vector<bool>, this is a "don't care", +and that at this point in the process it's not worth the bandwidth. +</p> +<p> +Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a> -- which was in ready status pre-Bellevue and is +now in the working paper -- is related to this, though not a duplicate. +</p> +<p> +Moving to Open with a task for Alisdair to craft a informative note to +be put whereever appropriate in the WP. This note would clarify places +where pass-by-const-ref can be transformed to pass-by-value under the +as-if rule. +</p> +</blockquote> + + <p><b>Proposed resolution:</b></p> <p> @@ -14510,11 +12371,11 @@ requirements on allocator types. <hr> <h3><a name="753"></a>753. Move constructor in draft</h3> -<p><b>Section:</b> 20.1.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> +<p><b>Section:</b> 20.1.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Yechezkel Mett <b>Date:</b> 2007-10-14</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> <p><b>Discussion:</b></p> <p> The draft standard n2369 uses the term <i>move constructor</i> in a few @@ -14553,7 +12414,7 @@ in filling the above requirement. <p> For <tt>vector::reserve</tt>, <tt>vector::resize</tt> and the <tt>vector</tt> modifiers given in -23.2.5.4 [vector.modifiers] we have +23.2.6.4 [vector.modifiers] we have </p> <blockquote> @@ -14592,104 +12453,6763 @@ possibly more concise too. <p><b>Proposed resolution:</b></p> <p> +Add new defintions to 17.1 [definitions]: </p> +<blockquote> +<p> +<b>move constructor</b> +</p> +<p> +a constructor which accepts only rvalue arguments of that type, and modifies the rvalue as a +side effect during the construction. +</p> +<p> +<b>move assignment operator</b> +</p> +<p> +an assignment operator which accepts only rvalue arguments of that type, and modifies the rvalue as a +side effect during the assignment. +</p> +<p> +<b>move assignment</b> +</p> +<p> +use of the move assignment operator. +</p> +</blockquote> + +<p><i>[ +Howard adds post-Bellevue: +]</i></p> + + +<blockquote> +<p> +Unfortunately I believe the wording recommended by the LWG in Bellevue is incorrect. <tt>reserve</tt> et. al. will use a move constructor +if one is available, else it will use a copy constructor. A type may have both. If the move constructor is +used, it must not throw. If the copy constructor is used, it can throw. The sentence in the proposed wording +is correct without the recommended insertion. The Bellevue LWG recommended moving this issue to Ready. I am +unfortunately pulling it back to Open. But I'm drafting wording to atone for this egregious action. :-) +</p> +</blockquote> + + <hr> -<h3><a name="754"></a>754. Ambiguous return clause for <tt>std::uninitialized_copy</tt></h3> -<p><b>Section:</b> 20.6.4.1 [uninitialized.copy] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> - <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-10-15</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#uninitialized.copy">active issues</a> in [uninitialized.copy].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#uninitialized.copy">issues</a> in [uninitialized.copy].</p> +<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> + <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>Discussion:</b></p> +<p> +Consider the following program: +</p> + +<blockquote><pre>int main() { + shared_ptr<int> p(nullptr); + return 0; +} +</pre></blockquote> + +<p> +This program will fail to compile because <tt>shared_ptr</tt> uses the following +template constructor to construct itself from pointers: +</p> + +<blockquote><pre>template <class Y> shared_ptr(Y *); +</pre></blockquote> + +<p> +According +to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf">N2431</a>, +the conversion from <tt>nullptr_t</tt> to <tt>Y *</tt> is not +deducible, so the above constructor will not be found. There are similar problems with the +constructors that take a pointer and a <tt>deleter</tt> or a +pointer, a <tt>deleter</tt> and an allocator, as well as the +corresponding forms of <tt>reset()</tt>. Note that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2435.htm">N2435</a> +will solve this problem for constructing from just <tt>nullptr</tt>, but not for constructors that use +<tt>deleters</tt> or allocators or for <tt>reset()</tt>. +</p> + +<p> +In the case of the functions that take deleters, there is the additional +question of what argument should be passed to the deleter when it is +eventually called. There are two reasonable possibilities: <tt>nullptr</tt> or +<tt>static_cast<T *>(0)</tt>, where <tt>T</tt> is the template argument of the +<tt>shared_ptr</tt>. It is not immediately clear which of these is better. If +<tt>D::operator()</tt> is a template function similar to <tt>shared_ptr</tt>'s +constructor, then <tt>d(static_cast<T*>(0))</tt> will compile and <tt>d(nullptr)</tt> +will not. On the other hand, if <tt>D::operator()()</tt> takes a parameter that +is a pointer to some type other that <tt>T</tt> (for instance <tt>U*</tt> where <tt>U</tt> derives +from <tt>T</tt>) then <tt>d(nullptr)</tt> will compile and <tt>d(static_cast<T *>(0))</tt> may not. +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +The general idea is right, we need to be able to pass a nullptr to a +shared_ptr, but there are a few borderline editorial issues here. (For +example, the single-argument nullptr_t constructor in the class synopsis +isn't marked explicit, but it is marked explicit in the proposed wording +for 20.6.6.2.1. There is a missing empty parenthesis in the form that +takes a nullptr_t, a deleter, and an allocator.) +</p> +<p> +More seriously: this issue says that a shared_ptr constructed from a +nullptr is empty. Since "empty" is undefined, it's hard to know whether +that's right. This issue is pending on handling that term better. +</p> +<p> +Peter suggests definition of empty should be "does not own anything" +</p> +<p> +Is there an editorial issue that post-conditions should refer to get() = +nullptr, rather than get() = 0? +</p> +<p> +No strong feeling towards accept or NAD, but prefer to make a decision than leave it open. +</p> +<p> +Seems there are no technical merits between NAD and Ready, comes down to +"Do we intentially want to allow/disallow null pointers with these +functions". Staw Poll - support null pointers 5 - No null pointers 0 +</p> +<p> +Move to Ready, modulo editorial comments +</p> +</blockquote> + +<p><i>[ +post Bellevue Peter adds: +]</i></p> + + +<blockquote> +<p> +The following wording changes are less intrusive: +</p> + +<p> +In 20.6.12.2.1 [util.smartptr.shared.const], add: +</p> + +<blockquote><pre>shared_ptr(nullptr_t); +</pre></blockquote> + +<p> +after: +</p> + +<blockquote><pre>shared_ptr(); +</pre></blockquote> + +<p> +(Absence of explicit intentional.) +</p> + +<p> +<tt>px.reset( nullptr )</tt> seems a somewhat contrived way to write <tt>px.reset()</tt>, so +I'm not convinced of its utility. +</p> +<p> +It's similarly not clear to me whether the deleter constructors need to be +extended to take <tt>nullptr</tt>, but if they need to: +</p> +<p> +Add +</p> + +<blockquote><pre>template<class D> shared_ptr(nullptr_t p, D d); +template<class D, class A> shared_ptr(nullptr_t p, D d, A a); +</pre></blockquote> + +<p> +after +</p> + +<blockquote><pre>template<class Y, class D> shared_ptr(Y* p, D d); +template<class Y, class D, class A> shared_ptr(Y* p, D d, A a); +</pre></blockquote> + +<p> +Note that this changes the semantics of the new constructors such that they +consistently call <tt>d(p)</tt> instead of <tt>d((T*)0)</tt> when <tt>p</tt> is <tt>nullptr</tt>. +</p> +<p> +The ability to be able to pass <tt>0/NULL</tt> to a function that takes a <tt>shared_ptr</tt> +has repeatedly been requested by users, but the other additions that the +proposed resolution makes are not supported by real world demand or +motivating examples. +</p> +<p> +It might be useful to split the obvious and non-controversial <tt>nullptr_t</tt> +constructor into a separate issue. Waiting for "empty" to be clarified is +unnecessary; this is effectively an alias for the default constructor. +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Add the following constructors to 20.6.12.2 [util.smartptr.shared]: +</p> + +<blockquote><pre>shared_ptr(nullptr_t); +template <class D> shared_ptr(nullptr_t, D d); +template <class D, class A> shared_ptr(nullptr_t, D d, A a); +</pre></blockquote> + +<p> +Add the following 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]: +</p> + +<blockquote> +<pre> explicit shared_ptr(nullptr_t); +</pre> +<blockquote> +<p> +<i>Effects:</i> Constructs an empty shared_ptr object. +</p> +<p> +<i>Postconditions:</i> <tt>use_count() == 0 && get() == 0</tt>. +</p> +<p> +<i>Throws:</i> nothing. +</p> +</blockquote> +</blockquote> + +<blockquote> +<pre>template <class D> shared_ptr(nullptr_t, D d); +template <class D, class A> shared_ptr<nullptr_t, D d, A a); +</pre> +<blockquote> +<p> +<i>Requires:</i> <tt>D</tt> shall be <tt>CopyConstructible</tt>. The copy constructor and +destructor of <tt>D</tt> shall not throw exceptions. The expression +<tt>d(static_cast<T *>(0))</tt> shall be well-formed, shall have well defined behavior, +and shall not throw exceptions. <tt>A</tt> shall be an allocator (20.1.2 [allocator.requirements]). +The copy constructor and destructor of <tt>A</tt> shall not throw +exceptions. +</p> +<p> +<i>Effects:</i> Constructs a <tt>shared_ptr</tt> object that owns a null pointer of type <tt>T *</tt> +and deleter <tt>d</tt>. The +second constructor shall use a copy of <tt>a</tt> to allocate memory for +internal use. +</p> +<p> +<i>Postconditions:</i> <tt>use_count() == 1</tt> and <tt>get() == 0</tt>. +</p> +<p> +<i>Throws:</i> <tt>bad_alloc</tt>, or an implementation-defined exception when a +resource other than memory could not be obtained. +</p> +<p> +<i>Exception safety:</i> If an exception is thrown, <tt>d(static_cast<Y *>(nullptr))</tt> is called. +</p> +</blockquote> +</blockquote> + +<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> + + + + + + +<hr> +<h3><a name="760"></a>760. The emplace issue</h3> +<p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2007-11-11</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In an emplace member function the function parameter pack may be bound +to a priori unlimited number of objects: some or all of them can be +elements of the container itself. Apparently, in order to conform to the +blanket statement 23.1 [container.requirements]/11, the implementation must check all of them for +that possibility. A possible solution can involve extending the +exception in 23.1 [container.requirements]/12 also to the emplace member. As a side note, the +<tt>push_back</tt> and <tt>push_front</tt> member functions are luckily not affected by +this problem, can be efficiently implemented anyway +</p> + +<p><i>[ +Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#767">767</a> +]</i></p> + + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +The proposed addition (13) is partially redundant with the existing +paragraph 12. Why was the qualifier "rvalues" added to paragraph 12? Why +does it not cover subelements and pointers? +</p> +<p> +Resolution: Alan Talbot to rework language, then set state to Review. +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Add after 23.1 [container.requirements]/12: +</p> + +<blockquote> +<p> +-12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No +diagnostic required. +</p> +<p> +<ins> +-13- Objects bound to the function parameter pack of the <tt>emplace</tt> member function shall not be elements or +sub-objects of elements of the container. No diagnostic required. +</ins> +</p> + +</blockquote> + + + + + + +<hr> +<h3><a name="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> + <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>Discussion:</b></p> +<p> +In contrast to the proposed <tt>std::shared_ptr</tt>, <tt>std::unique_ptr</tt> +does currently not support incomplete types, because it +gives no explicit grant - thus instantiating <tt>unique_ptr</tt> with +an incomplete pointee type <tt>T</tt> automatically belongs to +undefined behaviour according to 17.4.3.7 [res.on.functions]/2, last +bullet. This is an unnecessary restriction and prevents +many well-established patterns - like the bridge pattern - +for <tt>std::unique_ptr</tt>. +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Move to open. The LWG is comfortable with the intent of allowing +incomplete types and making <tt>unique_ptr</tt> more like <tt>shared_ptr</tt>, but we are +not comfortable with the wording. The specification for <tt>unique_ptr</tt> +should be more like that of <tt>shared_ptr</tt>. We need to know, for individual +member functions, which ones require their types to be complete. The +<tt>shared_ptr</tt> specification is careful to say that for each function, and +we need the same level of care here. We also aren't comfortable with the +"part of the operational semantic" language; it's not used elsewhere in +the standard, and it's not clear what it means. We need a volunteer to +produce new wording. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +The proposed changes in the following revision refers to the current state of +N2521 including the assumption that 20.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>. +</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: +"<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 +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 +with the here discussed +ones, provided that <tt>D::pointer</tt>'s operations (including default +construction, copy construction/assignment, +and pointer conversion) are specified <em>not</em> to throw, otherwise this +would have impact on the +current specification of <tt>unique_ptr</tt>. +</p> + +<ol> +<li> +<p> +In 20.6.11 [unique.ptr]/2 add as the last sentence to the existing para: +</p> + +<blockquote> +The <tt>unique_ptr</tt> provides a semantics of strict ownership. A +<tt>unique_ptr</tt> owns the object it holds a pointer to. A +<tt>unique_ptr</tt> is not <tt>CopyConstructible</tt>, nor +<tt>CopyAssignable</tt>, however it is <tt>MoveConstructible</tt> and +<tt>MoveAssignable</tt>. <ins>The template parameter <tt>T</tt> of +<tt>unique_ptr</tt> may be an incomplete type.</ins> [ <i>Note:</i> The +uses of <tt>unique_ptr</tt> include providing exception safety for +dynamically allcoated memory, passing ownership of dynamically allocated +memory to a function, and returning dynamically allocated memory from a +function. -- <i>end note</i> ] +</blockquote> +</li> + +<li> +<p> +20.6.11.2.1 [unique.ptr.single.ctor]/1: No changes necessary. +</p> + +<blockquote> +<p><i>[ +N.B.: We only need the requirement that <tt>D</tt> is <tt>DefaultConstructible</tt>. +The current wording says just this. +]</i></p> + +</blockquote> +</li> + +<li> +<p> +In 20.6.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. +<ins> +<tt>D</tt> shall be default constructible, and that construction +shall not throw an exception. +</ins> +</p> +<p><i>[ +N.B.: There is no need that the expression <tt>D()(p)</tt> is well-formed at +this point. I assume that the current wording is based on the +corresponding <tt>shared_ptr</tt> wording. In case of <tt>shared_ptr</tt> this +requirement is necessary, because the corresponding c'tor *can* fail +and must invoke delete <tt>p/d(p)</tt> in this case. <tt>Unique_ptr</tt> is simpler in +this regard. The *only* functions that must insist on well-formedness +and well-definedness of the expression <tt>get_deleter()(get())</tt> are (1) +the destructor and (2) <tt>reset</tt>. The reasoning for the wording change to +explicitly require <tt>DefaultConstructible</tt> of <tt>D</tt> is to guarantee that +invocation of +<tt>D</tt>'s default c'tor is both well-formed and well-defined. Note also that +we do *not* need the +requirement that <tt>T</tt> must be complete, also in contrast to <tt>shared_ptr</tt>. +<tt>Shared_ptr</tt> needs this, because it's c'tor is a template c'tor which +potentially requires <tt>Convertible<Y*, X*></tt>, which +again requires Completeness of <tt>Y</tt>, if <tt>!SameType<X, Y></tt> +]</i></p> + +</blockquote> +</li> + +<li> +<p> +Merge 20.6.11.2.1 [unique.ptr.single.ctor]/12+13 thereby removing the sentence +of 12, but transferring the "requires" to 13: +</p> + +<blockquote> +<p> +<i>Requires:</i> If <tt>D</tt> is not an lvalue-reference type then[..] +</p> +<p><i>[ +N.B.: For the same reasons as for (3), there is no need that <tt>d(p)</tt> is +well-formed/well-defined at this point. The current wording guarantees +all what we need, namely that the initialization of both the <tt>T*</tt> +pointer and the <tt>D</tt> deleter are well-formed and well-defined. +]</i></p> + +</blockquote> +</li> + +<li> +20.6.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><i>[ +N.B.: The current wording of 21 already implicitly guarantees that <tt>U</tt> +is completely defined, because it requires that <tt>Convertible<U*, T*></tt> is +true. If the committee wishes this explicit requirement can be added, +e.g. "<tt>U</tt> shall be a complete type." +]</i></p> + +</li> + +<li> +<p> +20.6.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. +</p> +<p><i>[ +N.B.: This requirement ensures that the whole responsibility on +type-completeness of <tt>T</tt> is delegated to this expression. +]</i></p> + +</blockquote> +</li> + +<li> +<p> +20.6.11.2.3 [unique.ptr.single.asgn]/1: No changes necessary, except the +current editorial issue, that "must shall" has to be changed to +"shall", but this change is not a special part of this resolution. +</p> + +<p><i>[ +N.B. The current wording is sufficient, because we can delegate all +further requirements on the requirements of the effects clause +]</i></p> + +</li> + +<li> +<p> +20.6.11.2.3 [unique.ptr.single.asgn]/6: No changes necessary. +</p> +<p><i>[ +N.B.: The current wording of p. 6 already implicitly guarantees that +<tt>U</tt> is completely defined, because it requires that <tt>Convertible<U*, T*></tt> +is true, see (6)+(8). +]</i></p> + +</li> + +<li> +<p> +20.6.11.2.3 [unique.ptr.single.asgn]/11: No changes necessary. +</p> +<p><i>[ +N.B.: Delegation to requirements of effects clause is sufficient. +]</i></p> + +</li> + +<li> +20.6.11.2.4 [unique.ptr.single.observers]/1+4+7+9+11: No changes necessary. +</li> + +<li> +20.6.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: +</p> +<blockquote> +<i>Requires:</i> The expression <tt>get_deleter()(get())</tt> shall be well-formed, +shall have well-defined behavior, and shall not throw exceptions. +</blockquote> +</li> + +<li> +20.6.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: +</p> + +<blockquote> +<p> +<i>Requires:</i> <tt>T</tt> shall be a complete type. +</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> + +<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> + +</blockquote> + +</li> +</ol> + +<p><i>[ +post Bellevue: Daniel provided revised wording. +]</i></p> + + + + + + + +<hr> +<h3><a name="765"></a>765. more on iterator validity</h3> +<p><b>Section:</b> 24.1 [iterator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-12-14</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.requirements">active issues</a> in [iterator.requirements].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> <p><b>Discussion:</b></p> + <p> + +Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a> +defines the meaning of the term "invalid iterator" as one that may be +singular. + + </p> + <p> + +Consider the following code: + + </p> + <pre> std::deque<int> x, y; + std::deque<int>::iterator i = x.end(), j = y.end(); + x.swap(y); + </pre> + <p> + +Given that <code>swap()</code> is required not to invalidate iterators +and using the definition above, what should be the expected result of +comparing <code>i</code> and <code>j</code> to <code>x.end()</code> +and <code>y.end()</code>, respectively, after the <code>swap()</code>? + + </p> + <p> + +I.e., is the expression below required to evaluate +to <code>true</code>? + + </p> + <pre> i == y.end() && j == x.end() + </pre> + <p> + +(There are at least two implementations where the expression +returns <code>false</code>.) + + </p> + <p> + +More generally, is the definition introduced in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a> meant to +make any guarantees about whether iterators actually point to the same +elements or be associated with the same containers after a +non-invalidating operation as they did before? + + </p> + <p> + +Here's a motivating example intended to demonstrate the importance of +the question: + + </p> + <pre> Container x, y ({ 1, 2}); // pseudocode to initialize y with { 1, 2 } + Container::iterator i = y.begin() + 1; + Container::iterator j = y.end(); + std::swap(x, y); + std::find(i, j, 3); + </pre> + <p> + +<code>swap()</code> guarantees that <code>i</code> and <code>j</code> +continue to be valid. Unless the spec says that even though they are +valid they may no longer denote a valid range the code above must be +well-defined. Expert opinions on this differ as does the behavior of +popular implementations for some standard <code>Containers</code>. + + </p> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="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> -14882-2003, [lib.uninitialized.copy] is currently written as follows: +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> -<pre>template <class InputIterator, class ForwardIterator> - ForwardIterator uninitialized_copy(InputIterator <i>first</i>, InputIterator <i>last</i>, - ForwardIterator <i>result</i>); +<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> + <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>Discussion:</b></p> +<p> +N2461 already replaced in 20.5.15.2 [func.wrap.func] it's originally proposed +(implicit) conversion operator to "unspecified-bool-type" by the new +explicit bool conversion, but the inverse conversion should also +use the new <tt>std::nullptr_t</tt> type instead of "unspecified-null-pointer- +type". +</p> + + +<p><b>Proposed resolution:</b></p> + +<p> +In 20.5 [function.objects], header <tt><functional></tt> synopsis replace: +</p> + +<blockquote><pre>template<class R, class... ArgTypes> + bool operator==(const function<R(ArgTypes...)>&, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>); +template<class R, class... ArgTypes> + bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>&); +template<class R, class... ArgTypes> + bool operator!=(const function<R(ArgTypes...)>&, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>); +template<class R, class... ArgTypes> + bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>&); +</pre></blockquote> + +<p> +In the class function synopsis of 20.5.15.2 [func.wrap.func] replace +</p> + +<blockquote><pre>function(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>); +... +function& operator=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>); +</pre></blockquote> + +<p> +In 20.5.15.2 [func.wrap.func], "Null pointer comparisons" replace: +</p> + +<blockquote><pre>template <class R, class... ArgTypes> + bool operator==(const function<R(ArgTypes...)>&, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>); +template <class R, class... ArgTypes> + bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>&); +template <class R, class... ArgTypes> + bool operator!=(const function<R(ArgTypes...)>&, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>); +template <class R, class... ArgTypes> + bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>&); +</pre></blockquote> + +<p> +In 20.5.15.2.1 [func.wrap.func.con], replace +</p> + +<blockquote><pre>function(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>); +... +function& operator=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>); +</pre></blockquote> + +<p> +In 20.5.15.2.6 [func.wrap.func.nullptr], replace +</p> + +<blockquote><pre>template <class R, class... ArgTypes> + bool operator==(const function<R(ArgTypes...)>& f, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>); +template <class R, class... ArgTypes> + bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>& f); +</pre></blockquote> + +<p> +and replace +</p> + +<blockquote><pre>template <class R, class... ArgTypes> + bool operator!=(const function<R(ArgTypes...)>& f, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>); +template <class R, class... ArgTypes> + bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function<R(ArgTypes...)>& f); +</pre></blockquote> + + + + + + +<hr> +<h3><a name="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> + <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>Discussion:</b></p> +<p> +The new <tt>to_string</tt> and <tt>to_wstring</tt> functions described in 21.4 [string.conversions] +have throws clauses (paragraphs 8 and 16) which say: +</p> + +<blockquote> +<i>Throws:</i> nothing +</blockquote> + +<p> +Since all overloads return either a <tt>std::string</tt> or a <tt>std::wstring</tt> by value +this throws clause is impossible to realize in general, since the <tt>basic_string</tt> +constructors can fail due to out-of-memory conditions. Either these throws +clauses should be removed or should be more detailled like: +</p> + +<blockquote> +<i>Throws:</i> Nothing if the string construction throws nothing +</blockquote> + +<p> +Further there is an editorial issue in p. 14: All three <tt>to_wstring</tt> +overloads return a <tt>string</tt>, which should be <tt>wstring</tt> instead (The +header <tt><string></tt> synopsis of 21.2 [string.classes] is correct in this +regard). +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +In 21.4 [string.conversions], remove the paragraphs 8 and 16. +</p> + +<blockquote> +<pre>string to_string(long long val); +string to_string(unsigned long long val); +string to_string(long double val); </pre> <blockquote> +<del><i>Throws:</i> nothing</del> +</blockquote> +</blockquote> + +<blockquote> +<pre><ins>w</ins>string to_wstring(long long val); +<ins>w</ins>string to_wstring(unsigned long long val); +<ins>w</ins>string to_wstring(long double val); +</pre> +<blockquote> +<del><i>Throws:</i> nothing</del> +</blockquote> +</blockquote> + + + + + + +<hr> +<h3><a name="772"></a>772. Impossible return clause in [string.conversions]</h3> +<p><b>Section:</b> 21.4 [string.conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</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>Discussion:</b></p> +<p> +The return clause 21.4 [string.conversions]/paragraph 15 of the new <tt>to_wstring</tt> +overloads says: +</p> + +<blockquote> +<i>Returns:</i> each function returns a <tt>wstring</tt> object holding the character +representation of the value of its argument that would be generated by +calling <tt>wsprintf(buf, fmt, val)</tt> with a format specifier of <tt>L"%lld"</tt>, <tt>L"%ulld"</tt>, +or <tt>L"%f"</tt>, respectively. +</blockquote> + <p> --1- <i>Effects:</i> +Problem is: There does not exist any <tt>wsprintf</tt> function in C99 (I checked +the 2nd edition of ISO 9899, and the first and the second corrigenda from +2001-09-01 and 2004-11-15). What probably meant here is the function +<tt>swprintf</tt> from <tt><wchar.h>/<cwchar></tt>, but this has the non-equivalent +declaration: </p> -<blockquote><pre>for (; first != last; ++result, ++first) - new (static_cast<void*>(&*result)) - typename iterator_traits<ForwardIterator>::value_type(*first); + +<blockquote><pre>int swprintf(wchar_t * restrict s, size_t n, +const wchar_t * restrict format, ...); </pre></blockquote> + <p> --2- <i>Returns:</i> <tt><i>result</i></tt> +therefore the paragraph needs to mention the <tt>size_t</tt> parameter <tt>n</tt>. </p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change the current wording of 21.4 [string.conversions]/p. 15 to: +</p> + +<blockquote> +<i>Returns:</i> <del>e</del><ins>E</ins>ach function returns a +<tt>wstring</tt> object holding the character representation of the +value of its argument that would be generated by calling +<tt><del>ws</del><ins>sw</ins>printf(buf, <ins>bufsz,</ins> fmt, +val)</tt> with a format specifier <ins><tt>fmt</tt></ins> of <tt>L"%lld"</tt>, +<tt>L"%ulld"</tt>, or <tt>L"%f"</tt>, respectively<ins>, where <tt>buf</tt> +designates an internal character buffer of sufficient size <tt>bufsz</tt></ins>. </blockquote> + +<p> +[Hint to the editor: The resolution also adds to mention the name of +the format specifier "fmt"] +</p> + +<p> +I also would like to remark that the current wording of it's equivalent +paragraph 7 should also mention the meaning of <tt>buf</tt> and <tt>fmt</tt>. +</p> + +<p> +Change the current wording of 21.4 [string.conversions]/p. 7 to: +</p> + +<blockquote> +<i>Returns:</i> <del>e</del><ins>E</ins>ach function returns a string object holding the +character representation of the value of its argument that would be +generated by calling <tt>sprintf(buf, fmt, val)</tt> with a format specifier <ins><tt>fmt</tt></ins> of +<tt>"%lld"</tt>, <tt>"%ulld"</tt>, or <tt>"%f"</tt>, respectively<ins>, where <tt>buf</tt> designates an internal +character buffer of sufficient size</ins>. </blockquote> + + + + + +<hr> +<h3><a name="774"></a>774. Member swap undefined for most containers</h3> +<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-01-14</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> +<p><b>Discussion:</b></p> <p> -similarily for N2369, and its corresponding section -20.6.4.1 [uninitialized.copy]. +It appears most containers declare but do not define a member-swap +function. </p> <p> -It's not clear to me what the return clause is supposed to mean, I see -two -possible interpretations: +This is unfortunate, as all overload the <tt>swap</tt> algorithm to call the +member-swap function! +(required for <tt>swappable</tt> guarantees [Table 37] and Container Requirements +[Table 87]) </p> -<ol type="a"> +<p> +Note in particular that Table 87 gives semantics of <tt>a.swap(b)</tt> as <tt>swap(a,b)</tt>, +yet for all containers we define <tt>swap(a,b)</tt> to call <tt>a.swap(b)</tt> - a circular +definition. +</p> + +<p> +A quick survey of clause 23 shows that the following containers provide a +definition for member-swap: +</p> + +<blockquote><pre>array +queue +stack +vector +</pre></blockquote> + +<p> +Whereas the following declare it, but do not define the semantics: +</p> + +<blockquote><pre>deque +list +map +multimap +multiset +priority_queue +set +unordered_map +unordered_multi_map +unordered_multi_set +unordered_set +</pre></blockquote> + +<p> +Suggested resolution: +</p> +<blockquote> +Provide a definition for each of the affected containers... +</blockquote> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Move to Open and ask Alisdair to provide wording. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Wording provided in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2590.pdf">N2590</a>. +</p> + + + + + +<hr> +<h3><a name="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> + <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>Discussion:</b></p> +<p> +The class template array synopsis in 23.2.1 [array]/3 declares a member +function +</p> + +<blockquote><pre>void assign(const T& u); +</pre></blockquote> + +<p> +which's semantic is no-where described. Since this signature is +not part of the container requirements, such a semantic cannot +be derived by those. +</p> + +<p> +I found only one reference to this function in the issue list, +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a> where the question is raised: +</p> + +<blockquote> +what's the effect of calling <tt>assign(T&)</tt> on a zero-sized array? +</blockquote> + +<p> +which does not answer the basic question of this issue. +</p> + +<p> +If this function shall be part of the <tt>std::array</tt>, it's probable +semantic should correspond to that of <tt>boost::array</tt>, but of +course such wording must be added. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Just after the section 23.2.1.4 [array.data] add the following new section: +</p> + +<p> +23.2.1.5 array::fill [array.fill] +</p> + +<blockquote> +<pre>void fill(const T& u); +</pre> + +<p> +1: <i>Effects:</i> <tt>fill_n(begin(), N, u)</tt> +</p> +</blockquote> + +<p> +[N.B: I wonder, why class <tt>array</tt> does not have a "modifiers" +section. If it had, then <tt>assign</tt> would naturally belong to it] +</p> + +<p> +Change the synopsis in 23.2.1 [array]/3: +</p> + +<blockquote><pre>template <class T, size_t N> +struct array { + ... + void <del>assign</del> <ins>fill</ins>(const T& u); + ... +</pre></blockquote> + + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +Suggest substituting "fill" instead of "assign". +</p> +<p> +Set state to Review given substitution of "fill" for "assign". +</p> +</blockquote> + + + + +<hr> +<h3><a name="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> + <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>Discussion:</b></p> +<p> +The resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a> did not resolve similar necessary changes for algorithm +<tt>remove_copy[_if]</tt>, +which seems to be an oversight. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 25.2.8 [alg.remove]/p.6, replace the N2461 requires clause with one of: +</p> + +<blockquote> +<i>Requires:</i> <del>Type <tt>T</tt> is <tt>EqualityComparable</tt> (31).</del> The ranges <tt>[first,last)</tt> +and <tt>[result,result + (last - first))</tt> shall not overlap. <ins>The expression <tt>*result = *first</tt> shall be +valid.</ins> +</blockquote> + +<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> + + + + + + +<hr> +<h3><a name="780"></a>780. <tt>std::merge()</tt> specification incorrect/insufficient</h3> +<p><b>Section:</b> 25.3.4 [alg.merge] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-01-25</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Though issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a> has fixed many open issues, it seems that some are still open: +</p> + +<p> +Both 25.3.4 [lib.alg.merge] in 14882:2003 and 25.3.4 [alg.merge] in N2461 +have no Requires element and the Effects element contains some requirements, +which is probably editorial. Worse is that: +</p> + +<ul> +<li> +no assignment requirements are specified (neither implicit nor explicit). +</li> + +<li> +the effects clause just speaks of "merges", which is badly worded +near to a circular definition. +</li> + +<li> +p. 2 mentions a range <tt>[first, last)</tt>, which is not defined by the +function arguments or otherwise. +</li> + +<li> +p. 2 says "according to the ordering defined by comp" which is both +incomplete (because +this excludes the first variant with <) and redundant (because the +following subordinate +clause mentions comp again) +</li> +</ul> + + + +<p><b>Proposed resolution:</b></p> +<p> +In 25.3.4 [alg.merge] replace p.1+ 2: +</p> + +<blockquote> +<p> +<i>Effects:</i> <del>Merges</del> <ins>Copies all the elements of the</ins> two sorted ranges <tt>[first1,last1)</tt> and +<tt>[first2,last2)</tt> into the range +<del><tt>[result,result + (last1 - first1) + (last2 - first2))</tt></del> +<ins><tt>[result, last)</tt> (where <tt>last</tt> is equal to <tt>result + (last1 +- first1) + (last2 - first2))</tt>, such that resulting range will be +sorted in non-decreasing order; that is, for every iterator <tt>i</tt> in +<tt>[result,last)</tt> other than <tt>result</tt>, the condition <tt>*i < *(i - 1)</tt> or, +respectively, <tt>comp(*i, *(i - 1))</tt> will be false</ins>. +</p> + +<p> +<ins><i>Requires:</i></ins> The resulting range shall not overlap with either of the original ranges. <del>The list will be sorted in non-decreasing +order according to the ordering defined by <tt>comp</tt>; that is, for every iterator <tt>i</tt> in +<tt>[first,last)</tt> other than <tt>first</tt>, the condition <tt>*i < *(i - 1)</tt> or +<tt>comp(*i, *(i - 1))</tt> will be false.</del> <ins>The results of the expressions <tt>*first1</tt> and <tt>*first2</tt> +shall be writable to the output iterator.</ins> +</p> +</blockquote> + +<p> +[N.B.: I attempted to reuse the wording style of <tt>inplace_merge</tt>, +therefore proposing to +insert ", respectively," between both predicate tests. This is no +strictly necessary as +other parts of <tt><algorithm></tt> show, just a matter of consistency] +</p> + + + + + + +<hr> +<h3><a name="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> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Table 16 of TR1 requires that all Pseudo Random Number generators have a +</p> + +<blockquote><pre>seed(integer-type s) +</pre></blockquote> + +<p> +member function that is equivalent to: +</p> + +<blockquote><pre>mygen = Generator(s) +</pre></blockquote> + +<p> +But the generators <tt>xor_combine</tt> and <tt>discard_block</tt> have no such seed member, only the +</p> + +<blockquote><pre>template <class Gen> +seed(Gen&); +</pre></blockquote> + +<p> +member, which will not accept an integer literal as an argument: something that appears to violate the intent of Table 16. +</p> + +<p> +So... is this a bug in TR1? +</p> + +<p>This is a real issue BTW, since the Boost implementation does adhere +to the requirements of Table 16, while at least one commercial +implementation does not and follows a strict adherence to sections +5.1.4.5 and 5.1.4.6 instead. +</p> + +<p><i>[ +Jens adds: +]</i></p> + + +<blockquote> +Both engines do have the necessary +constructor, therefore the omission of the <tt>seed()</tt> member +functions appears to be an oversight. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="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> + <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>Discussion:</b></p> +<p> +In 25.3.3.4 [binary.search]/3 the complexity of <tt>binary_search</tt> is described as +</p> + +<blockquote> +At most <tt>log(last - first) + 2</tt> comparisons. +</blockquote> + +<p> +This should be precised and brought in line with the nomenclature used for +<tt>lower_bound</tt>, <tt>upper_bound</tt>, and <tt>equal_range</tt>. +</p> + +<p> +All existing libraries I'm aware of, delegate to +<tt>lower_bound</tt> (+ one further comparison). Since +issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a> +has now WP status, the resolution of #787 should +be brought in-line with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a> by changing the <tt>+ 2</tt> +to <tt>+ O(1)</tt>. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 25.3.3.4 [binary.search]/3 +</p> + +<blockquote> +<i>Complexity:</i> At most <tt>log<ins><sub>2</sub></ins>(last - first) + <del>2</del> <ins><i>O</i>(1)</ins></tt> comparisons. +</blockquote> + + + + + +<hr> +<h3><a name="788"></a>788. ambiguity in [istream.iterator]</h3> +<p><b>Section:</b> 24.5.1 [istream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-02-06</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.iterator">active issues</a> in [istream.iterator].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator">issues</a> in [istream.iterator].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The description of how an istream_iterator object becomes an +end-of-stream iterator is a) ambiguous and b) out of date WRT +issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>: +</p> + +<blockquote> +<tt>istream_iterator</tt> reads (using <tt>operator>></tt>) successive elements from the +input stream for which it was constructed. After it is constructed, and +every time <tt>++</tt> is used, the iterator reads and stores a value of <tt>T</tt>. If +the end of stream is reached (<tt>operator void*()</tt> on the stream returns +<tt>false</tt>), the iterator becomes equal to the <i>end-of-stream</i> iterator value. +The constructor with no arguments <tt>istream_iterator()</tt> always constructs +an end of stream input iterator object, which is the only legitimate +iterator to be used for the end condition. The result of <tt>operator*</tt> on an +end of stream is not defined. For any other iterator value a <tt>const T&</tt> is +returned. The result of <tt>operator-></tt> on an end of stream is not defined. +For any other iterator value a <tt>const T*</tt> is returned. It is impossible to +store things into istream iterators. The main peculiarity of the istream +iterators is the fact that <tt>++</tt> operators are not equality preserving, +that is, <tt>i == j</tt> does not guarantee at all that <tt>++i == ++j</tt>. Every time <tt>++</tt> +is used a new value is read. +</blockquote> + +<p> +<tt>istream::operator void*()</tt> returns null if <tt>istream::fail()</tt> is <tt>true</tt>, +otherwise non-null. <tt>istream::fail()</tt> returns <tt>true</tt> if <tt>failbit</tt> or +<tt>badbit</tt> is set in <tt>rdstate()</tt>. Reaching the end of stream doesn't +necessarily imply that <tt>failbit</tt> or <tt>badbit</tt> is set (e.g., after +extracting an <tt>int</tt> from <tt>stringstream("123")</tt> the stream object will +have reached the end of stream but <tt>fail()</tt> is <tt>false</tt> and <tt>operator +void*()</tt> will return a non-null value). +</p> + +<p> +Also I would prefer to be explicit about calling <tt>fail()</tt> here +(there is no <tt>operator void*()</tt> anymore.) +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 24.5.1 [istream.iterator]/1: +</p> + +<blockquote> +<tt>istream_iterator</tt> reads (using <tt>operator>></tt>) successive elements from the +input stream for which it was constructed. After it is constructed, and +every time <tt>++</tt> is used, the iterator reads and stores a value of <tt>T</tt>. If +<del>the end of stream is reached</del> <ins>the iterator fails to read and store a value of <tt>T</tt></ins> +(<tt><del>operator void*()</del> <ins>fail()</ins></tt> on the stream returns +<tt><del>false</del> <ins>true</ins></tt>), the iterator becomes equal to the <i>end-of-stream</i> iterator value. +The constructor with no arguments <tt>istream_iterator()</tt> always constructs +an end of stream input iterator object, which is the only legitimate +iterator to be used for the end condition. The result of <tt>operator*</tt> on an +end of stream is not defined. For any other iterator value a <tt>const T&</tt> is +returned. The result of <tt>operator-></tt> on an end of stream is not defined. +For any other iterator value a <tt>const T*</tt> is returned. It is impossible to +store things into istream iterators. The main peculiarity of the istream +iterators is the fact that <tt>++</tt> operators are not equality preserving, +that is, <tt>i == j</tt> does not guarantee at all that <tt>++i == ++j</tt>. Every time <tt>++</tt> +is used a new value is read. +</blockquote> + + + + + +<hr> +<h3><a name="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> + <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>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#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.) +</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="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: +</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 vaues over a range.) +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +How do you specify the function so that it does not return negative +values? If you do it is a bad construction. This requirement is already +there. Where in each bin does one evaluate the function? In the middle. +Need to revisit tomorrow. +</blockquote> + + +<p><b>Proposed resolution:</b></p> + + + + + +<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> + <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>Discussion:</b></p> +<p> +<tt>piecewise_constant_distribution</tt> should have a constructor like: +</p> + +<blockquote><pre>template<class _Fn> + piecewise_constant_distribution(size_t _Count, + _Ty _Low, _Ty _High, _Fn& _Func); +</pre></blockquote> + +<p> +(Makes it easier to fill a histogram with function vaues 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><b>Proposed resolution:</b></p> + + + + + +<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> +<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> + + + + + + +<hr> +<h3><a name="800"></a>800. Issues in 26.4.7.1 [rand.util.seedseq](6)</h3> +<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2008-02-18</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The for-loop in the algorithm specification has <tt>n</tt> iterations, where <tt>n</tt> is +defined to be <tt>end - begin</tt>, i.e. the number of supplied w-bit quantities. +Previous versions of this algorithm and the general logic behind it +suggest that this is an oversight and that in the context of the +for-loop <tt>n</tt> should be the number of full 32-bit quantities in <tt>b</tt> (rounded +upwards). If <tt>w</tt> is 64, the current algorithm throws away half of all bits +in <tt>b</tt>. If <tt>w</tt> is 16, the current algorithm sets half of all elements in <tt>v</tt> +to 0. +</p> + +<p> +There are two more minor issues: +</p> + +<ul> +<li> +Strictly speaking <tt>end - begin</tt> is not defined since +<tt>InputIterator</tt> is not required to be a random access iterator. +</li> +<li> +Currently all integral types are allowed as input to the <tt>seed_seq</tt> +constructor, including <tt>bool</tt>. IMHO allowing <tt>bool</tt>s unnecessarily +complicates the implementation without any real benefit to the user. +I'd suggest to exclude <tt>bool</tt>s as input. +</li> +</ul> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Move to OPEN Bill will try to propose a resolution by the next meeting. +</blockquote> + +<p><i>[ +post Bellevue: Bill provided wording. +]</i></p> + + +<p> +This issue is made moot if <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a> is accepted. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Replace 26.4.7.1 [rand.util.seedseq] paragraph 6 with: +</p> + +<blockquote> +<p> +<i>Effects:</i> Constructs a <tt>seed_seq</tt> object by effectively concatenating the +low-order <tt>u</tt> bits of each of the elements of the supplied sequence <tt>[begin, +end)</tt> +in ascending order of significance to make a (possibly very large) unsigned +binary number <tt>b</tt> having a total of <tt>n</tt> bits, and then carrying out the +following +algorithm: +</p> + +<blockquote><pre>for( v.clear(); n > 0; n -= 32 ) + v.push_back(b mod 2<sup>32</sup>), b /= 2<sup>32</sup>; +</pre></blockquote> +</blockquote> + + + + + +<hr> +<h3><a name="801"></a>801. <tt>tuple</tt> and <tt>pair</tt> trivial members</h3> +<p><b>Section:</b> 20.3 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> + <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-02-18</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple">active issues</a> in [tuple].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple">issues</a> in [tuple].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Classes with trivial special member functions are inherently more +efficient than classes without such functions. This efficiency is +particularly pronounced on modern ABIs that can pass small classes +in registers. Examples include value classes such as complex numbers +and floating-point intervals. Perhaps more important, though, are +classes that are simple collections, like <tt>pair</tt> and <tt>tuple</tt>. When the +parameter types of these classes are trivial, the <tt>pair</tt>s and <tt>tuple</tt>s +themselves can be trivial, leading to substantial performance wins. +</p> +<p> +The current working draft make specification of trivial functions +(where possible) much easer through <tt>default</tt>ed and <tt>delete</tt>d functions. +As long as the semantics of defaulted and deleted functions match +the intended semantics, specification of defaulted and deleted +functions will yield more efficient programs. +</p> +<p> +There are at least two cases where specification of an explicitly +defaulted function may be desirable. +</p> +<p> +First, the <tt>std::pair</tt> template has a non-trivial default constructor, +which prevents static initialization of the pair even when the +types are statically initializable. Changing the definition to +</p> + +<blockquote><pre>pair() = default; +</pre></blockquote> + +<p> +would enable such initialization. Unfortunately, the change is +not semantically neutral in that the current definition effectively +forces value initialization whereas the change would not value +initialize in some contexts. +</p> + +<p> +** Does the committee confirm that forced value initialization +was the intent? If not, does the committee wish to change the +behavior of <tt>std::pair</tt> in C++0x? +</p> +<p> +Second, the same default constructor issue applies to <tt>std::tuple</tt>. +Furthermore, the <tt>tuple</tt> copy constructor is current non-trivial, +which effectively prevents passing it in registers. To enable +passing <tt>tuples</tt> in registers, the copy constructor should be +make explicitly <tt>default</tt>ed. The new declarations are: +</p> + +<blockquote><pre>tuple() = default; +tuple(const tuple&) = default; +</pre></blockquote> + +<p> +This changes is not implementation neutral. In particular, it +prevents implementations based on pointers to the parameter +types. It does however, permit implementations using the +parameter types as bases. +</p> +<p> +** How does the committee wish to trade implementation +efficiency versus implementation flexibility? +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +General agreement; the first half of the issue is NAD. +</p> +<p> +Before voting on the second half, it was agreed that a "Strongly Favor" +vote meant support for trivial tuples (assuming usual requirements met), +even at the expense of other desired qualities. A "Weakly Favor" vote +meant support only if not at the expense of other desired qualities. +</p> +<p> +Concensus: Go forward, but not at expense of other desired qualities. +</p> +<p> +It was agreed to Alisdair should fold this work in with his other +pair/tuple action items, above, and that issue 801 should be "open", but +tabled until Alisdair's proposals are disposed of. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="803"></a>803. Simplification of <tt>seed_seq::seq_seq</tt></h3> +<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</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>Discussion:</b></p> +<p> +<tt>seed_seq(InputIterator begin, InputIterator end);</tt> constructs a <tt>seed_seq</tt> +object repacking the bits of supplied sequence <tt>[begin, end)</tt> into a +32-bit vector. +</p> +<p> +This repacking triggers several problems: +</p> +<ol> +<li> +Distinctness of the output of <tt>seed_seq::generate</tt> required the +introduction of the initial "<tt>if (w < 32) v.push_back(n);</tt>" (Otherwise +the unsigned short vectors [1, 0] and [1] generate the same sequence.) +</li> +<li> +Portability demanded the introduction of the template parameter <tt>u</tt>. +(Otherwise some sequences could not be obtained on computers where no +integer types are exactly 32-bits wide.) +</li> +<li> +The description and algorithm have become unduly complicated. +</li> +</ol> +<p> +I propose simplifying this <tt>seed_seq</tt> constructor to be "32-bit only". +Despite it's being simpler, there is NO loss of functionality (see +below). +</p> +<p> +Here's how the description would read +</p> +<blockquote> +<p> +26.4.7.1 [rand.util.seedseq] Class <tt>seed_seq</tt> +</p> + +<blockquote> +<pre>template<class InputIterator> + seed_seq(InputIterator begin, InputIterator end); +</pre> +<blockquote> +<p> +5 <i>Requires:</i> NO CHANGE +</p> +<p> +6 <i>Effects:</i> Constructs a <tt>seed_seq</tt> object by +</p> +<blockquote> +<pre>for (InputIterator s = begin; s != end; ++s) + v.push_back((*s) mod 2^32); +</pre> +</blockquote> +</blockquote> +</blockquote> +</blockquote> + +<p> +Discussion: +</p> +<p> +The chief virtues here are simplicity, portability, and generality. +</p> +<ul> <li> -The notion of <tt><i>result</i></tt> is supposed to mean the value given by the -function parameter <tt><i>result</i></tt> [Note to the issue editor: Please use italics for -<tt><i>result</i></tt>]. -This seems somewhat implied by recognizing that both the function -parameter -and the name used in the clause do have the same italic font. +Simplicity -- compare the above specification with the +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a> proposal. </li> <li> -The notion of "result" is supposed to mean the value of <tt><i>result</i></tt> -after the -preceding effects clause. This is in fact what all implementations I -checked -do (and which is probably it's intend, because it matches the -specification of <tt>std::copy</tt>). +Portability -- with <tt>iterator_traits<InputIterator>::value_type = +uint_least32_t</tt> the user is guaranteed to get the same behavior across +platforms. +</li> +<li> +Generality -- any behavior that the +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a> +proposal can achieve can be +obtained with this simpler proposal (albeit with a shuffling of bits +in the input sequence). +</li> +</ul> +<p> +Arguments (and counter-arguments) against making this change (and +retaining the +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a> +behavior) are: +</p> +<ul> +<li> +<p> +The user can pass an array of <tt>unsigned char</tt> and <tt>seed_seq</tt> will nicely + repack it. +</p> +<p> + Response: So what? Consider the seed string "ABC". The + <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a> + proposal results in +</p> +<blockquote><pre>v = { 0x3, 0x434241 }; +</pre></blockquote> +<p> +while the simplified proposal yields +</p> +<blockquote><pre>v = { 0x41, 0x42, 0x43 }; +</pre></blockquote> +<p> +The results produced by <tt>seed_seq::generate</tt> with the two inputs are +different but nevertheless equivalently "mixed up" and this remains +true even if the seed string is long. +</p> +</li> +<li> +<p> +With long strings (e.g., with bit-length comparable to the number of + bits in the state), <tt>v</tt> is longer (by a factor of 4) with the simplified + proposal and <tt>seed_seq::generate</tt> will be slower. +</p> +<p> +Response: It's unlikely that the efficiency of <tt>seed_seq::generate</tt> will + be a big issue. If it is, the user is free to repack the seed vector + before constructing <tt>seed_seq</tt>. +</p> +</li> +<li> +<p> +A user can pass an array of 64-bit integers and all the bits will be + used. +</p> +<p> + Response: Indeed. However, there are many instances in the + <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a> + where integers are silently coerced to a narrower width and this + should just be a case of the user needing to read the documentation. + The user can of course get equivalent behavior by repacking his seed + into 32-bit pieces. Furthermore, the unportability of the + <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a> + proposal with +</p> +<blockquote><pre>unsigned long s[] = {1, 2, 3, 4}; +seed_seq q(s, s+4); +</pre></blockquote> +<p> + which typically results in <tt>v = {1, 2, 3, 4}</tt> on 32-bit machines and in +<tt>v = {1, 0, 2, 0, 3, 0, 4, 0}</tt> on 64-bit machines is a major pitfall for + unsuspecting users. +</p> +</li> +</ul> + +<p> +Note: this proposal renders moot issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#782">782</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>. +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Walter needs to ask Fermilab for guidance. Defer till tomorrow. Bill likes the proposed resolution. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 26.4.7.1 [rand.util.seedseq]: +</p> + +<blockquote> +<pre>template<class InputIterator<del>, + size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits</del>> + seed_seq(InputIterator begin, InputIterator end); +</pre> +<blockquote> +<p> +-5- <i>Requires:</i> <tt>InputIterator</tt> shall satisfy the requirements of an input iterator (24.1.1) +such that <tt>iterator_traits<InputIterator>::value_type</tt> shall denote an integral type. +</p> +<p> +-6- Constructs a <tt>seed_seq</tt> object by <del>rearranging some or all of the bits of the supplied sequence +<tt>[begin,end)</tt> of w-bit quantities into 32-bit units, as if by the following: </del> +</p> +<p> +<del>First extract the rightmost <tt>u</tt> bits from each of the <tt>n = end +- begin</tt> elements of the supplied sequence and concatenate all the +extracted bits to initialize a single (possibly very large) unsigned +binary number, <tt>b = ∑<sup>n-1</sup><sub>i=0</sub> (begin[i] +mod 2<sup>u</sup>) · 2<sup>w·i</sup></tt> (in which the bits of each <tt>begin[i]</tt> +are treated as denoting an unsigned quantity). Then carry out +the following algorithm:</del> +</p> +<blockquote><pre><del> +v.clear(); +if ($w$ < 32) + v.push_back($n$); +for( ; $n$ > 0; --$n$) + v.push_back(b mod 2<sup>32</sup>), b /= 2<sup>32</sup>; +</del></pre></blockquote> +<blockquote> +<pre><ins> +for (InputIterator s = begin; s != end; ++s) + v.push_back((*s) mod 2<sup>32</sup>); +</ins></pre> +</blockquote> +</blockquote> +</blockquote> + + + + + +<hr> +<h3><a name="804"></a>804. Some problems with classes <tt>error_code</tt>/<tt>error_condition</tt></h3> +<p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</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>Discussion:</b></p> +<ol type="A"> +<li> +<p> +19.4.2.1 [syserr.errcode.overview]/1, class <tt>error_code</tt> and +19.4.3.1 [syserr.errcondition.overview]/, class <tt>error_condition</tt> synopses +declare an expository data member <tt>cat_</tt>: +</p> +<blockquote><pre>const error_category& cat_; // exposition only +</pre></blockquote> +<p> +which is used to define the semantics of several members. The decision +to use a member of reference type lead to several problems: +</p> +<ol> +<li> +The classes are not <tt>(Copy)Assignable</tt>, which is probably not the intent. +</li> +<li> +The post conditions of all modifiers from +19.4.2.3 [syserr.errcode.modifiers] and 19.4.3.3 [syserr.errcondition.modifiers], resp., +cannot be fulfilled. +</li> +</ol> +<p> +The simple fix would be to replace the reference by a pointer member. +</p> +</li> + +<li> +I would like to give the editorial remark that in both classes the +constrained <tt>operator=</tt> +overload (template with <tt>ErrorCodeEnum</tt> argument) makes in invalid +usage of <tt>std::enable_if</tt>: By using the default value for the second <tt>enable_if</tt> +parameter the return type would be defined to be <tt>void&</tt> even in otherwise +valid circumstances - this return type must be explicitly provided (In +<tt>error_condition</tt> the first declaration uses an explicit value, but of wrong +type). +</li> + +<li> +The member function <tt>message</tt> throws clauses ( +19.4.1.2 [syserr.errcat.virtuals]/10, 19.4.2.4 [syserr.errcode.observers]/8, and +19.4.3.4 [syserr.errcondition.observers]/6) guarantee "throws nothing", +although +they return a <tt>std::string</tt> by value, which might throw in out-of-memory +conditions (see related issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>). </li> </ol> + +<p><b>Proposed resolution:</b></p> <p> -The problem is: I see nothing in the standard which grants that this -interpretation -is correct, specifically [lib.structure.specifications] or -17.3.1.3 [structure.specifications] -resp. do not clarify which "look-up" rules apply for names found in -the elements -of the detailed specifications - Do they relate to the corresponding -synopsis or -to the effects clause (or possibly other elements)? Fortunately most -detailed -descriptions are unambigious in this regard, e.g. this problem does -not apply -for <tt>std::copy</tt>. +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.1 [syserr.errcode.overview]/1, class <tt>error_code</tt> synopsis, modifiers section, +replace the current <tt>operator=</tt> overload by the following: +</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: +</p> + +<blockquote> +const error_category<del>&</del><ins>*</ins> cat_; // exposition only +</blockquote> + +<p> +In 19.4.2.2 [syserr.errcode.constructors], change p. 2 to read: +</p> + +<blockquote> +<pre>error_code(); +</pre> +<blockquote> +<p> +</p><p>...</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: +</p> + +<blockquote> +<pre>error_code(int val, const error_category& cat); +</pre> +<blockquote> +<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 p. 1 to read: +</p> + +<blockquote> +<pre>void assign(int val, const error_category& cat); +</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: +</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 19.4.2.4 [syserr.errcode.observers], change p. 3 to read: +</p> + +<blockquote> +<pre>const error_category& category() const; +</pre> +<blockquote> +<p> +</p><p>...</p> + +<p> +<i>Returns:</i> <tt><ins>*</ins>cat_</tt>. +</p> +</blockquote> +</blockquote> + +<p> +In 19.4.2.4 [syserr.errcode.observers], remove the throws clause p. 8. +</p> + +<blockquote> +<pre>string message() const; +</pre> +<blockquote> +<p> +</p><p>...</p> + +<p> +<del><i>Throws:</i> Nothing.</del> +</p> +</blockquote> +</blockquote> + +<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> +</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: +</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: +</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: +</p> + +<blockquote> +<pre>error_condition(); +</pre> +<blockquote> +<p> +</p><p>...</p> + +<p> +<i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&</ins>posix_category</tt>. +</p> +</blockquote> +</blockquote> + +<p> +In the same section, change p. 5 to read: +</p> + +<blockquote> +<pre>error_condition(int val, const error_category& cat); +</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.3.3 [syserr.errcondition.modifiers], change p. 1 to read: +</p> + +<blockquote> +<pre>void assign(int val, const error_category& cat); +</pre> +<blockquote> +<p> +<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&</ins>cat</tt>. +</p> +</blockquote> +</blockquote> + +<p> +In the same section replace the current <tt>operator=</tt> overload declaration by: +</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: +</p> + +<blockquote> +<pre>const error_category& category() const; +</pre> +<blockquote> +<p> +<i>Returns:</i> <tt><ins>*</ins>cat_</tt>. +</p> +</blockquote> +</blockquote> + +<p> +In 19.4.3.4 [syserr.errcondition.observers], remove the throws clause p. 6. +</p> + +<blockquote> +<pre>string message() const; +</pre> +<blockquote> +<p> +</p><p>...</p> + +<p> +<del><i>Throws:</i> Nothing.</del> +</p> +</blockquote> +</blockquote> + + + + + + + +<hr> +<h3><a name="805"></a>805. <tt>posix_error::posix_errno</tt> concerns</h3> +<p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</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>Discussion:</b></p> +<p> +19.4 [syserr] +</p> + +<blockquote><pre>namespace posix_error { + enum posix_errno { + address_family_not_supported, // EAFNOSUPPORT + ... +</pre></blockquote> + +<p> +should rather use the new scoped-enum facility (7.2 [dcl.enum]), +which would avoid the necessity for a new <tt>posix_error</tt> +namespace, if I understand correctly. +</p> + +<p><i>[ +Further discussion: +]</i></p> + + +<blockquote> +<p> +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf">N2347</a>, +Strongly Typed Enums, since renamed Scoped Enums. +</p> +<p> +Alberto Ganesh Barbati also raised this issue in private email, and also proposed the scoped-enum solution. +</p> +<p> +Nick Stoughton asked in Bellevue that <tt>posix_error</tt> and <tt>posix_errno</tt> not be used as names. The LWG agreed. +</p> +<p> +The wording for the Proposed resolution was provided by Beman Dawes. +</p> +</blockquote> <p><b>Proposed resolution:</b></p> <p> -Change the wording of the return clause to say (20.6.4.1 [uninitialized.copy]): +Change System error support 19.4 [syserr] as indicated: </p> +<blockquote><pre><del>namespace posix_error {</del> + enum <del>posix_errno</del> <ins>class errc</ins> { + address_family_not_supported, // EAFNOSUPPORT + ... + wrong_protocol_type, // EPROTOTYPE + }; +<del>} // namespace posix_error</del> + +template <> struct is_error_condition_enum<<del>posix_error::posix_errno</del> <ins>errc</ins>> + : public true_type {} + +<del>namespace posix_error {</del> + error_code make_error_code(<del>posix_errno</del> <ins>errc</ins> e); + error_condition make_error_condition(<del>posix_errno</del> <ins>errc</ins> e); +<del>} // namespace posix_error</del> +</pre></blockquote> + +<p> +Change System error support 19.4 [syserr] : +</p> + +<blockquote> +<del>The <tt>is_error_code_enum</tt> and <tt>is_error_condition_enum</tt> templates may be +specialized for user-defined types to indicate that such a type is +eligible for class <tt>error_code</tt> and class <tt>error_condition</tt> automatic +conversions, respectively.</del> +</blockquote> + +<p> +Change System error support 19.4 [syserr] and its subsections: +</p> + +<blockquote> +<ul> +<li> +remove all occurrences of <tt>posix_error::</tt> +</li> +<li> +change all instances of <tt>posix_errno</tt> to <tt>errc</tt> +</li> +<li> +change all instances of <tt>posix_category</tt> to <tt>generic_category</tt> +</li> +<li> +change all instances of <tt>get_posix_category</tt> to <tt>get_generic_category</tt> +</li> +</ul> +</blockquote> + +<p> +Change Error category objects 19.4.1.5 [syserr.errcat.objects], paragraph 2: +</p> + +<blockquote> +<i>Remarks:</i> The object's <tt>default_error_condition</tt> and equivalent virtual +functions shall behave as specified for the class <tt>error_category</tt>. The +object's name virtual function shall return a pointer to the string +<del>"POSIX"</del> <ins>"GENERIC"</ins>. +</blockquote> + +<p> +Change 19.4.2.5 [syserr.errcode.nonmembers] Class <tt>error_code</tt> non-member functions as indicated: +</p> + +<blockquote> +<pre>error_code make_error_code(<del>posix_errno</del> <ins>errc</ins> e); +</pre> + <blockquote> +<i>Returns:</i> <tt>error_code(<ins>static_cast<int>(</ins>e<ins>)</ins>, <del>posix</del><ins>generic</ins>_category)</tt>. +</blockquote> +</blockquote> + <p> --2- <i>Returns:</i> <ins>The value of</ins> <tt><i>result</i></tt> <ins>after effects have taken place.</ins> +Change 19.4.3.5 [syserr.errcondition.nonmembers] Class <tt>error_condition</tt> non-member functions as indicated: </p> + +<blockquote> +<pre>error_condition make_error_condition(<del>posix_errno</del> <ins>errc</ins> e); +</pre> + +<blockquote> +<i>Returns:</i> <tt>error_condition(<ins>static_cast<int>(</ins>e<ins>)</ins>, <del>posix</del><ins>generic</ins>_category)</tt>. +</blockquote> </blockquote> +<p><b>Rationale:</b></p> +<table border="1"> +<tbody><tr> +<th colspan="2">Names Considered</th> +</tr> + +<tr> +<td><tt>portable</tt></td> +<td> +Too non-specific. Did not wish to reserve such a common word in +namespace std. Not quite the right meaning, either. +</td> +</tr> + +<tr> +<td><tt>portable_error</tt></td> +<td> +Too long. Explicit qualification is always required for scoped enums, so +a short name is desirable. Not quite the right meaning, either. May be +misleading because <tt>*_error</tt> in the std lib is usually an exception class +name. +</td> +</tr> + +<tr> +<td><tt>std_error</tt></td> +<td> +Fairly short, yet explicit. But in fully qualified names like +<tt>std::std_error::not_enough_memory</tt>, the std_ would be unfortunate. Not +quite the right meaning, either. May be misleading because <tt>*_error</tt> in +the std lib is usually an exception class name. +</td> +</tr> + +<tr> +<td><tt>generic</tt></td> +<td> +Short enough. The category could be <tt>generic_category</tt>. Fully qualified +names like <tt>std::generic::not_enough_memory</tt> read well. Reserving in +namespace std seems dicey. +</td> +</tr> + +<tr> +<td><tt>generic_error</tt></td> +<td> +Longish. The category could be <tt>generic_category</tt>. Fully qualified names +like <tt>std::generic_error::not_enough_memory</tt> read well. Misleading because +<tt>*_error</tt> in the std lib is usually an exception class name. +</td> +</tr> + +<tr> +<td><tt>generic_err</tt></td> +<td> +A bit less longish. The category could be <tt>generic_category</tt>. Fully +qualified names like <tt>std::generic_err::not_enough_memory</tt> read well. +</td> +</tr> + +<tr> +<td><tt>gen_err</tt></td> +<td> +Shorter still. The category could be <tt>generic_category</tt>. Fully qualified +names like <tt>std::gen_err::not_enough_memory</tt> read well. +</td> +</tr> + +<tr> +<td><tt>generr</tt></td> +<td> +Shorter still. The category could be <tt>generic_category</tt>. Fully qualified +names like <tt>std::generr::not_enough_memory</tt> read well. +</td> +</tr> + +<tr> +<td><tt>error</tt></td> +<td> +Shorter still. The category could be <tt>generic_category</tt>. Fully qualified +names like <tt>std::error::not_enough_memory</tt> read well. Do we want to use +this general a name? +</td> +</tr> + +<tr> +<td><tt>err</tt></td> +<td> +Shorter still. The category could be <tt>generic_category</tt>. Fully qualified +names like <tt>std::err::not_enough_memory</tt> read well. Although alone it +looks odd as a name, given the existing <tt>errno</tt> and <tt>namespace std</tt> names, +it seems fairly intuitive. +Problem: <tt>err</tt> is used throughout the standard library as an argument name +and in examples as a variable name; it seems too confusing to add yet +another use of the name. +</td> +</tr> + +<tr> +<td><tt>errc</tt></td> +<td> +Short enough. The "c" stands for "constant". The category could be +<tt>generic_category</tt>. Fully qualified names like +<tt>std::errc::not_enough_memory</tt> read well. Although alone it looks odd as a +name, given the existing <tt>errno</tt> and <tt>namespace std</tt> names, it seems fairly +intuitive. There are no uses of <tt>errc</tt> in the current C++ standard. +</td> +</tr> +</tbody></table> + + + + + +<hr> +<h3><a name="806"></a>806. <tt>unique_ptr::reset</tt> effects incorrect, too permissive</h3> +<p><b>Section:</b> 20.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> + <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>Discussion:</b></p> +<p> +<tt>void unique_ptr::reset(T* p = 0)</tt> is currently specified as: +</p> + +<blockquote> +<i>Effects:</i> If <tt>p == get()</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>. +</blockquote> + +<p> +There are two problems with this. One, if <tt>get() == 0</tt> and <tt>p != 0</tt>, the +deleter is called with a NULL pointer, and this is probably not what's +intended (the destructor avoids calling the deleter with 0.) +</p> + +<p> +Two, the special check for <tt>get() == p</tt> is generally not needed and such a +situation usually indicates an error in the client code, which is being +masked. As a data point, <tt>boost::shared_ptr</tt> was changed to assert on such +self-resets in 2001 and there were no complaints. +</p> + +<p> +One might think that self-resets are necessary for operator= to work; it's specified to perform +</p> + +<blockquote><pre>reset( u.release() ); +</pre></blockquote> + +<p> +and the self-assignment +</p> + +<blockquote><pre>p = move(p); +</pre></blockquote> + +<p> +might appear to result in a self-reset. But it doesn't; the <tt>release()</tt> is +performed first, zeroing the stored pointer. In other words, <tt>p.reset( +q.release() )</tt> works even when <tt>p</tt> and <tt>q</tt> are the same <tt>unique_ptr</tt>, and there +is no need to special-case <tt>p.reset( q.get() )</tt> to work in a similar +scenario, as it definitely doesn't when <tt>p</tt> and <tt>q</tt> are separate. +</p> + + + +<p><b>Proposed resolution:</b></p> + +<p> +Change 20.6.11.2.5 [unique.ptr.single.modifiers]: +</p> + +<blockquote> +<pre>void reset(T* p = 0); +</pre> +<blockquote> +-4- <i>Effects:</i> If <tt><del>p ==</del> get()<ins> == 0</ins></tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>. +</blockquote> +</blockquote> + +<p> +Change 20.6.11.3.3 [unique.ptr.runtime.modifiers]: +</p> + +<blockquote> +<pre>void reset(T* p = 0); +</pre> +<blockquote> +<p>...</p> +<p> +-2- <i>Effects:</i> If <tt><del>p ==</del> get()<ins> == 0</ins></tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>. +</p> +</blockquote> +</blockquote> + + + + + + +<hr> +<h3><a name="807"></a>807. <tt>tuple</tt> construction should not fail unless its element's construction fails</h3> +<p><b>Section:</b> 20.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> + <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>Discussion:</b></p> +<p> +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> Added a throws clause to <tt>bind</tt> constructors. I believe the same throws clause +should be added to <tt>tuple</tt> except it ought to take into account move constructors as well. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add to 20.3.1.2 [tuple.cnstr]: +</p> + +<blockquote> +<p> +For each <tt>tuple</tt> constructor and assignment operator, an exception is thrown only if the construction +or assignment of one of the types in <tt>Types</tt> throws an exception. +</p> +</blockquote> + + + + + +<hr> +<h3><a name="808"></a>808. [forward] incorrect redundant specification</h3> +<p><b>Section:</b> 20.2.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</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>Discussion:</b></p> +<p> +p4 (forward) says: +</p> +<blockquote> +<i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue. +</blockquote> + +<p> +First of all, lvalue-ness and rvalue-ness are properties of an expression, +not of a type (see 3.10 [basic.lval]). Thus, the phrasing "Return type" is wrong. +Second, the phrase says exactly what the core language wording says for +folding references in 14.3.1 [temp.arg.type]/p4 and for function return values +in 5.2.2 [expr.call]/p10. (If we feel the wording should be retained, it should +at most be a note with cross-references to those sections.) +</p> +<p> +The prose after the example talks about "forwarding as an <tt>int&</tt> (an lvalue)" etc. +In my opinion, this is a category error: "<tt>int&</tt>" is a type, "lvalue" is a +property of an expression, orthogonal to its type. (Btw, expressions cannot +have reference type, ever.) +</p> +<p> +Similar with move: +</p> +<blockquote> +Return type: an rvalue. +</blockquote> +<p> +is just wrong and also redundant. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 20.2.2 [forward] as indicated: +</p> + +<blockquote> +<pre>template <class T> T&& forward(typename identity<T>::type&& t); +</pre> + +<blockquote> +<p>...</p> +<p> +<del><i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue.</del> +</p> +<p>...</p> +<p> +-7- In the first call to <tt>factory</tt>, <tt>A1</tt> is deduced as <tt>int</tt>, so 2 is forwarded to <tt>A</tt>'s constructor +as <del>an <tt>int&&</tt> (</del>an rvalue<del>)</del>. In the second call to factory, <tt>A1</tt> is deduced +as <tt>int&</tt>, so <tt>i</tt> is forwarded to <tt>A</tt>'s constructor as <del>an <tt>int&</tt> (</del>an lvalue<del>)</del>. +In both cases, <tt>A2</tt> is deduced as double, so 1.414 is forwarded to <tt>A</tt>'s constructor as +<del><tt>double&&</tt> (</del>an rvalue<del>)</del>. +</p> +</blockquote> + +<pre>template <class T> typename remove_reference<T>::type&& move(T&& t); +</pre> + +<blockquote> +<p>...</p> +<p> +<del><i>Return type:</i> an rvalue.</del> +</p> +</blockquote> + +</blockquote> + + + + + + +<hr> +<h3><a name="809"></a>809. std::swap should be overloaded for array types</h3> +<p><b>Section:</b> 25.2.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</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>Discussion:</b></p> +<p> +For the sake of generic programming, the header <code><algorithm></code> should provide an +overload of <code>std::swap</code> for array types: +</p><pre>template<class T, size_t N> void swap(T (&a)[N], T (&b)[N]); +</pre> + + +<p> +It became apparent to me that this overload is missing, when I considered how to write a swap +function for a generic wrapper class template. +(Actually I was thinking of Boost's <a href="http://www.boost.org/libs/utility/value_init.htm">value_initialized</a>.) +Please look at the following template, <code>W</code>, and suppose that is intended to be a very +<em>generic</em> wrapper: +</p><pre>template<class T> class W { +public: + T data; +}; +</pre> +Clearly <code>W<T></code> is <em>CopyConstructible and CopyAssignable</em>, and therefore +<em>Swappable</em>, whenever <code>T</code> is <em>CopyConstructible and CopyAssignable</em>. +Moreover, <code>W<T></code> is <em>also</em> Swappable when <code>T</code> is an array type +whose element type is CopyConstructible and CopyAssignable. +Still it is recommended to add a <em>custom</em> swap function template to such a class template, +for the sake of efficiency and exception safety. +(E.g., <em>Scott Meyers, Effective C++, Third Edition, item 25: Consider support for a non-throwing +swap</em>.) +This function template is typically written as follows: +<pre>template<class T> void swap(W<T>& x, W<T>& y) { + using std::swap; + swap(x.data, y.data); +} +</pre> +Unfortunately, this will introduce an undesirable inconsistency, when <code>T</code> is an array. +For instance, <code>W<std::string[8]></code> is Swappable, but the current Standard does not +allow calling the custom swap function that was especially written for <code>W</code>! +<pre>W<std::string[8]> w1, w2; // Two objects of a Swappable type. +std::swap(w1, w2); // Well-defined, but inefficient. +using std::swap; +swap(w1, w2); // Ill-formed, just because ADL finds W's swap function!!! +</pre> + +<code>W</code>'s <code>swap</code> function would try to call <code>std::swap</code> for an array, +<code>std::string[8]</code>, which is not supported by the Standard Library. +This issue is easily solved by providing an overload of <code>std::swap</code> for array types. +This swap function should be implemented in terms of swapping the elements of the arrays, so that +it would be non-throwing for arrays whose element types have a non-throwing swap. + + +<p> +Note that such an overload of <code>std::swap</code> should also support <em>multi-dimensional</em> +arrays. Fortunately that isn't really an issue, because it would do so <i>automatically</i>, by +means of recursion. +</p> + +<p> +For your information, there was a discussion on this issue at comp.lang.c++.moderated: <a href="http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/9341ebd3635c9c74">[Standard +Library] Shouldn't std::swap be overloaded for C-style arrays?</a> +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add an extra condition to the definition of Swappable requirements [swappable] in 20.1.1 [utility.arg.requirements]: +</p> +<blockquote> +- <tt>T</tt> is <tt>Swappable</tt> if <tt>T</tt> is an array type whose element type is <tt>Swappable</tt>. +</blockquote> +<p> +Add the following to 25.2.3 [alg.swap]: +</p> +<blockquote> +<pre>template<class T, size_t N> void swap(T (&a)[N], T (&b)[N]); +</pre> +<blockquote> +<i>Requires:</i> Type <code>T</code> shall be <tt>Swappable</tt>. +</blockquote> +<blockquote> +<i>Effects:</i> <code>swap_ranges(a, a + N, b);</code> +</blockquote> +</blockquote> + + + + + +<hr> +<h3><a name="810"></a>810. Missing traits dependencies in operational semantics of extended manipulators</h3> +<p><b>Section:</b> 27.6.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2008-03-01</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ext.manip">active issues</a> in [ext.manip].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ext.manip">issues</a> in [ext.manip].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The recent draft (as well as the original proposal n2072) uses an +operational semantic +for <tt>get_money</tt> ([ext.manip]/3) and <tt>put_money</tt> ([ext.manip]/5), which uses +</p> + +<blockquote><pre>istreambuf_iterator<charT> +</pre></blockquote> + +<p> +and +</p> + +<blockquote><pre>ostreambuf_iterator<charT> +</pre></blockquote> + +<p> +resp, instead of the iterator instances, with explicitly provided +traits argument (The operational semantic defined by <tt>f</tt> is also traits +dependent). This is an obvious oversight because both <tt>*stream_buf</tt> +c'tors expect a <tt>basic_streambuf<charT,traits></tt> as argument. +</p> +<p> +The same problem occurs within the <tt>get_time</tt> and <tt>put_time</tt> semantic (p. +7 and p. 9) +of n2071 incorporated in N2521, where additional to the problem we +have an editorial issue in <tt>get_time</tt> (<tt>streambuf_iterator</tt> instead of +<tt>istreambuf_iterator</tt>). +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 27.6.4 [ext.manip]/3 within function <tt>f</tt> replace the first line +</p> + +<blockquote><pre>template <class charT, class traits, class moneyT> +void f(basic_ios<charT, traits>& str, moneyT& mon, bool intl) { + typedef istreambuf_iterator<charT<ins>, traits</ins>> Iter; + ... +</pre></blockquote> + +<p> +In 27.6.4 [ext.manip]/4 remove the first template <tt>charT</tt> parameter: +</p> + +<blockquote><pre>template <<del>class charT, </del>class moneyT> unspecified put_money(const moneyT& mon, bool intl = false<ins>)</ins>; +</pre></blockquote> + +<p> +In 27.6.4 [ext.manip]/5 within function <tt>f</tt> replace the first line +</p> + +<blockquote><pre>template <class charT, class traits, class moneyT> +void f(basic_ios<charT, traits>& str, const moneyT& mon, bool intl) { + typedef ostreambuf_iterator<charT<ins>, traits</ins>> Iter; + ... +</pre></blockquote> + +<p> +In 27.6.4 [ext.manip]/7 within function <tt>f</tt> replace the first line +</p> + +<blockquote><pre>template <class charT, class traits> +void f(basic_ios<charT, traits>& str, struct tm *tmb, const charT *fmt) { + typedef <ins>i</ins>streambuf_iterator<charT<ins>, traits</ins>> Iter; + ... +</pre></blockquote> + +<p> +In 27.6.4 [ext.manip]/8 add const: +</p> + +<blockquote><pre>template <class charT> unspecified put_time(<ins>const</ins> struct tm *tmb, const charT *fmt); +</pre></blockquote> + +<p> +In 27.6.4 [ext.manip]/9 within function <tt>f</tt> replace the first line +</p> + +<blockquote><pre>template <class charT, class traits> +void f(basic_ios<charT, traits>& str, const struct tm *tmb, const charT *fmt) { + typedef ostreambuf_iterator<charT<ins>, traits</ins>> Iter; + ... +</pre></blockquote> + +<p> +Add to the <tt><iomanip></tt> synopsis in 27.6 [iostream.format] +</p> + +<blockquote><pre>template <class moneyT> unspecified get_money(moneyT& mon, bool intl = false); +template <class moneyT> unspecified put_money(const moneyT& mon, bool intl = false); +template <class charT> unspecified get_time(struct tm *tmb, const charT *fmt); +template <class charT> unspecified put_time(const struct tm *tmb, const charT *fmt); +</pre></blockquote> + + + + + + +<hr> +<h3><a name="811"></a>811. <tt>pair</tt> of pointers no longer works with literal 0</h3> +<p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Doug Gregor <b>Date:</b> 2008-03-14</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<blockquote><pre>#include <utility> + +int main() +{ + std::pair<char *, char *> p (0,0); +} +</pre></blockquote> + +<p> +I just got a bug report about that, because it's valid C++03, but not +C++0x. The important realization, for me, is that the emplace +proposal---which made <tt>push_back</tt> variadic, causing the <tt>push_back(0)</tt> +issue---didn't cause this break in backward compatibility. The break +actually happened when we added this pair constructor as part of adding +rvalue references into the language, long before variadic templates or +emplace came along: +</p> + +<blockquote><pre>template<class U, class V> pair(U&& x, V&& y); +</pre></blockquote> + +<p> +Now, concepts will address this issue by constraining that <tt>pair</tt> +constructor to only <tt>U</tt>'s and <tt>V</tt>'s that can properly construct "first" and +"second", e.g. (from +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2322.pdf">N2322</a>): +</p> + +<blockquote><pre>template<class U , class V > +requires Constructible<T1, U&&> && Constructible<T2, V&&> +pair(U&& x , V&& y ); +</pre></blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="812"></a>812. unsolicited multithreading considered harmful?</h3> +<p><b>Section:</b> 25.3.1 [alg.sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Paul McKenney <b>Date:</b> 2008-02-27</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Multi-threading is a good thing, but unsolicited multi-threading can +potentially be harmful. For example, <tt>sort()</tt> performance might be +greatly increased via a multithreaded implementation. However, such +a multithreaded implementation could result in concurrent invocations +of the user-supplied comparator. This would in turn result in problems +given a caching comparator that might be written for complex sort keys. +Please note that this is not a theoretical issue, as multithreaded +implementations of <tt>sort()</tt> already exist. +</p> +<p> +Having a multithreaded <tt>sort()</tt> available is good, but it should not +be the default for programs that are not explicitly multithreaded. +Users should not be forced to deal with concurrency unless they have +asked for it. +</p> + +<p><i>[ +This may be covered by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2410.html">N2410</a> +Thread-Safety in the Standard Library (Rev 1). +]</i></p> + + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="813"></a>813. "empty" undefined for <tt>shared_ptr</tt></h3> +<p><b>Section:</b> 20.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> + <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>Discussion:</b></p> +<p> +Several places in 20.6.12.2 [util.smartptr.shared] refer to an "empty" <tt>shared_ptr</tt>. +However, that term is nowhere defined. The closest thing we have to a +definition is that the default constructor creates an empty <tt>shared_ptr</tt> +and that a copy of a default-constructed <tt>shared_ptr</tt> is empty. Are any +other <tt>shared_ptr</tt>s empty? For example, is <tt>shared_ptr((T*) 0)</tt> empty? What +are the properties of an empty <tt>shared_ptr</tt>? We should either clarify this +term or stop using it. +</p><p> +</p> +One reason it's not good enough to leave this term up to the reader's +intuition is that, in light of +<a href="http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2007/n2351.htm">N2351</a> +and issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, most readers' +intuitive understanding is likely to be wrong. Intuitively one might +expect that an empty <tt>shared_ptr</tt> is one that doesn't store a pointer, +but, whatever the definition is, that isn't it. + + +<p><i>[ +Peter adds: +]</i></p> + + +<blockquote> +<p> +Or, what is an "empty" <tt>shared_ptr</tt>? +</p> + +<ul> +<li> +<p> +Are any other <tt>shared_ptrs</tt> empty? +</p> +<p> +Yes. Whether a given <tt>shared_ptr</tt> instance is empty or not is (*) +completely specified by the last mutating operation on that instance. +Give me an example and I'll tell you whether the <tt>shared_ptr</tt> is empty or +not. +</p> +<blockquote> +(*) If it isn't, this is a legitimate defect. +</blockquote> +</li> + +<li> +<p> +For example, is <tt>shared_ptr((T*) 0)</tt> empty? +</p> +<p> +No. If it were empty, it would have a <tt>use_count()</tt> of 0, whereas it is +specified to have an <tt>use_count()</tt> of 1. +</p> +</li> + +<li> +<p> +What are the properties of an empty <tt>shared_ptr</tt>? +</p> +<p> +The properties of an empty <tt>shared_ptr</tt> can be derived from the +specification. One example is that its destructor is a no-op. Another is +that its <tt>use_count()</tt> returns 0. I can enumerate the full list if you +really like. +</p> +</li> + +<li> +<p> +We should either clarify this term or stop using it. +</p> +<p> +I don't agree with the imperative tone +</p> +<p> +A clarification would be either a no-op - if it doesn't contradict the +existing wording - or a big mistake if it does. +</p> +<p> +I agree that a clarification that is formally a no-op may add value. +</p> +</li> + +<li> +<p> +However, that term is nowhere defined. +</p> +<p> +Terms can be useful without a definition. Consider the following +simplistic example. We have a type <tt>X</tt> with the following operations +defined: +</p> +<blockquote><pre>X x; +X x2(x); +X f(X x); +X g(X x1, X x2); +</pre></blockquote> +<p> +A default-constructed value is green.<br> +A copy has the same color as the original.<br> +<tt>f(x)</tt> returns a red value if the argument is green, a green value otherwise.<br> +<tt>g(x1,x2)</tt> returns a green value if the arguments are of the same color, a red value otherwise. +</p> + +<p> +Given these definitions, you can determine the color of every instance +of type <tt>X</tt>, even if you have absolutely no idea what green and red mean. +</p> + +<p> +Green and red are "nowhere defined" and completely defined at the same time. +</p> +</li> +</ul> + +<p> +Alisdair's wording is fine. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Append the following sentance to 20.6.12.2 [util.smartptr.shared] +</p> +<blockquote> +The <code>shared_ptr</code> class template stores a pointer, usually obtained +via <code>new</code>. <code>shared_ptr</code> implements semantics of +shared ownership; the last remaining owner of the pointer is responsible for +destroying the object, or otherwise releasing the resources associated with +the stored pointer. <ins>A <code>shared_ptr</code> object that does not own +a pointer is said to be <i>empty</i>.</ins> +</blockquote> + + + + + +<hr> +<h3><a name="814"></a>814. <tt>vector<bool>::swap(reference, reference)</tt> not defined</h3> +<p><b>Section:</b> 23.2.7 [vector.bool] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-17</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#vector.bool">active issues</a> in [vector.bool].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.bool">issues</a> in [vector.bool].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +<tt>vector<bool>::swap(reference, reference)</tt> has no definition. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="815"></a>815. <tt>std::function</tt> and <tt>reference_closure</tt> do not use perfect forwarding</h3> +<p><b>Section:</b> 20.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> + <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>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><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="816"></a>816. Should <tt>bind()</tt>'s returned functor have a nofail copy ctor when <tt>bind()</tt> is nofail?</h3> +<p><b>Section:</b> 20.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> + <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2008-02-08</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.bind.bind">active issues</a> in [func.bind.bind].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> notes that <tt>bind(f, t1, ..., tN)</tt> +should be nofail when <tt>f, t1, ..., tN</tt> have nofail copy ctors. +</p> +<p> +However, no guarantees are provided for the copy ctor of the functor +returned by <tt>bind()</tt>. (It's guaranteed to have a copy ctor, which can +throw implementation-defined exceptions: <tt>bind()</tt> returns a forwarding +call wrapper, TR1 3.6.3/2. A forwarding call wrapper is a call wrapper, +TR1 3.3/4. Every call wrapper shall be CopyConstructible, TR1 3.3/4. +Everything without an exception-specification may throw +implementation-defined exceptions unless otherwise specified, C++03 +17.4.4.8/3.) +</p> +<p> +Should the nofail guarantee requested by Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> be extended +to cover both calling <tt>bind()</tt> and copying the returned functor? +</p> + +<p><i>[ +Howard adds: +]</i></p> + + +<blockquote> +<tt>tuple</tt> construction should probably have a similar guarantee. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="817"></a>817. <tt>bind</tt> needs to be moved</h3> +<p><b>Section:</b> 20.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> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-03-17</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.bind.bind">active issues</a> in [func.bind.bind].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The functor retureed by <tt>bind()</tt> should have a move constructor that +requires only move construction of its contained functor and bound arguments. +That way move-only functors can be passed to objects such as <tt>thread</tt>. +</p> +<p> +This issue is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="818"></a>818. wording for memory ordering</h3> +<p><b>Section:</b> 29.1 [atomics.order] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-03-22</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +29.1 [atomics.order] p1 says in the table that +</p> + +<blockquote> +<table border="1"> +<tbody><tr> +<th>Element</th><th>Meaning</th> +</tr> +<tr> +<td><tt>memory_order_acq_rel</tt></td> +<td>the operation has both acquire and release semantics</td> +</tr> +</tbody></table> +</blockquote> + +<p> +To my naked eye, that seems to imply that even an atomic read has both +acquire and release semantics. +</p> + +<p> +Then, p1 says in the table: +</p> + +<blockquote> +<table border="1"> +<tbody><tr> +<th>Element</th><th>Meaning</th> +</tr> +<tr> +<td><tt>memory_order_seq_cst</tt></td> +<td>the operation has both acquire and release semantics, + and, in addition, has sequentially-consistent operation ordering</td> +</tr> +</tbody></table> +</blockquote> + +<p> +So that seems to be "the same thing" as <tt>memory_order_acq_rel</tt>, with additional +constraints. +</p> + +<p> +I'm then reading p2, where it says: +</p> + +<blockquote> +The <tt>memory_order_seq_cst</tt> operations that load a value are acquire operations +on the affected locations. The <tt>memory_order_seq_cst</tt> operations that store a value +are release operations on the affected locations. +</blockquote> + +<p> +That seems to imply that atomic reads only have acquire semantics. If that +is intended, does this also apply to <tt>memory_order_acq_rel</tt> and the individual +load/store operations as well? +</p> + +<p> +Also, the table in p1 contains phrases with "thus" that seem to indicate +consequences of normative wording in 1.10 [intro.multithread]. That shouldn't be in +normative text, for the fear of redundant or inconsistent specification with +the other normative text. +</p> + +<p> +Double-check 29.4.4 [atomics.types.operations] that each +operation clearly says whether it's a load or a store operation, or +both. (It could be clearer, IMO. Solution not in current proposed resolution.) +</p> + +<p> +29.1 [atomics.order] p2: What's a "consistent execution"? It's not defined in +1.10 [intro.multithread], it's just used in notes there. +</p> + +<p> +And why does 29.4.4 [atomics.types.operations] p9 for "load" say: +</p> + + +<blockquote> +<i>Requires:</i> The order argument shall not be <tt>memory_order_acquire</tt> +nor <tt>memory_order_acq_rel</tt>. +</blockquote> + +<p> +(Since this is exactly the same restriction as for "store", it seems to be a typo.) +</p> + +<p> +And then: 29.4.4 [atomics.types.operations] p12: +</p> + +<blockquote> +These operations are read-modify-write operations in the sense of the +"synchronizes with" definition (1.10 [intro.multithread]), so both such an operation and the +evaluation that produced the input value synchronize with any evaluation +that reads the updated value. +</blockquote> + +<p> +This is redundant with 1.10 [intro.multithread], see above for the reasoning. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Replace the cross-reference in p1 to refer to 1.1 [intro.scope] instead of +1.7 [intro.memory]. +Rephrase the table in as follows (maybe don't use a table): +</p> + +<blockquote> +<p> +For <tt>memory_order_relaxed</tt>, no operation orders memory. +</p> + +<p> +For <tt>memory_order_release</tt>, <tt>memory_order_acq_rel</tt>, and <tt>memory_order_seq_cst</tt>, +a store operation performs a release operation on the affected memory location. +</p> + +<p> +For <tt>memory_order_acquire</tt>, <tt>memory_order_acq_rel</tt>, and <tt>memory_order_seq_cst</tt>, +a load operation performs an acquire operation on the affected memory location. +</p> +</blockquote> + +<p> +Rephrase 29.1 [atomics.order] p2: +</p> + +<blockquote> +<del>The <tt>memory_order_seq_cst</tt> operations that load a value are +acquire operations on the affected locations. The +<tt>memory_order_seq_cst</tt> operations that store a value are release +operations on the affected locations.</del> +<del>In addition, in a consistent +execution, t</del><ins>T</ins>here <del>must be</del> <ins>is</ins> a single +total order <tt>S</tt> on all +<tt>memory_order_seq_cst</tt> operations, consistent with the happens before +order and modification orders for all affected locations, such that each +<tt>memory_order_seq_cst</tt> operation observes either the last preceding +modification according to this order <tt>S</tt>, or the result of an operation +that is not <tt>memory_order_seq_cst</tt>. [<i>Note:</i> Although it is not explicitly +required that <tt>S</tt> include locks, it can always be extended to an order +that does include lock and unlock operations, since the ordering between +those is already included in the happens before ordering. <i>-- end note</i>] +</blockquote> + +<p> +Rephrase 29.4.4 [atomics.types.operations] p12 as: +</p> + +<blockquote> +<i>Effects:</i> Atomically replaces the value pointed to by object or by +this with desired. Memory is affected according to the value of order. +These operations are read-modify-write operations <del>in the sense of the +"synchronizes with" definition</del> (1.10 [intro.multithread])<del>, so both such an operation and the +evaluation that produced the input value synchronize with any evaluation +that reads the updated value</del>. +</blockquote> + +<p> +Same in p15, p20, p22. +</p> + + + + + + +<hr> +<h3><a name="819"></a>819. rethrow_if_nested</h3> +<p><b>Section:</b> 18.7.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-25</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Looking at the wording I submitted for <tt>rethrow_if_nested</tt>, I don't think I +got it quite right. +</p> + +<p> +The current wording says: +</p> + +<blockquote> +<pre>template <class E> void rethrow_if_nested(const E& e); +</pre> +<blockquote> +<p> +<i>Effects:</i> Calls <tt>e.rethrow_nested()</tt> only if <tt>e</tt> +is publicly derived from <tt>nested_exception</tt>. +</p> +</blockquote> +</blockquote> + +<p> +This is trying to be a bit subtle, by requiring <tt>e</tt> (not <tt>E</tt>) to be publicly +derived from <tt>nested_exception</tt> the idea is that a <tt>dynamic_cast</tt> would be +required to be sure. Unfortunately, if <tt>e</tt> is dynamically but not statically +derived from <tt>nested_exception</tt>, <tt>e.rethrow_nested()</tt> is ill-formed. +</p> + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="820"></a>820. <tt>current_exception()</tt>'s interaction with throwing copy ctors</h3> +<p><b>Section:</b> 18.7.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2008-03-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +As of N2521, the Working Paper appears to be silent about what +<tt>current_exception()</tt> should do if it tries to copy the currently handled +exception and its copy constructor throws. 18.7.5 [propagation]/7 says "If the +function needs to allocate memory and the attempt fails, it returns an +<tt>exception_ptr</tt> object that refers to an instance of <tt>bad_alloc</tt>.", but +doesn't say anything about what should happen if memory allocation +succeeds but the actual copying fails. +</p> + +<p> +I see three alternatives: (1) return an <tt>exception_ptr</tt> object that refers +to an instance of some fixed exception type, (2) return an <tt>exception_ptr</tt> +object that refers to an instance of the copy ctor's thrown exception +(but if that has a throwing copy ctor, an infinite loop can occur), or +(3) call <tt>terminate()</tt>. +</p> + +<p> +I believe that <tt>terminate()</tt> is the most reasonable course of action, but +before we go implement that, I wanted to raise this issue. +</p> + +<p><i>[ +Peter's summary: +]</i></p> + + +<blockquote> +<p> +The current practice is to not have throwing copy constructors in +exception classes, because this can lead to <tt>terminate()</tt> as described in +15.5.1 [except.terminate]. Thus calling <tt>terminate()</tt> in this situation seems +consistent and does not introduce any new problems. +</p> + +<p> +However, the resolution of core issue 475 may relax this requirement: +</p> + +<blockquote> +The CWG agreed with the position that <tt>std::uncaught_exception()</tt> should +return <tt>false</tt> during the copy to the exception object and that <tt>std::terminate()</tt> +should not be called if that constructor exits with an exception. +</blockquote> + +<p> +Since throwing copy constructors will no longer call <tt>terminate()</tt>, option +(3) doesn't seem reasonable as it is deemed too drastic a response in a +recoverable situation. +</p> + +<p> +Option (2) cannot be adopted by itself, because a potential infinite +recursion will need to be terminated by one of the other options. +</p> + +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Add the following paragraph after 18.7.5 [propagation]/7: +</p> + +<blockquote> +<p> +<i>Returns (continued):</i> If the attempt to copy the current exception +object throws an exception, the function returns an <tt>exception_ptr</tt> that +refers to the thrown exception or, if this is not possible, to an +instance of <tt>bad_exception</tt>. +</p> +<p> +[<i>Note:</i> The copy constructor of the thrown exception may also fail, so +the implementation is allowed to substitute a <tt>bad_exception</tt> to avoid +infinite recursion. <i>-- end note.</i>] +</p> +</blockquote> + + + + + + +<hr> +<h3><a name="821"></a>821. Minor cleanup : <tt>unique_ptr</tt></h3> +<p><b>Section:</b> 20.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> + <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: +</p> + +<blockquote> +<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>); +</pre> + +<p> +-1- <i>Requires:</i> Does not accept pointer types which are convertible +to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (diagnostic +required). [<i>Note:</i> One implementation technique is to create a private +templated overload. <i>-- end note</i>] +</p> +</blockquote> + +<p> +This could be cleaned up by mandating the overload as a public deleted +function. In addition, we should probably overload <tt>reset</tt> on <tt>nullptr_t</tt> +to be a stronger match than the deleted overload. Words... +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add to class template definition in 20.6.11.3 [unique.ptr.runtime] +</p> + +<blockquote> +<pre>// modifiers +T* release(); +void reset(T* p = 0); +<ins>void reset( nullptr_t );</ins> +<ins>template< typename T > void reset( T ) = delete;</ins> +void swap(unique_ptr&& u); +</pre> +</blockquote> + +<p> +Update 20.6.11.3.3 [unique.ptr.runtime.modifiers] +</p> + +<blockquote> +<pre>void reset(pointer p = pointer()); +<ins>void reset(nullptr_t);</ins> +</pre> + +<p> +<del>-1- <i>Requires:</i> Does not accept pointer types which are convertible +to <tt>pointer</tt> (diagnostic +required). [<i>Note:</i> One implementation technique is to create a private +templated overload. <i>-- end note</i>]</del> +</p> +<p> +<i>Effects:</i> If <tt>get() == nullptr</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>. +</p> +<p>...</p> +</blockquote> + +<p><i>[ +Note this wording incorporates resolutions for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a> (New) and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a> (Ready). +]</i></p> + + + + + + +<hr> +<h3><a name="822"></a>822. Object with explicit copy constructor no longer <tt>CopyConstructible</tt></h3> +<p><b>Section:</b> 20.1.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> James Kanze <b>Date:</b> 2008-04-01</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +I just noticed that the following program is legal in C++03, but +is forbidden in the current draft: +</p> + +<blockquote><pre>#include <vector> +#include <iostream> + +class Toto +{ +public: + Toto() {} + explicit Toto( Toto const& ) {} +} ; + +int +main() +{ + std::vector< Toto > v( 10 ) ; + return 0 ; +} +</pre></blockquote> + +<p> +Is this change intentional? (And if so, what is the +justification? I wouldn't call such code good, but I don't see +any reason to break it unless we get something else in return.) +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +In 20.1.1 [utility.arg.requirements] change Table 33: <tt>MoveConstructible</tt> requirements [moveconstructible]: +</p> + +<blockquote> +<table border="1"> +<tbody><tr> +<th>expression</th><th>post-condition</th> +</tr> +<tr> +<td><tt>T t<ins>(rv)</ins><del> = rv</del></tt></td><td><tt>t</tt> is equivalent to the value of <tt>rv</tt> before the construction</td> +</tr> +<tr> +<td colspan="2" align="center">...</td> +</tr> +</tbody></table> +</blockquote> + +<p> +In 20.1.1 [utility.arg.requirements] change Table 34: <tt>CopyConstructible</tt> requirements [copyconstructible]: +</p> + +<blockquote> +<table border="1"> +<tbody><tr> +<th>expression</th><th>post-condition</th> +</tr> +<tr> +<td><tt>T t<ins>(u)</ins><del> = u</del></tt></td><td>the value of <tt>u</tt> is unchanged and is equivalent to <tt>t</tt></td> +</tr> +<tr> +<td colspan="2" align="center">...</td> +</tr> +</tbody></table> +</blockquote> + + + + + +<hr> +<h3><a name="823"></a>823. <tt>identity<void></tt> seems broken</h3> +<p><b>Section:</b> 20.2.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</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>Discussion:</b></p> +<p> +N2588 seems to have added an <tt>operator()</tt> member function to the +<tt>identity<></tt> helper in 20.2.2 [forward]. I believe this change makes it no +longer possible to instantiate <tt>identity<void></tt>, as it would require +forming a reference-to-<tt>void</tt> type as this <tt>operator()</tt>'s parameter type. +</p> + +<p> +Suggested resolution: Specialize <tt>identity<void></tt> so as not to require +the member function's presence. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="824"></a>824. rvalue ref issue with <tt>basic_string</tt> inserter</h3> +<p><b>Section:</b> 21.3.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</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>Discussion:</b></p> +<p> +In the current working paper, the <tt><string></tt> header synopsis at the end of +21.2 [string.classes] lists a single <tt>operator<<</tt> overload +for <tt>basic_string</tt>. +</p> + +<blockquote><pre>template<class charT, class traits, class Allocator> + basic_ostream<charT, traits>& + operator<<(basic_ostream<charT, traits>&& os, + const basic_string<charT,traits,Allocator>& str); +</pre></blockquote> + +<p> +The definition in 21.3.8.9 [string.io] lists two: +</p> + +<blockquote><pre>template<class charT, class traits, class Allocator> + basic_ostream<charT, traits>& + operator<<(basic_ostream<charT, traits>& os, + const basic_string<charT,traits,Allocator>& str); + +template<class charT, class traits, class Allocator> + basic_ostream<charT, traits>& + operator<<(basic_ostream<charT, traits>&& os, + const basic_string<charT,traits,Allocator>& str); +</pre></blockquote> + +<p> +I believe the synopsis in 21.2 [string.classes] is correct, and the first of the two +signatures in 21.3.8.9 [string.io] should be deleted. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<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 +[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> + <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>Discussion:</b></p> +<p> +Should the following use rvalues references to stream in insert/extract +operators? +</p> + +<ul> +<li>19.4.2.1 [syserr.errcode.overview]</li> +<li>20.6.12.2.8 [util.smartptr.shared.io]</li> +<li>22.2.8 [facets.examples]</li> +<li>23.3.5.3 [bitset.operators]</li> +<li>26.3.6 [complex.ops]</li> +<li>Doubled signatures in 27.5 [stream.buffers] for character inserters +(ref 27.6.2.6.4 [ostream.inserters.character]) ++ definition 27.6.2.6.4 [ostream.inserters.character]</li> +<li>28.9 [re.submatch]</li> +</ul> + + +<p><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: +]</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><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="827"></a>827. <tt>constexpr shared_ptr::shared_ptr()?</tt></h3> +<p><b>Section:</b> 20.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> + <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-04-11</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Would anyone object to making the default constructor of <tt>shared_ptr</tt> (and +<tt>weak_ptr</tt> and <tt>enable_shared_from_this) constexpr</tt>? This would enable +static initialization for <tt>shared_ptr</tt> variables, eliminating another +unfair advantage of raw pointers. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="828"></a>828. Static initialization for <tt>std::mutex</tt>?</h3> +<p><b>Section:</b> 30.3.1.1 [thread.mutex.class] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</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>Discussion:</b></p> +<p> +[Note: I'm assuming here that 3.6.2 [basic.start.init]/1 will be fixed.] +</p> +<p> +Currently <tt>std::mutex</tt> doesn't support static initialization. This is a +regression with respect to <tt>pthread_mutex_t</tt>, which does. I believe that +we should strive to eliminate such regressions in expressive power where +possible, both to ease migration and to not provide incentives to (or +force) people to forego the C++ primitives in favor of pthreads. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<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> + <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>Discussion:</b></p> +<p>Consider this code:</p> + +<blockquote> +<pre>exception_ptr xp;</pre> +<pre>try {do_something(); } + +catch (const runtime_error& ) {xp = current_exception();} + +... + +rethrow_exception(xp);</pre> +</blockquote> + +<p> +Say <code>do_something()</code> throws an exception object of type <code> +range_error</code>. What is the type of the exception object thrown by <code> +rethrow_exception(xp)</code> above? It must have a type of <code>range_error</code>; +if it were of type <code>runtime_error</code> it still isn't possible to +propagate an exception and the exception_ptr/current_exception/rethrow_exception +machinery serves no useful purpose. +</p> + +<p> +Unfortunately, the current wording does not explicitly say that. Different +people read the current wording and come to different conclusions. While it may +be possible to deduce the correct type from the current wording, it would be +much clearer to come right out and explicitly say what the type of the referred +to exception is. +</p> + +<p><i>[ +Peter adds: +]</i></p> + + +<blockquote> +<p> +I don't like the proposed resolution of 829. The normative text is +unambiguous that the <tt>exception_ptr</tt> refers to the <em>currently handled +exception</em>. This term has a standard meaning, see 15.3 [except.handle]/8; this is the +exception that <tt>throw;</tt> would rethrow, see 15.1 [except.throw]/7. +</p> +<p> +A better way to address this is to simply add the non-normative example +in question as a clarification. The term <i>currently handled exception</i> +should be italicized and cross-referenced. A [<i>Note:</i> the currently +handled exception is the exception that a throw expression without an +operand (15.1 [except.throw]/7) would rethrow. <i>--end note</i>] is also an option. +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> + +<p> +After 18.7.5 [propagation] , paragraph 7, add the indicated text: +</p> + +<blockquote> +<pre>exception_ptr current_exception();</pre> + +<blockquote> +<p> +<i>Returns:</i> <code>exception_ptr</code> object that refers +to the currently handled exception or a copy of the currently handled +exception, or a null <code>exception_ptr</code> object if no exception is being handled. If +the function needs to allocate memory and the attempt fails, it returns an +<code>exception_ptr</code> object that refers to an instance of <code>bad_alloc</code>. +It is unspecified whether the return values of two successive calls to +<code>current_exception</code> refer to the same exception object. +[<i>Note:</i> that is, it +is unspecified whether <code>current_exception</code> +creates a new copy each time it is called. +<i>-- end note</i>] +</p> + +<p> +<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> + +</blockquote> +</blockquote> + + + + + + +<hr> +<h3><a name="830"></a>830. Incomplete list of char_traits specializations</h3> +<p><b>Section:</b> 21.1 [char.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</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>Discussion:</b></p> +<p> + Paragraph 4 of 21.1 [char.traits] mentions that this + section specifies two specializations (<code>char_traits<char></code> + and (<code>char_traits<wchar_t></code>). However, there are actually + four specializations provided, i.e. in addition to the two above also + <code>char_traits<char16_t></code> and <code>char_traits<char32_t></code>). + I guess this was just an oversight and there is nothing wrong with just + fixing this. +</p> + +<p><i>[ +Alisdair adds: +]</i></p> + +<blockquote> +<tt>char_traits< char16/32_t ></tt> +should also be added to <tt><ios_fwd></tt> in 27.2 [iostream.forward], and all the specializations +taking a <tt>char_traits</tt> parameter in that header. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> + Replace paragraph 4 of 21.1 [char.traits] by: +</p> +<blockquote> +<p> + This subclause specifies a struct template, <code>char_traits<charT></code>, + and four explicit specializations of it, <code>char_traits<char></code>, + <code>char_traits<char16_t></code>, <code>char_traits<char32_t></code>, and + <code>char_traits<wchar_t></code>, all of which appear in the header + <string> and satisfy the requirements below. +</p> +</blockquote> + + + + + +<hr> +<h3><a name="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> + <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>Discussion:</b></p> +<p> +Initialization of objects of class <tt>error_code</tt> +(19.4.2 [syserr.errcode]) and class +<tt>error_condition</tt> (19.4.3 [syserr.errcondition]) can be made simpler and more reliable by use of +the new <tt>constexpr</tt> feature +[<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2349.pdf">N2349</a>] +of C++0x. Less code will need to be +generated for both library implementations and user programs when +manipulating constant objects of these types. +</p> + +<p> +This was not proposed originally because the constant expressions +proposal was moving into the standard at about the same time as the +Diagnostics Enhancements proposal +[<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html">N2241</a>], +and it wasn't desirable to +make the later depend on the former. There were also technical concerns +as to how <tt>constexpr</tt> would apply to references. Those concerns are now +resolved; <tt>constexpr</tt> can't be used for references, and that fact is +reflected in the proposed resolution. +</p> + +<p> +Thanks to Jens Maurer, Gabriel Dos Reis, and Bjarne Stroustrup for clarification of <tt>constexpr</tt> requirements. +</p> + +<p> +LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a> is related in that it raises the question of whether the +exposition only member <tt>cat_</tt> of class <tt>error_code</tt> (19.4.2 [syserr.errcode]) and class +<tt>error_condition</tt> (19.4.3 [syserr.errcondition]) should be presented as a reference or pointer. +While in the context of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a> that is arguably an editorial question, +presenting it as a pointer becomes more or less required with this +proposal, given <tt>constexpr</tt> does not play well with references. The +proposed resolution thus changes the private member to a pointer, which +also brings it in sync with real implementations. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +The proposed wording assumes the LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a> proposed wording has been +applied to the WP, resulting in the former <tt>posix_category</tt> being renamed +<tt>generic_category</tt>. If <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a> has not been applied, the names in this +proposal must be adjusted accordingly. +</p> + +<p> +Change 19.4.1.1 [syserr.errcat.overview] Class +<tt>error_category</tt> overview <tt>error_category</tt> synopsis as +indicated: +</p> + +<blockquote><pre><del>const error_category& get_generic_category();</del> +<del>const error_category& get_system_category();</del> + +<del>static</del> <ins>extern</ins> const error_category<del>&</del><ins>* const</ins> generic_category<del> = get_generic_category()</del>; +<del>static</del> <ins>extern</ins> const error_category<del>&</del><ins>* const</ins> <del>native_category</del> system_category<del> = get_system_category()</del>; +</pre></blockquote> + +<p> +Change 19.4.1.5 [syserr.errcat.objects] Error category objects as indicated: +</p> + +<blockquote> +<pre><ins>extern</ins> const error_category<del>&</del><ins>* const</ins> <del>get_</del>generic_category<del>()</del>; +</pre> +<p> +<del><i>Returns:</i> A reference</del> <ins><tt>generic_category</tt> shall point</ins> +to <del>an</del> <ins>a statically initialized</ins> object of a type derived from +class <tt>error_category</tt>. +</p> + +<p> +<del><i>Remarks:</i></del> The object's <tt>default_error_condition</tt> and <tt>equivalent</tt> virtual +functions shall behave as specified for the class <tt>error_category</tt>. The +object's <tt>name</tt> virtual function shall return a pointer to the string +<tt>"GENERIC"</tt>. +</p> + +<pre><ins>extern</ins> const error_category<del>&</del><ins>* const</ins> <del>get_</del>system_category<del>()</del>; +</pre> + +<p> +<del><i>Returns:</i> A reference</del> <ins><tt>system_category</tt> shall point</ins> +to <del>an</del> <ins>a statically +initialized</ins> object of a type derived from class <tt>error_category</tt>. +</p> + +<p> +<del><i>Remarks:</i></del> The object's <tt>equivalent</tt> virtual functions shall behave as +specified for class <tt>error_category</tt>. The object's <tt>name</tt> virtual function +shall return a pointer to the string <tt>"system"</tt>. The object's +<tt>default_error_condition</tt> virtual function shall behave as follows: +</p> + +<p> +If the argument <tt>ev</tt> corresponds to a POSIX <tt>errno</tt> value <tt>posv</tt>, the function +shall return <tt>error_condition(posv, generic_category)</tt>. Otherwise, the +function shall return <tt>error_condition(ev, system_category)</tt>. What +constitutes correspondence for any given operating system is +unspecified. [<i>Note:</i> The number of potential system error codes is large +and unbounded, and some may not correspond to any POSIX <tt>errno</tt> value. +Thus implementations are given latitude in determining correspondence. +<i>-- end note</i>] +</p> +</blockquote> + +<p> +Change 19.4.2.1 [syserr.errcode.overview] Class <tt>error_code</tt> overview as indicated: +</p> + +<blockquote><pre>class error_code { +public: + ...; + <ins>constexpr</ins> error_code(int val, const error_category<del>&</del><ins>*</ins> cat); + ... + void assign(int val, const error_category<del>&</del><ins>*</ins> cat); + ... + const error_category<del>&</del><ins>*</ins> category() const; + ... +private: + int val_; // exposition only + const error_category<del>&</del><ins>*</ins> cat_; // exposition only +</pre></blockquote> + +<p> +Change 19.4.2.2 [syserr.errcode.constructors] Class <tt>error_code</tt> constructors as indicated: +</p> + +<blockquote> +<pre><ins>constexpr</ins> error_code(int val, const error_category<del>&</del><ins>*</ins> cat); +</pre> +<p> +<i>Effects:</i> Constructs an object of type <tt>error_code</tt>. +</p> +<p> +<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>. +</p> +<p> +<i>Throws:</i> Nothing. +</p> +</blockquote> + +<p> +Change 19.4.2.3 [syserr.errcode.modifiers] Class <tt>error_code</tt> modifiers as indicated: +</p> + +<blockquote> +<pre>void assign(int val, const error_category<del>&</del><ins>*</ins> cat); +</pre> +<p> +<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>. +</p> +<p> +<i>Throws:</i> Nothing. +</p> +</blockquote> + +<p> +Change 19.4.2.4 [syserr.errcode.observers] Class <tt>error_code</tt> observers as indicated: +</p> + +<blockquote> +<pre>const error_category<del>&</del><ins>*</ins> category() const; +</pre> + +<p> +<i>Returns:</i> <tt>cat_</tt>. +</p> +<p> +<i>Throws:</i> Nothing. +</p> +</blockquote> + +<p> +Change 19.4.3.1 [syserr.errcondition.overview] Class <tt>error_condition</tt> overview as indicated: +</p> + +<blockquote> +<pre>class error_condition { +public: + ...; + <ins>constexpr</ins> error_condition(int val, const error_category<del>&</del><ins>*</ins> cat); + ... + void assign(int val, const error_category<del>&</del><ins>*</ins> cat); + ... + const error_category<del>&</del><ins>*</ins> category() const; + ... +private: + int val_; // exposition only + const error_category<del>&</del><ins>*</ins> cat_; // exposition only +</pre> +</blockquote> + +<p> +Change 19.4.3.2 [syserr.errcondition.constructors] Class <tt>error_condition</tt> constructors as indicated: +</p> + +<blockquote> +<pre>constexpr error_condition(int val, const error_category<del>&</del><ins>*</ins> cat); +</pre> +<p> +<i>Effects:</i> Constructs an object of type <tt>error_condition</tt>. +</p> +<p> +<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>. +</p> +<p> +<i>Throws:</i> Nothing. +</p> +</blockquote> + +<p> +Change 19.4.3.3 [syserr.errcondition.modifiers] Class <tt>error_condition</tt> modifiers as indicated: +</p> + +<blockquote> +<pre>void assign(int val, const error_category<del>&</del><ins>*</ins> cat); +</pre> +<p> +<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>. +</p> +<p> +<i>Throws:</i> Nothing. +</p> +</blockquote> + +<p> +Change 19.4.3.4 [syserr.errcondition.observers] Class <tt>error_condition</tt> observers as indicated: +</p> + +<blockquote> +<pre>const error_category<del>&</del><ins>*</ins> category() const; +</pre> +<p> +<i>Returns:</i> <tt>cat_</tt>. +</p> +<p> +<i>Throws:</i> Nothing. +</p> +</blockquote> + +<p> +Throughout 19.4 [syserr] System error support, change "<tt>category().</tt>" to "<tt>category()-></tt>". +Appears approximately six times. +</p> + +<p> +<i>[Partially Editorial]</i> In 19.4.4 [syserr.compare] Comparison operators, +paragraphs 2 and 4, change "<tt>category.equivalent(</tt>" to +"<tt>category()->equivalent(</tt>". +</p> + + + + + +<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> + <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>Discussion:</b></p> +<p> +Once the C++0x standard library is feature complete, the LWG needs to +review 17.4.1.3 [compliance] Freestanding implementations header list to +ensure it reflects LWG consensus. +</p> + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="834"></a>834. Unique_ptr::pointer requirements underspecified</h3> +<p><b>Section:</b> 20.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> + <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>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 +extension point for <tt>unique_ptr</tt> by granting support for an optional +<tt>deleter_type::pointer</tt> to act as pointer-like replacement for <tt>element_type*</tt> +(In the following: <tt>pointer</tt>). +</p> +<p> +Unfortunately no requirements are specified for the type <tt>pointer</tt> which has +impact on at least two key features of <tt>unique_ptr</tt>: +</p> + +<ol> +<li>Operational fail-safety.</li> +<li>(Well-)Definedness of expressions.</li> +</ol> + +<p> +<tt>Unique_ptr</tt> specification makes great efforts to require that essentially *all* +operations cannot throw and therefore adds proper wording to the affected +operations of the deleter as well. If user-provided <tt>pointer</tt>-emulating types +("smart pointers") will be allowed, either *all* throw-nothing clauses have to +be replaced by weaker "An exception is thrown only if <tt>pointer</tt>'s {op} throws +an exception"-clauses or it has to be said explicitly that all used +operations of +<tt>pointer</tt> are required *not* to throw. I understand the main focus of <tt>unique_ptr</tt> +to be as near as possible to the advantages of native pointers which cannot +fail and thus strongly favor the second choice. Also, the alternative position +would make it much harder to write safe and simple template code for +<tt>unique_ptr</tt>. Additionally, I assume that a general statement need to be given +that all of the expressions of <tt>pointer</tt> used to define semantics are required to +be well-formed and well-defined (also as back-end for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>). +</p> + + +<p><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: +</p> + +<blockquote> +<tt>unique_ptr<T, D>::pointer</tt>'s operations shall be well-formed, shall have well +defined behavior, and shall not throw exceptions. +</blockquote> + + + + + +<hr> +<h3><a name="835"></a>835. tying two streams together (correction to DR 581)</h3> +<p><b>Section:</b> 27.4.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +The fix for +issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, +now integrated into the working paper, overlooks a couple of minor +problems. + + </p> + <p> + +First, being an unformatted function once again, <code>flush()</code> +is required to create a sentry object whose constructor must, among +other things, flush the tied stream. When two streams are tied +together, either directly or through another intermediate stream +object, flushing one will also cause a call to <code>flush()</code> on +the other tied stream(s) and vice versa, ad infinitum. The program +below demonstrates the problem. + + </p> + <p> + +Second, as Bo Persson notes in his +comp.lang.c++.moderated <a href="http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/f2187794e9cc036d/305df31dc583054a">post</a>, +for streams with the <code>unitbuf</code> flag set such +as <code>std::stderr</code>, the destructor of the sentry object will +again call <code>flush()</code>. This seems to create an infinite +recursion for <code>std::cerr << std::flush;</code> + + </p> + <blockquote> + <pre>#include <iostream> + +int main () +{ + std::cout.tie (&std::cerr); + std::cerr.tie (&std::cout); + std::cout << "cout\n"; + std::cerr << "cerr\n"; +} + </pre> + </blockquote> + + <p><b>Proposed resolution:</b></p> + <p> + +I think an easy way to plug the first hole is to add a requires clause +to <code>ostream::tie(ostream *tiestr)</code> requiring the this +pointer not be equal to any pointer on the list starting +with <code>tiestr->tie()</code> +through <code>tiestr()->tie()->tie()</code> and so on. I am not +proposing that we require implementations to traverse this list, +although I think we could since the list is unlikely to be very long. + + </p> + <p> + +Add a <i>Requires</i> clause to 27.4.4.2 [basic.ios.members] withethe following +text: + + </p> + <blockquote> + +<i>Requires:</i> If <code>(tiestr != 0)</code> is +true, <code>tiestr</code> must not be reachable by traversing the +linked list of tied stream objects starting +from <code>tiestr->tie()</code>. + + </blockquote> + <p> + +In addition, to prevent the infinite recursion that Bo writes about in +his comp.lang.c++.moderated post, I propose to change +27.6.2.4 [ostream::sentry], p2 like so: + + </p> + <blockquote> + +If <code>((os.flags() & ios_base::unitbuf) && +!uncaught_exception())</code> is true, +calls <del>os.flush()</del> <ins><code>os.rdbuf()->pubsync()</code></ins>. + + </blockquote> + + + + +<hr> +<h3><a name="836"></a>836. + effects of <code>money_base::space</code> and + <code>money_base::none</code> on <code>money_get</code> + </h3> +<p><b>Section:</b> 22.2.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +In paragraph 2, 22.2.6.1.2 [locale.money.get.virtuals] specifies the following: + + </p> + <blockquote> + +Where <code>space</code> or <code>none</code> appears in the format +pattern, except at the end, optional white space (as recognized +by <code>ct.is</code>) is consumed after any required space. + + </blockquote> + <p> + +This requirement can be (and has been) interpreted two mutually +exclusive ways by different readers. One possible interpretation +is that: + + </p> + <blockquote> + <ol> + <li> + +where <code>money_base::space</code> appears in the format, at least +one space is required, and + + </li> + <li> + +where <code>money_base::none</code> appears in the format, space is +allowed but not required. + + </li> + </ol> + </blockquote> + <p> + +The other is that: + + </p> + <blockquote> + +where either <code>money_base::space</code> or <code>money_base::none</code> appears in the format, white space is optional. + + </blockquote> + + + <p><b>Proposed resolution:</b></p> + <p> + +I propose to change the text to make it clear that the first +interpretation is intended, that is, to make following change to +22.2.6.1.2 [locale.money.get.virtuals], p2: + + </p> + + <blockquote> + +When <code><ins>money_base::</ins>space</code> +or <code><ins>money_base::</ins>none</code> appears <ins>as the last +element </ins>in the format pattern, <del>except at the end, optional +white space (as recognized by <code>ct.is</code>) is consumed after +any required space.</del> <ins>no white space is consumed. Otherwise, +where <code>money_base::space</code> appears in any of the initial +elements of the format pattern, at least one white space character is +required. Where <code>money_base::none</code> appears in any of the +initial elements of the format pattern, white space is allowed but not +required. In either case, any required followed by all optional white +space (as recognized by <code>ct.is()</code>) is consumed.</ins> +If <code>(str.flags() & str.showbase)</code> is <code>false</code>, ... + + </blockquote> + + + + +<hr> +<h3><a name="837"></a>837. + <code>basic_ios::copyfmt()</code> overly loosely specified + </h3> +<p><b>Section:</b> 27.4.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +The <code>basic_ios::copyfmt()</code> member function is specified in 27.4.4.2 [basic.ios.members] to have the following effects: + + </p> + <blockquote> + +<i>Effects</i>: If <code>(this == &rhs)</code> does +nothing. Otherwise assigns to the member objects of <code>*this</code> +the corresponding member objects of <code>rhs</code>, except that + + <ul> + <li> + +<code>rdstate()</code> and <code>rdbuf()</code> are left unchanged; + + </li> + <li> + +<code>exceptions()</code> is altered last by +calling <code>exceptions(rhs.except)</code> + + </li> + <li> + +the contents of arrays pointed at by <code>pword</code> +and <code>iword</code> are copied not the pointers themselves + + </li> + </ul> + </blockquote> + <p> + +Since the rest of the text doesn't specify what the member objects +of <code>basic_ios</code> are this seems a little too loose. + + </p> + + + <p><b>Proposed resolution:</b></p> + <p> + +I propose to tighten things up by adding a <i>Postcondition</i> clause +to the function like so: + + </p> + <blockquote> + <i>Postconditions:</i> + + <table border="1"> + <thead> + <tr> + <th colspan="2"><code>copyfmt()</code> postconditions</th> + </tr> + <tr> + <th>Element</th> + <th>Value</th> + </tr> + </thead> + <tbody> + <tr> + <td><code>rdbuf()</code></td> + <td><i>unchanged</i></td> + </tr> + <tr> + <td><code>tie()</code></td> + <td><code>rhs.tie()</code></td> + </tr> + <tr> + <td><code>rdstate()</code></td> + <td><i>unchanged</i></td> + </tr> + <tr> + <td><code>exceptions()</code></td> + <td><code>rhs.exceptions()</code></td> + </tr> + <tr> + <td><code>flags()</code></td> + <td><code>rhs.flags()</code></td> + </tr> + <tr> + <td><code>width()</code></td> + <td><code>rhs.width()</code></td> + </tr> + <tr> + <td><code>precision()</code></td> + <td><code>rhs.precision()</code></td> + </tr> + <tr> + <td><code>fill()</code></td> + <td><code>rhs.fill()</code></td> + </tr> + <tr> + <td><code>getloc()</code></td> + <td><code>rhs.getloc()</code></td> + </tr> + </tbody> + </table> + </blockquote> + <p> + +The format of the table follows Table 117 (as +of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2588.pdf">N2588</a>): <code>basic_ios::init()</code> +effects. + + </p> + <p> + +The intent of the new table is not to impose any new requirements or +change existing ones, just to be more explicit about what I believe is +already there. + + </p> + + + + +<hr> +<h3><a name="838"></a>838. + can an <i>end-of-stream</i> iterator become a <i>non-end-of-stream</i> one? + </h3> +<p><b>Section:</b> 24.5.1 [istream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.iterator">active issues</a> in [istream.iterator].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator">issues</a> in [istream.iterator].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +From message c++std-lib-20003... + + </p> + <p> + +The description of <code>istream_iterator</code> in +24.5.1 [istream.iterator], p1 specifies that objects of the +class become the <i>end-of-stream</i> (EOS) iterators under the +following condition (see also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a> another problem +with this paragraph): + + </p> + <blockquote> + +If the end of stream is reached (<code>operator void*()</code> on the +stream returns <code>false</code>), the iterator becomes equal to +the <i>end-of-stream</i> iterator value. + + </blockquote> + <p> + +One possible implementation approach that has been used in practice is +for the iterator to set its <code>in_stream</code> pointer to 0 when +it reaches the end of the stream, just like the default ctor does on +initialization. The problem with this approach is that +the <i>Effects</i> clause for <code>operator++()</code> says the +iterator unconditionally extracts the next value from the stream by +evaluating <code>*in_stream >> value</code>, without checking +for <code>(in_stream == 0)</code>. + + </p> + <p> + +Conformance to the requirement outlined in the <i>Effects</i> clause +can easily be verified in programs by setting <code>eofbit</code> +or <code>failbit</code> in <code>exceptions()</code> of the associated +stream and attempting to iterate past the end of the stream: each +past-the-end access should trigger an exception. This suggests that +some other, more elaborate technique might be intended. + + </p> + <p> + +Another approach, one that allows <code>operator++()</code> to attempt +to extract the value even for EOS iterators (just as long +as <code>in_stream</code> is non-0) is for the iterator to maintain a +flag indicating whether it has reached the end of the stream. This +technique would satisfy the presumed requirement implied by +the <i>Effects</i> clause mentioned above, but it isn't supported by +the exposition-only members of the class (no such flag is shown). This +approach is also found in existing practice. + + </p> + <p> + +The inconsistency between existing implementations raises the question +of whether the intent of the specification is that a non-EOS iterator +that has reached the EOS become a non-EOS one again after the +stream's <code>eofbit</code> flag has been cleared? That is, are the +assertions in the program below expected to pass? + + </p> + <blockquote> + <pre> sstream strm ("1 "); + istream_iterator eos; + istream_iterator it (strm); + int i; + i = *it++ + assert (it == eos); + strm.clear (); + strm << "2 3 "; + assert (it != eos); + i = *++it; + assert (3 == i); + </pre> + </blockquote> + <p> + +Or is it intended that once an iterator becomes EOS it stays EOS until +the end of its lifetime? + + </p> + + + <p><b>Proposed resolution:</b></p> + <p> + +The discussion of this issue on the reflector suggests that the intent +of the standard is for an <code>istreambuf_iterator</code> that has +reached the EOS to remain in the EOS state until the end of its +lifetime. Implementations that permit EOS iterators to return to a +non-EOS state may only do so as an extension, and only as a result of +calling <code>istream_iterator</code> member functions on EOS +iterators whose behavior is in this case undefined. + + </p> + <p> + +To this end we propose to change 24.5.1 [istream.iterator], p1, +as follows: + + </p> + <blockquote> + +The result of operator-> on an end<ins>-</ins>of<ins>-</ins>stream +is not defined. For any other iterator value a <code>const T*</code> +is returned.<ins> Invoking <code>operator++()</code> on +an <i>end-of-stream</i> iterator is undefined.</ins> It is impossible +to store things into istream iterators... + + </blockquote> + <p> + +Add pre/postconditions to the member function descriptions of <code>istream_iterator</code> like so: + + </p> + <blockquote> + +<pre>istream_iterator();</pre> + +<i>Effects</i>: Constructs the <i>end-of-stream</i> iterator.<br> +<ins><i>Postcondition</i>: <code>in_stream == 0</code>.</ins> + +<pre>istream_iterator(istream_type &s);</pre> + +<i>Effects</i>: Initializes <code>in_stream</code> with &s. value +may be initialized during construction or the first time it is +referenced.<br> +<ins><i>Postcondition</i>: <code>in_stream == &s</code>.</ins> + +<pre>istream_iterator(const istream_iterator &x);</pre> + +<i>Effects</i>: Constructs a copy of <code>x</code>.<br> +<ins><i>Postcondition</i>: <code>in_stream == x.in_stream</code>.</ins> + +<pre>istream_iterator& operator++();</pre> + +<ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br> +<i>Effects</i>: <code>*in_stream >> value</code>. + +<pre>istream_iterator& operator++(int);</pre> + +<ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br> +<i>Effects</i>: + <blockquote><pre>istream_iterator tmp (*this); +*in_stream >> value; +return tmp; + </pre> + </blockquote> + </blockquote> + + diff --git a/libstdc++-v3/doc/html/ext/lwg-closed.html b/libstdc++-v3/doc/html/ext/lwg-closed.html index 52184fb..68bca50 100644 --- a/libstdc++-v3/doc/html/ext/lwg-closed.html +++ b/libstdc++-v3/doc/html/ext/lwg-closed.html @@ -12,11 +12,11 @@ del {background-color:#FFA0A0} <table> <tbody><tr> <td align="left">Doc. no.</td> -<td align="left">N2458=07-0328</td> +<td align="left">N2614=08-0124</td> </tr> <tr> <td align="left">Date:</td> -<td align="left">2007-10-20</td> +<td align="left">2008-05-18</td> </tr> <tr> <td align="left">Project:</td> @@ -27,7 +27,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 R52)</h1> +<h1>C++ Standard Library Closed Issues List (Revision R56)</h1> <p>Reference ISO/IEC IS 14882:1998(E)</p> <p>Also see:</p> @@ -49,6 +49,89 @@ del {background-color:#FFA0A0} <h2>Revision History</h2> <ul> +<li>R56: +2008-05-16 pre-Sophia Antipolis mailing. +<ul> +<li><b>Summary:</b><ul> +<li>191 open issues, up by 24.</li> +<li>647 closed issues, up by 1.</li> +<li>838 issues total, up by 25.</li> +</ul></li> +<li><b>Details:</b><ul> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>.</li> +</ul></li> +</ul> +</li> +<li>R55: +2008-03-14 post-Bellevue mailing. +<ul> +<li><b>Summary:</b><ul> +<li>167 open issues, down by 39.</li> +<li>646 closed issues, up by 65.</li> +<li>813 issues total, up by 26.</li> +</ul></li> +<li><b>Details:</b><ul> +<li>Added the following Dup issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a>.</li> +<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#790">790</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#791">791</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#796">796</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#797">797</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#799">799</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>.</li> +<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#801">801</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a>.</li> +<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>.</li> +<li>Changed the following issues from NAD Future to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.</li> +<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>.</li> +<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#462">462</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>.</li> +<li>Changed the following issues from NAD Future to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li> +<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li> +<li>Changed the following issues from Review to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>.</li> +<li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a>.</li> +<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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 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 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 Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>.</li> +<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>.</li> +<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li> +<li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>.</li> +</ul></li> +</ul> +</li> +<li>R54: +2008-02-01 pre-Bellevue mailing. +<ul> +<li><b>Summary:</b><ul> +<li>206 open issues, up by 23.</li> +<li>581 closed issues, up by 0.</li> +<li>787 issues total, up by 23.</li> +</ul></li> +<li><b>Details:</b><ul> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>.</li> +<li>Changed the following issues from NAD Future to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>.</li> +<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#697">697</a>.</li> +<li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>.</li> +<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>.</li> +</ul></li> +</ul> +</li> +<li>R53: +2007-12-09 mid-term mailing. +<ul> +<li><b>Summary:</b><ul> +<li>183 open issues, up by 11.</li> +<li>581 closed issues, down by 1.</li> +<li>764 issues total, up by 10.</li> +</ul></li> +<li><b>Details:</b><ul> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>.</li> +<li>Changed the following issues from Pending WP to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li> +</ul></li> +</ul> +</li> <li>R52: 2007-10-19 post-Kona mailing. <ul> @@ -58,16 +141,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-active.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#754">754</a>.</li> +<li>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>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>.</li> <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>.</li> <li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a>.</li> -<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li> +<li>Changed the following issues from New to 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 Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li> <li>Changed the following issues from New to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li> -<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#706">706</a>.</li> -<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#680">680</a>.</li> -<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>.</li> +<li>Changed the following issues from New to 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 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 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> @@ -83,7 +166,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-active.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>.</li> +<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> </ul></li> </ul> </li> @@ -96,13 +179,13 @@ del {background-color:#FFA0A0} <li>708 issues total, up by 12.</li> </ul></li> <li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#697">697</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#697">697</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li> <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#584">584</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>.</li> <li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</a>.</li> <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>.</li> <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>.</li> <li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li> -<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#680">680</a>.</li> +<li>Changed the following issues from 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 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> @@ -123,7 +206,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-active.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li> +<li>Added the following 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 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> @@ -140,12 +223,12 @@ 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-active.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>.</li> +<li>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>Changed the following issues from Tentatively Ready to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>.</li> -<li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li> +<li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li> <li>Changed the following issues from NAD to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#357">357</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#368">368</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a>.</li> <li>Changed the following issues from Tentatively Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>.</li> -<li>Changed the following issues from NAD_Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li> +<li>Changed the following issues from NAD_Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li> <li>Changed the following issues from Tentatively Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>.</li> <li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li> <li>Changed the following issues from Tentatively Ready to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>.</li> @@ -167,11 +250,11 @@ 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-active.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li> -<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#626">626</a>.</li> +<li>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 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 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-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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 Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>.</li> <li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>.</li> </ul></li> </ul> @@ -201,7 +284,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-active.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li> +<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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> @@ -245,9 +328,9 @@ del {background-color:#FFA0A0} <li>574 issues total, up by 8.</li> </ul></li> <li><b>Details:</b><ul> -<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#567">567</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li> +<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li> <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#501">501</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#517">517</a> to NAD.</li> -<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a> to Open.</li> +<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a> to Open.</li> <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a> to Ready.</li> <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> to WP.</li> <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li> @@ -278,7 +361,7 @@ del {background-color:#FFA0A0} <li>535 issues total.</li> </ul></li> <li><b>Details:</b><ul> -<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#529">529</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>.</li> +<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>.</li> </ul></li> </ul> </li> @@ -323,12 +406,12 @@ new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html# <li>R31: 2004-07 mid-term mailing: reflects new proposed resolutions and new issues received after the post-Sydney mailing. Added -new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>. +new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>. </li> <li>R30: Post-Sydney mailing: reflects decisions made at the Sydney meeting. Voted all "Ready" issues from R29 into the working paper. -Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#462">462</a>. +Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#462">462</a>. </li> <li>R29: Pre-Sydney mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>. @@ -473,7 +556,7 @@ of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3 <li>R10: pre-Kona updated. Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>, -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a> to +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99) </li> <li>R9: @@ -492,7 +575,7 @@ pre-Dublin updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a> (31 Mar 99) </li> <li>R6: -pre-Dublin mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>, +pre-Dublin mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>, and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>. (99-0007/N1194, 22 Feb 99) </li> <li>R5: @@ -1214,6 +1297,7 @@ illegal. See 17.4.4.4 [member.functions] paragraph 2.</p> <h3><a name="97"></a>97. Insert inconsistent definition</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">NAD</a> <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</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">NAD</a> status.</p> <p><b>Discussion:</b></p> @@ -1275,7 +1359,7 @@ incorrect code to work, rather than the other way around.</p> <hr> <h3><a name="101"></a>101. No way to free storage for vector and deque</h3> -<p><b>Section:</b> 23.2.5 [vector], 23.2.1 [array] <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.2.6 [vector], 23.2.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> @@ -1348,10 +1432,13 @@ the Standard.</p> <hr> <h3><a name="105"></a>105. fstream ctors argument types desired</h3> -<p><b>Section:</b> 27.8 [file.streams] <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> 27.8 [file.streams] <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 issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#454">454</a></p> <p><b>Discussion:</b></p> + + <p>fstream ctors take a const char* instead of string.<br> fstream ctors can't take wchar_t</p> @@ -1488,12 +1575,15 @@ desired functionality.</p> <hr> <h3><a name="116"></a>116. bitset cannot be constructed with a const char*</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#NAD%20Future">NAD Future</a> +<p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-11-06</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#778">778</a></p> <p><b>Discussion:</b></p> + + + <p>The following code does not compile with the EDG compiler:</p> <blockquote> @@ -1591,60 +1681,8 @@ ctype<wchar_t> specialization. </p> <hr> -<h3><a name="128"></a>128. Need open_mode() function for file stream, string streams, file buffers, and string buffers</h3> -<p><b>Section:</b> 27.7 [string.streams], 27.8 [file.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a> - <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-02-22</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.streams">issues</a> in [string.streams].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p> -<p><b>Discussion:</b></p> -<p>The following question came from Thorsten Herlemann:</p> - -<blockquote> - <p>You can set a mode when constructing or opening a file-stream or - filebuf, e.g. ios::in, ios::out, ios::binary, ... But how can I get - that mode later on, e.g. in my own operator << or operator - >> or when I want to check whether a file-stream or - file-buffer object passed as parameter is opened for input or output - or binary? Is there no possibility? Is this a design-error in the - standard C++ library? </p> -</blockquote> - -<p>It is indeed impossible to find out what a stream's or stream -buffer's open mode is, and without that knowledge you don't know -how certain operations behave. Just think of the append mode. </p> - -<p>Both streams and stream buffers should have a <tt>mode()</tt> function that returns the -current open mode setting. </p> - - -<p><b>Proposed resolution:</b></p> -<p>For stream buffers, add a function to the base class as a non-virtual function -qualified as const to 27.5.2 [streambuf]:</p> - -<p> <tt>openmode mode() const</tt>;</p> - -<p><b> Returns</b> the current open mode.</p> - -<p>With streams, I'm not sure what to suggest. In principle, the mode -could already be returned by <tt>ios_base</tt>, but the mode is only -initialized for file and string stream objects, unless I'm overlooking -anything. For this reason it should be added to the most derived -stream classes. Alternatively, it could be added to <tt>basic_ios</tt> -and would be default initialized in <tt>basic_ios<>::init()</tt>.</p> - - -<p><b>Rationale:</b></p> -<p>This might be an interesting extension for some future, but it is -not a defect in the current standard. The Proposed Resolution is -retained for future reference.</p> - - - - - -<hr> <h3><a name="131"></a>131. list::splice throws nothing</h3> -<p><b>Section:</b> 23.2.3.4 [list.ops] <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.2.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</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> @@ -1731,10 +1769,10 @@ not in the specialization. See issue <a href="http://www.open-std.org/jtc1/sc22/ <hr> <h3><a name="140"></a>140. map<Key, T>::value_type does not satisfy the assignable requirement</h3> -<p><b>Section:</b> 23.3.1 [map] <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.3.1 [map] <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> Mark Mitchell <b>Date:</b> 1999-04-14</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map">issues</a> in [map].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> <p><b>Discussion:</b></p> <blockquote> <p>23.1 [container.requirements]<br> @@ -2192,64 +2230,10 @@ ios_base::init to basic_ios::init().)</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#NAD%20Future">NAD Future</a> - <b>Submitter:</b> Dave Abrahams <b>Date:</b> 1999-07-01</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%20Future">NAD Future</a> status.</p> -<p><b>Discussion:</b></p> -<p>It is the constness of the container which should control whether -it can be modified through a member function such as erase(), not the -constness of the iterators. The iterators only serve to give -positioning information.</p> - -<p>Here's a simple and typical example problem which is currently very -difficult or impossible to solve without the change proposed -below.</p> - -<p>Wrap a standard container C in a class W which allows clients to -find and read (but not modify) a subrange of (C.begin(), C.end()]. The -only modification clients are allowed to make to elements in this -subrange is to erase them from C through the use of a member function -of W.</p> - - -<p><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>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> -</p> - - -<p><b>Rationale:</b></p> -<p>The issue was discussed at length. It was generally agreed that 1) -There is no major technical argument against the change (although -there is a minor argument that some obscure programs may break), and -2) Such a change would not break const correctness. The concerns about -making the change were 1) it is user detectable (although only in -boundary cases), 2) it changes a large number of signatures, and 3) it -seems more of a design issue that an out-and-out defect.</p> - -<p>The LWG believes that this issue should be considered as part of a -general review of const issues for the next revision of the -standard. Also see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>.</p> - - - - -<hr> <h3><a name="188"></a>188. valarray helpers missing augmented assignment operators</h3> -<p><b>Section:</b> 26.5.2.6 [valarray.cassign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a> +<p><b>Section:</b> 26.5.2.6 [valarray.cassign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 1999-08-15</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> <p><b>Discussion:</b></p> <p>26.5.2.6 defines augmented assignment operators valarray<T>::op=(const T&), but fails to provide @@ -2283,30 +2267,6 @@ operators.</p> <hr> -<h3><a name="190"></a>190. min() and max() functions should be std::binary_functions</h3> -<p><b>Section:</b> 25.3.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a> - <b>Submitter:</b> Mark Rintoul <b>Date:</b> 1999-08-26</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.min.max">issues</a> in [alg.min.max].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p> -<p><b>Discussion:</b></p> -<p>Both std::min and std::max are defined as template functions. This -is very different than the definition of std::plus (and similar -structs) which are defined as function objects which inherit -std::binary_function.<br> -<br> - This lack of inheritance leaves std::min and std::max somewhat useless in standard library algorithms which require -a function object that inherits std::binary_function.</p> - - -<p><b>Rationale:</b></p> -<p>Although perhaps an unfortunate design decision, the omission is not a defect -in the current standard. A future standard may wish to consider additional -function objects.</p> - - - - -<hr> <h3><a name="191"></a>191. Unclear complexity for algorithms such as binary search</h3> <p><b>Section:</b> 25.3.3 [alg.binary.search] <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> 1999-10-10</p> @@ -3011,6 +2971,8 @@ might reasonably pass an argument that is not Copy Constructible.</p> <h3><a name="245"></a>245. Which operations on <tt>istream_iterator</tt> trigger input operations?</h3> <p><b>Section:</b> 24.5.1 [istream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2000-05-02</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.iterator">active issues</a> in [istream.iterator].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator">issues</a> in [istream.iterator].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> <p><b>Discussion:</b></p> <p>I do not think the standard specifies what operation(s) on istream @@ -3977,11 +3939,11 @@ about when terminate() is called; it merely specifies which <hr> <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%20Future">NAD Future</a> +<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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%20Future">NAD Future</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> <p><b>Discussion:</b></p> <p>Currently the standard mandates the following overloads of abs():</p> @@ -4019,6 +3981,16 @@ and int_max_abs.</p> <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#343">343</a>.</p> +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +The situation is not sufficiently severe to warrant a change. +</blockquote> + + <p><b>Rationale:</b></p> @@ -4208,11 +4180,14 @@ consensus in the LWG for action. <hr> <h3><a name="348"></a>348. Minor issue with std::pair operator<</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%20Future">NAD Future</a> +<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#Dup">Dup</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 2001-10-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%20Future">NAD Future</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a></p> <p><b>Discussion:</b></p> + + <p> The current wording of 20.2.2 [lib.pairs] p6 precludes the use of operator< on any pair type which contains a pointer. @@ -4253,7 +4228,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.1.1 [allocator.members], 20.1.2 [allocator.requirements], 17.4.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> +<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> <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> @@ -4371,10 +4346,10 @@ might wish to make the change as editorial.]</i></p> <hr> <h3><a name="353"></a>353. <tt>std::pair</tt> missing template assignment</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%20Future">NAD Future</a> +<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%20Editorial">NAD Editorial</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-12-02</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%20Future">NAD Future</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> <p><b>Discussion:</b></p> <p> The class template <tt>std::pair</tt> defines a template ctor (20.2.2, p4) but @@ -4413,6 +4388,13 @@ a design decision, and thus NAD. May be appropriate for a future standard.]</i></p> +<p><i>[ +Pre Bellevue: It was recognized that this was taken care of by +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a>, +and thus moved from NAD Future to NAD Editorial. +]</i></p> + + @@ -5109,10 +5091,10 @@ then precisely describe and enforce the precise requirements. <hr> <h3><a name="388"></a>388. Use of complex as a key in associative containers</h3> -<p><b>Section:</b> 26.3 [complex.numbers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a> +<p><b>Section:</b> 26.3 [complex.numbers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2002-11-08</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.numbers">issues</a> in [complex.numbers].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> <p><b>Discussion:</b></p> <p> Practice with std::complex<> and the associative containers @@ -5138,6 +5120,27 @@ containers as an ordering useful to meet complexity requirements. <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>.</p> +<p><i>[ +Pre Bellevue: Reopened at the request of Alisdair. +]</i></p> + + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +This is a request for a design change, and not a defect in the standard. +It is in scope to consider, but the group feels that it is not a change +that we need to do. Is there a total ordering for floating point values, +including NaN? There is not a clear enough solution or big enough +problem for us to solve. Solving this problem would require solving the +problem for floating point, which is equally unclear. The LWG noted that +users who want to put objects into an associative container for which +operator< isn't defined can simply provide their own comparison function +object. NAD +</blockquote> <p><b>Proposed resolution:</b></p> @@ -5160,11 +5163,11 @@ provide their own comparison function object.</p> <hr> <h3><a name="390"></a>390. CopyConstructible requirements too strict</h3> -<p><b>Section:</b> 20.1.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a> +<p><b>Section:</b> 20.1.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> <b>Submitter:</b> Doug Gregor <b>Date:</b> 2002-10-24</p> <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p> +<p><b>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 CopyConstructible requirements in Table 30 state that for an @@ -5295,7 +5298,6 @@ of input iterators.</p> <h3><a name="393"></a>393. do_in/do_out operation on state unclear</h3> <p><b>Section:</b> 22.2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a> <b>Submitter:</b> Alberto Barbati <b>Date:</b> 2002-12-24</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.codecvt.virtuals">active issues</a> in [locale.codecvt.virtuals].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.virtuals">issues</a> in [locale.codecvt.virtuals].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p> <p><b>Discussion:</b></p> @@ -5402,6 +5404,95 @@ can use alternative signatures that don't call widen. <hr> +<h3><a name="424"></a>424. normative notes</h3> +<p><b>Section:</b> 17.3.1.1 [structure.summary] <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> 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#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> + +<p> +The text in 17.3.1.1, p1 says: +<br> + +"Paragraphs labelled "Note(s):" or "Example(s):" are informative, other +paragraphs are normative." +<br> + +The library section makes heavy use of paragraphs labeled "Notes(s)," +some of which are clearly intended to be normative (see list 1), while +some others are not (see list 2). There are also those where the intent +is not so clear (see list 3). +<br><br> + +List 1 -- Examples of (presumably) normative Notes: +<br> + +20.6.5.1 [allocator.members], p3,<br> +20.6.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> +25.3.7 [alg.min.max], p3,<br> +26.3.6 [complex.ops], p15,<br> +27.5.2.4.3 [streambuf.virt.get], p7.<br> +<br> + +List 2 -- Examples of (presumably) informative Notes: +<br> + +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> +26.3.5 [complex.member.ops], p1,<br> +27.4.2.5 [ios.base.storage], p6.<br> +<br> + +List 3 -- Examples of Notes that are not clearly either normative +or informative: +<br> + +22.1.1.2 [locale.cons], p8,<br> +22.1.1.5 [locale.statics], p6,<br> +27.5.2.4.5 [streambuf.virt.put], p4.<br> +<br> + +None of these lists is meant to be exhaustive. +</p> + +<p><i>[Definitely a real problem. The big problem is there's material + that doesn't quite fit any of the named paragraph categories + (e.g. <b>Effects</b>). Either we need a new kind of named + paragraph, or we need to put more material in unnamed paragraphs + jsut after the signature. We need to talk to the Project Editor + about how to do this. +]</i></p> + + +<p><i>[ +Bellevue: Specifics of list 3: First 2 items correct in std (22.1.1.2, +22.1.1.5) Third item should be non-normative (27.5.2.4.5), which Pete +will handle editorially. +]</i></p> + + + +<p><b>Proposed resolution:</b></p> +<p><i>[Pete: I changed the paragraphs marked "Note" and "Notes" to use "Remark" and "Remarks". +Fixed as editorial. This change has been in the WD since the post-Redmond mailing, in 2004. +Recommend NAD.]</i></p> + +<p><i>[ +Batavia: We feel that the references in List 2 above should be changed from <i>Remarks</i> +to <i>Notes</i>. We also feel that those items in List 3 need to be double checked for +the same change. Alan and Pete to review. +]</i></p> + + + + + +<hr> <h3><a name="429"></a>429. typo in basic_ios::clear(iostate)</h3> <p><b>Section:</b> 27.4.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p> @@ -5770,274 +5861,153 @@ standard facets. <hr> -<h3><a name="463"></a>463. auto_ptr usability issues</h3> -<p><b>Section:</b> D.9.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Rani Sharoni <b>Date:</b> 2003-12-07</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#auto.ptr">issues</a> in [auto.ptr].</p> +<h3><a name="462"></a>462. Destroying objects with static storage duration</h3> +<p><b>Section:</b> 3.6.3 [basic.start.term], 18.3 [cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-03-23</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> -TC1 CWG DR #84 effectively made the template<class Y> operator auto_ptr<Y>() -member of auto_ptr (20.4.5.3/4) obsolete. +3.6.3 Termination spells out in detail the interleaving of static +destructor calls and calls to functions registered with atexit. To +match this behavior requires intimate cooperation between the code +that calls destructors and the exit/atexit machinery. The former +is tied tightly to the compiler; the latter is a primitive mechanism +inherited from C that traditionally has nothing to do with static +construction and destruction. The benefits of intermixing destructor +calls with atexit handler calls is questionable at best, and <i>very</i> +difficult to get right, particularly when mixing third-party C++ +libraries with different third-party C++ compilers and C libraries +supplied by still other parties. </p> <p> -The sole purpose of this obsolete conversion member is to enable copy -initialization base from r-value derived (or any convertible types like -cv-types) case: +I believe the right thing to do is defer all static destruction +until after all atexit handlers are called. This is a change in +behavior, but one that is likely visible only to perverse test +suites. At the very least, we should <i>permit</i> deferred destruction +even if we don't require it. </p> -<pre>#include <memory> -using std::auto_ptr; -struct B {}; -struct D : B {}; +<p><i>[If this is to be changed, it should probably be changed by CWG. + At this point, however, the LWG is leaning toward NAD. Implementing + what the standard says is hard work, but it's not impossible and + most vendors went through that pain years ago. Changing this + behavior would be a user-visible change, and would break at least + one real application.]</i></p> -auto_ptr<D> source(); -int sink(auto_ptr<B>); -int x1 = sink( source() ); // #1 EDG - no suitable copy constructor -</pre> - -<p> -The excellent analysis of conversion operations that was given in the final -auto_ptr proposal -(http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/1997/N1128.pdf) -explicitly specifies this case analysis (case 4). DR #84 makes the analysis -wrong and actually comes to forbid the loophole that was exploited by the -auto_ptr designers. -</p> - -<p> -I didn't encounter any compliant compiler (e.g. EDG, GCC, BCC and VC) that -ever allowed this case. This is probably because it requires 3 user defined -conversions and in fact current compilers conform to DR #84. -</p> - -<p> -I was surprised to discover that the obsolete conversion member actually has -negative impact of the copy initialization base from l-value derived -case:</p> -<pre>auto_ptr<D> dp; -int x2 = sink(dp); // #2 EDG - more than one user-defined conversion applies -</pre> - -<p> -I'm sure that the original intention was allowing this initialization using -the template<class Y> auto_ptr(auto_ptr<Y>& a) constructor (20.4.5.1/4) but -since in this copy initialization it's merely user defined conversion (UDC) -and the obsolete conversion member is UDC with the same rank (for the early -overloading stage) there is an ambiguity between them. -</p> - -<p> -Removing the obsolete member will have impact on code that explicitly -invokes it: -</p> -<pre>int y = sink(source().operator auto_ptr<B>()); -</pre> - -<p> -IMHO no one ever wrote such awkward code and the reasonable workaround for -#1 is: -</p> -<pre>int y = sink( auto_ptr<B>(source()) ); -</pre> - -<p> -I was even more surprised to find out that after removing the obsolete -conversion member the initialization was still ill-formed: -int x3 = sink(dp); // #3 EDG - no suitable copy constructor -</p> - -<p> -This copy initialization semantically requires copy constructor which means -that both template conversion constructor and the auto_ptr_ref conversion -member (20.4.5.3/3) are required which is what was explicitly forbidden in -DR #84. This is a bit amusing case in which removing ambiguity results with -no candidates. -</p> - -<p> -I also found exception safety issue with auto_ptr related to auto_ptr_ref: -</p> -<pre>int f(auto_ptr<B>, std::string); -auto_ptr<B> source2(); -// string constructor throws while auto_ptr_ref -// "holds" the pointer -int x4 = f(source2(), "xyz"); // #4 -</pre> +<p><i>[ +Batavia: Send to core with our recommendation that we should permit deferred +destruction but not require it. +]</i></p> -<p> -The theoretic execution sequence that will cause a leak: -</p> -<ol> -<li>call auto_ptr<B>::operator auto_ptr_ref<B>()</li> -<li>call string::string(char const*) and throw</li> -</ol> -<p> -According to 20.4.5.3/3 and 20.4.5/2 the auto_ptr_ref conversion member -returns auto_ptr_ref<Y> that holds *this and this is another defect since -the type of *this is auto_ptr<X> where X might be different from Y. Several -library vendors (e.g. SGI) implement auto_ptr_ref<Y> with Y* as member which -is much more reasonable. Other vendor implemented auto_ptr_ref as -defectively required and it results with awkward and catastrophic code: -int oops = sink(auto_ptr<B>(source())); // warning recursive on all control -paths -</p> +<p><i>[ +Howard: The course of action recommended in Batavia would undo LWG +issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3">3</a> and break current code implementing the "phoenix +singleton". Search the net for "phoenix singleton atexit" to get a feel +for the size of the adverse impact this change would have. Below is +sample code which implements the phoenix singleton and would break if +<tt>atexit</tt> is changed in this way: +]</i></p> -<p> -Dave Abrahams noticed that there is no specification saying that -auto_ptr_ref copy constructor can't throw. -</p> -<p> -My proposal comes to solve all the above issues and significantly simplify -auto_ptr implementation. One of the fundamental requirements from auto_ptr -is that it can be constructed in an intuitive manner (i.e. like ordinary -pointers) but with strict ownership semantics which yield that source -auto_ptr in initialization must be non-const. My idea is to add additional -constructor template with sole propose to generate ill-formed, diagnostic -required, instance for const auto_ptr arguments during instantiation of -declaration. This special constructor will not be instantiated for other -types which is achievable using 14.8.2/2 (SFINAE). Having this constructor -in hand makes the constructor template<class Y> auto_ptr(auto_ptr<Y> const&) -legitimate since the actual argument can't be const yet non const r-value -are acceptable. -</p> +<blockquote><pre>#include <cstdlib> +#include <iostream> +#include <type_traits> +#include <new> -<p> -This implementation technique makes the "private auxiliary class" -auto_ptr_ref obsolete and I found out that modern C++ compilers (e.g. EDG, -GCC and VC) consume the new implementation as expected and allow all -intuitive initialization and assignment cases while rejecting illegal cases -that involve const auto_ptr arguments. -</p> +class A +{ + bool alive_; + A(const A&); + A& operator=(const A&); +public: + A() : alive_(true) {std::cout << "A()\n";} + ~A() {alive_ = false; std::cout << "~A()\n";} + void use() + { + if (alive_) + std::cout << "A is alive\n"; + else + std::cout << "A is dead\n"; + } +}; -<p>The proposed auto_ptr interface:</p> +void deallocate_resource(); -<pre>namespace std { - template<class X> class auto_ptr { - public: - typedef X element_type; - - // 20.4.5.1 construct/copy/destroy: - explicit auto_ptr(X* p=0) throw(); - auto_ptr(auto_ptr&) throw(); - template<class Y> auto_ptr(auto_ptr<Y> const&) throw(); - auto_ptr& operator=(auto_ptr&) throw(); - template<class Y> auto_ptr& operator=(auto_ptr<Y>) throw(); - ~auto_ptr() throw(); - - // 20.4.5.2 members: - X& operator*() const throw(); - X* operator->() const throw(); - X* get() const throw(); - X* release() throw(); - void reset(X* p=0) throw(); - - private: - template<class U> - auto_ptr(U& rhs, typename -unspecified_error_on_const_auto_ptr<U>::type = 0); - }; +// This is the phoenix singleton pattern +A& get_resource(bool create = true) +{ + static std::aligned_storage<sizeof(A), std::alignment_of<A>::value>::type buf; + static A* a; + if (create) + { + if (a != (A*)&buf) + { + a = ::new (&buf) A; + std::atexit(deallocate_resource); + } + } + else + { + a->~A(); + a = (A*)&buf + 1; + } + return *a; } -</pre> - -<p> -One compliant technique to implement the unspecified_error_on_const_auto_ptr -helper class is using additional private auto_ptr member class template like -the following: -</p> -<pre>template<typename T> struct unspecified_error_on_const_auto_ptr; -template<typename T> -struct unspecified_error_on_const_auto_ptr<auto_ptr<T> const> -{ typedef typename auto_ptr<T>::const_auto_ptr_is_not_allowed type; }; -</pre> - -<p> -There are other techniques to implement this helper class that might work -better for different compliers (i.e. better diagnostics) and therefore I -suggest defining its semantic behavior without mandating any specific -implementation. IMO, and I didn't found any compiler that thinks otherwise, -14.7.1/5 doesn't theoretically defeat the suggested technique but I suggest -verifying this with core language experts. -</p> +void deallocate_resource() +{ + get_resource(false); +} -<p><b>Further changes in standard text:</b></p> -<p>Remove section 20.4.5.3</p> +void use_A(const char* message) +{ + A& a = get_resource(); + std::cout << "Using A " << message << "\n"; + a.use(); +} -<p>Change 20.4.5/2 to read something like: -Initializing auto_ptr<X> from const auto_ptr<Y> will result with unspecified -ill-formed declaration that will require unspecified diagnostic.</p> +struct B +{ + ~B() {use_A("from ~B()");} +}; -<p>Change 20.4.5.1/4,5,6 to read:</p> +B b; -<pre>template<class Y> auto_ptr(auto_ptr<Y> const& a) throw();</pre> -<p> 4 Requires: Y* can be implicitly converted to X*.</p> -<p> 5 Effects: Calls const_cast<auto_ptr<Y>&>(a).release().</p> -<p> 6 Postconditions: *this holds the pointer returned from a.release().</p> +int main() +{ + use_A("from main()"); +} +</pre></blockquote> -<p>Change 20.4.5.1/10</p> -<pre>template<class Y> auto_ptr& operator=(auto_ptr<Y> a) throw(); -</pre> <p> -10 Requires: Y* can be implicitly converted to X*. The expression delete -get() is well formed. +The correct output is: </p> -<p>LWG TC DR #127 is obsolete.</p> - -<p> -Notice that the copy constructor and copy assignment operator should remain -as before and accept non-const auto_ptr& since they have effect on the form -of the implicitly declared copy constructor and copy assignment operator of -class that contains auto_ptr as member per 12.8/5,10: -</p> -<pre>struct X { - // implicit X(X&) - // implicit X& operator=(X&) - auto_ptr<D> aptr_; -}; -</pre> +<blockquote><pre>A() +Using A from main() +A is alive +~A() +A() +Using A from ~B() +A is alive +~A() +</pre></blockquote> -<p> -In most cases this indicates about sloppy programming but preserves the -current auto_ptr behavior. -</p> +<p><i>[ +Bellevue: Confirmed no interaction with <tt>quick_exit</tt>. +Strong feeling against mandating the change. Leaning towards NAD rather than permitting the change, +as this would make common implementations of pheonix-singleton pattern implementation defined, as noted by Howard. +Bill agrees issue is no longer serious, and accepts NAD. +]</i></p> -<p> -Dave Abrahams encouraged me to suggest fallback implementation in case that -my suggestion that involves removing of auto_ptr_ref will not be accepted. -In this case removing the obsolete conversion member to auto_ptr<Y> and -20.4.5.3/4,5 is still required in order to eliminate ambiguity in legal -cases. The two constructors that I suggested will co exist with the current -members but will make auto_ptr_ref obsolete in initialization contexts. -auto_ptr_ref will be effective in assignment contexts as suggested in DR -#127 and I can't see any serious exception safety issues in those cases -(although it's possible to synthesize such). auto_ptr_ref<X> semantics will -have to be revised to say that it strictly holds pointer of type X and not -reference to an auto_ptr for the favor of cases in which auto_ptr_ref<Y> is -constructed from auto_ptr<X> in which X is different from Y (i.e. assignment -from r-value derived to base). -</p> <p><b>Proposed resolution:</b></p> -<p><i>[Redmond: punt for the moment. We haven't decided yet whether we - want to fix auto_ptr for C++-0x, or remove it and replace it with - move_ptr and unique_ptr.]</i></p> - - - -<p><b>Rationale:</b></p> <p> -Recommend NAD. We're just going to deprecate it. It still works for simple use cases -and people know how to deal with it. Going forward <tt>unique_ptr</tt> is the recommended -tool. </p> @@ -6096,6 +6066,7 @@ Recommend NAD. Relegate this functionality to debugging implementations. <h3><a name="470"></a>470. accessing containers from their elements' special functions</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">NAD</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-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">NAD</a> status.</p> <p><b>Discussion:</b></p> @@ -6564,6 +6535,7 @@ 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> @@ -7080,12 +7052,12 @@ change, so there is no real-world harm here.</p> <hr> <h3><a name="491"></a>491. std::list<>::unique incorrectly specified</h3> -<p><b>Section:</b> 23.2.3.4 [list.ops] <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.2.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Thomas Mang <b>Date:</b> 2004-12-12</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</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 Section 23.2.3.4 [list.ops], paragraphs 19 to 21 describe the +<p>In Section 23.2.4.4 [list.ops], paragraphs 19 to 21 describe the behavior of the std::list<T, Allocator>::unique operation. However, the current wording is defective for various reasons.</p> @@ -7095,7 +7067,7 @@ current wording is defective for various reasons.</p> 1) Analysis of current wording: </p> -<p>23.2.3.4 [list.ops], paragraph 19:</p> +<p>23.2.4.4 [list.ops], paragraph 19:</p> <p> Current wording says: @@ -7109,7 +7081,7 @@ predicate argument) holds."</p> This sentences makes use of the undefined term "Eliminates". Although it is, to a certain degree, reasonable to consider the term "eliminate" synonymous with "erase", using "Erase" in the first place, as the -wording of 23.2.3.4 [list.ops], paragraph 15 does, would be clearer.</p> +wording of 23.2.4.4 [list.ops], paragraph 15 does, would be clearer.</p> <p> The range of the elements referred to by iterator i is "[first + 1, @@ -7126,7 +7098,7 @@ The same problems as pointed out in DR 202 (equivalence relation / order of arguments for pred()) apply to this paragraph.</p> <p> -23.2.3.4 [list.ops], paragraph 20: +23.2.4.4 [list.ops], paragraph 20: </p> <p> @@ -7143,7 +7115,7 @@ expressions ( "*i == *(i - 1)", "pred(*i, *(i -1))" ). </p> <p> -23.2.3.4 [list.ops], paragraph 21:</p> +23.2.4.4 [list.ops], paragraph 21:</p> <p> Current wording says: @@ -7182,7 +7154,7 @@ of DR 202, no impact on current code is expected.</p> 3) Proposed fixes:</p> <p> -Change 23.2.3.4 [list.ops], paragraph 19 to:</p> +Change 23.2.4.4 [list.ops], paragraph 19 to:</p> <p> "Effect: Erases all but the first element from every consecutive group @@ -7201,7 +7173,7 @@ wording need also additional review. b) "Erases" refers in the author's opinion unambiguously to the member function "erase". In case there is doubt this might not be unamgibuous, a direct reference to the member function "erase" is suggested [Note: -This would also imply a change of 23.2.3.4 [list.ops], paragraph +This would also imply a change of 23.2.4.4 [list.ops], paragraph 15.]. c) The expression "(i - 1)" was left, but is expected that DR submitted by Thomas Mang regarding invalid iterator arithmetic expressions will @@ -7221,7 +7193,7 @@ elements consists of only a single element, this element is also considered the first element."</p> <p> -Change 23.2.3.4 [list.ops], paragraph 20 to:</p> +Change 23.2.4.4 [list.ops], paragraph 20 to:</p> <p> "Throws: Nothing unless an exception is thrown by *(i-1) == *i or @@ -7232,7 +7204,7 @@ Comments to the new wording:</p> <p> a) The wording regarding the conditions is identical to proposed -23.2.3.4 [list.ops], paragraph 19. If 23.2.3.4 [list.ops], +23.2.4.4 [list.ops], paragraph 19. If 23.2.4.4 [list.ops], paragraph 19 is resolved in another way, the proposed wording need also additional review. b) The expression "(i - 1)" was left, but is expected that DR submitted @@ -7241,7 +7213,7 @@ take this into account. c) Typos fixed.</p> <p> -Change 23.2.3.4 [list.ops], paragraph 21 to:</p> +Change 23.2.4.4 [list.ops], paragraph 21 to:</p> <p> "Complexity: If empty() == false, exactly size() - 1 applications of the @@ -7659,6 +7631,7 @@ Marc supports having min and max to satisfy generic programming interface. <h3><a name="509"></a>509. Uniform_int template parameters</h3> <p><b>Section:</b> 26.4.8.1 [rand.dist.uni], TR1 5.1.7.1 [tr.rand.dist.iunif] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Walter Brown <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#rand.dist.uni">issues</a> in [rand.dist.uni].</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> @@ -8417,10 +8390,105 @@ 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> + <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> +<p> +17.4.3.8/1 says: +</p> + +<blockquote><p> +Violation of the preconditions specified in a function's +Required behavior: paragraph results in undefined behavior unless the +function's Throws: paragraph specifies throwing an exception when the +precondition is violated. +</p></blockquote> + +<p> +This implies that a precondition violation can lead to defined +behavior. That conflicts with the only reasonable definition of +precondition: that a violation leads to undefined behavior. Any other +definition muddies the waters when it comes to analyzing program +correctness, because precondition violations may be routinely done in +correct code (e.g. you can use std::vector::at with the full +expectation that you'll get an exception when your index is out of +range, catch the exception, and continue). Not only is it a bad +example to set, but it encourages needless complication and redundancy +in the standard. For example: +</p> + +<blockquote><pre> 21 Strings library + 21.3.3 basic_string capacity + + void resize(size_type n, charT c); + + 5 Requires: n <= max_size() + 6 Throws: length_error if n > max_size(). + 7 Effects: Alters the length of the string designated by *this as follows: +</pre></blockquote> + +<p> +The Requires clause is entirely redundant and can be dropped. We +could make that simplifying change (and many others like it) even +without changing 17.4.3.8/1; the wording there just seems to encourage +the redundant and error-prone Requires: clause. +</p> + +<p><i>[ +Batavia: Alan and Pete to work. +]</i></p> + + +<p><i>[ +Bellevue: NAD Editorial, this group likes +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2121.html">N2121</a>, +Pete agrees, accepting it is Pete's business. +General agreement that precondition violations are synonymous with UB. +]</i></p> + + + +<p><b>Proposed resolution:</b></p> +<p> +1. Change 17.4.3.8/1 to read: +</p> + +<blockquote><p> +Violation of the preconditions specified in a function's +<i>Required behavior:</i> paragraph results in undefined behavior +<del>unless the function's <i>Throws:</i> paragraph specifies throwing +an exception when the precondition is violated</del>. +</p></blockquote> + +<p> +2. Go through and remove redundant Requires: clauses. Specifics to be + provided by Dave A. +</p> + +<p><i>[ +Berlin: The LWG requests a detailed survey of part 2 of the proposed resolution. +]</i></p> + + +<p><i>[ +Alan provided the survey +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2121.html">N2121</a>. +]</i></p> + + + + + + + +<hr> <h3><a name="532"></a>532. Tuple comparison</h3> -<p><b>Section:</b> 20.3.1.5 [tuple.rel], TR1 6.1.3.5 [tr.tuple.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a> +<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> <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> <p><b>Discussion:</b></p> <p> Where possible, tuple comparison operators <,<=,=>, and > ought to be @@ -8845,6 +8913,97 @@ 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> + <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>Discussion:</b></p> +<p> +I'm seeing a problem with such overloads: when, _Longlong == intmax_t == +long long we end up, essentially, with the same arguments and different +return types (lldiv_t and imaxdiv_t, respectively). Similar issue with +abs(_Longlong) and abs(intmax_t), of course. +</p> +<p> +Comparing sections 8.25 and 8.11, I see an important difference, +however: 8.25.3 and 8.25.4 carefully describe div and abs for _Longlong +types (rightfully, because not moved over directly from C99), whereas +there is no equivalent in 8.11: the abs and div overloads for intmax_t +types appear only in the synopsis and are not described anywhere, in +particular no mention in 8.11.2 (at variance with 8.25.2). +</p> +<p> +I'm wondering whether we really, really, want div and abs for intmax_t... +</p> + + + +<p><b>Proposed resolution:</b></p> + + + +<p><i>[ +Portland: no consensus. +]</i></p> + + +<p><b>Rationale:</b></p> +<p><i>[ +Batavia, Bill: The <tt><cstdint></tt> synopsis in TR1 8.11.1 [tr.c99.cinttypes.syn] contains: +]</i></p> + +<blockquote><pre>intmax_t imaxabs(intmax_t i); +intmax_t abs(intmax_t i); + +imaxdiv_t imaxdiv(intmax_t numer, intmax_t denom); +imaxdiv_t div(intmax_t numer, intmax_t denom); +</pre></blockquote> + +<p><i>[ +and in TR1 8.11.2 [tr.c99.cinttypes.def]: +]</i></p> + + +<blockquote><p> +The header defines all functions, types, and macros the same as C99 +subclause 7.8. +</p></blockquote> + +<p><i>[ +This is as much definition as we give for most other C99 functions, +so nothing need change. We might, however, choose to add the footnote: +]</i></p> + + +<blockquote><p> +[<i>Note:</i> These overloads for <tt>abs</tt> and <tt>div</tt> may well be equivalent to +those that take <tt>long long</tt> arguments. If so, the implementation is +responsible for avoiding conflicting declarations. -- <i>end note</i>] +</p></blockquote> + +<p><i>[ +Bellevue: NAD Editorial. Pete must add a footnote, as described below. +]</i></p> + + +<blockquote> +<p><i>[ +Looks like a real problem. Dietmar suggests div() return a template +type. Matt: looks like imaxdiv_t is loosly defined. Can it be a typedef +for lldiv_t when _Longlong == intmax_t? PJP seems to agree. We would +need a non-normative note declaring that the types lldiv_t and imaxdiv_t +may not be unique if intmax_t==_longlong. +]</i></p> + +</blockquote> + + + + + + +<hr> <h3><a name="558"></a>558. lib.input.iterators Defect</h3> <p><b>Section:</b> 24.1.1 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> <b>Submitter:</b> David Abrahams <b>Date:</b> 2006-02-09</p> @@ -9143,6 +9302,93 @@ 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> + <b>Submitter:</b> Joaquín M López Muñoz <b>Date:</b> 2006-06-13</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> +<p> +See +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2023.pdf">N2023</a> +for full discussion. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Option 1: +</p> + +<p> +The problem can be eliminated by omitting the requirement that <tt>a.erase(q)</tt> return an +iterator. This is, however, in contrast with the equivalent requirements for other +standard containers. +</p> + +<p> +Option 2: +</p> + +<p> +<tt>a.erase(q)</tt> can be made to compute the next iterator only when explicitly requested: +the technique consists in returning a proxy object implicitly convertible to <tt>iterator</tt>, so +that +</p> + +<blockquote><pre>iterator q1=a.erase(q); +</pre></blockquote> + +<p> +works as expected, while +</p> + +<blockquote><pre>a.erase(q); +</pre></blockquote> + +<p> +does not ever invoke the conversion-to-iterator operator, thus avoiding the associated +computation. To allow this technique, some sections of TR1 along the line "return value +is an iterator..." should be changed to "return value is an unspecified object implicitly +convertible to an iterator..." Although this trick is expected to work transparently, it can +have some collateral effects when the expression <tt>a.erase(q)</tt> is used inside generic +code. +</p> + + + +<p><b>Rationale:</b></p> +<p> +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2023.pdf">N2023</a> +was discussed in Portland and the consensus was that there appears to be +no need for either change proposed in the paper. The consensus opinion +was that since the iterator could serve as its own proxy, there appears +to be no need for the change. In general, "converts to" is undesirable +because it interferes with template matching. +</p> + +<p> +Post Toronto: There does not at this time appear to be consensus with the Portland consensus. +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +The Bellevue review of this issue reached consensus with the Portland +consensus, in contravention of the Toronto non-consensus. Common +implementations have the iterator readily available, and most common +uses depend on the iterator being returned. +</blockquote> + + + + + + +<hr> <h3><a name="583"></a>583. div() for unsigned integral types</h3> <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-06-15</p> @@ -9598,6 +9844,207 @@ Recommend NAD, editorial. Send to Pete. <hr> +<h3><a name="625"></a>625. mixed up <i>Effects</i> and <i>Returns</i> clauses</h3> +<p><b>Section:</b> 17 [library] <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> Martin Sebor <b>Date:</b> 2007-01-20</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#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#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +Many member functions of <code>basic_string</code> are overloaded, +with some of the overloads taking a <code>string</code> argument, +others <code>value_type*</code>, others <code>size_type</code>, and +others still <code>iterators</code>. Often, the requirements on one of +the overloads are expressed in the form of <i>Effects</i>, +<i>Throws</i>, and in the Working Paper +(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>) +also <i>Remark</i> clauses, while those on the rest of the overloads +via a reference to this overload and using a <i>Returns</i> clause. + + </p><p> + </p> + +The difference between the two forms of specification is that per +17.3.1.3 [structure.specifications], p3, an <i>Effects</i> clause specifies +<i>"actions performed by the functions,"</i> i.e., its observable +effects, while a <i>Returns</i> clause is <i>"a description of the +return value(s) of a function"</i> that does not impose any +requirements on the function's observable effects. + + <p> + </p> + +Since only <i>Notes</i> are explicitly defined to be informative and +all other paragraphs are explicitly defined to be normative, like +<i>Effects</i> and <i>Returns</i>, the new <i>Remark</i> clauses also +impose normative requirements. + + <p> + </p> + +So by this strict reading of the standard there are some member +functions of <code>basic_string</code> that are required to throw an +exception under some conditions or use specific traits members while +many other otherwise equivalent overloads, while obliged to return the +same values, aren't required to follow the exact same requirements +with regards to the observable effects. + + <p> + </p> + +Here's an example of this problem that was precipitated by the change +from informative Notes to normative <i>Remark</i>s (presumably made to +address <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>): + + <p> + </p> + +In the Working Paper, <code>find(string, size_type)</code> contains a +<i>Remark</i> clause (which is just a <i>Note</i> in the current +standard) requiring it to use <code>traits::eq()</code>. + + <p> + </p> + +<code>find(const charT *s, size_type pos)</code> is specified to +return <code>find(string(s), pos)</code> by a <i>Returns</i> clause +and so it is not required to use <code>traits::eq()</code>. However, +the Working Paper has replaced the original informative <i>Note</i> +about the function using <code>traits::length()</code> with a +normative requirement in the form of a <i>Remark</i>. Calling +<code>traits::length()</code> may be suboptimal, for example when the +argument is a very long array whose initial substring doesn't appear +anywhere in <code>*this</code>. + + <p> + </p> + +Here's another similar example, one that existed even prior to the +introduction of <i>Remark</i>s: + + <p> + </p> + +<code> insert(size_type pos, string, size_type, size_type)</code> is +required to throw <code>out_of_range</code> if <code>pos > +size()</code>. + + <p> + </p> + +<code>insert(size_type pos, string str)</code> is specified to return +<code>insert(pos, str, 0, npos)</code> by a <i>Returns</i> clause and +so its effects when <code>pos > size()</code> are strictly speaking +unspecified. + + + <p> + +I believe a careful review of the current <i>Effects</i> and +<i>Returns</i> clauses is needed in order to identify all such +problematic cases. In addition, a review of the Working Paper should +be done to make sure that the newly introduced normative <i>Remark</i> +clauses do not impose any undesirable normative requirements in place +of the original informative <i>Notes</i>. + + </p> +<p><i>[ +Batavia: Alan and Pete to work. +]</i></p> + + +<p><i>[ +Bellevue: Marked as NAD Editorial. +]</i></p> + + + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="626"></a>626. new <i>Remark</i> clauses not documented</h3> +<p><b>Section:</b> 17.3.1.3 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#structure.specifications">issues</a> in [structure.specifications].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +The <i>Remark</i> clauses newly introduced into the Working Paper +(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>) +are not mentioned in 17.3.1.3 [structure.specifications] where we list the +meaning of <i>Effects</i>, <i>Requires</i>, and other clauses (with +the exception of <i>Notes</i> which are documented as informative in +17.3.1.1 [structure.summary], p2, and which they replace in many cases). + + </p> + <p> + +Propose add a bullet for <i>Remarks</i> along with a brief description. + + </p> +<p><i>[ +Batavia: Alan and Pete to work. +]</i></p> + + +<p><i>[ +Bellevue: Already resolved in current working paper. +]</i></p> + + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="627"></a>627. Low memory and exceptions</h3> +<p><b>Section:</b> 18.5.1.1 [new.delete.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2007-01-23</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete.single">issues</a> in [new.delete.single].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +I recognize the need for nothrow guarantees in the exception reporting +mechanism, but I strongly believe that implementors also need an escape hatch +when memory gets really low. (Like, there's not enough heap to construct and +copy exception objects, or not enough stack to process the throw.) I'd like to +think we can put this escape hatch in 18.5.1.1 [new.delete.single], +<tt>operator new</tt>, but I'm not sure how to do it. We need more than a +footnote, but the wording has to be a bit vague. The idea is that if +<tt>new</tt> can't allocate something sufficiently small, it has the right to +<tt>abort</tt>/call <tt>terminate</tt>/call <tt>unexpected</tt>. +</p> + +<p><i>[ +Bellevue: NAD. 1.4p2 specifies a program must behave correctly "within +its resource limits", so no further escape hatch is necessary. +]</i></p> + + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<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> <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-03</p> @@ -9862,6 +10309,7 @@ input functions because that applies to the case in which badbit is set. <h3><a name="641"></a>641. Editorial fix for 27.6.4 (N2134)</h3> <p><b>Section:</b> 27.6.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-18</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#NAD%20Editorial">NAD Editorial</a> status.</p> <p><b>Discussion:</b></p> @@ -9963,6 +10411,113 @@ In 27.8.1.13 [ofstream.members], remove footnote: <hr> +<h3><a name="645"></a>645. Missing members in match_results</h3> +<p><b>Section:</b> 28.10 [re.results] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-26</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.results">issues</a> in [re.results].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +According to the description given in 28.10 [re.results]/2 the class template +match_results "shall satisfy the requirements of a Sequence, [..], +except that only operations defined for const-qualified Sequences +are supported". +Comparing the provided operations from 28.10 [re.results]/3 with the +sequence/container tables 80 and 81 one recognizes the following +missing operations: +</p> + +<p> +1) The members +</p> + +<blockquote><pre>const_iterator rbegin() const; +const_iterator rend() const; +</pre></blockquote> + +<p> +should exists because 23.1/10 demands these for containers +(all sequences are containers) which support bidirectional +iterators. Aren't these supported by match_result? This is not +explicitely expressed, but it's somewhat implied by two arguments: +</p> +<p> +(a) Several typedefs delegate to +<tt>iterator_traits<BidirectionalIterator></tt>. +</p> +<p> +(b) The existence of <tt>const_reference operator[](size_type n) const</tt> +implies even random-access iteration. +I also suggest, that <tt>match_result</tt> should explicitly mention, +which minimum iterator category is supported and if this does +not include random-access the existence of <tt>operator[]</tt> is +somewhat questionable. +</p> +<p> +2) The new "convenience" members +</p> +<blockquote><pre>const_iterator cbegin() const; +const_iterator cend() const; +const_iterator crbegin() const; +const_iterator crend() const; +</pre></blockquote> +<p> +should be added according to tables 80/81. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add the following members to the <tt>match_results</tt> synopsis after <tt>end()</tt> in 28.10 [re.results] +para 3: +</p> + +<blockquote><pre>const_iterator cbegin() const; +const_iterator cend() const; +</pre></blockquote> + +<p> +In section 28.10.3 [re.results.acc] change: +</p> + +<blockquote> +<pre>const_iterator begin() const; +<ins>const_iterator cbegin() const;</ins> +</pre> +<blockquote> +<p> +-7- <i>Returns:</i> A starting iterator that enumerates over all the sub-expressions stored in <tt>*this</tt>. +</p> +</blockquote> + +<pre>const_iterator end() const; +<ins>const_iterator cend() const;</ins> +</pre> +<blockquote> +<p> +-8- <i>Returns:</i> A terminating iterator that enumerates over all the sub-expressions stored in <tt>*this</tt>. +</p> +</blockquote> +</blockquote> + + + +<p><i>[ +Kona (2007): Voted to adopt proposed wording in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a> +except removing the entry in the table container requirements. Moved to Review. +]</i></p> + + +<p><i>[ +Bellevue: Proposed wording now in the WP. +]</i></p> + + + + + +<hr> <h3><a name="647"></a>647. Inconsistent regex_search params</h3> <p><b>Section:</b> 28.11.3 [re.alg.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-26</p> @@ -10179,6 +10734,92 @@ constructor sets <tt>*this</tt> to an end-of-sequence iterator. <hr> +<h3><a name="653"></a>653. Library reserved names</h3> +<p><b>Section:</b> 1.2 [intro.refs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-03-08</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#intro.refs">issues</a> in [intro.refs].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +</p> +<blockquote> +<p> +1.2 [intro.refs] Normative references +</p> + +<p> +The following standards contain provisions which, through reference in +this text, constitute provisions of this Interna- tional Standard. At +the time of publication, the editions indicated were valid. All +standards are subject to revision, and parties to agreements based on +this International Standard are encouraged to investigate the +possibility of applying the most recent editions of the standards +indicated below. Members of IEC and ISO maintain registers of currently +valid International Standards. +</p> + +<ul> +<li>Ecma International, ECMAScript Language Specification, Standard +Ecma-262, third edition, 1999.</li> +<li>ISO/IEC 2382 (all parts), Information technology - Vocabulary</li> +<li>ISO/IEC 9899:1990, Programming languages - C</li> +<li>ISO/IEC 9899/Amd.1:1995, Programming languages - C, AMENDMENT 1: C +Integrity</li> +<li>ISO/IEC 9899:1999, Programming languages - C</li> +<li>ISO/IEC 9899:1999/Cor.1:2001 Programming languages - C</li> +<li>ISO/IEC 9899:1999/Cor.2:2004 Programming languages - C</li> +<li>ISO/IEC 9945:2003, Information Technology-Portable Operating System +Interface (POSIX)</li> +<li>ISO/IEC 10646-1:1993 Information technology - Universal Multiple-Octet +Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual +Plane</li> +</ul> +</blockquote> + +<p> +I'm not sure how many of those reserve naming patterns that might affect +us, but I am equally sure I don't own a copy of any of these to check! +</p> +<p> +The point is to list the reserved naming patterns, rather than the +individual names themselves - although we may want to list C keywords +that are valid identifiers in C++ but likely to cause trouble in shared +headers (e.g. restrict) +</p> + +<p><i>[ +Kona (2007): Recommend NAD. No one has identified a specific defect, just the possibility of one. +]</i></p> + + +<p><i>[ +Post-Kona: Alisdair request Open. A good example of the problem was a +discussion of the system error proposal, where it was pointed out an all-caps +identifier starting with a capital E conflicted with reserved macro names for +both Posix and C. I had absolutely no idea of this rule, and suspect I was +not the only one in the room.<br> +<br> +Resolution will require someone with access to all the listed documents to +research their respective name reservation rules, or people with access to +specific documents add their rules to this issue until the list is complete. +]</i></p> + + +<p><i>[ +Bellevue: Wording is aleady present in various standards, and no-one has come forward with wording. +Suggest a formal paper rather than a defect report is the correct way to proceed. +]</i></p> + + + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> <h3><a name="656"></a>656. Typo in subtract_with_carry_engine declaration</h3> <p><b>Section:</b> 26.4.2 [rand.synopsis] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-08</p> @@ -10585,6 +11226,159 @@ Yep, looks like a typo/administrative fix to me. <hr> +<h3><a name="684"></a>684. Unclear which members of match_results should be used in comparison</h3> +<p><b>Section:</b> 28.10 [re.results] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Nozomu Katoo <b>Date:</b> 2007-05-27</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.results">issues</a> in [re.results].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In 28.4 [re.syn] of N2284, two template functions +are declared here: +</p> +<blockquote><pre>// 28.10, class template match_results: + <<i>snip</i>> +// match_results comparisons + template <class BidirectionalIterator, class Allocator> + bool operator== (const match_results<BidirectionalIterator, Allocator>& m1, + const match_results<BidirectionalIterator, Allocator>& m2); + template <class BidirectionalIterator, class Allocator> + bool operator!= (const match_results<BidirectionalIterator, Allocator>& m1, + const match_results<BidirectionalIterator, Allocator>& m2); + +// 28.10.6, match_results swap: +</pre></blockquote> + +<p> +But the details of these two bool operator functions (i.e., which members of +<tt>match_results</tt> should be used in comparison) are not described in any +following sections. +</p> + +<p><i>[ +John adds: +]</i></p> + + +<blockquote><p> +That looks like a bug: <tt>operator==</tt> should return <tt>true</tt> only if +the two objects refer to the same match - ie if one object was constructed as a +copy of the other. +</p></blockquote> + +<p><i>[ +Kona (2007): Bill and Pete to add minor wording to that proposed in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>. +]</i></p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Add a new section after 28.10.6 [re.results.swap], which reads: +</p> +<p> +28.10.7 match_results non-member functions. +</p> + +<blockquote> +<pre>template<class BidirectionalIterator, class Allocator> + bool operator==(const match_results<BidirectionalIterator, Allocator>& m1, + const match_results<BidirectionalIterator, Allocator>& m2); +</pre> +<blockquote> +<p> +<i>Returns:</i> <tt>true</tt> only if the two objects refer to the same match. +</p> +</blockquote> +</blockquote> + +<blockquote> +<pre>template<class BidirectionalIterator, class Allocator> + bool operator!=(const match_results<BidirectionalIterator, Allocator>& m1, + const match_results<BidirectionalIterator, Allocator>& m2); +</pre> +<blockquote> +<p> +<i>Returns:</i> <tt>!(m1 == m2)</tt>. +</p> +</blockquote> +</blockquote> + +<blockquote> +<pre>template<class BidirectionalIterator, class Allocator> + void swap(match_results<BidirectionalIterator, Allocator>& m1, + match_results<BidirectionalIterator, Allocator>& m2); +</pre> +<blockquote> +<p> +<i>Returns:</i> <tt>m1.swap(m2)</tt>. +</p> +</blockquote> +</blockquote> + + +<p><i>[ +Bellevue: Proposed wording now in WP. +]</i></p> + + + + + +<hr> +<h3><a name="686"></a>686. Unique_ptr and shared_ptr fail to specify non-convertibility to int for unspecified-bool-type</h3> +<p><b>Section:</b> 20.6.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> + <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 +for example) the returned value is constrained to disallow +unintended conversions to int. The standardese is +</p> +<blockquote><p> +The return type shall not be convertible to <tt>int</tt>. +</p></blockquote> +<p> +This constraint is omitted for <tt>unique_ptr</tt> and <tt>shared_ptr</tt>. It should be added for those. +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Close as NAD. Accepting paper +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2435.htm">N2435</a> +makes it irrelevant. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +To the <i>Returns</i> paragraph for <tt>operator <i>unspecified-bool-type</i>() +const</tt> +of 20.6.11.2.4 [unique.ptr.single.observers] paragraph 11 and +20.6.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>. +</p></blockquote> + + +<p><i>[ +Kona (2007): Uncertain if <tt>nullptr</tt> will address this issue. +]</i></p> + + + + + +<hr> <h3><a name="690"></a>690. abs(long long) should return long long</h3> <p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> <b>Submitter:</b> Niels Dekker <b>Date:</b> 2007-06-10</p> @@ -10624,4 +11418,1893 @@ Had already been fixed in the WP by the time the LWG reviewed this. +<hr> +<h3><a name="697"></a>697. New <tt><system_error></tt> header leads to name clashes</h3> +<p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-06-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#NAD%20Editorial">NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The most recent state of +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html">N2241</a> +as well as the current draft +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a> +(section 19.4 [syserr], p.2) proposes a +new +enumeration type <tt>posix_errno</tt> immediatly in the namespace <tt>std</tt>. One of +the enumerators has the name <tt>invalid_argument</tt>, or fully qualified: +<tt>std::invalid_argument</tt>. This name clashes with the exception type +<tt>std::invalid_argument</tt>, see 19.1 [std.exceptions]/p.3. This clash makes +e.g. the following snippet invalid: +</p> + +<blockquote><pre>#include <system_error> +#include <stdexcept> + +void foo() { throw std::invalid_argument("Don't call us - we call you!"); } +</pre></blockquote> + +<p> +I propose that this enumeration type (and probably the remaining parts +of +<tt><system_error></tt> as well) should be moved into one additional inner +namespace, e.g. <tt>sys</tt> or <tt>system</tt> to reduce foreseeable future clashes +due +to the great number of members that <tt>std::posix_errno</tt> already contains +(Btw.: Why has the already proposed <tt>std::sys</tt> sub-namespace from +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2066.html">N2066</a> +been rejected?). A further clash <em>candidate</em> seems to be +<tt>std::protocol_error</tt> +(a reasonable name for an exception related to a std network library, +I guess). +</p> + +<p> +Another possible resolution would rely on the proposed strongly typed +enums, +as described in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2213.pdf">N2213</a>. +But maybe the forbidden implicit conversion to integral types would +make +these enumerators less attractive in this special case? +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Fixed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2422.htm#Issue7">issue 7 of N2422</a>. +</p> + + + + + + +<hr> +<h3><a name="707"></a>707. null pointer constant for <tt>exception_ptr</tt></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#NAD">NAD</a> + <b>Submitter:</b> Jens Maurer <b>Date:</b> 2007-07-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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> + +<p> +From the Toronto Core wiki: +</p> + +<p> +What do you mean by "null pointer constant"? How do you guarantee that +<tt>exception_ptr() == 1</tt> doesn't work? Do you even want to prevent that? +What's the semantics? What about <tt>void *p = 0; exception_ptr() == p</tt>? +Maybe disallow those in the interface, but how do you do that with +portable C++? Could specify just "make it work". +</p> + +<p> +Peter's response: +</p> + +<p> +null pointer constant as defined in 4.10 [conv.ptr]. Intent is "just make it +work", can be implemented as assignment operator taking a unique pointer +to member, as in the unspecified bool type idiom. +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +Original implementation was possible using the "unspecified-null-pointer" idiom, similar to unspecified-bool. +</p> +<p> +Even simpler now with nullptr_t. +</p> +<p> +NAD Rationale : null pointer constant is a perfectly defined term, and +while API is clearly implementable there is no need to spell out +implementation details. +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="709"></a>709. <tt>char_traits::not_eof</tt> has wrong signature</h3> +<p><b>Section:</b> 21.1.3 [char.traits.specializations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.access">issues</a> in [valarray.access].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Since the return type of <tt>valarray</tt>'s <tt>operator[] const</tt> overload has been +changed to <tt>const T&</tt> as described in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> several paragraphs of +the section 26.5.2.3 [valarray.access] are now +incompletely +specified, because many requirements and guarantees should now also +apply to the const overload. Most notably, the address and reference +guarantees should be extended to the const overload case. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 26.5.2.3 [valarray.access]: +</p> + +<blockquote> +<p> +-1- <del>When applied to a constant array, the subscript operator returns a +reference to the corresponding element of the array. When applied to a +non-constant array, t</del><ins>T</ins>he subscript operator returns a +reference to the corresponding element of the array. +</p> + +<p> +-3- The expression <tt>&a[i+j] == &a[i] + j</tt> evaluates as <tt>true</tt> for all <tt>size_t i</tt> +and <tt>size_t j</tt> such that <tt>i+j</tt> is less +than the length of the <del>non-constant</del> array <tt>a</tt>. +</p> + +<p> +-4- Likewise, the expression <tt>&a[i] != &b[j]</tt> evaluates +as <tt>true</tt> for any two <del>non-constant</del> arrays <tt>a</tt> and +<tt>b</tt> and for any <tt>size_t i</tt> and <tt>size_t j</tt> such that +<tt>i</tt> is less than the length of <tt>a</tt> and <tt>j</tt> is less +than the length of <tt>b</tt>. This property indicates an absence of +aliasing and may be used to advantage by optimizing +compilers.<sup>281)</sup> +</p> + +<p> +-5- The reference returned by the subscript operator for a<ins>n</ins> <del>non-constant</del> array is guaranteed to be valid until +the member function <tt>resize(size_t, T)</tt> (26.5.2.7) is called for that array or until the lifetime +of that array ends, whichever happens first. +</p> + +</blockquote> + + + + + + +<hr> +<h3><a name="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> + <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> +<p><b>Discussion:</b></p> +<p> +Table 90: (Optional sequence container operations) states the +"assertion note pre/post-condition" of <tt>operator[]</tt> to be +</p> + +<blockquote><pre>*(a.begin() + n) +</pre></blockquote> + +<p> +Surely that's meant to be "operational semantics?" +</p> + + + +<p><b>Proposed resolution:</b></p> +<blockquote> +<table border="1"> +<caption>Table 90: Optional sequence container operations</caption> +<tbody><tr> +<th>expression</th> <th>return type</th> <th><del>assertion/note<br>pre/post-condition</del><br> <ins>operational semantics</ins></th> <th>container</th> +</tr> +</tbody></table> +</blockquote> + + + + + + +<hr> +<h3><a name="729"></a>729. Problem in [rand.req.eng]/3</h3> +<p><b>Section:</b> 26.4.1.3 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req.eng">issues</a> in [rand.req.eng].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The 3rd table row in 26.4.1.3 [rand.req.eng]/3 requires random number engines to accept any +arithmetic type as a seed, which is then casted to the engine's <tt>result_type</tt> and subsequently +used for seeding the state of the engine. The requirement stated as "Creates an engine with +initial state determined by <tt>static_cast<X::result_type>(s)</tt>" forces random number engines +to either use a seeding method that completely depends on the <tt>result_type</tt> (see the discussion +of seeding for the <tt>mersenne_twister_engine</tt> in point T2 above) or at least to throw away "bits +of randomness" in the seed value if the <tt>result_type</tt> is smaller than the seed type. This seems +to be inappropriate for many modern random number generators, in particular F2-linear or +cryptographic ones, which operate on an internal bit array that in principle is independent of the +type of numbers returned. +</p> + +<p> +<b>Posible resolution:</b> I propose to change the wording to a version similar to "Creates an +engine with initial state determined by <tt>static_cast<UintType>(s)</tt>, where <tt>UintType</tt> is an +implementation specific unsigned integer type." +</p> + +<p> +Additionally, the definition of s in 26.4.1.3 [rand.req.eng]/1 c) could be restricted to unsigned integer types. +</p> + +<p> +Similarly, the type of the seed in 26.4.1.4 [rand.req.adapt]/3 e) could be left unspecified. +</p> + +<p> +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a> +for further discussion. +</p> + +<p><i>[ +Stephan Tolksdorf adds pre-Bellevue: +]</i></p> + + +<blockquote> +<p> +In reply to the discussion in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a> +regarding this issue: +</p> +<p> +The descriptions of all engines and engine adaptors given in sections +26.4.3 [rand.eng] and 26.4.4 [rand.adapt] already specify the concrete +types of the integer arguments for seeding. Hence, relaxing the general +requirement in 26.4.1.3 [rand.req.eng] would not affect portability and +reproducibility of the standard library. Furthermore, it is not clear to +me what exactly the guarantee "with initial state determined by +<tt>static_cast<X::result_type>(s)</tt>" is useful for. On the other hand, +relaxing the requirement would allow developers to implement other +random number engines that do not have to cast all arithmetic seed +arguments to their result_types. +</p> +</blockquote> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Propose close NAD for the reasons given in N2424. +</blockquote> + + + + +<p><b>Proposed resolution:</b></p> +<p> +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a> +for further discussion. +</p> + +<p><i>[ +Stephan Tolksdorf adds pre-Bellevue: +]</i></p> + + +<blockquote> +<p> +Change row 3 of table 105 "Random number engine requirements" in 26.4.1.3 [rand.req.eng]/3 +</p> + +<blockquote> +Creates an engine with initial state determined by +<tt><del>static_cast<X::result_type>(</del>s<del>)</del></tt> +</blockquote> + +<p> +Similarly, change 26.4.1.4 [rand.req.adapt]/3 e) +</p> + +<blockquote> +When <tt>X::X</tt> is invoked with <del>an <tt>X::result_type</tt></del> value <tt>s</tt> +<ins>of arithmetic type (3.9.1)</ins>, ... +</blockquote> + +</blockquote> + + + + + + +<hr> +<h3><a name="730"></a>730. Comment on [rand.req.adapt]/3 e)</h3> +<p><b>Section:</b> 26.4.1.4 [rand.req.adapt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +If an engine adaptor is invoked with an argument of type <tt>seed_seq</tt>, then all base +engines are specified to be seeded with this <tt>seed_seq</tt>. As <tt>seed_seq</tt>'s randomization method is +qualified as constant, this procedure will ef fectively initialize all base engines with the same seed +(though the resulting state might still dif fer to a certain degree if the engines are of different types). +It is not clear whether this mode of operation is in general appropriate, hence -- as far as the +stated requirements are of general nature and not just specific to the engine adaptors provided by +the library -- it might be better to leave the behaviour unspecified, since the current definition of +<tt>seed_seq</tt> does not allow for a generally satisfying specification. +</p> + +<p> +<b>Posssible resolution:</b> [As above] +</p> + +<p> +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a> +for further discussion. +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Close NAD for the reasons given in N2424. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a> +for the proposed resolution. +</p> + + + + + +<hr> +<h3><a name="731"></a>731. proposal for a customizable <tt>seed_seq</tt></h3> +<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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.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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The proper way to seed random number engines seems to be the most frequently +discussed issue of the 26.4 [rand] proposal. While the new <tt>seed_seq</tt> approach is already rather +general and probably sufficient for most situations, it is unlikely to be optimal in every case (one +problem was pointed out in point T5 above). In some situations it might, for instance, be better to +seed the state with a cryptographic generator. +</p> +<p> +In my opinion this is a pretty strong argument for extending the standard with a simple facility to +customize the seeding procedure. This could, for example, be done with the following minimal +changes: +</p> + +<p> +<b>Possible resolution:</b> +</p> + +<ol type="a"> +<li> +Turn the interface specification of 26.4.7.1 [rand.util.seedseq]/2 into a "SeedSeq" requirement, where the +exact behaviour of the constructors and the randomize method are left unspecified and where the +const qualification for randomize is removed. Classes implementing this interface are additionally +required to specialize the traits class in c). +</li> +<li> +Provide the class <tt>seed_seq</tt> as a default implementation of the SeedSeq interface. +</li> +<li> +<p> +Supplement the <tt>seed_seq</tt> with a traits class +</p> +<blockquote><pre>template <typename T> +struct is_seed_seq { static const bool value = false; } +</pre></blockquote> +<p>and the specialization</p> +<blockquote><pre>template <> +struct is_seed_seq<seed_seq> { static const bool value = true; } +</pre></blockquote> +<p>which users can supplement with further specializations.</p> +</li> +<li> +Change 26.4.1.3 [rand.req.eng]/1 d) to "q is an lvalue of a type that fulfils the SeedSeq requirements", and +modify the constructors and seed methods in 26.4.3 [rand.eng] appropriately (the actual implementation +could be done using the SFINAE technique). +</li> +</ol> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +See N2424. Close NAD but note that "conceptizing" the library may cause +this problem to be solved by that route. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a> +for the proposed resolution. +</p> + + + + + +<hr> +<h3><a name="733"></a>733. Comment on [rand.req.dist]/9</h3> +<p><b>Section:</b> 26.4.1.5 [rand.req.dist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The requirement "P shall have a declaration of the form <tt>typedef X distribution_- +type</tt>" effectively makes the use of inheritance for implementing distributions very inconvenient, +because the child of a distribution class in general will not satisfy this requirement. In my opinion +the benefits of having a typedef in the parameter class pointing back to the distribution class are +not worth the hassle this requirement causes. [In my code base I never made use of the nested +typedef but on several occasions could have profited from being able to use simple inheritance for +the implementation of a distribution class.] +</p> + +<p> +<b>Proposed resolution:</b> I propose to drop this requirement. +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Close NAD for the reasons given in N2424. In practice it is not inconvenient to meet these requirements. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a> +for the proposed resolution. +</p> + + + + + +<hr> +<h3><a name="735"></a>735. Unfortunate naming</h3> +<p><b>Section:</b> 26.4.8.2.2 [rand.dist.bern.bin], 26.4.8.2.4 [rand.dist.bern.negbin] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +In my opinion the choice of name for the <tt>t</tt> parameter of the <tt>binomial_distribution</tt> +is very unfortunate. In virtually every internet reference, book and software implementation +this parameter is called <tt>n</tt> instead, see for example Wikipedia, Mathworld, Evans et al. (1993) +Statistical Distributions, 2nd E., Wiley, p. 38, the R statistical computing language, p. 926, +Mathematica and Matlab. +</p> + +<p> +Similarly, the choice of <tt>k</tt> for the parameter of the negative binomial distributions is rather unusual. +The most common choice for the negative binomial distribution seems to be <tt>r</tt> instead. +</p> + +<p> +Choosing unusual names for the parameters causes confusion among users and makes the +interface unnecessarily inconvenient to use. +</p> + +<p> +<b>Possible resolution:</b> For these reasons, I propose to change the name of the respective parameters +to <tt>n</tt> and <tt>r</tt>. +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +In N2424. NAD It has been around for a while. It is hardly universal, +there is prior art, and this would confuse people. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a> +for the proposed resolution. +</p> + + + + + +<hr> +<h3><a name="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 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> +<ol type="a"> +<li> +The specification for <tt>discrete_distribution</tt> requires the member <tt>probabilities()</tt> +to return a vector of <i>standardized</i> probabilities, which forces the implementation every time to +divide each probability by the sum of all probabilities, as the sum will in practice almost never be +exactly 1.0. This is unnecessarily inef ficient as the implementation would otherwise not need to +compute the standardized probabilities at all and could instead work with the non-standardized +probabilities and the sum. If there was no standardization the user would just get back the +probabilities that were previously supplied to the distribution object, which to me seems to be the +more obvious solution. +</li> +<li> +The behaviour of <tt>discrete_distribution</tt> is not specified in case the number of given +probabilities is larger than the maximum number representable by the IntType. +</li> +</ol> + +<p> +<b>Possible resolution:</b> I propose to change the specification such that the non-standardized +probabilities need to be returned and that an additional requirement is included for the number +of probabilities to be smaller than the maximum of IntType. +</p> + +<p><i>[ +Stephan Tolksdorf adds pre-Bellevue: +]</i></p> + + +<blockquote> +<p> +In reply to the discussion in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a> +of this issue: +</p> +<p> +Rescaled floating-point parameter vectors can not be expected to compare +equal because of the limited precision of floating-point numbers. +My proposal would at least guarantee that a parameter +vector (of type double) passed into the distribution would compare equal +with the one returned by the <tt>probabilities()</tt> method. Furthermore, I do +not understand why "the changed requirement would lead to a significant +increase in the amount of state in the distribution object". A typical +implementation's state would increase by exactly one number: the sum of +all probabilities. The textual representation for serialization would +not need to grow at all. Finally, the proposed replacement "<tt>0 < n <= +numeric_limits<IntType>::max() + 1</tt>" makes the implementation +unnecessarily complicated, "<tt>0 < n <= numeric_limits<IntType>::max()</tt>" +would be better. +</p> +</blockquote> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +In N2424. We agree with the observation and the proposed resolution to +part b). We recommend the wording n > 0 be replaced with 0 < n +numeric_limits::max() + 1. However, we disagree with part a), as it +would interfere with the definition of parameters' equality. Further, +the changed requirement would lead to a significant increase in the +amount of state of the distribution object. +</p> + +<p> +As it stands now, it is convenient, and the changes proposed make it +much less so. +</p> + +<p> +NAD. Part a the current behavior is desirable. Part b, any constructor +can fail, but the rules under which it can fail do not need to be listed +here. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a> +for the proposed resolution. +</p> + +<p><i>[ +Stephan Tolksdorf adds pre-Bellevue: +]</i></p> + + +<blockquote> +<p> +In 26.4.8.5.1 [rand.dist.samp.discrete]: +</p> + +<p> +Proposed wording a): +</p> + +<blockquote> +<p> +Changae in para. 2 +</p> + +<blockquote> +Constructs a <tt>discrete_distribution</tt> object with <tt>n=1</tt> and <tt>p<sub>0</sub> <ins>= w<sub>0</sub></ins> = 1</tt> +</blockquote> + +<p> +and change in para. 5 +</p> + +<blockquote> +<i>Returns:</i> A <tt>vector<double></tt> whose <tt>size</tt> member returns <tt>n</tt> and whose +<tt>operator[]</tt> member returns <del><tt>p<sub>k</sub></tt></del> +<ins>the weight <tt>w<sub>k</sub></tt> as a double value</ins> +when invoked with argument <tt>k</tt> for <tt>k = 0, +..., n-1</tt> +</blockquote> + +</blockquote> + +<p> +Proposed wording b): +</p> + +<blockquote> +<p> +Change in para. 3: +</p> + +<blockquote> +If <tt>firstW == lastW</tt>, let the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist +of the single value <tt>w<sub>0</sub> = 1</tt>. Otherwise, <tt>[firstW,lastW)</tt> shall form a +sequence <tt>w</tt> of length <tt>n <del>> 0</del></tt> +<ins>such that <tt>0 < n <= numeric_limits<IntType>::max()</tt>,</ins> +and <tt>*firstW</tt> shall yield a value <tt>w<sub>0</sub></tt> +convertible to <tt>double</tt>. [<i>Note:</i> The values <tt>w<sub>k</sub></tt> are commonly known +as the weights . <i>-- end note</i>] +</blockquote> + +</blockquote> + +</blockquote> + + + + + +<hr> +<h3><a name="737"></a>737. Comment on [rand.dist.samp.pconst]</h3> +<p><b>Section:</b> 26.4.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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.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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<ol type="a"> +<li> +The discussion in point T11 above regarding <tt>probabilities()</tt> similarly applies +to the method <tt>densities()</tt> of <tt>piecewise_constant_distribution</tt>. +</li> +<li> +<p> +The design of the constructor +</p> +<blockquote><pre>template <class InputIteratorB, class InputIteratorW> +piecewise_constant_distribution( InputIteratorB firstB, InputIteratorB lastB, + InputIteratorW firstW); +</pre></blockquote> +<p> +is unnecessarily unsafe, as there is no separate end-iterator given for the weights. I can't see +any performance or convenience reasons that would justify the risks inherent in such a function +interface, in particular the risk that input error might go unnoticed. +</p> +</li> +</ol> + +<p> +<b>Possible resolution:</b> I propose to add an <tt>InputIteratorW lastW</tt> argument to the interface. +</p> + +<p><i>[ +Stephan Tolksdorf adds pre-Bellevue: +]</i></p> + +<blockquote> +In reply to the discussion in +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a> +I'd like to make the same comments as for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>. +</blockquote> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +In N2424. There is already precedent elsewhere in the library. Follows existing convention. NAD. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a> +for the proposed resolution. +</p> + +<p><i>[ +Stephan Tolksdorf adds pre-Bellevue: +]</i></p> + + +<blockquote> +<p> +In 26.4.8.5.2 [rand.dist.samp.pconst]: +</p> + +<p> +Proposed wording a) +</p> + +<blockquote> +<p> +Change in para. 2 +</p> +<blockquote> +Constructs a <tt>piecewise_constant_distribution</tt> object with <tt>n = 1</tt>, <tt>p<sub>0</sub> <ins>= w<sub>0</sub></ins> = 1</tt>, +<tt>b<sub>0</sub> = 0</tt>, and <tt>b<sub>1</sub> = 1</tt> +</blockquote> + +<p> +and change in para. 5 +</p> + +<blockquote> +A <tt>vector<result_type></tt> whose <tt>size</tt> member returns <tt>n</tt> and whose <tt>operator[]</tt> +member returns <del><tt>p<sub>k</sub></tt></del> +<ins>the weight <tt>w<sub>k</sub></tt> as a double value</ins> +when invoked with argument <tt>k</tt> for <tt>k = 0, ..., n-1</tt> +</blockquote> + +</blockquote> + +<p> +Proposed wording b) +</p> + +<blockquote> +<p> +Change both occurrences of +</p> + +<blockquote> +"piecewise_constant_distribution(InputIteratorB firstB, InputIteratorB lastB, + InputIteratorW firstW<ins>, InputIteratorW lastW</ins>) +</blockquote> + +<p> +and change in para. 3 +</p> + +<blockquote> +<del>the length of the sequence <tt>w</tt> starting from <tt>firstW</tt> shall be at least <tt>n</tt>, +<tt>*firstW</tt> shall return a value <tt>w<sub>0</sub></tt> that is convertible to <tt>double</tt>, and any +<tt>w<sub>k</sub></tt> for <tt>k >= n</tt> shall be ignored by the distribution</del> +<ins><tt>[firstW, lastW)</tt> shall form a sequence <tt>w</tt> of length <tt>n</tt> whose leading element +<tt>w<sub>0</sub></tt> shall be convertible to <tt>double</tt></ins> +</blockquote> + +</blockquote> + + +</blockquote> + + + + + + +<hr> +<h3><a name="738"></a>738. Editorial issue in [rand.adapt.disc]/3</h3> +<p><b>Section:</b> 26.4.4.1 [rand.adapt.disc] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</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#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Since the template parameter <tt>p</tt> and <tt>r</tt> are of type <tt>size_t</tt>, the member <tt>n</tt> in the class +exposition should have type <tt>size_t</tt>, too. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a> +for the proposed resolution. +</p> + + + + + +<hr> +<h3><a name="739"></a>739. Defect in [rand.util.canonical]/3</h3> +<p><b>Section:</b> 26.4.7.2 [rand.util.canonical] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.canonical">issues</a> in [rand.util.canonical].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The complexity of <tt>generate_canonical</tt> is specified to be "exactly k=max(1, ceil(b/log2 +R)) invocations of g". This terms involves a logarithm that is not rounded and hence can not (in +general) be computed at compile time. As this function template is performance critical, I propose +to replace ceil(b/log2 R) with ceil(b/floor(log2 R)). +</p> + +<p> +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a> +for further discussion. +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +In N2424. Close NAD as described there. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a> +for the proposed resolution. +</p> + + + + + +<hr> +<h3><a name="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> + <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> +<p><b>Discussion:</b></p> +<p> +The following issue was raised by Alf P. Steinbach in c.l.c++.mod: +</p> + +<p> +According to the recent draft N2369, both the header memory synopsis +of 20.6 [memory] and 20.6.12.2.11 [util.smartptr.getdeleter] declare: +</p> + +<blockquote><pre>template<class D, class T> D* get_deleter(shared_ptr<T> const& p); +</pre></blockquote> + +<p> +This allows to retrieve the pointer to a mutable deleter of a <tt>const +shared_ptr</tt> (if that owns one) and therefore contradicts the usual +philosophy that associated functors are either read-only (e.g. +<tt>key_comp</tt> or <tt>value_comp</tt> of <tt>std::map</tt>) or do at least reflect +the mutability of the owner (as seen for the both overloads of +<tt>unique_ptr::get_deleter</tt>). +Even the next similar counter-part of <tt>get_deleter</tt> - the two +overloads of <tt>function::target</tt> in the class template function +synopsis 20.5.15.2 [func.wrap.func] or in 20.5.15.2.5 [func.wrap.func.targ] - do +properly mirror the const-state of the owner. +</p> + +<b>Possible proposed resolutions:</b> + +<p> +Replace the declarations of <tt>get_deleter</tt> in the header <tt><memory></tt> +synopsis of 20.6 [memory] and in 20.6.12.2.11 [util.smartptr.getdeleter] by one of the +following alternatives (A) or (B): +</p> + +<ol type="A"> +<li> +Provide <b>only</b> the immutable variant. This would reflect the +current praxis of <tt>container::get_allocator()</tt>, <tt>map::key_comp()</tt>, or +<tt>map::value_comp</tt>. + +<blockquote><pre>template<class D, class T> const D* get_deleter(shared_ptr<T> const& p); +</pre></blockquote> +</li> +<li> +Just remove the function. +</li> +</ol> + +<p> +Alberto Ganesh Barbati adds: +</p> + +<ol start="3" type="A"> +<li> +<p> +Replace it with two functions: +</p> +<blockquote><pre>template <class D, class T> D get_deleter(shared_ptr<T> const&); +template <class D, class T> bool has_deleter(shared_ptr<T> const&); +</pre></blockquote> + +<p> +The first one would throw if <tt>D</tt> is the wrong type, while the latter would +never throw. This approach would reflect the current praxis of +<tt>use_facet/has_facet</tt>, with the twist of returning the deleter by value as +<tt>container::get_allocator()</tt> do. +</p> +</li> +</ol> + +<p> +Peter Dimov adds: +</p> + +<blockquote> +<p> +My favorite option is "not a defect". A, B and C break useful code. +</p> +</blockquote> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Concern this is similar to confusing "pointer to const" with "a constant pointer". +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="745"></a>745. copy_exception API slices.</h3> +<p><b>Section:</b> 18.7.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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#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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +It could be I did not understand the design rationale, but I thought +copy_exception would produce an exception_ptr to the most-derived (dynamic) +type of the passed exception. Instead it slices, which appears to be less +useful, and a likely source of FAQ questions in the future. +</p> +<p> +(Peter Dimov suggests NAD) +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +How could this be implemented in a way that the dynamic type is cloned? +</p> +<p> +The feature is designed to create an exception_ptr from an object whose +static type is identical to the dynamic type and thus there is no +slicing involved. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="748"></a>748. The is_abstract type trait is defined by reference to 10.4.</h3> +<p><b>Section:</b> 20.4.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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> +<p> +I am trying to decide is a pure virtual function is a <i>necessary</i> as well as +sufficient requirement to be classified as abstract? +</p> +<p> +For instance, is the following (non-polymorphic) type considered abstract? +</p> +<blockquote><pre>struct abstract { +protected: + abstract(){} + abstract( abstract const & ) {} + ~abstract() {} +}; +</pre></blockquote> +<p> +(Suggested that this may be NAD, with an editorial fix-up from Pete on the +core wording to make clear that abstract requires a pure virtual function) +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Core has clarified that the definition abstract is adequate. Issue withdrawn by submitter. NAD. +</p> + + + + + +<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> + <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>Discussion:</b></p> +<p> +14882-2003, [lib.uninitialized.copy] is currently written as follows: +</p> + +<blockquote> +<pre>template <class InputIterator, class ForwardIterator> + ForwardIterator uninitialized_copy(InputIterator <i>first</i>, InputIterator <i>last</i>, + ForwardIterator <i>result</i>); +</pre> +<blockquote> +<p> +-1- <i>Effects:</i> +</p> +<blockquote><pre>for (; first != last; ++result, ++first) + new (static_cast<void*>(&*result)) + typename iterator_traits<ForwardIterator>::value_type(*first); +</pre></blockquote> +<p> +-2- <i>Returns:</i> <tt><i>result</i></tt> +</p> +</blockquote> +</blockquote> + +<p> +similarily for N2369, and its corresponding section +20.6.10.1 [uninitialized.copy]. +</p> + +<p> +It's not clear to me what the return clause is supposed to mean, I see +two +possible interpretations: +</p> + +<ol type="a"> +<li> +The notion of <tt><i>result</i></tt> is supposed to mean the value given by the +function parameter <tt><i>result</i></tt> [Note to the issue editor: Please use italics for +<tt><i>result</i></tt>]. +This seems somewhat implied by recognizing that both the function +parameter +and the name used in the clause do have the same italic font. +</li> +<li> +The notion of "result" is supposed to mean the value of <tt><i>result</i></tt> +after the +preceding effects clause. This is in fact what all implementations I +checked +do (and which is probably it's intend, because it matches the +specification of <tt>std::copy</tt>). +</li> +</ol> + +<p> +The problem is: I see nothing in the standard which grants that this +interpretation +is correct, specifically [lib.structure.specifications] or +17.3.1.3 [structure.specifications] +resp. do not clarify which "look-up" rules apply for names found in +the elements +of the detailed specifications - Do they relate to the corresponding +synopsis or +to the effects clause (or possibly other elements)? Fortunately most +detailed +descriptions are unambigious in this regard, e.g. this problem does +not apply +for <tt>std::copy</tt>. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change the wording of the return clause to say (20.6.10.1 [uninitialized.copy]): +</p> + +<blockquote> +<p> +-2- <i>Returns:</i> <ins>The value of</ins> <tt><i>result</i></tt> <ins>after effects have taken place.</ins> +</p> +</blockquote> + + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Resolution: NAD editorial -- project editor to decide if change is +worthwhile. Concern is that there are many other places this might +occur. +</blockquote> + + + + +<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> + <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>Discussion:</b></p> +<p> +In the synopsis 23.2.6 [vector], there is the signature: +</p> + +<blockquote><pre>void insert(const_iterator position, size_type n, T&& x); +</pre></blockquote> + +<p> +instead of: +</p> + +<blockquote><pre>iterator insert(const_iterator position, T&& x); +</pre></blockquote> + +<p> +23.2.6.4 [vector.modifiers] is fine. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change the synopsis in 23.2.6 [vector]: +</p> + +<blockquote><pre>iterator insert(const_iterator position, const T& x); +<ins>iterator insert(const_iterator position, T&& x);</ins> +void insert(const_iterator position, size_type n, const T& x); +<del>void insert(const_iterator position, size_type n, T&& x);</del> +</pre></blockquote> + + + + + +<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> + <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> +<p><b>Discussion:</b></p> +<p> +The associative containers provide 2 overloads of <tt>emplace()</tt>: +</p> + +<blockquote><pre>template <class... Args> pair<iterator, bool> emplace(Args&&... args); +template <class... Args> iterator emplace(const_iterator position, Args&&... args); +</pre></blockquote> + +<p> +This is a problem if you mean the first overload while passing +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> +]</i></p> + + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +</blockquote> +<p> +This can be disambiguated by passing "begin" as the first argument in +the case when the non-default choice is desired. We believe that desire +will be rare. +</p> +<p> +Resolution: Change state to NAD. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Rename one of the two overloads. +For example to <tt>emplace_here</tt>, <tt>hint_emplace</tt>... +</p> + + + + + +<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> + <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-11-29</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> +<p> + A major attribute of the unordered containers is that iterating +though them inside a bucket is very fast while iterating between buckets +can be much slower. If an unordered container has a low load factor, +iterating between the last iterator in one bucket and the next iterator, +which is in another bucket, is <tt>O(bucket_count())</tt> which may be much +larger than <tt>O(size())</tt>. +</p> +<p> + If <tt>b</tt> is an non-const unordered container of type <tt>B</tt> and <tt>k</tt> is an +object of it's <tt>key_type</tt>, then <tt>b.equal_range(k)</tt> currently returns +<tt>pair<B::iterator, B::iterator></tt>. Consider the following code: +</p> + +<blockquote><pre>B::iterator lb, ub; +tie(lb, ub) = b.equal_range(k); +for (B::iterator it = lb; it != ub; ++it) { + // Do something with *it +} +</pre></blockquote> + +<p> +If <tt>b.equal_range(k)</tt> returns a non-empty range (i.e. <tt>b</tt> contains at least +on element whose key is equivalent to <tt>k</tt>), then every iterator in the +half-open range <tt>[lb, ub)</tt> will be in the same bucket, but <tt>ub</tt> will likely +either be in a different bucket or be equal to <tt>b.end()</tt>. In either case, +iterating between <tt>ub - 1</tt> and <tt>ub</tt> could take a much longer time than +iterating through the rest of the range. +</p> +<p> +If instead of returning <tt>pair<iterator, iterator></tt>, <tt>equal_range</tt> were to +return <tt>pair<local_iterator, local_iterator></tt>, then <tt>ub</tt> (which, like <tt>lb</tt>, +would now be a <tt>local_iterator</tt>) could be guaranteed to always be in the +same bucket as <tt>lb</tt>. In the cases where currently <tt>ub</tt> is equal to <tt>b.end()</tt> +or is in a different bucket, <tt>ub</tt> would be equal to <tt>b.end(b.bucket(key))</tt>. + This would make iterating between <tt>lb</tt> and <tt>ub</tt> much faster, as every +iteration would be constant time. +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +The proposed resolution breaks consistency with other container types +for dubious benefit, and iterators are already constant time. +</blockquote> + + + +<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: +</p> +<table border="1"> +<tbody><tr> +<th>expression</th> <th>return type</th> <th>assertion/note pre/post-condition</th> <th>complexity</th> +</tr> + +<tr> +<td><tt>b.equal_range(k)</tt></td> +<td><tt>pair<<ins>local_</ins>iterator,<ins>local_</ins>iterator>; pair<const_<ins>local_</ins>iterator,const_<ins>local_</ins>iterator></tt> for <tt>const b</tt>.</td> +<td>Returns a range containing all elements with keys equivalent to <tt>k</tt>. Returns <tt>make_pair(b.end(<ins>b.bucket(key)</ins>),b.end(<ins>b.bucket(key)</ins>))</tt> if no such elements exist.</td> +<td>Average case Θ<tt>(b.count(k))</tt>. Worst case Θ<tt>(b.size())</tt>. </td> +</tr> +</tbody></table> + + + + + +<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> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.uni">issues</a> in [rand.dist.uni].</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> +<ol> +<li> +26.4.8.1.1 [rand.dist.uni.int] <tt>uniform_int</tt> constructor has changed the default +max constructor parameter from 9 (in TR1) to <tt>max()</tt>. The value +is arbitrary at best and shouldn't be lightly changed because +it breaks backward compatibility. +</li> + +<li> +26.4.8.1.1 [rand.dist.uni.int] <tt>uniform_int</tt> has a parameter <tt>param</tt> that you can +provide on construction or <tt>operator()</tt>, set, and get. But there +is not even a hint of what this might be for. +</li> + +<li> +26.4.8.1.2 [rand.dist.uni.real] <tt>uniform_real</tt>. Same issue as #2. +</li> +</ol> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +NAD. Withdrawn. +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +</p> + + + + + +<hr> +<h3><a name="784"></a>784. unique_lock::release</h3> +<p><b>Section:</b> 30.3.3.2.3 [thread.lock.unique.mod] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> + <b>Submitter:</b> Constantine Sapuntzakis <b>Date:</b> 2008-02-02</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> +<tt>unique_lock::release</tt> will probably lead to many mistakes where people +call <tt>release</tt> instead of <tt>unlock</tt>. I just coded such a mistake using the +boost pre-1.35 threads library last week. +</p> + +<p> +In many threading libraries, a call with <tt>release</tt> in it unlocks the +lock (e.g. ReleaseMutex in Win32, java.util.concurrent.Semaphore). +</p> + +<p> +I don't call <tt>unique_lock::lock</tt> much at all, so I don't get to see the +symmetry between <tt>::lock</tt> and <tt>::unlock</tt>. I usually use the constructor to +lock the mutex. So I'm left to remember whether to call <tt>release</tt> or +<tt>unlock</tt> during the few times I need to release the mutex before the scope +ends. If I get it wrong, the compiler doesn't warn me. +</p> + +<p> +An alternative name for release may be <tt>disown</tt>. +</p> + +<p> +This might be a rare case where usability is hurt by consistency with +the rest of the C++ standard (e.g. <tt>std::auto_ptr::release</tt>). +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Change a name from release to disown. However prior art uses the release +name. Compatibility with prior art is more important that any possible +benefit such a change might make. We do not see the benefit for +changing. NAD +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +Change the synopsis in 30.3.3.2 [thread.lock.unique]: +</p> + +<blockquote><pre>template <class Mutex> +class unique_lock +{ +public: + ... + mutex_type* <del>release</del> <ins>disown</ins>(); + ... +}; +</pre></blockquote> + +<p> +Change 30.3.3.2.3 [thread.lock.unique.mod]: +</p> + +<blockquote><pre>mutex_type *<del>release</del> <ins>disown</ins>(); +</pre></blockquote> + + + + + +<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> +<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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +<tt>xor_combine::seed(result_type)</tt> and <tt>seed(seed_seq&)</tt> don't say what +happens to each of the sub-engine seeds. (Should probably do the same +to both, unlike TR1.) +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<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>. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> + + + + + +<hr> +<h3><a name="791"></a>791. <tt>piecewise_constant_distribution::densities</tt> has wrong name</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#NAD">NAD</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +<tt>piecewise_constant_distribution::densities()</tt> should be <tt>probabilities()</tt>, +just like <tt>discrete_distribution</tt>. (There's no real use for weights divided +by areas.) +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +Fermilab does not agree with this summary. As defined in the equation in +26.4.8.5.2/4, the quantities are indeed probability densities not +probabilities. Because we view this distribution as a parameterization +of a *probability density function*, we prefer to work in terms of +probability densities. +</p> + +<p> +We don't think this should be changed. +</p> + +<p> +If there is a technical argument about why the implementation dealing +with these values can't be as efficient as one dealing with +probabilities, we might reconsider. We don't care about this one member +function being somewhat more or less efficient; we care about the size +of the distribution object and the speed of the calls to generate +variates. +</p> +</blockquote> + + + +<p><b>Proposed resolution:</b></p> + +<p> +Change synopsis in 26.4.8.5.2 [rand.dist.samp.pconst]: +</p> + +<blockquote><pre>template <class RealType = double> +class piecewise_constant_distribution +{ +public: + ... + vector<double> <del>densities</del> <ins>probabilities</ins>() const; + ... +}; +</pre></blockquote> + +<p> +Change 26.4.8.5.2 [rand.dist.samp.pconst]/6: +</p> + +<blockquote><pre>vector<double> <del>densities</del> <ins>probabilities</ins>() const; +</pre></blockquote> + + + + + + +<hr> +<h3><a name="795"></a>795. <tt>general_pdf_distribution</tt> should be dropped</h3> +<p><b>Section:</b> 26.4.8.5.3 [rand.dist.samp.genpdf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</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.genpdf">issues</a> in [rand.dist.samp.genpdf].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> +<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a></p> +<p><b>Discussion:</b></p> +<p> +<tt>general_pdf_distribution</tt> should be dropped. (It's a research topic in +adaptive numerical integration.) +</p> + +<p><i>[ +Stephan Tolksdorf notes: +]</i></p> + + +<blockquote> +This appears to be a duplicate of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>. +</blockquote> + + +<p><b>Proposed resolution:</b></p> + + + + + + +<hr> +<h3><a name="796"></a>796. <tt>ranlux48_base</tt> returns wrong value</h3> +<p><b>Section:</b> 26.4.5 [rand.predef] <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> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.predef">issues</a> in [rand.predef].</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 10,000<sup>th</sup> value returned by <tt>ranlux48_base</tt> is supposed to be +61839128582725. We get 192113843633948. (Note that the underlying +generator was changed in Kona.) +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Submitter withdraws defect. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change 26.4.5 [rand.predef]/p5: +</p> + +<blockquote> +<pre>typedef subtract_with_carry_engine<uint_fast64_t, 48, 5, 12> + ranlux48_base; +</pre> +<blockquote> +<i>Required behavior:</i> The 10000<sup>th</sup> consecutive invocation of a default-constructed +object of type <tt>ranlux48_base</tt> shall produce the value +<del>61839128582725</del> <ins>192113843633948</ins>. +</blockquote> +</blockquote> + + + + + +<hr> +<h3><a name="797"></a>797. <tt>ranlux48</tt> returns wrong value</h3> +<p><b>Section:</b> 26.4.5 [rand.predef] <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> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.predef">issues</a> in [rand.predef].</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 10,000<sup>th</sup> value returned by <tt>ranlux48</tt> is supposed to be +249142670248501. We get 88229545517833. (Note that this depends +on <tt>ranlux48_base</tt>.) +</p> +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +Submitter withdraws defect. +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change 26.4.5 [rand.predef]/p6: +</p> + +<blockquote> +<pre>typedef discard_block_engine<ranlux48_base, 389, 11> + ranlux48 +</pre> +<blockquote> +<i>Required behavior:</i> The 10000<sup>th</sup> consecutive invocation of a default-constructed +object of type <tt>ranlux48</tt> shall produce the value +<del>249142670248501</del> <ins>88229545517833</ins>. +</blockquote> +</blockquote> + + + + + +<hr> +<h3><a name="799"></a>799. [tr.rand.eng.mers] and [rand.eng.mers]</h3> +<p><b>Section:</b> 26.4.3.2 [rand.eng.mers], TR1 5.1.4.2 [tr.rand.eng.mers] <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> 2008-02-18</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#NAD">NAD</a> status.</p> +<p><b>Discussion:</b></p> +<p> +TR1 5.1.4.2 [tr.rand.eng.mers](10) requires that <tt>operator==</tt> for the <tt>mersenne_twister</tt> +returns <tt>true</tt> if and only if the states of two <tt>mersenne_twisters</tt>, +consisting each of <tt>n</tt> integers between <tt>0</tt> and <tt>2<sup>w</sup> - 1</tt>, are completely +equal. This is a contradiction with TR1 5.1.1 [tr.rand.req](3) because the given +definition of the state also includes the lower <tt>r</tt> bits of <tt>x(i-n)</tt>, which +will never be used to generate a random number. If two <tt>mersenne_twister</tt>s +only differ in the lower bits of <tt>x(i-n)</tt> they will not compare equal, +although they will produce an identical sequence of random numbers. +</p> + +<p> +26.4.3.2 [rand.eng.mers] in the latest C++ draft does not specify the behaviour +of <tt>operator==</tt> but uses a similar definition of the state and, just like +TR1 5.1.4.2 [tr.rand.eng.mers], requires the textual representation of a +<tt>mersenne_twister_engine</tt> to consist of <tt>X<sub>i-n</sub></tt> to <tt>X<sub>i-1</sub></tt>, including the +lower bits of <tt>X<sub>i-n</sub></tt>. This leads to two problems: First, the +unsuspecting implementer is likely to erroneously compare the lower <tt>r</tt> +bits of <tt>X<sub>i-n</sub></tt> in <tt>operator==</tt>. Second, if only the lower <tt>r</tt> bits differ, +two <tt>mersenne_twister_engine</tt>s will compare equal (if correctly +implemented) but have different textual representations, which +conceptually is a bit ugly. +</p> + +<p> +I propose that a paragraph or footnote is added to 26.4.3.2 [rand.eng.mers] which +clarifies that the lower <tt>r</tt> bits of <tt>X<sub>i-n</sub></tt> are not to be compared in +<tt>operator==</tt> and <tt>operator!=</tt>. It would only be consequent if furthermore +the specification for the textual respresentation was changed to +<tt>X<sub>i-n</sub> bitand ((2<sup>w</sup> - 1) - (2<sup>r</sup> - 1)), X<sub>i-(n-1)</sub>, ..., X<sub>i-1</sub></tt> or +something similar. +</p> + +<p> +These changes would likely have no practical effect, but would allow an +implementation that does the right thing to be standard-conformant. +</p> + +<p><i>[ +Bellevue: +]</i></p> + + +<blockquote> +<p> +Fermi Lab has no objection to the proposed change. However it feels that +more time is needed to check the details, which would suggest a change +to REVIEW. +</p> +<p> +Bill feels that this is NAD, not enough practical importance to abandon +the simple definition of equality, and someone would have to do a lot +more study to ensure that all cases are covered for a very small +payback. The submitter admits that "These changes would likely have no +practical effect,", and according to Plum's razor this means that it is +not worth the effort! +</p> +<p> +Revisted: Agree that the fact that there is no practical difference means that no change can be justified. +</p> +</blockquote> + + +<p><b>Proposed resolution:</b></p> +<p> +In 26.4.3.2 [rand.eng.mers]: +</p> + +<blockquote> +<p> +Insert at the end of para 2.: +</p> + +<blockquote> +[<i>Note:</i> The lower <tt>r</tt> bits of <tt>X<sub>i-n</sub></tt> do not influence +the state transition and hence should not be compared when comparing two +<tt>mersenne_twister_engine</tt> objects. <i>-- end note</i>] +</blockquote> + +<p> +In para 5. change: +</p> + +<blockquote> +The textual representation of <tt>x<sub>i</sub></tt> consists of the values of +<tt>X<sub>i-n</sub> <ins>bitand ((2<sup>w</sup> - 1) - (2<sup>r</sup> - 1)), X<sub>i-(n-1)</sub></ins>, +..., X<sub>i-1</sub></tt>, in that order. +</blockquote> +</blockquote> + + + + + +<hr> +<h3><a name="802"></a>802. <tt>knuth_b</tt> returns wrong value</h3> +<p><b>Section:</b> 26.4.5 [rand.predef] <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-20</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.predef">issues</a> in [rand.predef].</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 10,000<sup>th</sup> value returned by <tt>knuth_b</tt> is supposed to be +1112339016. We get 2126698284. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 26.4.5 [rand.predef]/p8: +</p> + +<blockquote> +<pre>typedef shuffle_order_engine<minstd_rand0, 256> + knuth_b; +</pre> +<blockquote> +<i>Required behavior:</i> The 10000<sup>th</sup> consecutive invocation of a default-constructed +object of type <tt>knuth_b</tt> shall produce the value +<del>1112339016</del> <ins>2126698284</ins>. +</blockquote> +</blockquote> + + +<p><i>[ +Bellevue: Submitter withdraws defect. "We got the wrong value for entirely the right reasons". NAD. +]</i></p> + + + + + + </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 cefbee6..0133503 100644 --- a/libstdc++-v3/doc/html/ext/lwg-defects.html +++ b/libstdc++-v3/doc/html/ext/lwg-defects.html @@ -12,11 +12,11 @@ del {background-color:#FFA0A0} <table> <tbody><tr> <td align="left">Doc. no.</td> -<td align="left">N2457=07-0327</td> +<td align="left">N2613=08-0123</td> </tr> <tr> <td align="left">Date:</td> -<td align="left">2007-10-20</td> +<td align="left">2008-05-18</td> </tr> <tr> <td align="left">Project:</td> @@ -27,7 +27,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 R52)</h1> +<h1>C++ Standard Library Defect Report List (Revision R56)</h1> <p>Reference ISO/IEC IS 14882:1998(E)</p> <p>Also see:</p> @@ -49,6 +49,89 @@ del {background-color:#FFA0A0} <h2>Revision History</h2> <ul> +<li>R56: +2008-05-16 pre-Sophia Antipolis mailing. +<ul> +<li><b>Summary:</b><ul> +<li>191 open issues, up by 24.</li> +<li>647 closed issues, up by 1.</li> +<li>838 issues total, up by 25.</li> +</ul></li> +<li><b>Details:</b><ul> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>.</li> +</ul></li> +</ul> +</li> +<li>R55: +2008-03-14 post-Bellevue mailing. +<ul> +<li><b>Summary:</b><ul> +<li>167 open issues, down by 39.</li> +<li>646 closed issues, up by 65.</li> +<li>813 issues total, up by 26.</li> +</ul></li> +<li><b>Details:</b><ul> +<li>Added the following Dup issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a>.</li> +<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#790">790</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#791">791</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#796">796</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#797">797</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#799">799</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>.</li> +<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#801">801</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a>.</li> +<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>.</li> +<li>Changed the following issues from NAD Future to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.</li> +<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>.</li> +<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#462">462</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>.</li> +<li>Changed the following issues from NAD Future to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li> +<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li> +<li>Changed the following issues from Review to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>.</li> +<li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a>.</li> +<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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 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 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 Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>.</li> +<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>.</li> +<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li> +<li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>.</li> +</ul></li> +</ul> +</li> +<li>R54: +2008-02-01 pre-Bellevue mailing. +<ul> +<li><b>Summary:</b><ul> +<li>206 open issues, up by 23.</li> +<li>581 closed issues, up by 0.</li> +<li>787 issues total, up by 23.</li> +</ul></li> +<li><b>Details:</b><ul> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>.</li> +<li>Changed the following issues from NAD Future to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>.</li> +<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#697">697</a>.</li> +<li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>.</li> +<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>.</li> +</ul></li> +</ul> +</li> +<li>R53: +2007-12-09 mid-term mailing. +<ul> +<li><b>Summary:</b><ul> +<li>183 open issues, up by 11.</li> +<li>581 closed issues, down by 1.</li> +<li>764 issues total, up by 10.</li> +</ul></li> +<li><b>Details:</b><ul> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>.</li> +<li>Changed the following issues from Pending WP to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li> +</ul></li> +</ul> +</li> <li>R52: 2007-10-19 post-Kona mailing. <ul> @@ -58,16 +141,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-active.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#754">754</a>.</li> +<li>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>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>.</li> <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>.</li> <li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a>.</li> -<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li> +<li>Changed the following issues from New to 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 Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li> <li>Changed the following issues from New to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li> -<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#706">706</a>.</li> -<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#680">680</a>.</li> -<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>.</li> +<li>Changed the following issues from New to 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 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 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> @@ -83,7 +166,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-active.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>.</li> +<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> </ul></li> </ul> </li> @@ -96,13 +179,13 @@ del {background-color:#FFA0A0} <li>708 issues total, up by 12.</li> </ul></li> <li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#697">697</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li> +<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#697">697</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li> <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#584">584</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>.</li> <li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</a>.</li> <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>.</li> <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>.</li> <li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li> -<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#680">680</a>.</li> +<li>Changed the following issues from 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 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> @@ -123,7 +206,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-active.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li> +<li>Added the following 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 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> @@ -140,12 +223,12 @@ 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-active.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>.</li> +<li>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>Changed the following issues from Tentatively Ready to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>.</li> -<li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li> +<li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li> <li>Changed the following issues from NAD to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#357">357</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#368">368</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a>.</li> <li>Changed the following issues from Tentatively Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>.</li> -<li>Changed the following issues from NAD_Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li> +<li>Changed the following issues from NAD_Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li> <li>Changed the following issues from Tentatively Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>.</li> <li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li> <li>Changed the following issues from Tentatively Ready to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>.</li> @@ -167,11 +250,11 @@ 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-active.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li> -<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#626">626</a>.</li> +<li>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 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 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-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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 Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>.</li> <li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>.</li> </ul></li> </ul> @@ -201,7 +284,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-active.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li> +<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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> @@ -245,9 +328,9 @@ del {background-color:#FFA0A0} <li>574 issues total, up by 8.</li> </ul></li> <li><b>Details:</b><ul> -<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#567">567</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li> +<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li> <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#501">501</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#517">517</a> to NAD.</li> -<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a> to Open.</li> +<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a> to Open.</li> <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a> to Ready.</li> <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> to WP.</li> <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li> @@ -278,7 +361,7 @@ del {background-color:#FFA0A0} <li>535 issues total.</li> </ul></li> <li><b>Details:</b><ul> -<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#529">529</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>.</li> +<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>.</li> </ul></li> </ul> </li> @@ -323,12 +406,12 @@ new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html# <li>R31: 2004-07 mid-term mailing: reflects new proposed resolutions and new issues received after the post-Sydney mailing. Added -new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>. +new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>. </li> <li>R30: Post-Sydney mailing: reflects decisions made at the Sydney meeting. Voted all "Ready" issues from R29 into the working paper. -Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#462">462</a>. +Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#462">462</a>. </li> <li>R29: Pre-Sydney mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>. @@ -473,7 +556,7 @@ of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3 <li>R10: pre-Kona updated. Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>, -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a> to +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99) </li> <li>R9: @@ -492,7 +575,7 @@ pre-Dublin updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a> (31 Mar 99) </li> <li>R6: -pre-Dublin mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>, +pre-Dublin mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>, and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>. (99-0007/N1194, 22 Feb 99) </li> <li>R5: @@ -962,7 +1045,6 @@ supporting to the proposed resolution.</p> <h3><a name="11"></a>11. Bitset minor problems</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#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-01-22</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> <p><b>Discussion:</b></p> @@ -3314,7 +3396,7 @@ item from:</p> <hr> <h3><a name="69"></a>69. Must elements of a vector be contiguous?</h3> -<p><b>Section:</b> 23.2.5 [vector] <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.2.6 [vector] <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> 1998-07-29</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#TC">TC</a> status.</p> @@ -3328,7 +3410,7 @@ debugging implementations)</p> <p><b>Proposed resolution:</b></p> -<p>Add the following text to the end of 23.2.5 [vector], +<p>Add the following text to the end of 23.2.6 [vector], paragraph 1. </p> <blockquote> @@ -4567,7 +4649,6 @@ example, printing short(-1) in hex format should yield 0xffff.)</p> <h3><a name="118"></a>118. <tt>basic_istream</tt> uses nonexistent <tt>num_get</tt> member functions</h3> <p><b>Section:</b> 27.6.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-11-20</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.formatted.arithmetic">active issues</a> in [istream.formatted.arithmetic].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> <p><b>Discussion:</b></p> @@ -4681,7 +4762,7 @@ exception-specification for a non-virtual function". </p> <hr> <h3><a name="120"></a>120. Can an implementor add specializations?</h3> -<p><b>Section:</b> 17.4.3.1 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> +<p><b>Section:</b> 17.4.3.2 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#reserved.names">issues</a> in [reserved.names].</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> @@ -4732,7 +4813,7 @@ different explicit instantiations might be harmless.</p> <p><b>Proposed resolution:</b></p> - <p>Append to 17.4.3.1 [reserved.names] paragraph 1: </p> + <p>Append to 17.4.3.2 [reserved.names] paragraph 1: </p> <blockquote><p> A program may explicitly instantiate any templates in the standard library only if the declaration depends on the name of a user-defined @@ -4751,7 +4832,7 @@ different explicit instantiations might be harmless.</p> <blockquote> <p>In light of the resolution to core issue 259, no normative changes in the library clauses are necessary. Add the following non-normative - note to the end of 17.4.3.1 [reserved.names] paragraph 1:</p> + note to the end of 17.4.3.2 [reserved.names] paragraph 1:</p> <blockquote><p> [<i>Note:</i> A program may explicitly instantiate standard library templates, even when an explicit instantiation does not depend on @@ -5226,7 +5307,7 @@ Redmond: formally voted into WP. <hr> <h3><a name="132"></a>132. list::resize description uses random access iterators</h3> -<p><b>Section:</b> 23.2.3.2 [list.capacity] <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.2.4.2 [list.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</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> @@ -5245,7 +5326,7 @@ Redmond: formally voted into WP. <p><b>Proposed resolution:</b></p> -<p>Change 23.2.3.2 [list.capacity] paragraph 1 to:</p> +<p>Change 23.2.4.2 [list.capacity] paragraph 1 to:</p> <p>Effects:</p> @@ -5286,7 +5367,7 @@ after operator= in the map declaration:</p> <hr> <h3><a name="134"></a>134. vector constructors over specified</h3> -<p><b>Section:</b> 23.2.5.1 [vector.cons] <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.2.6.1 [vector.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</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> @@ -5298,7 +5379,7 @@ tradeoff for the implementor.</p> <p><b>Proposed resolution:</b></p> -<p>Change 23.2.5.1 [vector.cons], paragraph 1 to:</p> +<p>Change 23.2.6.1 [vector.cons], paragraph 1 to:</p> <p>-1- Complexity: The constructor template <class InputIterator> vector(InputIterator first, InputIterator last) @@ -6085,7 +6166,6 @@ is the correct spelling.]</i></p> <h3><a name="161"></a>161. Typo: <tt>istream_iterator</tt> vs. <tt>istreambuf_iterator</tt></h3> <p><b>Section:</b> 27.6.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.formatted.arithmetic">active issues</a> in [istream.formatted.arithmetic].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> <p><b>Discussion:</b></p> @@ -6311,7 +6391,6 @@ sentences, change the word "formatted" to <h3><a name="169"></a>169. Bad efficiency of <tt>overflow()</tt> mandated</h3> <p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#stringbuf.virtuals">active issues</a> in [stringbuf.virtuals].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p> <p><b>Discussion:</b></p> @@ -6758,7 +6837,7 @@ proposed resolution passed their test suites.</p> <p><b>Discussion:</b></p> <p>Many references to <tt> size_t</tt> throughout the document omit the <tt> std::</tt> namespace qualification.</p> <p>For -example, 17.4.3.4 [replacement.functions] paragraph 2:</p> +example, 17.4.3.5 [replacement.functions] paragraph 2:</p> <blockquote> <pre> operator new(size_t) operator new(size_t, const std::nothrow_t&) @@ -6768,7 +6847,7 @@ example, 17.4.3.4 [replacement.functions] paragraph 2:</p> <p><b>Proposed resolution:</b></p> -<p> In 17.4.3.4 [replacement.functions] paragraph 2: replace:</p> +<p> In 17.4.3.5 [replacement.functions] paragraph 2: replace:</p> <blockquote> <p><tt> - operator new(size_t)<br> - operator new(size_t, const std::nothrow_t&)<br> @@ -6845,7 +6924,7 @@ declaration of template <class charT> class ctype.<br> <p>The LWG believes correcting names like <tt>size_t</tt> and <tt>ptrdiff_t</tt> to <tt>std::size_t</tt> and <tt>std::ptrdiff_t</tt> to be essentially editorial. There there can't be another size_t or -ptrdiff_t meant anyway because, according to 17.4.3.1.4 [extern.types],</p> +ptrdiff_t meant anyway because, according to 17.4.3.2.4 [extern.types],</p> <blockquote><p> For each type T from the Standard C library, the types ::T and std::T @@ -7700,7 +7779,7 @@ otherwise <tt>const U&</tt>". <p><i>[Tokyo: The LWG believes this is the tip of a larger iceberg; there are multiple const problems with the STL portion of the library and that these should be addressed as a single package. Note -that issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#180">180</a> has already been declared NAD Future for +that issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a> has already been declared NAD Future for that very reason.]</i></p> @@ -8382,6 +8461,7 @@ 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> @@ -8839,7 +8919,7 @@ resolution for this issue is in accordance with Howard's paper.]</i></p> <hr> <h3><a name="226"></a>226. User supplied specializations or overloads of namespace std function templates</h3> -<p><b>Section:</b> 17.4.3.1 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> +<p><b>Section:</b> 17.4.3.2 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2000-04-01</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#reserved.names">issues</a> in [reserved.names].</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> @@ -9452,7 +9532,7 @@ where precision is 0 and mode is %g.]</i></p> <hr> <h3><a name="232"></a>232. "depends" poorly defined in 17.4.3.1</h3> -<p><b>Section:</b> 17.4.3.1 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> +<p><b>Section:</b> 17.4.3.2 [reserved.names] <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> 2000-04-18</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#reserved.names">issues</a> in [reserved.names].</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> @@ -9557,10 +9637,10 @@ adjacent to the insertion point.]</i></p> <p><i>[Copenhagen: the LWG agreed to the original proposed resolution, in which an insertion hint would be used even when it is far from the -insertion point. This was contingent on seeing a reference +insertion point. This was contingent on seeing a example implementation showing that it is possible to implement this requirement without loss of efficiency. John Potter provided such a -reference implementation.]</i></p> +example implementation.]</i></p> <p><i>[Redmond: The LWG was reluctant to adopt the proposal that @@ -9656,7 +9736,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.1.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.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> <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> @@ -10184,12 +10264,12 @@ Jerry Schwarz's message c++std-lib-7618.</p> <hr> <h3><a name="247"></a>247. <tt>vector</tt>, <tt>deque::insert</tt> complexity</h3> -<p><b>Section:</b> 23.2.5.4 [vector.modifiers] <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.2.6.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Lisa Lippincott <b>Date:</b> 2000-06-06</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.modifiers">issues</a> in [vector.modifiers].</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 2 of 23.2.5.4 [vector.modifiers] describes the complexity +<p>Paragraph 2 of 23.2.6.4 [vector.modifiers] describes the complexity of <tt>vector::insert</tt>:</p> <blockquote><p> @@ -10226,7 +10306,7 @@ paragraph 3):</p> <p><b>Proposed resolution:</b></p> -<p>Change Paragraph 2 of 23.2.5.4 [vector.modifiers] to</p> +<p>Change Paragraph 2 of 23.2.6.4 [vector.modifiers] to</p> <blockquote><p> Complexity: The complexity is linear in the number of elements inserted plus the distance to the end of the vector. @@ -10292,13 +10372,13 @@ input facets.</p> <hr> <h3><a name="250"></a>250. splicing invalidates iterators</h3> -<p><b>Section:</b> 23.2.3.4 [list.ops] <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.2.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Brian Parker <b>Date:</b> 2000-07-14</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.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> -Section 23.2.3.4 [list.ops] states that +Section 23.2.4.4 [list.ops] states that </p> <pre> void splice(iterator position, list<T, Allocator>& x); </pre> @@ -10315,14 +10395,14 @@ after <tt>splice</tt>. <p><b>Proposed resolution:</b></p> -<p>Add a footnote to 23.2.3.4 [list.ops], paragraph 1:</p> +<p>Add a footnote to 23.2.4.4 [list.ops], paragraph 1:</p> <blockquote><p> [<i>Footnote:</i> As specified in [default.con.req], paragraphs 4-5, the semantics described in this clause applies only to the case where allocators compare equal. --end footnote] </p></blockquote> -<p>In 23.2.3.4 [list.ops], replace paragraph 4 with:</p> +<p>In 23.2.4.4 [list.ops], replace paragraph 4 with:</p> <blockquote><p> Effects: Inserts the contents of x before position and x becomes empty. Pointers and references to the moved elements of x now refer to @@ -10331,7 +10411,7 @@ moved elements will continue to refer to their elements, but they now behave as iterators into *this, not into x. </p></blockquote> -<p>In 23.2.3.4 [list.ops], replace paragraph 7 with:</p> +<p>In 23.2.4.4 [list.ops], replace paragraph 7 with:</p> <blockquote><p> Effects: Inserts an element pointed to by i from list x before position and removes the element from x. The result is unchanged if @@ -10341,7 +10421,7 @@ to refer to this same element but as a member of *this. Iterators to *i behave as iterators into *this, not into x. </p></blockquote> -<p>In 23.2.3.4 [list.ops], replace paragraph 12 with:</p> +<p>In 23.2.4.4 [list.ops], replace paragraph 12 with:</p> <blockquote><p> Requires: [first, last) is a valid range in x. The result is undefined if position is an iterator in the range [first, last). @@ -10439,7 +10519,6 @@ 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> @@ -11043,6 +11122,7 @@ the need to explicit include or construct a <tt>std::string</tt>. <h3><a name="256"></a>256. typo in 27.4.4.2, p17: copy_event does not exist</h3> <p><b>Section:</b> 27.4.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-08-21</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> <p><b>Discussion:</b></p> @@ -12193,13 +12273,13 @@ implement <tt>vector::push_back</tt> in terms of <hr> <h3><a name="278"></a>278. What does iterator validity mean?</h3> -<p><b>Section:</b> 23.2.3.4 [list.ops] <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.2.4.4 [list.ops] <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> 2000-11-27</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.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> -Section 23.2.3.4 [list.ops] states that +Section 23.2.4.4 [list.ops] states that </p> <pre> void splice(iterator position, list<T, Allocator>& x); </pre> @@ -12345,6 +12425,7 @@ 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> @@ -12855,6 +12936,7 @@ m</i> of these elements from [first2, last2) if <i>m</i> < <i>n</i>. <h3><a name="292"></a>292. effects of a.copyfmt (a)</h3> <p><b>Section:</b> 27.4.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-01-05</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> <p><b>Discussion:</b></p> @@ -12892,11 +12974,11 @@ objects of <tt>rhs</tt>, except that... <hr> <h3><a name="294"></a>294. User defined macros and standard headers</h3> -<p><b>Section:</b> 17.4.3.1.1 [macro.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> +<p><b>Section:</b> 17.4.3.2.1 [macro.names] <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> 2001-01-11</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 2 of 17.4.3.1.1 [macro.names] reads: "A +<p>Paragraph 2 of 17.4.3.2.1 [macro.names] reads: "A translation unit that includes a header shall not contain any macros that define names declared in that header." As I read this, it would mean that the following program is legal:</p> @@ -12917,7 +12999,7 @@ it isn't stringent enough.</p> <p><b>Proposed resolution:</b></p> -<p>For 17.4.3.1.1 [macro.names], replace the current wording, which reads:</p> +<p>For 17.4.3.2.1 [macro.names], replace the current wording, which reads:</p> <blockquote> <p>Each name defined as a macro in a header is reserved to the implementation for any use if the translation unit includes @@ -13101,7 +13183,7 @@ For a null value of <i><tt>ptr</tt></i> , does nothing. Any other value of <i><tt>ptr</tt></i> shall be a value returned earlier by a call to the default <tt>operator new[](std::size_t)</tt>. [Footnote: The value must not have been invalidated by an intervening -call to <tt>operator delete[](void*)</tt> (17.4.3.7 [res.on.arguments]). +call to <tt>operator delete[](void*)</tt> (17.4.3.8 [res.on.arguments]). --- end footnote] For such a non-null value of <i><tt>ptr</tt></i> , reclaims storage allocated by the earlier call to the default <tt>operator new[]</tt>. @@ -13123,13 +13205,13 @@ or <tt>operator delete(<i>ptr</i>, std::nothrow)</tt> respectively. <hr> <h3><a name="300"></a>300. list::merge() specification incomplete</h3> -<p><b>Section:</b> 23.2.3.4 [list.ops] <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.2.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> John Pedretti <b>Date:</b> 2001-01-23</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.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> -The "Effects" clause for list::merge() (23.2.3.4 [list.ops], p23) +The "Effects" clause for list::merge() (23.2.4.4 [list.ops], p23) appears to be incomplete: it doesn't cover the case where the argument list is identical to *this (i.e., this == &x). The requirement in the note in p24 (below) is that x be empty after the merge which is surely @@ -13138,7 +13220,7 @@ unintended in this case. <p><b>Proposed resolution:</b></p> -<p>In 23.2.3.4 [list.ops], replace paragraps 23-25 with:</p> +<p>In 23.2.4.4 [list.ops], replace paragraps 23-25 with:</p> <blockquote> <p> 23 Effects: if (&x == this) does nothing; otherwise, merges the two @@ -13167,7 +13249,7 @@ effects. </blockquote> <p><i>[Copenhagen: The original proposed resolution did not fix all of -the problems in 23.2.3.4 [list.ops], p22-25. Three different +the problems in 23.2.4.4 [list.ops], p22-25. Three different paragraphs (23, 24, 25) describe the effects of <tt>merge</tt>. Changing p23, without changing the other two, appears to introduce contradictions. Additionally, "merges the argument list into the @@ -13507,7 +13589,7 @@ possible.]</i></p> <hr> <h3><a name="307"></a>307. Lack of reference typedefs in container adaptors</h3> -<p><b>Section:</b> 23.2.3 [list] <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.2.4 [list] <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> 2001-03-13</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> <p><b>Discussion:</b></p> @@ -13515,8 +13597,8 @@ possible.]</i></p> <p>From reflector message c++std-lib-8330. See also lib-8317.</p> <p> -The standard is currently inconsistent in 23.2.3.2 [list.capacity] -paragraph 1 and 23.2.3.3 [list.modifiers] paragraph 1. +The standard is currently inconsistent in 23.2.4.2 [list.capacity] +paragraph 1 and 23.2.4.3 [list.modifiers] paragraph 1. 23.2.3.3/1, for example, says: </p> @@ -13975,13 +14057,13 @@ as <memory>.</p> <hr> <h3><a name="315"></a>315. Bad "range" in list::unique complexity</h3> -<p><b>Section:</b> 23.2.3.4 [list.ops] <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.2.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 2001-05-01</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.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> -23.2.3.4 [list.ops], Para 21 describes the complexity of +23.2.4.4 [list.ops], Para 21 describes the complexity of list::unique as: "If the range (last - first) is not empty, exactly (last - first) -1 applications of the corresponding predicate, otherwise no applications of the predicate)". @@ -14176,13 +14258,13 @@ should be specified as "Requires".</p> <hr> <h3><a name="320"></a>320. list::assign overspecified</h3> -<p><b>Section:</b> 23.2.3.1 [list.cons] <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.2.4.1 [list.cons] <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> 2001-05-17</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.cons">issues</a> in [list.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> <p> -Section 23.2.3.1 [list.cons], paragraphs 6-8 specify that list assign (both forms) have +Section 23.2.4.1 [list.cons], paragraphs 6-8 specify that list assign (both forms) have the "effects" of a call to erase followed by a call to insert. </p> @@ -14208,7 +14290,7 @@ Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't. <p><b>Proposed resolution:</b></p> -<p>Change 23.2.3.1 [list.cons]/7 from:</p> +<p>Change 23.2.4.1 [list.cons]/7 from:</p> <blockquote> <p>Effects:</p> @@ -14235,7 +14317,7 @@ add two new rows:</p> of t. </pre> -<p>Change 23.2.3.1 [list.cons]/8 from:</p> +<p>Change 23.2.4.1 [list.cons]/8 from:</p> <blockquote> <p>Effects:</p> @@ -14608,18 +14690,18 @@ modifier.</p> <hr> <h3><a name="329"></a>329. vector capacity, reserve and reallocation</h3> -<p><b>Section:</b> 23.2.5.2 [vector.capacity], 23.2.5.4 [vector.modifiers] <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.2.6.2 [vector.capacity], 23.2.6.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Anthony Williams <b>Date:</b> 2001-07-13</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> There is an apparent contradiction about which circumstances can cause -a reallocation of a vector in Section 23.2.5.2 [vector.capacity] and -section 23.2.5.4 [vector.modifiers]. +a reallocation of a vector in Section 23.2.6.2 [vector.capacity] and +section 23.2.6.4 [vector.modifiers]. </p> -<p>23.2.5.2 [vector.capacity],p5 says:</p> +<p>23.2.6.2 [vector.capacity],p5 says:</p> <blockquote><p> Notes: Reallocation invalidates all the references, pointers, and iterators referring to the elements in the sequence. It is guaranteed that no @@ -14639,7 +14721,7 @@ greater than the size specified in the most recent call to reserve(). <p>then the implementation may reallocate the vector for the insert, as the size specified in the previous call to reserve was zero.</p> -<p>However, the previous paragraphs (23.2.5.2 [vector.capacity], p1-2) state:</p> +<p>However, the previous paragraphs (23.2.6.2 [vector.capacity], p1-2) state:</p> <blockquote> <p> (capacity) Returns: The total number of elements the vector @@ -14655,7 +14737,7 @@ of capacity() otherwise... <p> This implies that vec.capacity() is still 23, and so the insert() should not require a reallocation, as vec.size() is 0. This is backed -up by 23.2.5.4 [vector.modifiers], p1: +up by 23.2.6.4 [vector.modifiers], p1: </p> <blockquote><p> (insert) Notes: Causes reallocation if the new size is greater than the old @@ -14670,7 +14752,7 @@ than the old capacity, I think the intent is clear. <p><b>Proposed resolution:</b></p> -<p>Change the wording of 23.2.5.2 [vector.capacity] paragraph 5 to:</p> +<p>Change the wording of 23.2.6.2 [vector.capacity] paragraph 5 to:</p> <blockquote><p> Notes: Reallocation invalidates all the references, pointers, and @@ -15009,7 +15091,7 @@ library (though a deprecated one).</p> <li>17.3.2.3 [objects.within.classes] Private members/1/(2 places)</li> <li>17.4 [requirements] Library-wide requirements/1</li> <li>17.4.1.2 [headers] Headers/4</li> -<li>17.4.3.4 [replacement.functions] Replacement functions/1</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> </ul> @@ -15268,7 +15350,7 @@ complete list of the ones we need.</p> <hr> <h3><a name="341"></a>341. Vector reallocation and swap</h3> -<p><b>Section:</b> 23.2.5.2 [vector.capacity] <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.2.6.2 [vector.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Anthony Williams <b>Date:</b> 2001-09-27</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> @@ -15281,7 +15363,7 @@ an empty one:</p> // vec is now empty, with minimal capacity </pre> -<p>However, the wording of 23.2.5.2 [vector.capacity]paragraph 5 prevents +<p>However, the wording of 23.2.6.2 [vector.capacity]paragraph 5 prevents the capacity of a vector being reduced, following a call to reserve(). This invalidates the idiom, as swap() is thus prevented from reducing the capacity. The proposed wording for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#329">329</a> does not affect this. Consequently, the example above @@ -15314,7 +15396,7 @@ referred to one vector now refer to the other, and vice-versa.</li> <p><b>Proposed resolution:</b></p> -<p>Add a new paragraph after 23.2.5.2 [vector.capacity] paragraph 5:</p> +<p>Add a new paragraph after 23.2.6.2 [vector.capacity] paragraph 5:</p> <blockquote> <pre> void swap(vector<T,Allocator>& x); </pre> @@ -16435,7 +16517,6 @@ In 27.6.1.2.1 [istream.formatted.reqmts] and 27.6.2.6.1 [ostream.formatted.reqmt <h3><a name="375"></a>375. basic_ios should be ios_base in 27.7.1.3</h3> <p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-08-14</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#stringbuf.virtuals">active issues</a> in [stringbuf.virtuals].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> <p><b>Discussion:</b></p> @@ -16462,7 +16543,6 @@ paragraph 14 to "ios_base". <h3><a name="376"></a>376. basic_streambuf semantics</h3> <p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-08-14</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#stringbuf.virtuals">active issues</a> in [stringbuf.virtuals].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> <p><b>Discussion:</b></p> @@ -17025,13 +17105,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.1.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.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> <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.1.1 [allocator.members] allocator members, contains +20.6.5.1 [allocator.members] allocator members, contains the following 3 lines: </p> @@ -17143,7 +17223,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.1.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.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> <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> @@ -17151,13 +17231,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.1.1 [allocator.members] and in par2 (table 32) of [default.con.req]. +20.6.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.1.1 [allocator.members] contains the following 3 lines:</p> +<p>20.6.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); @@ -17278,7 +17358,7 @@ Throws: Shall not throw exceptions. <hr> <h3><a name="404"></a>404. May a replacement allocation function be declared inline?</h3> -<p><b>Section:</b> 17.4.3.4 [replacement.functions], 18.5.1 [new.delete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> +<p><b>Section:</b> 17.4.3.5 [replacement.functions], 18.5.1 [new.delete] <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> 2003-04-24</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> @@ -17292,7 +17372,7 @@ in preference to the implementation's definition. <p> Three different parts of the standard mention requirements on -replacement functions: 17.4.3.4 [replacement.functions], 18.5.1.1 [new.delete.single] +replacement functions: 17.4.3.5 [replacement.functions], 18.5.1.1 [new.delete.single] and 18.5.1.2 [new.delete.array], and 3.7.2 [basic.stc.auto]. </p> @@ -17310,7 +17390,7 @@ and 18.5.1.2 [new.delete.array], and 3.7.2 [basic.stc.auto]. <p><b>Proposed resolution:</b></p> <p> -Add a new sentence to the end of 17.4.3.4 [replacement.functions] paragraph 3: +Add a new sentence to the end of 17.4.3.5 [replacement.functions] paragraph 3: "The program's definitions shall not be specified as <tt>inline</tt>. No diagnostic is required." </p> @@ -17367,7 +17447,7 @@ type." <hr> <h3><a name="406"></a>406. vector::insert(s) exception safety</h3> -<p><b>Section:</b> 23.2.5.4 [vector.modifiers] <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.2.6.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2003-04-27</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.modifiers">issues</a> in [vector.modifiers].</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> @@ -17384,7 +17464,7 @@ existing implementation. <p><b>Proposed resolution:</b></p> -<p>Replace 23.2.5.4 [vector.modifiers] paragraph 1 with:</p> +<p>Replace 23.2.6.4 [vector.modifiers] paragraph 1 with:</p> <blockquote><p> 1- Notes: Causes reallocation if the new size is greater than the old capacity. If no reallocation happens, all the iterators and @@ -17522,22 +17602,22 @@ flags.]</i></p> <hr> <h3><a name="410"></a>410. Missing semantics for stack and queue comparison operators</h3> -<p><b>Section:</b> 23.2.3.1 [list.cons], 23.2.3.3 [list.modifiers] <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.2.4.1 [list.cons], 23.2.4.3 [list.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Hans Bos <b>Date:</b> 2003-06-07</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.cons">issues</a> in [list.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> <p> -Sections 23.2.3.1 [list.cons] and 23.2.3.3 [list.modifiers] list +Sections 23.2.4.1 [list.cons] and 23.2.4.3 [list.modifiers] list comparison operators (==, !=, <, <=, >, =>) for queue and -stack. Only the semantics for queue::operator== (23.2.3.1 [list.cons] par2) and queue::operator< (23.2.3.1 [list.cons] +stack. Only the semantics for queue::operator== (23.2.4.1 [list.cons] par2) and queue::operator< (23.2.4.1 [list.cons] par3) are defined. </p> <p><b>Proposed resolution:</b></p> -<p>Add the following new paragraphs after 23.2.3.1 [list.cons] +<p>Add the following new paragraphs after 23.2.4.1 [list.cons] paragraph 3:</p> <blockquote> @@ -17560,7 +17640,7 @@ par3) are defined. </blockquote> -<p>Add the following paragraphs at the end of 23.2.3.3 [list.modifiers]:</p> +<p>Add the following paragraphs at the end of 23.2.4.3 [list.modifiers]:</p> <blockquote> @@ -17728,7 +17808,7 @@ then the caught exception is rethrown. <hr> <h3><a name="414"></a>414. Which iterators are invalidated by v.erase()?</h3> -<p><b>Section:</b> 23.2.5.4 [vector.modifiers] <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.2.6.4 [vector.modifiers] <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> 2003-08-19</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.modifiers">issues</a> in [vector.modifiers].</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> @@ -17783,7 +17863,7 @@ techniques.) <p><b>Proposed resolution:</b></p> <p> -In 23.2.5.4 [vector.modifiers] paragraph 3, change "Invalidates all the +In 23.2.6.4 [vector.modifiers] paragraph 3, change "Invalidates all the iterators and references after the point of the erase" to "Invalidates iterators and references at or after the point of the erase". @@ -17946,7 +18026,7 @@ allowed to just declare it without providing a full definition? <hr> <h3><a name="422"></a>422. explicit specializations of member functions of class templates</h3> -<p><b>Section:</b> 17.4.3.1 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> +<p><b>Section:</b> 17.4.3.2 [reserved.names] <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#reserved.names">issues</a> in [reserved.names].</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> @@ -17966,7 +18046,7 @@ the program) by relying on the "as if" rule. <p><b>Proposed resolution:</b></p> <p> - Add the following sentence to 17.4.3.1 [reserved.names], p1: + Add the following sentence to 17.4.3.2 [reserved.names], p1: </p> <blockquote><p> @@ -18014,7 +18094,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.3 [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.6.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> @@ -18160,7 +18240,6 @@ which is most likely not the intent. <h3><a name="432"></a>432. stringbuf::overflow() makes only one write position available</h3> <p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Christian W Brock <b>Date:</b> 2003-09-24</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#stringbuf.virtuals">active issues</a> in [stringbuf.virtuals].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> <p><b>Discussion:</b></p> @@ -19303,7 +19382,6 @@ undefined." <h3><a name="453"></a>453. basic_stringbuf::seekoff need not always fail for an empty stream</h3> <p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#stringbuf.virtuals">active issues</a> in [stringbuf.virtuals].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> <p><b>Discussion:</b></p> @@ -19529,6 +19607,7 @@ 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> @@ -19703,7 +19782,7 @@ An implementation may also accept additional implementation-defined formats. <hr> <h3><a name="464"></a>464. Suggestion for new member functions in standard containers</h3> -<p><b>Section:</b> 23.2.5 [vector], 23.3.1 [map] <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.2.6 [vector], 23.3.1 [map] <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> 2004-05-12</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#WP">WP</a> status.</p> @@ -19733,14 +19812,14 @@ at() (which will then throw if the vector is empty). </li> <p><b>Proposed resolution:</b></p> -<p>In 23.2.5 [vector], add the following to the <tt>vector</tt> +<p>In 23.2.6 [vector], add the following to the <tt>vector</tt> synopsis after "element access" and before "modifiers":</p> <pre> // <i>[lib.vector.data] data access</i> pointer data(); const_pointer data() const; </pre> -<p>Add a new subsection of 23.2.5 [vector]:</p> +<p>Add a new subsection of 23.2.6 [vector]:</p> <blockquote> <p>23.2.4.x <tt>vector</tt> data access</p> <pre> pointer data(); @@ -19954,7 +20033,7 @@ the value need not be valid. <hr> <h3><a name="469"></a>469. vector<bool> ill-formed relational operators</h3> -<p><b>Section:</b> 23.2.5 [vector] <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.2.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</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#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#DR">DR</a> status.</p> @@ -20321,13 +20400,13 @@ requirements of charT (described in 21 [strings]). <hr> <h3><a name="496"></a>496. Illegal use of "T" in vector<bool></h3> -<p><b>Section:</b> 23.2.5 [vector] <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.2.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> richard@ex-parrot.com <b>Date:</b> 2005-02-10</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#WP">WP</a> status.</p> <p><b>Discussion:</b></p> <p> -In the synopsis of the std::vector<bool> specialisation in 23.2.5 [vector], +In the synopsis of the std::vector<bool> specialisation in 23.2.6 [vector], the non-template assign() function has the signature</p> <pre> void assign( size_type n, const T& t ); @@ -20493,6 +20572,7 @@ Precondition: <tt>distribution().operator()(e,value)</tt> is well-formed. <h3><a name="508"></a>508. Bad parameters for ranlux64_base_01</h3> <p><b>Section:</b> 26.4.5 [rand.predef], TR1 5.1.5 [tr.rand.predef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Walter Brown <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#rand.predef">issues</a> in [rand.predef].</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> @@ -20800,6 +20880,98 @@ 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> + <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> +<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 original bind proposal gives the guarantee that tr1::bind(f, t1, +..., tN) does not throw when the copy constructors of f, t1, ..., tN +don't. +</p> + +<p> +This guarantee is not present in the final version of TR1. +</p> + +<p> +I'm pretty certain that we never removed it on purpose. Editorial omission? :-) +</p> + +<p><i>[ +Berlin: not quite editorial, needs proposed wording. +]</i></p> + +<p><i>[ +Batavia: Doug to translate wording to variadic templates. +]</i></p> + + +<p><i>[ +Toronto: We agree but aren't quite happy with the wording. The "t"'s no +longer refer to anything. Alan to provide improved wording. +]</i></p> + + + +<p><i>[ +Pre-Bellevue: Alisdair provided wording. +]</i></p> + + +<p> +TR1 proposed resolution: +</p> + +<blockquote> +<p> +In TR1 3.6.3 [tr.func.bind.bind], add a new paragraph after p2: +</p> +<blockquote><p> +<i>Throws:</i> Nothing unless one of the copy constructors of <tt>f, t1, t2, ..., tN</tt> +throws an exception. +</p></blockquote> + +<p> +Add a new paragraph after p4: +</p> +<blockquote><p> +<i>Throws:</i> nothing unless one of the copy constructors of <tt>f, t1, t2, ..., tN</tt> +throws an exception. +</p></blockquote> + +</blockquote> + + + +<p><b>Proposed resolution:</b></p> +<p> +In 20.5.11.1.3 [func.bind.bind], add a new paragraph after p2: +</p> + +<blockquote> +<i>Throws:</i> Nothing unless the copy constructor of <tt>F</tt> or of one of the types +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: +</p> + +<blockquote> +<i>Throws:</i> Nothing unless the copy constructor of <tt>F</tt> or of one of the types +in the <tt>BoundArgs...</tt> pack expansion throws an exception. +</blockquote> + + + + + + +<hr> <h3><a name="530"></a>530. Must elements of a string be contiguous?</h3> <p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 2005-11-15</p> @@ -20931,7 +21103,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.6.2.11 [util.smartptr.getdeleter], TR1 2.2.3.10 [tr.util.smartptr.getdeleter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> +<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> <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> @@ -21256,7 +21428,7 @@ Otherwise CopyConstructible is not required. <hr> <h3><a name="540"></a>540. shared_ptr<void>::operator*()</h3> -<p><b>Section:</b> 20.6.6.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.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> <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> @@ -21314,7 +21486,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.6.2 [util.smartptr.shared], TR1 2.2.3 [tr.util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> +<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> <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> @@ -21395,7 +21567,7 @@ public: <hr> <h3><a name="542"></a>542. shared_ptr observers</h3> -<p><b>Section:</b> 20.6.6.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.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> <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> @@ -21435,7 +21607,7 @@ capture the intent. <p><b>Proposed resolution:</b></p> <p> -Change 20.6.6.2.5 [util.smartptr.shared.obs] p12: +Change 20.6.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 @@ -21443,7 +21615,7 @@ debugging and testing purposes, not for production code.</del> --<i>end note</i> </p></blockquote> <p> -Change 20.6.6.3.5 [util.smartptr.weak.obs] p3: +Change 20.6.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 @@ -21532,7 +21704,7 @@ lengths, and strides, as explained in the previous section. <hr> <h3><a name="545"></a>545. When is a deleter deleted?</h3> -<p><b>Section:</b> 20.6.6.2.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.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> <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> @@ -21550,7 +21722,7 @@ instances). We should say which it is. <p><b>Proposed resolution:</b></p> <p> -Add after the first sentence of 20.6.6.2.11 [util.smartptr.getdeleter]/1: +Add after the first sentence of 20.6.12.2.11 [util.smartptr.getdeleter]/1: </p> <blockquote> <p> @@ -21746,6 +21918,325 @@ automatically. <hr> +<h3><a name="561"></a>561. inserter overly generic</h3> +<p><b>Section:</b> 24.4.2.6.5 [inserter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-02-21</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The declaration of <tt>std::inserter</tt> is: +</p> + +<blockquote><pre>template <class Container, class Iterator> +insert_iterator<Container> +inserter(Container& x, Iterator i); +</pre></blockquote> + +<p> +The template parameter <tt>Iterator</tt> in this function is completely unrelated +to the template parameter <tt>Container</tt> when it doesn't need to be. This +causes the code to be overly generic. That is, any type at all can be deduced +as <tt>Iterator</tt>, whether or not it makes sense. Now the same is true of +<tt>Container</tt>. However, for every free (unconstrained) template parameter +one has in a signature, the opportunity for a mistaken binding grows geometrically. +</p> + +<p> +It would be much better if <tt>inserter</tt> had the following signature instead: +</p> + +<blockquote><pre>template <class Container> +insert_iterator<Container> +inserter(Container& x, typename Container::iterator i); +</pre></blockquote> + +<p> +Now there is only one free template parameter. And the second argument to +<tt>inserter</tt> must be implicitly convertible to the container's iterator, +else the call will not be a viable overload (allowing other functions in the +overload set to take precedence). Furthermore, the first parameter must have a +nested type named <tt>iterator</tt>, or again the binding to <tt>std::inserter</tt> +is not viable. Contrast this with the current situation +where any type can bind to <tt>Container</tt> or <tt>Iterator</tt> and those +types need not be anything closely related to containers or iterators. +</p> + +<p> +This can adversely impact well written code. Consider: +</p> + +<blockquote><pre>#include <iterator> +#include <string> + +namespace my +{ + +template <class String> +struct my_type {}; + +struct my_container +{ +template <class String> +void push_back(const my_type<String>&); +}; + +template <class String> +void inserter(const my_type<String>& m, my_container& c) {c.push_back(m);} + +} // my + +int main() +{ + my::my_container c; + my::my_type<std::string> m; + inserter(m, c); +} +</pre></blockquote> + +<p> +Today this code fails because the call to <tt>inserter</tt> binds to +<tt>std::inserter</tt> instead of to <tt>my::inserter</tt>. However with the +proposed change <tt>std::inserter</tt> will no longer be a viable function which +leaves only <tt>my::inserter</tt> in the overload resolution set. Everything +works as the client intends. +</p> + +<p> +To make matters a little more insidious, the above example works today if you +simply change the first argument to an rvalue: +</p> + +<blockquote><pre> inserter(my::my_type(), c); +</pre></blockquote> + +<p> +It will also work if instantiated with some string type other than +<tt>std::string</tt> (or any other <tt>std</tt> type). It will also work if +<tt><iterator></tt> happens to not get included. +</p> + +<p> +And it will fail again for such inocuous reaons as <tt>my_type</tt> or +<tt>my_container</tt> privately deriving from any <tt>std</tt> type. +</p> + +<p> +It seems unfortunate that such simple changes in the client's code can result +in such radically differing behavior. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change 24.2: +</p> + +<blockquote><p> +<b>24.2 Header</b> <tt><iterator></tt> <b>synopsis</b> +</p> +<blockquote><pre>... +template <class Container<del>, class Iterator</del>> + insert_iterator<Container> inserter(Container& x, <del>Iterator</del> <ins>typename Container::iterator</ins> i); +... +</pre></blockquote> +</blockquote> + +<p> +Change 24.4.2.5: +</p> + +<blockquote><p> +<b>24.4.2.5 Class template</b> <tt>insert_iterator</tt></p> +<blockquote><pre>... +template <class Container<del>, class Iterator</del>> + insert_iterator<Container> inserter(Container& x, <del>Iterator</del> <ins>typename Container::iterator</ins> i); +... +</pre></blockquote> +</blockquote> + +<p> +Change 24.4.2.6.5: +</p> + +<blockquote> +<p> +<b>24.4.2.6.5</b> <tt>inserter</tt> +</p> +<pre>template <class Container<del>, class Inserter</del>> + insert_iterator<Container> inserter(Container& x, <del>Inserter</del> <ins>typename Container::iterator</ins> i); +</pre> +<blockquote><p> +-1- <i>Returns:</i> <tt>insert_iterator<Container>(x,<del>typename Container::iterator(</del>i<del>)</del>)</tt>. +</p></blockquote> +</blockquote> + + + +<p><i>[ +Kona (2007): This issue will probably be addressed as a part of the +concepts overhaul of the library anyway, but the proposed resolution is +correct in the absence of concepts. Proposed Disposition: Ready +]</i></p> + + + + + +<hr> +<h3><a name="562"></a>562. stringbuf ctor inefficient</h3> +<p><b>Section:</b> 27.7 [string.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.streams">issues</a> in [string.streams].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +For better efficiency, the requirement on the stringbuf ctor that +takes a string argument should be loosened up to let it set +<code>epptr()</code> beyond just one past the last initialized +character just like <code>overflow()</code> has been changed to be +allowed to do (see issue 432). That way the first call to +<code>sputc()</code> on an object won't necessarily cause a call to +<code>overflow</code>. The corresponding change should be made to the +string overload of the <code>str()</code> member function. + + </p> + + +<p><b>Proposed resolution:</b></p> + <p> + +Change 27.7.1.1, p3 of the Working Draft, N1804, as follows: + + </p> + +<blockquote><pre>explicit basic_stringbuf(const basic_string<charT,traits,Allocator>& <i>s<del>tr</del></i>, + ios_base::openmode <i>which</i> = ios_base::in | ios_base::out); +</pre> + +<p> +-3- <i>Effects:</i> Constructs an object of class <tt>basic_stringbuf</tt>, +initializing the base class with <tt>basic_streambuf()</tt> +(27.5.2.1), and initializing <tt><i>mode</i></tt> with <tt><i>which</i></tt>. +Then <ins>calls <tt>str(<i>s</i>)</tt>.</ins> <del>copies the content of +<i>str</i> into the <tt>basic_stringbuf</tt> underlying character +sequence. If <tt><i>which</i> & ios_base::out</tt> is true, initializes the +output sequence such that <tt>pbase()</tt> points to the first underlying +character, <tt>epptr()</tt> points one past the last underlying character, and +<tt>pptr()</tt> is equal to <tt>epptr()</tt> if <tt><i>which</i> & ios_base::ate</tt> +is true, otherwise <tt>pptr()</tt> is equal to <tt>pbase()</tt>. If +<tt>which & ios_base::in</tt> is true, initializes the input sequence such +that <tt>eback()</tt> and <tt>gptr()</tt> point to the first underlying +character and <tt>egptr()</tt> points one past the last underlying character.</del> +</p> +</blockquote> + + <p> + +Change the Effects clause of the <code>str()</code> in 27.7.1.2, p2 to +read: + + </p> +<blockquote> +<p> +-2- <i>Effects:</i> Copies the content<ins>s</ins> of <tt><i>s</i></tt> into the +<tt>basic_stringbuf</tt> underlying character sequence <ins>and +initializes the input and output sequences according to <tt><i>mode</i></tt></ins>. +<del>If +<tt><i>mode</i> & ios_base::out</tt> is true, initializes the output +sequence such that <tt>pbase()</tt> points to the first underlying character, +<tt>epptr()</tt> points one past the last underlying character, and <tt>pptr()</tt> +is equal to <tt>epptr()</tt> if <tt><i>mode</i> & ios_base::in</tt> +is true, otherwise <tt>pptr()</tt> is equal to <tt>pbase()</tt>. If +<tt>mode & ios_base::in</tt> is true, initializes the input sequence +such that <tt>eback()</tt> and <tt>gptr()</tt> point to the first underlying +character and <tt>egptr()</tt> points one past the last underlying character.</del> +</p> + + <p> + +<ins>-3- <i>Postconditions:</i> If <code>mode & ios_base::out</code> is true, +<code>pbase()</code> points to the first underlying character and +<code>(epptr() >= pbase() + s.size())</code> holds; in addition, if +<code>mode & ios_base::in</code> is true, <code>(pptr() == pbase() ++ s.data())</code> holds, otherwise <code>(pptr() == pbase())</code> +is true. If <code>mode & ios_base::in</code> is true, +<code>eback()</code> points to the first underlying character, and +<code>(gptr() == eback())</code> and <code>(egptr() == eback() + +s.size())</code> hold.</ins> + + </p> +</blockquote> + + +<p><i>[ +Kona (2007) Moved to Ready. +]</i></p> + + + + + +<hr> +<h3><a name="563"></a>563. stringbuf seeking from end</h3> +<p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +According to Table 92 (unchanged by issue 432), when <code>(way == +end)</code> the <code>newoff</code> value in out mode is computed as +the difference between <code>epptr()</code> and <code>pbase()</code>. +</p> + <p> + +This value isn't meaningful unless the value of <code>epptr()</code> +can be precisely controlled by a program. That used to be possible +until we accepted the resolution of issue 432, but since then the +requirements on <code>overflow()</code> have been relaxed to allow it +to make more than 1 write position available (i.e., by setting +<code>epptr()</code> to some unspecified value past +<code>pptr()</code>). So after the first call to +<code>overflow()</code> positioning the output sequence relative to +end will have unspecified results. + + </p> + <p> + +In addition, in <code>in|out</code> mode, since <code>(egptr() == +epptr())</code> need not hold, there are two different possible values +for <code>newoff</code>: <code>epptr() - pbase()</code> and +<code>egptr() - eback()</code>. + + </p> + + +<p><b>Proposed resolution:</b></p> + <p> + +Change the <code>newoff</code> column in the last row of Table 94 to +read: + + </p> +<blockquote><p> + +the <del>end</del> <ins>high mark</ins> pointer minus the beginning +pointer (<code><del>xend</del> <ins>high_mark</ins> - xbeg</code>). + +</p></blockquote> + + +<p><i>[ +Kona (2007) Moved to Ready. +]</i></p> + + + + + +<hr> <h3><a name="566"></a>566. array forms of unformatted input function undefined for zero-element arrays</h3> <p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p> @@ -21818,8 +22309,75 @@ location of the array. <hr> +<h3><a name="567"></a>567. streambuf inserter and extractor should be unformatted</h3> +<p><b>Section:</b> 27.6 [iostream.format] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-25</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.format">issues</a> in [iostream.format].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +Issue 60 explicitly made the extractor and inserter operators that +take a <tt>basic_streambuf*</tt> argument formatted input and output +functions, respectively. I believe that's wrong, certainly in the +case of the extractor, since formatted functions begin by extracting +and discarding whitespace. The extractor should not discard any +characters. + + </p> + + +<p><b>Proposed resolution:</b></p> + <p> + +I propose to change each operator to behave as unformatted input and +output function, respectively. The changes below are relative to the +working draft document number N1804. + + </p> + <p> + +Specifically, change 27.6.1.2.3, p14 as follows: + + </p> + + <blockquote> + <p> + +<i>Effects</i>: Behaves as a<ins>n un</ins>formatted input function +(as described in <del>27.6.1.2.1</del><ins>27.6.1.3, paragraph +1</ins>). + + </p> + </blockquote> + <p> + +And change 27.6.2.5.3, p7 as follows: + + </p> + + <blockquote> + <p> + +<i>Effects</i>: Behaves as a<ins>n un</ins>formatted output function +(as described in <del>27.6.2.5.1</del><ins>27.6.2.6, paragraph +1</ins>). + + </p> + </blockquote> + + +<p><i>[ +Kona (2007): Proposed Disposition: Ready +]</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.6.2.2 [util.smartptr.shared.dest], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> +<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> <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> @@ -22000,7 +22558,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.1.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.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> <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> @@ -22058,6 +22616,70 @@ adjacent element is often a good choice to pass for this argument.</del> <hr> +<h3><a name="581"></a>581. <code>flush()</code> not unformatted function</h3> +<p><b>Section:</b> 27.6.2.7 [ostream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-14</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.unformatted">issues</a> in [ostream.unformatted].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +The resolution of issue 60 changed <code>basic_ostream::flush()</code> +so as not to require it to behave as an unformatted output function. +That has at least two in my opinion problematic consequences: + + </p> + <p> + +First, <code>flush()</code> now calls <code>rdbuf()->pubsync()</code> +unconditionally, without regard to the state of the stream. I can't +think of any reason why <code>flush()</code> should behave differently +from the vast majority of stream functions in this respect. + + </p> + <p> + +Second, <code>flush()</code> is not required to catch exceptions from +<code>pubsync()</code> or set <code>badbit</code> in response to such +events. That doesn't seem right either, as most other stream functions +do so. + + </p> + + + <p><b>Proposed resolution:</b></p> + <p> + +I propose to revert the resolution of issue 60 with respect to +<code>flush()</code>. Specifically, I propose to change 27.6.2.6, p7 +as follows: + + </p> + +<p> +Effects: <ins>Behaves as an unformatted output function (as described +in 27.6.2.6, paragraph 1). </ins>If <code>rdbuf()</code> is not a null +pointer, <ins>constructs a sentry object. If this object returns +<code>true</code> when converted to a value of type bool the function +</ins>calls <code>rdbuf()->pubsync()</code>. If that function returns +-1 calls <code>setstate(badbit)</code> (which may throw +<code>ios_base::failure</code> (27.4.4.3)). <ins>Otherwise, if the +sentry object returns <code>false</code>, does nothing.</ins><del>Does +not behave as an unformatted output function (as described in +27.6.2.6, paragraph 1).</del> +</p> + + + +<p><i>[ +Kona (2007): Proposed Disposition: Ready +]</i></p> + + + + + +<hr> <h3><a name="586"></a>586. string inserter not a formatted function</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#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-22</p> @@ -22784,10 +23406,11 @@ floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>d <hr> <h3><a name="607"></a>607. Concern about short seed vectors</h3> -<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">Pending WP</a> +<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> Charles Karney <b>Date:</b> 2006-10-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20WP">Pending WP</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> <p><b>Discussion:</b></p> <p> Short seed vectors of 32-bit quantities all result in different states. However @@ -22835,10 +23458,11 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a <hr> <h3><a name="608"></a>608. Unclear seed_seq construction details</h3> -<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">Pending WP</a> +<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> Charles Karney <b>Date:</b> 2006-10-26</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20WP">Pending WP</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> <p><b>Discussion:</b></p> <p> In 26.4.7.1 [rand.util.seedseq] /6, the order of packing the inputs into b and the @@ -22977,7 +23601,7 @@ function pointer (a "bound member function").</ins> <hr> <h3><a name="611"></a>611. Standard library templates and incomplete types</h3> -<p><b>Section:</b> 17.4.3.6 [res.on.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> +<p><b>Section:</b> 17.4.3.7 [res.on.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Nicola Musatti <b>Date:</b> 2006-11-13</p> <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> <p><b>Discussion:</b></p> @@ -23225,6 +23849,498 @@ undefined behavior if replacing the <tt>setjmp</tt> and <tt>longjmp</tt> by <hr> +<h3><a name="620"></a>620. valid uses of empty valarrays</h3> +<p><b>Section:</b> 26.5.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#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> + <p> + +The <i>Effects</i> clause for the default <code>valarray</code> ctor +suggests that it is possible to increase the size of an empty +<code>valarray</code> object by calling other non-const member +functions of the class besides <code>resize()</code>. However, such an +interpretation would be contradicted by the requirement on the copy +assignment operator (and apparently also that on the computed +assignments) that the assigned arrays be the same size. See the +reflector discussion starting with c++std-lib-17871. + + </p> + <p> + +In addition, <i>Footnote</i> 280 uses some questionable normative +language. + + </p> + + +<p><b>Proposed resolution:</b></p> + <p> + +Reword the <i>Effects</i> clause and <i>Footnote 280</i> as follows (26.5.2.1 [valarray.cons]): + + </p> + <blockquote> + <p> + +<code>valarray();</code> + + </p> + <p> + +<i>Effects</i>: Constructs an object of class +<code>valarray<T></code>,<sup>279)</sup> which has zero +length<del> until it is passed into a library function as a modifiable +lvalue or through a non-constant this pointer</del>.<sup>280)</sup> + + </p> + <p> + +<ins><i>Postcondition</i>: <code>size() == 0</code>.</ins> + + </p> + <p> + +<i>Footnote 280</i>: This default constructor is essential, since +arrays of <code>valarray</code> <del>are likely to prove useful. +There shall also be a way to change the size of an array after +initialization; this is supplied by the semantics</del> <ins>may be +useful. The length of an empty array can be increased after +initialization by means</ins> of the <code>resize()</code> member +function. + + </p> + </blockquote> + + + + + +<hr> +<h3><a name="621"></a>621. non-const copy assignment operators of helper arrays</h3> +<p><b>Section:</b> 26.5 [numarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numarray">issues</a> in [numarray].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +The computed and "fill" assignment operators of <code>valarray</code> +helper array class templates (<code>slice_array</code>, +<code>gslice_array</code>, <code>mask_array</code>, and +<code>indirect_array</code>) are const member functions of each class +template (the latter by the resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#123">123</a> +since they have reference semantics and thus do not affect +the state of the object on which they are called. However, the copy +assignment operators of these class templates, which also have +reference semantics, are non-const. The absence of constness opens +the door to speculation about whether they really are intended to have +reference semantics (existing implementations vary widely). + + </p> + +<p> +Pre-Kona, Martin adds: +</p> + +<p> +I realized that adding the const qualifier to the +functions as I suggested would break the const correctness of the +classes. A few possible solutions come to mind: +</p> + +<ol> +<li>Add the const qualifier to the return types of these functions.</li> +<li>Change the return type of all the functions to void to match +the signatures of all the other assignment operators these classes +define.</li> +<li>Prohibit the copy assignment of these classes by declaring the +copy assignment operators private (as is done and documented by +some implementations).</li> +</ol> + + + +<p><b>Proposed resolution:</b></p> + <p> + +Declare the copy assignment operators of all four helper array +class templates const. + + </p> + <p> + +Specifically, make the following edits: + + </p> + <p> + +Change the signature in 26.5.5 [template.slice.array] and +26.5.5.1 [slice.arr.assign] as follows: + + </p> + <blockquote><pre> +<code><ins>const</ins> slice_array& operator= (const slice_array&)<ins> const</ins>;</code> + + </pre></blockquote> + <p> + +Change the signature in 26.5.7 [template.gslice.array] and +26.5.7.1 [gslice.array.assign] as follows: + + </p> + <blockquote><pre> +<code><ins>const</ins> gslice_array& operator= (const gslice_array&)<ins> const</ins>;</code> + + </pre></blockquote> + <p> + +Change the signature in 26.5.8 [template.mask.array] and 26.5.8.1 [mask.array.assign] as +follows: + + </p> + <blockquote><pre> +<code><ins>const</ins> mask_array& operator= (const mask_array&)<ins> const</ins>;</code> + + </pre></blockquote> + <p> + +Change the signature in 26.5.9 [template.indirect.array] and +26.5.9.1 [indirect.array.assign] as follows: + + </p> + <blockquote><pre> +<code><ins>const</ins> indirect_array& operator= (const indirect_array&)<ins> const</ins>;</code> + + </pre></blockquote> + + +<p><i>[ +Kona (2007) Added const qualification to the return types and set to Ready. +]</i></p> + + + + + +<hr> +<h3><a name="622"></a>622. behavior of <code>filebuf</code> dtor and <code>close</code> on error</h3> +<p><b>Section:</b> 27.8.1.17 [fstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +<code>basic_filebuf</code> dtor is specified to have the following +straightforward effects: + + </p> + <blockquote><p> + +<i>Effects</i>: Destroys an object of class +<code>basic_filebuf</code>. Calls <code>close()</code>. + + </p></blockquote> + <p> + +<code>close()</code> does a lot of potentially complicated processing, +including calling <code>overflow()</code> to write out the termination +sequence (to bring the output sequence to its initial shift +state). Since any of the functions called during the processing can +throw an exception, what should the effects of an exception be on the +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]. + + </p> + <p> + +Further, the last thing <code>close()</code> is specified to do is +call <code>fclose()</code> to close the <code>FILE</code> pointer. The +last sentence of the <i>Effects</i> clause reads: + + </p> + <blockquote><p> + +... If any of the calls to <code>overflow</code> or +<code>std::fclose</code> fails then <code>close</code> fails. + + </p></blockquote> + <p> + +This suggests that <code>close()</code> might be required to call +<code>fclose()</code> if and only if none of the calls to +<code>overflow()</code> fails, and avoid closing the <code>FILE</code> +otherwise. This way, if <code>overflow()</code> failed to flush out +the data, the caller would have the opportunity to try to flush it +again (perhaps after trying to deal with whatever problem may have +caused the failure), rather than losing it outright. + + </p> + <p> + +On the other hand, the function's <i>Postcondition</i> specifies that +<code>is_open() == false</code>, which suggests that it should call +<code>fclose()</code> unconditionally. However, since +<i>Postcondition</i> clauses are specified for many functions in the +standard, including constructors where they obviously cannot apply +after an exception, it's not clear whether this <i>Postcondition</i> +clause is intended to apply even after an exception. + + </p> + <p> + +It might be worth noting that the traditional behavior (Classic +Iostreams <code>fstream::close()</code> and C <code>fclose()</code>) +is to close the <code>FILE</code> unconditionally, regardless of +errors. + + </p> + +<p><i>[ +See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#397">397</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#418">418</a> for related issues. +]</i></p> + + + + +<p><b>Proposed resolution:</b></p> + <p> + +After discussing this on the reflector (see the thread starting with +c++std-lib-17650) we propose that <code>close()</code> be clarified to +match the traditional behavior, that is to close the <code>FILE</code> +unconditionally, even after errors or exceptions. In addition, we +propose the dtor description be amended so as to explicitly require it +to catch and swallow any exceptions thrown by <code>close()</code>. + + </p> + <p> + +Specifically, we propose to make the following edits in +27.8.1.4 [filebuf.members]: + + </p> + <blockquote> + <pre> +<code>basic_filebuf<charT,traits>* close();</code> + + </pre> + <p> + +<i>Effects</i>: If <code>is_open() == false</code>, returns a null +pointer. If a put area exists, calls +<code>overflow(traits::eof())</code> to flush characters. If the last +virtual member function called on <code>*this</code> (between +<code>underflow</code>, <code>overflow</code>, <code>seekoff</code>, +and <code>seekpos</code>) was <code>overflow</code> then calls +<code>a_codecvt.unshift</code> (possibly several times) to determine a +termination sequence, inserts those characters and calls +<code>overflow(traits::eof())</code> again. Finally<ins>, regardless +of whether any of the preceding calls fails or throws an exception, +the function</ins> <del>it</del> closes the file ("as if" by calling +<code>std::fclose(file)</code>).<sup>334)</sup> If any of the calls +<ins>made by the function</ins><del>to <code>overflow</code> +or</del><ins>, including </ins><code>std::fclose</code><ins>, </ins> +fails then <code>close</code> fails<ins> by returning a null pointer. +If one of these calls throws an exception, the exception is caught and +rethrown after closing the file.</ins> + + </p> + </blockquote> + <p> + +And to make the following edits in 27.8.1.2 [filebuf.cons]. + + </p> + <blockquote> + <pre> +<code>virtual ~basic_filebuf();</code> + + </pre> + <p> + +<i>Effects</i>: Destroys an object of class +<code>basic_filebuf<charT,traits></code>. Calls +<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> + + </p> + </blockquote> + + + + + +<hr> +<h3><a name="623"></a>623. <code>pubimbue</code> forbidden to call <code>imbue</code></h3> +<p><b>Section:</b> 27.1.1 [iostream.limits.imbue] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +27.1.1 [iostream.limits.imbue] specifies that "no function described in +clause 27 except for <code>ios_base::imbue</code> causes any instance +of <code>basic_ios::imbue</code> or +<code>basic_streambuf::imbue</code> to be called." + + </p> + <p> + +That contradicts the <i>Effects</i> clause for +<code>basic_streambuf::pubimbue()</code> which requires the function +to do just that: call <code>basic_streambuf::imbue()</code>. + + </p> + + +<p><b>Proposed resolution:</b></p> + <p> + +To fix this, rephrase the sentence above to allow +<code>pubimbue</code> to do what it was designed to do. Specifically. +change 27.1.1 [iostream.limits.imbue], p1 to read: + + </p> + <blockquote><p> + +No function described in clause 27 except for +<code>ios_base::imbue</code> <ins>and <code>basic_filebuf::pubimbue</code></ins> +causes any instance of <code>basic_ios::imbue</code> or +<code>basic_streambuf::imbue</code> to be called. ... + + </p></blockquote> + + + + + +<hr> +<h3><a name="624"></a>624. <code>valarray</code> assignment and arrays of unequal length</h3> +<p><b>Section:</b> 26.5.2.2 [valarray.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> + <p> + +The behavior of the <code>valarray</code> copy assignment operator is +defined only when both sides have the same number of elements and the +spec is explicit about assignments of arrays of unequal lengths having +undefined behavior. + + </p> + <p> + +However, the generalized subscripting assignment operators overloaded +on <code>slice_array</code> et al (26.5.2.2 [valarray.assign]) don't have any +such restriction, leading the reader to believe that the behavior of +these overloads is well defined regardless of the lengths of the +arguments. + + </p> + <p> + +For example, based on the reading of the spec the behavior of the +snippet below can be expected to be well-defined: + + </p> + <pre> const std::slice from_0_to_3 (0, 3, 1); // refers to elements 0, 1, 2 + const std::valarray<int> a (1, 3); // a = { 1, 1, 1 } + std::valarray<int> b (2, 4); // b = { 2, 2, 2, 2 } + + b = a [from_0_to_3]; + </pre> + <p> + +In practice, <code>b</code> may end up being <code>{ 1, 1, 1 }</code>, +<code>{ 1, 1, 1, 2 }</code>, or anything else, indicating that +existing implementations vary. + + </p> + +<p> +Quoting from Section 3.4, Assignment operators, of Al Vermeulen's +Proposal for Standard C++ Array Classes (see c++std-lib-704; +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0308.asc">N0308</a>): +</p> +<blockquote><p> + ...if the size of the array on the right hand side of the equal + sign differs from the size of the array on the left, a run time + error occurs. How this error is handled is implementation + dependent; for compilers which support it, throwing an exception + would be reasonable. +</p></blockquote> + +<p> +And see more history in +<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/1993/N0280.pdf">N0280</a>. +</p> + + <p> + +It has been argued in discussions on the committee's reflector that +the semantics of all <code>valarray</code> assignment operators should +be permitted to be undefined unless the length of the arrays being +assigned is the same as the length of the one being assigned from. See +the thread starting at c++std-lib-17786. + + </p> + <p> + +In order to reflect such views, the standard must specify that the +size of the array referred to by the argument of the assignment must +match the size of the array under assignment, for example by adding a +<i>Requires</i> clause to 26.5.2.2 [valarray.assign] as follows: + + </p> + <blockquote><p> + +<i>Requires</i>: The length of the array to which the argument refers +equals <code>size()</code>. + + </p></blockquote> + + <p> + +Note that it's far from clear that such leeway is necessary in order +to implement <code>valarray</code> efficiently. + + </p> + + +<p><b>Proposed resolution:</b></p> +<p> +Insert new paragraph into 26.5.2.2 [valarray.assign]: +</p> + +<blockquote> +<pre>valarray<T>& operator=(const slice_array<T>&); +valarray<T>& operator=(const gslice_array<T>&); +valarray<T>& operator=(const mask_array<T>&); +valarray<T>& operator=(const indirect_array<T>&); +</pre> +<blockquote> +<p><ins> +<i>Requires</i>: The length of the array to which the argument refers +equals <code>size()</code>. +</ins></p> +<p> +These operators allow the results of a generalized subscripting operation to be assigned directly to a <tt>valarray</tt>. +</p> +</blockquote> +</blockquote> + + + + + +<hr> <h3><a name="628"></a>628. Inconsistent definition of basic_regex constructor</h3> <p><b>Section:</b> 28.8 [re.regex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-01-23</p> @@ -23263,7 +24379,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.1.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.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> <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> @@ -23271,7 +24387,7 @@ Change 28.8.2 [re.regex.construct]: <p><b>Discussion:</b></p> <p> -20.6.1.1 [allocator.members] says: +20.6.5.1 [allocator.members] says: </p> <blockquote> <pre>pointer address(reference <i>x</i>) const;</pre> @@ -23283,7 +24399,7 @@ Change 28.8.2 [re.regex.construct]: </blockquote> <p> -20.6.1.1 [allocator.members] defines <tt>CopyConstructible</tt> which currently not +20.6.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 @@ -23314,7 +24430,7 @@ is expected to make use of <tt>allocator::address</tt> mandatory for containers. <p><b>Proposed resolution:</b></p> <p> -Change 20.6.1.1 [allocator.members]: +Change 20.6.5.1 [allocator.members]: </p> <blockquote> @@ -23473,7 +24589,6 @@ A local variable <tt><i>punct</i></tt> is initialized via <h3><a name="644"></a>644. Possible typos in 'function' description</h3> <p><b>Section:</b> X [func.wrap.func.undef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">Pending WP</a> <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-02-25</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20WP">Pending WP</a> status.</p> <p><b>Discussion:</b></p> <p> X [func.wrap.func.undef] @@ -23691,10 +24806,10 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a <hr> <h3><a name="654"></a>654. Missing IO roundtrip for random number engines</h3> -<p><b>Section:</b> 26.4.1.3 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">Pending WP</a> +<p><b>Section:</b> 26.4.1.3 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-08</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req.eng">issues</a> in [rand.req.eng].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20WP">Pending WP</a> status.</p> +<p><b>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> Table 98 and para 5 in 26.4.1.3 [rand.req.eng] specify @@ -23821,10 +24936,10 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a <hr> <h3><a name="655"></a>655. Signature of generate_canonical not useful</h3> -<p><b>Section:</b> 26.4.7.2 [rand.util.canonical] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">Pending WP</a> +<p><b>Section:</b> 26.4.7.2 [rand.util.canonical] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-08</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.canonical">issues</a> in [rand.util.canonical].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20WP">Pending WP</a> status.</p> +<p><b>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 26.4.2 [rand.synopsis] we have the declaration @@ -23930,11 +25045,348 @@ template <class T> struct bit_xor;</pre> <hr> +<h3><a name="661"></a>661. New 27.6.1.2.2 changes make special extractions useless</h3> +<p><b>Section:</b> 27.6.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-04-01</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +To the more drastic changes of 27.6.1.2.2 [istream.formatted.arithmetic] in the current draft N2134 belong +the explicit description of the extraction of the types short and int in +terms of as-if code fragments. +</p> + +<ol> +<li> +The corresponding as-if extractions in paragraph 2 and 3 will never +result in a change of the operator>> argument val, because the +contents of the local variable lval is in no case written into val. +Furtheron both fragments need a currently missing parentheses in the +beginning of the if-statement to be valid C++. +</li> +<li>I would like to ask whether the omission of a similar explicit +extraction of unsigned short and unsigned int in terms of long - +compared to their corresponding new insertions, as described in +27.6.2.6.2 [ostream.inserters.arithmetic], is a deliberate decision or +an +oversight. +</li> +</ol> + + +<p><b>Proposed resolution:</b></p> +<ol> +<li> +<p> +In 27.6.1.2.2 [istream.formatted.arithmetic]/2 change the current as-if code fragment +</p> +<blockquote><pre>typedef num_get<charT,istreambuf_iterator<charT,traits> > numget; +iostate err = 0; +long lval; +use_facet<numget>(loc).get(*this, 0, *this, err, lval ); +if (err == 0) <ins>{</ins> + <del>&&</del> <ins>if</ins> (lval < numeric_limits<short>::min() || numeric_limits<short>::max() < lval)<del>)</del> + err = ios_base::failbit; + <ins>else + val = static_cast<short>(lval); +}</ins> +setstate(err); +</pre></blockquote> + +<p> +Similarily in 27.6.1.2.2 [istream.formatted.arithmetic]/3 change the current as-if fragment +</p> + +<blockquote><pre>typedef num_get<charT,istreambuf_iterator<charT,traits> > numget; +iostate err = 0; +long lval; +use_facet<numget>(loc).get(*this, 0, *this, err, lval ); +if (err == 0) <ins>{</ins> + <del>&&</del> <ins>if</ins> (lval < numeric_limits<int>::min() || numeric_limits<int>::max() < lval)<del>)</del> + err = ios_base::failbit; + <ins>else + val = static_cast<int>(lval); +}</ins> +setstate(err); +</pre></blockquote> +</li> +<li> +--- +</li> +</ol> + + +<p><i>[ +Kona (2007): Note to the editor: the name lval in the call to <tt>use_facet</tt> +is incorrectly italicized in the code fragments corresponding to +<tt>operator>>(short &)</tt> and <tt>operator >>(int &)</tt>. Also, val -- which appears +twice on the line with the <tt>static_cast</tt> in the proposed resolution -- +should be italicized. Also, in response to part two of the issue: this +is deliberate. +]</i></p> + + + + + +<hr> +<h3><a name="664"></a>664. <tt>do_unshift</tt> for <tt>codecvt<char, char, mbstate_t></tt></h3> +<p><b>Section:</b> 22.2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +22.2.1.4.2 [locale.codecvt.virtuals], para 7 says (regarding <tt>do_unshift</tt>): +</p> + +<blockquote><p> +<i>Effects:</i> Places characters starting at to that should be appended to +terminate a sequence when the current <tt>stateT</tt> is given by +<tt><i>state</i></tt>.<sup>237)</sup> Stores no more than <tt>(<i>to_limit</i> - +<i>to</i>)</tt> destination elements, and leaves the <tt><i>to_next</i></tt> +pointer pointing one beyond the last element successfully stored. +<em><tt>codecvt<char, char, mbstate_t></tt> stores no characters.</em> +</p></blockquote> + +<p> +The following objection has been raised: +</p> + +<blockquote><p> +Since the C++ Standard permits a nontrivial conversion for the required +instantiations of <tt>codecvt</tt>, it is overly restrictive to say that +<tt>do_unshift</tt> must store no characters and return <tt>noconv</tt>. +</p></blockquote> + +<p> +[Plum ref _222152Y50] +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 22.2.1.4.2 [locale.codecvt.virtuals], p7: +</p> + +<blockquote> +<p> +<i>Effects:</i> Places characters starting at <i>to</i> that should be +appended to terminate a sequence when the current <tt>stateT</tt> is +given by state.<sup>237)</sup> Stores no more than (<i>to_limit -to</i>) +destination elements, and leaves the <i>to_next</i> pointer pointing one +beyond the last element successfully stored. <del><tt>codecvt<char, char, +mbstate_t></tt> stores no characters.</del> +</p> +</blockquote> + + + + + +<hr> +<h3><a name="665"></a>665. <tt>do_unshift</tt> return value</h3> +<p><b>Section:</b> 22.2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +22.2.1.4.2 [locale.codecvt.virtuals], para 8 says: +</p> + +<blockquote><p> +<tt>codecvt<char,char,mbstate_t></tt>, returns <tt>noconv</tt>. +</p></blockquote> + +<p> +The following objection has been raised: +</p> + +<blockquote><p> +Despite what the C++ Standard +says, <tt>unshift</tt> can't always return <tt>noconv</tt> for the default facets, since +they can be nontrivial. At least one implementation does whatever the +C functions do. +</p></blockquote> + +<p> +[Plum ref _222152Y62] +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 22.2.1.4.2 [locale.codecvt.virtuals], p8: +</p> + +<blockquote> +<p><i>Returns:</i> An enumeration value, as summarized in Table 76:</p> +<p>...</p> +<p> +<del><tt>codecvt<char,char,mbstate_t></tt>, returns <tt>noconv</tt>.</del> +</p> +</blockquote> + + + + + + +<hr> +<h3><a name="666"></a>666. <tt>moneypunct::do_curr_symbol()</tt></h3> +<p><b>Section:</b> 22.2.6.3.2 [locale.moneypunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.moneypunct.virtuals">issues</a> in [locale.moneypunct.virtuals].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +22.2.6.3.2 [locale.moneypunct.virtuals], para 4 footnote 257 says +</p> + +<blockquote><p> +<sup>257)</sup> For international +specializations (second template parameter <tt>true</tt>) this is always four +characters long, usually three letters and a space. +</p></blockquote> + +<p> +The following objection has been raised: +</p> + +<blockquote><p> +The international currency +symbol is whatever the underlying locale says it is, not necessarily +four characters long. +</p></blockquote> + +<p> +[Plum ref _222632Y41] +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change footnote 253 in 22.2.6.3.2 [locale.moneypunct.virtuals]: +</p> + +<blockquote> +<p> +<sup>253)</sup> For international specializations (second template +parameter <tt>true</tt>) this is <del>always</del> <ins>typically</ins> +four characters long, usually three letters and a space. +</p> +</blockquote> + + + + + +<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> + <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-05</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a> does not propose +any changes to <tt>shared_ptr</tt>. It needs to be updated to use a rvalue reference where appropriate +and to interoperate with <tt>unique_ptr</tt> as it does with <tt>auto_ptr</tt>. +</p> + + +<p><b>Proposed resolution:</b></p> + +<p> +Change 20.6.12.2 [util.smartptr.shared] as follows: +</p> + +<blockquote> +<pre>template<class Y> explicit shared_ptr(auto_ptr<Y><del>&</del><ins>&&</ins> r); +<ins>template<class Y, class D> explicit shared_ptr(const unique_ptr<Y,D>& r) = delete; +template<class Y, class D> explicit shared_ptr(unique_ptr<Y,D>&& r);</ins> +... +template<class Y> shared_ptr& operator=(auto_ptr<Y><del>&</del><ins>&&</ins> r); +<ins>template<class Y, class D> shared_ptr& operator=(const unique_ptr<Y,D>& r) = delete; +template<class Y, class D> shared_ptr& operator=(unique_ptr<Y,D>&& r);</ins></pre> +</blockquote> + +<p> +Change 20.6.12.2.1 [util.smartptr.shared.const] as follows: +</p> + +<blockquote> +<pre><ins>template<class Y> shared_ptr(auto_ptr<Y><del>&</del><ins>&&</ins> r);</ins></pre> +</blockquote> + +<p> +Add to 20.6.12.2.1 [util.smartptr.shared.const]: +</p> + +<blockquote> +<pre><ins>template<class Y, class D> shared_ptr(unique_ptr<Y, D>&& r);</ins></pre> +<blockquote> + +<p><ins> +<i>Effects:</i> Equivalent to <tt>shared_ptr( r.release(), r.get_deleter() )</tt> when <tt>D</tt> is + not a reference type, <tt>shared_ptr( r.release(), ref( r.get_deleter() ) )</tt> + otherwise. +</ins></p> + +<p><ins> +<i>Exception safety:</i> If an exception is thrown, the constructor has no effect. +</ins></p> +</blockquote> + +</blockquote> + +<p> +Change 20.6.12.2.3 [util.smartptr.shared.assign] as follows: +</p> + +<blockquote> +<pre>template<class Y> shared_ptr& operator=(auto_ptr<Y><del>&</del><ins>&&</ins> r);</pre> +</blockquote> + +<p> +Add to 20.6.12.2.3 [util.smartptr.shared.assign]: +</p> + +<blockquote> +<pre><ins>template<class Y, class D> shared_ptr& operator=(unique_ptr<Y,D>&& r);</ins></pre> + +<blockquote> +<p><ins> +-4- <i>Effects:</i> Equivalent to <tt>shared_ptr(std::move(r)).swap(*this)</tt>. +</ins></p> +<p><ins> +-5- <i>Returns:</i> <tt>*this</tt>. +</ins></p> +</blockquote> + +</blockquote> + + + +<p><i>[ +Kona (2007): We may need to open an issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#743">743</a>) to deal with the question of +whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>. +]</i></p> + + + + + +<hr> <h3><a name="677"></a>677. Weaknesses in seed_seq::randomize [rand.util.seedseq]</h3> -<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">Pending WP</a> +<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> Charles Karney <b>Date:</b> 2007-05-15</p> +<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p> <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20WP">Pending WP</a> status.</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> <p><b>Discussion:</b></p> <p> <tt>seed_seq::randomize</tt> provides a mechanism for initializing random number @@ -24089,6 +25541,206 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a <hr> +<h3><a name="679"></a>679. resize parameter by value</h3> +<p><b>Section:</b> 23.2 [sequences] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-06-11</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The C++98 standard specifies that one member function alone of the containers +passes its parameter (<tt>T</tt>) by value instead of by const reference: +</p> + +<blockquote><pre>void resize(size_type sz, T c = T()); +</pre></blockquote> + +<p> +This fact has been discussed / debated repeatedly over the years, the first time +being even before C++98 was ratified. The rationale for passing this parameter by +value has been: +</p> + +<blockquote> +<p> +So that self referencing statements are guaranteed to work, for example: +</p> +<blockquote><pre>v.resize(v.size() + 1, v[0]); +</pre></blockquote> +</blockquote> + +<p> +However this rationale is not convincing as the signature for <tt>push_back</tt> is: +</p> + +<blockquote><pre>void push_back(const T& x); +</pre></blockquote> + +<p> +And <tt>push_back</tt> has similar semantics to <tt>resize</tt> (append). +And <tt>push_back</tt> must also work in the self referencing case: +</p> + +<blockquote><pre>v.push_back(v[0]); // must work +</pre></blockquote> + +<p> +The problem with passing <tt>T</tt> by value is that it can be significantly more +expensive than passing by reference. The converse is also true, however when it is +true it is usually far less dramatic (e.g. for scalar types). +</p> + +<p> +Even with move semantics available, passing this parameter by value can be expensive. +Consider for example <tt>vector<vector<int>></tt>: +</p> + +<blockquote><pre>std::vector<int> x(1000); +std::vector<std::vector<int>> v; +... +v.resize(v.size()+1, x); +</pre></blockquote> + +<p> +In the pass-by-value case, <tt>x</tt> is copied once to the parameter of +<tt>resize</tt>. And then internally, since the code can not know at compile +time by how much <tt>resize</tt> is growing the <tt>vector</tt>, <tt>x</tt> is +usually copied (not moved) a second time from <tt>resize</tt>'s parameter into its proper place +within the <tt>vector</tt>. +</p> + +<p> +With pass-by-const-reference, the <tt>x</tt> in the above example need be copied +only once. In this case, <tt>x</tt> has an expensive copy constructor and so any +copies that can be saved represents a significant savings. +</p> + +<p> +If we can be efficient for <tt>push_back</tt>, we should be efficient for <tt>resize</tt> +as well. The resize taking a reference parameter has been coded and shipped in the +CodeWarrior library with no reports of problems which I am aware of. +</p> + + + +<p><b>Proposed resolution:</b></p> +<p> +Change 23.2.2 [deque], p2: +</p> + +<blockquote><pre>class deque { + ... + void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c); +</pre></blockquote> + +<p> +Change 23.2.2.2 [deque.capacity], p3: +</p> + +<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c); +</pre></blockquote> + +<p> +Change 23.2.4 [list], p2: +</p> + +<blockquote><pre>class list { + ... + void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c); +</pre></blockquote> + +<p> +Change 23.2.4.2 [list.capacity], p3: +</p> + +<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c); +</pre></blockquote> + +<p> +Change 23.2.6 [vector], p2: +</p> + +<blockquote><pre>class vector { + ... + void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c); +</pre></blockquote> + +<p> +Change 23.2.6.2 [vector.capacity], p11: +</p> + +<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&</ins> c); +</pre></blockquote> + + + + + + +<hr> +<h3><a name="680"></a>680. move_iterator operator-> return</h3> +<p><b>Section:</b> 24.4.3.1 [move.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-06-11</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +<tt>move_iterator</tt>'s <tt>operator-></tt> return type <tt>pointer</tt> +does not consistently match the type which is returned in the description +in 24.4.3.3.5 [move.iter.op.ref]. +</p> + +<blockquote><pre>template <class Iterator> +class move_iterator { +public: + ... + typedef typename iterator_traits<Iterator>::pointer pointer; + ... + pointer operator->() const {return current;} + ... +private: + Iterator current; // exposition only +}; +</pre></blockquote> + + +<p> +There are two possible fixes. +</p> + +<ol> +<li><tt>pointer operator->() const {return &*current;}</tt></li> +<li><tt>typedef Iterator pointer;</tt></li> +</ol> + +<p> +The first solution is the one chosen by <tt>reverse_iterator</tt>. A potential +disadvantage of this is it may not work well with iterators which return a +proxy on dereference and that proxy has overloaded <tt>operator&()</tt>. Proxy +references often need to overloaad <tt>operator&()</tt> to return a proxy +pointer. That proxy pointer may or may not be the same type as the iterator's +<tt>pointer</tt> type. +</p> + +<p> +By simply returning the <tt>Iterator</tt> and taking advantage of the fact that +the language forwards calls to <tt>operator-></tt> automatically until it +finds a non-class type, the second solution avoids the issue of an overloaded +<tt>operator&()</tt> entirely. +</p> + +<p><b>Proposed resolution:</b></p> +<p> +Change the synopsis in 24.4.3.1 [move.iterator]: +</p> + +<blockquote><pre>typedef <del>typename iterator_traits<</del>Iterator<del>>::pointer</del> pointer; +</pre></blockquote> + + + + + + +<hr> <h3><a name="681"></a>681. Operator functions impossible to compare are defined in [re.submatch.op]</h3> <p><b>Section:</b> 28.9.2 [re.submatch.op] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Nozomu Katoo <b>Date:</b> 2007-05-27</p> @@ -24100,8 +25752,7 @@ operator functions numbered 31-42 seem impossible to compare. E.g.: </p> <blockquote> -<pre> -template <class BiIter> +<pre>template <class BiIter> bool operator==(typename iterator_traits<BiIter>::value_type const& lhs, const sub_match<BiIter>& rhs); </pre> @@ -24139,9 +25790,9 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a <hr> <h3><a name="682"></a>682. basic_regex ctor takes InputIterator or ForwardIterator?</h3> -<p><b>Section:</b> 28.8.2 [re.regex.construct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">Pending WP</a> +<p><b>Section:</b> 28.8.2 [re.regex.construct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Eric Niebler <b>Date:</b> 2007-06-03</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20WP">Pending WP</a> status.</p> +<p><b>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> Looking at N2284, 28.8 [re.regex], p3 <tt>basic_regex</tt> class template synopsis shows this @@ -24199,6 +25850,341 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a <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> + <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> +<p><b>Discussion:</b></p> +<p> +Since all conversions from <tt>shared_ptr<T></tt> to <tt>shared_ptr<U></tt> have the same +rank regardless of the relationship between <tt>T</tt> and <tt>U</tt>, reasonable user +code that works with raw pointers fails with <tt>shared_ptr</tt>: +</p> + +<blockquote><pre>void f( shared_ptr<void> ); +void f( shared_ptr<int> ); + +int main() +{ + f( shared_ptr<double>() ); // ambiguous +} +</pre></blockquote> + +<p> +Now that we officially have <tt>enable_if</tt>, we can constrain the constructor +and the corresponding assignment operator to only participate in the +overload resolution when the pointer types are compatible. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 20.6.12.2.1 [util.smartptr.shared.const], change: +</p> + +<blockquote><p> +-14- <i>Requires:</i> <del>For the second constructor</del> <ins>The +second constructor shall not participate in the overload resolution +unless</ins> <tt>Y*</tt> <del>shall be</del> <ins>is implicitly</ins> convertible +to <tt>T*</tt>. +</p></blockquote> + +<p> +In 20.6.12.3.1 [util.smartptr.weak.const], change: +</p> + +<blockquote> +<pre><del>template<class Y> weak_ptr(shared_ptr<Y> const& r);</del> +<del>weak_ptr(weak_ptr const& r);</del> +<del>template<class Y> weak_ptr(weak_ptr<Y> const& r);</del> +<ins>weak_ptr(weak_ptr const& r);</ins> +<ins>template<class Y> weak_ptr(weak_ptr<Y> const& r);</ins> +<ins>template<class Y> weak_ptr(shared_ptr<Y> const& r);</ins> +</pre> +<blockquote><p> +-4- <i>Requires:</i> <del>For</del> <del>t</del><ins>T</ins>he second and +third constructors<del>,</del> <ins>shall not participate in the +overload resolution unless</ins> <tt>Y*</tt> <del>shall be</del> +<ins>is implicitly</ins> convertible to <tt>T*</tt>. +</p></blockquote> +</blockquote> + + + + + + +<hr> +<h3><a name="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> + <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> +<p><b>Discussion:</b></p> +<p> +The constructor of <tt>reference_wrapper</tt> is currently <tt>explicit</tt>. The primary +motivation behind this is the safety problem with respect to rvalues, +which is addressed by the proposed resolution of the previous issue. +Therefore we should consider relaxing the requirements on the +constructor since requests for the implicit conversion keep resurfacing. +</p> +<p> +Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Remove the <tt>explicit</tt> from the constructor of <tt>reference_wrapper</tt>. If the +proposed resolution of the previous issue is accepted, remove the +<tt>explicit</tt> from the <tt>T&&</tt> constructor as well to keep them in sync. +</p> + + + + + +<hr> +<h3><a name="693"></a>693. <code>std::bitset::all()</code> missing</h3> +<p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The <code>bitset</code> class template provides the member function +<code>any()</code> to determine whether an object of the type has any +bits set, and the member function <code>none()</code> to determine +whether all of an object's bits are clear. However, the template does +not provide a corresponding function to discover whether a +<code>bitset</code> object has all its bits set. While it is +possible, even easy, to obtain this information by comparing the +result of <code>count()</code> with the result of <code>size()</code> +for equality (i.e., via <code>b.count() == b.size()</code>) the +operation is less efficient than a member function designed +specifically for that purpose could be. (<code>count()</code> must +count all non-zero bits in a <code>bitset</code> a word at a time +while <code>all()</code> could stop counting as soon as it encountered +the first word with a zero bit). +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add a declaration of the new member function <code>all()</code> to the +defintion of the <code>bitset</code> template in 23.3.5 [template.bitset], p1, +right above the declaration of <code>any()</code> as shown below: +</p> + +<blockquote><pre>bool operator!=(const bitset<N>& rhs) const; +bool test(size_t pos) const; +<ins>bool all() const;</ins> +bool any() const; +bool none() const; +</pre></blockquote> + +<p> +Add a description of the new member function to the end of 23.3.5.2 [bitset.members] with the following text: +</p> +<blockquote><p> +<code>bool all() const;</code> +</p> +<blockquote> +<i>Returns</i>: <code>count() == size()</code>. +</blockquote> +</blockquote> + +<p> +In addition, change the description of <code>any()</code> and +<code>none()</code> for consistency with <code>all()</code> as +follows: +</p> +<blockquote><p> +<code>bool any() const;</code> +</p> +<blockquote> +<p> +<i>Returns</i>: <del><code>true</code> if any bit in <code>*this</code> +is one</del><ins><code>count() != 0</code></ins>. +</p> +</blockquote> +<p> +<code>bool none() const;</code> +</p> +<blockquote> +<p> +<i>Returns</i>: <del><code>true</code> if no bit in <code>*this</code> +is one</del><ins><code>count() == 0</code></ins>. +</p> +</blockquote> +</blockquote> + + + + + +<hr> +<h3><a name="694"></a>694. <code>std::bitset</code> and <code>long long</code></h3> +<p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +Objects of the <code>bitset</code> class template specializations can +be constructed from and explicitly converted to values of the widest +C++ integer type, <code>unsigned long</code>. With the introduction +of <code>long long</code> into the language the template should be +enhanced to make it possible to interoperate with values of this type +as well, or perhaps <code>uintmax_t</code>. See c++std-lib-18274 for +a brief discussion in support of this change. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +For simplicity, instead of adding overloads for <code>unsigned long +long</code> and dealing with possible ambiguities in the spec, replace +the <code>bitset</code> ctor that takes an <code>unsigned long</code> +argument with one taking <code>unsigned long long</code> in the +definition of the template as shown below. (The standard permits +implementations to add overloads on other integer types or employ +template tricks to achieve the same effect provided they don't cause +ambiguities or changes in behavior.) +</p> +<blockquote> +<pre>// [bitset.cons] constructors: +bitset(); +bitset(unsigned <ins>long</ins> long val); +template<class charT, class traits, class Allocator> +explicit bitset( + const basic_string<charT,traits,Allocator>& str, + typename basic_string<charT,traits,Allocator>::size_type pos = 0, + typename basic_string<charT,traits,Allocator>::size_type n = + basic_string<charT,traits,Allocator>::npos); +</pre> +</blockquote> +<p> +Make a corresponding change in 23.3.5.1 [bitset.cons], p2: +</p> +<blockquote> +<p> +<code>bitset(unsigned <ins>long</ins> long val);</code> +</p> +<blockquote> +<i>Effects</i>: Constructs an object of class bitset<N>, +initializing the first <code><i>M</i></code> bit positions to the +corresponding bit values in <code><i>val</i></code>. +<code><i>M</i></code> is the smaller of <code><i>N</i></code> and the +number of bits in the value representation (section [basic.types]) of +<code>unsigned <ins> long</ins> long</code>. If <code><i>M</i> < +<i>N</i></code> <ins>is <code>true</code></ins>, the remaining bit +positions are initialized to zero. +</blockquote> +</blockquote> + +<p> +Additionally, introduce a new member function <code>to_ullong()</code> +to make it possible to convert <code>bitset</code> to values of the +new type. Add the following declaration to the definition of the +template, immediate after the declaration of <code>to_ulong()</code> +in 23.3.5 [template.bitset], p1, as shown below: +</p> +<blockquote> +<pre>// element access: +bool operator[](size_t pos) const; // for b[i]; +reference operator[](size_t pos); // for b[i]; +unsigned long to_ulong() const; +<ins>unsigned long long to_ullong() const;</ins> +template <class charT, class traits, class Allocator> +basic_string<charT, traits, Allocator> to_string() const; +</pre> +</blockquote> +<p> +And add a description of the new member function to 23.3.5.2 [bitset.members], +below the description of the existing <code>to_ulong()</code> (if +possible), with the following text: +</p> +<blockquote> +<p> +<code>unsigned long long to_ullong() const;</code> +</p> +<blockquote> +<i>Throws</i>: <code>overflow_error</code> if the integral value +<code><i>x</i></code> corresponding to the bits in <code>*this</code> +cannot be represented as type <code>unsigned long long</code>. +</blockquote> +<blockquote> +<i>Returns:</i> <code><i>x</i></code>. +</blockquote> +</blockquote> + + + + + +<hr> +<h3><a name="695"></a>695. ctype<char>::classic_table() not accessible</h3> +<p><b>Section:</b> 22.2.1.3 [facet.ctype.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The <code>ctype<char>::classic_table()</code> static member +function returns a pointer to an array of const +<code>ctype_base::mask</code> objects (enums) that contains +<code>ctype<char>::table_size</code> elements. The table +describes the properties of the character set in the "C" locale (i.e., +whether a character at an index given by its value is alpha, digit, +punct, etc.), and is typically used to initialize the +<code>ctype<char></code> facet in the classic "C" locale (the +protected <code>ctype<char></code> member function +<code>table()</code> then returns the same value as +<code>classic_table()</code>). +</p> +<p> +However, while <code>ctype<char>::table_size</code> (the size of +the table) is a public static const member of the +<code>ctype<char></code> specialization, the +<code>classic_table()</code> static member function is protected. That +makes getting at the classic data less than convenient (i.e., one has +to create a whole derived class just to get at the masks array). It +makes little sense to expose the size of the table in the public +interface while making the table itself protected, especially when the +table is a constant object. +</p> +<p> +The same argument can be made for the non-static protected member +function <code>table()</code>. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Make the <code>ctype<char>::classic_table()</code> and +<code>ctype<char>::table()</code> member functions public by +moving their declarations into the public section of the definition of +specialization in 22.2.1.3 [facet.ctype.special] as shown below: +</p> +<blockquote> +<pre> static locale::id id; + static const size_t table_size = IMPLEMENTATION_DEFINED; +<del>protected:</del> + const mask* table() const throw(); + static const mask* classic_table() throw(); +<ins>protected:</ins> + +~ctype(); // virtual +virtual char do_toupper(char c) const; +</pre> +</blockquote> + + + + + +<hr> <h3><a name="699"></a>699. N2111 changes min/max</h3> <p><b>Section:</b> 26.4 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2007-07-01</p> @@ -24238,9 +26224,181 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a <hr> +<h3><a name="700"></a>700. N1856 defines struct <tt>identity</tt></h3> +<p><b>Section:</b> 20.2.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2007-07-01</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#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a> +defines struct <tt>identity</tt> in <tt><utility></tt> which clashes with +the traditional definition of struct <tt>identity</tt> in <tt><functional></tt> +(not standard, but a common extension from old STL). Be nice +if we could avoid this name clash for backward compatibility. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Change 20.2.2 [forward]: +</p> + +<blockquote> +<pre>template <class T> struct identity +{ + typedef T type; + <ins>const T& operator()(const T& x) const;</ins> +}; +</pre> +<blockquote> +<pre><ins>const T& operator()(const T& x) const;</ins> +</pre> +<blockquote> +<p> +<ins><i>Returns:</i> <tt>x</tt>.</ins> +</p> +</blockquote> +</blockquote> + +</blockquote> + + + + + + +<hr> +<h3><a name="703"></a>703. <tt>map::at()</tt> need a complexity specification</h3> +<p><b>Section:</b> 23.3.1.2 [map.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-07-03</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map.access">issues</a> in [map.access].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +<tt>map::at()</tt> need a complexity specification. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +Add the following to the specification of <tt>map::at()</tt>, 23.3.1.2 [map.access]: +</p> +<blockquote> +<p> +<i>Complexity:</i> logarithmic. +</p> +</blockquote> + + + + + +<hr> +<h3><a name="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> + <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2007-07-08</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#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]. +</p> + +<p> +Its use is to turn C++03 pass-by-value parameters into efficient C++0x +pass-by-rvalue-reference parameters. However, the current definition +introduces an incompatible change where the cv-qualification of the +parameter type is retained. The deduced type should loose such +cv-qualification, as pass-by-value does. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 20.4.7 [meta.trans.other] change the last sentence: +</p> + +<blockquote><p> +Otherwise the member typedef <tt>type</tt> equals <tt><ins>remove_cv<</ins>U<ins>>::type</ins></tt>. +</p></blockquote> + +<p> +In 20.3.1.3 [tuple.creation]/1 change: +</p> + +<blockquote><p> +<del>where each <tt>Vi</tt> in <tt>VTypes</tt> is <tt>X&</tt> if, for the +corresponding type <tt>Ti</tt> in <tt>Types</tt>, +<tt>remove_cv<remove_reference<Ti>::type>::type</tt> equals +<tt>reference_wrapper<X></tt>, otherwise <tt>Vi</tt> is +<tt>decay<Ti>::type</tt>.</del> +<ins>Let <tt>Ui</tt> be <tt>decay<Ti>::type</tt> for each +<tt>Ti</tt> in <tt>Types</tt>. Then each <tt>Vi</tt> in <tt>VTypes</tt> +is <tt>X&</tt> if <tt>Ui</tt> equals +<tt>reference_wrapper<X></tt>, otherwise <tt>Vi</tt> is +<tt>Ui</tt>.</ins> +</p></blockquote> + + + + + + +<hr> +<h3><a name="706"></a>706. <tt>make_pair()</tt> should behave as <tt>make_tuple()</tt> wrt. <tt>reference_wrapper()</tt></h3> +<p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> + <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2007-07-08</p> +<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p> +<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p> +<p><b>Discussion:</b></p> +<p> +The current draft has <tt>make_pair()</tt> in 20.2.3 [pairs]/16 +and <tt>make_tuple()</tt> in 20.3.1.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 +<tt>reference_wrapper<X></tt> member. I suggest that the two +functions are made to behave similar in this respect to minimize +confusion. +</p> + + +<p><b>Proposed resolution:</b></p> +<p> +In 20.2 [utility] change the synopsis for make_pair() to read +</p> + +<blockquote><pre>template <class T1, class T2> + pair<<del>typename decay<T1>::type</del> <ins>V1</ins>, <del>typename decay<T2>::type</del> <ins>V2</ins>> make_pair(T1&&, T2&&); +</pre></blockquote> + +<p> +In 20.2.3 [pairs]/16 change the declaration to match the above synopsis. +Then change the 20.2.3 [pairs]/17 to: +</p> + +<blockquote> +<p> +<i>Returns:</i> <tt>pair<<del>typename decay<T1>::type</del> <ins>V1</ins>,<del>typename decay<T2>::type</del> <ins>V2</ins>>(forward<T1>(x),forward<T2>(y))</tt> <ins>where <tt>V1</tt> and +<tt>V2</tt> are determined as follows: Let <tt>Ui</tt> be +<tt>decay<Ti>::type</tt> for each <tt>Ti</tt>. Then each +<tt>Vi</tt> is <tt>X&</tt> if <tt>Ui</tt> equals +<tt>reference_wrapper<X></tt>, otherwise <tt>Vi</tt> is +<tt>Ui</tt>.</ins> +</p> +</blockquote> + + + + + + +<hr> <h3><a name="712"></a>712. <tt>seed_seq::size</tt> no longer useful</h3> <p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Marc Paterno <b>Date:</b> 2007-08-25</p> +<p><b>View 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> @@ -24280,5 +26438,4 @@ The LWG voted to accelerate this issue to Ready status to be voted into the WP a - </body></html>
\ No newline at end of file |