diff options
Diffstat (limited to 'gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-closed.html')
-rw-r--r-- | gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-closed.html | 14016 |
1 files changed, 0 insertions, 14016 deletions
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-closed.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-closed.html deleted file mode 100644 index a056c3ee2..000000000 --- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-closed.html +++ /dev/null @@ -1,14016 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> -<html><head> -<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> - - -<title>C++ Standard Library Closed Issues List</title> -<style type="text/css"> -p {text-align:justify} -li {text-align:justify} -ins {background-color:#A0FFA0} -del {background-color:#FFA0A0} -</style> -</head><body> -<table> -<tbody><tr> -<td align="left">Doc. no.</td> -<td align="left">N2729=08-0239</td> -</tr> -<tr> -<td align="left">Date:</td> -<td align="left">2008-08-24</td> -</tr> -<tr> -<td align="left">Project:</td> -<td align="left">Programming Language C++</td> -</tr> -<tr> -<td align="left">Reply to:</td> -<td align="left">Howard Hinnant <<a href="mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>></td> -</tr> -</tbody></table> -<h1>C++ Standard Library Closed Issues List (Revision R59)</h1> - - <p>Reference ISO/IEC IS 14882:1998(E)</p> - <p>Also see:</p> - <ul> - <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html">Table of Contents</a> for all library issues.</li> - <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html">Index by Section</a> for all library issues.</li> - <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html">Index by Status</a> for all library issues.</li> - <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a></li> - <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a></li> - </ul> - - <p>This document contains only library issues which have been closed - by the Library Working Group as duplicates or not defects. That is, - issues which have a status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> or - <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>. See the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a> active issues and more - information. See the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a> for issues considered - defects. The introductory material in that document also applies to - this document.</p> - -<h2>Revision History</h2> -<ul> -<li>R59: -2008-08-22 pre-San Francisco mailing. -<ul> -<li><b>Summary:</b><ul> -<li>192 open issues, up by 9.</li> -<li>686 closed issues, up by 0.</li> -<li>878 issues total, up by 9.</li> -</ul></li> -<li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#871">871</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#872">872</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#875">875</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#877">877</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>.</li> -</ul></li> -</ul> -</li> -<li>R58: -2008-07-28 mid-term mailing. -<ul> -<li><b>Summary:</b><ul> -<li>183 open issues, up by 12.</li> -<li>686 closed issues, down by 4.</li> -<li>869 issues total, up by 8.</li> -</ul></li> -<li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#864">864</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#869">869</a>.</li> -<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li> -<li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>.</li> -<li>Changed the following issues from WP to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>.</li> -<li>Changed the following issues from Pending NAD Editorial to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>.</li> -</ul></li> -</ul> -</li> -<li>R57: -2008-06-27 post-Sophia Antipolis mailing. -<ul> -<li><b>Summary:</b><ul> -<li>171 open issues, down by 20.</li> -<li>690 closed issues, up by 43.</li> -<li>861 issues total, up by 23.</li> -</ul></li> -<li><b>Details:</b><ul> -<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#840">840</a>.</li> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#858">858</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#861">861</a>.</li> -<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#839">839</a>.</li> -<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#852">852</a>.</li> -<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#851">851</a>.</li> -<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>.</li> -<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>.</li> -<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>.</li> -<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>.</li> -<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>.</li> -<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>.</li> -<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>.</li> -<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#829">829</a>.</li> -<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>.</li> -<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>.</li> -<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>.</li> -<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a>.</li> -<li>Changed the following issues from Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>.</li> -<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li> -</ul></li> -</ul> -</li> -<li>R56: -2008-05-16 pre-Sophia Antipolis mailing. -<ul> -<li><b>Summary:</b><ul> -<li>191 open issues, up by 24.</li> -<li>647 closed issues, up by 1.</li> -<li>838 issues total, up by 25.</li> -</ul></li> -<li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#838">838</a>.</li> -<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>.</li> -</ul></li> -</ul> -</li> -<li>R55: -2008-03-14 post-Bellevue mailing. -<ul> -<li><b>Summary:</b><ul> -<li>167 open issues, down by 39.</li> -<li>646 closed issues, up by 65.</li> -<li>813 issues total, up by 26.</li> -</ul></li> -<li><b>Details:</b><ul> -<li>Added the following Dup issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a>.</li> -<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#790">790</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#791">791</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#796">796</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#797">797</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#799">799</a>.</li> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>.</li> -<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#801">801</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a>.</li> -<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li> -<li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>.</li> -<li>Changed the following issues from NAD Future to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.</li> -<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>.</li> -<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#462">462</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>.</li> -<li>Changed the following issues from NAD Future to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li> -<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li> -<li>Changed the following issues from Review to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>.</li> -<li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a>.</li> -<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>.</li> -<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>.</li> -<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li> -<li>Changed the following issues from Open to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#625">625</a>.</li> -<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>.</li> -<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>.</li> -<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>.</li> -<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>.</li> -<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>.</li> -<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li> -<li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>.</li> -</ul></li> -</ul> -</li> -<li>R54: -2008-02-01 pre-Bellevue mailing. -<ul> -<li><b>Summary:</b><ul> -<li>206 open issues, up by 23.</li> -<li>581 closed issues, up by 0.</li> -<li>787 issues total, up by 23.</li> -</ul></li> -<li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>.</li> -<li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>.</li> -<li>Changed the following issues from NAD Future to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>.</li> -<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#697">697</a>.</li> -<li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>.</li> -<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>.</li> -</ul></li> -</ul> -</li> -<li>R53: -2007-12-09 mid-term mailing. -<ul> -<li><b>Summary:</b><ul> -<li>183 open issues, up by 11.</li> -<li>581 closed issues, down by 1.</li> -<li>764 issues total, up by 10.</li> -</ul></li> -<li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>.</li> -<li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>.</li> -<li>Changed the following issues from Pending WP to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li> -</ul></li> -</ul> -</li> -<li>R52: -2007-10-19 post-Kona mailing. -<ul> -<li><b>Summary:</b><ul> -<li>172 open issues, up by 4.</li> -<li>582 closed issues, up by 27.</li> -<li>754 issues total, up by 31.</li> -</ul></li> -<li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>.</li> -<li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>.</li> -<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>.</li> -<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a>.</li> -<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li> -<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li> -<li>Changed the following issues from New to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li> -<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li> -<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>.</li> -<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>.</li> -<li>Changed the following issues from New to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#552">552</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>.</li> -<li>Changed the following issues from Open to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#401">401</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>.</li> -<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>.</li> -</ul></li> -</ul> -</li> -<li>R51: -2007-09-09 pre-Kona mailing. -<ul> -<li><b>Summary:</b><ul> -<li>168 open issues, up by 15.</li> -<li>555 closed issues, up by 0.</li> -<li>723 issues total, up by 15.</li> -</ul></li> -<li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>.</li> -</ul></li> -</ul> -</li> -<li>R50: -2007-08-05 post-Toronto mailing. -<ul> -<li><b>Summary:</b><ul> -<li>153 open issues, down by 5.</li> -<li>555 closed issues, up by 17.</li> -<li>708 issues total, up by 12.</li> -</ul></li> -<li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#697">697</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li> -<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#584">584</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>.</li> -<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</a>.</li> -<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>.</li> -<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>.</li> -<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li> -<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>.</li> -<li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>.</li> -<li>Changed the following issues from Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>.</li> -<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>.</li> -<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>.</li> -<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>.</li> -<li>Changed the following issues from Ready to TRDec: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>.</li> -<li>Changed the following issues from DR to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#453">453</a>.</li> -<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>.</li> -</ul></li> -</ul> -</li> -<li>R49: -2007-06-23 pre-Toronto mailing. -<ul> -<li><b>Summary:</b><ul> -<li>158 open issues, up by 13.</li> -<li>538 closed issues, up by 7.</li> -<li>696 issues total, up by 20.</li> -</ul></li> -<li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li> -<li>Added the following Pending NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#683">683</a>.</li> -<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#587">587</a>.</li> -<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>.</li> -<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>.</li> -</ul></li> -</ul> -</li> -<li>R48: -2007-05-06 post-Oxford mailing. -<ul> -<li><b>Summary:</b><ul> -<li>145 open issues, down by 33.</li> -<li>531 closed issues, up by 53.</li> -<li>676 issues total, up by 20.</li> -</ul></li> -<li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>.</li> -<li>Changed the following issues from Tentatively Ready to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>.</li> -<li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li> -<li>Changed the following issues from NAD to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#357">357</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#368">368</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a>.</li> -<li>Changed the following issues from Tentatively Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>.</li> -<li>Changed the following issues from NAD_Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li> -<li>Changed the following issues from Tentatively Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>.</li> -<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li> -<li>Changed the following issues from Tentatively Ready to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>.</li> -<li>Changed the following issues from Tentatively Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>.</li> -<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>.</li> -<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>.</li> -<li>Changed the following issues from Ready to TRDec: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#598">598</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#599">599</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#600">600</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#601">601</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#602">602</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a>.</li> -<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>.</li> -<li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li> -</ul></li> -</ul> -</li> -<li>R47: -2007-03-09 pre-Oxford mailing. -<ul> -<li><b>Summary:</b><ul> -<li>178 open issues, up by 37.</li> -<li>478 closed issues, up by 0.</li> -<li>656 issues total, up by 37.</li> -</ul></li> -<li><b>Details:</b><ul> -<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li> -<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li> -<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#614">614</a>.</li> -<li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li> -<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>.</li> -<li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>.</li> -</ul></li> -</ul> -</li> -<li>R46: -2007-01-12 mid-term mailing. -<ul> -<li><b>Summary:</b><ul> -<li>141 open issues, up by 11.</li> -<li>478 closed issues, down by 1.</li> -<li>619 issues total, up by 10.</li> -</ul></li> -<li><b>Details:</b><ul> -<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li> -</ul></li> -</ul> -</li> -<li>R45: -2006-11-03 post-Portland mailing. -<ul> -<li><b>Summary:</b><ul> -<li>130 open issues, up by 0.</li> -<li>479 closed issues, up by 17.</li> -<li>609 issues total, up by 17.</li> -</ul></li> -<li><b>Details:</b><ul> -<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a> to WP.</li> -<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#554">554</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a> to NAD.</li> -<li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Dup.</li> -<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li> -<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#598">598</a> - <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a> to Ready.</li> -<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a> to Review.</li> -<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>.</li> -</ul></li> -</ul> -</li> -<li>R44: -2006-09-08 pre-Portland mailing. -<ul> -<li><b>Summary:</b><ul> -<li>130 open issues, up by 6.</li> -<li>462 closed issues, down by 1.</li> -<li>592 issues total, up by 5.</li> -</ul></li> -<li><b>Details:</b><ul> -<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li> -</ul></li> -</ul> -</li> -<li>R43: -2006-06-23 mid-term mailing. -<ul> -<li><b>Summary:</b><ul> -<li>124 open issues, up by 14.</li> -<li>463 closed issues, down by 1.</li> -<li>587 issues total, up by 13.</li> -</ul></li> -<li><b>Details:</b><ul> -<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>.</li> -<li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#255">255</a>.</li> -<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Tentatively Ready.</li> -</ul></li> -</ul> -</li> -<li>R42: -2006-04-21 post-Berlin mailing. -<ul> -<li><b>Summary:</b><ul> -<li>110 open issues, down by 16.</li> -<li>464 closed issues, up by 24.</li> -<li>574 issues total, up by 8.</li> -</ul></li> -<li><b>Details:</b><ul> -<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li> -<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#501">501</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#517">517</a> to NAD.</li> -<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a> to Open.</li> -<li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a> to Ready.</li> -<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> to WP.</li> -<li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li> -</ul></li> -</ul> -</li> -<li>R41: -2006-02-24 pre-Berlin mailing. -<ul> -<li><b>Summary:</b><ul> -<li>126 open issues, up by 31.</li> -<li>440 closed issues, up by 0.</li> -<li>566 issues total, up by 31.</li> -</ul></li> -<li><b>Details:</b><ul> -<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>.</li> -<li>Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a> from Ready to Open.</li> -<li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309">309</a>.</li> -</ul></li> -</ul> -</li> -<li>R40: -2005-12-16 mid-term mailing. -<ul> -<li><b>Summary:</b><ul> -<li>95 open issues.</li> -<li>440 closed issues.</li> -<li>535 issues total.</li> -</ul></li> -<li><b>Details:</b><ul> -<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>.</li> -</ul></li> -</ul> -</li> -<li>R39: -2005-10-14 post-Mont Tremblant mailing. -Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</a>. -Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#461">461</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464">464</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#465">465</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#467">467</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#474">474</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#496">496</a> from Ready to WP as per the vote from Mont Tremblant. -Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a> from Review to Ready. -Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a> from New to Open. -Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> from New to Ready. -Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD. -Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a> from New to Review. -</li> -<li>R38: -2005-07-03 pre-Mont Tremblant mailing. -Merged open TR1 issues in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>. -Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a> -</li> -<li>R37: -2005-06 mid-term mailing. -Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>. -</li> -<li>R36: -2005-04 post-Lillehammer mailing. All issues in "ready" status except -for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#454">454</a> were moved to "DR" status, and all issues -previously in "DR" status were moved to "WP". -</li> -<li>R35: -2005-03 pre-Lillehammer mailing. -</li> -<li>R34: -2005-01 mid-term mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#494">494</a>. -</li> -<li>R33: -2004-11 post-Redmond mailing. Reflects actions taken in Redmond. -</li> -<li>R32: -2004-09 pre-Redmond mailing: reflects new proposed resolutions and -new issues received after the 2004-07 mailing. Added -new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#481">481</a>. -</li> -<li>R31: -2004-07 mid-term mailing: reflects new proposed resolutions and -new issues received after the post-Sydney mailing. Added -new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>. -</li> -<li>R30: -Post-Sydney mailing: reflects decisions made at the Sydney meeting. -Voted all "Ready" issues from R29 into the working paper. -Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#462">462</a>. -</li> -<li>R29: -Pre-Sydney mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>. -</li> -<li>R28: -Post-Kona mailing: reflects decisions made at the Kona meeting. -Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#432">432</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#440">440</a>. -</li> -<li>R27: -Pre-Kona mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#404">404</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#431">431</a>. -</li> -<li>R26: -Post-Oxford mailing: reflects decisions made at the Oxford meeting. -All issues in Ready status were voted into DR status. All issues in -DR status were voted into WP status. -</li> -<li>R25: -Pre-Oxford mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a>. -</li> -<li>R24: -Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz -meeting. All Ready issues from R23 with the exception of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, which has been given a new proposed resolution, were -moved to DR status. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#383">383</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a>. (Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> were discussed -at the meeting.) Made progress on issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a> have been moved to Ready status, and the only remaining -concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording. -</li> -<li>R23: -Pre-Santa Cruz mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#367">367</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#382">382</a>. -Moved issues in the TC to TC status. -</li> -<li>R22: -Post-Curaçao mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#366">366</a>. -</li> -<li>R21: -Pre-Curaçao mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#361">361</a>. -</li> -<li>R20: -Post-Redmond mailing; reflects actions taken in Redmond. Added -new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#336">336</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, of which issues -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#347">347</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a> were added since Redmond, hence -not discussed at the meeting. - -All Ready issues were moved to DR status, with the exception of issues -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#284">284</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">241</a>, and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>. - -Noteworthy issues discussed at Redmond include -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#120">120</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#202">202</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>. -</li> -<li>R19: -Pre-Redmond mailing. Added new issues -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#335">335</a>. -</li> -<li>R18: -Post-Copenhagen mailing; reflects actions taken in Copenhagen. -Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#317">317</a>, and discussed -new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>. - -Changed status of issues -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#118">118</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a> -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#165">165</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#171">171</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#183">183</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#184">184</a> -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#185">185</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#186">186</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#214">214</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#221">221</a> -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#234">234</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#237">237</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#243">243</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#248">248</a> -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#251">251</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#256">256</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#260">260</a> -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#261">261</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#262">262</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#263">263</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a> -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a> -to DR. - -Changed status of issues -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#117">117</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a> -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#230">230</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a> -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#238">238</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">241</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#242">242</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a> -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#259">259</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#266">266</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a> -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#272">272</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#273">273</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#275">275</a> -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#281">281</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#284">284</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#285">285</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#286">286</a> -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#288">288</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#292">292</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#295">295</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#297">297</a> -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#298">298</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#301">301</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#306">306</a> -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#307">307</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#308">308</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a> -to Ready. - -Closed issues -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#277">277</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#287">287</a> -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#289">289</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#293">293</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#302">302</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#313">313</a> -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a> -as NAD. - -</li> -<li>R17: -Pre-Copenhagen mailing. Converted issues list to XML. Added proposed -resolutions for issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#76">76</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>. -Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#311">311</a>. -</li> -<li>R16: -post-Toronto mailing; reflects actions taken in Toronto. Added new -issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#277">277</a>. Changed status of issues -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3">3</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#8">8</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#9">9</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#19">19</a>, -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#26">26</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#61">61</a>, -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#63">63</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#108">108</a>, -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#115">115</a>, -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#122">122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>, -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#142">142</a>, -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#144">144</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#146">146</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#147">147</a>, -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#159">159</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#164">164</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#170">170</a>, -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#181">181</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#208">208</a>, -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#209">209</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#210">210</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>, -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#217">217</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#220">220</a>, -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#222">222</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#223">223</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#224">224</a>, -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a> to "DR". Reopened issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#23">23</a>. Reopened -issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#187">187</a>. Changed issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#2">2</a> and -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> to NAD. Fixed a typo in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a>. Fixed -issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#70">70</a>: signature should be changed both places it -appears. Fixed issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#160">160</a>: previous version didn't fix -the bug in enough places. -</li> -<li>R15: -pre-Toronto mailing. Added issues -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a>. Some small HTML formatting -changes so that we pass Weblint tests. -</li> -<li>R14: -post-Tokyo II mailing; reflects committee actions taken in -Tokyo. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a>. (00-0019R1/N1242) -</li> -<li>R13: -pre-Tokyo II updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a>. -</li> -<li>R12: -pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>. Added "and paragraph 5" to the proposed resolution -of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>. Add further rationale to issue -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>. -</li> -<li>R11: -post-Kona mailing: Updated to reflect LWG and full committee actions -in Kona (99-0048/N1224). Note changed resolution of issues -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#196">196</a> -to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#198">198</a>. Closed issues list split into "defects" and -"closed" documents. Changed the proposed resolution of issue -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> to NAD, and changed the wording of proposed resolution -of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>. -</li> -<li>R10: -pre-Kona updated. Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>, -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>, -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a> to -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99) -</li> -<li>R9: -pre-Kona mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and -"closed" documents. (99-0030/N1206, 25 Aug 99) -</li> -<li>R8: -post-Dublin mailing. Updated to reflect LWG and full committee actions -in Dublin. (99-0016/N1193, 21 Apr 99) -</li> -<li>R7: -pre-Dublin updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#131">131</a>, -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#132">132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#133">133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>, -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#135">135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>, -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a> (31 Mar 99) -</li> -<li>R6: -pre-Dublin mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>, -and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>. (99-0007/N1194, 22 Feb 99) -</li> -<li>R5: -update issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>; added issues -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#126">126</a>. Format revisions to prepare -for making list public. (30 Dec 98) -</li> -<li>R4: -post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>, -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#113">113</a> added, several -issues corrected. (22 Oct 98) -</li> -<li>R3: -post-Santa Cruz II: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#94">94</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a> -added, many issues updated to reflect LWG consensus (12 Oct 98) -</li> -<li>R2: -pre-Santa Cruz II: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#93">93</a> added, -issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98) -</li> -<li>R1: -Correction to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#55">55</a> resolution, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a> code -format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98) -</li> -</ul> - -<h2>Closed Issues</h2> -<hr> -<h3><a name="2"></a>2. Auto_ptr conversions effects incorrect</h3> -<p><b>Section:</b> D.9.1.3 [auto.ptr.conv] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Nathan Myers <b>Date:</b> 1997-12-04</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p>Paragraph 1 in "Effects", says "Calls -p->release()" where it clearly must be "Calls -p.release()". (As it is, it seems to require using -auto_ptr<>::operator-> to refer to X::release, assuming that -exists.)</p> - - -<p><b>Proposed resolution:</b></p> -<p>Change 20.5.4.3 [meta.unary.prop] paragraph 1 Effects from -"Calls p->release()" to "Calls p.release()".</p> - - -<p><b>Rationale:</b></p> -<p>Not a defect: the proposed change is already found in the standard. -[Originally classified as a defect, later reclassified.]</p> - - - - - -<hr> -<h3><a name="4"></a>4. Basic_string size_type and difference_type should be implementation defined</h3> -<p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Beman Dawes <b>Date:</b> 1997-11-16</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p>In Morristown we changed the size_type and difference_type typedefs -for all the other containers to implementation defined with a -reference to 23.1 [container.requirements]. This should probably also have been -done for strings. </p> - - -<p><b>Rationale:</b></p> -<p>Not a defect. [Originally classified as a defect, later -reclassified.] basic_string, unlike the other standard library -template containers, is severely constrained by its use of -char_traits. Those types are dictated by the traits class, and are far -from implementation defined.</p> - - - - - -<hr> -<h3><a name="6"></a>6. File position not an offset unimplementable</h3> -<p><b>Section:</b> 27.4.3 [fpos] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Matt Austern <b>Date:</b> 1997-12-15</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fpos">issues</a> in [fpos].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p>Table 88, in I/O, is too strict; it's unimplementable on systems -where a file position isn't just an offset. It also never says just -what fpos<> is really supposed to be. [Here's my summary, which -Jerry agrees is more or less accurate. "I think I now know what -the class really is, at this point: it's a magic cookie that -encapsulates an mbstate_t and a file position (possibly represented as -an fpos_t), it has syntactic support for pointer-like arithmetic, and -implementors are required to have real, not just syntactic, support -for arithmetic." This isn't standardese, of course.] </p> - - -<p><b>Rationale:</b></p> -<p>Not a defect. The LWG believes that the Standard is already clear, -and that the above summary is what the Standard in effect says.</p> - - - - - -<hr> -<h3><a name="10"></a>10. Codecvt<>::do unclear</h3> -<p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> - <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-01-14</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</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#19">19</a></p> -<p><b>Discussion:</b></p> -<p>Section 22.2.1.5.2 says that codecvt<>::do_in and do_out -should return the value noconv if "no conversion was -needed". However, I don't see anything anywhere that defines what -it means for a conversion to be needed or not needed. I can think of -several circumstances where one might plausibly think that a -conversion is not "needed", but I don't know which one is -intended here. </p> - - -<p><b>Rationale:</b></p> - - - - - - -<hr> -<h3><a name="12"></a>12. Way objects hold allocators unclear</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#NAD">NAD</a> - <b>Submitter:</b> Angelika Langer <b>Date:</b> 1998-02-23</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p>I couldn't find a statement in the standard saying whether the allocator object held by -a container is held as a copy of the constructor argument or whether a pointer of -reference is maintained internal. There is an according statement for compare objects and -how they are maintained by the associative containers, but I couldn't find anything -regarding allocators. </p> - -<p>Did I overlook it? Is it an open issue or known defect? Or is it deliberately left -unspecified? </p> - - -<p><b>Rationale:</b></p> -<p>Not a defect. The LWG believes that the Standard is already -clear. See 23.1 [container.requirements], paragraph 8.</p> - - - - - -<hr> -<h3><a name="43"></a>43. Locale table correction</h3> -<p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> - <b>Submitter:</b> Brendan Kehoe <b>Date:</b> 1998-06-01</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</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#33">33</a></p> -<p><b>Discussion:</b></p> - - -<p><b>Rationale:</b></p> - - - - - - -<hr> -<h3><a name="45"></a>45. Stringstreams read/write pointers initial position unclear</h3> -<p><b>Section:</b> 27.7.3 [ostringstream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Matthias Mueller <b>Date:</b> 1998-05-27</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 a comp.lang.c++.moderated Matthias Mueller wrote:</p> - -<p>"We are not sure how to interpret the CD2 (see 27.2 -[iostream.forward], 27.7.3.1 [ostringstream.cons], 27.7.1.1 -[stringbuf.cons]) -with respect to the question as to what the correct initial positions -of the write and read pointers of a stringstream should -be."</p> - -<p>"Is it the same to output two strings or to initialize the stringstream with the -first and to output the second?"</p> - -<p><i>[PJ Plauger, Bjarne Stroustrup, Randy Smithey, Sean Corfield, and -Jerry Schwarz have all offered opinions; see reflector messages -lib-6518, 6519, 6520, 6521, 6523, 6524.]</i></p> - - - - -<p><b>Rationale:</b></p> -<p>The LWG believes the Standard is correct as written. The behavior -of stringstreams is consistent with fstreams, and there is a -constructor which can be used to obtain the desired effect. This -behavior is known to be different from strstreams.</p> - - - - - -<hr> -<h3><a name="58"></a>58. Extracting a char from a wide-oriented stream</h3> -<p><b>Section:</b> 27.6.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-07-01</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p>27.6.1.2.3 has member functions for extraction of signed char and -unsigned char, both singly and as strings. However, it doesn't say -what it means to extract a <tt>char</tt> from a -<tt>basic_streambuf<charT, Traits></tt>. </p> - -<p>basic_streambuf, after all, has no members to extract a char, so -basic_istream must somehow convert from charT to signed char or -unsigned char. The standard doesn't say how it is to perform that -conversion. </p> - - -<p><b>Rationale:</b></p> -<p>The Standard is correct as written. There is no such extractor and -this is the intent of the LWG.</p> - - - - -<hr> -<h3><a name="65"></a>65. Underspecification of strstreambuf::seekoff</h3> -<p><b>Section:</b> D.7.1.3 [depr.strstreambuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-18</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.strstreambuf.virtuals">issues</a> in [depr.strstreambuf.virtuals].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p>The standard says how this member function affects the current -stream position. (<tt>gptr</tt> or <tt>pptr</tt>) However, it does not -say how this member function affects the beginning and end of the -get/put area. </p> - -<p>This is an issue when seekoff is used to position the get pointer -beyond the end of the current read area. (Which is legal. This is -implicit in the definition of <i>seekhigh</i> in D.7.1, paragraph 4.) -</p> - - -<p><b>Rationale:</b></p> -<p>The LWG agrees that seekoff() is underspecified, but does not wish -to invest effort in this deprecated feature.</p> - - - - - -<hr> -<h3><a name="67"></a>67. Setw useless for strings</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#Dup">Dup</a> - <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-07-09</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#Dup">Dup</a> status.</p> -<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#25">25</a></p> -<p><b>Discussion:</b></p> -<p>In a comp.std.c++ posting Michel Michaud wrote: What -should be output by: </p> - -<pre> string text("Hello"); - cout << '[' << setw(10) << right << text << ']'; -</pre> - -<p>Shouldn't it be:</p> - -<pre> [ Hello]</pre> - -<p>Another person replied: Actually, according to the FDIS, the width -of the field should be the minimum of width and the length of the -string, so the output shouldn't have any padding. I think that this is -a typo, however, and that what is wanted is the maximum of the -two. (As written, setw is useless for strings. If that had been the -intent, one wouldn't expect them to have mentioned using its value.) -</p> - -<p>It's worth pointing out that this is a recent correction anyway; -IIRC, earlier versions of the draft forgot to mention formatting -parameters whatsoever.</p> - - -<p><b>Rationale:</b></p> - - - - - - -<hr> -<h3><a name="72"></a>72. Do_convert phantom member function</h3> -<p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> - <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-24</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> -<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#24">24</a></p> -<p><b>Discussion:</b></p> -<p>In 22.2.1.4 [locale.codecvt] par 3, and in 22.2.1.4.2 [locale.codecvt.virtuals] par 8, a nonexistent member function -"do_convert" is mentioned. This member was replaced with -"do_in" and "do_out", the proper referents in the -contexts above.</p> - - -<p><b>Rationale:</b></p> - - - - - -<hr> -<h3><a name="73"></a>73. <tt>is_open</tt> should be const</h3> -<p><b>Section:</b> 27.8.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-27</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fstreams">issues</a> in [fstreams].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p>Classes <tt>basic_ifstream</tt>, <tt>basic_ofstream</tt>, and -<tt>basic_fstream</tt> all have a member function <tt>is_open</tt>. It -should be a <tt>const</tt> member function, since it does nothing but -call one of <tt>basic_filebuf</tt>'s const member functions. </p> - - -<p><b>Rationale:</b></p> -<p>Not a defect. This is a deliberate feature; const streams would be -meaningless.</p> - - - - -<hr> -<h3><a name="77"></a>77. Valarray operator[] const returning value</h3> -<p><b>Section:</b> 26.5.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> - <b>Submitter:</b> Levente Farkas <b>Date:</b> 1998-09-09</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.access">issues</a> in [valarray.access].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> -<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a></p> -<p><b>Discussion:</b></p> -<p>valarray:<br> -<br> - <tt>T operator[] (size_t) const;</tt><br> -<br> -why not <br> -<br> - <tt>const T& operator[] (size_t) const;</tt><br> -<br> -as in vector ???<br> -<br> -One can't copy even from a const valarray eg:<br> -<br> - <tt>memcpy(ptr, &v[0], v.size() * sizeof(double));<br> -</tt><br> -[I] find this bug in valarray is very difficult.</p> - - -<p><b>Rationale:</b></p> -<p>The LWG believes that the interface was deliberately designed that -way. That is what valarray was designed to do; that's where the -"value array" name comes from. LWG members further comment -that "we don't want valarray to be a full STL container." -26.5.2.3 [valarray.access] specifies properties that indicate "an -absence of aliasing" for non-constant arrays; this allows -optimizations, including special hardware optimizations, that are not -otherwise possible. </p> - - - - - -<hr> -<h3><a name="81"></a>81. Wrong declaration of slice operations</h3> -<p><b>Section:</b> 26.5.5 [template.slice.array], 26.5.7 [template.gslice.array], 26.5.8 [template.mask.array], 26.5.9 [template.indirect.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.slice.array">issues</a> in [template.slice.array].</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>Isn't the definition of copy constructor and assignment operators wrong? - Instead of</p> - -<pre> slice_array(const slice_array&); - slice_array& operator=(const slice_array&);</pre> - -<p>IMHO they have to be</p> - -<pre> slice_array(const slice_array<T>&); - slice_array& operator=(const slice_array<T>&);</pre> - -<p>Same for gslice_array. </p> - - -<p><b>Rationale:</b></p> -<p>Not a defect. The Standard is correct as written. </p> - - - - -<hr> -<h3><a name="82"></a>82. Missing constant for set elements</h3> -<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p>Paragraph 5 specifies:</p> - -<blockquote><p> -For set and multiset the value type is the same as the key type. For -map and multimap it is equal to pair<const Key, T>. -</p></blockquote> - -<p>Strictly speaking, this is not correct because for set and multiset -the value type is the same as the <b>constant</b> key type.</p> - - -<p><b>Rationale:</b></p> -<p>Not a defect. The Standard is correct as written; it uses a -different mechanism (const &) for <tt>set</tt> and -<tt>multiset</tt>. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> for a related -issue.</p> - - - - -<hr> -<h3><a name="84"></a>84. Ambiguity with string::insert()</h3> -<p><b>Section:</b> 21.3.5 [string.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p> -<p><b>View all 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 I try</p> -<pre> s.insert(0,1,' ');</pre> - -<p> I get an nasty ambiguity. It might be</p> -<pre> s.insert((size_type)0,(size_type)1,(charT)' ');</pre> - -<p>which inserts 1 space character at position 0, or</p> -<pre> s.insert((char*)0,(size_type)1,(charT)' ')</pre> - -<p>which inserts 1 space character at iterator/address 0 (bingo!), or</p> -<pre> s.insert((char*)0, (InputIterator)1, (InputIterator)' ')</pre> - -<p>which normally inserts characters from iterator 1 to iterator ' -'. But according to 23.1.1.9 (the "do the right thing" fix) -it is equivalent to the second. However, it is still ambiguous, -because of course I mean the first!</p> - - -<p><b>Rationale:</b></p> -<p>Not a defect. The LWG believes this is a "genetic -misfortune" inherent in the design of string and thus not a -defect in the Standard as such .</p> - - - - -<hr> -<h3><a name="85"></a>85. String char types</h3> -<p><b>Section:</b> 21 [strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#strings">issues</a> in [strings].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p>The standard seems not to require that charT is equivalent to -traits::char_type. So, what happens if charT is not equivalent to -traits::char_type?</p> - - -<p><b>Rationale:</b></p> -<p>There is already wording in 21.1 [char.traits] paragraph 3 that -requires them to be the same.</p> - - - - -<hr> -<h3><a name="87"></a>87. Error in description of string::compare()</h3> -<p><b>Section:</b> 21.3.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> - <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::swap">issues</a> in [string::swap].</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#5">5</a></p> -<p><b>Discussion:</b></p> -<p>The following compare() description is obviously a bug:</p> - -<pre>int compare(size_type pos, size_type n1, - charT *s, size_type n2 = npos) const; -</pre> - -<p>because without passing n2 it should compare up to the end of the -string instead of comparing npos characters (which throws an -exception) </p> - - -<p><b>Rationale:</b></p> - - - - - -<hr> -<h3><a name="88"></a>88. Inconsistency between string::insert() and string::append()</h3> -<p><b>Section:</b> 21.3.6.4 [string::insert], 21.3.6.2 [string::append] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::insert">issues</a> in [string::insert].</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>Why does </p> -<pre> template<class InputIterator> - basic_string& append(InputIterator first, InputIterator last);</pre> - -<p>return a string, while</p> -<pre> template<class InputIterator> - void insert(iterator p, InputIterator first, InputIterator last);</pre> - -<p>returns nothing ?</p> - - -<p><b>Rationale:</b></p> -<p>The LWG believes this stylistic inconsistency is not sufficiently -serious to constitute a defect.</p> - - - - -<hr> -<h3><a name="89"></a>89. Missing throw specification for string::insert() and string::replace()</h3> -<p><b>Section:</b> 21.3.6.4 [string::insert], 21.3.6.6 [string::replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> - <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::insert">issues</a> in [string::insert].</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#83">83</a></p> -<p><b>Discussion:</b></p> -<p>All insert() and replace() members for strings with an iterator as -first argument lack a throw specification. The throw -specification should probably be: length_error if size exceeds -maximum. </p> - - -<p><b>Rationale:</b></p> -<p>Considered a duplicate because it will be solved by the resolution -of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>.</p> - - - - - -<hr> -<h3><a name="93"></a>93. Incomplete Valarray Subset Definitions</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#NAD">NAD</a> - <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#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#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p>You can easily create subsets, but you can't easily combine them -with other subsets. Unfortunately, you almost always needs an -explicit type conversion to valarray. This is because the standard -does not specify that valarray subsets provide the same operations as -valarrays. </p> - -<p>For example, to multiply two subsets and assign the result to a third subset, you can't -write the following:</p> - -<pre>va[slice(0,4,3)] = va[slice(1,4,3)] * va[slice(2,4,3)];</pre> - -<p>Instead, you have to code as follows:</p> - -<pre>va[slice(0,4,3)] = static_cast<valarray<double> >(va[slice(1,4,3)]) * - static_cast<valarray<double> >(va[slice(2,4,3)]);</pre> - -<p>This is tedious and error-prone. Even worse, it costs performance because each cast -creates a temporary objects, which could be avoided without the cast. </p> - - -<p><b>Proposed resolution:</b></p> -<p>Extend all valarray subset types so that they offer all valarray operations.</p> - - -<p><b>Rationale:</b></p> -<p>This is not a defect in the Standard; it is a request for an extension.</p> - - - - -<hr> -<h3><a name="94"></a>94. May library implementors add template parameters to Standard Library classes?</h3> -<p><b>Section:</b> 17.4.4 [conforming] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-01-22</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>Is it a permitted extension for library implementors to add template parameters to -standard library classes, provided that those extra parameters have defaults? For example, -instead of defining <tt>template <class T, class Alloc = allocator<T> > class -vector;</tt> defining it as <tt>template <class T, class Alloc = allocator<T>, -int N = 1> class vector;</tt> </p> - -<p>The standard may well already allow this (I can't think of any way that this extension -could break a conforming program, considering that users are not permitted to -forward-declare standard library components), but it ought to be explicitly permitted or -forbidden. </p> - -<p>comment from Steve Cleary via comp.std.c++:</p> -<blockquote> -<p>I disagree [with the proposed resolution] for the following reason: -consider user library code with template template parameters. For -example, a user library object may be templated on the type of -underlying sequence storage to use (deque/list/vector), since these -classes all take the same number and type of template parameters; this -would allow the user to determine the performance tradeoffs of the -user library object. A similar example is a user library object -templated on the type of underlying set storage (set/multiset) or map -storage (map/multimap), which would allow users to change (within -reason) the semantic meanings of operations on that object.</p> -<p>I think that additional template parameters should be forbidden in -the Standard classes. Library writers don't lose any expressive power, -and can still offer extensions because additional template parameters -may be provided by a non-Standard implementation class:</p> -<pre> - template <class T, class Allocator = allocator<T>, int N = 1> - class __vector - { ... }; - template <class T, class Allocator = allocator<T> > - class vector: public __vector<T, Allocator> - { ... }; -</pre> - -</blockquote> - - - -<p><b>Proposed resolution:</b></p> -<p>Add a new subclause [presumably 17.4.4.9] following 17.4.4.9 [res.on.exception.handling]:</p> - -<blockquote> - <p>17.4.4.9 Template Parameters</p> <p>A specialization of a - template class described in the C++ Standard Library behaves the - same as if the implementation declares no additional template - parameters.</p> <p>Footnote: Additional template parameters with - default values are thus permitted.</p> -</blockquote> - -<p>Add "template parameters" to the list of subclauses at -the end of 17.4.4 [conforming] paragraph 1.</p> - -<p><i>[Kona: The LWG agreed the standard needs clarification. After -discussion with John Spicer, it seems added template parameters can be -detected by a program using template-template parameters. A straw vote -- "should implementors be allowed to add template -parameters?" found no consensus ; 5 - yes, 7 - no.]</i></p> - - - - -<p><b>Rationale:</b></p> -<p> -There is no ambiguity; the standard is clear as written. Library -implementors are not permitted to add template parameters to standard -library classes. This does not fall under the "as if" rule, -so it would be permitted only if the standard gave explicit license -for implementors to do this. This would require a change in the -standard. -</p> - -<p> -The LWG decided against making this change, because it would break -user code involving template template parameters or specializations -of standard library class templates. -</p> - - - - - -<hr> -<h3><a name="95"></a>95. Members added by the implementation</h3> -<p><b>Section:</b> 17.4.4.4 [member.functions] <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 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 17.3.4.4/2 vs 17.3.4.7/0 there is a hole; an implementation could add virtual -members a base class and break user derived classes.</p> - -<p>Example: </p> - -<blockquote> - <pre>// implementation code: -struct _Base { // _Base is in the implementer namespace - virtual void foo (); -}; -class vector : _Base // deriving from a class is allowed -{ ... }; - -// user code: -class vector_checking : public vector -{ - void foo (); // don't want to override _Base::foo () as the - // user doesn't know about _Base::foo () -};</pre> -</blockquote> - - -<p><b>Proposed resolution:</b></p> -<p>Clarify the wording to make the example illegal.</p> - - -<p><b>Rationale:</b></p> -<p>This is not a defect in the Standard. The example is already -illegal. See 17.4.4.4 [member.functions] paragraph 2.</p> - - - - -<hr> -<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> -<p><tt>insert(iterator, const value_type&)</tt> is defined both on -sequences and on set, with unrelated semantics: insert here (in -sequences), and insert with hint (in associative containers). They -should have different names (B.S. says: do not abuse overloading).</p> - - -<p><b>Rationale:</b></p> -<p>This is not a defect in the Standard. It is a genetic misfortune of -the design, for better or for worse.</p> - - - - -<hr> -<h3><a name="99"></a>99. Reverse_iterator comparisons completely wrong</h3> -<p><b>Section:</b> 24.4.1.3.13 [reverse.iter.op==] <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 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 <, >, <=, >= comparison operator are wrong: they -return the opposite of what they should.</p> - -<p>Note: same problem in CD2, these were not even defined in CD1. SGI -STL code is correct; this problem is known since the Morristown -meeting but there it was too late</p> - - -<p><b>Rationale:</b></p> -<p>This is not a defect in the Standard. A careful reading shows the Standard is correct -as written. A review of several implementations show that they implement -exactly what the Standard says.</p> - - - - -<hr> -<h3><a name="100"></a>100. Insert iterators/ostream_iterators overconstrained</h3> -<p><b>Section:</b> 24.4.2 [insert.iterators], 24.5.4 [ostreambuf.iterator] <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 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>Overspecified For an insert iterator it, the expression *it is -required to return a reference to it. This is a simple possible -implementation, but as the SGI STL documentation says, not the only -one, and the user should not assume that this is the case.</p> - - -<p><b>Rationale:</b></p> -<p>The LWG believes this causes no harm and is not a defect in the -standard. The only example anyone could come up with caused some -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.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> -<p><b>Discussion:</b></p> -<p>Reserve can not free storage, unlike string::reserve</p> - - -<p><b>Rationale:</b></p> -<p>This is not a defect in the Standard. The LWG has considered this -issue in the past and sees no need to change the Standard. Deque has -no reserve() member function. For vector, shrink-to-fit can be -expressed in a single line of code (where <tt>v</tt> is -<tt>vector<T></tt>): -</p> - -<blockquote> - <p><tt>vector<T>(v).swap(v); // shrink-to-fit v</tt></p> -</blockquote> - - - - - -<hr> -<h3><a name="102"></a>102. Bug in insert range in associative containers</h3> -<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> - <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> -<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a></p> -<p><b>Discussion:</b></p> -<p>Table 69 of Containers say that a.insert(i,j) is linear if [i, j) is ordered. It seems -impossible to implement, as it means that if [i, j) = [x], insert in an associative -container is O(1)!</p> - - -<p><b>Proposed resolution:</b></p> -<p>N+log (size()) if [i,j) is sorted according to value_comp()</p> - - -<p><b>Rationale:</b></p> -<p>Subsumed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a>.</p> - - - - - -<hr> -<h3><a name="104"></a>104. Description of basic_string::operator[] is unclear</h3> -<p><b>Section:</b> 21.3.4 [string.capacity] <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#string.capacity">issues</a> in [string.capacity].</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 is not clear that undefined behavior applies when pos == size () -for the non const version.</p> - - -<p><b>Proposed resolution:</b></p> -<p>Rewrite as: Otherwise, if pos > size () or pos == size () and -the non-const version is used, then the behavior is undefined.</p> - - -<p><b>Rationale:</b></p> -<p>The Standard is correct. The proposed resolution already appears in -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#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#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> - -<p>An extension to add a const wchar_t* to fstream would make the -implementation non conforming.</p> - - -<p><b>Rationale:</b></p> -<p>This is not a defect in the Standard. It might be an -interesting extension for the next Standard. </p> - - - - -<hr> -<h3><a name="107"></a>107. Valarray constructor is strange</h3> -<p><b>Section:</b> 26.5.2 [template.valarray] <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#template.valarray">issues</a> in [template.valarray].</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 order of the arguments is (elem, size) instead of the normal -(size, elem) in the rest of the library. Since elem often has an -integral or floating point type, both types are convertible to each -other and reversing them leads to a well formed program.</p> - - -<p><b>Proposed resolution:</b></p> -<p>Inverting the arguments could silently break programs. Introduce -the two signatures (const T&, size_t) and (size_t, const T&), -but make the one we do not want private so errors result in a -diagnosed access violation. This technique can also be applied to STL -containers.</p> - - -<p><b>Rationale:</b></p> -<p>The LWG believes that while the order of arguments is unfortunate, -it does not constitute a defect in the standard. The LWG believes that -the proposed solution will not work for valarray<size_t> and -perhaps other cases.</p> - - - - -<hr> -<h3><a name="111"></a>111. istreambuf_iterator::equal overspecified, inefficient</h3> -<p><b>Section:</b> 24.5.3.5 [istreambuf.iterator::equal] <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> Nathan Myers <b>Date:</b> 1998-10-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>Discussion:</b></p> -<p>The member istreambuf_iterator<>::equal is specified to be -unnecessarily inefficient. While this does not affect the efficiency -of conforming implementations of iostreams, because they can -"reach into" the iterators and bypass this function, it does -affect users who use istreambuf_iterators. </p> - -<p>The inefficiency results from a too-scrupulous definition, which -requires a "true" result if neither iterator is at eof. In -practice these iterators can only usefully be compared with the -"eof" value, so the extra test implied provides no benefit, -but slows down users' code. </p> - -<p>The solution is to weaken the requirement on the function to return -true only if both iterators are at eof. </p> - - -<p><b>Proposed resolution:</b></p> -<p>Replace 24.5.3.5 [istreambuf.iterator::equal], -paragraph 1, </p> - -<blockquote> - <p>-1- Returns: true if and only if both iterators are at end-of-stream, or neither is at - end-of-stream, regardless of what streambuf object they use. </p> -</blockquote> - -<p>with</p> - -<blockquote> - <p>-1- Returns: true if and only if both iterators are at - end-of-stream, regardless of what streambuf object they use. </p> -</blockquote> - - - -<p><b>Rationale:</b></p> -<p>It is not clear that this is a genuine defect. Additionally, the -LWG was reluctant to make a change that would result in -operator== not being a equivalence relation. One consequence of -this change is that an algorithm that's passed the range [i, i) -would no longer treat it as an empty range.</p> - - - - - -<hr> -<h3><a name="113"></a>113. Missing/extra iostream sync semantics</h3> -<p><b>Section:</b> 27.6.1.1 [istream], 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-10-13</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream">issues</a> in [istream].</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 27.6.1.1, class basic_istream has a member function sync, described in 27.6.1.3, -paragraph 36. </p> - -<p>Following the chain of definitions, I find that the various sync functions have defined -semantics for output streams, but no semantics for input streams. On the other hand, -basic_ostream has no sync function. </p> - -<p>The sync function should at minimum be added to basic_ostream, for internal -consistency. </p> - -<p>A larger question is whether sync should have assigned semantics for input streams. </p> - -<p>Classic iostreams said streambuf::sync flushes pending output and attempts to return -unread input characters to the source. It is a protected member function. The filebuf -version (which is public) has that behavior (it backs up the read pointer). Class -strstreambuf does not override streambuf::sync, and so sync can't be called on a -strstream. </p> - -<p>If we can add corresponding semantics to the various sync functions, we should. If not, -we should remove sync from basic_istream.</p> - - -<p><b>Rationale:</b></p> -<p>A sync function is not needed in basic_ostream because the flush function provides the -desired functionality.</p> - -<p>As for the other points, the LWG finds the standard correct as written.</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#Dup">Dup</a> - <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-11-06</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> -<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a></p> -<p><b>Discussion:</b></p> - - - -<p>The following code does not compile with the EDG compiler:</p> - -<blockquote> - <pre>#include <bitset> -using namespace std; -bitset<32> b("111111111");</pre> -</blockquote> - -<p>If you cast the ctor argument to a string, i.e.:</p> - -<blockquote> - <pre>bitset<32> b(string("111111111"));</pre> -</blockquote> - -<p>then it will compile. The reason is that bitset has the following templatized -constructor:</p> - -<blockquote> - <pre>template <class charT, class traits, class Allocator> -explicit bitset (const basic_string<charT, traits, Allocator>& str, ...);</pre> -</blockquote> - -<p>According to the compiler vendor, Steve Adamcyk at EDG, the user -cannot pass this template constructor a <tt>const char*</tt> and -expect a conversion to <tt>basic_string</tt>. The reason is -"When you have a template constructor, it can get used in -contexts where type deduction can be done. Type deduction basically -comes up with exact matches, not ones involving conversions." -</p> - -<p>I don't think the intention when this constructor became -templatized was for construction from a <tt>const char*</tt> to no -longer work.</p> - - -<p><b>Proposed resolution:</b></p> -<p>Add to 23.3.5 [template.bitset] a bitset constructor declaration</p> - -<blockquote> - <pre>explicit bitset(const char*);</pre> -</blockquote> - -<p>and in Section 23.3.5.1 [bitset.cons] add:</p> - -<blockquote> - <pre>explicit bitset(const char* str);</pre> - <p>Effects: <br> - Calls <tt>bitset((string) str, 0, string::npos);</tt></p> -</blockquote> - - -<p><b>Rationale:</b></p> -<p>Although the problem is real, the standard is designed that way so -it is not a defect. Education is the immediate workaround. A future -standard may wish to consider the Proposed Resolution as an -extension.</p> - - - - - -<hr> -<h3><a name="121"></a>121. Detailed definition for ctype<wchar_t> specialization</h3> -<p><b>Section:</b> 22.1.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</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#locale.category">issues</a> in [locale.category].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p>Section 22.1.1.1.1 has the following listed in Table 51: ctype<char> , -ctype<wchar_t>. </p> - -<p>Also Section 22.2.1.1 [locale.ctype] says: </p> - -<blockquote> - <p>The instantiations required in Table 51 (22.1.1.1.1) namely ctype<char> and - ctype<wchar_t> , implement character classing appropriate to the implementation's - native character set. </p> -</blockquote> - -<p>However, Section 22.2.1.3 [facet.ctype.special] -only has a detailed description of the ctype<char> specialization, not the -ctype<wchar_t> specialization. </p> - - -<p><b>Proposed resolution:</b></p> -<p>Add the ctype<wchar_t> detailed class description to Section -22.2.1.3 [facet.ctype.special]. </p> - - -<p><b>Rationale:</b></p> -<p>Specialization for wchar_t is not needed since the default is acceptable.</p> - - - - - -<hr> -<h3><a name="131"></a>131. list::splice throws nothing</h3> -<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> -<p><b>Discussion:</b></p> -<p>What happens if a splice operation causes the size() of a list to grow -beyond max_size()?</p> - - -<p><b>Rationale:</b></p> -<p>Size() cannot grow beyond max_size(). </p> - - - - - -<hr> -<h3><a name="135"></a>135. basic_iostream doubly initialized</h3> -<p><b>Section:</b> 27.6.1.5.1 [iostream.cons] <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 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>-1- Effects Constructs an object of class basic_iostream, assigning -initial values to the base classes by calling -basic_istream<charT,traits>(sb) (lib.istream) and -basic_ostream<charT,traits>(sb) (lib.ostream)</p> - -<p>The called for basic_istream and basic_ostream constructors call -init(sb). This means that the basic_iostream's virtual base class is -initialized twice.</p> - - -<p><b>Proposed resolution:</b></p> -<p>Change 27.6.1.5.1, paragraph 1 to:</p> - -<p>-1- Effects Constructs an object of class basic_iostream, assigning -initial values to the base classes by calling -basic_istream<charT,traits>(sb) (lib.istream).</p> - - -<p><b>Rationale:</b></p> -<p>The LWG agreed that the <tt> init()</tt> function is called -twice, but said that this is harmless and so not a defect in the -standard.</p> - - - - -<hr> -<h3><a name="138"></a>138. Class ctype_byname<char> redundant and misleading</h3> -<p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a> - <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-03-18</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p> -<p><b>Discussion:</b></p> -<p>Section 22.2.1.4 [locale.codecvt] specifies that -ctype_byname<char> must be a specialization of the ctype_byname -template.</p> - -<p>It is common practice in the standard that specializations of class templates are only -mentioned where the interface of the specialization deviates from the interface of the -template that it is a specialization of. Otherwise, the fact whether or not a required -instantiation is an actual instantiation or a specialization is left open as an -implementation detail. </p> - -<p>Clause 22.2.1.4 deviates from that practice and for that reason is misleading. The -fact, that ctype_byname<char> is specified as a specialization suggests that there -must be something "special" about it, but it has the exact same interface as the -ctype_byname template. Clause 22.2.1.4 does not have any explanatory value, is at best -redundant, at worst misleading - unless I am missing anything. </p> - -<p>Naturally, an implementation will most likely implement ctype_byname<char> as a -specialization, because the base class ctype<char> is a specialization with an -interface different from the ctype template, but that's an implementation detail and need -not be mentioned in the standard. </p> - - -<p><b>Rationale:</b></p> -<p> The standard as written is mildly misleading, but the correct fix -is to deal with the underlying problem in the ctype_byname base class, -not in the specialization. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>.</p> - - - - -<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%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%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<blockquote> - <p>23.1 [container.requirements]<br> - <br> - expression return type - pre/post-condition<br> - ------------- ----------- - -------------------<br> - X::value_type T - - T is assignable<br> - <br> - 23.3.1 [map]<br> - <br> - A map satisfies all the requirements of a container.<br> - <br> - For a map<Key, T> ... the value_type is pair<const Key, T>.</p> -</blockquote> - -<p>There's a contradiction here. In particular, `pair<const Key, -T>' is not assignable; the `const Key' cannot be assigned -to. So, map<Key, T>::value_type does not satisfy the -assignable requirement imposed by a container.</p> - -<p><i>[See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> for the slightly related issue of -modification of set keys.]</i></p> - - - -<p><b>Rationale:</b></p> -<p>The LWG believes that the standard is inconsistent, but that this -is a design problem rather than a strict defect. May wish to -reconsider for the next standard.</p> - - - - -<hr> -<h3><a name="143"></a>143. C .h header wording unclear</h3> -<p><b>Section:</b> D.5 [depr.c.headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Christophe de Dinechin <b>Date:</b> 1999-05-04</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>[depr.c.headers] paragraph 2 reads:</p> - -<blockquote> - -<p>Each C header, whose name has the form name.h, behaves as if each -name placed in the Standard library namespace by the corresponding -cname header is also placed within the namespace scope of the -namespace std and is followed by an explicit using-declaration -(_namespace.udecl_)</p> - -</blockquote> - -<p>I think it should mention the global name space somewhere... -Currently, it indicates that name placed in std is also placed in -std...</p> - -<p>I don't know what is the correct wording. For instance, if struct -tm is defined in time.h, ctime declares std::tm. However, the current -wording seems ambiguous regarding which of the following would occur -for use of both ctime and time.h:</p> - -<blockquote> - <pre>// version 1: -namespace std { - struct tm { ... }; -} -using std::tm; - -// version 2: -struct tm { ... }; -namespace std { - using ::tm; -} - -// version 3: -struct tm { ... }; -namespace std { - struct tm { ... }; -}</pre> -</blockquote> - -<p>I think version 1 is intended.</p> - -<p><i>[Kona: The LWG agreed that the wording is not clear. It also -agreed that version 1 is intended, version 2 is not equivalent to -version 1, and version 3 is clearly not intended. The example below -was constructed by Nathan Myers to illustrate why version 2 is not -equivalent to version 1.</i></p> - -<p><i>Although not equivalent, the LWG is unsure if (2) is enough of -a problem to be prohibited. Points discussed in favor of allowing -(2):</i></p> - -<blockquote> - <ul> - <li><i>It may be a convenience to implementors.</i></li> - <li><i>The only cases that fail are structs, of which the C library - contains only a few.</i></li> - </ul> -</blockquote> - -<p><i>]</i></p> - -<p><b>Example:</b></p> - -<blockquote> - -<pre>#include <time.h> -#include <utility> - -int main() { - std::tm * t; - make_pair( t, t ); // okay with version 1 due to Koenig lookup - // fails with version 2; make_pair not found - return 0; -}</pre> - -</blockquote> - - -<p><b>Proposed resolution:</b></p> - -<p>Replace D.5 [depr.c.headers] paragraph 2 with:</p> - -<blockquote> - -<p> Each C header, whose name has the form name.h, behaves as if each -name placed in the Standard library namespace by the corresponding -cname header is also placed within the namespace scope of the -namespace std by name.h and is followed by an explicit -using-declaration (_namespace.udecl_) in global scope.</p> - -</blockquote> - - - -<p><b>Rationale:</b></p> -<p> The current wording in the standard is the result of a difficult -compromise that averted delay of the standard. Based on discussions -in Tokyo it is clear that there is no still no consensus on stricter -wording, so the issue has been closed. It is suggested that users not -write code that depends on Koenig lookup of C library functions.</p> - - - - -<hr> -<h3><a name="145"></a>145. adjustfield lacks default value</h3> -<p><b>Section:</b> 27.4.4.1 [basic.ios.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-05-12</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.cons">issues</a> in [basic.ios.cons].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p>There is no initial value for the adjustfield defined, although -many people believe that the default adjustment were right. This is a -common misunderstanding. The standard only defines that, if no -adjustment is specified, all the predefined inserters must add fill -characters before the actual value, which is "as if" the -right flag were set. The flag itself need not be set.</p> - -<p>When you implement a user-defined inserter you cannot rely on right -being the default setting for the adjustfield. Instead, you must be -prepared to find none of the flags set and must keep in mind that in -this case you should make your inserter behave "as if" the -right flag were set. This is surprising to many people and complicates -matters more than necessary.</p> - -<p>Unless there is a good reason why the adjustfield should not be -initialized I would suggest to give it the default value that -everybody expects anyway.</p> - - - -<p><b>Rationale:</b></p> -<p>This is not a defect. It is deliberate that the default is no bits -set. Consider Arabic or Hebrew, for example. See 22.2.2.2.2 [facet.num.put.virtuals] paragraph 19, Table 61 - Fill padding.</p> - - - - -<hr> -<h3><a name="149"></a>149. Insert should return iterator to first element inserted</h3> -<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a> - <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-06-28</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p> -<p><b>Discussion:</b></p> -<p>Suppose that c and c1 are sequential containers and i is an -iterator that refers to an element of c. Then I can insert a copy of -c1's elements into c ahead of element i by executing </p> - -<blockquote> - -<pre>c.insert(i, c1.begin(), c1.end());</pre> - -</blockquote> - -<p>If c is a vector, it is fairly easy for me to find out where the -newly inserted elements are, even though i is now invalid: </p> - -<blockquote> - -<pre>size_t i_loc = i - c.begin(); -c.insert(i, c1.begin(), c1.end());</pre> - -</blockquote> - -<p>and now the first inserted element is at c.begin()+i_loc and one -past the last is at c.begin()+i_loc+c1.size().<br> -<br> -But what if c is a list? I can still find the location of one past the -last inserted element, because i is still valid. To find the location -of the first inserted element, though, I must execute something like </p> - -<blockquote> - -<pre>for (size_t n = c1.size(); n; --n) - --i;</pre> - -</blockquote> - -<p>because i is now no longer a random-access iterator.<br> -<br> -Alternatively, I might write something like </p> - -<blockquote> - -<pre>bool first = i == c.begin(); -list<T>::iterator j = i; -if (!first) --j; -c.insert(i, c1.begin(), c1.end()); -if (first) - j = c.begin(); -else - ++j;</pre> - -</blockquote> - -<p>which, although wretched, requires less overhead.<br> -<br> -But I think the right solution is to change the definition of insert -so that instead of returning void, it returns an iterator that refers -to the first element inserted, if any, and otherwise is a copy of its -first argument. </p> - - -<p><b>Rationale:</b></p> -<p>The LWG believes this was an intentional design decision and so is -not a defect. It may be worth revisiting for the next standard.</p> - - - - -<hr> -<h3><a name="157"></a>157. Meaningless error handling for <tt>pword()</tt> and <tt>iword()</tt></h3> -<p><b>Section:</b> 27.4.2.5 [ios.base.storage] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> - <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base.storage">issues</a> in [ios.base.storage].</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#41">41</a></p> -<p><b>Discussion:</b></p> -<p>According to paragraphs 2 and 4 of 27.4.2.5 [ios.base.storage], the -functions <tt>iword()</tt> and <tt>pword()</tt> "set the -<tt>badbit</tt> (which might throw an exception)" on -failure. ... but what does it mean for <tt>ios_base</tt> to set the -<tt>badbit</tt>? The state facilities of the IOStream library are -defined in <tt>basic_ios</tt>, a derived class! It would be possible -to attempt a down cast but then it would be necessary to know the -character type used...</p> - - -<p><b>Rationale:</b></p> - - - - - -<hr> -<h3><a name="162"></a>162. Really "formatted input functions"?</h3> -<p><b>Section:</b> 27.6.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> - <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> -<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a></p> -<p><b>Discussion:</b></p> -<p>It appears to be somewhat nonsensical to consider the functions -defined in the paragraphs 1 to 5 to be "Formatted input -function" but since these functions are defined in a section -labeled "Formatted input functions" it is unclear to me -whether these operators are considered formatted input functions which -have to conform to the "common requirements" from 27.6.1.2.1 -[istream.formatted.reqmts]: If this is the case, all manipulators, not -just -<tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is set -(... but setting <tt>noskipws</tt> using the manipulator syntax would -also skip whitespace :-)</p> - -<p>See also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#166">166</a> for the same problem in formatted -output</p> - - -<p><b>Rationale:</b></p> - - - - - -<hr> -<h3><a name="163"></a>163. Return of <tt>gcount()</tt> after a call to <tt>gcount</tt></h3> -<p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> - <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> -<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a></p> -<p><b>Discussion:</b></p> -<p>It is not clear which functions are to be considered unformatted -input functions. As written, it seems that all functions in 27.6.1.3 -[istream.unformatted] are unformatted input functions. However, it does -not -really make much sense to construct a sentry object for -<tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is unclear what -happens to the <tt>gcount()</tt> if eg. <tt>gcount()</tt>, -<tt>putback()</tt>, <tt>unget()</tt>, or <tt>sync()</tt> is called: -These functions don't extract characters, some of them even -"unextract" a character. Should this still be reflected in -<tt>gcount()</tt>? Of course, it could be read as if after a call to -<tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt> (the last -unformatted input function, <tt>gcount()</tt>, didn't extract any -character) and after a call to <tt>putback()</tt> <tt>gcount()</tt> -returns <tt>-1</tt> (the last unformatted input function -<tt>putback()</tt> did "extract" back into the -stream). Correspondingly for <tt>unget()</tt>. Is this what is -intended? If so, this should be clarified. Otherwise, a corresponding -clarification should be used.</p> - - -<p><b>Rationale:</b></p> - - - - - -<hr> -<h3><a name="166"></a>166. Really "formatted output functions"?</h3> -<p><b>Section:</b> 27.6.2.6.3 [ostream.inserters] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> - <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 1999-07-20</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> -<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a></p> -<p><b>Discussion:</b></p> -<p>From 27.6.2.6.1 [ostream.formatted.reqmts] it appears that all the functions -defined in 27.6.2.6.3 [ostream.inserters] have to construct a -<tt>sentry</tt> object. Is this really intended?</p> - -<p>This is basically the same problem as issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#162">162</a> but -for output instead of input.</p> - - -<p><b>Rationale:</b></p> - - - - - -<hr> -<h3><a name="177"></a>177. Complex operators cannot be explicitly instantiated</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#NAD">NAD</a> - <b>Submitter:</b> Judy Ward <b>Date:</b> 1999-07-02</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#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p>A user who tries to explicitly instantiate a complex non-member operator will -get compilation errors. Below is a simplified example of the reason why. The -problem is that iterator_traits cannot be instantiated on a non-pointer type -like float, yet when the compiler is trying to decide which operator+ needs to -be instantiated it must instantiate the declaration to figure out the first -argument type of a reverse_iterator operator.</p> -<pre>namespace std { -template <class Iterator> -struct iterator_traits -{ - typedef typename Iterator::value_type value_type; -}; - -template <class T> class reverse_iterator; - -// reverse_iterator operator+ -template <class T> -reverse_iterator<T> operator+ -(typename iterator_traits<T>::difference_type, const reverse_iterator<T>&); - -template <class T> struct complex {}; - -// complex operator + -template <class T> -complex<T> operator+ (const T& lhs, const complex<T>& rhs) -{ return complex<T>();} -} - -// request for explicit instantiation -template std::complex<float> std::operator+<float>(const float&, - const std::complex<float>&);</pre> -<p>See also c++-stdlib reflector messages: lib-6814, 6815, 6816.</p> - - -<p><b>Rationale:</b></p> -<p>Implementors can make minor changes and the example will -work. Users are not affected in any case.</p> <p>According to John -Spicer, It is possible to explicitly instantiate these operators using -different syntax: change "std::operator+<float>" to -"std::operator+".</p> - -<p>The proposed resolution of issue 120 is that users will not be able -to explicitly instantiate standard library templates. If that -resolution is accepted then library implementors will be the only ones -that will be affected by this problem, and they must use the indicated -syntax.</p> - - - - -<hr> -<h3><a name="178"></a>178. Should clog and cerr initially be tied to cout?</h3> -<p><b>Section:</b> 27.3.1 [narrow.stream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Judy Ward <b>Date:</b> 1999-07-02</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#narrow.stream.objects">issues</a> in [narrow.stream.objects].</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> -Section 27.3.1 says "After the object cerr is initialized, -cerr.flags() & unitbuf is nonzero. Its state is otherwise the same as -required for ios_base::init (lib.basic.ios.cons). It doesn't say -anything about the the state of clog. So this means that calling -cerr.tie() and clog.tie() should return 0 (see Table 89 for -ios_base::init effects). -</p> -<p> -Neither of the popular standard library implementations -that I tried does this, they both tie cerr and clog -to &cout. I would think that would be what users expect. -</p> - - -<p><b>Rationale:</b></p> -<p>The standard is clear as written.</p> -<p>27.3.1/5 says that "After the object cerr is initialized, cerr.flags() -& unitbuf is nonzero. Its state is otherwise the same as required for -ios_base::init (27.4.4.1)." Table 89 in 27.4.4.1, which gives the -postconditions of basic_ios::init(), says that tie() is 0. (Other issues correct -ios_base::init to basic_ios::init().)</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">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">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 -corresponding versions for the helper classes. Thus making the -following illegal:</p> -<blockquote> -<pre>#include <valarray> - -int main() -{ -std::valarray<double> v(3.14, 1999); - -v[99] *= 2.0; // Ok - -std::slice s(0, 50, 2); - -v[s] *= 2.0; // ERROR -}</pre> -</blockquote> -<p>I can't understand the intent of that omission. It makes the -valarray library less intuitive and less useful.</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 add the missing -operators.</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> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.binary.search">issues</a> in [alg.binary.search].</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 binary_search() is stated as "At most -log(last-first) + 2 comparisons", which seems to say that the -algorithm has logarithmic complexity. However, this algorithms is -defined for forward iterators. And for forward iterators, the need to -step element-by-element results into linear complexity. But such a -statement is missing in the standard. The same applies to -lower_bound(), upper_bound(), and equal_range(). <br> -<br> -However, strictly speaking the standard contains no bug here. So this -might considered to be a clarification or improvement. -</p> - - -<p><b>Rationale:</b></p> -<p>The complexity is expressed in terms of comparisons, and that -complexity can be met even if the number of iterators accessed is -linear. Paragraph 1 already says exactly what happens to -iterators.</p> - - - - -<hr> -<h3><a name="192"></a>192. a.insert(p,t) is inefficient and overconstrained</h3> -<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Ed Brey <b>Date:</b> 1999-06-06</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a></p> -<p><b>Discussion:</b></p> -<p>As defined in 23.1.2, paragraph 7 (table 69), a.insert(p,t) suffers from -several problems:</p> -<table border="1" cellpadding="5"> - <tbody><tr> - <td><b>expression</b></td> - <td><b>return type</b></td> - <td><b>pre/post-condition</b></td> - <td><b>complexity</b></td> - </tr> - <tr> - <td><tt>a.insert(p,t)</tt></td> - <td><tt>iterator</tt></td> - <td>inserts t if and only if there is no element with key equivalent to the key of - t in containers with unique keys; always inserts t in containers with equivalent - keys. always returns the iterator pointing to the element with key equivalent to - the key of t . iterator p is a hint pointing to where the insert should start to search.</td> - <td>logarithmic in general, but amortized constant if t is inserted right after p .</td> - </tr> -</tbody></table> -<p>1. For a container with unique keys, only logarithmic complexity is -guaranteed if no element is inserted, even though constant complexity is always -possible if p points to an element equivalent to t.</p> -<p>2. For a container with equivalent keys, the amortized constant complexity -guarantee is only useful if no key equivalent to t exists in the container. -Otherwise, the insertion could occur in one of multiple locations, at least one -of which would not be right after p.</p> -<p>3. By guaranteeing amortized constant complexity only when t is inserted -after p, it is impossible to guarantee constant complexity if t is inserted at -the beginning of the container. Such a problem would not exist if amortized -constant complexity was guaranteed if t is inserted before p, since there is -always some p immediately before which an insert can take place.</p> -<p>4. For a container with equivalent keys, p does not allow specification of -where to insert the element, but rather only acts as a hint for improving -performance. This negates the added functionality that p would provide if it -specified where within a sequence of equivalent keys the insertion should occur. -Specifying the insert location provides more control to the user, while -providing no disadvantage to the container implementation.</p> - - -<p><b>Proposed resolution:</b></p> -<p>In 23.1.4 [associative.reqmts] paragraph 7, replace the row in table 69 -for a.insert(p,t) with the following two rows:</p> -<table border="1" cellpadding="5"> - <tbody><tr> - <td><b>expression</b></td> - <td><b>return type</b></td> - <td><b>pre/post-condition</b></td> - <td><b>complexity</b></td> - </tr> - <tr> - <td><tt>a_uniq.insert(p,t)</tt></td> - <td><tt>iterator</tt></td> - <td>inserts t if and only if there is no element with key equivalent to the - key of t. returns the iterator pointing to the element with key equivalent - to the key of t.</td> - <td>logarithmic in general, but amortized constant if t is inserted right - before p or p points to an element with key equivalent to t.</td> - </tr> - <tr> - <td><tt>a_eq.insert(p,t)</tt></td> - <td><tt>iterator</tt></td> - <td>inserts t and returns the iterator pointing to the newly inserted - element. t is inserted right before p if doing so preserves the container - ordering.</td> - <td>logarithmic in general, but amortized constant if t is inserted right - before p.</td> - </tr> -</tbody></table> - - - -<p><b>Rationale:</b></p> -<p>Too big a change. Furthermore, implementors report checking -both before p and after p, and don't want to change this behavior.</p> - - - - - -<hr> -<h3><a name="194"></a>194. rdbuf() functions poorly specified</h3> -<p><b>Section:</b> 27.4.4 [ios] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Steve Clamage <b>Date:</b> 1999-09-07</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p>In classic iostreams, base class ios had an rdbuf function that returned a -pointer to the associated streambuf. Each derived class had its own rdbuf -function that returned a pointer of a type reflecting the actual type derived -from streambuf. Because in ARM C++, virtual function overrides had to have the -same return type, rdbuf could not be virtual.</p> -<p>In standard iostreams, we retain the non-virtual rdbuf function design, and -in addition have an overloaded rdbuf function that sets the buffer pointer. -There is no need for the second function to be virtual nor to be implemented in -derived classes.</p> -<p>Minor question: Was there a specific reason not to make the original rdbuf -function virtual?</p> -<p>Major problem: Friendly compilers warn about functions in derived classes -that hide base-class overloads. Any standard implementation of iostreams will -result in such a warning on each of the iostream classes, because of the -ill-considered decision to overload rdbuf only in a base class.</p> -<p>In addition, users of the second rdbuf function must use explicit -qualification or a cast to call it from derived classes. An explicit -qualification or cast to basic_ios would prevent access to any later overriding -version if there was one.</p> -<p>What I'd like to do in an implementation is add a using- declaration for the -second rdbuf function in each derived class. It would eliminate warnings about -hiding functions, and would enable access without using explicit qualification. -Such a change I don't think would change the behavior of any valid program, but -would allow invalid programs to compile:</p> -<blockquote> - <pre> filebuf mybuf; - fstream f; - f.rdbuf(mybuf); // should be an error, no visible rdbuf</pre> -</blockquote> -<p>I'd like to suggest this problem as a defect, with the proposed resolution to -require the equivalent of a using-declaration for the rdbuf function that is not -replaced in a later derived class. We could discuss whether replacing the -function should be allowed.</p> - - -<p><b>Rationale:</b></p> -<p>For historical reasons, the standard is correct as written. There is a subtle difference between the base -class <tt> rdbuf()</tt> and derived class <tt>rdbuf()</tt>. The derived -class <tt> rdbuf()</tt> always returns the original streambuf, whereas the base class -<tt> rdbuf()</tt> will return the "current streambuf" if that has been changed by the variant you mention.</p> - -<p>Permission is not required to add such an extension. See -17.4.4.4 [member.functions].</p> - - - - -<hr> -<h3><a name="196"></a>196. Placement new example has alignment problems</h3> -<p><b>Section:</b> 18.5.1.3 [new.delete.placement] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> - <b>Submitter:</b> Herb Sutter <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#new.delete.placement">issues</a> in [new.delete.placement].</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#114">114</a></p> -<p><b>Discussion:</b></p> -<p>The example in 18.5.1.3 [new.delete.placement] paragraph 4 reads: </p> - -<blockquote> - -<p>[Example: This can be useful for constructing an object at a known address:<br> -<br> -<tt> char place[sizeof(Something)];<br> - Something* p = new (place) Something();<br> -<br> -</tt>end example] </p> - -</blockquote> - -<p>This example has potential alignment problems. </p> - - -<p><b>Rationale:</b></p> - - - - - -<hr> -<h3><a name="197"></a>197. max_size() underspecified</h3> -<p><b>Section:</b> 20.1.2 [allocator.requirements], 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Andy Sawyer <b>Date:</b> 1999-10-21</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p>Must the value returned by max_size() be unchanged from call to call? </p> - -<p>Must the value returned from max_size() be meaningful? </p> - -<p>Possible meanings identified in lib-6827: </p> - -<p>1) The largest container the implementation can support given "best -case" conditions - i.e. assume the run-time platform is "configured to -the max", and no overhead from the program itself. This may possibly -be determined at the point the library is written, but certainly no -later than compile time.<br> -<br> -2) The largest container the program could create, given "best case" -conditions - i.e. same platform assumptions as (1), but take into -account any overhead for executing the program itself. (or, roughly -"storage=storage-sizeof(program)"). This does NOT include any resource -allocated by the program. This may (or may not) be determinable at -compile time.<br> -<br> -3) The largest container the current execution of the program could -create, given knowledge of the actual run-time platform, but again, -not taking into account any currently allocated resource. This is -probably best determined at program start-up.<br> -<br> -4) The largest container the current execution program could create at -the point max_size() is called (or more correctly at the point -max_size() returns :-), given it's current environment (i.e. taking -into account the actual currently available resources). This, -obviously, has to be determined dynamically each time max_size() is -called. </p> - - -<p><b>Proposed resolution:</b></p> - - -<p><b>Rationale:</b></p> -<p>max_size() isn't useful for very many things, and the existing - wording is sufficiently clear for the few cases that max_size() can - be used for. None of the attempts to change the existing wording - were an improvement.</p> - -<p>It is clear to the LWG that the value returned by max_size() can't - change from call to call.</p> - - - - - - -<hr> -<h3><a name="203"></a>203. basic_istream::sentry::sentry() is uninstantiable with ctype<user-defined type></h3> -<p><b>Section:</b> 27.6.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Matt McClure and Dietmar Kühl <b>Date:</b> 2000-01-01</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::sentry">issues</a> in [istream::sentry].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p>27.6.1.1.2 Paragraph 4 states:</p> -<blockquote> - <p>To decide if the character c is a whitespace character, the constructor - performs ''as if'' it executes the following code fragment: </p> - <pre>const ctype<charT>& ctype = use_facet<ctype<charT> >(is.getloc()); -if (ctype.is(ctype.space,c)!=0) -// c is a whitespace character.</pre> -</blockquote> - -<p> But Table 51 in 22.1.1.1.1 only requires an implementation to -provide specializations for ctype<char> and -ctype<wchar_t>. If sentry's constructor is implemented using -ctype, it will be uninstantiable for a user-defined character type -charT, unless the implementation has provided non-working (since it -would be impossible to define a correct ctype<charT> specialization -for an arbitrary charT) definitions of ctype's virtual member -functions.</p> - -<p> -It seems the intent the standard is that sentry should behave, in -every respect, not just during execution, as if it were implemented -using ctype, with the burden of providing a ctype specialization -falling on the user. But as it is written, nothing requires the -translation of sentry's constructor to behave as if it used the above -code, and it would seem therefore, that sentry's constructor should be -instantiable for all character types. -</p> - -<p> -Note: If I have misinterpreted the intent of the standard with -respect to sentry's constructor's instantiability, then a note should -be added to the following effect: -</p> - -<blockquote><p> -An implementation is forbidden from using the above code if it renders -the constructor uninstantiable for an otherwise valid character -type. -</p></blockquote> - -<p>In any event, some clarification is needed.</p> - - - -<p><b>Rationale:</b></p> -<p>It is possible but not easy to instantiate on types other than char -or wchar_t; many things have to be done first. That is by intention -and is not a defect.</p> - - - - -<hr> -<h3><a name="204"></a>204. distance(first, last) when "last" is before "first"</h3> -<p><b>Section:</b> 24.3.4 [iterator.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Rintala Matti <b>Date:</b> 2000-01-28</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>Section 24.3.4 describes the function distance(first, last) (where first and -last are iterators) which calculates "the number of increments or -decrements needed to get from 'first' to 'last'".</p> -<p>The function should work for forward, bidirectional and random access -iterators, and there is a requirement 24.3.4.5 which states that "'last' -must be reachable from 'first'".</p> -<p>With random access iterators the function is easy to implement as "last -- first".</p> -<p>With forward iterators it's clear that 'first' must point to a place before -'last', because otherwise 'last' would not be reachable from 'first'.</p> -<p>But what about bidirectional iterators? There 'last' is reachable from -'first' with the -- operator even if 'last' points to an earlier position than -'first'. However, I cannot see how the distance() function could be implemented -if the implementation does not know which of the iterators points to an earlier -position (you cannot use ++ or -- on either iterator if you don't know which -direction is the "safe way to travel").</p> -<p>The paragraph 24.3.4.1 states that "for ... bidirectional iterators they -use ++ to provide linear time implementations". However, the ++ operator is -not mentioned in the reachability requirement. Furthermore 24.3.4.4 explicitly -mentions that distance() returns the number of increments _or decrements_, -suggesting that it could return a negative number also for bidirectional -iterators when 'last' points to a position before 'first'.</p> -<p>Is a further requirement is needed to state that for forward and -bidirectional iterators "'last' must be reachable from 'first' using the ++ -operator". Maybe this requirement might also apply to random access -iterators so that distance() would work the same way for every iterator -category?</p> - - -<p><b>Rationale:</b></p> -<p>"Reachable" is defined in the standard in 24.1 [iterator.requirements] paragraph 6. -The definition is only in terms of operator++(). The LWG sees no defect in -the standard.</p> - - - - -<hr> -<h3><a name="205"></a>205. numeric_limits unclear on how to determine floating point types</h3> -<p><b>Section:</b> 18.2.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Steve Cleary <b>Date:</b> 2000-01-28</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#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p>In several places in 18.2.1.2 [numeric.limits.members], a member is -described as "Meaningful for all floating point types." -However, no clear method of determining a floating point type is -provided.</p> - -<p>In 18.2.1.5 [numeric.special], paragraph 1 states ". . . (for -example, epsilon() is only meaningful if is_integer is -false). . ." which suggests that a type is a floating point type -if is_specialized is true and is_integer is false; however, this is -unclear.</p> - -<p>When clarifying this, please keep in mind this need of users: what -exactly is the definition of floating point? Would a fixed point or -rational representation be considered one? I guess my statement here -is that there could also be types that are neither integer or -(strictly) floating point.</p> - - -<p><b>Rationale:</b></p> -<p>It is up to the implementor of a user define type to decide if it is a -floating point type.</p> - - - - -<hr> -<h3><a name="207"></a>207. ctype<char> members return clause incomplete</h3> -<p><b>Section:</b> 22.2.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> - <b>Submitter:</b> Robert Klarer <b>Date:</b> 1999-11-02</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.ctype.char.members">issues</a> in [facet.ctype.char.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> -<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a></p> -<p><b>Discussion:</b></p> -<p> -The <tt>widen</tt> and <tt>narrow</tt> member functions are described -in 22.2.1.3.2, paragraphs 9-11. In each case we have two overloaded -signatures followed by a <b>Returns</b> clause. The <b>Returns</b> -clause only describes one of the overloads. -</p> - - -<p><b>Proposed resolution:</b></p> -<p>Change the returns clause in 22.2.1.3.2 [facet.ctype.char.members] -paragraph 10 from:</p> -<p> Returns: do_widen(low, high, to).</p> - -<p>to:</p> -<p> Returns: do_widen(c) or do_widen(low, high, to), -respectively.</p> - -<p>Change the returns clause in 22.2.1.3.2 [facet.ctype.char.members] paragraph 11 -from:</p> -<p> Returns: do_narrow(low, high, to).</p> - -<p>to:</p> -<p> Returns: do_narrow(c) or do_narrow(low, high, to), -respectively.</p> - - -<p><b>Rationale:</b></p> -<p>Subsumed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a>, which addresses the same -paragraphs.</p> - - - - - - -<hr> -<h3><a name="213"></a>213. Math function overloads ambiguous</h3> -<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Nico Josuttis <b>Date:</b> 2000-02-26</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p>Due to the additional overloaded versions of numeric functions for -float and long double according to Section 26.5, calls such as int x; -std::pow (x, 4) are ambiguous now in a standard conforming -implementation. Current implementations solve this problem very -different (overload for all types, don't overload for float and long -double, use preprocessor, follow the standard and get -ambiguities).</p> <p>This behavior should be standardized or at least -identified as implementation defined.</p> - - -<p><b>Rationale:</b></p> -<p>These math issues are an -understood and accepted consequence of the design. They have -been discussed several times in the past. Users must write casts -or write floating point expressions as arguments.</p> - - - - -<hr> -<h3><a name="215"></a>215. Can a map's key_type be const?</h3> -<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-02-29</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p>A user noticed that this doesn't compile with the Rogue Wave library because -the rb_tree class declares a key_allocator, and allocator<const int> is -not legal, I think:</p> -<blockquote> - <pre>map < const int, ... > // legal?</pre> -</blockquote> -<p>which made me wonder whether it is legal for a map's key_type to be const. In -email from Matt Austern he said:</p> -<blockquote> -<p>I'm not sure whether it's legal to declare a map with a const key type. I -hadn't thought about that question until a couple weeks ago. My intuitive -feeling is that it ought not to be allowed, and that the standard ought to say -so. It does turn out to work in SGI's library, though, and someone in the -compiler group even used it. Perhaps this deserves to be written up as an issue -too.</p> -</blockquote> - - -<p><b>Rationale:</b></p> -<p>The "key is assignable" requirement from table 69 in -23.1.4 [associative.reqmts] already implies the key cannot be const.</p> - - - - -<hr> -<h3><a name="216"></a>216. setbase manipulator description flawed</h3> -<p><b>Section:</b> 27.6.3 [std.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> - <b>Submitter:</b> Hyman Rosen <b>Date:</b> 2000-02-29</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#std.manip">issues</a> in [std.manip].</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#193">193</a></p> -<p><b>Discussion:</b></p> -<p>27.6.3 [std.manip] paragraph 5 says:</p> -<blockquote> -<pre>smanip setbase(int base);</pre> -<p> Returns: An object s of unspecified type such that if out is an -(instance of) basic_ostream then the expression out<<s behaves -as if f(s) were called, in is an (instance of) basic_istream then the -expression in>>s behaves as if f(s) were called. Where f can be -defined as:</p> -<pre>ios_base& f(ios_base& str, int base) -{ - // set basefield - str.setf(n == 8 ? ios_base::oct : - n == 10 ? ios_base::dec : - n == 16 ? ios_base::hex : - ios_base::fmtflags(0), ios_base::basefield); - return str; -}</pre> -</blockquote> -<p>There are two problems here. First, f takes two parameters, so the -description needs to say that out<<s and in>>s behave as if f(s,base) -had been called. Second, f is has a parameter named base, but is written as if -the parameter was named n.</p> -<p>Actually, there's a third problem. The paragraph has grammatical errors. -There needs to be an "and" after the first comma, and the "Where -f" sentence fragment needs to be merged into its preceding sentence. You -may also want to format the function a little better. The formatting above is -more-or-less what the Standard contains.</p> - - -<p><b>Rationale:</b></p> -<p>The resolution of this defect is subsumed by the proposed resolution for -issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#193">193</a>.</p> - -<p><i>[Tokyo: The LWG agrees that this is a defect and notes that it -occurs additional places in the section, all requiring fixes.]</i></p> - - - - - - - - -<hr> -<h3><a name="218"></a>218. Algorithms do not use binary predicate objects for default comparisons</h3> -<p><b>Section:</b> 25.3 [alg.sorting] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Pablo Halpern <b>Date:</b> 2000-03-06</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.sorting">issues</a> in [alg.sorting].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p>Many of the algorithms take an argument, pred, of template parameter type -BinaryPredicate or an argument comp of template parameter type Compare. These -algorithms usually have an overloaded version that does not take the predicate -argument. In these cases pred is usually replaced by the use of operator== and -comp is replaced by the use of operator<.</p> -<p>This use of hard-coded operators is inconsistent with other parts of the -library, particularly the containers library, where equality is established -using equal_to<> and ordering is established using less<>. Worse, -the use of operator<, would cause the following innocent-looking code to have -undefined behavior:</p> -<blockquote> - <pre>vector<string*> vec; -sort(vec.begin(), vec.end());</pre> -</blockquote> -<p>The use of operator< is not defined for pointers to unrelated objects. If -std::sort used less<> to compare elements, then the above code would be -well-defined, since less<> is explicitly specialized to produce a total -ordering of pointers.</p> - - -<p><b>Rationale:</b></p> -<p>This use of operator== and operator< was a very deliberate, conscious, and -explicitly made design decision; these operators are often more efficient. The -predicate forms are available for users who don't want to rely on operator== and -operator<.</p> - - - - -<hr> -<h3><a name="219"></a>219. find algorithm missing version that takes a binary predicate argument</h3> -<p><b>Section:</b> 25.1.5 [alg.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a> - <b>Submitter:</b> Pablo Halpern <b>Date:</b> 2000-03-06</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find">issues</a> in [alg.find].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p> -<p><b>Discussion:</b></p> -<p>The find function always searches for a value using operator== to compare the -value argument to each element in the input iterator range. This is inconsistent -with other find-related functions such as find_end and find_first_of, which -allow the caller to specify a binary predicate object to be used for determining -equality. The fact that this can be accomplished using a combination of find_if -and bind_1st or bind_2nd does not negate the desirability of a consistent, -simple, alternative interface to find.</p> - - -<p><b>Proposed resolution:</b></p> -<blockquote> -<p>In section 25.1.5 [alg.find], add a second prototype for find -(between the existing prototype and the prototype for find_if), as -follows:</p> -<pre> template<class InputIterator, class T, class BinaryPredicate> - InputIterator find(InputIterator first, InputIterator last, - const T& value, BinaryPredicate bin_pred);</pre> -<p>Change the description of the return from:</p> -<blockquote> - <p>Returns: The first iterator i in the range [first, last) for which the following corresponding - conditions hold: *i == value, pred(*i) != false. Returns last if no such iterator is found.</p> -</blockquote> -<p> to:</p> -<blockquote> - <p>Returns: The first iterator i in the range [first, last) for which the following - corresponding condition holds: *i == value, bin_pred(*i,value) != false, pred(*) - != false. Return last if no such iterator is found.</p> -</blockquote> -</blockquote> - - -<p><b>Rationale:</b></p> -<p>This is request for a pure extension, so it is not a defect in the -current standard. As the submitter pointed out, "this can -be accomplished using a combination of find_if and bind_1st or -bind_2nd".</p> - - - - -<hr> -<h3><a name="236"></a>236. ctype<char>::is() member modifies facet</h3> -<p><b>Section:</b> 22.2.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> - <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2000-04-24</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.ctype.char.members">issues</a> in [facet.ctype.char.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> -<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#28">28</a></p> -<p><b>Discussion:</b></p> -<p>The description of the <tt>is()</tt> member in paragraph 4 of 22.2.1.3.2 [facet.ctype.char.members] is broken: According to this description, the -second form of the <tt>is()</tt> method modifies the masks in the -<tt>ctype</tt> object. The correct semantics if, of course, to obtain -an array of masks. The corresponding method in the general case, -ie. the <tt>do_is()</tt> method as described in 22.2.1.1.2 [locale.ctype.virtuals] paragraph 1 does the right thing.</p> - - -<p><b>Proposed resolution:</b></p> - <p>Change paragraph 4 from</p> - <blockquote><p> - The second form, for all *p in the range [low, high), assigns - vec[p-low] to table()[(unsigned char)*p]. - </p></blockquote> - <p>to become</p> - <blockquote><p> - The second form, for all *p in the range [low, high), assigns - table()[(unsigned char)*p] to vec[p-low]. - </p></blockquote> - - -<p><b>Rationale:</b></p> - - - - - -<hr> -<h3><a name="244"></a>244. Must <tt>find</tt>'s third argument be CopyConstructible?</h3> -<p><b>Section:</b> 25.1.5 [alg.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2000-05-02</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find">issues</a> in [alg.find].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p>Is the following implementation of <tt>find</tt> acceptable?</p> - -<pre> template<class Iter, class X> - Iter find(Iter begin, Iter end, const X& x) - { - X x1 = x; // this is the crucial statement - while (begin != end && *begin != x1) - ++begin; - return begin; - } -</pre> - -<p>If the answer is yes, then it is implementation-dependent as to -whether the following fragment is well formed:</p> - -<pre> vector<string> v; - - find(v.begin(), v.end(), "foo"); -</pre> - -<p>At issue is whether there is a requirement that the third argument -of find be CopyConstructible. There may be no problem here, but -analysis is necessary.</p> - - -<p><b>Rationale:</b></p> -<p>There is no indication in the standard that find's third argument -is required to be Copy Constructible. The LWG believes that no such -requirement was intended. As noted above, there are times when a user -might reasonably pass an argument that is not Copy Constructible.</p> - - - - -<hr> -<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 -iterators trigger input operations. So, for example:</p> - -<pre> istream_iterator<int> i(cin); - - int n = *i++; -</pre> - -<p>I do not think it is specified how many integers have been read -from cin. The number must be at least 1, of course, but can it be 2? -More?</p> - - -<p><b>Rationale:</b></p> -<p>The standard is clear as written: the stream is read every time -operator++ is called, and it is also read either when the iterator is -constructed or when operator* is called for the first time. In the -example above, exactly two integers are read from cin.</p> - -<p>There may be a problem with the interaction between istream_iterator -and some STL algorithms, such as find. There are no guarantees about -how many times find may invoke operator++.</p> - - - - -<hr> -<h3><a name="246"></a>246. <tt>a.insert(p,t)</tt> is incorrectly specified</h3> -<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> - <b>Submitter:</b> Mark Rodgers <b>Date:</b> 2000-05-19</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> -<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a></p> -<p><b>Discussion:</b></p> -<p>Closed issue 192 raised several problems with the specification of -this function, but was rejected as Not A Defect because it was too big -a change with unacceptable impacts on existing implementations. -However, issues remain that could be addressed with a smaller change -and with little or no consequent impact.</p> - -<ol> - <li><p> The specification is inconsistent with the original - proposal and with several implementations.</p> - - <p>The initial implementation by Hewlett Packard only ever looked - immediately <i>before</i> p, and I do not believe there was any - intention to standardize anything other than this behavior. - Consequently, current implementations by several leading - implementors also look immediately before p, and will only insert - after p in logarithmic time. I am only aware of one implementation - that does actually look after p, and it looks before p as well. It - is therefore doubtful that existing code would be relying on the - behavior defined in the standard, and it would seem that fixing - this defect as proposed below would standardize existing - practice.</p></li> - - <li><p> - The specification is inconsistent with insertion for sequence - containers.</p> - - <p>This is difficult and confusing to teach to newcomers. All - insert operations that specify an iterator as an insertion location - should have a consistent meaning for the location represented by - that iterator.</p></li> - - <li><p> As specified, there is no way to hint that the insertion - should occur at the beginning of the container, and the way to hint - that it should occur at the end is long winded and unnatural.</p> - - <p>For a container containing n elements, there are n+1 possible - insertion locations and n+1 valid iterators. For there to be a - one-to-one mapping between iterators and insertion locations, the - iterator must represent an insertion location immediately before - the iterator.</p></li> - - <li><p> When appending sorted ranges using insert_iterators, - insertions are guaranteed to be sub-optimal.</p> - - <p>In such a situation, the optimum location for insertion is - always immediately after the element previously inserted. The - mechanics of the insert iterator guarantee that it will try and - insert after the element after that, which will never be correct. - However, if the container first tried to insert before the hint, - all insertions would be performed in amortized constant - time.</p></li> -</ol> - - -<p><b>Proposed resolution:</b></p> -<p>In 23.1.2 [lib.associative.reqmts] paragraph 7, table 69, make -the following changes in the row for a.insert(p,t):</p> - -<p><i>assertion/note pre/post condition:</i> -<br>Change the last sentence from</p> - <blockquote><p> - "iterator p is a hint pointing to where the insert should - start to search." - </p></blockquote> -<p>to</p> - <blockquote><p> - "iterator p is a hint indicating that immediately before p - may be a correct location where the insertion could occur." - </p></blockquote> - -<p><i>complexity:</i><br> -Change the words "right after" to "immediately before".</p> - - -<p><b>Rationale:</b></p> - - - - - -<hr> -<h3><a name="249"></a>249. Return Type of <tt>auto_ptr::operator=</tt></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> Joseph Gottman <b>Date:</b> 2000-06-30</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#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p>According to section 20.4.5, the function -<tt>auto_ptr::operator=()</tt> returns a reference to an auto_ptr. -The reason that <tt>operator=()</tt> usually returns a reference is to -facilitate code like</p> - -<pre> int x,y,z; - x = y = z = 1; -</pre> - -<p>However, given analogous code for <tt>auto_ptr</tt>s,</p> -<pre> auto_ptr<int> x, y, z; - z.reset(new int(1)); - x = y = z; -</pre> - -<p>the result would be that <tt>z</tt> and <tt>y</tt> would both be set to -NULL, instead of all the <tt>auto_ptr</tt>s being set to the same value. -This makes such cascading assignments useless and counterintuitive for -<tt>auto_ptr</tt>s.</p> - - -<p><b>Proposed resolution:</b></p> -<p>Change <tt>auto_ptr::operator=()</tt> to return <tt>void</tt> instead -of an <tt>auto_ptr</tt> reference.</p> - - -<p><b>Rationale:</b></p> -<p>The return value has uses other than cascaded assignments: a user can -call an auto_ptr member function, pass the auto_ptr to a -function, etc. Removing the return value could break working user -code.</p> - - - - -<hr> -<h3><a name="257"></a>257. STL functional object and iterator inheritance.</h3> -<p><b>Section:</b> 20.6.3 [base], 24.3.2 [iterator.basic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Robert Dick <b>Date:</b> 2000-08-17</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -According to the November 1997 Draft Standard, the results of deleting an -object of a derived class through a pointer to an object of its base class are -undefined if the base class has a non-virtual destructor. Therefore, it is -potentially dangerous to publicly inherit from such base classes. -</p> - -<p>Defect: -<br> -The STL design encourages users to publicly inherit from a number of classes -which do nothing but specify interfaces, and which contain non-virtual -destructors. -</p> - -<p>Attribution: -<br> -Wil Evers and William E. Kempf suggested this modification for functional -objects. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -When a base class in the standard library is useful only as an interface -specifier, i.e., when an object of the class will never be directly -instantiated, specify that the class contains a protected destructor. This -will prevent deletion through a pointer to the base class without performance, -or space penalties (on any implementation I'm aware of). -</p> - -<p> -As an example, replace... -</p> - -<pre> template <class Arg, class Result> - struct unary_function { - typedef Arg argument_type; - typedef Result result_type; - }; -</pre> - -<p> -... with... -</p> - -<pre> template <class Arg, class Result> - struct unary_function { - typedef Arg argument_type; - typedef Result result_type; - protected: - ~unary_function() {} - }; -</pre> - -<p> -Affected definitions: -<br> - 20.3.1 [lib.function.objects] -- unary_function, binary_function - <br> - 24.3.2 [lib.iterator.basic] -- iterator -</p> - - -<p><b>Rationale:</b></p> -<p> -The standard is clear as written; this is a request for change, not a -defect in the strict sense. The LWG had several different objections -to the proposed change. One is that it would prevent users from -creating objects of type <tt>unary_function</tt> and -<tt>binary_function</tt>. Doing so can sometimes be legitimate, if users -want to pass temporaries as traits or tag types in generic code. -</p> - - - - - -<hr> -<h3><a name="267"></a>267. interaction of strstreambuf::overflow() and seekoff()</h3> -<p><b>Section:</b> D.7.1.3 [depr.strstreambuf.virtuals] <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> 2000-10-05</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.strstreambuf.virtuals">issues</a> in [depr.strstreambuf.virtuals].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -It appears that the interaction of the strstreambuf members overflow() -and seekoff() can lead to undefined behavior in cases where defined -behavior could reasonably be expected. The following program -demonstrates this behavior: -</p> - -<pre> #include <strstream> - - int main () - { - std::strstreambuf sb; - sb.sputc ('c'); - - sb.pubseekoff (-1, std::ios::end, std::ios::in); - return !('c' == sb.sgetc ()); - } -</pre> - -<p> -D.7.1.1, p1 initializes strstreambuf with a call to basic_streambuf<>(), -which in turn sets all pointers to 0 in 27.5.2.1, p1. -</p> - -<p> -27.5.2.2.5, p1 says that basic_streambuf<>::sputc(c) calls -overflow(traits::to_int_type(c)) if a write position isn't available (it -isn't due to the above). -</p> - -<p> -D.7.1.3, p3 says that strstreambuf::overflow(off, ..., ios::in) makes at -least one write position available (i.e., it allows the function to make -any positive number of write positions available). -</p> - -<p> -D.7.1.3, p13 computes newoff = seekhigh - eback(). In D.7.1, p4 we see -seekhigh = epptr() ? epptr() : egptr(), or seekhigh = epptr() in this -case. newoff is then epptr() - eback(). -</p> - -<p> -D.7.1.4, p14 sets gptr() so that gptr() == eback() + newoff + off, or -gptr() == epptr() + off holds. -</p> - -<p> -If strstreambuf::overflow() made exactly one write position available -then gptr() will be set to just before epptr(), and the program will -return 0. Buf if the function made more than one write position -available, epptr() and gptr() will both point past pptr() and the -behavior of the program is undefined. -</p> - - -<p><b>Proposed resolution:</b></p> - - - <p>Change the last sentence of D.7.1 [depr.strstreambuf] paragraph 4 from</p> - - <blockquote><p> - Otherwise, seeklow equals gbeg and seekhigh is either pend, if - pend is not a null pointer, or gend. - </p></blockquote> - - <p>to become</p> - - <blockquote><p> - Otherwise, seeklow equals gbeg and seekhigh is either gend if - 0 == pptr(), or pbase() + max where max is the maximum value of - pptr() - pbase() ever reached for this stream. - </p></blockquote> - -<p><i>[ - pre-Copenhagen: Dietmar provided wording for proposed resolution. -]</i></p> - - -<p><i>[ - post-Copenhagen: Fixed a typo: proposed resolution said to fix - 4.7.1, not D.7.1. -]</i></p> - - - - -<p><b>Rationale:</b></p> -<p>This is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#65">65</a>: it's not clear what it -means to seek beyond the current area. Without resolving issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#65">65</a> we can't resolve this. As with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#65">65</a>, -the library working group does not wish to invest time nailing down -corner cases in a deprecated feature.</p> - - - - - -<hr> -<h3><a name="269"></a>269. cstdarg and unnamed parameters</h3> -<p><b>Section:</b> 18.7 [support.exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> J. Stephen Adamczyk <b>Date:</b> 2000-10-10</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.exception">issues</a> in [support.exception].</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> -One of our customers asks whether this is valid C++: -</p> - -<pre> #include <cstdarg> - - void bar(const char *, va_list); - - void - foo(const char *file, const char *, ...) - { - va_list ap; - va_start(ap, file); - bar(file, ap); - va_end(ap); - } -</pre> - -<p> -The issue being whether it is valid to use cstdarg when the final -parameter before the "..." is unnamed. cstdarg is, as far -as I can tell, inherited verbatim from the C standard. and the -definition there (7.8.1.1 in the ISO C89 standard) refers to "the -identifier of the rightmost parameter". What happens when there -is no such identifier? -</p> - -<p> -My personal opinion is that this should be allowed, but some tweak -might be required in the C++ standard. -</p> - - -<p><b>Rationale:</b></p> -<p> -Not a defect, the C and C++ standards are clear. It is impossible to -use varargs if the parameter immediately before "..." has no -name, because that is the parameter that must be passed to va_start. -The example given above is broken, because va_start is being passed -the wrong parameter. -</p> - -<p> -There is no support for extending varargs to provide additional -functionality beyond what's currently there. For reasons of C/C++ -compatibility, it is especially important not to make gratuitous -changes in this part of the C++ standard. The C committee has already -been requested not to touch this part of the C standard unless -necessary. -</p> - - - - -<hr> -<h3><a name="277"></a>277. Normative encouragement in allocator requirements unclear</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#NAD">NAD</a> - <b>Submitter:</b> Matt Austern <b>Date:</b> 2000-11-07</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -In 20.1.5, paragraph 5, the standard says that "Implementors are -encouraged to supply libraries that can accept allocators that -encapsulate more general memory models and that support non-equal -instances." This is intended as normative encouragement to -standard library implementors. However, it is possible to interpret -this sentence as applying to nonstandard third-party libraries. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -In 20.1.5, paragraph 5, change "Implementors" to -"Implementors of the library described in this International -Standard". -</p> - - -<p><b>Rationale:</b></p> -<p>The LWG believes the normative encouragement is already -sufficiently clear, and that there are no important consequences -even if it is misunderstood.</p> - - - - - -<hr> -<h3><a name="279"></a>279. const and non-const iterators should have equivalent typedefs</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#NAD">NAD</a> - <b>Submitter:</b> Steve Cleary <b>Date:</b> 2000-11-27</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#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> - -<p> -This came from an email from Steve Cleary to Fergus in reference to -issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>. The library working group briefly discussed -this in Toronto and believes it should be a separate issue. -</p> - -<p> -Steve said: "We may want to state that the const/non-const iterators must have -the same difference type, size_type, and category." -</p> - -<p> -(Comment from Judy) -I'm not sure if the above sentence should be true for all -const and non-const iterators in a particular container, or if it means -the container's iterator can't be compared with the container's -const_iterator unless the above it true. I suspect the former. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -In <b>Section:</b> 23.1 [container.requirements], -table 65, in the assertion/note pre/post condition for X::const_iterator, -add the following: -</p> - -<blockquote> -<p> -typeid(X::const_iterator::difference_type) == typeid(X::iterator::difference_type) -</p> - -<p> -typeid(X::const_iterator::size_type) == typeid(X::iterator::size_type) -</p> - -<p> -typeid(X::const_iterator::category) == typeid(X::iterator::category) -</p> -</blockquote> - - -<p><b>Rationale:</b></p> -<p>Going through the types one by one: Iterators don't have a -<tt>size_type</tt>. We already know that the difference types are -identical, because the container requirements already say that the -difference types of both X::iterator and X::const_iterator are both -X::difference_type. The standard does not require that X::iterator -and X::const_iterator have the same iterator category, but the LWG -does not see this as a defect: it's possible to imagine cases in which -it would be useful for the categories to be different.</p> - -<p>It may be desirable to require X::iterator and X::const_iterator to -have the same value type, but that is a new issue. (Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#322">322</a>.)</p> - - - - - - -<hr> -<h3><a name="287"></a>287. conflicting ios_base fmtflags</h3> -<p><b>Section:</b> 27.4.2.2 [fmtflags.state] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-12-30</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fmtflags.state">issues</a> in [fmtflags.state].</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 Effects clause for ios_base::setf(fmtflags fmtfl) says -"Sets fmtfl in flags()". What happens if the user first calls -ios_base::scientific and then calls ios_base::fixed or vice-versa? -This is an issue for all of the conflicting flags, i.e. ios_base::left -and ios_base::right or ios_base::dec, ios_base::hex and ios_base::oct. -</p> - -<p> -I see three possible solutions: -</p> - -<ol> -<li>Set ios_base::failbit whenever the user specifies a conflicting -flag with one previously explicitly set. If the constructor is -supposed to set ios_base::dec (see discussion below), then -the user setting hex or oct format after construction will not -set failbit. </li> -<li>The last call to setf "wins", i.e. it clears any conflicting -previous setting.</li> -<li>All the flags that the user specifies are set, but when actually -interpreting them, fixed always override scientific, right always -overrides left, dec overrides hex which overrides oct.</li> -</ol> - -<p> -Most existing implementations that I tried seem to conform to resolution #3, -except that when using the iomanip manipulator hex or oct then that always -overrides dec, but calling setf(ios_base::hex) doesn't. -</p> - -<p> -There is a sort of related issue, which is that although the ios_base -constructor says that each ios_base member has an indeterminate value -after construction, all the existing implementations I tried explicitly set -ios_base::dec. -</p> - - -<p><b>Proposed resolution:</b></p> - - -<p><b>Rationale:</b></p> -<p> -<tt>adjustfield</tt>, <tt>basefield</tt>, and <tt>floatfield</tt> -are each multi-bit fields. It is possible to set multiple bits within -each of those fields. (For example, <tt>dec</tt> and -<tt>oct</tt>). These fields are used by locale facets. The LWG -reviewed the way in which each of those three fields is used, and -believes that in each case the behavior is well defined for any -possible combination of bits. See for example Table 58, in 22.2.2.2.2 -[facet.num.put.virtuals], noting the requirement in paragraph 6 of that -section. -</p> -<p> -Users are advised to use manipulators, or else use the two-argument -version of <tt>setf</tt>, to avoid unexpected behavior. -</p> - - - - - -<hr> -<h3><a name="289"></a>289. <cmath> requirements missing C float and long double versions</h3> -<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-12-30</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> - In ISO/IEC 9899:1990 Programming Languages C we find the following - concerning <math.h>: -</p> - -<blockquote><p> - 7.13.4 Mathematics <math.h> - <br> - The names of all existing functions declared in the <math.h> - header, suffixed with f or l, are reserved respectively for - corresponding functions with float and long double arguments - are return values. -</p></blockquote> - -<p> - For example, <tt>float sinf(float)</tt> - is reserved. -</p> - -<p> - In the C99 standard, <math.h> must contain declarations - for these functions. -</p> - -<p> -So, is it acceptable for an implementor to add these prototypes to the -C++ versions of the math headers? Are they required? -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Add these Functions to Table 80, section 26.5 and to Table 99, -section C.2: -</p> - -<pre> acosf asinf atanf atan2f ceilf cosf coshf - expf fabsf floorf fmodf frexpf ldexpf - logf log10f modff powf sinf sinhf sqrtf - tanf tanhf - acosl asinl atanl atan2l ceill cosl coshl - expl fabsl floorl fmodl frexpl ldexpl - logl log10l modfl powl sinl sinhl sqrtl - tanl tanhl -</pre> - -<p> -There should probably be a note saying that these functions -are optional and, if supplied, should match the description in -the 1999 version of the C standard. In the next round -of C++ standardization they can then become mandatory. -</p> - - -<p><b>Rationale:</b></p> -<p>The C90 standard, as amended, already permits (but does not -require) these functions, and the C++ standard incorporates the -C90 standard by reference. C99 is not an issue, because it is -never referred to by the C++ standard.</p> - - - - - -<hr> -<h3><a name="293"></a>293. Order of execution in transform algorithm</h3> -<p><b>Section:</b> 25.2.4 [alg.transform] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Angelika Langer <b>Date:</b> 2001-01-04</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.transform">issues</a> in [alg.transform].</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>This issue is related to issue 242. In case that the resolution -proposed for issue 242 is accepted, we have have the following -situation: The 4 numeric algorithms (accumulate and consorts) as well -as transform would allow a certain category of side effects. The -numeric algorithms specify that they invoke the functor "for -every iterator i in the range [first, last) in order". transform, -in contrast, would not give any guarantee regarding order of -invocation of the functor, which means that the functor can be invoked -in any arbitrary order. -</p> - -<p>Why would that be a problem? Consider an example: say the -transformator that is a simple enumerator ( or more generally -speaking, "is order-sensitive" ). Since a standard -compliant implementation of transform is free to invoke the enumerator -in no definite order, the result could be a garbled enumeration. -Strictly speaking this is not a problem, but it is certainly at odds -with the prevalent understanding of transform as an algorithms that -assigns "a new _corresponding_ value" to the output -elements. -</p> - -<p>All implementations that I know of invoke the transformator in -definite order, namely starting from first and proceeding to last - -1. Unless there is an optimization conceivable that takes advantage of -the indefinite order I would suggest to specify the order, because it -eliminate the uncertainty that users would otherwise have regarding -the order of execution of their potentially order-sensitive function -objects. -</p> - - -<p><b>Proposed resolution:</b></p> -<p>In section 25.2.3 - Transform [lib.alg.transform] change:</p> -<blockquote><p> --1- Effects: Assigns through every iterator i in the range [result, -result + (last1 - first1)) a new corresponding -value equal to op(*(first1 + (i - result)) or binary_op(*(first1 + -(i - result), *(first2 + (i - result))). -</p></blockquote> -<p>to:</p> -<blockquote><p> --1- Effects: Computes values by invoking the operation op or binary_op -for every iterator in the range [first1, last1) in order. Assigns through -every iterator i in the range [result, result + (last1 - first1)) a new -corresponding -value equal to op(*(first1 + (i - result)) or binary_op(*(first1 + -(i - result), *(first2 + (i - result))). -</p></blockquote> - - -<p><b>Rationale:</b></p> -<p>For Input Iterators an order is already guaranteed, because -only one order is possible. If a user who passes a Forward -Iterator to one of these algorithms really needs a specific -order of execution, it's possible to achieve that effect by -wrapping it in an Input Iterator adaptor.</p> - - - - - -<hr> -<h3><a name="296"></a>296. Missing descriptions and requirements of pair operators</h3> -<p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-01-14</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p>The synopsis of the header <tt><utility></tt> in 20.2 [utility] -lists the complete set of equality and relational operators for <tt>pair</tt> -but the section describing the template and the operators only describes -<tt>operator==()</tt> and <tt>operator<()</tt>, and it fails to mention -any requirements on the template arguments. The remaining operators are -not mentioned at all. -</p> - - -<p><b>Rationale:</b></p> -<p>20.2.1 [operators] paragraph 10 already specifies the semantics. -That paragraph says that, if declarations of operator!=, operator>, -operator<=, and operator>= appear without definitions, they are -defined as specified in 20.2.1 [operators]. There should be no user -confusion, since that paragraph happens to immediately precede the -specification of <tt>pair</tt>.</p> - - - - - -<hr> -<h3><a name="302"></a>302. Need error indication from codecvt<>::do_length</h3> -<p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Gregory Bumgardner <b>Date:</b> 2001-01-25</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</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 effects of <tt>codecvt<>::do_length()</tt> are described in -22.2.1.5.2, paragraph 10. As implied by that paragraph, and clarified -in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#75">75</a>, <tt>codecvt<>::do_length()</tt> must -process the source data and update the <tt>stateT</tt> argument just -as if the data had been processed by <tt>codecvt<>::in()</tt>. -However, the standard does not specify how <tt>do_length()</tt> would -report a translation failure, should the source sequence contain -untranslatable or illegal character sequences. -</p> - -<p> -The other conversion methods return an "error" result value -to indicate that an untranslatable character has been encountered, but -<tt>do_length()</tt> already has a return value (the number of source -characters that have been processed by the method). -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -This issue cannot be resolved without modifying the interface. An exception -cannot be used, as there would be no way to determine how many characters -have been processed and the state object would be left in an indeterminate -state. -</p> - -<p> -A source compatible solution involves adding a fifth argument to length() -and do_length() that could be used to return position of the offending -character sequence. This argument would have a default value that would -allow it to be ignored: -</p> - -<pre> int length(stateT& state, - const externT* from, - const externT* from_end, - size_t max, - const externT** from_next = 0); - - virtual - int do_length(stateT& state, - const externT* from, - const externT* from_end, - size_t max, - const externT** from_next); -</pre> - -<p> -Then an exception could be used to report any translation errors and -the from_next argument, if used, could then be used to retrieve the -location of the offending character sequence. -</p> - - -<p><b>Rationale:</b></p> -<p>The standard is already clear: the return value is the number of -"valid complete characters". If it encounters an invalid sequence of -external characters, it stops.</p> - - - - - -<hr> -<h3><a name="304"></a>304. Must <tt>*a</tt> return an lvalue when <tt>a</tt> is an input iterator?</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#NAD">NAD</a> - <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2001-02-05</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#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -We all "know" that input iterators are allowed to produce -values when dereferenced of which there is no other in-memory copy. -</p> - -<p> -But: Table 72, with a careful reading, seems to imply that this can only be -the case if the value_type has no members (e.g. is a built-in type). -</p> - -<p>The problem occurs in the following entry:</p> - -<pre> a->m pre: (*a).m is well-defined - Equivalent to (*a).m -</pre> - -<p> -<tt>*a.m</tt> can be well-defined if <tt>*a</tt> is not a reference -type, but since <tt>operator->()</tt> must return a pointer for -<tt>a->m</tt> to be well-formed, it needs something to return a -pointer <i>to</i>. This seems to indicate that <tt>*a</tt> must be -buffered somewhere to make a legal input iterator. -</p> - -<p>I don't think this was intentional.</p> - - -<p><b>Rationale:</b></p> -<p>The current standard is clear and consistent. Input iterators that - return rvalues are in fact implementable. They may in some cases - require extra work, but it is still possible to define an operator-> - in such cases: it doesn't have to return a T*, but may return a - proxy type. No change to the standard is justified.</p> - - - - - -<hr> -<h3><a name="313"></a>313. set_terminate and set_unexpected question</h3> -<p><b>Section:</b> 18.7.3.3 [terminate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Judy Ward <b>Date:</b> 2001-04-03</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#terminate">issues</a> in [terminate].</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> -According to section 18.7.3.3 of the standard, std::terminate() is -supposed to call the terminate_handler in effect immediately after -evaluating the throw expression. -</p> - -<p> -Question: what if the terminate_handler in effect is itself -std::terminate? -</p> - -<p>For example:</p> - -<pre> #include <exception> - - int main () { - std::set_terminate(std::terminate); - throw 5; - return 0; - } -</pre> - -<p> -Is the implementation allowed to go into an infinite loop? -</p> - -<p> -I think the same issue applies to std::set_unexpected. -</p> - - -<p><b>Proposed resolution:</b></p> - - -<p><b>Rationale:</b></p> -<p>Infinite recursion is to be expected: users who set the terminate -handler to <tt>terminate</tt> are explicitly asking for <tt>terminate</tt> -to call itself.</p> - - - - - -<hr> -<h3><a name="314"></a>314. Is the stack unwound when terminate() is called?</h3> -<p><b>Section:</b> 18.7.3.3 [terminate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Detlef Vollmann <b>Date:</b> 2001-04-11</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#terminate">issues</a> in [terminate].</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 appears to contradict itself about whether the stack is -unwound when the implementation calls terminate(). -</p> - -<p>From 18.7.3.3p2:</p> -<blockquote><p> - Calls the terminate_handler function in effect immediately - after evaluating the throw-expression (lib.terminate.handler), - if called by the implementation [...] -</p></blockquote> - -<p>So the stack is guaranteed not to be unwound.</p> - -<p>But from 15.3p9:</p> -<blockquote><p> - [...]whether or not the stack is unwound before this call - to terminate() is implementation-defined (except.terminate). -</p></blockquote> - -<p> -And 15.5.1 actually defines that in most cases the stack is unwound. -</p> - - -<p><b>Proposed resolution:</b></p> - - -<p><b>Rationale:</b></p> -<p>There is definitely no contradiction between the core and library -clauses; nothing in the core clauses says that stack unwinding happens -after <tt>terminate</tt> is called. 18.7.3.3p2 does not say anything -about when terminate() is called; it merely specifies which -<tt>terminate_handler</tt> is used.</p> - - - - - -<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">NAD</a> - <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2001-06-04</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p>Currently the standard mandates the following overloads of -abs():</p> - -<pre> abs(long), abs(int) in <cstdlib> - - abs(float), abs(double), abs(long double) in <cmath> - - template<class T> T abs(const complex<T>&) in <complex> - - template<class T> valarray<T> abs(const valarray<T>&); in <valarray> -</pre> - -<p> -The problem is that having only some overloads visible of a function -that works on "implicitly inter-convertible" types is dangerous in -practice. The headers that get included at any point in a translation -unit can change unpredictably during program -development/maintenance. The wrong overload might be unintentionally -selected. -</p> - -<p> -Currently, there is nothing that mandates the simultaneous visibility -of these overloads. Indeed, some vendors have begun fastidiously -reducing dependencies among their (public) headers as a QOI issue: it -helps people to write portable code by refusing to compile unless all -the correct headers are #included. -</p> - -<p>The same issue may exist for other functions in the library.</p> - -<p>Redmond: PJP reports that C99 adds two new kinds of abs: complex, -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> -<p>The programs that could potentially be broken by this situation are - already fragile, and somewhat contrived: For example, a user-defined - class that has conversion overloads both to <tt>long</tt> and - to <tt>float</tt>. If <tt>x</tt> is a value of such a class, then - <tt>abs(x)</tt> would give the <tt>long</tt> version if the user - included <cstdlib>, the <tt>float</tt> version if the user - included <cmath>, and would be diagnosed as ambiguous at - compile time if the user included both headers. The LWG couldn't - find an example of a program whose meaning would be changed (as - opposed to changing it from well-formed to ill-formed) simply by - adding another standard header.</p> - -<p>Since the harm seems minimal, and there don't seem to be any simple - and noninvasive solutions, this is being closed as NAD. It is - marked as "Future" for two reasons. First, it might be useful to - define an <tt><all></tt> header that would include all - Standard Library headers. Second, we should at least make sure that - future library extensions don't make this problem worse.</p> - - - - - -<hr> -<h3><a name="326"></a>326. Missing typedef in moneypunct_byname</h3> -<p><b>Section:</b> 22.2.6.4 [locale.moneypunct.byname] <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> 2001-07-05</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 definition of the moneypunct facet contains the typedefs char_type -and string_type. Only one of these names, string_type, is defined in -the derived facet, moneypunct_byname.</p> - - -<p><b>Proposed resolution:</b></p> -<p>For consistency with the numpunct facet, add a typedef for -char_type to the definition of the moneypunct_byname facet in -22.2.6.4 [locale.moneypunct.byname].</p> - - -<p><b>Rationale:</b></p> -<p>The absence of the typedef is irrelevant. Users can still access -the typedef, because it is inherited from the base class.</p> - - - - - -<hr> -<h3><a name="330"></a>330. Misleading "exposition only" value in class locale definition</h3> -<p><b>Section:</b> 22.1.1 [locale] <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> 2001-07-15</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</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 "exposition only" value of the std::locale::none constant shown in -the definition of class locale is misleading in that it on many -systems conflicts with the value assigned to one if the LC_XXX -constants (specifically, LC_COLLATE on AIX, LC_ALL on HP-UX, LC_CTYPE -on Linux and SunOS). This causes incorrect behavior when such a -constant is passed to one of the locale member functions that accept a -locale::category argument and interpret it as either the C LC_XXX -constant or a bitmap of locale::category values. At least three major -implementations adopt the suggested value without a change and -consequently suffer from this problem. -</p> - -<p> -For instance, the following code will (presumably) incorrectly copy facets -belonging to the collate category from the German locale on AIX: -</p> - -<pre> std::locale l (std::locale ("C"), "de_DE", std::locale::none); -</pre> - - -<p><b>Rationale:</b></p> -<p>The LWG agrees that it may be difficult to implement locale member -functions in such a way that they can take either <tt>category</tt> -arguments or the LC_ constants defined in <cctype>. In light of -this requirement (22.1.1.1.1 [locale.category], paragraph 2), and in light -of the requirement in the preceding paragraph that it is possible to -combine <tt>category</tt> bitmask elements with bitwise operations, -defining the <tt>category</tt> elements is delicate, -particularly if an implementor is constrained to work with a -preexisting C library. (Just using the existing LC_ constants would -not work in general.) There's no set of "exposition only" values that -could give library implementors proper guidance in such a delicate -matter. The non-normative example we're giving is no worse than -any other choice would be.</p> - -<p>See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#347">347</a>.</p> - - - - - -<hr> -<h3><a name="332"></a>332. Consider adding increment and decrement operators to std::fpos< T > </h3> -<p><b>Section:</b> 27.4.3 [fpos] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> PremAnand M. Rao <b>Date:</b> 2001-08-27</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fpos">issues</a> in [fpos].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -Increment and decrement operators are missing from -Table 88 -- Position type requirements in 27.4.3 [fpos]. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Table 88 (section 27.4.3) -- Position type requirements -be updated to include increment and decrement operators. -</p> - -<pre>expression return type operational note - -++p fpos& p += O(1) -p++ fpos { P tmp = p; - ++p; - return tmp; } ---p fpos& p -= O(1) -p-- fpos { P tmp = p; - --p; - return tmp; } -</pre> - - - -<p><b>Rationale:</b></p> -<p>The LWG believes this is a request for extension, not a defect -report. Additionally, nobody saw a clear need for this extension; -<tt>fpos</tt> is used only in very limited ways.</p> - - - - - -<hr> -<h3><a name="344"></a>344. grouping + showbase</h3> -<p><b>Section:</b> 22.2.2 [category.numeric] <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> 2001-10-13</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> -When both grouping and showbase are active and the basefield is octal, -does the leading 0 participate in the grouping or not? For example, -should one format as: 0,123,456 or 0123,456? -</p> -<p> -An analogy can be drawn with hexadecimal. It appears that 0x123,456 is -preferred over 0x,123,456. However, this analogy is not universally -accepted to apply to the octal base. The standard is not clear on how -to format (or parse) in this manner. -</p> - -<p><b>Proposed resolution:</b></p> -<p> -Insert into 22.2.3.1.2 [facet.numpunct.virtuals] paragraph 3, just before the last -sentence: -</p> -<blockquote><p> -The leading hexadecimal base specifier "0x" does not participate in -grouping. The leading '0' octal base specifier may participate in -grouping. It is unspecified if the leading '0' participates in -formatting octal numbers. In parsing octal numbers, the implementation -is encouraged to accept both the leading '0' participating in the -grouping, and not participating (e.g. 0123,456 or 0,123,456). -</p></blockquote> - -<p><b>Rationale:</b></p> -<p> -The current behavior may be unspecified, but it's not clear that it -matters. This is an obscure corner case, since grouping is usually -intended for the benefit of humans and oct/hex prefixes are usually -intended for the benefit of machines. There is not a strong enough -consensus in the LWG for action. -</p> - - - - -<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#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#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. -</p> - - -<p><b>Proposed resolution:</b></p> -<p>In 20.2.3 [pairs] paragraph 6, replace:</p> -<pre> Returns: x.first < y.first || (!(y.first < x.first) && x.second < - y.second). -</pre> -<p>With:</p> -<pre> Returns: std::less<T1>()( x.first, y.first ) || - (!std::less<T1>()( y.first, x.first) && - std::less<T2>()( x.second, y.second ) ) -</pre> - - - -<p><b>Rationale:</b></p> -<p>This is an instance of a much more general problem. If we want - operator< to translate to std::less for pairs of pointers, where - do we draw the line? The same issue applies to individual - pointers, smart pointer wrappers, std::vector<T*>, and so - on.</p> - -<p>Andy Koenig suggests that the real issue here is that we aren't - distinguishing adequately between two different orderings, a - "useful ordering" and a "canonical ordering" that's used just - because we sometimes need <i>some</i> ordering without caring much - which ordering it is. Another example of the later is typeinfo's - <tt>before</tt>.</p> - - - - - - -<hr> -<h3><a name="350"></a>350. allocator<>::address</h3> -<p><b>Section:</b> 20.7.5.1 [allocator.members], 20.1.2 [allocator.requirements], 17.4.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> - <b>Submitter:</b> Nathan Myers <b>Date:</b> 2001-10-25</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> -<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a></p> -<p><b>Discussion:</b></p> -<p>See c++std-lib-9006 and c++std-lib-9007. This issue is taken -verbatim from -9007.</p> - -<p> -The core language feature allowing definition of operator&() applied -to any non-builtin type makes that operator often unsafe to use in -implementing libraries, including the Standard Library. The result -is that many library facilities fail for legal user code, such as -the fragment</p> -<pre> class A { private: A* operator&(); }; - std::vector<A> aa; - - class B { }; - B* operator&(B&) { return 0; } - std::vector<B> ba; -</pre> - -<p> -In particular, the requirements table for Allocator (Table 32) specifies -no semantics at all for member address(), and allocator<>::address is -defined in terms of unadorned operator &. -</p> - - - -<p><b>Proposed resolution:</b></p> -<p> -In 20.6.1.1, Change the definition of allocator<>::address from:</p> -<blockquote><p> - Returns: &x -</p></blockquote> - -<p>to:</p> - -<p> - Returns: The value that the built in operator&(x) would return if not - overloaded. -</p> - -<p> -In 20.1.6, Table 32, add to the Notes column of the a.address(r) and -a.address(s) lines, respectively: -</p> - -<pre> allocator<T>::address(r) - allocator<T>::address(s) -</pre> - -<p>In addition, in clause 17.4.1.1, add a statement:</p> - -<blockquote><p> - The Standard Library does not apply operator& to any type for which - operator& may be overloaded. -</p></blockquote> - - - -<p><b>Rationale:</b></p> -<p>The LWG believes both examples are ill-formed. The contained type -is required to be CopyConstructible (20.1.1 [utility.arg.requirements]), and that -includes the requirement that &t return the usual types and -values. Since allocators are intended to be used in conjunction with -containers, and since the CopyConstructible requirements appear to -have been written to deal with the concerns of this issue, the LWG -feels it is NAD unless someone can come up with a well-formed example -exhibiting a problem.</p> - -<p>It may well be that the CopyConstructible requirements are too - restrictive and that either the container requirements or the - CopyConstructive requirements should be relaxed, but that's a far - larger issue. Marking this issue as "future" as a pointer to that - larger issue.</p> - - - - - -<hr> -<h3><a name="351"></a>351. unary_negate and binary_negate: struct or class?</h3> -<p><b>Section:</b> 20.6 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> - <b>Submitter:</b> Dale Riley <b>Date:</b> 2001-11-12</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -In 20.6 [function.objects] the header <functional> synopsis declares -the unary_negate and binary_negate function objects as struct. -However in 20.6.10 [negators] the unary_negate and binary_negate -function objects are defined as class. Given the context, they are -not "basic function objects" like negate, so this is either a typo or -an editorial oversight. -</p> - -<p><i>[Taken from comp.std.c++]</i></p> - - - -<p><b>Proposed resolution:</b></p> -<p>Change the synopsis to reflect the useage in 20.6.10 [negators]</p> - -<p><i>[Curaçao: Since the language permits "struct", the LWG -views this as NAD. They suggest, however, that the Project Editor -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%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%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 -no template assignment operator. This may lead to inefficient code since -assigning an object of <tt>pair<C, D></tt> to <tt>pair<A, B></tt> -where the types <tt>C</tt> and <tt>D</tt> are distinct from but convertible to -<tt>A</tt> and <tt>B</tt>, respectively, results in a call to the template copy -ctor to construct an unnamed temporary of type <tt>pair<A, B></tt> -followed by an ordinary (perhaps implicitly defined) assignment operator, -instead of just a straight assignment. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Add the following declaration to the definition of <tt>std::pair</tt>: -</p> -<pre> template<class U, class V> - pair& operator=(const pair<U, V> &p); -</pre> -<p> -And also add a paragraph describing the effects of the function template to the -end of 20.2.2: -</p> -<pre> template<class U, class V> - pair& operator=(const pair<U, V> &p); -</pre> -<p> - <b>Effects</b>: <tt>first = p.first;</tt> - <tt>second = p.second;</tt> - <b>Returns</b>: <tt>*this</tt> -</p> - -<p><i>[Curaçao: There is no indication this is was anything other than -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> - - - - - - -<hr> -<h3><a name="356"></a>356. Meaning of ctype_base::mask enumerators</h3> -<p><b>Section:</b> 22.2.1 [category.ctype] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Matt Austern <b>Date:</b> 2002-01-23</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#category.ctype">issues</a> in [category.ctype].</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>What should the following program print?</p> - -<pre> #include <locale> - #include <iostream> - - class my_ctype : public std::ctype<char> - { - typedef std::ctype<char> base; - public: - my_ctype(std::size_t refs = 0) : base(my_table, false, refs) - { - std::copy(base::classic_table(), base::classic_table() + base::table_size, - my_table); - my_table[(unsigned char) '_'] = (base::mask) (base::print | base::space); - } - private: - mask my_table[base::table_size]; - }; - - int main() - { - my_ctype ct; - std::cout << "isspace: " << ct.is(std::ctype_base::space, '_') << " " - << "isalpha: " << ct.is(std::ctype_base::alpha, '_') << std::endl; - } -</pre> - -<p>The goal is to create a facet where '_' is treated as whitespace.</p> - -<p>On gcc 3.0, this program prints "isspace: 1 isalpha: 0". On -Microsoft C++ it prints "isspace: 1 isalpha: 1".</p> - -<p> -I believe that both implementations are legal, and the standard does not -give enough guidance for users to be able to use std::ctype's -protected interface portably.</p> - -<p> -The above program assumes that ctype_base::mask enumerators like -<tt>space</tt> and <tt>print</tt> are disjoint, and that the way to -say that a character is both a space and a printing character is to or -those two enumerators together. This is suggested by the "exposition -only" values in 22.2.1 [category.ctype], but it is nowhere specified in -normative text. An alternative interpretation is that the more -specific categories subsume the less specific. The above program -gives the results it does on the Microsoft compiler because, on that -compiler, <tt>print</tt> has all the bits set for each specific -printing character class. -</p> - -<p>From the point of view of std::ctype's public interface, there's no -important difference between these two techniques. From the point of -view of the protected interface, there is. If I'm defining a facet -that inherits from std::ctype<char>, I'm the one who defines the -value that table()['a'] returns. I need to know what combination of -mask values I should use. This isn't so very esoteric: it's exactly -why std::ctype has a protected interface. If we care about users -being able to write their own ctype facets, we have to give them a -portable way to do it. -</p> - -<p> -Related reflector messages: -lib-9224, lib-9226, lib-9229, lib-9270, lib-9272, lib-9273, lib-9274, -lib-9277, lib-9279. -</p> - -<p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a> is related, but not identical. The -proposed resolution if issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a> says that -ctype_base::mask must be a bitmask type. It does not say that the -ctype_base::mask elements are bitmask elements, so it doesn't -directly affect this issue.</p> - -<p>More comments from Benjamin Kosnik, who believes that -that C99 compatibility essentially requires what we're -calling option 1 below.</p> - -<blockquote> -<pre>I think the C99 standard is clear, that isspace -> !isalpha. --------- - -#include <locale> -#include <iostream> - -class my_ctype : public std::ctype<char> -{ -private: - typedef std::ctype<char> base; - mask my_table[base::table_size]; - -public: - my_ctype(std::size_t refs = 0) : base(my_table, false, refs) - { - std::copy(base::classic_table(), base::classic_table() + base::table_size, - my_table); - mask both = base::print | base::space; - my_table[static_cast<mask>('_')] = both; - } -}; - -int main() -{ - using namespace std; - my_ctype ct; - cout << "isspace: " << ct.is(ctype_base::space, '_') << endl; - cout << "isprint: " << ct.is(ctype_base::print, '_') << endl; - - // ISO C99, isalpha iff upper | lower set, and !space. - // 7.5, p 193 - // -> looks like g++ behavior is correct. - // 356 -> bitmask elements are required for ctype_base - // 339 -> bitmask type required for mask - cout << "isalpha: " << ct.is(ctype_base::alpha, '_') << endl; -} -</pre> -</blockquote> - - - -<p><b>Proposed resolution:</b></p> -<p>Informally, we have three choices:</p> -<ol> -<li>Require that the enumerators are disjoint (except for alnum and -graph)</li> -<li>Require that the enumerators are not disjoint, and specify which -of them subsume which others. (e.g. mandate that lower includes alpha -and print)</li> -<li>Explicitly leave this unspecified, which the result that the above -program is not portable.</li> -</ol> - -<p>Either of the first two options is just as good from the standpoint -of portability. Either one will require some implementations to -change.</p> - - -<p><b>Rationale:</b></p> -<p>The LWG agrees that this is a real ambiguity, and that both -interpretations are conforming under the existing standard. However, -there's no evidence that it's causing problems for real users. Users -who want to define ctype facets portably can test the ctype_base masks -to see which interpretation is being used.</p> - - - - - -<hr> -<h3><a name="357"></a>357. <cmath> float functions cannot return HUGE_VAL</h3> -<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> - <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-02-26</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -The float versions of the math functions have no meaningful value to return -for a range error. The long double versions have a value they can return, -but it isn't necessarily the most reasonable value. -</p> - -<p> -Section 26.5 [lib.c.math], paragraph 5, says that C++ "adds float and long -double overloaded versions of these functions, with the same semantics," -referring to the math functions from the C90 standard. -</p> - -<p> -The C90 standard, in section 7.5.1, paragraph 3, says that functions return -"the value of the macro HUGE_VAL" when they encounter a range error. -Section 7.5, paragraph 2, defines HUGE_VAL as a macro that "expands to a -positive double expression, not necessarily representable as a float." -</p> - -<p> -Therefore, the float versions of the math functions have no way to -signal a range error. <i>[Curaçao: The LWG notes that this isn't -strictly correct, since errno is set.]</i> The semantics require that they -return HUGE_VAL, but they cannot because HUGE_VAL might not be -representable as a float. -</p> - -<p> -The problem with long double functions is less severe because HUGE_VAL is -representable as a long double. On the other hand, it might not be a "huge" -long double value, and might fall well within the range of normal return -values for a long double function. Therefore, it does not make sense for a -long double function to return a double (HUGE_VAL) for a range error. -</p> - - -<p><b>Proposed resolution:</b></p> -<p>Curaçao: C99 was faced with a similar problem, which they fixed by -adding HUGE_VALF and HUGE_VALL in addition to HUGE_VAL.</p> - -<p>C++ must also fix, but it should be done in the context of the -general C99 based changes to C++, not via DR. Thus the LWG in Curaçao -felt the resolution should be NAD, FUTURE, but the issue is being held -open for one more meeting to ensure LWG members not present during the -discussion concur.</p> - - -<p><b>Rationale:</b></p> -<p>Will be fixed as part of more general work in the TR.</p> - - - - - -<hr> -<h3><a name="361"></a>361. num_get<>::do_get (..., void*&) checks grouping</h3> -<p><b>Section:</b> 22.2.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-03-12</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.put.virtuals">issues</a> in [facet.num.put.virtuals].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -22.2.2.2.2, p12 specifies that <tt>thousands_sep</tt> is to be inserted only -for integral types (issue 282 suggests that this should be done for -all arithmetic types). -</p> - -<p> -22.2.2.1.2, p12 requires that grouping be checked for all extractors -including that for <tt>void*</tt>. -</p> - -<p> -I don't think that's right. <tt>void*</tt> values should not be checked for -grouping, should they? (Although if they should, then <tt>num_put</tt> needs -to write them out, otherwise their extraction will fail.) -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Change the first sentence of 22.2.2.2.2, p12 from -</p> -<blockquote><p> - Digit grouping is checked. That is, the positions of discarded - separators is examined for consistency with - use_facet<numpunct<charT> >(loc).grouping(). - If they are not consistent then ios_base::failbit is assigned - to err. -</p></blockquote> - -<p>to</p> -<blockquote><p> - Except for conversions to void*, digit grouping is checked... -</p></blockquote> - - - -<p><b>Rationale:</b></p> -<p>This would be a change: as it stands, the standard clearly - specifies that grouping applies to void*. A survey of existing - practice shows that most existing implementations do that, as they - should.</p> - - - - - -<hr> -<h3><a name="366"></a>366. Excessive const-qualification</h3> -<p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Walter Brown, Marc Paterno <b>Date:</b> 2002-05-10</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -The following member functions are declared const, yet return non-const -pointers. We believe they are should be changed, because they allow code -that may surprise the user. See document N1360 for details and -rationale. -</p> - -<p><i>[Santa Cruz: the real issue is that we've got const member -functions that return pointers to non-const, and N1360 proposes -replacing them by overloaded pairs. There isn't a consensus about -whether this is a real issue, since we've never said what our -constness policy is for iostreams. N1360 relies on a distinction -between physical constness and logical constness; that distinction, or -those terms, does not appear in the standard.]</i></p> - - - - -<p><b>Proposed resolution:</b></p> -<p>In 27.4.4 and 27.4.4.2</p> -<p>Replace</p> -<pre> basic_ostream<charT,traits>* tie() const; -</pre> -<p>with</p> -<pre> basic_ostream<charT,traits>* tie(); - const basic_ostream<charT,traits>* tie() const; -</pre> - -<p>and replace</p> -<pre> basic_streambuf<charT,traits>* rdbuf() const; -</pre> -<p>with</p> -<pre> basic_streambuf<charT,traits>* rdbuf(); - const basic_streambuf<charT,traits>* rdbuf() const; -</pre> - -<p>In 27.5.2 and 27.5.2.3.1</p> -<p>Replace</p> -<pre> char_type* eback() const; -</pre> -<p>with</p> -<pre> char_type* eback(); - const char_type* eback() const; -</pre> - -<p>Replace</p> -<pre> char_type gptr() const; -</pre> -<p>with</p> -<pre> char_type* gptr(); - const char_type* gptr() const; -</pre> - -<p>Replace</p> -<pre> char_type* egptr() const; -</pre> -<p>with</p> -<pre> char_type* egptr(); - const char_type* egptr() const; -</pre> - -<p>In 27.5.2 and 27.5.2.3.2</p> -<p>Replace</p> -<pre> char_type* pbase() const; -</pre> -<p>with</p> -<pre> char_type* pbase(); - const char_type* pbase() const; -</pre> - -<p>Replace</p> -<pre> char_type* pptr() const; -</pre> -<p>with</p> -<pre> char_type* pptr(); - const char_type* pptr() const; -</pre> - -<p>Replace</p> -<pre> char_type* epptr() const; -</pre> -<p>with</p> -<pre> char_type* epptr(); - const char_type* epptr() const; -</pre> - -<p>In 27.7.2, 27.7.2.2, 27.7.3 27.7.3.2, 27.7.4, and 27.7.6</p> -<p>Replace</p> -<pre> basic_stringbuf<charT,traits,Allocator>* rdbuf() const; -</pre> -<p>with</p> -<pre> basic_stringbuf<charT,traits,Allocator>* rdbuf(); - const basic_stringbuf<charT,traits,Allocator>* rdbuf() const; -</pre> - -<p>In 27.8.1.5, 27.8.1.7, 27.8.1.8, 27.8.1.10, 27.8.1.11, and 27.8.1.13</p> -<p>Replace</p> -<pre> basic_filebuf<charT,traits>* rdbuf() const; -</pre> -<p>with</p> -<pre> basic_filebuf<charT,traits>* rdbuf(); - const basic_filebuf<charT,traits>* rdbuf() const; -</pre> - - -<p><b>Rationale:</b></p> -<p>The existing specification is a bit sloppy, but there's no - particular reason to change this other than tidiness, and there are - a number of ways in which streams might have been designed - differently if we were starting today. There's no evidence that the - existing constness policy is harming users. We might consider - a different constness policy as part of a full stream redesign.</p> - - - - - -<hr> -<h3><a name="367"></a>367. remove_copy/remove_copy_if and Input Iterators</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#NAD">NAD</a> - <b>Submitter:</b> Anthony Williams <b>Date:</b> 2002-05-13</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#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -remove_copy and remove_copy_if (25.2.8 [alg.remove]) permit their -input range to be marked with Input Iterators. However, since two -operations are required against the elements to copy (comparison and -assigment), when the input range uses Input Iterators, a temporary -copy must be taken to avoid dereferencing the iterator twice. This -therefore requires the value type of the InputIterator to be -CopyConstructible. If the iterators are at least Forward Iterators, -then the iterator can be dereferenced twice, or a reference to the -result maintained, so the temporary is not required. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Add "If InputIterator does not meet the requirements of forward -iterator, then the value type of InputIterator must be copy -constructible. Otherwise copy constructible is not required." to -25.2.8 [alg.remove] paragraph 6. -</p> - - -<p><b>Rationale:</b></p> -<p>The assumption is that an input iterator can't be dereferenced - twice. There's no basis for that assumption in the Standard.</p> - - - - - -<hr> -<h3><a name="368"></a>368. basic_string::replace has two "Throws" paragraphs</h3> -<p><b>Section:</b> 21.3.6.6 [string::replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> - <b>Submitter:</b> Beman Dawes <b>Date:</b> 2002-06-03</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -21.3.6.6 [string::replace] basic_string::replace, second -signature, given in paragraph 1, has two "Throws" paragraphs (3 and -5). -</p> - -<p> -In addition, the second "Throws" paragraph (5) includes specification -(beginning with "Otherwise, the function replaces ...") that should be -part of the "Effects" paragraph. -</p> - - -<p><b>Proposed resolution:</b></p> - - -<p><b>Rationale:</b></p> -<p>This is editorial. Both "throws" statements are true. The bug is - just that the second one should be a sentence, part of the "Effects" - clause, not a separate "Throws". The project editor has been - notified.</p> - - - - - -<hr> -<h3><a name="372"></a>372. Inconsistent description of stdlib exceptions</h3> -<p><b>Section:</b> 17.4.4.9 [res.on.exception.handling], 18.6.1 [type.info] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Randy Maddox <b>Date:</b> 2002-07-22</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.exception.handling">issues</a> in [res.on.exception.handling].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> - -<p>Paragraph 3 under clause 17.4.4.9 [res.on.exception.handling], Restrictions on -Exception Handling, states that "Any other functions defined in the -C++ Standard Library that do not have an exception-specification may -throw implementation-defined exceptions unless otherwise specified." -This statement is followed by a reference to footnote 178 at the -bottom of that page which states, apparently in reference to the C++ -Standard Library, that "Library implementations are encouraged (but -not required) to report errors by throwing exceptions from (or derived -from) the standard exceptions."</p> - -<p>These statements appear to be in direct contradiction to clause -18.6.1 [type.info], which states "The class exception defines the -base class for the types of objects thrown as exceptions by the C++ -Standard library components ...".</p> - -<p>Is this inconsistent?</p> - - - -<p><b>Proposed resolution:</b></p> - - -<p><b>Rationale:</b></p> -<p>Clause 17 is setting the overall library requirements, and it's - clear and consistent. This sentence from Clause 18 is descriptive, - not setting a requirement on any other class. -</p> - - - - - -<hr> -<h3><a name="374"></a>374. moneypunct::frac_digits returns int not unsigned</h3> -<p><b>Section:</b> 22.2.6.3.1 [locale.moneypunct.members], 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#NAD">NAD</a> - <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-08-08</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 22.2.6.3.1 [locale.moneypunct.members], frac_digits() returns type -"int". This implies that frac_digits() might return a negative value, -but a negative value is nonsensical. It should return "unsigned". -</p> - -<p> -Similarly, in section 22.2.6.3.2 [locale.moneypunct.virtuals], do_frac_digits() -should return "unsigned". -</p> - - - -<p><b>Proposed resolution:</b></p> - - -<p><b>Rationale:</b></p> -<p>Regardless of whether the return value is int or unsigned, it's -always conceivable that frac_digits might return a nonsensical -value. (Is 4294967295 really any better than -1?) The clients of -moneypunct, the get and put facets, can and do perform range -checks.</p> - - - - - -<hr> -<h3><a name="377"></a>377. basic_string::insert and length_error</h3> -<p><b>Section:</b> 21.3.6.4 [string::insert] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-08-16</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::insert">issues</a> in [string::insert].</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> -Section 21.3.6.4 [string::insert], paragraph 4, contains the following, -"Then throws length_error if size() >= npos - rlen." -</p> - -<p> -Related to DR 83, this sentence should probably be removed. -</p> - - -<p><b>Proposed resolution:</b></p> - - -<p><b>Rationale:</b></p><p>This requirement is redundant but correct. No change is -needed.</p> - - - - -<hr> -<h3><a name="378"></a>378. locale immutability and locale::operator=()</h3> -<p><b>Section:</b> 22.1.1 [locale] <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> 2002-09-06</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</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#31">31</a></p> -<p><b>Discussion:</b></p> -<p> -I think there is a problem with 22.1.1, p6 which says that -</p> -<pre> -6- An instance of locale is immutable; once a facet reference - is obtained from it, that reference remains usable as long - as the locale value itself exists. -</pre> -<p> -and 22.1.1.2, p4: -</p> -<pre> const locale& operator=(const locale& other) throw(); - - -4- Effects: Creates a copy of other, replacing the current value. -</pre> -<p> -How can a reference to a facet obtained from a locale object remain -valid after an assignment that clearly must replace all the facets -in the locale object? Imagine a program such as this -</p> -<pre> std::locale loc ("de_DE"); - const std::ctype<char> &r0 = std::use_facet<std::ctype<char> >(loc); - loc = std::locale ("en_US"); - const std::ctype<char> &r1 = std::use_facet<std::ctype<char> >(loc); -</pre> -<p> -Is r0 really supposed to be preserved and destroyed only when loc goes -out of scope? -</p> - - -<p><b>Proposed resolution:</b></p> -<p><i>[Summer '04 mid-meeting mailing: Martin and Dietmar believe this - is a duplicate of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a> and recommend that it be - closed. -]</i></p> - - - - - - -<hr> -<h3><a name="385"></a>385. Does call by value imply the CopyConstructible requirement?</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">NAD</a> - <b>Submitter:</b> Matt Austern <b>Date:</b> 2002-10-23</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -Many function templates have parameters that are passed by value; -a typical example is <tt>find_if</tt>'s <i>pred</i> parameter in -25.1.5 [alg.find]. Are the corresponding template parameters -(<tt>Predicate</tt> in this case) implicitly required to be -CopyConstructible, or does that need to be spelled out explicitly? -</p> - -<p> -This isn't quite as silly a question as it might seem to be at first -sight. If you call <tt>find_if</tt> in such a way that template -argument deduction applies, then of course you'll get call by value -and you need to provide a copy constructor. If you explicitly provide -the template arguments, however, you can force call by reference by -writing something like <tt>find_if<my_iterator, -my_predicate&></tt>. The question is whether implementation -are required to accept this, or whether this is ill-formed because -my_predicate& is not CopyConstructible. -</p> - -<p> -The scope of this problem, if it is a problem, is unknown. Function -object arguments to generic algorithms in clauses 25 [algorithms] -and 26 [numerics] are obvious examples. A review of the whole -library is necessary. -</p> -<p><i>[ -This is really two issues. First, predicates are typically passed by -value but we don't say they must be Copy Constructible. They should -be. Second: is specialization allowed to transform value arguments -into references? References aren't copy constructible, so this should -not be allowed. -]</i></p> - -<p><i>[ -2007-01-12, Howard: First, despite the note above, references <b>are</b> -copy constructible. They just aren't assignable. Second, this is very -closely related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a> and should be consistent with that. -That issue already says that implementations are allowed to copy -function objects. If one passes in a reference, it is copyable, but -susceptible to slicing if one passes in a reference to a base. Third, -with rvalue reference in the language one only needs to satisfy -MoveConstructible to pass an rvalue "by value". Though the function -might still copy the function object internally (requiring -CopyConstructible). Finally (and fwiw), if we wanted to, it is easy to -code all of the std::algorithms such that they do not copy function -objects internally. One merely passes them by reference internally if -desired (this has been fully implemented and shipped for several years). - If this were mandated, it would reverse <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>, allowing -function objects to reliably maintain state. E.g. the example in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a> would reliably remove only the third element. -]</i></p> - - - -<p><b>Proposed resolution:</b></p> -<p> -Recommend NAD. -</p> - - -<p><b>Rationale:</b></p> -<p> -Generic algorithms will be marked with concepts and these will imply a requirement -of MoveConstructible (not CopyConstructible). The signature of the function will -then precisely describe and enforce the precise requirements. -</p> - - - - - -<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">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">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -Practice with std::complex<> and the associative containers -occasionally reveals artificial and distracting issues with constructs -resembling: std::set<std::complex<double> > s; -</p> - -<p> -The main reason for the above to fail is the absence of an approriate -definition for std::less<std::complex<T> >. That in turn comes from -the definition of the primary template std::less<> in terms of -operator<. -</p> - -<p> -The usual argument goes as follows: Since there is no ordering over -the complex field compatible with field operations it makes little -sense to define a function operator< operating on the datatype -std::complex<T>. That is fine. However, that reasoning does not carry -over to std::less<T> which is used, among other things, by associative -containers as an ordering useful to meet complexity requirements. -</p> - -<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> -<p>Informally: Add a specialization of std::less for std::complex.</p> - - -<p><b>Rationale:</b></p> -<p>Discussed in Santa Cruz. An overwhelming majority of the LWG -believes this should not be treated a DR: it's a request for a design -change, not a defect in the existing standard. Most people (10-3) -believed that we probably don't want this change, period: as with -issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, it's hard to know where to draw the line. -The LWG noted that users who want to put objects into an associative -container for which <tt>operator<</tt> isn't defined can simply -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%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%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -The CopyConstructible requirements in Table 30 state that for an -object t of type T (where T is CopyConstructible), the expression &t -returns the address of t (with type T*). This requirement is overly -strict, in that it disallows types that overload operator& to not -return a value of type T*. This occurs, for instance, in the <a href="http://www.boost.org/libs/lambda">Boost.Lambda</a> library, where -operator& is overloaded for a Boost.Lambda function object to return -another function object. -</p> - -<p>Example:</p> - -<pre> std::vector<int> u, v; - int x; - // ... - std::transform(u.begin(), u.end(), std::back_inserter(v), _1 * x); -</pre> - -<p> -_1 * x returns an unnamed function object with operator& overloaded to -not return T* , therefore rendering the std::transform call ill-formed. -However, most standard library implementations will compile this code -properly, and the viability of such binder libraries is severely hindered -by the unnecessary restriction in the CopyConstructible requirements. -</p> - -<p> -For reference, the address of an object can be retrieved without using -the address-of operator with the following function template: -</p> - -<pre> template <typename T> T* addressof(T& v) - { - return reinterpret_cast<T*>( - &const_cast<char&>(reinterpret_cast<const volatile char &>(v))); - } -</pre> - -<p> -Note: this relates directly to library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, which -will need to be reexamined if the CopyConstructible requirements -change. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Remove the last two rows of Table 30, eliminating the requirements -that &t and &u return the address of t and u, respectively. -</p> - - -<p><b>Rationale:</b></p> -<p>This was a deliberate design decision. Perhaps it should be - reconsidered for C++0x. </p> - - - - - -<hr> -<h3><a name="392"></a>392. 'equivalence' for input iterators</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">NAD</a> - <b>Submitter:</b> Corwin Joy <b>Date:</b> 2002-12-11</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.iterators">issues</a> in [input.iterators].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> - -<p> -In section 24.1.1 [input.iterators] table 72 - -'Input Iterator Requirements' we have as a postcondition of *a: -"If a==b and (a, b) is in the domain of == then *a is equivalent to *b". -</p> - -<p> -In section 24.5.3.5 [istreambuf.iterator::equal] it states that -"istreambuf_iterator::equal returns true if and only if both iterators -are at end-of-stream, or neither is at end-of-stream, <i>regardless of -what streambuf object they use</i>." (My emphasis). -</p> - -<p> -The defect is that either 'equivalent' needs to be more precisely -defined or the conditions for equality in 24.5.3.5 [istreambuf.iterator::equal] -are incorrect. (Or both). -</p> - -<p>Consider the following example:</p> -<pre> #include <iostream> - #include <fstream> - #include <iterator> - using namespace std; - - int main() { - ifstream file1("file1.txt"), file2("file2.txt"); - istreambuf_iterator<char> f1(file1), f2(file2); - cout << "f1 == f2 : " << boolalpha << (f1 == f2) << endl; - cout << "f1 = " << *f1 << endl; - cout << "f2 = " << *f2 << endl; - return 0; - } -</pre> - -<p>Now assuming that neither f1 or f2 are at the end-of-stream then -f1 == f2 by 24.5.3.5 [istreambuf.iterator::equal].</p> - -<p>However, it is unlikely that *f1 will give the same value as *f2 except -by accident.</p> - -<p>So what does *f1 'equivalent' to *f2 mean? I think the standard should -be clearer on this point, or at least be explicit that this does not -mean that *f1 and *f2 are required to have the same value in the case -of input iterators.</p> - - -<p><b>Proposed resolution:</b></p> - - -<p><b>Rationale:</b></p><p>The two iterators aer not in the domain of ==</p> - - - - - - -<hr> -<h3><a name="393"></a>393. do_in/do_out operation on state unclear</h3> -<p><b>Section:</b> 22.2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> - <b>Submitter:</b> Alberto Barbati <b>Date:</b> 2002-12-24</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.virtuals">issues</a> in [locale.codecvt.virtuals].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -this DR follows the discussion on the previous thread "codecvt::do_in -not consuming external characters". It's just a clarification issue -and not a request for a change. -</p> -<p> -Can do_in()/do_out() produce output characters without consuming input -characters as a result of operation on state? -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Add a note at the end of 22.2.1.4.2 [locale.codecvt.virtuals], -paragraph 3: -</p> - -<p> -[Note: As a result of operations on state, it can return ok or partial -and set from_next == from and to_next != to. --end note] -</p> - - -<p><b>Rationale:</b></p> -<p> -The submitter believes that standard already provides an affirmative -answer to the question. However, the current wording has induced a few -library implementors to make the incorrect assumption that -do_in()/do_out() always consume at least one internal character when -they succeed. -</p> - -<p> -The submitter also believes that the proposed resolution is not in -conflict with the related issue 76. Moreover, by explicitly allowing -operations on state to produce characters, a codecvt implementation -may effectively implement N-to-M translations without violating the -"one character at a time" principle described in such issue. On a side -note, the footnote in the proposed resolution of issue 76 that -informally rules out N-to-M translations for basic_filebuf should be -removed if this issue is accepted as valid. -</p> - - -<p><i>[ -Kona (2007): The proposed resolution is to add a note. Since this is -non-normative, the issue is editorial, but we believe that the note is -correct. Proposed Disposition: NAD, Editorial -]</i></p> - - - - - - -<hr> -<h3><a name="399"></a>399. volations of unformatted input function requirements</h3> -<p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-01-05</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> - <p> -The Effects clauses for the two functions below violate the -general requirements on unformatted input functions outlined -in 27.6.1.3: they do not begin by constructing a sentry object. -Instead, they begin by calling widen ('\n'), which may throw -an exception. The exception is then allowed to propagate from -the unformatted input function irrespective of the setting of -exceptions(). - </p> - <p> -Note that in light of 27.6.1.1, p3 and p4, the fact that the -functions allow exceptions thrown from widen() to propagate -may not strictly speaking be a defect (but the fact that the -functions do not start by constructing a sentry object still -is). However, since an exception thrown from ctype<charT> -::widen() during any other input operation (say, from within -a call to num_get<charT>::get()) will be caught and cause -badbit to be set, these two functions should not be treated -differently for the sake of consistency. - </p> - - -<p><b>Proposed resolution:</b></p> - - -<p><b>Rationale:</b></p> -<p> -Not a defect. The standard is consistent, and the behavior required -by the standard is unambiguous. Yes, it's theoretically possible for -widen to throw. (Not that this will happen for the default ctype -facet or for most real-world replacement ctype facets.) Users who -define ctype facets that can throw, and who care about this behavior, -can use alternative signatures that don't call widen. -</p> - - - - - - -<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.7.5.1 [allocator.members], p3,<br> -20.7.5.1 [allocator.members], p10,<br> -21.3.2 [string.cons], p11,<br> -22.1.1.2 [locale.cons], p11,<br> -23.2.2.3 [deque.modifiers], p2,<br> -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.4 [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> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostate.flags">issues</a> in [iostate.flags].</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#412">412</a></p> -<p><b>Discussion:</b></p> - <p> - -The Effects clause in 27.4.4.3, p5 describing the effects of a call to -the ios_base member function clear(iostate state) says that the function -only throws if the respective bits are already set prior to the function -call. That's obviously not the intent. If it was, a call to clear(badbit) -on an object for which (rdstate() == goodbit && exceptions() == badbit) -holds would not result in an exception being thrown. - - </p> - - <p><b>Proposed resolution:</b></p> - <p> - -The text ought to be changed from -<br> - -"If (rdstate() & exceptions()) == 0, returns. ..." -<br> - -to -<br> - -"If (state & exceptions()) == 0, returns. ..." - </p> - - -<p><b>Rationale:</b></p> - - - - - - -<hr> -<h3><a name="433"></a>433. Contradiction in specification of unexpected()</h3> -<p><b>Section:</b> 18.7.2.4 [unexpected] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Vyatcheslav Sysoltsev <b>Date:</b> 2003-09-29</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> -Clause 15.5.2 [except.unexpected] paragraph 1 says that "void unexpected(); -is called (18.7.2) immediately after completing the stack unwinding -for the former function", but 18.7.2.4 (Effects) says that "void -unexpected(); . . . Calls the unexpected_handler function in effect -immediately after evaluating the throwexpression (18.7.2.2),". Isn't -here a contradiction: 15.5.2 requires stack have been unwound when in -void unexpected() and therefore in unexpected_handler but 18.7.2.4 -claims that unexpected_handler is called "in effect immediately" after -evaluation of throw expression is finished, so there is no space left -for stack to be unwound therefore? I think the phrase "in effect -immediately" should be removed from the standard because it brings -ambiguity in understanding. -</p> - - -<p><b>Proposed resolution:</b></p> - - -<p><b>Rationale:</b></p> -<p>There is no contradiction. The phrase "in effect immediately" is - just to clarify which handler is to be called.</p> - - - - - -<hr> -<h3><a name="437"></a>437. Formatted output of function pointers is confusing</h3> -<p><b>Section:</b> 27.6.2.6.2 [ostream.inserters.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Ivan Godard <b>Date:</b> 2003-10-24</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.inserters.arithmetic">issues</a> in [ostream.inserters.arithmetic].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -Given: -</p> -<pre>void f(int) {} -void(*g)(int) = f; -cout << g; -</pre> - -<p> -(with the expected #include and usings), the value printed is a rather -surprising "true". Rather useless too. -</p> - -<p>The standard defines:</p> - -<pre>ostream& operator<<(ostream&, void*);</pre> - -<p>which picks up all data pointers and prints their hex value, but does -not pick up function pointers because there is no default conversion -from function pointer to void*. Absent that, we fall back to legacy -conversions from C and the function pointer is converted to bool. -</p> - -<p>There should be an analogous inserter that prints the address of a - function pointer.</p> - - -<p><b>Proposed resolution:</b></p> - - -<p><b>Rationale:</b></p> -<p>This is indeed a wart, but there is no good way to solve it. C - doesn't provide a portable way of outputting the address of a - function point either.</p> - - - - - -<hr> -<h3><a name="439"></a>439. Should facets be copyable?</h3> -<p><b>Section:</b> 22.2 [locale.categories] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-11-02</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.categories">active issues</a> in [locale.categories].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.categories">issues</a> in [locale.categories].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p>The following facets classes have no copy constructors described in - the standard, which, according to the standard, means that they are - supposed to use the compiler-generated defaults. Default copy - behavior is probably inappropriate. We should either make these - classes uncopyable or else specify exactly what their constructors do.</p> - -<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#421">421</a>.</p> - -<pre> ctype_base - ctype - ctype_byname - ctype<char> - ctype_byname<char> - codecvt_base - codecvt - codecvt_byname - num_get - num_put - numpunct - numpunct_byname - collate - collate_byname - time_base - time_get - time_get_byname - time_put - time_put_byname - money_get - money_put - money_base - moneypunct - moneypunct_byname - messages_base - messages - messages_byname -</pre> - - - -<p><b>Proposed resolution:</b></p> - - -<p><b>Rationale:</b></p> -<p>The copy constructor in the base class is private.</p> - - - - - -<hr> -<h3><a name="440"></a>440. Should std::complex use unqualified transcendentals?</h3> -<p><b>Section:</b> 26.3.8 [complex.transcendentals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-11-05</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> -Operations like <tt>pow</tt> and <tt>exp</tt> on -<tt>complex<T></tt> are typically implemented in terms of -operations like <tt>sin</tt> and <tt>cos</tt> on <tt>T</tt>. -Should implementations write this as <tt>std::sin</tt>, or as plain -unqualified <tt>sin</tt>? -</p> - -<p>The issue, of course, is whether we want to use -argument-dependent lookup in the case where <tt>T</tt> is a -user-defined type. This is similar to the issue of valarray -transcendentals, as discussed in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>.</p> - -<p>This issue differs from valarray transcendentals in two important -ways. First, "the effect of instantiating the template -<tt>complex</tt> for types other than float, double or long double is -unspecified." (26.3.1 [complex.synopsis]) Second, the standard does not -dictate implementation, so there is no guarantee that a particular -real math function is used in the implementation of a particular -complex function.</p> - - - -<p><b>Proposed resolution:</b></p> - - -<p><b>Rationale:</b></p> -<p>If you instantiate std::complex for user-defined types, all bets -are off.</p> - - - - - -<hr> -<h3><a name="447"></a>447. Wrong template argument for time facets</h3> -<p><b>Section:</b> 22.1.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> - <b>Submitter:</b> Pete Becker <b>Date:</b> 2003-12-26</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> -<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#327">327</a></p> -<p><b>Discussion:</b></p> -<p> -22.1.1.1.1/4, table 52, "Required Instantiations", lists, among others: -</p> -<pre> time_get<char,InputIterator> - time_get_byname<char,InputIterator> - time_get<wchar_t,OutputIterator> - time_get_byname<wchar_t,OutputIterator> -</pre> - -<p> -The second argument to the last two should be InputIterator, not -OutputIterator. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Change the second template argument to InputIterator. -</p> - - -<p><b>Rationale:</b></p> - - - - - - -<hr> -<h3><a name="450"></a>450. set::find is inconsistent with associative container requirements</h3> -<p><b>Section:</b> 23.3.3 [set] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> - <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#set">issues</a> in [set].</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#214">214</a></p> -<p><b>Discussion:</b></p> -<p>map/multimap have:</p> - -<pre> iterator find(const key_type& x) const; - const_iterator find(const key_type& x) const; -</pre> - -<p> -which is consistent with the table of associative container requirements. -But set/multiset have: -</p> -<pre> iterator find(const key_type&) const; -</pre> - -<p> -set/multiset should look like map/multimap, and honor the requirements -table, in this regard. -</p> - - -<p><b>Proposed resolution:</b></p> - - -<p><b>Rationale:</b></p> - - - - - - -<hr> -<h3><a name="451"></a>451. Associative erase should return an iterator</h3> -<p><b>Section:</b> 23.1.4 [associative.reqmts], 23.3 [associative] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> - <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> -<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a></p> -<p><b>Discussion:</b></p> -<p>map/multimap/set/multiset have:</p> -<pre> void erase(iterator); - void erase(iterator, iterator); -</pre> - -<p>But there's no good reason why these can't return an iterator, as for -vector/deque/list:</p> -<pre> iterator erase(iterator); - iterator erase(iterator, iterator); -</pre> - - - -<p><b>Proposed resolution:</b></p> -<p> -Informally: The table of associative container requirements, and the -relevant template classes, should return an iterator designating the -first element beyond the erased subrange. -</p> - - -<p><b>Rationale:</b></p> - - - - - - -<hr> -<h3><a name="452"></a>452. locale::combine should be permitted to generate a named locale</h3> -<p><b>Section:</b> 22.1.1.3 [locale.members] <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-01-30</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.members">issues</a> in [locale.members].</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> -<pre>template<class Facet> - locale::combine(const locale&) const; -</pre> -<p> -is obliged to create a locale that has no name. This is overspecification -and overkill. The resulting locale should follow the usual rules -- it -has a name if the locale argument has a name and Facet is one of the -standard facets. -</p> - -<p><i>[ - Sydney and post-Sydney (see c++std-lib-13439, c++std-lib-13440, - c++std-lib-13443): agreed that it's overkill to say that the locale - is obligated to be nameless. However, we also can't require it to - have a name. At the moment, locale names are based on categories - and not on individual facets. If a locale contains two different - facets of different names from the same category, then this would - not fit into existing naming schemes. We need to give - implementations more freedom. Bill will provide wording. -]</i></p> - - - - -<p><b>Rationale:</b></p> -<p>After further discussion the LWG decided to close this as NAD. - The fundamental problem is that names right now are per-category, - not per-facet. The <tt>combine</tt> member function works at the - wrong level of granularity.</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#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> -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> -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> - -<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><i>[ -Batavia: Send to core with our recommendation that we should permit deferred -destruction but not require it. -]</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: -]</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(); - -// 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; -} - -void deallocate_resource() -{ - get_resource(false); -} - -void use_A(const char* message) -{ - A& a = get_resource(); - std::cout << "Using A " << message << "\n"; - a.use(); -} - -struct B -{ - ~B() {use_A("from ~B()");} -}; - -B b; - -int main() -{ - use_A("from main()"); -} -</pre></blockquote> - -<p> -The correct output is: -</p> - -<blockquote><pre>A() -Using A from main() -A is alive -~A() -A() -Using A from ~B() -A is alive -~A() -</pre></blockquote> - -<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><b>Proposed resolution:</b></p> -<p> -</p> - - - - - -<hr> -<h3><a name="466"></a>466. basic_string ctor should prevent null pointer error</h3> -<p><b>Section:</b> 21.3.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Daniel Frey <b>Date:</b> 2004-06-10</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.require">issues</a> in [string.require].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -Today, my colleagues and me wasted a lot of time. After some time, I -found the problem. It could be reduced to the following short example: -</p> - -<pre> #include <string> - int main() { std::string( 0 ); } -</pre> - -<p>The problem is that the tested compilers (GCC 2.95.2, GCC 3.3.1 and -Comeau online) compile the above without errors or warnings! The -programs (at least for the GCC) resulted in a SEGV.</p> - -<p>I know that the standard explicitly states that the ctor of string -requires a char* which is not zero. STLs could easily detect the above -case with a private ctor for basic_string which takes a single 'int' -argument. This would catch the above code at compile time and would not -ambiguate any other legal ctors.</p> - -<p><i>[Redmond: No great enthusiasm for doing this. If we do, - however, we want to do it for all places that take <tt>charT*</tt> - pointers, not just the single-argument constructor. The other - question is whether we want to catch this at compile time (in which - case we catch the error of a literal 0, but not an expression whose - value is a null pointer), at run time, or both.]</i></p> - - - - -<p><b>Proposed resolution:</b></p> - - -<p><b>Rationale:</b></p> -<p> -Recommend NAD. Relegate this functionality to debugging implementations. -</p> - - - - - -<hr> -<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> - -<p> -The standard doesn't prohibit the destructors (or any other special -functions) of containers' elements invoked from a member function -of the container from "recursively" calling the same (or any other) -member function on the same container object, potentially while the -container is in an intermediate state, or even changing the state -of the container object while it is being modified. This may result -in some surprising (i.e., undefined) behavior. -</p> - -<p>Read email thread starting with c++std-lib-13637 for more.</p> - - - -<p><b>Proposed resolution:</b></p> - -<p>Add to Container Requirements the following new paragraph:</p> - -<pre> Unless otherwise specified, the behavior of a program that - invokes a container member function f from a member function - g of the container's value_type on a container object c that - called g from its mutating member function h, is undefined. - I.e., if v is an element of c, directly or indirectly calling - c.h() from v.g() called from c.f(), is undefined. -</pre> - -<p><i>[Redmond: This is a real issue, but it's probably a clause 17 - issue, not clause 23. We get the same issue, for example, if we - try to destroy a stream from one of the stream's callback functions.]</i></p> - - - - -<p><b>Rationale:</b></p> -<p> -Recommend NAD. We agree this is an issue, but not a defect. -We believe that there is no wording we can put in the standard -that will cover all cases without introducing unfortunate -corner cases. -</p> - - - - - -<hr> -<h3><a name="472"></a>472. Missing "Returns" clause in std::equal_range</h3> -<p><b>Section:</b> 25.3.3.3 [equal.range] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> - <b>Submitter:</b> Prateek R Karandikar <b>Date:</b> 2004-06-30</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#equal.range">issues</a> in [equal.range].</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#270">270</a></p> -<p><b>Discussion:</b></p> -<p> -There is no "Returns:" clause for std::equal_range, which returns non-void. -</p> - - -<p><b>Proposed resolution:</b></p> - - -<p><b>Rationale:</b></p> -<p>Fixed as part of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a>.</p> - - - - - - -<hr> -<h3><a name="476"></a>476. Forward Iterator implied mutability</h3> -<p><b>Section:</b> 24.1.3 [forward.iterators] <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> 2004-07-09</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward.iterators">issues</a> in [forward.iterators].</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>24.1/3 says:</p> -<blockquote><p> - Forward iterators satisfy all the requirements of the input and - output iterators and can be used whenever either kind is specified -</p></blockquote> - -<p> -The problem is that satisfying the requirements of output iterator -means that you can always assign *something* into the result of -dereferencing it. That makes almost all non-mutable forward -iterators non-conforming. I think we need to sever the refinement -relationship between forward iterator and output iterator. -</p> - -<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>. But this is not a dup.</p> - - - -<p><b>Proposed resolution:</b></p> - - -<p><b>Rationale:</b></p> -<p>Yes, 24.1/3 does say that. But it's introductory material. The -precise specification is in 24.1.3, and the requrements table there is -right. We don't need to fine-tune introductory wording. (Especially -since this wording is likely to be changed as part of the iterator -overhaul.)</p> - - - - - -<hr> -<h3><a name="477"></a>477. Operator-> for const forward iterators</h3> -<p><b>Section:</b> 24.1.3 [forward.iterators] <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-07-11</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward.iterators">issues</a> in [forward.iterators].</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#478">478</a></p> -<p><b>Discussion:</b></p> -<p> -The Forward Iterator requirements table contains the following: -</p> -<pre> expression return type operational precondition - semantics - ========== ================== =========== ========================== - a->m U& if X is mutable, (*a).m pre: (*a).m is well-defined. - otherwise const U& - - r->m U& (*r).m pre: (*r).m is well-defined. -</pre> - -<p> -The first line is exactly right. The second line is wrong. Basically -it implies that the const-ness of the iterator affects the const-ness -of referenced members. But Paragraph 11 of [lib.iterator.requirements] says: -</p> - -<blockquote><p> - In the following sections, a and b denote values of type const X, n - denotes a value of the difference type Distance, u, tmp, and m - denote identifiers, r denotes a value of X&, t denotes a value of - value type T, o denotes a value of some type that is writable to - the output iterator. -</p></blockquote> - -<p>AFAICT if we need the second line at all, it should read the same -as the first line.</p> - -<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a></p> - - -<p><b>Proposed resolution:</b></p> - - -<p><b>Rationale:</b></p> -<p>The LWG agrees that this is a real problem. Marked as a DUP - because the LWG chose to adopt the solution proposed in - <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>. -</p> - - - - - -<hr> -<h3><a name="479"></a>479. Container requirements and placement new</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#Dup">Dup</a> - <b>Submitter:</b> Herb Sutter <b>Date:</b> 2004-08-01</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p> -<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a></p> -<p><b>Discussion:</b></p> -<p>Nothing in the standard appears to make this program ill-formed:</p> - -<pre> struct C { - void* operator new( size_t s ) { return ::operator new( s ); } - // NOTE: this hides in-place and nothrow new - }; - - int main() { - vector<C> v; - v.push_back( C() ); - } -</pre> - -<p>Is that intentional? We should clarify whether or not we intended - to require containers to support types that define their own special - versions of <tt>operator new</tt>.</p> - -<p><i>[ -Lillehammer: A container will definitely never use this overridden -operator new, but whether it will fail to compile is unclear from the -standard. Are containers supposed to use qualified or unqualified -placement new? 20.4.1.1 is somewhat relevant, but the standard -doesn't make it completely clear whether containers have to use -Allocator::construct(). If containers don't use it, the details of how -containers use placement new are unspecified. That is the real bug, -but it needs to be fixed as part of the allocator overhaul. Weak -support that the eventual solution should make this code well formed. -]</i></p> - - - - -<p><b>Proposed resolution:</b></p> - - - - - - - -<hr> -<h3><a name="480"></a>480. unary_function and binary_function should have protected nonvirtual destructors</h3> -<p><b>Section:</b> 20.6.3 [base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Joe Gottman <b>Date:</b> 2004-08-19</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p>The classes std::unary_function and std::binary_function are both -designed to be inherited from but contain no virtual functions. This -makes it too easy for a novice programmer to write code like -binary_function<int, int, int> *p = new plus<int>; delete p;</p> - -<p>There are two common ways to prevent this source of undefined -behavior: give the base class a public virtual destructor, or give it -a protected nonvirtual destructor. Since unary_function and -binary_function have no other virtual functions, (note in particular -the absence of an operator()() ), it would cost too much to give them -public virtual destructors. Therefore, they should be given protected -nonvirtual destructors.</p> - - -<p><b>Proposed resolution:</b></p> -<p>Change Paragraph 20.3.1 of the Standard from</p> -<pre> template <class Arg, class Result> - struct unary_function { - typedef Arg argument_type; - typedef Result result_type; - }; - - template <class Arg1, class Arg2, class Result> - struct binary_function { - typedef Arg1 first_argument_type; - typedef Arg2 second_argument_type; - typedef Result result_type; - }; -</pre> - -<p>to</p> -<pre> template <class Arg, class Result> - struct unary_function { - typedef Arg argument_type; - typedef Result result_type; - protected: - ~unary_function() {} - }; - - template <class Arg1, class Arg2, class Result> - struct binary_function { - typedef Arg1 first_argument_type; - typedef Arg2 second_argument_type; - typedef Result result_type; - protected: - ~binary_function() {} - }; -</pre> - - -<p><b>Rationale:</b></p> -<p>The LWG doesn't believe the existing definition causes anybody any - concrete harm.</p> - - - - - -<hr> -<h3><a name="481"></a>481. unique's effects on the range [result, last)</h3> -<p><b>Section:</b> 25.2.9 [alg.unique] <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> 2004-08-30</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</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 says that unique(first, last) "eliminates all but the -first element from every consecutive group of equal elements" in -[first, last) and returns "the end of the resulting range". So a -postcondition is that [first, result) is the same as the old [first, -last) except that duplicates have been eliminated. -</p> - -<p>What postconditions are there on the range [result, last)? One - might argue that the standard says nothing about those values, so - they can be anything. One might also argue that the standard - doesn't permit those values to be changed, so they must not be. - Should the standard say something explicit one way or the other?</p> - - - -<p><b>Proposed resolution:</b></p> -<p> -</p> - - -<p><b>Rationale:</b></p> -<p>We don't want to make many guarantees about what's in [result, -end). Maybe we aren't being quite explicit enough about not being -explicit, but it's hard to think that's a major problem.</p> - - - - - -<hr> -<h3><a name="482"></a>482. Swapping pairs</h3> -<p><b>Section:</b> 20.2.3 [pairs], 20.4 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> - <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2004-09-14</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p>(Based on recent comp.std.c++ discussion)</p> - -<p>Pair (and tuple) should specialize std::swap to work in terms of -std::swap on their components. For example, there's no obvious reason -why swapping two objects of type pair<vector<int>, -list<double> > should not take O(1).</p> - -<p><i>[Lillehammer: We agree it should be swappable. Howard will - provide wording.]</i></p> - - -<p><i>[ -Post Oxford: We got <tt>swap</tt> for <tt>pair</tt> but accidently -missed <tt>tuple</tt>. <tt>tuple::swap</tt> is being tracked by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>. -]</i></p> - - - - -<p><b>Proposed resolution:</b></p> -<p> -Wording provided in -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html#20.2.3%20-%20Pairs">N1856</a>. -</p> - -<p><b>Rationale:</b></p> -<p> -Recommend NAD, fixed by -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html#20.2.3%20-%20Pairs">N1856</a>. -</p> - - - - - -<hr> -<h3><a name="483"></a>483. Heterogeneous equality and EqualityComparable</h3> -<p><b>Section:</b> 25.1 [alg.nonmodifying], 25.2 [alg.modifying.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> - <b>Submitter:</b> Peter Dimov <b>Date:</b> 2004-09-20</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#283">283</a></p> -<p><b>Discussion:</b></p> -<p>c++std-lib-14262</p> - -<p>[lib.alg.find] requires T to be EqualityComparable:</p> - -<pre>template <class InputIterator, class T> - InputIterator find(InputIterator first, InputIterator last, - const T& value); -</pre> - -<p> -However the condition being tested, as specified in the Effects -clause, is actually *i == value, where i is an InputIterator. -</p> - -<p> -The two clauses are in agreement only if the type of *i is T, but this -isn't necessarily the case. *i may have a heterogeneous comparison -operator that takes a T, or a T may be convertible to the type of *i. -</p> - -<p>Further discussion (c++std-lib-14264): this problem affects a - number of algorithsm in clause 25, not just <tt>find</tt>. We - should try to resolve this problem everywhere it appears.</p> - - -<p><b>Proposed resolution:</b></p> - -<p>[lib.alg.find]:</p> -<blockquote><p> - Remove [lib.alg.find]/1. -</p></blockquote> - -<p>[lib.alg.count]:</p> -<blockquote><p> - Remove [lib.alg.count]/1. -</p></blockquote> - -<p>[lib.alg.search]:</p> -<blockquote><p> - Remove "Type T is EqualityComparable (20.1.1), " from [lib.alg.search]/4. -</p></blockquote> - -<p>[lib.alg.replace]:</p> - -<blockquote> - <p> - Remove [lib.alg.replace]/1. - Replace [lb.alg.replace]/2 with: - </p> - - <blockquote><p> - For every iterator i in the range [first, last) for which *i == value - or pred(*i) holds perform *i = new_value. - </p></blockquote> - - <p> - Remove the first sentence of /4. - Replace the beginning of /5 with: - </p> - - <blockquote><p> - For every iterator i in the range [result, result + (last - - first)), assign to *i either... - </p></blockquote> - - <p>(Note the defect here, current text says assign to i, not *i).</p> -</blockquote> - -<p>[lib.alg.fill]:</p> - -<blockquote> - <p> - Remove "Type T is Assignable (23.1), " from /1. - Replace /2 with: - </p> - - <blockquote><p> - For every iterator i in the range [first, last) or [first, first + n), - perform *i = value. - </p></blockquote> -</blockquote> - -<p>[lib.alg.remove]:</p> -<blockquote><p> - Remove /1. - Remove the first sentence of /6. -</p></blockquote> - - - -<p><b>Rationale:</b></p> -<p>Duplicate of (a subset of) issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a>.</p> - - - - - - -<hr> -<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 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> -<p><b>Discussion:</b></p> -<p>A straightforward implementation of these algorithms does not need to -copy T.</p> - - -<p><b>Proposed resolution:</b></p> -<p>drop the the words "and CopyConstructible" from paragraphs 1 and 4</p> - - -<p><b>Rationale:</b></p> - - - - - - -<hr> -<h3><a name="487"></a>487. Allocator::construct is too limiting</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#NAD">NAD</a> - <b>Submitter:</b> Dhruv Matani <b>Date:</b> 2004-10-17</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -The standard's version of allocator::construct(pointer, -const_reference) severely limits what you can construct using this -function. Say you can construct a socket from a file descriptor. Now, -using this syntax, I first have to manually construct a socket from -the fd, and then pass the constructed socket to the construct() -function so it will just to an uninitialized copy of the socket I -manually constructed. Now it may not always be possible to copy -construct a socket eh! So, I feel that the changes should go in the -allocator::construct(), making it: -</p> -<pre> template<typename T> - struct allocator{ - template<typename T1> - void construct(pointer T1 const& rt1); - }; -</pre> - -<p> -Now, the ctor of the class T which matches the one that takes a T1 can -be called! Doesn't that sound great? -</p> - - -<p><b>Proposed resolution:</b></p> - - -<p><b>Rationale:</b></p> -<p>NAD. STL uses copying all the time, and making it possible for - allocators to construct noncopyable objects is useless in the - absence of corresponding container changes. We might consider this - as part of a larger redesign of STL.</p> - - - - - -<hr> -<h3><a name="489"></a>489. std::remove / std::remove_if wrongly specified</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#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#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#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p>In Section 25.2.7 [lib.alg.remove], paragraphs 1 to 5 describe the -behavior of the mutating sequence operations std::remove and -std::remove_if. However, the wording does not reflect the intended -behavior [Note: See definition of intended behavior below] of these -algorithms, as it is known to the C++ community [1]. -</p> - - - -<p>1) Analysis of current wording:</p> - - -<p>25.2.7 [lib.alg.remove], paragraph 2:</p> - -<p>Current wording says: -"Effects: Eliminates all the elements referred to by iterator i in the -range [first, last) for which the following corresponding conditions -hold: *i == value, pred(*i) != false."</p> - -<p> -This sentences expresses specifically that all elements denoted by the -(original) range [first, last) for which the corresponding condition -hold will be eliminated. Since there is no formal definition of the term -"eliminate" provided, the meaning of "eliminate" in everyday language -implies that as postcondition, no element in the range denoted by -[first, last) will hold the corresponding condition on reiteration over -the range [first, last). -</p> - -<p> -However, this is neither the intent [Note: See definition of intended -behavior below] nor a general possible approach. It can be easily proven -that if all elements of the original range[first, last) will hold the -condition, it is not possible to substitute them by an element for which -the condition will not hold. -</p> - - -<p>25.2.7 [lib.alg.remove], paragraph 3:</p> - -<p> -Current wording says: -"Returns: The end of the resulting range." -</p> - -<p> -The resulting range is not specified. In combination with 25.2.7 -[lib.alg.remove], paragraph 2, the only reasonable interpretation of -this so-called resulting range is the range [first,last) - thus -returning always the ForwardIterator 'last' parameter. -</p> - - -<p> -25.2.7 [lib.alg.remove], paragraph 4: -</p> - -<p> -Current wording says: -"Notes: Stable: the relative order of the elements that are not removed -is the same as their relative order in the original range" -</p> - -<p> -This sentences makes use of the term "removed", which is neither -specified, nor used in a previous paragraph (which uses the term -"eliminate"), nor unamgiuously separated from the name of the algorithm. -</p> - - -<p>2) Description of intended behavior:</p> - -<p> -For the rest of this Defect Report, it is assumed that the intended -behavior was that all elements of the range [first, last) which do not -hold the condition *i == value (std::remove) or pred(*i) != false -(std::remove_if)], call them s-elements [Note: s...stay], will be placed -into a contiguous subrange of [first, last), denoted by the iterators -[first, return value). The number of elements in the resulting range -[first, return value) shall be equal to the number of s-elements in the -original range [first, last). The relative order of the elements in the -resulting subrange[first, return value) shall be the same as the -relative order of the corresponding elements in the original range. It -is undefined whether any elements in the resulting subrange [return -value, last) will hold the corresponding condition, or not. -</p> - -<p> -All implementations known to the author of this Defect Report comply -with this intent. Since the intent of the behavior (contrary to the -current wording) is also described in various utility references serving -the C++ community [1], it is not expected that fixing the paragraphs -will influence current code - unless the code relies on the behavior as -it is described by current wording and the implementation indeed -reflects the current wording, and not the intent. -</p> - - - -<p>3) Proposed fixes:</p> - - -<p>Change 25.2.7 [lib.alg.remove], paragraph 2 to:</p> - -<p> -"Effect: Places all the elements referred to by iterator i in the range -[first, last) for which the following corresponding conditions hold : -!(*i == value), pred(*i) == false into the subrange [first, k) of the -original range, where k shall denote a value of type ForwardIterator. It -is undefined whether any elements in the resulting subrange [k, last) -will hold the corresponding condition, or not." -</p> - -<p>Comments to the new wording:</p> - -<p> -a) "Places" has no special meaning, and the everyday language meaning -should fit. -b) The corresponding conditions were negated compared to the current -wording, becaue the new wording requires it. -c) The wording "of the original range" might be redundant, since any -subrange starting at 'first' and containing no more elements than the -original range is implicitly a subrange of the original range [first, -last). -d) The iterator k was introduced instead of "return value" in order to -avoid a cyclic dependency on 25.2.7/3. The wording ", where k shall -denote a value of type ForwardIterator" might be redundant, because it -follows implicitly by 25.2.7/3. -e) "Places" does, in the author's opinion, explicitly forbid duplicating -any element holding the corresponding condition in the original range -[first, last) within the resulting range [first, k). If there is doubt -this term might be not unambiguous regarding this, it is suggested that -k is specified more closely by the following wording: "k shall denote a -value of type ForwardIterator [Note: see d)] so that k - first is equal -to the number of elements in the original range [first, last) for which -the corresponding condition did hold". This could also be expressed as a -separate paragraph "Postcondition:" -f) The senctence "It is undefined whether any elements in the resulting -subrange [k, last) will hold the corresponding condition, or not." was -added consciously so the term "Places" does not imply if the original -range [first, last) contains n elements holding the corresponding -condition, the identical range[first, last) will also contain exactly n -elements holding the corresponding condition after application of the -algorithm. -</p> - -<p> -Change 25.2.7 [lib.alg.remove], paragraph 3 to: - -"Returns: The iterator k." -</p> - -<p> -Change 25.2.7 [lib.alg.remove], paragraph 4 to: - -"Notes: Stable: the relative order of the elements that are placed into -the subrange [first, return value) shall be the same as their relative -order was in the original range [first, last) prior to application of -the algorithm." -</p> - -<p> -Comments to the new wording: -</p> - -<p> -a) the wording "was ... prior to application of the algorithm" is used -to explicitly distinguish the original range not only by means of -iterators, but also by a 'chronological' factor from the resulting range -[first, return value). It might be redundant. -</p> - -<p> -[1]: -The wording of these references is not always unambiguous, and provided -examples partially contradict verbal description of the algorithms, -because the verbal description resembles the problematic wording of -ISO/IEC 14882:2003. -</p> - - -<p><b>Proposed resolution:</b></p> - - -<p><b>Rationale:</b></p> -<p>The LWG believes that the standard is sufficiently clear, and that - there is no evidence of any real-world confusion about this point.</p> - - - - - -<hr> -<h3><a name="490"></a>490. std::unique wrongly specified</h3> -<p><b>Section:</b> 25.2.9 [alg.unique] <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#alg.unique">issues</a> in [alg.unique].</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 25.2.8 [lib.alg.unique], paragraphs 1 to 3 describe the -behavior of the mutating sequence operation std::unique. However, the -wording does not reflect the intended behavior [Note: See definition of -intended behavior below] of these algorithms, as it is known to the C++ -community [1].</p> - - - -<p>1) Analysis of current wording:</p> - - -<p>25.2.8 [lib.alg.unique], paragraph 1:</p> - -<p> -Current wording says: -"Effects: Eliminates all but the first element from every consecutive -group of equal elements referred to by the iterator i in the range -[first, last) for which the following corresponding conditions hold: *i -== *(i - 1) or pred(*i, *(i -1)) != false" -</p> - -<p> -This sentences expresses specifically that all elements denoted by the -(original) range [first, last) which are not but the first element from -a consecutive group of equal elements (where equality is defined as *i -== *(i - 1) or pred(*i, *(i - 1)) ! = false) [Note: See DR 202], call -them r-elements [Note: r...remove], will be eliminated. Since there is -no formal definition of the term "eliminate" provided, it is undefined -how this "elimination" takes place. But the meaning of "eliminate" in -everyday language seems to disallow explicitly that after application of -the algorithm, any r-element will remain at any position of the range -[first, last) [2]. -</p> - -<p> -Another defect in the current wording concerns the iterators used to -compare two elements for equality: The current wording contains the -expression "(i - 1)", which is not covered by 25/9 [Note: See DR -submitted by Thomas Mang regarding invalid iterator arithmetic -expressions]. -</p> - - -<p> -25.2.8 [lib.alg.unique], paragraph 2: -</p> -<p>Current wording says: -"Returns: The end of the resulting range."</p> - -<p> -The resulting range is not specified. In combination with 25.2.8 -[lib.alg.unique], paragraph 1, one reasonable interpretation (in the -author's opinion even the only possible interpretation) of this -so-called resulting range is the range [first, last) - thus returning -always the ForwardIterator 'last' parameter. -</p> - -<p>2) Description of intended behavior:</p> - -<p> -For the rest of this Defect Report, it is assumed that the intended -behavior was that all elements denoted by the original range [first, -last) which are the first element from a consecutive group of elements -for which the corresponding conditions: *(i-1) == *i (for the version of -unique without a predicate argument) or pred(*(i-1), *i) ! = false (for -the version of unique with a predicate argument) [Note: If such a group -of elements consists of only a single element, this is also considered -the first element] [Note: See resolutions of DR 202], call them -s-elements [Note: s...stay], will be placed into a contiguous subrange -of [first, last), denoted by the iterators [first, return value). The -number of elements in the resulting range [first, return value) shall be -equal to the number of s-elements in the original range [first, last). -Invalid iterator arithmetic expressions are expected to be resolved as -proposed in DR submitted by Thomas Mang regarding invalid iterator -arithmetic expressions. It is also assumed by the author that the -relative order of the elements in the resulting subrange [first, return -value) shall be the same as the relative order of the corresponding -elements (the s-elements) in the original range [Note: If this was not -intended behavior, the additional proposed paragraph about stable order -will certainly become obsolete]. -Furthermore, the resolutions of DR 202 are partially considered. -</p> - -<p> -All implementations known to the author of this Defect Report comply -with this intent [Note: Except possible effects of DR 202]. Since this -intent of the behavior (contrary to the current wording) is also -described in various utility references serving the C++ community [1], -it is not expected that fixing the paragraphs will influence current -code [Note: Except possible effects of DR 202] - unless the code relies -on the behavior as it is described by current wording and the -implementation indeed reflects the current wording, and not the intent. -</p> - - - -<p>3) Proposed fixes:</p> - -<p> -Change 25.2.8 [lib.alg.unique], paragraph 1 to: -</p> - -<p> -"Effect: Places the first element from every consecutive group of -elements, referred to by the iterator i in the range [first, last), for -which the following conditions hold: *(i-1) == *i (for the version of -unique without a predicate argument) or pred(*(i -1), *i) != false (for -the version of unique with a predicate argument), into the subrange -[first, k) of the original range, where k shall denote a value of type -ForwardIterator." -</p> - -<p>Comments to the new wording:</p> - -<p> -a) The new wording was influenced by the resolutions of DR 202. If DR -202 is resolved in another way, the proposed wording need also -additional review. -b) "Places" has no special meaning, and the everyday language meaning -should fit. -c) The expression "(i - 1)" was left, but is expected that DR submitted -by Thomas Mang regarding invalid iterator arithmetic expressions will -take this into account. -d) The wording "(for the version of unique without a predicate -argument)" and "(for the version of unique with a predicate argument)" -was added consciously for clarity and is in resemblence with current -23.2.2.4 [lib.list.ops], paragraph 19. It might be considered redundant. -e) The wording "of the original range" might be redundant, since any -subrange starting at first and containing no more elements than the -original range is implicitly a subrange of the original range [first, -last). -f) The iterator k was introduced instead of "return value" in order to -avoid a cyclic dependency on 25.2.8 [lib.alg.unique], paragraph 2. The -wording ", where k shall denote a value of type ForwardIterator" might -be redundant, because it follows implicitly by 25.2.8 [lib.alg.unique], -paragraph 2. -g) "Places" does, in the author's opinion, explicitly forbid duplicating -any s-element in the original range [first, last) within the resulting -range [first, k). If there is doubt this term might be not unambiguous -regarding this, it is suggested that k is specified more closely by the -following wording: "k shall denote a value of type ForwardIterator -[Note: See f)] so that k - first is equal to the number of elements in -the original range [first, last) being the first element from every -consecutive group of elements for which the corresponding condition did -hold". This could also be expressed as a separate paragraph -"Postcondition:". -h) If it is considered that the wording is unclear whether it declares -the element of a group which consists of only a single element -implicitly to be the first element of this group [Note: Such an -interpretation could eventually arise especially in case last - first == -1] , the following additional sentence is proposed: "If such a group of -elements consists of only a single element, this element is also -considered the first element." -</p> - -<p> -Change 25.2.8 [lib.alg.unique], paragraph 2 to: -"Returns: The iterator k." -</p> - -<p> -Add a separate paragraph "Notes:" as 25.2.8 [lib.alg.unique], paragraph -2a or 3a, or a separate paragraph "Postcondition:" before 25.2.8 -[lib.alg.unique], paragraph 2 (wording inside {} shall be eliminated if -the preceding expressions are used, or the preceding expressions shall -be eliminated if wording inside {} is used): -</p> - -<p> -"Notes:{Postcondition:} Stable: the relative order of the elements that -are placed into the subrange [first, return value {k}) shall be the same -as their relative order was in the original range [first, last) prior to -application of the algorithm." -</p> - -<p>Comments to the new wording:</p> - -<p> -a) It is assumed by the author that the algorithm was intended to be -stable. -In case this was not the intent, this paragraph becomes certainly -obsolete. -b) The wording "was ... prior to application of the algorithm" is used -to explicitly distinguish the original range not only by means of -iterators, but also by a 'chronological' factor from the resulting range -[first, return value). It might be redundant. -</p> - -<p> -25.2.8 [lib.alg.unique], paragraph 3: -</p> -<p>See DR 239.</p> - -<p> -4) References to other DRs: -</p> - -<p> -See DR 202, but which does not address any of the problems described in -this Defect Report [Note: This DR is supposed to complement DR 202]. -See DR 239. -See DR submitted by Thomas Mang regarding invalid iterator arithmetic -expressions. -</p> - -<p> -[1]: -The wording of these references is not always unambiguous, and provided -examples partially contradict verbal description of the algorithms, -because the verbal description resembles the problematic wording of -ISO/IEC 14882:2003. -</p> - -<p> -[2]: -Illustration of conforming implementations according to current wording: -</p> - -<p> -One way the author of this DR considers how this "elimination" could be -achieved by a conforming implementation according to current wording is -by substituting each r-element by _any_ s-element [Note: s...stay; any -non-r-element], since all r-elements are "eliminated". -</p> - -<p> -In case of a sequence consisting of elements being all 'equal' [Note: -See DR 202], substituting each r-element by the single s-element is the -only possible solution according to current wording. -</p> - - -<p><b>Proposed resolution:</b></p> - - -<p><b>Rationale:</b></p> -<p>The LWG believes the standard is sufficiently clear. No -implementers get it wrong, and changing it wouldn't cause any code to -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.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.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> - - - -<p> -1) Analysis of current wording: -</p> - -<p>23.2.4.4 [list.ops], paragraph 19:</p> - -<p> -Current wording says: -"Effects: Eliminates all but the first element from every consecutive -group of equal elements referred to by the iterator i in the range -[first + 1, last) for which *i == *(i - 1) (for the version of unique -with no argument) or pred(*i, *(i -1)) (for the version of unique with a -predicate argument) holds."</p> - -<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.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, -last)". However, neither "first" nor "last" is defined.</p> - -<p> -The sentence makes three times use of iterator arithmetic expressions ( -"first + 1", "*i == *(i - 1)", "pred(*i, *(i -1))" ) which is not -defined for bidirectional iterator [see DR submitted by Thomas Mang -regarding invalid iterator arithmetic expressions].</p> - -<p> -The same problems as pointed out in DR 202 (equivalence relation / order -of arguments for pred()) apply to this paragraph.</p> - -<p> -23.2.4.4 [list.ops], paragraph 20: -</p> - -<p> -Current wording says: -"Throws: Nothing unless an exception in thrown by *i == *(i-1) or -pred(*i, *(i - 1))"</p> - -<p> -The sentence makes two times use of invalid iterator arithmetic -expressions ( "*i == *(i - 1)", "pred(*i, *(i -1))" ). -</p> -<p> -[Note: Minor typos: "in" / missing dot at end of sentence.] -</p> - -<p> -23.2.4.4 [list.ops], paragraph 21:</p> - -<p> -Current wording says: -"Complexity: If the range (last - first) is not empty, exactly (last - -first) - 1 applications of the corresponding predicate, otherwise no -application of the predicate.</p> - -<p> -See DR 315 regarding "(last - first)" not yielding a range.</p> - -<p> -Invalid iterator arithmetic expression "(last - first) - 1" left .</p> - - -<p>2) Description of intended behavior:</p> - -<p> -For the rest of this Defect Report, it is assumed that "eliminate" is -supposed to be synonymous to "erase", that "first" is equivalent to an -iterator obtained by a call to begin(), "last" is equivalent to an -iterator obtained by a call to end(), and that all invalid iterator -arithmetic expressions are resolved as described in DR submitted by -Thomas Mang regarding invalid iterator arithmetic expressions.</p> - -<p> -Furthermore, the resolutions of DR 202 are considered regarding -equivalence relation and order of arguments for a call to pred.</p> - -<p> -All implementations known to the author of this Defect Report comply -with these assumptions, apart from the impact of the alternative -resolution of DR 202. Except for the changes implied by the resolutions -of DR 202, no impact on current code is expected.</p> - -<p> -3) Proposed fixes:</p> - -<p> -Change 23.2.4.4 [list.ops], paragraph 19 to:</p> - -<p> -"Effect: Erases all but the first element from every consecutive group -of elements, referred to by the iterator i in the range [begin(), -end()), for which the following conditions hold: *(i-1) == *i (for the -version of unique with no argument) or pred(*(i-1), *i) != false (for -the version of unique with a predicate argument)."</p> - -<p> -Comments to the new wording:</p> - -<p> -a) The new wording was influenced by DR 202 and the resolutions -presented there. If DR 202 is resolved in another way, the proposed -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.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 -take this into account. -d) The wording "(for the version of unique with no argument)" and "(for -the version of unique with a predicate argument)" was kept consciously -for clarity. -e) "begin()" substitutes "first", and "end()" substitutes "last". The -range need adjustment from "[first + 1, last)" to "[begin(), end())" to -ensure a valid range in case of an empty list. -f) If it is considered that the wording is unclear whether it declares -the element of a group which consists of only a single element -implicitly to be the first element of this group [Note: Such an -interpretation could eventually arise especially in case size() == 1] , -the following additional sentence is proposed: "If such a group of -elements consists of only a single element, this element is also -considered the first element."</p> - -<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 -pred(*(i-1), *i)."</p> - -<p> -Comments to the new wording:</p> - -<p> -a) The wording regarding the conditions is identical to proposed -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 -by Thomas Mang regarding invalid iterator arithmetic expressions will -take this into account. -c) Typos fixed.</p> - -<p> -Change 23.2.4.4 [list.ops], paragraph 21 to:</p> - -<p> -"Complexity: If empty() == false, exactly size() - 1 applications of the -corresponding predicate, otherwise no applications of the corresponding -predicate."</p> - -<p> -Comments to the new wording:</p> - -<p> -a) The new wording is supposed to also replace the proposed resolution -of DR 315, which suffers from the problem of undefined "first" / "last". -</p> - -<p> -5) References to other DRs:</p> - -<p>See DR 202. -See DR 239. -See DR 315. -See DR submitted by Thomas Mang regarding invalid iterator arithmetic -expressions.</p> - - - -<p><b>Proposed resolution:</b></p> - - -<p><b>Rationale:</b></p> -<p>"All implementations known to the author of this Defect Report -comply with these assumption", and "no impact on current code is -expected", i.e. there is no evidence of real-world confusion or -harm.</p> - - - - - -<hr> -<h3><a name="493"></a>493. Undefined Expression in Input Iterator Note Title</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">NAD</a> - <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2004-12-13</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.iterators">issues</a> in [input.iterators].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p>1) In 24.1.1/3, the following text is currently present.</p> - -<p>"Note: For input iterators, a==b does not imply ++a=++b (Equality does -not guarantee the substitution property or referential transparency)."</p> - -<p>However, when in Table 72, part of the definition of ++r is given as:</p> - -<p>"pre: r is dereferenceable. -post: any copies of the previous value of r are no longer required -either to be dereferenceable ..."</p> - -<p>While a==b does not imply that b is a copy of a, this statement should -perhaps still be made more clear.</p> - -<p>2) There are no changes to intended behaviour</p> - -<p> -3) This Note should be altered to say "Note: For input iterators a==b, -when its behaviour is defined ++a==++b may still be false (Equality does -not guarantee the substitution property or referential transparency).</p> - - - -<p><b>Proposed resolution:</b></p> - - -<p><b>Rationale:</b></p> -<p>This is descriptive text, not normative, and the meaning is clear.</p> - - - - - -<hr> -<h3><a name="494"></a>494. Wrong runtime complexity for associative container's insert and delete</h3> -<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Hans B os <b>Date:</b> 2004-12-19</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p>According to [lib.associative.reqmts] table 69, the runtime comlexity -of insert(p, t) and erase(q) can be done in amortized constant time.</p> - -<p>It was my understanding that an associative container could be -implemented as a balanced binary tree.</p> - -<p>For inser(p, t), you 'll have to iterate to p's next node to see if t -can be placed next to p. Furthermore, the insertion usually takes -place at leaf nodes. An insert next to the root node will be done at -the left of the root next node</p> - -<p>So when p is the root node you 'll have to iterate from the root to -its next node, which takes O(log(size)) time in a balanced tree.</p> - -<p>If you insert all values with insert(root, t) (where root is the -root of the tree before insertion) then each insert takes O(log(size)) -time. The amortized complexity per insertion will be O(log(size)) -also.</p> - -<p>For erase(q), the normal algorithm for deleting a node that has no -empty left or right subtree, is to iterate to the next (or previous), -which is a leaf node. Then exchange the node with the next and delete -the leaf node. Furthermore according to DR 130, erase should return -the next node of the node erased. Thus erasing the root node, -requires iterating to the next node.</p> - -<p>Now if you empty a map by deleting the root node until the map is -empty, each operation will take O(log(size)), and the amortized -complexity is still O(log(size)).</p> - -<p>The operations can be done in amortized constant time if iterating -to the next node can be done in (non amortized) constant time. This -can be done by putting all nodes in a double linked list. This -requires two extra links per node. To me this is a bit overkill since -you can already efficiently insert or erase ranges with erase(first, -last) and insert(first, last).</p> - - - -<p><b>Proposed resolution:</b></p> - - -<p><b>Rationale:</b></p> -<p>Only "amortized constant" in special circumstances, and we believe - that's implementable. That is: doing this N times will be O(N), not - O(log N).</p> - - - - - -<hr> -<h3><a name="499"></a>499. Std. doesn't seem to require stable_sort() to be stable!</h3> -<p><b>Section:</b> 25.3.1.2 [stable.sort] <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> Prateek Karandikar <b>Date:</b> 2005-04-12</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> -17.3.1.1 Summary</p> - -<p> -1 The Summary provides a synopsis of the category, and introduces the -first-level subclauses. Each subclause also provides a summary, listing -the headers specified in the subclause and the library entities -provided in each header. -</p> -<p> -2 Paragraphs labelled "Note(s):" or "Example(s):" are informative, -other paragraphs are normative. -</p></blockquote> - -<p>So this means that a "Notes" paragraph wouldn't be normative. </p> - -<blockquote><p> -25.3.1.2 stable_sort -</p> -<pre>template<class RandomAccessIterator> -void stable_sort(RandomAccessIterat or first, RandomAccessIterator last); - -template<class RandomAccessIterator, class Compare> -void stable_sort(RandomAccessIterat or first, RandomAccessIterator last, Compare comp); -</pre> -<p> -1 Effects: Sorts the elements in the range [first, last). -</p> -<p> -2 Complexity: It does at most N(log N)^2 (where N == last - first) -comparisons; if enough extra memory is available, it is N log N. -</p> -<p> -3 Notes: Stable: the relative order of the equivalent elements is -preserved. -</p></blockquote> - -<p> -The Notes para is informative, and nowhere else is stability mentioned above. -</p> - -<p> -Also, I just searched for the word "stable" in my copy of the Standard. -and the phrase "Notes: Stable: the relative order of the elements..." -is repeated several times in the Standard library clauses for -describing various functions. How is it that stability is talked about -in the informative paragraph? Or am I missing something obvious? -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -</p> - - -<p><b>Rationale:</b></p> -<p> -This change has already been made. -</p> - - - - - -<hr> -<h3><a name="500"></a>500. do_length cannot be implemented correctly</h3> -<p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Krzysztof Żelechowski <b>Date:</b> 2005-05-24</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</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>codecvt::do_length is of type int;</li> -<li>it is assumed to be sort-of returning from_next - from of type ptrdiff_t;</li> -<li>ptrdiff_t cannot be cast to an int without data loss.</li> -</ol> -<p> -Contradiction. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -</p> - - - - - -<hr> -<h3><a name="501"></a>501. Proposal: strengthen guarantees of lib.comparisons</h3> -<p><b>Section:</b> 20.6.3 [base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Me <anti_spam_email2003@yahoo.com> <b>Date:</b> 2005-06-07</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<blockquote><p> -"For templates greater, less, greater_equal, and less_equal, -the specializations for any pointer type yield a total order, even if -the built-in operators <, >, <=, >= do not." -</p></blockquote> - -<p> -The standard should do much better than guarantee that these provide a -total order, it should guarantee that it can be used to test if memory -overlaps, i.e. write a portable memmove. You can imagine a platform -where the built-in operators use a uint32_t comparison (this tests for -overlap on this platform) but the less<T*> functor is allowed to be -defined to use a int32_t comparison. On this platform, if you use -std::less with the intent of making a portable memmove, comparison on -an array that straddles the 0x7FFFFFFF/0x8000000 boundary can give -incorrect results. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Add a footnote to 20.5.3/8 saying: -</p> - -<blockquote><p> -Given a p1 and p2 such that p1 points to N objects of type T and p2 -points to M objects of type T. If [p1,p1+N) does not overlap [p2,p2+M), -less returns the same value when comparing all pointers in [p1,p1+N) to -all pointers in [p2,p2+M). Otherwise, there is a value Q and a value R -such that less returns the same value when comparing all pointers in -[p1,p1+Q) to all pointers in [p2,p2+R) and an opposite value when -comparing all pointers in [p1+Q,p1+N) to all pointers in [p2+R,p2+M). -For the sake of completeness, the null pointer value (4.10) for T is -considered to be an array of 1 object that doesn't overlap with any -non-null pointer to T. less_equal, greater, greater_equal, equal_to, -and not_equal_to give the expected results based on the total ordering -semantics of less. For T of void, treat it as having similar semantics -as T of char i.e. less<cv T*>(a, b) gives the same results as less<cv -void*>(a, b) which gives the same results as less<cv char*>((cv -char*)(cv void*)a, (cv char*)(cv void*)b). -</p></blockquote> - -<p> -I'm also thinking there should be a footnote to 20.5.3/1 saying that if -A and B are similar types (4.4/4), comp<A>(a,b) returns the same value -as comp<B>(a,b) (where comp is less, less_equal, etc.). But this might -be problematic if there is some really funky operator overloading going -on that does different things based on cv (that should be undefined -behavior if somebody does that though). This at least should be -guaranteed for all POD types (especially pointers) that use the -built-in comparison operators. -</p> - - - -<p><b>Rationale:</b></p> -<p> -less is already required to provide a strict weak ordering which is good enough -to detect overlapping memory situations. -</p> - - - - - -<hr> -<h3><a name="504"></a>504. Integer types in pseudo-random number engine requirements</h3> -<p><b>Section:</b> 26.4.1 [rand.req], TR1 5.1.1 [tr.rand.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</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.req">issues</a> in [rand.req].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -In [tr.rand.req], Paragraph 2 states that "... s is a value of integral type, -g is an ... object returning values of unsigned integral type ..." -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -In 5.1.1 [tr.rand.req], Paragraph 2 replace -</p> - -<blockquote><p> -... s is a value of integral type, g is an lvalue of a type other than X that -defines a zero-argument function object returning values of <del>unsigned integral</del> type -<ins><tt>unsigned long int</tt></ins>, -... -</p></blockquote> - -<p> -In 5.1.1 [tr.rand.seq], Table 16, replace in the line for X(s) -</p> - -<blockquote><p> -creates an engine with the initial internal state -determined by <ins><tt>static_cast<unsigned long>(</tt></ins><tt><i>s</i></tt><ins><tt>)</tt></ins> -</p></blockquote> - -<p><i>[ -Mont Tremblant: Both s and g should be unsigned long. -This should refer to the constructor signatures. Jens provided wording post Mont Tremblant. -]</i></p> - - -<p><i>[ -Berlin: N1932 adopts the proposed resolution: see 26.3.1.3/1e and Table 3 row 2. Moved -to Ready. -]</i></p> - - - - -<p><b>Rationale:</b></p> -<p> -Jens: Just requiring X(unsigned long) still makes it possible -for an evil library writer to also supply a X(int) that does something -unexpected. The wording above requires that X(s) always performs -as if X(unsigned long) would have been called. I believe that is -sufficient and implements our intentions from Mont Tremblant. I -see no additional use in actually requiring a X(unsigned long) -signature. u.seed(s) is covered by its reference to X(s), same -arguments. -</p> - - -<p><i>[ -Portland: Subsumed by N2111. -]</i></p> - - - - - -<hr> -<h3><a name="506"></a>506. Requirements of Distribution parameter for variate_generator</h3> -<p><b>Section:</b> 26.4 [rand], TR1 5.1.3 [tr.rand.var] <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">issues</a> in [rand].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -Paragraph 3 requires that template argument U (which corresponds to template -parameter Engine) satisfy all uniform random number generator requirements. -However, there is no analogous requirement regarding the template argument -that corresponds to template parameter Distribution. We believe there should -be, and that it should require that this template argument satisfy all random -distribution requirements. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Consequence 1: Remove the precondition clauses [tr.rand.var]/16 and /18. -</p> -<p> -Consequence 2: Add max() and min() functions to those distributions that -do not already have them. -</p> - -<p><i>[ -Mont Tremblant: Jens reccommends NAD, min/max not needed everywhere. -Marc supports having min and max to satisfy generic programming interface. -]</i></p> - - - - -<p><b>Rationale:</b></p> -<p>Berlin: N1932 makes this moot: variate_generator has been eliminated.</p> - - - - - -<hr> -<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> -In [tr.rand.dist.iunif] the uniform_int distribution currently has a single -template parameter, IntType, used as the input_type and as the result_type -of the distribution. We believe there is no reason to conflate these types -in this way. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -We recommend that there be a second template parameter to -reflect the distribution's input_type, and that the existing first template -parameter continue to reflect (solely) the result_type: -</p> -<blockquote><pre>template< class IntType = int, UIntType = unsigned int > -class uniform_int -{ -public: - // types - typedef UIntType input_type; - typedef IntType result_type; -</pre></blockquote> - -<p><i>[ -Berlin: Moved to NAD. N1932 makes this moot: the input_type template parameter has been -eliminated. -]</i></p> - - - - - - - -<hr> -<h3><a name="510"></a>510. Input_type for bernoulli_distribution</h3> -<p><b>Section:</b> 26.4.8.2 [rand.dist.bern], TR1 5.1.7.2 [tr.rand.dist.bern] <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 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 [tr.rand.dist.bern] the distribution currently requires; -</p> -<blockquote><pre>typedef int input_type; -</pre></blockquote> - - -<p><b>Proposed resolution:</b></p> -<p> -We believe this is an unfortunate choice, and recommend instead: -</p> -<blockquote><pre>typedef unsigned int input_type; -</pre></blockquote> - -<p><i>[ -Berlin: Moved to NAD. N1932 makes this moot: the input_type template parameter has been -eliminated. -]</i></p> - - - - - - - -<hr> -<h3><a name="511"></a>511. Input_type for binomial_distribution</h3> -<p><b>Section:</b> 26.4.8 [rand.dist], TR1 5.1.7.5 [tr.rand.dist.bin] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">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">issues</a> in [rand.dist].</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> -Unlike all other distributions in TR1, this binomial_distribution has an -implementation-defined input_type. We believe this is an unfortunate choice, -because it hinders users from writing portable code. It also hinders the -writing of compliance tests. We recommend instead: -</p> -<blockquote><pre>typedef RealType input_type; -</pre></blockquote> -<p> -While this choice is somewhat arbitrary (as it was for some of the other -distributions), we make this particular choice because (unlike all other -distributions) otherwise this template would not publish its RealType -argument and so users could not write generic code that accessed this -second template parameter. In this respect, the choice is consistent with -the other distributions in TR1. -</p> -<p> -We have two reasons for recommending that a real type be specified instead. -One reason is based specifically on characteristics of binomial distribution -implementations, while the other is based on mathematical characteristics of -probability distribution functions in general. -</p> -<p> -Implementations of binomial distributions commonly use Stirling approximations -for values in certain ranges. It is far more natural to use real values to -represent these approximations than it would be to use integral values to do -so. In other ranges, implementations reply on the Bernoulli distribution to -obtain values. While TR1's bernoulli_distribution::input_type is specified as -int, we believe this would be better specified as double. -</p> -<p> -This brings us to our main point: The notion of a random distribution rests -on the notion of a cumulative distribution function, which in turn mathematically -depends on a continuous dependent variable. Indeed, such a distribution function -would be meaningless if it depended on discrete values such as integers - and this -remains true even if the distribution function were to take discrete steps. -</p> -<p> -Although this note is specifically about binomial_distribution::input_type, -we intend to recommend that all of the random distributions input_types be -specified as a real type (either a RealType template parameter, or double, -as appropriate). -</p> -<p> -Of the nine distributions in TR1, four already have this characteristic -(uniform_real, exponential_distribution, normal_distribution, and -gamma_distribution). We have already argued the case for the binomial the -remaining four distributions. -</p> -<p> -In the case of uniform_int, we believe that the calculations to produce an -integer result in a specified range from an integer in a different specified -range is best done using real arithmetic. This is because it involves a -product, one of whose terms is the ratio of the extents of the two ranges. -Without real arithmetic, the results become less uniform: some numbers become -more (or less) probable that they should be. This is, of course, undesireable -behavior in a uniform distribution. -</p> -<p> -Finally, we believe that in the case of the bernoulli_distribution (briefly -mentioned earlier), as well as the cases of the geometric_distribution and the -poisson_distribution, it would be far more natural to have a real input_type. -This is because the most natural computation involves the random number -delivered and the distribution's parameter p (in the case of bernoulli_distribution, -for example, the computation is a comparison against p), and p is already specified -in each case as having some real type. -</p> - - -<p><b>Proposed resolution:</b></p> -<blockquote><pre>typedef RealType input_type; -</pre></blockquote> - -<p><i>[ -Berlin: Moved to NAD. N1932 makes this moot: the input_type template parameter has been -eliminated. -]</i></p> - - - - - - -<hr> -<h3><a name="512"></a>512. Seeding subtract_with_carry_01 from a single unsigned long</h3> -<p><b>Section:</b> 26.4.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] <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> 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.eng">issues</a> in [rand.eng].</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> -Paragraph 8 specifies the algorithm by which a subtract_with_carry_01 engine -is to be seeded given a single unsigned long. This algorithm is seriously -flawed in the case where the engine parameter w (also known as word_size) -exceeds 31 [bits]. The key part of the paragraph reads: -</p> -<blockquote><p> -sets x(-r) ... x(-1) to (lcg(1)*2**(-w)) mod 1 -</p></blockquote> -<p> -and so forth. -</p> -<p> -Since the specified linear congruential engine, lcg, delivers numbers with -a maximum of 2147483563 (just a shade under 31 bits), then when w is, for -example, 48, each of the x(i) will be less than 2**-17. The consequence -is that roughly the first 400 numbers delivered will be conspicuously -close to either zero or one. -</p> -<p> -Unfortunately, this is not an innocuous flaw: One of the predefined engines -in [tr.rand.predef], namely ranlux64_base_01, has w = 48 and would exhibit -this poor behavior, while the original N1378 proposal states that these -pre-defined engines are intended to be of "known good properties." -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -In 5.1.4.4 [tr.rand.eng.sub1], replace the "effects" clause for -void seed(unsigned long value = 19780503) by -</p> - -<blockquote><p> -<i>Effects:</i> If <tt>value == 0</tt>, sets value to <tt>19780503</tt>. In any -case, <del>with a linear congruential generator <tt>lcg</tt>(i) having parameters -<tt><i>m<sub>lcg</sub></i> = 2147483563</tt>, <tt><i>a<sub>lcg</sub></i> = 40014</tt>, -<tt><i>c<sub>lcg</sub></i> = 0</tt>, and <tt><i>lcg</i>(0) = value</tt>,</del> -sets <ins>carry<tt>(-1)</tt> and</ins> <tt>x(-r) … x(-1)</tt> -<ins>as if executing</ins></p> - -<blockquote><pre><ins> -linear_congruential<unsigned long, 40014, 0, 2147483563> lcg(value); -seed(lcg); -</ins></pre></blockquote> - -<p> -<del>to <tt>(<i>lcg</i>(1) · 2<sup>-<i>w</i></sup>) mod 1 -… (<i>lcg</i>(<i>r</i>) · 2<sup>-<i>w</i></sup>) mod 1</tt>, -respectively. If <tt><i>x</i>(-1) == 0</tt>, sets carry<tt>(-1) = 2<sup>-<i>w</i></sup></tt>, -else sets carry<tt>(-1) = 0</tt>.</del></p> -</blockquote> - -<p><i>[ -Jens provided revised wording post Mont Tremblant. -]</i></p> - - -<p><i>[ -Berlin: N1932 adopts the originally-proposed resolution of the issue. -Jens's supplied wording is a clearer description of what is -intended. Moved to Ready. -]</i></p> - - - - -<p><b>Rationale:</b></p> -<p> -Jens: I'm using an explicit type here, because fixing the -prose would probably not qualify for the (with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a> even -stricter) requirements we have for seed(Gen&). -</p> - -<p><i>[ -Portland: Subsumed by N2111. -]</i></p> - - - - - - -<hr> -<h3><a name="513"></a>513. Size of state for subtract_with_carry_01</h3> -<p><b>Section:</b> 26.4.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] <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> 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.eng">issues</a> in [rand.eng].</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> -Paragraph 3 begins: -</p> -<blockquote><p> -The size of the state is r. -</p></blockquote> -<p> -However, this is not quite consistent with the remainder of the paragraph -which specifies a total of nr+1 items in the textual representation of -the state. We recommend the sentence be corrected to match: -</p> -<blockquote><p> -The size of the state is nr+1. -</p></blockquote> -<p> -To give meaning to the coefficient n, it may be also desirable to move -n's definition from later in the paragraph. Either of the following -seem reasonable formulations: -</p> -<blockquote><p> -With n=..., the size of the state is nr+1. -</p></blockquote> -<blockquote><p> -The size of the state is nr+1, where n=... . -</p></blockquote> - - - -<p><b>Proposed resolution:</b></p> -<p><i>[ -Jens: I plead for "NAD" on the grounds that "size of state" is only -used as an argument for big-O complexity notation, thus -constant factors and additions don't count. -]</i></p> - - -<p><i>[ -Berlin: N1932 adopts the proposed NAD. -]</i></p> - - - - - - - -<hr> -<h3><a name="514"></a>514. Size of state for subtract_with_carry</h3> -<p><b>Section:</b> 26.4.3.3 [rand.eng.sub], TR1 5.1.4.3 [tr.rand.eng.sub] <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> Walter Brown <b>Date:</b> 2005-07-03</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -Paragraph 2 begins: -</p> -<blockquote><p> -The size of the state is r. -</p></blockquote> -<p> -However, the next sentence specifies a total of r+1 items in the textual -representation of the state, r specific x's as well as a specific carry. -This makes a total of r+1 items that constitute the size of the state, -rather than r. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -We recommend the sentence be corrected to match: -</p> -<blockquote><p> - The size of the state is r+1. -</p></blockquote> - -<p><i>[ -Jens: I plead for "NAD" on the grounds that "size of state" is only -used as an argument for big-O complexity notation, thus -constant factors and additions don't count. -]</i></p> - - -<p><i>[ -Berlin: N1932 adopts the proposed NAD. -]</i></p> - - - - - - - -<hr> -<h3><a name="515"></a>515. Random number engine traits</h3> -<p><b>Section:</b> 26.4.2 [rand.synopsis], TR1 5.1.2 [tr.rand.synopsis] <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.synopsis">issues</a> in [rand.synopsis].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -To accompany the concept of a pseudo-random number engine as defined in Table 17, -we propose and recommend an adjunct template, engine_traits, to be declared in -[tr.rand.synopsis] as: -</p> -<blockquote><pre>template< class PSRE > -class engine_traits; -</pre></blockquote> -<p> -This template's primary purpose would be as an aid to generic programming involving -pseudo-random number engines. Given only the facilities described in tr1, it would -be very difficult to produce any algorithms involving the notion of a generic engine. -The intent of this proposal is to provide, via engine_traits<>, sufficient -descriptive information to allow an algorithm to employ a pseudo-random number engine -without regard to its exact type, i.e., as a template parameter. -</p> -<p> -For example, today it is not possible to write an efficient generic function that -requires any specific number of random bits. More specifically, consider a -cryptographic application that internally needs 256 bits of randomness per call: -</p> -<blockquote><pre>template< class Eng, class InIter, class OutIter > -void crypto( Eng& e, InIter in, OutIter out ); -</pre></blockquote> -<p> -Without knowning the number of bits of randomness produced per call to a provided -engine, the algorithm has no means of determining how many times to call the engine. -</p> -<p> -In a new section [tr.rand.eng.traits], we proposed to define the engine_traits -template as: -</p> -<blockquote><pre>template< class PSRE > -class engine_traits -{ - static std::size_t bits_of_randomness = 0u; - static std::string name() { return "unknown_engine"; } - // TODO: other traits here -}; -</pre></blockquote> -<p> -Further, each engine described in [tr.rand.engine] would be accompanied by a -complete specialization of this new engine_traits template. -</p> - - - -<p><b>Proposed resolution:</b></p> -<p><i>[ -Berlin: Walter: While useful for implementation per TR1, N1932 has no need for this -feature. Recommend close as NAD. -]</i></p> - - - -<p><b>Rationale:</b></p> -<p> -Recommend NAD, -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1932.pdf">N1932</a>, -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2111.pdf">N2111</a> -covers this. Already in WP. -</p> - - - - - -<hr> -<h3><a name="516"></a>516. Seeding subtract_with_carry_01 using a generator</h3> -<p><b>Section:</b> 26.4.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] <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> 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.eng">issues</a> in [rand.eng].</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> -Paragraph 6 says: -</p> -<blockquote><p> -... obtained by successive invocations of g, ... -</p></blockquote> -<p> -We recommend instead: -</p> -<blockquote><p> -... obtained by taking successive invocations of g mod 2**32, ... -</p></blockquote> -<p> -as the context seems to require only 32-bit quantities be used here. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Berlin: N1932 adopts the proposed resultion: see 26.3.3.4/7. Moved to Ready. -</p> - -<p><i>[ -Portland: Subsumed by N2111. -]</i></p> - - - - - - -<hr> -<h3><a name="517"></a>517. Should include name in external representation</h3> -<p><b>Section:</b> 26.4.1 [rand.req], TR1 5.1.1 [tr.rand.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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.req">issues</a> in [rand.req].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -The last two rows of Table 16 deal with the i/o requirements of an engine, -specifying that the textual representation of an engine's state, -appropriately formatted, constitute the engine's external representation. -</p> -<p> -This seems adequate when an engine's type is known. However, it seems -inadequate in the context of generic code, where it becomes useful and -perhaps even necessary to determine an engine's type via input. -</p> -<p> -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -We therefore recommend that, in each of these two rows of Table 16, the -text "textual representation" be expanded so as to read "engine name -followed by the textual representation." -</p> - -<p><i>[ -Berlin: N1932 considers this NAD. This is a QOI issue. -]</i></p> - - - - - - - -<hr> -<h3><a name="525"></a>525. type traits definitions not clear</h3> -<p><b>Section:</b> 20.5.4 [meta.unary], TR1 4.5 [tr.meta.unary] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> - <b>Submitter:</b> Robert Klarer <b>Date:</b> 2005-07-11</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -It is not completely clear how the primary type traits deal with -cv-qualified types. And several of the secondary type traits -seem to be lacking a definition. -</p> - -<p><i>[ -Berlin: Howard to provide wording. -]</i></p> - - - -<p><b>Proposed resolution:</b></p> -<p> -Wording provided in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2028.html">N2028</a>. -A -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html">revision (N2157)</a> -provides more detail for motivation. -</p> - - -<p><b>Rationale:</b></p> -Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html">revision (N2157)</a> -in the WP. - - - - - -<hr> -<h3><a name="526"></a>526. Is it undefined if a function in the standard changes in parameters?</h3> -<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2005-09-14</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -Problem: There are a number of places in the C++ standard library where -it is possible to write what appear to be sensible ways of calling -functions, but which can cause problems in some (or all) -implementations, as they cause the values given to the function to be -changed in a way not specified in standard (and therefore not coded to -correctly work). These fall into two similar categories. -</p> - -<p> -1) Parameters taken by const reference can be changed during execution -of the function -</p> - -<p> -Examples: -</p> - -<p> -Given std::vector<int> v: -</p> -<p> -v.insert(v.begin(), v[2]); -</p> -<p> -v[2] can be changed by moving elements of vector -</p> - - -<p> -Given std::list<int> l: -</p> -<p> -l.remove(*l.begin()); -</p> -<p> -Will delete the first element, and then continue trying to access it. -This is particularily vicious, as it will appear to work in almost all -cases. -</p> - -<p> -2) A range is given which changes during the execution of the function: -Similarly, -</p> - -<p> -v.insert(v.begin(), v.begin()+4, v.begin()+6); -</p> - -<p> -This kind of problem has been partly covered in some cases. For example -std::copy(first, last, result) states that result cannot be in the range -[first, last). However, does this cover the case where result is a -reverse_iterator built from some iterator in the range [first, last)? -Also, std::copy would still break if result was reverse_iterator(last + -1), yet this is not forbidden by the standard -</p> - -<p> -Solution: -</p> - -<p> -One option would be to try to more carefully limit the requirements of -each function. There are many functions which would have to be checked. -However as has been shown in the std::copy case, this may be difficult. -A simpler, more global option would be to somewhere insert text similar to: -</p> - -<p> -If the execution of any function would change either any values passed -by reference or any value in any range passed to a function in a way not -defined in the definition of that function, the result is undefined. -</p> - -<p> -Such code would have to at least cover chapters 23 and 25 (the sections -I read through carefully). I can see no harm on applying it to much of -the rest of the standard. -</p> - -<p> -Some existing parts of the standard could be improved to fit with this, -for example the requires for 25.2.1 (Copy) could be adjusted to: -</p> - -<p> -Requires: For each non-negative integer n < (last - first), assigning to -*(result + n) must not alter any value in the range [first + n, last). -</p> - -<p> -However, this may add excessive complication. -</p> - -<p> -One other benefit of clearly introducing this text is that it would -allow a number of small optimisations, such as caching values passed -by const reference. -</p> - -<p> -Matt Austern adds that this issue also exists for the <tt>insert</tt> and -<tt>erase</tt> members of the ordered and unordered associative containers. -</p> - -<p><i>[ -Berlin: Lots of controversey over how this should be solved. Lots of confusion -as to whether we're talking about self referencing iterators or references. -Needs a good survey as to the cases where this matters, for which -implementations, and how expensive it is to fix each case. -]</i></p> - - - - -<p><b>Proposed resolution:</b></p> - - -<p><b>Rationale:</b></p> -<p> -Recommend NAD. -</p> -<ul> -<li><tt>vector::insert(iter, value)</tt> is required to work because the standard -doesn't give permission for it not to work.</li> -<li><tt>list::remove(value)</tt> is required to work because the standard -doesn't give permission for it not to work.</li> -<li><tt>vector::insert(iter, iter, iter)</tt> is not required to work because -23.1.3 [sequence.reqmts], p4 says so.</li> -<li><tt>copy</tt> has to work, except where 25.2.1 [alg.copy] says -it doesn't have to work. While a language lawyer can tear this wording apart, -it is felt that the wording is not prone to accidental interpretation.</li> -<li>The current working draft provide exceptions for the unordered associative -containers similar to the containers requirements which exempt the member -template insert functions from self referencing.</li> -</ul> - - - - - -<hr> -<h3><a name="528"></a>528. <tt>const_iterator</tt> <tt>iterator</tt> issue when they are the same type</h3> -<p><b>Section:</b> 23.4 [unord], TR1 6.3.4 [tr.unord.unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2005-10-12</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord">active issues</a> in [unord].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord">issues</a> in [unord].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -while implementing the resolution of issue 6.19 I'm noticing the -following: according to 6.3.4.3/2 (and 6.3.4.5/2), for unordered_set and -unordered_multiset: -</p> - -<blockquote><p> - "The iterator and const_iterator types are both const types. It is -unspecified whether they are the same type" -</p></blockquote> - -<p> -Now, according to the resolution of 6.19, we have overloads of insert -with hint and erase (single and range) both for iterator and -const_iterator, which, AFAICS, can be meaningful at the same time *only* -if iterator and const_iterator *are* in fact different types. -</p> -<p> -Then, iterator and const_iterator are *required* to be different types? -Or that is an unintended consequence? Maybe the overloads for plain -iterators should be added only to unordered_map and unordered_multimap? -Or, of course, I'm missing something? -</p> - - - -<p><b>Proposed resolution:</b></p> -<p> -Add to 6.3.4.3p2 (and 6.3.4.5p2): -</p> -<p> -2 ... The iterator and const_iterator types are both <del>const</del> -<ins>constant</ins> iterator types. -It is unspecified whether they are the same type. -</p> - -<p> -Add a new subsection to 17.4.4 [lib.conforming]: -</p> - -<blockquote> -<p> -An implementation shall not supply an overloaded function - signature specified in any library clause if such a signature - would be inherently ambiguous during overload resolution - due to two library types referring to the same type. -</p> -<p> - [Note: For example, this occurs when a container's iterator - and const_iterator types are the same. -- end note] -</p> -</blockquote> - -<p><i>[ -Post-Berlin: Beman supplied wording. -]</i></p> - - - - -<p><b>Rationale:</b></p> -Toronto: The first issue has been fixed by N2350 (the insert and erase members -are collapsed into one signature). Alisdair to open a separate issue on the -chapter 17 wording. - - - - - -<hr> -<h3><a name="529"></a>529. The standard encourages redundant and confusing preconditions</h3> -<p><b>Section:</b> 17.4.3.10 [res.on.required] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> - <b>Submitter:</b> David Abrahams <b>Date:</b> 2005-10-25</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<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.4.1.6 [tuple.rel], TR1 6.1.3.5 [tr.tuple.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a> - <b>Submitter:</b> David Abrahams <b>Date:</b> 2005-11-29</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p> -<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a></p> -<p><b>Discussion:</b></p> -<p> -Where possible, tuple comparison operators <,<=,=>, and > ought to be -defined in terms of std::less rather than operator<, in order to -support comparison of tuples of pointers. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -change 6.1.3.5/5 from: -</p> - -<blockquote><p> - Returns: The result of a lexicographical comparison between t and - u. The result is defined as: (bool)(get<0>(t) < get<0>(u)) || - (!(bool)(get<0>(u) < get<0>(t)) && ttail < utail), where rtail for - some tuple r is a tuple containing all but the first element of - r. For any two zero-length tuples e and f, e < f returns false. -</p></blockquote> - -<p> -to: -</p> - -<blockquote> -<p> - Returns: The result of a lexicographical comparison between t and - u. For any two zero-length tuples e and f, e < f returns false. - Otherwise, the result is defined as: cmp( get<0>(t), get<0>(u)) || - (!cmp(get<0>(u), get<0>(t)) && ttail < utail), where rtail for some - tuple r is a tuple containing all but the first element of r, and - cmp(x,y) is an unspecified function template defined as follows. -</p> -<p> - Where T is the type of x and U is the type of y: -</p> - -<p> - if T and U are pointer types and T is convertible to U, returns - less<U>()(x,y) -</p> - -<p> - otherwise, if T and U are pointer types, returns less<T>()(x,y) -</p> - -<p> - otherwise, returns (bool)(x < y) -</p> -</blockquote> - -<p><i>[ -Berlin: This issue is much bigger than just tuple (pair, containers, -algorithms). Dietmar will survey and work up proposed wording. -]</i></p> - - - - -<p><b>Rationale:</b></p> -<p> -Recommend NAD. This will be fixed with the next revision of concepts. -</p> - - - - - -<hr> -<h3><a name="536"></a>536. Container iterator constructor and explicit convertibility</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#Dup">Dup</a> - <b>Submitter:</b> Joaquín M López Muñoz <b>Date:</b> 2005-12-17</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#Dup">Dup</a> status.</p> -<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a></p> -<p><b>Discussion:</b></p> -<p> -The iterator constructor X(i,j) for containers as defined in 23.1.1 and -23.2.2 does only require that i and j be input iterators but -nothing is said about their associated value_type. There are three -sensible -options: -</p> -<ol> -<li>iterator's value_type is exactly X::value_type (modulo cv).</li> -<li>iterator's value_type is *implicitly* convertible to X::value_type.</li> -<li>iterator's value_type is *explicitly* convertible to X::value_type.</li> -</ol> -<p> -The issue has practical implications, and stdlib vendors have -taken divergent approaches to it: Dinkumware follows 2, -libstdc++ follows 3. -</p> -<p> -The same problem applies to the definition of insert(p,i,j) for -sequences and insert(i,j) for associative contianers, as well as -assign. -</p> - -<p><i>[ -The following added by Howard and the example code was originally written by -Dietmar. -]</i></p> - -<p> -Valid code below? -</p> - -<blockquote><pre>#include <vector> -#include <iterator> -#include <iostream> - -struct foo -{ - explicit foo(int) {} -}; - -int main() -{ - std::vector<int> v_int; - std::vector<foo> v_foo1(v_int.begin(), v_int.end()); - std::vector<foo> v_foo2((std::istream_iterator<int>(std::cin)), - std::istream_iterator<int>()); -} -</pre></blockquote> -<p><i>[ -Berlin: Some support, not universal, for respecting the explicit qualifier. -]</i></p> - - - - -<p><b>Proposed resolution:</b></p> - - - - - - -<hr> -<h3><a name="544"></a>544. minor NULL problems in C.2</h3> -<p><b>Section:</b> C.2 [diff.library] <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> 2005-11-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> -According to C.2.2.3, p1, "the macro NULL, defined in any of <clocale>, -<cstddef>, <cstdio>, <cstdlib>, <cstring>, <ctime>, -or <cwchar>." This is consistent with the C standard. -</p> -<p> -However, Table 95 in C.2 fails to mention <clocale> and <cstdlib>. -</p> -<p> -In addition, C.2, p2 claims that "The C++ Standard library provides -54 standard macros from the C library, as shown in Table 95." While -table 95 does have 54 entries, since a couple of them (including the -NULL macro) are listed more than once, the actual number of macros -defined by the C++ Standard Library may not be 54. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -I propose we add <clocale> and <cstdlib> to Table 96 and remove the -number of macros from C.2, p2 and reword the sentence as follows: -</p> -<blockquote><p> -The C++ Standard library <del>provides 54 standard macros from</del> -<ins>defines a number macros corresponding to those defined by</ins> the C -<ins>Standard</ins> library, as shown in Table 96. -</p></blockquote> - -<p><i>[ -Portland: Resolution is considered editorial. It will be incorporated into the WD. -]</i></p> - - - - - - - -<hr> -<h3><a name="547"></a>547. division should be floating-point, not integer</h3> -<p><b>Section:</b> 26.4 [rand], TR1 5.1 [tr.rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand">issues</a> in [rand].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -Paragraph 10 describes how a variate generator uses numbers produced by an -engine to pass to a generator. The sentence that concerns me is: "Otherwise, if -the value for engine_value_type::result_type is true and the value for -Distribution::input_type is false [i.e. if the engine produces integers and the -engine wants floating-point values], then the numbers in s_eng are divided by -engine().max() - engine().min() + 1 to obtain the numbers in s_e." Since the -engine is producing integers, both the numerator and the denominator are -integers and we'll be doing integer division, which I don't think is what we -want. Shouldn't we be performing a conversion to a floating-point type first? -</p> - - -<p><b>Proposed resolution:</b></p> - - -<p><b>Rationale:</b></p> -<p> -Recommend NAD as the affected section is now gone and so the issue is moot. -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2111.pdf">N2111</a>. -</p> - - - - - -<hr> -<h3><a name="548"></a>548. May random_device block?</h3> -<p><b>Section:</b> 26.4.6 [rand.device], TR1 5.1.6 [tr.rand.device] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -Class random_device "produces non-deterministic random numbers", using some -external source of entropy. In most real-world systems, the amount of available -entropy is limited. Suppose that entropy has been exhausted. What is an -implementation permitted to do? In particular, is it permitted to block -indefinitely until more random bits are available, or is the implementation -required to detect failure immediately? This is not an academic question. On -Linux a straightforward implementation would read from /dev/random, and "When -the entropy pool is empty, reads to /dev/random will block until additional -environmental noise is gathered." Programmers need to know whether random_device -is permitted to (or possibly even required to?) behave the same way. -</p> - -<p><i>[ -Berlin: Walter: N1932 considers this NAD. Does the standard specify whether std::cin -may block? -]</i></p> - - -<p> -See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> -for some further discussion. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Adopt the proposed resolution in -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> (NAD). -</p> - - - - - -<hr> -<h3><a name="549"></a>549. Undefined variable in binomial_distribution</h3> -<p><b>Section:</b> 26.4.8 [rand.dist], TR1 5.1.7.5 [tr.rand.dist.bin] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> - <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist">issues</a> in [rand.dist].</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> -Paragraph 1 says that "A binomial distributon random distribution produces -integer values i>0 with p(i) = (n choose i) * p*i * (1-p)^(t-i), where t and -p are the parameters of the distribution. OK, that tells us what t, p, and i -are. What's n? -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Berlin: Typo: "n" replaced by "t" in N1932: see 26.3.7.2.2/1. -</p> - -<p><i>[ -Portland: Subsumed by N2111. -]</i></p> - - - - - - -<hr> -<h3><a name="553"></a>553. very minor editorial change intptr_t / uintptr_t</h3> -<p><b>Section:</b> 18.3.1 [cstdint.syn], TR1 8.22.1 [tr.c99.cstdint.syn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> - <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-01-30</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint.syn">issues</a> in [cstdint.syn].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -In the synopsis, some types are identified as optional: int8_t, int16_t, -and so on, consistently with C99, indeed. -</p> -<p> -On the other hand, intptr_t and uintptr_t, are not marked as such and -probably should, consistently with C99, 7.18.1.4. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Change 18.3.1 [cstdint.syn]: -</p> - -<blockquote><pre>... -typedef <i>signed integer type</i> intptr_t; <ins><i>// optional</i></ins> -... -typedef <i>unsigned integer type</i> uintptr_t; <ins><i>// optional</i></ins> -... -</pre></blockquote> - - - -<p><b>Rationale:</b></p> -Recommend NAD and fix as editorial with the proposed resolution. - - - - - -<hr> -<h3><a name="554"></a>554. Problem with lwg DR 184 numeric_limits<bool></h3> -<p><b>Section:</b> 18.2.1.5 [numeric.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-01-29</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.special">issues</a> in [numeric.special].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -I believe we have a bug in the resolution of: -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#184">lwg 184</a> -(WP status). -</p> - -<p> -The resolution spells out each member of <tt>numeric_limits<bool></tt>. -The part I'm having a little trouble with is: -</p> -<blockquote><pre>static const bool traps = false; -</pre></blockquote> - -<p> -Should this not be implementation defined? Given: -</p> - -<blockquote><pre>int main() -{ - bool b1 = true; - bool b2 = false; - bool b3 = b1/b2; -} -</pre></blockquote> - -<p> -If this causes a trap, shouldn't <tt>numeric_limits<bool>::traps</tt> be -<tt>true</tt>? -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Change 18.2.1.5p3: -</p> - -<blockquote><p> --3- The specialization for <tt>bool</tt> shall be provided as follows: </p> -<blockquote><pre>namespace std { - template <> class numeric_limits<bool> { - ... - static const bool traps = <del>false</del> <ins><i>implementation-defined</i></ins>; - ... - }; -} -</pre></blockquote> -</blockquote> - -<p><i>[ -Redmond: NAD because traps refers to values, not operations. There is no bool -value that will trap. -]</i></p> - - - - - - - -<hr> -<h3><a name="555"></a>555. TR1, 8.21/1: typo</h3> -<p><b>Section:</b> TR1 8.21 [tr.c99.boolh] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> - <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-02-02</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -This one, if nobody noticed it yet, seems really editorial: -s/cstbool/cstdbool/ -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Change 8.21p1: -</p> -<blockquote><p> --1- The header behaves as if it defines the additional macro defined in -<tt><cst<ins>d</ins>bool></tt> by including the header <tt><cstdbool></tt>. -</p></blockquote> - -<p><i>[ -Redmond: Editorial. -]</i></p> - - - - - - - -<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">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#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -I'm seeing a problem with such overloads: when, _Longlong == intmax_t == -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> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.iterators">issues</a> in [input.iterators].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<blockquote> -<p> - 24.1.1 Input iterators [lib.input.iterators] -</p> -<p> - 1 A class or a built-in type X satisfies the requirements of an - input iterator for the value type T if the following expressions are - valid, where U is the type of any specified member of type T, as - shown in Table 73. -</p> -</blockquote> -<p> -There is no capital U used in table 73. There is a lowercase u, but -that is clearly not meant to denote a member of type T. Also, there's -no description in 24.1.1 of what lowercase a means. IMO the above -should have been...Hah, a and b are already covered in 24.1/11, so maybe it -should have just been: -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Change 24.1.1p1: -</p> -<blockquote><p> --1- A class or a built-in type <tt>X</tt> satisfies the requirements of an -input iterator for the value type <tt>T</tt> if the following expressions -are valid<del>, where <tt>U</tt> is the type of any specified member of type -<tt>T</tt>,</del> as shown in Table 73. -</p></blockquote> - -<p><i>[ -Portland: Editorial. -]</i></p> - - - - - - - -<hr> -<h3><a name="560"></a>560. User-defined allocators without default constructor</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#NAD">NAD</a> - <b>Submitter:</b> Sergey P. Derevyago <b>Date:</b> 2006-02-17</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<h4>1. The essence of the problem.</h4> -<p> -User-defined allocators without default constructor are not explicitly -supported by the standard but they can be supported just like std::vector -supports elements without default constructor. -</p> -<p> -As a result, there exist implementations that work well with such allocators -and implementations that don't. -</p> - -<h4>2. The cause of the problem.</h4> -<p> -1) The standard doesn't explicitly state this intent but it should. In -particular, 20.1.5p5 explicitly state the intent w.r.t. the allocator -instances that compare non-equal. So it can similarly state the intent w.r.t. -the user-defined allocators without default constructor. -</p> -<p> -2) Some container operations are obviously underspecified. In particular, -21.3.7.1p2 tells: -</p> -<blockquote><pre>template<class charT, class traits, class Allocator> - basic_string<charT,traits,Allocator> operator+( - const charT* lhs, - const basic_string<charT,traits,Allocator>& rhs - ); -</pre> -<p> -Returns: <tt>basic_string<charT,traits,Allocator>(lhs) + rhs</tt>. -</p> -</blockquote> -<p> -That leads to the basic_string<charT,traits,Allocator>(lhs, Allocator()) call. -Obviously, the right requirement is: -</p> -<blockquote><p> -Returns: <tt>basic_string<charT,traits,Allocator>(lhs, rhs.get_allocator()) + rhs</tt>. -</p></blockquote> -<p> -It seems like a lot of DRs can be submitted on this "Absent call to -get_allocator()" topic. -</p> - -<h4>3. Proposed actions.</h4> -<p> -1) Explicitly state the intent to allow for user-defined allocators without -default constructor in 20.1.5 Allocator requirements. -</p> -<p> -2) Correct all the places, where a correct allocator object is available -through the get_allocator() call but default Allocator() gets passed instead. -</p> -<h4>4. Code sample.</h4> -<p> -Let's suppose that the following memory pool is available: -</p> -<blockquote><pre>class mem_pool { - // ... - void* allocate(size_t size); - void deallocate(void* ptr, size_t size); -}; -</pre></blockquote> -<p> -So the following allocator can be implemented via this pool: -</p> -<blockquote><pre>class stl_allocator { - mem_pool& pool; - - public: - explicit stl_allocator(mem_pool& mp) : pool(mp) {} - stl_allocator(const stl_allocator& sa) : pool(sa.pool) {} - template <class U> - stl_allocator(const stl_allocator<U>& sa) : pool(sa.get_pool()) {} - ~stl_allocator() {} - - pointer allocate(size_type n, std::allocator<void>::const_pointer = 0) - { - return (n!=0) ? static_cast<pointer>(pool.allocate(n*sizeof(T))) : 0; - } - - void deallocate(pointer p, size_type n) - { - if (n!=0) pool.deallocate(p, n*sizeof(T)); - } - - // ... -}; -</pre></blockquote> -<p> -Then the following code works well on some implementations and doesn't work on -another: -</p> -<blockquote><pre>typedef basic_string<char, char_traits<char>, stl_allocator<char> > - tl_string; -mem_pool mp; -tl_string s1("abc", stl_allocator<int>(mp)); -printf("(%s)\n", ("def"+s1).c_str()); -</pre></blockquote> -<p> -In particular, on some implementations the code can't be compiled without -default stl_allocator() constructor. -</p> -<p> -The obvious way to solve the compile-time problems is to intentionally define -a NULL pointer dereferencing default constructor -</p> -<blockquote><pre>stl_allocator() : pool(*static_cast<mem_pool*>(0)) {} -</pre></blockquote> -<p> -in a hope that it will not be called. The problem is that it really gets -called by operator+(const char*, const string&) under the current 21.3.7.1p2 -wording. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -</p> - - -<p><b>Rationale:</b></p> -<p> -Recommend NAD. <tt>operator+()</tt> with <tt>string</tt> already requires the desired -semantics of copying the allocator from one of the strings (<i>lhs</i> when there is a choice). -</p> - - - - - -<hr> -<h3><a name="569"></a>569. Postcondition for basic_ios::clear(iostate) incorrectly stated</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> Seungbeom Kim <b>Date:</b> 2006-03-10</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostate.flags">issues</a> in [iostate.flags].</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#272">272</a></p> -<p><b>Discussion:</b></p> -<p> -Section: 27.4.4.3 [lib.iostate.flags] -</p> -<p> -Paragraph 4 says: -</p> -<blockquote> -<blockquote><pre>void clear(iostate <i>state</i> = goodbit); -</pre></blockquote> -<p> -<i>Postcondition:</i> If <tt>rdbuf()!=0</tt> then <tt><i>state</i> == rdstate();</tt> -otherwise <tt>rdstate()==<i>state</i>|ios_base::badbit</tt>. -</p> -</blockquote> - -<p> -The postcondition "rdstate()==state|ios_base::badbit" is parsed as -"(rdstate()==state)|ios_base::badbit", which is probably what the -committee meant. -</p> - - - - -<p><b>Rationale:</b></p> - - - - - - -<hr> -<h3><a name="570"></a>570. Request adding additional explicit specializations of char_traits</h3> -<p><b>Section:</b> 21.1 [char.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Jack Reeves <b>Date:</b> 2006-04-06</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits">issues</a> in [char.traits].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -Currently, the Standard Library specifies only a declaration for template class -char_traits<> and requires the implementation provide two explicit -specializations: char_traits<char> and char_traits<wchar_t>. I feel the Standard -should require explicit specializations for all built-in character types, i.e. -char, wchar_t, unsigned char, and signed char. -</p> -<p> -I have put together a paper -(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1985.htm">N1985</a>) -that describes this in more detail and -includes all the necessary wording. -</p> -<p><i>[ -Portland: Jack will rewrite -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1985.htm">N1985</a> -to propose a primary template that will work with other integral types. -]</i></p> - -<p><i>[ -Toronto: issue has grown with addition of <tt>char16_t</tt> and <tt>char32_t</tt>. -]</i></p> - - -<p><i>[ -post Bellevue: -]</i></p> - - -<blockquote> -<p> -We suggest that Jack be asked about the status of his paper, and if it -is not forthcoming, the work-item be assigned to someone else. If no one -steps forward to do the paper before the next meeting, we propose to -make this NAD without further discussion. We leave this Open for now, -but our recommendation is NAD. -</p> -<p> -Note: the issue statement should be updated, as the Toronto comment has -already been resolved. E.g., char_traits specializations for char16_t -and char32_t are now in the working paper. -</p> -</blockquote> - -<p><i>[ -Sophia Antipolis: -]</i></p> - - -<blockquote> -Nobody has submitted the requested paper, so we move to NAD, as suggested by the decision at the last meeting. -</blockquote> - - -<p><b>Proposed resolution:</b></p> - - - - - -<hr> -<h3><a name="571"></a>571. Update C90 references to C99?</h3> -<p><b>Section:</b> 1.2 [intro.refs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> - <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-04-08</p> -<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%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -1.2 Normative references [intro.refs] of the WP currently refers to ISO/IEC -9899:1990, Programming languages - C. Should that be changed to ISO/IEC -9899:1999? -</p> -<p> -What impact does this have on the library? -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -In 1.2/1 [intro.refs] of the WP, change: -</p> -<blockquote> -<ul> -<li>ISO/IEC 9899:<del>1990</del><ins>1999 + TC1 + TC2</ins>, <i>Programming languages - C</i></li> -</ul> -</blockquote> - - - -<p><b>Rationale:</b></p> -Recommend NAD, fixed editorially. - - - - - -<hr> -<h3><a name="572"></a>572. Oops, we gave 507 WP status</h3> -<p><b>Section:</b> 26.4 [rand], TR1 5.1 [tr.rand] <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> 2006-04-11</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand">issues</a> in [rand].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -In Berlin, as a working group, we voted in favor of N1932 which makes issue 507 moot: -variate_generator has been eliminated. Then in full committee we voted to give -this issue WP status (mistakenly). -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Strike the proposed resolution of issue 507. -</p> -<p><i>[ -post-Portland: Walter and Howard recommend NAD. The proposed resolution of 507 no longer -exists in the current WD. -]</i></p> - - - -<p><b>Rationale:</b></p> -<p> -NAD. Will be moot once -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2135.pdf">N2135</a> -is adopted. -</p> - - - - - -<hr> -<h3><a name="579"></a>579. erase(iterator) for unordered containers should not return an iterator</h3> -<p><b>Section:</b> 23.1.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Joaquín M López Muñoz <b>Date:</b> 2006-06-13</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<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> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -There is no div() function for unsigned integer types. -</p> -<p> -There are several possible resolutions. The simplest one is noted below. Other -possibilities include a templated solution. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Add to 26.7 [lib.c.math] paragraph 8: -</p> - -<blockquote><pre>struct udiv_t div(unsigned, unsigned); -struct uldiv_t div(unsigned long, unsigned long); -struct ulldiv_t div(unsigned long long, unsigned long long); -</pre></blockquote> - - - -<p><b>Rationale:</b></p> -Toronto: C99 does not have these unsigned versions because -the signed version exist just to define the implementation-defined behavior -of signed integer division. Unsigned integer division has no implementation-defined -behavior and thus does not need this treatment. - - - - - -<hr> -<h3><a name="584"></a>584. missing int pow(int,int) functionality</h3> -<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-06-15</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -There is no pow() function for any integral type. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Add something like: -</p> - -<blockquote><pre>template< typename T> -T power( T x, int n ); -// requires: n >=0 -</pre></blockquote> - - -<p><b>Rationale:</b></p> -Toronto: We already have double pow(integral, integral) from 26.7 [c.math] p11. - - - - - -<hr> -<h3><a name="587"></a>587. iststream ctor missing description</h3> -<p><b>Section:</b> D.7.2.1 [depr.istrstream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> - <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-22</p> -<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 <code>iststream(char*, streamsize)</code> ctor is in the class -synopsis in D.7.2 but its signature is missing in the description -below (in D.7.2.1). - - </p> - - - <p><b>Proposed resolution:</b></p> - <p> - -This seems like a simple editorial issue and the missing signature can -be added to the one for <code>const char*</code> in paragraph 2. - - </p> - -<p><i>[ -post Oxford: Noted that it is already fixed in -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a> -]</i></p> - - - - - - -<hr> -<h3><a name="590"></a>590. Type traits implementation latitude should be removed for C++0x</h3> -<p><b>Section:</b> 20.5 [meta], TR1 4.9 [tr.meta.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> - <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-08-10</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta">issues</a> in [meta].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -20.4.9 [lib.meta.req], Implementation requirements, provides latitude for type -traits implementers that is not needed in C++0x. It includes the wording: -</p> - -<blockquote><p> -[<i>Note:</i> the latitude granted to implementers in this clause is temporary, -and is expected to be removed in future revisions of this document. -- <i>end note</i>] -</p></blockquote> - -<p> -Note: -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html">N2157: Minor Modifications to the type traits Wording</a> -also has the intent of removing this wording from the WP. -</p> - - - -<p><b>Proposed resolution:</b></p> -<p> -Remove 20.4.9 [lib.meta.req] in its entirety from the WP. -</p> - -<p><i>[ -post-Oxford: Recommend NAD Editorial. This resolution is now in the -current working draft. -]</i></p> - - - - - - - -<hr> -<h3><a name="591"></a>591. Misleading "built-in</h3> -<p><b>Section:</b> 18.2.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> - <b>Submitter:</b> whyglinux <b>Date:</b> 2006-08-08</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.limits.members">issues</a> in [numeric.limits.members].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -18.2.1.2 numeric_limits members [lib.numeric.limits.members] -Paragraph 7: -</p> -<blockquote><p> -"For built-in integer types, the number of non-sign bits in the -representation." -</p></blockquote> - -<p> -26.1 Numeric type requirements [lib.numeric.requirements] -Footnote: -</p> - -<blockquote><p> -"In other words, value types. These include built-in arithmetic types, -pointers, the library class complex, and instantiations of valarray for -value types." -</p></blockquote> - -<p> -Integer types (which are bool, char, wchar_t, and the signed and -unsigned integer types) and arithmetic types (which are integer and -floating types) are all built-in types and thus there are no -non-built-in (that is, user-defined) integer or arithmetic types. Since -the redundant "built-in" in the above 2 sentences can mislead that -there may be built-in or user-defined integer and arithmetic types -(which is not correct), the "built-in" should be removed. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -18.2.1.2 numeric_limits members [lib.numeric.limits.members] -Paragraph 7: -</p> -<blockquote><p> -"For <del>built-in</del> integer types, the number of non-sign bits in the -representation." -</p></blockquote> - -<p> -26.1 Numeric type requirements [lib.numeric.requirements] -Footnote: -</p> - -<blockquote><p> -"In other words, value types. These include <del>built-in</del> arithmetic types, -pointers, the library class complex, and instantiations of valarray for -value types." -</p></blockquote> - - -<p><b>Rationale:</b></p> -<p> -Recommend NAD / Editorial. The proposed resolution is accepted as editorial. -</p> - - - - - -<hr> -<h3><a name="592"></a>592. Incorrect treatment of rdbuf()->close() return type</h3> -<p><b>Section:</b> 27.8.1.9 [ifstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> - <b>Submitter:</b> Christopher Kohlhoff <b>Date:</b> 2006-08-17</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ifstream.members">issues</a> in [ifstream.members].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -I just spotted a minor problem in 27.8.1.7 -[lib.ifstream.members] para 4 and also 27.8.1.13 -[lib.fstream.members] para 4. In both places it says: -</p> -<blockquote> -<pre>void close(); -</pre> -<p> -Effects: Calls rdbuf()->close() and, if that function returns false, ... -</p> -</blockquote> -<p> -However, basic_filebuf::close() (27.8.1.2) returns a pointer to the -filebuf on success, null on failure, so I think it is meant to -say "if that function returns a null pointer". Oddly, it is -correct for basic_ofstream. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Change 27.8.1.9 [ifstream.members], p5: -</p> - -<blockquote><p> -<i>Effects:</i> Calls <tt>rdbuf()->close()</tt> and, if that function -<ins>fails (</ins>returns <del><tt>false</tt></del> <ins>a null pointer)</ins>, -calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt> -(27.4.4.3)). -</p></blockquote> - -<p> -Change 27.8.1.17 [fstream.members], p5: -</p> - -<blockquote><p> -<i>Effects:</i> Calls <tt>rdbuf()->close()</tt> and, if that function -<ins>fails (</ins>returns <del><tt>false</tt></del> <ins>a null pointer)</ins>, -calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt> -(27.4.4.3)). -</p></blockquote> - - - -<p><i>[ -Kona (2007): Proposed Disposition: NAD, Editorial -]</i></p> - - - - - -<hr> -<h3><a name="594"></a>594. Disadvantages of defining Swappable in terms of CopyConstructible and Assignable</h3> -<p><b>Section:</b> 20.1.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a> - <b>Submitter:</b> Niels Dekker <b>Date:</b> 2006-11-02</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -It seems undesirable to define the Swappable requirement in terms of -CopyConstructible and Assignable requirements. And likewise, once the -MoveConstructible and MoveAssignable requirements (N1860) have made it -into the Working Draft, it seems undesirable to define the Swappable -requirement in terms of those requirements. Instead, it appears -preferable to have the Swappable requirement defined exclusively in -terms of the existence of an appropriate swap function. -</p> -<p> -Section 20.1.4 [lib.swappable] of the current Working Draft (N2009) -says: -</p> -<blockquote><p> -The Swappable requirement is met by satisfying one or more of the -following conditions:</p> -<ul> -<li> -T is Swappable if T satisfies the CopyConstructible requirements -(20.1.3) and the Assignable requirements (23.1); -</li> -<li> -T is Swappable if a namespace scope function named swap exists in the -same namespace as the definition of T, such that the expression -swap(t,u) is valid and has the semantics described in Table 33. -</li> -</ul> -</blockquote> -I can think of three disadvantages of this definition: -<ol> -<li> -If a client's type T satisfies the first condition (T is both -CopyConstructible and Assignable), the client cannot stop T from -satisfying the Swappable requirement without stopping T from -satisfying the first condition. -<p> -A client might want to stop T from satisfying the Swappable -requirement, because swapping by means of copy construction and -assignment might throw an exception, and she might find a throwing -swap unacceptable for her type. On the other hand, she might not feel -the need to fully implement her own swap function for this type. In -this case she would want to be able to simply prevent algorithms that -would swap objects of type T from being used, e.g., by declaring a -swap function for T, and leaving this function purposely undefined. -This would trigger a link error, if an attempt would be made to use -such an algorithm for this type. For most standard library -implementations, this practice would indeed have the effect of -stopping T from satisfying the Swappable requirement. -</p> -</li> -<li> -A client's type T that does not satisfy the first condition can not be -made Swappable by providing a specialization of std::swap for T. -<p> -While I'm aware about the fact that people have mixed feelings about -providing a specialization of std::swap, it is well-defined to do so. -It sounds rather counter-intuitive to say that T is not Swappable, if -it has a valid and semantically correct specialization of std::swap. -Also in practice, providing such a specialization will have the same -effect as satisfying the Swappable requirement. -</p> -</li> -<li> -For a client's type T that satisfies both conditions of the Swappable -requirement, it is not specified which of the two conditions prevails. -After reading section 20.1.4 [lib.swappable], one might wonder whether -objects of T will be swapped by doing copy construction and -assignments, or by calling the swap function of T. -<p> -I'm aware that the intention of the Draft is to prefer calling the -swap function of T over doing copy construction and assignments. Still -in my opinion, it would be better to make this clear in the wording of -the definition of Swappable. -</p> -</li> -</ol> -<p> -I would like to have the Swappable requirement defined in such a way -that the following code fragment will correctly swap two objects of a -type T, if and only if T is Swappable: -</p> -<pre> using std::swap; - swap(t, u); // t and u are of type T. -</pre> -<p> -This is also the way Scott Meyers recommends calling a swap function, -in Effective C++, Third Edition, item 25. -</p> -<p> -Most aspects of this issue have been dealt with in a discussion on -comp.std.c++ about the Swappable requirement, from 13 September to 4 -October 2006, including valuable input by David Abrahams, Pete Becker, -Greg Herlihy, Howard Hinnant and others. -</p> - -<p><b>Proposed resolution:</b></p> -<p> -Change section 20.1.4 [lib.swappable] as follows: -</p> -<blockquote><p> -The Swappable requirement is met by satisfying -<del>one or more of the following conditions:</del> -<ins>the following condition:</ins></p> -<ul> - -<li> -<del>T is Swappable if T satisfies the CopyConstructible requirements -(20.1.3) and the Assignable requirements (23.1);</del> -</li> -<li> -<del> -T is Swappable if a namespace scope function named swap exists in the -same namespace as the definition of T, such that the expression -swap(t,u) is valid and has the semantics described in Table 33. -</del> -T is Swappable if an unqualified function call swap(t,u) is valid -within the namespace std, and has the semantics described in Table 33. -</li> -</ul> -</blockquote> - - -<p><b>Rationale:</b></p> -<p> -Recommend NAD. Concepts, specifically -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2082.pdf">N2082</a> -and -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2084.pdf">N2084</a>, -will essentially rewrite this section and provide the desired semantics. -</p> - - - - - -<hr> -<h3><a name="615"></a>615. Inconsistencies in Section 21.4</h3> -<p><b>Section:</b> 21.5 [c.strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> - <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-11</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.strings">issues</a> in [c.strings].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -In the current draft N2134, 21.4/1 says -</p> -<p> -"Tables 59,228) 60, 61, 62,and 63 229) 230) describe headers <cctype>, -<cwctype>, <cstring>, <cwchar>, and <cstdlib> (character conversions), -respectively." -</p> -<p> -Here footnote 229 applies to table 62, not table 63. -</p> -<p> -Also, footnote 230 lists the new functions in table 63, "atoll, strtoll, -strtoull, strtof, and strtold added by TR1". However, strtof is not present -in table 63. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -</p> - - -<p><b>Rationale:</b></p> -<p> -Recommend NAD, editorial. Send to Pete. -</p> - - - - - -<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><i>[ -Post-Sophia Antipolis: Martin indicates there is still work to be done on this issue. -Reopened. -]</i></p> - - - - -<p><b>Proposed resolution:</b></p> -<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.6.15.2.5 [func.wrap.func.targ] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> - <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-03</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -20.6.15.2.5 [func.wrap.func.targ], p4 says: -</p> -<blockquote><p> -<i>Returns:</i> If <tt>type() == typeid(T)</tt>, a pointer to the stored -function target; otherwise a null pointer. -</p></blockquote> - -<ol> -<li> -There exists neither a type, a typedef <tt>type</tt>, nor member -function <tt>type()</tt> in class template function nor in the global or -<tt>std</tt> namespace. -</li> -<li> -Assuming that <tt>type</tt> should have been <tt>target_type()</tt>, -this description would lead to false results, if <tt>T = <i>cv</i> -void</tt> due to returns clause 20.6.15.2.5 [func.wrap.func.targ], p1. -</li> -</ol> - - - -<p><b>Proposed resolution:</b></p> -<p> -Change 20.6.15.2.5 [func.wrap.func.targ], p4: -</p> - -<blockquote><p> -<i>Returns:</i> If <tt><del>type()</del> <ins>target_type()</ins> == typeid(T) <ins>&& typeid(T) != -typeid(void)</ins></tt>, a pointer to the stored function target; -otherwise a null pointer. -</p></blockquote> - -<p><i>[ -Pete: Agreed. It's editorial, so I'll fix it. -]</i></p> - - - - - - - -<hr> -<h3><a name="636"></a>636. 26.5.2.3 valarray::operator[]</h3> -<p><b>Section:</b> 26.5.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> - <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-02-11</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.access">issues</a> in [valarray.access].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -The signature of the const operator[] has been changed to return a const -reference. -</p> -<p> -The description in paragraph 1 still says that the operator returns by -value. -</p> -<p><i>[ -Pete recommends editorial fix. -]</i></p> - - - -<p><b>Proposed resolution:</b></p> -<p> -</p> - - - - - -<hr> -<h3><a name="637"></a>637. [c.math]/10 inconsistent return values</h3> -<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> - <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-02-13</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -26.7 [c.math], paragraph 10 has long lists of added signatures for float and long double -functions. All the signatures have float/long double return values, which is -inconsistent with some of the double functions they are supposed to -overload. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Change 26.7 [c.math], paragraph 10, -</p> - -<blockquote><pre><del>float</del> <ins>int</ins> ilogb(float); -<del>float</del> <ins>long</ins> lrint(float); -<del>float</del> <ins>long</ins> lround(float); -<del>float</del> <ins>long long</ins> llrint(float); -<del>float</del> <ins>long long</ins> llround(float); - -<del>long double</del> <ins>int</ins> ilogb(long double); -<del>long double</del> <ins>long</ins> lrint(long double); -<del>long double</del> <ins>long</ins> lround(long double); -<del>long double</del> <ins>long long</ins> llrint(long double); -<del>long double</del> <ins>long long</ins> llround(long double); -</pre></blockquote> - - - - - -<hr> -<h3><a name="639"></a>639. Still problems with exceptions during streambuf IO</h3> -<p><b>Section:</b> 27.6.1.2.3 [istream::extractors], 27.6.2.6.3 [ostream.inserters] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-17</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -There already exist two active DR's for the wording of 27.6.1.2.3 [istream::extractors]/13 -from 14882:2003(E), namely <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#413">413</a>. -</p> - -<p> -Even with these proposed corrections, already maintained in N2134, -I have the feeling, that the current wording does still not properly -handle the "exceptional" situation. The combination of para 14 -</p> - -<blockquote><p> -"[..] Characters are extracted and inserted until -any of the following occurs: -</p> -<p> -[..] -</p> -<p> -- an exception occurs (in which case the exception is caught)." -</p></blockquote> - -<p> -and 15 -</p> - -<blockquote><p> -"If the function inserts no characters, it calls setstate(failbit), -which -may throw ios_base::failure (27.4.4.3). If it inserted no characters -because it caught an exception thrown while extracting characters -from *this and failbit is on in exceptions() (27.4.4.3), then the -caught -exception is rethrown." -</p></blockquote> - -<p> -both in N2134 seems to imply that any exception, which occurs -*after* at least one character has been inserted is caught and lost -for -ever. It seems that even if failbit is on in exceptions() rethrow is -not -allowed due to the wording "If it inserted no characters because it -caught an exception thrown while extracting". -</p> - -<p> -Is this behaviour by design? -</p> - -<p> -I would like to add that its output counterpart in 27.6.2.6.3 [ostream.inserters]/7-9 -(also -N2134) does not demonstrate such an exception-loss-behaviour. -On the other side, I wonder concerning several subtle differences -compared to input:: -</p> -<p> -1) Paragraph 8 says at its end: -</p> - -<blockquote><p> -"- an exception occurs while getting a character from sb." -</p></blockquote> - -<p> -Note that there is nothing mentioned which would imply that such -an exception will be caught compared to 27.6.1.2.3 [istream::extractors]/14. -</p> - -<p> -2) Paragraph 9 says: -</p> - -<blockquote><p> -"If the function inserts no characters, it calls setstate(failbit) -(which -may throw ios_base::failure (27.4.4.3)). If an exception was thrown -while extracting a character, the function sets failbit in error -state, -and if failbit is on in exceptions() the caught exception is -rethrown." -</p></blockquote> - -<p> -The sentence starting with "If an exception was thrown" seems to -imply that such an exception *should* be caught before. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -(a) In 27.6.1.2.3 [istream::extractors]/15 (N2134) change the sentence -</p> - -<blockquote><p> -If the function inserts no characters, it calls -<tt>setstate(failbit)</tt>, which may throw <tt>ios_base::failure</tt> -(27.4.4.3). If <del>it inserted no characters because it caught an -exception thrown while extracting characters from <tt>*this</tt></del> -<ins>an exception was thrown while extracting a character from -<tt>*this</tt>, the function sets <tt>failbit</tt> in error state,</ins> -and <tt>failbit</tt> is on in <tt>exceptions()</tt> (27.4.4.3), then the -caught exception is rethrown. -</p></blockquote> - -<p> -(b) In 27.6.2.6.3 [ostream.inserters]/8 (N2134) change the sentence: -</p> - -<blockquote> -<p> -Gets characters from <tt>sb</tt> and inserts them in <tt>*this</tt>. -Characters are read from <tt>sb</tt> and inserted until any of the -following occurs: -</p> -<ul> -<li>end-of-file occurs on the input sequence;</li> -<li>inserting in the output sequence fails (in which case the character to be inserted is not extracted);</li> -<li>an exception occurs while getting a character from <tt>sb</tt> <ins>(in which -case the exception is caught)</ins>.</li> -</ul> -</blockquote> - - - -<p><b>Rationale:</b></p> -This extractor is described as a formatted input function so the -exception behavior is already specified. There is additional behavior -described in this section that applies to the case in which failbit is -set. This doesn't contradict the usual exception behavior for formatted -input functions because that applies to the case in which badbit is set. - - - - - -<hr> -<h3><a name="641"></a>641. Editorial fix for 27.6.4 (N2134)</h3> -<p><b>Section:</b> 27.6.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">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> -<p> -The function <tt>f</tt> in para 4 (27.6.4 [ext.manip]) references an unknown <tt>strm</tt> -in the following line: -</p> - -<blockquote><pre>mg.get(Iter(str.rdbuf()), Iter(), intl, strm, err, mon); -</pre></blockquote> - - -<p><b>Proposed resolution:</b></p> -<p> -Change 27.6.4 [ext.manip], p4: -</p> - -<blockquote><pre>mg.get(Iter(str.rdbuf()), Iter(), intl, str<del>m</del>, err, mon); -</pre></blockquote> - -<p><i>[ -Oxford: Editorial. -]</i></p> - - - - - - - -<hr> -<h3><a name="642"></a>642. Invalidated fstream footnotes in N2134</h3> -<p><b>Section:</b> 27.8.1.9 [ifstream.members], 27.8.1.13 [ofstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> - <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-02-20</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ifstream.members">issues</a> in [ifstream.members].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -The standard wording of N2134 has extended the 14882:2003(E) -wording for the ifstream/ofstream/fstream open function to fix -a long standing problem, see <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#409">409</a>. -</p> - -<p> -Now it's properly written as -</p> - -<blockquote><p> -"If that function does not return a null pointer calls clear(), -otherwise -calls setstate(failbit)[..]" -</p></blockquote> - -<p> -instead of the previous -</p> - -<blockquote><p> -"If that function returns a null pointer, calls setstate(failbit)[..] -</p></blockquote> - -<p> -While the old footnotes saying -</p> - -<blockquote><p> -"A successful open does not change the error state." -</p></blockquote> - -<p> -where correct and important, they are invalid now for ifstream and -ofstream (because clear *does* indeed modify the error state) and -should be removed (Interestingly fstream itself never had these, -although -they where needed for that time). -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -In 27.8.1.9 [ifstream.members], remove footnote: -</p> - -<blockquote><p> -<del><sup>334)</sup> A successful open does not change the error state.</del> -</p></blockquote> - -<p> -In 27.8.1.13 [ofstream.members], remove footnote: -</p> - -<blockquote><p> -<del><sup>335)</sup> A successful open does not change the error state.</del> -</p></blockquote> - - - - - - -<hr> -<h3><a name="645"></a>645. Missing members in match_results</h3> -<p><b>Section:</b> 28.10 [re.results] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -28.11.3 [re.alg.search]/5 declares -</p> - -<blockquote><pre>template <class iterator, class charT, class traits> -bool regex_search(iterator first, iterator last, - const basic_regex<charT, traits>& e, - regex_constants::match_flag_type flags = - regex_constants::match_default); -</pre></blockquote> - -<p> -where it's not explained, which iterator category -the parameter iterator belongs to. This is inconsistent -to the preceding declaration in the synopsis section -28.4 [re.syn], which says: -</p> - -<blockquote><pre>template <class BidirectionalIterator, class charT, class traits> -bool regex_search(BidirectionalIterator first, BidirectionalIterator last, - const basic_regex<charT, traits>& e, - regex_constants::match_flag_type flags = - regex_constants::match_default); -</pre></blockquote> - - -<p><b>Proposed resolution:</b></p> -<p> -In 28.11.3 [re.alg.search]/5 replace all three occurences of param "iterator" with -"BidirectionalIterator" -</p> - -<blockquote><pre>template <class <del>iterator</del> <ins>BidirectionalIterator</ins>, class charT, class traits> - bool regex_search(<del>iterator</del> <ins>BidirectionalIterator</ins> first, <del>iterator</del> <ins>BidirectionalIterator</ins> last, - const basic_regex<charT, traits>& e, - regex_constants::match_flag_type flags = - regex_constants::match_default); -</pre> -<p> --6- <i>Effects:</i> Behaves "as if" by constructing an object what of -type <tt>match_results<<del>iterator</del> -<ins>BidirectionalIterator</ins>></tt> and then returning the result -of <tt>regex_search(first, last, what, e, flags)</tt>. -</p> -</blockquote> - - -<p><b>Rationale:</b></p> -Applied to working paper while issue was still in New status. - - - - - -<hr> -<h3><a name="648"></a>648. regex_iterator c'tor needs clarification/editorial fix</h3> -<p><b>Section:</b> 28.12.1.1 [re.regiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> - <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-03</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -In 28.12.1.1 [re.regiter.cnstr]/2 the effects paragraph starts with: -</p> - -<blockquote> -<p> -<i>Effects:</i> Initializes begin and end to point to the beginning and the -end of the target sequence, sets pregex to &re, sets flags to f,[..] -</p></blockquote> - -<p> -There are two issues with this description: -</p> - -<ol> -<li> -The meaning of very first part of this quote is unclear, because -there is no target sequence provided, instead there are given two -parameters a and b, both of type BidirectionalIterator. The mentioned -part does not explain what a and b represent. -</li> -<li> -There does not exist any parameter f, but instead a parameter -m in the constructor declaration, so this is actually an editorial -fix. -</li> -</ol> - - -<p><b>Proposed resolution:</b></p> -<p> -In 28.12.1.1 [re.regiter.cnstr]/2 change the above quoted part by -</p> - -<blockquote><p> -<i>Effects:</i> Initializes <tt>begin</tt> and <tt>end</tt> to point to -the beginning and the end of the target sequence <ins>designated by the -iterator range <tt>[a, b)</tt></ins>, sets <tt>pregex</tt> to -<tt>&re</tt>, sets <tt>flags</tt> to <tt><del>f</del> -<ins>m</ins></tt>, then calls <tt>regex_search(begin, end, match, -*pregex, flags)</tt>. If this call returns <tt>false</tt> the -constructor sets <tt>*this</tt> to the end-of-sequence iterator. -</p></blockquote> - - - - - -<hr> -<h3><a name="649"></a>649. Several typos in regex_token_iterator constructors</h3> -<p><b>Section:</b> 28.12.2.1 [re.tokiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> - <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-03</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.tokiter.cnstr">issues</a> in [re.tokiter.cnstr].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -In 28.12.2.1 [re.tokiter.cnstr]/1+2 both the constructor declaration -and the following text shows some obvious typos: -</p> -<p> -1) The third constructor form is written as -</p> -<blockquote><pre>template <std::size_t N> - regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b, - const regex_type& re, - const int (&submatches)[R], - regex_constants::match_flag_type m = - regex_constants::match_default); -</pre></blockquote> - -<p> -where the dimensions of submatches are specified by an -unknown value R, which should be N. -</p> -<p> -2) Paragraph 2 of the same section says in its last sentence: -</p> - -<blockquote><p> -The third constructor initializes the member <tt>subs</tt> to hold a -copy of the sequence of integer values pointed to by the iterator range -<tt>[&submatches, &submatches + R)</tt>. -</p></blockquote> - -<p> -where again R must be replaced by N. -</p> - -<p> -3) Paragraph 3 of the same section says in its first sentence: -</p> - -<blockquote><p> -Each constructor then sets <tt>N</tt> to <tt>0</tt>, and -<tt>position</tt> to <tt>position_iterator(a, b, re, f)</tt>. -</p></blockquote> - -<p> -where a non-existing parameter "f" is mentioned, which must be -replaced -by the parameter "m". -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Change 28.12.2.1 [re.tokiter.cnstr]/1: -</p> -<blockquote><pre>template <std::size_t N> - regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b, - const regex_type& re, - const int (&submatches)[<del>R</del> <ins>N</ins>], - regex_constants::match_flag_type m = - regex_constants::match_default); -</pre></blockquote> - -<p> -Change 28.12.2.1 [re.tokiter.cnstr]/2: -</p> - -<blockquote><p> -<i>Effects:</i> The first constructor initializes the member -<tt>subs</tt> to hold the single value <tt>submatch</tt>. The second -constructor initializes the member <tt>subs</tt> to hold a copy of the -argument <tt>submatches</tt>. The third constructor initializes the -member <tt>subs</tt> to hold a copy of the sequence of integer values -pointed to by the iterator range <tt>[&submatches, &submatches + -<del>R</del> <ins>N</ins>)</tt>. -</p></blockquote> - -<p> -Change 28.12.2.1 [re.tokiter.cnstr]/3: -</p> - -<blockquote><p> -Each constructor then sets <tt>N</tt> to <tt>0</tt>, and -<tt>position</tt> to <tt>position_iterator(a, b, re, <del>f</del> -<ins>m</ins>)</tt>. If <tt>position</tt> is not an end-of-sequence -iterator the constructor sets <tt>result</tt> to the address of the -current match. Otherwise if any of the values stored in <tt>subs</tt> is -equal to <tt>-1</tt> the constructor sets <tt>*this</tt> to a suffix -iterator that points to the range <tt>[a, b)</tt>, otherwise the -constructor sets <tt>*this</tt> to an end-of-sequence iterator. -</p></blockquote> - - - - - - -<hr> -<h3><a name="653"></a>653. Library reserved names</h3> -<p><b>Section:</b> 1.2 [intro.refs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.synopsis">issues</a> in [rand.synopsis].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -26.4.2 [rand.synopsis] the header <tt><random></tt> synopsis -contains an unreasonable closing curly brace inside the -<tt>subtract_with_carry_engine</tt> declaration. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Change the current declaration in 26.4.2 [rand.synopsis] -</p> - -<blockquote><pre>template <class UIntType, size_t w<del>}</del>, size_t s, size_t r> -class subtract_with_carry_engine; -</pre></blockquote> - - -<p><i>[ -Pete: Recommends editorial. -]</i></p> - - - - - -<hr> -<h3><a name="657"></a>657. unclear requirement about header inclusion</h3> -<p><b>Section:</b> 17.4.2.1 [using.headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Gennaro Prota <b>Date:</b> 2007-03-14</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -17.4.2.1 [using.headers] states: -</p> - -<blockquote><p> -A translation unit shall include a header only outside of any -external declaration or definition, [...] -</p></blockquote> - -<p> -I see three problems with this requirement: -</p> - -<ol type="a"> -<li><p>The C++ standard doesn't define what an "external declaration" or -an "external definition" are (incidentally the C99 standard does, and -has a sentence very similar to the above regarding header inclusion). -</p><p> -I think the intent is that the #include directive shall lexically -appear outside *any* declaration; instead, when the issue was pointed -out on comp.std.c++ at least one poster interpreted "external -declaration" as "declaration of an identifier with external linkage". -If this were the correct interpretation, then the two inclusions below -would be legal: -</p> -<blockquote><pre> // at global scope - static void f() - { -# include <cstddef> - } - - static void g() - { -# include <stddef.h> - } -</pre></blockquote> -<p> -(note that while the first example is unlikely to compile correctly, -the second one may well do) -</p></li> - -<li><p>as the sentence stands, violations will require a diagnostic; is -this the intent? It was pointed out on comp.std.c++ (by several -posters) that at least one way to ensure a diagnostic exists: -</p> -<blockquote><p> - [If there is an actual file for each header,] one simple way - to implement this would be to insert a reserved identifier - such as __begin_header at the start of each standard header. - This reserved identifier would be ignored for all other - purposes, except that, at the appropriate point in phase 7, if - it is found inside an external definition, a diagnostic is - generated. There's many other similar ways to achieve the same - effect. - </p> -<p> --James Kuyper, on comp.std.c++ -</p></blockquote></li> - -<li><p>is the term "header" meant to be limited to standard headers? -Clause 17 is all about the library, but still the general question is -interesting and affects one of the points in the explicit namespaces -proposal (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1691.html">n1691</a>): -</p> -<blockquote><p> - Those seeking to conveniently enable argument-dependent - lookups for all operators within an explicit namespace - could easily create a header file that does so: -</p><pre> namespace mymath:: - { - #include "using_ops.hpp" - } -</pre></blockquote> -</li> -</ol> - - -<p><b>Proposed resolution:</b></p> -<p> -</p> - - -<p><b>Rationale:</b></p> -We believe that the existing language does not cause any real confusion -and any new formulation of the rules that we could come up with are -unlikely to be better than what's already in the standard. - - - - - -<hr> -<h3><a name="658"></a>658. Two unspecified function comparators in [function.objects]</h3> -<p><b>Section:</b> 20.6 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> - <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-03-19</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -The header <tt><functional></tt> synopsis in 20.6 [function.objects] -contains the following two free comparison operator templates -for the <tt>function</tt> class template -</p> - -<blockquote><pre>template<class Function1, class Function2> -void operator==(const function<Function1>&, const function<Function2>&); -template<class Function1, class Function2> -void operator!=(const function<Function1>&, const function<Function2>&); -</pre></blockquote> - -<p> -which are nowhere described. I assume that they are relicts before the -corresponding two private and undefined member templates in the function -template (see 20.6.15.2 [func.wrap.func] and X [func.wrap.func.undef]) have been introduced. The original free -function templates should be removed, because using an undefined entity -would lead to an ODR violation of the user. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Remove the above mentioned two function templates from -the header <tt><functional></tt> synopsis (20.6 [function.objects]) -</p> - -<blockquote><pre><del>template<class Function1, class Function2> -void operator==(const function<Function1>&, const function<Function2>&); -template<class Function1, class Function2> -void operator!=(const function<Function1>&, const function<Function2>&);</del> -</pre></blockquote> - - - -<p><b>Rationale:</b></p> -Fixed by -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2292.html">N2292</a> -Standard Library Applications for Deleted Functions. - - - - - -<hr> -<h3><a name="662"></a>662. Inconsistent handling of incorrectly-placed thousands separators</h3> -<p><b>Section:</b> 22.2.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Cosmin Truta <b>Date:</b> 2007-04-05</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -From Section 22.2.2.1.2 [facet.num.get.virtuals], paragraphs 11 and 12, it is implied -that the value read from a stream must be stored -even if the placement of thousands separators does not conform to the -<code>grouping()</code> specification from the <code>numpunct</code> facet. -Since incorrectly-placed thousands separators are flagged as an extraction -failure (by the means of <code>failbit</code>), we believe it is better not -to store the value. A consistent strategy, in which any kind of extraction -failure leaves the input item intact, is conceptually cleaner, is able to avoid -corner-case traps, and is also more understandable from the programmer's point -of view. -</p> -<p> -Here is a quote from <i>"The C++ Programming Language (Special Edition)"</i> -by B. Stroustrup (Section D.4.2.3, pg. 897): -</p> -<blockquote><p> -<i>"If a value of the desired type could not be read, failbit is set in r. -[...] An input operator will use r to determine how to set the state of its -stream. If no error was encountered, the value read is assigned through v; -otherwise, v is left unchanged."</i> -</p></blockquote> -<p> -This statement implies that <code>rdstate()</code> alone is sufficient to -determine whether an extracted value is to be assigned to the input item -<i>val</i> passed to <code>do_get</code>. However, this is in disagreement -with the current C++ Standard. The above-mentioned assumption is true in all -cases, except when there are mismatches in digit grouping. In the latter case, -the parsed value is assigned to <i>val</i>, and, at the same time, <i>err</i> -is assigned to <code>ios_base::failbit</code> (essentially "lying" about the -success of the operation). Is this intentional? The current behavior raises -both consistency and usability concerns. -</p> -<p> -Although digit grouping is outside the scope of <code>scanf</code> (on which -the virtual methods of <code>num_get</code> are based), handling of grouping -should be consistent with the overall behavior of scanf. The specification of -<code>scanf</code> makes a distinction between input failures and matching -failures, and yet both kinds of failures have no effect on the input items -passed to <code>scanf</code>. A mismatch in digit grouping logically falls in -the category of matching failures, and it would be more consistent, and less -surprising to the user, to leave the input item intact whenever a failure is -being signaled. -</p> -<p> -The extraction of <code>bool</code> is another example outside the scope of -<code>scanf</code>, and yet consistent, even in the event of a successful -extraction of a <code>long</code> but a failed conversion from -<code>long</code> to <code>bool</code>. -</p> -<p> -Inconsistency is further aggravated by the fact that, when failbit is set, -subsequent extraction operations are no-ops until <code>failbit</code> is -explicitly cleared. Assuming that there is no explicit handling of -<code>rdstate()</code> (as in <code>cin>>i>>j</code>) it is -counter-intuitive to be able to extract an integer with mismatched digit -grouping, but to be unable to extract another, properly-formatted integer -that immediately follows. -</p> -<p> -Moreover, setting <code>failbit</code>, and selectively assigning a value to -the input item, raises usability problems. Either the strategy of -<code>scanf</code> (when there is no extracted value in case of failure), or -the strategy of the <code>strtol</code> family (when there is always an -extracted value, and there are well-defined defaults in case of a failure) are -easy to understand and easy to use. On the other hand, if <code>failbit</code> -alone cannot consistently make a difference between a failed extraction, and a -successful but not-quite-correct extraction whose output happens to be the same -as the previous value, the programmer must resort to implementation tricks. -Consider the following example: -</p> -<pre> int i = old_i; - cin >> i; - if (cin.fail()) - // can the value of i be trusted? - // what does it mean if i == old_i? - // ... -</pre> -<p> -Last but not least, the current behvaior is not only confusing to the casual -reader, but it has also been confusing to some book authors. Besides -Stroustrup's book, other books (e.g. "Standard C++ IOStreams and Locales" by -Langer and Kreft) are describing the same mistaken assumption. Although books -are not to be used instead of the standard reference, the readers of these -books, as well as the people who are generally familiar to <code>scanf</code>, -are even more likely to misinterpret the standard, and expect the input items -to remain intact when a failure occurs. -</p> - - -<p><b>Proposed resolution:</b></p> - -<p> -Change 22.2.2.1.2 [facet.num.get.virtuals]: -</p> - -<blockquote> -<p> -<b>Stage 3:</b> The result of stage 2 processing can be one of -</p> -<ul> -<li>A sequence of <code>chars</code> has been accumulated in stage 2 that is converted (according to the rules of <code>scanf</code>) to a value of the type of <code><i>val</i></code>. <del>This value is stored in <code><i>val</i></code> and <code>ios_base::goodbit</code> is stored in <code><i>err</i></code>.</del></li> - -<li>The sequence of <code>chars</code> accumulated in stage 2 would have caused <code>scanf</code> to report an input failure. <code>ios_base::failbit</code> is assigned to <code><i>err</i></code>.</li> -</ul> -<p> -<ins>In the first case,</ins> <del>D</del><ins>d</ins>igit grouping is checked. That is, the positions of discarded separators is examined for consistency with <code>use_facet<numpunct<charT> >(<i>loc</i>).grouping()</code>. If they are not consistent then <code>ios_base::failbit</code> is assigned to <code><i>err</i></code>. <ins>Otherwise, the value that was converted in stage 2 is stored in <code><i>val</i></code> and <code>ios_base::goodbit</code> is stored in <code><i>err</i></code>.</ins> -</p> -</blockquote> - - -<p><b>Rationale:</b></p> -post-Toronto: Changed from New to NAD at the request of the author. The preferred solution of -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2327.pdf">N2327</a> -makes this resolution obsolete. - - - - - -<hr> -<h3><a name="663"></a>663. Complexity Requirements</h3> -<p><b>Section:</b> 17.3.1.3 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#structure.specifications">issues</a> in [structure.specifications].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -17.3.1.3 [structure.specifications] para 5 says -</p> - -<blockquote><p> --5- Complexity requirements specified in the library -clauses are upper bounds, and implementations that provide better -complexity guarantees satisfy the requirements. -</p></blockquote> - -<p> -The following -objection has been raised: -</p> - -<blockquote><p> -The library clauses suggest general -guidelines regarding complexity, but we have been unable to discover -any absolute hard-and-fast formulae for these requirements. Unless -or until the Library group standardizes specific hard-and-fast -formulae, we regard all the complexity requirements as subject to a -"fudge factor" without any intrinsic upper bound. -</p></blockquote> - -<p> -[Plum ref -_23213Y31 etc] -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -</p> - - -<p><b>Rationale:</b></p> -Kona (2007): No specific instances of underspecification have been -identified, and big-O notation always involves constant factors. - - - - - -<hr> -<h3><a name="683"></a>683. regex_token_iterator summary error</h3> -<p><b>Section:</b> 28.12.2 [re.tokiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a> - <b>Submitter:</b> Eric Niebler <b>Date:</b> 2007-06-02</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.tokiter">issues</a> in [re.tokiter].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -28.12.2 [re.tokiter], p3 says: -</p> -<blockquote> -<p> -After it is constructed, the iterator finds and stores a value -<tt>match_results<BidirectionalIterator></tt> position and sets the -internal count <tt>N</tt> to zero. -</p> -</blockquote> - -<p> -Should read: -</p> - -<blockquote> -<p> -After it is constructed, the iterator finds and stores a value -<tt><del>match_results</del><ins>regex_iterator</ins><BidirectionalIterator<ins>, charT, traits</ins>></tt> -position and sets the internal count <tt>N</tt> to zero. -</p> -</blockquote> - -<p><i>[ -John adds: -]</i></p> - - -<blockquote><p> -Yep, looks like a typo/administrative fix to me. -</p></blockquote> - - - -<p><b>Proposed resolution:</b></p> -<p> -</p> - - - - - -<hr> -<h3><a name="684"></a>684. Unclear which members of match_results should be used in comparison</h3> -<p><b>Section:</b> 28.10 [re.results] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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.7.11.2.4 [unique.ptr.single.observers], 20.7.12.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Beman Dawes <b>Date:</b> 2007-06-14</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -The standard library uses the <tt>operator <i>unspecified-bool-type</i>() const</tt> idiom in -five places. In three of those places (20.6.15.2.3 [func.wrap.func.cap], function capacity -for example) the returned value is constrained to disallow -unintended conversions to int. The standardese is -</p> -<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.7.11.2.4 [unique.ptr.single.observers] paragraph 11 and -20.7.12.2.5 [util.smartptr.shared.obs] paragraph 16, add the sentence: -</p> -<blockquote><p> -The return type shall not be convertible to <tt>int</tt>. -</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> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -Quoting the latest draft (n2135), 26.7 [c.math]: -</p> - -<blockquote> -<p> -The added signatures are: -</p> -<blockquote><pre>long abs(long); // labs() -long abs(long long); // llabs() -</pre></blockquote> -</blockquote> -<p> -Shouldn't <tt>abs(long long)</tt> have <tt>long long</tt> as return type? -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Change 26.7 [c.math]: -</p> -<blockquote><pre><ins>long </ins>long abs(long long); // llabs() -</pre></blockquote> - - -<p><b>Rationale:</b></p> -Had already been fixed in the WP by the time the LWG reviewed this. - - - - - -<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="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.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a> - <b>Submitter:</b> David Abrahams <b>Date:</b> 2007-09-16</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p> -<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 other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.discrete">active issues</a> in [rand.dist.samp.discrete].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.discrete">issues</a> in [rand.dist.samp.discrete].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<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.7.12.2.11 [util.smartptr.getdeleter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-09-27</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.getdeleter">issues</a> in [util.smartptr.getdeleter].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<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.7 [memory] and 20.7.12.2.11 [util.smartptr.getdeleter] declare: -</p> - -<blockquote><pre>template<class D, class T> D* get_deleter(shared_ptr<T> const& p); -</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.6.15.2 [func.wrap.func] or in 20.6.15.2.5 [func.wrap.func.targ] - do -properly mirror the const-state of the owner. -</p> - -<b>Possible proposed resolutions:</b> - -<p> -Replace the declarations of <tt>get_deleter</tt> in the header <tt><memory></tt> -synopsis of 20.7 [memory] and in 20.7.12.2.11 [util.smartptr.getdeleter] by one of the -following alternatives (A) or (B): -</p> - -<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.5.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p> -<p><b>View 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.7.10.1 [uninitialized.copy] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> - <b>Submitter:</b> Daniel Krügler <b>Date:</b> 2007-10-15</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#uninitialized.copy">issues</a> in [uninitialized.copy].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">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.7.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.7.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="756"></a>756. Container adaptors push</h3> -<p><b>Section:</b> 23.2.5 [container.adaptors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> - <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2007-10-31</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -After n2369 we have a single <tt>push_back</tt> overload in the sequence containers, -of the "emplace" type. At variance with that, still in n2461, we have -two separate overloads, the C++03 one + one taking an rvalue reference -in the container adaptors. Therefore, simply from a consistency point of -view, I was wondering whether the container adaptors should be aligned -with the specifications of the sequence container themselves: thus have -a single <tt>push</tt> along the lines: -</p> - -<blockquote><pre>template<typename... _Args> -void -push(_Args&&... __args) - { c.push_back(std::forward<_Args>(__args)...); } -</pre></blockquote> - -<p><i>[ -Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a> -]</i></p> - - - -<p><b>Proposed resolution:</b></p> -<p> -Change 23.2.5.1.1 [queue.defn]: -</p> - -<blockquote><pre><del>void push(const value_type& x) { c.push_back(x); }</del> -<del>void push(value_type&& x) { c.push_back(std::move(x)); }</del> -<ins>template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }</ins> -</pre></blockquote> - -<p> -Change 23.2.5.2 [priority.queue]: -</p> - -<blockquote><pre><del>void push(const value_type& x) { c.push_back(x); }</del> -<del>void push(value_type&& x) { c.push_back(std::move(x)); }</del> -<ins>template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }</ins> -</pre></blockquote> - -<p> -Change 23.2.5.2.2 [priqueue.members]: -</p> - -<blockquote> -<pre><del>void push(const value_type& x);</del> -</pre> -<blockquote> -<p> -<del><i>Effects:</i></del> -</p> -<blockquote><pre><del>c.push_back(x);</del> -<del>push_heap(c.begin(), c.end(), comp);</del> -</pre></blockquote> -</blockquote> - -<pre><ins>template<class... Args></ins> void push(<del>value_type</del> <ins>Args</ins>&&<ins>...</ins> <del>x</del> <ins>args</ins>); -</pre> -<blockquote> -<p> -<i>Effects:</i> -</p> -<blockquote><pre>c.push_back(std::<del>move</del><ins>forward<Args></ins>(<del>x</del> <ins>args</ins>)<ins>...</ins>); -push_heap(c.begin(), c.end(), comp); -</pre></blockquote> -</blockquote> -</blockquote> - -<p> -Change 23.2.5.3.1 [stack.defn]: -</p> - -<blockquote><pre><del>void push(const value_type& x) { c.push_back(x); }</del> -<del>void push(value_type&& x) { c.push_back(std::move(x)); }</del> -<ins>template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(args)...); }</ins> -</pre></blockquote> - - - -<p><b>Rationale:</b></p> -<p> -Addressed by -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2680.pdf">N2680 Proposed Wording for Placement Insert (Revision 1)</a>. -</p> - - - - - -<hr> -<h3><a name="757"></a>757. Typo in the synopsis of vector</h3> -<p><b>Section:</b> 23.2.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">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#NAD%20Editorial">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.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Sylvain Pion <b>Date:</b> 2007-12-04</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<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-closed.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.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-11-29</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<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.5 [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="767"></a>767. Forwarding and backward compatibility</h3> -<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> - <b>Submitter:</b> Sylvain Pion <b>Date:</b> 2007-12-28</p> -<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -Playing with g++'s C++0X mode, I noticed that the following -code, which used to compile: -</p> - -<blockquote><pre>#include <vector> - -int main() -{ - std::vector<char *> v; - v.push_back(0); -} -</pre></blockquote> - -<p> -now fails with the following error message: -</p> - -<blockquote>.../include/c++/4.3.0/ext/new_allocator.h: In member -function 'void __gnu_cxx::new_allocator<_Tp>::construct(_Tp*, -_Args&& ...) [with _Args = int, _Tp = char*]': -.../include/c++/4.3.0/bits/stl_vector.h:707: instantiated from 'void -std::vector<_Tp, _Alloc>::push_back(_Args&& ...) [with -_Args = int, _Tp = char*, _Alloc = std::allocator<char*>]' -test.cpp:6: instantiated from here -.../include/c++/4.3.0/ext/new_allocator.h:114: error: invalid -conversion from 'int' to 'char*' -</blockquote> - -<p> -As far as I know, g++ follows the current draft here. -</p> -<p> -Does the committee really intend to break compatibility for such cases? -</p> - -<p><i>[ -Sylvain adds: -]</i></p> - - -<blockquote> -<p> -I just noticed that <tt>std::pair</tt> has the same issue. -The following now fails with GCC's -std=c++0x mode: -</p> - -<blockquote><pre>#include <utility> - -int main() -{ - std::pair<char *, char *> p (0,0); -} -</pre></blockquote> - -<p> -I have not made any general audit for such problems elsewhere. -</p> -</blockquote> - -<p><i>[ -Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a> -]</i></p> - - -<p><i>[ -Bellevue: -]</i></p> - - -<blockquote> -<p> -Motivation is to handle the old-style int-zero-valued NULL pointers. -Problem: this solution requires concepts in some cases, which some users -will be slow to adopt. Some discussion of alternatives involving -prohibiting variadic forms and additional library-implementation -complexity. -</p> -<p> -Discussion of "perfect world" solutions, the only such solution put -forward being to retroactively prohibit use of the integer zero for a -NULL pointer. This approach was deemed unacceptable given the large -bodies of pre-existing code that do use integer zero for a NULL pointer. -</p> -<p> -Another approach is to change the member names. Yet another approach is -to forbid the extension in absence of concepts. -</p> -<p> -Resolution: These issues (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>) will be subsumed into a -paper to be produced by Alan Talbot in time for review at the 2008 -meeting in France. Once this paper is produced, these issues will be -moved to NAD. -</p> -</blockquote> - - - -<p><b>Proposed resolution:</b></p> -<p> -Add the following rows to Table 90 "Optional sequence container operations", 23.1.3 [sequence.reqmts]: -</p> - -<blockquote> -<table border="1"> -<tbody><tr> -<th>expression</th> <th>return type</th> <th>assertion/note<br>pre-/post-condition</th> <th>container</th> -</tr> - -<tr> -<td> -<tt>a.push_front(t)</tt> -</td> -<td> -<tt>void</tt> -</td> -<td> -<tt>a.insert(a.begin(), t)</tt><br> -<i>Requires:</i> <tt>T</tt> shall be <tt>CopyConstructible</tt>. -</td> -<td> -<tt>list, deque</tt> -</td> -</tr> - -<tr> -<td> -<tt>a.push_front(rv)</tt> -</td> -<td> -<tt>void</tt> -</td> -<td> -<tt>a.insert(a.begin(), rv)</tt><br> -<i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt>. -</td> -<td> -<tt>list, deque</tt> -</td> -</tr> - -<tr> -<td> -<tt>a.push_back(t)</tt> -</td> -<td> -<tt>void</tt> -</td> -<td> -<tt>a.insert(a.end(), t)</tt><br> -<i>Requires:</i> <tt>T</tt> shall be <tt>CopyConstructible</tt>. -</td> -<td> -<tt>list, deque, vector, basic_string</tt> -</td> -</tr> - -<tr> -<td> -<tt>a.push_back(rv)</tt> -</td> -<td> -<tt>void</tt> -</td> -<td> -<tt>a.insert(a.end(), rv)</tt><br> -<i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt>. -</td> -<td> -<tt>list, deque, vector, basic_string</tt> -</td> -</tr> - -</tbody></table> -</blockquote> - -<p> -Change the synopsis in 23.2.2 [deque]: -</p> - -<blockquote><pre><ins>void push_front(const T& x);</ins> -<ins>void push_front(T&& x);</ins> -<ins>void push_back(const T& x);</ins> -<ins>void push_back(T&& x);</ins> -template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args); -template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args); -</pre></blockquote> - -<p> -Change 23.2.2.3 [deque.modifiers]: -</p> - -<blockquote><pre><ins>void push_front(const T& x);</ins> -<ins>void push_front(T&& x);</ins> -<ins>void push_back(const T& x);</ins> -<ins>void push_back(T&& x);</ins> -template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args); -template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args); -</pre></blockquote> - -<p> -Change the synopsis in 23.2.4 [list]: -</p> - -<blockquote><pre><ins>void push_front(const T& x);</ins> -<ins>void push_front(T&& x);</ins> -<ins>void push_back(const T& x);</ins> -<ins>void push_back(T&& x);</ins> -template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args); -template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args); -</pre></blockquote> - -<p> -Change 23.2.4.3 [list.modifiers]: -</p> - -<blockquote><pre><ins>void push_front(const T& x);</ins> -<ins>void push_front(T&& x);</ins> -<ins>void push_back(const T& x);</ins> -<ins>void push_back(T&& x);</ins> -template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args); -template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args); -</pre></blockquote> - -<p> -Change the synopsis in 23.2.6 [vector]: -</p> - -<blockquote><pre><ins>void push_back(const T& x);</ins> -<ins>void push_back(T&& x);</ins> -template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args); -</pre></blockquote> - -<p> -Change 23.2.6.4 [vector.modifiers]: -</p> - -<blockquote><pre><ins>void push_back(const T& x);</ins> -<ins>void push_back(T&& x);</ins> -template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... args); -</pre></blockquote> - - - - -<p><b>Rationale:</b></p> -<p> -Addressed by -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2680.pdf">N2680 Proposed Wording for Placement Insert (Revision 1)</a>. -</p> - -<p> -If there is still an issue with pair, Howard should submit another issue. -</p> - - - - - -<hr> -<h3><a name="773"></a>773. issues with random</h3> -<p><b>Section:</b> 26.4.8.1 [rand.dist.uni] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-01-14</p> -<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="786"></a>786. Thread library timed waits, UTC and monotonic clocks</h3> -<p><b>Section:</b> X [datetime.system] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> - <b>Submitter:</b> Christopher Kohlhoff, Jeff Garland <b>Date:</b> 2008-02-03</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> -The draft C++0x thread library requires that the time points of type -<tt>system_time</tt> and returned by <tt>get_system_time()</tt> represent Coordinated -Universal Time (UTC) (section X [datetime.system]). This can lead to -surprising behavior when a library user performs a duration-based wait, -such as <tt>condition_variable::timed_wait()</tt>. A complete explanation of the -problem may be found in the -<a href="http://www.opengroup.org/onlinepubs/009695399/xrat/xsh_chap02.html#tag_03_02_08_19">Rationale for the Monotonic Clock</a> -section in POSIX, but in summary: -</p> - -<ul> -<li> -Operations such as <tt>condition_variable::timed_wait()</tt> (and its POSIX -equivalent, <tt>pthread_cond_timedwait()</tt>) are specified using absolute times -to address the problem of spurious wakeups. -</li> - -<li> -The typical use of the timed wait operations is to perform a relative -wait. This may be achieved by first calculating an absolute time as the -sum of the current time and the desired duration. In fact, the C++0x -thread library includes duration-based overloads of -<tt>condition_variable::timed_wait()</tt> that behave as if by calling the -corresponding absolute time overload with a time point value of -<tt>get_system_time() + rel_time</tt>. -</li> - -<li> -A UTC clock may be affected by changes to the system time, such as -synchronization with an external source, leap seconds, or manual changes -to the clock. -</li> - -<li> -Should the clock change during a timed wait operation, the actual -duration of the wait will not be the expected length. For example, a -user may intend a timed wait of one second duration but, due to an -adjustment of the system clock backwards by a minute, the wait instead -takes 61 seconds. -</li> -</ul> - -<p> -POSIX solves the problem by introducing a new monotonic clock, which is -unaffected by changes to the system time. When a condition variable is -initialized, the user may specify whether the monotonic clock is to be -used. (It is worth noting that on POSIX systems it is not possible to -use <tt>condition_variable::native_handle()</tt> to access this facility, since -the desired clock type must be specified during construction of the -condition variable object.) -</p> - -<p> -In the context of the C++0x thread library, there are added dimensions -to the problem due to the need to support platforms other than POSIX: -</p> - -<ul> -<li> -Some environments (such as embedded systems) do not have a UTC clock, but do have a monotonic clock. -</li> - -<li> -Some environments do not have a monotonic clock, but do have a UTC clock. -</li> - -<li> -The Microsoft Windows API's synchronization functions use relative -timeouts based on an implied monotonic clock. A program that switches -from the Windows API to the C++0x thread library will now find itself -susceptible to clock changes. -</li> -</ul> - -<p> -One possible minimal solution: -</p> - -<ul> -<li> -Strike normative references to UTC and an epoch based on 1970-01-01. -</li> - -<li> -Make the semantics of <tt>system_time</tt> and <tt>get_system_time()</tt> -implementation-defined (i.e standard library implementors may choose the -appropriate underlying clock based on the capabilities of the target -platform). -</li> - -<li> -Add a non-normative note encouraging use of a monotonic clock. -</li> - -<li> -Remove <tt>system_time::seconds_since_epoch()</tt>. -</li> - -<li> -Change the constructor <tt>explicit system_time(time_t secs, nanoseconds ns -= 0)</tt> to <tt>explicit system_time(nanoseconds ns)</tt>. -</li> -</ul> - - - -<p><b>Proposed resolution:</b></p> -<p> -</p> - - -<p><b>Rationale:</b></p> -Addressed by -<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.html">N2661: A Foundation to Sleep On</a>. - - - - - -<hr> -<h3><a name="790"></a>790. <tt>xor_combine::seed</tt> not specified</h3> -<p><b>Section:</b> 26.4.4.4 [rand.adapt.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p> -<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-defects.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> - - - - - -<hr> -<h3><a name="826"></a>826. Equivalent of <tt>%'d</tt>, or rather, lack thereof?</h3> -<p><b>Section:</b> 22.2.2.2 [locale.nm.put] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-04-07</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -In the spirit of <tt>printf vs iostream</tt>... -</p> - -<p> -POSIX <tt>printf</tt> says that <tt>%'d</tt> should insert grouping characters (and the -implication is that in the absence of <tt>'</tt> no grouping characters are -inserted). The <tt>num_put</tt> facet, on the other hand, seems to always insert -grouping characters. Can this be considered a defect worth fixing for -C++0x? Maybe <tt>ios_base</tt> needs an additional flag? -</p> - -<p><i>[ -Pablo Halpern: -]</i></p> - - -<blockquote> -I'm not sure it constitutes a defect, but I would be in favor of adding -another flag (and corresponding manipulator). -</blockquote> - -<p><i>[ -Martin Sebor: -]</i></p> - - -<blockquote> -I don't know if it qualifies as a defect but I agree that there -should be an easy way to control whether the thousands separator -should or shouldn't be inserted. A new flag would be in line with -the current design of iostreams (like <tt>boolalpha</tt>, <tt>showpos</tt>, or -<tt>showbase</tt>). -</blockquote> - -<p><i>[ -Sophia Antipolis: -]</i></p> - - -<blockquote> -This is not a part of C99. LWG suggests submitting a paper may be appropriate. -</blockquote> - - - -<p><b>Proposed resolution:</b></p> -<p> -</p> - - - - - -<hr> -<h3><a name="831"></a>831. wrong type for not_eof()</h3> -<p><b>Section:</b> 21.1.3 [char.traits.specializations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a> - <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 2008-04-23</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits.specializations">issues</a> in [char.traits.specializations].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p> -<p><b>Discussion:</b></p> -<p> - In Table 56 (Traits requirements) the <tt>not_eof()</tt> member function - is using an argument of type <i>e</i> which denotes an object of - type <code>X::int_type</code>. However, the specializations in - 21.1.3 [char.traits.specializations] all use <code>char_type</code>. - This would effectively mean that the argument type actually can't - represent EOF in the first place. I'm pretty sure that the type used - to be <code>int_type</code> which is quite obviously the only sensible - argument. -</p> -<p> - This issue is close to being editorial. I suspect that the proposal - changing this section to include the specializations for <code>char16_t</code> - and <code>char32_t</code> accidentally used the wrong type. -</p> - - -<p><b>Proposed resolution:</b></p> -<p> - In 21.1.3.1 [char.traits.specializations.char], - 21.1.3.2 [char.traits.specializations.char16_t], - 21.1.3.3 [char.traits.specializations.char32_t], and - [char.traits.specializations.wchar_t] correct the - argument type from <code>char_type</code> to <code>int_type</code>. -</p> - - -<p><b>Rationale:</b></p> -Already fixed in WP. - - - - - -<hr> -<h3><a name="840"></a>840. <tt>pair</tt> default template argument</h3> -<p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> - <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2008-05-23</p> -<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p> -<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p> -<p><b>Discussion:</b></p> -<p> -I have one issue with <tt>std::pair</tt>. Well, it might just be a very annoying -historical accident, but why is there no default template argument for -the second template argument? This is so annoying when the type in -question is looong and hard to write (type deduction with <tt>auto</tt> won't -help those cases where we use it as a return or argument type). -</p> - - -<p><b>Proposed resolution:</b></p> -<p> -Change the synopsis in 20.2 [utility] to read: -</p> - -<blockquote><pre>template <class T1, class T2 <ins>= T1</ins>> struct pair; -</pre></blockquote> - -<p> -Change 20.2.3 [pairs] to read: -</p> - -<blockquote><pre>namespace std { - template <class T1, class T2 <ins>= T1</ins>> - struct pair { - typedef T1 first_type; - typedef T2 second_type; - ... -</pre></blockquote> - - -<p><b>Rationale:</b></p> -<tt>std::pair</tt> is a heterogeneous container. - - - - - -</body></html>
\ No newline at end of file |