libstdc++-v3/doc/html/ext/lwg-active.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
   2 <html><head>
   3 <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
   4
   5
   6 <title>C++ Standard Library Active Issues List</title>
   7 <style type="text/css">
   8 p {text-align:justify}
   9 li {text-align:justify}
  10 ins {background-color:#A0FFA0}
  11 del {background-color:#FFA0A0}
  12 </style>
  13 </head><body>
  14 <table>
  15 <tbody><tr>
  16 <td align="left">Doc. no.</td>
  17 <td align="left">N2940=09-0130</td>
  18 </tr>
  19 <tr>
  20 <td align="left">Date:</td>
  21 <td align="left">2009-08-02</td>
  22 </tr>
  23 <tr>
  24 <td align="left">Project:</td>
  25 <td align="left">Programming Language C++</td>
  26 </tr>
  27 <tr>
  28 <td align="left">Reply to:</td>
  29 <td align="left">Howard Hinnant &lt;<a href="mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>&gt;</td>
  30 </tr>
  31 </tbody></table>
  32 <h1>C++ Standard Library Active Issues List (Revision R66)</h1>
  33
  34   <p>Reference ISO/IEC IS 14882:2003(E)</p>
  35   <p>Also see:</p>
  36   <ul>
  37       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html">Table of Contents</a> for all library issues.</li>
  38       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html">Index by Section</a> for all library issues.</li>
  39       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html">Index by Status</a> for all library issues.</li>
  40       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a></li>
  41       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a></li>
  42   </ul>
  43   <p>The purpose of this document is to record the status of issues
  44   which have come before the Library Working Group (LWG) of the ANSI
  45   (J16) and ISO (WG21) C++ Standards Committee. Issues represent
  46   potential defects in the ISO/IEC IS 14882:2003(E) document.
  47   </p>
  48
  49   <p>This document contains only library issues which are actively being
  50   considered by the Library Working Group, i.e., issues which have a
  51   status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>,
  52   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>, or <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>. See
  53   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a> for issues considered defects and
  54   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a> for issues considered closed.</p>
  55
  56   <p>The issues in these lists are not necessarily formal ISO Defect
  57   Reports (DR's). While some issues will eventually be elevated to
  58   official Defect Report status, other issues will be disposed of in
  59   other ways. See <a href="#Status">Issue Status</a>.</p>
  60
  61   <p>Prior to Revision 14, library issues lists existed in two slightly
  62   different versions; a Committee Version and a Public
  63   Version. Beginning with Revision 14 the two versions were combined
  64   into a single version.</p>
  65
  66   <p>This document includes <i>[bracketed italicized notes]</i> as a
  67   reminder to the LWG of current progress on issues. Such notes are
  68   strictly unofficial and should be read with caution as they may be
  69   incomplete or incorrect. Be aware that LWG support for a particular
  70   resolution can quickly change if new viewpoints or killer examples are
  71   presented in subsequent discussions.</p>
  72
  73   <p>For the most current official version of this document see
  74   <a href="http://www.open-std.org/jtc1/sc22/wg21/">http://www.open-std.org/jtc1/sc22/wg21/</a>.
  75   Requests for further information about this document should include
  76   the document number above, reference ISO/IEC 14882:2003(E), and be
  77   submitted to Information Technology Industry Council (ITI), 1250 Eye
  78   Street NW, Washington, DC 20005.</p>
  79
  80   <p>Public information as to how to obtain a copy of the C++ Standard,
  81   join the standards committee, submit an issue, or comment on an issue
  82   can be found in the comp.std.c++ FAQ.
  83   </p>
  84
  85
  86 <h2>Revision History</h2>
  87 <ul>
  88 <li>R66:
  89 2009-07-31 post-Frankfurt mailing.
  90 <ul>
  91 <li><b>Summary:</b><ul>
  92 <li>250 open issues, down by 128.</li>
  93 <li>936 closed issues, up by 171.</li>
  94 <li>1186 issues total, up by 43.</li>
  95 </ul></li>
  96 <li><b>Details:</b><ul>
  97 <li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1164">1164</a>.</li>
  98 <li>Added the following NAD Concepts issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1149">1149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1167">1167</a>.</li>
  99 <li>Added the following NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1168">1168</a>.</li>
 100 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1144">1144</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1145">1145</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1146">1146</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1147">1147</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1148">1148</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1150">1150</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1151">1151</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1152">1152</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1153">1153</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1154">1154</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1155">1155</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1156">1156</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1158">1158</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1159">1159</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1166">1166</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1169">1169</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1170">1170</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1171">1171</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1172">1172</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1173">1173</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1174">1174</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1175">1175</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1176">1176</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1177">1177</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1179">1179</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1180">1180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1181">1181</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1182">1182</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1183">1183</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1184">1184</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1185">1185</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1186">1186</a>.</li>
 101 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1160">1160</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1161">1161</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1162">1162</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1163">1163</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1165">1165</a>.</li>
 102 <li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1178">1178</a>.</li>
 103 <li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1157">1157</a>.</li>
 104 <li>Changed the following issues from Open to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#895">895</a>.</li>
 105 <li>Changed the following issues from Open to NAD: <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#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#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#290">290</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#309">309</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#342">342</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#343">343</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#382">382</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#394">394</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#398">398</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#417">417</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#418">418</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#421">421</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#459">459</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#492">492</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#582">582</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#606">606</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#614">614</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#941">941</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#992">992</a>.</li>
 106 <li>Changed the following issues from Review to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1003">1003</a>.</li>
 107 <li>Changed the following issues from Tentatively NAD to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#568">568</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#901">901</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#903">903</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#946">946</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#988">988</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#995">995</a>.</li>
 108 <li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1002">1002</a>.</li>
 109 <li>Changed the following issues from New to NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1124">1124</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1127">1127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1128">1128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1139">1139</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1140">1140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1141">1141</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1142">1142</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1143">1143</a>.</li>
 110 <li>Changed the following issues from Open to NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#902">902</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#989">989</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1000">1000</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1007">1007</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1010">1010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1015">1015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1016">1016</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1017">1017</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1018">1018</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1026">1026</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1027">1027</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1028">1028</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1029">1029</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1032">1032</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1036">1036</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1057">1057</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1059">1059</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1072">1072</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1078">1078</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1081">1081</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1082">1082</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1083">1083</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1084">1084</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1085">1085</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1086">1086</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1092">1092</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1096">1096</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1105">1105</a>.</li>
 111 <li>Changed the following issues from Review to NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1001">1001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1005">1005</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1080">1080</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1087">1087</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1111">1111</a>.</li>
 112 <li>Changed the following issues from Tentatively NAD to NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#912">912</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#918">918</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1074">1074</a>.</li>
 113 <li>Changed the following issues from Tentatively NAD Editorial to NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#927">927</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1109">1109</a>.</li>
 114 <li>Changed the following issues from Tentatively Ready to NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#906">906</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#913">913</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#914">914</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#928">928</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1024">1024</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1063">1063</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1067">1067</a>.</li>
 115 <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#873">873</a>.</li>
 116 <li>Changed the following issues from Tentatively NAD Editorial to 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#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#884">884</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#945">945</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#952">952</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#969">969</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#972">972</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#973">973</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#979">979</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1023">1023</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1058">1058</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1060">1060</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1061">1061</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1077">1077</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1101">1101</a>.</li>
 117 <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#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1107">1107</a>.</li>
 118 <li>Changed the following issues from Open to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#255">255</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#423">423</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#523">523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#708">708</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#839">839</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#877">877</a>.</li>
 119 <li>Changed the following issues from CD1 to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>.</li>
 120 <li>Changed the following issues from NAD Editorial to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#484">484</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#594">594</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#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</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#811">811</a>, <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#872">872</a>.</li>
 121 <li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1009">1009</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1093">1093</a>.</li>
 122 <li>Changed the following issues from Tentatively NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#458">458</a>.</li>
 123 <li>Changed the following issues from Tentatively NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#96">96</a>.</li>
 124 <li>Changed the following issues from Tentatively Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1011">1011</a>.</li>
 125 <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#419">419</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#430">430</a>, <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#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#630">630</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#696">696</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-active.html#716">716</a>, <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#788">788</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#838">838</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#857">857</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#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#881">881</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#883">883</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#886">886</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1004">1004</a>.</li>
 126 <li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>.</li>
 127 <li>Changed the following issues from Tentatively NAD to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>.</li>
 128 <li>Changed the following issues from Tentatively Ready to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#934">934</a>.</li>
 129 <li>Changed the following issues from NAD to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#871">871</a>.</li>
 130 <li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#397">397</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#408">408</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#473">473</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</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#889">889</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#968">968</a>.</li>
 131 <li>Changed the following issues from Tentatively NAD to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>.</li>
 132 <li>Changed the following issues from Tentatively Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1100">1100</a>.</li>
 133 <li>Changed the following issues from Open to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#971">971</a>.</li>
 134 <li>Changed the following issues from Open to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1031">1031</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1062">1062</a>.</li>
 135 <li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1019">1019</a>.</li>
 136 <li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#878">878</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#888">888</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#890">890</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#904">904</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#922">922</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#925">925</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#931">931</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#938">938</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#948">948</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#949">949</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#982">982</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#984">984</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#998">998</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1006">1006</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1066">1066</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1070">1070</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1073">1073</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1103">1103</a>.</li>
 137 </ul></li>
 138 </ul>
 139 </li>
 140 <li>R65:
 141 2009-06-19 pre-Frankfurt mailing.
 142 <ul>
 143 <li><b>Summary:</b><ul>
 144 <li>378 open issues, up by 32.</li>
 145 <li>765 closed issues, up by 0.</li>
 146 <li>1143 issues total, up by 32.</li>
 147 </ul></li>
 148 <li><b>Details:</b><ul>
 149 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1115">1115</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1116">1116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1117">1117</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1118">1118</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1119">1119</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1120">1120</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1121">1121</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1122">1122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1123">1123</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1124">1124</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1125">1125</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1126">1126</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1127">1127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1128">1128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1129">1129</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1130">1130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1131">1131</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1132">1132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1133">1133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1134">1134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1135">1135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1136">1136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1137">1137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1138">1138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1139">1139</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1140">1140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1141">1141</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1142">1142</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1143">1143</a>.</li>
 150 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1112">1112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1113">1113</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1114">1114</a>.</li>
 151 <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#937">937</a>.</li>
 152 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</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#900">900</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#911">911</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#920">920</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#941">941</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#951">951</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#953">953</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#955">955</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#956">956</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#977">977</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#985">985</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#989">989</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#996">996</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1033">1033</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1056">1056</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1057">1057</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1059">1059</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1062">1062</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1068">1068</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1069">1069</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1071">1071</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1072">1072</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1076">1076</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1090">1090</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1092">1092</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1096">1096</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1098">1098</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1099">1099</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1105">1105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1106">1106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1108">1108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1110">1110</a>.</li>
 153 <li>Changed the following issues from Review to Open: <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#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#992">992</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1010">1010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1015">1015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1019">1019</a>.</li>
 154 <li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#957">957</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1001">1001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1080">1080</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1093">1093</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1094">1094</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1095">1095</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1097">1097</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1102">1102</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1104">1104</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1111">1111</a>.</li>
 155 <li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1087">1087</a>.</li>
 156 <li>Changed the following issues from New to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#568">568</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#903">903</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#912">912</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#918">918</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#946">946</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#995">995</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1074">1074</a>.</li>
 157 <li>Changed the following issues from Open to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#458">458</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#669">669</a>.</li>
 158 <li>Changed the following issues from Review to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#901">901</a>.</li>
 159 <li>Changed the following issues from Tentatively Ready to Tentatively NAD: <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-closed.html#988">988</a>.</li>
 160 <li>Changed the following issues from New to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#927">927</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#945">945</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#952">952</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#969">969</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#972">972</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#973">973</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#979">979</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1058">1058</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1060">1060</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1061">1061</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1077">1077</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1101">1101</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1109">1109</a>.</li>
 161 <li>Changed the following issues from Open to Tentatively 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#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#884">884</a>.</li>
 162 <li>Changed the following issues from Review to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1023">1023</a>.</li>
 163 <li>Changed the following issues from Open to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#96">96</a>.</li>
 164 <li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#906">906</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#913">913</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#914">914</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#925">925</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#982">982</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#984">984</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#998">998</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1063">1063</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1067">1067</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1070">1070</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1073">1073</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1103">1103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1107">1107</a>.</li>
 165 <li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#814">814</a>.</li>
 166 <li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#938">938</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1002">1002</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1006">1006</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1011">1011</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1024">1024</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1066">1066</a>.</li>
 167 </ul></li>
 168 </ul>
 169 </li>
 170 <li>R64:
 171 2009-05-01 mid-term mailing.
 172 <ul>
 173 <li><b>Summary:</b><ul>
 174 <li>346 open issues, up by 19.</li>
 175 <li>765 closed issues, up by 0.</li>
 176 <li>1111 issues total, up by 19.</li>
 177 </ul></li>
 178 <li><b>Details:</b><ul>
 179 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1093">1093</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1094">1094</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1095">1095</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1096">1096</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1097">1097</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1098">1098</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1099">1099</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1100">1100</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1101">1101</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1102">1102</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1103">1103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1104">1104</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1105">1105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1106">1106</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1107">1107</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1108">1108</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1109">1109</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1110">1110</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1111">1111</a>.</li>
 180 <li>Changed the following issues from DR to CD1: <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-defects.html#386">386</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#406">406</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#409">409</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#413">413</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#434">434</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#438">438</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#444">444</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#445">445</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#455">455</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>, <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-defects.html#469">469</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#533">533</a>.</li>
 181 <li>Changed the following issues from Review to New: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1070">1070</a>.</li>
 182 </ul></li>
 183 </ul>
 184 </li>
 185 <li>R63:
 186 2009-03-20 post-Summit mailing.
 187 <ul>
 188 <li><b>Summary:</b><ul>
 189 <li>327 open issues, up by 96.</li>
 190 <li>765 closed issues, up by 14.</li>
 191 <li>1092 issues total, up by 110.</li>
 192 </ul></li>
 193 <li><b>Details:</b><ul>
 194 <li>Added the following NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1022">1022</a>.</li>
 195 <li>Added the following NAD Future issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1025">1025</a>.</li>
 196 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#983">983</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#984">984</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#985">985</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#989">989</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#990">990</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#995">995</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#996">996</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#998">998</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#999">999</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1001">1001</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1033">1033</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1056">1056</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1057">1057</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1058">1058</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1059">1059</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1060">1060</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1061">1061</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1062">1062</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1063">1063</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1067">1067</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1068">1068</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1069">1069</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1071">1071</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1072">1072</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1073">1073</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1074">1074</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1076">1076</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1077">1077</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1080">1080</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1090">1090</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1092">1092</a>.</li>
 197 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#987">987</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1000">1000</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1007">1007</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1008">1008</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1016">1016</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1017">1017</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1018">1018</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1020">1020</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1026">1026</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1027">1027</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1028">1028</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1029">1029</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1030">1030</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1031">1031</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1032">1032</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1034">1034</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1035">1035</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1036">1036</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1041">1041</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1042">1042</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1046">1046</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1048">1048</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1051">1051</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1052">1052</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1053">1053</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1055">1055</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1064">1064</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1075">1075</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1078">1078</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1079">1079</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1081">1081</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1082">1082</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1083">1083</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1084">1084</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1085">1085</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1086">1086</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1087">1087</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1088">1088</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1089">1089</a>.</li>
 198 <li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#986">986</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#991">991</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#992">992</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#993">993</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#994">994</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#997">997</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1002">1002</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1003">1003</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1005">1005</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1006">1006</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1009">1009</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1010">1010</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1011">1011</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1013">1013</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1014">1014</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1015">1015</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1019">1019</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1021">1021</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1023">1023</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1024">1024</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1037">1037</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1038">1038</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1039">1039</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1040">1040</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1043">1043</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1044">1044</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1045">1045</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1047">1047</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1049">1049</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1050">1050</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1065">1065</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1066">1066</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1070">1070</a>.</li>
 199 <li>Added the following Tentatively Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#988">988</a>.</li>
 200 <li>Changed the following issues from New to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#905">905</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#942">942</a>.</li>
 201 <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#980">980</a>.</li>
 202 <li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#875">875</a>.</li>
 203 <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#800">800</a>.</li>
 204 <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#683">683</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a>.</li>
 205 <li>Changed the following issues from Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a>.</li>
 206 <li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>.</li>
 207 <li>Changed the following issues from NAD Future to Open: <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#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>.</li>
 208 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#880">880</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#891">891</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#902">902</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#908">908</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#959">959</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#960">960</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#961">961</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#963">963</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#964">964</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#966">966</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#968">968</a>.</li>
 209 <li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>.</li>
 210 <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#937">937</a>.</li>
 211 <li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#901">901</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#938">938</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#975">975</a>.</li>
 212 <li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>.</li>
 213 <li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#904">904</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#922">922</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#928">928</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#931">931</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#948">948</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#949">949</a>.</li>
 214 <li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#890">890</a>.</li>
 215 <li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#765">765</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-defects.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#878">878</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#888">888</a>.</li>
 216 <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#894">894</a>.</li>
 217 </ul></li>
 218 </ul>
 219 </li>
 220 <li>R62:
 221 2009-02-06 pre-Summit mailing.
 222 <ul>
 223 <li><b>Summary:</b><ul>
 224 <li>231 open issues, up by 44.</li>
 225 <li>751 closed issues, up by 0.</li>
 226 <li>982 issues total, up by 44.</li>
 227 </ul></li>
 228 <li><b>Details:</b><ul>
 229 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#939">939</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#940">940</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#941">941</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#942">942</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#943">943</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#945">945</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#946">946</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#948">948</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#949">949</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#951">951</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#952">952</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#953">953</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#954">954</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#955">955</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#956">956</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#957">957</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#959">959</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#960">960</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#961">961</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#963">963</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#964">964</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#965">965</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#966">966</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#967">967</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#968">968</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#969">969</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#970">970</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#972">972</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#973">973</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#974">974</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#975">975</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#977">977</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#978">978</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#979">979</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#980">980</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#981">981</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#982">982</a>.</li>
 230 </ul></li>
 231 </ul>
 232 </li>
 233 <li>R61:
 234 2008-12-05 mid-term mailing.
 235 <ul>
 236 <li><b>Summary:</b><ul>
 237 <li>187 open issues, up by 20.</li>
 238 <li>751 closed issues, up by 0.</li>
 239 <li>938 issues total, up by 20.</li>
 240 </ul></li>
 241 <li><b>Details:</b><ul>
 242 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#920">920</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#922">922</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#925">925</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#927">927</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#928">928</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#931">931</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#932">932</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#937">937</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#938">938</a>.</li>
 243 </ul></li>
 244 </ul>
 245 </li>
 246 <li>R60:
 247 2008-10-03 post-San Francisco mailing.
 248 <ul>
 249 <li><b>Summary:</b><ul>
 250 <li>167 open issues, down by 25.</li>
 251 <li>751 closed issues, up by 65.</li>
 252 <li>918 issues total, up by 40.</li>
 253 </ul></li>
 254 <li><b>Details:</b><ul>
 255 <li>Added the following CD1 issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#882">882</a>.</li>
 256 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#880">880</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#891">891</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#898">898</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#899">899</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#900">900</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#901">901</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#902">902</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#903">903</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#904">904</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#905">905</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#906">906</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#907">907</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#908">908</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#909">909</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#910">910</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#911">911</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#912">912</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#913">913</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#914">914</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#915">915</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#918">918</a>.</li>
 257 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#881">881</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#883">883</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#884">884</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#885">885</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#886">886</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#887">887</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#889">889</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#890">890</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#895">895</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#896">896</a>.</li>
 258 <li>Added the following Pending NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a>.</li>
 259 <li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#894">894</a>.</li>
 260 <li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#888">888</a>.</li>
 261 <li>Changed the following issues from New to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#858">858</a>.</li>
 262 <li>Changed the following issues from Ready to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#852">852</a>.</li>
 263 <li>Changed the following issues from Review to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>.</li>
 264 <li>Changed the following issues from WP to CD1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#44">44</a>, <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#92">92</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#98">98</a>, <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#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#118">118</a>, <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#123">123</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#167">167</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#179">179</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#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#187">187</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#198">198</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>, <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#202">202</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#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#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#228">228</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#230">230</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#231">231</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#233">233</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#235">235</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#238">238</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#239">239</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#240">240</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#243">243</a>, <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#248">248</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#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#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-defects.html#256">256</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-defects.html#259">259</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#264">264</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#266">266</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</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#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#274">274</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#276">276</a>, <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#280">280</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#282">282</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</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#291">291</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#294">294</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#300">300</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#305">305</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#310">310</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#311">311</a>, <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#315">315</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#316">316</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#317">317</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#318">318</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#319">319</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#320">320</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#321">321</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#322">322</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#324">324</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#325">325</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#327">327</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#328">328</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#329">329</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#331">331</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#333">333</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#334">334</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#335">335</a>, <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-defects.html#337">337</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#338">338</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#340">340</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#341">341</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#345">345</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#346">346</a>, <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-defects.html#349">349</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#352">352</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#354">354</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#355">355</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#358">358</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#359">359</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#360">360</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#363">363</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#364">364</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#365">365</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#370">370</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#373">373</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#375">375</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#379">379</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#380">380</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#381">381</a>, <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#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#391">391</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#395">395</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#400">400</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#402">402</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#403">403</a>, <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-defects.html#405">405</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#407">407</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#410">410</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#411">411</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#412">412</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#414">414</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#415">415</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#420">420</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#425">425</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#426">426</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#428">428</a>, <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-defects.html#435">435</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#436">436</a>, <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#442">442</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#443">443</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#448">448</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#449">449</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#453">453</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#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#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#488">488</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#496">496</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#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a>, <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#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</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#534">534</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>, <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#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-defects.html#550">550</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#552">552</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#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#566">566</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#574">574</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#577">577</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#581">581</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#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#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#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#612">612</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#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</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#628">628</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#638">638</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>, <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#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#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-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#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-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-defects.html#685">685</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#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-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>, <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#712">712</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>
 265 <li>Changed the following issues from Open to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#670">670</a>.</li>
 266 <li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#871">871</a>.</li>
 267 <li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#454">454</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>.</li>
 268 <li>Changed the following issues from New to NAD Editorial: <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-closed.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#864">864</a>, <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#872">872</a>.</li>
 269 <li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#484">484</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</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#704">704</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#742">742</a>.</li>
 270 <li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#594">594</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>.</li>
 271 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#814">814</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#819">819</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#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#838">838</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#857">857</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>, <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-closed.html#873">873</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-closed.html#877">877</a>.</li>
 272 <li>Changed the following issues from Pending NAD Editorial to Open: <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-active.html#625">625</a>.</li>
 273 <li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#851">851</a>.</li>
 274 <li>Changed the following issues from New to Ready: <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-defects.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#866">866</a>.</li>
 275 <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#753">753</a>.</li>
 276 <li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a>.</li>
 277 <li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#765">765</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-defects.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-defects.html#869">869</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#878">878</a>.</li>
 278 <li>Changed the following issues from TC to TC1: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1">1</a>, <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#5">5</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#7">7</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#11">11</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#13">13</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#14">14</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#15">15</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#16">16</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#18">18</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#20">20</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#21">21</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#22">22</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#24">24</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#25">25</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#27">27</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#28">28</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#30">30</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#32">32</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#33">33</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#34">34</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#35">35</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#36">36</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#37">37</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#39">39</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#40">40</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#41">41</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#42">42</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#46">46</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#47">47</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#48">48</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#50">50</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#51">51</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#52">52</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#53">53</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#54">54</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#55">55</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#56">56</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#57">57</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#59">59</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</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#62">62</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#64">64</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#66">66</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#68">68</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#69">69</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#70">70</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#71">71</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#74">74</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#75">75</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#78">78</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#79">79</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#80">80</a>, <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#90">90</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#106">106</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#110">110</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#119">119</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#124">124</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#125">125</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#126">126</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#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-defects.html#137">137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#141">141</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#148">148</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#150">150</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#151">151</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#152">152</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#154">154</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#155">155</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#156">156</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#158">158</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#160">160</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#161">161</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#168">168</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#169">169</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#172">172</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#173">173</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#174">174</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#175">175</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#176">176</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#189">189</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#193">193</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</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>.</li>
 279 </ul></li>
 280 </ul>
 281 </li>
 282 <li>R59:
 283 2008-08-22 pre-San Francisco mailing.
 284 <ul>
 285 <li><b>Summary:</b><ul>
 286 <li>192 open issues, up by 9.</li>
 287 <li>686 closed issues, up by 0.</li>
 288 <li>878 issues total, up by 9.</li>
 289 </ul></li>
 290 <li><b>Details:</b><ul>
 291 <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-closed.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#877">877</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#878">878</a>.</li>
 292 </ul></li>
 293 </ul>
 294 </li>
 295 <li>R58:
 296 2008-07-28 mid-term mailing.
 297 <ul>
 298 <li><b>Summary:</b><ul>
 299 <li>183 open issues, up by 12.</li>
 300 <li>686 closed issues, down by 4.</li>
 301 <li>869 issues total, up by 8.</li>
 302 </ul></li>
 303 <li><b>Details:</b><ul>
 304 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.html#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.html#869">869</a>.</li>
 305 <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>
 306 <li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#644">644</a>.</li>
 307 <li>Changed the following issues from WP to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#629">629</a>.</li>
 308 <li>Changed the following issues from Pending NAD Editorial to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#709">709</a>.</li>
 309 </ul></li>
 310 </ul>
 311 </li>
 312 <li>R57:
 313 2008-06-27 post-Sophia Antipolis mailing.
 314 <ul>
 315 <li><b>Summary:</b><ul>
 316 <li>171 open issues, down by 20.</li>
 317 <li>690 closed issues, up by 43.</li>
 318 <li>861 issues total, up by 23.</li>
 319 </ul></li>
 320 <li><b>Details:</b><ul>
 321 <li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#840">840</a>.</li>
 322 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.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>
 323 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#839">839</a>.</li>
 324 <li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#852">852</a>.</li>
 325 <li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#851">851</a>.</li>
 326 <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>
 327 <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>
 328 <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>
 329 <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>
 330 <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-closed.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-closed.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>.</li>
 331 <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>
 332 <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>
 333 <li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#829">829</a>.</li>
 334 <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>.</li>
 335 <li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>.</li>
 336 <li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.html#832">832</a>.</li>
 337 <li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a>.</li>
 338 <li>Changed the following issues from Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#758">758</a>.</li>
 339 <li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.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>
 340 </ul></li>
 341 </ul>
 342 </li>
 343 <li>R56:
 344 2008-05-16 pre-Sophia Antipolis mailing.
 345 <ul>
 346 <li><b>Summary:</b><ul>
 347 <li>191 open issues, up by 24.</li>
 348 <li>647 closed issues, up by 1.</li>
 349 <li>838 issues total, up by 25.</li>
 350 </ul></li>
 351 <li><b>Details:</b><ul>
 352 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.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-defects.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#832">832</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#838">838</a>.</li>
 353 <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>
 354 </ul></li>
 355 </ul>
 356 </li>
 357 <li>R55:
 358 2008-03-14 post-Bellevue mailing.
 359 <ul>
 360 <li><b>Summary:</b><ul>
 361 <li>167 open issues, down by 39.</li>
 362 <li>646 closed issues, up by 65.</li>
 363 <li>813 issues total, up by 26.</li>
 364 </ul></li>
 365 <li><b>Details:</b><ul>
 366 <li>Added the following Dup issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a>.</li>
 367 <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>
 368 <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-closed.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-defects.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#813">813</a>.</li>
 369 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#803">803</a>.</li>
 370 <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>
 371 <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>
 372 <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>
 373 <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>
 374 <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>
 375 <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>
 376 <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>
 377 <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>
 378 <li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a>.</li>
 379 <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-closed.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-defects.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-closed.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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>
 380 <li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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#688">688</a>.</li>
 381 <li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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>
 382 <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-active.html#625">625</a>.</li>
 383 <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-defects.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>
 384 <li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>.</li>
 385 <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>
 386 <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-defects.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776">776</a>.</li>
 387 <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>
 388 <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>
 389 <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>
 390 </ul></li>
 391 </ul>
 392 </li>
 393 <li>R54:
 394 2008-02-01 pre-Bellevue mailing.
 395 <ul>
 396 <li><b>Summary:</b><ul>
 397 <li>206 open issues, up by 23.</li>
 398 <li>581 closed issues, up by 0.</li>
 399 <li>787 issues total, up by 23.</li>
 400 </ul></li>
 401 <li><b>Details:</b><ul>
 402 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.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-defects.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.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-defects.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-closed.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-defects.html#787">787</a>.</li>
 403 <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>
 404 <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>
 405 <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>
 406 <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>
 407 <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>
 408 </ul></li>
 409 </ul>
 410 </li>
 411 <li>R53:
 412 2007-12-09 mid-term mailing.
 413 <ul>
 414 <li><b>Summary:</b><ul>
 415 <li>183 open issues, up by 11.</li>
 416 <li>581 closed issues, down by 1.</li>
 417 <li>764 issues total, up by 10.</li>
 418 </ul></li>
 419 <li><b>Details:</b><ul>
 420 <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-defects.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-closed.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-defects.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>
 421 <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>
 422 <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>
 423 </ul></li>
 424 </ul>
 425 </li>
 426 <li>R52:
 427 2007-10-19 post-Kona mailing.
 428 <ul>
 429 <li><b>Summary:</b><ul>
 430 <li>172 open issues, up by 4.</li>
 431 <li>582 closed issues, up by 27.</li>
 432 <li>754 issues total, up by 31.</li>
 433 </ul></li>
 434 <li><b>Details:</b><ul>
 435 <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-defects.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-closed.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-defects.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-closed.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-closed.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>.</li>
 436 <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>
 437 <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>
 438 <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>
 439 <li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.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-closed.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-closed.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-closed.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#708">708</a>.</li>
 440 <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>
 441 <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>
 442 <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-defects.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-defects.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>
 443 <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>
 444 <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-defects.html#691">691</a>.</li>
 445 <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>
 446 <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>
 447 <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>
 448 </ul></li>
 449 </ul>
 450 </li>
 451 <li>R51:
 452 2007-09-09 pre-Kona mailing.
 453 <ul>
 454 <li><b>Summary:</b><ul>
 455 <li>168 open issues, up by 15.</li>
 456 <li>555 closed issues, up by 0.</li>
 457 <li>723 issues total, up by 15.</li>
 458 </ul></li>
 459 <li><b>Details:</b><ul>
 460 <li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.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-defects.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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>
 461 </ul></li>
 462 </ul>
 463 </li>
 464 <li>R50:
 465 2007-08-05 post-Toronto mailing.
 466 <ul>
 467 <li><b>Summary:</b><ul>
 468 <li>153 open issues, down by 5.</li>
 469 <li>555 closed issues, up by 17.</li>
 470 <li>708 issues total, up by 12.</li>
 471 </ul></li>
 472 <li><b>Details:</b><ul>
 473 <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-defects.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-closed.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#708">708</a>.</li>
 474 <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>
 475 <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>
 476 <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>
 477 <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>
 478 <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>
 479 <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>
 480 <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>
 481 <li>Changed the following issues from Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#644">644</a>.</li>
 482 <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>
 483 <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>
 484 <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>
 485 <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>
 486 <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>
 487 <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>
 488 </ul></li>
 489 </ul>
 490 </li>
 491 <li>R49:
 492 2007-06-23 pre-Toronto mailing.
 493 <ul>
 494 <li><b>Summary:</b><ul>
 495 <li>158 open issues, up by 13.</li>
 496 <li>538 closed issues, up by 7.</li>
 497 <li>696 issues total, up by 20.</li>
 498 </ul></li>
 499 <li><b>Details:</b><ul>
 500 <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-defects.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-defects.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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>
 501 <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>
 502 <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>
 503 <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>
 504 <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>
 505 </ul></li>
 506 </ul>
 507 </li>
 508 <li>R48:
 509 2007-05-06 post-Oxford mailing.
 510 <ul>
 511 <li><b>Summary:</b><ul>
 512 <li>145 open issues, down by 33.</li>
 513 <li>531 closed issues, up by 53.</li>
 514 <li>676 issues total, up by 20.</li>
 515 </ul></li>
 516 <li><b>Details:</b><ul>
 517 <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-closed.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-closed.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>.</li>
 518 <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>
 519 <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>
 520 <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>
 521 <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>
 522 <li>Changed the following issues from NAD_Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li>
 523 <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>
 524 <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>
 525 <li>Changed the following issues from Tentatively Ready to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.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-active.html#594">594</a>.</li>
 526 <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>
 527 <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-closed.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>.</li>
 528 <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>
 529 <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>
 530 <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>
 531 <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>
 532 </ul></li>
 533 </ul>
 534 </li>
 535 <li>R47:
 536 2007-03-09 pre-Oxford mailing.
 537 <ul>
 538 <li><b>Summary:</b><ul>
 539 <li>178 open issues, up by 37.</li>
 540 <li>478 closed issues, up by 0.</li>
 541 <li>656 issues total, up by 37.</li>
 542 </ul></li>
 543 <li><b>Details:</b><ul>
 544 <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-defects.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-closed.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-closed.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>
 545 <li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li>
 546 <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-closed.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-closed.html#614">614</a>.</li>
 547 <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-active.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>
 548 <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-active.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>
 549 <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>
 550 </ul></li>
 551 </ul>
 552 </li>
 553 <li>R46:
 554 2007-01-12 mid-term mailing.
 555 <ul>
 556 <li><b>Summary:</b><ul>
 557 <li>141 open issues, up by 11.</li>
 558 <li>478 closed issues, down by 1.</li>
 559 <li>619 issues total, up by 10.</li>
 560 </ul></li>
 561 <li><b>Details:</b><ul>
 562 <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#611">611</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#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#614">614</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-active.html#617">617</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#619">619</a>.</li>
 563 </ul></li>
 564 </ul>
 565 </li>
 566 <li>R45:
 567 2006-11-03 post-Portland mailing.
 568 <ul>
 569 <li><b>Summary:</b><ul>
 570 <li>130 open issues, up by 0.</li>
 571 <li>479 closed issues, up by 17.</li>
 572 <li>609 issues total, up by 17.</li>
 573 </ul></li>
 574 <li><b>Details:</b><ul>
 575 <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>
 576 <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>
 577 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Dup.</li>
 578 <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-closed.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-closed.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#606">606</a> to Open.</li>
 579 <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>
 580 <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>
 581 <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-active.html#594">594</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-closed.html#597">597</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#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#604">604</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#606">606</a>, <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#609">609</a>.</li>
 582 </ul></li>
 583 </ul>
 584 </li>
 585 <li>R44:
 586 2006-09-08 pre-Portland mailing.
 587 <ul>
 588 <li><b>Summary:</b><ul>
 589 <li>130 open issues, up by 6.</li>
 590 <li>462 closed issues, down by 1.</li>
 591 <li>592 issues total, up by 5.</li>
 592 </ul></li>
 593 <li><b>Details:</b><ul>
 594 <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#584">584</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#585">585</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-closed.html#587">587</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-defects.html#589">589</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-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li>
 595 </ul></li>
 596 </ul>
 597 </li>
 598 <li>R43:
 599 2006-06-23 mid-term mailing.
 600 <ul>
 601 <li><b>Summary:</b><ul>
 602 <li>124 open issues, up by 14.</li>
 603 <li>463 closed issues, down by 1.</li>
 604 <li>587 issues total, up by 13.</li>
 605 </ul></li>
 606 <li><b>Details:</b><ul>
 607 <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-defects.html#576">576</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#578">578</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-active.html#580">580</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-closed.html#582">582</a>.</li>
 608 <li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#255">255</a>.</li>
 609 <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>
 610 </ul></li>
 611 </ul>
 612 </li>
 613 <li>R42:
 614 2006-04-21 post-Berlin mailing.
 615 <ul>
 616 <li><b>Summary:</b><ul>
 617 <li>110 open issues, down by 16.</li>
 618 <li>464 closed issues, up by 24.</li>
 619 <li>574 issues total, up by 8.</li>
 620 </ul></li>
 621 <li><b>Details:</b><ul>
 622 <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#568">568</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a>, <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-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
 623 <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#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#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>
 624 <li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.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#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</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-active.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>
 625 <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>
 626 <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>
 627 <li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li>
 628 </ul></li>
 629 </ul>
 630 </li>
 631 <li>R41:
 632 2006-02-24 pre-Berlin mailing.
 633 <ul>
 634 <li><b>Summary:</b><ul>
 635 <li>126 open issues, up by 31.</li>
 636 <li>440 closed issues, up by 0.</li>
 637 <li>566 issues total, up by 31.</li>
 638 </ul></li>
 639 <li><b>Details:</b><ul>
 640 <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#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-active.html#539">539</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>, <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#543">543</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-defects.html#545">545</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#546">546</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#548">548</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#550">550</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#552">552</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#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-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-closed.html#558">558</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-closed.html#560">560</a>, <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-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-defects.html#566">566</a>.</li>
 641 <li>Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#342">342</a> from Ready to Open.</li>
 642 <li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#309">309</a>.</li>
 643 </ul></li>
 644 </ul>
 645 </li>
 646 <li>R40:
 647 2005-12-16 mid-term mailing.
 648 <ul>
 649 <li><b>Summary:</b><ul>
 650 <li>95 open issues.</li>
 651 <li>440 closed issues.</li>
 652 <li>535 issues total.</li>
 653 </ul></li>
 654 <li><b>Details:</b><ul>
 655 <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#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-active.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#533">533</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#535">535</a>.</li>
 656 </ul></li>
 657 </ul>
 658 </li>
 659 <li>R39:
 660 2005-10-14 post-Mont Tremblant mailing.
 661 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>.
 662 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.
 663 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-closed.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.
 664 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.
 665 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.
 666 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
 667 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a> from New to Review.
 668 </li>
 669 <li>R38:
 670 2005-07-03 pre-Mont Tremblant mailing.
 671 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-defects.html#522">522</a>.
 672 Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#523">523</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#523">523</a>
 673 </li>
 674 <li>R37:
 675 2005-06 mid-term mailing.
 676 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-closed.html#503">503</a>.
 677 </li>
 678 <li>R36:
 679 2005-04 post-Lillehammer mailing. All issues in "ready" status except
 680 for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#454">454</a> were moved to "DR" status, and all issues
 681 previously in "DR" status were moved to "WP".
 682 </li>
 683 <li>R35:
 684 2005-03 pre-Lillehammer mailing.
 685 </li>
 686 <li>R34:
 687 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>.
 688 </li>
 689 <li>R33:
 690 2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
 691 </li>
 692 <li>R32:
 693 2004-09 pre-Redmond mailing: reflects new proposed resolutions and
 694 new issues received after the 2004-07 mailing.  Added
 695 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>.
 696 </li>
 697 <li>R31:
 698 2004-07 mid-term mailing: reflects new proposed resolutions and
 699 new issues received after the post-Sydney mailing.  Added
 700 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>.
 701 </li>
 702 <li>R30:
 703 Post-Sydney mailing: reflects decisions made at the Sydney meeting.
 704 Voted all "Ready" issues from R29 into the working paper.
 705 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>.
 706 </li>
 707 <li>R29:
 708 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>.
 709 </li>
 710 <li>R28:
 711 Post-Kona mailing: reflects decisions made at the Kona meeting.
 712 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>.
 713 </li>
 714 <li>R27:
 715 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>.
 716 </li>
 717 <li>R26:
 718 Post-Oxford mailing: reflects decisions made at the Oxford meeting.
 719 All issues in Ready status were voted into DR status.  All issues in
 720 DR status were voted into WP status.
 721 </li>
 722 <li>R25:
 723 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>.
 724 </li>
 725 <li>R24:
 726 Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
 727 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
 728 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-defects.html#387">387</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> were discussed
 729 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
 730 concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
 731 </li>
 732 <li>R23:
 733 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-closed.html#382">382</a>.
 734 Moved issues in the TC to TC status.
 735 </li>
 736 <li>R22:
 737 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>.
 738 </li>
 739 <li>R21:
 740 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>.
 741 </li>
 742 <li>R20:
 743 Post-Redmond mailing; reflects actions taken in Redmond.  Added
 744 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
 745 <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
 746 not discussed at the meeting.
 747
 748 All Ready issues were moved to DR status, with the exception of issues
 749 <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>.
 750
 751 Noteworthy issues discussed at Redmond include
 752 <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>,
 753 <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>.
 754 </li>
 755 <li>R19:
 756 Pre-Redmond mailing.  Added new issues
 757 <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>.
 758 </li>
 759 <li>R18:
 760 Post-Copenhagen mailing; reflects actions taken in Copenhagen.
 761 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
 762 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>.
 763
 764 Changed status of issues
 765 <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>
 766 <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>
 767 <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>
 768 <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>
 769 <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>
 770 <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>
 771 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>
 772 to DR.
 773
 774 Changed status of issues
 775 <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>
 776 <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>
 777 <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>
 778 <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>
 779 <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>
 780 <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>
 781 <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>
 782 <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>
 783 <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>
 784 to Ready.
 785
 786 Closed issues
 787 <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>
 788 <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>
 789 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
 790 as NAD.
 791
 792 </li>
 793 <li>R17:
 794 Pre-Copenhagen mailing.  Converted issues list to XML.  Added proposed
 795 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>.
 796 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>.
 797 </li>
 798 <li>R16:
 799 post-Toronto mailing; reflects actions taken in Toronto. Added new
 800 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
 801 <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>,
 802 <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>,
 803 <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>,
 804 <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>,
 805 <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>,
 806 <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>,
 807 <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>,
 808 <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>,
 809 <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>,
 810 <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>,
 811 <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>,
 812 <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>,
 813 <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-defects.html#23">23</a>. Reopened
 814 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
 815 <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
 816 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
 817 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
 818 the bug in enough places.
 819 </li>
 820 <li>R15:
 821 pre-Toronto mailing. Added issues
 822 <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
 823 changes so that we pass Weblint tests.
 824 </li>
 825 <li>R14:
 826 post-Tokyo II mailing; reflects committee actions taken in
 827 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)
 828 </li>
 829 <li>R13:
 830 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>.
 831 </li>
 832 <li>R12:
 833 pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to
 834 <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
 835 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>.  Add further rationale to issue
 836 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>.
 837 </li>
 838 <li>R11:
 839 post-Kona mailing: Updated to reflect LWG and full committee actions
 840 in Kona (99-0048/N1224). Note changed resolution of issues
 841 <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>
 842 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
 843 "closed" documents.  Changed the proposed resolution of issue
 844 <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
 845 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>.
 846 </li>
 847 <li>R10:
 848 pre-Kona updated.  Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
 849 <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>,
 850 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a> to
 851 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
 852 </li>
 853 <li>R9:
 854 pre-Kona mailing.  Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to
 855 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
 856 "closed" documents. (99-0030/N1206, 25 Aug 99)
 857 </li>
 858 <li>R8:
 859 post-Dublin mailing. Updated to reflect LWG and full committee actions
 860 in Dublin. (99-0016/N1193, 21 Apr 99)
 861 </li>
 862 <li>R7:
 863 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>,
 864 <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>,
 865 <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>,
 866 <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)
 867 </li>
 868 <li>R6:
 869 pre-Dublin mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>,
 870 and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>.  (99-0007/N1194, 22 Feb 99)
 871 </li>
 872 <li>R5:
 873 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
 874 <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
 875 for making list public. (30 Dec 98)
 876 </li>
 877 <li>R4:
 878 post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
 879 <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
 880 issues corrected. (22 Oct 98)
 881 </li>
 882 <li>R3:
 883 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>
 884 added, many issues updated to reflect LWG consensus (12 Oct 98)
 885 </li>
 886 <li>R2:
 887 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,
 888 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98)
 889 </li>
 890 <li>R1:
 891 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
 892 format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98)
 893 </li>
 894 </ul>
 895
 896 <h2><a name="Status"></a>Issue Status</h2>
 897
 898   <p><b><a name="New">New</a></b> - The issue has not yet been
 899   reviewed by the LWG. Any <b>Proposed Resolution</b> is purely a
 900   suggestion from the issue submitter, and should not be construed as
 901   the view of LWG.</p>
 902
 903   <p><b><a name="Open">Open</a></b> - The LWG has discussed the issue
 904   but is not yet ready to move the issue forward. There are several
 905   possible reasons for open status:</p>
 906      <ul>
 907         <li>Consensus may have not yet have been reached as to how to deal
 908             with the issue.</li>
 909         <li>Informal consensus may have been reached, but the LWG awaits
 910             exact <b>Proposed Resolution</b> wording for review.</li>
 911         <li>The LWG wishes to consult additional technical experts before
 912             proceeding.</li>
 913         <li>The issue may require further study.</li>
 914      </ul>
 915
 916   <p>A <b>Proposed Resolution</b> for an open issue is still not be
 917   construed as the view of LWG. Comments on the current state of
 918   discussions are often given at the end of open issues in an italic
 919   font. Such comments are for information only and should not be given
 920   undue importance.</p>
 921
 922   <p><b><a name="Dup">Dup</a></b> - The LWG has reached consensus that
 923   the issue is a duplicate of another issue, and will not be further
 924   dealt with. A <b>Rationale</b> identifies the duplicated issue's
 925   issue number.  </p>
 926
 927   <p><b><a name="NAD">NAD</a></b> - The LWG has reached consensus that
 928   the issue is not a defect in the Standard.</p>
 929
 930   <p><b><a name="NAD Editorial">NAD Editorial</a></b> - The LWG has reached consensus that
 931   the issue can either be handled editorially, or is handled by a paper (usually
 932   linked to in the rationale).</p>
 933
 934   <p><b><a name="NAD Concepts">NAD Concepts</a></b> - The LWG has reached consensus that
 935   the issue is NAD for now, but represents a real issue when the library is
 936   done with language-supported concepts.</p>
 937
 938   <p><b><a name="NAD Future">NAD Future</a></b> - In addition to the regular
 939   status, the LWG believes that this issue should be revisited at the
 940   next revision of the standard.</p>
 941
 942   <p><b><a name="Review">Review</a></b> - Exact wording of a
 943   <b>Proposed Resolution</b> is now available for review on an issue
 944   for which the LWG previously reached informal consensus.</p>
 945
 946   <p><b><a name="Ready">Ready</a></b> - The LWG has reached consensus
 947   that the issue is a defect in the Standard, the <b>Proposed
 948   Resolution</b> is correct, and the issue is ready to forward to the
 949   full committee for further action as a Defect Report (DR).</p>
 950
 951   <p><b><a name="DR">DR</a></b> - (Defect Report) - The full J16
 952   committee has voted to forward the issue to the Project Editor to be
 953   processed as a Potential Defect Report. The Project Editor reviews
 954   the issue, and then forwards it to the WG21 Convenor, who returns it
 955   to the full committee for final disposition. This issues list
 956   accords the status of DR to all these Defect Reports regardless of
 957   where they are in that process.</p>
 958
 959   <p><b><a name="TC1">TC1</a></b> - (Technical Corrigenda 1) - The full
 960   WG21 committee has voted to accept the Defect Report's Proposed
 961   Resolution as a Technical Corrigenda.  Action on this issue is thus
 962   complete and no further action is possible under ISO rules.</p>
 963
 964   <p><b><a name="CD1">CD1</a></b> - (Committee Draft 2008) - The full
 965   WG21 committee has voted to accept the Defect Report's Proposed
 966   Resolution into the Fall 2008 Committee Draft.</p>
 967
 968   <p><b><a name="TRDec">TRDec</a></b> - (Decimal TR defect) - The
 969   LWG has voted to accept the Defect Report's Proposed
 970   Resolution into the Decimal TR.  Action on this issue is thus
 971   complete and no further action is expected.</p>
 972
 973   <p><b><a name="WP">WP</a></b> - (Working Paper) - The proposed
 974   resolution has not been accepted as a Technical Corrigendum, but
 975   the full WG21 committee has voted to apply the Defect Report's Proposed
 976   Resolution to the working paper.</p>
 977
 978   <p><b>Tentatively</b> - This is a <i>status qualifier</i>.  The issue has
 979   been reviewed online, or at an unofficial meeting, but not in an official meeting, and some support has been formed
 980   for the qualified status.  Tentatively qualified issues may be moved to the unqualified status
 981   and forwarded to full committee (if Ready) within the same meeting.  Unlike Ready issues, Tentatively Ready issues
 982   will be reviewed in subcommittee prior to forwarding to full committee.  When a status is
 983   qualified with Tentatively, the issue is still considered active.</p>
 984
 985   <p><b>Pending</b> - This is a <i>status qualifier</i>.  When prepended to
 986   a status this indicates the issue has been
 987   processed by the committee, and a decision has been made to move the issue to
 988   the associated unqualified status.  However for logistical reasons the indicated
 989   outcome of the issue has not yet appeared in the latest working paper.
 990
 991   </p><p>Issues are always given the status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> when
 992   they first appear on the issues list. They may progress to
 993   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> or <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> while the LWG
 994   is actively working on them. When the LWG has reached consensus on
 995   the disposition of an issue, the status will then change to
 996   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>, or
 997   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> as appropriate.  Once the full J16 committee votes to
 998   forward Ready issues to the Project Editor, they are given the
 999   status of Defect Report ( <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>). These in turn may
1000   become the basis for Technical Corrigenda (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>),
1001   or are closed without action other than a Record of Response
1002   (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#RR">RR</a> ). The intent of this LWG process is that
1003   only issues which are truly defects in the Standard move to the
1004   formal ISO DR status.
1005   </p>
1006
1007
1008 <h2>Active Issues</h2>
1009 <hr>
1010 <h3><a name="96"></a>96. Vector&lt;bool&gt; is not a container</h3>
1011 <p><b>Section:</b> 23.3.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
1012  <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07  <b>Last modified:</b> 2009-07-29</p>
1013 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#vector">active issues</a> in [vector].</p>
1014 <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>
1015 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
1016 <p><b>Discussion:</b></p>
1017 <p><tt>vector&lt;bool&gt;</tt> is not a container as its reference and
1018 pointer types are not references and pointers. </p>
1019
1020 <p>Also it forces everyone to have a space optimization instead of a
1021 speed one.</p>
1022
1023 <p><b>See also:</b> 99-0008 == N1185 Vector&lt;bool&gt; is
1024 Nonconforming, Forces Optimization Choice.</p>
1025
1026 <p><i>[In Santa Cruz the LWG felt that this was Not A Defect.]</i></p>
1027
1028
1029 <p><i>[In Dublin many present felt that failure to meet Container
1030 requirements was a defect. There was disagreement as to whether
1031 or not the optimization requirements constituted a defect.]</i></p>
1032
1033
1034 <p><i>[The LWG looked at the following resolutions in some detail:
1035 <br>
1036 &nbsp;&nbsp;&nbsp;&nbsp; * Not A Defect.<br>
1037 &nbsp;&nbsp;&nbsp;&nbsp; * Add a note explaining that vector&lt;bool&gt; does not meet
1038 Container requirements.<br>
1039 &nbsp;&nbsp;&nbsp;&nbsp; * Remove vector&lt;bool&gt;.<br>
1040 &nbsp;&nbsp;&nbsp;&nbsp; * Add a new category of container requirements which
1041 vector&lt;bool&gt; would meet.<br>
1042 &nbsp;&nbsp;&nbsp;&nbsp; * Rename vector&lt;bool&gt;.<br>
1043 <br>
1044 No alternative had strong, wide-spread, support and every alternative
1045 had at least one "over my dead body" response.<br>
1046 <br>
1047 There was also mention of a transition scheme something like (1) add
1048 vector_bool and deprecate vector&lt;bool&gt; in the next standard. (2)
1049 Remove vector&lt;bool&gt; in the following standard.]</i></p>
1050
1051
1052 <p><i>[Modifying container requirements to permit returning proxies
1053 (thus allowing container requirements conforming vector&lt;bool&gt;)
1054 was also discussed.]</i></p>
1055
1056
1057 <p><i>[It was also noted that there is a partial but ugly workaround in
1058 that vector&lt;bool&gt; may be further specialized with a customer
1059 allocator.]</i></p>
1060
1061
1062 <p><i>[Kona: Herb Sutter presented his paper J16/99-0035==WG21/N1211,
1063 vector&lt;bool&gt;: More Problems, Better Solutions. Much discussion
1064 of a two step approach: a) deprecate, b) provide replacement under a
1065 new name.  LWG straw vote on that: 1-favor, 11-could live with, 2-over
1066 my dead body.  This resolution was mentioned in the LWG report to the
1067 full committee, where several additional committee members indicated
1068 over-my-dead-body positions.]</i></p>
1069
1070
1071 <p>Discussed at Lillehammer.  General agreement that we should
1072   deprecate vector&lt;bool&gt; and introduce this functionality under
1073   a different name, e.g. bit_vector.  This might make it possible to
1074   remove the vector&lt;bool&gt; specialization in the standard that comes
1075   after C++0x. There was also a suggestion that
1076   in C++0x we could additional say that it's implementation defined
1077   whether vector&lt;bool&gt; refers to the specialization or to the
1078   primary template, but there wasn't general agreement that this was a
1079   good idea.</p>
1080
1081 <p>We need a paper for the new bit_vector class.</p>
1082
1083 <p><i>[
1084 Batavia:
1085 ]</i></p>
1086
1087 <blockquote>
1088 The LWG feels we need something closer to SGI's <tt>bitvector</tt> to ease migration
1089 from <tt>vector&lt;bool&gt;</tt>.  Although some of the funcitonality from
1090 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2050.pdf">N2050</a>
1091 could well be used in such a template.  The concern is easing the API migration for those
1092 users who want to continue using a bit-packed container.  Alan and Beman to work.
1093 </blockquote>
1094
1095 <p><i>[
1096 Post Summit Alisdair adds:
1097 ]</i></p>
1098
1099
1100 <blockquote>
1101 <p>
1102 <tt>vector&lt;bool&gt;</tt> is now a conforming container under the revised terms of C++0x,
1103 which supports containers of proxies.
1104 </p>
1105 <p>
1106 Recommend NAD.
1107 </p>
1108 <p>
1109 Two issues remain:
1110 </p>
1111 <p>
1112 i/ premature optimization in the specification.
1113 There is still some sentiment that deprecation is the correct way to go,
1114 although it is still not clear what it would mean to deprecate a single
1115 specialization of a template.
1116 </p>
1117 <p>
1118 Recommend: Create a new issue for the discussion, leave as Open.
1119 </p>
1120 <p>
1121 ii/ Request for a new bitvector class to guarantee the optimization, perhaps
1122 with a better tuned interface.
1123 </p>
1124 <p>
1125 This is a clear extension request that may be handled via a future TR.
1126 </p>
1127 </blockquote>
1128
1129 <p><i>[
1130 Batavia (2009-05):
1131 ]</i></p>
1132
1133 <blockquote>
1134 We note that most of this issue has become moot over time,
1135 and agree with Alisdair's recommendations.
1136 Move to NAD Future for reconsideration of part (ii).
1137 </blockquote>
1138
1139 <p><i>[
1140 2009-07-29 Alisdair reopens:
1141 ]</i></p>
1142
1143
1144 <blockquote>
1145 <p>
1146 This infamous issue was closed as NAD Future when concepts introduced
1147 support for proxy iterators, so the only remaining requirement was to
1148 provide a better type to support bitsets of dynamic length.  I fear we
1149 must re-open this issue until the post-concept form of iterators is
1150 available, and hopefully will support the necessary proxy functionality
1151 to allow us to close this issue as NAD.
1152 </p>
1153
1154 <p>
1155 I recommend we spawn a separate issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1184">1184</a>) requesting a dynamic length bitset
1156 and pre-emptively file it as NAD Future.  It is difficult to resolve #96
1157 when it effectively contains two separate sub-issues.
1158 </p>
1159 </blockquote>
1160
1161
1162 <p><b>Proposed resolution:</b></p>
1163 <p>
1164 We now have:
1165 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2050.pdf">N2050</a>
1166 and
1167 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2160.html">N2160</a>.
1168 </p>
1169
1170
1171
1172
1173
1174
1175 <hr>
1176 <h3><a name="149"></a>149. Insert should return iterator to first element inserted</h3>
1177 <p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
1178  <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 1999-06-28  <b>Last modified:</b> 2009-07-15</p>
1179 <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>
1180 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
1181 <p><b>Discussion:</b></p>
1182 <p>Suppose that c and c1 are sequential containers and i is an
1183 iterator that refers to an element of c.  Then I can insert a copy of
1184 c1's elements into c ahead of element i by executing </p>
1185
1186 <blockquote>
1187
1188 <pre>c.insert(i, c1.begin(), c1.end());</pre>
1189
1190 </blockquote>
1191
1192 <p>If c is a vector, it is fairly easy for me to find out where the
1193 newly inserted elements are, even though i is now invalid: </p>
1194
1195 <blockquote>
1196
1197 <pre>size_t i_loc = i - c.begin();
1198 c.insert(i, c1.begin(), c1.end());</pre>
1199
1200 </blockquote>
1201
1202 <p>and now the first inserted element is at c.begin()+i_loc and one
1203 past the last is at c.begin()+i_loc+c1.size().<br>
1204 <br>
1205 But what if c is a list? I can still find the location of one past the
1206 last inserted element, because i is still valid. To find the location
1207 of the first inserted element, though, I must execute something like </p>
1208
1209 <blockquote>
1210
1211 <pre>for (size_t n = c1.size(); n; --n)
1212    --i;</pre>
1213
1214 </blockquote>
1215
1216 <p>because i is now no longer a random-access iterator.<br>
1217 <br>
1218 Alternatively, I might write something like </p>
1219
1220 <blockquote>
1221
1222 <pre>bool first = i == c.begin();
1223 list&lt;T&gt;::iterator j = i;
1224 if (!first) --j;
1225 c.insert(i, c1.begin(), c1.end());
1226 if (first)
1227    j = c.begin();
1228 else
1229    ++j;</pre>
1230
1231 </blockquote>
1232
1233 <p>which, although wretched, requires less overhead.<br>
1234 <br>
1235 But I think the right solution is to change the definition of insert
1236 so that instead of returning void, it returns an iterator that refers
1237 to the first element inserted, if any, and otherwise is a copy of its
1238 first argument.&nbsp; </p>
1239
1240 <p><i>[
1241 Summit:
1242 ]</i></p>
1243
1244
1245 <blockquote>
1246 Reopened by Alisdair.
1247 </blockquote>
1248
1249 <p><i>[
1250 Post Summit Alisdair adds:
1251 ]</i></p>
1252
1253
1254 <blockquote>
1255 <p>
1256 In addition to the original rationale for C++03, this change also gives a
1257 consistent interface for all container insert operations i.e. they all
1258 return an iterator to the (first) inserted item.
1259 </p>
1260
1261 <p>
1262 Proposed wording provided.
1263 </p>
1264 </blockquote>
1265
1266 <p><i>[
1267 2009-07 Frankfurt
1268 ]</i></p>
1269
1270
1271 <blockquote>
1272 <p>
1273 Q: why isn't this change also proposed for associative containers?
1274 </p>
1275
1276 <p>
1277 A: The returned iterator wouldn't necessarily point to a contiguous range.
1278 </p>
1279
1280 <p>
1281 Moved to Ready.
1282 </p>
1283 </blockquote>
1284
1285
1286
1287 <p><b>Proposed resolution:</b></p>
1288 <p>
1289 <sef ref="[sequence.reqmts]"> Table 83
1290 change return type from <tt>void</tt> to <tt>iterator</tt> for the following rows:
1291 </sef></p>
1292
1293 <blockquote>
1294 <table border="1">
1295 <caption>Table 83 -- Sequence container requirements (in addition to container)</caption>
1296 <tbody><tr>
1297 <th>Expression</th>
1298 <th>Return type</th>
1299 <th>Assertion/note pre-/post-condition</th>
1300 </tr>
1301 <tr>
1302 <td>
1303 <tt>a.insert(p,n,t)</tt>
1304 </td>
1305 <td>
1306 <tt><del>void</del> <ins>iterator</ins></tt>
1307 </td>
1308 <td>
1309 Inserts <tt>n</tt> copies of <tt>t</tt> before <tt>p</tt>.
1310 </td>
1311 </tr>
1312
1313 <tr>
1314 <td>
1315 <tt>a.insert(p,i,j)</tt>
1316 </td>
1317 <td>
1318 <tt><del>void</del> <ins>iterator</ins></tt>
1319 </td>
1320 <td>
1321 Each iterator in the range <tt>[i,j)</tt> shall be
1322 dereferenced exactly once.
1323 pre: <tt>i</tt> and <tt>j</tt> are not iterators into <tt>a</tt>.
1324 Inserts copies of elements in <tt>[i, j)</tt> before <tt>p</tt>
1325 </td>
1326 </tr>
1327
1328 <tr>
1329 <td>
1330 <tt>a.insert(p,il)</tt>
1331 </td>
1332 <td>
1333 <tt><del>void</del> <ins>iterator</ins></tt>
1334 </td>
1335 <td>
1336 <tt>a.insert(p, il.begin(), il.end())</tt>.
1337 </td>
1338 </tr>
1339 </tbody></table>
1340 </blockquote>
1341
1342 <p>
1343 Add after p6 23.2.3 [sequence.reqmts]:
1344 </p>
1345
1346 <blockquote>
1347 <p>-6- ...</p>
1348
1349 <p><ins>
1350 The iterator returned from <tt>a.insert(p,n,t)</tt> points to the copy of the
1351 first element inserted into <tt>a</tt>, or <tt>p</tt> if <tt>n == 0</tt>.
1352 </ins></p>
1353
1354 <p><ins>
1355 The iterator returned from <tt>a.insert(p,i,j)</tt> points to the copy of the
1356 first element inserted into <tt>a</tt>, or <tt>p</tt> if <tt>i == j</tt>.
1357 </ins></p>
1358
1359 <p><ins>
1360 The iterator returned from <tt>a.insert(p,il)</tt> points to the copy of the
1361 first element inserted into <tt>a</tt>, or <tt>p</tt> if <tt>il</tt> is empty.
1362 </ins></p>
1363
1364 </blockquote>
1365
1366 <p>
1367 p2 23.3.2 [deque] Update class definition, change return type
1368 from <tt>void</tt> to <tt>iterator</tt>:
1369 </p>
1370
1371 <blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T&amp; x);
1372 template &lt;class InputIterator&gt;
1373   <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
1374   <del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list&lt;T&gt;);
1375 </pre></blockquote>
1376
1377 <p>
1378 23.3.2.3 [deque.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
1379 </p>
1380
1381 <blockquote><pre>  <del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T&amp; x);
1382 template &lt;class InputIterator&gt;
1383   <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
1384 </pre></blockquote>
1385
1386 <p>
1387 Add the following (missing) declaration
1388 </p>
1389
1390 <blockquote><pre><ins>iterator insert(const_iterator position, initializer_list&lt;T&gt;);</ins>
1391 </pre></blockquote>
1392
1393 <p>
1394 23.3.3 [forwardlist] Update class definition, change return type
1395 from <tt>void</tt> to <tt>iterator</tt>:
1396 </p>
1397
1398 <blockquote><pre><del>void</del> <ins>iterator</ins> insert_after(const_iterator position, initializer_list&lt;T&gt; il);
1399 <del>void</del> <ins>iterator</ins> insert_after(const_iterator position, size_type n, const T&amp; x);
1400 template &lt;class InputIterator&gt;
1401   <del>void</del> <ins>iterator</ins> insert_after(const_iterator position, InputIterator first, InputIterator last);
1402 </pre></blockquote>
1403
1404 <p>
1405 p8 23.3.3.4 [forwardlist.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt>:
1406 </p>
1407
1408 <blockquote><pre><del>void</del> <ins>iterator</ins> insert_after(const_iterator position, size_type n, const T&amp; x);
1409 </pre></blockquote>
1410
1411 <p>
1412 Add paragraph:
1413 </p>
1414
1415 <blockquote>
1416 Returns: position.
1417 </blockquote>
1418
1419 <p>
1420 p10 23.3.3.4 [forwardlist.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt>:
1421 </p>
1422
1423 <blockquote><pre>template &lt;class InputIterator&gt;
1424   <del>void</del> <ins>iterator</ins> insert_after(const_iterator position, InputIterator first, InputIterator last);
1425 </pre></blockquote>
1426
1427 <p>
1428 Add paragraph:
1429 </p>
1430
1431 <blockquote>
1432 Returns: position.
1433 </blockquote>
1434
1435 <p>
1436 p12 23.3.3.4 [forwardlist.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
1437 </p>
1438
1439 <blockquote><pre><del>void</del> <ins>iterator</ins> insert_after(const_iterator position, initializer_list&lt;T&gt; il);
1440 </pre></blockquote>
1441
1442 <p>
1443 change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
1444 </p>
1445
1446 <p>
1447 p2 23.3.4 [list] Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>:
1448 </p>
1449
1450 <blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T&amp; x);
1451
1452 template &lt;class InputIterator&gt;
1453 <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
1454
1455 <del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list&lt;T&gt;);
1456 </pre></blockquote>
1457
1458 <p>
1459 23.3.4.3 [list.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
1460 </p>
1461
1462 <blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T&amp; x);
1463
1464 template &lt;class InputIterator&gt;
1465   <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
1466 </pre></blockquote>
1467
1468 <p>
1469 Add the following (missing) declaration
1470 </p>
1471
1472 <blockquote><pre>iterator insert(const_iterator position, initializer_list&lt;T&gt;);
1473 </pre></blockquote>
1474
1475 <p>
1476 p2 23.3.6 [vector]
1477 </p>
1478
1479 <p>
1480 Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>:
1481 </p>
1482
1483 <blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator position, T&amp;&amp; x);
1484
1485 <del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T&amp; x);
1486
1487 template &lt;class InputIterator&gt;
1488   <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
1489
1490 <del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list&lt;T&gt;);
1491 </pre></blockquote>
1492
1493 <p>
1494 23.3.6.4 [vector.modifiers] change return type from <tt>void</tt> to <tt>iterator</tt> on following declarations:
1495 </p>
1496
1497 <blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator position, size_type n, const T&amp; x);
1498
1499 template &lt;class InputIterator&gt;
1500   <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
1501 </pre></blockquote>
1502
1503 <p>
1504 Add the following (missing) declaration
1505 </p>
1506
1507 <blockquote><pre>iterator insert(const_iterator position, initializer_list&lt;T&gt;);
1508 </pre></blockquote>
1509
1510
1511 <p>
1512 p1 23.3.7 [vector.bool] Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>:
1513 </p>
1514
1515 <blockquote><pre><del>void</del> <ins>iterator</ins> insert (const_iterator position, size_type n, const bool&amp; x);
1516
1517 template &lt;class InputIterator&gt;
1518   <del>void</del> <ins>iterator</ins> insert(const_iterator position, InputIterator first, InputIterator last);
1519
1520   <del>void</del> <ins>iterator</ins> insert(const_iterator position, initializer_list&lt;bool&gt; il);
1521 </pre></blockquote>
1522
1523 <p>
1524 p5 21.4 [basic.string] Update class definition, change return type from <tt>void</tt> to <tt>iterator</tt>:
1525 </p>
1526
1527 <blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator p, size_type n, charT c);
1528
1529 template&lt;class InputIterator&gt;
1530   <del>void</del> <ins>iterator</ins> insert(const_iterator p, InputIterator first, InputIterator last);
1531
1532 <del>void</del> <ins>iterator</ins> insert(const_iterator p, initializer_list&lt;charT&gt;);
1533 </pre></blockquote>
1534
1535 <p>
1536 p13 21.4.6.4 [string::insert] change return type from <tt>void</tt> to <tt>iterator</tt>:
1537 </p>
1538
1539 <blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator p, size_type n, charT c);
1540 </pre></blockquote>
1541
1542 <p>
1543 Add paragraph:
1544 </p>
1545
1546 <blockquote>
1547 <i>Returns:</i> an iterator which refers to the copy of the first inserted
1548 character, or <tt>p</tt> if <tt>n == 0</tt>.
1549 </blockquote>
1550
1551 <p>
1552 p15 21.4.6.4 [string::insert] change return type from <tt>void</tt> to <tt>iterator</tt>:
1553 </p>
1554
1555 <blockquote><pre>template&lt;class InputIterator&gt;
1556   <del>void</del> <ins>iterator</ins> insert(const_iterator p, InputIterator first, InputIterator last);
1557 </pre></blockquote>
1558
1559 <p>
1560 Add paragraph:
1561 </p>
1562
1563 <blockquote>
1564 <i>Returns:</i> an iterator which refers to the copy of the first inserted
1565 character, or <tt>p</tt> if <tt>first == last</tt>.
1566 </blockquote>
1567
1568 <p>
1569 p17 21.4.6.4 [string::insert] change return type from <tt>void</tt> to <tt>iterator</tt>:
1570 </p>
1571
1572 <blockquote><pre><del>void</del> <ins>iterator</ins> insert(const_iterator p, initializer_list&lt;charT&gt; il);
1573 </pre></blockquote>
1574
1575 <p>
1576 Add paragraph:
1577 </p>
1578
1579 <blockquote>
1580 <i>Returns:</i> an iterator which refers to the copy of the first inserted
1581 character, or <tt>p</tt> if <tt>il</tt> is empty.
1582 </blockquote>
1583
1584
1585
1586 <p><b>Rationale:</b></p>
1587
1588 <p><i>[
1589 The following was the C++98/03 rationale and does not necessarily apply to the
1590 proposed resolution in the C++0X time frame:
1591 ]</i></p>
1592
1593
1594 <blockquote>
1595 <p>The LWG believes this was an intentional design decision and so is
1596 not a defect. It may be worth revisiting for the next standard.</p>
1597 </blockquote>
1598
1599
1600
1601
1602 <hr>
1603 <h3><a name="299"></a>299. Incorrect return types for iterator dereference</h3>
1604 <p><b>Section:</b> 24.2.5 [bidirectional.iterators], 24.2.6 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
1605  <b>Submitter:</b> John Potter <b>Opened:</b> 2001-01-22  <b>Last modified:</b> 2009-07-28</p>
1606 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bidirectional.iterators">issues</a> in [bidirectional.iterators].</p>
1607 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
1608 <p><b>Discussion:</b></p>
1609 <p>
1610 In section 24.2.5 [bidirectional.iterators],
1611 Table 75 gives the return type of *r-- as convertible to T.  This is
1612 not consistent with Table 74 which gives the return type of *r++ as
1613 T&amp;.  *r++ = t is valid while *r-- = t is invalid.
1614 </p>
1615
1616 <p>
1617 In section 24.2.6 [random.access.iterators],
1618 Table 76 gives the return type of a[n] as convertible to T.  This is
1619 not consistent with the semantics of *(a + n) which returns T&amp; by
1620 Table 74.  *(a + n) = t is valid while a[n] = t is invalid.
1621 </p>
1622
1623 <p>
1624 Discussion from the Copenhagen meeting: the first part is
1625 uncontroversial.  The second part, operator[] for Random Access
1626 Iterators, requires more thought.  There are reasonable arguments on
1627 both sides.  Return by value from operator[] enables some potentially
1628 useful iterators, e.g. a random access "iota iterator" (a.k.a
1629 "counting iterator" or "int iterator").  There isn't any obvious way
1630 to do this with return-by-reference, since the reference would be to a
1631 temporary.  On the other hand, <tt>reverse_iterator</tt> takes an
1632 arbitrary Random Access Iterator as template argument, and its
1633 operator[] returns by reference.  If we decided that the return type
1634 in Table 76 was correct, we would have to change
1635 <tt>reverse_iterator</tt>.  This change would probably affect user
1636 code.
1637 </p>
1638
1639 <p>
1640 History: the contradiction between <tt>reverse_iterator</tt> and the
1641 Random Access Iterator requirements has been present from an early
1642 stage.  In both the STL proposal adopted by the committee
1643 (N0527==94-0140) and the STL technical report (HPL-95-11 (R.1), by
1644 Stepanov and Lee), the Random Access Iterator requirements say that
1645 operator[]'s return value is "convertible to T".  In N0527
1646 reverse_iterator's operator[] returns by value, but in HPL-95-11
1647 (R.1), and in the STL implementation that HP released to the public,
1648 reverse_iterator's operator[] returns by reference.  In 1995, the
1649 standard was amended to reflect the contents of HPL-95-11 (R.1).  The
1650 original intent for operator[] is unclear.
1651 </p>
1652
1653 <p>
1654 In the long term it may be desirable to add more fine-grained
1655 iterator requirements, so that access method and traversal strategy
1656 can be decoupled.  (See "Improved Iterator Categories and
1657 Requirements", N1297 = 01-0011, by Jeremy Siek.)  Any decisions
1658 about issue 299 should keep this possibility in mind.
1659 </p>
1660
1661 <p>Further discussion: I propose a compromise between John Potter's
1662 resolution, which requires <tt>T&amp;</tt> as the return type of
1663 <tt>a[n]</tt>, and the current wording, which requires convertible to
1664 <tt>T</tt>. The compromise is to keep the convertible to <tt>T</tt>
1665 for the return type of the expression <tt>a[n]</tt>, but to also add
1666 <tt>a[n] = t</tt> as a valid expression. This compromise "saves" the
1667 common case uses of random access iterators, while at the same time
1668 allowing iterators such as counting iterator and caching file
1669 iterators to remain random access iterators (iterators where the
1670 lifetime of the object returned by <tt>operator*()</tt> is tied to the
1671 lifetime of the iterator).
1672 </p>
1673
1674 <p>
1675 Note that the compromise resolution necessitates a change to
1676 <tt>reverse_iterator</tt>. It would need to use a proxy to support
1677 <tt>a[n] = t</tt>.
1678 </p>
1679
1680 <p>
1681 Note also there is one kind of mutable random access iterator that
1682 will no longer meet the new requirements. Currently, iterators that
1683 return an r-value from <tt>operator[]</tt> meet the requirements for a
1684 mutable random access iterartor, even though the expression <tt>a[n] =
1685 t</tt> will only modify a temporary that goes away. With this proposed
1686 resolution, <tt>a[n] = t</tt> will be required to have the same
1687 operational semantics as <tt>*(a + n) = t</tt>.
1688 </p>
1689
1690 <p><i>[
1691 2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
1692 ]</i></p>
1693
1694
1695
1696
1697 <p><b>Proposed resolution:</b></p>
1698
1699 <p>
1700 In section 24.1.4 [lib.bidirectdional.iterators], change the return
1701 type in table 75 from "convertible to <tt>T</tt>" to
1702 <tt>T&amp;</tt>.
1703 </p>
1704
1705 <p>
1706 In section 24.1.5 [lib.random.access.iterators], change the
1707 operational semantics for <tt>a[n]</tt> to " the r-value of
1708 <tt>a[n]</tt> is equivalent to the r-value of <tt>*(a +
1709 n)</tt>". Add a new row in the table for the expression <tt>a[n] = t</tt>
1710 with a return type of convertible to <tt>T</tt> and operational semantics of
1711 <tt>*(a + n) = t</tt>.
1712 </p>
1713
1714 <p><i>[Lillehammer: Real problem, but should be addressed as part of
1715   iterator redesign]</i></p>
1716
1717
1718
1719
1720 <p><b>Rationale:</b></p>
1721 <p><i>[
1722 San Francisco:
1723 ]</i></p>
1724
1725
1726 <blockquote>
1727 Solved by
1728 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/N2758.pdf">N2758</a>.
1729 </blockquote>
1730
1731
1732
1733
1734
1735
1736
1737 <hr>
1738 <h3><a name="397"></a>397. ostream::sentry dtor throws exceptions</h3>
1739 <p><b>Section:</b> 27.7.2.4 [ostream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
1740  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-01-05  <b>Last modified:</b> 2009-07-14</p>
1741 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream::sentry">issues</a> in [ostream::sentry].</p>
1742 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
1743 <p><b>Discussion:</b></p>
1744     <p>
1745 17.4.4.8, p3 prohibits library dtors from throwing exceptions.
1746     </p>
1747     <p>
1748 27.6.2.3, p4 says this about the ostream::sentry dtor:
1749     </p>
1750     <pre>    -4- If ((os.flags() &amp; ios_base::unitbuf) &amp;&amp; !uncaught_exception())
1751         is true, calls os.flush().
1752     </pre>
1753     <p>
1754 27.6.2.6, p7 that describes ostream::flush() says:
1755     </p>
1756     <pre>    -7- If rdbuf() is not a null pointer, calls rdbuf()-&gt;pubsync().
1757         If that function returns ?-1 calls setstate(badbit) (which
1758         may throw ios_base::failure (27.4.4.3)).
1759     </pre>
1760     <p>
1761 That seems like a defect, since both pubsync() and setstate() can
1762 throw an exception.
1763     </p>
1764 <p><i>[
1765 The contradiction is real.  Clause 17 says destructors may never
1766 throw exceptions, and clause 27 specifies a destructor that does
1767 throw.  In principle we might change either one.  We're leaning
1768 toward changing clause 17: putting in an "unless otherwise specified"
1769 clause, and then putting in a footnote saying the sentry destructor
1770 is the only one that can throw.  PJP suggests specifying that
1771 sentry::~sentry() should internally catch any exceptions it might cause.
1772 ]</i></p>
1773
1774
1775 <p><i>[
1776 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#418">418</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a> for related issues.
1777 ]</i></p>
1778
1779
1780 <p><i>[
1781 2009-07 Frankfurt
1782 ]</i></p>
1783
1784
1785 <blockquote>
1786 <p>
1787 Move to Review. Add "Throws: nothing" to the specification of ostream::sentry::~sentry().
1788 </p>
1789 </blockquote>
1790
1791
1792
1793 <p><b>Proposed resolution:</b></p>
1794 <p>
1795 Add after 27.7.2.4 [ostream::sentry] p17:
1796 </p>
1797
1798 <blockquote>
1799 <pre>~sentry();
1800 </pre>
1801 <blockquote>
1802 <p>
1803 -17- If <tt>((os.flags() &amp; ios_base::unitbuf) &amp;&amp; !uncaught_exception())</tt>
1804 is <tt>true</tt>, calls <tt>os.flush()</tt>.
1805 </p>
1806
1807 <p><ins>
1808 <i>Throws:</i> Nothing.
1809 </ins></p>
1810 </blockquote>
1811 </blockquote>
1812
1813
1814
1815
1816
1817 <hr>
1818 <h3><a name="408"></a>408. Is vector&lt;reverse_iterator&lt;char*&gt; &gt; forbidden?</h3>
1819 <p><b>Section:</b> 24.2 [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
1820  <b>Submitter:</b> Nathan Myers <b>Opened:</b> 2003-06-03  <b>Last modified:</b> 2009-07-31</p>
1821 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.concepts">active issues</a> in [iterator.concepts].</p>
1822 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.concepts">issues</a> in [iterator.concepts].</p>
1823 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
1824 <p><b>Discussion:</b></p>
1825 <p>
1826 I've been discussing iterator semantics with Dave Abrahams, and a
1827 surprise has popped up.  I don't think this has been discussed before.
1828 </p>
1829
1830 <p>
1831 24.2 [iterator.concepts] says that the only operation that can be performed on "singular"
1832 iterator values is to assign a non-singular value to them.  (It
1833 doesn't say they can be destroyed, and that's probably a defect.)
1834 Some implementations have taken this to imply that there is no need
1835 to initialize the data member of a reverse_iterator&lt;&gt; in the default
1836 constructor.  As a result, code like
1837 </p>
1838 <blockquote><pre>  std::vector&lt;std::reverse_iterator&lt;char*&gt; &gt; v(7);
1839   v.reserve(1000);
1840 </pre></blockquote>
1841 <p>
1842 invokes undefined behavior, because it must default-initialize the
1843 vector elements, and then copy them to other storage.  Of course many
1844 other vector operations on these adapters are also left undefined,
1845 and which those are is not reliably deducible from the standard.
1846 </p>
1847
1848 <p>
1849 I don't think that 24.1 was meant to make standard-library iterator
1850 types unsafe.  Rather, it was meant to restrict what operations may
1851 be performed by functions which take general user- and standard
1852 iterators as arguments, so that raw pointers would qualify as
1853 iterators.  However, this is not clear in the text, others have come
1854 to the opposite conclusion.
1855 </p>
1856
1857 <p>
1858 One question is whether the standard iterator adaptors have defined
1859 copy semantics.  Another is whether they have defined destructor
1860 semantics: is
1861 </p>
1862 <blockquote><pre>  { std::vector&lt;std::reverse_iterator&lt;char*&gt; &gt;  v(7); }
1863 </pre></blockquote>
1864 <p>
1865 undefined too?
1866 </p>
1867
1868 <p>
1869 Note this is not a question of whether algorithms are allowed to
1870 rely on copy semantics for arbitrary iterators, just whether the
1871 types we actually supply support those operations.  I believe the
1872 resolution must be expressed in terms of the semantics of the
1873 adapter's argument type.  It should make clear that, e.g., the
1874 reverse_iterator&lt;T&gt; constructor is actually required to execute
1875 T(), and so copying is defined if the result of T() is copyable.
1876 </p>
1877
1878 <p>
1879 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, which defines reverse_iterator's default
1880 constructor more precisely, has some relevance to this issue.
1881 However, it is not the whole story.
1882 </p>
1883
1884 <p>
1885 The issue was whether
1886 </p>
1887 <blockquote><pre>  reverse_iterator() { }
1888 </pre></blockquote>
1889 <p>
1890 is allowed, vs.
1891 </p>
1892 <blockquote><pre>  reverse_iterator() : current() { }
1893 </pre></blockquote>
1894
1895 <p>
1896 The difference is when T is char*, where the first leaves the member
1897 uninitialized, and possibly equal to an existing pointer value, or
1898 (on some targets) may result in a hardware trap when copied.
1899 </p>
1900
1901 <p>
1902 8.5 paragraph 5 seems to make clear that the second is required to
1903 satisfy DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, at least for non-class Iterator argument
1904 types.
1905 </p>
1906
1907 <p>
1908 But that only takes care of reverse_iterator, and doesn't establish
1909 a policy for all iterators.  (The reverse iterator adapter was just
1910 an example.)  In particular, does my function
1911 </p>
1912 <blockquote><pre>  template &lt;typename Iterator&gt;
1913     void f() { std::vector&lt;Iterator&gt;  v(7); }
1914 </pre></blockquote>
1915 <p>
1916 evoke undefined behavior for some conforming iterator definitions?
1917 I think it does, now, because vector&lt;&gt; will destroy those singular
1918 iterator values, and that's explicitly disallowed.
1919 </p>
1920
1921 <p>
1922 24.1 shouldn't give blanket permission to copy all singular iterators,
1923 because then pointers wouldn't qualify as iterators.  However, it
1924 should allow copying of that subset of singular iterator values that
1925 are default-initialized, and it should explicitly allow destroying any
1926 iterator value, singular or not, default-initialized or not.
1927 </p>
1928
1929 <p>Related issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#407">407</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a></p>
1930 <p><i>[
1931 We don't want to require all singular iterators to be copyable,
1932 because that is not the case for pointers.  However, default
1933 construction may be a special case.  Issue: is it really default
1934 construction we want to talk about, or is it something like value
1935 initialization?  We need to check with core to see whether default
1936 constructed pointers are required to be copyable; if not, it would be
1937 wrong to impose so strict a requirement for iterators.
1938 ]</i></p>
1939
1940
1941 <p><i>[
1942 2009-05-10 Alisdair provided wording.
1943 ]</i></p>
1944
1945
1946 <blockquote>
1947 The comments regarding destroying singular iterators have already been
1948 resolved.  That just leaves copying (with moving implied).
1949 </blockquote>
1950
1951 <p><i>[
1952 2009-07 Frankfurt
1953 ]</i></p>
1954
1955
1956 <blockquote>
1957 <p>
1958 This is related to LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a>.
1959 </p>
1960 <p>
1961 Note that there is a bug in the proposed resolution to LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a>. The
1962 change to  [reverse.iter.con] should be modified so that the word
1963 "default" in the second sentence of the Effects clause is replaced by
1964 "value."
1965 </p>
1966 <p>
1967 We believe that the proposed fix to LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a> (now corrected) is
1968 sufficient to solve the problem for reverse_iterator. However, Alisdair
1969 pointed out that LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a> does not solve the general problem for authors
1970 of iterator adaptors.
1971 </p>
1972 <p>
1973 There are some problems with the proposed resolution. The phrase "safely
1974 copyable" is not a term of art. Also, it mentions a
1975 DefaultConstructible? concept.
1976 </p>
1977 <p>
1978 Move to Review after Alisdair updates the wording.
1979 </p>
1980 </blockquote>
1981
1982 <p><i>[
1983 2009-07-31 Alisdair revised wording:
1984 ]</i></p>
1985
1986
1987
1988
1989 <p><b>Proposed resolution:</b></p>
1990 <p>
1991 Add a new paragrpah to Iterator concepts 24.2 [iterator.concepts] after para 5 (the one
1992 describing singular iterators)
1993 </p>
1994 <blockquote>
1995 <p>
1996 Just as a regular pointer to an array guarantees that there is a pointer
1997 value pointing past the last element of the array, so for any iterator
1998 type there is an iterator value that points past the last element of a
1999 corresponding container. These values are called <i>past-the-end</i> values.
2000 Values of an iterator <tt>i</tt> for which the expression <tt>*i</tt> is defined are called
2001 <i>dereferenceable</i>. The library never assumes that past-the-end values are
2002 dereferenceable. Iterators can also have singular values that are not
2003 associated with any container. [<i>Example:</i> After the declaration of an
2004 uninitialized pointer <tt>x</tt> (as with <tt>int* x;</tt>), <tt>x</tt> must always be assumed to
2005 have a singular value of a pointer. &#8212; <i>end example</i>] Results of most
2006 expressions are undefined for singular values; the only exceptions are
2007 destroying an iterator that holds a singular value and the assignment of
2008 a non-singular value to an iterator that holds a singular value. In this
2009 case the singular value is overwritten the same way as any other value.
2010 Dereferenceable values are always non-singular.
2011 </p>
2012 <p><ins>
2013 After value-initialization, any iterator that satisfies the
2014 <tt>DefaultConstructible</tt> concept shall not introduce undefined behaviour
2015 when used the source of a copy or move operation, even if it would
2016 otherwise be singular. [<i>Note:</i> This guarantee is not offered for
2017 default-initialization (8.5 [dcl.init]), although the distinction only
2018 matters for types with trivial default constructors such as pointers. &#8212;
2019 <i>end note</i>]
2020 </ins></p>
2021
2022
2023 </blockquote>
2024
2025
2026
2027
2028
2029
2030 <hr>
2031 <h3><a name="419"></a>419. istream extractors not setting failbit if eofbit is already set</h3>
2032 <p><b>Section:</b> 27.7.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
2033  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18  <b>Last modified:</b> 2009-07-14</p>
2034 <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>
2035 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
2036 <p><b>Discussion:</b></p>
2037         <p>
2038
2039 27.7.1.1.3 [istream::sentry], p2 says that istream::sentry ctor prepares for input if is.good()
2040 is true. p4 then goes on to say that the ctor sets the sentry::ok_ member to
2041 true if the stream state is good after any preparation. 27.7.1.2.1 [istream.formatted.reqmts], p1 then
2042 says that a formatted input function endeavors to obtain the requested input
2043 if the sentry's operator bool() returns true.
2044
2045 Given these requirements, no formatted extractor should ever set failbit if
2046 the initial stream rdstate() == eofbit. That is contrary to the behavior of
2047 all implementations I tested. The program below prints out
2048
2049 eof = 1, fail = 0
2050 eof = 1, fail = 1
2051
2052 on all of them.
2053         </p>
2054 <pre>
2055 #include &lt;sstream&gt;
2056 #include &lt;cstdio&gt;
2057
2058 int main()
2059 {
2060     std::istringstream strm ("1");
2061
2062     int i = 0;
2063
2064     strm &gt;&gt; i;
2065
2066     std::printf ("eof = %d, fail = %d\n",
2067                  !!strm.eof (), !!strm.fail ());
2068
2069     strm &gt;&gt; i;
2070
2071     std::printf ("eof = %d, fail = %d\n",
2072                  !!strm.eof (), !!strm.fail ());
2073 }
2074
2075 </pre>
2076         <p>
2077 <br>
2078
2079 Comments from Jerry Schwarz (c++std-lib-11373):
2080 <br>
2081
2082 Jerry Schwarz wrote:
2083 <br>
2084
2085 I don't know where (if anywhere) it says it in the standard, but the
2086 formatted extractors are supposed to set failbit if they don't extract
2087 any characters. If they didn't then simple loops like
2088 <br>
2089
2090 while (cin &gt;&gt; x);
2091 <br>
2092
2093 would loop forever.
2094 <br>
2095
2096 Further comments from Martin Sebor:
2097 <br>
2098
2099 The question is which part of the extraction should prevent this from happening
2100 by setting failbit when eofbit is already set. It could either be the sentry
2101 object or the extractor. It seems that most implementations have chosen to
2102 set failbit in the sentry [...] so that's the text that will need to be
2103 corrected.
2104
2105         </p>
2106 <p>
2107 Pre Berlin:  This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#342">342</a>.  If the sentry
2108 sets <tt>failbit</tt> when it finds <tt>eofbit</tt> already set, then
2109 you can never seek away from the end of stream.
2110 </p>
2111 <p>Kona: Possibly NAD.  If eofbit is set then good() will return false.  We
2112   then set <i>ok</i> to false.  We believe that the sentry's
2113   constructor should always set failbit when <i>ok</i> is false, and
2114   we also think the standard already says that.  Possibly it could be
2115   clearer.</p>
2116
2117
2118 <p><i>[
2119 2009-07 Frankfurt
2120 ]</i></p>
2121
2122
2123 <blockquote>
2124 Moved to Ready.
2125 </blockquote>
2126
2127
2128
2129 <p><b>Proposed resolution:</b></p>
2130 <p>
2131 Change 27.7.1.1.3 [istream::sentry], p2 to:
2132 </p>
2133
2134 <blockquote>
2135 <pre>explicit sentry(basic_istream&lt;charT,traits&gt;&amp; <i>is</i> , bool <i>noskipws</i> = false);</pre>
2136 <p>
2137 -2- <i>Effects:</i> If <tt>is.good()</tt> is <del><tt>true</tt></del>
2138 <ins><tt>false</tt></ins>, <ins>calls <tt>is.setstate(failbit)</tt>.
2139 Otherwise</ins> prepares for formatted or unformatted input. ...
2140 </p>
2141 </blockquote>
2142
2143
2144
2145
2146
2147
2148 <hr>
2149 <h3><a name="427"></a>427. stage 2 and rationale of DR 221</h3>
2150 <p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
2151  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18  <b>Last modified:</b> 2009-07-14</p>
2152 <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>
2153 <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>
2154 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
2155 <p><b>Discussion:</b></p>
2156 <p>
2157 The requirements specified in Stage 2 and reiterated in the rationale
2158 of DR 221 (and echoed again in DR 303) specify that num_get&lt;charT&gt;::
2159 do_get() compares characters on the stream against the widened elements
2160 of "012...abc...ABCX+-"
2161 </p>
2162
2163 <p>
2164 An implementation is required to allow programs to instantiate the num_get
2165 template on any charT that satisfies the requirements on a user-defined
2166 character type. These requirements do not include the ability of the
2167 character type to be equality comparable (the char_traits template must
2168 be used to perform tests for equality). Hence, the num_get template cannot
2169 be implemented to support any arbitrary character type. The num_get template
2170 must either make the assumption that the character type is equality-comparable
2171 (as some popular implementations do), or it may use char_traits&lt;charT&gt; to do
2172 the comparisons (some other popular implementations do that). This diversity
2173 of approaches makes it difficult to write portable programs that attempt to
2174 instantiate the num_get template on user-defined types.
2175 </p>
2176
2177 <p><i>[Kona: the heart of the problem is that we're theoretically
2178   supposed to use traits classes for all fundamental character
2179   operations like assignment and comparison, but facets don't have
2180   traits parameters.  This is a fundamental design flaw and it
2181   appears all over the place, not just in this one place.  It's not
2182   clear what the correct solution is, but a thorough review of facets
2183   and traits is in order.  The LWG considered and rejected the
2184   possibility of changing numeric facets to use narrowing instead of
2185   widening.  This may be a good idea for other reasons (see issue
2186   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#459">459</a>), but it doesn't solve the problem raised by this
2187   issue.  Whether we use widen or narrow the <tt>num_get</tt> facet
2188   still has no idea which traits class the user wants to use for
2189   the comparison, because only streams, not facets, are passed traits
2190   classes.   The standard does not require that two different
2191   traits classes with the same <tt>char_type</tt> must necessarily
2192   have the same behavior.]</i></p>
2193
2194
2195 <p>Informally, one possibility: require that some of the basic
2196 character operations, such as <tt>eq</tt>, <tt>lt</tt>,
2197 and <tt>assign</tt>, must behave the same way for all traits classes
2198 with the same <tt>char_type</tt>.  If we accept that limitation on
2199 traits classes, then the facet could reasonably be required to
2200 use <tt>char_traits&lt;charT&gt;</tt>.</p>
2201
2202 <p><i>[
2203 2009-07 Frankfurt
2204 ]</i></p>
2205
2206
2207 <blockquote>
2208 <p>
2209 There was general agreement that the standard only needs to specify the
2210 behavior when the character type is char or wchar_t.
2211 </p>
2212 <p>
2213 Beman: we don't need to worry about C++1x because there is a non-zero
2214 possibility that we would have a replacement facility for iostreams that
2215 would solve these problems.
2216 </p>
2217 <p>
2218 We need to change the following sentence in [locale.category], paragraph
2219 6 to specify that C is char and wchar_t:
2220 </p>
2221 <p>
2222 "A template formal parameter with name C represents the set of all
2223 possible specializations on a parameter that satisfies the requirements
2224 for a character on which any member of the iostream components can be
2225 instantiated."
2226 </p>
2227 <p>
2228 We also need to specify in 27 that the basic character operations, such
2229 as eq, lt, and assign use std::char_traits.
2230 </p>
2231 <p>
2232 Daniel volunteered to provide wording.
2233 </p>
2234 </blockquote>
2235
2236
2237
2238 <p><b>Proposed resolution:</b></p>
2239
2240
2241
2242
2243 <hr>
2244 <h3><a name="430"></a>430. valarray subset operations</h3>
2245 <p><b>Section:</b> 26.6.2.4 [valarray.sub] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
2246  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18  <b>Last modified:</b> 2009-07-14</p>
2247 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
2248 <p><b>Discussion:</b></p>
2249 <p>
2250 The standard fails to specify the behavior of valarray::operator[](slice)
2251 and other valarray subset operations when they are passed an "invalid"
2252 slice object, i.e., either a slice that doesn't make sense at all (e.g.,
2253 slice (0, 1, 0) or one that doesn't specify a valid subset of the valarray
2254 object (e.g., slice (2, 1, 1) for a valarray of size 1).
2255 </p>
2256 <p><i>[Kona: the LWG believes that invalid slices should invoke
2257   undefined behavior.  Valarrays are supposed to be designed for high
2258   performance, so we don't want to require specific checking.  We
2259   need wording to express this decision.]</i></p>
2260
2261
2262 <p><i>[
2263 Bellevue:
2264 ]</i></p>
2265
2266
2267 <blockquote>
2268 Please note that the standard also fails to specify the behavior of
2269 slice_array and gslice_array in the valid case. Bill Plauger will
2270 endeavor to provide revised wording for slice_array and gslice_array.
2271 </blockquote>
2272
2273 <p><i>[
2274 post-Bellevue:  Bill provided wording.
2275 ]</i></p>
2276
2277
2278 <p><i>[
2279 2009-07 Frankfurt
2280 ]</i></p>
2281
2282
2283 <blockquote>
2284 <p>
2285 Move to Ready.
2286 </p>
2287 </blockquote>
2288
2289
2290
2291 <p><b>Proposed resolution:</b></p>
2292 <p>
2293 Insert after 26.6.2.4 [valarray.sub], paragraph 1:
2294 </p>
2295
2296 <blockquote>
2297 <p>
2298 The member operator is overloaded to provide several ways to select
2299 sequences
2300 of elements from among those controlled by <tt>*this</tt>. The first group of five
2301 member operators work in conjunction with various overloads of <tt>operator=</tt>
2302 (and other assigning operators) to allow selective replacement (slicing) of
2303 the controlled sequence. The selected elements must exist.
2304 </p>
2305 <p>
2306 The first member operator selects element off. For example:
2307 </p>
2308
2309 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
2310 v0[3] = 'A';
2311 // v0 == valarray&lt;char&gt;("abcAefghijklmnop", 16)
2312 </pre></blockquote>
2313
2314 <p>
2315 The second member operator selects those elements of the controlled sequence
2316 designated by <tt>slicearr</tt>. For example:
2317 </p>
2318
2319 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
2320 valarray&lt;char&gt; v1("ABCDE", 5);
2321 v0[slice(2, 5, 3)] = v1;
2322 // v0 == valarray&lt;char&gt;("abAdeBghCjkDmnEp", 16)
2323 </pre></blockquote>
2324
2325 <p>
2326 The third member operator selects those elements of the controlled sequence
2327 designated by <tt>gslicearr</tt>. For example:
2328 </p>
2329
2330 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
2331 valarray&lt;char&gt; v1("ABCDEF", 6);
2332 const size_t lv[] = {2, 3};
2333 const size_t dv[] = {7, 2};
2334 const valarray&lt;size_t&gt; len(lv, 2), str(dv, 2);
2335 v0[gslice(3, len, str)] = v1;
2336 // v0 == valarray&lt;char&gt;("abcAeBgCijDlEnFp", 16)
2337 </pre></blockquote>
2338
2339 <p>
2340 The fourth member operator selects those elements of the controlled sequence
2341 designated by <tt>boolarr</tt>. For example:
2342 </p>
2343
2344 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
2345 valarray&lt;char&gt; v1("ABC", 3);
2346 const bool vb[] = {false, false, true, true, false, true};
2347 v0[valarray&lt;bool&gt;(vb, 6)] = v1;
2348 // v0 == valarray&lt;char&gt;("abABeCghijklmnop", 16)
2349 </pre></blockquote>
2350
2351 <p>
2352 The fifth member operator selects those elements of the controlled sequence
2353 designated by indarr. For example:
2354 </p>
2355
2356 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
2357 valarray&lt;char&gt; v1("ABCDE", 5);
2358 const size_t vi[] = {7, 5, 2, 3, 8};
2359 v0[valarray&lt;size_t&gt;(vi, 5)] = v1;
2360 // v0 == valarray&lt;char&gt;("abCDeBgAEjklmnop", 16)
2361 </pre></blockquote>
2362
2363 <p>
2364 The second group of five member operators each construct an object that
2365 represents the value(s) selected. The selected elements must exist.
2366 </p>
2367
2368 <p>
2369 The sixth member operator returns the value of element off. For example:
2370 </p>
2371
2372 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
2373 // v0[3] returns 'd'
2374 </pre></blockquote>
2375
2376 <p>
2377 The seventh member operator returns an object of class <tt>valarray&lt;Ty&gt;</tt>
2378 containing those elements of the controlled sequence designated by <tt>slicearr</tt>.
2379 For example:
2380 </p>
2381
2382 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
2383 // v0[slice(2, 5, 3)] returns valarray&lt;char&gt;("cfilo", 5)
2384 </pre></blockquote>
2385
2386 <p>
2387 The eighth member operator selects those elements of the controlled sequence
2388 designated by <tt>gslicearr</tt>. For example:
2389 </p>
2390
2391 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
2392 const size_t lv[] = {2, 3};
2393 const size_t dv[] = {7, 2};
2394 const valarray&lt;size_t&gt; len(lv, 2), str(dv, 2);
2395 // v0[gslice(3, len, str)] returns
2396 //    valarray&lt;char&gt;("dfhkmo", 6)
2397 </pre></blockquote>
2398
2399 <p>
2400 The ninth member operator selects those elements of the controlled sequence
2401 designated by <tt>boolarr</tt>. For example:
2402 </p>
2403
2404 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
2405 const bool vb[] = {false, false, true, true, false, true};
2406 // v0[valarray&lt;bool&gt;(vb, 6)] returns
2407 //    valarray&lt;char&gt;("cdf", 3)
2408 </pre></blockquote>
2409
2410 <p>
2411 The last member operator selects those elements of the controlled sequence
2412 designated by <tt>indarr</tt>. For example:
2413 </p>
2414
2415 <blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
2416 const size_t vi[] = {7, 5, 2, 3, 8};
2417 // v0[valarray&lt;size_t&gt;(vi, 5)] returns
2418 //    valarray&lt;char&gt;("hfcdi", 5)
2419 </pre></blockquote>
2420
2421 </blockquote>
2422
2423
2424
2425
2426
2427 <hr>
2428 <h3><a name="431"></a>431. Swapping containers with unequal allocators</h3>
2429 <p><b>Section:</b> X [allocator.requirements], 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
2430  <b>Submitter:</b> Matt Austern <b>Opened:</b> 2003-09-20  <b>Last modified:</b> 2009-07-17</p>
2431 <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>
2432 <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>
2433 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
2434 <p><b>Discussion:</b></p>
2435 <p>Clause X [allocator.requirements] paragraph 4 says that implementations
2436   are permitted to supply containers that are unable to cope with
2437   allocator instances and that container implementations may assume
2438   that all instances of an allocator type compare equal.  We gave
2439   implementers this latitude as a temporary hack, and eventually we
2440   want to get rid of it.  What happens when we're dealing with
2441   allocators that <i>don't</i> compare equal?
2442 </p>
2443
2444 <p>In particular: suppose that <tt>v1</tt> and <tt>v2</tt> are both
2445   objects of type <tt>vector&lt;int, my_alloc&gt;</tt> and that
2446   <tt>v1.get_allocator() != v2.get_allocator()</tt>.  What happens if
2447   we write <tt>v1.swap(v2)</tt>?  Informally, three possibilities:</p>
2448
2449 <p>1. This operation is illegal.  Perhaps we could say that an
2450   implementation is required to check and to throw an exception, or
2451   perhaps we could say it's undefined behavior.</p>
2452 <p>2. The operation performs a slow swap (i.e. using three
2453   invocations of <tt>operator=</tt>, leaving each allocator with its
2454   original container.  This would be an O(N) operation.</p>
2455 <p>3. The operation swaps both the vectors' contents and their
2456   allocators.  This would be an O(1) operation. That is:</p>
2457   <blockquote>
2458   <pre>    my_alloc a1(...);
2459     my_alloc a2(...);
2460     assert(a1 != a2);
2461
2462     vector&lt;int, my_alloc&gt; v1(a1);
2463     vector&lt;int, my_alloc&gt; v2(a2);
2464     assert(a1 == v1.get_allocator());
2465     assert(a2 == v2.get_allocator());
2466
2467     v1.swap(v2);
2468     assert(a1 == v2.get_allocator());
2469     assert(a2 == v1.get_allocator());
2470   </pre>
2471   </blockquote>
2472
2473 <p><i>[Kona: This is part of a general problem.  We need a paper
2474   saying how to deal with unequal allocators in general.]</i></p>
2475
2476
2477 <p><i>[pre-Sydney: Howard argues for option 3 in
2478 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1599.html">N1599</a>.
2479 ]</i></p>
2480
2481
2482 <p><i>[
2483 2007-01-12, Howard:  This issue will now tend to come up more often with move constructors
2484 and move assignment operators.  For containers, these members transfer resources (i.e.
2485 the allocated memory) just like swap.
2486 ]</i></p>
2487
2488
2489 <p><i>[
2490 Batavia:  There is agreement to overload the container <tt>swap</tt> on the allocator's Swappable
2491 requirement using concepts.  If the allocator supports Swappable, then container's swap will
2492 swap allocators, else it will perform a "slow swap" using copy construction and copy assignment.
2493 ]</i></p>
2494
2495
2496 <p><i>[
2497 2009-04-28 Pablo adds:
2498 ]</i></p>
2499
2500 <blockquote>
2501 Fixed in
2502 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>.
2503 I argued for marking this Tentatively-Ready right after Bellevue,
2504 but there was a concern that
2505 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>
2506 would break in the presence of the RVO. (That breakage had nothing to do with
2507 swap, but never-the-less). I addressed that breakage in in
2508 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">N2840</a>
2509 (Summit) by means of a non-normative reference:
2510
2511 <blockquote>
2512 [<i>Note:</i> in situations where the copy constructor for a container is elided,
2513 this function is not called. The behavior in these cases is as if
2514 <tt>select_on_container_copy_construction</tt> returned <tt>x</tt> &#8212; <i>end note</i>]
2515 </blockquote>
2516
2517 </blockquote>
2518
2519
2520
2521 <p><b>Proposed resolution:</b></p>
2522
2523
2524
2525
2526
2527 <hr>
2528 <h3><a name="446"></a>446. Iterator equality between different containers</h3>
2529 <p><b>Section:</b> 24.2 [iterator.concepts], 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
2530  <b>Submitter:</b> Andy Koenig <b>Opened:</b> 2003-12-16  <b>Last modified:</b> 2009-07-14</p>
2531 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.concepts">active issues</a> in [iterator.concepts].</p>
2532 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.concepts">issues</a> in [iterator.concepts].</p>
2533 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
2534 <p><b>Discussion:</b></p>
2535 <p>
2536 What requirements does the standard place on equality comparisons between
2537 iterators that refer to elements of different containers.  For example, if
2538 v1 and v2 are empty vectors, is v1.end() == v2.end() allowed to yield true?
2539 Is it allowed to throw an exception?
2540 </p>
2541
2542 <p>
2543 The standard appears to be silent on both questions.
2544 </p>
2545 <p><i>[Sydney: The intention is that comparing two iterators from
2546 different containers is undefined, but it's not clear if we say that,
2547 or even whether it's something we should be saying in clause 23 or in
2548 clause 24.  Intuitively we might want to say that equality is defined
2549 only if one iterator is reachable from another, but figuring out how
2550 to say it in any sensible way is a bit tricky: reachability is defined
2551 in terms of equality, so we can't also define equality in terms of
2552 reachability.
2553 ]</i></p>
2554
2555
2556 <p><i>[
2557 2009-07 Frankfurt
2558 ]</i></p>
2559
2560
2561 <blockquote>
2562 Daniel volunteered to work on this.
2563 </blockquote>
2564
2565
2566
2567 <p><b>Proposed resolution:</b></p>
2568
2569
2570
2571
2572
2573
2574 <hr>
2575 <h3><a name="458"></a>458. 24.1.5 contains unintended limitation for operator-</h3>
2576 <p><b>Section:</b> 24.2.6 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
2577  <b>Submitter:</b> Daniel Frey <b>Opened:</b> 2004-02-27  <b>Last modified:</b> 2009-07-17</p>
2578 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#random.access.iterators">active issues</a> in [random.access.iterators].</p>
2579 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#random.access.iterators">issues</a> in [random.access.iterators].</p>
2580 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
2581 <p><b>Discussion:</b></p>
2582 <p>
2583 In 24.1.5 [lib.random.access.iterators], table 76 the operational
2584 semantics for the expression "r -= n" are defined as "return r += -n".
2585 This means, that the expression -n must be valid, which is not the case
2586 for unsigned types.
2587 </p>
2588
2589 <p><i>[
2590 Sydney: Possibly not a real problem, since difference type is required
2591 to be a signed integer type. However, the wording in the standard may
2592 be less clear than we would like.
2593 ]</i></p>
2594
2595
2596 <p><i>[
2597 Post Summit Alisdair adds:
2598 ]</i></p>
2599
2600
2601 <blockquote>
2602 <p>
2603 This issue refers to a requirements table we have removed.
2604 </p>
2605 <p>
2606 The issue might now relate to 24.2.6 [random.access.iterators] p5.
2607 However, the rationale in the issue already recognises that the
2608 <tt>difference_type</tt> must be signed, so this really looks NAD.
2609 </p>
2610 </blockquote>
2611
2612 <p><i>[
2613 Batavia (2009-05):
2614 ]</i></p>
2615
2616 <blockquote>
2617 <p>
2618 We agree with Alisdair's observations.
2619 </p>
2620 <p>
2621 Move to NAD.
2622 </p>
2623 </blockquote>
2624
2625 <p><i>[
2626 2009-07 Frankfurt:
2627 ]</i></p>
2628
2629
2630 <blockquote>
2631 <p>
2632 Need to look at again without concepts.
2633 </p>
2634 <p>
2635 There was a question about this phrase in the discussion: "the
2636 expression -n must be valid, which is not the case for unsigned types."
2637 If n is an object ofthe iterator difference_type (eg ptrdiff_t), then it
2638 is never unsigned.
2639 </p>
2640 </blockquote>
2641
2642
2643
2644 <p><b>Proposed resolution:</b></p>
2645 <p>
2646 To remove this limitation, I suggest to change the
2647 operational semantics for this column to:
2648 </p>
2649 <blockquote><pre>    { Distance m = n;
2650       if (m &gt;= 0)
2651         while (m--) --r;
2652       else
2653         while (m++) ++r;
2654       return r; }
2655 </pre></blockquote>
2656
2657
2658
2659
2660
2661
2662 <hr>
2663 <h3><a name="463"></a>463. auto_ptr usability issues</h3>
2664 <p><b>Section:</b> D.9.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
2665  <b>Submitter:</b> Rani Sharoni <b>Opened:</b> 2003-12-07  <b>Last modified:</b> 2009-07-14</p>
2666 <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>
2667 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
2668 <p><b>Discussion:</b></p>
2669
2670 <p>
2671 TC1 CWG DR #84 effectively made the template&lt;class Y&gt; operator auto_ptr&lt;Y&gt;()
2672 member of auto_ptr (20.4.5.3/4) obsolete.
2673 </p>
2674
2675 <p>
2676 The sole purpose of this obsolete conversion member is to enable copy
2677 initialization base from r-value derived (or any convertible types like
2678 cv-types) case:
2679 </p>
2680 <pre>#include &lt;memory&gt;
2681 using std::auto_ptr;
2682
2683 struct B {};
2684 struct D : B {};
2685
2686 auto_ptr&lt;D&gt; source();
2687 int sink(auto_ptr&lt;B&gt;);
2688 int x1 = sink( source() ); // #1 EDG - no suitable copy constructor
2689 </pre>
2690
2691 <p>
2692 The excellent analysis of conversion operations that was given in the final
2693 auto_ptr proposal
2694 (http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/1997/N1128.pdf)
2695 explicitly specifies this case analysis (case 4). DR #84 makes the analysis
2696 wrong and actually comes to forbid the loophole that was exploited by the
2697 auto_ptr designers.
2698 </p>
2699
2700 <p>
2701 I didn't encounter any compliant compiler (e.g. EDG, GCC, BCC and VC) that
2702 ever allowed this case. This is probably because it requires 3 user defined
2703 conversions and in fact current compilers conform to DR #84.
2704 </p>
2705
2706 <p>
2707 I was surprised to discover that the obsolete conversion member actually has
2708 negative impact of the copy initialization base from l-value derived
2709 case:</p>
2710 <pre>auto_ptr&lt;D&gt; dp;
2711 int x2 = sink(dp); // #2 EDG - more than one user-defined conversion applies
2712 </pre>
2713
2714 <p>
2715 I'm sure that the original intention was allowing this initialization using
2716 the template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;&amp; a) constructor (20.4.5.1/4) but
2717 since in this copy initialization it's merely user defined conversion (UDC)
2718 and the obsolete conversion member is UDC with the same rank (for the early
2719 overloading stage) there is an ambiguity between them.
2720 </p>
2721
2722 <p>
2723 Removing the obsolete member will have impact on code that explicitly
2724 invokes it:
2725 </p>
2726 <pre>int y = sink(source().operator auto_ptr&lt;B&gt;());
2727 </pre>
2728
2729 <p>
2730 IMHO no one ever wrote such awkward code and the reasonable workaround for
2731 #1 is:
2732 </p>
2733 <pre>int y = sink( auto_ptr&lt;B&gt;(source()) );
2734 </pre>
2735
2736 <p>
2737 I was even more surprised to find out that after removing the obsolete
2738 conversion member the initialization was still ill-formed:
2739 int x3 = sink(dp); // #3 EDG - no suitable copy constructor
2740 </p>
2741
2742 <p>
2743 This copy initialization semantically requires copy constructor which means
2744 that both template conversion constructor and the auto_ptr_ref conversion
2745 member (20.4.5.3/3) are required which is what was explicitly forbidden in
2746 DR #84. This is a bit amusing case in which removing ambiguity results with
2747 no candidates.
2748 </p>
2749
2750 <p>
2751 I also found exception safety issue with auto_ptr related to auto_ptr_ref:
2752 </p>
2753 <pre>int f(auto_ptr&lt;B&gt;, std::string);
2754 auto_ptr&lt;B&gt; source2();
2755
2756 // string constructor throws while auto_ptr_ref
2757 // "holds" the pointer
2758 int x4 = f(source2(), "xyz"); // #4
2759 </pre>
2760
2761 <p>
2762 The theoretic execution sequence that will cause a leak:
2763 </p>
2764 <ol>
2765 <li>call auto_ptr&lt;B&gt;::operator auto_ptr_ref&lt;B&gt;()</li>
2766 <li>call string::string(char const*) and throw</li>
2767 </ol>
2768
2769 <p>
2770 According to 20.4.5.3/3 and 20.4.5/2 the auto_ptr_ref conversion member
2771 returns auto_ptr_ref&lt;Y&gt; that holds *this and this is another defect since
2772 the type of *this is auto_ptr&lt;X&gt; where X might be different from Y. Several
2773 library vendors (e.g. SGI) implement auto_ptr_ref&lt;Y&gt; with Y* as member which
2774 is much more reasonable. Other vendor implemented auto_ptr_ref as
2775 defectively required and it results with awkward and catastrophic code:
2776 int oops = sink(auto_ptr&lt;B&gt;(source())); // warning recursive on all control
2777 paths
2778 </p>
2779
2780 <p>
2781 Dave Abrahams noticed that there is no specification saying that
2782 auto_ptr_ref copy constructor can't throw.
2783 </p>
2784
2785 <p>
2786 My proposal comes to solve all the above issues and significantly simplify
2787 auto_ptr implementation. One of the fundamental requirements from auto_ptr
2788 is that it can be constructed in an intuitive manner (i.e. like ordinary
2789 pointers) but with strict ownership semantics which yield that source
2790 auto_ptr in initialization must be non-const. My idea is to add additional
2791 constructor template with sole propose to generate ill-formed, diagnostic
2792 required, instance for const auto_ptr arguments during instantiation of
2793 declaration. This special constructor will not be instantiated for other
2794 types which is achievable using 14.8.2/2 (SFINAE). Having this constructor
2795 in hand makes the constructor template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp;)
2796 legitimate since the actual argument can't be const yet non const r-value
2797 are acceptable.
2798 </p>
2799
2800 <p>
2801 This implementation technique makes the "private auxiliary class"
2802 auto_ptr_ref obsolete and I found out that modern C++ compilers (e.g. EDG,
2803 GCC and VC) consume the new implementation as expected and allow all
2804 intuitive initialization and assignment cases while rejecting illegal cases
2805 that involve const auto_ptr arguments.
2806 </p>
2807
2808 <p>The proposed auto_ptr interface:</p>
2809
2810 <pre>namespace std {
2811     template&lt;class X&gt; class auto_ptr {
2812     public:
2813         typedef X element_type;
2814
2815         // 20.4.5.1 construct/copy/destroy:
2816         explicit auto_ptr(X* p=0) throw();
2817         auto_ptr(auto_ptr&amp;) throw();
2818         template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp;) throw();
2819         auto_ptr&amp; operator=(auto_ptr&amp;) throw();
2820         template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;) throw();
2821         ~auto_ptr() throw();
2822
2823         // 20.4.5.2 members:
2824         X&amp; operator*() const throw();
2825         X* operator-&gt;() const throw();
2826         X* get() const throw();
2827         X* release() throw();
2828         void reset(X* p=0) throw();
2829
2830     private:
2831         template&lt;class U&gt;
2832         auto_ptr(U&amp; rhs, typename
2833 unspecified_error_on_const_auto_ptr&lt;U&gt;::type = 0);
2834     };
2835 }
2836 </pre>
2837
2838 <p>
2839 One compliant technique to implement the unspecified_error_on_const_auto_ptr
2840 helper class is using additional private auto_ptr member class template like
2841 the following:
2842 </p>
2843 <pre>template&lt;typename T&gt; struct unspecified_error_on_const_auto_ptr;
2844
2845 template&lt;typename T&gt;
2846 struct unspecified_error_on_const_auto_ptr&lt;auto_ptr&lt;T&gt; const&gt;
2847 { typedef typename auto_ptr&lt;T&gt;::const_auto_ptr_is_not_allowed type; };
2848 </pre>
2849
2850 <p>
2851 There are other techniques to implement this helper class that might work
2852 better for different compliers (i.e. better diagnostics) and therefore I
2853 suggest defining its semantic behavior without mandating any specific
2854 implementation. IMO, and I didn't found any compiler that thinks otherwise,
2855 14.7.1/5 doesn't theoretically defeat the suggested technique but I suggest
2856 verifying this with core language experts.
2857 </p>
2858
2859 <p><b>Further changes in standard text:</b></p>
2860 <p>Remove section 20.4.5.3</p>
2861
2862 <p>Change 20.4.5/2 to read something like:
2863 Initializing auto_ptr&lt;X&gt; from const auto_ptr&lt;Y&gt; will result with unspecified
2864 ill-formed declaration that will require unspecified diagnostic.</p>
2865
2866 <p>Change 20.4.5.1/4,5,6 to read:</p>
2867
2868 <pre>template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp; a) throw();</pre>
2869 <p> 4 Requires: Y* can be implicitly converted to X*.</p>
2870 <p> 5 Effects: Calls const_cast&lt;auto_ptr&lt;Y&gt;&amp;&gt;(a).release().</p>
2871 <p> 6 Postconditions: *this holds the pointer returned from a.release().</p>
2872
2873 <p>Change 20.4.5.1/10</p>
2874 <pre>template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt; a) throw();
2875 </pre>
2876 <p>
2877 10 Requires: Y* can be implicitly converted to X*. The expression delete
2878 get() is well formed.
2879 </p>
2880
2881 <p>LWG TC DR #127 is obsolete.</p>
2882
2883 <p>
2884 Notice that the copy constructor and copy assignment operator should remain
2885 as before and accept non-const auto_ptr&amp; since they have effect on the form
2886 of the implicitly declared copy constructor and copy assignment operator of
2887 class that contains auto_ptr as member per 12.8/5,10:
2888 </p>
2889 <pre>struct X {
2890     // implicit X(X&amp;)
2891     // implicit X&amp; operator=(X&amp;)
2892     auto_ptr&lt;D&gt; aptr_;
2893 };
2894 </pre>
2895
2896 <p>
2897 In most cases this indicates about sloppy programming but preserves the
2898 current auto_ptr behavior.
2899 </p>
2900
2901 <p>
2902 Dave Abrahams encouraged me to suggest fallback implementation in case that
2903 my suggestion that involves removing of auto_ptr_ref will not be accepted.
2904 In this case removing the obsolete conversion member to auto_ptr&lt;Y&gt; and
2905 20.4.5.3/4,5 is still required in order to eliminate ambiguity in legal
2906 cases. The two constructors that I suggested will co exist with the current
2907 members but will make auto_ptr_ref obsolete in initialization contexts.
2908 auto_ptr_ref will be effective in assignment contexts as suggested in DR
2909 #127 and I can't see any serious exception safety issues in those cases
2910 (although it's possible to synthesize such). auto_ptr_ref&lt;X&gt; semantics will
2911 have to be revised to say that it strictly holds pointer of type X and not
2912 reference to an auto_ptr for the favor of cases in which auto_ptr_ref&lt;Y&gt; is
2913 constructed from auto_ptr&lt;X&gt; in which X is different from Y (i.e. assignment
2914 from r-value derived to base).
2915 </p>
2916
2917 <p><i>[Redmond: punt for the moment. We haven't decided yet whether we
2918   want to fix auto_ptr for C++-0x, or remove it and replace it with
2919   move_ptr and unique_ptr.]</i></p>
2920
2921
2922 <p><i>[
2923 Oxford 2007: Recommend NAD.  We're just going to deprecate it.  It still works for simple use cases
2924 and people know how to deal with it.  Going forward <tt>unique_ptr</tt> is the recommended
2925 tool.
2926 ]</i></p>
2927
2928
2929 <p><i>[
2930 2007-11-09: Reopened at the request of David Abrahams, Alisdair Meredith and Gabriel Dos Reis.
2931 ]</i></p>
2932
2933
2934 <p><i>[
2935 2009-07 Frankfurt
2936 ]</i></p>
2937
2938
2939 <blockquote>
2940 This is a complicated issue, so we agreed to defer discussion until
2941 later in the week so that interested parties can read up on it.
2942 </blockquote>
2943
2944
2945
2946 <p><b>Proposed resolution:</b></p>
2947 <p>
2948 Change the synopsis in D.9.1 [auto.ptr]:
2949 </p>
2950
2951 <blockquote><pre>namespace std {
2952   <del>template &lt;class Y&gt; struct auto_ptr_ref {};</del>
2953
2954   <ins>// exposition only</ins>
2955   <ins>template &lt;class T&gt; struct constant_object;</ins>
2956
2957   <ins>// exposition only</ins>
2958   <ins>template &lt;class T&gt;</ins>
2959   <ins>struct cannot_transfer_ownership_from</ins>
2960     <ins>: constant_object&lt;T&gt; {};</ins>
2961
2962   template &lt;class X&gt; class auto_ptr {
2963   public:
2964     typedef X element_type;
2965
2966     // D.9.1.1 construct/copy/destroy:
2967     explicit auto_ptr(X* p =0) throw();
2968     auto_ptr(auto_ptr&amp;) throw();
2969     template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;<ins> const</ins>&amp;) throw();
2970     auto_ptr&amp; operator=(auto_ptr&amp;) throw();
2971     template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del>) throw();
2972     <del>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw();</del>
2973     ~auto_ptr() throw();
2974
2975     // D.9.1.2 members:
2976     X&amp; operator*() const throw();
2977     X* operator-&gt;() const throw();
2978     X* get() const throw();
2979     X* release() throw();
2980     void reset(X* p =0) throw();
2981
2982     <del>// D.9.1.3 conversions:</del>
2983     <del>auto_ptr(auto_ptr_ref&lt;X&gt;) throw();</del>
2984     <del>template&lt;class Y&gt; operator auto_ptr_ref&lt;Y&gt;() throw();</del>
2985     <del>template&lt;class Y&gt; operator auto_ptr&lt;Y&gt;() throw();</del>
2986
2987     <ins>// exposition only</ins>
2988     <ins>template&lt;class U&gt;</ins>
2989     <ins>auto_ptr(U&amp; rhs, typename cannot_transfer_ownership_from&lt;U&gt;::error = 0);</ins>
2990   };
2991
2992   template &lt;&gt; class auto_ptr&lt;void&gt;
2993   {
2994   public:
2995     typedef void element_type;
2996   };
2997
2998 }
2999 </pre></blockquote>
3000
3001 <p>
3002 Remove D.9.1.3 [auto.ptr.conv].
3003 </p>
3004
3005 <p>
3006 Change D.9.1 [auto.ptr], p3:
3007 </p>
3008
3009 <blockquote>
3010 The <tt>auto_ptr</tt> provides a semantics of strict ownership. An
3011 <tt>auto_ptr</tt> owns the object it holds a pointer to. Copying an
3012 <tt>auto_ptr</tt> copies the pointer and transfers ownership to the
3013 destination. If more than one <tt>auto_ptr</tt> owns the same object at
3014 the same time the behavior of the program is undefined. <ins>Templates
3015 <tt>constant_object</tt> and <tt>cannot_transfer_ownership_from</tt>,
3016 and the final constructor of <tt>auto_ptr</tt> are for exposition only.
3017 For any types <tt>X</tt> and <tt>Y</tt>, initializing
3018 <tt>auto_ptr&lt;X&gt;</tt> from <tt>const auto_ptr&lt;Y&gt;</tt> is
3019 ill-formed, diagnostic required.</ins> [<i>Note:</i> The uses of
3020 <tt>auto_ptr</tt> include providing temporary exception-safety for
3021 dynamically allocated memory, passing ownership of dynamically allocated
3022 memory to a function, and returning dynamically allocated memory from a
3023 function. <tt>auto_ptr</tt> does not meet the <tt>CopyConstructible</tt>
3024 and <tt>Assignable</tt> requirements for Standard Library container
3025 elements and thus instantiating a Standard Library container with an
3026 <tt>auto_ptr</tt> results in undefined behavior. <i>-- end note</i>]
3027 </blockquote>
3028
3029 <p>
3030 Change D.9.1.1 [auto.ptr.cons], p5:
3031 </p>
3032
3033 <blockquote>
3034 <pre>template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;<ins> const</ins>&amp; a) throw();
3035 </pre>
3036 <blockquote>
3037 <p>
3038 <i>Requires:</i> <tt>Y*</tt> can be implicitly converted to <tt>X*</tt>.
3039 </p>
3040 <p>
3041 <i>Effects:</i> Calls <ins><tt>const_cast&lt;auto_ptr&lt;Y&gt;&amp;&gt;(</tt></ins><tt>a</tt><ins><tt>)</tt></ins><tt>.release()</tt>.
3042 </p>
3043 <p>
3044 <i>Postconditions:</i> <tt>*this</tt> holds the pointer returned from <tt>a.release()</tt>.
3045 </p>
3046 </blockquote>
3047 </blockquote>
3048
3049 <p>
3050 Change D.9.1.1 [auto.ptr.cons], p10:
3051 </p>
3052
3053 <blockquote>
3054 <pre>template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del> a) throw();
3055 </pre>
3056 <blockquote>
3057 <p>
3058 <i>Requires:</i> <tt>Y*</tt> can be implicitly converted to <tt>X*</tt>.
3059 The expression <tt>delete get()</tt> is well formed.
3060 </p>
3061 <p>
3062 <i>Effects:</i> Calls <tt>reset(a.release())</tt>.
3063 </p>
3064 <p>
3065 <i>Returns:</i> <tt>*this</tt>.
3066 </p>
3067 </blockquote>
3068 </blockquote>
3069
3070
3071
3072
3073
3074
3075 <hr>
3076 <h3><a name="471"></a>471. result of what() implementation-defined</h3>
3077 <p><b>Section:</b> 18.8.1 [exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
3078  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-06-28  <b>Last modified:</b> 2009-07-30</p>
3079 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3080 <p><b>Discussion:</b></p>
3081
3082 <p>[lib.exception] specifies the following:</p>
3083 <pre>    exception (const exception&amp;) throw();
3084     exception&amp; operator= (const exception&amp;) throw();
3085
3086     -4- Effects: Copies an exception object.
3087     -5- Notes: The effects of calling what() after assignment
3088         are implementation-defined.
3089 </pre>
3090
3091 <p>
3092 First, does the Note only apply to the assignment operator? If so,
3093 what are the effects of calling what() on a copy of an object? Is
3094 the returned pointer supposed to point to an identical copy of
3095 the NTBS returned by what() called on the original object or not?
3096 </p>
3097
3098 <p>
3099 Second, is this Note intended to extend to all the derived classes
3100 in section 19? I.e., does the standard provide any guarantee for
3101 the effects of what() called on a copy of any of the derived class
3102 described in section 19?
3103 </p>
3104
3105 <p>
3106 Finally, if the answer to the first question is no, I believe it
3107 constitutes a defect since throwing an exception object typically
3108 implies invoking the copy ctor on the object. If the answer is yes,
3109 then I believe the standard ought to be clarified to spell out
3110 exactly what the effects are on the copy (i.e., after the copy
3111 ctor was called).
3112 </p>
3113
3114 <p><i>[Redmond: Yes, this is fuzzy.  The issue of derived classes is
3115   fuzzy too.]</i></p>
3116
3117
3118 <p><i>[
3119 Batavia: Howard provided wording.
3120 ]</i></p>
3121
3122
3123 <p><i>[
3124 Bellevue:
3125 ]</i></p>
3126
3127
3128 <blockquote>
3129 <p>
3130 Eric concerned this is unimplementable, due to nothrow guarantees.
3131 Suggested implementation would involve reference counting.
3132 </p>
3133 <p>
3134 Is the implied reference counting subtle enough to call out a note on
3135 implementation? Probably not.
3136 </p>
3137 <p>
3138 If reference counting required, could we tighten specification further
3139 to require same pointer value? Probably an overspecification, especially
3140 if exception classes defer evalutation of final string to calls to
3141 what().
3142 </p>
3143 <p>
3144 Remember issue moved open and not resolved at Batavia, but cannot
3145 remember who objected to canvas a disenting opinion - please speak up if
3146 you disagree while reading these minutes!
3147 </p>
3148 <p>
3149 Move to Ready as we are accepting words unmodified.
3150 </p>
3151 </blockquote>
3152
3153 <p><i>[
3154 Sophia Antipolis:
3155 ]</i></p>
3156
3157
3158 <blockquote>
3159 The issue was pulled from Ready.  It needs to make clear that only homogenous copying
3160 is intended to be supported, not coping from a derived to a base.
3161 </blockquote>
3162
3163 <p><i>[
3164 Batavia (2009-05):
3165 ]</i></p>
3166
3167 <blockquote>
3168 <p>
3169 Howard supplied the following replacement wording
3170 for paragraph 7 of the proposed resolution:
3171 </p>
3172 <blockquote>
3173 <ins>-7- <i>Postcondition:</i> <tt>what()</tt> shall return the same NTBS
3174   as would be obtained by using <tt>static_cast</tt>
3175   to cast the rhs to the same types as the lhs
3176   and then calling <tt>what()</tt> on that possibly sliced object.</ins>
3177 </blockquote>
3178 <p>
3179 Pete asks what "the same NTBS" means.
3180 </p>
3181 </blockquote>
3182
3183 <p><i>[
3184 2009-07-30 Niels adds:
3185 ]</i></p>
3186
3187
3188 <blockquote>
3189 Further discussion in the thread starting with c++std-lib-24512.
3190 </blockquote>
3191
3192
3193
3194 <p><b>Proposed resolution:</b></p>
3195
3196 <p>
3197 Change 18.8.1 [exception] to:
3198 </p>
3199
3200 <blockquote>
3201 <pre>exception(const exception&amp; <ins><i>e</i></ins>) throw();
3202 exception&amp; operator=(const exception&amp; <ins><i>e</i></ins>) throw();</pre>
3203 <blockquote>
3204 <p>
3205 -4- <i>Effects:</i> Copies an exception object.
3206 </p>
3207 <p>
3208 <del> -5- <i>Remarks:</i> The effects of calling what() after assignment are implementation-defined.</del>
3209 </p>
3210 <p>
3211 <ins>-5- <i>Throws:</i> Nothing.  This also applies
3212 to all standard library-defined classes that derive from <tt>exception</tt>.</ins>
3213 </p>
3214 <p>
3215 <ins>-7- <i>Postcondition:</i> <tt>strcmp(what(), <i>e</i>.what()) == 0</tt>.  This also applies
3216 to all standard library-defined classes that derive from <tt>exception</tt>.</ins>
3217 </p>
3218
3219 </blockquote>
3220 </blockquote>
3221
3222
3223
3224
3225 <hr>
3226 <h3><a name="473"></a>473. underspecified ctype calls</h3>
3227 <p><b>Section:</b> 22.4.1.1 [locale.ctype] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
3228  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-07-01  <b>Last modified:</b> 2009-07-17</p>
3229 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
3230 <p><b>Discussion:</b></p>
3231 <p>
3232 Most ctype member functions come in two forms: one that operates
3233 on a single character at a time and another form that operates
3234 on a range of characters. Both forms are typically described by
3235 a single Effects and/or Returns clause.
3236 </p>
3237 <p>
3238 The Returns clause of each of the single-character non-virtual forms
3239 suggests that the function calls the corresponding single character
3240 virtual function, and that the array form calls the corresponding
3241 virtual array form. Neither of the two forms of each virtual member
3242 function is required to be implemented in terms of the other.
3243 </p>
3244 <p>
3245 There are three problems:
3246 </p>
3247 <p>
3248 1. One is that while the standard does suggest that each non-virtual
3249 member function calls the corresponding form of the virtual function,
3250 it doesn't actually explicitly require it.
3251 </p>
3252 <p>
3253 Implementations that cache results from some of the virtual member
3254 functions for some or all values of their arguments might want to
3255 call the array form from the non-array form the first time to fill
3256 the cache and avoid any or most subsequent virtual calls. Programs
3257 that rely on each form of the virtual function being called from
3258 the corresponding non-virtual function will see unexpected behavior
3259 when using such implementations.
3260 </p>
3261 <p>
3262 2. The second problem is that either form of each of the virtual
3263 functions can be overridden by a user-defined function in a derived
3264 class to return a value that is different from the one produced by
3265 the virtual function of the alternate form that has not been
3266 overriden.
3267 </p>
3268 <p>
3269 Thus, it might be possible for, say, ctype::widen(c) to return one
3270 value, while for ctype::widen(&amp;c, &amp;c + 1, &amp;wc) to set
3271 wc to another value. This is almost certainly not intended. Both
3272 forms of every function should be required to return the same result
3273 for the same character, otherwise the same program using an
3274 implementation that calls one form of the functions will behave
3275 differently than when using another implementation that calls the
3276 other form of the function "under the hood."
3277 </p>
3278 <p>
3279 3. The last problem is that the standard text fails to specify whether
3280 one form of any of the virtual functions is permitted to be implemented
3281 in terms of the other form or not, and if so, whether it is required
3282 or permitted to call the overridden virtual function or not.
3283 </p>
3284 <p>
3285 Thus, a program that overrides one of the virtual functions so that
3286 it calls the other form which then calls the base member might end
3287 up in an infinite loop if the called form of the base implementation
3288 of the function in turn calls the other form.
3289 </p>
3290 <p>
3291 Lillehammer: Part of this isn't a real problem. We already talk about
3292 caching. 22.1.1/6 But part is a real problem. ctype virtuals may call
3293 each other, so users don't know which ones to override to avoid avoid
3294 infinite loops.</p>
3295
3296 <p>This is a problem for all facet virtuals, not just ctype virtuals,
3297 so we probably want a blanket statement in clause 22 for all
3298 facets. The LWG is leaning toward a blanket prohibition, that a
3299 facet's virtuals may never call each other. We might want to do that
3300 in clause 27 too, for that matter. A review is necessary.  Bill will
3301 provide wording.</p>
3302
3303 <p><i>[
3304 2009-07 Frankfurt, Howard provided wording directed by consensus.
3305 ]</i></p>
3306
3307
3308
3309
3310 <p><b>Proposed resolution:</b></p>
3311 <p>
3312 Add paragraph 3 to 22.4 [locale.categories]:
3313 </p>
3314
3315 <blockquote><ins>
3316 -3- Within this clause it is unspecified if one virtual function calls another
3317 virtual function.
3318 </ins></blockquote>
3319
3320
3321
3322
3323
3324 <hr>
3325 <h3><a name="484"></a>484. Convertible to T</h3>
3326 <p><b>Section:</b> 24.2.2 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
3327  <b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2004-09-16  <b>Last modified:</b> 2009-07-28</p>
3328 <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>
3329 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3330 <p><b>Discussion:</b></p>
3331 <p>From comp.std.c++:</p>
3332
3333 <p>
3334 I note that given an input iterator a for type T,
3335 then *a only has to be "convertable to T", not actually of type T.
3336 </p>
3337
3338 <p>Firstly, I can't seem to find an exact definition of "convertable to T".
3339 While I assume it is the obvious definition (an implicit conversion), I
3340 can't find an exact definition. Is there one?</p>
3341
3342 <p>Slightly more worryingly, there doesn't seem to be any restriction on
3343 the this type, other than it is "convertable to T". Consider two input
3344 iterators a and b. I would personally assume that most people would
3345 expect *a==*b would perform T(*a)==T(*b), however it doesn't seem that
3346 the standard requires that, and that whatever type *a is (call it U)
3347 could have == defined on it with totally different symantics and still
3348 be a valid inputer iterator.</p>
3349
3350 <p>Is this a correct reading? When using input iterators should I write
3351 T(*a) all over the place to be sure that the object i'm using is the
3352 class I expect?</p>
3353
3354 <p>This is especially a nuisance for operations that are defined to be
3355   "convertible to bool".  (This is probably allowed so that
3356   implementations could return say an int and avoid an unnessary
3357   conversion. However all implementations I have seen simply return a
3358   bool anyway.  Typical implemtations of STL algorithms just write
3359   things like <tt>while(a!=b &amp;&amp; *a!=0)</tt>.  But strictly
3360   speaking, there are lots of types that are convertible to T but
3361   that also overload the appropriate operators so this doesn't behave
3362   as expected.</p>
3363
3364 <p>If we want to make code like this legal (which most people seem to
3365   expect), then we'll need to tighten up what we mean by "convertible
3366   to T".</p>
3367
3368 <p><i>[Lillehammer: The first part is NAD, since "convertible" is
3369  well-defined in core. The second part is basically about pathological
3370  overloads. It's a minor problem but a real one. So leave open for
3371  now, hope we solve it as part of iterator redesign.]</i></p>
3372
3373
3374 <p><i>[
3375 2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
3376 ]</i></p>
3377
3378
3379
3380
3381 <p><b>Proposed resolution:</b></p>
3382
3383
3384 <p><b>Rationale:</b></p>
3385 <p><i>[
3386 San Francisco:
3387 ]</i></p>
3388
3389
3390 <blockquote>
3391 Solved by
3392 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/N2758.pdf">N2758</a>.
3393 </blockquote>
3394
3395
3396
3397
3398
3399
3400
3401 <hr>
3402 <h3><a name="485"></a>485. output iterator insufficiently constrained</h3>
3403 <p><b>Section:</b> 24.2.3 [output.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
3404  <b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2004-10-13  <b>Last modified:</b> 2009-07-21</p>
3405 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#output.iterators">issues</a> in [output.iterators].</p>
3406 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3407 <p><b>Discussion:</b></p>
3408 <p>
3409 The note on 24.1.2 Output iterators insufficiently limits what can be
3410 performed on output iterators. While it requires that each iterator is
3411 progressed through only once and that each iterator is written to only
3412 once, it does not require the following things:</p>
3413
3414 <p>Note: Here it is assumed that x is an output iterator of type X which
3415 has not yet been assigned to.</p>
3416
3417 <p>a) That each value of the output iterator is written to:
3418 The standard allows:
3419 ++x; ++x; ++x;
3420 </p>
3421
3422 <p>
3423 b) That assignments to the output iterator are made in order
3424 X a(x); ++a; *a=1; *x=2; is allowed
3425 </p>
3426
3427 <p>
3428 c) Chains of output iterators cannot be constructed:
3429 X a(x); ++a; X b(a); ++b; X c(b); ++c; is allowed, and under the current
3430 wording (I believe) x,a,b,c could be written to in any order.
3431 </p>
3432
3433 <p>I do not believe this was the intension of the standard?</p>
3434 <p><i>[Lillehammer: Real issue.  There are lots of constraints we
3435   intended but didn't specify.  Should be solved as part of iterator
3436   redesign.]</i></p>
3437
3438
3439 <p><i>[
3440 2009-07 Frankfurt
3441 ]</i></p>
3442
3443
3444 <blockquote>
3445 Bill provided wording according to consensus.
3446 </blockquote>
3447
3448 <p><i>[
3449 2009-07-21 Alsidair requests change from Review to Open.  See thread starting
3450 with c++std-lib-24459 for discussion.
3451 ]</i></p>
3452
3453
3454
3455
3456 <p><b>Proposed resolution:</b></p>
3457 <p>
3458 Change Table 101 &#8212; Output iterator requirements in 24.2.3 [output.iterators]:
3459 </p>
3460 <blockquote>
3461 <table border="1">
3462 <caption>Table 101 &#8212; Output iterator requirements</caption>
3463 <tbody><tr>
3464 <th>Expression</th>
3465 <th>Return type</th>
3466 <th>Operational semantics</th>
3467 <th>Assertion/note pre-/post-condition</th>
3468 </tr>
3469
3470 <tr>
3471 <td>
3472 <tt>X(a)</tt>
3473 </td>
3474 <td>
3475 &nbsp;
3476 </td>
3477 <td>
3478 &nbsp;
3479 </td>
3480 <td>
3481 <tt>a = t</tt> is equivalent to <tt>X(a) = t</tt>. note: a destructor is assumed.
3482 </td>
3483 </tr>
3484
3485 <tr>
3486 <td>
3487 <tt>X u(a);</tt><br>
3488 <tt>X u = a;</tt>
3489 </td>
3490 <td>
3491 &nbsp;
3492 </td>
3493 <td>
3494 &nbsp;
3495 </td>
3496 <td>
3497 &nbsp;
3498 </td>
3499 </tr>
3500
3501 <tr>
3502 <td><del>
3503 <tt>*r = o</tt>
3504 </del></td>
3505 <td><del>
3506 result is not used
3507 </del></td>
3508 <td>
3509 &nbsp;
3510 </td>
3511 <td>
3512 &nbsp;
3513 </td>
3514 </tr>
3515
3516 <tr>
3517 <td><del>
3518 <tt>++r</tt>
3519 </del></td>
3520 <td><del>
3521 <tt>X&amp;</tt>
3522 </del></td>
3523 <td>
3524 &nbsp;
3525 </td>
3526 <td><del>
3527 <tt>&amp;r == &amp;++r</tt>
3528 </del></td>
3529 </tr>
3530
3531 <tr>
3532 <td><del>
3533 <tt>r++</tt>
3534 </del></td>
3535 <td><del>
3536 convertible to <tt>const X&amp;</tt>
3537 </del></td>
3538 <td><del>
3539 <tt>{X tmp = r;<br>++r;<br>return tmp;}</tt>
3540 </del></td>
3541 <td>
3542 &nbsp;
3543 </td>
3544 </tr>
3545
3546 <tr>
3547 <td>
3548 <tt>*r++ = o<br>*r = o, ++r<br>*r = o, r++</tt>
3549 </td>
3550 <td>
3551 result is not <del>used</del> <ins>usable</ins>
3552 </td>
3553 <td>
3554 &nbsp;
3555 </td>
3556 <td>
3557 <ins>Note: only these forms permitted</ins>
3558 </td>
3559 </tr>
3560
3561 </tbody></table>
3562 </blockquote>
3563
3564
3565
3566
3567
3568 <hr>
3569 <h3><a name="498"></a>498. Requirements for partition() and stable_partition() too strong</h3>
3570 <p><b>Section:</b> 25.4.13 [alg.partitions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
3571  <b>Submitter:</b> Sean Parent, Joe Gottman <b>Opened:</b> 2005-05-04  <b>Last modified:</b> 2009-07-15</p>
3572 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
3573 <p><b>Discussion:</b></p>
3574 <p>
3575 Problem:
3576 The iterator requirements for partition() and stable_partition() [25.2.12]
3577 are listed as BidirectionalIterator, however, there are efficient algorithms
3578 for these functions that only require ForwardIterator that have been known
3579 since before the standard existed. The SGI implementation includes these (see
3580 <a href="http://www.sgi.com/tech/stl/partition.html">http://www.sgi.com/tech/stl/partition.html</a>
3581 and
3582 <a href="http://www.sgi.com/tech/stl/stable_partition.html">http://www.sgi.com/tech/stl/stable_partition.html</a>).
3583 </p>
3584
3585 <p><i>[
3586 2009-04-30 Alisdair adds:
3587 ]</i></p>
3588
3589
3590 <blockquote>
3591 <p>
3592 Now we have concepts this is easier to express!
3593 </p>
3594 <p>
3595 Proposed resolution:
3596 </p>
3597 <p>
3598 Add the following signature to:
3599 </p>
3600 <p>
3601 Header <tt>&lt;algorithm&gt;</tt> synopsis 25.2 [algorithms.syn]<br>
3602 p3 Partitions 25.4.13 [alg.partitions]
3603 </p>
3604 <blockquote><pre> template&lt;ForwardIterator Iter, Predicate&lt;auto, Iter::value_type&gt; Pred&gt;
3605    requires ShuffleIterator&lt;Iter&gt;
3606          &amp;&amp; CopyConstructible&lt;Pred&gt;
3607    Iter partition(Iter first, Iter last, Pred pred);
3608 </pre></blockquote>
3609
3610 <p>
3611 Update p3 Partitions 25.4.13 [alg.partitions]:
3612 </p>
3613
3614 <blockquote>
3615 <p>
3616 <i>Complexity:</i> <del>At most <tt>(last - first)/2</tt> swaps. Exactly <tt>last - first</tt>
3617 applications of the predicate
3618 are done.</del>
3619 <ins>
3620 If <tt>Iter</tt> satisfies <tt>BidirectionalIterator</tt>, at most <tt>(last -
3621 first)/2</tt> swaps. Exactly <tt>last - first</tt> applications of the predicate
3622 are done.
3623 </ins>
3624 </p>
3625 <p><ins>
3626 If <tt>Iter</tt> merely satisfied <tt>ForwardIterator</tt> at most <tt>(last - first)</tt> swaps
3627 are done. Exactly <tt>(last - first)</tt> applications of the predicate are done.
3628 </ins></p>
3629 </blockquote>
3630
3631 <p>
3632 [Editorial note: I looked for existing precedent in how we might call out
3633 distinct overloads overloads from a set of constrained templates, but there
3634 is not much existing practice to lean on.   advance/distance were the only
3635 algorithms I could find, and that wording is no clearer.]
3636 </p>
3637
3638 </blockquote>
3639
3640 <p><i>[
3641 2009-07 Frankfurt
3642 ]</i></p>
3643
3644
3645 <blockquote>
3646 <p>
3647 Hinnant: if you want to partition your std::forward_list, you'll need
3648 partition() to accept ForwardIterators.
3649 </p>
3650 <p>
3651 No objection to Ready.
3652 </p>
3653 <p>
3654 Move to Ready.
3655 </p>
3656 </blockquote>
3657
3658
3659
3660 <p><b>Proposed resolution:</b></p>
3661 <p>
3662 Change 25.2.12 from </p>
3663 <blockquote><pre>template&lt;class BidirectionalIterator, class Predicate&gt;
3664 BidirectionalIterator partition(BidirectionalIterato r first,
3665                                 BidirectionalIterator last,
3666                                 Predicate pred);
3667 </pre></blockquote>
3668 <p>to </p>
3669 <blockquote><pre>template&lt;class ForwardIterator, class Predicate&gt;
3670 ForwardIterator partition(ForwardIterator first,
3671                           ForwardIterator last,
3672                           Predicate pred);
3673 </pre></blockquote>
3674 <p>Change the complexity from </p>
3675
3676 <blockquote><p>
3677 At most (last - first)/2 swaps are done. Exactly (last - first)
3678 applications of the predicate are done.
3679 </p></blockquote>
3680
3681 <p>to </p>
3682
3683 <blockquote><p>
3684 If ForwardIterator is a bidirectional_iterator, at most (last - first)/2
3685 swaps are done; otherwise at most (last - first) swaps are done. Exactly
3686 (last - first) applications of the predicate are done.
3687 </p></blockquote>
3688
3689
3690
3691 <p><b>Rationale:</b></p>
3692 <p>
3693 Partition is a "foundation" algorithm useful in many contexts (like sorting
3694 as just one example) - my motivation for extending it to include forward
3695 iterators is foward_list - without this extension you can't partition an foward_list
3696 (without writing your own partition). Holes like this in the standard
3697 library weaken the argument for generic programming (ideally I'd be able
3698 to provide a library that would refine std::partition() to other concepts
3699 without fear of conflicting with other libraries doing the same - but
3700 that is a digression). I consider the fact that partition isn't defined
3701 to work for ForwardIterator a minor embarrassment.
3702 </p>
3703
3704 <p><i>[Mont Tremblant: Moved to Open, request motivation and use cases
3705 by next meeting. Sean provided further rationale by post-meeting
3706 mailing.]</i></p>
3707
3708
3709
3710
3711
3712
3713
3714 <hr>
3715 <h3><a name="532"></a>532. Tuple comparison</h3>
3716 <p><b>Section:</b> 20.5.2.5 [tuple.rel], TR1 6.1.3.5 [tr.tuple.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
3717  <b>Submitter:</b> David Abrahams <b>Opened:</b> 2005-11-29  <b>Last modified:</b> 2009-07-28</p>
3718 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.rel">issues</a> in [tuple.rel].</p>
3719 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3720 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a></p>
3721 <p><b>Discussion:</b></p>
3722 <p>
3723 Where possible, tuple comparison operators &lt;,&lt;=,=&gt;, and &gt; ought to be
3724 defined in terms of std::less rather than operator&lt;, in order to
3725 support comparison of tuples of pointers.
3726 </p>
3727
3728 <p><i>[
3729 2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
3730 ]</i></p>
3731
3732
3733
3734
3735 <p><b>Proposed resolution:</b></p>
3736 <p>
3737 change 6.1.3.5/5 from:
3738 </p>
3739
3740 <blockquote><p>
3741   Returns: The result of a lexicographical comparison between t and
3742   u. The result is defined as: (bool)(get&lt;0&gt;(t) &lt; get&lt;0&gt;(u)) ||
3743   (!(bool)(get&lt;0&gt;(u) &lt; get&lt;0&gt;(t)) &amp;&amp; ttail &lt; utail), where rtail for
3744   some tuple r is a tuple containing all but the first element of
3745   r. For any two zero-length tuples e and f, e &lt; f returns false.
3746 </p></blockquote>
3747
3748 <p>
3749 to:
3750 </p>
3751
3752 <blockquote>
3753 <p>
3754   Returns: The result of a lexicographical comparison between t and
3755   u. For any two zero-length tuples e and f, e &lt; f returns false.
3756   Otherwise, the result is defined as: cmp( get&lt;0&gt;(t), get&lt;0&gt;(u)) ||
3757   (!cmp(get&lt;0&gt;(u), get&lt;0&gt;(t)) &amp;&amp; ttail &lt; utail), where rtail for some
3758   tuple r is a tuple containing all but the first element of r, and
3759   cmp(x,y) is an unspecified function template defined as follows.
3760 </p>
3761 <p>
3762   Where T is the type of x and U is the type of y:
3763 </p>
3764
3765 <p>
3766      if T and U are pointer types and T is convertible to U, returns
3767      less&lt;U&gt;()(x,y)
3768 </p>
3769
3770 <p>
3771      otherwise, if T and U are pointer types, returns less&lt;T&gt;()(x,y)
3772 </p>
3773
3774 <p>
3775      otherwise, returns (bool)(x &lt; y)
3776 </p>
3777 </blockquote>
3778
3779 <p><i>[
3780 Berlin: This issue is much bigger than just tuple (pair, containers,
3781 algorithms). Dietmar will survey and work up proposed wording.
3782 ]</i></p>
3783
3784
3785
3786
3787 <p><b>Rationale:</b></p>
3788 <p>
3789 Recommend NAD.  This will be fixed with the next revision of concepts.
3790 </p>
3791
3792 <p><i>[
3793 San Francisco:
3794 ]</i></p>
3795
3796
3797 <blockquote>
3798 Solved by
3799 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>.
3800 </blockquote>
3801
3802
3803
3804
3805
3806 <hr>
3807 <h3><a name="539"></a>539. partial_sum and adjacent_difference should mention requirements</h3>
3808 <p><b>Section:</b> 26.7.3 [partial.sum] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
3809  <b>Submitter:</b> Marc Schoolderman <b>Opened:</b> 2006-02-06  <b>Last modified:</b> 2009-07-30</p>
3810 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
3811 <p><b>Discussion:</b></p>
3812 <p>
3813 There are some problems in the definition of partial_sum and
3814 adjacent_difference in 26.4 [lib.numeric.ops]
3815 </p>
3816
3817 <p>
3818 Unlike <tt>accumulate</tt> and <tt>inner_product</tt>, these functions are not
3819 parametrized on a "type T", instead, 26.4.3 [lib.partial.sum] simply
3820 specifies the effects clause as;
3821 </p>
3822
3823 <blockquote><p>
3824 Assigns to every element referred to by iterator <tt>i</tt> in the range
3825 <tt>[result,result + (last - first))</tt> a value correspondingly equal to
3826 </p>
3827 <blockquote><pre>((...(* first + *( first + 1)) + ...) + *( first + ( i - result )))
3828 </pre></blockquote>
3829 </blockquote>
3830
3831 <p>
3832 And similarly for BinaryOperation. Using just this definition, it seems
3833 logical to expect that:
3834 </p>
3835
3836
3837 <blockquote><pre>char i_array[4] = { 100, 100, 100, 100 };
3838 int  o_array[4];
3839
3840 std::partial_sum(i_array, i_array+4, o_array);
3841 </pre></blockquote>
3842
3843 <p>
3844 Is equivalent to
3845 </p>
3846
3847 <blockquote><pre>int o_array[4] = { 100, 100+100, 100+100+100, 100+100+100+100 };
3848 </pre></blockquote>
3849
3850 <p>
3851 i.e. 100, 200, 300, 400, with addition happening in the <tt>result type</tt>,
3852 <tt>int</tt>.
3853 </p>
3854
3855 <p>
3856 Yet all implementations I have tested produce 100, -56, 44, -112,
3857 because they are using an accumulator of the <tt>InputIterator</tt>'s
3858 <tt>value_type</tt>, which in this case is <tt>char</tt>, not <tt>int</tt>.
3859 </p>
3860
3861 <p>
3862 The issue becomes more noticeable when the result of the expression <tt>*i +
3863 *(i+1)</tt> or <tt>binary_op(*i, *i-1)</tt> can't be converted to the
3864 <tt>value_type</tt>. In a contrived example:
3865 </p>
3866
3867 <blockquote><pre>enum not_int { x = 1, y = 2 };
3868 ...
3869 not_int e_array[4] = { x, x, y, y };
3870 std::partial_sum(e_array, e_array+4, o_array);
3871 </pre></blockquote>
3872
3873 <p>
3874 Is it the intent that the operations happen in the <tt>input type</tt>, or in
3875 the <tt>result type</tt>?
3876 </p>
3877
3878 <p>
3879 If the intent is that operations happen in the <tt>result type</tt>, something
3880 like this should be added to the "Requires" clause of 26.4.3/4
3881 [lib.partial.sum]:
3882 </p>
3883
3884 <blockquote><p>
3885 The type of <tt>*i + *(i+1)</tt> or <tt>binary_op(*i, *(i+1))</tt> shall meet the
3886 requirements of <tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt>
3887 (23.1) types.
3888 </p></blockquote>
3889
3890 <p>
3891 (As also required for <tt>T</tt> in 26.4.1 [lib.accumulate] and 26.4.2
3892 [lib.inner.product].)
3893 </p>
3894
3895 <p>
3896 The "auto initializer" feature proposed in
3897 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1894.pdf">N1894</a>
3898 is not required to
3899 implement <tt>partial_sum</tt> this way. The 'narrowing' behaviour can still be
3900 obtained by using the <tt>std::plus&lt;&gt;</tt> function object.
3901 </p>
3902
3903 <p>
3904 If the intent is that operations happen in the <tt>input type</tt>, then
3905 something like this should be added instead;
3906 </p>
3907
3908 <blockquote><p>
3909 The type of *first shall meet the requirements of
3910 <tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt> (23.1) types.
3911 The result of <tt>*i + *(i+1)</tt> or <tt>binary_op(*i, *(i+1))</tt> shall be
3912 convertible to this type.
3913 </p></blockquote>
3914
3915 <p>
3916 The 'widening' behaviour can then be obtained by writing a custom proxy
3917 iterator, which is somewhat involved.
3918 </p>
3919
3920 <p>
3921 In both cases, the semantics should probably be clarified.
3922 </p>
3923
3924 <p>
3925 26.4.4 [lib.adjacent.difference] is similarly underspecified, although
3926 all implementations seem to perform operations in the 'result' type:
3927 </p>
3928
3929 <blockquote><pre>unsigned char i_array[4] = { 4, 3, 2, 1 };
3930 int o_array[4];
3931
3932 std::adjacent_difference(i_array, i_array+4, o_array);
3933 </pre></blockquote>
3934
3935 <p>
3936 o_array is 4, -1, -1, -1 as expected, not 4, 255, 255, 255.
3937 </p>
3938
3939 <p>
3940 In any case, <tt>adjacent_difference</tt> doesn't mention the requirements on the
3941 <tt>value_type</tt>; it can be brought in line with the rest of 26.4
3942 [lib.numeric.ops] by adding the following to 26.4.4/2
3943 [lib.adjacent.difference]:
3944 </p>
3945
3946 <blockquote><p>
3947 The type of <tt>*first</tt> shall meet the requirements of
3948 <tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt> (23.1) types."
3949 </p></blockquote>
3950 <p><i>[
3951 Berlin: Giving output iterator's value_types very controversial. Suggestion of
3952 adding signatures to allow user to specify "accumulator".
3953 ]</i></p>
3954
3955
3956 <p><i>[
3957 Bellevue:
3958 ]</i></p>
3959
3960
3961 <blockquote>
3962 The intent of the algorithms is to perform their calculations using the type of the input iterator.
3963 Proposed wording provided.
3964 </blockquote>
3965
3966 <p><i>[
3967 Sophia Antipolis:
3968 ]</i></p>
3969
3970
3971 <blockquote>
3972 We did not agree that the proposed resolution was correct. For example,
3973 when the arguments are types <tt>(float*, float*, double*)</tt>, the
3974 highest-quality solution would use double as the type of the
3975 accumulator. If the intent of the wording is to require that the type of
3976 the accumulator must be the <tt>input_iterator</tt>'s <tt>value_type</tt>, the wording
3977 should specify it.
3978 </blockquote>
3979
3980 <p><i>[
3981 2009-05-09 Alisdair adds:
3982 ]</i></p>
3983
3984
3985 <blockquote>
3986 <p>
3987 Now that we have the facility, the 'best' accumulator type could probably be
3988 deduced as:
3989 </p>
3990 <blockquote><pre>std::common_type&lt;InIter::value_type, OutIter::reference&gt;::type
3991 </pre></blockquote>
3992 <p>
3993 This type would then have additional requirements of constructability and
3994 incrementability/assignability.
3995 </p>
3996 <p>
3997 If this extracting an accumulator type from a pair/set of iterators (with
3998 additional requirements on that type) is a problem for multiple functions,
3999 it might be worth extracting into a SharedAccumulator concept or similar.
4000 </p>
4001 <p>
4002 I'll go no further in writing up wording now, until the group gives a
4003 clearer indication of preferred direction.
4004 </p>
4005 </blockquote>
4006
4007 <p><i>[
4008 2009-07 Frankfurt
4009 ]</i></p>
4010
4011
4012 <blockquote>
4013 The proposed resolution isn't quite right. For example, "the type of
4014 *first" should be changed to "iterator::value_type" or similar. Daniel
4015 volunteered to correct the wording.
4016 </blockquote>
4017
4018 <p><i>[
4019 2009-07-29 Daniel corrected wording.
4020 ]</i></p>
4021
4022
4023
4024 <p><b>Proposed resolution:</b></p>
4025
4026
4027
4028 <ol>
4029 <li>
4030 <p>
4031 Change 26.7.3 [partial.sum]/1 as indicated:
4032 </p>
4033
4034 <blockquote>
4035 <p>
4036 <i>Effects:</i> <ins>Let <tt>VT</tt> be <tt>InputIterator</tt>'s value type. For a nonempty range,
4037 initializes an accumulator <tt>acc</tt> of type <tt>VT</tt> with <tt>*first</tt> and performs
4038 <tt>*result = acc</tt>. For every iterator <tt>i</tt> in <tt>[first + 1, last)</tt> in order, <tt>acc</tt> is then
4039 modified by <tt>acc = acc + *i</tt> or <tt>acc = binary_op(acc, *i)</tt> and is assigned
4040 to <tt>*(result + (i - first))</tt>.</ins> <del>Assigns to every element referred to by
4041 iterator <tt>i</tt> in the range <tt>[result,result + (last - first))</tt> a value
4042 correspondingly
4043 equal to</del>
4044 </p>
4045
4046 <blockquote><pre><del>
4047 ((...(*first + *(first + 1)) + ...) + *(first + (i - result)))
4048 </del></pre></blockquote>
4049
4050 <p><del>
4051 or
4052 </del></p>
4053
4054 <blockquote><pre><del>
4055 binary_op(binary_op(...,
4056    binary_op(*first, *(first + 1)),...), *(first + (i - result)))
4057 </del></pre></blockquote>
4058 </blockquote>
4059 </li>
4060
4061 <li>
4062 <p>
4063 Change 26.7.3 [partial.sum]/3 as indicated:
4064 </p>
4065
4066 <blockquote>
4067 <i>Complexity:</i> Exactly <tt><ins>max(</ins>(last - first) - 1<ins>, 0)</ins></tt>
4068 applications
4069 of <tt><del>binary_op</del></tt><ins>the binary operation</ins>.
4070 </blockquote>
4071 </li>
4072
4073 <li>
4074 <p>
4075 Change 26.7.3 [partial.sum]/4 as indicated:
4076 </p>
4077
4078 <blockquote>
4079 <i>Requires:</i> <ins><tt>VT</tt> shall be constructible from the type of <tt>*first</tt>, the result of
4080 <tt>acc + *i</tt> or <tt>binary_op(acc, *i)</tt> shall be implicitly convertible to <tt>VT</tt>, and
4081 the result of the expression <tt>acc</tt> shall be writable to the <tt>result</tt>
4082 output iterator.</ins> In the ranges <tt>[first,last]</tt> and
4083 <tt>[result,result + (last - first)]</tt> [..]
4084 </blockquote>
4085 </li>
4086
4087 <li>
4088 <p>
4089 Change 26.7.4 [adjacent.difference]/1 as indicated:
4090 </p>
4091
4092 <blockquote>
4093 <p>
4094 <i>Effects:</i> <ins>Let <tt>VT</tt> be <tt>InputIterator</tt>'s value type. For a nonempty range,
4095 initializes an accumulator <tt>acc</tt> of type <tt>VT</tt> with <tt>*first</tt> and performs
4096 <tt>*result = acc</tt>. For every iterator <tt>i</tt> in <tt>[first + 1, last)</tt> in order,
4097 initializes a
4098 value <tt>val</tt> of type <tt>VT</tt> with <tt>*i</tt>, assigns the result of <tt>val - acc</tt> or
4099 <tt>binary_op(val, acc)</tt>
4100 to <tt>*(result + (i - first))</tt> and modifies <tt>acc = std::move(val)</tt>.</ins>
4101 <del>Assigns to every element referred to by iterator <tt>i</tt> in the range
4102 <tt>[result + 1,
4103 result + (last - first))</tt> a value correspondingly equal to</del>
4104 </p>
4105
4106 <blockquote><pre><del>
4107 *(first + (i - result)) - *(first + (i - result) - 1)
4108 </del></pre></blockquote>
4109
4110 <p><del>
4111 or
4112 </del></p>
4113
4114 <blockquote><pre><del>
4115 binary_op(*(first + (i - result)), *(first + (i - result) - 1)).
4116 </del></pre></blockquote>
4117
4118 <p><del>
4119 result gets the value of *first.</del>
4120 </p>
4121 </blockquote>
4122 </li>
4123
4124 <li>
4125 <p>
4126 Change 26.7.4 [adjacent.difference]/2 as indicated:
4127 </p>
4128
4129 <blockquote>
4130 <i>Requires:</i> <ins><tt>VT</tt> shall be <tt>MoveAssignable</tt> ([moveassignable])
4131 and shall be
4132 constructible from the type of <tt>*first</tt>. The result
4133 of the expression <tt>acc</tt> and the result of the expression <tt>val - acc</tt> or
4134 <tt>binary_op(val, acc)</tt>
4135 shall be writable to the <tt>result</tt> output iterator.</ins> In the ranges
4136 <tt>[first,last]</tt> [..]
4137 </blockquote>
4138 </li>
4139
4140 <li>
4141 <p>
4142 Change 26.7.4 [adjacent.difference]/5 as indicated:
4143 </p>
4144
4145 <blockquote>
4146 <i>Complexity:</i> Exactly <tt><ins>max(</ins>(last - first) - 1<ins>, 0)</ins></tt>
4147 applications
4148 of <del><tt>binary_op</tt></del><ins>the binary operation</ins>.
4149 </blockquote>
4150 </li>
4151 </ol>
4152
4153
4154
4155
4156
4157
4158
4159
4160 <hr>
4161 <h3><a name="556"></a>556. is Compare a BinaryPredicate?</h3>
4162 <p><b>Section:</b> 25.5 [alg.sorting] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
4163  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-05  <b>Last modified:</b> 2009-07-28</p>
4164 <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>
4165 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
4166 <p><b>Discussion:</b></p>
4167 <p>
4168 In 25, p8 we allow BinaryPredicates to return a type that's convertible
4169 to bool but need not actually be bool. That allows predicates to return
4170 things like proxies and requires that implementations be careful about
4171 what kinds of expressions they use the result of the predicate in (e.g.,
4172 the expression in if (!pred(a, b)) need not be well-formed since the
4173 negation operator may be inaccessible or return a type that's not
4174 convertible to bool).
4175 </p>
4176 <p>
4177 Here's the text for reference:
4178 </p>
4179 <blockquote><p>
4180   ...if an algorithm takes BinaryPredicate binary_pred as its argument
4181  and first1 and first2 as its iterator arguments, it should work
4182  correctly in the construct if (binary_pred(*first1, first2)){...}.
4183 </p></blockquote>
4184
4185 <p>
4186 In 25.3, p2 we require that the Compare function object return true
4187 of false, which would seem to preclude such proxies. The relevant text
4188 is here:
4189 </p>
4190 <blockquote><p>
4191   Compare is used as a function object which returns true if the first
4192   argument is less than the second, and false otherwise...
4193 </p></blockquote>
4194
4195 <p><i>[
4196 2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
4197 ]</i></p>
4198
4199
4200
4201
4202 <p><b>Proposed resolution:</b></p>
4203 <p>
4204 I think we could fix this by rewording 25.3, p2 to read somthing like:
4205 </p>
4206 <blockquote><p>
4207 -2- <tt>Compare</tt> is <del>used as a function object which returns
4208 <tt>true</tt> if the first argument</del> <ins>a <tt>BinaryPredicate</tt>. The
4209 return value of the function call operator applied to an object of type
4210 <tt>Compare</tt>, when converted to type <tt>bool</tt>, yields <tt>true</tt>
4211 if the first argument of the call</ins> is less than the second, and
4212 <tt>false</tt> otherwise. <tt>Compare <i>comp</i></tt> is used throughout for
4213 algorithms assuming an ordering relation. It is assumed that <tt><i>comp</i></tt>
4214 will not apply any non-constant function through the dereferenced iterator.
4215 </p></blockquote>
4216
4217
4218 <p><i>[
4219 Portland:  Jack to define "convertible to bool" such that short circuiting isn't
4220 destroyed.
4221 ]</i></p>
4222
4223
4224 <p><b>Rationale:</b></p>
4225 <p><i>[
4226 San Francisco:
4227 ]</i></p>
4228
4229
4230 <blockquote>
4231 Solved by
4232 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2774.pdf">N2774</a>).
4233 </blockquote>
4234
4235
4236
4237
4238
4239
4240 <hr>
4241 <h3><a name="564"></a>564. stringbuf seekpos underspecified</h3>
4242 <p><b>Section:</b> 27.8.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
4243  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-23  <b>Last modified:</b> 2009-07-15</p>
4244 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
4245 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
4246 <p><b>Discussion:</b></p>
4247 <p>
4248 The   effects  of  the   <code>seekpos()</code>  member   function  of
4249 <code>basic_stringbuf</code>  simply say  that the  function positions
4250 the  input and/or  output  sequences  but fail  to  spell out  exactly
4251 how. This is in contrast  to the detail in which <code>seekoff()</code>
4252 is described.
4253 </p>
4254
4255 <p><i>[
4256 2009-07 Frankfurt
4257 ]</i></p>
4258
4259
4260 <blockquote>
4261 Move to Ready.
4262 </blockquote>
4263
4264
4265
4266 <p><b>Proposed resolution:</b></p>
4267         <p>
4268
4269 Change 27.7.1.3, p13 to read:
4270
4271         </p>
4272 <blockquote>
4273 <p>
4274 -13- <i>Effects:</i> <ins>Equivalent to <tt>seekoff(off_type(<i>sp</i>), ios_base::beg,
4275 <i>which</i>)</tt>.</ins> <del>Alters the stream position within the controlled sequences,
4276 if possible, to correspond to the stream position stored in <tt><i>sp</i></tt>
4277 (as described below).</del>
4278 </p>
4279 <ul>
4280 <li><del>If <tt>(<i>which</i> &amp; ios_base::in) != 0</tt>, positions the input sequence.</del></li>
4281 <li><del>If <tt>(<i>which</i> &amp; ios_base::out) != 0</tt>, positions the output sequence.</del></li>
4282 <li><del>If <tt><i>sp</i></tt> is an invalid stream position, or if the function
4283 positions neither sequence, the positioning operation fails. If <tt><i>sp</i></tt>
4284 has not been obtained by a previous successful call to one of the positioning
4285 functions (<tt>seekoff</tt>, <tt>seekpos</tt>, <tt>tellg</tt>, <tt>tellp</tt>)
4286 the effect is undefined.</del></li>
4287 </ul>
4288 </blockquote>
4289
4290
4291 <p><i>[
4292 Kona (2007): A <tt>pos_type</tt> is a position in a stream by
4293 definition, so there is no ambiguity as to what it means. Proposed
4294 Disposition: NAD
4295 ]</i></p>
4296
4297
4298 <p><i>[
4299 Post-Kona Martin adds:
4300 I'm afraid I disagree
4301 with the Kona '07 rationale for marking it NAD. The only text
4302 that describes precisely what it means to position the input
4303 or output sequence is in <tt>seekoff()</tt>. The <tt>seekpos()</tt> Effects
4304 clause is inadequate in comparison and the proposed resolution
4305 plugs the hole by specifying <tt>seekpos()</tt> in terms of <tt>seekoff()</tt>.
4306 ]</i></p>
4307
4308
4309
4310
4311
4312 <hr>
4313 <h3><a name="565"></a>565. xsputn inefficient</h3>
4314 <p><b>Section:</b> 27.6.2.4.5 [streambuf.virt.put] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
4315  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-02-23  <b>Last modified:</b> 2009-07-15</p>
4316 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
4317 <p><b>Discussion:</b></p>
4318         <p>
4319
4320 <tt>streambuf::xsputn()</tt>  is  specified  to  have  the  effect  of
4321 "writing up to  <tt>n</tt> characters to the output  sequence as if by
4322 repeated calls to <tt>sputc(c)</tt>."
4323
4324         </p>
4325         <p>
4326
4327 Since  <tt>sputc()</tt> is required  to call  <tt>overflow()</tt> when
4328 <tt>(pptr()    ==   epptr())</tt>    is   true,    strictly   speaking
4329 <tt>xsputn()</tt>  should do  the same.   However, doing  so  would be
4330 suboptimal in  some interesting cases,  such as in unbuffered  mode or
4331 when the buffer is <tt>basic_stringbuf</tt>.
4332
4333         </p>
4334         <p>
4335
4336 Assuming  calling <tt>overflow()</tt>  is  not really  intended to  be
4337 required  and the  wording is  simply  meant to  describe the  general
4338 effect of appending to the end  of the sequence it would be worthwhile
4339 to  mention in  <tt>xsputn()</tt> that  the function  is  not actually
4340 required to cause a call to <tt>overflow()</tt>.
4341
4342         </p>
4343
4344 <p><i>[
4345 2009-07 Frankfurt
4346 ]</i></p>
4347
4348
4349 <blockquote>
4350 Move to Ready.
4351 </blockquote>
4352
4353
4354
4355 <p><b>Proposed resolution:</b></p>
4356         <p>
4357
4358 Add the following sentence  to the <tt>xsputn()</tt> Effects clause in
4359 27.5.2.4.5, p1 (N1804):
4360
4361         </p>
4362         <blockquote>
4363             <p>
4364 -1- <i>Effects:</i> Writes up to <tt><i>n</i></tt> characters to the output
4365 sequence as if by repeated calls to <tt>sputc(<i>c</i>)</tt>. The characters
4366 written are obtained from successive elements of the array whose first element
4367 is designated by <tt><i>s</i></tt>. Writing stops when either <tt><i>n</i></tt>
4368 characters have been written or a call to <tt>sputc(<i>c</i>)</tt> would return
4369 <tt>traits::eof()</tt>. <ins>It is  uspecified whether the function  calls
4370 <tt>overflow()</tt> when <tt>(pptr() ==  epptr())</tt> becomes true or whether
4371 it achieves the same effects by other means.</ins>
4372             </p>
4373         </blockquote>
4374         <p>
4375
4376 In addition,  I suggest to  add a footnote  to this function  with the
4377 same text as Footnote 292 to  make it extra clear that derived classes
4378 are permitted to override <tt>xsputn()</tt> for efficiency.
4379
4380         </p>
4381
4382
4383 <p><i>[
4384 Kona (2007): We want to permit a <tt>streambuf</tt> that streams output directly
4385 to a device without making calls to <tt>sputc</tt> or <tt>overflow</tt>. We believe that
4386 has always been the intention of the committee. We believe that the
4387 proposed wording doesn't accomplish that. Proposed Disposition: Open
4388 ]</i></p>
4389
4390
4391
4392
4393
4394 <hr>
4395 <h3><a name="580"></a>580. unused allocator members</h3>
4396 <p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
4397  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-14  <b>Last modified:</b> 2009-07-15</p>
4398 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
4399 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
4400 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
4401 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a></p>
4402 <p><b>Discussion:</b></p>
4403         <p>
4404
4405 C++ Standard Library  templates that take an allocator  as an argument
4406 are    required    to    call    the    <code>allocate()</code>    and
4407 <code>deallocate()</code>  members of the  allocator object  to obtain
4408 storage.  However, they do not appear to be required to call any other
4409 allocator      members      such     as      <code>construct()</code>,
4410 <code>destroy()</code>,           <code>address()</code>,          and
4411 <code>max_size()</code>.  This makes these allocator members less than
4412 useful in portable programs.
4413
4414         </p>
4415         <p>
4416
4417 It's unclear to me whether the absence of the requirement to use these
4418 allocator  members  is  an  unintentional  omission  or  a  deliberate
4419 choice. However,  since the functions exist in  the standard allocator
4420 and  since  they are  required  to  be  provided by  any  user-defined
4421 allocator I  believe the standard  ought to be clarified  to explictly
4422 specify  whether programs  should or  should not  be able  to  rely on
4423 standard containers calling the functions.
4424
4425         </p>
4426         <p>
4427
4428 I  propose  that all  containers  be required  to  make  use of  these
4429 functions.
4430
4431         </p>
4432 <p><i>[
4433 Batavia:  We support this resolution.  Martin to provide wording.
4434 ]</i></p>
4435
4436 <p><i>[
4437 pre-Oxford:  Martin provided wording.
4438 ]</i></p>
4439
4440
4441 <p><i>[
4442 2009-04-28 Pablo adds:
4443 ]</i></p>
4444
4445
4446 <blockquote>
4447 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2554.pdf">N2554</a>
4448 (scoped allocators),
4449 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2768.pdf">N2768</a>
4450 (allocator concepts), and
4451 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2810.pdf">N2810</a>
4452 (allocator defects), address all of these points EXCEPT <tt>max_size()</tt>.
4453 So, I would add a note to that affect and re-class the defect as belonging
4454 to section 23.2.1 [container.requirements.general].
4455 </blockquote>
4456
4457 <p><i>[
4458 2009-07 Frankfurt
4459 ]</i></p>
4460
4461
4462 <blockquote>
4463 The comment in the description of this issue that this "would be"
4464 rendered editorial by the adoption of N2257 is confusing. It appears
4465 that N2257 was never adopted.
4466 </blockquote>
4467
4468
4469
4470     <p><b>Proposed resolution:</b></p>
4471        <p>
4472
4473 Specifically, I propose to change 23.2 [container.requirements],
4474 p9 as follows:
4475
4476        </p>
4477            <blockquote>
4478 <p>
4479 -9- Copy constructors  for all container types defined  in this clause
4480 <ins>that   are  parametrized  on   <code>Allocator</code></ins>  copy
4481 <del>an</del><ins>the</ins>  allocator argument from  their respective
4482 first parameters.
4483
4484 All other  constructors for  these container types  take a<del>n</del>
4485 <ins>const</ins>  <code>Allocator&amp;</code>  argument  (20.1.6),  an
4486 allocator whose <code>value_type</code> is the same as the container's
4487 <code>value_type</code>.
4488
4489 A copy of this  argument <del>is</del><ins>shall be</ins> used for any
4490 memory  allocation <ins> and  deallocation</ins> performed<del>,</del>
4491 by these  constructors and by all  member functions<del>,</del> during
4492 the  lifetime  of each  container  object.   <ins>Allocation shall  be
4493 performed  "as  if"  by  calling  the  <code>allocate()</code>  member
4494 function on  a copy  of the allocator  object of the  appropriate type
4495 <sup>New  Footnote)</sup>,   and  deallocation  "as   if"  by  calling
4496 <code>deallocate()</code> on  a copy of  the same allocator  object of
4497 the corresponding type.</ins>
4498
4499 <ins>A  copy of  this argument  shall also  be used  to  construct and
4500 destroy objects whose lifetime  is managed by the container, including
4501 but not  limited to those of  the container's <code>value_type</code>,
4502 and  to  obtain  their  address.   All  objects  residing  in  storage
4503 allocated by a  container's allocator shall be constructed  "as if" by
4504 calling the <code>construct()</code> member  function on a copy of the
4505 allocator object of  the appropriate type.  The same  objects shall be
4506 destroyed "as if"  by calling <code>destroy()</code> on a  copy of the
4507 same allocator object  of the same type.  The  address of such objects
4508 shall be obtained "as if" by calling the <code>address()</code> member
4509 function  on  a  copy  of  the allocator  object  of  the  appropriate
4510 type.</ins>
4511
4512 <ins>Finally, a copy  of this argument shall be  used by its container
4513 object to determine  the maximum number of objects  of the container's
4514 <code>value_type</code> the container may  store at the same time. The
4515 container  member function <code>max_size()</code> obtains  this number
4516 from      the      value      returned      by     a      call      to
4517 <code>get_allocator().max_size()</code>.</ins>
4518
4519 In   all  container   types  defined   in  this   clause <ins>that  are
4520 parametrized     on    <code>Allocator</code></ins>,     the    member
4521 <code>get_allocator()</code>     returns     a     copy     of     the
4522 <code>Allocator</code>     object     used     to    construct     the
4523 container.<sup>258)</sup>
4524 </p>
4525 <p>
4526 New Footnote: This type  may be different from <code>Allocator</code>:
4527 it     may    be     derived    from     <code>Allocator</code>    via
4528 <code>Allocator::rebind&lt;U&gt;::other</code>   for  the  appropriate
4529 type <code>U</code>.
4530 </p>
4531            </blockquote>
4532        <p>
4533
4534 The proposed wording seems cumbersome but I couldn't think of a better
4535 way   to  describe   the   requirement  that   containers  use   their
4536 <code>Allocator</code>  to manage  only objects  (regardless  of their
4537 type)  that  persist  over  their  lifetimes  and  not,  for  example,
4538 temporaries  created on the  stack. That  is, containers  shouldn't be
4539 required  to  call  <code>Allocator::construct(Allocator::allocate(1),
4540 elem)</code>  just to  construct a  temporary copy  of an  element, or
4541 <code>Allocator::destroy(Allocator::address(temp),     1)</code>    to
4542 destroy temporaries.
4543
4544        </p>
4545
4546
4547 <p><i>[
4548 Howard: This same paragraph will need some work to accommodate <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#431">431</a>.
4549 ]</i></p>
4550
4551
4552 <p><i>[
4553 post Oxford:  This would be rendered NAD Editorial by acceptance of
4554 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
4555 ]</i></p>
4556
4557
4558
4559
4560
4561 <hr>
4562 <h3><a name="588"></a>588. requirements on zero sized tr1::arrays and other details</h3>
4563 <p><b>Section:</b> 23.3.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
4564  <b>Submitter:</b> Gennaro Prota <b>Opened:</b> 2006-07-18  <b>Last modified:</b> 2009-07-15</p>
4565 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p>
4566 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
4567 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
4568 <p><b>Discussion:</b></p>
4569 <p>
4570 The wording used for section 23.2.1 [lib.array] seems to be subtly
4571 ambiguous about zero sized arrays (N==0). Specifically:
4572 </p>
4573 <p>
4574 * "An instance of array&lt;T, N&gt; stores N elements of type T, so that
4575 [...]"
4576 </p>
4577 <p>
4578 Does this imply that a zero sized array object stores 0 elements, i.e.
4579 that it cannot store any element of type T? The next point clarifies
4580 the rationale behind this question, basically how to implement begin()
4581 and end():
4582 </p>
4583 <p>
4584 * 23.2.1.5 [lib.array.zero], p2: "In the case that N == 0, begin() ==
4585 end() == unique value."
4586 </p>
4587 <p>
4588 What does "unique" mean in this context? Let's consider the following
4589 possible implementations, all relying on a partial specialization:
4590 </p>
4591 <blockquote><pre>a)
4592     template&lt; typename T &gt;
4593     class array&lt; T, 0 &gt; {
4594
4595         ....
4596
4597         iterator begin()
4598         { return iterator( reinterpret_cast&lt; T * &gt;( this ) ); }
4599         ....
4600
4601     };
4602 </pre></blockquote>
4603 <p>
4604 This has been used in boost, probably intending that the return value
4605 had to be unique to the specific array object and that array couldn't
4606 store any T. Note that, besides relying on a reinterpret_cast, has
4607 (more than potential) alignment problems.
4608 </p>
4609 <blockquote><pre>b)
4610     template&lt; typename T &gt;
4611     class array&lt; T, 0 &gt; {
4612
4613         T t;
4614
4615         iterator begin()
4616         { return iterator( &amp;t ); }
4617         ....
4618
4619     };
4620 </pre></blockquote>
4621 <p>
4622 This provides a value which is unique to the object and to the type of
4623 the array, but requires storing a T. Also, it would allow the user to
4624 mistakenly provide an initializer list with one element.
4625 </p>
4626 <p>
4627 A slight variant could be returning *the* null pointer of type T
4628 </p>
4629 <blockquote><pre>    return static_cast&lt;T*&gt;(0);
4630 </pre></blockquote>
4631 <p>
4632 In this case the value would be unique to the type array&lt;T, 0&gt; but not
4633 to the objects (all objects of type array&lt;T, 0&gt; with the same value
4634 for T would yield the same pointer value).
4635 </p>
4636 <p>
4637 Furthermore this is inconsistent with what the standard requires from
4638 allocation functions (see library issue 9).
4639 </p>
4640 <p>
4641 c) same as above but with t being a static data member; again, the
4642 value would be unique to the type, not to the object.
4643 </p>
4644 <p>
4645 d) to avoid storing a T *directly* while disallowing the possibility
4646 to use a one-element initializer list a non-aggregate nested class
4647 could be defined
4648 </p>
4649 <blockquote><pre>    struct holder { holder() {} T t; } h;
4650 </pre></blockquote>
4651 <p>
4652 and then begin be defined as
4653 </p>
4654 <blockquote><pre> iterator begin() { return &amp;h.t; }
4655 </pre></blockquote>
4656 <p>
4657 But then, it's arguable whether the array stores a T or not.
4658 Indirectly it does.
4659 </p>
4660 <p>
4661 -----------------------------------------------------
4662 </p>
4663 <p>
4664 Now, on different issues:
4665 </p>
4666 <p>
4667 * what's the effect of calling assign(T&amp;) on a zero-sized array? There
4668 seems to be only mention of front() and back(), in 23.2.1 [lib.array]
4669 p4 (I would also suggest to move that bullet to section 23.2.1.5
4670 [lib.array.zero], for locality of reference)
4671 </p>
4672 <p>
4673 * (minor) the opening paragraph of 23.2.1 [lib.array] wording is a bit
4674 inconsistent with that of other sequences: that's not a problem in
4675 itself, but compare it for instance with "A vector is a kind of
4676 sequence that supports random access iterators"; though the intent is
4677 obvious one might argue that the wording used for arrays doesn't tell
4678 what an array is, and relies on the reader to infer that it is what
4679 the &lt;array&gt; header defines.
4680 </p>
4681 <p>
4682 * it would be desiderable to have a static const data member of type
4683 std::size_t, with value N, for usage as integral constant expression
4684 </p>
4685 <p>
4686 * section 23.1 [lib.container.requirements] seem not to consider
4687 fixed-size containers at all, as it says: "[containers] control
4688 allocation and deallocation of these objects [the contained objects]
4689 through constructors, destructors, *insert and erase* operations"
4690 </p>
4691 <p>
4692 * max_size() isn't specified: the result is obvious but, technically,
4693 it relies on table 80: "size() of the largest possible container"
4694 which, again, doesn't seem to consider fixed size containers
4695 </p>
4696
4697 <p><i>[
4698 2009-05-29 Daniel adds:
4699 ]</i></p>
4700
4701
4702 <blockquote>
4703 <ol type="a">
4704 <li>
4705 <p>
4706 star bullet 1 ("what's the effect of calling <tt>assign(T&amp;)</tt> on a
4707 zero-sized array?[..]");
4708 </p>
4709 <blockquote>
4710 <tt>assign</tt> has been renamed to <tt>fill</tt> and the semantic of <tt>fill</tt> is now
4711 defined in terms of
4712 the free algorithm <tt>fill_n</tt>, which is well-defined for this situation.
4713 </blockquote>
4714 </li>
4715 <li>
4716 <p>
4717 star bullet 3 ("it would be desiderable to have a static const data
4718 member..."):
4719 </p>
4720 <blockquote>
4721 It seems that <tt>tuple_size&lt;array&lt;T, N&gt; &gt;::value</tt> as of 23.3.1.7 [array.tuple] does
4722 provide this functionality now.
4723 </blockquote>
4724 </li>
4725 </ol>
4726 </blockquote>
4727
4728 <p><i>[
4729 2009-07 Frankfurt
4730 ]</i></p>
4731
4732
4733 <blockquote>
4734 <p>
4735 Alisdair to address by the next meeting, or declare NAD.
4736 </p>
4737 <p>
4738 Moved to Tentatively NAD.
4739 </p>
4740 </blockquote>
4741
4742
4743
4744 <p><b>Proposed resolution:</b></p>
4745 <p>
4746 </p>
4747
4748
4749 <p><i>[
4750 Kona (2007): requirements on zero sized <tt>tr1::array</tt>s and other details
4751 Issue 617: <tt>std::array</tt> is a sequence that doesn't satisfy the sequence
4752 requirements? Alisdair will prepare a paper. Proposed Disposition: Open
4753 ]</i></p>
4754
4755
4756
4757
4758
4759 <hr>
4760 <h3><a name="594"></a>594. Disadvantages of defining Swappable in terms of CopyConstructible and Assignable</h3>
4761 <p><b>Section:</b> X [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
4762  <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2006-11-02  <b>Last modified:</b> 2009-07-26</p>
4763 <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>
4764 <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>
4765 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
4766 <p><b>Discussion:</b></p>
4767 <p>
4768 It seems undesirable to define the Swappable requirement in terms of
4769 CopyConstructible and Assignable requirements. And likewise, once the
4770 MoveConstructible and MoveAssignable requirements (N1860) have made it
4771 into the Working Draft, it seems undesirable to define the Swappable
4772 requirement in terms of those requirements. Instead, it appears
4773 preferable to have the Swappable requirement defined exclusively in
4774 terms of the existence of an appropriate swap function.
4775 </p>
4776 <p>
4777 Section 20.1.4 [lib.swappable] of the current Working Draft (N2009)
4778 says:
4779 </p>
4780 <blockquote><p>
4781 The Swappable requirement is met by satisfying one or more of the
4782 following conditions:</p>
4783 <ul>
4784 <li>
4785 T is Swappable if T satisfies the CopyConstructible requirements
4786 (20.1.3) and the Assignable requirements (23.1);
4787 </li>
4788 <li>
4789 T is Swappable if a namespace scope function named swap exists in the
4790 same namespace as the definition of T, such that the expression
4791 swap(t,u) is valid and has the semantics described in Table 33.
4792 </li>
4793 </ul>
4794 </blockquote>
4795 I can think of three disadvantages of this definition:
4796 <ol>
4797 <li>
4798 If a client's type T satisfies the first condition (T is both
4799 CopyConstructible and Assignable), the client cannot stop T from
4800 satisfying the Swappable requirement without stopping T from
4801 satisfying the first condition.
4802 <p>
4803 A client might want to stop T from satisfying the Swappable
4804 requirement, because swapping by means of copy construction and
4805 assignment might throw an exception, and she might find a throwing
4806 swap unacceptable for her type. On the other hand, she might not feel
4807 the need to fully implement her own swap function for this type. In
4808 this case she would want to be able to simply prevent algorithms that
4809 would swap objects of type T from being used, e.g., by declaring a
4810 swap function for T, and leaving this function purposely undefined.
4811 This would trigger a link error, if an attempt would be made to use
4812 such an algorithm for this type. For most standard library
4813 implementations, this practice would indeed have the effect of
4814 stopping T from satisfying the Swappable requirement.
4815 </p>
4816 </li>
4817 <li>
4818 A client's type T that does not satisfy the first condition can not be
4819 made Swappable by providing a specialization of std::swap for T.
4820 <p>
4821 While I'm aware about the fact that people have mixed feelings about
4822 providing a specialization of std::swap, it is well-defined to do so.
4823 It sounds rather counter-intuitive to say that T is not Swappable, if
4824 it has a valid and semantically correct specialization of std::swap.
4825 Also in practice, providing such a specialization will have the same
4826 effect as satisfying the Swappable requirement.
4827 </p>
4828 </li>
4829 <li>
4830 For a client's type T that satisfies both conditions of the Swappable
4831 requirement, it is not specified which of the two conditions prevails.
4832 After reading section 20.1.4 [lib.swappable], one might wonder whether
4833 objects of T will be swapped by doing copy construction and
4834 assignments, or by calling the swap function of T.
4835 <p>
4836 I'm aware that the intention of the Draft is to prefer calling the
4837 swap function of T over doing copy construction and assignments. Still
4838 in my opinion, it would be better to make this clear in the wording of
4839 the definition of Swappable.
4840 </p>
4841 </li>
4842 </ol>
4843 <p>
4844 I would like to have the Swappable requirement defined in such a way
4845 that the following code fragment will correctly swap two objects of a
4846 type T, if and only if T is Swappable:
4847 </p>
4848 <pre>   using std::swap;
4849    swap(t, u);  // t and u are of type T.
4850 </pre>
4851 <p>
4852 This is also the way Scott Meyers recommends calling a swap function,
4853 in Effective C++, Third Edition, item 25.
4854 </p>
4855 <p>
4856 Most aspects of this issue have been dealt with in a discussion on
4857 comp.std.c++ about the Swappable requirement, from 13 September to 4
4858 October 2006, including valuable input by David Abrahams, Pete Becker,
4859 Greg Herlihy, Howard Hinnant and others.
4860 </p>
4861
4862 <p><i>[
4863 San Francisco:
4864 ]</i></p>
4865
4866
4867 <blockquote>
4868 Recommend NAD.  Solved by
4869 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2774.pdf">N2774</a>.
4870 </blockquote>
4871
4872 <p><i>[
4873 2009-07 Frankfurt
4874 ]</i></p>
4875
4876
4877 <blockquote>
4878 Moved to Open.  Waiting for non-concepts draft.
4879 </blockquote>
4880
4881
4882 <p><b>Proposed resolution:</b></p>
4883 <p>
4884 Change section 20.1.4 [lib.swappable] as follows:
4885 </p>
4886 <blockquote><p>
4887 The Swappable requirement is met by satisfying
4888 <del>one or more of the following conditions:</del>
4889 <ins>the following condition:</ins></p>
4890 <ul>
4891
4892 <li>
4893 <del>T is Swappable if T satisfies the CopyConstructible requirements
4894 (20.1.3) and the Assignable requirements (23.1);</del>
4895 </li>
4896 <li>
4897 <del>
4898 T is Swappable if a namespace scope function named swap exists in the
4899 same namespace as the definition of T, such that the expression
4900 swap(t,u) is valid and has the semantics described in Table 33.
4901 </del>
4902 T is Swappable if an unqualified function call swap(t,u) is valid
4903 within the namespace std, and has the semantics described in Table 33.
4904 </li>
4905 </ul>
4906 </blockquote>
4907
4908
4909
4910
4911
4912 <hr>
4913 <h3><a name="617"></a>617. std::array is a sequence that doesn't satisfy the sequence requirements?</h3>
4914 <p><b>Section:</b> 23.3.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
4915  <b>Submitter:</b> Bo Persson <b>Opened:</b> 2006-12-30  <b>Last modified:</b> 2009-07-16</p>
4916 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p>
4917 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
4918 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
4919 <p><b>Discussion:</b></p>
4920 <p>
4921 The <tt>&lt;array&gt;</tt> header is given under 23.3 [sequences].
4922 23.3.1 [array]/paragraph 3 says:
4923 </p>
4924 <blockquote><p>
4925 "Unless otherwise specified, all array operations are as described in
4926 23.2 [container.requirements]".
4927 </p></blockquote>
4928 <p>
4929 However, array isn't mentioned at all in section 23.2 [container.requirements].
4930 In particular, Table 82 "Sequence requirements" lists several operations (insert, erase, clear)
4931 that std::array does not have in 23.3.1 [array].
4932 </p>
4933 <p>
4934 Also, Table 83 "Optional sequence operations" lists several operations that
4935 std::array does have, but array isn't mentioned.
4936 </p>
4937
4938 <p><i>[
4939 2009-07 Frankfurt
4940 ]</i></p>
4941
4942
4943 <blockquote>
4944 <p>
4945 The real issue seems to be different than what is described here.
4946 Non-normative text says that std::array is a sequence container, but
4947 there is disagreement about what that really means. There are two
4948 possible interpretations:
4949 </p>
4950 <ol>
4951 <li>
4952 a sequence container is one that satisfies all sequence container requirements
4953 </li>
4954 <li>
4955 a sequence container is one that satisfies some of the sequence
4956 container requirements. Any operation that the container supports is
4957 specified by one or more sequence container requirements, unless that
4958 operation is specifically singled out and defined alongside the
4959 description of the container itself.
4960 </li>
4961 </ol>
4962 <p>
4963 Move to Tentatively NAD.
4964 </p>
4965 </blockquote>
4966
4967 <p><i>[
4968 2009-07-15 Loïc Joly adds:
4969 ]</i></p>
4970
4971
4972 <blockquote>
4973 <p>
4974 The section 23.2.3 [sequence.reqmts]/1 states that array is a sequence. 23.2.3 [sequence.reqmts]/3
4975 introduces table 83, named Sequence container requirements. This seems
4976 to me to be defining the requirements for all sequences. However, array
4977 does not follow all of this requirements (this can be read in the array
4978 specific section, for the standard is currently inconsistent).
4979 </p>
4980
4981 <p>
4982 Proposed resolution 1 (minimal change):
4983 </p>
4984 <blockquote>
4985 <p>
4986 Say that array is a container, that in addition follows only some of the
4987 sequence requirements, as described in the array section:
4988 </p>
4989
4990 <blockquote>
4991 The library provides <del>five</del> <ins>three</ins> basic kinds of sequence containers: <del><tt>array</tt></del>,
4992 <tt>vector</tt>,
4993 <del><tt>forward_list</tt></del>, <tt>list</tt>, and <tt>deque</tt>. <ins>In addition, <tt>array</tt>
4994 and <tt>forward_list</tt> follows some of the requirements
4995 of sequences, as described in their respective sections.</ins>
4996 </blockquote>
4997
4998 </blockquote>
4999
5000 <p>
5001 Proposed resolution 2 (most descriptive description, no full wording provided):
5002 </p>
5003 <blockquote>
5004 Introduce the notion of a Fixed Size Sequence, with it requirement table
5005 that would be a subset of the current Sequence container. array would be
5006 the only Fixed Size Sequence (but dynarray is in the queue for TR2).
5007 Sequence requirements would now be requirements in addition to Fixed
5008 Size Sequence requirements (it is currently in addition to container).
5009 </blockquote>
5010 </blockquote>
5011
5012 <p><i>[
5013 2009-07 Frankfurt:
5014 ]</i></p>
5015
5016
5017 <blockquote>
5018 Move to NAD Editorial
5019 </blockquote>
5020
5021
5022
5023 <p><b>Proposed resolution:</b></p>
5024 <p>
5025 </p>
5026
5027
5028
5029
5030
5031 <hr>
5032 <h3><a name="625"></a>625. mixed up <i>Effects</i> and <i>Returns</i> clauses</h3>
5033 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
5034  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20  <b>Last modified:</b> 2009-07-15</p>
5035 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
5036 <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>
5037 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
5038 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#895">895</a></p>
5039 <p><b>Discussion:</b></p>
5040  <p>
5041
5042 Many member functions of <code>basic_string</code> are overloaded,
5043 with some of the overloads taking a <code>string</code> argument,
5044 others <code>value_type*</code>, others <code>size_type</code>, and
5045 others still <code>iterators</code>. Often, the requirements on one of
5046 the overloads are expressed in the form of <i>Effects</i>,
5047 <i>Throws</i>, and in the Working Paper
5048 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>)
5049 also <i>Remark</i> clauses, while those on the rest of the overloads
5050 via a reference to this overload and using a <i>Returns</i> clause.
5051 </p>
5052
5053 <p>
5054 The difference between the two forms of specification is that per
5055 17.5.1.4 [structure.specifications], p3, an <i>Effects</i> clause specifies
5056 <i>"actions performed by the functions,"</i> i.e., its observable
5057 effects, while a <i>Returns</i> clause is <i>"a description of the
5058 return value(s) of a function"</i> that does not impose any
5059 requirements on the function's observable effects.
5060 </p>
5061
5062 <p>
5063 Since only <i>Notes</i> are explicitly defined to be informative and
5064 all other paragraphs are explicitly defined to be normative, like
5065 <i>Effects</i> and <i>Returns</i>, the new <i>Remark</i> clauses also
5066 impose normative requirements.
5067 </p>
5068
5069 <p>
5070 So by this strict reading of the standard there are some member
5071 functions of <code>basic_string</code> that are required to throw an
5072 exception under some conditions or use specific traits members while
5073 many other otherwise equivalent overloads, while obliged to return the
5074 same values, aren't required to follow the exact same requirements
5075 with regards to the observable effects.
5076 </p>
5077
5078 <p>
5079 Here's an example of this problem that was precipitated by the change
5080 from informative Notes to normative <i>Remark</i>s (presumably made to
5081 address <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>):
5082 </p>
5083
5084 <p>
5085 In the Working Paper, <code>find(string, size_type)</code> contains a
5086 <i>Remark</i> clause (which is just a <i>Note</i> in the current
5087 standard) requiring it to use <code>traits::eq()</code>.
5088 </p>
5089
5090 <p>
5091 <code>find(const charT *s, size_type pos)</code> is specified to
5092 return <code>find(string(s), pos)</code> by a <i>Returns</i> clause
5093 and so it is not required to use <code>traits::eq()</code>. However,
5094 the Working Paper has replaced the original informative <i>Note</i>
5095 about the function using <code>traits::length()</code> with a
5096 normative requirement in the form of a <i>Remark</i>. Calling
5097 <code>traits::length()</code> may be suboptimal, for example when the
5098 argument is a very long array whose initial substring doesn't appear
5099 anywhere in <code>*this</code>.
5100 </p>
5101
5102 <p>
5103 Here's another similar example, one that existed even prior to the
5104 introduction of <i>Remark</i>s:
5105 </p>
5106
5107 <p>
5108 <code> insert(size_type pos, string, size_type, size_type)</code> is
5109 required to throw <code>out_of_range</code> if <code>pos &gt;
5110 size()</code>.
5111 </p>
5112
5113 <p>
5114 <code>insert(size_type pos, string str)</code> is specified to return
5115 <code>insert(pos, str, 0, npos)</code> by a <i>Returns</i> clause and
5116 so its effects when <code>pos &gt; size()</code> are strictly speaking
5117 unspecified.
5118 </p><p>
5119
5120 </p>
5121 I believe a careful review of the current <i>Effects</i> and
5122 <i>Returns</i> clauses is needed in order to identify all such
5123 problematic cases. In addition, a review of the Working Paper should
5124 be done to make sure that the newly introduced normative <i>Remark</i>
5125 clauses do not impose any undesirable normative requirements in place
5126 of the original informative <i>Notes</i>.
5127
5128
5129 <p><i>[
5130 Batavia: Alan and Pete to work.
5131 ]</i></p>
5132
5133
5134 <p><i>[
5135 Bellevue: Marked as NAD Editorial.
5136 ]</i></p>
5137
5138
5139 <p><i>[
5140 Post-Sophia Antipolis:
5141 Martin indicates there is still work to be done on this issue.
5142 Reopened.
5143 ]</i></p>
5144
5145
5146 <p><i>[
5147 Batavia (2009-05):
5148 ]</i></p>
5149
5150 <blockquote>
5151 Tom proposes we say that, unless specified otherwise,
5152 it is always the caller's responsibility to verify that supplied arguments
5153 meet the called function's requirements.
5154 If further semantics are specified
5155 (e.g., that the function throws under certain conditions),
5156 then it is up to the implementer to check those conditions.
5157 Alan feels strongly that our current use of Requires in this context
5158 is confusing, especially now that <tt>requires</tt> is a new keyword.
5159 </blockquote>
5160
5161 <p><i>[
5162 2009-07 Frankfurt
5163 ]</i></p>
5164
5165
5166 <blockquote>
5167 Move to Tentatively NAD.
5168 </blockquote>
5169
5170
5171
5172 <p><b>Proposed resolution:</b></p>
5173 <p>
5174 </p>
5175
5176
5177
5178
5179
5180 <hr>
5181 <h3><a name="630"></a>630. arrays of valarray</h3>
5182 <p><b>Section:</b> 26.6.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
5183  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-28  <b>Last modified:</b> 2009-07-15</p>
5184 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cons">issues</a> in [valarray.cons].</p>
5185 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
5186 <p><b>Discussion:</b></p>
5187         <p>
5188
5189 Section 26.2 [numeric.requirements], p1     suggests     that     a
5190 <code>valarray</code>  specialization on  a  type <code>T</code>  that
5191 satisfies  the requirements enumerated  in the  paragraph is  itself a
5192 valid  type   on  which  <code>valarray</code>   may  be  instantiated
5193 (Footnote       269        makes       this       clear).        I.e.,
5194 <code>valarray&lt;valarray&lt;T&gt;  &gt;</code> is  valid as  long as
5195 <code>T</code>   is   valid.    However,  since   implementations   of
5196 <code>valarray</code> are permitted to initialize storage allocated by
5197 the class by  invoking the default ctor of  <code>T</code> followed by
5198 the    copy    assignment    operator,   such    implementations    of
5199 <code>valarray</code>   wouldn't  work  with   (perhaps  user-defined)
5200 specializations of <code>valarray</code> whose assignment operator had
5201 undefined behavior when the size of its argument didn't match the size
5202 of <code>*this</code>.  By <i>"wouldn't work"</i> I mean that it would
5203 be  impossible  to resize  such  an array  of  arrays  by calling  the
5204 <code>resize()</code> member  function on it if the  function used the
5205 copy  assignment operator  after constructing  all elements  using the
5206 default  ctor (e.g.,  by invoking  <code>new  value_type[N]</code>) to
5207 obtain default-initialized storage) as it's permitted to do.
5208
5209         </p>
5210         <p>
5211
5212 Stated      more     generally,      the      problem     is      that
5213 <code>valarray&lt;valarray&lt;T&gt;  &gt;::resize(size_t)</code> isn't
5214 required or  guaranteed to have well-defined semantics  for every type
5215 <code>T</code>     that      satisfies     all     requirements     in
5216 26.2 [numeric.requirements].
5217
5218         </p>
5219         <p>
5220
5221 I  believe  this  problem  was  introduced  by  the  adoption  of  the
5222 resolution                outlined                in                <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0857.asc">N0857</a>,
5223 <i>Assignment  of  valarrays</i>,  from  1996.   The  copy  assignment
5224 operator  of  the original  numerical  array  classes  proposed in  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0280.pdf">N0280</a>,
5225 as      well       as      the      one       proposed      in      <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0308.asc">N0308</a>
5226 (both  from 1993), had  well-defined semantics  for arrays  of unequal
5227 size (the  latter explicitly  only when <code>*this</code>  was empty;
5228 assignment of non empty arrays of unequal size was a runtime error).
5229
5230         </p>
5231         <p>
5232
5233 The  justification for  the  change given  in  N0857 was the "loss  of
5234 performance [deemed]  only significant  for very simple  operations on
5235 small arrays or for architectures with very few registers."
5236
5237         </p>
5238         <p>
5239
5240 Since tiny  arrays on a  limited subset of hardware  architectures are
5241 likely  to  be  an   exceedingly  rare  case  (despite  the  continued
5242 popularity of  x86) I  propose to revert  the resolution and  make the
5243 behavior    of   all   <code>valarray</code>    assignment   operators
5244 well-defined even  for non-conformal  arrays (i.e., arrays  of unequal
5245 size).   I have implemented  this change  and measured  no significant
5246 degradation  in performance in  the common  case (non-empty  arrays of
5247 equal size).  I  have measured a 50% (and in  some cases even greater)
5248 speedup  in the  case of  assignments to  empty arrays  versus calling
5249 <code>resize()</code>  first followed  by  an invocation  of the  copy
5250 assignment operator.
5251
5252         </p>
5253
5254 <p><i>[
5255 Bellevue:
5256 ]</i></p>
5257
5258
5259 <blockquote>
5260 If no proposed wording by June meeting, this issue should be closed NAD.
5261 </blockquote>
5262
5263 <p><i>[
5264 2009-07 Frankfurt
5265 ]</i></p>
5266
5267
5268 <blockquote>
5269 <p>
5270 Move resolution 1 to Ready.
5271 </p>
5272 <p>
5273 Howard: second resolution has been commented out (made invisible).
5274 Can be brought back on demand.
5275 </p>
5276 </blockquote>
5277
5278
5279
5280 <p><b>Proposed resolution:</b></p>
5281         <p>
5282
5283 Change 26.6.2.2 [valarray.assign], p1 as follows:
5284
5285         </p>
5286         <blockquote>
5287             <p>
5288                 <code>
5289
5290 valarray&lt;T&gt;&amp; operator=(const valarray&lt;T&gt;&amp;<ins> x</ins>);
5291
5292                 </code>
5293             </p>
5294             <p>
5295
5296 -1- Each element of the <code>*this</code> array is assigned the value
5297 of  the  corresponding  element   of  the  argument  array.   <del>The
5298 resulting behavior is undefined if </del><ins>When </ins>the length of
5299 the  argument  array  is  not   equal  to  the  length  of  the  *this
5300 array<del>.</del><ins>  resizes  <code>*this</code>  to make  the  two
5301 arrays     the      same     length,     as      if     by     calling
5302 <code>resize(x.size())</code>, before performing the assignment.</ins>
5303
5304             </p>
5305         </blockquote>
5306         <p>
5307
5308 And  add a new  paragraph just  below paragraph  1 with  the following
5309 text:
5310
5311         </p>
5312         <blockquote>
5313             <p>
5314
5315 <ins>-2- <i>Postcondition</i>: <code>size() == x.size()</code>.</ins>
5316
5317             </p>
5318         </blockquote>
5319         <p>
5320
5321 Also add the following paragraph to 26.6.2.2 [valarray.assign], immediately after p4:
5322
5323         </p>
5324         <blockquote>
5325             <p>
5326
5327 <ins>-?- When the length,  <i><code>N</code></i> of the array referred
5328 to by the  argument is not equal to  the length of <code>*this</code>,
5329 the  operator resizes <code>*this</code>  to make  the two  arrays the
5330 same  length, as if  by calling  <code>resize(<i>N</i>)</code>, before
5331 performing the assignment.</ins>
5332
5333             </p>
5334         </blockquote>
5335
5336 <p><i>[
5337 pre-Sophia Antipolis, Martin adds the following compromise wording, but
5338 prefers the original proposed resolution:
5339 ]</i></p>
5340
5341
5342
5343
5344
5345
5346 <p><i>[
5347 Kona (2007): Gaby to propose wording for an alternative resolution in
5348 which you can assign to a <tt>valarray</tt> of size 0, but not to any other
5349 <tt>valarray</tt> whose size is unequal to the right hand side of the assignment.
5350 ]</i></p>
5351
5352
5353
5354
5355
5356 <hr>
5357 <h3><a name="631"></a>631. conflicting requirements for <tt>BinaryPredicate</tt></h3>
5358 <p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
5359  <b>Submitter:</b> James Kanze <b>Opened:</b> 2007-01-31  <b>Last modified:</b> 2009-07-28</p>
5360 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#algorithms">active issues</a> in [algorithms].</p>
5361 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#algorithms">issues</a> in [algorithms].</p>
5362 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
5363 <p><b>Discussion:</b></p>
5364 <p>
5365 The general requirements for <tt><tt>BinaryPredicate</tt></tt> (in 25 [algorithms]/8) contradict the implied specific requirements for
5366 some functions. In particular, it says that:
5367 </p>
5368
5369 <blockquote><p>
5370 [...] if an algorithm takes <tt>BinaryPredicate <i>binary_pred</i></tt>
5371 as its argument and <tt><i>first1</i></tt> and <i>first2</i> as its
5372 iterator arguments, it should work correctly in the construct <tt>if
5373 (binary_pred (*<i>first1</i> , *<i>first2</i> )){...}</tt>.
5374 <tt>BinaryPredicate</tt> always takes the first iterator type as its
5375 first argument, that is, in those cases when <tt>T <i>value</i></tt> is
5376 part of the signature, it should work correctly in the context of <tt>if
5377 (binary_pred (*<i>first1</i> , <i>value</i>)){...}</tt>.
5378 </p></blockquote>
5379
5380 <p>
5381 In the description of <tt>upper_bound</tt> (25.5.3.2 [upper.bound]/2), however, the use is described as
5382 "<tt>!comp(<i>value</i>, <i>e</i>)</tt>", where <tt><i>e</i></tt> is an
5383 element of the sequence (a result of dereferencing
5384 <tt>*<i>first</i></tt>).
5385 </p>
5386
5387 <p>
5388 In the description of <tt>lexicographical_compare</tt>, we have both
5389 "<tt>*<i>first1</i> &lt; *<i>first2</i></tt>" and "<tt>*<i>first2</i>
5390 &lt; *<i>first1</i></tt>" (which presumably implies "<tt>comp(
5391 *<i>first1</i>, *<i>first2</i> )</tt>" and "<tt>comp( *<i>first2</i>,
5392 *<i>first1</i> )</tt>".
5393 </p>
5394
5395 <p><i>[
5396 Toronto:  Moved to Open.  ConceptGCC seems to get <tt>lower_bound</tt>
5397 and <tt>upper_bound</tt> to work withoutt these changes.
5398 ]</i></p>
5399
5400
5401 <p><i>[
5402 2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
5403 ]</i></p>
5404
5405
5406
5407
5408 <p><b>Proposed resolution:</b></p>
5409 <p>
5410 Logically, the <tt>BinaryPredicate</tt> is used as an ordering
5411 relationship, with the semantics of "less than".  Depending on the
5412 function, it may be used to determine equality, or any of the inequality
5413 relationships; doing this requires being able to use it with either
5414 parameter first.  I would thus suggest that the requirement be:
5415 </p>
5416
5417 <blockquote><p>
5418 [...] <tt>BinaryPredicate</tt> always takes the first iterator
5419 <tt>value_type</tt> as one of its arguments, it is unspecified which. If
5420 an algorithm takes <tt>BinaryPredicate <i>binary_pred</i></tt> as its
5421 argument and <tt><i><i>first1</i></i></tt> and <i>first2</i> as its
5422 iterator arguments, it should work correctly both in the construct
5423 <tt>if (binary_pred (*<i>first1</i> , *<i>first2</i> )){...}</tt> and
5424 <tt>if (binary_pred (*<i>first2</i>, *<i>first1</i>)){...}</tt>.  In
5425 those cases when <tt>T <i>value</i></tt> is part of the signature, it
5426 should work correctly in the context of <tt>if (binary_pred
5427 (*<i>first1</i> , <i>value</i>)){...}</tt> and of <tt>if (binary_pred
5428 (<i>value</i>, *<i>first1</i>)){...}</tt>. [<i>Note:</i> if the two
5429 types are not identical, and neither is convertable to the other, this
5430 may require that the <tt>BinaryPredicate</tt> be a functional object
5431 with two overloaded <tt>operator()()</tt> functions. <i>--end note</i>]
5432 </p></blockquote>
5433
5434 <p>
5435 Alternatively, one could specify an order for each function. IMHO, this
5436 would be more work for the committee, more work for the implementors,
5437 and of no real advantage for the user: some functions, such as
5438 <tt>lexicographical_compare</tt> or <tt>equal_range</tt>, will still require both
5439 functions, and it seems like a much easier rule to teach that both
5440 functions are always required, rather than to have a complicated list of
5441 when you only need one, and which one.
5442 </p>
5443
5444
5445 <p><b>Rationale:</b></p>
5446 <p><i>[
5447 post San Francisco:
5448 ]</i></p>
5449
5450
5451 <blockquote>
5452 Solved by
5453 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/N2759.pdf">N2759</a>.
5454 </blockquote>
5455
5456
5457
5458
5459
5460
5461 <hr>
5462 <h3><a name="635"></a>635. domain of <tt>allocator::address</tt></h3>
5463 <p><b>Section:</b> X [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
5464  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-02-08  <b>Last modified:</b> 2009-07-28</p>
5465 <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>
5466 <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>
5467 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
5468 <p><b>Discussion:</b></p>
5469 <p>
5470 The table of allocator requirements in X [allocator.requirements] describes
5471 <tt>allocator::address</tt> as:
5472 </p>
5473 <blockquote><pre>a.address(r)
5474 a.address(s)
5475 </pre></blockquote>
5476 <p>
5477 where <tt>r</tt> and <tt>s</tt> are described as:
5478 </p>
5479 <blockquote><p>
5480 a value of type <tt>X::reference</tt> obtained by the expression <tt>*p</tt>.
5481 </p></blockquote>
5482
5483 <p>
5484 and <tt>p</tt> is
5485 </p>
5486
5487 <blockquote><p>
5488 a value of type <tt>X::pointer</tt>, obtained by calling <tt>a1.allocate</tt>,
5489 where <tt>a1 == a</tt>
5490 </p></blockquote>
5491
5492 <p>
5493 This all implies that to get the address of some value of type <tt>T</tt> that
5494 value must have been allocated by this allocator or a copy of it.
5495 </p>
5496
5497 <p>
5498 However sometimes container code needs to compare the address of an external value of
5499 type <tt>T</tt> with an internal value.  For example <tt>list::remove(const T&amp; t)</tt>
5500 may want to compare the address of the external value <tt>t</tt> with that of a value
5501 stored within the list.  Similarly <tt>vector</tt> or <tt>deque insert</tt> may
5502 want to make similar comparisons (to check for self-referencing calls).
5503 </p>
5504
5505 <p>
5506 Mandating that <tt>allocator::address</tt> can only be called for values which the
5507 allocator allocated seems overly restrictive.
5508 </p>
5509
5510 <p><i>[
5511 post San Francisco:
5512 ]</i></p>
5513
5514
5515 <blockquote>
5516 Pablo recommends NAD Editorial, solved by
5517 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2768.pdf">N2768</a>.
5518 </blockquote>
5519
5520 <p><i>[
5521 2009-04-28 Pablo adds:
5522 ]</i></p>
5523
5524
5525 <blockquote>
5526 Tentatively-ready NAD Editorial as fixed by
5527 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2768.pdf">N2768</a>.
5528 </blockquote>
5529
5530 <p><i>[
5531 2009-07 Frankfurt
5532 ]</i></p>
5533
5534
5535 <blockquote>
5536 Fixed by N2768.
5537 </blockquote>
5538
5539 <p><i>[
5540 2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
5541 ]</i></p>
5542
5543
5544
5545
5546 <p><b>Proposed resolution:</b></p>
5547 <p>
5548 Change X [allocator.requirements]:
5549 </p>
5550
5551 <blockquote>
5552 <p>
5553 <tt>r</tt> : a value of type <tt>X::reference</tt> <del>obtained by the expression *p</del>.
5554 </p>
5555 <p>
5556 <tt>s</tt> : a value of type <tt>X::const_reference</tt> <del>obtained by the
5557 expression <tt>*q</tt> or by conversion from a value <tt>r</tt></del>.
5558 </p>
5559 </blockquote>
5560
5561 <p><i>[
5562 post Oxford:  This would be rendered NAD Editorial by acceptance of
5563 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
5564 ]</i></p>
5565
5566
5567 <p><i>[
5568 Kona (2007):  This issue is section 8 of N2387.  There was some discussion of it but
5569 no resolution to this issue was recorded.  Moved to Open.
5570 ]</i></p>
5571
5572
5573
5574
5575
5576
5577
5578 <hr>
5579 <h3><a name="659"></a>659. istreambuf_iterator should have an operator-&gt;()</h3>
5580 <p><b>Section:</b> 24.6.3 [istreambuf.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
5581  <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2007-03-25  <b>Last modified:</b> 2009-07-15</p>
5582 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istreambuf.iterator">issues</a> in [istreambuf.iterator].</p>
5583 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
5584 <p><b>Discussion:</b></p>
5585 <p>
5586 Greg Herlihy has clearly demonstrated that a user defined input
5587 iterator should have an operator-&gt;(), even if its
5588 value type is a built-in type (comp.std.c++, "Re: Should any iterator
5589 have an operator-&gt;() in C++0x?", March 2007).  And as Howard
5590 Hinnant remarked in the same thread that the input iterator
5591 <tt>istreambuf_iterator</tt> doesn't have one, this must be a
5592 defect!
5593 </p>
5594 <p>
5595 Based on Greg's example, the following code demonstrates the issue:
5596 </p><pre> #include &lt;iostream&gt;
5597  #include &lt;fstream&gt;
5598  #include &lt;streambuf&gt;
5599
5600  typedef char C;
5601  int main ()
5602  {
5603    std::ifstream s("filename", std::ios::in);
5604    std::istreambuf_iterator&lt;char&gt; i(s);
5605
5606    (*i).~C();  // This is well-formed...
5607    i-&gt;~C();  // ... so this should be supported!
5608  }
5609 </pre>
5610
5611 <p>
5612 Of course, operator-&gt; is also needed when the value_type of
5613 istreambuf_iterator is a class.
5614 </p>
5615 <p>
5616 The operator-&gt; could be implemented in various ways.  For instance,
5617 by storing the current value inside the iterator, and returning its
5618 address.  Or by returning a proxy, like operator_arrow_proxy, from
5619 <a href="http://www.boost.org/boost/iterator/iterator_facade.hpp">http://www.boost.org/boost/iterator/iterator_facade.hpp</a>
5620 </p>
5621 <p>
5622 I hope that the resolution of this issue will contribute to getting a
5623 clear and consistent definition of iterator concepts.
5624 </p>
5625
5626 <p><i>[
5627 Kona (2007): The proposed resolution is inconsistent because the return
5628 type of <tt>istreambuf_iterator::operator-&gt;()</tt> is specified to be <tt>pointer</tt>,
5629 but the proposed text also states that "<tt>operator-&gt;</tt> may return a proxy."
5630 ]</i></p>
5631
5632
5633 <p><i>[
5634 Niels Dekker (mailed to Howard Hinnant):
5635 ]</i></p>
5636
5637 <blockquote>
5638 <p>
5639 The proposed resolution does
5640 not seem inconsistent to me. <tt>istreambuf_iterator::operator-&gt;()</tt> should
5641 have <tt>istreambuf_iterator::pointer</tt> as return type, and this return type
5642 may in fact be a proxy.
5643 </p>
5644 <p>
5645 AFAIK, the resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#445">445</a> ("<tt>iterator_traits::reference</tt>
5646 unspecified for some iterator categories") implies that for any iterator
5647 class <tt>Iter</tt>, the return type of <tt>operator-&gt;()</tt> is <tt>Iter::pointer</tt>, by
5648 definition.  I don't think <tt>Iter::pointer</tt> needs to be a raw pointer.
5649 </p>
5650 <p>
5651 Still I wouldn't mind if the text "<tt>operator-&gt;</tt> may return a proxy" would
5652 be removed from the resolution. I think it's up to the library
5653 implementation, how to implement <tt>istreambuf_iterator::operator-&gt;()</tt>.  As
5654 longs as it behaves as expected: <tt>i-&gt;m</tt> should have the same effect as
5655 <tt>(*i).m</tt>. Even for an explicit destructor call, <tt>i-&gt;~C()</tt>.  The main issue
5656 is just: <tt>istreambuf_iterator</tt> should have an <tt>operator-&gt;()</tt>!
5657 </p>
5658 </blockquote>
5659
5660 <p><i>[
5661 2009-04-30 Alisdair adds:
5662 ]</i></p>
5663
5664
5665 <blockquote>
5666 Note that operator-&gt; is now a requirement in the <tt>InputIterator</tt> concept, so
5667 this issue cannot be ignored or existing valid programs will break when
5668 compiled with an 0x library.
5669 </blockquote>
5670
5671 <p><i>[
5672 2009-05-29 Alisdair adds:
5673 ]</i></p>
5674
5675
5676 <blockquote>
5677 <p>
5678 I agree with the observation that in principle the type 'pointer' may be a
5679 proxy, and the words highlighting this are redundant.
5680 </p>
5681 <p>
5682 However, in the current draught <tt>pointer</tt> is required to be exactly '<tt>charT *</tt>'
5683 by the derivation from <tt>std::iterator</tt>.  At a minimum, the 4th parameter of
5684 this base class template should become unspecified.  That permits the
5685 introduction of a proxy as a nested class in some further undocumented (not
5686 even exposition-only) base.
5687 </p>
5688 <p>
5689 It also permits the <tt>istream_iterator</tt> approach where the cached value is
5690 stored in the iterator itself, and the iterator serves as its own proxy for
5691 post-increment <tt>operator++</tt> - removing the need for the existing
5692 exposition-only nested class <tt>proxy</tt>.
5693 </p>
5694 <p>
5695 Note that the current <tt>proxy</tt> class also has exactly the right properties to
5696 serve as the pointer <tt>proxy</tt> too.  This is likely to be a common case where an
5697 <tt>InputIterator</tt> does not hold internal state but delegates to another class.
5698 </p>
5699 <p>
5700 Proposed Resolution:
5701 </p>
5702 <p>
5703 In addition to the current proposal:
5704 </p>
5705 <p>
5706 24.6.3 [istreambuf.iterator]
5707 </p>
5708 <blockquote><pre>template&lt;class charT, class traits = char_traits&lt;charT&gt; &gt;
5709 class istreambuf_iterator
5710   : public iterator&lt;input_iterator_tag, charT,
5711                     typename traits::off_type, <del>charT*</del> <ins><i>unspecified</i></ins>, charT&gt; {
5712 </pre></blockquote>
5713 </blockquote>
5714
5715 <p><i>[
5716 2009-07 Frankfurt
5717 ]</i></p>
5718
5719
5720 <blockquote>
5721 <p>
5722 Move the additional part into the proposed resolution, and wrap the
5723 descriptive text in a Note.
5724 </p>
5725 <p><i>[Howard: done.]</i></p>
5726
5727 <p>
5728 Move to Ready.
5729 </p>
5730 </blockquote>
5731
5732
5733
5734 <p><b>Proposed resolution:</b></p>
5735 <p>
5736 Add to the synopsis in 24.6.3 [istreambuf.iterator]:
5737 </p>
5738
5739 <blockquote><pre>charT operator*() const;
5740 <ins>pointer operator-&gt;() const;</ins>
5741 istreambuf_iterator&lt;charT,traits&gt;&amp; operator++();
5742 </pre></blockquote>
5743
5744 <p>
5745 24.6.3 [istreambuf.iterator]
5746 </p>
5747
5748 <blockquote><pre>template&lt;class charT, class traits = char_traits&lt;charT&gt; &gt;
5749 class istreambuf_iterator
5750   : public iterator&lt;input_iterator_tag, charT,
5751                     typename traits::off_type, <del>charT*</del> <ins><i>unspecified</i></ins>, charT&gt; {
5752 </pre></blockquote>
5753
5754 <p>
5755 Change 24.6.3 [istreambuf.iterator], p1:
5756 </p>
5757
5758 <blockquote><p>
5759 The class template <tt>istreambuf_iterator</tt> reads successive
5760 characters from the <tt>streambuf</tt> for which it was constructed.
5761 <tt>operator*</tt> provides access to the current input character, if
5762 any. <ins>[<i>Note:</i> <tt>operator-&gt;</tt> may return a proxy. &#8212;
5763 <i>end note</i>]</ins> Each time
5764 <tt>operator++</tt> is evaluated, the iterator advances to the next
5765 input character. If the end of stream is reached
5766 (<tt>streambuf_type::sgetc()</tt> returns <tt>traits::eof()</tt>), the
5767 iterator becomes equal to the end of stream iterator value. The default
5768 constructor <tt>istreambuf_iterator()</tt> and the constructor
5769 <tt>istreambuf_iterator(0)</tt> both construct an end of stream iterator
5770 object suitable for use as an end-of-range.
5771 </p></blockquote>
5772
5773
5774
5775
5776
5777
5778
5779 <hr>
5780 <h3><a name="668"></a>668. <tt>money_get</tt>'s empty minus sign</h3>
5781 <p><b>Section:</b> 22.4.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
5782  <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16  <b>Last modified:</b> 2009-07-20</p>
5783 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p>
5784 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
5785 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
5786 <p><b>Discussion:</b></p>
5787 <p>
5788 22.4.6.1.2 [locale.money.get.virtuals], para 3 says:
5789 </p>
5790
5791 <blockquote><p>
5792 If <tt>pos</tt> or <tt>neg</tt> is empty, the sign component is
5793 optional, and if no sign is detected, the result is given the sign
5794 that corresponds to the source of the empty string.
5795 </p></blockquote>
5796
5797 <p>
5798 The following objection has been raised:
5799 </p>
5800
5801 <blockquote><p>
5802 A <tt>negative_sign</tt> of "" means "there is no
5803 way to write a negative sign" not "any null sequence is a negative
5804 sign, so it's always there when you look for it".
5805 </p></blockquote>
5806
5807 <p>
5808 [Plum ref _222612Y32]
5809 </p>
5810
5811 <p><i>[
5812 Kona (2007): Bill to provide proposed wording and interpretation of existing wording.
5813 ]</i></p>
5814
5815
5816 <p>
5817 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>.
5818 </p>
5819
5820 <p><i>[
5821 2009-05-17 Howard adds:
5822 ]</i></p>
5823
5824
5825 <blockquote>
5826 <p>
5827 I disagree that a <tt>negative_sign</tt> of "" means "there is no
5828 way to
5829 write a negative sign". The meaning requires the sentences of
5830 22.4.6.1.2 [locale.money.get.virtuals] p3 following that quoted above
5831 to be
5832 taken into account:
5833 </p>
5834
5835 <blockquote>
5836 -3- ... If <tt>pos</tt> or <tt>neg</tt> is empty, the sign component is
5837 optional, and if no sign is detected, the result is given the sign that
5838 corresponds to the source of the empty string. Otherwise, the character
5839 in the indicated position must match the first character of <tt>pos</tt>
5840 or <tt>neg</tt>, and the result is given the corresponding sign. If the
5841 first character of <tt>pos</tt> is equal to the first character of
5842 <tt>neg</tt>, or if both strings are empty, the result is given a
5843 positive sign.
5844 </blockquote>
5845
5846 <p>
5847 So a <tt>negative_sign</tt> of "" means "there is no way to write a
5848 negative sign" only when <tt>positive_sign</tt> is also "".  However
5849 when <tt>negative_sign</tt> is "" and <tt>postive_sign.size() &gt;
5850 0</tt>, then one writes a negative value by not writing the
5851 <tt>postive_sign</tt> in the position indicated by
5852 <tt>money_base::sign</tt>.
5853 For example:
5854 </p>
5855
5856 <blockquote><pre>pattern = {symbol, sign, value, none}
5857 positive_sign = "+"
5858 negative_sign = ""
5859 $123   // a negative value, using optional sign
5860 $+123  // a positive value
5861 $-123  // a parse error
5862 </pre></blockquote>
5863
5864 <p>
5865 And:
5866 </p>
5867
5868 <blockquote><pre>pattern = {symbol, sign, value, none}
5869 positive_sign = ""
5870 negative_sign = ""
5871 $123   // a positive value, no sign possible
5872 $+123  // a parse error
5873 $-123  // a parse error
5874 </pre></blockquote>
5875
5876
5877 <p>
5878 And (regarding <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>):
5879 </p>
5880
5881 <blockquote><pre>pattern = {symbol, sign, value, none}
5882 positive_sign = "-"
5883 negative_sign = "-"
5884 $123   // a parse error, sign is mandatory
5885 $+123  // a parse error
5886 $-123  // a positive value
5887 </pre></blockquote>
5888
5889
5890 <p>
5891 The text seems both unambiguous and clear to me.  I recommend NAD for
5892 both this issue and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>.  However I would have no
5893 objection to adding examples such as those above.
5894 </p>
5895 </blockquote>
5896
5897 <p><i>[
5898 Batavia (2009-05):
5899 ]</i></p>
5900
5901 <blockquote>
5902 <p>
5903 This discussion applies equally to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a> (q.v.).
5904 Howard has added examples above,
5905 and recommends either NAD or a resolution that adds his (or similar) examples
5906 to the Working Paper.
5907 </p>
5908 <p>
5909 Alan would like to rewrite paragraph 3.
5910 </p>
5911 <p>
5912 We recommend moving to NAD.
5913 Anyone who feels strongly about adding the examples
5914 is invited to submit corresponding wording.
5915 We further recommend issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a> be handled identically.
5916 </p>
5917 </blockquote>
5918
5919 <p><i>[
5920 2009-07-14 Alan reopens with improved wording.
5921 ]</i></p>
5922
5923
5924 <p><i>[
5925 2009-07 Frankfurt
5926 ]</i></p>
5927
5928
5929 <blockquote>
5930 No consensus for closing as NAD.  Leave in Review.
5931 </blockquote>
5932
5933
5934
5935 <p><b>Proposed resolution:</b></p>
5936 <p>
5937 Change 22.4.6.1.2 [locale.money.get.virtuals] p3:
5938 </p>
5939
5940 <blockquote>
5941 -3- <del>If the first character (if any) in the string pos returned by
5942 <tt>mp.positive_sign()</tt> or the string <tt>neg</tt> returned by
5943 <tt>mp.negative_sign()</tt> is recognized in the position indicated by
5944 sign in the format pattern, it is consumed and any remaining characters
5945 in the string are required after all the other format components.
5946 [<i>Example:</i> If <tt>showbase</tt> is off&#65533;, then for a <tt>neg</tt>
5947 value of "()" and a currency symbol of "L", in "(100 L)" the "L" is
5948 consumed; but if <tt>neg</tt> is "-", the "L" in "-100 L" is not
5949 consumed. -- <i>end example</i>] If <tt>pos</tt> or <tt>neg</tt> is
5950 empty, the sign component is optional, and if no sign is detected, the
5951 result is given the sign that corresponds to the source of the empty
5952 string. Otherwise, the character in the indicated position must match
5953 the first character of <tt>pos</tt> or <tt>neg</tt>, and the result is
5954 given the corresponding sign. If the first character of <tt>pos</tt> is
5955 equal to the first character of <tt>neg</tt>, or if both strings are
5956 empty, the result is given a positive sign.</del>
5957
5958 <ins>The sign pattern strings <tt>pos</tt> and <tt>neg</tt> are returned by
5959 <tt>mp.positive_sign()</tt> and <tt>mp.negative_sign()</tt> respectively. A sign pattern
5960 is matched if its first character is recognized in <tt>s</tt> in the position
5961 indicated by <tt>sign</tt> in the format pattern, or if the pattern is empty and
5962 there is no sign recognized in <tt>s</tt>. A match is required to occur. If both
5963 patterns are matched, the result is given a positive sign, otherwise the
5964 result is given the sign corresponding to the matched pattern.
5965 If the pattern contains more than one character, the characters after the first
5966 must be matched in <tt>s</tt> after all other format components.
5967 If any sign
5968 characters are matched, <tt>s</tt> is consumed up to and including those characters.
5969 [<i>Example:</i> If <tt>showbase</tt> is off, then for a <tt>neg</tt>
5970 value of "<tt>()</tt>" and a currency symbol of "<tt>L</tt>", in
5971 "<tt>(100 L)</tt>" the entire string is consumed; but for a <tt>neg</tt>
5972 value of "<tt>-</tt>", in "<tt>-100 L</tt>", the string is consumed
5973 through the second "<tt>0</tt>" (the space and "<tt>L</tt>" are not consumed). &#8212; <i>end
5974 example</i>] </ins>
5975 </blockquote>
5976
5977
5978
5979
5980
5981 <hr>
5982 <h3><a name="671"></a>671. precision of hexfloat</h3>
5983 <p><b>Section:</b> 22.4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
5984  <b>Submitter:</b> John Salmon <b>Opened:</b> 2007-04-20  <b>Last modified:</b> 2009-07-26</p>
5985 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.put.virtuals">active issues</a> in [facet.num.put.virtuals].</p>
5986 <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>
5987 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
5988 <p><b>Discussion:</b></p>
5989 <p>
5990 I am trying to understand how TR1 supports hex float (%a) output.
5991 </p>
5992 <p>
5993 As far as I can tell, it does so via the following:
5994 </p>
5995 <p>
5996 8.15 Additions to header &lt;locale&gt; [tr.c99.locale]
5997 </p>
5998 <p>
5999 In subclause 22.4.2.2.2 [facet.num.put.virtuals], Table 58 Floating-point conversions, after
6000 the line:
6001 floatfield == ios_base::scientific %E
6002 </p>
6003 <p>
6004 add the two lines:
6005 </p>
6006 <blockquote><pre>floatfield == ios_base::fixed | ios_base::scientific &amp;&amp; !uppercase %a
6007 floatfield == ios_base::fixed | ios_base::scientific %A 2
6008 </pre></blockquote>
6009 <p>
6010 [Note: The additional requirements on print and scan functions, later
6011 in this clause, ensure that the print functions generate hexadecimal
6012 floating-point fields with a %a or %A conversion specifier, and that
6013 the scan functions match hexadecimal floating-point fields with a %g
6014 conversion specifier.  end note]
6015 </p>
6016 <p>
6017 Following the thread, in 22.4.2.2.2 [facet.num.put.virtuals], we find:
6018 </p>
6019 <p>
6020 For conversion from a floating-point type, if (flags &amp; fixed) != 0 or
6021 if str.precision() &gt; 0, then str.precision() is specified in the
6022 conversion specification.
6023 </p>
6024 <p>
6025 This would seem to imply that when floatfield == fixed|scientific, the
6026 precision of the conversion specifier is to be taken from
6027 str.precision().  Is this really what's intended?  I sincerely hope
6028 that I'm either missing something or this is an oversight.  Please
6029 tell me that the committee did not intend to mandate that hex floats
6030 (and doubles) should by default be printed as if by %.6a.
6031 </p>
6032
6033 <p><i>[
6034 Howard: I think the fundamental issue we overlooked was that with %f,
6035 %e, %g, the default precision was always 6.  With %a the default
6036 precision is not 6, it is infinity.  So for the first time, we need to
6037 distinguish between the default value of precision, and the precision
6038 value 6.
6039 ]</i></p>
6040
6041
6042 <p><i>[
6043 2009-07 Frankfurt
6044 ]</i></p>
6045
6046
6047 <blockquote>
6048 <p>
6049 Leave this open for Robert and Daniel to work on.
6050 </p>
6051 <p>
6052 Straw poll: Disposition?
6053 </p>
6054 <ul>
6055 <li>Default is %.6a (i.e. NAD): 2</li>
6056 <li>Always %a (no precision): 6</li>
6057 <li>precision(-1) == %a: 3</li>
6058 </ul>
6059 <p>
6060 Daniel and Robert have direction to write up wording for the "always %a" solution.
6061 </p>
6062
6063 <p><i>[
6064 2009-07-15 Robert provided wording.
6065 ]</i></p>
6066
6067 </blockquote>
6068
6069
6070
6071 <p><b>Proposed resolution:</b></p>
6072 <p>
6073 Change 22.4.2.2.2 [facet.num.put.virtuals], Stage 1, under p5 (near the end
6074 of Stage 1):
6075 </p>
6076
6077 <blockquote>
6078 For conversion from a floating-point type, <tt>str.precision()</tt> is specified
6079 <ins>as precision</ins> in the conversion specification
6080 <ins>if <tt>floatfield != (ios_base::fixed | ios_base::scientific)</tt>, else no
6081 precision is specified</ins>.
6082 </blockquote>
6083
6084
6085
6086 <p><i>[
6087 Kona (2007): Robert volunteers to propose wording.
6088 ]</i></p>
6089
6090
6091
6092
6093
6094 <hr>
6095 <h3><a name="676"></a>676. Moving the unordered containers</h3>
6096 <p><b>Section:</b> 23.5 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
6097  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-05-05  <b>Last modified:</b> 2009-07-28</p>
6098 <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>
6099 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
6100 <p><b>Discussion:</b></p>
6101 <p>
6102 Move semantics are missing from the <tt>unordered</tt> containers.  The proposed
6103 resolution below adds move-support consistent with
6104 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1858.html">N1858</a>
6105 and the current working draft.
6106 </p>
6107
6108 <p>
6109 The current proposed resolution simply lists the requirements for each function.
6110 These might better be hoisted into the requirements table for unordered associative containers.
6111 Futhermore a mild reorganization of the container requirements could well be in order.
6112 This defect report is purposefully ignoring these larger issues and just focusing
6113 on getting the unordered containers "moved".
6114 </p>
6115
6116 <p><i>[
6117 2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
6118 ]</i></p>
6119
6120
6121
6122
6123 <p><b>Proposed resolution:</b></p>
6124
6125 <p>
6126 Add to 23.5 [unord]:
6127 </p>
6128
6129 <blockquote><pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
6130   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
6131             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
6132
6133 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
6134   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
6135             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
6136
6137 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
6138   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
6139             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
6140
6141 template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
6142   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
6143             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
6144
6145 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
6146   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
6147             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
6148
6149 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
6150   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
6151             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
6152
6153 ...
6154
6155 template &lt;class Value, class Hash, class Pred, class Alloc&gt;
6156   void swap(unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; x,
6157             unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; y);
6158
6159 <ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt;
6160   void swap(unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; x,
6161             unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
6162
6163 <ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt;
6164   void swap(unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; x,
6165             unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; y);</ins>
6166
6167 template &lt;class Value, class Hash, class Pred, class Alloc&gt;
6168   void swap(unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; x,
6169             unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; y);
6170
6171 <ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt;
6172   void swap(unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; x,
6173             unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
6174
6175 <ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt;
6176   void swap(unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; x,
6177             unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; y);</ins>
6178 </pre></blockquote>
6179
6180 <p><b><tt>unordered_map</tt></b></p>
6181
6182 <p>
6183 Change 23.5.1 [unord.map]:
6184 </p>
6185
6186 <blockquote><pre>class unordered_map
6187 {
6188     ...
6189     unordered_map(const unordered_map&amp;);
6190     <ins>unordered_map(unordered_map&amp;&amp;);</ins>
6191     ~unordered_map();
6192     unordered_map&amp; operator=(const unordered_map&amp;);
6193     <ins>unordered_map&amp; operator=(unordered_map&amp;&amp;);</ins>
6194     ...
6195     // modifiers
6196     <del>std::</del>pair&lt;iterator, bool&gt; insert(const value_type&amp; obj);
6197     <ins>template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(P&amp;&amp; obj);</ins>
6198     iterator       insert(iterator hint, const value_type&amp; obj);
6199     <ins>template &lt;class P&gt; iterator       insert(iterator hint, P&amp;&amp; obj);</ins>
6200     const_iterator insert(const_iterator hint, const value_type&amp; obj);
6201     <ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; obj);</ins>
6202     ...
6203     void swap(unordered_map&amp;<ins>&amp;</ins>);
6204     ...
6205     mapped_type&amp; operator[](const key_type&amp; k);
6206     <ins>mapped_type&amp; operator[](key_type&amp;&amp; k);</ins>
6207     ...
6208 };
6209
6210 template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
6211   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
6212             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
6213
6214 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
6215   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
6216             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
6217
6218 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
6219   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
6220             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
6221 </pre></blockquote>
6222
6223 <p>
6224 Add to 23.5.1.1 [unord.map.cnstr]:
6225 </p>
6226
6227 <blockquote>
6228 <pre>template &lt;class InputIterator&gt;
6229   unordered_map(InputIterator f, InputIterator l,
6230                 size_type n = <i>implementation-defined</i>,
6231                 const hasher&amp; hf = hasher(),
6232                 const key_equal&amp; eql = key_equal(),
6233                 const allocator_type&amp; a = allocator_type());
6234 </pre>
6235
6236 <blockquote><p>
6237 <ins>
6238 <i>Requires:</i> If the iterator's dereference operator returns an
6239 lvalue or a const rvalue <tt>pair&lt;key_type, mapped_type&gt;</tt>,
6240 then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be
6241 <tt>CopyConstructible</tt>.
6242 </ins>
6243 </p></blockquote>
6244 </blockquote>
6245
6246 <p>
6247 Add to 23.5.1.2 [unord.map.elem]:
6248 </p>
6249
6250 <blockquote>
6251
6252 <pre>mapped_type&amp; operator[](const key_type&amp; k);</pre>
6253
6254 <blockquote>
6255 <p>...</p>
6256 <p><ins>
6257 <i>Requires:</i> <tt>key_type</tt> shall be <tt>CopyConstructible</tt>
6258 and <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>.
6259 </ins></p>
6260 </blockquote>
6261
6262 <pre><ins>mapped_type&amp; operator[](key_type&amp;&amp; k);</ins></pre>
6263
6264 <blockquote>
6265 <p><ins>
6266 <i>Effects:</i> If the <tt>unordered_map</tt> does not already contain an
6267 element whose key is equivalent to <tt>k</tt> , inserts the value
6268 <tt>std::pair&lt;const key_type, mapped_type&gt;(std::move(k), mapped_type())</tt>.
6269 </ins></p>
6270
6271 <p><ins>
6272 <i>Requires:</i> <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>.
6273 </ins></p>
6274
6275 <p><ins>
6276 <i>Returns:</i> A reference to <tt>x.second</tt>, where <tt>x</tt> is the
6277 (unique) element whose key is equivalent to <tt>k</tt>.
6278 </ins></p>
6279
6280 </blockquote>
6281
6282 </blockquote>
6283
6284 <p>
6285 Add new section [unord.map.modifiers]:
6286 </p>
6287
6288 <blockquote>
6289 <pre><ins>pair&lt;iterator, bool&gt; insert(const value_type&amp; x);</ins>
6290 <ins>template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(P&amp;&amp; x);</ins>
6291 <ins>iterator       insert(iterator hint, const value_type&amp; x);</ins>
6292 <ins>template &lt;class P&gt; iterator       insert(iterator hint, P&amp;&amp; x);</ins>
6293 <ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
6294 <ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; x);</ins>
6295 <ins>template &lt;class InputIterator&gt;
6296   void insert(InputIterator first, InputIterator last);</ins>
6297 </pre>
6298
6299 <blockquote>
6300 <p><ins>
6301 <i>Requires:</i> Those signatures taking a <tt>const value_type&amp;</tt> parameter
6302 requires both the <tt>key_type</tt> and the <tt>mapped_type</tt> to be
6303 <tt>CopyConstructible</tt>.
6304 </ins></p>
6305
6306 <p><ins>
6307 <tt>P</tt> shall be convertible to <tt>value_type</tt>.
6308  If <tt>P</tt> is instantiated as a reference
6309 type, then the argument <tt>x</tt> is copied from. Otherwise <tt>x</tt>
6310 is considered to be an rvalue as it is converted to <tt>value_type</tt>
6311 and inserted into the <tt>unordered_map</tt>. Specifically, in such
6312 cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or
6313 <tt>mapped_type</tt> unless the conversion from <tt>P</tt> specifically
6314 requires it (e.g. if <tt>P</tt> is a <tt>tuple&lt;const key_type,
6315 mapped_type&gt;</tt>, then <tt>key_type</tt> must be
6316 <tt>CopyConstructible</tt>).
6317 </ins></p>
6318
6319 <p><ins>
6320 The signature taking <tt>InputIterator</tt>
6321 parameters requires <tt>CopyConstructible</tt> of both
6322 <tt>key_type</tt> and <tt>mapped_type</tt> if the dereferenced
6323 <tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
6324 <tt>value_type</tt>.
6325 </ins></p>
6326
6327 </blockquote>
6328
6329 </blockquote>
6330
6331 <p>
6332 Add to 23.5.1.3 [unord.map.swap]:
6333 </p>
6334
6335 <blockquote>
6336 <pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
6337   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
6338             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
6339 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
6340   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
6341             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
6342 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
6343   void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
6344             unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
6345 </pre>
6346 </blockquote>
6347
6348 <p><b><tt>unordered_multimap</tt></b></p>
6349
6350 <p>
6351 Change 23.5.2 [unord.multimap]:
6352 </p>
6353
6354 <blockquote><pre>class unordered_multimap
6355 {
6356     ...
6357     unordered_multimap(const unordered_multimap&amp;);
6358     <ins>unordered_multimap(unordered_multimap&amp;&amp;);</ins>
6359     ~unordered_multimap();
6360     unordered_multimap&amp; operator=(const unordered_multimap&amp;);
6361     <ins>unordered_multimap&amp; operator=(unordered_multimap&amp;&amp;);</ins>
6362     ...
6363     // modifiers
6364     iterator insert(const value_type&amp; obj);
6365     <ins>template &lt;class P&gt; iterator insert(P&amp;&amp; obj);</ins>
6366     iterator       insert(iterator hint, const value_type&amp; obj);
6367     <ins>template &lt;class P&gt; iterator       insert(iterator hint, P&amp;&amp; obj);</ins>
6368     const_iterator insert(const_iterator hint, const value_type&amp; obj);
6369     <ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; obj);</ins>
6370     ...
6371     void swap(unordered_multimap&amp;<ins>&amp;</ins>);
6372     ...
6373 };
6374
6375 template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
6376   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
6377             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
6378
6379 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
6380   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
6381             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
6382
6383 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
6384   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
6385             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
6386 </pre></blockquote>
6387
6388 <p>
6389 Add to 23.5.2.1 [unord.multimap.cnstr]:
6390 </p>
6391
6392 <blockquote>
6393 <pre>template &lt;class InputIterator&gt;
6394   unordered_multimap(InputIterator f, InputIterator l,
6395                 size_type n = <i>implementation-defined</i>,
6396                 const hasher&amp; hf = hasher(),
6397                 const key_equal&amp; eql = key_equal(),
6398                 const allocator_type&amp; a = allocator_type());
6399 </pre>
6400
6401 <blockquote><p>
6402 <ins>
6403 <i>Requires:</i> If the iterator's dereference operator returns an
6404 lvalue or a const rvalue <tt>pair&lt;key_type, mapped_type&gt;</tt>,
6405 then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be
6406 <tt>CopyConstructible</tt>.
6407 </ins>
6408 </p></blockquote>
6409 </blockquote>
6410
6411 <p>
6412 Add new section [unord.multimap.modifiers]:
6413 </p>
6414
6415 <blockquote>
6416 <pre><ins>iterator insert(const value_type&amp; x);</ins>
6417 <ins>template &lt;class P&gt; iterator       insert(P&amp;&amp; x);</ins>
6418 <ins>iterator       insert(iterator hint, const value_type&amp; x);</ins>
6419 <ins>template &lt;class P&gt; iterator       insert(iterator hint, P&amp;&amp; x);</ins>
6420 <ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
6421 <ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; x);</ins>
6422 <ins>template &lt;class InputIterator&gt;
6423   void insert(InputIterator first, InputIterator last);</ins>
6424 </pre>
6425
6426 <blockquote>
6427 <p><ins>
6428 <i>Requires:</i> Those signatures taking a <tt>const value_type&amp;</tt> parameter
6429 requires both the <tt>key_type</tt> and the <tt>mapped_type</tt> to be
6430 <tt>CopyConstructible</tt>.
6431 </ins></p>
6432
6433 <p><ins>
6434 <tt>P</tt> shall be convertible to <tt>value_type</tt>.
6435  If <tt>P</tt> is instantiated as a reference
6436 type, then the argument <tt>x</tt> is copied from. Otherwise <tt>x</tt>
6437 is considered to be an rvalue as it is converted to <tt>value_type</tt>
6438 and inserted into the <tt>unordered_multimap</tt>. Specifically, in such
6439 cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or
6440 <tt>mapped_type</tt> unless the conversion from <tt>P</tt> specifically
6441 requires it (e.g. if <tt>P</tt> is a <tt>tuple&lt;const key_type,
6442 mapped_type&gt;</tt>, then <tt>key_type</tt> must be
6443 <tt>CopyConstructible</tt>).
6444 </ins></p>
6445
6446 <p><ins>
6447 The signature taking <tt>InputIterator</tt>
6448 parameters requires <tt>CopyConstructible</tt> of both
6449 <tt>key_type</tt> and <tt>mapped_type</tt> if the dereferenced
6450 <tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
6451 <tt>value_type</tt>.
6452 </ins></p>
6453 </blockquote>
6454
6455 </blockquote>
6456
6457 <p>
6458 Add to 23.5.2.2 [unord.multimap.swap]:
6459 </p>
6460
6461 <blockquote>
6462 <pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
6463   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
6464             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
6465 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
6466   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
6467             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
6468 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
6469   void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
6470             unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
6471 </pre>
6472 </blockquote>
6473
6474 <p><b><tt>unordered_set</tt></b></p>
6475
6476 <p>
6477 Change 23.5.3 [unord.set]:
6478 </p>
6479
6480 <blockquote><pre>class unordered_set
6481 {
6482     ...
6483     unordered_set(const unordered_set&amp;);
6484     <ins>unordered_set(unordered_set&amp;&amp;);</ins>
6485     ~unordered_set();
6486     unordered_set&amp; operator=(const unordered_set&amp;);
6487     <ins>unordered_set&amp; operator=(unordered_set&amp;&amp;);</ins>
6488     ...
6489     // modifiers
6490     <del>std::</del>pair&lt;iterator, bool&gt; insert(const value_type&amp; obj);
6491     <ins>pair&lt;iterator, bool&gt; insert(value_type&amp;&amp; obj);</ins>
6492     iterator       insert(iterator hint, const value_type&amp; obj);
6493     <ins>iterator       insert(iterator hint, value_type&amp;&amp; obj);</ins>
6494     const_iterator insert(const_iterator hint, const value_type&amp; obj);
6495     <ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; obj);</ins>
6496     ...
6497     void swap(unordered_set&amp;<ins>&amp;</ins>);
6498     ...
6499 };
6500
6501 template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
6502   void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
6503             unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
6504
6505 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
6506   void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
6507             unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
6508
6509 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
6510   void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
6511             unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
6512 </pre></blockquote>
6513
6514 <p>
6515 Add to 23.5.3.1 [unord.set.cnstr]:
6516 </p>
6517
6518 <blockquote>
6519 <pre>template &lt;class InputIterator&gt;
6520   unordered_set(InputIterator f, InputIterator l,
6521                 size_type n = <i>implementation-defined</i>,
6522                 const hasher&amp; hf = hasher(),
6523                 const key_equal&amp; eql = key_equal(),
6524                 const allocator_type&amp; a = allocator_type());
6525 </pre>
6526
6527 <blockquote><p>
6528 <ins>
6529 <i>Requires:</i> If the iterator's dereference operator returns an
6530 lvalue or a const rvalue <tt>value_type</tt>, then the
6531 <tt>value_type</tt> shall be <tt>CopyConstructible</tt>.
6532 </ins>
6533 </p></blockquote>
6534 </blockquote>
6535
6536 <p>
6537 Add new section [unord.set.modifiers]:
6538 </p>
6539
6540 <blockquote>
6541 <pre><ins>pair&lt;iterator, bool&gt; insert(const value_type&amp; x);</ins>
6542 <ins>pair&lt;iterator, bool&gt; insert(value_type&amp;&amp; x);</ins>
6543 <ins>iterator       insert(iterator hint, const value_type&amp; x);</ins>
6544 <ins>iterator       insert(iterator hint, value_type&amp;&amp; x);</ins>
6545 <ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
6546 <ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; x);</ins>
6547 <ins>template &lt;class InputIterator&gt;
6548   void insert(InputIterator first, InputIterator last);</ins>
6549 </pre>
6550
6551 <blockquote>
6552
6553 <p><ins>
6554 <i>Requires:</i> Those signatures taking a <tt>const
6555 value_type&amp;</tt> parameter requires the <tt>value_type</tt> to
6556 be <tt>CopyConstructible</tt>.
6557 </ins></p>
6558
6559 <p><ins>
6560 The signature taking <tt>InputIterator</tt> parameters requires
6561 <tt>CopyConstructible</tt> of <tt>value_type</tt> if the dereferenced
6562 <tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
6563 <tt>value_type</tt>.
6564 </ins></p>
6565
6566 </blockquote>
6567
6568 </blockquote>
6569
6570 <p>
6571 Add to 23.5.3.2 [unord.set.swap]:
6572 </p>
6573
6574 <blockquote>
6575 <pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
6576   void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
6577             unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
6578 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
6579   void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
6580             unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
6581 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
6582   void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
6583             unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
6584 </pre>
6585 </blockquote>
6586
6587 <p><b><tt>unordered_multiset</tt></b></p>
6588
6589 <p>
6590 Change 23.5.4 [unord.multiset]:
6591 </p>
6592
6593 <blockquote><pre>class unordered_multiset
6594 {
6595     ...
6596     unordered_multiset(const unordered_multiset&amp;);
6597     <ins>unordered_multiset(unordered_multiset&amp;&amp;);</ins>
6598     ~unordered_multiset();
6599     unordered_multiset&amp; operator=(const unordered_multiset&amp;);
6600     <ins>unordered_multiset&amp; operator=(unordered_multiset&amp;&amp;);</ins>
6601     ...
6602     // modifiers
6603     iterator insert(const value_type&amp; obj);
6604     <ins>iterator insert(value_type&amp;&amp; obj);</ins>
6605     iterator       insert(iterator hint, const value_type&amp; obj);
6606     <ins>iterator       insert(iterator hint, value_type&amp;&amp; obj);</ins>
6607     const_iterator insert(const_iterator hint, const value_type&amp; obj);
6608     <ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; obj);</ins>
6609     ...
6610     void swap(unordered_multiset&amp;<ins>&amp;</ins>);
6611     ...
6612 };
6613
6614 template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
6615   void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
6616             unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
6617
6618 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
6619   void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
6620             unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
6621
6622 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
6623   void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
6624             unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
6625 </pre></blockquote>
6626
6627 <p>
6628 Add to 23.5.4.1 [unord.multiset.cnstr]:
6629 </p>
6630
6631 <blockquote>
6632 <pre>template &lt;class InputIterator&gt;
6633   unordered_multiset(InputIterator f, InputIterator l,
6634                 size_type n = <i>implementation-defined</i>,
6635                 const hasher&amp; hf = hasher(),
6636                 const key_equal&amp; eql = key_equal(),
6637                 const allocator_type&amp; a = allocator_type());
6638 </pre>
6639
6640 <blockquote><p>
6641 <ins>
6642 <i>Requires:</i> If the iterator's dereference operator returns an
6643 lvalue or a const rvalue <tt>value_type</tt>, then the
6644 <tt>value_type</tt> shall be <tt>CopyConstructible</tt>.
6645 </ins>
6646 </p></blockquote>
6647 </blockquote>
6648
6649 <p>
6650 Add new section [unord.multiset.modifiers]:
6651 </p>
6652
6653 <blockquote>
6654 <pre><ins>iterator insert(const value_type&amp; x);</ins>
6655 <ins>iterator insert(value_type&amp;&amp; x);</ins>
6656 <ins>iterator       insert(iterator hint, const value_type&amp; x);</ins>
6657 <ins>iterator       insert(iterator hint, value_type&amp;&amp; x);</ins>
6658 <ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
6659 <ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; x);</ins>
6660 <ins>template &lt;class InputIterator&gt;
6661   void insert(InputIterator first, InputIterator last);</ins>
6662 </pre>
6663
6664 <blockquote>
6665
6666 <p><ins>
6667 <i>Requires:</i> Those signatures taking a <tt>const
6668 value_type&amp;</tt> parameter requires the <tt>value_type</tt> to
6669 be <tt>CopyConstructible</tt>.
6670 </ins></p>
6671
6672 <p><ins>
6673 The signature taking <tt>InputIterator</tt> parameters requires
6674 <tt>CopyConstructible</tt> of <tt>value_type</tt> if the dereferenced
6675 <tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
6676 <tt>value_type</tt>.
6677 </ins></p>
6678
6679 </blockquote>
6680
6681 </blockquote>
6682
6683 <p>
6684 Add to 23.5.4.2 [unord.multiset.swap]:
6685 </p>
6686
6687 <blockquote>
6688 <pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
6689   void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
6690             unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
6691 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
6692   void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
6693             unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
6694 <ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
6695   void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
6696             unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
6697 </pre>
6698 </blockquote>
6699
6700
6701
6702 <p><i>[
6703 Voted to WP in Bellevue.
6704 ]</i></p>
6705
6706
6707 <p><i>[
6708 post Bellevue, Pete notes:
6709 ]</i></p>
6710
6711
6712 <blockquote>
6713 <p>
6714 Please remind people who are reviewing issues to check that the text
6715 modifications match the current draft. Issue 676, for example, adds two
6716 overloads for unordered_map::insert taking a hint. One takes a
6717 const_iterator and returns a const_iterator, and the other takes an
6718 iterator and returns an iterator. This was correct at the time the issue
6719 was written, but was changed in Toronto so there is only one hint
6720 overload, taking a const_iterator and returning an iterator.
6721 </p>
6722 <p>
6723 This issue is not ready. In addition to the relatively minor signature
6724 problem I mentioned earlier, it puts requirements in the wrong places.
6725 Instead of duplicating requirements throughout the template
6726 specifications, it should put them in the front matter that talks about
6727 requirements for unordered containers in general. This presentation
6728 problem is editorial, but I'm not willing to do the extensive rewrite
6729 that it requires. Please put it back into Open status.
6730 </p>
6731 </blockquote>
6732
6733 <p><b>Rationale:</b></p>
6734 <p><i>[
6735 San Francisco:
6736 ]</i></p>
6737
6738
6739 <blockquote>
6740 Solved by
6741 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2776.pdf">N2776</a>.
6742 </blockquote>
6743
6744
6745
6746
6747
6748
6749 <hr>
6750 <h3><a name="696"></a>696. <code>istream::operator&gt;&gt;(int&amp;)</code> broken</h3>
6751 <p><b>Section:</b> 27.7.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
6752  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-06-23  <b>Last modified:</b> 2009-07-15</p>
6753 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p>
6754 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
6755 <p><b>Discussion:</b></p>
6756 <p>
6757 From message c++std-lib-17897:
6758 </p>
6759 <p>
6760 The code shown in 27.7.1.2.2 [istream.formatted.arithmetic] as the "as if"
6761 implementation of the two arithmetic extractors that don't have a
6762 corresponding <code>num_get</code> interface (i.e., the
6763 <code>short</code> and <code>int</code> overloads) is subtly buggy in
6764 how it deals with <code>EOF</code>, overflow, and other similar
6765 conditions (in addition to containing a few typos).
6766 </p>
6767 <p>
6768 One problem is that if <code>num_get::get()</code> reaches the EOF
6769 after reading in an otherwise valid value that exceeds the limits of
6770 the narrower type (but not <code>LONG_MIN</code> or
6771 <code>LONG_MAX</code>), it will set <code><i>err</i></code> to
6772 <code>eofbit</code>. Because of the if condition testing for
6773 <code>(<i>err</i> == 0)</code>, the extractor won't set
6774 <code>failbit</code> (and presumably, return a bogus value to the
6775 caller).
6776 </p>
6777 <p>
6778 Another problem with the code is that it never actually sets the
6779 argument to the extracted value. It can't happen after the call to
6780 <code>setstate()</code> since the function may throw, so we need to
6781 show when and how it's done (we can't just punt as say: "it happens
6782 afterwards"). However, it turns out that showing how it's done isn't
6783 quite so easy since the argument is normally left unchanged by the
6784 facet on error except when the error is due to a misplaced thousands
6785 separator, which causes <code>failbit</code> to be set but doesn't
6786 prevent the facet from storing the value.
6787 </p>
6788
6789 <p><i>[
6790 Batavia (2009-05):
6791 ]</i></p>
6792
6793 <blockquote>
6794 <p>
6795 We believe this part of the Standard has been recently adjusted
6796 and that this issue was addressed during that rewrite.
6797 </p>
6798 <p>
6799 Move to NAD.
6800 </p>
6801 </blockquote>
6802
6803 <p><i>[
6804 2009-05-28 Howard adds:
6805 ]</i></p>
6806
6807
6808 <blockquote>
6809 <p>
6810 I've moved this issue from Tentatively NAD to Open.
6811 </p>
6812
6813 <p>
6814 The current wording of
6815 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>
6816 in 22.4.2.1.2 [facet.num.get.virtuals] p3, stage 3 appears to indicate that
6817 in parsing arithmetic types, the value is always set, but sometimes in addition
6818 to setting <tt>failbit</tt>.
6819 </p>
6820
6821 <ul>
6822 <li>
6823 If there is a range error, the value is set to min or max, else
6824 </li>
6825 <li>
6826 if there is a conversion error, the value is set to 0, else
6827 </li>
6828 <li>
6829 if there is a grouping error, the value is set to whatever it would be if grouping were ignored, else
6830 </li>
6831 <li>
6832 the value is set to its error-free result.
6833 </li>
6834 </ul>
6835
6836 <p>
6837 However there is a contradictory sentence in 22.4.2.1.2 [facet.num.get.virtuals] p1.
6838 </p>
6839
6840 <p>
6841 27.7.1.2.2 [istream.formatted.arithmetic] should mimic the behavior of 22.4.2.1.2 [facet.num.get.virtuals]
6842 (whatever we decide that behavior is) for
6843 <tt>int</tt> and <tt>short</tt>, and currently does not.  I believe that the
6844 correct code fragment should look like:
6845 </p>
6846
6847 <blockquote><pre>typedef num_get&lt;charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
6848 iostate err = ios_base::goodbit;
6849 long lval;
6850 use_facet&lt;numget&gt;(loc).get(*this, 0, *this, err, lval);
6851 if (lval &lt; numeric_limits&lt;int&gt;::min())
6852 {
6853   err |= ios_base::failbit;
6854   val = numeric_limits&lt;int&gt;::min();
6855 }
6856 else if (lval &gt; numeric_limits&lt;int&gt;::max())
6857 {
6858   err |= ios_base::failbit;
6859   val = numeric_limits&lt;int&gt;::max();
6860 }
6861 else
6862   val = static_cast&lt;int&gt;(lval);
6863 setstate(err);
6864 </pre></blockquote>
6865 </blockquote>
6866
6867 <p><i>[
6868 2009-07 Frankfurt
6869 ]</i></p>
6870
6871
6872 <blockquote>
6873 Move to Ready.
6874 </blockquote>
6875
6876
6877
6878 <p><b>Proposed resolution:</b></p>
6879 <p>
6880 Change 22.4.2.1.2 [facet.num.get.virtuals], p1:
6881 </p>
6882
6883 <blockquote>
6884 -1- <i>Effects:</i> Reads characters from <tt>in</tt>, interpreting them
6885 according to <tt>str.flags()</tt>, <tt>use_facet&lt;ctype&lt;charT&gt;
6886 &gt;(loc)</tt>, and <tt>use_facet&lt; numpunct&lt;charT&gt;
6887 &gt;(loc)</tt>, where <tt>loc</tt> is <tt>str.getloc()</tt>. <del>If an error
6888 occurs, <tt>val</tt> is unchanged; otherwise it is set to the resulting value.</del>
6889 </blockquote>
6890
6891 <p>
6892 Change 27.7.1.2.2 [istream.formatted.arithmetic], p2 and p3:
6893 </p>
6894
6895 <blockquote>
6896 <pre>operator&gt;&gt;(short&amp; val);
6897 </pre>
6898 <blockquote>
6899 <p>
6900 -2- The conversion occurs as if performed by the following code fragment (using the same notation as for
6901 the preceding code fragment):
6902 </p>
6903
6904 <blockquote><pre>typedef num_get&lt;charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
6905 iostate err = ios<del>tate</del><ins>_base</ins>::goodbit;
6906 long lval;
6907 use_facet&lt;numget&gt;(loc).get(*this, 0, *this, err, lval);
6908 <del>if (err != 0)
6909   ;
6910 else if (lval &lt; numeric_limits&lt;short&gt;::min()
6911   || numeric_limits&lt;short&gt;::max() &lt; lval)
6912      err = ios_base::failbit;</del>
6913 <ins>if (lval &lt; numeric_limits&lt;short&gt;::min())
6914 {
6915   err |= ios_base::failbit;
6916   val = numeric_limits&lt;short&gt;::min();
6917 }
6918 else if (lval &gt; numeric_limits&lt;short&gt;::max())
6919 {
6920   err |= ios_base::failbit;
6921   val = numeric_limits&lt;short&gt;::max();
6922 }</ins>
6923 else
6924   val = static_cast&lt;short&gt;(lval);
6925 setstate(err);
6926 </pre></blockquote>
6927
6928 </blockquote>
6929
6930 <pre>operator&gt;&gt;(int&amp; val);
6931 </pre>
6932 <blockquote>
6933 <p>
6934 -3- The conversion occurs as if performed by the following code fragment (using the same notation as for
6935 the preceding code fragment):
6936 </p>
6937
6938 <blockquote><pre>typedef num_get&lt;charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
6939 iostate err = ios<del>tate</del><ins>_base</ins>::goodbit;
6940 long lval;
6941 use_facet&lt;numget&gt;(loc).get(*this, 0, *this, err, lval);
6942 <del>if (err != 0)
6943   ;
6944 else if (lval &lt; numeric_limits&lt;int&gt;::min()
6945   || numeric_limits&lt;int&gt;::max() &lt; lval)
6946      err = ios_base::failbit;</del>
6947 <ins>if (lval &lt; numeric_limits&lt;int&gt;::min())
6948 {
6949   err |= ios_base::failbit;
6950   val = numeric_limits&lt;int&gt;::min();
6951 }
6952 else if (lval &gt; numeric_limits&lt;int&gt;::max())
6953 {
6954   err |= ios_base::failbit;
6955   val = numeric_limits&lt;int&gt;::max();
6956 }</ins>
6957 else
6958   val = static_cast&lt;int&gt;(lval);
6959 setstate(err);
6960 </pre></blockquote>
6961
6962 </blockquote>
6963
6964 </blockquote>
6965
6966
6967
6968
6969
6970 <hr>
6971 <h3><a name="704"></a>704. MoveAssignable requirement for container value type overly strict</h3>
6972 <p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
6973  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-05-20  <b>Last modified:</b> 2009-07-20</p>
6974 <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>
6975 <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>
6976 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
6977 <p><b>Discussion:</b></p>
6978 <p>
6979 The move-related changes inadvertently overwrote the intent of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>.
6980 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a> removed the requirement of <tt>CopyAssignable</tt> from
6981 most of the member functions of node-based containers.  But the move-related changes
6982 unnecessarily introduced the <tt>MoveAssignable</tt> requirement for those members which used to
6983 require <tt>CopyAssignable</tt>.
6984 </p>
6985
6986 <p>
6987 We also discussed (c++std-lib-18722) the possibility of dropping <tt>MoveAssignable</tt>
6988 from some of the sequence requirements.  Additionally the <i>in-place</i> construction
6989 work may further reduce requirements.  For purposes of an easy reference, here are the
6990 minimum sequence requirements as I currently understand them.  Those items in requirements
6991 table in the working draft which do not appear below have been purposefully omitted for
6992 brevity as they do not have any requirements of this nature.  Some items which do not
6993 have any requirements of this nature are included below just to confirm that they were
6994 not omitted by mistake.
6995 </p>
6996
6997 <table border="1">
6998 <caption>Container Requirements</caption>
6999 <tbody><tr><td><tt>X u(a)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
7000 <tr><td><tt>X u(rv)</tt></td><td><tt>array</tt> and containers with a <tt>propagate_never</tt> allocator require <tt>value_type</tt> to be <tt>MoveConstructible</tt></td></tr>
7001 <tr><td><tt>a = u</tt></td><td>Sequences require <tt>value_type</tt> to be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.
7002                                Associative containers require <tt>value_type</tt> to be <tt>CopyConstructible</tt>.</td></tr>
7003 <tr><td><tt>a = rv</tt></td><td><tt>array</tt> requires <tt>value_type</tt> to be <tt>MoveAssignable</tt>.
7004                                 Sequences and Associative containers with <tt>propagate_never</tt> and <tt>propagate_on_copy_construction</tt> allocators require <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
7005 <tr><td><tt>swap(a,u)</tt></td><td><tt>array</tt> and containers with <tt>propagate_never</tt> and
7006                   <tt>propagate_on_copy_construction</tt> allocators require <tt>value_type</tt> to be <tt>Swappable</tt>.</td></tr>
7007 </tbody></table>
7008
7009 <p>
7010 </p>
7011
7012 <table border="1">
7013 <caption>Sequence Requirements</caption>
7014 <tbody><tr><td><tt>X(n)</tt></td><td><tt>value_type</tt> must be <tt>DefaultConstructible</tt></td></tr>
7015 <tr><td><tt>X(n, t)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
7016 <tr><td><tt>X(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
7017                                  If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
7018 <tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
7019                                         The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
7020 <tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
7021                                         The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
7022 <tr><td><tt>a.insert(p, n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
7023                                         The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
7024 <tr><td><tt>a.insert(p, i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
7025                                         The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt> when the iterators return an lvalue.
7026                                         If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
7027                                         The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt> when the iterators return an rvalue.</td></tr>
7028 <tr><td><tt>a.erase(p)</tt></td><td>The sequences <tt>vector</tt> and <tt>deque</tt> require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
7029 <tr><td><tt>a.erase(q1, q2)</tt></td><td>The sequences <tt>vector</tt> and <tt>deque</tt> require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
7030 <tr><td><tt>a.clear()</tt></td><td></td></tr>
7031 <tr><td><tt>a.assign(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.
7032                                         If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.</td></tr>
7033 <tr><td><tt>a.assign(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.</td></tr>
7034 <tr><td><tt>a.resize(n)</tt></td><td>The <tt>value_type</tt> must be <tt>DefaultConstructible</tt>.
7035                                      The sequence <tt>vector</tt> also requires the <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
7036 <tr><td><tt>a.resize(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
7037 </tbody></table>
7038
7039 <p>
7040 </p>
7041
7042 <table border="1">
7043 <caption>Optional Sequence Requirements</caption>
7044 <tbody><tr><td><tt>a.front()</tt></td><td></td></tr>
7045 <tr><td><tt>a.back()</tt></td><td></td></tr>
7046 <tr><td><tt>a.push_front(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
7047 <tr><td><tt>a.push_front(rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
7048 <tr><td><tt>a.push_back(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
7049 <tr><td><tt>a.push_back(rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
7050 <tr><td><tt>a.pop_front()</tt></td><td></td></tr>
7051 <tr><td><tt>a.pop_back()</tt></td><td></td></tr>
7052 <tr><td><tt>a[n]</tt></td><td></td></tr>
7053 <tr><td><tt>a.at[n]</tt></td><td></td></tr>
7054 </tbody></table>
7055
7056 <p>
7057 </p>
7058
7059 <table border="1">
7060 <caption>Associative Container Requirements</caption>
7061 <tbody><tr><td><tt>X(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
7062                                  If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
7063 <tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
7064 <tr><td><tt>a_uniq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
7065 <tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
7066 <tr><td><tt>a_eq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
7067 <tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
7068 <tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
7069 <tr><td><tt>a.insert(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
7070                                         If the iterators return an rvalue the <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>..</td></tr>
7071 </tbody></table>
7072
7073 <p>
7074 </p>
7075
7076 <table border="1">
7077 <caption>Unordered Associative Container Requirements</caption>
7078 <tbody><tr><td><tt>X(i, j, n, hf, eq)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
7079                                  If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
7080 <tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
7081 <tr><td><tt>a_uniq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
7082 <tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
7083 <tr><td><tt>a_eq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
7084 <tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
7085 <tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
7086 <tr><td><tt>a.insert(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
7087                                         If the iterators return an rvalue the <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>..</td></tr>
7088 </tbody></table>
7089
7090 <p>
7091 </p>
7092
7093 <table border="1">
7094 <caption>Miscellaneous Requirements</caption>
7095 <tbody><tr><td><tt>map[lvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>CopyConstructible</tt>.
7096                                          The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr>
7097 <tr><td><tt>map[rvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>MoveConstructible</tt>.
7098                                          The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr>
7099 </tbody></table>
7100
7101 <p><i>[
7102 Kona (2007): Howard and Alan to update requirements table in issue with emplace signatures.
7103 ]</i></p>
7104
7105
7106 <p><i>[
7107 Bellevue: This should be handled as part of the concepts work.
7108 ]</i></p>
7109
7110
7111 <p><i>[
7112 2009-07-20 Reopened by Howard:
7113 ]</i></p>
7114
7115
7116 <blockquote>
7117 <p>
7118 This is one of the issues that was "solved by concepts" and is now no longer solved.
7119 </p>
7120
7121 <p>
7122 In a nutshell, concepts adopted the "minimum requirements" philosophy outlined
7123 in the discussion of this issue, and enforced it.  My strong suggestion is that
7124 we translate the concepts specification into documentation for the containers.
7125 </p>
7126
7127 <p>
7128 What this means for vendors is that they will have to implement container members
7129 being careful to only use those characteristics of a type that the concepts specification
7130 formally allowed.  Note that I <em>am not</em> talking about <tt>enable_if</tt>'ing
7131 everything.  I am simply suggesting that (for example) we tell the vendor he can't call <tt>T's</tt>
7132 copy constructor or move constructor within the <tt>emplace</tt> member function, etc.
7133 </p>
7134
7135 <p>
7136 What this means for customers is that they will be able to use types within C++03
7137 containers which are sometimes not CopyConstructible, and sometimes not even
7138 MoveConstructible, etc.
7139 </p>
7140 </blockquote>
7141
7142
7143
7144 <p><b>Proposed resolution:</b></p>
7145
7146
7147
7148 <p><b>Rationale:</b></p>
7149 <p><i>[
7150 post San Francisco:
7151 ]</i></p>
7152
7153
7154 <blockquote>
7155 Solved by
7156 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2776.pdf">N2776</a>.
7157 </blockquote>
7158
7159
7160
7161
7162
7163
7164 <hr>
7165 <h3><a name="711"></a>711. Contradiction in empty <tt>shared_ptr</tt></h3>
7166 <p><b>Section:</b> 20.8.10.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
7167  <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-08-24  <b>Last modified:</b> 2009-07-17</p>
7168 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.obs">issues</a> in [util.smartptr.shared.obs].</p>
7169 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
7170 <p><b>Discussion:</b></p>
7171 <p>
7172 A discussion on
7173 <a href="http://groups.google.com/group/comp.std.c++/browse_frm/thread/8e89dceb35cd7971">comp.std.c++</a>
7174 has identified a contradiction in the <tt>shared_ptr</tt> specification.
7175 The note:
7176 </p>
7177
7178 <blockquote><p>
7179 [ <i>Note:</i> this constructor allows creation of an empty shared_ptr instance with a non-NULL stored pointer.
7180 -end note ]
7181 </p></blockquote>
7182
7183 <p>
7184 after the aliasing constructor
7185 </p>
7186
7187 <blockquote><pre>template&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt; const&amp; r, T *p);
7188 </pre></blockquote>
7189
7190 <p>
7191 reflects the intent of
7192 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm">N2351</a>
7193 to, well, allow the creation of an empty <tt>shared_ptr</tt>
7194 with a non-NULL stored pointer.
7195 </p>
7196
7197 <p>
7198 This is contradicted by the second sentence in the Returns clause of 20.8.10.2.5 [util.smartptr.shared.obs]:
7199 </p>
7200
7201 <blockquote>
7202 <pre>T* get() const;
7203 </pre>
7204 <blockquote><p>
7205 <i>Returns:</i> the stored pointer. Returns a null pointer if <tt>*this</tt> is empty.
7206 </p></blockquote>
7207 </blockquote>
7208
7209 <p><i>[
7210 Bellevue:
7211 ]</i></p>
7212
7213
7214 <blockquote>
7215 <p>
7216 Adopt option 1 and move to review, not ready.
7217 </p>
7218 <p>
7219 There was a lot of confusion about what an empty <tt>shared_ptr</tt> is (the term
7220 isn't defined anywhere), and whether we have a good mental model for how
7221 one behaves. We think it might be possible to deduce what the definition
7222 should be, but the words just aren't there. We need to open an issue on
7223 the use of this undefined term. (The resolution of that issue might
7224 affect the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>.)
7225 </p>
7226 <p>
7227 The LWG is getting more uncomfortable with the aliasing proposal (N2351)
7228 now that we realize some of its implications, and we need to keep an eye
7229 on it, but there isn't support for removing this feature at this time.
7230 </p>
7231 </blockquote>
7232
7233 <p><i>[
7234 Sophia Antipolis:
7235 ]</i></p>
7236
7237
7238 <blockquote>
7239 <p>
7240 We heard from Peter Dimov, who explained his reason for preferring solution 1.
7241 </p>
7242 <p>
7243 Because it doesn't seem to add anything. It simply makes the behavior
7244 for p = 0 undefined. For programmers who don't create empty pointers
7245 with p = 0, there is no difference. Those who do insist on creating them
7246 presumably have a good reason, and it costs nothing for us to define the
7247 behavior in this case.
7248 </p>
7249 <p>
7250 The aliasing constructor is sharp enough as it is, so "protecting" users
7251 doesn't make much sense in this particular case.
7252 </p>
7253 <p>
7254 &gt; Do you have a use case for r being empty and r being non-null?
7255 </p>
7256 <p>
7257 I have received a few requests for it from "performance-conscious"
7258 people (you should be familiar with this mindset) who don't like the
7259 overhead of allocating and maintaining a control block when a null
7260 deleter is used to approximate a raw pointer. It is obviously an "at
7261 your own risk", low-level feature; essentially a raw pointer behind a
7262 shared_ptr facade.
7263 </p>
7264 <p>
7265 We could not agree upon a resolution to the issue; some of us thought
7266 that Peter's description above is supporting an undesirable behavior.
7267 </p>
7268 </blockquote>
7269
7270 <p><i>[
7271 2009-07 Frankfurt:
7272 ]</i></p>
7273
7274
7275 <blockquote>
7276 <p>
7277 We favor option 1, move to Ready.
7278 </p>
7279 <p><i>[
7280 Howard:  Option 2 commented out for clarity, and can be brought back.
7281 ]</i></p>
7282
7283 </blockquote>
7284
7285
7286
7287 <p><b>Proposed resolution:</b></p>
7288 <p>
7289 In keeping the N2351 spirit and obviously my preference, change 20.8.10.2.5 [util.smartptr.shared.obs]:
7290 </p>
7291
7292 <blockquote>
7293 <pre>T* get() const;
7294 </pre>
7295 <blockquote><p>
7296 <i>Returns:</i> the stored pointer. <del>Returns a null pointer if <tt>*this</tt> is empty.</del>
7297 </p></blockquote>
7298 </blockquote>
7299
7300
7301
7302
7303
7304
7305
7306
7307 <hr>
7308 <h3><a name="716"></a>716. Production in [re.grammar] not actually modified</h3>
7309 <p><b>Section:</b> 28.13 [re.grammar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
7310  <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2007-08-31  <b>Last modified:</b> 2009-07-16</p>
7311 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
7312 <p><b>Discussion:</b></p>
7313 <p>
7314 TR1 7.13 [tr.re.grammar]/3 and C++0x WP 28.13 [re.grammar]/3 say:
7315 </p>
7316
7317 <blockquote>
7318 <p>
7319 The following productions within the ECMAScript grammar are modified as follows:
7320 </p>
7321
7322 <blockquote><pre>CharacterClass ::
7323 [ [lookahead &#8713; {^}] ClassRanges ]
7324 [ ^ ClassRanges ]
7325 </pre></blockquote>
7326
7327 </blockquote>
7328
7329 <p>
7330 This definition for <tt>CharacterClass</tt> appears to be exactly identical to that in ECMA-262.
7331 </p>
7332
7333 <p>
7334 Was an actual modification intended here and accidentally omitted, or was this production accidentally included?
7335 </p>
7336
7337 <p><i>[
7338 Batavia (2009-05):
7339 ]</i></p>
7340
7341 <blockquote>
7342 <p>
7343 We agree that what is specified is identical to what ECMA-262 specifies.
7344 Pete would like to take a bit of time to assess whether we had intended,
7345 but failed, to make a change.
7346 It would also be useful to hear from John Maddock on the issue.
7347 </p>
7348 <p>
7349 Move to Open.
7350 </p>
7351 </blockquote>
7352
7353 <p><i>[
7354 2009-07 Frankfurt:
7355 ]</i></p>
7356
7357
7358 <blockquote>
7359 Move to Ready.
7360 </blockquote>
7361
7362
7363
7364 <p><b>Proposed resolution:</b></p>
7365 <p>
7366 Remove this mention of the CharacterClass production.
7367 </p>
7368
7369 <blockquote><pre><del>CharacterClass ::
7370 [ [lookahead &#8713; {^}] ClassRanges ]
7371 [ ^ ClassRanges ]</del>
7372 </pre></blockquote>
7373
7374
7375
7376
7377
7378
7379 <hr>
7380 <h3><a name="719"></a>719. <tt>std::is_literal</tt> type traits should be provided</h3>
7381 <p><b>Section:</b> 20.6 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
7382  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-08-25  <b>Last modified:</b> 2009-07-16</p>
7383 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta">active issues</a> in [meta].</p>
7384 <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>
7385 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
7386 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#750">750</a></p>
7387 <p><b>Discussion:</b></p>
7388 <p>
7389 Since the inclusion of <tt>constexpr</tt> in the standard draft N2369 we have
7390 a new type category "literal", which is defined in 3.9 [basic.types]/p.11:
7391 </p>
7392
7393 <blockquote>
7394 <p>
7395 -11- A type is a <i>literal</i> type if it is:
7396 </p>
7397 <ul>
7398 <li>a scalar type; or</li>
7399 <li><p>a class type (clause 9) with</p>
7400 <ul>
7401 <li>a trivial copy constructor,</li>
7402 <li>a trivial destructor,</li>
7403 <li>at least one constexpr constructor other than the copy constructor,</li>
7404 <li>no virtual base classes, and</li>
7405 <li>all non-static data members and base classes of literal types; or</li>
7406 </ul>
7407 </li>
7408 <li>an array of literal type.</li>
7409 </ul>
7410 </blockquote>
7411
7412 <p>
7413 I strongly suggest that the standard provides a type traits for
7414 literal types in 20.6.4.3 [meta.unary.prop] for several reasons:
7415 </p>
7416
7417 <ol type="a">
7418 <li>To keep the traits in sync with existing types.</li>
7419 <li>I see many reasons for programmers to use this trait in template
7420    code to provide optimized template definitions for these types,
7421    see below.</li>
7422 <li>A user-provided definition of this trait is practically impossible
7423 to write portably.</li>
7424 </ol>
7425
7426 <p>
7427 The special problem of reason (c) is that I don't see currently a
7428 way to portably test the condition for literal class types:
7429 </p>
7430
7431 <blockquote>
7432 <ul>
7433 <li>at least one constexpr constructor other than the copy constructor,</li>
7434 </ul>
7435 </blockquote>
7436
7437
7438
7439 <p><i>[
7440 Alisdair is considering preparing a paper listing a number of missing
7441 type traits, and feels that it might be useful to handle them all
7442 together rather than piecemeal. This would affect issue 719 and 750.
7443 These two issues should move to OPEN pending AM paper on type traits.
7444 ]</i></p>
7445
7446
7447 <p><i>[
7448 2009-07 Frankfurt:
7449 ]</i></p>
7450
7451
7452 <blockquote>
7453 Beman, Daniel, and Alisdair will work on a paper proposing new type traits.
7454 </blockquote>
7455
7456
7457 <p><b>Proposed resolution:</b></p>
7458 <p>
7459 In 20.6.2 [meta.type.synop] in the group "type properties",
7460 just below the line
7461 </p>
7462
7463 <blockquote><pre>template &lt;class T&gt; struct is_pod;
7464 </pre></blockquote>
7465
7466 <p>
7467 add a new one:
7468 </p>
7469
7470 <blockquote><pre>template &lt;class T&gt; struct is_literal;
7471 </pre></blockquote>
7472
7473 <p>
7474 In 20.6.4.3 [meta.unary.prop], table Type Property Predicates, just
7475 below the line for the <tt>is_pod</tt> property add a new line:
7476 </p>
7477
7478 <table border="1">
7479 <tbody><tr>
7480 <th>Template</th><th>Condition</th><th>Preconditions</th>
7481 </tr>
7482 <tr>
7483 <td><tt>template &lt;class T&gt; struct is_literal;</tt></td>
7484 <td><tt>T</tt> is a literal type (3.9)</td>
7485 <td><tt>T</tt> shall be a complete type, an
7486 array of unknown bound, or
7487 (possibly cv-qualified) <tt>void</tt>.</td>
7488 </tr>
7489 </tbody></table>
7490
7491
7492
7493
7494
7495
7496 <hr>
7497 <h3><a name="723"></a>723. <tt>basic_regex</tt> should be moveable</h3>
7498 <p><b>Section:</b> 28.8 [re.regex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
7499  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-08-29  <b>Last modified:</b> 2009-07-16</p>
7500 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.regex">issues</a> in [re.regex].</p>
7501 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
7502 <p><b>Discussion:</b></p>
7503
7504 <p><b>Addresses UK 316</b></p>
7505
7506 <p>
7507 According to the current state of the standard draft, the class
7508 template <tt>basic_regex</tt>, as described in 28.8 [re.regex]/3, is
7509 neither <tt>MoveConstructible</tt> nor <tt>MoveAssignable</tt>.
7510 IMO it should be, because typical regex state machines tend
7511 to have a rather large data quantum and I have seen several
7512 use cases, where a factory function returns regex values,
7513 which would take advantage of moveabilities.
7514 </p>
7515
7516 <p><i>[
7517 Sophia Antipolis:
7518 ]</i></p>
7519
7520
7521 <blockquote>
7522 Needs wording for the semantics, the idea is agreed upon.
7523 </blockquote>
7524
7525 <p><i>[
7526 Post Summit Daniel updated wording to reflect new "swap rules".
7527 ]</i></p>
7528
7529
7530 <p><i>[
7531 2009-07 Frankfurt:
7532 ]</i></p>
7533
7534
7535 <blockquote>
7536 Move to Ready.
7537 </blockquote>
7538
7539
7540
7541 <p><b>Proposed resolution:</b></p>
7542 <p>
7543 In the class definition of <tt>basic_regex</tt>, just below 28.8 [re.regex]/3,
7544 perform the following changes:
7545 </p>
7546
7547 <ol type="a">
7548 <li>
7549 <p>
7550 Just after <tt>basic_regex(const basic_regex&amp;);</tt> insert:
7551 </p>
7552
7553 <blockquote><pre>basic_regex(basic_regex&amp;&amp;);
7554 </pre></blockquote>
7555 </li>
7556 <li>
7557 <p>
7558 Just after <tt>basic_regex&amp; operator=(const basic_regex&amp;);</tt> insert:
7559 </p>
7560 <blockquote><pre>basic_regex&amp; operator=(basic_regex&amp;&amp;);
7561 </pre></blockquote>
7562 </li>
7563 <li>
7564 <p>
7565 Just after <tt>basic_regex&amp; assign(const basic_regex&amp; that);</tt> insert:
7566 </p>
7567 <blockquote><pre>basic_regex&amp; assign(basic_regex&amp;&amp; that);
7568 </pre></blockquote>
7569 </li>
7570 <li>
7571 <p>
7572 In 28.8.2 [re.regex.construct], just after p.11 add the following
7573 new member definition:
7574 </p>
7575 <blockquote><pre>basic_regex(basic_regex&amp;&amp; e);
7576 </pre>
7577 <blockquote>
7578 <p>
7579 <i>Effects:</i> Move-constructs a <tt>basic_regex</tt> instance from <tt>e</tt>.
7580 </p>
7581 <p>
7582 <i>Postconditions:</i> <tt>flags()</tt> and <tt>mark_count()</tt> return <tt>e.flags()</tt> and
7583 <tt>e.mark_count()</tt>, respectively,
7584 that <tt>e</tt> had before construction, leaving
7585 <tt>e</tt> in a valid state with an unspecified value.
7586 </p>
7587 <p>
7588 <i>Throws:</i> nothing.
7589 </p>
7590 </blockquote>
7591 </blockquote>
7592 </li>
7593 <li>
7594 <p>
7595 Also in 28.8.2 [re.regex.construct], just after p.18 add the
7596 following new member definition:
7597 </p>
7598
7599 <blockquote><pre>basic_regex&amp; operator=(basic_regex&amp;&amp; e);
7600 </pre>
7601 <blockquote>
7602 <i>Effects:</i> Returns the result of <tt>assign(std::move(e))</tt>.
7603 </blockquote>
7604 </blockquote>
7605 </li>
7606 <li>
7607 <p>
7608 In 28.8.3 [re.regex.assign], just after p. 2 add the following new
7609 member definition:
7610 </p>
7611 <blockquote><pre>basic_regex&amp; assign(basic_regex&amp;&amp; rhs);
7612 </pre>
7613 <blockquote>
7614 <p>
7615 <i>Effects:</i> Move-assigns a <tt>basic_regex</tt> instance from <tt>rhs</tt> and returns <tt>*this</tt>.
7616 </p>
7617 <p>
7618 <i>Postconditions:</i> <tt>flags()</tt> and <tt>mark_count()</tt> return <tt>rhs.flags()</tt>
7619 and <tt>rhs.mark_count()</tt>, respectively, that
7620 <tt>rhs</tt> had before assignment, leaving <tt>rhs</tt>
7621 in a valid state with an unspecified value.
7622 </p>
7623 <p>
7624 <i>Throws:</i> nothing.
7625 </p>
7626 </blockquote>
7627 </blockquote>
7628 </li>
7629 </ol>
7630
7631
7632
7633
7634
7635 <hr>
7636 <h3><a name="724"></a>724. <tt>DefaultConstructible</tt> is not defined</h3>
7637 <p><b>Section:</b> X [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
7638  <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2007-09-12  <b>Last modified:</b> 2009-07-28</p>
7639 <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>
7640 <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>
7641 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
7642 <p><b>Discussion:</b></p>
7643 <p>
7644 The <tt>DefaultConstructible</tt> requirement is referenced in
7645 several places in the August 2007 working draft
7646 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2369.pdf">N2369</a>,
7647 but is not defined anywhere.
7648 </p>
7649
7650 <p><i>[
7651 Bellevue:
7652 ]</i></p>
7653
7654
7655 <blockquote>
7656 <p>
7657 Walking into the default/value-initialization mess...
7658 </p>
7659 <p>
7660 Why two lines? Because we need both expressions to be valid.
7661 </p>
7662 <p>
7663 AJM not sure what the phrase "default constructed" means. This is
7664 unfortunate, as the phrase is already used 24 times in the library!
7665 </p>
7666 <p>
7667 Example: const int would not accept first line, but will accept the second.
7668 </p>
7669 <p>
7670 This is an issue that must be solved by concepts, but we might need to solve it independantly first.
7671 </p>
7672 <p>
7673 It seems that the requirements are the syntax in the proposed first
7674 column is valid, but not clear what semantics we need.
7675 </p>
7676 <p>
7677 A table where there is no post-condition seems odd, but appears to sum up our position best.
7678 </p>
7679 <p>
7680 At a minimum an object is declared and is destuctible.
7681 </p>
7682 <p>
7683 Move to open, as no-one happy to produce wording on the fly.
7684 </p>
7685 </blockquote>
7686
7687 <p><i>[
7688 2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
7689 ]</i></p>
7690
7691
7692
7693
7694 <p><b>Proposed resolution:</b></p>
7695 <p>
7696 In section X [utility.arg.requirements], before table 33, add the
7697 following table:
7698 </p>
7699
7700 <p style="text-align: center;" align="center">Table 33: <tt>DefaultConstructible</tt> requirements</p>
7701
7702 <div align="center">
7703
7704 <table style="border-collapse: collapse;" border="0" cellpadding="0" cellspacing="0">
7705  <tbody><tr>
7706   <td style="border-style: solid none double solid; border-color: navy -moz-use-text-color navy navy; border-width: 1pt medium 1.5pt 1pt; padding: 0in 5.4pt; width: 85.5pt;" valign="top" width="114">
7707   <p style="margin: 0in 0in 0.0001pt; text-align: center;" align="center">expression</p>
7708   </td>
7709   <td style="border-style: solid solid double none; border-color: navy navy navy -moz-use-text-color; border-width: 1pt 1pt 1.5pt medium; padding: 0in 5.4pt; width: 243pt;" valign="top" width="324">
7710   <p style="margin: 0in 0in 0.0001pt; text-align: center;" align="center">post-condition</p>
7711   </td>
7712  </tr>
7713  <tr>
7714   <td style="border-style: none none solid solid; border-color: -moz-use-text-color -moz-use-text-color navy navy; border-width: medium medium 1pt 1pt; padding: 0in 5.4pt; width: 85.5pt;" valign="top" width="114">
7715   <p style="margin: 0in 0in 0.0001pt;"><tt>T
7716   t;</tt><br>
7717   <tt>T()</tt></p>
7718   </td>
7719   <td style="border-style: none solid solid none; border-color: -moz-use-text-color navy navy -moz-use-text-color; border-width: medium 1pt 1pt medium; padding: 0in 5.4pt; width: 243pt;" valign="top" width="324">
7720   <p style="margin: 0in 0in 0.0001pt;"><tt>T</tt>
7721   is <i>default constructed.</i></p>
7722   </td>
7723  </tr>
7724 </tbody></table>
7725
7726 </div>
7727
7728
7729
7730 <p><b>Rationale:</b></p>
7731 <p><i>[
7732 San Francisco:
7733 ]</i></p>
7734
7735 <blockquote>
7736 We believe concepts will solve this problem
7737 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2774.pdf">N2774</a>).
7738 </blockquote>
7739
7740
7741
7742
7743
7744 <hr>
7745 <h3><a name="726"></a>726. Missing <tt>regex_replace()</tt> overloads</h3>
7746 <p><b>Section:</b> 28.11.4 [re.alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
7747  <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2007-09-22  <b>Last modified:</b> 2009-07-25</p>
7748 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re.alg.replace">active issues</a> in [re.alg.replace].</p>
7749 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.alg.replace">issues</a> in [re.alg.replace].</p>
7750 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
7751 <p><b>Discussion:</b></p>
7752 <p>
7753 Two overloads of <tt>regex_replace()</tt> are currently provided:
7754 </p>
7755
7756 <blockquote><pre>template &lt;class OutputIterator, class BidirectionalIterator,
7757     class traits, class charT&gt;
7758   OutputIterator
7759   regex_replace(OutputIterator out,
7760                 BidirectionalIterator first, BidirectionalIterator last,
7761                 const basic_regex&lt;charT, traits&gt;&amp; e,
7762                 const basic_string&lt;charT&gt;&amp; fmt,
7763                 regex_constants::match_flag_type flags =
7764                   regex_constants::match_default);
7765
7766 template &lt;class traits, class charT&gt;
7767   basic_string&lt;charT&gt;
7768   regex_replace(const basic_string&lt;charT&gt;&amp; s,
7769                 const basic_regex&lt;charT, traits&gt;&amp; e,
7770                 const basic_string&lt;charT&gt;&amp; fmt,
7771                 regex_constants::match_flag_type flags =
7772                   regex_constants::match_default);
7773 </pre></blockquote>
7774
7775 <ol>
7776 <li>Overloads taking <tt>const charT *</tt> are provided for <tt>regex_match()</tt> and
7777 <tt>regex_search()</tt>, but not <tt>regex_replace()</tt>.  This is inconsistent.</li>
7778 <li>
7779 <p>The absence of <tt>const charT *</tt> overloads prevents ordinary-looking code from compiling, such as:</p>
7780
7781 <blockquote><pre>const string s("kitten");
7782 const regex r("en");
7783 cout &lt;&lt; regex_replace(s, r, "y") &lt;&lt; endl;
7784 </pre></blockquote>
7785
7786 <p>
7787 The compiler error message will be something like "could not deduce
7788 template argument for 'const std::basic_string&lt;_Elem&gt; &amp;' from 'const
7789 char[1]'".
7790 </p>
7791
7792 <p>
7793 Users expect that anything taking a <tt>basic_string&lt;charT&gt;</tt> can also take a
7794 <tt>const charT *</tt>.  In their own code, when they write a function taking
7795 <tt>std::string</tt> (or <tt>std::wstring</tt>), they can pass a <tt>const char *</tt> (or <tt>const
7796 wchar_t *</tt>), thanks to <tt>basic_string</tt>'s implicit constructor.  Because the
7797 regex algorithms are templated on <tt>charT</tt>, they can't rely on
7798 <tt>basic_string</tt>'s implicit constructor (as the compiler error message
7799 indicates, template argument deduction fails first).
7800 </p>
7801
7802 <p>
7803 If a user figures out what the compiler error message means, workarounds
7804 are available - but they are all verbose.  Explicit template arguments
7805 could be given to <tt>regex_replace()</tt>, allowing <tt>basic_string</tt>'s implicit
7806 constructor to be invoked - but <tt>charT</tt> is the last template argument, not
7807 the first, so this would be extremely verbose.  Therefore, constructing
7808 a <tt>basic_string</tt> from each C string is the simplest workaround.
7809 </p>
7810 </li>
7811
7812 <li>
7813 There is an efficiency consideration: constructing <tt>basic_string</tt>s can
7814 impose performance costs that could be avoided by a library
7815 implementation taking C strings and dealing with them directly.
7816 (Currently, for replacement sources, C strings can be converted into
7817 iterator pairs at the cost of verbosity, but for format strings, there
7818 is no way to avoid constructing a <tt>basic_string</tt>.)
7819 </li>
7820 </ol>
7821
7822 <p><i>[
7823 Sophia Antipolis:
7824 ]</i></p>
7825
7826
7827 <blockquote>
7828 We note that Boost already has these overloads. However, the proposed
7829 wording is provided only for 28.11.4 [re.alg.replace]; wording is needed for the synopsis
7830 as well. We also note that this has impact on <tt>match_results::format</tt>,
7831 which may require further overloads.
7832 </blockquote>
7833
7834 <p><i>[
7835 2009-07 Frankfurt:
7836 ]</i></p>
7837
7838
7839 <blockquote>
7840 Daniel to tweak for us.
7841 </blockquote>
7842
7843 <p><i>[
7844 2009-07-25 Daniel tweaks both this issue and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>.
7845 ]</i></p>
7846
7847
7848 <blockquote>
7849 <p>
7850 This is solved by the proposed resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>.
7851 </p>
7852 </blockquote>
7853
7854
7855
7856 <p><b>Proposed resolution:</b></p>
7857
7858 <p>
7859 Provide additional overloads for <tt>regex_replace()</tt>: one additional
7860 overload of the iterator-based form (taking <tt>const charT* fmt</tt>), and three
7861 additional overloads of the convenience form (one taking <tt>const charT*
7862 str</tt>, another taking <tt>const charT* fmt</tt>, and the third taking both <tt>const
7863 charT* str</tt> and <tt>const charT* fmt</tt>).  28.11.4 [re.alg.replace]:
7864 </p>
7865
7866 <blockquote>
7867 <pre>template &lt;class OutputIterator, class BidirectionalIterator,
7868     class traits, class charT&gt;
7869   OutputIterator
7870   regex_replace(OutputIterator out,
7871                 BidirectionalIterator first, BidirectionalIterator last,
7872                 const basic_regex&lt;charT, traits&gt;&amp; e,
7873                 const basic_string&lt;charT&gt;&amp; fmt,
7874                 regex_constants::match_flag_type flags =
7875                   regex_constants::match_default);
7876
7877 <ins>template &lt;class OutputIterator, class BidirectionalIterator,
7878     class traits, class charT&gt;
7879   OutputIterator
7880   regex_replace(OutputIterator out,
7881                 BidirectionalIterator first, BidirectionalIterator last,
7882                 const basic_regex&lt;charT, traits&gt;&amp; e,
7883                 const charT* fmt,
7884                 regex_constants::match_flag_type flags =
7885                   regex_constants::match_default);</ins>
7886 </pre>
7887 <p>...</p>
7888 <pre>template &lt;class traits, class charT&gt;
7889   basic_string&lt;charT&gt;
7890   regex_replace(const basic_string&lt;charT&gt;&amp; s,
7891                 const basic_regex&lt;charT, traits&gt;&amp; e,
7892                 const basic_string&lt;charT&gt;&amp; fmt,
7893                 regex_constants::match_flag_type flags =
7894                   regex_constants::match_default);
7895
7896 <ins>template &lt;class traits, class charT&gt;
7897   basic_string&lt;charT&gt;
7898   regex_replace(const basic_string&lt;charT&gt;&amp; s,
7899                 const basic_regex&lt;charT, traits&gt;&amp; e,
7900                 const charT* fmt,
7901                 regex_constants::match_flag_type flags =
7902                   regex_constants::match_default);</ins>
7903
7904 <ins>template &lt;class traits, class charT&gt;
7905   basic_string&lt;charT&gt;
7906   regex_replace(const charT* s,
7907                 const basic_regex&lt;charT, traits&gt;&amp; e,
7908                 const basic_string&lt;charT&gt;&amp; fmt,
7909                 regex_constants::match_flag_type flags =
7910                   regex_constants::match_default);</ins>
7911
7912 <ins>template &lt;class traits, class charT&gt;
7913   basic_string&lt;charT&gt;
7914   regex_replace(const charT* s,
7915                 const basic_regex&lt;charT, traits&gt;&amp; e,
7916                 const charT* fmt,
7917                 regex_constants::match_flag_type flags =
7918                   regex_constants::match_default);</ins>
7919 </pre>
7920 </blockquote>
7921
7922
7923
7924
7925
7926
7927 <hr>
7928 <h3><a name="727"></a>727. <tt>regex_replace()</tt> doesn't accept <tt>basic_string</tt>s with custom traits and allocators</h3>
7929 <p><b>Section:</b> 28.11.4 [re.alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
7930  <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2007-09-22  <b>Last modified:</b> 2009-07-31</p>
7931 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re.alg.replace">active issues</a> in [re.alg.replace].</p>
7932 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.alg.replace">issues</a> in [re.alg.replace].</p>
7933 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
7934 <p><b>Discussion:</b></p>
7935 <p>
7936 <tt>regex_match()</tt> and <tt>regex_search()</tt> take <tt>const basic_string&lt;charT, ST,
7937 SA&gt;&amp;</tt>.  <tt>regex_replace()</tt> takes <tt>const basic_string&lt;charT&gt;&amp;</tt>.  This prevents
7938 <tt>regex_replace()</tt> from accepting <tt>basic_string</tt>s with custom traits and
7939 allocators.
7940 </p>
7941
7942 <p>
7943 Overloads of <tt>regex_replace()</tt> taking <tt>basic_string</tt> should be additionally
7944 templated on <tt>class ST, class SA</tt> and take <tt>const basic_string&lt;charT, ST,
7945 SA&gt;&amp;</tt>.  Consistency with <tt>regex_match()</tt> and <tt>regex_search()</tt> would place
7946 <tt>class ST, class SA</tt> as the first template arguments; compatibility with
7947 existing code using TR1 and giving explicit template arguments to
7948 <tt>regex_replace()</tt> would place <tt>class ST, class SA</tt> as the last template
7949 arguments.
7950 </p>
7951
7952 <p><i>[
7953 Batavia (2009-05):
7954 ]</i></p>
7955
7956 <blockquote>
7957 <p>
7958 Bill comments, "We need to look at the depth of this change."
7959 </p>
7960 <p>
7961 Pete remarks that we are here dealing with a convenience function
7962 that saves a user from calling the iterato-based overload.
7963 </p>
7964 <p>
7965 Move to Open.
7966 </p>
7967 </blockquote>
7968
7969 <p><i>[
7970 2009-07 Frankfurt:
7971 ]</i></p>
7972
7973
7974 <blockquote>
7975 Howard to ask Stephan Lavavej to provide wording.
7976 </blockquote>
7977
7978 <p><i>[
7979 2009-07-17 Stephan provided wording.
7980 ]</i></p>
7981
7982
7983 <p><i>[
7984 2009-07-25 Daniel tweaks both this issue and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>.
7985 ]</i></p>
7986
7987
7988 <blockquote>
7989 <p>
7990 One relevant part of the proposed resolution below suggests
7991 to add a new overload of the format member function in the
7992 <tt>match_results</tt> class template that accepts two character pointers
7993 defining the <tt>begin</tt> and <tt>end</tt> of a format range. A more general
7994 approach could have proposed a pair of iterators instead, but
7995 the used pair of char pointers reflects existing practice. If the
7996 committee strongly favors an iterator-based signature, this
7997 could be simply changed. I think that the minimum requirement
7998 should be a <tt>BidirectionalIterator</tt>, but current implementations
7999 take advantage (at least partially) of the <tt>RandomAccessIterator</tt>
8000 sub interface of the char pointers.
8001 </p>
8002
8003 <p><b>Suggested Resolution:</b></p>
8004
8005 <p><i>[Moved into the proposed resloution]</i></p>
8006
8007
8008
8009 </blockquote>
8010
8011 <p><i>[
8012 2009-07-30 Stephan agrees with Daniel's wording.  Howard places Daniel's wording
8013 in the Proposed Resolution.
8014 ]</i></p>
8015
8016
8017
8018
8019 <p><b>Proposed resolution:</b></p>
8020
8021 <ol>
8022 <li>
8023 <p>
8024 Change 28.4 [re.syn] as indicated:
8025 </p>
8026
8027 <blockquote><pre>// 28.11.4, function template regex_replace:
8028 template &lt;class OutputIterator, class BidirectionalIterator,
8029           class traits, class charT<ins>, class ST, class SA</ins>&gt;
8030   OutputIterator
8031   regex_replace(OutputIterator out,
8032                 BidirectionalIterator first, BidirectionalIterator last,
8033                 const basic_regex&lt;charT, traits&gt;&amp; e,
8034                 const basic_string&lt;charT<ins>, ST, SA</ins>&gt;&amp; fmt,
8035                 regex_constants::match_flag_type flags =
8036                   regex_constants::match_default);
8037
8038 <ins>
8039 template &lt;class OutputIterator, class BidirectionalIterator,
8040           class traits, class charT&gt;
8041   OutputIterator
8042   regex_replace(OutputIterator out,
8043                 BidirectionalIterator first, BidirectionalIterator last,
8044                 const basic_regex&lt;charT, traits&gt;&amp; e,
8045                 const charT* fmt,
8046                 regex_constants::match_flag_type flags =
8047                   regex_constants::match_default);
8048 </ins>
8049
8050 template &lt;class traits, class charT<ins>, class ST, class SA,
8051           class FST, class FSA</ins>&gt;
8052   basic_string&lt;charT<ins>, ST, SA</ins>&gt;
8053   regex_replace(const basic_string&lt;charT<ins>, ST, SA</ins>&gt;&amp; s,
8054                 const basic_regex&lt;charT, traits&gt;&amp; e,
8055                 const basic_string&lt;charT<ins>, FST, FSA</ins>&gt;&amp; fmt,
8056                 regex_constants::match_flag_type flags =
8057                   regex_constants::match_default);
8058
8059 <ins>
8060 template &lt;class traits, class charT, class ST, class SA&gt;
8061   basic_string&lt;charT, ST, SA&gt;
8062   regex_replace(const basic_string&lt;charT, ST, SA&gt;&amp; s,
8063                 const basic_regex&lt;charT, traits&gt;&amp; e,
8064                 const charT* fmt,
8065                 regex_constants::match_flag_type flags =
8066                   regex_constants::match_default);
8067 </ins>
8068
8069 <ins>
8070 template &lt;class traits, class charT, class ST, class SA&gt;
8071   basic_string&lt;charT&gt;
8072   regex_replace(const charT* s,
8073                 const basic_regex&lt;charT, traits&gt;&amp; e,
8074                 const basic_string&lt;charT, ST, SA&gt;&amp; fmt,
8075                 regex_constants::match_flag_type flags =
8076                   regex_constants::match_default);
8077 </ins>
8078
8079 <ins>
8080 template &lt;class traits, class charT&gt;
8081   basic_string&lt;charT&gt;
8082   regex_replace(const charT* s,
8083                 const basic_regex&lt;charT, traits&gt;&amp; e,
8084                 const charT* fmt,
8085                 regex_constants::match_flag_type flags =
8086                   regex_constants::match_default);
8087 </ins>
8088 </pre></blockquote>
8089 </li>
8090
8091 <li>
8092 <p>
8093 Change 28.10 [re.results]/3, class template <tt>match_results</tt> as
8094 indicated:
8095 </p>
8096
8097 <blockquote><pre><ins>
8098 template &lt;class OutputIter&gt;
8099   OutputIter
8100   format(OutputIter out,
8101          const char_type* fmt_first, const char_type* fmt_last,
8102          regex_constants::match_flag_type flags =
8103            regex_constants::format_default) const;
8104 </ins>
8105
8106 template &lt;class OutputIter<ins>, class ST, class SA</ins>&gt;
8107   OutputIter
8108   format(OutputIter out,
8109          const <del>string_type</del><ins>basic_string&lt;char_type, ST, SA&gt;</ins>&amp; fmt,
8110          regex_constants::match_flag_type flags =
8111            regex_constants::format_default) const;
8112
8113 <ins>template &lt;class ST, class SA&gt;</ins>
8114   <del>string_type</del><ins>basic_string&lt;char_type, ST, SA&gt;</ins>
8115   format(const <del>string_type</del><ins>basic_string&lt;char_type, ST, SA&gt;</ins>&amp; fmt,
8116          regex_constants::match_flag_type flags =
8117            regex_constants::format_default) const;
8118
8119 <ins>
8120 string_type
8121 format(const char_type* fmt,
8122        regex_constants::match_flag_type flags =
8123          regex_constants::format_default) const;
8124 </ins>
8125 </pre></blockquote>
8126 </li>
8127
8128 <li>
8129 <p>
8130 Insert at the very beginning of 28.10.4 [re.results.form] the following:
8131 </p>
8132
8133 <blockquote><pre><ins>
8134 template &lt;class OutputIter&gt;
8135   OutputIter
8136   format(OutputIter out,
8137          const char_type* fmt_first, const char_type* fmt_last,
8138          regex_constants::match_flag_type flags =
8139            regex_constants::format_default) const;
8140 </ins>
8141 </pre>
8142 <blockquote>
8143
8144 <p><ins>
8145 1 <i>Requires:</i> The type <tt>OutputIter</tt> shall satisfy the requirements for an
8146 Output Iterator (24.2.3 [output.iterators]).
8147 </ins></p>
8148
8149 <p><ins>
8150 2 <i>Effects:</i> Copies the character sequence <tt>[fmt_first,fmt_last)</tt> to
8151 <tt>OutputIter out</tt>. Replaces each
8152 format specifier or escape sequence in the copied range with either
8153 the character(s) it represents
8154 or the sequence of characters within <tt>*this</tt> to which it refers. The
8155 bitmasks specified in <tt>flags</tt>
8156 determines what format specifiers and escape sequences are recognized.
8157 </ins></p>
8158
8159 <p><ins>
8160 3 <i>Returns:</i> <tt>out</tt>.
8161 </ins></p>
8162 </blockquote>
8163 </blockquote>
8164 </li>
8165
8166 <li>
8167 <p>
8168 Change 28.10.4 [re.results.form], before p. 1 until p. 3 (according to
8169 previous numbering)
8170 as indicated:
8171 </p>
8172
8173 <blockquote><pre>template &lt;class OutputIter<ins>, class ST, class SA</ins>&gt;
8174   OutputIter
8175   format(OutputIter out,
8176          const <del>string_type</del><ins>basic_string&lt;char_type, ST, SA&gt;</ins>&amp; fmt,
8177          regex_constants::match_flag_type flags =
8178            regex_constants::format_default) const;
8179 </pre>
8180
8181 <blockquote>
8182 <p>
8183 <del><i>Requires:</i> The type <tt>OutputIter</tt> shall satisfy the requirements for
8184 an Output Iterator (24.2.3).</del>
8185 </p>
8186
8187 <p>
8188 <del><i>Effects:</i> Copies the character sequence <tt>[fmt.begin(),fmt.end())</tt> to
8189 <tt>OutputIter out</tt>. Replaces each
8190 format specifier or escape sequence in <tt>fmt</tt> with either the
8191 character(s) it represents or the sequence of
8192 characters within <tt>*this</tt> to which it refers. The bitmasks specified in
8193 <tt>flags</tt> determines what format
8194 specifiers and escape sequences are recognized.</del>
8195 </p>
8196
8197 <p>
8198 <i>Returns:</i> <tt><del>out</del><ins>format(out, fmt.data(), fmt.data() +
8199 fmt.size(), flags)</ins></tt>.
8200 </p>
8201 </blockquote>
8202 </blockquote>
8203 </li>
8204
8205 <li>
8206 <p>
8207 Change 28.10.4 [re.results.form], before p. 4 until p. 4 (according to
8208 previous numbering) as indicated:
8209 </p>
8210
8211 <blockquote><pre><ins>template &lt;class ST, class SA&gt;</ins>
8212   <del>string_type</del><ins>basic_string&lt;char_type, ST, SA&gt;</ins>
8213   format(const <del>string_type</del><ins>basic_string&lt;char_type, ST, SA&gt;</ins>&amp; fmt,
8214          regex_constants::match_flag_type flags =
8215            regex_constants::format_default) const;
8216 </pre>
8217
8218 <blockquote>
8219 <p>
8220 <i>Effects:</i> <del>Returns a copy of the string <tt>fmt</tt>. Replaces each format
8221 specifier or escape sequence
8222 in <tt>fmt</tt> with either the character(s) it represents or the sequence of
8223 characters within <tt>*this</tt> to which
8224 it refers. The bitmasks specified in flags determines what format
8225 specifiers and escape sequences are
8226 recognized.</del> <ins>Constructs an empty string result of type
8227 <tt>basic_string&lt;char_type, ST, SA&gt;</tt>,
8228 and calls <tt>format(back_inserter(result), fmt, flags)</tt>.</ins>
8229 </p>
8230
8231 <p>
8232 <ins><i>Returns:</i> <tt>result</tt></ins>
8233 </p>
8234 </blockquote>
8235 </blockquote>
8236 </li>
8237
8238 <li>
8239 <p>
8240 At the end of 28.10.4 [re.results.form] insert as indicated:
8241 </p>
8242
8243 <blockquote><pre><ins>
8244 string_type
8245   format(const char_type* fmt,
8246          regex_constants::match_flag_type flags =
8247            regex_constants::format_default) const;
8248 </ins></pre>
8249
8250 <blockquote>
8251 <p>
8252 <ins><i>Effects:</i> Constructs an empty string result of type <tt>string_type</tt>, and calls
8253 <tt>format(back_inserter(result), fmt, fmt +
8254 char_traits&lt;char_type&gt;::length(fmt), flags)</tt>.</ins>
8255 </p>
8256 <p>
8257 <ins><i>Returns:</i> <tt>result</tt></ins>
8258 </p>
8259 </blockquote>
8260 </blockquote>
8261
8262 </li>
8263
8264 <li>
8265 <p>
8266 Change 28.11.4 [re.alg.replace] before p. 1 as indicated:
8267 </p>
8268
8269 <blockquote><pre>template &lt;class OutputIterator, class BidirectionalIterator,
8270           class traits, class charT<ins>, class ST, class SA</ins>&gt;
8271   OutputIterator
8272   regex_replace(OutputIterator out,
8273                 BidirectionalIterator first, BidirectionalIterator last,
8274                 const basic_regex&lt;charT, traits&gt;&amp; e,
8275                 const basic_string&lt;charT<ins>, ST, SA</ins>&gt;&amp; fmt,
8276                 regex_constants::match_flag_type flags =
8277                   regex_constants::match_default);
8278
8279 <ins>
8280 template &lt;class OutputIterator, class BidirectionalIterator,
8281           class traits, class charT&gt;
8282   OutputIterator
8283   regex_replace(OutputIterator out,
8284                 BidirectionalIterator first, BidirectionalIterator last,
8285                 const basic_regex&lt;charT, traits&gt;&amp; e,
8286                 const charT* fmt,
8287                 regex_constants::match_flag_type flags =
8288                   regex_constants::match_default);
8289 </ins></pre>
8290
8291 <blockquote>
8292 <i>Effects:</i> [..]. If any matches are found then, for each such match, if <tt>!(flags &amp;
8293  regex_constants::format_no_copy)</tt> calls <tt>std::copy(m.prefix().first,
8294 m.prefix().second,
8295  out)</tt>, and then calls <tt>m.format(out, fmt, flags)</tt> <ins>for the first
8296 form of the function
8297  and <tt>m.format(out, fmt, fmt + char_traits&lt;charT&gt;::length(fmt), flags)</tt>
8298 for the second
8299  form</ins>. [..].
8300 </blockquote>
8301 </blockquote>
8302 </li>
8303
8304 <li>
8305 <p>
8306 Change 28.11.4 [re.alg.replace] before p. 3 as indicated:
8307 </p>
8308
8309 <blockquote><pre>template &lt;class traits, class charT<ins>, class ST, class SA,
8310           class FST, class FSA</ins>&gt;
8311   basic_string&lt;charT<ins>, ST, SA</ins>&gt;
8312   regex_replace(const basic_string&lt;charT<ins>, ST, SA</ins>&gt;&amp; s,
8313                 const basic_regex&lt;charT, traits&gt;&amp; e,
8314                 const basic_string&lt;charT<ins>, FST, FSA</ins>&gt;&amp; fmt,
8315                 regex_constants::match_flag_type flags =
8316                   regex_constants::match_default);
8317
8318 <ins>
8319 template &lt;class traits, class charT, class ST, class SA&gt;
8320   basic_string&lt;charT, ST, SA&gt;
8321   regex_replace(const basic_string&lt;charT, ST, SA&gt;&amp; s,
8322                 const basic_regex&lt;charT, traits&gt;&amp; e,
8323                 const charT* fmt,
8324                 regex_constants::match_flag_type flags =
8325                   regex_constants::match_default);
8326 </ins></pre>
8327
8328 <blockquote>
8329 <i>Effects:</i> Constructs an empty string result of type <tt>basic_string&lt;charT<ins>,
8330 ST, SA</ins>&gt;</tt>, calls <tt>regex_replace(back_inserter(result), s.begin(), s.end(),
8331 e, fmt, flags)</tt>, and then returns <tt>result</tt>.
8332 </blockquote>
8333 </blockquote>
8334 </li>
8335
8336 <li>
8337 <p>
8338 At the end of 28.11.4 [re.alg.replace] add the following new prototype description:
8339 </p>
8340
8341 <blockquote><pre><ins>
8342 template &lt;class traits, class charT, class ST, class SA&gt;
8343   basic_string&lt;charT&gt;
8344   regex_replace(const charT* s,
8345                 const basic_regex&lt;charT, traits&gt;&amp; e,
8346                 const basic_string&lt;charT, ST, SA&gt;&amp; fmt,
8347                 regex_constants::match_flag_type flags =
8348                   regex_constants::match_default);
8349 </ins>
8350
8351 <ins>
8352 template &lt;class traits, class charT&gt;
8353   basic_string&lt;charT&gt;
8354   regex_replace(const charT* s,
8355                 const basic_regex&lt;charT, traits&gt;&amp; e,
8356                 const charT* fmt,
8357                 regex_constants::match_flag_type flags =
8358                   regex_constants::match_default);
8359 </ins></pre>
8360
8361 <blockquote>
8362 <ins>
8363 <i>Effects:</i> Constructs an empty string result of type <tt>basic_string&lt;charT&gt;</tt>,
8364 calls <tt>regex_replace(back_inserter(result), s, s +
8365 char_traits&lt;charT&gt;::length(s),
8366 e, fmt, flags)</tt>, and then returns <tt>result</tt>.
8367 </ins>
8368 </blockquote>
8369 </blockquote>
8370 </li>
8371
8372 </ol>
8373
8374
8375
8376
8377
8378
8379
8380 <hr>
8381 <h3><a name="742"></a>742. Enabling <tt>swap</tt> for proxy iterators</h3>
8382 <p><b>Section:</b> X [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
8383  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-10-10  <b>Last modified:</b> 2009-07-28</p>
8384 <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>
8385 <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>
8386 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
8387 <p><b>Discussion:</b></p>
8388 <p>
8389 This issue was split from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>. <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a> now just
8390 deals with changing the requirements of <tt>T</tt> in the <tt>Swappable</tt>
8391 requirement from <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt> to
8392 <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.
8393 </p>
8394
8395 <p>
8396 This issue seeks to widen the <tt>Swappable</tt> requirement to support proxy iterators.  Here
8397 is example code:
8398 </p>
8399
8400 <blockquote><pre>namespace Mine {
8401
8402 template &lt;class T&gt;
8403 struct proxy {...};
8404
8405 template &lt;class T&gt;
8406 struct proxied_iterator
8407 {
8408    typedef T value_type;
8409    typedef proxy&lt;T&gt; reference;
8410    reference operator*() const;
8411    ...
8412 };
8413
8414 struct A
8415 {
8416    // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
8417    void swap(A&amp;);
8418    ...
8419 };
8420
8421 void swap(A&amp;, A&amp;);
8422 void swap(proxy&lt;A&gt;, A&amp;);
8423 void swap(A&amp;, proxy&lt;A&gt;);
8424 void swap(proxy&lt;A&gt;, proxy&lt;A&gt;);
8425
8426 }  // Mine
8427
8428 ...
8429
8430 Mine::proxied_iterator&lt;Mine::A&gt; i(...)
8431 Mine::A a;
8432 <b>swap(*i1, a);</b>
8433 </pre></blockquote>
8434
8435 <p>
8436 The key point to note in the above code is that in the call to <tt>swap</tt>, <tt>*i1</tt>
8437 and <tt>a</tt> are different types (currently types can only be <tt>Swappable</tt> with the
8438 same type).  A secondary point is that to support proxies, one must be able to pass rvalues
8439 to <tt>swap</tt>.  But note that I am not stating that the general purpose <tt>std::swap</tt>
8440 should accept rvalues!  Only that overloaded <tt>swap</tt>s, as in the example above, be allowed
8441 to take rvalues.
8442 </p>
8443
8444 <p>
8445 That is, no standard library code needs to change.  We simply need to have a more flexible
8446 definition of <tt>Swappable</tt>.
8447 </p>
8448
8449 <p><i>[
8450 Bellevue:
8451 ]</i></p>
8452
8453
8454 <blockquote>
8455 <p>
8456 While we believe Concepts work will define a swappable concept, we
8457 should still resolve this issue if possible to give guidance to the
8458 Concepts work.
8459 </p>
8460 <p>
8461 Would an ambiguous swap function in two namespaces found by ADL break
8462 this wording? Suggest that the phrase "valid expression" means such a
8463 pair of types would still not be swappable.
8464 </p>
8465 <p>
8466 Motivation is proxy-iterators, but facility is considerably more
8467 general. Are we happy going so far?
8468 </p>
8469 <p>
8470 We think this wording is probably correct and probably an improvement on
8471 what's there in the WP. On the other hand, what's already there in the
8472 WP is awfully complicated. Why do we need the two bullet points? They're
8473 too implementation-centric. They don't add anything to the semantics of
8474 what swap() means, which is there in the post-condition. What's wrong
8475 with saying that types are swappable if you can call swap() and it
8476 satisfies the semantics of swapping?
8477 </p>
8478 </blockquote>
8479
8480 <p><i>[
8481 2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
8482 ]</i></p>
8483
8484
8485
8486
8487 <p><b>Proposed resolution:</b></p>
8488 <p>
8489 Change X [utility.arg.requirements]:
8490 </p>
8491
8492 <blockquote>
8493
8494 <p>
8495 -1- The template definitions in the C++ Standard Library refer to various
8496 named requirements whose details are set out in tables 31-38. In these
8497 tables, <tt>T</tt> <ins>and <tt>V</tt> are</ins> <del>is a</del> type<ins>s</ins> to be supplied by a C++ program
8498 instantiating a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
8499 values of type <tt>const T</tt>; <tt>s</tt> and <tt>t</tt> are modifiable
8500 lvalues of type <tt>T</tt>; <tt>u</tt> is a value of type (possibly
8501 <tt>const</tt>) <tt>T</tt>; <del>and</del> <tt>rv</tt> is a non-<tt>const</tt>
8502 rvalue of type <tt>T</tt><ins>; <tt>w</tt> is a value of type <tt>T</tt>; and <tt>v</tt> is a value of type <tt>V</tt></ins>.
8503 </p>
8504
8505 <table border="1">
8506 <caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
8507 <tbody><tr><th>expression</th><th>return type</th><th>post-condition</th></tr>
8508 <tr><td><tt>swap(<del>s</del><ins>w</ins>,<del>t</del><ins>v</ins>)</tt></td><td><tt>void</tt></td>
8509 <td><del><tt>t</tt></del><ins><tt>w</tt></ins> has the value originally
8510 held by <del><tt>u</tt></del><ins><tt>v</tt></ins>, and
8511 <del><tt>u</tt></del><ins><tt>v</tt></ins> has the value originally held
8512 by <del><tt>t</tt></del><ins><tt>w</tt></ins></td></tr>
8513 <tr><td colspan="3">
8514 <p>
8515 The <tt>Swappable</tt> requirement is met by satisfying one or more of the following conditions:
8516 </p>
8517 <ul>
8518 <li>
8519 <tt>T</tt> is <tt>Swappable</tt> if <ins><tt>T</tt> and <tt>V</tt> are
8520 the same type and </ins> <tt>T</tt> satisfies the
8521 <del><tt>CopyConstructible</tt></del>
8522 <ins><tt>MoveConstructible</tt></ins> requirements (Table <del>34</del>
8523 <ins>33</ins>) and the <del><tt>CopyAssignable</tt></del>
8524 <ins><tt>MoveAssignable</tt></ins> requirements (Table <del>36</del>
8525 <ins>35</ins>);
8526 </li>
8527 <li>
8528 <tt>T</tt> is <tt>Swappable</tt> <ins>with <tt>V</tt></ins> if a namespace scope function named
8529 <tt>swap</tt> exists in the same namespace as the definition of
8530 <tt>T</tt> <ins>or <tt>V</tt></ins>, such that the expression
8531 <tt>swap(<del>t</del><ins>w</ins>,<del>u</del> <ins>v</ins>)</tt> is valid and has the
8532 semantics described in this table.
8533 </li>
8534 </ul>
8535 </td></tr>
8536 </tbody></table>
8537 </blockquote>
8538
8539
8540
8541 <p><b>Rationale:</b></p>
8542 <p><i>[
8543 post San Francisco:
8544 ]</i></p>
8545
8546
8547 <blockquote>
8548 Solved by
8549 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/N2758.pdf">N2758</a>.
8550 </blockquote>
8551
8552
8553
8554
8555
8556
8557 <hr>
8558 <h3><a name="774"></a>774. Member swap undefined for most containers</h3>
8559 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
8560  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-01-14  <b>Last modified:</b> 2009-07-30</p>
8561 <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>
8562 <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>
8563 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
8564 <p><b>Discussion:</b></p>
8565 <p>
8566 It appears most containers declare but do not define a member-swap
8567 function.
8568 </p>
8569
8570 <p>
8571 This is unfortunate, as all overload the <tt>swap</tt> algorithm to call the
8572 member-swap function!
8573 (required for <tt>swappable</tt> guarantees [Table 37] and Container Requirements
8574 [Table 87])
8575 </p>
8576
8577 <p>
8578 Note in particular that Table 87 gives semantics of <tt>a.swap(b)</tt> as <tt>swap(a,b)</tt>,
8579 yet for all containers we define <tt>swap(a,b)</tt> to call <tt>a.swap(b)</tt> - a circular
8580 definition.
8581 </p>
8582
8583 <p>
8584 A quick survey of clause 23 shows that the following containers provide a
8585 definition for member-swap:
8586 </p>
8587
8588 <blockquote><pre>array
8589 queue
8590 stack
8591 vector
8592 </pre></blockquote>
8593
8594 <p>
8595 Whereas the following declare it, but do not define the semantics:
8596 </p>
8597
8598 <blockquote><pre>deque
8599 list
8600 map
8601 multimap
8602 multiset
8603 priority_queue
8604 set
8605 unordered_map
8606 unordered_multi_map
8607 unordered_multi_set
8608 unordered_set
8609 </pre></blockquote>
8610
8611 <p>
8612 Suggested resolution:
8613 </p>
8614 <blockquote>
8615 Provide a definition for each of the affected containers...
8616 </blockquote>
8617
8618 <p><i>[
8619 Bellevue:
8620 ]</i></p>
8621
8622
8623 <blockquote>
8624 Move to Open and ask Alisdair to provide wording.
8625 </blockquote>
8626
8627 <p><i>[
8628 2009-07 Frankfurt:
8629 ]</i></p>
8630
8631
8632 <blockquote>
8633 Daniel to provide wording.
8634 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2590.pdf">N2590</a>
8635 is no longer applicable.
8636 </blockquote>
8637
8638 <p><i>[
8639 2009-07-28 Daniel provided wording.
8640 ]</i></p>
8641
8642
8643 <blockquote>
8644 <ol>
8645 <li>
8646 It assumes that the proposed resolution for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#883">883</a> is applied,
8647 which breaks the circularity of definition between member
8648 <tt>swap</tt> and free <tt>swap</tt>.
8649 </li>
8650
8651 <li>
8652 It uses the notation of the pre-concept allocator trait
8653 <tt>allocator_propagation_map</tt>, which might be renamed after the
8654 next refactoring phase of generalized allocators.
8655 </li>
8656
8657 <li>
8658 It requires that compare objects, key equal functions and
8659 hash functions in containers are swapped via unqualified free
8660 <tt>swap</tt> according to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#594">594</a>.
8661 </li>
8662 </ol>
8663 </blockquote>
8664
8665
8666 <p><b>Proposed resolution:</b></p>
8667 <ol>
8668 <li>
8669 <p>
8670 Add a new Throws clause just after X [allocator.propagation.map]/5:
8671 </p>
8672
8673 <blockquote><pre>static void swap(Alloc&amp; a, Alloc&amp; b);
8674 </pre>
8675 <blockquote>
8676 <p>
8677 <i>Effects:</i> [..]
8678 </p>
8679
8680 <p>
8681 <ins><i>Throws:</i> Nothing.</ins>
8682 </p>
8683 </blockquote>
8684 </blockquote>
8685 <p><i>[
8686 This exception requirement is added, such that it's combination with the
8687 general container requirements of
8688 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
8689 [container.requirements.general]/9
8690 make it unambiguously clear that the following descriptions of "swaps the
8691 allocators" have the following meaning: (a) This swap is done by calling
8692 <tt>allocator_propagation_map&lt;allocator_type&gt;::swap</tt> and (b) This allocator
8693 swap does never propagate an exception
8694 ]</i></p>
8695
8696 </li>
8697
8698 <li>
8699 <p>
8700 Change 23.2.4.1 [associative.reqmts.except]/3 as indicated:
8701 </p>
8702
8703 <blockquote>
8704 For associative containers, no <tt>swap</tt> function throws an exception unless that
8705 exception is thrown by the <del>copy constructor or copy assignment
8706 operator</del>
8707 <ins><tt>swap</tt></ins> of the container's <tt>Pred</tt> object<ins>s</ins><del> (if any)</del>.
8708 </blockquote>
8709 </li>
8710
8711 <li>
8712 <p>
8713 Change 23.2.5.1 [unord.req.except]/3 as indicated:
8714 </p>
8715
8716 <blockquote>
8717 For unordered associative containers, no <tt>swap</tt> function throws an
8718 exception unless
8719 that exception is thrown by the <del>copy constructor or copy
8720 assignment operator</del>
8721 <ins><tt>swap</tt></ins> of the container's <tt>Hash</tt> or <tt>Pred</tt> object<ins>s,
8722 respectively</ins><del> (if any)</del>.
8723 </blockquote>
8724 </li>
8725
8726 <li>
8727 <p>
8728 Insert a new paragraph just after 23.3 [sequences]/1:
8729 </p>
8730
8731 <blockquote>
8732 <ins>In addition to being available via inclusion of the <tt>&lt;algorithm&gt;</tt> header,
8733 the <tt>swap</tt> function templates in 25.4.3 [alg.swap] are also available when the
8734 header <tt>&lt;queue&gt;</tt> is included.</ins>
8735 </blockquote>
8736
8737 <p><i>[
8738 There is a new issue in process that will suggest a minimum header for <tt>swap</tt>
8739 and <tt>move</tt>. If this one is provided, this text can be removed and the header
8740 dependency should be added to <tt>&lt;queue&gt;</tt>
8741 ]</i></p>
8742
8743
8744 </li>
8745
8746 <li>
8747 <p>
8748 Add one further clause at the end of 23.3.1.2 [array.special]:
8749 </p>
8750 <p><i>[This part is added, because otherwise <tt>array::swap</tt> would otherwise
8751 contradict the
8752 general contract of 23.2.1 [container.requirements.general] p. 10 b. 5]</i></p>
8753
8754
8755 <blockquote>
8756 <ins><i>Throws:</i> Nothing, unless one of the element-wise <tt>swap</tt> calls throws
8757 an exception.</ins>
8758 </blockquote>
8759 </li>
8760
8761 <li>
8762 <ol type="a">
8763 <li>
8764 <p>
8765 In 23.3.2 [deque], class template deque synopsis change as indicated:
8766 </p>
8767 <blockquote><pre>void swap(deque<del>&lt;T,Alloc&gt;</del>&amp;);
8768 </pre></blockquote>
8769 </li>
8770
8771 <li>
8772 <p>
8773 At the end of 23.3.2.3 [deque.modifiers] add as indicated:
8774 </p>
8775
8776 <blockquote><pre><ins>void swap(deque&amp; x);</ins>
8777 </pre>
8778 <blockquote>
8779 <p>
8780 <ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
8781 with that of <tt>x</tt>.</ins>
8782 </p>
8783 <p>
8784 <ins><i>Complexity:</i> Constant time.</ins>
8785 </p>
8786 </blockquote>
8787 </blockquote>
8788 </li>
8789 </ol>
8790 </li>
8791
8792 <li>
8793 <ol type="a">
8794 <li>
8795 <p>
8796 In 23.3.3 [forwardlist], class template <tt>forward_list</tt> synposis change as indicated:
8797 </p>
8798
8799 <blockquote><pre>void swap(forward_list<del>&lt;T,Allocator&gt;</del>&amp;);
8800 </pre></blockquote>
8801 </li>
8802
8803 <li>
8804 <p>
8805 At the end of 23.3.3.4 [forwardlist.modifiers] add as indicated:
8806 </p>
8807
8808 <blockquote><pre><ins>void swap(forward_list&amp; x);</ins>
8809 </pre>
8810 <blockquote>
8811 <p>
8812 <ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
8813 with that of <tt>x</tt>.</ins>
8814 </p>
8815 <p>
8816 <ins><i>Complexity:</i> Constant time.</ins>
8817 </p>
8818 </blockquote>
8819 </blockquote>
8820 </li>
8821 </ol>
8822 </li>
8823
8824 <li>
8825 <ol type="a">
8826 <li>
8827 <p>
8828 In 23.3.4 [list], class template <tt>list</tt> synopsis change as indicated:
8829 </p>
8830
8831 <blockquote><pre>void swap(list<del>&lt;T,Allocator&gt;</del>&amp;);
8832 </pre></blockquote>
8833 </li>
8834
8835 <li>
8836 <p>
8837 At the end of 23.3.4.3 [list.modifiers] add as indicated:
8838 </p>
8839
8840 <blockquote><pre><ins>void swap(list&amp; x);</ins>
8841 </pre>
8842
8843 <blockquote>
8844 <p>
8845 <ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
8846 with that of <tt>x</tt>.</ins>
8847 </p>
8848
8849 <p>
8850 <ins><i>Complexity:</i> Constant time.</ins>
8851 </p>
8852 </blockquote>
8853 </blockquote>
8854 </li>
8855 </ol>
8856 </li>
8857
8858 <li>
8859 <p>
8860 At the end of 23.3.5.2.2 [priqueue.members] add a new prototype description:
8861 </p>
8862
8863 <blockquote><pre><ins>void swap(priority_queue&amp; q);</ins>
8864 </pre>
8865 <blockquote>
8866 <p>
8867 <ins><i>Requires:</i> <tt>Compare</tt> shall satisfy the <tt>Swappable</tt> requirements
8868 ( [swappable]).</ins>
8869 </p>
8870
8871 <p><i>[
8872 This requirement is added to ensure that even a user defined <tt>swap</tt>
8873 which is found by
8874 ADL for <tt>Compare</tt> satisfies the <tt>Swappable</tt> requirements
8875 ]</i></p>
8876
8877
8878 <p>
8879 <ins><i>Effects:</i> <tt>this-&gt;c.swap(q.c); swap(this-&gt;comp, q.comp);</tt></ins>
8880 </p>
8881 <p>
8882 <ins><i>Throws:</i> What and if <tt>c.swap(q.c)</tt> and <tt>swap(comp, q.comp)</tt> throws.</ins>
8883 </p>
8884 </blockquote>
8885 </blockquote>
8886 <p><i>[
8887 This part is added, because otherwise <tt>priority_queue::swap</tt> would otherwise
8888 contradict the general contract of 23.2.1 [container.requirements.general] p. 10 b. 5
8889 ]</i></p>
8890
8891 </li>
8892
8893 <li>
8894 <ol type="a">
8895 <li>
8896 <p>
8897 In 23.3.6 [vector], class template <tt>vector</tt> synopsis change as indicated:
8898 </p>
8899
8900 <blockquote><pre>void swap(vector<del>&lt;T,Allocator&gt;</del>&amp;);
8901 </pre></blockquote>
8902 </li>
8903
8904 <li>
8905 <p>
8906 Change 23.3.6.2 [vector.capacity]/8 as indicated:
8907 </p>
8908
8909 <blockquote><pre>void swap(vector<del>&lt;T,Allocator&gt;</del>&amp; x);
8910 </pre>
8911
8912 <blockquote>
8913 <i>Effects:</i> Exchanges the contents and <tt>capacity()</tt> <ins>and swaps the
8914 allocators</ins>
8915 of <tt>*this</tt> with that of <tt>x</tt>.
8916 </blockquote>
8917 </blockquote>
8918 </li>
8919 </ol>
8920 </li>
8921
8922 <li>
8923 <p>
8924 Insert a new paragraph just before 23.4 [associative]/1:
8925 </p>
8926
8927 <blockquote>
8928 <ins>In addition to being available via inclusion of the <tt>&lt;algorithm&gt;</tt> header,
8929 the <tt>swap</tt> function templates in 25.4.3 [alg.swap] are also available when any of the
8930 headers <tt>&lt;map&gt;</tt> or <tt>&lt;set&gt;</tt> are included.</ins>
8931 </blockquote>
8932 </li>
8933
8934 <li>
8935 <ol type="a">
8936 <li>
8937 <p>
8938 In 23.4.1 [map], class template <tt>map</tt> synopsis change as indicated:
8939 </p>
8940
8941 <blockquote><pre>void swap(map<del>&lt;Key,T,Compare,Allocator&gt;</del>&amp;);
8942 </pre></blockquote>
8943 </li>
8944
8945 <li>
8946 <p>
8947 At the end of 23.4.1.3 [map.modifiers] add as indicated:
8948 </p>
8949
8950 <blockquote><pre><ins>void swap(map&amp; x);</ins>
8951 </pre>
8952
8953 <blockquote>
8954 <p>
8955 <ins><i>Requires:</i> Compare shall satisfy the <tt>Swappable</tt> requirements
8956 ( [swappable]).</ins>
8957 </p>
8958
8959 <p><i>[
8960 This requirement is added to ensure that even a user defined <tt>swap</tt>
8961 which is found by ADL for <tt>Compare</tt> satisfies the <tt>Swappable</tt>
8962 requirements
8963 ]</i></p>
8964
8965
8966 <p>
8967 <ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
8968 with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the comparison objects
8969 of <tt>*this</tt> and <tt>x</tt>.</ins>
8970 </p>
8971
8972 <p>
8973 <ins><i>Complexity:</i> Constant time</ins>
8974 </p>
8975 </blockquote>
8976 </blockquote>
8977 </li>
8978 </ol>
8979 </li>
8980
8981 <li>
8982 <ol type="a">
8983 <li>
8984 <p>
8985 In 23.4.2 [multimap], class template <tt>multimap</tt> synopsis change as indicated:
8986 </p>
8987
8988 <blockquote><pre>void swap(multimap<del>&lt;Key,T,Compare,Allocator&gt;</del>&amp;);
8989 </pre></blockquote>
8990 </li>
8991
8992 <li>
8993 <p>
8994 At the end of 23.4.2.2 [multimap.modifiers] add as indicated:
8995 </p>
8996
8997 <blockquote><pre><ins>void swap(multimap&amp; x);</ins>
8998 </pre>
8999
9000 <blockquote>
9001 <p>
9002 <ins><i>Requires:</i> Compare shall satisfy the <tt>Swappable</tt> requirements
9003 ( [swappable]).</ins>
9004 </p>
9005 <p>
9006 <ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
9007 with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the comparison objects
9008 of <tt>*this</tt> and <tt>x</tt>.</ins>
9009 </p>
9010 <p>
9011 <ins><i>Complexity:</i> Constant time</ins>
9012 </p>
9013 </blockquote>
9014 </blockquote>
9015 </li>
9016 </ol>
9017 </li>
9018
9019 <li>
9020 <ol type="a">
9021 <li>
9022 <p>
9023 In 23.4.3 [set], class template <tt>set</tt> synopsis change as indicated:
9024 </p>
9025
9026 <blockquote><pre>void swap(set<del>&lt;Key,Compare,Allocator&gt;</del>&amp;);
9027 </pre></blockquote>
9028 </li>
9029
9030 <li>
9031 <p>
9032 After section 23.4.3.1 [set.cons] add a new section <ins><tt>set</tt> modifiers
9033  [set.modifiers]</ins>
9034 and add the following paragraphs:
9035 </p>
9036
9037 <blockquote><pre><ins>void swap(set&amp; x);</ins>
9038 </pre>
9039
9040 <blockquote>
9041 <p>
9042 <ins><i>Requires:</i> Compare shall satisfy the <tt>Swappable</tt> requirements
9043 ( [swappable]).</ins>
9044 </p>
9045
9046 <p>
9047 <ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
9048 with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the comparison objects
9049 of <tt>*this</tt> and <tt>x</tt>.</ins>
9050 </p>
9051
9052 <p>
9053 <ins>Complexity: Constant time</ins>
9054 </p>
9055 </blockquote>
9056 </blockquote>
9057 </li>
9058 </ol>
9059 </li>
9060
9061 <li>
9062 <ol type="a">
9063 <li>
9064 <p>
9065 In 23.4.4 [multiset], class template <tt>multiset</tt> synosis, change as indicated:
9066 </p>
9067
9068 <blockquote><pre>void swap(multiset<del>&lt;Key,Compare,Allocator&gt;</del>&amp;);
9069 </pre></blockquote>
9070 </li>
9071
9072 <li>
9073 <p>
9074 After section 23.4.4.1 [multiset.cons] add a new section <ins><tt>multiset</tt> modifiers
9075  [multiset.modifiers]</ins> and add the following paragraphs:
9076 </p>
9077
9078 <blockquote><pre><ins>void swap(multiset&amp; x);</ins>
9079 </pre>
9080
9081 <blockquote>
9082 <p>
9083 <ins><i>Requires:</i> Compare shall satisfy the <tt>Swappable</tt> requirements
9084 ( [swappable]).</ins>
9085 </p>
9086
9087 <p>
9088 <ins><i>Effects:</i> Exchanges the contents and swaps the allocators of <tt>*this</tt>
9089 with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the comparison objects
9090 of <tt>*this</tt> and <tt>x</tt>.</ins>
9091 </p>
9092
9093 <p>
9094 <ins><i>Complexity:</i> Constant time</ins>
9095 </p>
9096 </blockquote>
9097 </blockquote>
9098 </li>
9099 </ol>
9100 </li>
9101
9102 <li>
9103 <p>
9104 Insert a new paragraph just before 23.5 [unord]/1:
9105 </p>
9106
9107 <blockquote>
9108 <ins>In addition to being available via inclusion of the <tt>&lt;algorithm&gt;</tt> header,
9109 the <tt>swap</tt> function templates in 25.4.3 [alg.swap] are also available when any of the
9110 headers <tt>&lt;unordered_map&gt;</tt> or <tt>&lt;unordered_set&gt;</tt> are included.</ins>
9111 </blockquote>
9112
9113 </li>
9114
9115 <li>
9116 <p>
9117 After section 23.5.1.2 [unord.map.elem] add a new section <ins>unordered_map
9118 modifiers  [unord.map.modifiers]</ins> and add the following paragraphs:
9119 </p>
9120
9121 <blockquote><pre><ins>void swap(unordered_map&amp; x);</ins>
9122 </pre>
9123
9124 <blockquote>
9125 <p>
9126 <ins><i>Requires:</i> <tt>Hash</tt> and <tt>Pred</tt> shall satisfy the <tt>Swappable</tt> requirements
9127 ( [swappable]).</ins>
9128 </p>
9129
9130 <p><i>[
9131 This requirement is added to ensure that even a user defined <tt>swap</tt>
9132 which is found by ADL for <tt>Hash</tt> and <tt>Pred</tt> satisfies the <tt>Swappable</tt>
9133 requirements
9134 ]</i></p>
9135
9136
9137 <p>
9138 <ins><i>Effects:</i> Exchanges the contents and hash policy and swaps the
9139 allocators of <tt>*this</tt>
9140 with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the <tt>Pred</tt> objects
9141 and an unqualified <tt>swap</tt> of the <tt>Hash</tt> objects of <tt>*this</tt> and <tt>x</tt>.</ins>
9142 </p>
9143
9144 <p>
9145 <ins><i>Complexity:</i> Constant time</ins>
9146 </p>
9147 </blockquote>
9148 </blockquote>
9149 </li>
9150
9151 <li>
9152 <p>
9153 After section 23.5.2.1 [unord.multimap.cnstr] add a new section
9154 <ins>unordered_multimap
9155 modifiers  [unord.multimap.modifiers]</ins> and add the following paragraphs:
9156 </p>
9157
9158 <blockquote><pre><ins>void swap(unordered_multimap&amp; x);</ins>
9159 </pre>
9160
9161 <blockquote>
9162 <p>
9163 <ins><i>Requires:</i> <tt>Hash</tt> and <tt>Pred</tt> shall satisfy the <tt>Swappable</tt> requirements
9164 ( [swappable]).</ins>
9165 </p>
9166
9167 <p>
9168 <ins><i>Effects:</i> Exchanges the contents and hash policy and swaps the
9169 allocators of <tt>*this</tt>
9170 with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the <tt>Pred</tt> objects
9171 and an unqualified <tt>swap</tt> of the <tt>Hash</tt> objects of <tt>*this</tt> and <tt>x</tt></ins>
9172 </p>
9173 <p>
9174 <ins><i>Complexity:</i> Constant time</ins>
9175 </p>
9176 </blockquote>
9177 </blockquote>
9178 </li>
9179
9180 <li>
9181 <p>
9182 After section 23.5.3.1 [unord.set.cnstr] add a new section
9183 <ins>unordered_set modifiers
9184  [unord.set.modifiers]</ins> and add the following paragraphs:
9185 </p>
9186
9187 <blockquote><pre><ins>void swap(unordered_set&amp; x);</ins>
9188 </pre>
9189
9190 <blockquote>
9191 <p>
9192 <ins><i>Requires:</i> <tt>Hash</tt> and <tt>Pred</tt> shall satisfy the <tt>Swappable</tt> requirements
9193 ( [swappable]).</ins>
9194 </p>
9195
9196 <p>
9197 <ins><i>Effects:</i> Exchanges the contents and hash policy and swaps the
9198 allocators of <tt>*this</tt>
9199 with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the <tt>Pred</tt> objects
9200 and an unqualified <tt>swap</tt> of the <tt>Hash</tt> objects of <tt>*this</tt> and <tt>x</tt></ins>
9201 </p>
9202
9203 <p>
9204 <ins><i>Complexity:</i> Constant time</ins>
9205 </p>
9206 </blockquote>
9207 </blockquote>
9208 </li>
9209
9210 <li>
9211 <p>
9212 After section 23.5.4.1 [unord.multiset.cnstr] add a new section
9213 <ins>unordered_multiset
9214 modifiers  [unord.multiset.modifiers]</ins> and add the following paragraphs:
9215 </p>
9216
9217 <blockquote><pre><ins>void swap(unordered_multiset&amp; x);</ins>
9218 </pre>
9219
9220 <blockquote>
9221 <p>
9222 <ins><i>Requires:</i> <tt>Hash</tt> and <tt>Pred</tt> shall satisfy the <tt>Swappable</tt> requirements
9223 ( [swappable]).</ins>
9224 </p>
9225
9226 <p>
9227 <ins><i>Effects:</i> Exchanges the contents and hash policy and swaps the
9228 allocators of <tt>*this</tt>
9229 with that of <tt>x</tt>, followed by an unqualified <tt>swap</tt> of the <tt>Pred</tt> objects
9230 and an unqualified <tt>swap</tt> of the <tt>Hash</tt> objects of <tt>*this</tt> and <tt>x</tt></ins>
9231 </p>
9232 <p>
9233 <ins><i>Complexity:</i> Constant time</ins>
9234 </p>
9235 </blockquote>
9236 </blockquote>
9237 </li>
9238
9239 </ol>
9240
9241
9242
9243
9244
9245
9246 <hr>
9247 <h3><a name="780"></a>780. <tt>std::merge()</tt> specification incorrect/insufficient</h3>
9248 <p><b>Section:</b> 25.5.4 [alg.merge] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
9249  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-01-25  <b>Last modified:</b> 2009-07-16</p>
9250 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
9251 <p><b>Discussion:</b></p>
9252 <p>
9253 Though issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a> has fixed many open issues, it seems that some are still open:
9254 </p>
9255
9256 <p>
9257 Both 25.3.4 [lib.alg.merge] in 14882:2003 and 25.5.4 [alg.merge] in N2461
9258 have no Requires element and the Effects element contains some requirements,
9259 which is probably editorial. Worse is that:
9260 </p>
9261
9262 <ul>
9263 <li>
9264 no assignment requirements are specified (neither implicit nor explicit).
9265 </li>
9266
9267 <li>
9268 the effects clause just speaks of "merges", which is badly worded
9269 near to a circular definition.
9270 </li>
9271
9272 <li>
9273 p. 2 mentions a range <tt>[first, last)</tt>, which is not defined by the
9274 function arguments or otherwise.
9275 </li>
9276
9277 <li>
9278 p. 2 says "according to the ordering defined by comp" which is both
9279 incomplete (because
9280 this excludes the first variant with &lt;) and redundant (because the
9281 following subordinate
9282 clause mentions comp again)
9283 </li>
9284 </ul>
9285
9286 <p><i>[
9287 Post Summit Alisdair adds:
9288 ]</i></p>
9289
9290
9291 <blockquote>
9292 <p>
9293 Suggest:
9294 </p>
9295 <blockquote>
9296 (where <tt>last</tt> is equal to <tt>next(result, distance(first1, last1) +
9297 distance(first2, last2))</tt>, such that resulting range will be sorted in
9298 non-decreasing order; that is, for every iterator <tt>i</tt> in <tt>[result,last)</tt> other
9299 than <tt>result</tt>, the condition <tt>*i &lt; *prev(i)</tt> or, respectively, <tt>comp(*i,
9300 *prev(i))</tt> will be <tt>false</tt>.
9301 </blockquote>
9302
9303 <p>
9304 Note that this might still not be technically accurate in the case of
9305 <tt>InputIterators</tt>, depending on other resolutions working their way through the
9306 system (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1011">1011</a>).
9307 </p>
9308 </blockquote>
9309
9310 <p><i>[
9311 Post Summit Daniel adds:
9312 ]</i></p>
9313
9314
9315 <blockquote>
9316 If we want to use <tt>prev</tt> and <tt>next</tt> here (Note: <tt>merge</tt>
9317 is sufficiently satisfied with <tt>InputIterator</tt>) we should instead *add* more to
9318 25 [algorithms]/6, but I can currently not propose any good wording for this.
9319 </blockquote>
9320
9321 <p><i>[
9322 Batavia (2009-05):
9323 ]</i></p>
9324
9325 <blockquote>
9326 <p>
9327 Pete points out the existing wording in [algorithms]/4
9328 that permits the use of + in algorithm specifications.
9329 </p>
9330 <p>
9331 Alisdair points out that that wording may not apply to input iterators.
9332 </p>
9333 <p>
9334 Move to Review.
9335 </p>
9336 </blockquote>
9337
9338 <p><i>[
9339 2009-07 Frankfurt:
9340 ]</i></p>
9341
9342
9343 <blockquote>
9344 Move to Ready.
9345 </blockquote>
9346
9347
9348
9349 <p><b>Proposed resolution:</b></p>
9350 <p>
9351 In 25.5.4 [alg.merge] replace p.1+ 2:
9352 </p>
9353
9354 <blockquote>
9355 <p>
9356 <i>Effects:</i> <del>Merges</del> <ins>Copies all the elements of the</ins> two sorted ranges <tt>[first1,last1)</tt> and
9357 <tt>[first2,last2)</tt> into the range
9358 <del><tt>[result,result + (last1 - first1) + (last2 - first2))</tt></del>
9359 <ins><tt>[result, last)</tt> (where <tt>last</tt> is equal to <tt>result + (last1
9360 - first1) + (last2 - first2))</tt>, such that resulting range will be
9361 sorted in non-decreasing order; that is, for every iterator <tt>i</tt> in
9362 <tt>[result,last)</tt> other than <tt>result</tt>, the condition <tt>*i &lt; *(i - 1)</tt> or,
9363 respectively, <tt>comp(*i, *(i - 1))</tt> will be false</ins>.
9364 </p>
9365
9366 <p>
9367 <ins><i>Requires:</i></ins> The resulting range shall not overlap with either of the original ranges. <del>The list will be sorted in non-decreasing
9368 order according to the ordering defined by <tt>comp</tt>; that is, for every iterator <tt>i</tt> in
9369 <tt>[first,last)</tt> other than <tt>first</tt>, the condition <tt>*i &lt; *(i - 1)</tt> or
9370 <tt>comp(*i, *(i - 1))</tt> will be false.</del>
9371 </p>
9372 </blockquote>
9373
9374 <p>
9375 [N.B.: I attempted to reuse the wording style of <tt>inplace_merge</tt>,
9376 therefore proposing to
9377 insert ", respectively," between both predicate tests. This is no
9378 strictly necessary as
9379 other parts of <tt>&lt;algorithm&gt;</tt> show, just a matter of consistency]
9380 </p>
9381
9382
9383
9384
9385
9386
9387 <hr>
9388 <h3><a name="788"></a>788. ambiguity in [istream.iterator]</h3>
9389 <p><b>Section:</b> 24.6.1 [istream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
9390  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-02-06  <b>Last modified:</b> 2009-07-16</p>
9391 <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>
9392 <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>
9393 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
9394 <p><b>Discussion:</b></p>
9395
9396 <p><b>Addresses UK 287</b></p>
9397
9398 <blockquote>
9399 <p>
9400 It is not clear what the initial state of an <tt>istream_iterator</tt> should be. Is
9401 _value_ initialized by reading the stream, or default/value initialized? If
9402 it is initialized by reading the stream, what happens if the initialization
9403 is deferred until first dereference, when ideally the iterator value should
9404 have been that of an end-of-stream iterator which is not safely
9405 dereferencable?
9406 </p>
9407
9408 <p>
9409 Recommendation: Specify _value_ is initialized by reading the stream, or
9410 the iterator takes on the end-of-stream value if the stream is empty.
9411 </p>
9412 </blockquote>
9413
9414 <p>
9415 The description of how an istream_iterator object becomes an
9416 end-of-stream iterator is a) ambiguous and b) out of date WRT
9417 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>:
9418 </p>
9419
9420 <blockquote>
9421 <tt>istream_iterator</tt> reads (using <tt>operator&gt;&gt;</tt>) successive elements from the
9422 input stream for which it was constructed. After it is constructed, and
9423 every time <tt>++</tt> is used, the iterator reads and stores a value of <tt>T</tt>. If
9424 the end of stream is reached (<tt>operator void*()</tt> on the stream returns
9425 <tt>false</tt>), the iterator becomes equal to the <i>end-of-stream</i> iterator value.
9426 The constructor with no arguments <tt>istream_iterator()</tt> always constructs
9427 an end of stream input iterator object, which is the only legitimate
9428 iterator to be used for the end condition. The result of <tt>operator*</tt> on an
9429 end of stream is not defined. For any other iterator value a <tt>const T&amp;</tt> is
9430 returned. The result of <tt>operator-&gt;</tt> on an end of stream is not defined.
9431 For any other iterator value a <tt>const T*</tt> is returned. It is impossible to
9432 store things into istream iterators. The main peculiarity of the istream
9433 iterators is the fact that <tt>++</tt> operators are not equality preserving,
9434 that is, <tt>i == j</tt> does not guarantee at all that <tt>++i == ++j</tt>. Every time <tt>++</tt>
9435 is used a new value is read.
9436 </blockquote>
9437
9438 <p>
9439 <tt>istream::operator void*()</tt> returns null if <tt>istream::fail()</tt> is <tt>true</tt>,
9440 otherwise non-null. <tt>istream::fail()</tt> returns <tt>true</tt> if <tt>failbit</tt> or
9441 <tt>badbit</tt> is set in <tt>rdstate()</tt>. Reaching the end of stream doesn't
9442 necessarily imply that <tt>failbit</tt> or <tt>badbit</tt> is set (e.g., after
9443 extracting an <tt>int</tt> from <tt>stringstream("123")</tt> the stream object will
9444 have reached the end of stream but <tt>fail()</tt> is <tt>false</tt> and <tt>operator
9445 void*()</tt> will return a non-null value).
9446 </p>
9447
9448 <p>
9449 Also I would prefer to be explicit about calling <tt>fail()</tt> here
9450 (there is no <tt>operator void*()</tt> anymore.)
9451 </p>
9452
9453 <p><i>[
9454 Summit:
9455 ]</i></p>
9456
9457
9458 <blockquote>
9459 Moved from Ready to Open for the purposes of using this issue to address NB UK 287.
9460 Martin to handle.
9461 </blockquote>
9462
9463 <p><i>[
9464 2009-07 Frankfurt:
9465 ]</i></p>
9466
9467
9468 <blockquote>
9469 <p>
9470 This improves the wording.
9471 </p>
9472 <p>
9473 Move to Ready.
9474 </p>
9475 </blockquote>
9476
9477
9478
9479 <p><b>Proposed resolution:</b></p>
9480 <p>
9481 Change 24.6.1 [istream.iterator]/1:
9482 </p>
9483
9484 <blockquote>
9485 <tt>istream_iterator</tt> reads (using <tt>operator&gt;&gt;</tt>) successive elements from the
9486 input stream for which it was constructed. After it is constructed, and
9487 every time <tt>++</tt> is used, the iterator reads and stores a value of <tt>T</tt>. If
9488 <del>the end of stream is reached</del> <ins>the iterator fails to read and store a value of <tt>T</tt></ins>
9489 (<tt><del>operator void*()</del> <ins>fail()</ins></tt> on the stream returns
9490 <tt><del>false</del> <ins>true</ins></tt>), the iterator becomes equal to the <i>end-of-stream</i> iterator value.
9491 The constructor with no arguments <tt>istream_iterator()</tt> always constructs
9492 an end of stream input iterator object, which is the only legitimate
9493 iterator to be used for the end condition. The result of <tt>operator*</tt> on an
9494 end of stream is not defined. For any other iterator value a <tt>const T&amp;</tt> is
9495 returned. The result of <tt>operator-&gt;</tt> on an end of stream is not defined.
9496 For any other iterator value a <tt>const T*</tt> is returned. It is impossible to
9497 store things into istream iterators. The main peculiarity of the istream
9498 iterators is the fact that <tt>++</tt> operators are not equality preserving,
9499 that is, <tt>i == j</tt> does not guarantee at all that <tt>++i == ++j</tt>. Every time <tt>++</tt>
9500 is used a new value is read.
9501 </blockquote>
9502
9503
9504
9505
9506
9507 <hr>
9508 <h3><a name="801"></a>801. <tt>tuple</tt> and <tt>pair</tt> trivial members</h3>
9509 <p><b>Section:</b> 20.5 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
9510  <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-02-18  <b>Last modified:</b> 2009-07-20</p>
9511 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple">issues</a> in [tuple].</p>
9512 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
9513 <p><b>Discussion:</b></p>
9514 <p>
9515 Classes with trivial special member functions are inherently more
9516 efficient than classes without such functions.  This efficiency is
9517 particularly pronounced on modern ABIs that can pass small classes
9518 in registers.  Examples include value classes such as complex numbers
9519 and floating-point intervals.  Perhaps more important, though, are
9520 classes that are simple collections, like <tt>pair</tt> and <tt>tuple</tt>.  When the
9521 parameter types of these classes are trivial, the <tt>pair</tt>s and <tt>tuple</tt>s
9522 themselves can be trivial, leading to substantial performance wins.
9523 </p>
9524 <p>
9525 The current working draft make specification of trivial functions
9526 (where possible) much easer through <tt>default</tt>ed and <tt>delete</tt>d functions.
9527 As long as the semantics of defaulted and deleted functions match
9528 the intended semantics, specification of defaulted and deleted
9529 functions will yield more efficient programs.
9530 </p>
9531 <p>
9532 There are at least two cases where specification of an explicitly
9533 defaulted function may be desirable.
9534 </p>
9535 <p>
9536 First, the <tt>std::pair</tt> template has a non-trivial default constructor,
9537 which prevents static initialization of the pair even when the
9538 types are statically initializable.  Changing the definition to
9539 </p>
9540
9541 <blockquote><pre>pair() = default;
9542 </pre></blockquote>
9543
9544 <p>
9545 would enable such initialization.  Unfortunately, the change is
9546 not semantically neutral in that the current definition effectively
9547 forces value initialization whereas the change would not value
9548 initialize in some contexts.
9549 </p>
9550
9551 <p>
9552 ** Does the committee confirm that forced value initialization
9553 was the intent?  If not, does the committee wish to change the
9554 behavior of <tt>std::pair</tt> in C++0x?
9555 </p>
9556 <p>
9557 Second, the same default constructor issue applies to <tt>std::tuple</tt>.
9558 Furthermore, the <tt>tuple</tt> copy constructor is current non-trivial,
9559 which effectively prevents passing it in registers.  To enable
9560 passing <tt>tuples</tt> in registers, the copy constructor should be
9561 make explicitly <tt>default</tt>ed.  The new declarations are:
9562 </p>
9563
9564 <blockquote><pre>tuple() = default;
9565 tuple(const tuple&amp;) = default;
9566 </pre></blockquote>
9567
9568 <p>
9569 This changes is not implementation neutral.  In particular, it
9570 prevents implementations based on pointers to the parameter
9571 types.  It does however, permit implementations using the
9572 parameter types as bases.
9573 </p>
9574 <p>
9575 ** How does the committee wish to trade implementation
9576 efficiency versus implementation flexibility?
9577 </p>
9578
9579 <p><i>[
9580 Bellevue:
9581 ]</i></p>
9582
9583
9584 <blockquote>
9585 <p>
9586 General agreement; the first half of the issue is NAD.
9587 </p>
9588 <p>
9589 Before voting on the second half, it was agreed that a "Strongly Favor"
9590 vote meant support for trivial tuples (assuming usual requirements met),
9591 even at the expense of other desired qualities. A "Weakly Favor" vote
9592 meant support only if not at the expense of other desired qualities.
9593 </p>
9594 <p>
9595 Concensus: Go forward, but not at expense of other desired qualities.
9596 </p>
9597 <p>
9598 It was agreed to Alisdair should fold this work in with his other
9599 pair/tuple action items, above, and that issue 801 should be "open", but
9600 tabled until Alisdair's proposals are disposed of.
9601 </p>
9602 </blockquote>
9603
9604 <p><i>[
9605 2009-05-27 Daniel adds:
9606 ]</i></p>
9607
9608
9609 <blockquote>
9610 This is partly solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1117">1117</a>.
9611 </blockquote>
9612
9613 <p><i>[
9614 2009-07 Frankfurt:
9615 ]</i></p>
9616
9617
9618 <blockquote>
9619 Wait for dust to settle from fixing exception safety problem
9620 with rvalue refs.
9621 </blockquote>
9622
9623 <p><i>[
9624 2009-07-20 Alisdair adds:
9625 ]</i></p>
9626
9627
9628 <blockquote>
9629 <p>
9630 Basically, this issue is what should we do with the default constructor
9631 for pairs and tuples of trivial types.  The motivation of the issue was
9632 to force static initialization rather than dynamic initialization, and
9633 was rejected in the case of pair as it would change the meaning of
9634 existing programs.  The advice was "do the best we can" for tuple
9635 without changing existing meaning.
9636 </p>
9637
9638 <p>
9639 Frankfurt seems to simply wait and see the resolution on no-throw move
9640 constructors, which (I believe) is only tangentially related to this
9641 issue, but as good as any to defer until Santa Cruz.
9642 </p>
9643
9644 <p>
9645 Looking again now, I think constant (static) initialization for pair can
9646 be salvaged by making the default construct constexpr.  I have a
9647 clarification from Core that this is intended to work, even if the
9648 constructor is not trivial/constexpr, so long as no temporaries are
9649 implied in the process (even if elided).
9650 </p>
9651 </blockquote>
9652
9653
9654
9655 <p><b>Proposed resolution:</b></p>
9656 <p>
9657 </p>
9658
9659
9660
9661
9662
9663 <hr>
9664 <h3><a name="811"></a>811. <tt>pair</tt> of pointers no longer works with literal 0</h3>
9665 <p><b>Section:</b> 20.3.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
9666  <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2008-03-14  <b>Last modified:</b> 2009-07-28</p>
9667 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</p>
9668 <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>
9669 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
9670 <p><b>Discussion:</b></p>
9671 <blockquote><pre>#include &lt;utility&gt;
9672
9673 int main()
9674 {
9675    std::pair&lt;char *, char *&gt; p (0,0);
9676 }
9677 </pre></blockquote>
9678
9679 <p>
9680 I just got a bug report about that, because it's valid C++03, but not
9681 C++0x. The important realization, for me, is that the emplace
9682 proposal---which made <tt>push_back</tt> variadic, causing the <tt>push_back(0)</tt>
9683 issue---didn't cause this break in backward compatibility. The break
9684 actually happened when we added this pair constructor as part of adding
9685 rvalue references into the language, long before variadic templates or
9686 emplace came along:
9687 </p>
9688
9689 <blockquote><pre>template&lt;class U, class V&gt; pair(U&amp;&amp; x, V&amp;&amp; y);
9690 </pre></blockquote>
9691
9692 <p>
9693 Now, concepts will address this issue by constraining that <tt>pair</tt>
9694 constructor to only <tt>U</tt>'s and <tt>V</tt>'s that can properly construct "first" and
9695 "second", e.g. (from
9696 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2322.pdf">N2322</a>):
9697 </p>
9698
9699 <blockquote><pre>template&lt;class U , class V &gt;
9700 requires Constructible&lt;T1, U&amp;&amp;&gt; &amp;&amp; Constructible&lt;T2, V&amp;&amp;&gt;
9701 pair(U&amp;&amp; x , V&amp;&amp; y );
9702 </pre></blockquote>
9703
9704 <p><i>[
9705 San Francisco:
9706 ]</i></p>
9707
9708
9709 <blockquote>
9710 <p>
9711 Suggested to resolve using pass-by-value for that case.
9712 </p>
9713 <p>
9714 Side question: Should pair interoperate with tuples? Can construct a
9715 tuple of a pair, but not a pair from a two-element tuple.
9716 </p>
9717 <p>
9718 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#885">885</a>.
9719 </p>
9720 </blockquote>
9721
9722 <p><i>[
9723 2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
9724 ]</i></p>
9725
9726
9727
9728
9729 <p><b>Proposed resolution:</b></p>
9730 <p>
9731 </p>
9732
9733
9734 <p><b>Rationale:</b></p>
9735 <p><i>[
9736 San Francisco:
9737 ]</i></p>
9738
9739
9740 <blockquote>
9741 Solved by
9742 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>.
9743 </blockquote>
9744
9745
9746
9747
9748
9749
9750
9751 <hr>
9752 <h3><a name="815"></a>815. <tt>std::function</tt> and <tt>reference_closure</tt> do not use perfect forwarding</h3>
9753 <p><b>Section:</b> 20.7.16.2.4 [func.wrap.func.inv] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
9754  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-03-16  <b>Last modified:</b> 2009-07-16</p>
9755 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
9756 <p><b>Discussion:</b></p>
9757 <p>
9758 <tt>std::function</tt> and <tt>reference_closure</tt> should use "perfect forwarding" as
9759 described in the rvalue core proposal.
9760 </p>
9761
9762 <p><i>[
9763 Sophia Antipolis:
9764 ]</i></p>
9765
9766
9767 <blockquote>
9768 According to Doug Gregor, as far as <tt>std::function</tt> is concerned, perfect
9769 forwarding can not be obtained because of type erasure. Not everyone
9770 agreed with this diagnosis of forwarding.
9771 </blockquote>
9772
9773 <p><i>[
9774 2009-05-01 Howard adds:
9775 ]</i></p>
9776
9777
9778 <blockquote>
9779 <p>
9780 Sebastian Gesemann brought to my attention that the <tt>CopyConstructible</tt>
9781 requirement on <tt>function</tt>'s <tt>ArgTypes...</tt> is an unnecessary
9782 restriction.
9783 </p>
9784
9785 <blockquote><pre>template&lt;Returnable R, <b>CopyConstructible</b>... ArgTypes&gt;
9786 class function&lt;R(ArgTypes...)&gt;
9787 ...
9788 </pre></blockquote>
9789
9790 <p>
9791 On further investigation, this complaint seemed to be the same
9792 issue as this one.  I believe the reason <tt>CopyConstructible</tt> was put
9793 on <tt>ArgTypes</tt> in the first place was because of the nature of the
9794 <i>invoke</i> member:
9795 </p>
9796
9797 <blockquote><pre>template&lt;class R, class ...ArgTypes&gt;
9798 R
9799 function&lt;R(ArgTypes...)&gt;::operator()(ArgTypes... arg) const
9800 {
9801     if (f_ == 0)
9802         throw bad_function_call();
9803     return (*f_)(arg...);
9804 }
9805 </pre></blockquote>
9806
9807 <p>
9808 However now with rvalue-refs, "by value" no longer implies <tt>CopyConstructible</tt>
9809 (as Sebastian correctly points out).  If rvalue arguments are supplied, <tt>MoveConstructible</tt>
9810 is sufficient.  Furthermore, the constraint need not be applied in <tt>function</tt>
9811 if I understand correctly.  Rather the client must apply the proper constraints
9812 at the call site.  Therefore, at the very least, I recommend that <tt>CopyConstructible</tt>
9813 be removed from the template class <tt>function</tt>.
9814 </p>
9815
9816 <p>
9817 Furthermore we need to mandate that the <i>invoker</i> is coded as:
9818 </p>
9819
9820 <blockquote><pre>template&lt;class R, class ...ArgTypes&gt;
9821 R
9822 function&lt;R(ArgTypes...)&gt;::operator()(ArgTypes... arg) const
9823 {
9824     if (f_ == 0)
9825         throw bad_function_call();
9826     return (*f_)(<b>std::forward&lt;ArgTypes&gt;(</b>arg<b>)</b>...);
9827 }
9828 </pre></blockquote>
9829
9830 <p>
9831 Note that <tt>ArgTypes&amp;&amp;</tt> (the "perfect forwarding signature") is not
9832 appropriate here as this is not a deduced context for <tt>ArgTypes</tt>.  Instead
9833 the client's arguments must implicitly convert to the non-deduced <tt>ArgType</tt>
9834 type.  Catching these arguments by value makes sense to enable decay.
9835 </p>
9836
9837 <p>
9838 Next <tt>forward</tt> is used to move the <tt>ArgTypes</tt> as efficiently as
9839 possible, and also with minimum requirements (not <tt>CopyConstructible</tt>)
9840 to the type-erased functor.  For object types, this will be a <tt>move</tt>.  For
9841 reference type <tt>ArgTypes</tt>, this will be a copy.  The end result <em>must</em> be
9842 that the following is a valid program:
9843 </p>
9844
9845 <blockquote><pre>#include &lt;functional&gt;
9846 #include &lt;memory&gt;
9847 #include &lt;cassert&gt;
9848
9849 std::unique_ptr&lt;int&gt;
9850 f(std::unique_ptr&lt;int&gt; p, int&amp; i)
9851 {
9852     ++i;
9853     return std::move(p);
9854 }
9855
9856 int main()
9857 {
9858     int i = 2;
9859     std::function&lt;std::unique_ptr&lt;int&gt;(std::unique_ptr&lt;int&gt;,
9860                                        int&amp;&gt; g(f);
9861     std::unique_ptr&lt;int&gt; p = g(std::unique_ptr&lt;int&gt;(new int(1)), i);
9862     assert(*p == 1);
9863     assert(i == 3);
9864 }
9865 </pre></blockquote>
9866
9867 <p><i>[
9868 Tested in pre-concepts rvalue-ref-enabled compiler.
9869 ]</i></p>
9870
9871
9872 <p>
9873 In the example above, the first <tt>ArgType</tt> is <tt>unique_ptr&lt;int&gt;</tt>
9874 and the second <tt>ArgType</tt> is <tt>int&amp;</tt>.  Both <em>must</em> work!
9875 </p>
9876
9877 </blockquote>
9878
9879 <p><i>[
9880 2009-05-27 Daniel adds:
9881 ]</i></p>
9882
9883
9884 <blockquote>
9885 <p>
9886 in the 2009-05-01 comment of above mentioned issue Howard
9887 </p>
9888
9889 <ol type="a">
9890 <li>
9891 Recommends to replace the <tt>CopyConstructible</tt> requirement by a
9892 <tt>MoveConstructible</tt> requirement
9893 </li>
9894 <li>
9895 Says: "Furthermore, the constraint need not be applied in <tt>function</tt> if I
9896 understand correctly. Rather the client must apply the proper constraints
9897 at the call site"
9898 </li>
9899 </ol>
9900 <p>
9901 I'm fine with (a), but I think comment (b) is incorrect, at least in the
9902 sense I read these sentences. Let's look at Howard's example code:
9903 </p>
9904
9905 <blockquote><pre>function&lt;R(ArgTypes...)&gt;::operator()(ArgTypes... arg) const
9906 {
9907    if (f_ == 0)
9908        throw bad_function_call();
9909    return (*f_)(std::forward&lt;ArgTypes&gt;(arg)...);
9910 }
9911 </pre></blockquote>
9912
9913 <p>
9914 In the constrained scope of this <tt>operator()</tt> overload the expression
9915 "<tt>(*f_)(std::forward&lt;ArgTypes&gt;(arg)...)</tt>" must be valid. How can it
9916 do so, if <tt>ArgTypes</tt> aren't at least <tt>MoveConstructible</tt>?
9917 </p>
9918 </blockquote>
9919
9920 <p><i>[
9921 2009-07 Frankfurt:
9922 ]</i></p>
9923
9924
9925 <blockquote>
9926 Leave this open and wait until concepts are removed from the Working
9927 Draft so that we know how to write the proposed resolution in terms of
9928 diffs to otherwise stable text.
9929 </blockquote>
9930
9931
9932
9933 <p><b>Proposed resolution:</b></p>
9934 <p>
9935 </p>
9936
9937
9938
9939
9940
9941 <hr>
9942 <h3><a name="816"></a>816. Should <tt>bind()</tt>'s returned functor have a nofail copy ctor when <tt>bind()</tt> is nofail?</h3>
9943 <p><b>Section:</b> 20.7.12.1.3 [func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
9944  <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2008-02-08  <b>Last modified:</b> 2009-07-16</p>
9945 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.bind.bind">active issues</a> in [func.bind.bind].</p>
9946 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p>
9947 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
9948 <p><b>Discussion:</b></p>
9949 <p>
9950 Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> notes that <tt>bind(f, t1, ..., tN)</tt>
9951 should be nofail when <tt>f, t1, ..., tN</tt> have nofail copy ctors.
9952 </p>
9953 <p>
9954 However, no guarantees are provided for the copy ctor of the functor
9955 returned by <tt>bind()</tt>.  (It's guaranteed to have a copy ctor, which can
9956 throw implementation-defined exceptions: <tt>bind()</tt> returns a forwarding
9957 call wrapper, TR1 3.6.3/2.  A forwarding call wrapper is a call wrapper,
9958 TR1 3.3/4.  Every call wrapper shall be CopyConstructible, TR1 3.3/4.
9959 Everything without an exception-specification may throw
9960 implementation-defined exceptions unless otherwise specified, C++03
9961 17.4.4.8/3.)
9962 </p>
9963 <p>
9964 Should the nofail guarantee requested by Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> be extended
9965 to cover both calling <tt>bind()</tt> and copying the returned functor?
9966 </p>
9967
9968 <p><i>[
9969 Howard adds:
9970 ]</i></p>
9971
9972
9973 <blockquote>
9974 <tt>tuple</tt> construction should probably have a similar guarantee.
9975 </blockquote>
9976
9977 <p><i>[
9978 San Francisco:
9979 ]</i></p>
9980
9981
9982 <blockquote>
9983 Howard to provide wording.
9984 </blockquote>
9985
9986 <p><i>[
9987 Post Summit, Anthony provided wording.
9988 ]</i></p>
9989
9990
9991 <p><i>[
9992 Batavia (2009-05):
9993 ]</i></p>
9994
9995 <blockquote>
9996 Part of all of this issue appears to be rendered moot
9997 by the proposed resolution to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a> (q.v.).
9998 We recommend the issues be considered simultaneously
9999 (or possibly even merged)
10000 to ensure there is no overlap.
10001 Move to Open, and likewise for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>.
10002 </blockquote>
10003
10004 <p><i>[
10005 2009-07 Frankfurt:
10006 ]</i></p>
10007
10008
10009 <blockquote>
10010 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a> (see below). Leave Open.
10011 </blockquote>
10012
10013
10014
10015 <p><b>Proposed resolution:</b></p>
10016 <p>
10017 Add a new sentence to the end of paragraphs 2 and 4 of 20.7.12.1.3 [func.bind.bind]:
10018 </p>
10019
10020 <blockquote>
10021 <p>
10022 -2- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a weak result type (20.6.2). The effect of <tt>g(u1, u2,
10023 ..., uM)</tt> shall be <tt><i>INVOKE</i>(f, v1, v2, ..., vN, Callable&lt;F cv,V1, V2, ..., VN&gt;::result_type)</tt>, where <i>cv</i>
10024 represents the <i>cv</i>-qualifiers of <tt>g</tt> and the values and types of the bound arguments
10025 <tt>v1, v2, ..., vN</tt> are determined as specified below.
10026 <ins>The copy constructor and move constructor of the forwarding call wrapper shall throw an
10027 exception if and only if the corresponding constructor of <tt>F</tt> or any of the types
10028 in <tt>BoundArgs...</tt> throw an exception.</ins>
10029 </p>
10030 <p>...</p>
10031 <p>
10032 -4- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a nested type <tt>result_type</tt> defined as a synonym
10033 for <tt>R</tt>. The effect of <tt>g(u1, u2, ..., uM)</tt> shall be <tt><i>INVOKE</i>(f, v1, v2, ..., vN, R)</tt>, where the
10034 values and types of the bound arguments <tt>v1, v2, ..., vN</tt> are determined as specified below.
10035 <ins>The copy constructor and move constructor of the forwarding call wrapper shall throw an
10036 exception if and only if the corresponding constructor of <tt>F</tt> or any of the types
10037 in <tt>BoundArgs...</tt> throw an exception.</ins>
10038 </p>
10039
10040 </blockquote>
10041
10042
10043
10044
10045
10046 <hr>
10047 <h3><a name="817"></a>817. <tt>bind</tt> needs to be moved</h3>
10048 <p><b>Section:</b> 20.7.12.1.3 [func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
10049  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-03-17  <b>Last modified:</b> 2009-07-16</p>
10050 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.bind.bind">active issues</a> in [func.bind.bind].</p>
10051 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p>
10052 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
10053 <p><b>Discussion:</b></p>
10054 <p><b>Addresses US 72, JP 38 and DE 21</b></p>
10055
10056 <p>
10057 The functor returned by <tt>bind()</tt> should have a move constructor that
10058 requires only move construction of its contained functor and bound arguments.
10059 That way move-only functors can be passed to objects such as <tt>thread</tt>.
10060 </p>
10061 <p>
10062 This issue is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>.
10063 </p>
10064
10065 <p>
10066 US 72:
10067 </p>
10068
10069 <blockquote>
10070 <tt>bind</tt> should support move-only functors and bound arguments.
10071 </blockquote>
10072
10073 <p>
10074 JP 38:
10075 </p>
10076
10077 <blockquote>
10078 <p>
10079 add the move requirement for bind's return type.
10080 </p>
10081 <p>
10082 For example, assume following <tt>th1</tt> and <tt>th2</tt>,
10083 </p>
10084
10085 <blockquote><pre>void f(vector&lt;int&gt; v) { }
10086
10087 vector&lt;int&gt; v{ ... };
10088 thread th1([v]{ f(v); });
10089 thread th2(bind(f, v));
10090 </pre></blockquote>
10091
10092 <p>
10093 When function object are set to thread, <tt>v</tt> is moved to <tt>th1</tt>'s lambda
10094 expression in a Move Constructor of lambda expression because <tt>th1</tt>'s lambda
10095 expression has a Move Constructor. But <tt>bind</tt> of <tt>th2</tt>'s
10096 return type doesn't have the requirement of Move, so it may not
10097 moved but copied.
10098 </p>
10099 <p>
10100 Add the requirement of move to get rid of this useless copy.
10101 </p>
10102 <p>
10103 And also, add the <tt>MoveConstructible</tt> as well as <tt>CopyConstructible</tt>.
10104 </p>
10105 </blockquote>
10106
10107 <p>
10108 DE 21
10109 </p>
10110
10111 <blockquote>
10112 The specification for bind claims twice that "the values and types for
10113 the bound arguments v1, v2, ..., vN are determined as specified below".
10114 No such specification appears to exist.
10115 </blockquote>
10116
10117 <p><i>[
10118 San Francisco:
10119 ]</i></p>
10120
10121
10122 <blockquote>
10123 Howard to provide wording.
10124 </blockquote>
10125
10126 <p><i>[
10127 Post Summit Alisdair and Howard provided wording.
10128 ]</i></p>
10129
10130
10131 <blockquote>
10132 <p>
10133 Several issues are being combined in this resolution.  They are all touching the
10134 same words so this is an attempt to keep one issue from stepping on another, and
10135 a place to see the complete solution in one place.
10136 </p>
10137
10138 <ol>
10139 <li>
10140 <tt>bind</tt> needs to be "moved".
10141 </li>
10142 <li>
10143 20.7.12.1.3 [func.bind.bind]/p3, p6 and p7 were accidently removed from N2798.
10144 </li>
10145 <li>
10146 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a> argues for a way to pass by &amp;&amp; for
10147 efficiency but retain the decaying behavior of pass by value for the
10148 <tt>thread</tt> constructor.  That same solution is applicable here.
10149 </li>
10150 </ol>
10151 </blockquote>
10152
10153 <p><i>[
10154 Batavia (2009-05):
10155 ]</i></p>
10156
10157 <blockquote>
10158 <p>
10159 We were going to recommend moving this issue to Tentatively Ready
10160 until we noticed potential overlap with issue 816 (q.v.).
10161 </p>
10162 <p>
10163 Move to Open,
10164 and recommend both issues be considered together
10165 (and possibly merged).
10166 </p>
10167 </blockquote>
10168
10169 <p><i>[
10170 2009-07 Frankfurt:
10171 ]</i></p>
10172
10173
10174 <blockquote>
10175 The proposed resolution uses concepts. Leave Open.
10176 </blockquote>
10177
10178
10179
10180 <p><b>Proposed resolution:</b></p>
10181 <p>
10182 Change 20.7 [function.objects] p2:
10183 </p>
10184
10185 <blockquote><pre>template&lt;<del>CopyConstructible</del> <ins>MoveConstructible</ins> Fn, <del>CopyConstructible</del> <ins>MoveConstructible</ins>... Types&gt;
10186   <i>unspecified</i> bind(Fn<ins>&amp;&amp;</ins>, Types<ins>&amp;&amp;</ins>...);
10187 template&lt;Returnable R, <del>CopyConstructible</del> <ins>MoveConstructible</ins> Fn, <del>CopyConstructible</del> <ins>MoveConstructible</ins>... Types&gt;
10188   <i>unspecified</i> bind(Fn<ins>&amp;&amp;</ins>, Types<ins>&amp;&amp;</ins>...);
10189 </pre></blockquote>
10190
10191 <p>
10192 Change 20.7.12.1.3 [func.bind.bind]:
10193 </p>
10194
10195 <blockquote><pre>template&lt;<del>CopyConstructible</del> <ins>MoveConstructible</ins> F, <del>CopyConstructible</del> <ins>MoveConstructible</ins>... BoundArgs&gt;
10196   <i>unspecified</i> bind(F<ins>&amp;&amp;</ins> f, BoundArgs<ins>&amp;&amp;</ins>... bound_args);
10197 </pre>
10198
10199 <blockquote>
10200 <p>
10201 <ins><i>Requires:</i> <i>unspecified</i> return type shall be <tt>MoveConstructible</tt>.</ins>
10202 </p>
10203 <p>
10204 -1- <i>Requires:</i> <tt><i>INVOKE</i>(f, w1, w2, ..., wN)</tt> (20.6.2) shall be a valid expression for some values
10205 <i>w1, w2, ..., wN</i>, where <tt>N == sizeof...(bound_args)</tt>.
10206 </p>
10207 <p>
10208 -2- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a weak result type (20.6.2). The effect of <tt>g(u1, u2,
10209 ..., uM)</tt> shall be <tt><i>INVOKE</i>(f, v1, v2, ..., vN, Callable&lt;F cv,V1, V2, ..., VN&gt;::result_type)</tt>, where <i>cv</i>
10210 represents the <i>cv</i>-qualifiers of <tt>g</tt> and the values and types of the bound arguments
10211 <tt>v1, v2, ..., vN</tt> are determined as specified below.
10212 </p>
10213 <p><ins>
10214 <i>Throws:</i> Nothing unless the constructor of <tt>F</tt> or of one of the types in the <tt>BoundArgs...</tt> pack expansion
10215 throws an exception.
10216 </ins></p>
10217 </blockquote>
10218
10219 <pre>template&lt;Returnable R, <del>CopyConstructible</del> <ins>MoveConstructible</ins> F, <del>CopyConstructible</del> <ins>MoveConstructible</ins>... BoundArgs&gt;
10220   <i>unspecified</i> bind(F<ins>&amp;&amp;</ins> f, BoundArgs<ins>&amp;&amp;</ins>... bound_args);
10221 </pre>
10222
10223 <blockquote>
10224 <p>
10225 <ins><i>Requires:</i> <i>unspecified</i> return type shall be <tt>MoveConstructible</tt>.</ins>
10226 </p>
10227 <p>
10228 -3- <i>Requires:</i> <tt><i>INVOKE</i>(f, w1, w2, ..., wN)</tt> shall be a valid expression for some values <i>w1, w2, ...,
10229 wN</i>, where <tt>N == sizeof...(bound_args)</tt>.
10230 </p>
10231 <p>
10232 -4- <i>Returns:</i> A forwarding call wrapper <tt>g</tt> with a nested type <tt>result_type</tt> defined as a synonym
10233 for <tt>R</tt>. The effect of <tt>g(u1, u2, ..., uM)</tt> shall be <tt><i>INVOKE</i>(f, v1, v2, ..., vN, R)</tt>, where the
10234 values and types of the bound arguments <tt>v1, v2, ..., vN</tt> are determined as specified below.
10235 </p>
10236 <p>
10237 </p><p><ins>
10238 <i>Throws:</i> Nothing unless the constructor of <tt>F</tt> or of one of the types in the <tt>BoundArgs...</tt> pack expansion
10239 throws an exception.
10240 </ins></p>
10241
10242 </blockquote>
10243
10244 <p><ins>
10245 Let the values of <i>bound arguments</i> <tt>v1, v2, ..., vN</tt> and
10246 their corresponding types <tt>V1, V2, ..., VN</tt> depend on the type of
10247 the corresponding argument <tt>ti</tt> in <tt>bound_args</tt> in the
10248 call to <tt>bind</tt> and the <i>cv</i>-qualifiers <i>cv</i> of the call
10249 wrapper <tt>g</tt> as follows. Let <tt>Ti</tt> be an alias for the ith
10250 element of the pack expansion <tt>decay&lt;BoundArgs&gt;::type...</tt>,
10251 and let <tt>ti</tt> be an alias for the ith element in the function
10252 parameter pack expansion <tt>bound_args...</tt>:
10253 </ins></p>
10254
10255 <ul>
10256 <li><ins>
10257 if <tt>ti</tt> is of type <tt>reference_wrapper&lt;T&gt;</tt> the argument is
10258 <tt>ti.get()</tt> and its type <tt>Vi</tt> is <tt>T&amp;</tt>;
10259 </ins></li>
10260 <li><ins>
10261 if the value of <tt>std::is_bind_expression&lt;Ti&gt;::value</tt> is <tt>true</tt> the argument is <tt>ti(u1, u2, ..., uM)</tt> and
10262 its type <tt>Vi</tt> is <tt>result_of&lt;Ti cv (U1&amp;, U2&amp;, ..., UM&amp;)&gt;::type</tt>;
10263 </ins></li>
10264 <li><ins>
10265 if the value <tt>j</tt> of <tt>std::is_placeholder&lt;Ti&gt;::value</tt> is not zero the argument is <tt>std::forward&lt;Uj&gt;(uj)</tt> and
10266 its type <tt>Vi</tt> is <tt>Uj&amp;&amp;</tt>;
10267 </ins></li>
10268 <li><ins>
10269 otherwise the value is <tt>ti</tt> and its type <tt>Vi</tt> is <tt>Ti cv &amp;</tt>.
10270 </ins></li>
10271 </ul>
10272
10273 </blockquote>
10274
10275
10276
10277
10278
10279
10280 <hr>
10281 <h3><a name="819"></a>819. rethrow_if_nested</h3>
10282 <p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
10283  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-03-25  <b>Last modified:</b> 2008-09-17</p>
10284 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p>
10285 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p>
10286 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
10287 <p><b>Discussion:</b></p>
10288 <p>
10289 Looking at the wording I submitted for <tt>rethrow_if_nested</tt>, I don't think I
10290 got it quite right.
10291 </p>
10292
10293 <p>
10294 The current wording says:
10295 </p>
10296
10297 <blockquote>
10298 <pre>template &lt;class E&gt; void rethrow_if_nested(const E&amp; e);
10299 </pre>
10300 <blockquote>
10301 <p>
10302 <i>Effects:</i> Calls <tt>e.rethrow_nested()</tt> only if <tt>e</tt>
10303 is publicly derived from <tt>nested_exception</tt>.
10304 </p>
10305 </blockquote>
10306 </blockquote>
10307
10308 <p>
10309 This is trying to be a bit subtle, by requiring <tt>e</tt> (not <tt>E</tt>) to be publicly
10310 derived from <tt>nested_exception</tt> the idea is that a <tt>dynamic_cast</tt> would be
10311 required to be sure.  Unfortunately, if <tt>e</tt> is dynamically but not statically
10312 derived from <tt>nested_exception</tt>, <tt>e.rethrow_nested()</tt> is ill-formed.
10313 </p>
10314
10315 <p><i>[
10316 San Francisco:
10317 ]</i></p>
10318
10319
10320 <blockquote>
10321 Alisdair was volunteered to provide wording.
10322 </blockquote>
10323
10324
10325 <p><b>Proposed resolution:</b></p>
10326
10327
10328
10329
10330
10331 <hr>
10332 <h3><a name="822"></a>822. Object with explicit copy constructor no longer <tt>CopyConstructible</tt></h3>
10333 <p><b>Section:</b> X [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
10334  <b>Submitter:</b> James Kanze <b>Opened:</b> 2008-04-01  <b>Last modified:</b> 2009-07-26</p>
10335 <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>
10336 <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>
10337 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
10338 <p><b>Discussion:</b></p>
10339 <p>
10340 I just noticed that the following program is legal in C++03, but
10341 is forbidden in the current draft:
10342 </p>
10343
10344 <blockquote><pre>#include &lt;vector&gt;
10345 #include &lt;iostream&gt;
10346
10347 class Toto
10348 {
10349 public:
10350     Toto() {}
10351     explicit Toto( Toto const&amp; ) {}
10352 } ;
10353
10354 int
10355 main()
10356 {
10357     std::vector&lt; Toto &gt; v( 10 ) ;
10358     return 0 ;
10359 }
10360 </pre></blockquote>
10361
10362 <p>
10363 Is this change intentional?  (And if so, what is the
10364 justification?  I wouldn't call such code good, but I don't see
10365 any reason to break it unless we get something else in return.)
10366 </p>
10367
10368 <p><i>[
10369 San Francisco:
10370 ]</i></p>
10371
10372
10373 <blockquote>
10374 The subgroup that looked at this felt this was a good change, but it may
10375 already be handled by incoming concepts (we're not sure).
10376 </blockquote>
10377
10378 <p><i>[
10379 Post Summit:
10380 ]</i></p>
10381
10382
10383 <blockquote>
10384 <p>
10385 Alisdair: Proposed resolution kinda funky as these tables no longer
10386 exist. Move from direct init to copy init. Clarify with Doug, recommends
10387 NAD.
10388 </p>
10389 <p>
10390 Walter: Suggest NAD via introduction of concepts.
10391 </p>
10392 <p>
10393 Recommend close as NAD.
10394 </p>
10395 </blockquote>
10396
10397 <p><i>[
10398 2009-07 Frankfurt:
10399 ]</i></p>
10400
10401
10402 <blockquote>
10403 Need to look at again without concepts.
10404 </blockquote>
10405
10406 <p><i>[
10407 2009-07 Frankfurt:
10408 ]</i></p>
10409
10410
10411 <blockquote>
10412 <p>
10413 Move to Ready with original proposed resolution.
10414 </p>
10415 <p><i>[Howard:  Original proposed resolution restored.]</i></p>
10416
10417 </blockquote>
10418
10419
10420
10421 <p><b>Proposed resolution:</b></p>
10422 <p>
10423 In X [utility.arg.requirements] change Table 33: <tt>MoveConstructible</tt> requirements [moveconstructible]:
10424 </p>
10425
10426 <blockquote>
10427 <table border="1">
10428 <tbody><tr>
10429 <th>expression</th><th>post-condition</th>
10430 </tr>
10431 <tr>
10432 <td><tt>T t<ins>(rv)</ins><del> = rv</del></tt></td><td><tt>t</tt> is equivalent to the value of <tt>rv</tt> before the construction</td>
10433 </tr>
10434 <tr>
10435 <td colspan="2" align="center">...</td>
10436 </tr>
10437 </tbody></table>
10438 </blockquote>
10439
10440 <p>
10441 In X [utility.arg.requirements] change Table 34: <tt>CopyConstructible</tt> requirements [copyconstructible]:
10442 </p>
10443
10444 <blockquote>
10445 <table border="1">
10446 <tbody><tr>
10447 <th>expression</th><th>post-condition</th>
10448 </tr>
10449 <tr>
10450 <td><tt>T t<ins>(u)</ins><del> = u</del></tt></td><td>the value of <tt>u</tt> is unchanged and is equivalent to <tt>t</tt></td>
10451 </tr>
10452 <tr>
10453 <td colspan="2" align="center">...</td>
10454 </tr>
10455 </tbody></table>
10456 </blockquote>
10457
10458
10459
10460
10461
10462 <hr>
10463 <h3><a name="823"></a>823. <tt>identity&lt;void&gt;</tt> seems broken</h3>
10464 <p><b>Section:</b> 20.3.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
10465  <b>Submitter:</b> Walter Brown <b>Opened:</b> 2008-04-09  <b>Last modified:</b> 2009-07-30</p>
10466 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forward">active issues</a> in [forward].</p>
10467 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward">issues</a> in [forward].</p>
10468 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
10469 <p><b>Discussion:</b></p>
10470 <p>
10471 N2588 seems to have added an <tt>operator()</tt> member function to the
10472 <tt>identity&lt;&gt;</tt> helper in 20.3.2 [forward].  I believe this change makes it no
10473 longer possible to instantiate <tt>identity&lt;void&gt;</tt>, as it would require
10474 forming a reference-to-<tt>void</tt> type as this <tt>operator()</tt>'s parameter type.
10475 </p>
10476
10477 <p>
10478 Suggested resolution:  Specialize <tt>identity&lt;void&gt;</tt> so as not to require
10479 the member function's presence.
10480 </p>
10481
10482 <p><i>[
10483 Sophia Antipolis:
10484 ]</i></p>
10485
10486
10487 <blockquote>
10488 <p>
10489 Jens: suggests to add a requires clause to avoid specializing on <tt>void</tt>.
10490 </p>
10491 <p>
10492 Alisdair: also consider cv-qualified <tt>void</tt>.
10493 </p>
10494 <p>
10495 Alberto provided proposed wording.
10496 </p>
10497 </blockquote>
10498
10499 <p><i>[
10500 2009-07-30 Daniel reopens:
10501 ]</i></p>
10502
10503
10504 <blockquote>
10505 <p>
10506 This issue became closed, because the <tt>ReferentType</tt> requirement
10507 fixed the problem - this is no longer the case. In retrospective it seems
10508 to be that the root of current issues around <tt>std::identity</tt> (823, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>,
10509 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#939">939</a>)
10510 is that it was standardized as something very different (an unconditional
10511 type mapper) than traditional usage indicated (a function object that should
10512 derive from <tt>std::unary_function)</tt>, as the SGI definition does. This issue could
10513 be solved, if <tt>std::identity</tt> is removed (one proposal of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#939">939</a>), but until this
10514 has been decided, this issue should remain open. An alternative for
10515 removing it, would be, to do the following:
10516 </p>
10517
10518 <ol type="a">
10519 <li>
10520 <p>
10521 Let <tt>identity</tt> stay as a <em>real</em> function object, which would
10522 now properly
10523 derive from <tt>unary_function</tt>:
10524 </p>
10525
10526 <blockquote><pre>template &lt;class T&gt; struct identity : unary_function&lt;T, T&gt; {
10527   const T&amp; operator()(const T&amp;) const;
10528 };
10529 </pre></blockquote>
10530 </li>
10531
10532 <li>
10533 <p>
10534 Invent (if needed) a generic type wrapper (corresponding to concept
10535 <tt>IdentityOf</tt>),
10536 e.g. <tt>identity_of</tt>, and move it's prototype description back to 20.3.2 [forward]:
10537 </p>
10538
10539 <blockquote><pre>template &lt;class T&gt; struct identity_of {
10540   typedef T type;
10541 };
10542 </pre></blockquote>
10543
10544 <p>
10545 and adapt the <tt>std::forward</tt> signature to use <tt>identity_of</tt>
10546 instead of <tt>identity</tt>.
10547 </p>
10548 </li>
10549 </ol>
10550 </blockquote>
10551
10552
10553 <p><b>Proposed resolution:</b></p>
10554 <p>
10555 Change definition of <tt>identity</tt> in 20.3.2 [forward], paragraph 2, to:
10556 </p>
10557
10558 <blockquote><pre>template &lt;class T&gt;  struct identity {
10559     typedef T type;
10560
10561     <ins>requires ReferentType&lt;T&gt;</ins>
10562       const T&amp; operator()(const T&amp; x) const;
10563   };
10564 </pre></blockquote>
10565 <p>...</p>
10566 <blockquote><pre>  <ins>requires ReferentType&lt;T&gt;</ins>
10567     const T&amp; operator()(const T&amp; x) const;
10568 </pre></blockquote>
10569
10570
10571 <p><b>Rationale:</b></p>
10572 <p>
10573 The point here is to able to write <tt>T&amp;</tt> given <tt>T</tt> and <tt>ReferentType</tt> is
10574 precisely the concept that guarantees so, according to N2677
10575 (Foundational concepts). Because of this, it seems preferable than an
10576 explicit check for <tt>cv void</tt> using <tt>SameType/remove_cv</tt> as it was suggested
10577 in Sophia. In particular, Daniel remarked that there may be types other
10578 than <tt>cv void</tt> which aren't referent types (<tt>int[]</tt>, perhaps?).
10579 </p>
10580
10581
10582
10583
10584
10585 <hr>
10586 <h3><a name="827"></a>827. <tt>constexpr shared_ptr::shared_ptr()?</tt></h3>
10587 <p><b>Section:</b> 20.8.10.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
10588  <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-04-11  <b>Last modified:</b> 2009-07-21</p>
10589 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared.const">active issues</a> in [util.smartptr.shared.const].</p>
10590 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
10591 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
10592 <p><b>Discussion:</b></p>
10593 <p>
10594 Would anyone object to making the default constructor of <tt>shared_ptr</tt> (and
10595 <tt>weak_ptr</tt> and <tt>enable_shared_from_this) constexpr</tt>? This would enable
10596 static initialization for <tt>shared_ptr</tt> variables, eliminating another
10597 unfair advantage of raw pointers.
10598 </p>
10599
10600 <p><i>[
10601 San Francisco:
10602 ]</i></p>
10603
10604
10605 <blockquote>
10606 <p>
10607 It's not clear to us that you can initialize a pointer with the literal
10608 0 in a constant expression. We need to ask CWG to make sure this works.
10609 Bjarne has been appointed to do this.
10610 </p>
10611 <p>
10612 Core got back to us and assured as that <tt>nullptr</tt> would do the job
10613 nicely here.
10614 </p>
10615 </blockquote>
10616
10617 <p><i>[
10618 2009-05-01 Alisdair adds:
10619 ]</i></p>
10620
10621
10622 <blockquote>
10623 <p>
10624 I don't believe that constexpr will buy anything in this case.
10625 <tt>shared_ptr/weak_ptr/enable_shared_from_this</tt> cannot be literal types as they
10626 have a non-trivial copy constructor.  As they do not produce literal types,
10627 then the constexpr default constructor will <em>not</em> guarantee constant
10628 initialization, and so not buy the hoped for optimization.
10629 </p>
10630 <p>
10631 I recommend referring this back to Core to see if we can get static
10632 initialization for types with constexpr constructors, even if they are not
10633 literal types.  Otherwise this should be closed as NAD.
10634 </p>
10635 </blockquote>
10636
10637 <p><i>[
10638 2009-05-26 Daniel adds:
10639 ]</i></p>
10640
10641
10642 <blockquote>
10643 If Alisdair's 2009-05-01 comment is correct, wouldn't that also make
10644 <tt>constexpr mutex()</tt> useless, because this class has a non-trivial
10645 destructor? (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>)
10646 </blockquote>
10647
10648 <p><i>[
10649 2009-07-21 Alisdair adds:
10650 ]</i></p>
10651
10652
10653 <blockquote>
10654 <p>
10655 The feedback from core is that this and similar uses of constexpr
10656 constructors to force static initialization should be supported.  If
10657 there are any problems with this in the working draught, we should file
10658 core issues.
10659 </p>
10660
10661 <p>
10662 Recommend we declare the default constructor constexpr as the issue suggests
10663 (proposed wording added).
10664 </p>
10665 </blockquote>
10666
10667
10668
10669 <p><b>Proposed resolution:</b></p>
10670 <p>
10671 Change 20.8.10.2 [util.smartptr.shared] and 20.8.10.2.1 [util.smartptr.shared.const]:
10672 </p>
10673
10674 <blockquote><pre><ins>consexpr</ins> shared_ptr();
10675 </pre></blockquote>
10676
10677 <p>
10678 Change 20.8.10.3 [util.smartptr.weak] and 20.8.10.3.1 [util.smartptr.weak.const]:
10679 </p>
10680
10681 <blockquote><pre><ins>consexpr</ins> weak_ptr();
10682 </pre></blockquote>
10683
10684 <p>
10685 Change 20.8.10.5 [util.smartptr.enab] (2 places):
10686 </p>
10687
10688 <blockquote><pre><ins>consexpr</ins> enable_shared_from_this();
10689 </pre></blockquote>
10690
10691
10692
10693
10694
10695
10696 <hr>
10697 <h3><a name="828"></a>828. Static initialization for <tt>std::mutex</tt>?</h3>
10698 <p><b>Section:</b> 30.4.1.1 [thread.mutex.class] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
10699  <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-04-18  <b>Last modified:</b> 2009-05-30</p>
10700 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.class">active issues</a> in [thread.mutex.class].</p>
10701 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.class">issues</a> in [thread.mutex.class].</p>
10702 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
10703 <p><b>Discussion:</b></p>
10704 <p>
10705 [Note: I'm assuming here that 3.6.2 [basic.start.init]/1 will be fixed.]
10706 </p>
10707 <p>
10708 Currently <tt>std::mutex</tt> doesn't support static initialization. This is a
10709 regression with respect to <tt>pthread_mutex_t</tt>, which does. I believe that
10710 we should strive to eliminate such regressions in expressive power where
10711 possible, both to ease migration and to not provide incentives to (or
10712 force) people to forego the C++ primitives in favor of pthreads.
10713 </p>
10714
10715 <p><i>[
10716 Sophia Antipolis:
10717 ]</i></p>
10718
10719
10720 <blockquote>
10721 <p>
10722 We believe this is implementable on POSIX, because the initializer-list
10723 feature and the constexpr feature make this work. Double-check core
10724 language about static initialization for this case. Ask core for a core
10725 issue about order of destruction of statically-initialized objects wrt.
10726 dynamically-initialized objects (should come afterwards). Check
10727 non-POSIX systems for implementability.
10728 </p>
10729 <p>
10730 If ubiquitous implementability cannot be assured, plan B is to introduce
10731 another constructor, make this constexpr, which is
10732 conditionally-supported. To avoid ambiguities, this new constructor needs
10733 to have an additional parameter.
10734 </p>
10735 </blockquote>
10736
10737 <p><i>[
10738 Post Summit:
10739 ]</i></p>
10740
10741
10742 <blockquote>
10743 <p>
10744 Jens: constant initialization seems to be ok core-language wise
10745 </p>
10746 <p>
10747 Consensus: Defer to threading experts, in particular a Microsoft platform expert.
10748 </p>
10749 <p>
10750 Lawrence to send e-mail to Herb Sutter, Jonathan Caves, Anthony Wiliams,
10751 Paul McKenney, Martin Tasker, Hans Boehm, Bill Plauger, Pete Becker,
10752 Peter Dimov to alert them of this issue.
10753 </p>
10754 <p>
10755 Lawrence: What about header file shared with C? The initialization
10756 syntax is different in C and C++.
10757 </p>
10758 <p>
10759 Recommend Keep in Review
10760 </p>
10761 </blockquote>
10762
10763 <p><i>[
10764 Batavia (2009-05):
10765 ]</i></p>
10766
10767 <blockquote>
10768 Keep in Review status pending feedback from members of the Concurrency subgroup.
10769 </blockquote>
10770
10771 <p><i>[
10772 See related comments from Alisdiar and Daniel in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#827">827</a>.
10773 ]</i></p>
10774
10775
10776
10777
10778 <p><b>Proposed resolution:</b></p>
10779 <p>
10780 Change 30.4.1.1 [thread.mutex.class]:
10781 </p>
10782
10783 <blockquote><pre>class mutex {
10784 public:
10785   <ins>constexpr</ins> mutex();
10786   ...
10787 </pre></blockquote>
10788
10789
10790
10791
10792
10793 <hr>
10794 <h3><a name="834"></a>834. Unique_ptr::pointer requirements underspecified</h3>
10795 <p><b>Section:</b> 20.8.9.2 [unique.ptr.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
10796  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-05-14  <b>Last modified:</b> 2009-07-16</p>
10797 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single">active issues</a> in [unique.ptr.single].</p>
10798 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single">issues</a> in [unique.ptr.single].</p>
10799 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
10800 <p><b>Discussion:</b></p>
10801 <p>
10802 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> (including recent updates by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#821">821</a>) proposes a useful
10803 extension point for <tt>unique_ptr</tt> by granting support for an optional
10804 <tt>deleter_type::pointer</tt> to act as pointer-like replacement for <tt>element_type*</tt>
10805 (In the following: <tt>pointer</tt>).
10806 </p>
10807 <p>
10808 Unfortunately no requirements are specified for the type <tt>pointer</tt> which has
10809 impact on at least two key features of <tt>unique_ptr</tt>:
10810 </p>
10811
10812 <ol>
10813 <li>Operational fail-safety.</li>
10814 <li>(Well-)Definedness of expressions.</li>
10815 </ol>
10816
10817 <p>
10818 <tt>Unique_ptr</tt> specification makes great efforts to require that essentially *all*
10819 operations cannot throw and therefore adds proper wording to the affected
10820 operations of the deleter as well. If user-provided <tt>pointer</tt>-emulating types
10821 ("smart pointers") will be allowed, either *all* throw-nothing clauses have to
10822 be replaced by weaker "An exception is thrown only if <tt>pointer</tt>'s {op} throws
10823 an exception"-clauses or it has to be said explicitly that all used
10824 operations of
10825 <tt>pointer</tt> are required *not* to throw. I understand the main focus of <tt>unique_ptr</tt>
10826 to be as near as possible to the advantages of native pointers which cannot
10827 fail and thus strongly favor the second choice. Also, the alternative position
10828 would make it much harder to write safe and simple template code for
10829 <tt>unique_ptr</tt>. Additionally, I assume that a general statement need to be given
10830 that all of the expressions of <tt>pointer</tt> used to define semantics are required to
10831 be well-formed and well-defined (also as back-end for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#762">762</a>).
10832 </p>
10833
10834 <p><i>[
10835 Sophia Antipolis:
10836 ]</i></p>
10837
10838
10839 <blockquote>
10840 <p>
10841 Howard: We maybe need a core concept <tt>PointerLike</tt>, but we don't need the
10842 arithmetic (see <tt>shared_ptr</tt> vs. <tt>vector&lt;T&gt;::iterator</tt>.
10843 </p>
10844 <p>
10845 Howard will go through and enumerate the individual requirements wrt. <tt>pointer</tt> for each member function.
10846 </p>
10847 </blockquote>
10848
10849 <p><i>[
10850 2009-07 Frankfurt:
10851 ]</i></p>
10852
10853
10854 <blockquote>
10855 Move to Ready.
10856 </blockquote>
10857
10858
10859
10860 <p><b>Proposed resolution:</b></p>
10861 <p>
10862 Add the following sentence just at the end of the newly proposed
10863 20.8.9.2 [unique.ptr.single]/p. 3:
10864 </p>
10865
10866 <blockquote>
10867 <tt>unique_ptr&lt;T, D&gt;::pointer</tt>'s operations shall be well-formed, shall have well
10868 defined behavior, and shall not throw exceptions.
10869 </blockquote>
10870
10871
10872
10873
10874
10875 <hr>
10876 <h3><a name="835"></a>835. tying two streams together (correction to DR 581)</h3>
10877 <p><b>Section:</b> 27.5.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
10878  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-05-17  <b>Last modified:</b> 2009-07-27</p>
10879 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p>
10880 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
10881 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
10882 <p><b>Discussion:</b></p>
10883        <p>
10884
10885 The fix for
10886 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>,
10887 now integrated into the working paper, overlooks a couple of minor
10888 problems.
10889
10890        </p>
10891        <p>
10892
10893 First, being an unformatted function once again, <code>flush()</code>
10894 is required to create a sentry object whose constructor must, among
10895 other things, flush the tied stream. When two streams are tied
10896 together, either directly or through another intermediate stream
10897 object, flushing one will also cause a call to <code>flush()</code> on
10898 the other tied stream(s) and vice versa, ad infinitum. The program
10899 below demonstrates the problem.
10900
10901        </p>
10902        <p>
10903
10904 Second, as Bo Persson notes in his
10905 comp.lang.c++.moderated <a href="http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/f2187794e9cc036d/305df31dc583054a">post</a>,
10906 for streams with the <code>unitbuf</code> flag set such
10907 as <code>std::stderr</code>, the destructor of the sentry object will
10908 again call <code>flush()</code>. This seems to create an infinite
10909 recursion for <code>std::cerr &lt;&lt; std::flush;</code>
10910
10911        </p>
10912        <blockquote>
10913            <pre>#include &lt;iostream&gt;
10914
10915 int main ()
10916 {
10917    std::cout.tie (&amp;std::cerr);
10918    std::cerr.tie (&amp;std::cout);
10919    std::cout &lt;&lt; "cout\n";
10920    std::cerr &lt;&lt; "cerr\n";
10921 }
10922 </pre>
10923 </blockquote>
10924
10925 <p><i>[
10926 Batavia (2009-05):
10927 ]</i></p>
10928
10929 <blockquote>
10930 We agree with the proposed resolution.
10931 Move to Review.
10932 </blockquote>
10933
10934 <p><i>[
10935 2009-05-26 Daniel adds:
10936 ]</i></p>
10937
10938
10939 <blockquote>
10940 <p>
10941 I think that the most recently suggested change in
10942 27.7.2.4 [ostream::sentry] need some further word-smithing. As
10943 written, it would make the behavior undefined, if under
10944 conditions when <tt>pubsync()</tt> should be called, but when
10945 in this scenario <tt>os.rdbuf()</tt> returns 0.
10946 </p>
10947 <p>
10948 This case is explicitly handled in <tt>flush()</tt> and needs to be
10949 taken care of. My suggested fix is:
10950 </p>
10951
10952 <blockquote>
10953 If <tt>((os.flags() &amp; ios_base::unitbuf) &amp;&amp; !uncaught_exception()</tt>
10954 <ins><tt>&amp;&amp; os.rdbuf() != 0</tt></ins>) is true, calls <del><tt>os.flush()</tt></del>
10955 <ins><tt>os.rdbuf()-&gt;pubsync()</tt></ins>.
10956 </blockquote>
10957
10958 <p>
10959 Two secondary questions are:
10960 </p>
10961
10962 <ol>
10963 <li>
10964 Should <tt>pubsync()</tt> be invoked in any case or shouldn't a
10965 base requirement for this trial be that <tt>os.good() == true</tt>
10966 as required in the original <tt>flush()</tt> case?
10967 </li>
10968 <li>
10969 Since <tt>uncaught_exception()</tt> is explicitly tested, shouldn't
10970 a return value of -1 of <tt>pubsync()</tt> produce <tt>setstate(badbit)</tt>
10971 (which may throw <tt>ios_base::failure</tt>)?
10972 </li>
10973 </ol>
10974 </blockquote>
10975
10976 <p><i>[
10977 2009-07 Frankfurt:
10978 ]</i></p>
10979
10980
10981 <blockquote>
10982 <p>
10983 Daniel volunteered to modify the proposed resolution to address his two questions.
10984 </p>
10985 <p>
10986 Move back to Open.
10987 </p>
10988 </blockquote>
10989
10990 <p><i>[
10991 2009-07-26 Daniel provided wording.  Moved to Review.
10992 ]</i></p>
10993
10994
10995
10996
10997 <p><b>Proposed resolution:</b></p>
10998 <p><i>[
10999 based on
11000 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>
11001 numbering
11002 ]</i></p>
11003
11004
11005 <ol>
11006 <li>
11007 <p>
11008 Just before 27.5.4.2 [basic.ios.members]/2 insert a new paragraph:
11009 </p>
11010
11011 <blockquote>
11012 <ins><i>Requires:</i> If <tt>(tiestr != 0)</tt> is <tt>true</tt>, <tt>tiestr</tt> must not be reachable
11013 by traversing the linked list of tied stream objects starting from
11014 <tt>tiestr-&gt;tie()</tt>.</ins>
11015 </blockquote>
11016 </li>
11017
11018 <li>
11019 <p>
11020 Change 27.7.2.4 [ostream::sentry]/4 as indicated:
11021 </p>
11022
11023 <blockquote>
11024 If <tt>((os.flags() &amp; ios_base::unitbuf) &amp;&amp; !uncaught_exception()<ins>&amp;&amp;
11025 os.good()</ins>)</tt> is <tt>true</tt>, calls <del><tt>os.flush()</tt></del>
11026 <ins><tt>os.rdbuf()-&gt;pubsync()</tt>. If that function returns -1 sets
11027 <tt>badbit</tt> in <tt>os.rdstate()</tt> without propagating an exception</ins>.
11028 </blockquote>
11029 </li>
11030
11031 </ol>
11032
11033
11034
11035
11036
11037
11038 <hr>
11039 <h3><a name="836"></a>836.
11040        effects of <code>money_base::space</code> and
11041        <code>money_base::none</code> on <code>money_get</code>
11042    </h3>
11043 <p><b>Section:</b> 22.4.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
11044  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-05-17  <b>Last modified:</b> 2009-07-16</p>
11045 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p>
11046 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
11047 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
11048 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#670">670</a></p>
11049 <p><b>Discussion:</b></p>
11050
11051        <p>
11052
11053 In paragraph 2, 22.4.6.1.2 [locale.money.get.virtuals] specifies the following:
11054
11055        </p>
11056        <blockquote>
11057
11058 Where <code>space</code> or <code>none</code> appears in the format
11059 pattern, except at the end, optional white space (as recognized
11060 by <code>ct.is</code>) is consumed after any required space.
11061
11062        </blockquote>
11063        <p>
11064
11065 This requirement can be (and has been) interpreted two mutually
11066 exclusive ways by different readers. One possible interpretation
11067 is that:
11068
11069        </p>
11070        <blockquote>
11071            <ol>
11072                <li>
11073
11074 where <code>money_base::space</code> appears in the format, at least
11075 one space is required, and
11076
11077                </li>
11078                <li>
11079
11080 where <code>money_base::none</code> appears in the format, space is
11081 allowed but not required.
11082
11083                </li>
11084            </ol>
11085        </blockquote>
11086        <p>
11087
11088 The other is that:
11089
11090        </p>
11091        <blockquote>
11092
11093 where either <code>money_base::space</code> or <code>money_base::none</code> appears in the format, white space is optional.
11094
11095        </blockquote>
11096
11097 <p><i>[
11098 San Francisco:
11099 ]</i></p>
11100
11101
11102 <blockquote>
11103 Martin will revise the proposed resolution.
11104 </blockquote>
11105
11106 <p><i>[
11107 2009-07 Frankfurt:
11108 ]</i></p>
11109
11110
11111 <blockquote>
11112 <p>
11113 There is a noun missing from the proposed resolution. It's not clear
11114 that the last sentence would be helpful, even if the word were not
11115 missing:
11116 </p>
11117 <blockquote>
11118 In either case, any required MISSINGWORD followed by all optional whitespace (as recognized by ct.is()) is consumed.
11119 </blockquote>
11120 <p>
11121 Strike this sentence and move to Review.
11122 </p>
11123 </blockquote>
11124
11125
11126
11127    <p><b>Proposed resolution:</b></p>
11128        <p>
11129
11130 I propose to change the text to make it clear that the first
11131 interpretation is intended, that is, to make following change to
11132 22.4.6.1.2 [locale.money.get.virtuals], p2:
11133
11134        </p>
11135
11136        <blockquote>
11137
11138 When <code><ins>money_base::</ins>space</code>
11139 or <code><ins>money_base::</ins>none</code> appears <ins>as the last
11140 element </ins>in the format pattern, <del>except at the end, optional
11141 white space (as recognized by <code>ct.is</code>) is consumed after
11142 any required space.</del> <ins>no white space is consumed. Otherwise,
11143 where <code>money_base::space</code> appears in any of the initial
11144 elements of the format pattern, at least one white space character is
11145 required. Where <code>money_base::none</code> appears in any of the
11146 initial elements of the format pattern, white space is allowed but not
11147 required.</ins>
11148 If <code>(str.flags() &amp; str.showbase)</code> is <code>false</code>, ...
11149
11150        </blockquote>
11151
11152
11153
11154
11155 <hr>
11156 <h3><a name="838"></a>838.
11157    can an <i>end-of-stream</i> iterator become a <i>non-end-of-stream</i> one?
11158  </h3>
11159 <p><b>Section:</b> 24.6.1 [istream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
11160  <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-05-17  <b>Last modified:</b> 2009-07-16</p>
11161 <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>
11162 <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>
11163 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
11164 <p><b>Discussion:</b></p>
11165    <p>
11166
11167 From message c++std-lib-20003...
11168
11169    </p>
11170    <p>
11171
11172 The description of <code>istream_iterator</code> in
11173 24.6.1 [istream.iterator], p1 specifies that objects of the
11174 class become the <i>end-of-stream</i> (EOS) iterators under the
11175 following condition (see also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a> another problem
11176 with this paragraph):
11177
11178    </p>
11179    <blockquote>
11180
11181 If the end of stream is reached (<code>operator void*()</code> on the
11182 stream returns <code>false</code>), the iterator becomes equal to
11183 the <i>end-of-stream</i> iterator value.
11184
11185    </blockquote>
11186    <p>
11187
11188 One possible implementation approach that has been used in practice is
11189 for the iterator to set its <code>in_stream</code> pointer to 0 when
11190 it reaches the end of the stream, just like the default ctor does on
11191 initialization. The problem with this approach is that
11192 the <i>Effects</i> clause for <code>operator++()</code> says the
11193 iterator unconditionally extracts the next value from the stream by
11194 evaluating <code>*in_stream &gt;&gt; value</code>, without checking
11195 for <code>(in_stream == 0)</code>.
11196
11197    </p>
11198    <p>
11199
11200 Conformance to the requirement outlined in the <i>Effects</i> clause
11201 can easily be verified in programs by setting <code>eofbit</code>
11202 or <code>failbit</code> in <code>exceptions()</code> of the associated
11203 stream and attempting to iterate past the end of the stream: each
11204 past-the-end access should trigger an exception. This suggests that
11205 some other, more elaborate technique might be intended.
11206
11207    </p>
11208    <p>
11209
11210 Another approach, one that allows <code>operator++()</code> to attempt
11211 to extract the value even for EOS iterators (just as long
11212 as <code>in_stream</code> is non-0) is for the iterator to maintain a
11213 flag indicating whether it has reached the end of the stream. This
11214 technique would satisfy the presumed requirement implied by
11215 the <i>Effects</i> clause mentioned above, but it isn't supported by
11216 the exposition-only members of the class (no such flag is shown). This
11217 approach is also found in existing practice.
11218
11219    </p>
11220    <p>
11221
11222 The inconsistency between existing implementations raises the question
11223 of whether the intent of the specification is that a non-EOS iterator
11224 that has reached the EOS become a non-EOS one again after the
11225 stream's <code>eofbit</code> flag has been cleared? That is, are the
11226 assertions in the program below expected to pass?
11227
11228    </p>
11229    <blockquote>
11230      <pre>   sstream strm ("1 ");
11231    istream_iterator eos;
11232    istream_iterator it (strm);
11233    int i;
11234    i = *it++
11235    assert (it == eos);
11236    strm.clear ();
11237    strm &lt;&lt; "2 3 ";
11238    assert (it != eos);
11239    i = *++it;
11240    assert (3 == i);
11241      </pre>
11242    </blockquote>
11243    <p>
11244
11245 Or is it intended that once an iterator becomes EOS it stays EOS until
11246 the end of its lifetime?
11247
11248    </p>
11249
11250  <p><i>[
11251 San Francisco:
11252 ]</i></p>
11253
11254
11255 <blockquote>
11256 <p>
11257 We like the direction of the proposed resolution. We're not sure about
11258 the wording, and we need more time to reflect on it,
11259 </p>
11260 <p>
11261 Move to Open. Detlef to rewrite the proposed resolution in such a way
11262 that no reference is made to exposition only members of
11263 <tt>istream_iterator</tt>.
11264 </p>
11265 </blockquote>
11266
11267 <p><i>[
11268 2009-07 Frankfurt:
11269 ]</i></p>
11270
11271
11272 <blockquote>
11273 Move to Ready.
11274 </blockquote>
11275
11276
11277
11278  <p><b>Proposed resolution:</b></p>
11279    <p>
11280
11281 The discussion of this issue on the reflector suggests that the intent
11282 of the standard is for an <code>istreambuf_iterator</code> that has
11283 reached the EOS to remain in the EOS state until the end of its
11284 lifetime. Implementations that permit EOS iterators to return to a
11285 non-EOS state may only do so as an extension, and only as a result of
11286 calling <code>istream_iterator</code> member functions on EOS
11287 iterators whose behavior is in this case undefined.
11288
11289    </p>
11290    <p>
11291
11292 To this end we propose to change 24.6.1 [istream.iterator], p1,
11293 as follows:
11294
11295    </p>
11296    <blockquote>
11297
11298 The result of operator-&gt; on an end<ins>-</ins>of<ins>-</ins>stream
11299 is not defined. For any other iterator value a <code>const T*</code>
11300 is returned.<ins> Invoking <code>operator++()</code> on
11301 an <i>end-of-stream</i> iterator is undefined.</ins> It is impossible
11302 to store things into istream iterators...
11303
11304    </blockquote>
11305    <p>
11306
11307 Add pre/postconditions to the member function descriptions of <code>istream_iterator</code> like so:
11308
11309    </p>
11310    <blockquote>
11311
11312 <pre>istream_iterator();</pre>
11313
11314 <i>Effects</i>: Constructs the <i>end-of-stream</i> iterator.<br>
11315 <ins><i>Postcondition</i>: <code>in_stream == 0</code>.</ins>
11316
11317 <pre>istream_iterator(istream_type &amp;s);</pre>
11318
11319 <i>Effects</i>: Initializes <code>in_stream</code> with &amp;s. value
11320 may be initialized during construction or the first time it is
11321 referenced.<br>
11322 <ins><i>Postcondition</i>: <code>in_stream == &amp;s</code>.</ins>
11323
11324 <pre>istream_iterator(const istream_iterator &amp;x);</pre>
11325
11326 <i>Effects</i>: Constructs a copy of <code>x</code>.<br>
11327 <ins><i>Postcondition</i>: <code>in_stream == x.in_stream</code>.</ins>
11328
11329 <pre>istream_iterator&amp; operator++();</pre>
11330
11331 <ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br>
11332 <i>Effects</i>: <code>*in_stream &gt;&gt; value</code>.
11333
11334 <pre>istream_iterator&amp; operator++(int);</pre>
11335
11336 <ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br>
11337 <i>Effects</i>:
11338    <blockquote><pre>istream_iterator tmp (*this);
11339 *in_stream &gt;&gt; value;
11340 return tmp;
11341      </pre>
11342      </blockquote>
11343    </blockquote>
11344
11345
11346
11347
11348 <hr>
11349 <h3><a name="847"></a>847. string exception safety guarantees</h3>
11350 <p><b>Section:</b> 21.4.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
11351  <b>Submitter:</b> Hervé Brönnimann <b>Opened:</b> 2008-06-05  <b>Last modified:</b> 2009-07-16</p>
11352 <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>
11353 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
11354 <p><b>Discussion:</b></p>
11355 <p>
11356 In March, on comp.lang.c++.moderated, I asked what were the
11357 string exception safety guarantees are, because I cannot see
11358 *any* in the working paper, and any implementation I know offers
11359 the strong exception safety guarantee (string unchanged if a
11360 member throws exception). The closest the current draft comes to
11361 offering any guarantees is 21.4 [basic.string], para 3:
11362 </p>
11363
11364 <blockquote>
11365 The class template <tt>basic_string</tt> conforms to the requirements
11366 for a Sequence Container (23.1.1), for a Reversible Container (23.1),
11367 and for an Allocator-aware container (91). The iterators supported by
11368 <tt>basic_string</tt> are random access iterators (24.1.5).
11369 </blockquote>
11370
11371 <p>
11372 However, the chapter 23 only says, on the topic of exceptions:  23.2 [container.requirements],
11373 para 10:
11374 </p>
11375
11376 <blockquote>
11377 <p>
11378 Unless otherwise specified (see 23.2.2.3 and 23.2.6.4) all container types defined in this clause meet the following
11379 additional requirements:
11380 </p>
11381
11382 <ul>
11383 <li>if an exception is thrown by...</li>
11384 </ul>
11385 </blockquote>
11386
11387 <p>
11388 I take it  as saying that this paragraph has *no* implication on
11389 <tt>std::basic_string</tt>, as <tt>basic_string</tt> isn't defined in Clause 23 and
11390 this paragraph does not define a *requirement* of Sequence
11391 nor Reversible Container, just of the models defined in Clause 23.
11392 In addition, LWG Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#718">718</a> proposes to remove 23.2 [container.requirements], para 3.
11393 </p>
11394
11395 <p>
11396 Finally, the fact that no operation on Traits should throw
11397 exceptions has no bearing, except to suggest (since the only
11398 other throws should be allocation, <tt>out_of_range</tt>, or <tt>length_error</tt>)
11399 that the strong exception guarantee can be achieved.
11400 </p>
11401
11402 <p>
11403 The reaction in that group by Niels Dekker, Martin Sebor, and
11404 Bo Persson, was all that this would be worth an LWG issue.
11405 </p>
11406
11407 <p>
11408 A related issue is that <tt>erase()</tt> does not throw.  This should be
11409 stated somewhere (and again, I don't think that the 23.2 [container.requirements], para 1
11410 applies here).
11411 </p>
11412
11413 <p><i>[
11414 San Francisco:
11415 ]</i></p>
11416
11417
11418 <blockquote>
11419 Implementors will study this to confirm that it is actually possible.
11420 </blockquote>
11421
11422 <p><i>[
11423 Daniel adds 2009-02-14:
11424 ]</i></p>
11425
11426
11427 <blockquote>
11428 The proposed resolution of paper
11429 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2815.html">N2815</a>
11430 interacts with this issue (the paper does not refer to this issue).
11431 </blockquote>
11432
11433 <p><i>[
11434 2009-07 Frankfurt:
11435 ]</i></p>
11436
11437
11438 <blockquote>
11439 Move to Ready.
11440 </blockquote>
11441
11442
11443
11444 <p><b>Proposed resolution:</b></p>
11445 <p>
11446 Add a blanket statement in 21.4.1 [string.require]:
11447 </p>
11448
11449 <blockquote>
11450 <p>
11451 - if any member function or operator of <tt>basic_string&lt;charT, traits, Allocator&gt;</tt>
11452 throws, that function or operator has no effect.
11453 </p>
11454 <p>
11455 - no <tt>erase()</tt> or <tt>pop_back()</tt> function throws.
11456 </p>
11457 </blockquote>
11458
11459 <p>
11460 As far as I can tell, this is achieved by any implementation.  If I made a
11461 mistake and it is not possible to offer this guarantee, then
11462 either state all the functions for which this is possible
11463 (certainly at least <tt>operator+=</tt>, <tt>append</tt>, <tt>assign</tt>, and <tt>insert</tt>),
11464 or add paragraphs to Effects clauses wherever appropriate.
11465 </p>
11466
11467
11468
11469
11470
11471 <hr>
11472 <h3><a name="851"></a>851. simplified array construction</h3>
11473 <p><b>Section:</b> 23.3.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
11474  <b>Submitter:</b> Benjamin Kosnik <b>Opened:</b> 2008-06-05  <b>Last modified:</b> 2009-07-25</p>
11475 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p>
11476 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
11477 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
11478 <p><b>Discussion:</b></p>
11479 <p>
11480 This is an issue that came up on the libstdc++ list, where a
11481 discrepancy between "C" arrays and C++0x's <tt>std::array</tt> was pointed
11482 out.
11483 </p>
11484
11485 <p>
11486 In "C," this array usage is possible:
11487 </p>
11488
11489 <blockquote><pre>int ar[] = {1, 4, 6};
11490 </pre></blockquote>
11491
11492 <p>
11493 But for C++,
11494 </p>
11495
11496 <blockquote><pre>std::array&lt;int&gt; a = { 1, 4, 6 }; // error
11497 </pre></blockquote>
11498
11499 <p>
11500 Instead, the second parameter of the <tt>array</tt> template must be
11501 explicit, like so:
11502 </p>
11503
11504 <blockquote><pre>std::array&lt;int, 3&gt; a = { 1, 4, 6 };
11505 </pre></blockquote>
11506
11507 <p>
11508 Doug Gregor proposes the following solution, that assumes
11509 generalized initializer lists.
11510 </p>
11511
11512 <blockquote><pre>template&lt;typename T, typename... Args&gt;
11513 inline array&lt;T, sizeof...(Args)&gt;
11514 make_array(Args&amp;&amp;... args)
11515 { return { std::forward&lt;Args&gt;(args)... };  }
11516 </pre></blockquote>
11517
11518 <p>
11519 Then, the way to build an <tt>array</tt> from a list of unknown size is:
11520 </p>
11521
11522 <blockquote><pre>auto a = make_array&lt;T&gt;(1, 4, 6);
11523 </pre></blockquote>
11524
11525 <p><i>[
11526 San Francisco:
11527 ]</i></p>
11528
11529
11530 <blockquote>
11531 <p>
11532 Benjamin: Move to Ready?
11533 </p>
11534 <p>
11535 Bjarne: I'm not convinced this is useful enough to add, so I'd like us
11536 to have time to reflect on it.
11537 </p>
11538 <p>
11539 Alisdair: the constraints are wrong, they should be
11540 </p>
11541 <blockquote><pre>template&lt;ValueType T, ValueType... Args&gt;
11542 requires Convertible&lt;Args, T&gt;...
11543 array&lt;T, sizeof...(Args)&gt; make_array(Args&amp;&amp;... args);
11544 </pre></blockquote>
11545 <p>
11546 Alidair: this would be useful if we had a constexpr version.
11547 </p>
11548 <p>
11549 Bjarne: this is probably useful for arrays with a small number of
11550 elements, but it's not clearly useful otherwise.
11551 </p>
11552 <p>
11553 Consensus is to move to Open.
11554 </p>
11555 </blockquote>
11556
11557 <p><i>[
11558 2009-06-07 Daniel adds:
11559 ]</i></p>
11560
11561
11562 <blockquote>
11563 <p>
11564 I suggest a fix and a simplification of the current proposal: Recent
11565 prototyping by
11566 Howard showed, that a fix is required because narrowing conversion
11567 8.5.4 [dcl.init.list]/6 b.3
11568 would severely limit the possible distribution of argument types, e.g.
11569 the expression
11570 <tt>make_array&lt;double&gt;(1, 2.0)</tt> is ill-formed, because the narrowing
11571 happens <em>inside</em> the
11572 function body where no constant expressions exist anymore. Furthermore
11573 given e.g.
11574 </p>
11575 <blockquote><pre>int f();
11576 double g();
11577 </pre></blockquote>
11578 <p>
11579 we probably want to support
11580 </p>
11581 <blockquote><pre>make_array&lt;double&gt;(f(), g());
11582 </pre></blockquote>
11583
11584 <p>
11585 as well. To make this feasible, the currently suggested expansion
11586 </p>
11587
11588 <blockquote><pre>{ std::forward&lt;Args&gt;(args)... }
11589 </pre></blockquote>
11590
11591 <p>
11592 needs to be replaced by
11593 </p>
11594
11595 <blockquote><pre>{ static_cast&lt;T&gt;(std::forward&lt;Args&gt;(args))... }
11596 </pre></blockquote>
11597
11598 <p>
11599 which is safe, because we already ensure convertibility via the
11600 element-wise <tt>Convertible&lt;Args, T&gt;</tt> requirement. Some other fixes are
11601 necessary: The <tt>ValueType</tt> requirement for the function <em>parameters</em>
11602 is invalid, because all lvalue arguments will deduce to an lvalue-reference,
11603 thereby no longer satisfying this requirement.
11604 </p>
11605
11606 <p>
11607 The suggested simplification is to provide a default-computed effective
11608 type for the result array based on common_type and decay, in
11609 unconstrained form:
11610 </p>
11611
11612 <blockquote><pre>template&lt;typename... Args&gt;
11613 array&lt;typename decay&lt;typename common_type&lt;Args...&gt;::type&gt;::type,
11614 sizeof...(Args)&gt;
11615 make_array(Args&amp;&amp;... args);
11616 </pre></blockquote>
11617
11618 <p>
11619 The approach used below is similar to that of <tt>make_pair</tt> and <tt>make_tuple</tt>
11620 using a symbol <tt>C</tt> to represent the decayed common type [Note: Special
11621 handling of <tt>reference_wrapper</tt> types is intentionally <em>not</em> provided, because
11622 our target has so satisfy <tt>ValueType</tt>, thus under the revised proposal only
11623 an all-<tt>reference_wrapper</tt>-arguments would be well-formed and an array of
11624 <tt>reference_wrapper</tt> will be constructed]. I do currently not suggest to
11625 add new concepts reflecting <tt>decay</tt> and <tt>common_type</tt>, but an implementor will
11626 need something like this to succeed. Note that we use a similar fuzziness for
11627 <tt>make_pair</tt> and <tt>make_tuple</tt> currently. This fuzziness is not related to
11628 the currently
11629 missing <tt>Constructible&lt;Vi, Ti&amp;&amp;&gt;</tt> requirement for those functions. The following
11630 proposal fixes that miss for <tt>make_array</tt>. If the corresponding <tt>C</tt> type
11631 deduction is
11632 explicitly wanted for standardization, here the implementation
11633 </p>
11634
11635 <blockquote><pre>auto concept DC&lt;typename... T&gt; {
11636   typename type = typename decay&lt;typename common_type&lt;T...&gt;::type&gt;::type;
11637 }
11638 </pre></blockquote>
11639
11640 <p>
11641 where <tt>C</tt> is identical to <tt>DC&lt;Args...&gt;::type</tt> in the proposed resolution below.
11642 </p>
11643 <p>
11644 I intentionally added no further type relation between type and the concept
11645 template parameters, but instead added this requirement below to make
11646 the specification as transparent as possible. As written this concept is
11647 satisfied, if the corresponding associated type exists.
11648 </p>
11649
11650 <p><b>Suggested Resolution:</b></p>
11651
11652 <ol>
11653 <li>
11654 <p>
11655 Add to the array synopsis in 23.3 [sequences]:
11656 </p>
11657 <blockquote><pre><ins>
11658 template&lt;ReferentType... Args&gt;
11659 requires ValueType&lt;C&gt; &amp;&amp; IdentityOf&lt;Args&gt; &amp;&amp; Constructible&lt;C, Args&amp;&amp;&gt;...
11660 array&lt;C, sizeof...(Args)&gt;
11661 make_array(Args&amp;&amp;... args);
11662 </ins>
11663 </pre></blockquote>
11664 </li>
11665
11666 <li>
11667 <p>
11668 Append after 23.3.1.7 [array.tuple] Tuple interface to class template array
11669 the following new section:
11670 </p>
11671 <blockquote>
11672 <p>
11673 23.4.1.7 Array creation functions [array.creation]
11674 </p>
11675
11676 <pre><ins>
11677 template&lt;ReferentType... Args&gt;
11678 requires ValueType&lt;C&gt; &amp;&amp; IdentityOf&lt;Args&gt; &amp;&amp; Constructible&lt;C, Args&amp;&amp;&gt;...
11679 array&lt;C, sizeof...(Args)&gt;
11680 make_array(Args&amp;&amp;... args);</ins>
11681 </pre>
11682
11683 <blockquote>
11684 <p><ins>
11685 Let <tt>C</tt> be <tt>decay&lt;common_type&lt;Args...&gt;::type&gt;::type</tt>.
11686 </ins></p>
11687 <p>
11688 <ins><i>Returns:</i> an <tt>array&lt;C, sizeof...(Args)&gt;</tt> initialized with
11689 <tt>{ static_cast&lt;C&gt;(std::forward&lt;Args&gt;(args))... }</tt>.
11690 </ins></p>
11691 </blockquote>
11692 </blockquote>
11693
11694 </li>
11695
11696 </ol>
11697
11698 </blockquote>
11699
11700 <p><i>[
11701 2009-07 Frankfurt:
11702 ]</i></p>
11703
11704
11705 <blockquote>
11706 <p>
11707 The proposed resolution uses concepts.
11708 </p>
11709 <p>
11710 Daniel to rewrite the proposed resolution.
11711 </p>
11712 <p>
11713 Leave Open.
11714 </p>
11715 </blockquote>
11716
11717 <p><i>[
11718 2009-07-25 Daniel provides rewritten proposed resolution.
11719 ]</i></p>
11720
11721
11722
11723
11724 <p><b>Proposed resolution:</b></p>
11725
11726 <ol>
11727 <li>
11728 <p>
11729 Add to the array synopsis in 23.3 [sequences]:
11730 </p>
11731
11732 <blockquote><pre><ins>template&lt;class... Args&gt;
11733   array&lt;<i>CT</i>, sizeof...(Args)&gt;
11734   make_array(Args&amp;&amp;... args);</ins>
11735 </pre></blockquote>
11736 </li>
11737
11738 <li>
11739 <p>
11740 Append after 23.3.1.7 [array.tuple] "Tuple interface to class template array" the
11741 following new section:
11742 </p>
11743
11744 <blockquote>
11745 <p>
11746 <ins>XX.X.X.X Array creation functions [array.creation]</ins>
11747 </p>
11748
11749 <pre><ins>
11750 template&lt;class... Args&gt;
11751 array&lt;<i>CT</i>, sizeof...(Args)&gt;
11752 make_array(Args&amp;&amp;... args)
11753 </ins></pre>
11754
11755 <blockquote>
11756 <p>
11757 <ins>Let <i>CT</i> be <tt>decay&lt;common_type&lt;Args...&gt;::type&gt;::type</tt>.</ins>
11758 </p>
11759 <p>
11760 <ins><i>Returns:</i> An <tt>array&lt;<i>CT</i>, sizeof...(Args)&gt;</tt> initialized with <tt>{
11761 static_cast&lt;<i>CT</i>&gt;(std::forward&lt;Args&gt;(args))... }</tt>.</ins>
11762 </p>
11763
11764 <p><ins>
11765 [<i>Example:</i>
11766 </ins></p>
11767 <blockquote><pre><ins>
11768 int i = 0; int&amp; ri = i;
11769 make_array(42u, i, 2.78, ri);
11770 </ins></pre></blockquote>
11771 <p><ins>
11772 returns an array of type
11773 </ins></p>
11774 <blockquote><pre><ins>
11775 array&lt;double, 4&gt;
11776 </ins></pre></blockquote>
11777
11778 <p><ins>
11779 &#8212;<i>end example</i>]</ins>
11780 </p>
11781 </blockquote>
11782 </blockquote>
11783 </li>
11784
11785 </ol>
11786
11787
11788
11789
11790
11791
11792
11793
11794 <hr>
11795 <h3><a name="854"></a>854. <tt>default_delete</tt> converting constructor underspecified</h3>
11796 <p><b>Section:</b> 20.8.9.1.1 [unique.ptr.dltr.dflt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
11797  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-06-18  <b>Last modified:</b> 2009-07-26</p>
11798 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
11799 <p><b>Discussion:</b></p>
11800 <p>
11801 No relationship between <tt>U</tt> and <tt>T</tt> in the converting constructor for <tt>default_delete</tt> template.
11802 </p>
11803 <p>
11804 Requirements: <tt>U*</tt> is convertible to <tt>T*</tt> and <tt>has_virtual_destructor&lt;T&gt;</tt>;
11805 the latter should also become a concept.
11806 </p>
11807 <p>
11808 Rules out cross-casting.
11809 </p>
11810 <p>
11811 The requirements for <tt>unique_ptr</tt> conversions should be the same as those on the deleter.
11812 </p>
11813
11814 <p><i>[
11815 Howard adds 2008-11-26:
11816 ]</i></p>
11817
11818
11819 <blockquote>
11820 <p>
11821 I believe we need to be careful to not outlaw the following use case, and
11822 I believe the current proposed wording
11823 (<tt>requires Convertible&lt;U*, T*&gt; &amp;&amp; HasVirtualDestructor&lt;T&gt;</tt>) does so:
11824 </p>
11825
11826 <blockquote><pre>#include &lt;memory&gt;
11827
11828 int main()
11829 {
11830     std::unique_ptr&lt;int&gt; p1(new int(1));
11831     std::unique_ptr&lt;const int&gt; p2(move(p1));
11832     int i = *p2;
11833 <font color="#c80000">//    *p2 = i;  // should not compile</font>
11834 }
11835 </pre></blockquote>
11836
11837 <p>
11838 I've removed "<tt>&amp;&amp; HasVirtualDestructor&lt;T&gt;</tt>" from the
11839 <tt>requires</tt> clause in the proposed wording.
11840 </p>
11841
11842 </blockquote>
11843
11844 <p><i>[
11845 Post Summit:
11846 ]</i></p>
11847
11848
11849 <blockquote>
11850 <p>
11851 Alisdair: This issue has to stay in review pending a paper constraining
11852 <tt>unique_ptr</tt>.
11853 </p>
11854 <p>
11855 Consensus: We agree with the resolution, but <tt>unique_ptr</tt> needs
11856 to be constrained, too.
11857 </p>
11858 <p>
11859 Recommend Keep in Review.
11860 </p>
11861 </blockquote>
11862
11863 <p><i>[
11864 Batavia (2009-05):
11865 ]</i></p>
11866
11867 <blockquote>
11868 Keep in Review status for the reasons cited.
11869 </blockquote>
11870
11871 <p><i>[
11872 2009-07 Frankfurt:
11873 ]</i></p>
11874
11875
11876 <blockquote>
11877 <p>
11878 The proposed resolution uses concepts. Howard needs to rewrite the
11879 proposed resolution.
11880 </p>
11881 <p>
11882 Move back to Open.
11883 </p>
11884 </blockquote>
11885
11886 <p><i>[
11887 2009-07-26 Howard provided rewritten proposed wording and moved to Review.
11888 ]</i></p>
11889
11890
11891
11892 <p><b>Proposed resolution:</b></p>
11893 <p>
11894 Add after 20.8.9.1.1 [unique.ptr.dltr.dflt], p1:
11895 </p>
11896
11897 <blockquote><pre>template &lt;class U&gt; default_delete(const default_delete&lt;U&gt;&amp; other);
11898 </pre>
11899 <blockquote>
11900 <p>
11901 -1- <i>Effects:</i> ...
11902 </p>
11903 <p><ins>
11904 <i>Remarks:</i> This constructor shall participate in overload resolution
11905 if and only if <tt>U*</tt> is implicitly convertible to <tt>T*</tt>.
11906 </ins></p>
11907 </blockquote>
11908 </blockquote>
11909
11910
11911
11912
11913
11914
11915 <hr>
11916 <h3><a name="857"></a>857. <tt>condition_variable::time_wait</tt> return <tt>bool</tt> error prone</h3>
11917 <p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
11918  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-06-13  <b>Last modified:</b> 2009-07-16</p>
11919 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p>
11920 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
11921 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
11922 <p><b>Discussion:</b></p>
11923 <p>
11924 The meaning of the <tt>bool</tt> returned by <tt>condition_variable::timed_wait</tt> is so
11925 obscure that even the class' designer can't deduce it correctly. Several
11926 people have independently stumbled on this issue.
11927 </p>
11928 <p>
11929 It might be simpler to change the return type to a scoped enum:
11930 </p>
11931 <blockquote><pre>enum class timeout { not_reached, reached };
11932 </pre></blockquote>
11933
11934 <p>
11935 That's the same cost as returning a <tt>bool</tt>, but not subject to mistakes. Your example below would be:
11936 </p>
11937
11938 <blockquote><pre>if (cv.wait_until(lk, time_limit) == timeout::reached )
11939   throw time_out();
11940 </pre></blockquote>
11941
11942 <p><i>[
11943 Beman to supply exact wording.
11944 ]</i></p>
11945
11946
11947 <p><i>[
11948 San Francisco:
11949 ]</i></p>
11950
11951
11952 <blockquote>
11953 <p>
11954 There is concern that the enumeration names are just as confusing, if
11955 not more so, as the bool. You might have awoken because of a signal or a
11956 spurious wakeup, for example.
11957 </p>
11958 <p>
11959 Group feels that this is a defect that needs fixing.
11960 </p>
11961 <p>
11962 Group prefers returning an enum over a void return.
11963 </p>
11964 <p>
11965 Howard to provide wording.
11966 </p>
11967 </blockquote>
11968
11969 <p><i>[
11970 2009-06-14 Beman provided wording.
11971 ]</i></p>
11972
11973
11974 <p><i>[
11975 2009-07 Frankfurt:
11976 ]</i></p>
11977
11978
11979 <blockquote>
11980 Move to Ready.
11981 </blockquote>
11982
11983
11984
11985 <p><b>Proposed resolution:</b></p>
11986 <p>
11987 Change Condition variables 30.5 [thread.condition], Header
11988 condition_variable synopsis, as indicated:
11989 </p>
11990
11991 <blockquote><pre>namespace std {
11992   class condition_variable;
11993   class condition_variable_any;
11994
11995   <ins>enum class cv_status { no_timeout, timeout };</ins>
11996 }
11997 </pre></blockquote>
11998
11999 <p>
12000 Change Class condition_variable 30.5.1 [thread.condition.condvar] as indicated:
12001 </p>
12002
12003 <blockquote><pre>class condition_variable {
12004 public:
12005   ...
12006   template &lt;class Clock, class Duration&gt;
12007     <del>bool</del> <ins>cv_status</ins> wait_until(unique_lock&lt;mutex&gt;&amp; lock,
12008                     const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);
12009   template &lt;class Clock, class Duration, class Predicate&gt;
12010     bool wait_until(unique_lock&lt;mutex&gt;&amp; lock,
12011                     const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time,
12012                     Predicate pred);
12013
12014   template &lt;class Rep, class Period&gt;
12015     <del>bool</del> <ins>cv_status</ins> wait_for(unique_lock&lt;mutex&gt;&amp; lock,
12016                   const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
12017   template &lt;class Rep, class Period, class Predicate&gt;
12018     bool wait_for(unique_lock&lt;mutex&gt;&amp; lock,
12019                   const chrono::duration&lt;Rep, Period&gt;&amp; rel_time,
12020                   Predicate pred);
12021   ...
12022 };
12023
12024 ...
12025
12026 template &lt;class Clock, class Duration&gt;
12027   <del>bool</del> <ins>cv_status</ins> wait_until(unique_lock&lt;mutex&gt;&amp; lock,
12028                   const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);
12029 </pre>
12030 <blockquote>
12031 <p>
12032 -15- <i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either
12033 </p>
12034 <ul>
12035 <li>
12036 no other thread is waiting on this <tt>condition_variable</tt> object or
12037 </li>
12038 <li>
12039 <tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt>
12040 arguments supplied by all concurrently waiting threads (via <tt>wait</tt>,
12041 <tt>wait_for</tt> or <tt>wait_until</tt>.).
12042 </li>
12043 </ul>
12044
12045 <p>
12046 -16- <i>Effects:</i>
12047 </p>
12048
12049 <ul>
12050 <li>
12051 Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
12052 </li>
12053 <li>
12054 When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns.
12055 </li>
12056 <li>
12057 The function will unblock when signaled by a call to <tt>notify_one()</tt>,
12058 a call to <tt>notify_all()</tt>, <del>by
12059 the current time exceeding <tt>abs_time</tt></del> <ins>if <tt>Clock::now() &gt;= abs_time</tt></ins>,
12060 or spuriously.
12061 </li>
12062 <li>
12063 If the function exits via an exception, <tt>lock.unlock()</tt> shall be called prior
12064 to exiting the function scope.
12065 </li>
12066 </ul>
12067
12068 <p>
12069 -17- <i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
12070 </p>
12071
12072 <p>
12073 -18- <i>Returns:</i> <del><tt>Clock::now() &lt; abs_time</tt></del>
12074 <ins><tt>cv_status::timeout</tt> if the function unblocked because <tt>abs_time</tt>
12075 was reached, otherwise <tt>cv_status::no_timeout</tt></ins>.
12076 </p>
12077
12078 <p>
12079 -19- <i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition
12080 cannot be achieved.
12081 </p>
12082
12083 <p>
12084 -20- <i>Error conditions:</i>
12085 </p>
12086
12087 <ul>
12088 <li>
12089 <tt>operation_not_permitted</tt> &#8212; if the thread does not own the lock.
12090 </li>
12091 <li>
12092 equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
12093 </li>
12094 </ul>
12095 </blockquote>
12096
12097 <pre>template &lt;class Rep, class Period&gt;
12098   <del>bool</del> <ins>cv_status</ins> wait_for(unique_lock&lt;mutex&gt;&amp; lock,
12099                 const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
12100
12101 </pre>
12102 <blockquote>
12103 <p>
12104 -21- <i><del>Effects</del> <ins>Returns</ins>:</i>
12105 </p>
12106 <blockquote><pre>wait_until(lock, chrono::monotonic_clock::now() + rel_time)
12107 </pre></blockquote>
12108 <p>
12109 <del>-22- <i>Returns:</i> <tt>false</tt> if the call is returning because the time
12110 duration specified by <tt>rel_time</tt> has elapsed,
12111 otherwise <tt>true</tt>.</del>
12112 </p>
12113
12114 <p><i>[
12115 This part of the wording may conflict with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a> in detail, but does
12116 not do so in spirit.  If both issues are accepted, there is a logical merge.
12117 ]</i></p>
12118
12119 </blockquote>
12120
12121 <pre>template &lt;class Clock, class Duration, class Predicate&gt;
12122   bool wait_until(unique_lock&lt;mutex&gt;&amp; lock,
12123                   const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time,
12124                   Predicate pred);
12125 </pre>
12126
12127 <blockquote>
12128 <p>
12129 -23- <i>Effects:</i>
12130 </p>
12131 <blockquote><pre>while (!pred())
12132   if (<del>!</del>wait_until(lock, abs_time) <ins>== cv_status::timeout</ins>)
12133     return pred();
12134 return true;
12135 </pre></blockquote>
12136
12137 <p>
12138 -24- <i>Returns:</i> <tt>pred()</tt>.
12139 </p>
12140
12141 <p>
12142 -25- [<i>Note:</i>
12143 The returned value indicates whether the predicate evaluates to
12144 <tt>true</tt> regardless of whether the timeout was triggered.
12145 &#8212; <i>end note</i>].
12146 </p>
12147 </blockquote>
12148 </blockquote>
12149
12150 <p>
12151 Change Class condition_variable_any 30.5.2 [thread.condition.condvarany] as indicated:
12152 </p>
12153
12154 <blockquote><pre>class condition_variable_any {
12155 public:
12156   ...
12157   template &lt;class Lock, class Clock, class Duration&gt;
12158     <del>bool</del> <ins>cv_status</ins> wait_until(Lock&amp; lock,
12159                     const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);
12160   template &lt;class Lock, class Clock, class Duration, class Predicate&gt;
12161     bool wait_until(Lock&amp; lock,
12162                     const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time,
12163                     Predicate pred);
12164
12165   template &lt;class Lock, class Rep, class Period&gt;
12166     <del>bool</del> <ins>cv_status</ins> wait_for(Lock&amp; lock,
12167                   const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
12168   template &lt;class Lock, class Rep, class Period, class Predicate&gt;
12169     bool wait_for(Lock&amp; lock,
12170                   const chrono::duration&lt;Rep, Period&gt;&amp; rel_time,
12171                   Predicate pred);
12172   ...
12173 };
12174
12175 ...
12176
12177 template &lt;class Lock, class Clock, class Duration&gt;
12178   <del>bool</del> <ins>cv_status</ins> wait_until(Lock&amp; lock,
12179                   const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time);
12180 </pre>
12181
12182 <blockquote>
12183
12184 <p>
12185 -13- <i>Effects:</i>
12186 </p>
12187
12188 <ul>
12189 <li>
12190 Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
12191 </li>
12192 <li>
12193 When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns.
12194 </li>
12195 <li>
12196 The function will unblock when signaled by a call to <tt>notify_one()</tt>,
12197 a call to <tt>notify_all()</tt>, <del>by
12198 the current time exceeding <tt>abs_time</tt></del> <ins>if <tt>Clock::now() &gt;= abs_time</tt></ins>,
12199 or spuriously.
12200 </li>
12201 <li>
12202 If the function exits via an exception, <tt>lock.unlock()</tt> shall be called prior
12203 to exiting the function scope.
12204 </li>
12205 </ul>
12206
12207 <p>
12208 -14- <i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
12209 </p>
12210
12211 <p>
12212 -15- <i>Returns:</i> <del><tt>Clock::now() &lt; abs_time</tt></del>
12213 <ins><tt>cv_status::timeout</tt> if the function unblocked because <tt>abs_time</tt>
12214 was reached, otherwise <tt>cv_status::no_timeout</tt></ins>.
12215 </p>
12216
12217 <p>
12218 -16- <i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition
12219 cannot be achieved.
12220 </p>
12221
12222 <p>
12223 -17- <i>Error conditions:</i>
12224 </p>
12225
12226 <ul>
12227 <li>
12228 equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
12229 </li>
12230 </ul>
12231 </blockquote>
12232
12233 <pre>template &lt;class Lock, class Rep, class Period&gt;
12234   <del>bool</del> <ins>cv_status</ins> wait_for(Lock&amp; lock,
12235                 const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
12236
12237 </pre>
12238
12239 <blockquote>
12240 <p>
12241 -18- <i><del>Effects</del> <ins>Returns</ins>:</i>
12242 </p>
12243 <blockquote><pre>wait_until(lock, chrono::monotonic_clock::now() + rel_time)
12244 </pre></blockquote>
12245
12246 <p>
12247 <del>-19- <i>Returns:</i> <tt>false</tt> if the call is returning because the time
12248 duration specified by <tt>rel_time</tt> has elapsed,
12249 otherwise <tt>true</tt>.</del>
12250 </p>
12251
12252 <p><i>[
12253 This part of the wording may conflict with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a> in detail, but does
12254 not do so in spirit.  If both issues are accepted, there is a logical merge.
12255 ]</i></p>
12256
12257
12258 </blockquote>
12259
12260 <pre>template &lt;class Lock, class Clock, class Duration, class Predicate&gt;
12261   bool wait_until(Lock&amp; lock,
12262                   const chrono::time_point&lt;Clock, Duration&gt;&amp; <del>rel_time</del> <ins>abs_time</ins>,
12263                   Predicate pred);
12264 </pre>
12265
12266 <blockquote>
12267 <p>
12268 -20- <i>Effects:</i>
12269 </p>
12270 <blockquote><pre>while (!pred())
12271   if (<del>!</del>wait_until(lock, abs_time) <ins>== cv_status::timeout</ins>)
12272     return pred();
12273 return true;
12274 </pre></blockquote>
12275
12276 <p>
12277 -21- <i>Returns:</i> <tt>pred()</tt>.
12278 </p>
12279
12280 <p>
12281 -22- [<i>Note:</i>
12282 The returned value indicates whether the predicate evaluates to
12283 <tt>true</tt> regardless of whether the timeout was triggered.
12284 &#8212; <i>end note</i>].
12285 </p>
12286 </blockquote>
12287
12288 </blockquote>
12289
12290
12291
12292
12293
12294
12295 <hr>
12296 <h3><a name="859"></a>859. Monotonic Clock is Conditionally Supported?</h3>
12297 <p><b>Section:</b> 30.5 [thread.condition] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
12298  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-06-23  <b>Last modified:</b> 2009-07-21</p>
12299 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
12300 <p><b>Discussion:</b></p>
12301
12302 <p>Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#959">959</a>.</p>
12303
12304 <p>
12305 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.html">N2661</a>
12306 says that there is a class named <tt>monotonic_clock</tt>. It also says that this
12307 name may be a synonym for <tt>system_clock</tt>, and that it's conditionally
12308 supported. So the actual requirement is that it can be monotonic or not,
12309 and you can tell by looking at <tt>is_monotonic</tt>, or it might not exist at
12310 all (since it's conditionally supported). Okay, maybe too much
12311 flexibility, but so be it.
12312 </p>
12313 <p>
12314 A problem comes up in the threading specification, where several
12315 variants of <tt>wait_for</tt> explicitly use <tt>monotonic_clock::now()</tt>. What is the
12316 meaning of an effects clause that says
12317 </p>
12318
12319 <blockquote><pre>wait_until(lock, chrono::monotonic_clock::now() + rel_time)
12320 </pre></blockquote>
12321
12322 <p>
12323 when <tt>monotonic_clock</tt> is not required to exist?
12324 </p>
12325
12326 <p><i>[
12327 San Francisco:
12328 ]</i></p>
12329
12330
12331 <blockquote>
12332 <p>
12333 Nick: maybe instead of saying that chrono::monotonic_clock is
12334 conditionally supported, we could say that it's always there, but not
12335 necessarily supported..
12336 </p>
12337 <p>
12338 Beman: I'd prefer a typedef that identifies the best clock to use for
12339 wait_for locks.
12340 </p>
12341 <p>
12342 Tom: combine the two concepts; create a duration clock type, but keep
12343 the is_monotonic test.
12344 </p>
12345 <p>
12346 Howard: if we create a duration_clock type, is it a typedef or an
12347 entirely true type?
12348 </p>
12349 <p>
12350 There was broad preference for a typedef.
12351 </p>
12352 <p>
12353 Move to Open. Howard to provide wording to add a typedef for
12354 duration_clock and to replace all uses of monotonic_clock in function
12355 calls and signatures with duration_clock.
12356 </p>
12357 </blockquote>
12358
12359 <p><i>[
12360 Howard notes post-San Francisco:
12361 ]</i></p>
12362
12363
12364 <blockquote>
12365 <p>
12366 After further thought I do not believe that creating a <tt>duration_clock typedef</tt>
12367 is the best way to proceed.  An implementation may not need to use a
12368 <tt>time_point</tt> to implement the <tt>wait_for</tt> functions.
12369 </p>
12370
12371 <p>
12372 For example, on POSIX systems <tt>sleep_for</tt> can be implemented in terms of
12373 <tt>nanosleep</tt> which takes only a duration in terms of nanoseconds.  The current
12374 working paper does not describe <tt>sleep_for</tt> in terms of <tt>sleep_until</tt>.
12375 And paragraph 2 of 30.2.4 [thread.req.timing] has the words strongly encouraging
12376 implementations to use monotonic clocks for <tt>sleep_for</tt>:
12377 </p>
12378
12379 <blockquote>
12380 2 The member functions whose names end in <tt>_for</tt> take an argument that
12381 specifies a relative time. Implementations should use a monotonic clock to
12382 measure time for these functions.
12383 </blockquote>
12384
12385 <p>
12386 I believe the approach taken in describing the effects of <tt>sleep_for</tt>
12387 and <tt>try_lock_for</tt> is also appropriate for <tt>wait_for</tt>.  I.e. these
12388 are not described in terms of their <tt>_until</tt> variants.
12389 </p>
12390
12391 </blockquote>
12392
12393 <p><i>[
12394 2009-07 Frankfurt:
12395 ]</i></p>
12396
12397
12398 <blockquote>
12399 <p>
12400 Beman will send some suggested wording changes to Howard.
12401 </p>
12402 <p>
12403 Move to Ready.
12404 </p>
12405 </blockquote>
12406
12407 <p><i>[
12408 2009-07-21 Beman added the requested wording changes to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>.
12409 ]</i></p>
12410
12411
12412
12413
12414 <p><b>Proposed resolution:</b></p>
12415 <p>
12416 Change 30.5.1 [thread.condition.condvar], p21-22:
12417 </p>
12418
12419 <blockquote>
12420 <pre>template &lt;class Rep, class Period&gt;
12421   bool wait_for(unique_lock&lt;mutex&gt;&amp; lock,
12422                 const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
12423 </pre>
12424 <blockquote>
12425 <p><ins>
12426 <i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either
12427 </ins></p>
12428 <ul>
12429 <li><ins>no other thread is waiting on this <tt>condition_variable</tt> object or</ins></li>
12430 <li><ins><tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt>
12431 arguments supplied by all concurrently waiting threads (via <tt>wait</tt>,
12432 <tt>wait_for</tt> or <tt>wait_until</tt>).</ins></li>
12433 </ul>
12434 <p>
12435 21 <i>Effects:</i>
12436 </p>
12437 <blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time)</del>
12438 </pre></blockquote>
12439 <ul>
12440 <li><ins>
12441 Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
12442 </ins></li>
12443
12444 <li><ins>
12445 When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns.
12446 </ins></li>
12447
12448 <li><ins>
12449 The function will unblock when signaled by a call to <tt>notify_one()</tt>, a call
12450 to <tt>notify_all()</tt>, by
12451 the elapsed time <tt>rel_time</tt> passing (30.2.4 [thread.req.timing]),
12452 or spuriously.
12453 </ins></li>
12454
12455 <li><ins>
12456 If the function exits via an exception, <tt>lock.unlock()</tt> shall be called
12457 prior to exiting the function scope.
12458 </ins></li>
12459 </ul>
12460
12461 <p><ins>
12462 <i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
12463 </ins></p>
12464
12465
12466 <p>
12467 22 <i>Returns:</i> <tt>false</tt> if the call is returning because the time
12468 duration specified by <tt>rel_time</tt> has elapsed, otherwise <tt>true</tt>.
12469 </p>
12470
12471 <p><i>[
12472 This part of the wording may conflict with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#857">857</a> in detail, but does
12473 not do so in spirit.  If both issues are accepted, there is a logical merge.
12474 ]</i></p>
12475
12476
12477 <p><ins>
12478 <i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition cannot be achieved.
12479 </ins></p>
12480
12481 <p><ins>
12482 <i>Error conditions:</i>
12483 </ins></p>
12484
12485 <ul>
12486 <li><ins>
12487 <tt>operation_not_permitted</tt> -- if the thread does not own the lock.
12488 </ins></li>
12489 <li><ins>
12490 equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
12491 </ins></li>
12492 </ul>
12493
12494 </blockquote>
12495 </blockquote>
12496
12497 <p>
12498 Change 30.5.1 [thread.condition.condvar], p26-p29:
12499 </p>
12500
12501 <blockquote>
12502 <pre>template &lt;class Rep, class Period, class Predicate&gt;
12503   bool wait_for(unique_lock&lt;mutex&gt;&amp; lock,
12504                 const chrono::duration&lt;Rep, Period&gt;&amp; rel_time,
12505                 Predicate pred);
12506 </pre>
12507 <blockquote>
12508 <p><ins>
12509 <i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either
12510 </ins></p>
12511 <ul>
12512 <li><ins>no other thread is waiting on this <tt>condition_variable</tt> object or</ins></li>
12513 <li><ins><tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt>
12514 arguments supplied by all concurrently waiting threads (via <tt>wait</tt>,
12515 <tt>wait_for</tt> or <tt>wait_until</tt>).</ins></li>
12516 </ul>
12517 <p>
12518 <i>26 Effects:</i>
12519 </p>
12520 <blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time, std::move(pred))</del>
12521 </pre>
12522 <ul>
12523 <li><ins>
12524 Executes a loop:  Within the loop the function first evaluates <tt>pred()</tt>
12525 and exits the loop if the result of <tt>pred()</tt> is <tt>true</tt>.
12526 </ins></li>
12527 <li><ins>
12528 Atomically calls <tt>lock.unlock()</tt>
12529 and blocks on <tt>*this</tt>.
12530 </ins></li>
12531 <li><ins>
12532 When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock).
12533 </ins></li>
12534 <li><ins>
12535 The function will unblock when signaled by a call to <tt>notify_one()</tt>, a
12536 call to <tt>notify_all()</tt>, by the elapsed time <tt>rel_time</tt> passing (30.1.4
12537 [thread.req.timing]), or spuriously.
12538 </ins></li>
12539 <li><ins>
12540 If the function exits via an exception, <tt>lock.unlock()</tt> shall be called
12541 prior to exiting the function scope.
12542 </ins></li>
12543 <li><ins>
12544 The loop terminates when <tt>pred()</tt> returns <tt>true</tt> or when the time
12545 duration specified by <tt>rel_time</tt> has elapsed.
12546 </ins></li>
12547 </ul>
12548 </blockquote>
12549
12550 <p>
12551 27 [<i>Note:</i> There is no blocking if <tt>pred()</tt> is initially <tt>true</tt>,
12552 even if the timeout has already expired. <i>-- end note</i>]
12553 </p>
12554
12555 <p><ins>
12556 <i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
12557 </ins></p>
12558
12559 <p>
12560 28 <i>Returns:</i> <tt>pred()</tt>
12561 </p>
12562
12563 <p>
12564 29 [<i>Note:</i> The returned value indicates whether the predicate evaluates to
12565 <tt>true</tt> regardless of whether the timeout was triggered. <i>-- end note</i>]
12566 </p>
12567
12568 <p><ins>
12569 <i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition cannot be achieved.
12570 </ins></p>
12571
12572 <p><ins>
12573 <i>Error conditions:</i>
12574 </ins></p>
12575
12576 <ul>
12577 <li><ins>
12578 <tt>operation_not_permitted</tt> -- if the thread does not own the lock.
12579 </ins></li>
12580 <li><ins>
12581 equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
12582 </ins></li>
12583 </ul>
12584
12585 </blockquote>
12586 </blockquote>
12587
12588 <p>
12589 Change 30.5.2 [thread.condition.condvarany], p18-19:
12590 </p>
12591
12592 <blockquote>
12593 <pre>template &lt;class Lock, class Rep, class Period&gt;
12594   bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
12595 </pre>
12596 <blockquote>
12597 <p>
12598 18 <i>Effects:</i>
12599 </p>
12600 <blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time)</del>
12601 </pre></blockquote>
12602
12603 <ul>
12604 <li><ins>
12605 Atomically calls <tt>lock.unlock()</tt> and blocks on <tt>*this</tt>.
12606 </ins></li>
12607
12608 <li><ins>
12609 When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock) and returns.
12610 </ins></li>
12611
12612 <li><ins>
12613 The function will unblock when signaled by a call to <tt>notify_one()</tt>, a call to
12614 <tt>notify_all()</tt>, by
12615 the elapsed time <tt>rel_time</tt> passing (30.2.4 [thread.req.timing]),
12616 or spuriously.
12617 </ins></li>
12618
12619 <li><ins>
12620 If the function exits via an exception, <tt>lock.unlock()</tt> shall be called
12621 prior to exiting the function scope.
12622 </ins></li>
12623 </ul>
12624
12625 <p><ins>
12626 <i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
12627 </ins></p>
12628
12629 <p>
12630 19 <i>Returns:</i> <tt>false</tt> if the call is returning because the time duration
12631 specified by <tt>rel_time</tt> has elapsed, otherwise <tt>true</tt>.
12632 </p>
12633
12634 <p><ins>
12635 <i>Throws:</i> <tt>std::system_error</tt> when the returned value, effects,
12636 or postcondition cannot be achieved.
12637 </ins></p>
12638
12639 <p><ins>
12640 <i>Error conditions:</i>
12641 </ins></p>
12642
12643 <ul>
12644 <li><ins>
12645 equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
12646 </ins></li>
12647 </ul>
12648 </blockquote>
12649 </blockquote>
12650
12651 <p>
12652 Change 30.5.2 [thread.condition.condvarany], p23-p26:
12653 </p>
12654
12655 <blockquote>
12656 <pre>template &lt;class Lock, class Rep, class Period, class Predicate&gt;
12657   bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time, Predicate pred);
12658 </pre>
12659 <blockquote>
12660 <p><ins>
12661 <i>Precondition:</i> <tt>lock</tt> is locked by the calling thread, and either
12662 </ins></p>
12663 <ul>
12664 <li><ins>no other thread is waiting on this <tt>condition_variable</tt> object or</ins></li>
12665 <li><ins><tt>lock.mutex()</tt> returns the same value for each of the <tt>lock</tt>
12666 arguments supplied by all concurrently waiting threads (via <tt>wait</tt>,
12667 <tt>wait_for</tt> or <tt>wait_until</tt>).</ins></li>
12668 </ul>
12669 <p>
12670 <i>23 Effects:</i>
12671 </p>
12672 <blockquote><pre><del>wait_until(lock, chrono::monotonic_clock::now() + rel_time, std::move(pred))</del>
12673 </pre>
12674 <ul>
12675 <li><ins>
12676 Executes a loop:  Within the loop the function first evaluates <tt>pred()</tt>
12677 and exits the loop if the result of <tt>pred()</tt> is <tt>true</tt>.
12678 </ins></li>
12679 <li><ins>
12680 Atomically calls <tt>lock.unlock()</tt>
12681 and blocks on <tt>*this</tt>.
12682 </ins></li>
12683 <li><ins>
12684 When unblocked, calls <tt>lock.lock()</tt> (possibly blocking on the lock).
12685 </ins></li>
12686 <li><ins>
12687 The function will unblock when signaled by a call to <tt>notify_one()</tt>, a
12688 call to <tt>notify_all()</tt>, by the elapsed time <tt>rel_time</tt> passing (30.1.4
12689 [thread.req.timing]), or spuriously.
12690 </ins></li>
12691 <li><ins>
12692 If the function exits via an exception, <tt>lock.unlock()</tt> shall be called
12693 prior to exiting the function scope.
12694 </ins></li>
12695 <li><ins>
12696 The loop terminates when <tt>pred()</tt> returns <tt>true</tt> or when the time
12697 duration specified by <tt>rel_time</tt> has elapsed.
12698 </ins></li>
12699 </ul>
12700 </blockquote>
12701
12702 <p>
12703 24 [<i>Note:</i> There is no blocking if <tt>pred()</tt> is initially <tt>true</tt>,
12704 even if the timeout has already expired. <i>-- end note</i>]
12705 </p>
12706
12707 <p><ins>
12708 <i>Postcondition:</i> <tt>lock</tt> is locked by the calling thread.
12709 </ins></p>
12710
12711 <p>
12712 25 <i>Returns:</i> <tt>pred()</tt>
12713 </p>
12714
12715 <p>
12716 26 [<i>Note:</i> The returned value indicates whether the predicate evaluates to
12717 <tt>true</tt> regardless of whether the timeout was triggered. <i>-- end note</i>]
12718 </p>
12719
12720 <p><ins>
12721 <i>Throws:</i> <tt>std::system_error</tt> when the effects or postcondition cannot be achieved.
12722 </ins></p>
12723
12724 <p><ins>
12725 <i>Error conditions:</i>
12726 </ins></p>
12727
12728 <ul>
12729 <li><ins>
12730 <tt>operation_not_permitted</tt> -- if the thread does not own the lock.
12731 </ins></li>
12732 <li><ins>
12733 equivalent error condition from <tt>lock.lock()</tt> or <tt>lock.unlock()</tt>.
12734 </ins></li>
12735 </ul>
12736
12737 </blockquote>
12738 </blockquote>
12739
12740
12741
12742
12743
12744
12745
12746 <hr>
12747 <h3><a name="860"></a>860. Floating-Point State</h3>
12748 <p><b>Section:</b> 26 [numerics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
12749  <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-06-23  <b>Last modified:</b> 2009-03-09</p>
12750 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numerics">issues</a> in [numerics].</p>
12751 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
12752 <p><b>Discussion:</b></p>
12753 <p>
12754 There are a number of functions that affect the floating point state.
12755 These function need to be thread-safe, but I'm unsure of the right
12756 approach in the standard, as we inherit them from C.
12757 </p>
12758
12759 <p><i>[
12760 San Francisco:
12761 ]</i></p>
12762
12763
12764 <blockquote>
12765 <p>
12766 Nick: I think we already say that these functions do not introduce data
12767 races; see 17.6.5.6/20
12768 </p>
12769 <p>
12770 Pete: there's more to it than not introducing data races; are these
12771 states maintained per thread?
12772 </p>
12773 <p>
12774 Howard: 21.5/14 says that strtok and strerror are not required to avoid
12775 data races, and 20.9/2 says the same about asctime, gmtime, ctime, and
12776 gmtime.
12777 </p>
12778 <p>
12779 Nick: POSIX has a list of not-safe functions. All other functions are
12780 implicitly thread safe.
12781 </p>
12782 <p>
12783 Lawrence is to form a group between meetings to attack this issue. Nick
12784 and Tom volunteered to work with Lawrence.
12785 </p>
12786 <p>
12787 Move to Open.
12788 </p>
12789 </blockquote>
12790
12791 <p><i>[
12792 Post Summit:
12793 ]</i></p>
12794
12795
12796 <blockquote>
12797 <p>
12798 Hans: Sane oses seem ok. Sensible thing is implementable and makes sense.
12799 </p>
12800 <p>
12801 Nick: Default wording seems to cover this? Hole in POSIX, these
12802 functions need to be added to list of thread-unsafe functions.
12803 </p>
12804 <p>
12805 Lawrence: Not sufficient, not "thread-safe" per our definition, but
12806 think of state as a thread-local variable. Need something like "these
12807 functions only affect state in the current thread."
12808 </p>
12809 <p>
12810 Hans: Suggest the following wording: "The floating point environment is
12811 maintained per-thread."
12812 </p>
12813 <p>
12814 Walter: Any other examples of state being thread safe that are not
12815 already covered elsewhere?
12816 </p>
12817 <p>
12818 Have thread unsafe functions paper which needs to be updated. Should
12819 just fold in 26.3 [cfenv] functions.
12820 </p>
12821 <p>
12822 Recommend Open. Lawrence instead suggests leaving it open until we have
12823 suitable wording that may or may not include the thread local
12824 commentary.
12825 </p>
12826 </blockquote>
12827
12828
12829 <p><b>Proposed resolution:</b></p>
12830 <p>
12831 </p>
12832
12833
12834
12835
12836
12837 <hr>
12838 <h3><a name="861"></a>861. Incomplete specification of EqualityComparable for std::forward_list</h3>
12839 <p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
12840  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-06-24  <b>Last modified:</b> 2009-07-26</p>
12841 <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>
12842 <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>
12843 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
12844 <p><b>Discussion:</b></p>
12845 <p>
12846 Table 89, Container requirements, defines <tt>operator==</tt> in terms of the container
12847 member function <tt>size()</tt> and the algorithm <tt>std::equal</tt>:
12848 </p>
12849
12850 <blockquote>
12851 <tt>==</tt> is an equivalence relation. <tt>a.size() == b.size() &amp;&amp;
12852 equal(a.begin(), a.end(), b.begin()</tt>
12853 </blockquote>
12854
12855 <p>
12856 The new container <tt>forward_list</tt> does not provide a <tt>size</tt> member function
12857 by design but does provide <tt>operator==</tt> and <tt>operator!=</tt> without specifying it's semantic.
12858 </p>
12859 <p>
12860 Other parts of the (sequence) container requirements do also depend on
12861 <tt>size()</tt>, e.g. <tt>empty()</tt>
12862 or <tt>clear()</tt>, but this issue explicitly attempts to solve the missing
12863 <tt>EqualityComparable</tt> specification,
12864 because of the special design choices of <tt>forward_list</tt>.
12865 </p>
12866 <p>
12867 I propose to apply one of the following resolutions, which are described as:
12868 </p>
12869
12870 <ol type="A">
12871 <li>
12872 Provide a definition, which is optimal for this special container without
12873 previous size test. This choice prevents two <tt>O(N)</tt> calls of <tt>std::distance()</tt>
12874 with the corresponding container ranges and instead uses a special
12875 <tt>equals</tt> implementation which takes two container ranges instead of 1 1/2.
12876 </li>
12877 <li>
12878 The simple fix where the usual test is adapted such that <tt>size()</tt> is replaced
12879 by <tt>distance</tt> with corresponding performance disadvantages.
12880 </li>
12881 </ol>
12882 <p>
12883 Both proposal choices are discussed, the preferred choice of the author is
12884 to apply (A).
12885 </p>
12886
12887 <p><i>[
12888 San Francisco:
12889 ]</i></p>
12890
12891
12892 <blockquote>
12893 <p>
12894 There's an Option C: change the requirements table to use distance().
12895 </p>
12896 <p>
12897 LWG found Option C acceptable.
12898 </p>
12899 <p>
12900 Martin will draft the wording for Option C.
12901 </p>
12902 </blockquote>
12903
12904 <p><i>[
12905 post San Francisco:
12906 ]</i></p>
12907
12908
12909 <blockquote>
12910 Martin provided wording for Option C.
12911 </blockquote>
12912
12913 <p><i>[
12914 2009-07 Frankfurt
12915 ]</i></p>
12916
12917
12918 <blockquote>
12919 <p>
12920 Other operational semantics (see, for example, Tables 82 and 83) are
12921 written in terms of a container's size() member. Daniel to update
12922 proposed resolution C.
12923 </p>
12924 <p><i>[
12925 Howard: Commented out options A and B.
12926 ]</i></p>
12927
12928 </blockquote>
12929
12930 <p><i>[
12931 2009-07-26 Daniel updated proposed resolution C.
12932 ]</i></p>
12933
12934
12935
12936
12937 <p><b>Proposed resolution:</b></p>
12938
12939
12940 <p>
12941 Option (C):
12942 </p>
12943 <blockquote>
12944
12945 <p><i>[
12946 The changes are relative to
12947 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>
12948 but concept-free.
12949 ]</i></p>
12950
12951
12952 <ol>
12953 <li>
12954 <p>
12955 In 23.2.1 [container.requirements.general] change Table 80 -- Container requirements as indicated:
12956 </p>
12957
12958 <ol type="a">
12959 <li>
12960 <p>
12961 Change the text in the Assertion/note column in the row for "<tt>X u</tt>;"
12962 as follows:
12963 </p>
12964
12965 <blockquote>
12966 post: <tt>u.<del>size() == 0</del><ins>empty() == true</ins></tt>
12967 </blockquote>
12968 </li>
12969
12970 <li>
12971 <p>
12972 Change the text in the Assertion/note column in the row for "<tt>X();</tt>"
12973 as follows:
12974 </p>
12975
12976 <blockquote>
12977 <tt>X().<del>size() == 0</del><ins>empty() == true</ins></tt>
12978 </blockquote>
12979 </li>
12980
12981 <li>
12982 <p>
12983 Change the text in the Operational Semantics column in the row for
12984 "<tt>a == b</tt>" as follows:
12985 </p>
12986 <blockquote>
12987 <tt>==</tt> is an equivalence relation.
12988 <tt><del>a.size()</del><ins>distance(a.begin(), a.end())</ins> ==
12989    <del>b.size()</del><ins>distance(b.begin(), b.end())</ins> &amp;&amp;
12990 equal(a.begin(), a.end(), b.begin())</tt>
12991 </blockquote>
12992 </li>
12993
12994 <li>
12995 <p>
12996 Change the text in the Operational Semantics column in the row for
12997 "<tt>a.size()</tt>" as follows:
12998 </p>
12999
13000 <blockquote>
13001 <tt><del>a.end() - a.begin()</del><ins>distance(a.begin(), a.end())</ins></tt>
13002 </blockquote>
13003 </li>
13004
13005 <li>
13006 <p>
13007 Change the text in the Operational Semantics column in the row for
13008 "<tt>a.max_size()</tt>" as follows:
13009 </p>
13010
13011 <blockquote>
13012 <tt><del>size()</del><ins>distance(begin(), end())</ins></tt> of the largest
13013 possible container
13014 </blockquote>
13015 </li>
13016
13017 <li>
13018 <p>
13019 Change the text in the Operational Semantics column in the row for
13020 "<tt>a.empty()</tt>" as follows:
13021 </p>
13022
13023 <blockquote>
13024 <tt><del>a.size() == 0</del><ins>a.begin() == a.end()</ins></tt>
13025 </blockquote>
13026 </li>
13027 </ol>
13028 </li>
13029
13030 <li>
13031 <p>
13032 In 23.2.1 [container.requirements.general] change Table 82 -- Allocator-aware container requirements as indicated:
13033 </p>
13034
13035 <ol type="a">
13036 <li>
13037 <p>
13038 Change the text in the Assertion/note column in the row for "<tt>X() /
13039 X u;</tt>" as follows:
13040 </p>
13041
13042 <blockquote>
13043 <i>Requires:</i> <tt>A</tt> is <tt>DefaultConstructible</tt> post: <tt><del>u.size() ==
13044 0</del><ins>u.empty() == true</ins></tt>, <tt>get_allocator() == A()</tt>
13045 </blockquote>
13046 </li>
13047
13048 <li>
13049 <p>
13050 Change the text in the Assertion/note column in the row for "<tt>X(m) /
13051 X u(m);</tt>" as follows:
13052 </p>
13053
13054 <blockquote>
13055 post: <tt><del>u.size() == 0</del><ins>u.empty() == true</ins>,
13056 get_allocator() == m</tt>
13057 </blockquote>
13058 </li>
13059 </ol>
13060 </li>
13061
13062 <li>
13063 <p>
13064 In 23.2.3 [sequence.reqmts] change Table 83 -- Sequence container requirements as indicated:
13065 </p>
13066
13067 <ol type="a">
13068 <li>
13069 <p>
13070 Change the text in the Assertion/note column in the row for "<tt>X(n,
13071 t) / X a(n, t)</tt>" as follows:
13072 </p>
13073
13074 <blockquote>
13075 post: <tt><del>size()</del><ins>distance(begin(), end())</ins> == n [..]</tt>
13076 </blockquote>
13077 </li>
13078
13079 <li>
13080 <p>
13081 Change the text in the Assertion/note column in the row for "<tt>X(i,
13082 j) / X a(i, j)</tt>" as follows:
13083 </p>
13084
13085 <blockquote>
13086 [..] post: <del><tt>size() ==</tt> distance between <tt>i</tt> and
13087 <tt>j</tt></del><ins><tt>distance(begin(), end()) == distance(i, j)</tt></ins> [..]
13088 </blockquote>
13089 </li>
13090
13091 <li>
13092 <p>
13093 Change the text in the Assertion/note column in the row for
13094 "<tt>a.clear()</tt>" as follows:
13095 </p>
13096 <blockquote>
13097 <tt><ins>a.</ins>erase(<ins>a.</ins>begin(), <ins>a.</ins>end())</tt> post:
13098 <tt><del>size() == 0</del><ins>a.empty() == true</ins></tt>
13099 </blockquote>
13100 </li>
13101 </ol>
13102 </li>
13103
13104 <li>
13105 <p>
13106 In 23.2.4 [associative.reqmts] change Table 85 -- Associative container requirements as indicated:
13107 </p>
13108
13109 <p><i>[
13110 Not every occurrence of <tt>size()</tt> was replaced, because all current
13111 associative containers
13112 have a <tt>size</tt>. The following changes ensure consistency regarding the
13113 semantics of "<tt>erase</tt>"
13114 for all tables and adds some missing objects
13115 ]</i></p>
13116
13117
13118 <ol type="a">
13119 <li>
13120 <p>
13121 Change the text in the Complexity column in the row for
13122 "<tt>a.insert(i, j)</tt>" as follows:
13123 </p>
13124 <blockquote>
13125 <tt>N log(<ins>a.</ins>size() + N)</tt> <del>(<tt>N</tt> is the distance from <tt>i</tt> to
13126 <tt>j</tt>)</del><ins> where <tt>N == distance(i, j)</tt></ins>
13127 </blockquote>
13128 </li>
13129
13130 <li>
13131 <p>
13132 Change the text in the Complexity column in the row for
13133 "<tt>a.erase(k)</tt>" as follows:
13134 </p>
13135 <blockquote>
13136 <tt>log(<ins>a.</ins>size()) + <ins>a.</ins>count(k)</tt>
13137 </blockquote>
13138 </li>
13139
13140 <li>
13141 <p>
13142 Change the text in the Complexity column in the row for
13143 "<tt>a.erase(q1, q2)</tt>" as follows:
13144 </p>
13145
13146 <blockquote>
13147 <tt>log(<ins>a.</ins>size()) + N</tt> where <tt>N</tt> <del>is the distance from <tt>q1</tt>
13148 to <tt>q2</tt></del>
13149    <ins><tt>== distance(q1, q2)</tt></ins>.
13150 </blockquote>
13151 </li>
13152
13153 <li>
13154 <p>
13155 Change the text in the Assertion/note column in the row for
13156 "<tt>a.clear()</tt>" as follows:
13157 </p>
13158
13159 <blockquote>
13160 <tt><ins>a.</ins>erase(a.begin(),a.end())</tt> post: <tt><del>size() ==
13161 0</del><ins>a.empty() == true</ins></tt>
13162 </blockquote>
13163 </li>
13164
13165 <li>
13166 <p>
13167 Change the text in the Complexity column in the row for "<tt>a.clear()</tt>"
13168 as follows:
13169 </p>
13170
13171 <blockquote>
13172 linear in <tt><ins>a.</ins>size()</tt>
13173 </blockquote>
13174 </li>
13175
13176 <li>
13177 <p>
13178 Change the text in the Complexity column in the row for
13179 "<tt>a.count(k)</tt>" as follows:
13180 </p>
13181
13182 <blockquote>
13183 <tt>log(<ins>a.</ins>size()) + <ins>a.</ins>count(k)</tt>
13184 </blockquote>
13185 </li>
13186 </ol>
13187 </li>
13188
13189 <li>
13190 <p>
13191 In 23.2.5 [unord.req] change Table 87 -- Unordered associative container requirements as indicated:
13192 </p>
13193 <p><i>[
13194 The same rational as for Table 85 applies here
13195 ]</i></p>
13196
13197
13198 <ol type="a">
13199 <li>
13200 <p>
13201 Change the text in the Assertion/note column in the row for
13202 "<tt>a.clear()</tt>" as follows:
13203 </p>
13204
13205 <blockquote>
13206 [..] Post: <tt>a.<del>size() == 0</del><ins>empty() == true</ins></tt>
13207 </blockquote>
13208 </li>
13209 </ol>
13210 </li>
13211 </ol>
13212
13213
13214 </blockquote>
13215
13216
13217
13218
13219
13220 <hr>
13221 <h3><a name="865"></a>865. More algorithms that throw away information</h3>
13222 <p><b>Section:</b> 25.4.6 [alg.fill], 25.4.7 [alg.generate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
13223  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-07-13  <b>Last modified:</b> 2009-07-25</p>
13224 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
13225 <p><b>Discussion:</b></p>
13226 <p>
13227 In regard to library defect <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a> I found some more algorithms which
13228 unnecessarily throw away information. These are typically algorithms,
13229 which sequentially write into an <tt>OutputIterator</tt>, but do not return the
13230 final value of this output iterator. These cases are:
13231 </p>
13232
13233 <ol>
13234 <li>
13235 <pre>template&lt;class OutputIterator, class Size, class T&gt;
13236 void fill_n(OutputIterator first, Size n, const T&amp; value);</pre></li>
13237
13238 <li>
13239 <pre>template&lt;class OutputIterator, class Size, class Generator&gt;
13240 void generate_n(OutputIterator first, Size n, Generator gen);</pre></li>
13241 </ol>
13242 <p>
13243 In both cases the minimum requirements on the iterator are
13244 <tt>OutputIterator</tt>, which means according to the requirements of
13245 24.2.3 [output.iterators]/2 that only single-pass iterations are guaranteed.
13246 So, if users of <tt>fill_n</tt> and <tt>generate_n</tt> have *only* an <tt>OutputIterator</tt>
13247 available, they have no chance to continue pushing further values
13248 into it, which seems to be a severe limitation to me.
13249 </p>
13250
13251 <p><i>[
13252 Post Summit Daniel "conceptualized" the wording.
13253 ]</i></p>
13254
13255
13256 <p><i>[
13257 Batavia (2009-05):
13258 ]</i></p>
13259
13260 <blockquote>
13261 <p>
13262 Alisdair likes the idea, but has concerns about the specific wording
13263 about the returns clauses.
13264 </p>
13265 <p>
13266 Alan notes this is a feature request.
13267 </p>
13268 <p>
13269 Bill notes we have made similar changes to other algorithms.
13270 </p>
13271 <p>
13272 Move to Open.
13273 </p>
13274 </blockquote>
13275
13276 <p><i>[
13277 2009-07 Frankfurt
13278 ]</i></p>
13279
13280
13281 <blockquote>
13282 We have a consensus for moving forward on this issue, but Daniel needs
13283 to deconceptify it.
13284 </blockquote>
13285
13286 <p><i>[
13287 2009-07-25 Daniel provided non-concepts wording.
13288 ]</i></p>
13289
13290
13291
13292
13293 <p><b>Proposed resolution:</b></p>
13294
13295 <ol>
13296 <li>
13297 <p>
13298 Replace the current declaration of <tt>fill_n</tt> in 25 [algorithms]/2, header
13299 <tt>&lt;algorithm&gt;</tt> synopsis and in 25.4.6 [alg.fill] by
13300 </p>
13301
13302 <blockquote><pre>template&lt;class OutputIterator, class Size, class T&gt;
13303   <del>void</del><ins>OutputIterator</ins> fill_n(OutputIterator first, Size n, const T&amp; value);
13304 </pre></blockquote>
13305
13306 <p>
13307 Just after the effects clause add a new returns clause saying:
13308 </p>
13309
13310 <blockquote>
13311 <ins><i>Returns:</i> For <tt>fill_n</tt> and positive <tt>n</tt>, returns <tt>first + n</tt>. Otherwise
13312 returns <tt>first</tt> for <tt>fill_n</tt>.</ins>
13313 </blockquote>
13314 </li>
13315
13316 <li>
13317 <p>
13318 Replace the current declaration of <tt>generate_n</tt> in 25 [algorithms]/2,
13319 header <tt>&lt;algorithm&gt;</tt> synopsis and in 25.4.7 [alg.generate] by
13320 </p>
13321
13322 <blockquote><pre>template&lt;class OutputIterator, class Size, class Generator&gt;
13323   <del>void</del><ins>OutputIterator</ins> generate_n(OutputIterator first, Size n, Generator gen);
13324 </pre></blockquote>
13325
13326 <p>
13327 Just after the effects clause add a new returns clause saying:
13328 </p>
13329
13330 <blockquote>
13331 <ins>For <tt>generate_n</tt> and positive <tt>n</tt>, returns <tt>first + n</tt>. Otherwise
13332 returns <tt>first</tt> for <tt>generate_n</tt>.</ins>
13333 </blockquote>
13334 </li>
13335 </ol>
13336
13337
13338
13339
13340
13341
13342
13343 <hr>
13344 <h3><a name="868"></a>868. default construction and value-initialization</h3>
13345 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
13346  <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-07-22  <b>Last modified:</b> 2009-07-19</p>
13347 <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>
13348 <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>
13349 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
13350 <p><b>Discussion:</b></p>
13351 <p>
13352 The term "default constructed" is often used in wording that predates
13353 the introduction of the concept of value-initialization. In a few such
13354 places the concept of value-initialization is more correct than the
13355 current wording (for example when the type involved can be a built-in)
13356 so a replacement is in order. Two of such places are already covered by
13357 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#867">867</a>. This issue deliberately addresses the hopefully
13358 non-controversial changes in the attempt of being approved more quickly.
13359 A few other occurrences (for example in <tt>std::tuple</tt>,
13360 <tt>std::reverse_iterator</tt> and <tt>std::move_iterator</tt>) are left to separate
13361 issues. For <tt>std::reverse_iterator</tt>, see also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#408">408</a>. This issue is
13362 related with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>.
13363 </p>
13364
13365 <p><i>[
13366 San Francisco:
13367 ]</i></p>
13368
13369
13370 <blockquote>
13371 <p>
13372 The list provided in the proposed resolution is not complete. James
13373 Dennett will review the library and provide a complete list and will
13374 double-check the vocabulary.
13375 </p>
13376 <p>
13377 This issue relates to Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#886">886</a> tuple construction
13378 </p>
13379 </blockquote>
13380
13381 <p><i>[
13382 2009-07 Frankfurt
13383 ]</i></p>
13384
13385
13386 <blockquote>
13387 <p>
13388 The proposed resolution is incomplete.
13389 </p>
13390 <p>
13391 Move to Tentatively NAD Future. Howard will contact Ganesh for wording.
13392 If wording is forthcoming, Howard will move it back to Review.
13393 </p>
13394 </blockquote>
13395
13396 <p><i>[
13397 2009-07-18 Ganesh updated the proposed wording.
13398 ]</i></p>
13399
13400
13401 <blockquote>
13402 <p>
13403 Howard:  Moved back to Review.  Note that X [utility.arg.requirements]
13404 refers to a section that is not in the current working paper, but does refer to
13405 a section that we expect to reappear after the de-concepts merge.  This was a
13406 point of confusion we did not recognize when we reviewed this issue in Frankfurt.
13407 </p>
13408 <p>
13409 Howard:  Ganesh also includes a survey of places in the WP surveyed for changes
13410 of this nature and purposefully <em>not</em> treated:
13411 </p>
13412
13413 <blockquote>
13414 <p>
13415 Places where changes are <u>not</u> being
13416 proposed
13417 </p>
13418 <p>
13419 In the following paragraphs, we are not proposing changes because
13420 it's not clear whether we actually prefer value-initialization over
13421 default-initialization (now partially covered by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1012">1012</a>):
13422 </p>
13423 <ul>
13424         <li><p>20.8.9.2.1 [unique.ptr.single.ctor] para 3 e 7</p></li>
13425         <li><p>24.5.1.2.1 [reverse.iter.cons] para 1</p></li>
13426         <li><p>24.5.2.2.1 [move.iter.op.const] para 1</p></li>
13427 </ul>
13428 <p>In the following paragraphs, the expression "default
13429 constructed" need not be changed, because the relevant type does
13430 not depend on a template parameter and has a user-provided
13431 constructor:</p>
13432 <ul>
13433         <li><p> [func.referenceclosure.invoke] para 12, type:
13434         reference_closure</p></li>
13435         <li><p>30.3.1.2 [thread.thread.constr] para 30, type: thread</p></li>
13436         <li><p>30.3.1.5 [thread.thread.member] para 52, type: thread_id</p></li>
13437         <li><p>30.3.2 [thread.thread.this], para 1, type: thread_id</p></li>
13438 </ul>
13439 </blockquote>
13440
13441 </blockquote>
13442
13443
13444
13445 <p><b>Proposed resolution:</b></p>
13446 <p>
13447 Change X [utility.arg.requirements] para 2:
13448 </p>
13449
13450 <blockquote>
13451 In general, a default constructor is
13452 not required. Certain container class member function signatures
13453 specify <del>the default constructor</del><ins>T()</ins>
13454 as a default argument. T() shall be a well-defined expression (8.5)
13455 if one of those signatures is called using the default argument
13456 (8.3.6).
13457 </blockquote>
13458
13459 <p>
13460 Change 23.3.2.1 [deque.cons] para 5:
13461 </p>
13462
13463 <blockquote>
13464 <i>Effects:</i> Constructs a deque with n
13465 <del>default constructed</del><ins>value-initialized</ins>
13466 elements.
13467 </blockquote>
13468
13469 <p>
13470 Change 23.3.2.2 [deque.capacity] para 1:
13471 </p>
13472
13473 <blockquote>
13474 <i>Effects:</i> If sz &lt; size(), equivalent
13475 to erase(begin() + sz, end());. If size() &lt; sz, appends sz -
13476 size() <del>default
13477 constructed</del><ins>value-initialized</ins>
13478 elements to the sequence.
13479 </blockquote>
13480
13481 <p>
13482 Change 23.3.3.1 [forwardlist.cons] para 5:
13483 </p>
13484
13485 <blockquote>
13486 <i>Effects:</i> Constructs a forward_list object with n <del>default
13487 constructed</del><ins>value-initialized</ins>
13488 elements.
13489 </blockquote>
13490
13491 <p>
13492 Change 23.3.3.4 [forwardlist.modifiers] para 21:
13493 </p>
13494
13495 <blockquote>
13496 <i>Effects:</i> [...] For the first signature
13497 the inserted elements are <del>default
13498 constructed</del><ins>value-initialized</ins>,
13499 and for the second signature they are copies of c.
13500 </blockquote>
13501
13502 <p>
13503 Change 23.3.4.1 [list.cons] para 5:
13504 </p>
13505
13506 <blockquote>
13507 <i>Effects:</i> Constructs a list with n <del>default
13508 constructed</del><ins>value-initialized</ins>
13509 elements.
13510 </blockquote>
13511
13512 <p>
13513 Change 23.3.4.2 [list.capacity] para 15:
13514 </p>
13515
13516 <blockquote>
13517 <i>Effects:</i> If sz &lt; size(), equivalent
13518 to list&lt;T&gt;::iterator it = begin(); advance(it, sz); erase(it,
13519 end());. If size() &lt; sz, appends sz - size() <del>default
13520 constructed</del><ins>value-initialized</ins>
13521 elements to the sequence.
13522 </blockquote>
13523
13524 <p>
13525 Change 23.3.6.1 [vector.cons] para 3:
13526 </p>
13527
13528 <blockquote>
13529 <i>Effects:</i> Constructs a vector with n
13530 <del>default constructed</del><ins>value-initialized</ins>
13531 elements.
13532 </blockquote>
13533
13534 <p>
13535 Change 23.3.6.2 [vector.capacity] para 24:
13536 </p>
13537
13538 <blockquote>
13539 <i>Effects:</i> If sz &lt; size(), equivalent
13540 to erase(begin() + sz, end());. If size() &lt; sz, appends sz -
13541 size() <del>default
13542 constructed</del><ins>value-initialized</ins>
13543 elements to the sequence.
13544 </blockquote>
13545
13546
13547
13548
13549
13550
13551 <hr>
13552 <h3><a name="870"></a>870. Do unordered containers not support function pointers for predicate/hasher?</h3>
13553 <p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
13554  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-08-17  <b>Last modified:</b> 2009-07-28</p>
13555 <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>
13556 <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>
13557 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
13558 <p><b>Discussion:</b></p>
13559 <p>
13560 Good ol' associative containers allow both function pointers and
13561 function objects as feasible
13562 comparators, as described in 23.2.4 [associative.reqmts]/2:
13563 </p>
13564
13565 <blockquote>
13566 Each associative container is parameterized on <tt>Key</tt> and an ordering
13567 relation <tt>Compare</tt> that
13568 induces a strict weak ordering (25.3) on elements of Key. [..]. The
13569 object of type <tt>Compare</tt> is
13570 called the comparison object of a container. This comparison object
13571 may be a pointer to
13572 function or an object of a type with an appropriate function call operator.[..]
13573 </blockquote>
13574
13575 <p>
13576 The corresponding wording for unordered containers is not so clear,
13577 but I read it to disallow
13578 function pointers for the hasher and I miss a clear statement for the
13579 equality predicate, see
13580 23.2.5 [unord.req]/3+4+5:
13581 </p>
13582
13583 <blockquote>
13584 <p>
13585 Each unordered associative container is parameterized by <tt>Key</tt>, by a
13586 function object <tt>Hash</tt> that
13587 acts as a hash function for values of type <tt>Key</tt>, and by a binary
13588 predicate <tt>Pred</tt> that induces an
13589 equivalence relation on values of type <tt>Key</tt>.[..]
13590 </p>
13591 <p>
13592 A hash function is a function object that takes a single argument of
13593 type <tt>Key</tt> and returns a
13594 value of type <tt>std::size_t</tt>.
13595 </p>
13596 <p>
13597 Two values <tt>k1</tt> and <tt>k2</tt> of type <tt>Key</tt> are considered equal if the
13598 container's equality function object
13599 returns <tt>true</tt> when passed those values.[..]
13600 </p>
13601 </blockquote>
13602
13603 <p>
13604 and table 97 says in the column "assertion...post-condition" for the
13605 expression X::hasher:
13606 </p>
13607
13608 <blockquote>
13609 <tt>Hash</tt> shall be a unary function object type such that the expression
13610 <tt>hf(k)</tt> has type <tt>std::size_t</tt>.
13611 </blockquote>
13612
13613 <p>
13614 Note that 20.7 [function.objects]/1 defines as "Function objects are
13615 objects with an <tt>operator()</tt> defined.[..]"
13616 </p>
13617 <p>
13618 Does this restriction exist by design or is it an oversight? If an
13619 oversight, I suggest that to apply
13620 the following
13621 </p>
13622
13623 <p><i>[
13624 2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
13625 ]</i></p>
13626
13627
13628
13629
13630 <p><b>Proposed resolution:</b></p>
13631 <p>
13632 In 23.2.5 [unord.req]/3, just after the second sentence which is written as
13633 </p>
13634
13635 <blockquote>
13636 Additionally, <tt>unordered_map</tt> and <tt>unordered_multimap</tt> associate an
13637 arbitrary mapped type <tt>T</tt> with the <tt>Key</tt>.
13638 </blockquote>
13639
13640 <p>
13641 add one further sentence:
13642 </p>
13643
13644 <blockquote>
13645 Both <tt>Hash</tt> and <tt>Pred</tt> may be pointers to function or objects of a type
13646 with an appropriate function call operator.
13647 </blockquote>
13648
13649 <p>
13650 [Note1: Since the detailed requirements for <tt>Pred</tt> and <tt>Hash</tt> are given in
13651 p.4 and p.5, it an alternative resolution
13652 would be to insert a new paragraph just after p.5, which contains the
13653 above proposed sentence]
13654 </p>
13655 <p>
13656 [Note2: I do not propose a change of above quoted element in table 97,
13657 because the mis-usage of the
13658 notion of "function object" seems already present in the standard at
13659 several places, even if it includes
13660 function pointers, see e.g. 25 [algorithms]/7. The important point is
13661 that in those places a statement is
13662 given that the actually used symbol, like "Predicate" applies for
13663 function pointers as well]
13664 </p>
13665
13666
13667 <p><b>Rationale:</b></p>
13668 <p><i>[
13669 San Francisco:
13670 ]</i></p>
13671
13672
13673 <blockquote>
13674 This is fixed by
13675 <a href="" ref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2776.pdf">N2776</a>.
13676 </blockquote>
13677
13678
13679
13680
13681
13682
13683 <hr>
13684 <h3><a name="871"></a>871. Iota's requirements on T are too strong</h3>
13685 <p><b>Section:</b> 26.7.5 [numeric.iota] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
13686  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-08-20  <b>Last modified:</b> 2009-07-30</p>
13687 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
13688 <p><b>Discussion:</b></p>
13689 <p>
13690 According to the recent WP
13691 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>,
13692 26.7.5 [numeric.iota]/1, the requires clause
13693 of <tt>std::iota</tt> says:
13694 </p>
13695
13696 <blockquote>
13697 <tt>T</tt> shall meet the requirements of <tt>CopyConstructible</tt> and <tt>Assignable</tt> types, and
13698 shall be convertible to <tt>ForwardIterator</tt>'s value type.[..]
13699 </blockquote>
13700
13701 <p>
13702 Neither <tt>CopyConstructible</tt> nor <tt>Assignable</tt> is needed, instead <tt>MoveConstructible</tt>
13703 seems to be the correct choice. I guess the current wording resulted as an
13704 artifact from comparing it with similar numerical algorithms like <tt>accumulate</tt>.
13705 </p>
13706
13707 <p>
13708 Note: If this function will be conceptualized, the here proposed
13709 <tt>MoveConstructible</tt>
13710 requirement can be removed, because this is an implied requirement of
13711 function arguments, see
13712 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2710.pdf">N2710</a>/[temp.req.impl]/3, last bullet.
13713 </p>
13714
13715 <p><i>[
13716 post San Francisco:
13717 ]</i></p>
13718
13719
13720 <blockquote>
13721 Issue pulled by author prior to review.
13722 </blockquote>
13723
13724 <p><i>[
13725 2009-07-30 Daniel reopened:
13726 ]</i></p>
13727
13728
13729 <blockquote>
13730 with the absence of concepts, this issue (closed) is valid again and I
13731 suggest to reopen it.
13732 I also revised by proposed resolution based on N2723 wording:
13733 </blockquote>
13734
13735
13736
13737 <p><b>Proposed resolution:</b></p>
13738 <p>
13739 Change the first sentence of 26.7.5 [numeric.iota]/1:
13740 </p>
13741
13742 <blockquote>
13743 <i>Requires:</i> <tt>T</tt> shall <del>meet the requirements of <tt>CopyConstructible</tt> and
13744 <tt>Assignable</tt> types, and shall</del> be
13745 convertible to <tt>ForwardIterator</tt>'s value type. [..]
13746 </blockquote>
13747
13748
13749
13750
13751
13752
13753
13754
13755 <hr>
13756 <h3><a name="872"></a>872. <tt>move_iterator::operator[]</tt> has wrong return type</h3>
13757 <p><b>Section:</b> 24.5.2.2.12 [move.iter.op.index] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
13758  <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2008-08-21  <b>Last modified:</b> 2009-07-28</p>
13759 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
13760 <p><b>Discussion:</b></p>
13761 <p>
13762 <tt>move_iterator</tt>'s <tt>operator[]</tt> is declared as:
13763 </p>
13764
13765 <blockquote><pre>reference operator[](difference_type n) const;
13766 </pre></blockquote>
13767
13768 <p>
13769 This has the same problem that <tt>reverse_iterator</tt>'s <tt>operator[]</tt> used to
13770 have: if the underlying iterator's <tt>operator[]</tt> returns a proxy, the
13771 implicit conversion to <tt>value_type&amp;&amp;</tt> could end up referencing a temporary
13772 that has already been destroyed. This is essentially the same issue that
13773 we dealt with for <tt>reverse_iterator</tt> in DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#386">386</a>.
13774 </p>
13775
13776 <p><i>[
13777 2009-07-28 Reopened by Alisdair.  No longer solved by concepts.
13778 ]</i></p>
13779
13780
13781
13782
13783 <p><b>Proposed resolution:</b></p>
13784 <p>
13785 In 24.5.2.1 [move.iterator] and 24.5.2.2.12 [move.iter.op.index], change the declaration of
13786 <tt>move_iterator</tt>'s <tt>operator[]</tt> to:
13787 </p>
13788
13789 <blockquote><pre><del>reference</del> <ins><i>unspecified</i></ins> operator[](difference_type n) const;
13790 </pre></blockquote>
13791
13792
13793
13794 <p><b>Rationale:</b></p>
13795 <p><i>[
13796 San Francisco:
13797 ]</i></p>
13798
13799
13800 <blockquote>
13801 NAD Editorial, see
13802 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2777.pdf">N2777</a>.
13803 </blockquote>
13804
13805
13806
13807
13808 <hr>
13809 <h3><a name="876"></a>876. <tt>basic_string</tt> access operations should give stronger guarantees</h3>
13810 <p><b>Section:</b> 21.4 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
13811  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-08-22  <b>Last modified:</b> 2009-07-17</p>
13812 <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>
13813 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
13814 <p><b>Discussion:</b></p>
13815 <p>
13816 During the Sophia Antipolis meeting it was decided to split-off some
13817 parts of the
13818 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2647.html">n2647</a>
13819 ("Concurrency modifications for <tt>basic_string</tt>")
13820 proposal into a separate issue, because these weren't actually
13821 concurrency-related. The here proposed changes refer to the recent
13822 update document
13823 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2668.htm">n2668</a>
13824 and attempt to take advantage of the
13825 stricter structural requirements.
13826 </p>
13827 <p>
13828 Indeed there exists some leeway for more guarantees that would be
13829 very useful for programmers, especially if interaction with transactionary
13830 or exception-unaware C API code is important. This would also allow
13831 compilers to take advantage of more performance optimizations, because
13832 more functions can have throw() specifications. This proposal uses the
13833 form of "Throws: Nothing" clauses to reach the same effect, because
13834 there already exists a different issue in progress to clean-up the current
13835 existing "schizophrenia" of the standard in this regard.
13836 </p>
13837 <p>
13838 Due to earlier support for copy-on-write, we find the following
13839 unnecessary limitations for C++0x:
13840 </p>
13841
13842 <ol>
13843 <li>
13844 Missing no-throw guarantees: <tt>data()</tt> and <tt>c_str()</tt> simply return
13845 a pointer to their guts, which is a non-failure operation. This should
13846 be spelled out. It is also noteworthy to mention that the same
13847 guarantees should also be given by the size query functions,
13848 because the combination of pointer to content and the length is
13849 typically needed during interaction with low-level API.
13850 </li>
13851 <li>
13852 Missing complexity guarantees: <tt>data()</tt> and <tt>c_str()</tt> simply return
13853 a pointer to their guts, which is guaranteed O(1). This should be
13854 spelled out.
13855 </li>
13856 <li>
13857 Missing reading access to the terminating character: Only the
13858 const overload of <tt>operator[]</tt> allows reading access to the terminator
13859 char. For more intuitive usage of strings, reading access to this
13860 position should be extended to the non-const case. In contrast
13861 to C++03 this reading access should now be homogeneously
13862 an lvalue access.
13863 </li>
13864 </ol>
13865
13866 <p>
13867 The proposed resolution is split into a main part (A) and a
13868 secondary part (B) (earlier called "Adjunct Adjunct Proposal").
13869 (B) extends (A) by also making access to index position
13870 size() of the at() overloads a no-throw operation. This was
13871 separated, because this part is theoretically observable in
13872 specifically designed test programs.
13873 </p>
13874
13875 <p><i>[
13876 San Francisco:
13877 ]</i></p>
13878
13879
13880 <blockquote>
13881 <p>
13882 We oppose part 1 of the issue but hope to address <tt>size()</tt> in
13883 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#877">877</a>.
13884 </p>
13885 <p>
13886 We do not support part B. 4 of the issue because of the breaking API change.
13887 </p>
13888 <p>
13889 We support part A. 2 of the issue.
13890 </p>
13891 <p>
13892 On support part A. 3 of the issue:
13893 </p>
13894 <blockquote>
13895 Pete's broader comment: now that we know that basic_string will be a
13896 block of contiguous memory, we should just rewrite its specification
13897 with that in mind. The expression of the specification will be simpler
13898 and probably more correct as a result.
13899 </blockquote>
13900 </blockquote>
13901
13902 <p><i>[
13903 2009-07 Frankfurt
13904 ]</i></p>
13905
13906
13907 <blockquote>
13908 <p>
13909 Move proposed resolution A to Ready.
13910 </p>
13911 <p><i>[
13912 Howard: Commented out part B.
13913 ]</i></p>
13914
13915 </blockquote>
13916
13917
13918
13919 <p><b>Proposed resolution:</b></p>
13920 <ol type="A">
13921 <li>
13922 <ol>
13923 <li>
13924 <p>In 21.4.4 [string.capacity], just after p. 1 add a new paragraph:
13925 </p>
13926 <blockquote>
13927 <i>Throws:</i> Nothing.
13928 </blockquote>
13929
13930 </li>
13931 <li>
13932 <p>
13933 In 21.4.5 [string.access] <em>replace</em> p. 1 by the following <em>4</em> paragraghs:
13934 </p>
13935
13936 <blockquote>
13937 <p>
13938 <i>Requires:</i> <tt>pos &#8804; size()</tt>.
13939 </p>
13940 <p>
13941 <i>Returns:</i> If <tt>pos &lt; size()</tt>, returns <tt>*(begin() + pos)</tt>. Otherwise, returns
13942 a reference to a <tt>charT()</tt> that shall not be modified.
13943 </p>
13944 <p>
13945 <i>Throws:</i> Nothing.
13946 </p>
13947 <p>
13948 <i>Complexity:</i> Constant time.
13949 </p>
13950 </blockquote>
13951
13952 </li>
13953 <li>
13954 <p>
13955 In 21.4.7.1 [string.accessors] replace the now <em>common</em> returns
13956 clause of <tt>c_str()</tt> and <tt>data()</tt> by the following <em>three</em> paragraphs:
13957 </p>
13958 <blockquote>
13959 <p>
13960 <i>Returns:</i> A pointer <tt>p</tt> such that <tt>p+i == &amp;operator[](i)</tt> for each <tt>i</tt>
13961 in <tt>[0, size()]</tt>.
13962 </p>
13963 <p>
13964 <i>Throws:</i> Nothing.
13965 </p>
13966 <p>
13967 <i>Complexity:</i> Constant time.
13968 </p>
13969 </blockquote>
13970 </li>
13971 </ol>
13972 </li>
13973
13974 </ol>
13975
13976
13977
13978
13979
13980
13981 <hr>
13982 <h3><a name="879"></a>879. Atomic load const qualification</h3>
13983 <p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
13984  <b>Submitter:</b> Alexander Chemeris <b>Opened:</b> 2008-08-24  <b>Last modified:</b> 2009-07-17</p>
13985 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p>
13986 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p>
13987 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
13988 <p><b>Discussion:</b></p>
13989 <p>
13990 The <tt>atomic_address</tt> type and <tt>atomic&lt;T*&gt;</tt> specialization provide atomic
13991 updates to pointers.  However, the current specification requires
13992 that the types pointer be to non-const objects.  This restriction
13993 is unnecessary and unintended.
13994 </p>
13995
13996 <p><i>[
13997 Summit:
13998 ]</i></p>
13999
14000 <blockquote>
14001 Move to review.  Lawrence will first check with Peter whether the
14002 current examples are sufficient, or whether they need to be expanded to
14003 include all cases.
14004 </blockquote>
14005
14006 <p><i>[
14007 2009-07 Frankfurt
14008 ]</i></p>
14009
14010
14011 <blockquote>
14012 <p>
14013 Lawrence will handle all issues relating to atomics in a single paper.
14014 </p>
14015 <p>
14016 LWG will defer discussion on atomics until that paper appears.
14017 </p>
14018 <p>
14019 Move to Open.
14020 </p>
14021 </blockquote>
14022
14023
14024
14025 <p><b>Proposed resolution:</b></p>
14026 <p>
14027 Add const qualification to the pointer values of the <tt>atomic_address</tt>
14028 and <tt>atomic&lt;T*&gt;</tt> specializations.  E.g.
14029 </p>
14030
14031 <blockquote><pre>typedef struct atomic_address {
14032    void store(<ins>const</ins> void*, memory_order = memory_order_seq_cst) volatile;
14033    void* exchange( <ins>const</ins> void*, memory_order = memory_order_seq_cst) volatile;
14034    bool compare_exchange( <ins>const</ins> void*&amp;, <ins>const</ins> void*,
14035                           memory_order, memory_order) volatile;
14036    bool compare_exchange( <ins>const</ins> void*&amp;, <ins>const</ins> void*,
14037                           memory_order = memory_order_seq_cst ) volatile;
14038    void* operator=(<ins>const</ins> void*) volatile;
14039 } atomic_address;
14040
14041 void atomic_store(volatile atomic_address*, <ins>const</ins> void*);
14042 void atomic_store_explicit(volatile atomic_address*, <ins>const</ins> void*,
14043                           memory_order);
14044 void* atomic_exchange(volatile atomic_address*<ins>, const void*</ins>);
14045 void* atomic_exchange_explicit(volatile atomic_address*, <ins>const</ins> void*,
14046                               memory_order);
14047 bool atomic_compare_exchange(volatile atomic_address*,
14048                             <ins>const</ins> void**, <ins>const</ins> void*);
14049 bool atomic_compare_exchange_explicit(volatile atomic_address*,
14050                                      <ins>const</ins> void**, <ins>const</ins> void*,
14051                                      memory_order, memory_order);
14052 </pre></blockquote>
14053
14054
14055
14056
14057
14058 <hr>
14059 <h3><a name="880"></a>880. Missing atomic exchange parameter</h3>
14060 <p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
14061  <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-08-24  <b>Last modified:</b> 2009-07-17</p>
14062 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p>
14063 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p>
14064 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
14065 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#942">942</a></p>
14066 <p><b>Discussion:</b></p>
14067 <p>
14068 The <tt>atomic_exchange</tt> and <tt>atomic_exchange_explicit</tt> functions seem to
14069 be inconsistently missing parameters.
14070 </p>
14071
14072 <p><i>[
14073 Post Summit:
14074 ]</i></p>
14075
14076
14077 <blockquote>
14078 <p>
14079 Lawrence: Need to write up a list for Pete with details.
14080 </p>
14081 <p>
14082 Detlef: Should not be New, we already talked about in Concurrency group.
14083 </p>
14084 <p>
14085 Recommend Open.
14086 </p>
14087 </blockquote>
14088
14089 <p><i>[
14090 2009-07 Frankfurt
14091 ]</i></p>
14092
14093
14094 <blockquote>
14095 <p>
14096 Lawrence will handle all issues relating to atomics in a single paper.
14097 </p>
14098 <p>
14099 LWG will defer discussion on atomics until that paper appears.
14100 </p>
14101 <p>
14102 Move to Open.
14103 </p>
14104 </blockquote>
14105
14106
14107
14108 <p><b>Proposed resolution:</b></p>
14109 <p>
14110 Add the appropriate parameters.  For example,
14111 </p>
14112
14113 <blockquote><pre>bool atomic_exchange(volatile atomic_bool*<ins>, bool</ins>);
14114 bool atomic_exchange_explicit(volatile atomic_bool*, bool<ins>, memory_order</ins>);
14115 </pre></blockquote>
14116
14117
14118
14119
14120
14121 <hr>
14122 <h3><a name="881"></a>881. shared_ptr conversion issue</h3>
14123 <p><b>Section:</b> 20.8.10.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
14124  <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-08-30  <b>Last modified:</b> 2009-07-17</p>
14125 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared.const">active issues</a> in [util.smartptr.shared.const].</p>
14126 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
14127 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
14128 <p><b>Discussion:</b></p>
14129 <p>
14130 We've changed <tt>shared_ptr&lt;Y&gt;</tt> to not convert to <tt>shared_ptr&lt;T&gt;</tt> when <tt>Y*</tt>
14131 doesn't convert to <tt>T*</tt> by resolving issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>. This only fixed the
14132 converting copy constructor though.
14133 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm">N2351</a>
14134 later added move support, and
14135 the converting move constructor is not constrained.
14136 </p>
14137
14138 <p><i>[
14139 San Francisco:
14140 ]</i></p>
14141
14142
14143 <blockquote>
14144 We might be able to move this to NAD, Editorial once shared_ptr is
14145 conceptualized, but we want to revisit this issue to make sure.
14146 </blockquote>
14147
14148 <p><i>[
14149 2009-07 Frankfurt
14150 ]</i></p>
14151
14152
14153 <blockquote>
14154 <p>
14155 Moved to Ready.
14156 </p>
14157 <p>
14158 This issue now represents the favored format for specifying constrained templates.
14159 </p>
14160 </blockquote>
14161
14162
14163
14164 <p><b>Proposed resolution:</b></p>
14165 <p>
14166 We need to change the Requires clause of the move constructor:
14167 </p>
14168
14169 <blockquote><pre>shared_ptr(shared_ptr&amp;&amp; r);
14170 template&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt;&amp;&amp; r);
14171 </pre>
14172 <blockquote>
14173 <i><del>Requires</del> <ins>Remarks</ins>:</i> <del>For the second constructor <tt>Y*</tt> shall be
14174 convertible to <tt>T*</tt>.</del>
14175 <ins>
14176 The second constructor shall not participate in overload resolution
14177 unless <tt>Y*</tt> is convertible to <tt>T*</tt>.
14178 </ins>
14179 </blockquote>
14180 </blockquote>
14181
14182 <p>
14183 in order to actually make the example in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a> compile
14184 (it now resolves to the move constructor).
14185 </p>
14186
14187
14188
14189
14190
14191
14192 <hr>
14193 <h3><a name="883"></a>883. swap circular definition</h3>
14194 <p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
14195  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-10  <b>Last modified:</b> 2009-07-17</p>
14196 <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>
14197 <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>
14198 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
14199 <p><b>Discussion:</b></p>
14200
14201 <p>
14202 Note in particular that Table 90 "Container Requirements" gives
14203 semantics of <tt>a.swap(b)</tt> as <tt>swap(a,b)</tt>, yet for all
14204 containers we define <tt>swap(a,b)</tt> to call <tt>a.swap(b)</tt> - a
14205 circular definition.
14206 </p>
14207
14208 <p><i>[
14209 San Francisco:
14210 ]</i></p>
14211
14212
14213 <blockquote>
14214 Robert to propose a resolution along the lines of "Postcondition: "a =
14215 b, b = a" This will be a little tricky for the hash containers, since
14216 they don't have <tt>operator==</tt>.
14217 </blockquote>
14218
14219 <p><i>[
14220 Post Summit Anthony Williams provided proposed wording.
14221 ]</i></p>
14222
14223
14224 <p><i>[
14225 2009-07 Frankfurt
14226 ]</i></p>
14227
14228
14229 <blockquote>
14230 Moved to Ready with minor edits (which have been made).
14231 </blockquote>
14232
14233
14234
14235 <p><b>Proposed resolution:</b></p>
14236 <p>
14237 In table 80 in section 23.2.1 [container.requirements.general],
14238 replace the postcondition of <tt>a.swap(b)</tt> with the following:
14239 </p>
14240
14241 <blockquote>
14242 <table border="1">
14243 <caption>Table 80 -- Container requirements</caption>
14244 <tbody><tr>
14245 <th>Expression</th>
14246 <th>Return type</th>
14247 <th>Operational semantics</th>
14248 <th>Assertion/note pre-/post-conidtion</th>
14249 <th>Complexity</th>
14250 </tr>
14251 <tr>
14252 <td>...</td>
14253 <td>...</td>
14254 <td>...</td>
14255 <td>...</td>
14256 <td>...</td>
14257 </tr>
14258 <tr>
14259 <td><tt>a.swap(b);</tt></td>
14260 <td><tt>void</tt></td>
14261 <td>&nbsp;</td>
14262 <td><del><tt>swap(a,b)</tt></del>
14263 <ins>Exchange the contents of <tt>a</tt> and <tt>b</tt>.</ins></td>
14264 <td>(Note A)</td>
14265 </tr>
14266 </tbody></table>
14267 </blockquote>
14268
14269 <p>
14270 Remove the reference to swap from the paragraph following the table.
14271 </p>
14272
14273 <blockquote>
14274 Notes: the algorithms <del><tt>swap()</tt>, </del><tt>equal()</tt> and
14275 <tt>lexicographical_compare()</tt> are defined in Clause 25. ...
14276 </blockquote>
14277
14278
14279
14280
14281
14282 <hr>
14283 <h3><a name="885"></a>885. pair assignment</h3>
14284 <p><b>Section:</b> 20.3.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
14285  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-15  <b>Last modified:</b> 2009-07-17</p>
14286 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</p>
14287 <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>
14288 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
14289 <p><b>Discussion:</b></p>
14290 <blockquote><pre>20.2.3 pairs
14291 Missing assignemnt operator:
14292 template&lt;class U , class V&gt;
14293   requires CopyAssignable&lt;T1, U&gt; &amp;&amp; CopyAssignable&lt;T2, V&gt;
14294     pair&amp; operator=(pair&lt;U , V&gt; const &amp; p );
14295 </pre></blockquote>
14296
14297 <p>
14298 Well, that's interesting. This assignment operator isn't in the
14299 current working paper, either. Perhaps we deemed it acceptable to
14300 build a temporary of type <tt>pair</tt> from <tt>pair&lt;U, V&gt;</tt>, then move-assign
14301 from that temporary?
14302 </p>
14303 <p>
14304 It sounds more like an issue waiting to be opened, unless you want to plug
14305 it now.  As written we risk moving from lvalues.
14306 </p>
14307
14308 <p><i>[
14309 San Francisco:
14310 ]</i></p>
14311
14312
14313 <blockquote>
14314 <p>
14315 Would be NAD if better ctors fixed it.
14316 </p>
14317 <p>
14318 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#811">811</a>.
14319 </p>
14320 </blockquote>
14321
14322 <p><i>[
14323 post San Francisco:
14324 ]</i></p>
14325
14326
14327 <blockquote>
14328 Possibly NAD Editorial, solved by
14329 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>.
14330 </blockquote>
14331
14332 <p><i>[
14333 2009-05-25 Alisdair adds:
14334 ]</i></p>
14335
14336
14337 <blockquote>
14338 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#885">885</a> was something I reported while reviewing the library concepts
14339 documents ahead of San Francisco.  The missing operator was added as part of
14340 the paper adopted at that meeting
14341 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>)
14342 and I can confirm this operator is
14343 present in the current working paper.  I recommend NAD.
14344 </blockquote>
14345
14346 <p><i>[
14347 2009-07 Frankfurt
14348 ]</i></p>
14349
14350
14351 <blockquote>
14352 We agree with the intent, but we need to wait for the dust to settle on concepts.
14353 </blockquote>
14354
14355
14356
14357 <p><b>Proposed resolution:</b></p>
14358 <p>
14359 </p>
14360
14361
14362
14363
14364
14365 <hr>
14366 <h3><a name="886"></a>886. tuple construction</h3>
14367 <p><b>Section:</b> 20.5.2.1 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
14368  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-15  <b>Last modified:</b> 2009-07-17</p>
14369 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.cnstr">active issues</a> in [tuple.cnstr].</p>
14370 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.cnstr">issues</a> in [tuple.cnstr].</p>
14371 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
14372 <p><b>Discussion:</b></p>
14373 <p>
14374 20.5.2.1 [tuple.cnstr]:
14375 </p>
14376 <blockquote>
14377 <i>Effects:</i> Default initializes each element.
14378 </blockquote>
14379
14380 <p>
14381 Could be clarified to state each "non-trivial" element.  Otherwise
14382 we have a conflict with Core deinfition of default initialization -
14383 trivial types do not get initialized (rather than initialization
14384 having no effect)
14385 </p>
14386
14387 <p>
14388 I'm going to punt on this one, because it's not an issue that's
14389 related to concepts. I suggest bringing it to Howard's attention on
14390 the reflector.
14391 </p>
14392
14393 <p><i>[
14394 San Francisco:
14395 ]</i></p>
14396
14397
14398 <blockquote>
14399 <p>
14400 Text in draft doesn't mean anything, changing to "non-trivial" makes it
14401 meaningful.
14402 </p>
14403 <p>
14404 We prefer "value initializes". Present implementations use
14405 value-initialization. Users who don't want value initialization have
14406 alternatives.
14407 </p>
14408 <p>
14409 Request resolution text from Alisdair.
14410 </p>
14411
14412 <p>
14413 This issue relates to Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a> default construction and value-initialization.
14414 </p>
14415 </blockquote>
14416
14417 <p><i>[
14418 2009-05-04 Alisdair provided wording and adds:
14419 ]</i></p>
14420
14421
14422 <blockquote>
14423 <p>
14424 Note: This <em>IS</em> a change of semantic from TR1, although one the room agreed
14425 with during the discussion.  To preserve TR1 semantics, this would have been
14426 worded:
14427 </p>
14428 <blockquote><pre>requires DefaultConstructible&lt;Types&gt;... tuple();
14429 </pre>
14430 <blockquote>
14431 -2-   <i>Effects:</i> Default-initializes each non-trivial element.
14432 </blockquote>
14433 </blockquote>
14434
14435
14436 </blockquote>
14437
14438 <p><i>[
14439 2009-07 Frankfurt
14440 ]</i></p>
14441
14442
14443 <blockquote>
14444 Move to Ready.
14445 </blockquote>
14446
14447
14448
14449 <p><b>Proposed resolution:</b></p>
14450 <p>
14451 Change p2 in Construction 20.5.2.1 [tuple.cnstr]:
14452 </p>
14453
14454 <blockquote><pre>requires DefaultConstructible&lt;Types&gt;... tuple();
14455 </pre>
14456 <blockquote>
14457 <p>
14458 -2- <i>Effects:</i> <del>Default</del> <ins>Value-</ins>initializes each element.
14459 </p>
14460 </blockquote>
14461 </blockquote>
14462
14463
14464
14465
14466
14467
14468 <hr>
14469 <h3><a name="887"></a>887. issue with condition::wait_...</h3>
14470 <p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
14471  <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-09-15  <b>Last modified:</b> 2009-07-26</p>
14472 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p>
14473 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
14474 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
14475 <p><b>Discussion:</b></p>
14476 <p>
14477 The Posix/C++ working group has identified an inconsistency between
14478 Posix and the C++ working draft in that Posix requires the clock to be
14479 identified at creation, whereas C++ permits identifying the clock at the
14480 call to wait.  The latter cannot be implemented with the former.
14481 </p>
14482
14483 <p><i>[
14484 San Francisco:
14485 ]</i></p>
14486
14487
14488 <blockquote>
14489 <p>
14490 Howard recommends NAD with the following explanation:
14491 </p>
14492
14493 <p>
14494 The intent of the current wording is for the <tt>condtion_variable::wait_until</tt>
14495 be able to handle user-defined clocks as well as clocks the system knows about.
14496 This can be done by providing overloads for the known clocks, and another
14497 overload for unknown clocks which synchs to a known clock before waiting.
14498 For example:
14499 </p>
14500
14501 <blockquote><pre>template &lt;class Duration&gt;
14502 bool
14503 condition_variable::wait_until(unique_lock&lt;mutex&gt;&amp; lock,
14504                                const chrono::time_point&lt;chrono::system_clock, Duration&gt;&amp; abs_time)
14505 {
14506     using namespace chrono;
14507     nanoseconds d = __round_up&lt;nanoseconds&gt;(abs_time.time_since_epoch());
14508     __do_timed_wait(lock.mutex()-&gt;native_handle(), time_point&lt;system_clock, nanoseconds&gt;(d));
14509     return system_clock::now() &lt; abs_time;
14510 }
14511
14512 template &lt;class Clock, class Duration&gt;
14513 bool
14514 condition_variable::wait_until(unique_lock&lt;mutex&gt;&amp; lock,
14515                                const chrono::time_point&lt;Clock, Duration&gt;&amp; abs_time)
14516 {
14517     using namespace chrono;
14518     typename Clock::time_point  c_entry = Clock::now();
14519     system_clock::time_point    s_entry = system_clock::now();
14520     nanoseconds dn = __round_up&lt;nanoseconds&gt;(abs_time.time_since_epoch() -
14521                                               c_entry.time_since_epoch());
14522     __do_timed_wait(lock.mutex()-&gt;native_handle(), s_entry + dn);
14523     return Clock::now() &lt; abs_time;
14524 }
14525 </pre></blockquote>
14526
14527 <p>
14528 In the above example, <tt>system_clock</tt> is the only clock which the underlying
14529 condition variable knows how to deal with.  One overload just passes that clock
14530 through.  The second overload (approximately) converts the unknown clock into
14531 a <tt>system_clock  time_point</tt> prior to passing it down to the native
14532 condition variable.
14533 </p>
14534
14535 <p>
14536 On Posix systems vendors are free to add implementation defined constructors which
14537 take a clock.  That clock can be stored in the condition_variable, and converted
14538 to (or not as necessary) as shown above.
14539 </p>
14540
14541 <p>
14542 If an implementation defined constructor takes a clock (for example), then part
14543 of the semantics for that implementation defined ctor might include that a
14544 <tt>wait_until</tt> using a clock other than the one constructed with results
14545 in an error (exceptional condition) instead of a conversion to the stored clock.
14546 Such a design is up to the vendor as once an implementation defined ctor is used,
14547 the vendor is free to specifiy the behavior of waits and/or notifies however
14548 he pleases (when the cv is constructed in an implementation defined manner).
14549 </p>
14550 </blockquote>
14551
14552 <p><i>[
14553 Post Summit:
14554 ]</i></p>
14555
14556
14557 <blockquote>
14558 <p>
14559 "POSIX people will review the proposed NAD resolution at their upcoming NY
14560 meeting.
14561 </p>
14562
14563 <p>
14564 See the minutes at: <a href="http://wiki.dinkumware.com/twiki/bin/view/Posix/POSIX-CppBindingWorkingGroupNewYork2009">http://wiki.dinkumware.com/twiki/bin/view/Posix/POSIX-CppBindingWorkingGroupNewYork2009</a>.
14565 </p>
14566 </blockquote>
14567
14568 <p><i>[
14569 2009-07 Frankfurt
14570 ]</i></p>
14571
14572
14573 <blockquote>
14574 Move to NAD.
14575 </blockquote>
14576
14577 <p><i>[
14578 2009-07-18 Detlef reopens the issue:
14579 ]</i></p>
14580
14581
14582 <blockquote>
14583 <p>
14584 On Friday afternoon in Frankfurt is was decided that 887 is NAD.
14585 This decision was mainly based on a sample implementation presented
14586 by Howard that implemented one clock on top of another.
14587 Unfortunately this implementation doesn't work for the probably most
14588 important case where a system has a monotonic clock and a real-time
14589 clock (or "wall time" clock):
14590 </p>
14591 <p>
14592 If the underlying "system_clock" is a monotonic clock, and
14593 the program waits on the real-time clock, and the real-time clock
14594 is set forward, the wait will unblock too late.
14595 </p>
14596
14597 <p>
14598 If the underlying "system_clock" is a real-time clock, and the
14599 program waits on the monotonic clock, and the real-time clock
14600 is set back, the wait again will unblock too late.
14601 </p>
14602
14603 <p>
14604 Sorry that I didn't remember this on Friday, but it was Friday
14605 afternoon after a busy week...
14606 </p>
14607
14608 <p>
14609 So as the decision was made on a wrong asumption, I propose to re-open
14610 the issue.
14611 </p>
14612 </blockquote>
14613
14614 <p><i>[
14615 2009-07-26 Howard adds:
14616 ]</i></p>
14617
14618
14619 <blockquote>
14620 <p>
14621 Detlef correctly argues that <tt>condition_variable::wait_until</tt> could
14622 return "too late" in the context of clocks being adjusted during the wait.  I agree
14623 with his logic.  But I disagree that this makes this interface unimplementable
14624 on POSIX.
14625 </p>
14626
14627 <p>
14628 The POSIX spec also does not guarantee that <tt>pthread_cond_timedwait</tt> does
14629 not return "too late" when clocks are readjusted during the wait.  Indeed, the
14630 POSIX specification lacks any requirements at all concerning how soon
14631 <tt>pthread_cond_timedwait</tt> returns after a time out.  This is evidently a
14632 QOI issue by the POSIX standard.  Here is a quote of the most relevant normative
14633 text concerning <tt>pthread_cond_timedwait</tt> found
14634 <a href="http://www.unix.org/single_unix_specification/">here</a>.
14635 </p>
14636
14637 <blockquote>
14638 The <tt>pthread_cond_timedwait()</tt> function shall be equivalent to
14639 <tt>pthread_cond_wait()</tt>, except that an error is returned if the absolute
14640 time specified by <tt>abstime</tt> passes (that is, system time equals or exceeds
14641 <tt>abstime</tt>) before the condition <tt>cond</tt> is signaled or broadcasted, or if the
14642 absolute time specified by <tt>abstime</tt> has already been passed at the time
14643 of the call.
14644 </blockquote>
14645
14646 <p>
14647 I.e. the POSIX specification speaks of the error code returned in case of a time
14648 out, but not on the timeliness of that return.
14649 </p>
14650
14651 <p>
14652 Might this simply be an oversight, or minor defect in the POSIX specification?
14653 </p>
14654
14655 <p>
14656 I do not believe so.  This same section goes on to say in <em>non-normative</em>
14657 text:
14658 </p>
14659
14660 <blockquote>
14661 For cases when the system clock is advanced discontinuously by an
14662 operator, it is expected that implementations process any timed wait
14663 expiring at an intervening time as if that time had actually occurred.
14664 </blockquote>
14665
14666 <p>
14667 Here is non-normative wording encouraging the implementation to ignore an advancing
14668 underlying clock and subsequently causing an early (spurious) return.  There is
14669 no wording at all which addresses Detlef's example of a "late return".  With
14670 <tt>pthread_cond_timedwait</tt> this would be caused by setting the system clock
14671 backwards.  It seems reasonable to assume, based on the wording that is already
14672 in the POSIX spec, that again, the discontinuously changed clock would be ignored
14673 by <tt>pthread_cond_timedwait</tt>.
14674 </p>
14675
14676 <p>
14677 A noteworthy difference between <tt>pthread_cond_timedwait</tt> and
14678 <tt>condition_variable::wait_until</tt> is that the POSIX spec appears to
14679 say that <tt>ETIMEDOUT</tt> should be returned if <tt>pthread_cond_timedwait</tt>
14680 returns because of timeout signal, whether or not the system clock was discontinuously
14681 advanced during the wait.  In contrast <tt>condition_variable::wait_until</tt>
14682 always returns:
14683 </p>
14684
14685 <blockquote><pre><tt>Clock::now() &lt; abs_time</tt>
14686 </pre></blockquote>
14687
14688 <p>
14689 That is, the C++ spec requires that the clock be rechecked (detecting discontinuous
14690 adjustments during the wait) at the time of return.  <tt>condition_variable::wait_until</tt>
14691 may indeed return early or late.  But regardless it will return a value
14692 reflecting timeout status at the time of return (even if clocks have been adjusted).
14693 Of course the clock may be adjusted after the return value is computed but before the client has
14694 a chance to read the result of the return.  Thus there are no iron-clad guarantees
14695 here.
14696 </p>
14697
14698 <p>
14699 <tt>condition_variable::wait_until</tt> (and <tt>pthread_cond_timedwait</tt>)
14700 is little more than a convenience function for making sure
14701 <tt>condition_variable::wait</tt> doesn't hang for an unreasonable amount of
14702 time (where the client gets to define "unreasonable").  I do not think it
14703 is in anyone's interest to try to make it into anything more than that.
14704 </p>
14705
14706 <p>
14707 I maintain that this is a useful and flexible specification in the spirit of
14708 C++, and is implementable on POSIX.  The implementation technique described above
14709 is a reasonable approach.  There may also be higher quality approaches.  This
14710 specification, like the POSIX specification, gives a wide latitude for QOI.
14711 </p>
14712
14713 <p>
14714 I continue to recommend NAD, but would not object to a clarifying note regarding
14715 the behavior of <tt>condition_variable::wait_until</tt>.  At the moment, I do
14716 not have good wording for such a note, but welcome suggestions.
14717 </p>
14718
14719 </blockquote>
14720
14721
14722
14723 <p><b>Proposed resolution:</b></p>
14724 <p>
14725 </p>
14726
14727
14728
14729
14730
14731 <hr>
14732 <h3><a name="889"></a>889. thread::id comparisons</h3>
14733 <p><b>Section:</b> 30.3.1.1 [thread.thread.id] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
14734  <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-09-15  <b>Last modified:</b> 2009-07-28</p>
14735 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.id">issues</a> in [thread.thread.id].</p>
14736 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
14737 <p><b>Discussion:</b></p>
14738
14739 <p><b>Addresses UK 324</b></p>
14740
14741 <p>
14742 The <tt>thread::id</tt> type supports the full set of comparison operators.  This
14743 is substantially more than is required for the associative containers that
14744 justified them.  Please place an issue against the threads library.
14745 </p>
14746
14747 <p><i>[
14748 San Francisco:
14749 ]</i></p>
14750
14751
14752 <blockquote>
14753 <p>
14754 Would depend on proposed extension to POSIX, or non-standard extension.
14755 What about hash? POSIX discussing op. POSIX not known to be considering
14756 support needed for hash, op.
14757 </p>
14758 <p>
14759 Group expresses support for putting ids in both unordered and ordered containers.
14760 </p>
14761 </blockquote>
14762
14763 <p><i>[
14764 post San Francisco:
14765 ]</i></p>
14766
14767
14768 <blockquote>
14769 <p>
14770 Howard:  It turns out the current working paper
14771 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
14772 <i>already has</i> <tt>hash&lt;thread::id&gt;</tt>
14773 (20.7 [function.objects], 20.7.17 [unord.hash]).  We simply
14774 overlooked it in the meeting.  It is a good thing we voted in favor of it
14775 (again). :-)
14776 </p>
14777 <p>
14778 Recommend NAD.
14779 </p>
14780
14781 </blockquote>
14782
14783 <p><i>[
14784 Post Summit:
14785 ]</i></p>
14786
14787
14788 <blockquote>
14789 Recommend to close as NAD. For POSIX, see if we need to add a function to
14790 convert <tt>pthread_t</tt> to integer.
14791 </blockquote>
14792
14793 <p><i>[
14794 Post Summit, Alisdair adds:
14795 ]</i></p>
14796
14797
14798 <blockquote>
14799 <p>
14800 The recommendation for LWG-889/UK-324 is NAD, already specified.
14801 </p>
14802 <p>
14803 It is not clear to me that the specification is complete.
14804 </p>
14805 <p>
14806 In particular, the synopsis of <tt>&lt;functional&gt;</tt> in 20.7 [function.objects] does not mention <tt>hash&lt; thread::id
14807 &gt;</tt> nor <tt>hash&lt; error_code &gt;</tt>, although their
14808 existence is implied by 20.7.17 [unord.hash], p1.
14809 </p>
14810 <p>
14811 I am fairly uncomfortable putting the declaration for the
14812 <tt>thread_id</tt> specialization into <tt>&lt;functional&gt;</tt> as
14813 <tt>id</tt> is a nested class inside <tt>std::thread</tt>, so it implies
14814 that <tt>&lt;functional&gt;</tt> would require the definition of the
14815 <tt>thread</tt> class template in order to forward declared
14816 <tt>thread::id</tt> and form this specialization.
14817 </p>
14818 <p>
14819 It seems better to me that the dependency goes the other way around
14820 (<tt>&lt;thread&gt;</tt> will more typically make use of
14821 <tt>&lt;functional&gt;</tt> than vice-versa) and the
14822 <tt>hash&lt;thread::id&gt;</tt> specialization be declared in the
14823 <tt>&lt;thread&gt;</tt> header.
14824 </p>
14825 <p>
14826 I think <tt>hash&lt;error_code&gt;</tt> could go into either
14827 <tt>&lt;system_error&gt;</tt> or <tt>&lt;functional&gt;</tt> and have no
14828 immediate preference either way.  However, it should clearly appear in
14829 the synopsis of one of these two.
14830 </p>
14831 <p>
14832 Recommend moving 889 back to open, and tying in a reference to UK-324.
14833 </p>
14834 </blockquote>
14835
14836 <p><i>[
14837 Batavia (2009-05):
14838 ]</i></p>
14839
14840 <blockquote>
14841 Howard observes that <tt>thread::id</tt> need not be a nested class;
14842 it could be a <tt>typedef</tt> for a more visible type.
14843 </blockquote>
14844
14845 <p><i>[
14846 2009-05-24 Alisdair adds:
14847 ]</i></p>
14848
14849 <blockquote>
14850 I do not believe this is correct.  <tt>thread::id</tt> is explicitly documents as a
14851 nested class, rather than as an unspecified typedef analogous to an
14852 iterator.  If the intent is that this is not implemented as a nested class
14853 (under the as-if freedoms) then this is a novel form of standardese.
14854 </blockquote>
14855
14856 <p><i>[
14857 2009-07 Frankfurt
14858 ]</i></p>
14859
14860
14861 <blockquote>
14862 Decided we want to move hash specialization for thread_id to the thread
14863 header. Alisdair to provide wording.
14864 </blockquote>
14865
14866 <p><i>[
14867 2009-07-28 Alisdair provided wording, moved to Review.
14868 ]</i></p>
14869
14870
14871
14872
14873 <p><b>Proposed resolution:</b></p>
14874 <p>
14875 Add to 30.3 [thread.threads], p1 Header <tt>&lt;thread&gt;</tt> synopsis:
14876 </p>
14877
14878 <blockquote><pre><ins>template &lt;class T&gt; struct hash;
14879 template &lt;&gt; struct hash&lt;thread::id&gt;;</ins>
14880 </pre></blockquote>
14881
14882 <p>
14883 Add template specialization below class definition in 30.3.1.1 [thread.thread.id]
14884 </p>
14885
14886 <blockquote><pre><ins>template &lt;&gt;
14887 struct hash&lt;thread::id&gt; : public unary_function&lt;thread::id, size_t&gt; {
14888    size_t operator()(thread::id val) const;
14889 };</ins>
14890 </pre></blockquote>
14891
14892 <p>
14893 Extend note in p2 30.3.1.1 [thread.thread.id] with second sentence:
14894 </p>
14895
14896 <blockquote>
14897 [<i>Note:</i> Relational operators allow <tt>thread::id</tt> objects to be used
14898 as keys in associative containers.
14899 <ins><tt>hash</tt> template specialization allow <tt>thread::id</tt> objects to be used as keys
14900 in unordered containers.</ins>
14901 &#8212; <i>end note</i>]
14902 </blockquote>
14903
14904 <p>
14905 Add new paragraph to end of 30.3.1.1 [thread.thread.id]
14906 </p>
14907
14908 <blockquote><pre><ins>template &lt;&gt; struct hash&lt;thread::id&gt;;</ins>
14909 </pre>
14910 <blockquote><ins>
14911 An explicit specializations of the class template hash (20.7.17 [unord.hash])
14912 shall be provided for the values of type <tt>thread::id</tt>
14913 suitable for use as keys in unordered associative containers (23.5 [unord]).
14914 </ins></blockquote>
14915 </blockquote>
14916
14917
14918
14919
14920
14921 <hr>
14922 <h3><a name="891"></a>891. std::thread, std::call_once issue</h3>
14923 <p><b>Section:</b> 30.3.1.2 [thread.thread.constr], 30.4.5.2 [thread.once.callonce] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
14924  <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-09-15  <b>Last modified:</b> 2009-07-17</p>
14925 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.constr">active issues</a> in [thread.thread.constr].</p>
14926 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.constr">issues</a> in [thread.thread.constr].</p>
14927 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
14928 <p><b>Discussion:</b></p>
14929 <p>
14930 I notice that the vararg overloads of <tt>std::thread</tt> and <tt>std::call_once</tt>
14931 (N2723 30.3.1.2 [thread.thread.constr] and 30.4.5.2 [thread.once.callonce]) are no longer specified in terms of
14932 <tt>std::bind</tt>; instead, some of the <tt>std::bind</tt> wording has been inlined into
14933 the specification.
14934 </p>
14935 <p>
14936 There are two problems with this.
14937 </p>
14938 <p>
14939 First, the specification (and implementation) in terms of <tt>std::bind</tt> allows, for example:
14940 </p>
14941
14942 <blockquote><pre>std::thread th( f, 1, std::bind( g ) );
14943 </pre></blockquote>
14944
14945 <p>
14946 which executes <tt>f( 1, g() )</tt> in a thread. This can be useful. The
14947 "inlined" formulation changes it to execute <tt>f( 1, bind(g) )</tt> in a thread.
14948 </p>
14949 <p>
14950 Second, assuming that we don't want the above, the specification has copied the wording
14951 </p>
14952
14953 <blockquote>
14954 <tt>INVOKE(func, w1, w2, ..., wN)</tt> (20.6.2) shall be a valid
14955 expression for some values <tt>w1, w2, ..., wN</tt>
14956 </blockquote>
14957
14958 <p>
14959 but this is not needed since we know that our argument list is args; it should simply be
14960 </p>
14961
14962 <blockquote>
14963 <tt>INVOKE(func, args...)</tt> (20.6.2) shall be a valid expression
14964 </blockquote>
14965
14966 <p><i>[
14967 Summit:
14968 ]</i></p>
14969
14970
14971 <blockquote>
14972 Move to open.
14973 </blockquote>
14974
14975 <p><i>[
14976 Post Summit Anthony provided proposed wording.
14977 ]</i></p>
14978
14979
14980 <p><i>[
14981 2009-07 Frankfurt
14982 ]</i></p>
14983
14984
14985 <blockquote>
14986 Leave Open. Await decision for thread variadic constructor.
14987 </blockquote>
14988
14989
14990
14991 <p><b>Proposed resolution:</b></p>
14992 <p>
14993 Change paragraph 4 of 30.3.1.2 [thread.thread.constr] to:
14994 </p>
14995
14996 <blockquote>
14997 <pre>template &lt;class F&gt; explicit thread(F f);
14998 template &lt;class F, class ...Args&gt; thread(F&amp;&amp; f, Args&amp;&amp;... args);
14999 </pre>
15000 <blockquote>
15001 -4- <i>Requires:</i> <tt>F</tt> and each <tt>Ti</tt> in <tt>Args</tt>
15002 shall be <tt>CopyConstructible</tt> if an lvalue and otherwise
15003 <tt>MoveConstructible</tt>. <tt><i>INVOKE</i>(f, <del>w1, w2, ..., wN</del> <ins>args...</ins>)</tt>
15004 (20.6.2) shall be a valid expression<del> for some values <i>w1, w2, ...,
15005 wN</i>, where <tt>N == sizeof...(Args)</tt></del>.
15006 </blockquote>
15007 </blockquote>
15008
15009 <p>
15010 Change paragraph 1 of 30.4.5.2 [thread.once.callonce] to:
15011 </p>
15012
15013 <blockquote><pre>template&lt;class Callable, class ...Args&gt;
15014   void call_once(once_flag&amp; flag, Callable func, Args&amp;&amp;... args);
15015 </pre>
15016 <blockquote>
15017 -1- <i>Requires:</i> The template parameters <tt>Callable&gt;</tt> and each
15018 <tt>Ti</tt> in <tt>Args</tt> shall be <tt>CopyConstructible</tt> if an
15019 lvalue and otherwise <tt>MoveConstructible</tt>. <tt><i>INVOKE</i>(func,
15020 <del>w1, w2, ..., wN</del> <ins>args...</ins>)</tt> (20.6.2) shall be a
15021 valid expression<del> for some values <i>w1, w2, ..., wN</i>, where
15022 <tt>N == sizeof...(Args)</tt></del>.
15023 </blockquote>
15024 </blockquote>
15025
15026
15027
15028
15029
15030 <hr>
15031 <h3><a name="893"></a>893. std::mutex issue</h3>
15032 <p><b>Section:</b> 30.4.1.1 [thread.mutex.class] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
15033  <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-09-15  <b>Last modified:</b> 2009-07-31</p>
15034 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.class">active issues</a> in [thread.mutex.class].</p>
15035 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.class">issues</a> in [thread.mutex.class].</p>
15036 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
15037 <p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#905">905</a></p>
15038 <p><b>Discussion:</b></p>
15039 <p>
15040 30.4.1.1 [thread.mutex.class]/27 (in
15041 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>)
15042 says that the behavior is undefined if:
15043 </p>
15044 <ul>
15045 <li>a thread that owns a <tt>mutex</tt> object calls <tt>lock()</tt> or
15046 <tt>try_lock()</tt> on that object</li>
15047 </ul>
15048 <p>
15049 I don't believe that this is right. Calling <tt>lock()</tt> or <tt>try_lock()</tt> on a
15050 locked <tt>mutex</tt> is well defined in the general case. <tt>try_lock()</tt> is required
15051 to fail and return <tt>false</tt>. <tt>lock()</tt> is required to either throw an
15052 exception (and is allowed to do so if it detects deadlock) or to block
15053 until the <tt>mutex</tt> is free. These general requirements apply regardless of
15054 the current owner of the <tt>mutex</tt>; they should apply even if it's owned by
15055 the current thread.
15056 </p>
15057 <p>
15058 Making double <tt>lock()</tt> undefined behavior probably can be justified (even
15059 though I'd still disagree with the justification), but <tt>try_lock()</tt> on a
15060 locked <tt>mutex</tt> must fail.
15061 </p>
15062
15063 <p><i>[
15064 Summit:
15065 ]</i></p>
15066
15067 <blockquote>
15068 <p>
15069 Move to open. Proposed resolution:
15070 </p>
15071 <ul>
15072 <li>
15073 In 30.4.1 [thread.mutex.requirements] paragraph 12, change the error
15074 condition for <tt>resource_deadlock_would_occur</tt> to: "if the implementation
15075 detects that a deadlock would occur"
15076 </li>
15077 <li>
15078 Strike 30.4.1.1 [thread.mutex.class] paragraph 3 bullet 2 "a thread that owns a mutex object
15079 calls <tt>lock()</tt> or <tt>try_lock()</tt> on that object, or"
15080 </li>
15081 </ul>
15082 </blockquote>
15083
15084 <p><i>[
15085 2009-07 Frankfurt
15086 ]</i></p>
15087
15088
15089 <blockquote>
15090 Move to Review. Alisdair to provide note.
15091 </blockquote>
15092
15093 <p><i>[
15094 2009-07-31 Alisdair provided note.
15095 ]</i></p>
15096
15097
15098
15099 <p><b>Proposed resolution:</b></p>
15100 <p>
15101 In 30.4.1 [thread.mutex.requirements] paragraph 12 change:
15102 </p>
15103
15104 <blockquote>
15105 <ul>
15106 <li>...</li>
15107 <li>
15108 <tt>resource_deadlock_would_occur</tt> -- if the <del>current thread already owns the mutex and is able
15109 to detect it</del> <ins>implementation detects that a deadlock would occur</ins>.
15110 </li>
15111 <li>...</li>
15112 </ul>
15113 </blockquote>
15114
15115 <p>
15116 Strike 30.4.1.1 [thread.mutex.class] paragraph 3 bullet 2:
15117 </p>
15118 <blockquote>
15119 <p>
15120 -3- The behavior of a program is undefined if:
15121 </p>
15122 <ul>
15123 <li>...</li>
15124 <li>
15125 <del>a thread that owns a <tt>mutex</tt> object calls <tt>lock()</tt> or <tt>try_lock()</tt> on that object, or</del>
15126 </li>
15127 <li>...</li>
15128 </ul>
15129 </blockquote>
15130
15131 <p>
15132 Add the following note after p3 30.4.1.1 [thread.mutex.class]
15133 </p>
15134
15135 <blockquote>
15136 [<i>Note:</i> a program may deadlock if the thread that owns a <tt>mutex</tt>
15137 object calls <tt>lock()</tt> or <tt>try_lock()</tt> on that object. If the program can
15138 detect the deadlock, a <tt>resource_deadlock_would_occur</tt> error condition may
15139 be observed. &#8212; <i>end note</i>]
15140 </blockquote>
15141
15142
15143
15144
15145
15146
15147 <hr>
15148 <h3><a name="896"></a>896. Library thread safety issue</h3>
15149 <p><b>Section:</b> 20.8.10.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
15150  <b>Submitter:</b> Hans Boehm <b>Opened:</b> 2008-09-16  <b>Last modified:</b> 2009-07-17</p>
15151 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
15152 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
15153 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
15154 <p><b>Discussion:</b></p>
15155 <p>
15156 It is unclear whether <tt>shared_ptr</tt> is thread-safe in the sense that
15157 multiple threads may simultaneously copy a <tt>shared_ptr</tt>.  However this
15158 is a critical piece of information for the client, and it has significant
15159 impact on usability for many applications.  (Detlef Vollman thinks it
15160 is currently clear that it is not thread-safe.  Hans Boehm thinks
15161 it currently requires thread safety, since the <tt>use_count</tt> is not an
15162 explicit field, and constructors and assignment take a const reference
15163 to an existing <tt>shared_ptr</tt>.)
15164 </p>
15165
15166 <p>
15167 Pro thread-safety:
15168 </p>
15169 <p>
15170 Many multi-threaded usages are impossible.  A thread-safe version can
15171 be used to destroy an object when the last thread drops it, something
15172 that is often required, and for which we have no other easy mechanism.
15173 </p>
15174 <p>
15175 Against thread-safety:
15176 </p>
15177 <p>
15178 The thread-safe version is well-known to be far more expensive, even
15179 if used by a single thread.  Many applications, including all single-threaded
15180 ones, do not care.
15181 </p>
15182
15183 <p><i>[
15184 San Francisco:
15185 ]</i></p>
15186
15187
15188 <blockquote>
15189 <p>
15190 Beman: this is a complicated issue, and would like to move this to Open
15191 and await comment from Peter Dimov; we need very careful and complete
15192 rationale for any decision we make; let's go slow
15193 </p>
15194 <p>
15195 Detlef: I think that <tt>shared_ptr</tt> should not be thread-safe.
15196 </p>
15197 <p>
15198 Hans: When you create a thread with a lambda, it in some cases makes it
15199 very difficult for the lambda to reference anything in the heap. It's
15200 currently ambiguous as to whether you can use a <tt>shared_ptr</tt> to get at an
15201 object.
15202 </p>
15203 <p>
15204 Leave in Open. Detlef will submit an alternative proposed resolution
15205 that makes <tt>shared_ptr</tt> explicitly unsafe.
15206 </p>
15207 <p>
15208 A third option is to support both threadsafe and non-safe share_ptrs,
15209 and to let the programmer decide which behavior they want.
15210 </p>
15211
15212 <p>
15213 Beman:  Peter, do you support the PR?
15214 </p>
15215
15216 <p>
15217 Peter:
15218 </p>
15219 <blockquote>
15220 <p>
15221 Yes, I support the proposed resolution, and I certainly oppose any
15222 attempts to <tt>make shared_ptr</tt> thread-unsafe.
15223 </p>
15224 <p>
15225 I'd mildly prefer if
15226 </p>
15227 <blockquote>
15228 [<i>Note:</i> This is true in spite of that fact that such functions often
15229 modify <tt>use_count()</tt> <i>--end note</i>]
15230 </blockquote>
15231 <p>
15232 is changed to
15233 </p>
15234 <blockquote>
15235 [<i>Note:</i> This is true in spite of that fact that such functions often
15236 cause a change in <tt>use_count()</tt> <i>--end note</i>]
15237 </blockquote>
15238 <p>
15239 (or something along these lines) to emphasise that <tt>use_count()</tt> is not,
15240 conceptually, a variable, but a return value.
15241 </p>
15242 </blockquote>
15243
15244 </blockquote>
15245
15246 <p><i>[
15247 2009-07 Frankfurt
15248 ]</i></p>
15249
15250
15251 <blockquote>
15252 <p>
15253 Vote: Do we want one thread-safe shared pointer or two? If two, one
15254 would allow concurrent construction and destruction of shared pointers,
15255 and one would not be thread-safe. If one, then it would be thread-safe.
15256 </p>
15257 <p>
15258 No concensus on that vote.
15259 </p>
15260 <p>
15261 Hans to improve wording in consultation with Pete. Leave Open.
15262 </p>
15263 </blockquote>
15264
15265
15266
15267 <p><b>Proposed resolution:</b></p>
15268 <p>
15269 Make it explicitly thread-safe, in this weak sense, as I believe was intended:
15270 </p>
15271 <p>
15272 Insert in 20.8.10.2 [util.smartptr.shared], before p5:
15273 </p>
15274 <blockquote>
15275 <p>
15276 For purposes of determining the presence of a data race,
15277 member functions do not modify <tt>const shared_ptr</tt> and
15278 const <tt>weak_ptr</tt> arguments, nor any objects they
15279 refer to.  [<i>Note:</i> This is true in spite of that fact that such functions often
15280 cause a change in <tt>use_count()</tt> <i>--end note</i>]
15281 </p>
15282 </blockquote>
15283 <p>
15284 On looking at the text, I'm not sure we need a similar disclaimer
15285 anywhere else, since nothing else has the problem with the modified
15286 <tt>use_count()</tt>.  I think Howard arrived at a similar conclusion.
15287 </p>
15288
15289
15290
15291
15292
15293 <hr>
15294 <h3><a name="897"></a>897. Forward_list issues... Part 2</h3>
15295 <p><b>Section:</b> 23.3.3.4 [forwardlist.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
15296  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-09-22  <b>Last modified:</b> 2009-07-18</p>
15297 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
15298 <p><b>Discussion:</b></p>
15299 <p>
15300 This issue was split off from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a> at the request of the LWG.
15301 </p>
15302
15303 <p><i>[
15304 San Francisco:
15305 ]</i></p>
15306
15307
15308 <blockquote>
15309 <p>
15310 This issue is more complicated than it looks.
15311 </p>
15312 <p>
15313 paragraph 47: replace each <tt>(first, last) with (first, last]</tt>
15314 </p>
15315 <p>
15316 add a statement after paragraph 48 that complexity is O(1)
15317 </p>
15318 <p>
15319 remove the complexity statement from the first overload of splice_after
15320 </p>
15321 <p>
15322 We may have the same problems with other modifiers, like erase_after.
15323 Should it require that all iterators in the range (position, last] be
15324 dereferenceable?
15325 </p>
15326 </blockquote>
15327
15328 <p>
15329 There are actually 3 issues here:
15330 </p>
15331
15332 <ol>
15333 <li>
15334 <p>
15335 What value should <tt>erase_after</tt> return?  With <tt>list</tt>, code often
15336 looks like:
15337 </p>
15338 <blockquote><pre>for (auto i = l.begin(); i != l.end();)
15339 {
15340     // inspect *i and decide if you want to erase it
15341     // ...
15342     if (I want to erase *i)
15343         i = l.erase(i);
15344     else
15345         ++i;
15346 }
15347 </pre></blockquote>
15348 <p>
15349 I.e. the iterator returned from <tt>erase</tt> is useful for setting up the
15350 logic for operating on the next element.  For <tt>forward_list</tt> this might
15351 look something like:
15352 </p>
15353 <blockquote><pre>auto i = fl.before_begin();
15354 auto ip1 = i;
15355 for (++ip1; ip1 != fl.end(); ++ip1)
15356 {
15357     // inspect *(i+1) and decide if you want to erase it
15358     // ...
15359     if (I want to erase *(i+1))
15360         i = fl.erase_after(i);
15361     else
15362         ++i;
15363     ip1 = i;
15364 }
15365 </pre></blockquote>
15366 <p>
15367 In the above example code, it is convenient if <tt>erase_after</tt> returns
15368 the element <i>prior</i> to the erased element (range) instead of the element
15369 <i>after</i> the erase element (range).
15370 </p>
15371 <p>
15372 Existing practice:
15373 </p>
15374 <ul>
15375 <li>SGI slist returns an iterator referencing the element <i>after</i> the erased range.</li>
15376 <li>CodeWarrior slist returns an iterator referencing the element <i>before</i> the erased range.</li>
15377 </ul>
15378 <p>
15379 There is not a strong technical argument for either solution over the other.
15380 </p>
15381 </li>
15382
15383 <li>
15384 <p>
15385 With all other containers, operations always work on the range
15386 <tt>[first, last)</tt> and/or <i>prior to</i> the given <tt>position</tt>.
15387 </p>
15388 <p>
15389 With <tt>forward_list</tt>, operations sometimes work on the range
15390 <tt>(first, last]</tt> and/or <i>after</i> the given <tt>position</tt>.
15391 </p>
15392 <p>
15393 This is simply due to the fact that in order to operate on
15394 <tt>*first</tt> (with <tt>forward_list</tt>) one needs access to
15395 <tt>*(first-1)</tt>.  And that's not practical with
15396 <tt>forward_list</tt>.  So the operating range needs to start with <tt>(first</tt>,
15397 not <tt>[first</tt> (as the current working paper says).
15398 </p>
15399 <p>
15400 Additionally, if one is interested in  splicing the range <tt>(first, last)</tt>,
15401 then (with <tt>forward_list</tt>), one needs practical (constant time) access to
15402 <tt>*(last-1)</tt> so that one can set the <i>next</i> field in this node to
15403 the proper value.  As this is not possible with <tt>forward_list</tt>, one must
15404 specify the last element of interest instead of one past the last element of
15405 interest.  The syntax for doing this is to pass <tt>(first, last]</tt> instead
15406 of <tt>(first, last)</tt>.
15407 </p>
15408 <p>
15409 With <tt>erase_after</tt> we have a choice of either erasing the range
15410 <tt>(first, last]</tt> <em>or</em> <tt>(first, last)</tt>.  Choosing the latter
15411 enables:
15412 </p>
15413 <blockquote><pre>x.erase_after(pos, x.end());
15414 </pre></blockquote>
15415
15416 <p>
15417 With the former, the above statement is inconvenient or expensive due to the lack
15418 of constant time access to <tt>x.end()-1</tt>.  However we could introduce:
15419 </p>
15420
15421 <blockquote><pre>iterator erase_to_end(const_iterator position);
15422 </pre></blockquote>
15423
15424 <p>
15425 to compensate.
15426 </p>
15427
15428 <p>
15429 The advantage of the former (<tt>(first, last]</tt>) for <tt>erase_after</tt>
15430 is a consistency with <tt>splice_after</tt> which uses <tt>(first, last]</tt>
15431 as the specified range.  But this either requires the addition of <tt>erase_to_end</tt>
15432 or giving up such functionality.
15433 </p>
15434
15435 </li>
15436
15437 <li>
15438 As stated in the discussion of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#892">892</a>, and reienforced by point 2 above,
15439 a <tt>splice_after</tt> should work on the source range <tt>(first, last]</tt>
15440 if the operation is to be <i>&#927;</i>(1).  When splicing an entire list <tt>x</tt> the
15441 algorithm needs <tt>(x.before_begin(), x.end()-1]</tt>.  Unfortunately <tt>x.end()-1</tt>
15442 is not available in constant time unless we specify that it must be.  In order to
15443 make <tt>x.end()-1</tt> available in constant time, the implementation would have
15444 to dedicate a pointer to it.  I believe the design of
15445 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2543.htm">N2543</a>
15446 intended a nominal overhead of <tt>foward_list</tt> of 1 pointer.  Thus splicing
15447 one <i>entire</i> <tt>forward_list</tt> into another can not be <i>&#927;</i>(1).
15448 </li>
15449 </ol>
15450
15451 <p><i>[
15452 Batavia (2009-05):
15453 ]</i></p>
15454
15455 <blockquote>
15456 <p>
15457 We agree with the proposed resolution.
15458 </p>
15459 <p>
15460 Move to Review.
15461 </p>
15462 </blockquote>
15463
15464 <p><i>[
15465 2009-07 Frankfurt
15466 ]</i></p>
15467
15468
15469 <blockquote>
15470 <p>
15471 We may need a new issue to correct splice_after, because it may no
15472 longer be correct to accept an rvalues as an argument. Merge may be
15473 affected, too. This might be issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1133">1133</a>. (Howard: confirmed)
15474 </p>
15475 <p>
15476 Move this to Ready, but the Requires clause of the second form of
15477 splice_after should say "(first, last)," not "(first, last]" (there are
15478 three occurrences). There was considerable discussion on this. (Howard: fixed)
15479 </p>
15480 <p>
15481 Alan suggested removing the "foward_last&lt;T. Alloc&gt;&amp;&amp; x"
15482 parameter from the second form of splice_after, because it is redundant.
15483 PJP wanted to keep it, because it allows him to check for bad ranges
15484 (i.e. "Granny knots").
15485 </p>
15486 <p>
15487 We prefer to keep <tt>x</tt>.
15488 </p>
15489 <p>
15490 Beman. Whenever we deviate from the customary half-open range in the
15491 specification, we should add a non-normative comment to the standard
15492 explaining the deviation. This clarifies the intention and spares the
15493 committee much confusion in the future.
15494 </p>
15495 <p>
15496 Alan to write a non-normative comment to explain the use of fully-closed ranges.
15497 </p>
15498 <p>
15499 Move to Ready, with the changes described above. (Howard: awaiting note from Alan)
15500 </p>
15501 </blockquote>
15502
15503
15504
15505 <p><b>Proposed resolution:</b></p>
15506 <p>
15507 Wording below assumes issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#878">878</a> is accepted, but this issue is
15508 independent of that issue.
15509 </p>
15510
15511 <p>
15512 Change 23.3.3.4 [forwardlist.modifiers]:
15513 </p>
15514
15515 <blockquote>
15516 <pre>iterator erase_after(const_iterator position);
15517 </pre>
15518 <blockquote>
15519 <p>
15520 <i>Requires:</i> The iterator following <tt>position</tt> is dereferenceable.
15521 </p>
15522 <p>
15523 <i>Effects:</i> Erases the element pointed to by the iterator following <tt>position</tt>.
15524 </p>
15525 <p>
15526 <i>Returns:</i> <del>An iterator pointing to the element following the one that was erased, or <tt>end()</tt> if no such
15527 element exists</del>
15528 <ins>An iterator equal to <tt>position</tt></ins>.
15529 </p>
15530 </blockquote>
15531
15532
15533 <pre>iterator erase_after(const_iterator position, <ins>const_</ins>iterator last);
15534 </pre>
15535 <blockquote>
15536 <p>
15537 <i>Requires:</i> All iterators in the range
15538 <tt><del>[</del><ins>(</ins>position,last)</tt>
15539 are dereferenceable.
15540 </p>
15541 <p>
15542 <i>Effects:</i> Erases the elements in the range
15543 <tt><del>[</del><ins>(</ins>position,last)</tt>.
15544 </p>
15545 <p>
15546 <i>Returns:</i>  <ins>An iterator equal to <tt>position</tt></ins> <del><tt>last</tt></del>
15547 </p>
15548 </blockquote>
15549 </blockquote>
15550
15551 <p>
15552 Change 23.3.3.5 [forwardlist.ops]:
15553 </p>
15554
15555 <blockquote>
15556 <pre>void splice_after(const_iterator position, forward_list&lt;T,Allocator&gt;&amp;&amp; x);
15557 </pre>
15558 <blockquote>
15559 <p>
15560 <i>Requires:</i> <tt>position</tt> is <tt>before_begin()</tt> or a
15561 dereferenceable iterator in the range <tt>[begin(), end))</tt>. <tt>&amp;x != this</tt>.
15562 </p>
15563 <p>
15564 <i>Effects:</i> Inserts the contents of <tt>x</tt> after <tt>position</tt>, and
15565 <tt>x</tt> becomes empty. Pointers and references to
15566 the moved elements of <tt>x</tt> now refer to those same elements but as members of <tt>*this</tt>.
15567 Iterators referring to the moved elements will continue to refer to their elements,
15568 but they now behave as iterators into <tt>*this</tt>, not into <tt>x</tt>.
15569 </p>
15570 <p>
15571 <i>Throws:</i> Nothing.
15572 </p>
15573 <p>
15574 <i>Complexity:</i> <del><i>&#927;</i>(1)</del> <ins><i>&#927;</i>(<tt>distance(x.begin(), x.end())</tt>)</ins>
15575 </p>
15576 </blockquote>
15577
15578 <p>...</p>
15579
15580 <pre>void splice_after(const_iterator position, forward_list&lt;T,Allocator&gt;&amp;&amp; x,
15581                   const_iterator first, const_iterator last);
15582 </pre>
15583 <blockquote>
15584 <p>
15585 <i>Requires:</i> <tt>position</tt> is <tt>before_begin()</tt> or a
15586 dereferenceable iterator in the range <tt>[begin(), end))</tt>.
15587 <tt>(first,last)</tt> is a valid range in
15588 <tt>x</tt>, and all iterators in the range
15589 <tt>(first,last)</tt> are dereferenceable.
15590 <tt>position</tt> is not an iterator in the range <tt>(first,last)</tt>.
15591 </p>
15592 <p>
15593 <i>Effects:</i> Inserts elements in the range <tt>(first,last)</tt>
15594 after <tt>position</tt> and removes the elements from <tt>x</tt>.
15595 Pointers and references to the moved elements of <tt>x</tt> now refer to
15596 those same elements but as members of <tt>*this</tt>. Iterators
15597 referring to the moved elements will continue to refer to their
15598 elements, but they now behave as iterators into <tt>*this</tt>, not into
15599 <tt>x</tt>.
15600 </p>
15601 <p>
15602 <ins><i>Complexity:</i> <i>&#927;</i>(1).</ins>
15603 </p>
15604 </blockquote>
15605
15606 </blockquote>
15607
15608
15609
15610
15611
15612
15613 <hr>
15614 <h3><a name="900"></a>900. stream move-assignment</h3>
15615 <p><b>Section:</b> 27.9.1.8 [ifstream.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
15616  <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2008-09-20  <b>Last modified:</b> 2009-07-26</p>
15617 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
15618 <p><b>Discussion:</b></p>
15619 <p>
15620 It
15621 appears that we have an issue similar to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a> regarding the move-assignment of
15622 stream types. For example, when assigning to an <tt>std::ifstream</tt>,
15623 <tt>ifstream1</tt>, it seems preferable to close the file originally held by
15624 <tt>ifstream1</tt>:
15625 </p>
15626
15627 <blockquote><pre>ifstream1 = std::move(ifstream2);
15628 </pre></blockquote>
15629
15630 <p>
15631 The current Draft
15632 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>)
15633 specifies that the move-assignment of
15634 stream types like <tt>ifstream</tt> has the same effect as a swap:
15635 </p>
15636
15637 <blockquote>
15638 <p>
15639 Assign and swap 27.9.1.8 [ifstream.assign]
15640 </p>
15641 <pre>basic_ifstream&amp; operator=(basic_ifstream&amp;&amp; rhs);
15642 </pre>
15643 <blockquote>
15644 <i>Effects:</i> <tt>swap(rhs)</tt>.
15645 </blockquote>
15646 </blockquote>
15647
15648 <p><i>[
15649 Batavia (2009-05):
15650 ]</i></p>
15651
15652 <blockquote>
15653 <p>
15654 Howard agrees with the analysis and the direction proposed.
15655 </p>
15656 <p>
15657 Move to Open pending specific wording to be supplied by Howard.
15658 </p>
15659 </blockquote>
15660
15661 <p><i>[
15662 2009-07 Frankfurt:
15663 ]</i></p>
15664
15665
15666 <blockquote>
15667 Howard is going to write wording.
15668 </blockquote>
15669
15670 <p><i>[
15671 2009-07-26 Howard provided wording.
15672 ]</i></p>
15673
15674
15675
15676
15677 <p><b>Proposed resolution:</b></p>
15678
15679 <p>
15680 Change 27.8.1.2 [stringbuf.assign]/1:
15681 </p>
15682
15683 <blockquote><pre>basic_stringbuf&amp; operator=(basic_stringbuf&amp;&amp; rhs);
15684 </pre>
15685 <blockquote>
15686 -1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
15687 <ins>After the move assignment <tt>*this</tt> reflects the same observable
15688 state it would have if it had been move constructed from <tt>rhs</tt>
15689 (27.8.1.1 [stringbuf.cons]).
15690 </ins>
15691 </blockquote>
15692 </blockquote>
15693
15694 <p>
15695 Change 27.8.2.2 [istringstream.assign]/1:
15696 </p>
15697
15698 <blockquote><pre>basic_istringstream&amp; operator=(basic_istringstream&amp;&amp; rhs);
15699 </pre>
15700 <blockquote>
15701 -1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
15702 <ins>Move assigns the base and members of <tt>*this</tt> with the respective
15703 base and members of <tt>rhs</tt>.
15704 </ins>
15705 </blockquote>
15706 </blockquote>
15707
15708 <p>
15709 Change 27.8.3.2 [ostringstream.assign]/1:
15710 </p>
15711
15712 <blockquote><pre>basic_ostringstream&amp; operator=(basic_ostringstream&amp;&amp; rhs);
15713 </pre>
15714 <blockquote>
15715 -1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
15716 <ins>Move assigns the base and members of <tt>*this</tt> with the respective
15717 base and members of <tt>rhs</tt>.
15718 </ins>
15719 </blockquote>
15720 </blockquote>
15721
15722 <p>
15723 Change 27.8.5.1 [stringstream.assign]/1:
15724 </p>
15725
15726 <blockquote><pre>basic_stringstream&amp; operator=(basic_stringstream&amp;&amp; rhs);
15727 </pre>
15728 <blockquote>
15729 -1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
15730 <ins>Move assigns the base and members of <tt>*this</tt> with the respective
15731 base and members of <tt>rhs</tt>.
15732 </ins>
15733 </blockquote>
15734 </blockquote>
15735
15736 <p>
15737 Change 27.9.1.3 [filebuf.assign]/1:
15738 </p>
15739
15740 <blockquote><pre>basic_filebuf&amp; operator=(basic_filebuf&amp;&amp; rhs);
15741 </pre>
15742 <blockquote>
15743 -1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
15744 <ins>Begins by calling <tt>this-&gt;close()</tt>.
15745 After the move assignment <tt>*this</tt> reflects the same observable
15746 state it would have if it had been move constructed from <tt>rhs</tt>
15747 (27.9.1.2 [filebuf.cons]).
15748 </ins>
15749 </blockquote>
15750 </blockquote>
15751
15752 <p>
15753 Change 27.9.1.8 [ifstream.assign]/1:
15754 </p>
15755
15756 <blockquote><pre>basic_ifstream&amp; operator=(basic_ifstream&amp;&amp; rhs);
15757 </pre>
15758 <blockquote>
15759 -1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
15760 <ins>Move assigns the base and members of <tt>*this</tt> with the respective
15761 base and members of <tt>rhs</tt>.</ins>
15762 </blockquote>
15763 </blockquote>
15764
15765 <p>
15766 Change 27.9.1.12 [ofstream.assign]/1:
15767 </p>
15768
15769 <blockquote><pre>basic_ofstream&amp; operator=(basic_ofstream&amp;&amp; rhs);
15770 </pre>
15771 <blockquote>
15772 -1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
15773 <ins>Move assigns the base and members of <tt>*this</tt> with the respective
15774 base and members of <tt>rhs</tt>.</ins>
15775 </blockquote>
15776 </blockquote>
15777
15778 <p>
15779 Change 27.9.1.16 [fstream.assign]/1:
15780 </p>
15781
15782 <blockquote><pre>basic_fstream&amp; operator=(basic_fstream&amp;&amp; rhs);
15783 </pre>
15784 <blockquote>
15785 -1- <i>Effects:</i> <del><tt>swap(rhs)</tt>.</del>
15786 <ins>Move assigns the base and members of <tt>*this</tt> with the respective
15787 base and members of <tt>rhs</tt>.</ins>
15788 </blockquote>
15789 </blockquote>
15790
15791
15792
15793
15794
15795
15796 <hr>
15797 <h3><a name="908"></a>908. Deleted assignment operators for atomic types must be volatile</h3>
15798 <p><b>Section:</b> 29.5 [atomics.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
15799  <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2008-09-26  <b>Last modified:</b> 2009-03-22</p>
15800 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types">issues</a> in [atomics.types].</p>
15801 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
15802 <p><b>Discussion:</b></p>
15803
15804 <p><b>Addresses US 90</b></p>
15805
15806 <p>
15807 The deleted copy-assignment operators for the atomic types are not
15808 marked as volatile in N2723, whereas the assignment operators from the
15809 associated non-atomic types are. e.g.
15810 </p>
15811 <blockquote><pre>atomic_bool&amp; operator=(atomic_bool const&amp;) = delete;
15812 atomic_bool&amp; operator=(bool) volatile;
15813 </pre></blockquote>
15814
15815 <p>
15816 This leads to ambiguity when assigning a non-atomic value to a
15817 non-volatile instance of an atomic type:
15818 </p>
15819 <blockquote><pre>atomic_bool b;
15820 b=false;
15821 </pre></blockquote>
15822
15823 <p>
15824 Both assignment operators require a standard conversions: the
15825 copy-assignment operator can use the implicit <tt>atomic_bool(bool)</tt>
15826 conversion constructor to convert <tt>false</tt> to an instance of
15827 <tt>atomic_bool</tt>, or <tt>b</tt> can undergo a qualification conversion in order to
15828 use the assignment from a plain <tt>bool</tt>.
15829 </p>
15830
15831 <p>
15832 This is only a problem once issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#845">845</a> is applied.
15833 </p>
15834
15835 <p><i>[
15836 Summit:
15837 ]</i></p>
15838
15839 <blockquote>
15840 Move to open. Assign to Lawrence. Related to US 90 comment.
15841 </blockquote>
15842
15843
15844 <p><b>Proposed resolution:</b></p>
15845 <p>
15846 Add volatile qualification to the deleted copy-assignment operator of
15847 all the atomic types:
15848 </p>
15849
15850 <blockquote><pre>atomic_bool&amp; operator=(atomic_bool const&amp;) <ins>volatile</ins> = delete;
15851 atomic_itype&amp; operator=(atomic_itype const&amp;) <ins>volatile</ins> = delete;
15852 </pre></blockquote>
15853
15854 <p>
15855 etc.
15856 </p>
15857 <p>
15858 This will mean that the deleted copy-assignment operator will require
15859 <i>two</i> conversions in the above example, and thus be a worse match than
15860 the assignment from plain <tt>bool</tt>.
15861 </p>
15862
15863
15864
15865
15866
15867 <hr>
15868 <h3><a name="910"></a>910. Effects of MoveAssignable</h3>
15869 <p><b>Section:</b> 20.2.9 [concept.copymove] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
15870  <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-09-29  <b>Last modified:</b> 2009-07-18</p>
15871 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
15872 <p><b>Discussion:</b></p>
15873 <p><b>Addresses UK 150</b></p>
15874
15875 <p>
15876 The description of the effect of <tt>operator=</tt> in the <tt>MoveAssignable</tt>
15877 concept, given in paragraph 7 is:
15878 </p>
15879
15880 <blockquote><pre>result_type  T::operator=(T&amp;&amp;  rv);  // inherited from HasAssign&lt;T, T&amp;&amp;&gt;
15881 </pre>
15882
15883 <blockquote>
15884 <i>Postconditions:</i> the constructed <tt>T</tt> object is equivalent to the value of
15885 <tt>rv</tt> before the assignment. [<i>Note:</i> there is no
15886 requirement on the value of <tt>rv</tt> after the assignment.  <i>--end note</i>]
15887 </blockquote>
15888 </blockquote>
15889
15890 <p>
15891 The sentence contains a typo (what is the "constructed <tt>T</tt> object"?)
15892 probably due to a cut&amp;paste from <tt>MoveConstructible</tt>. Moreover, the
15893 discussion of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#675">675</a> shows that the postcondition is too generic
15894 and might not reflect the user expectations. An implementation of the
15895 move assignment that just calls <tt>swap()</tt> would always fulfill the
15896 postcondition as stated, but might have surprising side-effects in case
15897 the source rvalue refers to an object that is not going to be
15898 immediately destroyed. See LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#900">900</a> for another example. Due to
15899 the sometimes intangible nature of the "user expectation", it seems
15900 difficult to have precise normative wording that could cover all cases
15901 without introducing unnecessary restrictions. However a non-normative
15902 clarification could be a very helpful warning sign that swapping is not
15903 always the correct thing to do.
15904 </p>
15905
15906 <p><i>[
15907 2009-05-09 Alisdair adds:
15908 ]</i></p>
15909
15910
15911 <blockquote>
15912 <p>
15913 Issue 910 is exactly the reason BSI advanced the Editorial comment UK-150.
15914 </p>
15915 <p>
15916 The post-conditions after assignment are at a minimum that the object
15917 referenced by rv must be safely destructible, and the transaction should not
15918 leak resources.  Ideally it should be possible to simply assign rv a new
15919 valid state after the call without invoking undefined behaviour, but any
15920 other use of the referenced object would depend upon additional guarantees
15921 made by that type.
15922 </p>
15923 </blockquote>
15924
15925 <p><i>[
15926 2009-05-09 Howard adds:
15927 ]</i></p>
15928
15929
15930 <blockquote>
15931 <p>
15932 The intent of the rvalue reference work is that the moved from <tt>rv</tt> is
15933 a valid object.  Not one in a singular state.  If, for example, the moved from
15934 object is a <tt>vector</tt>, one should be able to do anything on that moved-from
15935 <tt>vector</tt> that you can do with any other <tt>vector</tt>.  However you would
15936 first have to query it to find out what its current state is.  E.g. it might have <tt>capacity</tt>,
15937 it might not.  It might have a non-zero <tt>size</tt>, it might not.  But regardless,
15938 you can <tt>push_back</tt> on to it if you want.
15939 </p>
15940
15941 <p>
15942 That being said, most standard code is now conceptized.  That is, the concepts
15943 list the only operations that can be done with templated types - whether or not
15944 the values have been moved from.
15945 </p>
15946
15947 <p>
15948 Here is user-written code which must be allowed to be legal:
15949 </p>
15950 <blockquote><pre>#include &lt;vector&gt;
15951 #include &lt;cstdio&gt;
15952
15953 template &lt;class Allocator&gt;
15954 void
15955 inspect(std::vector&lt;double, Allocator&gt;&amp;&amp; v)
15956 {
15957     std::vector&lt;double, Allocator&gt; result(move(v));
15958     std::printf("moved from vector has %u size and %u capacity\n", v.size(), v.capacity());
15959     std::printf("The contents of the vector are:\n");
15960     typedef typename std::vector&lt;double, Allocator&gt;::iterator I;
15961     for (I i = v.begin(), e = v.end(); i != e; ++i)
15962         printf("%f\n", *i);
15963 }
15964
15965 int main()
15966 {
15967     std::vector&lt;double&gt; v1(100, 5.5);
15968     inspect(move(v1));
15969 }
15970 </pre></blockquote>
15971
15972 <p>
15973 The above program does not treat the moved-from <tt>vector</tt> as singular.  It
15974 only treats it as a <tt>vector</tt> with an unknown value.
15975 </p>
15976 <p>
15977 I believe the current proposed wording is consistent with my view on this.
15978 </p>
15979 </blockquote>
15980
15981 <p><i>[
15982 Batavia (2009-05):
15983 ]</i></p>
15984
15985 <blockquote>
15986 We agree that the proposed resolution
15987 is an improvement over the current wording.
15988 </blockquote>
15989
15990 <p><i>[
15991 2009-07 Frankfurt:
15992 ]</i></p>
15993
15994
15995 <blockquote>
15996 Need to look at again without concepts.
15997 </blockquote>
15998
15999 <p><i>[
16000 2009-07 Frankfurt:
16001 ]</i></p>
16002
16003
16004 <blockquote>
16005 Walter will consult with Dave and Doug.
16006 </blockquote>
16007
16008
16009
16010 <p><b>Proposed resolution:</b></p>
16011 <p>
16012 In 20.2.9 [concept.copymove], replace the postcondition in paragraph 7 with:
16013 </p>
16014
16015 <blockquote>
16016 <i>Postconditions:</i> <tt>*this</tt> is equivalent to the value of <tt>rv</tt> before the
16017 assignment. [<i>Note:</i> there is no requirement on the value of <tt>rv</tt> after the
16018 assignment, but the
16019 effect should be unsurprising to the user even in case <tt>rv</tt> is not
16020 immediately destroyed. This may require that resources previously owned
16021 by <tt>*this</tt> are released instead of transferred to <tt>rv</tt>. <i>-- end note</i>]
16022 </blockquote>
16023
16024
16025
16026
16027
16028 <hr>
16029 <h3><a name="911"></a>911. I/O streams and <tt>move/swap</tt> semantic</h3>
16030 <p><b>Section:</b> 27.7.1 [input.streams], 27.7.2 [output.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
16031  <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-09-29  <b>Last modified:</b> 2009-07-27</p>
16032 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
16033 <p><b>Discussion:</b></p>
16034 <p>
16035 Class template <tt>basic_istream</tt>, <tt>basic_ostream</tt> and <tt>basic_iostream</tt>
16036 implements public move constructors, move assignment operators and <tt>swap</tt>
16037 method and free functions. This might induce both the user and the
16038 compiler to think that those types are <tt>MoveConstructible</tt>, <tt>MoveAssignable</tt>
16039 and <tt>Swappable</tt>. However, those class templates fail to fulfill the user
16040 expectations. For example:
16041 </p>
16042
16043 <blockquote><pre>std::ostream os(std::ofstream("file.txt"));
16044 assert(os.rdbuf() == 0); // buffer object is not moved to os, file.txt has been closed
16045
16046 std::vector&lt;std::ostream&gt; v;
16047 v.push_back(std::ofstream("file.txt"));
16048 v.reserve(100); // causes reallocation
16049 assert(v[0].rdbuf() == 0); // file.txt has been closed!
16050
16051 std::ostream&amp;&amp; os1 = std::ofstream("file1.txt");
16052 os1 = std::ofstream("file2.txt");
16053 os1 &lt;&lt; "hello, world"; // still writes to file1.txt, not to file2.txt!
16054
16055 std::ostream&amp;&amp; os1 = std::ofstream("file1.txt");
16056 std::ostream&amp;&amp; os2 = std::ofstream("file2.txt");
16057 std::swap(os1, os2);
16058 os1 &lt;&lt; "hello, world"; // writes to file1.txt, not to file2.txt!
16059 </pre></blockquote>
16060
16061 <p>
16062 This is because the move constructor, the move assignment operator and
16063 <tt>swap</tt> are all implemented through calls to <tt>std::basic_ios</tt> member
16064 functions <tt>move()</tt> and <tt>swap()</tt> that do not move nor swap the controlled
16065 stream buffers. That can't happen because the stream buffers may have
16066 different types.
16067 </p>
16068
16069 <p>
16070 Notice that for <tt>basic_streambuf</tt>, the member function <tt>swap()</tt> is
16071 protected. I believe that is correct and all of <tt>basic_istream</tt>,
16072 <tt>basic_ostream</tt>, <tt>basic_iostream</tt> should do the same as the move ctor, move
16073 assignment operator and swap member function are needed by the derived
16074 <tt>fstream</tt>s and <tt>stringstream</tt>s template. The free swap functions for
16075 <tt>basic_(i|o|io)stream</tt> templates should be removed for the same reason.
16076 </p>
16077
16078 <p><i>[
16079 Batavia (2009-05):
16080 ]</i></p>
16081
16082 <blockquote>
16083 <p>
16084 We note that the rvalue swap functions have already been removed.
16085 </p>
16086 <p>
16087 Bill is unsure about making the affected functions protected;
16088 he believes they may need to be public.
16089 </p>
16090 <p>
16091 We are also unsure about removing the lvalue swap functions as proposed.
16092 </p>
16093 <p>
16094 Move to Open.
16095 </p>
16096 </blockquote>
16097
16098 <p><i>[
16099 2009-07 Frankfurt:
16100 ]</i></p>
16101
16102
16103 <blockquote>
16104 <p>
16105 It's not clear that the use case is compelling.
16106 </p>
16107 <p>
16108 Howard: This needs to be implemented and tested.
16109 </p>
16110 </blockquote>
16111
16112 <p><i>[
16113 2009-07-26 Howard adds:
16114 ]</i></p>
16115
16116
16117 <blockquote>
16118 <p>
16119 I started out thinking I would recommend NAD for this one.  I've turned around
16120 to agree with the proposed resolution (which I've updated to the current draft).
16121 I did not fully understand Ganesh's rationale, and attempt to describe my
16122 improved understanding below.
16123 </p>
16124
16125 <p>
16126 The move constructor, move assignment operator, and swap function are different
16127 for <tt>basic_istream</tt>, <tt>basic_ostream</tt> and <tt>basic_iostream</tt>
16128 than other classes.  A timely conversation with Daniel reminded me of this long
16129 forgotten fact.  These members are sufficiently different that they would be
16130 extremely confusing to use in general, but they are very much needed for derived
16131 clients.
16132 </p>
16133
16134 <ul>
16135 <li>
16136 The move constructor moves everything but the <tt>rdbuf</tt> pointer.
16137 </li>
16138 <li>
16139 The move assignment operator moves everything but the <tt>rdbuf</tt> pointer.
16140 </li>
16141 <li>
16142 The swap function swaps everything but the <tt>rdbuf</tt> pointer.
16143 </li>
16144 </ul>
16145
16146 <p>
16147 The reason for this behavior is that for the std-derived classes (stringstreams,
16148 filestreams), the <tt>rdbuf</tt> pointer points back into the class itself
16149 (self referencing).  It can't be swapped or moved.  But this fact isn't born out
16150 at the <tt>stream</tt> level.  Rather it is born out at the <tt>fstream</tt>/<tt>sstream</tt>
16151 level.  And the lower levels just need to deal with that fact by not messing around
16152 with the <tt>rdbuf</tt> pointer which is stored down at the lower levels.
16153 </p>
16154
16155 <p>
16156 In a nutshell, it is very confusing for all of those who are not so intimately
16157 related with streams that they've implemented them.  And it is even fairly
16158 confusing for some of those who have (including myself).  I do not think it is
16159 safe to swap or move <tt>istreams</tt> or <tt>ostreams</tt> because this will
16160 (by necessary design) separate stream state from streambuffer state.  Derived
16161 classes (such as <tt>fstream</tt> and <tt>stringstream</tt> must be used to
16162 keep the stream state and stream buffer consistently packaged as one unit during
16163 a move or swap.
16164 </p>
16165
16166 <p>
16167 I've implemented this proposal and am living with it day to day.
16168 </p>
16169
16170 </blockquote>
16171
16172
16173
16174 <p><b>Proposed resolution:</b></p>
16175 <p>
16176 27.7.1.1 [istream]: make the following member functions protected:
16177 </p>
16178
16179 <blockquote><pre>basic_istream(basic_istream&amp;&amp;  rhs);
16180 basic_istream&amp;  operator=(basic_istream&amp;&amp;  rhs);
16181 void  swap(basic_istream&amp;  rhs);
16182 </pre></blockquote>
16183
16184 <p>
16185 Ditto: remove the swap free function signature
16186 </p>
16187
16188 <blockquote><pre><del>// swap:
16189 template &lt;class charT, class traits&gt;
16190   void swap(basic_istream&lt;charT, traits&gt;&amp; x, basic_istream&lt;charT, traits&gt;&amp; y);</del>
16191 </pre></blockquote>
16192
16193 <p>
16194 27.7.1.1.2 [istream.assign]: remove paragraph 4
16195 </p>
16196
16197 <blockquote><pre><del>template &lt;class charT, class traits&gt;
16198   void swap(basic_istream&lt;charT, traits&gt;&amp; x, basic_istream&lt;charT, traits&gt;&amp; y);</del>
16199 </pre>
16200 <blockquote>
16201 <del><i>Effects:</i> <tt>x.swap(y)</tt>.</del>
16202 </blockquote>
16203 </blockquote>
16204
16205 <p>
16206 27.7.1.5 [iostreamclass]: make the following member function protected:
16207 </p>
16208
16209 <blockquote><pre>basic_iostream(basic_iostream&amp;&amp;  rhs);
16210 basic_iostream&amp;  operator=(basic_iostream&amp;&amp;  rhs);
16211 void  swap(basic_iostream&amp;  rhs);
16212 </pre></blockquote>
16213
16214 <p>
16215 Ditto: remove the swap free function signature
16216 </p>
16217
16218 <blockquote><pre><del>template &lt;class charT, class traits&gt;
16219   void swap(basic_iostream&lt;charT, traits&gt;&amp; x, basic_iostream&lt;charT, traits&gt;&amp; y);</del>
16220 </pre></blockquote>
16221
16222 <p>
16223 27.7.1.5.3 [iostream.assign]: remove paragraph 3
16224 </p>
16225
16226 <blockquote><pre><del>template &lt;class charT, class traits&gt;
16227   void swap(basic_iostream&lt;charT, traits&gt;&amp; x, basic_iostream&lt;charT, traits&gt;&amp; y);</del>
16228 </pre>
16229 <blockquote>
16230 <del><i>Effects:</i> <tt>x.swap(y)</tt>.</del>
16231 </blockquote>
16232 </blockquote>
16233
16234 <p>
16235 27.7.2.1 [ostream]: make the following member function protected:
16236 </p>
16237
16238 <blockquote><pre>basic_ostream(basic_ostream&amp;&amp;  rhs);
16239 basic_ostream&amp;  operator=(basic_ostream&amp;&amp;  rhs);
16240 void  swap(basic_ostream&amp;  rhs);
16241 </pre></blockquote>
16242
16243 <p>
16244 Ditto: remove the swap free function signature
16245 </p>
16246
16247 <blockquote><pre><del>// swap:
16248 template &lt;class charT, class traits&gt;
16249   void swap(basic_ostream&lt;charT, traits&gt;&amp; x, basic_ostream&lt;charT, traits&gt;&amp; y);</del>
16250 </pre></blockquote>
16251
16252 <p>
16253 27.7.2.3 [ostream.assign]: remove paragraph 4
16254 </p>
16255
16256 <blockquote><pre><del>template &lt;class charT, class traits&gt;
16257   void swap(basic_ostream&lt;charT, traits&gt;&amp; x, basic_ostream&lt;charT, traits&gt;&amp; y);</del>
16258 </pre>
16259 <blockquote>
16260 <del><i>Effects:</i> <tt>x.swap(y)</tt>.</del>
16261 </blockquote>
16262 </blockquote>
16263
16264
16265
16266
16267
16268
16269 <hr>
16270 <h3><a name="915"></a>915. <tt>minmax</tt> with <tt>initializer_list</tt> should return
16271 <tt>pair</tt> of <tt>T</tt>, not <tt>pair</tt> of <tt>const T&amp;</tt></h3>
16272 <p><b>Section:</b> 25.5.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
16273  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-04  <b>Last modified:</b> 2009-07-14</p>
16274 <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>
16275 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
16276 <p><b>Discussion:</b></p>
16277 <p>
16278 It seems that the proposed changes for
16279 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2772.pdf">N2772</a>
16280 were not clear enough in
16281 this point:
16282 </p>
16283
16284 <blockquote>
16285 25.5.7 [alg.min.max], before p.23 + p.24 + before p. 27 + p. 28 say that the return
16286 type of the <tt>minmax</tt> overloads with an <tt>initializer_list</tt> is
16287 <tt>pair&lt;const T&amp;, const T&amp;&gt;</tt>,
16288 which is inconsistent with the decision for the other <tt>min/max</tt> overloads which take
16289 a <tt>initializer_list</tt> as argument and return a <tt>T</tt>, not a <tt>const T&amp;</tt>.
16290 Doing otherwise for <tt>minmax</tt> would easily lead to unexpected life-time
16291 problems by using <tt>minmax</tt> instead of <tt>min</tt> and <tt>max</tt> separately.
16292 </blockquote>
16293
16294 <p><i>[
16295 Batavia (2009-05):
16296 ]</i></p>
16297
16298 <blockquote>
16299 We agree with the proposed resolution.
16300 Move to Tentatively Ready.
16301 </blockquote>
16302
16303 <p><i>[
16304 2009-07 Frankfurt
16305 ]</i></p>
16306
16307
16308 <blockquote>
16309 Moved from Tentatively Ready to Open only because the wording needs to be
16310 tweaked for concepts removal.
16311 </blockquote>
16312
16313
16314
16315 <p><b>Proposed resolution:</b></p>
16316 <ol>
16317 <li>
16318 <p>
16319 In 25 [algorithms]/2, header <tt>&lt;algorithm&gt;</tt> synopsis change as indicated:
16320 </p>
16321
16322 <blockquote><pre>template&lt;<del>class</del><ins>LessThanComparable</ins> T&gt;
16323 <ins>requires CopyConstructible&lt;T&gt;</ins>
16324 pair&lt;<del>const </del>T<del>&amp;</del>, <del>const </del>T<del>&amp;</del>&gt;
16325 minmax(initializer_list&lt;T&gt; t);
16326
16327 template&lt;class T, <del>class</del><ins>StrictWeakOrder&lt;auto, T&gt;</ins> Compare&gt;
16328 <ins>requires CopyConstructible&lt;T&gt;</ins>
16329 pair&lt;<del>const </del>T<del>&amp;</del>, <del>const </del>T<del>&amp;</del>&gt;
16330 minmax(initializer_list&lt;T&gt; t, Compare comp);
16331 </pre></blockquote>
16332 </li>
16333 <li>
16334 <p>
16335 In 25.5.7 [alg.min.max] change as indicated (Begin: Just before p.20):
16336 </p>
16337 <blockquote><pre>template&lt;<del>class</del><ins>LessThanComparable</ins> T&gt;
16338   <ins>requires CopyConstructible&lt;T&gt;</ins>
16339   pair&lt;<del>const </del>T<del>&amp;</del>, <del>const </del>T<del>&amp;</del>&gt;
16340   minmax(initializer_list&lt;T&gt; t);
16341 </pre>
16342 <blockquote>
16343 <p>
16344 <del>-20- <i>Requires:</i> <tt>T</tt> is <tt>LessThanComparable</tt> and
16345 <tt>CopyConstructible</tt>.</del>
16346 </p>
16347 <p>
16348 -21- <i>Returns:</i> <tt>pair&lt;<del>const </del>T<del>&amp;</del>, <del>const
16349 </del>T<del>&amp;</del>&gt;(x, y)</tt> where <tt>x</tt> is the
16350 smallest value and <tt>y</tt> the largest value in the <tt>initializer_list</tt>.
16351 </p>
16352 </blockquote>
16353
16354 <p>[..]</p>
16355 <pre>template&lt;class T, <del>class</del><ins>StrictWeakOrder&lt;auto, T&gt;</ins> Compare&gt;
16356   <ins>requires CopyConstructible&lt;T&gt;</ins>
16357   pair&lt;<del>const </del>T<del>&amp;</del>, <del>const </del>T<del>&amp;</del>&gt;
16358   minmax(initializer_list&lt;T&gt; t, Compare comp);
16359 </pre>
16360
16361 <blockquote>
16362 <p>
16363 <del>-24- <i>Requires:</i> type <tt>T</tt> is <tt>LessThanComparable</tt> and <tt>CopyConstructible</tt>.</del>
16364 </p>
16365 <p>
16366 -25- <i>Returns:</i> <tt>pair&lt;<del>const </del>T<del>&amp;</del>, <del>const
16367 </del>T<del>&amp;</del>&gt;(x, y)</tt> where <tt>x</tt> is the
16368 smallest value and <tt>y</tt> largest value in the <tt>initializer_list</tt>.
16369 </p>
16370 </blockquote>
16371 </blockquote>
16372 </li>
16373 </ol>
16374
16375
16376
16377
16378
16379
16380 <hr>
16381 <h3><a name="916"></a>916. Redundant move-assignment operator of <tt>pair</tt> should be removed</h3>
16382 <p><b>Section:</b> 20.3.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
16383  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-04  <b>Last modified:</b> 2009-07-18</p>
16384 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#pairs">active issues</a> in [pairs].</p>
16385 <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>
16386 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
16387 <p><b>Discussion:</b></p>
16388 <p><b>see also <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#917">917</a>.</b></p>
16389
16390 <p>
16391 The current WP provides the following assignment operators for <tt>pair</tt>
16392 in 20.3.3 [pairs]/1:
16393 </p>
16394
16395 <ol>
16396 <li>
16397 <pre>template&lt;class U , class V&gt;
16398 requires HasAssign&lt;T1, const U&amp;&gt; &amp;&amp; HasAssign&lt;T2, const V&amp;&gt;
16399 pair&amp; operator=(const pair&lt;U , V&gt;&amp; p);
16400 </pre>
16401 </li>
16402 <li>
16403 <pre>requires MoveAssignable&lt;T1&gt; &amp;&amp; MoveAssignable&lt;T2&gt; pair&amp; operator=(pair&amp;&amp; p );
16404 </pre>
16405 </li>
16406 <li>
16407 <pre>template&lt;class U , class V&gt;
16408 requires HasAssign&lt;T1, RvalueOf&lt;U&gt;::type&gt; &amp;&amp; HasAssign&lt;T2, RvalueOf&lt;V&gt;::type&gt;
16409 pair&amp; operator=(pair&lt;U , V&gt;&amp;&amp; p);
16410 </pre>
16411 </li>
16412 </ol>
16413
16414 <p>
16415 It seems that the functionality of (2) is completely covered by (3), therefore
16416 (2) should be removed.
16417 </p>
16418
16419 <p><i>[
16420 Batavia (2009-05):
16421 ]</i></p>
16422
16423 <blockquote>
16424 <p>
16425 Bill believes the extra assignment operators are necessary for resolving
16426 ambiguities, but that does not mean it needs to be part of the specification.
16427 </p>
16428 <p>
16429 Move to Open.
16430 We recommend this be looked at in the context of the ongoing work
16431 related to the pair templates.
16432 </p>
16433 </blockquote>
16434
16435 <p><i>[
16436 2009-07 Frankfurt:
16437 ]</i></p>
16438
16439
16440 <blockquote>
16441 Leave this open pending the removal of concepts from the WD.
16442 </blockquote>
16443
16444
16445
16446 <p><b>Proposed resolution:</b></p>
16447 <ol type="A">
16448 <li>
16449 <p>
16450 In 20.3.3 [pairs] p. 1, class <tt>pair</tt> and just before p. 13 remove the declaration:
16451 </p>
16452
16453 <blockquote><pre>requires MoveAssignable&lt;T1&gt; &amp;&amp; MoveAssignable&lt;T2&gt; pair&amp; operator=(pair&amp;&amp; p );
16454 </pre></blockquote>
16455 </li>
16456
16457 <li>
16458 Remove p.13+p.14
16459 </li>
16460
16461 </ol>
16462
16463
16464
16465
16466
16467 <hr>
16468 <h3><a name="917"></a>917. Redundant move-assignment operator of <tt>tuple</tt> should be removed</h3>
16469 <p><b>Section:</b> 20.5.2.1 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
16470  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-04  <b>Last modified:</b> 2009-07-18</p>
16471 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.cnstr">active issues</a> in [tuple.cnstr].</p>
16472 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.cnstr">issues</a> in [tuple.cnstr].</p>
16473 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
16474 <p><b>Discussion:</b></p>
16475 <p><b>see also <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#916">916</a>.</b></p>
16476 <p>
16477 N2770 (and thus now the WP) removed the
16478 non-template move-assignment operator from tuple's class definition,
16479 but the latter individual member description does still provide this
16480 operator. Is this (a) an oversight and can it (b) be solved as part of an
16481 editorial process?
16482 </p>
16483
16484 <p><i>[
16485 Post Summit Daniel provided wording.
16486 ]</i></p>
16487
16488
16489 <p><i>[
16490 Batavia (2009-05):
16491 ]</i></p>
16492
16493 <blockquote>
16494 <p>
16495 We believe that the proposed resolution's part 1 is editorial.
16496 </p>
16497 <p>
16498 Regarding part 2, we either remove the specification as proposed,
16499 or else add back the declaration to which the specification refers.
16500 Alisdair and Bill prefer the latter.
16501 It is not immediately obvious whether the function is intended to be present.
16502 </p>
16503 <p>
16504 We recommend that the Project Editor restore the missing declaration
16505 and that we keep part 2 of the issue alive.
16506 </p>
16507 <p>
16508 Move to Open.
16509 </p>
16510 </blockquote>
16511
16512 <p><i>[
16513 2009-07 Frankfurt:
16514 ]</i></p>
16515
16516
16517 <blockquote>
16518 Leave this open pending the removal of concepts from the WD.
16519 </blockquote>
16520
16521
16522
16523 <p><b>Proposed resolution:</b></p>
16524 <ol>
16525 <li>
16526 <p>
16527 In 20.5.2 [tuple.tuple], class <tt>tuple</tt> just before member <tt>swap</tt> please
16528 change as indicated:
16529 </p>
16530 <p><i>[
16531 This fixes an editorial loss between N2798 to N2800
16532 ]</i></p>
16533
16534 <blockquote><pre>template &lt;class... UTypes&gt;
16535 requires HasAssign&lt;Types, const UTypes&amp;&gt;...
16536 <ins>tuple&amp; operator=(const pair&lt;UTypes...&gt;&amp;);</ins>
16537
16538 template &lt;class... UTypes&gt;
16539 requires HasAssign&lt;Types, RvalueOf&lt;UTypes&gt;::type&gt;...
16540 <ins>tuple&amp; operator=(pair&lt;UTypes...&gt;&amp;&amp;);</ins>
16541 </pre></blockquote>
16542 </li>
16543 <li>
16544 <p>
16545 In 20.5.2.1 [tuple.cnstr], starting just before p. 11 please remove
16546 as indicated:
16547 </p>
16548
16549 <blockquote><pre><del>requires MoveAssignable&lt;Types&gt;... tuple&amp; operator=(tuple&amp;&amp; u);</del>
16550 </pre>
16551 <blockquote>
16552 <p>
16553 <del>-11- <i>Effects:</i> Move-assigns each element of <tt>u</tt> to the corresponding
16554 element of <tt>*this</tt>.</del>
16555 </p>
16556 <p>
16557 <del>-12- <i>Returns:</i> <tt>*this</tt>.</del>
16558 </p>
16559 </blockquote>
16560 </blockquote>
16561 </li>
16562 </ol>
16563
16564
16565
16566
16567
16568 <hr>
16569 <h3><a name="919"></a>919. (forward_)list specialized remove algorithms are over constrained</h3>
16570 <p><b>Section:</b> 23.3.3.5 [forwardlist.ops], 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
16571  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2008-10-06  <b>Last modified:</b> 2009-07-21</p>
16572 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forwardlist.ops">active issues</a> in [forwardlist.ops].</p>
16573 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forwardlist.ops">issues</a> in [forwardlist.ops].</p>
16574 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
16575 <p><b>Discussion:</b></p>
16576 <p>
16577 The signatures of <tt>forwardlist::remove</tt> and <tt>list::remove</tt>
16578 defined in 23.3.3.5 [forwardlist.ops] before 11 + 23.3.4.4 [list.ops] before 15:
16579 </p>
16580
16581 <blockquote><pre>requires EqualityComparable&lt;T&gt; void remove(const T&amp; value);
16582 </pre></blockquote>
16583
16584 <p>
16585 are asymmetric to their predicate variants (which only require
16586 <tt>Predicate</tt>, <em>not</em> <tt>EquivalenceRelation</tt>) and with the free algorithm
16587 remove (which only require <tt>HasEqualTo</tt>). Also, nothing in the
16588 pre-concept WP
16589 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
16590 implies that <tt>EqualityComparable</tt> should
16591 be the intended requirement.
16592 </p>
16593
16594 <p><i>[
16595 Batavia (2009-05):
16596 ]</i></p>
16597
16598 <blockquote>
16599 <p>
16600 We agree with the proposed resolution,
16601 but would like additional input from concepts experts.
16602 </p>
16603 <p>
16604 Move to Review.
16605 </p>
16606 </blockquote>
16607
16608 <p><i>[
16609 2009-07-21 Alisdair adds:
16610 ]</i></p>
16611
16612
16613 <blockquote>
16614 Current rationale and wording for this issue is built around concepts. I
16615 suggest the issue reverts to Open status. &nbsp;I believe there is enough of
16616 an issue to review after concepts are removed from the WP to re-examine
16617 the issue in Santa Cruz, rather than resolve as NAD Concepts.
16618 </blockquote>
16619
16620
16621 <p><b>Proposed resolution:</b></p>
16622 <ol type="A">
16623 <li>
16624 <p>
16625 Replace in 23.3.3.5 [forwardlist.ops] before 11 and in 23.3.4.4 [list.ops] before 15
16626 </p>
16627
16628 <blockquote><pre>requires <del>EqualityComparable&lt;T&gt;</del> <ins>HasEqualTo&lt;T, T&gt;</ins> void remove(const T&amp; value);
16629 </pre></blockquote>
16630 </li>
16631 </ol>
16632
16633
16634
16635
16636
16637
16638 <hr>
16639 <h3><a name="920"></a>920. Ref-qualification support in the library</h3>
16640 <p><b>Section:</b> 20.7.15 [func.memfn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
16641  <b>Submitter:</b> Bronek Kozicki <b>Opened:</b> 2008-10-06  <b>Last modified:</b> 2009-05-23</p>
16642 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
16643 <p><b>Discussion:</b></p>
16644 <p>
16645 Daniel Krügler wrote:
16646 </p>
16647
16648 <blockquote>
16649 <p>
16650 Shouldn't above list be completed for &amp;- and &amp;&amp;-qualified
16651 member functions This would cause to add:
16652 </p>
16653 <blockquote><pre>template&lt;Returnable R, class T, CopyConstructible... Args&gt;
16654 unspecified mem_fn(R (T::* pm)(Args...) &amp;);
16655 template&lt;Returnable R, class T, CopyConstructible... Args&gt;
16656 unspecified mem_fn(R (T::* pm)(Args...) const &amp;);
16657 template&lt;Returnable R, class T, CopyConstructible... Args&gt;
16658 unspecified mem_fn(R (T::* pm)(Args...) volatile &amp;);
16659 template&lt;Returnable R, class T, CopyConstructible... Args&gt;
16660 unspecified mem_fn(R (T::* pm)(Args...) const volatile &amp;);
16661 template&lt;Returnable R, class T, CopyConstructible... Args&gt;
16662 unspecified mem_fn(R (T::* pm)(Args...) &amp;&amp;);
16663 template&lt;Returnable R, class T, CopyConstructible... Args&gt;
16664 unspecified mem_fn(R (T::* pm)(Args...) const &amp;&amp;);
16665 template&lt;Returnable R, class T, CopyConstructible... Args&gt;
16666 unspecified mem_fn(R (T::* pm)(Args...) volatile &amp;&amp;);
16667 template&lt;Returnable R, class T, CopyConstructible... Args&gt;
16668 unspecified mem_fn(R (T::* pm)(Args...) const volatile &amp;&amp;);
16669 </pre></blockquote>
16670
16671 </blockquote>
16672
16673 <p>
16674 yes, absolutely. Thanks for spotting this. Without this change <tt>mem_fn</tt>
16675 cannot be initialized from pointer to ref-qualified member function. I
16676 believe semantics of such function pointer is well defined.
16677 </p>
16678
16679 <p><i>[
16680 Post Summit Daniel provided wording.
16681 ]</i></p>
16682
16683
16684 <p><i>[
16685 Batavia (2009-05):
16686 ]</i></p>
16687
16688 <blockquote>
16689 <p>
16690 We need to think about whether we really want to go down the proposed path
16691 of combinatorial explosion.
16692 Perhaps a Note would suffice.
16693 </p>
16694 <p>
16695 We would really like to have an implementation before proceeding.
16696 </p>
16697 <p>
16698 Move to Open, and recommend this be deferred until after the next
16699 Committee Draft has been issued.
16700 </p>
16701 </blockquote>
16702
16703
16704 <p><b>Proposed resolution:</b></p>
16705 <ol>
16706 <li>
16707 <p>
16708 In 20.7 [function.objects]/2, header <tt>&lt;functional&gt;</tt> synopsis, just after
16709 the section "// 20.6.15, member function adaptors::" add the following
16710 declarations to the existing list:
16711 </p>
16712 <blockquote><pre>template&lt;Returnable R, class T, CopyConstructible... Args&gt;
16713   <i>unspecified</i> mem_fn(R (T::* pm)(Args...) &amp;);
16714 template&lt;Returnable R, class T, CopyConstructible... Args&gt;
16715   <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const &amp;);
16716 template&lt;Returnable R, class T, CopyConstructible... Args&gt;
16717   <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile &amp;);
16718 template&lt;Returnable R, class T, CopyConstructible... Args&gt;
16719   <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile &amp;);
16720 template&lt;Returnable R, class T, CopyConstructible... Args&gt;
16721   <i>unspecified</i> mem_fn(R (T::* pm)(Args...) &amp;&amp;);
16722 template&lt;Returnable R, class T, CopyConstructible... Args&gt;
16723   <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const &amp;&amp;);
16724 template&lt;Returnable R, class T, CopyConstructible... Args&gt;
16725   <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile &amp;&amp;);
16726 template&lt;Returnable R, class T, CopyConstructible... Args&gt;
16727   <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile &amp;&amp;);
16728 </pre></blockquote>
16729 </li>
16730 <li>
16731 <p>
16732 In 20.7.15 [func.memfn] add the following declarations to the existing
16733 list:
16734 </p>
16735 <blockquote><pre>template&lt;Returnable R, class T, CopyConstructible... Args&gt;
16736   <i>unspecified</i> mem_fn(R (T::* pm)(Args...) &amp;);
16737 template&lt;Returnable R, class T, CopyConstructible... Args&gt;
16738   <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const &amp;);
16739 template&lt;Returnable R, class T, CopyConstructible... Args&gt;
16740   <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile &amp;);
16741 template&lt;Returnable R, class T, CopyConstructible... Args&gt;
16742   <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile &amp;);
16743 template&lt;Returnable R, class T, CopyConstructible... Args&gt;
16744   <i>unspecified</i> mem_fn(R (T::* pm)(Args...) &amp;&amp;);
16745 template&lt;Returnable R, class T, CopyConstructible... Args&gt;
16746   <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const &amp;&amp;);
16747 template&lt;Returnable R, class T, CopyConstructible... Args&gt;
16748   <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile &amp;&amp;);
16749 template&lt;Returnable R, class T, CopyConstructible... Args&gt;
16750   <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile &amp;&amp;);
16751 </pre></blockquote>
16752 </li>
16753 </ol>
16754 <p>
16755 The following text, most notably p.2 and p.3 which discuss influence
16756 of the cv-qualification on the definition of the base class's first template
16757 parameter remains unchanged.
16758 </p>
16759
16760
16761
16762
16763
16764 <hr>
16765 <h3><a name="921"></a>921. Rational Arithmetic should use template aliases</h3>
16766 <p><b>Section:</b> 20.4.1 [ratio.ratio] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
16767  <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2008-10-07  <b>Last modified:</b> 2009-07-21</p>
16768 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ratio.ratio">active issues</a> in [ratio.ratio].</p>
16769 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ratio.ratio">issues</a> in [ratio.ratio].</p>
16770 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
16771 <p><b>Discussion:</b></p>
16772 <p>
16773 The compile-time functions that operate on <tt>ratio&lt;N,D&gt;</tt> require the
16774 cumbersome and error-prone "evaluation" of a <tt>type</tt> member using a
16775 meta-programming style that predates the invention of template aliases.
16776 Thus, multiplying three ratios <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> requires the expression:
16777 </p>
16778
16779 <blockquote><pre>ratio_multiply&lt;a, ratio_multiply&lt;b, c&gt;::type&gt;::type
16780 </pre></blockquote>
16781
16782 <p>
16783 The simpler expression:
16784 </p>
16785
16786 <blockquote><pre>ratio_multiply&lt;a, ratio_multiply&lt;b, c&gt;&gt;
16787 </pre></blockquote>
16788
16789 <p>
16790 Could be used by if template aliases were employed in the definitions.
16791 </p>
16792
16793 <p><i>[
16794 Post Summit:
16795 ]</i></p>
16796
16797
16798 <blockquote>
16799 <p>
16800 Jens: not a complete proposed resolution: "would need to make similar change"
16801 </p>
16802 <p>
16803 Consensus: We agree with the direction of the issue.
16804 </p>
16805 <p>
16806 Recommend Open.
16807 </p>
16808 </blockquote>
16809
16810 <p><i>[
16811 2009-05-11 Daniel adds:
16812 ]</i></p>
16813
16814
16815 <blockquote>
16816 <p>
16817 Personally I'm <em>not</em> in favor for the addition of:
16818 </p>
16819 <blockquote><pre>typedef ratio type;
16820 </pre></blockquote>
16821 <p>
16822 For a reader of the
16823 standard it's usage or purpose is unclear. I haven't seen similar examples
16824 of attempts to satisfy non-feature complete compilers.
16825 </p>
16826 </blockquote>
16827
16828 <p><i>[
16829 2009-05-11 Pablo adds:
16830 ]</i></p>
16831
16832
16833 <blockquote>
16834 <p>
16835 The addition of type to the <tt>ratio</tt> template allows the previous style
16836 (i.e., in the prototype implementations) to remain valid and permits the
16837 use of transitional library implementations for C++03 compilers.  I do
16838 not feel strongly about its inclusion, however, and leave it up to the
16839 reviewers to decide.
16840 </p>
16841 </blockquote>
16842
16843 <p><i>[
16844 Batavia (2009-05):
16845 ]</i></p>
16846
16847 <blockquote>
16848 Bill asks for additional discussion in the issue
16849 that spells out more details of the implementation.
16850 Howard points us to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#948">948</a>
16851 which has at least most of the requested details.
16852 Tom is strongly in favor of overflow-checking at compile time.
16853 Pete points out that there is no change of functionality implied.
16854 We agree with the proposed resolution,
16855 but recommend moving the issue to Review
16856 to allow time to improve the discussion if needed.
16857 </blockquote>
16858
16859 <p><i>[
16860 2009-07-21 Alisdair adds:
16861 ]</i></p>
16862
16863
16864 <blockquote>
16865 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1121">1121</a> for a potentially incompatible proposal.
16866 </blockquote>
16867
16868
16869 <p><b>Proposed resolution:</b></p>
16870
16871
16872  <ol start="0">
16873 <li>
16874 <p>
16875 In 20.4 [ratio]/3 change as indicated:
16876 </p>
16877
16878 <blockquote><pre>// ratio arithmetic
16879 template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_add<ins> = <em>see below</em></ins>;
16880 template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_subtract<ins> = <em>see below</em></ins>;
16881 template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_multiply<ins> = <em>see below</em></ins>;
16882 template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_divide<ins> = <em>see below</em></ins>;
16883 </pre></blockquote>
16884 </li>
16885 <li>
16886 <p>
16887 In 20.4.1 [ratio.ratio], change as indicated:
16888 </p>
16889 <blockquote><pre>namespace std {
16890   template &lt;intmax_t N, intmax_t D = 1&gt;
16891   class ratio {
16892   public:
16893     <ins>typedef ratio type;</ins>
16894     static const intmax_t num;
16895     static const intmax_t den;
16896   };
16897 }
16898 </pre></blockquote>
16899 </li>
16900 <li>
16901 <p>
16902 In 20.4.2 [ratio.arithmetic] change as indicated:
16903 </p>
16904
16905 <blockquote><pre>template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_add<ins> = <em>see below</em></ins><del>{
16906   typedef <em>see below</em> type;
16907 }</del>;
16908 </pre>
16909
16910 <blockquote>
16911 <p>
16912 1 The <del>nested typedef</del> type <tt><ins>ratio_add&lt;R1, R2&gt;</ins></tt>
16913 shall be a synonym for <tt>ratio&lt;T1, T2&gt;</tt>
16914 where <tt>T1</tt> has the value <tt>R1::num * R2::den + R2::num * R1::den</tt> and <tt>T2</tt>
16915 has the value <tt>R1::den * R2::den</tt>.
16916 </p>
16917 </blockquote>
16918 </blockquote>
16919 <blockquote><pre>template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_subtract<ins> = <em>see below</em></ins><del>{
16920   typedef <em>see below</em> type;
16921 }</del>;
16922 </pre>
16923 <blockquote>
16924 <p>
16925 2 The <del>nested typedef</del> type <tt><ins>ratio_subtract&lt;R1, R2&gt;</ins></tt>
16926 shall be a synonym for <tt>ratio&lt;T1, T2&gt;</tt>
16927 where <tt>T1</tt> has the value <tt>R1::num * R2::den - R2::num * R1::den</tt> and <tt>T2</tt>
16928 has the value <tt>R1::den * R2::den</tt>.
16929 </p>
16930 </blockquote>
16931 </blockquote>
16932 <blockquote><pre>template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_multiply<ins> = <em>see below</em></ins><del>{
16933   typedef <em>see below</em> type;
16934 }</del>;
16935 </pre>
16936 <blockquote>
16937 <p>
16938 3 The <del>nested typedef</del> type <tt><ins>ratio_multiply&lt;R1, R2&gt;</ins></tt>
16939 shall be a synonym for <tt>ratio&lt;T1, T2&gt;</tt>
16940 where <tt>T1</tt> has the value <tt>R1::num * R2::num</tt> and <tt>T2</tt> has the value <tt>R1::den * R2::den</tt>.
16941 </p>
16942 </blockquote>
16943 </blockquote>
16944 <blockquote><pre>template &lt;class R1, class R2&gt; <del>struct</del><ins>using</ins> ratio_divide<ins> = <em>see below</em></ins><del>{
16945   typedef <em>see below</em> type;
16946 }</del>;
16947 </pre>
16948 <blockquote>
16949 <p>
16950 4 The <del>nested typedef</del> type <tt><ins>ratio_divide&lt;R1, R2&gt;</ins></tt>
16951 shall be a synonym for <tt>ratio&lt;T1, T2&gt;</tt>
16952 where <tt>T1</tt> has the value <tt>R1::num * R2::den</tt> and <tt>T2</tt> has the value <tt>R1::den * R2::num</tt>.
16953 </p>
16954 </blockquote>
16955 </blockquote>
16956 </li>
16957 <li>
16958 <p>
16959 In 20.9.3.1 [time.duration.cons]/4 change as indicated:
16960 </p>
16961 <blockquote>
16962 <p>
16963 <i>Requires:</i> <tt>treat_as_floating_point&lt;rep&gt;::value</tt> shall be true or
16964 <tt>ratio_divide&lt;Period2, period&gt;::<del>type::</del>den</tt> shall be 1.[..]
16965 </p>
16966 </blockquote>
16967 </li>
16968 <li>
16969 <p>
16970 In 20.9.3.7 [time.duration.cast]/2 change as indicated:
16971 </p>
16972 <blockquote>
16973 <p>
16974 <i>Returns:</i> Let CF be <tt>ratio_divide&lt;Period, typename
16975 ToDuration::period&gt;<del>::type</del></tt>, and [..]
16976 </p>
16977 </blockquote>
16978 </li>
16979 </ol>
16980
16981
16982
16983
16984
16985 <hr>
16986 <h3><a name="923"></a>923. atomics with floating-point </h3>
16987 <p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
16988  <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2008-10-17  <b>Last modified:</b> 2009-05-01</p>
16989 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p>
16990 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p>
16991 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
16992 <p><b>Discussion:</b></p>
16993 <p>
16994 Right now, C++0x doesn't have <tt>atomic&lt;float&gt;</tt>. We're thinking of adding
16995 the words to support it for TR2 (note: that would be slightly
16996 post-C++0x). If we need it, we could probably add the words.
16997 </p>
16998 <p>
16999 <b>Proposed resolutions:</b> Using <tt>atomic&lt;FP&gt;::compare_exchange</tt> (weak or
17000 strong) should be either:
17001 </p>
17002
17003 <ol>
17004 <li>
17005 ill-formed, or
17006 </li>
17007 <li>
17008 well-defined.
17009 </li>
17010 </ol>
17011
17012 <p>
17013 I propose Option 1 for C++0x for expediency. If someone wants to argue
17014 for Option 2, they need to say what exactly they want <tt>compare_exchange</tt>
17015 to mean in this case (IIRC, C++0x doesn't even assume IEEE 754).
17016 </p>
17017
17018 <p><i>[
17019 Summit:
17020 ]</i></p>
17021
17022
17023 <blockquote>
17024 Move to open. Blocked until concepts for atomics are addressed.
17025 </blockquote>
17026
17027 <p><i>[
17028 Post Summit Anthony adds:
17029 ]</i></p>
17030
17031
17032 <blockquote>
17033 <p>
17034 Recommend NAD. C++0x does have <tt>std::atomic&lt;float&gt;</tt>, and both
17035 <tt>compare_exchange_weak</tt> and <tt>compare_exchange_strong</tt> are well-defined in
17036 this case. Maybe change the note in 29.6 [atomics.types.operations] paragraph 20 to:
17037 </p>
17038
17039 <blockquote>
17040 <p>
17041 [<i>Note:</i> The effect of the compare-and-exchange operations is
17042 </p>
17043 <blockquote><pre>if (!memcmp(object,expected,sizeof(*object)))
17044     *object = desired;
17045 else
17046     *expected = *object;
17047 </pre></blockquote>
17048
17049 <p>
17050 This may result in failed comparisons for values that compare equal if
17051 the underlying type has padding bits or alternate representations of
17052 the same value. <i>-- end note</i>]
17053 </p>
17054 </blockquote>
17055
17056 </blockquote>
17057
17058
17059
17060 <p><b>Proposed resolution:</b></p>
17061 <p>
17062 Change the note in 29.6 [atomics.types.operations] paragraph 20 to:
17063 </p>
17064
17065 <blockquote>
17066 <p>
17067 [<i>Note:</i> The effect of the compare-and-exchange operations is
17068 </p>
17069 <blockquote><pre>if (<del>*object == *expected</del> <ins>!memcmp(object,expected,sizeof(*object))</ins>)
17070     *object = desired;
17071 else
17072     *expected = *object;
17073 </pre></blockquote>
17074
17075 <p><ins>
17076 This may result in failed comparisons for values that compare equal if
17077 the underlying type has padding bits or alternate representations of
17078 the same value.</ins> <i>-- end note</i>]
17079 </p>
17080 </blockquote>
17081
17082
17083
17084
17085
17086
17087 <hr>
17088 <h3><a name="924"></a>924. structs with internal padding</h3>
17089 <p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
17090  <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2008-10-17  <b>Last modified:</b> 2009-03-22</p>
17091 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p>
17092 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p>
17093 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
17094 <p><b>Discussion:</b></p>
17095 <p>
17096 Right now, the <tt>compare_exchange_weak</tt> loop should rapidly converge on the
17097 padding contents. But <tt>compare_exchange_strong</tt> will require a bit more
17098 compiler work to ignore padding for comparison purposes.
17099 </p>
17100 <p>
17101 Note that this isn't a problem for structs with no padding, and we do
17102 already have one portable way to ensure that there is no padding that
17103 covers the key use cases: Have elements be the same type. I suspect that
17104 the greatest need is for a structure of two pointers, which has no
17105 padding problem. I suspect the second need is a structure of a pointer
17106 and some form of an integer. If that integer is <tt>intptr_t</tt>, there will be
17107 no padding.
17108 </p>
17109 <p>
17110 Related but separable issue: For unused bitfields, or other unused
17111 fields for that matter, we should probably say it's the programmer's
17112 responsibility to set them to zero or otherwise ensure they'll be
17113 ignored by <tt>memcmp</tt>.
17114 </p>
17115
17116 <p>
17117 <b>Proposed resolutions:</b> Using
17118 <tt>atomic&lt;struct-with-padding&gt;::compare_exchange_strong</tt> should be either:
17119 </p>
17120
17121 <ol>
17122 <li>
17123 ill-formed, or
17124 </li>
17125 <li>
17126 well-defined.
17127 </li>
17128 </ol>
17129
17130 <p>
17131 I propose Option 1 for C++0x for expediency, though I'm not sure how to
17132 say it. I would be happy with Option 2, which I believe would mean that
17133 <tt>compare_exchange_strong</tt> would be implemented to avoid comparing padding
17134 bytes, or something equivalent such as always zeroing out padding when
17135 loading/storing/comparing. (Either implementation might require compiler
17136 support.)
17137 </p>
17138
17139 <p><i>[
17140 Summit:
17141 ]</i></p>
17142
17143
17144 <blockquote>
17145 Move to open. Blocked until concepts for atomics are addressed.
17146 </blockquote>
17147
17148 <p><i>[
17149 Post Summit Anthony adds:
17150 ]</i></p>
17151
17152
17153 <blockquote>
17154 The resoultion of LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#923">923</a> should resolve this issue as well.
17155 </blockquote>
17156
17157
17158
17159 <p><b>Proposed resolution:</b></p>
17160 <p>
17161 </p>
17162
17163
17164
17165
17166
17167 <hr>
17168 <h3><a name="926"></a>926. Sequentially consistent fences, relaxed operations and modification order</h3>
17169 <p><b>Section:</b> 29.3 [atomics.order] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
17170  <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2008-10-19  <b>Last modified:</b> 2009-03-22</p>
17171 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.order">issues</a> in [atomics.order].</p>
17172 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
17173 <p><b>Discussion:</b></p>
17174 <p><b>Addresses UK 313</b></p>
17175
17176 <p>
17177 There was an interesting issue raised over on comp.programming.threads
17178 today regarding the following example
17179 </p>
17180
17181 <blockquote><pre>// Thread 1:
17182 x.store(1, memory_order_relaxed);           // SX
17183 atomic_thread_fence(memory_order_seq_cst);  // F1
17184 y.store(1, memory_order_relaxed);           // SY1
17185 atomic_thread_fence(memory_order_seq_cst);  // F2
17186 r1 = y.load(memory_order_relaxed);          // RY
17187
17188 // Thread 2:
17189 y.store(0, memory_order_relaxed);          // SY2
17190 atomic_thread_fence(memory_order_seq_cst); // F3
17191 r2 = x.load(memory_order_relaxed);         // RX
17192 </pre></blockquote>
17193
17194 <p>
17195 is the outcome <tt>r1 == 0</tt> and <tt>r2 == 0</tt> possible?
17196 </p>
17197 <p>
17198 I think the intent is that this is not possible, but I am not sure the
17199 wording guarantees that. Here is my analysis:
17200 </p>
17201 <p>
17202 Since all the fences are SC, there must be a total order between them.
17203 <tt>F1</tt> must be before <tt>F2</tt> in that order since they are in
17204 the same thread. Therefore <tt>F3</tt> is either before <tt>F1</tt>,
17205 between <tt>F1</tt> and <tt>F2</tt> or after <tt>F2</tt>.
17206 </p>
17207 <p>
17208 If <tt>F3</tt> is <em>after</em> <tt>F2</tt>, then we can apply 29.3 [atomics.order]p5 from
17209 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>:
17210 </p>
17211
17212 <blockquote>
17213 For atomic operations <tt>A</tt> and <tt>B</tt> on an atomic object
17214 <tt>M</tt>, where <tt>A</tt> modifies <tt>M</tt> and <tt>B</tt> takes
17215 its value, if there are <tt>memory_order_seq_cst</tt> fences <tt>X</tt>
17216 and <tt>Y</tt> such that <tt>A</tt> is sequenced before <tt>X</tt>,
17217 <tt>Y</tt> is sequenced before <tt>B</tt>, and <tt>X</tt> precedes
17218 <tt>Y</tt> in <tt>S</tt>, then <tt>B</tt> observes either the effects of
17219 <tt>A</tt> or a later modification of <tt>M</tt> in its modification
17220 order.
17221 </blockquote>
17222
17223 <p>
17224 In this case, <tt>A</tt> is <tt>SX</tt>, <tt>B</tt> is <tt>RX</tt>, the
17225 fence <tt>X</tt> is <tt>F2</tt> and the fence <tt>Y</tt> is <tt>F3</tt>,
17226 so <tt>RX</tt> must see 1.
17227 </p>
17228 <p>
17229 If <tt>F3</tt> is <em>before</em> <tt>F2</tt>, this doesn't apply, but
17230 <tt>F3</tt> can therefore be before or after <tt>F1</tt>.
17231 </p>
17232 <p>
17233 If <tt>F3</tt> is <em>after</em> <tt>F1</tt>, the same logic applies, but this
17234 time the fence <tt>X</tt> is <tt>F1</tt>. Therefore again, <tt>RX</tt>
17235 must see 1.
17236 </p>
17237 <p>
17238 Finally we have the case that <tt>F3</tt> is <em>before</em> <tt>F1</tt>
17239 in the SC ordering. There are now no guarantees about <tt>RX</tt>, and
17240 <tt>RX</tt> can see <tt>r2==0</tt>.
17241 </p>
17242 <p>
17243 We can apply 29.3 [atomics.order]p5 again. This time,
17244 <tt>A</tt> is <tt>SY2</tt>, <tt>B</tt> is <tt>RY</tt>, <tt>X</tt> is
17245 <tt>F3</tt> and <tt>Y</tt> is <tt>F1</tt>. Thus <tt>RY</tt> must observe
17246 the effects of <tt>SY2</tt> or a later modification of <tt>y</tt> in its
17247 modification order.
17248 </p>
17249 <p>
17250 Since <tt>SY1</tt> is sequenced before <tt>RY</tt>, <tt>RY</tt> must
17251 observe the effects of <tt>SY1</tt> or a later modification of
17252 <tt>y</tt> in its modification order.
17253 </p>
17254 <p>
17255 In order to ensure that <tt>RY</tt> sees <tt>(r1==1)</tt>, we must see
17256 that <tt>SY1</tt> is later in the modification order of <tt>y</tt> than
17257 <tt>SY2</tt>.
17258 </p>
17259 <p>
17260 We're now skating on thin ice. Conceptually, <tt>SY2</tt> happens-before
17261 <tt>F3</tt>, <tt>F3</tt> is SC-ordered before <tt>F1</tt>, <tt>F1</tt>
17262 happens-before <tt>SY1</tt>, so <tt>SY1</tt> is later in the
17263 modification order <tt>M</tt> of <tt>y</tt>, and <tt>RY</tt> must see
17264 the result of <tt>SY1</tt> (<tt>r1==1</tt>). However, I don't think the
17265 words are clear on that.
17266 </p>
17267
17268 <p><i>[
17269 Post Summit Hans adds:
17270 ]</i></p>
17271
17272
17273 <blockquote>
17274 <p>
17275 In my (Hans') view, our definition of fences will always be weaker than
17276 what particular hardware will guarantee.  <tt>Memory_order_seq_cst</tt> fences
17277 inherently don't guarantee sequential consistency anyway, for good
17278 reasons (e.g. because they can't enforce a total order on stores).
17279  Hence I don't think the issue demonstrates a gross failure to achieve
17280 what we intended to achieve.  The example in question is a bit esoteric.
17281  Hence, in my view, living with the status quo certainly wouldn't be a
17282 disaster either.
17283 </p>
17284 <p>
17285 In any case, we should probably add text along the lines of the
17286 following between p5 and p6 in 29.3 [atomics.order]:
17287 </p>
17288 <blockquote>
17289 [Note: <tt>Memory_order_seq_cst</tt> only ensures sequential consistency for a
17290 data-race-free program that uses exclusively <tt>memory_order_seq_cst</tt>
17291 operations.  Any use of weaker ordering will invalidate this guarantee
17292 unless extreme care is used.  In particular, <tt>memory_order_seq_cst</tt> fences
17293 only ensure a total order for the fences themselves.  They cannot, in
17294 general, be used to restore sequential consistency for atomic operations
17295 with weaker ordering specifications.]
17296 </blockquote>
17297
17298 <p>
17299 Also see thread beginning at c++std-lib-23271.
17300 </p>
17301
17302 </blockquote>
17303
17304 <p><i>[
17305 Herve's correction:
17306 ]</i></p>
17307
17308 <blockquote>
17309 <p>
17310 Minor point, and sorry for the knee jerk reaction: I admit to having
17311 no knowledge of Memory_order_seq_cst, but my former boss (John Lakos)
17312 has ingrained an automatic introspection on the use of "only".   I
17313 think you meant:
17314 </p>
17315
17316 <blockquote>
17317 [Note: <tt>Memory_order_seq_cst</tt> ensures sequential consistency only
17318 for . . . .  In particular, <tt>memory_order_seq_cst</tt> fences ensure a
17319 total order only for . . .
17320 </blockquote>
17321 <p>
17322 Unless, of course, <tt>Memory_order_seq_cst</tt> really do nothing but ensure
17323 sequential consistency for a data-race-free program that uses
17324 exclusively <tt>memory_order_seq_cst</tt> operations.
17325 </p>
17326 </blockquote>
17327
17328
17329
17330 <p><b>Proposed resolution:</b></p>
17331 <p>
17332 Add a new paragraph after 29.3 [atomics.order]p5 that says
17333 </p>
17334
17335 <blockquote>
17336 For atomic operations <tt>A</tt> and <tt>B</tt> on an atomic object
17337 <tt>M</tt>, where <tt>A</tt> and <tt>B</tt> modify <tt>M</tt>, if there
17338 are <tt>memory_order_seq_cst</tt> fences <tt>X</tt> and <tt>Y</tt> such
17339 that <tt>A</tt> is sequenced before <tt>X</tt>, <tt>Y</tt> is sequenced
17340 before <tt>B</tt>, and <tt>X</tt> precedes <tt>Y</tt> in <tt>S</tt>,
17341 then <tt>B</tt> occurs later than <tt>A</tt> in the modifiction order of
17342 <tt>M</tt>.
17343 </blockquote>
17344
17345
17346
17347
17348
17349 <hr>
17350 <h3><a name="929"></a>929. Thread constructor</h3>
17351 <p><b>Section:</b> 30.3.1.2 [thread.thread.constr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
17352  <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2008-10-23  <b>Last modified:</b> 2009-07-18</p>
17353 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.constr">active issues</a> in [thread.thread.constr].</p>
17354 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.constr">issues</a> in [thread.thread.constr].</p>
17355 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
17356 <p><b>Discussion:</b></p>
17357
17358 <p><b>Addresses UK 323</b></p>
17359
17360 <p>
17361 The <tt>thread</tt> constructor for starting a new thread with a function and
17362 arguments is overly constrained by the signature requiring rvalue
17363 references for <tt>func</tt> and <tt>args</tt> and the <tt>CopyConstructible</tt> requirements
17364 for the elements of <tt>args</tt>. The use of an rvalue reference for the
17365 function restricts the potential use of a plain function name, since
17366 the type of the bound parameter will be deduced to be a function
17367 reference and decay to pointer-to-function will not happen. This
17368 therefore complicates the implementation in order to handle a simple
17369 case. Furthermore, the use of rvalue references for args prevents the
17370 array to pointer decay. Since arrays are not <tt>CopyConstructible</tt> or even
17371 <tt>MoveConstructible</tt>, this essentially prevents the passing of arrays as
17372 parameters. In particular it prevents the passing of string literals.
17373 Consequently a simple case such as
17374 </p>
17375
17376 <blockquote><pre>void f(const char*);
17377 std::thread t(f,"hello");
17378 </pre></blockquote>
17379
17380 <p>
17381 is ill-formed since the type of the string literal is <tt>const char[6]</tt>.
17382 </p>
17383
17384 <p>
17385 By changing the signature to take all parameters by value we can
17386 eliminate the <tt>CopyConstructible</tt> requirement and permit the use of
17387 arrays, as the parameter passing semantics will cause the necessary
17388 array-to-pointer decay. They will also cause the function name to
17389 decay to a pointer to function and allow the implementation to handle
17390 functions and function objects identically.
17391 </p>
17392
17393 <p>
17394 The new signature of the <tt>thread</tt> constructor for a function and
17395 arguments is thus:
17396 </p>
17397
17398 <blockquote><pre>template&lt;typename F,typename... Args&gt;
17399 thread(F,Args... args);
17400 </pre></blockquote>
17401
17402 <p>
17403 Since the parameter pack <tt>Args</tt> can be empty, the single-parameter
17404 constructor that takes just a function by value is now redundant.
17405 </p>
17406
17407 <p><i>[
17408 Howard adds:
17409 ]</i></p>
17410
17411
17412 <blockquote>
17413 <p>
17414 I agree with everything Anthony says in this issue.  However I believe we
17415 can optimize in such a way as to get the pass-by-value behavior with the
17416 pass-by-rvalue-ref performance.  The performance difference is that the latter
17417 removes a <tt>move</tt> when passing in an lvalue.
17418 </p>
17419
17420 <p>
17421 This circumstance is very analogous to <tt>make_pair</tt> (20.3.3 [pairs])
17422 where we started with passing by const reference, changed to pass by value to
17423 get pointer decay, and then changed to pass by rvalue reference, but modified with
17424 <tt>decay&lt;T&gt;</tt> to retain the pass-by-value behavior.  If we were to
17425 apply the same solution here it would look like:
17426 </p>
17427
17428 <blockquote><pre><del>template &lt;class F&gt; explicit thread(F f);</del>
17429 template &lt;class F, class ...Args&gt; thread(F&amp;&amp; f, Args&amp;&amp;... args);
17430 </pre>
17431 <blockquote>
17432 <p>
17433 -4- <i>Requires:</i> <tt>F</tt> and each <tt>Ti</tt> in <tt>Args</tt> shall be <del><tt>CopyConstructible</tt>
17434 if an lvalue and otherwise</del> <tt>MoveConstructible</tt>.
17435 <tt><i>INVOKE</i>(f, w1, w2, ..., wN)</tt> (20.7.2 [func.require]) shall be a valid expression for
17436 some values <tt>w1, w2, ... , wN,</tt> where <tt>N == sizeof...(Args)</tt>.
17437 </p>
17438 <p>
17439 -5- <i>Effects:</i> Constructs an object of type <tt>thread</tt>
17440 <del>and executes <tt><i>INVOKE</i>(f, t1, t2, ..., tN)</tt> in a new
17441 thread of execution, where <tt>t1, t2, ..., tN</tt> are the values in <tt>args...</tt></del>.
17442 <ins>Constructs
17443 the following objects in memory which is accessible to a new thread of execution
17444 as if:</ins>
17445 </p>
17446 <blockquote><pre><ins>typename decay&lt;F&gt;::type g(std::forward&lt;F&gt;(f));</ins>
17447 <ins>tuple&lt;typename decay&lt;Args&gt;::type...&gt; w(std::forward&lt;Args&gt;(args)...);</ins>
17448 </pre></blockquote>
17449 <p>
17450 <ins>The new thread of
17451 execution executes <tt><i>INVOKE</i>(g, wi...)</tt> where the <tt>wi...</tt> refers
17452 to the elements stored in the <tt>tuple w</tt>.</ins>
17453 Any return value from <tt>g</tt> is ignored.
17454 <del>If <tt>f</tt> terminates with an uncaught exception, <tt>std::terminate()</tt> shall be called.</del>
17455 <ins>If the evaluation of <tt><i>INVOKE</i>(g,  wi...)</tt> terminates
17456 with an uncaught exception, <tt>std::terminate()</tt> shall be called [<i>Note:</i>
17457 <tt>std::terminate()</tt> could be called before entering <tt>g</tt>. -- <i>end note</i>]. Any
17458 exception thrown before the evaluation of <tt><i>INVOKE</i></tt> has started shall be
17459 catchable in the calling thread.</ins>
17460 </p>
17461 </blockquote>
17462 </blockquote>
17463
17464 <p>
17465 Text referring to when <tt>terminate()</tt> is called was contributed by Ganesh.
17466 </p>
17467
17468 </blockquote>
17469
17470 <p><i>[
17471 Batavia (2009-05):
17472 ]</i></p>
17473
17474 <blockquote>
17475 We agree with the proposed resolution,
17476 but would like the final sentence to be reworded
17477 since "catchable" is not a term of art (and is used nowhere else).
17478 </blockquote>
17479
17480 <p><i>[
17481 2009-07 Frankfurt:
17482 ]</i></p>
17483
17484
17485 <blockquote>
17486 <p>
17487 This is linked to
17488 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2901.pdf">N2901</a>.
17489 </p>
17490 <p>
17491 Howard to open a separate issue to remove (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1176">1176</a>).
17492 </p>
17493 <p>
17494 In Frankfurt there is no consensus for removing the variadic constructor.
17495 </p>
17496 </blockquote>
17497
17498
17499
17500 <p><b>Proposed resolution:</b></p>
17501 <p>
17502 Modify the class definition of <tt>std::thread</tt> in 30.3.1 [thread.thread.class] to remove the
17503 following signature:
17504 </p>
17505
17506 <blockquote><pre><del>template&lt;class F&gt; explicit thread(F f);</del>
17507 template&lt;class F, class ... Args&gt; <ins>explicit</ins> thread(F&amp;&amp; f, Args&amp;&amp; ... args);
17508 </pre></blockquote>
17509
17510 <p>
17511 Modify 30.3.1.2 [thread.thread.constr] to replace the constructors prior to paragraph 4 with
17512 the single constructor as above. Replace paragraph 4 - 6 with the
17513 following:
17514 </p>
17515
17516 <blockquote>
17517 <p>
17518 -4- <i>Requires:</i> <tt>F</tt> and each <tt>Ti</tt> in <tt>Args</tt> shall be <del><tt>CopyConstructible</tt>
17519 if an lvalue and otherwise</del> <tt>MoveConstructible</tt>.
17520 <tt><i>INVOKE</i>(f, w1, w2, ..., wN)</tt> (20.7.2 [func.require]) shall be a valid expression for
17521 some values <tt>w1, w2, ... , wN,</tt> where <tt>N == sizeof...(Args)</tt>.
17522 </p>
17523 <p>
17524 -5- <i>Effects:</i> Constructs an object of type <tt>thread</tt>
17525 <del>and executes <tt><i>INVOKE</i>(f, t1, t2, ..., tN)</tt> in a new
17526 thread of execution, where <tt>t1, t2, ..., tN</tt> are the values in <tt>args...</tt></del>.
17527 <ins>Constructs
17528 the following objects:</ins>
17529 </p>
17530 <blockquote><pre><ins>typename decay&lt;F&gt;::type g(std::forward&lt;F&gt;(f));</ins>
17531 <ins>tuple&lt;typename decay&lt;Args&gt;::type...&gt; w(std::forward&lt;Args&gt;(args)...);</ins>
17532 </pre></blockquote>
17533 <p>
17534 <ins>and executes <tt><i>INVOKE</i>(g, wi...)</tt> in a new thread of execution.
17535 These objects shall be destroyed when the new thread of execution completes.</ins>
17536 Any return value from <tt>g</tt> is ignored.
17537 <del>If <tt>f</tt> terminates with an uncaught exception, <tt>std::terminate()</tt> shall be called.</del>
17538 <ins>If the evaluation of <tt><i>INVOKE</i>(g,  wi...)</tt> terminates
17539 with an uncaught exception, <tt>std::terminate()</tt> shall be called [<i>Note:</i>
17540 <tt>std::terminate()</tt> could be called before entering <tt>g</tt>. -- <i>end note</i>]. Any
17541 exception thrown before the evaluation of <tt><i>INVOKE</i></tt> has started shall be
17542 catchable in the calling thread.</ins>
17543 </p>
17544 <p>
17545 -6- <i>Synchronization:</i> The invocation of the constructor <i>happens before</i> the
17546 invocation of <del><tt>f</tt></del> <ins><tt>g</tt></ins>.
17547 </p>
17548 </blockquote>
17549
17550
17551
17552
17553
17554
17555 <hr>
17556 <h3><a name="930"></a>930. Access to std::array data as built-in array type</h3>
17557 <p><b>Section:</b> 23.3.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
17558  <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2008-11-17  <b>Last modified:</b> 2009-07-31</p>
17559 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p>
17560 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
17561 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
17562 <p><b>Discussion:</b></p>
17563
17564 <p>
17565 The Working Draft (N2798) allows access to the elements of
17566 <tt>std::array</tt> by its <tt>data()</tt> member function:
17567 </p>
17568
17569 <blockquote>
17570
17571 <h5>23.2.1.4 array::data [array.data]</h5>
17572 <pre> T *data();
17573  const T *data() const;
17574 </pre>
17575 <ol><li>
17576  Returns: elems.
17577 </li></ol>
17578 </blockquote>
17579
17580 <p>
17581 Unfortunately, the result of <tt>std::array::data()</tt> cannot be bound
17582 to a reference to a built-in array of the type of <tt>array::elems</tt>.
17583 And <tt>std::array</tt> provides no other way to get a reference to
17584 <tt>array::elems</tt>.
17585 This hampers the use of <tt>std::array</tt>, for example when trying to
17586 pass its data to a C style API function:
17587 </p>
17588
17589 <pre> // Some C style API function.
17590  void set_path( char (*)[MAX_PATH] );
17591
17592  std::array&lt;char,MAX_PATH&gt; path;
17593  set_path( path.data() );  // error
17594  set_path( &amp;(path.data()) );  // error
17595 </pre>
17596
17597  <p>
17598 Another example, trying to pass the array data to an instance of another
17599 C++ class:
17600 </p>
17601
17602 <pre> // Represents a 3-D point in space.
17603  class three_d_point {
17604  public:
17605    explicit three_d_point(const double (&amp;)[3]);
17606  };
17607
17608  const std::array&lt;double,3&gt; coordinates = { 0, 1, 2 };
17609  three_d_point point1( coordinates.data() );  // error.
17610  three_d_point point2( *(coordinates.data()) );  // error.
17611 </pre>
17612
17613 <p>
17614 A user might be tempted to use <tt>std::array::elems</tt> instead, but
17615 doing so isn't recommended, because <tt>std::array::elems</tt> is "for
17616 exposition only".  Note that Boost.Array users might already use
17617 <tt>boost::array::elems</tt>, as its documentation doesn't explicitly
17618 state that <tt>boost::array::elems</tt> is for exposition only:
17619 http://www.boost.org/doc/libs/1_36_0/doc/html/boost/array.html
17620 </p>
17621 <p>
17622 I can think of three options to solve this issue:
17623 </p>
17624 <ol><li>
17625 Remove the words "exposition only" from the definition of
17626 <tt>std::array::elems</tt>, as well as the note saying that "elems is
17627 shown for exposition only."
17628 </li><li>
17629 Change the signature of <tt>std::array::data()</tt>, so that it would
17630 return a reference to the built-in array, instead of a pointer to its
17631 first element.
17632 </li><li>
17633 Add extra member functions, returning a reference to the built-in array.
17634 </li></ol>
17635 <p>
17636 Lawrence Crowl wrote me that it might be better to leave
17637 <tt>std::array::elems</tt> "for exposition only", to allow alternate
17638 representations to allocate the array data dynamically.  This might be
17639 of interest to the embedded community, having to deal with very limited
17640 stack sizes.
17641 </p>
17642 <p>
17643 The second option, changing the return type of
17644 <tt>std::array::data()</tt>, would break backward compatible to current
17645 Boost and TR1 implementations, as well as to the other contiguous
17646 container (<tt>vector</tt> and <tt>string</tt>) in a very subtle way.
17647 For example, the following call to <tt>std::swap</tt> currently swap two
17648 locally declared pointers <tt>(data1, data2)</tt>, for any container
17649 type <tt>T</tt> that has a <tt>data()</tt> member function. When
17650 <tt>std::array::data()</tt> is changed to return a reference, the
17651 <tt>std::swap</tt> call may swap the container elements instead.
17652 </p>
17653
17654 <pre> template &lt;typename T&gt;
17655  void func(T&amp; container1, T&amp; container2)
17656  {
17657    // Are data1 and data2 pointers or references?
17658    auto data1 = container1.data();
17659    auto data2 = container2.data();
17660
17661    // Will this swap two local pointers, or all container elements?
17662    std::swap(data1, data2);
17663  }
17664 </pre>
17665
17666 <p>
17667 The following concept is currently satisfied by all contiguous
17668 containers, but it no longer is for <tt>std::array</tt>, when
17669 <tt>array::data()</tt>
17670 is changed to return a reference (tested on ConceptGCC Alpha 7):
17671 </p>
17672
17673 <pre> auto concept ContiguousContainerConcept&lt;typename T&gt;
17674  {
17675    typename value_type = typename T::value_type;
17676    const value_type * T::data() const;
17677  }
17678 </pre>
17679
17680 <p>
17681 Still it's worth considering having <tt>std::array::data()</tt> return a
17682 reference, because it might be the most intuitive option, from a user's
17683 point of view.  Nicolai Josuttis (who wrote <tt>boost::array</tt>)
17684 mailed me that he very much prefers this option.
17685 </p>
17686 <p>
17687 Note that for this option, the definition of <tt>data()</tt> would also
17688 need to be revised for zero-sized arrays, as its return type cannot be a
17689 reference to a zero-sized built-in array.  Regarding zero-sized array,
17690 <tt>data()</tt> could throw an exception.  Or there could be a partial
17691 specialization of <tt>std::array</tt> where <tt>data()</tt> returns
17692 <tt>T*</tt> or gets removed.
17693 </p>
17694 <p>
17695 Personally I prefer the third option, adding a new member function to
17696 <tt>std::array</tt>, overloaded for const and non-const access,
17697 returning a reference to the built-in array, to avoid those compatible
17698 issues. I'd propose naming the function <tt>std::array::c_array()</tt>,
17699 which sounds intuitive to me. Note that <tt>boost::array</tt> already
17700 has a <tt>c_array()</tt> member, returning a pointer, but Nicolai told
17701 me that this one is only there for historical reasons. (Otherwise a name
17702 like <tt>std::array::native_array()</tt> or
17703 <tt>std::array::builtin_array()</tt> would also be fine with me.)
17704 According to my proposed resolution, a zero-sized <tt>std::array</tt> does not need
17705 to have <tt>c_array()</tt>, while it is still required to have
17706 <tt>data()</tt> functions.
17707 </p>
17708
17709 <p><i>[
17710 Post Summit:
17711 ]</i></p>
17712
17713
17714 <blockquote>
17715
17716 <p>
17717 Alisdair: Don't like p4 suggesting implementation-defined behaviour.
17718 </p>
17719 <p>
17720 Walter: What about an explicit conversion operator, instead of adding
17721 the new member function?
17722 </p>
17723 <p>
17724 Alisdair: Noodling about:
17725 </p>
17726 <blockquote><pre>template&lt;size_t N, ValueType T&gt;
17727 struct array
17728 {
17729   T elems[N];
17730
17731 // fantasy code starts here
17732
17733 // crazy decltype version for grins only
17734 //requires True&lt;(N&gt;0)&gt;
17735 //explict operator decltype(elems) &amp; () { return elems; }
17736
17737 // conversion to lvalue ref
17738 requires True&lt;(N&gt;0)&gt;
17739 explict operator T(&amp;)[N] () &amp; { return elems; }
17740
17741 // conversion to const lvalue ref
17742 requires True&lt;(N&gt;0)&gt;
17743 explict operator const T(&amp;)[N] () const &amp; { return elems; }
17744
17745 // conversion to rvalue ref using ref qualifiers
17746 requires True&lt;(N&gt;0)&gt;
17747 explict operator T(&amp;&amp;)[N] () &amp;&amp; { return elems; }
17748
17749 // fantasy code ends here
17750
17751 explicit operator bool() { return true; }
17752 };
17753 </pre></blockquote>
17754
17755 <p>
17756 This seems legal but odd. Jason Merrill says currently a CWG issue 613
17757 on the non-static data member that fixes the error that current G++
17758 gives for the non-explicit, non-conceptualized version of this. Verdict
17759 from human compiler: seems legal.
17760 </p>
17761 <p>
17762 Some grumbling about zero-sized arrays being allowed and supported.
17763 </p>
17764 <p>
17765 Walter: Would this address the issue? Are we inclined to go this route?
17766 </p>
17767 <p>
17768 Alan: What would usage look like?
17769 </p>
17770 <blockquote><pre>// 3-d point in space
17771 struct three_d_point
17772 {
17773   explicit three_d_point(const double (&amp;)[3]);
17774 };
17775
17776 void sink(double*);
17777
17778 const std::array&lt;double, 3&gt; coordinates = { 0, 1, 2 };
17779 three_d_point point1( coordinates.data() ); //error
17780 three_d_point point2( *(coordinates.data()) ); // error
17781 three_d_point point3( coordinates ); // yay!
17782
17783 sink(cooridinates); // error, no conversion
17784 </pre></blockquote>
17785
17786 <p>
17787 Recommended Open with new wording. Take the required clause and add the
17788 explicit conversion operators, not have a <tt>typedef</tt>. At issue still is use
17789 <tt>decltype</tt> or use <tt>T[N]</tt>. In favour of using <tt>T[N]</tt>, even though use of
17790 <tt>decltype</tt> is specially clever.
17791 </p>
17792
17793 </blockquote>
17794
17795 <p><i>[
17796 Post Summit, further discussion in the thread starting with c++std-lib-23215.
17797 ]</i></p>
17798
17799
17800 <p><i>[
17801 2009-07 post-Frankfurt (Saturday afternoon group):
17802 ]</i></p>
17803
17804
17805 <blockquote>
17806 <p>
17807 The idea to resolve the issue by adding explicit conversion operators
17808 was abandoned, because it would be inconvenient to use, especially when
17809 passing the array to a template function, as mentioned by Daniel. So we
17810 reconsidered the original proposed resolution, which appeared
17811 acceptable, except for its proposed changes to 23.3.1.6 [array.zero], which
17812 allowed <tt>c_array_type</tt> and <tt>c_array()</tt> to be absent for a zero-sized array.
17813 Alisdair argued that such wording would disallow certain generic use
17814 cases. New wording for 23.3.1.6 [array.zero] was agreed upon (Howard: and
17815 is reflected in the proposed resolution).
17816 </p>
17817 <p>
17818 Move to Review
17819 </p>
17820 </blockquote>
17821
17822 <p><i>[
17823 2009-07-31 Alisdair adds:
17824 ]</i></p>
17825
17826
17827 <blockquote>
17828 <p>
17829 I will be unhappy voting the proposed resolution for 930 past review
17830 until we have implementation experience with reference qualifiers.
17831 Specifically, I want to understand the impact of the missing overload
17832 for <tt>const &amp;&amp;</tt> (if any.)
17833 </p>
17834
17835 <p>
17836 If we think the issue is important enough it might be worthwhile
17837 stripping the ref qualifiers for easy progress next meeting, and opening
17838 yet another issue to put them back with experience.
17839 </p>
17840
17841 <p>
17842 Recommend deferring any decision on splitting the issue until we get LWG
17843 feedback next meeting - I may be the lone dissenting voice if others are
17844 prepared to proceed without it.
17845 </p>
17846 </blockquote>
17847
17848
17849 <p><b>Proposed resolution:</b></p>
17850 <p>
17851 Add to the template definition of array, 23.3.1 [array]/3:
17852 </p>
17853
17854 <blockquote>
17855 <pre><ins>
17856 typedef T c_array_type[N];
17857 c_array_type &amp; c_array() &amp;;
17858 c_array_type &amp;&amp; c_array() &amp;&amp;;
17859 const c_array_type &amp; c_array() const &amp;;
17860 </ins>
17861 </pre>
17862 </blockquote>
17863
17864 <p>
17865 Add the following subsection to 23.3.1 [array], after 23.3.1.4 [array.data]:
17866 </p>
17867
17868 <blockquote>
17869 <h5><ins>23.2.1.5 array::c_array [array.c_array]</ins></h5>
17870     <pre><ins>
17871 c_array_type &amp; c_array() &amp;;
17872 c_array_type &amp;&amp; c_array() &amp;&amp;;
17873 const c_array_type &amp; c_array() const &amp;;
17874 </ins></pre>
17875 <blockquote>
17876 <p>
17877 <ins><i>Returns:</i> <tt>elems</tt>.</ins>
17878 </p>
17879 </blockquote>
17880
17881 </blockquote>
17882
17883
17884
17885 <p>
17886 Change Zero sized arrays 23.3.1.6 [array.zero]:
17887 </p>
17888
17889 <blockquote>
17890
17891 <p>-2- ...</p>
17892
17893 <p><ins>
17894 The type <tt>c_array_type</tt> is unspecified for a zero-sized array.
17895 </ins></p>
17896
17897 <p>
17898 -3- The effect of calling <ins><tt>c_array()</tt>,</ins> <tt>front()</tt><ins>,</ins> or
17899 <tt>back()</tt> for a zero-sized array is implementation defined.
17900 </p>
17901 </blockquote>
17902
17903
17904
17905
17906
17907
17908 <hr>
17909 <h3><a name="932"></a>932. <tt>unique_ptr(pointer p)</tt> for pointer deleter types</h3>
17910 <p><b>Section:</b> 20.8.9.2.1 [unique.ptr.single.ctor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
17911  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-11-26  <b>Last modified:</b> 2009-07-27</p>
17912 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single.ctor">active issues</a> in [unique.ptr.single.ctor].</p>
17913 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.ctor">issues</a> in [unique.ptr.single.ctor].</p>
17914 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
17915 <p><b>Discussion:</b></p>
17916
17917 <p><b>Addresses US 79</b></p>
17918
17919 <p>
17920 20.8.9.2.1 [unique.ptr.single.ctor]/5 no longer requires for <tt>D</tt>
17921 not to be a pointer type.  I believe this restriction was accidently removed
17922 when we relaxed the completeness reuqirements on <tt>T</tt>. The restriction
17923 needs to be put back in.  Otherwise we have a run time failure that could
17924 have been caught at compile time:
17925 </p>
17926
17927 <blockquote><pre>{
17928 unique_ptr&lt;int, void(*)(void*)&gt; p1(malloc(sizeof(int)));  <font color="#c80000">// should not compile</font>
17929 }  <font color="#c80000">// p1.~unique_ptr() dereferences a null function pointer</font>
17930 unique_ptr&lt;int, void(*)(void*)&gt; p2(malloc(sizeof(int)), free);  <font color="#c80000">// ok</font>
17931 </pre></blockquote>
17932
17933 <p><i>[
17934 Post Summit:
17935 ]</i></p>
17936
17937
17938 <blockquote>
17939 Recommend Tentatively Ready.
17940 </blockquote>
17941
17942 <p><i>[
17943 2009-07 Frankfurt
17944 ]</i></p>
17945
17946
17947 <blockquote>
17948 Moved from Tentatively Ready to Open only because the wording needs to be
17949 improved for enable_if type constraining, possibly following Robert's
17950 formula.
17951 </blockquote>
17952
17953 <p><i>[
17954 2009-07 Frankfurt:
17955 ]</i></p>
17956
17957
17958 <blockquote>
17959 <p>
17960 We need to consider whether some requirements in the Requires paragraphs
17961 of [unique.ptr] should instead be Remarks.
17962 </p>
17963 <p>
17964 Leave Open. Howard to provide wording, and possibly demonstrate how this
17965 can be implemented using enable_if.
17966 </p>
17967 </blockquote>
17968
17969 <p><i>[
17970 2009-07-27 Howard adds:
17971 ]</i></p>
17972
17973
17974 <blockquote>
17975 <p>
17976 The two constructors to which this issue applies are not easily constrained
17977 with <tt>enable_if</tt> as they are not templated:
17978 </p>
17979
17980 <blockquote><pre>unique_ptr();
17981 explicit unique_ptr(pointer p);
17982 </pre></blockquote>
17983
17984 <p>
17985 To "SFINAE" these constructors away would take heroic effort such as specializing
17986 the entire <tt>unique_ptr</tt> class template on pointer deleter types.  There
17987 is insufficient motivation for such heroics.  Here is the expected and
17988 reasonable implementation for these constructors:
17989 </p>
17990
17991 <blockquote><pre>unique_ptr()
17992     : ptr_(pointer())
17993     {
17994         static_assert(!is_pointer&lt;deleter_type&gt;::value,
17995             "unique_ptr constructed with null function pointer deleter");
17996     }
17997 explicit unique_ptr(pointer p)
17998     : ptr_(p)
17999     {
18000         static_assert(!is_pointer&lt;deleter_type&gt;::value,
18001             "unique_ptr constructed with null function pointer deleter");
18002     }
18003 </pre></blockquote>
18004
18005 <p>
18006 I.e. just use <tt>static_assert</tt> to verify that the constructor is not
18007 instantiated with a function pointer for a deleter.  The compiler will automatically
18008 take care of issuing a diagnostic if the deleter is a reference type (uninitialized
18009 reference error).
18010 </p>
18011
18012 <p>
18013 In keeping with our discussions in Frankfurt, I'm moving this requirement on
18014 the implementation from the Requires paragraph to a Remarks paragraph.
18015 </p>
18016
18017 </blockquote>
18018
18019
18020
18021 <p><b>Proposed resolution:</b></p>
18022 <p>
18023 Change the description of the default constructor in 20.8.9.2.1 [unique.ptr.single.ctor]:
18024 </p>
18025
18026 <blockquote><pre>unique_ptr();
18027 </pre>
18028 <blockquote>
18029 <p>
18030 -1- <i>Requires:</i> <tt>D</tt> shall be default constructible, and that construction
18031 shall not throw an exception. <del><tt>D</tt> shall
18032 not be a reference type or pointer type (diagnostic required).</del>
18033 </p>
18034 <p>...</p>
18035 <ins><i>Remarks:</i> A diagnostic shall be emitted if this constructor is instantiated
18036 when <tt>D</tt> is a pointer type or reference type.</ins>
18037 </blockquote>
18038 </blockquote>
18039
18040 <p>
18041 Add  after 20.8.9.2.1 [unique.ptr.single.ctor]/8:
18042 </p>
18043
18044 <blockquote><pre>unique_ptr(pointer p);
18045 </pre>
18046 <blockquote>
18047 <p>...</p>
18048 <ins><i>Remarks:</i> A diagnostic shall be emitted if this constructor is instantiated
18049 when <tt>D</tt> is a pointer type or reference type.</ins>
18050 </blockquote>
18051 </blockquote>
18052
18053
18054
18055
18056
18057 <hr>
18058 <h3><a name="933"></a>933. Unique_ptr defect</h3>
18059 <p><b>Section:</b> 20.8.9.2.5 [unique.ptr.single.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
18060  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-11-27  <b>Last modified:</b> 2009-05-23</p>
18061 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.modifiers">issues</a> in [unique.ptr.single.modifiers].</p>
18062 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
18063 <p><b>Discussion:</b></p>
18064 <p>
18065 If we are supporting stateful deleters, we need an overload for
18066 <tt>reset</tt> that
18067 takes a deleter as well.
18068 </p>
18069
18070 <blockquote><pre>void reset( pointer p, deleter_type d);
18071 </pre></blockquote>
18072
18073 <p>
18074 We probably need two overloads to support move-only deleters, and
18075 this
18076 sounds uncomfortably like the two constructors I have been ignoring
18077 for
18078 now...
18079 </p>
18080
18081 <p><i>[
18082 Batavia (2009-05):
18083 ]</i></p>
18084
18085 <blockquote>
18086 <p>
18087 Howard comments that we have the functionality via move-assigment.
18088 </p>
18089 <p>
18090 Move to Open.
18091 </p>
18092 </blockquote>
18093
18094
18095 <p><b>Proposed resolution:</b></p>
18096 <p>
18097 </p>
18098
18099
18100
18101
18102
18103 <hr>
18104 <h3><a name="934"></a>934. <tt>duration</tt> is missing <tt>operator%</tt></h3>
18105 <p><b>Section:</b> 20.9.3 [time.duration] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
18106  <b>Submitter:</b> Terry Golubiewski <b>Opened:</b> 2008-11-30  <b>Last modified:</b> 2009-07-27</p>
18107 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.duration">active issues</a> in [time.duration].</p>
18108 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration">issues</a> in [time.duration].</p>
18109 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
18110 <p><b>Discussion:</b></p>
18111
18112 <p><b>Addresses US 81</b></p>
18113
18114 <p>
18115 <tt>duration</tt> is missing <tt>operator%</tt>.  This operator is convenient
18116 for computing where in a time frame a given <tt>duration</tt> lies.  A
18117 motivating example is converting a <tt>duration</tt> into a "broken-down"
18118 time duration such as hours::minutes::seconds:
18119 </p>
18120
18121 <blockquote><pre>class ClockTime
18122 {
18123     typedef std::chrono::hours hours;
18124     typedef std::chrono::minutes minutes;
18125     typedef std::chrono::seconds seconds;
18126 public:
18127     hours hours_;
18128     minutes minutes_;
18129     seconds seconds_;
18130
18131     template &lt;class Rep, class Period&gt;
18132       explicit ClockTime(const std::chrono::duration&lt;Rep, Period&gt;&amp; d)
18133         : hours_  (std::chrono::duration_cast&lt;hours&gt;  (d)),
18134           minutes_(std::chrono::duration_cast&lt;minutes&gt;(d % hours(1))),
18135           seconds_(std::chrono::duration_cast&lt;seconds&gt;(d % minutes(1)))
18136           {}
18137 };
18138 </pre></blockquote>
18139
18140 <p><i>[
18141 Summit:
18142 ]</i></p>
18143
18144
18145 <blockquote>
18146 Agree except that there is a typo in the proposed resolution. The member
18147 operators should be operator%=.
18148 </blockquote>
18149
18150 <p><i>[
18151 Batavia (2009-05):
18152 ]</i></p>
18153
18154 <blockquote>
18155 We agree with the proposed resolution.
18156 Move to Tentatively Ready.
18157 </blockquote>
18158
18159 <p><i>[
18160 2009-07 Frankfurt
18161 ]</i></p>
18162
18163
18164 <blockquote>
18165 Moved from Tentatively Ready to Open only because the wording needs to be
18166 improved for enable_if type constraining, possibly following Robert's
18167 formula.
18168 </blockquote>
18169
18170 <p><i>[
18171 2009-07 Frankfurt:
18172 ]</i></p>
18173
18174
18175 <blockquote>
18176 <p>
18177 Howard to open a separate issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1177">1177</a>) to handle the removal of member
18178 functions from overload sets, provide wording, and possibly demonstrate
18179 how this can be implemented using enable_if (see <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#947">947</a>).
18180 </p>
18181 <p>
18182 Move to Ready.
18183 </p>
18184 </blockquote>
18185
18186
18187
18188 <p><b>Proposed resolution:</b></p>
18189 <p>
18190 Add to the synopsis in 20.9 [time]:
18191 </p>
18192
18193 <blockquote><pre>template &lt;class Rep1, class Period, class Rep2&gt;
18194   duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
18195   operator%(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
18196 template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
18197   typename common_type&lt;duration&lt;Rep1, Period1&gt;, duration&lt;Rep2, Period2&gt;&gt;::type
18198   operator%(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
18199 </pre></blockquote>
18200
18201 <p>
18202 Add to the synopsis of <tt>duration</tt> in 20.9.3 [time.duration]:
18203 </p>
18204
18205 <blockquote><pre>template &lt;class Rep, class Period = ratio&lt;1&gt;&gt;
18206 class duration {
18207 public:
18208   ...
18209   <ins>duration&amp; operator%=(const rep&amp; rhs);</ins>
18210   <ins>duration&amp; operator%=(const duration&amp; d);</ins>
18211   ...
18212 };
18213 </pre></blockquote>
18214
18215 <p>
18216 Add to 20.9.3.3 [time.duration.arithmetic]:
18217 </p>
18218
18219 <blockquote>
18220 <pre>duration&amp; operator%=(const rep&amp; rhs);
18221 </pre>
18222 <blockquote>
18223 <p>
18224 <i>Effects:</i> <tt>rep_ %= rhs</tt>.
18225 </p>
18226 <p>
18227 <i>Returns:</i> <tt>*this</tt>.
18228 </p>
18229 </blockquote>
18230
18231 <pre>duration&amp; operator%=(const duration&amp; d);
18232 </pre>
18233 <blockquote>
18234 <p>
18235 <i>Effects:</i> <tt>rep_ %= d.count()</tt>.
18236 </p>
18237 <p>
18238 <i>Returns:</i> <tt>*this</tt>.
18239 </p>
18240 </blockquote>
18241 </blockquote>
18242
18243 <p>
18244 Add to 20.9.3.5 [time.duration.nonmember]:
18245 </p>
18246
18247 <blockquote>
18248
18249 <pre>template &lt;class Rep1, class Period, class Rep2&gt;
18250   duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
18251   operator%(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
18252 </pre>
18253 <blockquote>
18254 <p>
18255 <i>Requires:</i> <tt>Rep2</tt> shall be implicitly convertible to <tt>CR(Rep1, Rep2)</tt> and
18256 <tt>Rep2</tt> shall not be an instantiation of <tt>duration</tt>. Diagnostic required.
18257 </p>
18258 <p>
18259 <i>Returns:</i> <tt>duration&lt;CR, Period&gt;(d) %= s</tt>.
18260 </p>
18261 </blockquote>
18262
18263 <pre>template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
18264   typename common_type&lt;duration&lt;Rep1, Period1&gt;, duration&lt;Rep2, Period2&gt;&gt;::type
18265   operator%(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
18266 </pre>
18267 <blockquote>
18268 <p>
18269 <i>Returns:</i> <tt>common_type&lt;duration&lt;Rep1, Period1&gt;, duration&lt;Rep2, Period2&gt;&gt;::type(lhs) %= rhs</tt>.
18270 </p>
18271 </blockquote>
18272
18273 </blockquote>
18274
18275
18276
18277
18278
18279
18280 <hr>
18281 <h3><a name="935"></a>935. clock error handling needs to be specified</h3>
18282 <p><b>Section:</b> 20.9.5 [time.clock] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
18283  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-11-24  <b>Last modified:</b> 2009-05-23</p>
18284 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
18285 <p><b>Discussion:</b></p>
18286 <p>
18287 Each of the three clocks specified in Clocks 20.9.5 [time.clock]
18288 provides the member function:
18289 </p>
18290
18291 <blockquote><pre>static time_point now();
18292 </pre></blockquote>
18293
18294 <p>
18295 The semantics specified by Clock requirements 20.9.1 [time.clock.req]
18296 make no mention of error handling. Thus the function may throw <tt>bad_alloc</tt>
18297 or an implementation-defined exception (17.6.4.10 [res.on.exception.handling]
18298 paragraph 4).
18299 </p>
18300
18301 <p>
18302 Some implementations of these functions on POSIX, Windows, and
18303 presumably on other operating systems, may fail in ways only detectable
18304 at runtime. Some failures on Windows are due to supporting chipset
18305 errata and can even occur after successful calls to a clock's <tt>now()</tt>
18306 function.
18307 </p>
18308
18309 <p>
18310 These functions are used in cases where exceptions are not appropriate
18311 or where the specifics of the exception or cause of error need to be
18312 available to the user. See
18313 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2828.html">N2828</a>,
18314 <i>Library Support for hybrid error
18315 handling (Rev 1)</i>, for more specific discussion of use cases. Thus some change in
18316 the interface of now is required.
18317 </p>
18318
18319 <p>
18320 The proposed resolution has been implemented in the Boost version of the
18321 chrono library. No problems were encountered.
18322 </p>
18323
18324 <p><i>[
18325 Batavia (2009-05):
18326 ]</i></p>
18327
18328 <blockquote>
18329 <p>
18330 We recommend this issue be deferred until the next Committee Draft
18331 has been issued and the prerequisite paper has been accepted.
18332 </p>
18333 <p>
18334 Move to Open.
18335 </p>
18336 </blockquote>
18337
18338
18339 <p><b>Proposed resolution:</b></p>
18340 <p>
18341 Accept the proposed wording of
18342 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2828.html">N2828</a>,
18343 <i>Library Support for hybrid error handling (Rev 1)</i>.
18344 </p>
18345
18346 <p>
18347 Change Clock requirements 20.9.1 [time.clock.req] as indicated:
18348 </p>
18349
18350 <blockquote>
18351 <p>
18352 -2- In Table 55 <tt>C1</tt> and <tt>C2</tt> denote clock types. <tt>t1</tt> and
18353 <tt>t2</tt> are values returned by <tt>C1::now()</tt> where the call
18354 returning <tt>t1</tt> happens before (1.10) the call returning <tt>t2</tt> and
18355 both of these calls happen before <tt>C1::time_point::max()</tt>.
18356 <ins><tt>ec</tt> denotes an object of type <tt>error_code</tt>
18357 (19.5.2.2 [syserr.errcode.overview]).</ins>
18358 </p>
18359
18360 <table border="1">
18361 <caption>Table 55 -- Clock requirements</caption>
18362 <tbody><tr>
18363 <th>Expression</th><th>Return type</th><th>Operational semantics</th>
18364 </tr>
18365
18366 <tr>
18367 <td>...</td>
18368 <td>...</td>
18369 <td>...</td>
18370 </tr>
18371
18372 <tr>
18373 <td><tt>C1::now()</tt></td>
18374 <td><tt>C1::time_point</tt></td>
18375 <td>Returns a <tt>time_point</tt> object representing the current point in time.
18376 </td>
18377 </tr>
18378
18379 <tr>
18380 <td><tt><ins>C1::now(ec)</ins></tt></td>
18381 <td><tt><ins>C1::time_point</ins></tt></td>
18382 <td><ins>Returns a <tt>time_point</tt> object representing the current point in time.</ins>
18383 </td>
18384 </tr>
18385 </tbody></table>
18386 </blockquote>
18387
18388 <p>
18389 Change Class system_clock 20.9.5.1 [time.clock.system] as indicated:
18390 </p>
18391
18392 <blockquote><pre>static time_point now(<ins>error_code&amp; ec=throws()</ins>);
18393 </pre></blockquote>
18394
18395 <p>
18396 Change Class monotonic_clock 20.9.5.2 [time.clock.monotonic] as indicated:
18397 </p>
18398
18399 <blockquote><pre>static time_point now(<ins>error_code&amp; ec=throws()</ins>);
18400 </pre></blockquote>
18401
18402 <p>
18403 Change Class high_resolution_clock 20.9.5.3 [time.clock.hires] as indicated:
18404 </p>
18405
18406 <blockquote><pre>static time_point now(<ins>error_code&amp; ec=throws()</ins>);
18407 </pre></blockquote>
18408
18409
18410
18411
18412
18413
18414 <hr>
18415 <h3><a name="936"></a>936. Mutex type overspecified</h3>
18416 <p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
18417  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-12-05  <b>Last modified:</b> 2009-03-22</p>
18418 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.requirements">active issues</a> in [thread.mutex.requirements].</p>
18419 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
18420 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
18421 <p><b>Discussion:</b></p>
18422 <p>
18423 30.4.1 [thread.mutex.requirements] describes the requirements for a type to be
18424 a "Mutex type". A Mutex type can be used as the template argument for
18425 the <tt>Lock</tt> type that's passed to <tt>condition_variable_any::wait</tt> (although
18426 <tt>Lock</tt> seems like the wrong name here, since <tt>Lock</tt> is given a different
18427 formal meaning in 30.4.3 [thread.lock]) and, although the WD doesn't quite say
18428 so, as the template argument for <tt>lock_guard</tt> and <tt>unique_lock</tt>.
18429 </p>
18430
18431 <p>
18432 The requirements for a Mutex type include:
18433 </p>
18434
18435 <ul>
18436 <li>
18437 <tt>m.lock()</tt> shall be well-formed and have [described] semantics, including a return type of <tt>void</tt>.
18438 </li>
18439 <li>
18440 <tt>m.try_lock()</tt> shall be well-formed and have [described] semantics, including a return type of <tt>bool</tt>.
18441 </li>
18442 <li>
18443 <tt>m.unlock()</tt> shall be well-formed and have [described] semantics, including a return type of <tt>void</tt>.
18444 </li>
18445 </ul>
18446
18447 <p>
18448 Also, a Mutex type "shall not be copyable nor movable".
18449 </p>
18450
18451 <p>
18452 The latter requirement seems completely irrelevant, and the three
18453 requirements on return types are tighter than they need to be. For
18454 example, there's no reason that <tt>lock_guard</tt> can't be instantiated with a
18455 type that's copyable. The rule is, in fact, that <tt>lock_guard</tt>, etc. won't
18456 try to copy objects of that type. That's a constraint on locks, not on
18457 mutexes. Similarly, the requirements for <tt>void</tt> return types are
18458 unnecessary; the rule is, in fact, that <tt>lock_guard</tt>, etc. won't use any
18459 returned value. And with the return type of <tt>bool</tt>, the requirement should
18460 be that the return type is convertible to <tt>bool</tt>.
18461 </p>
18462
18463 <p><i>[
18464 Summit:
18465 ]</i></p>
18466
18467
18468 <blockquote>
18469 <p>
18470 Move to open. Related to conceptualization and should probably be tackled as part of that.
18471 </p>
18472 <ul>
18473 <li>
18474 The intention is not only to place a constraint on what types such as
18475 <tt>lock_guard</tt> may do with mutex types, but on what any code, including user
18476 code, may do with mutex types. Thus the constraints as they are apply to
18477 the mutex types themselves, not the current users of mutex types in the
18478 standard.
18479 </li>
18480 <li>
18481 This is a low priority issue; the wording as it is may be overly
18482 restrictive but this may not be a real issue.
18483 </li>
18484 </ul>
18485 </blockquote>
18486
18487 <p><i>[
18488 Post Summit Anthony adds:
18489 ]</i></p>
18490
18491
18492 <blockquote>
18493 <p>
18494 Section 30.4.1 [thread.mutex.requirements] conflates the
18495 requirements on a generic Mutex type (including user-supplied mutexes)
18496 with the requirements placed on the standard-supplied mutex types in an
18497 attempt to group everything together and save space.
18498 </p>
18499 <p>
18500 When applying concepts to chapter 30, I suggest that the concepts
18501 <tt>Lockable</tt> and <tt>TimedLockable</tt> embody the requirements for
18502 *use* of a mutex type as required by
18503 <tt>unique_lock/lock_guard/condition_variable_any</tt>. These should be
18504 relaxed as Pete describes in the issue. The existing words in 30.4.1 [thread.mutex.requirements] are requirements on all of
18505 <tt>std::mutex</tt>, <tt>std::timed_mutex</tt>,
18506 <tt>std::recursive_mutex</tt> and <tt>std::recursive_timed_mutex</tt>,
18507 and should be rephrased as such.
18508 </p>
18509 </blockquote>
18510
18511
18512
18513 <p><b>Proposed resolution:</b></p>
18514 <p>
18515 </p>
18516
18517
18518
18519
18520
18521 <hr>
18522 <h3><a name="939"></a>939. Problem with <tt>std::identity</tt> and reference-to-temporaries</h3>
18523 <p><b>Section:</b> 20.7.6 [identity.operation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
18524  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-12-11  <b>Last modified:</b> 2009-07-30</p>
18525 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
18526 <p><b>Discussion:</b></p>
18527 <p>
18528 <tt>std::identity</tt> takes an argument of type <tt>T const &amp;</tt>
18529 and returns a result of <tt>T const &amp;</tt>.
18530 </p>
18531 <p>
18532 Unfortunately, this signature will accept a value of type other than <tt>T</tt> that
18533 is convertible-to-<tt>T</tt>, and then return a reference to the dead temporary.  The
18534 constraint in the concepts version simply protects against returning
18535 reference-to-<tt>void</tt>.
18536 </p>
18537 <p>
18538 Solutions:
18539 </p>
18540 <blockquote>
18541 <p>
18542 i/  Return-by-value, potentially slicing bases and rejecting non-copyable
18543 types
18544 </p>
18545 <p>
18546 ii/ Provide an additional overload:
18547 </p>
18548 <blockquote><pre>template&lt; typename T &gt;
18549 template operator( U &amp; ) = delete;
18550 </pre></blockquote>
18551 <p>
18552 This seems closer on intent, but moves beyond the original motivation for
18553 the operator, which is compatibility with existing (non-standard)
18554 implementations.
18555 </p>
18556 <p>
18557 iii/ Remove the <tt>operator()</tt> overload.  This restores the original definition
18558 of the <tt>identity</tt>, although now effectively a type_trait rather than part of
18559 the perfect forwarding protocol.
18560 </p>
18561 <p>
18562 iv/ Remove <tt>std::identity</tt> completely; its original reason to exist is
18563 replaced with the <tt>IdentityOf</tt> concept.
18564 </p>
18565 </blockquote>
18566 <p>
18567 My own preference is somewhere between (ii) and (iii) - although I stumbled
18568 over the issue with a specific application hoping for resolution (i)!
18569 </p>
18570
18571 <p><i>[
18572 Batavia (2009-05):
18573 ]</i></p>
18574
18575 <blockquote>
18576 <p>
18577 We dislike options i and iii, and option ii seems like overkill.
18578 If we remove it (option iv), implementers can still provide it under a
18579 different name.
18580 </p>
18581 <p>
18582 Move to Open pending wording (from Alisdair) for option iv.
18583 </p>
18584 </blockquote>
18585
18586 <p><i>[
18587 2009-05-23 Alisdair provided wording for option iv.
18588 ]</i></p>
18589
18590
18591 <p><i>[
18592 2009-07-20 Alisdair adds:
18593 ]</i></p>
18594
18595
18596 <blockquote>
18597 <p>
18598 I'm not sure why this issue was not discussed at Frankfurt (or I missed
18599 the discussion) but the rationale is now fundamentally flawed.  With the
18600 removal of concepts, <tt>std::identity</tt> again becomes an important library
18601 type so we cannot simply remove it.
18602 </p>
18603 <p>
18604 At that point, we need to pick one of the other suggested resolutions,
18605 but have no guidance at the moment.
18606 </p>
18607 </blockquote>
18608
18609 <p><i>[
18610 2009-07-20 Howard adds:
18611 ]</i></p>
18612
18613
18614 <blockquote>
18615 <p>
18616 I believe the rationale for not addressing this issue in Frankfurt was that it did
18617 not address a national body comment.
18618 </p>
18619 <p>
18620 I also believe that removal of <tt>identity</tt> is still a practical option as
18621 my latest reformulation of <tt>forward</tt>, which is due to comments suggested
18622 at Summit, no longer uses <tt>identity</tt>. :-)
18623 </p>
18624
18625 <blockquote><pre>template &lt;class T, class U,
18626     class = typename enable_if
18627             &lt;
18628                 !is_lvalue_reference&lt;T&gt;::value ||
18629                  is_lvalue_reference&lt;T&gt;::value &amp;&amp;
18630                  is_lvalue_reference&lt;U&gt;::value
18631             &gt;::type,
18632     class = typename enable_if
18633             &lt;
18634                 is_same&lt;typename remove_all&lt;T&gt;::type,
18635                         typename remove_all&lt;U&gt;::type&gt;::value
18636             &gt;::type&gt;
18637 inline
18638 T&amp;&amp;
18639 forward(U&amp;&amp; t)
18640 {
18641     return static_cast&lt;T&amp;&amp;&gt;(t);
18642
18643 }
18644 </pre>
18645
18646 <p><i>[
18647 The above code assumes acceptance of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1120">1120</a> for the definition of
18648 <tt>remove_all</tt>.  This is just to make the syntax a little more palatable.
18649 Without this trait the above is still very implementable.
18650 ]</i></p>
18651
18652
18653 </blockquote>
18654
18655 <p>
18656 Paper with rationale is on the way ... <i>really</i>, I promise this time! ;-)
18657 </p>
18658 </blockquote>
18659
18660 <p><i>[
18661 2009-07-30 Daniel adds:  See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a> for an alternative resolution.
18662 ]</i></p>
18663
18664
18665
18666 <p><b>Proposed resolution:</b></p>
18667 <p>
18668 Strike 20.2.1 [concept.transform] p3:
18669 </p>
18670
18671 <blockquote>
18672 <del>-4- <i>Note:</i> concept form of the identity type metafunction (20.7.6).</del>
18673 </blockquote>
18674
18675 <p>
18676 Strike from 20.7 [function.objects] p2:
18677 </p>
18678
18679 <blockquote><pre><del>// 20.7.6, identity operation:</del>
18680 <del>template &lt;IdentityOf T&gt; struct identity;</del>
18681 </pre></blockquote>
18682
18683 <p>
18684 Remove 20.7.6 [identity.operation] (whole subclause):
18685 </p>
18686
18687 <blockquote>
18688 <pre><del>template &lt;IdentityOf T&gt; struct identity {
18689   typedef T type;
18690
18691   requires ReferentType&lt;T&gt;
18692      const T&amp; operator()(const T&amp; x) const;
18693 };</del>
18694
18695 <del>requires ReferentType&lt;T&gt;
18696   const T&amp; operator()(const T&amp; x) const;</del>
18697 </pre>
18698 <blockquote>
18699 <del>-1-  <i>Returns:</i> <tt>x</tt></del>
18700 </blockquote>
18701 </blockquote>
18702
18703
18704
18705
18706
18707
18708 <hr>
18709 <h3><a name="940"></a>940. <tt>std::distance</tt></h3>
18710 <p><b>Section:</b> 24.4 [iterator.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
18711  <b>Submitter:</b> Thomas <b>Opened:</b> 2008-12-14  <b>Last modified:</b> 2009-07-18</p>
18712 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.operations">active issues</a> in [iterator.operations].</p>
18713 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.operations">issues</a> in [iterator.operations].</p>
18714 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
18715 <p><b>Discussion:</b></p>
18716
18717 <p><b>Addresses UK 270</b></p>
18718
18719 <p>
18720 Regarding the <tt>std::distance</tt> - function, 24.4 [iterator.operations]
18721 / 4 says:
18722 </p>
18723 <blockquote>
18724 Returns the
18725 number of increments or decrements needed to get from first to last.
18726 </blockquote>
18727 <p>
18728 This sentence is completely silent about the sign of the return value.
18729 24.4 [iterator.operations] / 1 gives more information about the
18730 underlying operations, but
18731 again no inferences about the sign can be made.
18732 Strictly speaking, that is taking that sentence literally, I think this
18733 sentence even implies a positive return value in all cases, as the
18734 number of increments or decrements is clearly a ratio scale variable,
18735 with a natural zero bound.
18736 </p>
18737 <p>
18738 Practically speaking, my implementations did what common sense and
18739 knowledge based on pointer arithmetic forecasts, namely a positive sign
18740 for increments (that is, going from <tt>first</tt> to <tt>last</tt> by <tt>operator++</tt>), and a
18741 negative sign for decrements (going from <tt>first</tt> to <tt>last</tt> by <tt>operator--</tt>).
18742 </p>
18743 <p>
18744 Here are my two questions:
18745 </p>
18746 <p>
18747 First, is that paragraph supposed to be interpreted in the way what I
18748 called 'common sense', that is negative sign for decrements ? I am
18749 fairly sure that's the supposed behavior, but a double-check here in
18750 this group can't hurt.
18751 </p>
18752 <p>
18753 Second, is the present wording (2003 standard version - no idea about
18754 the draft for the upcoming standard) worth an edit to make it a bit more
18755 sensible, to mention the sign of the return value explicitly ?
18756 </p>
18757
18758 <p><i>[
18759 Daniel adds:
18760 ]</i></p>
18761
18762
18763 <blockquote>
18764 <p>
18765 My first thought was that resolution <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#204">204</a> would already cover the
18766 issue report, but it seems that current normative wording is in
18767 contradiction to that resolution:
18768 </p>
18769
18770 <p>
18771 Referring to
18772 <a href="" ref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>,
18773 24.4 [iterator.operations]/ p.4 says:
18774 </p>
18775
18776 <blockquote>
18777 <i>Effects:</i> Returns the number of increments or decrements needed to get
18778 from <tt>first</tt> to <tt>last</tt>.
18779 </blockquote>
18780
18781 <p>
18782 IMO the part " or decrements" is in contradiction to p. 5 which says
18783 </p>
18784
18785 <blockquote>
18786 <i>Requires:</i> <tt>last</tt> shall be reachable from <tt>first</tt>.
18787 </blockquote>
18788
18789 <p>
18790 because "reachable" is defined in 24.2 [iterator.concepts]/7 as
18791 </p>
18792
18793 <blockquote>
18794 An iterator <tt>j</tt> is called reachable from an iterator <tt>i</tt> if and only if
18795 there is a finite
18796 sequence of applications of the expression <tt>++i</tt> that makes <tt>i == j</tt>.[..]
18797 </blockquote>
18798
18799 <p>
18800 Here is wording that would be consistent with this definition of "reachable":
18801 </p>
18802
18803 <p>
18804 Change 24.4 [iterator.operations] p4 as follows:
18805 </p>
18806
18807 <blockquote>
18808 <i>Effects:</i> Returns the number of increments <del>or decrements</del>
18809 needed to get from <tt>first</tt> to <tt>last</tt>.
18810 </blockquote>
18811
18812 </blockquote>
18813
18814 <p>
18815 Thomas adds more discussion and an alternative view point
18816 <a href="http://groups.google.com/group/comp.std.c++/browse_thread/thread/e8e46dcda0a5d797#">here</a>.
18817 </p>
18818
18819 <p><i>[
18820 Summit:
18821 ]</i></p>
18822
18823
18824 <blockquote>
18825 The proposed wording below was verbally agreed to.  Howard provided.
18826 </blockquote>
18827
18828 <p><i>[
18829 Batavia (2009-05):
18830 ]</i></p>
18831
18832 <blockquote>
18833 <p>
18834 Pete reports that a recent similar change has been made
18835 for the <tt>advance()</tt> function.
18836 </p>
18837 <p>
18838 We agree with the proposed resolution.
18839 Move to Tentatively Ready.
18840 </p>
18841 </blockquote>
18842
18843 <p><i>[
18844 2009-07 Frankfurt
18845 ]</i></p>
18846
18847
18848 <blockquote>
18849 Moved from Tentatively Ready to Open only because the wording needs to be
18850 tweaked for concepts removal.
18851 </blockquote>
18852
18853 <p><i>[
18854 2009-07 Frankfurt:
18855 ]</i></p>
18856
18857
18858 <blockquote>
18859 Leave Open pending arrival of a post-Concepts WD.
18860 </blockquote>
18861
18862
18863
18864 <p><b>Proposed resolution:</b></p>
18865 <p>
18866 Change 24.4 [iterator.operations]:
18867 </p>
18868
18869 <blockquote>
18870 <pre>template &lt;InputIterator Iter&gt;
18871   Iter::difference_type
18872   distance(Iter first, Iter last);
18873 <del>template &lt;RandomAccessIterator Iter&gt;
18874   Iter::difference_type distance(Iter first, Iter last);</del>
18875 </pre>
18876
18877 <blockquote>
18878 <p>
18879 -4- <i>Effects:</i> Returns the number of increments <del>or decrements</del>
18880 needed to get from <tt>first</tt> to <tt>last</tt>.
18881 </p>
18882 <p>
18883 -5- <i>Requires:</i> <tt>last</tt> shall be reachable from <tt>first</tt>.
18884 </p>
18885 </blockquote>
18886
18887 <pre><ins>template &lt;RandomAccessIterator Iter&gt;
18888   Iter::difference_type distance(Iter first, Iter last);</ins>
18889 </pre>
18890
18891 <blockquote>
18892 <p>
18893 <ins>-6- <i>Effects:</i> Returns the number of increments or decrements
18894 needed to get from <tt>first</tt> to <tt>last</tt>.</ins>
18895 </p>
18896 <p>
18897 <ins>-7- <i>Requires:</i> <tt>last</tt> shall be reachable from <tt>first</tt>
18898 or <tt>first</tt> shall be reachable from <tt>last</tt>.</ins>
18899 </p>
18900 </blockquote>
18901
18902
18903 </blockquote>
18904
18905
18906
18907
18908
18909
18910 <hr>
18911 <h3><a name="944"></a>944. <tt>atomic&lt;bool&gt;</tt> derive from <tt>atomic_bool</tt>?</h3>
18912 <p><b>Section:</b> 29.5.3 [atomics.types.generic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
18913  <b>Submitter:</b> Holger Grund <b>Opened:</b> 2008-12-19  <b>Last modified:</b> 2009-03-22</p>
18914 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.generic">issues</a> in [atomics.types.generic].</p>
18915 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
18916 <p><b>Discussion:</b></p>
18917 <p>
18918 I think it's fairly obvious that <tt>atomic&lt;bool&gt;</tt> is supposed to be derived
18919 from <tt>atomic_bool</tt> (and otherwise follow the <tt>atomic&lt;integral&gt;</tt> interface),
18920 though I think the current wording doesn't support this. I raised this
18921 point along with <tt>atomic&lt;floating-point&gt;</tt> privately with Herb and I seem
18922 to recall it came up in the resulting discussion on this list. However,
18923 I don't see anything on the current libs issue list mentioning this
18924 problem.
18925 </p>
18926
18927 <p>
18928 29.5.3 [atomics.types.generic]/3 reads
18929 </p>
18930
18931 <blockquote>
18932 There are full specializations over the integral types on the atomic
18933 class template. For each integral type integral in the second column of
18934 table 121 or table 122, the specialization <tt>atomic&lt;integral&gt;</tt> shall be
18935 publicly derived from the corresponding atomic integral type in the
18936 first column of the table. These specializations shall have trivial
18937 default constructors and trivial destructors.
18938 </blockquote>
18939
18940 <p>
18941 Table 121 does not include (<tt>atomic_bool</tt>, <tt>bool</tt>),
18942 so that this should probably be mentioned explicitly in the quoted paragraph.
18943 </p>
18944
18945 <p><i>[
18946 Summit:
18947 ]</i></p>
18948
18949
18950 <blockquote>
18951 Move to open. Lawrence will draft a proposed resolution. Also, ask
18952 Howard to fix the title.
18953 </blockquote>
18954
18955 <p><i>[
18956 Post Summit Anthony provided proposed wording.
18957 ]</i></p>
18958
18959
18960
18961 <p><b>Proposed resolution:</b></p>
18962 <p>
18963 Replace paragraph 3 in 29.5.3 [atomics.types.generic] with
18964 </p>
18965
18966 <blockquote>
18967 -3- There are full specializations over the integral types on the <tt>atomic</tt>
18968 class template. For each integral type <tt>integral</tt> in the second column of
18969 table 121 or table 122, the specialization <tt>atomic&lt;integral&gt;</tt> shall be
18970 publicly derived from the corresponding atomic integral type in the first
18971 column of the table.
18972 <ins>In addition, the specialization <tt>atomic&lt;bool&gt;</tt>
18973 shall be publicly derived from <tt>atomic_bool</tt>.</ins>
18974 These specializations shall have trivial default
18975 constructors and trivial destructors.
18976 </blockquote>
18977
18978
18979
18980
18981
18982 <hr>
18983 <h3><a name="947"></a>947. duration arithmetic: contradictory requirements</h3>
18984 <p><b>Section:</b> 20.9.3.5 [time.duration.nonmember] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
18985  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-12-20  <b>Last modified:</b> 2009-07-27</p>
18986 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration.nonmember">issues</a> in [time.duration.nonmember].</p>
18987 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
18988 <p><b>Discussion:</b></p>
18989 <p>
18990 In 20.9.3.5 [time.duration.nonmember], paragraph 8 says that calling
18991 <tt>dur / rep</tt>
18992 when <tt>rep</tt> is an instantiation of <tt>duration</tt> requires a diagnostic.
18993 That's followed by an <tt>operator/</tt> that takes two durations.
18994 So <tt>dur1 / dur2</tt> is legal under the second version,
18995 but requires a diagnostic under the first.
18996 </p>
18997
18998 <p><i>[
18999 Howard adds:
19000 ]</i></p>
19001
19002
19003 <blockquote>
19004 Please see the thread starting with c++std-lib-22980 for more information.
19005 </blockquote>
19006
19007 <p><i>[
19008 Batavia (2009-05):
19009 ]</i></p>
19010
19011 <blockquote>
19012 Move to Open, pending proposed wording (and preferably an implementation).
19013 </blockquote>
19014
19015 <p><i>[
19016 2009-07-27 Howard adds:
19017 ]</i></p>
19018
19019
19020 <blockquote>
19021 <p>
19022 I've addressed this issue under the proposed wording for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1177">1177</a> which
19023 cleans up several places under 20.9.3 [time.duration] which used the
19024 phrase "diagnostic required".
19025 </p>
19026 <p>
19027 For clarity's sake, here is an example implementation of the constrained <tt>operator/</tt>:
19028 </p>
19029
19030 <blockquote><pre>template &lt;class _Duration, class _Rep, bool = __is_duration&lt;_Rep&gt;::value&gt;
19031 struct __duration_divide_result
19032 {
19033 };
19034
19035 template &lt;class _Duration, class _Rep2,
19036     bool = is_convertible&lt;_Rep2,
19037                           typename common_type&lt;typename _Duration::rep, _Rep2&gt;::type&gt;::value&gt;
19038 struct __duration_divide_imp
19039 {
19040 };
19041
19042 template &lt;class _Rep1, class _Period, class _Rep2&gt;
19043 struct __duration_divide_imp&lt;duration&lt;_Rep1, _Period&gt;, _Rep2, true&gt;
19044 {
19045     typedef duration&lt;typename common_type&lt;_Rep1, _Rep2&gt;::type, _Period&gt; type;
19046 };
19047
19048 template &lt;class _Rep1, class _Period, class _Rep2&gt;
19049 struct __duration_divide_result&lt;duration&lt;_Rep1, _Period&gt;, _Rep2, false&gt;
19050     : __duration_divide_imp&lt;duration&lt;_Rep1, _Period&gt;, _Rep2&gt;
19051 {
19052 };
19053
19054 template &lt;class _Rep1, class _Period, class _Rep2&gt;
19055 inline
19056 typename __duration_divide_result&lt;duration&lt;_Rep1, _Period&gt;, _Rep2&gt;::type
19057 operator/(const duration&lt;_Rep1, _Period&gt;&amp; __d, const _Rep2&amp; __s)
19058 {
19059     typedef typename common_type&lt;_Rep1, _Rep2&gt;::type _Cr;
19060     duration&lt;_Cr, _Period&gt; __r = __d;
19061     __r /= static_cast&lt;_Cr&gt;(__s);
19062     return __r;
19063 }
19064 </pre></blockquote>
19065
19066 <p>
19067 <tt>__duration_divide_result</tt> is basically a custom-built <tt>enable_if</tt>
19068 that will contain <tt>type</tt> only if <tt>Rep2</tt> is not a <tt>duration</tt>
19069 and if <tt>Rep2</tt> is implicitly convertible to
19070 <tt>common_type&lt;typename Duration::rep, Rep2&gt;::type</tt>. <tt>__is_duration</tt>
19071 is simply a private trait that answers <tt>false</tt>, but is specialized for
19072 <tt>duration</tt> to answer <tt>true</tt>.
19073 </p>
19074
19075 <p>
19076 The constrained <tt>operator%</tt> works identically.
19077 </p>
19078 </blockquote>
19079
19080
19081 <p><b>Proposed resolution:</b></p>
19082 <p>
19083 </p>
19084
19085
19086
19087
19088
19089 <hr>
19090 <h3><a name="950"></a>950. unique_ptr converting ctor shouldn't accept array form</h3>
19091 <p><b>Section:</b> 20.8.9.2.1 [unique.ptr.single.ctor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
19092  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-08-01</p>
19093 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single.ctor">active issues</a> in [unique.ptr.single.ctor].</p>
19094 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.ctor">issues</a> in [unique.ptr.single.ctor].</p>
19095 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
19096 <p><b>Discussion:</b></p>
19097 <p>
19098 <tt>unique_ptr</tt>'s of array type should not convert to
19099 <tt>unique_ptr</tt>'s which do not have an array type.
19100 </p>
19101
19102 <blockquote><pre>struct Deleter
19103 {
19104    void operator()(void*) {}
19105 };
19106
19107 int main()
19108 {
19109    unique_ptr&lt;int[], Deleter&gt; s;
19110    unique_ptr&lt;int, Deleter&gt; s2(std::move(s));  <font color="#c80000">// should not compile</font>
19111 }
19112 </pre></blockquote>
19113
19114 <p><i>[
19115 Post Summit:
19116 ]</i></p>
19117
19118
19119 <blockquote>
19120 <p>
19121 Walter: Does the "diagnostic required" apply to both arms of the "and"?
19122 </p>
19123 <p>
19124 Tom Plum: suggest to break into several sentences
19125 </p>
19126 <p>
19127 Walter: suggest "comma" before the "and" in both places
19128 </p>
19129 <p>
19130 Recommend Review.
19131 </p>
19132 </blockquote>
19133
19134 <p><i>[
19135 Batavia (2009-05):
19136 ]</i></p>
19137
19138 <blockquote>
19139 The post-Summit comments have been applied to the proposed resolution.
19140 We now agree with the proposed resolution.
19141 Move to Tentatively Ready.
19142 </blockquote>
19143
19144 <p><i>[
19145 2009-07 Frankfurt
19146 ]</i></p>
19147
19148
19149 <blockquote>
19150 Moved from Tentatively Ready to Open only because the wording needs to be
19151 improved for enable_if type constraining, possibly following Robert's
19152 formula.
19153 </blockquote>
19154
19155 <p><i>[
19156 2009-08-01 Howard updates wording and sets to Review.
19157 ]</i></p>
19158
19159
19160
19161
19162 <p><b>Proposed resolution:</b></p>
19163 <p>
19164 Change 20.8.9.2.1 [unique.ptr.single.ctor]:
19165 </p>
19166
19167 <blockquote>
19168 <pre>template &lt;class U, class E&gt; unique_ptr(unique_ptr&lt;U, E&gt;&amp;&amp; u);
19169 </pre>
19170 <blockquote>
19171 <p>
19172 -20- <i>Requires:</i> If <tt>D</tt> is not a reference type,
19173 construction of the deleter <tt>D</tt> from an rvalue of type <tt>E</tt>
19174 shall be well formed and shall not throw an exception. <del>If <tt>D</tt> is
19175 a reference type, then <tt>E</tt> shall be the same type as <tt>D</tt>
19176 (diagnostic required). <tt>unique_ptr&lt;U, E&gt;::pointer</tt> shall be
19177 implicitly convertible to <tt>pointer</tt>. [<i>Note:</i> These requirements
19178 imply that <tt>T</tt> and <tt>U</tt> are complete types. &#8212; <i>end note</i>]</del>
19179 </p>
19180
19181 <p><ins>
19182 <i>Remarks:</i> If <tt>D</tt> is
19183 a reference type, then <tt>E</tt> shall be the same type as <tt>D</tt>, else this
19184 constructor shall not participate in overload resolution. <tt>unique_ptr&lt;U, E&gt;::pointer</tt> shall be
19185 implicitly convertible to <tt>pointer</tt>, else this
19186 constructor shall not participate in overload resolution. <tt>U</tt> shall not be
19187 an array type, else this
19188 constructor shall not participate in overload resolution. [<i>Note:</i> These requirements
19189 imply that <tt>T</tt> and <tt>U</tt> are complete types. &#8212; <i>end note</i>]
19190 </ins></p>
19191
19192 </blockquote>
19193 </blockquote>
19194
19195 <p>
19196 Change 20.8.9.2.3 [unique.ptr.single.asgn]:
19197 </p>
19198
19199 <blockquote>
19200 <pre>template &lt;class U, class E&gt; unique_ptr&amp; operator=(unique_ptr&lt;U, E&gt;&amp;&amp; u);
19201 </pre>
19202 <blockquote>
19203 <p>
19204 -6- <i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
19205 <tt>D</tt> shall not throw an exception. <del><tt>unique_ptr&lt;U,
19206 E&gt;::pointer</tt> shall be implicitly convertible to <tt>pointer</tt>.
19207 [<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt>
19208 are complete types. &#8212; <i>end note</i>]</del>
19209 </p>
19210
19211 <p><ins>
19212 <i>Remarks:</i> <tt>unique_ptr&lt;U,
19213 E&gt;::pointer</tt> shall be implicitly convertible to <tt>pointer</tt>, else this
19214 operator shall not participate in overload resolution.
19215 <tt>U</tt> shall not be an array type, else this
19216 operator shall not participate in overload resolution.
19217 [<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt>
19218 are complete types. &#8212; <i>end note</i>]
19219 </ins></p>
19220
19221 </blockquote>
19222 </blockquote>
19223
19224
19225
19226
19227
19228
19229 <hr>
19230 <h3><a name="951"></a>951. Various threading bugs #1</h3>
19231 <p><b>Section:</b> 20.9.2.1 [time.traits.is_fp] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
19232  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-08-01</p>
19233 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
19234 <p><b>Discussion:</b></p>
19235
19236 <p>
19237 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#953">953</a>.
19238 </p>
19239
19240 <p>
19241 20.9.2.1 [time.traits.is_fp] says that the type <tt>Rep</tt> "is
19242 assumed to be ... a class emulating an integral type." What are the
19243 requirements for such a type?
19244 </p>
19245 <p><i>[
19246 2009-05-10 Howard adds:
19247 ]</i></p>
19248
19249
19250 <blockquote>
19251 <tt>IntegralLike</tt>.
19252 </blockquote>
19253
19254 <p><i>[
19255 Batavia (2009-05):
19256 ]</i></p>
19257
19258 <blockquote>
19259 <p>
19260 As with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#953">953</a>,
19261 we recommend this issue be addressed in the context of providing concepts for the entire <tt>thread</tt> header.
19262 </p>
19263 <p>
19264 We look forward to proposed wording.
19265 </p>
19266 <p>
19267 Move to Open.
19268 </p>
19269 </blockquote>
19270
19271 <p><i>[
19272 2009-08-01 Howard adds:
19273 ]</i></p>
19274
19275
19276 <blockquote>
19277 <p>
19278 I have surveyed all clauses of 20.9.2.2 [time.traits.duration_values],
19279 20.9.2.3 [time.traits.specializations] and 20.9.3 [time.duration].
19280 I can not find any clause which involves the use of a <tt>duration::rep</tt> type
19281 where the requirements on the <tt>rep</tt> type are not clearly spelled out.
19282 These requirements were carefully crafted to allow any arithmetic type, or
19283 any user-defined type emulating an arithmetic type.
19284 </p>
19285
19286 <p>
19287 Indeed, <tt>treat_as_floating_point</tt>
19288 becomes completely superfluous if <tt>duration::rep</tt> can never be a class type.
19289 </p>
19290
19291 <p>
19292 There will be some <tt>Rep</tt> types which will not meet the requirements of
19293 <em>every</em> <tt>duration</tt> operation.  This is no different than the fact
19294 that <tt>vector&lt;T&gt;</tt> can easily be used for types <tt>T</tt> which are
19295 not <tt>DefaultConstructible</tt>, even though some members of <tt>vector&lt;T&gt;</tt>
19296 require <tt>T</tt> to be <tt>DefaultConstructible</tt>.  This is why the requirements
19297 on <tt>Rep</tt> are specified for each operation individually.
19298 </p>
19299
19300 <p>
19301 In 20.9.2.1 [time.traits.is_fp] p1:
19302 </p>
19303
19304 <blockquote><pre>template &lt;class Rep&gt; struct treat_as_floating_point
19305   : is_floating_point&lt;Rep&gt; { };
19306 </pre>
19307
19308 <blockquote>
19309 The <tt>duration</tt> template uses the <tt>treat_as_floating_point</tt> trait to help
19310 determine if a <tt>duration</tt> object can be converted to another <tt>duration</tt>
19311 with a different tick period. If <tt>treat_as_floating_point&lt;Rep&gt;::value</tt> is
19312 <tt>true</tt>, then <tt>Rep</tt> is a floating-point type and implicit conversions are
19313 allowed among <tt>duration</tt>s. Otherwise, the implicit convertibility depends
19314 on the tick periods of the <tt>duration</tt>s. If <tt>Rep</tt> is <u>a class type which
19315 emulates a floating-point type</u>, the author of <tt>Rep</tt> can specialize
19316 <tt>treat_as_floating_point</tt> so that <tt>duration</tt> will treat this <tt>Rep</tt> as if it
19317 were a floating-point type. Otherwise <tt>Rep</tt> is assumed to be an integral
19318 type or <u>a class emulating an integral type</u>.
19319 </blockquote>
19320 </blockquote>
19321
19322 <p>
19323 The phrases "a class type which emulates a floating-point type" and
19324 "a class emulating an integral type" are clarifying phrases which refer to
19325 the summation of all the requirements on the <tt>Rep</tt> type specified in
19326 detail elsewhere (and <em>should not</em> be repeated here).
19327 </p>
19328
19329 <p>
19330 This specification has been implemented, now multiple times, and the experience
19331 has been favorable.  The current specification clearly specifies the requirements
19332 at each point of use (though I'd be happy to fix any place I may have missed,
19333 but none has been pointed out).
19334 </p>
19335
19336 <p>
19337 I am amenable to improved wording of this paragraph (and any others), but to not have any
19338 suggestions for improved wording at this time.  I am <em>strongly</em> opposed to
19339 changes which would significantly alter the semantics of the
19340 specification under 20.9 [time] without firmly grounded and
19341 documented rationale, example implementation, testing, and user
19342 experience which relates a positive experience.
19343 </p>
19344
19345 <p>
19346 I recommend NAD unless someone wants to produce some clarifying wording.
19347 </p>
19348 </blockquote>
19349
19350
19351 <p><b>Proposed resolution:</b></p>
19352 <p>
19353 </p>
19354
19355
19356
19357
19358
19359 <hr>
19360 <h3><a name="953"></a>953. Various threading bugs #3</h3>
19361 <p><b>Section:</b> 20.9.1 [time.clock.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
19362  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-08-01</p>
19363 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.clock.req">active issues</a> in [time.clock.req].</p>
19364 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.req">issues</a> in [time.clock.req].</p>
19365 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
19366 <p><b>Discussion:</b></p>
19367
19368 <p>
19369 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#951">951</a>.
19370 </p>
19371
19372 <p>
19373 20.9.1 [time.clock.req] says that a clock's <tt>rep</tt> member is "an
19374 arithmetic type or a class emulating an arithmetic type." What are the
19375 requirements for such a type?
19376 </p>
19377
19378 <p><i>[
19379 2009-05-10 Howard adds:
19380 ]</i></p>
19381
19382
19383 <blockquote>
19384 This wording was aimed directly at the <tt>ArithmeticLike</tt> concept.
19385 </blockquote>
19386
19387 <p><i>[
19388 Batavia (2009-05):
19389 ]</i></p>
19390
19391 <blockquote>
19392 <p>
19393 We recommend this issue be addressed in the context of providing concepts
19394 for the entire <tt>thread</tt> header.
19395 </p>
19396 <p>
19397 May resolve for now by specifying arithmetic types,
19398 and in future change to <tt>ArithmeticLike</tt>.
19399 However, Alisdair believes this is not feasible.
19400 </p>
19401 <p>
19402 Bill disagrees.
19403 </p>
19404 <p>
19405 We look forward to proposed wording.  Move to Open.
19406 </p>
19407 </blockquote>
19408
19409 <p><i>[
19410 2009-08-01 Howard adds:
19411 ]</i></p>
19412
19413
19414 <blockquote>
19415 See commented dated 2009-08-01 in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#951">951</a>.
19416 </blockquote>
19417
19418
19419 <p><b>Proposed resolution:</b></p>
19420 <p>
19421 </p>
19422
19423
19424
19425
19426
19427 <hr>
19428 <h3><a name="954"></a>954. Various threading bugs #4</h3>
19429 <p><b>Section:</b> 20.9.1 [time.clock.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
19430  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-08-01</p>
19431 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.clock.req">active issues</a> in [time.clock.req].</p>
19432 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.req">issues</a> in [time.clock.req].</p>
19433 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
19434 <p><b>Discussion:</b></p>
19435 <p>
19436 Table 55 -- Clock Requirements (in 20.9.1 [time.clock.req])
19437 </p>
19438
19439 <ol type="a">
19440 <li>
19441 the requirements for <tt>C1::time_point</tt> require <tt>C1</tt> and <tt>C2</tt>
19442 to "refer to the same epoch", but "epoch" is not defined.
19443 </li>
19444 <li>
19445 "Different clocks may share a <tt>time_point</tt> definition if it is
19446 valid to compare their <tt>time_point</tt>s by comparing their
19447 respective <tt>duration</tt>s." What does "valid" mean here? And, since
19448 <tt>C1::rep</tt> is "**THE** representation type of the native
19449 <tt>duration</tt> and <tt>time_point</tt>" (emphasis added), there
19450 doesn't seem to be much room for some other representation.
19451 </li>
19452 <li>
19453 <tt>C1::is_monotonic</tt> has type "<tt>const bool</tt>". The
19454 "<tt>const</tt>" should be removed.
19455 </li>
19456 <li>
19457 <tt>C1::period</tt> has type <tt>ratio</tt>. <tt>ratio</tt> isn't a type,
19458 it's a template. What is the required type?
19459 </li>
19460 </ol>
19461
19462 <p><i>[
19463 2009-05-10 Howard adds:
19464 ]</i></p>
19465
19466
19467 <ol type="a">
19468 <li>
19469 <p>
19470 "epoch" is purposefully not defined beyond the common English
19471 <a href="http://www.dictionary.net/epoch">definition</a>.  The C standard
19472 also chose not to define epoch, though POSIX did.  I believe it is a strength
19473 of the C standard that epoch is not defined.  When it is known that two <tt>time_point</tt>s
19474 refer to the same epoch, then a definition of the epoch is not needed to compare
19475 the two <tt>time_point</tt>s, or subtract them.
19476 </p>
19477 <p>
19478 A <tt>time_point</tt> and a <tt>Clock</tt> implicitly refer to an (unspecified) epoch.
19479 The <tt>time_point</tt> represents an offset (<tt>duration</tt>) from an epoch.
19480 </p>
19481 </li>
19482 <li>
19483 <p>
19484 The sentence:
19485 </p>
19486 <blockquote>
19487 Different clocks
19488 may share a <tt>time_point</tt>
19489 definition if it is valid to
19490 compare their <tt>time_point</tt>s by
19491 comparing their respective
19492 <tt>duration</tt>s.
19493 </blockquote>
19494
19495 <p>
19496 is redundant and could be removed.  I believe the sentence which follows the above:
19497 </p>
19498
19499 <blockquote>
19500 <tt>C1</tt> and <tt>C2</tt> shall refer to the same epoch.
19501 </blockquote>
19502
19503 <p>
19504 is sufficient.  If two clocks share the same epoch, then by definition, comparing
19505 their <tt>time_point</tt>s is valid.
19506 </p>
19507 </li>
19508 <li>
19509 <tt>is_monotonic</tt> is meant to never change (be <tt>const</tt>).  It is also
19510 desired that this value be usable in compile-time computation and branching.
19511 </li>
19512 <li>
19513 <p>
19514 This should probably instead be worded:
19515 </p>
19516 <blockquote>
19517 An instantiation of <tt>ratio</tt>.
19518 </blockquote>
19519 </li>
19520 </ol>
19521
19522 <p><i>[
19523 Batavia (2009-05):
19524 ]</i></p>
19525
19526 <blockquote>
19527 <p>
19528 Re (a): It is not clear to us whether "epoch" is a term of art.
19529 </p>
19530 <p>
19531 Re (b), (c), and (d):  We agree with Howard's comments,
19532 and would consider adding to (c) a <tt>static constexpr</tt> requirement.
19533 </p>
19534 <p>
19535 Move to Open pending proposed wording.
19536 </p>
19537 </blockquote>
19538
19539 <p><i>[
19540 2009-05-25 Daniel adds:
19541 ]</i></p>
19542
19543
19544 <blockquote>
19545 In regards to (d) I suggest to say "a specialization of ratio" instead of
19546 "An instantiation of ratio". This seems to be the better matching standard
19547 core language term for this kind of entity.
19548 </blockquote>
19549
19550 <p><i>[
19551 2009-05-25 Ganesh adds:
19552 ]</i></p>
19553
19554
19555 <blockquote>
19556 <p>
19557 Regarding (a), I found this paper on the ISO website using the term "epoch" consistently with the current wording:
19558 </p>
19559
19560 <p>
19561 <a href="http://standards.iso.org/ittf/PubliclyAvailableStandards/C030811e_FILES/MAIN_C030811e/text/ISOIEC_18026E_TEMPORAL_CS.HTM">http://standards.iso.org/ittf/PubliclyAvailableStandards/C030811e_FILES/MAIN_C030811e/text/ISOIEC_18026E_TEMPORAL_CS.HTM</a>
19562 </p>
19563 <p>
19564 which is part of ISO/IEC 18026 "Information technology -- Spatial Reference Model (SRM)".
19565 </p>
19566 </blockquote>
19567
19568 <p><i>[
19569 2009-08-01 Howard: Moved to Reivew as the wording requested in Batavia has been provided.
19570 ]</i></p>
19571
19572
19573
19574
19575 <p><b>Proposed resolution:</b></p>
19576 <ol type="a">
19577 <li>
19578 <p>
19579 Change 20.9.1 [time.clock.req] p1:
19580 </p>
19581 <blockquote>
19582 -1- A clock is a bundle consisting of a native <tt>duration</tt>, a native <tt>time_point</tt>, and a function <tt>now()</tt> to get the
19583 current <tt>time_point</tt>.  <ins>The origin of the clock's <tt>time_point</tt> is referred to as the clock's <i>epoch</i> as defined in
19584 section 6.3 of ISO/IEC 18026.</ins>
19585 A clock shall meet the requirements in Table 45.
19586 </blockquote>
19587 </li>
19588 <li>
19589 <p>
19590 Remove the sentence from the <tt>time_point</tt> row of the table "Clock Requirements":
19591 </p>
19592 <table border="1">
19593 <caption>Clock requirements</caption>
19594 <tbody><tr>
19595 <td>
19596 <tt>C1::time_point</tt>
19597 </td>
19598 <td>
19599 <tt>chrono::time_point&lt;C1&gt;</tt> or <tt>chrono::time_point&lt;C2, C1::duration&gt;</tt>
19600 </td>
19601 <td>
19602 The native <tt>time_point</tt> type of the clock.
19603 <del>Different clocks may share a <tt>time_point</tt> definition if it is valid to compare their <tt>time_point</tt>s by comparing their respective <tt>duration</tt>s.</del>
19604 <tt>C1</tt> and <tt>C2</tt> shall refer to the same epoch.
19605 </td>
19606 </tr>
19607 </tbody></table>
19608 </li>
19609 </ol>
19610 <ol start="4" type="a">
19611 <li>
19612 <p>
19613 Change the row starting with <tt>C1::period</tt> of the table "Clock Requirements":
19614 </p>
19615 <table border="1">
19616 <caption>Clock requirements</caption>
19617 <tbody><tr>
19618 <td>
19619 <tt>C1::period</tt>
19620 </td>
19621 <td>
19622 <ins>a specialization of</ins> <tt>ratio</tt>
19623 </td>
19624 <td>
19625 The tick period of the clock in seconds.
19626 </td>
19627 </tr>
19628 </tbody></table>
19629
19630 </li>
19631 </ol>
19632
19633
19634
19635
19636
19637 <hr>
19638 <h3><a name="955"></a>955. Various threading bugs #5</h3>
19639 <p><b>Section:</b> 20.9.1 [time.clock.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
19640  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-06-07</p>
19641 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.clock.req">active issues</a> in [time.clock.req].</p>
19642 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.req">issues</a> in [time.clock.req].</p>
19643 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
19644 <p><b>Discussion:</b></p>
19645 <p>
19646 20.9.1 [time.clock.req] requires that a clock type have a member
19647 typedef named <tt>time_point</tt> that names an instantiation of the
19648 template <tt>time_point</tt>, and a member named <tt>duration</tt> that
19649 names an instantiation of the template <tt>duration</tt>. This mixing of
19650 levels is confusing. The typedef names should be different from the
19651 template names.
19652 </p>
19653
19654 <p><i>[
19655 Post Summit, Anthony provided proposed wording.
19656 ]</i></p>
19657
19658
19659 <p><i>[
19660 2009-05-04 Howard adds:
19661 ]</i></p>
19662
19663
19664 <blockquote>
19665 <p>
19666 The reason that the typedef names were given the same name as the class templates
19667 was so that clients would not have to stop and think about whether they were
19668 using the clock's native <tt>time_point</tt> / <tt>duration</tt> or the class
19669 template directly.  In this case, one person's confusion is another person's
19670 encapsulation.  The detail that sometimes one is referring to the clock's
19671 native types, and sometimes one is referring to an independent type is
19672 <em>purposefully</em> "hidden" because it is supposed to be an unimportant
19673 detail.  It can be confusing to have to remember when to type <tt>duration</tt>
19674 and when to type <tt>duration_type</tt>, and there is no need to require the
19675 client to remember something like that.
19676 </p>
19677
19678 <p>
19679 For example, here is code that I once wrote in testing out the usability of
19680 this facility:
19681 </p>
19682
19683 <blockquote><pre>template &lt;class Clock, class Duration&gt;
19684 void do_until(const std::chrono::<b>time_point</b>&lt;Clock, Duration&gt;&amp; t)
19685 {
19686     typename Clock::<b>time_point now</b> = Clock::now();
19687     if (t &gt; now)
19688     {
19689         typedef typename std::common_type
19690         &lt;
19691             Duration,
19692             typename std::chrono::system_clock::<b>duration</b>
19693         &gt;::type CD;
19694         typedef std::chrono::<b>duration</b>&lt;double, std::nano&gt; ID;
19695
19696         CD d = t - now;
19697         ID us = duration_cast&lt;ID&gt;(d);
19698         if (us &lt; d)
19699             ++us;
19700         ...
19701     }
19702 }
19703 </pre></blockquote>
19704
19705 <p>
19706 I see no rationale to require the client to append <tt>_type</tt> to <em>some</em>
19707 of those declarations.  It seems overly burdensome on the author of <tt>do_until</tt>:
19708 </p>
19709
19710 <blockquote><pre>template &lt;class Clock, class Duration&gt;
19711 void do_until(const std::chrono::<b>time_point</b>&lt;Clock, Duration&gt;&amp; t)
19712 {
19713     typename Clock::<b>time_point<font color="#c80000">_type</font></b> now = Clock::now();
19714     if (t &gt; now)
19715     {
19716         typedef typename std::common_type
19717         &lt;
19718             Duration,
19719             typename std::chrono::system_clock::<b>duration<font color="#c80000">_type</font></b>
19720         &gt;::type CD;
19721         typedef std::chrono::<b>duration</b>&lt;double, std::nano&gt; ID;
19722
19723         CD d = t - now;
19724         ID us = duration_cast&lt;ID&gt;(d);
19725         if (us &lt; d)
19726             ++us;
19727         ...
19728     }
19729 }
19730 </pre></blockquote>
19731
19732 <p>
19733 Additionally I'm fairly certain that this suggestion hasn't been implemented.
19734 If it had, it would have been discovered that it is incomplete.  <tt>time_point</tt>
19735 also has a nested type (purposefully) named <tt>duration</tt>.
19736 </p>
19737 <blockquote>
19738 That is, the current proposed wording would put the WP into an inconsistent state.
19739 </blockquote>
19740 <p>
19741 In contrast,
19742 the current WP has been implemented and I've received very favorable feedback
19743 from people using this interface in real-world code.
19744 </p>
19745
19746 </blockquote>
19747
19748 <p><i>[
19749 Batavia (2009-05):
19750 ]</i></p>
19751
19752 <blockquote>
19753 <p>
19754 Bill agrees that distinct names should be used for distinct kinds of entities.
19755 </p>
19756 <p>
19757 Walter would prefer not to suffix type names,
19758 especially for such well-understood terms as "duration".
19759 </p>
19760 <p>
19761 Howard reminds us that the proposed resolution is incomplete, per his comment
19762 in the issue.
19763 </p>
19764 <p>
19765 Move to Open.
19766 </p>
19767 </blockquote>
19768
19769 <p><i>[
19770 2009-06-07 Howard adds:
19771 ]</i></p>
19772
19773
19774 <blockquote>
19775 <p>
19776 Not meaning to be argumentative, but we have a decade of positive experience
19777 with the precedent of using the same name for the nested type as an external
19778 class representing an identical concept.
19779 </p>
19780
19781 <blockquote><pre>template&lt;class Category, class T, class Distance = ptrdiff_t,
19782          class Pointer = T*, class Reference = T&amp;&gt;
19783 struct <b>iterator</b>
19784 {
19785     ...
19786 };
19787
19788 template &lt;BidirectionalIterator Iter&gt;
19789 class <b>reverse_iterator</b>
19790 {
19791     ...
19792 };
19793
19794 template &lt;ValueType T, Allocator Alloc = allocator&lt;T&gt; &gt;
19795     requires NothrowDestructible&lt;T&gt;
19796 class list
19797 {
19798 public:
19799     typedef <i>implementation-defined</i>     <b>iterator</b>;
19800     ...
19801     typedef reverse_iterator&lt;iterator&gt; <b>reverse_iterator</b>;
19802     ...
19803 };
19804 </pre></blockquote>
19805
19806 <p>
19807 I am aware of <em>zero</em> complaints regarding the use of <tt>iterator</tt>
19808 and <tt>reverse_iterator</tt> as nested types of the containers despite these
19809 names also having related meaning at namespace std scope.
19810 </p>
19811
19812 <p>
19813 Would we really be doing programmers a favor by renaming these nested types?
19814 </p>
19815
19816 <blockquote><pre>template &lt;ValueType T, Allocator Alloc = allocator&lt;T&gt; &gt;
19817     requires NothrowDestructible&lt;T&gt;
19818 class list
19819 {
19820 public:
19821     typedef <i>implementation-defined</i>     <b>iterator_type</b>;
19822     ...
19823     typedef reverse_iterator&lt;iterator&gt; <b>reverse_iterator_type</b>;
19824     ...
19825 };
19826 </pre></blockquote>
19827
19828 <p>
19829 I submit that such design contributes to needless verbosity which ends up
19830 reducing readability.
19831 </p>
19832 </blockquote>
19833
19834
19835
19836 <p><b>Proposed resolution:</b></p>
19837 <p>
19838 Change 20.9 [time]:
19839 </p>
19840
19841 <blockquote><pre>...
19842 template &lt;class Clock, class Duration = typename Clock::duration<ins>_type</ins>&gt; class time_point;
19843 ...
19844 </pre></blockquote>
19845
19846 <p>
19847 Change 20.9.1 [time.clock.req]:
19848 </p>
19849
19850 <blockquote>
19851 <table border="1">
19852 <caption>Table 45 -- Clock requirements</caption>
19853 <tbody><tr>
19854 <th>Expression</th>
19855 <th>Return type</th>
19856 <th>Operational semantics</th>
19857 </tr>
19858 <tr>
19859 <td>...</td>
19860 <td>...</td>
19861 <td>...</td>
19862 </tr>
19863 <tr>
19864 <td><tt>C1::duration<ins>_type</ins></tt></td>
19865 <td><tt>chrono::duration&lt;C1::rep, C1::period&gt;</tt></td>
19866 <td>The native <tt>duration</tt> type of the clock.</td>
19867 </tr>
19868 <tr>
19869 <td><tt>C1::time_point<ins>_type</ins></tt></td>
19870 <td><tt>chrono::time_point&lt;C1&gt;</tt> or <tt>chrono::time_point&lt;C2, C1::duration<ins>_type</ins>&lt;</tt></td>
19871 <td>The native <tt>time_point</tt> type of the clock.   Different clocks may  share a <tt>time_point<ins>_type</ins></tt>
19872 definition if it is valid to
19873 compare their <tt>time_point<ins>_type</ins></tt>s by
19874 comparing their respective
19875 <tt>duration<ins>_type</ins></tt>s. <tt>C1</tt> and <tt>C2</tt> shall
19876 refer to the same epoch.</td>
19877 </tr>
19878 <tr>
19879 <td>...</td>
19880 <td>...</td>
19881 <td>...</td>
19882 </tr>
19883 <tr>
19884 <td><tt>C1::now()</tt></td>
19885 <td><tt>C1::time_point<ins>_type</ins></tt></td>
19886 <td>Returns a <tt>time_point<ins>_type</ins></tt> object
19887 representing the current point
19888 in time.
19889 </td>
19890 </tr>
19891 </tbody></table>
19892 </blockquote>
19893
19894 <p>
19895 Change 20.9.5.1 [time.clock.system]:
19896 </p>
19897
19898 <blockquote>
19899 <p>
19900 -1- Objects of class <tt>system_clock</tt> represent wall clock time from the system-wide realtime clock.
19901 </p>
19902
19903 <blockquote><pre>class system_clock {
19904 public:
19905   typedef <i>see below</i> rep;
19906   typedef ratio&lt;<i>unspecified</i>, <i>unspecified</i>&gt; period;
19907   typedef chrono::duration&lt;rep, period&gt; duration<ins>_type</ins>;
19908   typedef chrono::time_point&lt;system_clock&gt; time_point<ins>_type</ins>;
19909   static const bool is_monotonic = <i>unspecified</i> ;
19910
19911   static time_point<ins>_type</ins> now();
19912
19913   // Map to C API
19914   static time_t to_time_t (const time_point<ins>_type</ins>&amp; t);
19915   static time_point<ins>_type</ins> from_time_t(time_t t);
19916 };
19917 </pre></blockquote>
19918
19919 <p>
19920 -2- <tt>system_clock::duration<ins>_type</ins>::min() &lt; system_clock::duration<ins>_type</ins>::zero()</tt> shall be <tt>true</tt>.
19921 </p>
19922
19923 <pre>time_t to_time_t(const time_point<ins>_type</ins>&amp; t);
19924 </pre>
19925
19926 <blockquote>
19927 -3- <i>Returns:</i> A <tt>time_t</tt> object that represents the same
19928 point in time as <tt>t</tt> when both values are truncated to the
19929 coarser of the precisions of <tt>time_t</tt> and <tt>time_point<ins>_type</ins></tt>.
19930 </blockquote>
19931
19932 <pre><tt>time_point<ins>_type</ins></tt> from_time_t(time_t t);
19933 </pre>
19934
19935 <blockquote>
19936 -4- <i>Returns:</i> A <tt>time_point<ins>_type</ins></tt> object that represents the same point
19937 in time as <tt>t</tt> when both values are truncated to the coarser of the
19938 precisions of <tt>time_t</tt> and <tt>time_point<ins>_type</ins></tt>.
19939 </blockquote>
19940 </blockquote>
19941
19942 <p>
19943 Change 20.9.5.2 [time.clock.monotonic]:
19944 </p>
19945
19946 <blockquote><pre>class monotonic_clock {
19947 public:
19948   typedef <i>unspecified</i>                                rep;
19949   typedef ratio&lt;<i>unspecified</i> , <i>unspecified</i>&gt;           period;
19950   typedef chrono::duration&lt;rep, period&gt;              duration<ins>_type</ins>;
19951   typedef chrono::time_point&lt;<i>unspecified</i> , duration<ins>_type</ins>&gt; time_point<ins>_type</ins>;
19952   static const bool is_monotonic =                   true;
19953
19954   static time_point<ins>_type</ins> now();
19955 };
19956 </pre></blockquote>
19957
19958 <p>
19959 Change 20.9.5.3 [time.clock.hires]:
19960 </p>
19961
19962 <blockquote><pre>class high_resolution_clock {
19963 public:
19964   typedef <i>unspecified</i>                                rep;
19965   typedef ratio&lt;<i>unspecified</i> , <i>unspecified</i>&gt;           period;
19966   typedef chrono::duration&lt;rep, period&gt;              duration<ins>_type</ins>;
19967   typedef chrono::time_point&lt;<i>unspecified</i> , duration<ins>_type</ins>&gt; time_point<ins>_type</ins>;
19968   static const bool is_monotonic =                   true;
19969
19970   static time_point<ins>_type</ins> now();
19971 };
19972 </pre></blockquote>
19973
19974
19975
19976
19977
19978
19979 <hr>
19980 <h3><a name="956"></a>956. Various threading bugs #6</h3>
19981 <p><b>Section:</b> 20.9.1 [time.clock.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
19982  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-05-23</p>
19983 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.clock.req">active issues</a> in [time.clock.req].</p>
19984 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.req">issues</a> in [time.clock.req].</p>
19985 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
19986 <p><b>Discussion:</b></p>
19987 <p>
19988 20.9.1 [time.clock.req] uses the word "native" in several places,
19989 but doesn't define it. What is a "native <tt>duration</tt>"?
19990 </p>
19991
19992 <p><i>[
19993 2009-05-10 Howard adds:
19994 ]</i></p>
19995
19996
19997 <blockquote>
19998 The standard uses "native" in several places without defining it (e.g.
19999 2.14.3 [lex.ccon]).  It is meant to mean "that which is defined
20000 by the facility", or something along those lines.  In this case it refers
20001 to the nested <tt>time_point</tt> and <tt>duration</tt> types of the clock.
20002 Better wording is welcome.
20003 </blockquote>
20004
20005 <p><i>[
20006 Batavia (2009-05):
20007 ]</i></p>
20008
20009 <blockquote>
20010 Move to Open pending proposed wording from Pete.
20011 </blockquote>
20012
20013
20014 <p><b>Proposed resolution:</b></p>
20015 <p>
20016 </p>
20017
20018
20019
20020
20021
20022 <hr>
20023 <h3><a name="957"></a>957. Various threading bugs #7</h3>
20024 <p><b>Section:</b> 20.9.5.1 [time.clock.system] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
20025  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-05-23</p>
20026 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.clock.system">issues</a> in [time.clock.system].</p>
20027 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
20028 <p><b>Discussion:</b></p>
20029 <p>
20030 20.9.5.1 [time.clock.system]: <tt>to_time_t</tt> is overspecified. It
20031 requires truncation, but should allow rounding. For example, suppose a
20032 system has a clock that gives times in milliseconds, but <tt>time()</tt> rounds
20033 those times to the nearest second. Then <tt>system_clock</tt> can't use any
20034 resolution finer than one second, because if it did, truncating times
20035 between half a second and a full second would produce the wrong <tt>time_t</tt>
20036 value.
20037 </p>
20038
20039 <p><i>[
20040 Post Summit Anthony Williams provided proposed wording.
20041 ]</i></p>
20042
20043
20044 <p><i>[
20045 Batavia (2009-05):
20046 ]</i></p>
20047
20048 <blockquote>
20049 Move to Review pending input from Howard. and other stakeholders.
20050 </blockquote>
20051
20052 <p><i>[
20053 2009-05-23 Howard adds:
20054 ]</i></p>
20055
20056
20057 <blockquote>
20058 I am in favor of the wording provided by Anthony.
20059 </blockquote>
20060
20061
20062 <p><b>Proposed resolution:</b></p>
20063 <p>
20064 In 20.9.5.1 [time.clock.system] replace paragraphs 3 and 4 with:
20065 </p>
20066
20067 <blockquote>
20068 <pre>time_t to_time_t(const time_point&amp; t);
20069 </pre>
20070 <blockquote>
20071 -3- <i>Returns:</i> A <tt>time_t</tt> object that represents the same
20072 point in time as <tt>t</tt> when both values are <del>truncated</del>
20073 <ins>restricted</ins> to the coarser of the precisions of
20074 <tt>time_t</tt> and <tt>time_point</tt>. <ins> It is implementation
20075 defined whether values are rounded or truncated to the required
20076 precision.</ins>
20077 </blockquote>
20078
20079 <pre>time_point from_time_t(time_t t);
20080 </pre>
20081 <blockquote>
20082 -4- <i>Returns:</i> A <tt>time_point</tt> object that represents the
20083 same point in time as <tt>t</tt> when both values are <del>truncated</del>
20084 <ins>restricted</ins> to the
20085 coarser of the precisions of <tt>time_t</tt> and <tt>time_point</tt>.
20086 <ins>It is implementation defined whether values are
20087 rounded or truncated to the required precision.</ins>
20088 </blockquote>
20089 </blockquote>
20090
20091
20092
20093
20094
20095 <hr>
20096 <h3><a name="958"></a>958. Various threading bugs #8</h3>
20097 <p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
20098  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-08-01</p>
20099 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p>
20100 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
20101 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
20102 <p><b>Discussion:</b></p>
20103 <p>
20104 30.5.1 [thread.condition.condvar]: the specification for <tt>wait_for</tt>
20105 with no predicate has an effects clause that says it calls <tt>wait_until</tt>,
20106 and a returns clause that sets out in words how to determine the return
20107 value. Is this description of the return value subtly different from the
20108 description of the value returned by <tt>wait_until</tt>? Or should the effects
20109 clause and the returns clause be merged?
20110 </p>
20111
20112 <p><i>[
20113 Summit:
20114 ]</i></p>
20115
20116
20117 <blockquote>
20118 Move to open. Associate with LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a> and any other monotonic-clock
20119 related issues.
20120 </blockquote>
20121
20122 <p><i>[
20123 2009-08-01 Howard adds:
20124 ]</i></p>
20125
20126
20127 <blockquote>
20128 I believe that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a> (currently Ready) addresses this issue, and
20129 that this issue should be marked NAD, solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a> (assuming
20130 it moves to WP).
20131 </blockquote>
20132
20133
20134
20135 <p><b>Proposed resolution:</b></p>
20136 <p>
20137 </p>
20138
20139
20140
20141
20142
20143 <hr>
20144 <h3><a name="959"></a>959. Various threading bugs #9</h3>
20145 <p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
20146  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-08-01</p>
20147 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p>
20148 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
20149 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
20150 <p><b>Discussion:</b></p>
20151 <p>
20152 30.5.1 [thread.condition.condvar]: <tt>condition_variable::wait_for</tt>
20153 is required to compute the absolute time by adding the duration value to
20154 <tt>chrono::monotonic_clock::now()</tt>, but <tt>monotonic_clock</tt> is not required to
20155 exist.
20156 </p>
20157
20158 <p><i>[
20159 Summit:
20160 ]</i></p>
20161
20162
20163 <blockquote>
20164 Move to open. Associate with LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a> and any other monotonic-clock
20165 related issues.
20166 </blockquote>
20167
20168 <p><i>[
20169 2009-08-01 Howard adds:
20170 ]</i></p>
20171
20172
20173 <blockquote>
20174 I believe that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a> (currently Ready) addresses this issue, and
20175 that this issue should be marked NAD, solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a> (assuming
20176 it moves to WP).
20177 </blockquote>
20178
20179
20180
20181 <p><b>Proposed resolution:</b></p>
20182 <p>
20183 </p>
20184
20185
20186
20187
20188
20189 <hr>
20190 <h3><a name="960"></a>960. Various threading bugs #10</h3>
20191 <p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
20192  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-03-27</p>
20193 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.requirements">active issues</a> in [thread.mutex.requirements].</p>
20194 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
20195 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
20196 <p><b>Discussion:</b></p>
20197 <p>
20198 30.4.1 [thread.mutex.requirements]: paragraph 4 is entitled
20199 "Error conditions", but according to 17.5.1.4 [structure.specifications], "Error
20200 conditions:" specifies "the error conditions for error codes reported by
20201 the function." It's not clear what this should mean when there is no
20202 function in sight.
20203 </p>
20204
20205 <p><i>[
20206 Summit:
20207 ]</i></p>
20208
20209
20210 <blockquote>
20211 Move to open.
20212 </blockquote>
20213
20214 <p><i>[
20215 Beman provided proposed wording.
20216 ]</i></p>
20217
20218
20219
20220 <p><b>Proposed resolution:</b></p>
20221 <p>
20222 Change 30.4.1 [thread.mutex.requirements] Mutex requirements,
20223 paragraph 4 as indicated:
20224 </p>
20225
20226 <blockquote>
20227 <p>
20228 -4- <del><i>Error conditions:</i></del>
20229 <ins>The error conditions for error codes, if any, reported by member
20230 functions of type Mutex shall be:</ins>
20231 </p>
20232 <ul>
20233 <li>
20234 <tt>not_enough_memory</tt> -- if there is not enough memory to construct
20235 the mutex object.
20236 </li>
20237 <li>
20238 <tt>resource_unavailable_try_again</tt> -- if any native handle type
20239 manipulated is not available.
20240 </li>
20241 <li>
20242 <tt>operation_not_permitted</tt> -- if the thread does not have the
20243 necessary permission to change the state of the mutex object.
20244 </li>
20245 <li>
20246 <tt>device_or_resource_busy</tt> -- if any native handle type
20247 manipulated is already locked.
20248 </li>
20249 <li>
20250 <tt>invalid_argument</tt> -- if any native handle type manipulated as
20251 part of mutex construction is incorrect.
20252 </li>
20253 </ul>
20254 </blockquote>
20255
20256
20257
20258
20259
20260 <hr>
20261 <h3><a name="961"></a>961. Various threading bugs #11</h3>
20262 <p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
20263  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-03-22</p>
20264 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.requirements">active issues</a> in [thread.mutex.requirements].</p>
20265 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
20266 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
20267 <p><b>Discussion:</b></p>
20268 <p>
20269 30.4.1 [thread.mutex.requirements] describes required member
20270 functions of mutex types, and requires that they throw exceptions under
20271 certain circumstances. This is overspecified. User-defined types can
20272 abort on such errors without affecting the operation of templates
20273 supplied by standard-library.
20274 </p>
20275
20276 <p><i>[
20277 Summit:
20278 ]</i></p>
20279
20280 <blockquote>
20281 Move to open. Related to conceptualization and should probably be
20282 tackled as part of that.
20283 </blockquote>
20284
20285
20286 <p><b>Proposed resolution:</b></p>
20287 <p>
20288 </p>
20289
20290
20291
20292
20293
20294 <hr>
20295 <h3><a name="962"></a>962. Various threading bugs #12</h3>
20296 <p><b>Section:</b> 30.4.3.2.2 [thread.lock.unique.locking] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
20297  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-07-21</p>
20298 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.lock.unique.locking">active issues</a> in [thread.lock.unique.locking].</p>
20299 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.lock.unique.locking">issues</a> in [thread.lock.unique.locking].</p>
20300 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
20301 <p><b>Discussion:</b></p>
20302 <p>
20303 30.4.3.2.2 [thread.lock.unique.locking]:  <tt>unique_lock::lock</tt> is
20304 required to throw an object of type <tt>std::system_error</tt> "when the
20305 postcondition cannot be achieved." The postcondition is <tt>owns == true</tt>,
20306 and this is trivial to achieve. Presumably, the requirement is intended
20307 to mean something more than that.
20308 </p>
20309
20310 <p><i>[
20311 Summit:
20312 ]</i></p>
20313
20314 <blockquote>
20315 Move to open.
20316 </blockquote>
20317
20318 <p><i>[
20319 Beman has volunteered to provide proposed wording.
20320 ]</i></p>
20321
20322
20323 <p><i>[
20324 2009-07-21 Beman added wording to address 30.2.2 [thread.req.exception]
20325 in response to the Frankfurt notes in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>.
20326 ]</i></p>
20327
20328
20329
20330
20331 <p><b>Proposed resolution:</b></p>
20332
20333 <p><i>Change Exceptions 30.2.2 [thread.req.exception] as indicated:</i></p>
20334 <blockquote>
20335 <p>Some functions described in this Clause are specified to throw exceptions of
20336 type <code>system_error</code> (19.5.5). Such exceptions shall be thrown if <ins>
20337 any of the <i>Error conditions</i> are detected or</ins> a call to an operating
20338 system or other underlying API results in an error that prevents the library
20339 function from <del>satisfying its postconditions or from returning a meaningful
20340 value</del> <ins>meeting its specifications</ins>. <ins>Nevertheless, failure to
20341 allocate storage shall be reported as described in [res.on.exception.handling].</ins></p>
20342 </blockquote>
20343
20344 <p><i>Change thread assignment 30.3.1.4 [thread.thread.assign], join(),
20345 paragraph 8 as indicated:</i></p>
20346 <blockquote>
20347 <p><i>Throws:</i> <code>std::system_error</code> when <del>the postconditions cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
20348
20349 </blockquote>
20350
20351 <p><i>Change thread assignment 30.3.1.4 [thread.thread.assign], detach(), paragraph
20352 13 as indicated:</i></p>
20353 <blockquote>
20354
20355 <p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or
20356 postconditions cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
20357
20358 </blockquote>
20359
20360 <p><i>Change Mutex requirements 30.4.1 [thread.mutex.requirements], paragraph
20361 11, as indicated:</i></p>
20362 <blockquote>
20363
20364 <p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or
20365 postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
20366 </blockquote>
20367 <p><i>Change unique_lock locking 30.4.3.2.2 [thread.lock.unique.locking],
20368 paragraph 3, as indicated:</i></p>
20369 <blockquote>
20370
20371 <p><i>Throws:</i> <code>std::system_error</code> when <del>the  postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
20372 </blockquote>
20373 <p><i>Change unique_lock locking 30.4.3.2.2 [thread.lock.unique.locking],
20374 paragraph 8, as indicated:</i></p>
20375 <blockquote>
20376
20377 <p><i>Throws:</i> <code>std::system_error</code> when <del>the  postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
20378 </blockquote>
20379 <p><i>Change unique_lock locking 30.4.3.2.2 [thread.lock.unique.locking],
20380 paragraph 13, as indicated:</i></p>
20381 <blockquote>
20382
20383 <p><i>Throws:</i> <code>std::system_error</code> when <del>the  postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
20384 </blockquote>
20385 <p><i>Change unique_lock locking 30.4.3.2.2 [thread.lock.unique.locking],
20386 paragraph 18, as indicated:</i></p>
20387 <blockquote>
20388
20389 <p><i>Throws:</i> <code>std::system_error</code> when <del>the  postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
20390 </blockquote>
20391 <p><i>Change unique_lock locking 30.4.3.2.2 [thread.lock.unique.locking],
20392 paragraph 22, as indicated:</i></p>
20393 <blockquote>
20394
20395 <p><i>Throws:</i> <code>std::system_error</code> when <del>the  postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
20396 </blockquote>
20397 <p><i>Change Function call_once 30.4.5.2 [thread.once.callonce], paragraph 4, as
20398 indicated</i></p>
20399 <blockquote>
20400   <p><i>Throws:</i> <code>std::system_error</code> when <del>the effects cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>,
20401   or any exception thrown by <code>func</code>.</p>
20402 </blockquote>
20403 <p><i>Change Class condition_variable 30.5.1 [thread.condition.condvar],
20404 paragraph 12, as indicated:</i></p>
20405 <blockquote>
20406
20407 <p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or
20408 postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
20409 </blockquote>
20410 <p><i>Change Class condition_variable 30.5.1 [thread.condition.condvar],
20411 paragraph 19, as indicated:</i></p>
20412 <blockquote>
20413
20414 <p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or
20415 postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
20416 </blockquote>
20417 <p><i>Change Class condition_variable_any 30.5.2 [thread.condition.condvarany],
20418 paragraph 10, as indicated:</i></p>
20419 <blockquote>
20420
20421 <p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or
20422 postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
20423 </blockquote>
20424 <p><i>Change Class condition_variable_any 30.5.2 [thread.condition.condvarany],
20425 paragraph 16, as indicated:</i></p>
20426 <blockquote>
20427
20428 <p><i>Throws:</i> <code>std::system_error</code> when <del>the returned value, effects, or
20429 postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
20430 </blockquote>
20431
20432 <p><i>Assuming issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, Monotonic Clock is Conditionally Supported?, has been
20433 applied to the working paper, change Change 30.5.1 [thread.condition.condvar] as
20434 indicated:</i></p>
20435 <blockquote>
20436 <pre>template &lt;class Rep, class Period&gt;
20437 bool wait_for(unique_lock&lt;mutex&gt;&amp; lock,
20438               const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);</pre>
20439 <pre>...</pre>
20440
20441 <p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or
20442 postcondition cannot be achieved</del> <ins>an exception is required ([thread.req.exception])</ins>.</p>
20443 </blockquote>
20444
20445 <p><i>Assuming issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, Monotonic Clock is Conditionally Supported?, has been
20446 applied to the working paper, change Change 30.5.1 [thread.condition.condvar] as
20447 indicated:</i></p>
20448 <blockquote>
20449 <pre>template &lt;class Rep, class Period, class Predicate&gt;
20450   bool wait_for(unique_lock&lt;mutex&gt;&amp; lock,
20451                 const chrono::duration&lt;Rep, Period&gt;&amp; rel_time,
20452                 Predicate pred);</pre>
20453   <pre>...</pre>
20454
20455 <p><i>Throws:</i> <code>std::system_error</code> when <del>the effects or
20456 postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
20457 </blockquote>
20458
20459 <p><i>Assuming issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, Monotonic Clock is Conditionally Supported?, has been
20460 applied to the working paper, change 30.5.2 [thread.condition.condvarany] as
20461 indicated:</i></p>
20462 <blockquote>
20463 <pre>template &lt;class Lock, class Rep, class Period&gt;
20464   bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);</pre>
20465   <pre>...</pre>
20466
20467 <p><i>Throws:</i> <code>std::system_error</code> when <del>the returned value, effects or
20468 postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
20469 </blockquote>
20470
20471 <p><i>Assuming issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, Monotonic Clock is Conditionally Supported?, has been
20472 applied to the working paper, change 30.5.2 [thread.condition.condvarany] as
20473 indicated:</i></p>
20474 <blockquote>
20475 <pre>template &lt;class Lock, class Rep, class Period, class Predicate&gt;
20476   bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time, Predicate pred);</pre>
20477   <pre>...</pre>
20478
20479 <p><i>Throws:</i> <code>std::system_error</code> when <del>the returned value, effects or
20480 postcondition cannot be achieved</del> <ins>an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
20481 </blockquote>
20482
20483
20484
20485
20486
20487
20488 <hr>
20489 <h3><a name="963"></a>963. Various threading bugs #13</h3>
20490 <p><b>Section:</b> 30.3.1.5 [thread.thread.member] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
20491  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-03-22</p>
20492 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.member">active issues</a> in [thread.thread.member].</p>
20493 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.member">issues</a> in [thread.thread.member].</p>
20494 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
20495 <p><b>Discussion:</b></p>
20496 <p>
20497 30.3.1.5 [thread.thread.member]:  <tt>thread::detach</tt> is required to
20498 throw an exception if the thread is "not a detachable thread".
20499 "Detachable" is never defined.
20500 </p>
20501
20502 <p><i>[
20503 Howard adds:
20504 ]</i></p>
20505
20506
20507 <blockquote>
20508 Due to a mistake on my part, 3 proposed resolutions appeared at approximately
20509 the same time.  They are all three noted below in the discussion.
20510 </blockquote>
20511
20512 <p><i>[
20513 Summit, proposed resolution:
20514 ]</i></p>
20515
20516
20517 <blockquote>
20518 <p>
20519 In 30.3.1.5 [thread.thread.member] change:
20520 </p>
20521
20522 <blockquote><pre>void detach();
20523 </pre>
20524 <blockquote>
20525 <p>...</p>
20526 <p>-14- <i>Error conditions:</i></p>
20527 <ul>
20528 <li><tt>no_such_process</tt> --  <ins>if the thread is</ins> not <del>a</del> valid<del> thread</del>.</li>
20529 <li><tt>invalid_argument</tt> -- <ins>if the thread is</ins> not <del>a detachable</del> <ins>joinable</ins><del> thread</del>.</li>
20530 </ul>
20531 </blockquote>
20532
20533 </blockquote>
20534
20535 </blockquote>
20536
20537 <p><i>[
20538 Post Summit, Jonathan Wakely adds:
20539 ]</i></p>
20540
20541
20542 <blockquote>
20543 <p>
20544 A <tt>thread</tt> is detachable if it is joinable. As we've defined joinable,
20545 we can just use that.
20546 </p>
20547 <p>
20548 This corresponds to the pthreads specification, where pthread_detach
20549 fails if the thread is not joinable:
20550 </p>
20551 <blockquote>
20552 EINVAL: The  implementation  has  detected  that  the value specified by
20553 thread does not refer to a joinable thread.
20554 </blockquote>
20555 <p>
20556 Jonathan recommends this proposed wording:
20557 </p>
20558 <blockquote>
20559 <p>
20560 In 30.3.1.5 [thread.thread.member] change:
20561 </p>
20562
20563 <blockquote><pre>void detach();
20564 </pre>
20565 <blockquote>
20566 <p>...</p>
20567 <p>-14- <i>Error conditions:</i></p>
20568 <ul>
20569 <li>...</li>
20570 <li><tt>invalid_argument</tt> -- not a <del>detachable</del> <ins>joinable</ins> thread.</li>
20571 </ul>
20572 </blockquote>
20573
20574 </blockquote>
20575 </blockquote>
20576 </blockquote>
20577
20578 <p><i>[
20579 Post Summit, Anthony Williams adds:
20580 ]</i></p>
20581
20582
20583 <blockquote>
20584 <p>
20585 This is covered by the precondition that <tt>joinable()</tt> be <tt>true</tt>.
20586 </p>
20587 <p>
20588 Anthony recommends this proposed wording:
20589 </p>
20590
20591 <blockquote>
20592 <p>
20593 In 30.3.1.5 [thread.thread.member] change:
20594 </p>
20595
20596 <blockquote><pre>void detach();
20597 </pre>
20598 <blockquote>
20599 <p>...</p>
20600 <p>-14- <i>Error conditions:</i></p>
20601 <ul>
20602 <li>...</li>
20603 <li><del><tt>invalid_argument</tt> -- not a detachable thread.</del></li>
20604 </ul>
20605 </blockquote>
20606
20607 </blockquote>
20608
20609 </blockquote>
20610
20611 </blockquote>
20612
20613
20614
20615 <p><b>Proposed resolution:</b></p>
20616
20617
20618
20619
20620
20621 <hr>
20622 <h3><a name="964"></a>964. Various threading bugs #14</h3>
20623 <p><b>Section:</b> 30.5.2 [thread.condition.condvarany] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
20624  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-03-22</p>
20625 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
20626 <p><b>Discussion:</b></p>
20627 <p>
20628 The requirements for the constructor for <tt>condition_variable</tt> has several
20629 error conditions, but the requirements for the constructor for
20630 <tt>condition_variable_any</tt> has none. Is this difference intentional?
20631 </p>
20632
20633 <p><i>[
20634 Summit:
20635 ]</i></p>
20636
20637
20638 <blockquote>
20639 Move to open, pass to Howard. If this is intentional, a note may be
20640 helpful. If the error conditions are to be copied from
20641 <tt>condition_variable</tt>, this depends on LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#965">965</a>.
20642 </blockquote>
20643
20644 <p><i>[
20645 Post Summit Howard adds:
20646 ]</i></p>
20647
20648
20649 <blockquote>
20650 The original intention
20651 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2447.htm#ConditionVariablesWording">N2447</a>)
20652 was to let the OS return whatever errors it was going to return, and for
20653 those to be translated into exceptions, for both
20654 <tt>condition_variable</tt> and <tt>condition_variable_any</tt>.  I have not
20655 received any complaints about specific error conditions from vendors on
20656 non-POSIX platforms, but such complaints would not surprise me if they surfaced.
20657 </blockquote>
20658
20659
20660 <p><b>Proposed resolution:</b></p>
20661
20662
20663
20664
20665
20666 <hr>
20667 <h3><a name="966"></a>966. Various threading bugs #16</h3>
20668 <p><b>Section:</b> 30.5.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
20669  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-08-01</p>
20670 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.condition.condvar">active issues</a> in [thread.condition.condvar].</p>
20671 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.condition.condvar">issues</a> in [thread.condition.condvar].</p>
20672 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
20673 <p><b>Discussion:</b></p>
20674 <p>
20675 30.5.1 [thread.condition.condvar]: <tt>condition_variable::wait</tt> and
20676 <tt>condition_variable::wait_until</tt> both have a postcondition that <tt>lock</tt> is
20677 locked by the calling thread, and a throws clause that requires throwing
20678 an exception if this postcondition cannot be achieved. How can the
20679 implementation detect that this <tt>lock</tt> can never be obtained?
20680 </p>
20681
20682 <p><i>[
20683 Summit:
20684 ]</i></p>
20685
20686
20687 <blockquote>
20688 Move to open. Requires wording. Agreed this is an issue, and the
20689 specification should not require detecting deadlocks.
20690 </blockquote>
20691
20692 <p><i>[
20693 2009-08-01 Howard provides wording.
20694 ]</i></p>
20695
20696
20697 <blockquote>
20698 <p>
20699 The proposed wording is inspired by the POSIX spec which says:
20700 </p>
20701
20702 <blockquote>
20703 <dl>
20704 <dt>[EINVAL]</dt>
20705 <dd>The value specified by cond or mutex is invalid.</dd>
20706 <dt>[EPERM]</dt>
20707 <dd>The mutex was not owned by the current thread at the time of the call.</dd>
20708 </dl>
20709 </blockquote>
20710
20711 <p>
20712 I do not believe [EINVAL] is possible without memory corruption (which we don't
20713 specify).  [EPERM] is possible if this thread doesn't own the mutex, which is
20714 listed as a precondition.  "May" is used instead of "Shall" because not all
20715 OS's are POSIX.
20716 </p>
20717 </blockquote>
20718
20719
20720
20721 <p><b>Proposed resolution:</b></p>
20722 <p>
20723 Change 30.5.1 [thread.condition.condvar] p12, p19 and
20724 30.5.2 [thread.condition.condvarany] p10, p16:
20725 </p>
20726
20727 <blockquote>
20728 <i>Throws:</i> <ins>May throw</ins> <tt>std::system_error</tt>
20729 <ins>
20730 if a precondition is not met.
20731 </ins>
20732 <del>when the effects or postcondition
20733 cannot be achieved.</del>
20734 </blockquote>
20735
20736
20737
20738
20739
20740 <hr>
20741 <h3><a name="967"></a>967. Various threading bugs #17</h3>
20742 <p><b>Section:</b> 30.3.1.2 [thread.thread.constr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
20743  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-06-27</p>
20744 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.constr">active issues</a> in [thread.thread.constr].</p>
20745 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.constr">issues</a> in [thread.thread.constr].</p>
20746 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
20747 <p><b>Discussion:</b></p>
20748 <p>
20749 the error handling for the constructor for <tt>condition_variable</tt>
20750 distinguishes lack of memory from lack of other resources, but the error
20751 handling for the thread constructor does not. Is this difference
20752 intentional?
20753 </p>
20754
20755 <p><i>[
20756 Beman has volunteered to provide proposed wording.
20757 ]</i></p>
20758
20759
20760
20761 <p><b>Proposed resolution:</b></p>
20762 <p><i>Change Exceptions 30.2.2 [thread.req.exception] as indicated:</i></p>
20763 <blockquote>
20764 <p>Some functions described in this Clause are
20765 specified to throw exceptions of type <code>system_error</code> (19.5.5). Such exceptions
20766 shall be thrown if any of the <i>Error conditions</i> are detected or a call to an operating system or other underlying API
20767 results in an error that prevents the library function from meeting its specifications.
20768 <ins><i>[Note:</i> See 17.6.4.10 [res.on.exception.handling] for exceptions thrown to report
20769 storage allocation failures. <i>--end
20770 note]</i></ins></p>
20771
20772 </blockquote>
20773
20774 <p><span style="font-style: italic;">Change Mutex requirements 30.4.1 [thread.mutex.requirements],
20775 paragraph 4, as indicated:</span></p>
20776 <blockquote>
20777
20778 <p><i>Error conditions:</i></p>
20779   <blockquote>
20780
20781 <ul>
20782 <li><del> <code>not_enough_memory</code> &#8212; if there is not enough memory to construct
20783 the mutex object.</del></li>
20784
20785 <li><code>resource_unavailable_try_again</code> &#8212; if any native handle type
20786 manipulated is not available.</li>
20787
20788 <li><code>operation_not_permitted</code> &#8212; if the thread does not have the
20789 necessary permission to change the state of the mutex object.</li>
20790
20791 <li><code>device_or_resource_busy</code> &#8212; if any native handle type
20792 manipulated is already locked.</li>
20793
20794 <li><code>invalid_argument</code> &#8212; if any native handle type manipulated as
20795 part of mutex construction is incorrect.</li>
20796 </ul>
20797   </blockquote>
20798 </blockquote>
20799
20800 <p><span style="font-style: italic;">Change Class condition_variable 30.5.1 [thread.condition.condvar],
20801 default constructor, as indicated:</span></p>
20802 <blockquote>
20803   <p><code>condition_variable();</code></p>
20804   <blockquote>
20805     <p><i>Effects:</i> Constructs an object of type <code>condition_variable</code>.</p>
20806     <p><ins><i>Throws:</i> <code>std::system_error</code> when an exception is required (30.2.2 [thread.req.exception])</ins>.</p>
20807     <p><i>Error conditions:</i></p>
20808     <blockquote>
20809     <ul>
20810       <li><del><code>not_enough_memory</code> &amp;msash; if a memory limitation prevents
20811       initialization.</del></li>
20812       <li> <code>resource_unavailable_try_again</code> &amp;msash; if some non-memory
20813       resource limitation prevents initialization.</li>
20814       <li> <code>device_or_resource_busy</code> &amp;msash; if attempting to initialize a
20815       previously-initialized but as of yet undestroyed <code>condition_variable</code>.</li>
20816     </ul>
20817     </blockquote>
20818   </blockquote>
20819 </blockquote>
20820
20821
20822
20823
20824
20825 <hr>
20826 <h3><a name="968"></a>968. Various threading bugs #18</h3>
20827 <p><b>Section:</b> 30.4.1 [thread.mutex.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
20828  <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-06-27</p>
20829 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.mutex.requirements">active issues</a> in [thread.mutex.requirements].</p>
20830 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.mutex.requirements">issues</a> in [thread.mutex.requirements].</p>
20831 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
20832 <p><b>Discussion:</b></p>
20833 <p>
20834 30.4.1 [thread.mutex.requirements]: several functions are
20835 required to throw exceptions "if the thread does not have the necessary
20836 permission ...". "The necessary permission" is not defined.
20837 </p>
20838
20839 <p><i>[
20840 Summit:
20841 ]</i></p>
20842
20843 <blockquote>
20844 Move to open.
20845 </blockquote>
20846
20847
20848 <p><i>[
20849 Beman has volunteered to provide proposed wording.
20850 ]</i></p>
20851
20852
20853
20854 <p><b>Proposed resolution:</b></p>
20855
20856
20857 <p><i>Change Exceptions 30.2.2 [thread.req.exception] as indicated:</i></p>
20858 <blockquote>
20859 <p>Some functions described in this Clause are
20860 specified to throw exceptions of type <code>system_error</code> (19.5.5). Such exceptions
20861 shall be thrown if any of the <i>Error conditions</i> are detected or a call to an operating system or other underlying API
20862 results in an error that prevents the library function from meeting its specifications.
20863 <i>[Note:</i> See 17.6.4.10 [res.on.exception.handling] for exceptions thrown to report
20864 storage allocation failures. <i>&#8212;end
20865 note]</i></p>
20866
20867 <p><ins><i>[Example:</i></ins></p>
20868
20869 <blockquote>
20870
20871 <p><ins>A function in this clause that is specified to throw exceptions of type <code>
20872 system_error</code> and specifies <i>Error conditions</i> that include <code>
20873 operation_not_permitted</code> for a thread that does not have the privilege to
20874 perform the operation. During the execution of this function, an <code>errno</code>
20875 of <code>EPERM</code> is reported by a POSIX API call used by the
20876 implementation. Since POSIX specifies an <code>errno</code> of <code>EPERM</code>
20877 when "the caller does not have the privilege to perform the operation",
20878 the implementation maps <code>EPERM</code>&nbsp; to an <code>error_condition</code>
20879 of <code>operation_not_permitted</code> (19.5 [syserr]) and an exception of type <code>
20880 system_error</code> is thrown. </ins></p>
20881
20882 </blockquote>
20883
20884 <p><ins><i>&#8212;end example]</i></ins></p>
20885
20886 <p><span style="font-style: italic;">Editorial note: For the sake of exposition,
20887 the existing text above is shown with the changes proposed in issues 962 and 967. The
20888 proposed additional example is independent of whether or not the 962 and 967
20889 proposed resolutions are accepted.</span></p>
20890
20891 </blockquote>
20892
20893 <p><span style="font-style: italic;">Change Mutex requirements 30.4.1 [thread.mutex.requirements],
20894 paragraph 4, as indicated:</span></p>
20895
20896 <blockquote>
20897
20898 <p>&#8212; <code>operation_not_permitted</code> &#8212; if the thread does not have the
20899 <del>necessary permission to change the state of the mutex object</del> <ins>privilege to perform the operation</ins>.</p>
20900
20901 </blockquote>
20902
20903 <p><span style="font-style: italic;">Change Mutex requirements 30.4.1 [thread.mutex.requirements],
20904 paragraph 12, as indicated:</span></p>
20905
20906 <blockquote>
20907
20908 <p>&#8212; <code>operation_not_permitted</code> &#8212; if the thread does not have the
20909 <del>necessary permission to change the state of the mutex</del> <ins>privilege to perform the operation</ins>.</p>
20910
20911 </blockquote>
20912
20913
20914
20915
20916
20917
20918 <hr>
20919 <h3><a name="971"></a>971. Spurious diagnostic conversion function</h3>
20920 <p><b>Section:</b> 19.5.2.6 [syserr.errcode.nonmembers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">Tentatively NAD</a>
20921  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-01-19  <b>Last modified:</b> 2009-07-22</p>
20922 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD">Tentatively NAD</a> status.</p>
20923 <p><b>Discussion:</b></p>
20924 <p>
20925 Anthony Williams raised the question in c++std-lib-22987 "why is there
20926 <tt>std::make_error_code(std::errc)</tt>? What purpose does this serve?"
20927 </p>
20928 <p>
20929 The function <tt>make_error_code(errc e)</tt> is not required, since
20930 <tt>make_error_condition(errc e)</tt> is the function that is needed for <tt>errc</tt>
20931 conversions. <tt>make_error_code(errc e)</tt> appears to be a holdover from my
20932 initial confusion over the distinction between POSIX and operating
20933 systems that conform to the POSIX spec.
20934 </p>
20935
20936 <p><i>[
20937 Post Summit:
20938 ]</i></p>
20939
20940
20941 <blockquote>
20942 Recommend Review.
20943 </blockquote>
20944
20945 <p><i>[
20946 Batavia (2009-05):
20947 ]</i></p>
20948
20949 <blockquote>
20950 The designer of the facility (Christopher Kohlhoff)
20951 strongly disagrees that there is an issue here,
20952 and especially disagrees with the proposed resolution.
20953 Bill would prefer to be conservative and not apply this proposed resolution.
20954 Move to Open, and recommend strong consideration for NAD status.
20955 </blockquote>
20956
20957 <p><i>[
20958 2009-05-21 Beman adds:
20959 ]</i></p>
20960
20961
20962 <blockquote>
20963 My mistake. Christopher and Bill are correct and the issue should be
20964 NAD. The function is needed by users.
20965 </blockquote>
20966
20967 <p><i>[
20968 2009-07-21 Christopher Kohlhoff adds rationale for <tt>make_error_code</tt>:
20969 ]</i></p>
20970
20971
20972 <blockquote>
20973 <p>
20974 Users (and indeed library implementers) may need to use the
20975 <tt>errc</tt> codes in portable code. For example:
20976 </p>
20977
20978 <blockquote><pre>void do_foo(error_code&amp; ec)
20979 {
20980 #if defined(_WIN32)
20981   // Windows implementation ...
20982 #elif defined(linux)
20983   // Linux implementation ...
20984 #else
20985   // do_foo not supported on this platform
20986   ec = make_error_code(errc::not_supported);
20987 #endif
20988 }
20989 </pre></blockquote>
20990 </blockquote>
20991
20992
20993 <p><b>Proposed resolution:</b></p>
20994 <p>
20995 Change System error support 19.5 [syserr], Header <tt>&lt;system_error&gt;</tt>
20996 synopsis, as indicated:
20997 </p>
20998
20999 <blockquote><pre><del>error_code make_error_code(errc e);</del>
21000 error_condition make_error_condition(errc e);
21001 </pre></blockquote>
21002
21003 <p>
21004 Delete from Class error_code non-member functions
21005 19.5.2.6 [syserr.errcode.nonmembers]:
21006 </p>
21007
21008 <blockquote><pre><del>error_code make_error_code(errc e);</del>
21009 </pre>
21010 <blockquote>
21011 <del><i>Returns:</i> <tt>error_code(static_cast&lt;int&gt;(e),
21012 generic_category)</tt>.</del>
21013 </blockquote>
21014 </blockquote>
21015
21016
21017
21018
21019
21020
21021 <hr>
21022 <h3><a name="974"></a>974. <tt>duration&lt;double&gt;</tt> should not implicitly convert to <tt>duration&lt;int&gt;</tt></h3>
21023 <p><b>Section:</b> 20.9.3.1 [time.duration.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
21024  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-01-21  <b>Last modified:</b> 2009-08-01</p>
21025 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
21026 <p><b>Discussion:</b></p>
21027 <p>
21028 The following code should not compile because it involves implicit truncation
21029 errors (against the design philosophy of the <tt>duration</tt> library).
21030 </p>
21031
21032 <blockquote><pre>duration&lt;double&gt; d(3.5);
21033 duration&lt;int&gt; i = d;  <font color="#c80000">// implicit truncation, should not compile</font>
21034 </pre></blockquote>
21035
21036 <p>
21037 This intent was codified in the example implementation which drove this proposal
21038 but I failed to accurately translate the code into the specification in this
21039 regard.
21040 </p>
21041
21042 <p><i>[
21043 Batavia (2009-05):
21044 ]</i></p>
21045
21046 <blockquote>
21047 <p>
21048 We agree with the proposed resolution.
21049 </p>
21050 <p>
21051 Move to Tentatively Ready.
21052 </p>
21053 </blockquote>
21054
21055 <p><i>[
21056 2009-07 Frankfurt
21057 ]</i></p>
21058
21059
21060 <blockquote>
21061 Moved from Tentatively Ready to Open only because the wording needs to be
21062 improved for enable_if type constraining, possibly following Robert's
21063 formula.
21064 </blockquote>
21065
21066 <p><i>[
21067 2009-08-01 Howard adds:
21068 ]</i></p>
21069
21070
21071 <blockquote>
21072 Addressed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1177">1177</a>.
21073 </blockquote>
21074
21075
21076
21077 <p><b>Proposed resolution:</b></p>
21078 <p>
21079 Change 20.9.3.1 [time.duration.cons], p4:
21080 </p>
21081
21082 <blockquote>
21083 <pre>template &lt;class Rep2, class Period2&gt;
21084   duration(const duration&lt;Rep2, Period2&gt;&amp; d);
21085 </pre>
21086 <blockquote>
21087 -4- <i>Requires:</i> <tt>treat_as_floating_point&lt;rep&gt;::value</tt>
21088 shall be <tt>true</tt> or <ins>both</ins> <tt>ratio_divide&lt;Period2,
21089 period&gt;::type::den</tt> shall be 1
21090 <ins>and <tt>treat_as_floating_point&lt;Rep2&gt;::value</tt>
21091 shall be <tt>false</tt></ins>.
21092 Diagnostic required.
21093 [<i>Note:</i> This requirement prevents implicit truncation error when
21094 converting between integral-based <tt>duration</tt> types. Such a
21095 construction could easily lead to confusion about the value of the
21096 <tt>duration</tt>. -- <i>end note</i>]
21097 </blockquote>
21098 </blockquote>
21099
21100
21101
21102
21103
21104 <hr>
21105 <h3><a name="976"></a>976. Class template std::stack should be movable</h3>
21106 <p><b>Section:</b> 23.3.5.3.1 [stack.defn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
21107  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-02-01  <b>Last modified:</b> 2009-07-14</p>
21108 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
21109 <p><b>Discussion:</b></p>
21110 <p>
21111 The synopsis given in 23.3.5.3.1 [stack.defn] does not show up
21112 </p>
21113
21114 <blockquote><pre>requires MoveConstructible&lt;Cont&gt; stack(stack&amp;&amp;);
21115 requires MoveAssignable&lt;Cont&gt; stack&amp; operator=(stack&amp;&amp;);
21116 </pre></blockquote>
21117
21118 <p>
21119 although the other container adaptors do provide corresponding
21120 members.
21121 </p>
21122
21123 <p><i>[
21124 Batavia (2009-05):
21125 ]</i></p>
21126
21127 <blockquote>
21128 <p>
21129 We agree with the proposed resolution.
21130 </p>
21131 <p>
21132 Move to Tentatively Ready.
21133 </p>
21134 </blockquote>
21135
21136 <p><i>[
21137 2009-07 Frankfurt
21138 ]</i></p>
21139
21140
21141 <blockquote>
21142 Moved from Tentatively Ready to Open only because the wording needs to be
21143 tweaked for concepts removal.
21144 </blockquote>
21145
21146
21147
21148 <p><b>Proposed resolution:</b></p>
21149 <p>
21150 In the class stack synopsis of 23.3.5.3.1 [stack.defn] insert:
21151 </p>
21152
21153 <blockquote><pre>template &lt;ObjectType T, StackLikeContainer Cont = deque&lt;T&gt; &gt;
21154   requires SameType&lt;Cont::value_type, T&gt;
21155         &amp;&amp; NothrowDestructible&lt;Cont&gt;
21156 class stack {
21157 public:
21158    ...
21159    requires CopyConstructible&lt;Cont&gt; explicit stack(const Cont&amp;);
21160    requires MoveConstructible&lt;Cont&gt; explicit stack(Cont&amp;&amp; = Cont());
21161    <ins>requires MoveConstructible&lt;Cont&gt; stack(stack&amp;&amp;);</ins>
21162    <ins>requires MoveAssignable&lt;Cont&gt; stack&amp; operator=(stack&amp;&amp;);</ins>
21163    template &lt;class Alloc&gt;
21164      requires Constructible&lt;Cont, const Alloc&amp;&gt;
21165      explicit stack(const Alloc&amp;);
21166    ...
21167 };
21168 </pre></blockquote>
21169
21170 <p>
21171 [Remark: This change should be done in sync with the resolution of
21172 paper
21173 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2819.html">N2819</a>]
21174 </p>
21175
21176
21177
21178
21179
21180
21181 <hr>
21182 <h3><a name="977"></a>977. insert iterators inefficient for expensive to move types</h3>
21183 <p><b>Section:</b> 24.7 [insert.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
21184  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-02  <b>Last modified:</b> 2009-05-23</p>
21185 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#insert.iterators">active issues</a> in [insert.iterators].</p>
21186 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#insert.iterators">issues</a> in [insert.iterators].</p>
21187 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
21188 <p><b>Discussion:</b></p>
21189 <p>
21190 The new concepts for the insert iterators mandate an extra copy when
21191 inserting an lvalue:
21192 </p>
21193
21194 <blockquote><pre>requires CopyConstructible&lt;Cont::value_type&gt;
21195   back_insert_iterator&lt;Cont&gt;&amp;
21196   operator=(const Cont::value_type&amp; value);
21197 </pre>
21198 <blockquote>
21199 -1- <i>Effects:</i> <tt>push_back(*container, <b>Cont::value_type(</b>value<b>)</b>);</tt>
21200 </blockquote>
21201 </blockquote>
21202
21203 <p>
21204 The reason is to convert <tt>value</tt> into an rvalue because the current
21205 <tt>BackInsertionContainer</tt> concept only handles <tt>push_back</tt>-ing
21206 rvalues:
21207 </p>
21208
21209 <blockquote><pre>concept BackInsertionContainer&lt;typename C&gt; : Container&lt;C&gt; {
21210   void push_back(C&amp;, value_type&amp;&amp;);
21211 }
21212 </pre></blockquote>
21213
21214 <p>
21215 Without the conversion of <tt>value</tt> to an rvalue, the assignment operator
21216 fails to concept check.
21217 </p>
21218
21219 <p>
21220 A solution is to modify the <tt>BackInsertionContainer</tt> concept so that
21221 the client can pass in the parameter type for <tt>push_back</tt> similar to
21222 what is already done for the <tt>OutputIterator</tt> concept:
21223 </p>
21224
21225 <blockquote><pre>concept BackInsertionContainer&lt;typename C, typename Value = C::value_type&amp;&amp;&gt;
21226   : Container&lt;C&gt; {
21227      void push_back(C&amp;, Value);
21228 }
21229 </pre></blockquote>
21230
21231 <p>
21232 This allows the assignment operator to be adjusted appropriately:
21233 </p>
21234
21235 <blockquote><pre>requires BackInsertionContainer&lt;Cont, Cont::value_type const&amp;&gt; &amp;&amp;
21236          CopyConstructible&lt;Cont::value_type&gt;
21237   back_insert_iterator&lt;Cont&gt;&amp;
21238   operator=(const Cont::value_type&amp; value);
21239 </pre>
21240 <blockquote>
21241 -1- <i>Effects:</i> <tt>push_back(*container, value);</tt>
21242 </blockquote>
21243 </blockquote>
21244
21245 <p><i>[
21246 We may want to propagate this fix to other concepts such as <tt>StackLikeContainer</tt>.
21247 ]</i></p>
21248
21249
21250 <p><i>[
21251 Solution and wording collaborated on by Doug and Howard.
21252 ]</i></p>
21253
21254
21255 <p><i>[
21256 Batavia (2009-05):
21257 ]</i></p>
21258
21259 <blockquote>
21260 <p>
21261 Howard notes that "these operations behaved efficiently until concepts were added."
21262 </p>
21263 <p>
21264 Alisdair is uncertain that the proposed resolution is syntactically correct.
21265 </p>
21266 <p>
21267 Move to Open, and recommend the issue be deferred until after the next
21268 Committee Draft is issued.
21269 </p>
21270 </blockquote>
21271
21272
21273 <p><b>Proposed resolution:</b></p>
21274 <p>
21275 Change 23.2.6.1 [container.concepts.free]:
21276 </p>
21277
21278 <blockquote>
21279 <pre>concept FrontInsertionContainer&lt;typename C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt;
21280     : Container&lt;C&gt; {
21281   void push_front(C&amp;, <del>value_type&amp;&amp;</del> <ins>Value</ins>);
21282
21283   axiom FrontInsertion(C c, <del>value_type</del> <ins>Value</ins> x) {
21284     x == (push_front(c, x), front(c));
21285   }
21286 }
21287 </pre>
21288
21289 <p>...</p>
21290
21291 <pre>concept BackInsertionContainer&lt;typename C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt;
21292     : Container&lt;C&gt; {
21293   void push_back(C&amp;, <del>value_type&amp;&amp;</del> <ins>Value</ins>);
21294 }
21295 </pre>
21296
21297 <p>...</p>
21298
21299 <pre>concept InsertionContainer&lt;typename C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt;
21300     : Container&lt;C&gt; {
21301   iterator insert(C&amp;, const_iterator, <del>value_type&amp;&amp;</del> <ins>Value</ins>);
21302
21303   axiom Insertion(C c, const_iterator position, <del>value_type</del> <ins>Value</ins> v) {
21304     v == *insert(c, position, v);
21305   }
21306 }
21307 </pre>
21308
21309 </blockquote>
21310
21311 <p>
21312 Change 23.2.6.2 [container.concepts.member]:
21313 </p>
21314
21315 <blockquote>
21316 <pre>auto concept MemberFrontInsertionContainer&lt;typename C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt;
21317     : MemberContainer&lt;C&gt; {
21318   void C::push_front(<del>value_type&amp;&amp;</del> <ins>Value</ins>);
21319
21320   axiom MemberFrontInsertion(C c, <del>value_type</del> <ins>Value</ins> x) {
21321     x == (c.push_front(x), c.front());
21322   }
21323 }
21324 </pre>
21325
21326 <p>...</p>
21327
21328 <pre>auto concept MemberBackInsertionContainer&lt;typename C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt;
21329     : MemberContainer&lt;C&gt; {
21330   void C::push_back(<del>value_type&amp;&amp;</del> <ins>Value</ins>);
21331 }
21332 </pre>
21333
21334 <p>...</p>
21335
21336 <pre>auto concept MemberInsertionContainer&lt;typename C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt;
21337     : MemberContainer&lt;C&gt; {
21338   iterator C::insert(const_iterator, <del>value_type&amp;&amp;</del> <ins>Value</ins>);
21339
21340   axiom MemberInsertion(C c, const_iterator position, <del>value_type</del> <ins>Value</ins> v) {
21341     v == *c.insert(position, v);
21342   }
21343 }
21344 </pre>
21345 </blockquote>
21346
21347 <p>
21348 Change 23.2.6.3 [container.concepts.maps]:
21349 </p>
21350
21351 <blockquote>
21352 <pre>template &lt;MemberFrontInsertionContainer C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt;
21353 concept_map FrontInsertionContainer&lt;C<ins>, Value</ins>&gt; {
21354   typedef Container&lt;C&gt;::value_type value_type;
21355
21356   void push_front(C&amp; c, <del>value_type&amp;&amp;</del> <ins>Value</ins> v) { c.push_front(static_cast&lt;<del>value_type&amp;&amp;</del> <ins>Value</ins>&gt;(v)); }
21357 }
21358 </pre>
21359
21360 <p>...</p>
21361
21362 <pre>template &lt;MemberBackInsertionContainer C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt;
21363 concept_map BackInsertionContainer&lt;C<ins>, Value</ins>&gt; {
21364   typedef Container&lt;C&gt;::value_type value_type;
21365
21366   void push_back(C&amp; c, <del>value_type&amp;&amp;</del> <ins>Value</ins> v) { c.push_back(static_cast&lt;<del>value_type&amp;&amp;</del> <ins>Value</ins>&gt;(v)); }
21367 }
21368 </pre>
21369
21370 <p>...</p>
21371
21372 <pre>template &lt;MemberInsertionContainer C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt;
21373 concept_map InsertionContainer&lt;C<ins>, Value</ins>&gt; {
21374   typedef Container&lt;C&gt;::value_type value_type;
21375   Container&lt;C&gt;::iterator insert(C&amp; c, Container&lt;C&gt;::const_iterator i, <del>value_type&amp;&amp;</del> <ins>Value</ins> v)
21376   { return c.insert(i, static_cast&lt;<del>value_type&amp;&amp;</del> <ins>Value</ins>&gt;(v)); }
21377 }
21378 </pre>
21379
21380 </blockquote>
21381
21382 <p>
21383 Change 24.7.1 [back.insert.iterator]:
21384 </p>
21385
21386 <blockquote><pre>template &lt;BackInsertionContainer Cont&gt;
21387 class back_insert_iterator {
21388   ...
21389   requires <ins>BackInsertionContainer&lt;Cont, const Cont::value_type&amp;&gt;</ins>
21390            <del>CopyConstructible&lt;Cont::value_type&gt;</del>
21391     back_insert_iterator&lt;Cont&gt;&amp;
21392       operator=(const Cont::value_type&amp; value);
21393   ...
21394 </pre></blockquote>
21395
21396 <p>
21397 Change 24.7.2.2 [back.insert.iter.op=]:
21398 </p>
21399
21400 <blockquote>
21401 <pre>requires <ins>BackInsertionContainer&lt;Cont, const Cont::value_type&amp;&gt;</ins>
21402          <del>CopyConstructible&lt;Cont::value_type&gt;</del>
21403   back_insert_iterator&lt;Cont&gt;&amp;
21404     operator=(const Cont::value_type&amp; value);
21405 </pre>
21406 <blockquote>
21407 -1- <i>Effects:</i> <tt>push_back(*container, <del>Cont::value_type(</del>value<del>)</del>);</tt>
21408 </blockquote>
21409 </blockquote>
21410
21411 <p>
21412 Change 24.7.3 [front.insert.iterator]:
21413 </p>
21414
21415 <blockquote><pre>template &lt;FrontInsertionContainer Cont&gt;
21416 class front_insert_iterator {
21417   ...
21418   requires <ins>FrontInsertionContainer&lt;Cont, const Cont::value_type&amp;&gt;</ins>
21419            <del>CopyConstructible&lt;Cont::value_type&gt;</del>
21420     front_insert_iterator&lt;Cont&gt;&amp;
21421       operator=(const Cont::value_type&amp; value);
21422   ...
21423 </pre></blockquote>
21424
21425 <p>
21426 Change 24.7.4.2 [front.insert.iter.op=]:
21427 </p>
21428
21429 <blockquote>
21430 <pre>requires <ins>FrontInsertionContainer&lt;Cont, const Cont::value_type&amp;&gt;</ins>
21431          <del>CopyConstructible&lt;Cont::value_type&gt;</del>
21432   front_insert_iterator&lt;Cont&gt;&amp;
21433     operator=(const Cont::value_type&amp; value);
21434 </pre>
21435 <blockquote>
21436 -1- <i>Effects:</i> <tt>push_front(*container, <del>Cont::value_type(</del>value<del>)</del>);</tt>
21437 </blockquote>
21438 </blockquote>
21439
21440 <p>
21441 Change 24.7.5 [insert.iterator]:
21442 </p>
21443
21444 <blockquote><pre>template &lt;InsertionContainer Cont&gt;
21445 class insert_iterator {
21446   ...
21447   requires <ins>InsertionContainer&lt;Cont, const Cont::value_type&amp;&gt;</ins>
21448            <del>CopyConstructible&lt;Cont::value_type&gt;</del>
21449     insert_iterator&lt;Cont&gt;&amp;
21450       operator=(const Cont::value_type&amp; value);
21451   ...
21452 </pre></blockquote>
21453
21454 <p>
21455 Change 24.7.6.2 [insert.iter.op=]:
21456 </p>
21457
21458 <blockquote>
21459 <pre>requires <ins>InsertionContainer&lt;Cont, const Cont::value_type&amp;&gt;</ins>
21460          <del>CopyConstructible&lt;Cont::value_type&gt;</del>
21461   insert_iterator&lt;Cont&gt;&amp;
21462     operator=(const Cont::value_type&amp; value);
21463 </pre>
21464 <blockquote>
21465 <p>
21466 -1- <i>Effects:</i>
21467 </p>
21468 <blockquote><pre>iter = insert(*container, iter, <del>Cont::value_type(</del>value<del>)</del>);
21469 ++iter;
21470 </pre></blockquote>
21471 </blockquote>
21472 </blockquote>
21473
21474
21475
21476
21477
21478
21479 <hr>
21480 <h3><a name="978"></a>978. Hashing smart pointers</h3>
21481 <p><b>Section:</b> 20.7.17 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
21482  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-02-02  <b>Last modified:</b> 2009-07-28</p>
21483 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.hash">active issues</a> in [unord.hash].</p>
21484 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.hash">issues</a> in [unord.hash].</p>
21485 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
21486 <p><b>Discussion:</b></p>
21487 <p>
21488 I don't see an open issue on supporting <tt>std::hash</tt> for smart pointers
21489 (<tt>unique_ptr</tt> and <tt>shared_ptr</tt> at least).
21490 </p>
21491 <p>
21492 It seems reasonable to at least expect support for the smart
21493 pointers, especially as they support comparison for use in ordered
21494 associative containers.
21495 </p>
21496
21497 <p><i>[
21498 Batavia (2009-05):
21499 ]</i></p>
21500
21501 <blockquote>
21502 <p>
21503 Howard points out that the client can always supply a custom hash function.
21504 </p>
21505 <p>
21506 Alisdair replies that the smart pointer classes are highly likely
21507 to be frequently used as hash keys.
21508 </p>
21509 <p>
21510 Bill would prefer to be conservative.
21511 </p>
21512 <p>
21513 Alisdair mentions that this issue may also be viewed as a subissue or
21514 duplicate of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1025">1025</a>.
21515 </p>
21516 <p>
21517 Move to Open, and recommend the issue be deferred until after the next
21518 Committee Draft is issued.
21519 </p>
21520 </blockquote>
21521
21522 <p><i>[
21523 2009-05-31 Peter adds:
21524 ]</i></p>
21525
21526
21527 <blockquote>
21528 <blockquote>
21529 Howard points out that the client can always supply a custom hash function.
21530 </blockquote>
21531 <p>
21532 Not entirely true. The client cannot supply the function that hashes the
21533 address of the control block (the equivalent of the old <tt>operator&lt;</tt>, now
21534 proudly carrying the awkward name of '<tt>owner_before</tt>'). Only the
21535 implementation can do that, not necessarily via specializing <tt>hash&lt;&gt;</tt>, of
21536 course.
21537 </p>
21538 <p>
21539 This hash function makes sense in certain situations for <tt>shared_ptr</tt>
21540 (when one needs to switch from <tt>set/map</tt> using ownership ordering to
21541 <tt>unordered_set/map</tt>) and is the only hash function that makes sense for
21542 <tt>weak_ptr</tt>.
21543 </p>
21544 </blockquote>
21545
21546 <p><i>[
21547 2009-07-28 Alisdair provides wording.
21548 ]</i></p>
21549
21550
21551
21552
21553 <p><b>Proposed resolution:</b></p>
21554 <p>
21555 Add the following declarations to the synopsis of <tt>&lt;memory&gt;</tt>
21556 in 20.8 [memory]
21557 </p>
21558
21559 <blockquote><pre>// 20.8.10.X hash support
21560 template &lt;class T&gt; struct hash;
21561 template &lt;class T, class D&gt; struct hash&lt;unique_ptr&lt;T,D&gt;&gt;;
21562 template &lt;class T&gt; struct hash&lt;shared_ptr&lt;T&gt;&gt;;
21563 </pre></blockquote>
21564
21565 <p>
21566 Add a new subclause 20.8.10.X hash support
21567 </p>
21568
21569 <blockquote>
21570 <p>
21571 20.8.10.X hash support [util.smartptr.hash]
21572 </p>
21573
21574 <pre>template &lt;class T, class D&gt; struct hash&lt;unique_ptr&lt;T,D&gt;&gt;;
21575 </pre>
21576
21577 <blockquote>
21578 A partial specialization of the class template <tt>hash</tt> (20.7.17 [unord.hash]) shall be provided for instances of the
21579 <tt>unique_ptr</tt> template suitable for use as a key in unordered
21580 associative containers (23.5 [unord]) if and only if there is a
21581 <tt>hash</tt> specialization available for the type <tt>D::pointer</tt>.
21582 For an object <tt>p</tt> of type <tt>unqiue_ptr&lt;T,D&gt;</tt> the
21583 <tt>hash</tt> shall evaluate to the same value as <tt>hash&lt;typename
21584 D::pointer&gt;{}(p.get())</tt>.
21585 </blockquote>
21586
21587 <pre>template &lt;class T&gt; struct hash&lt;shared_ptr&lt;T&gt;&gt;;
21588 </pre>
21589
21590 <blockquote>
21591 A partial specialization of the class template <tt>hash</tt> (20.7.17 [unord.hash])
21592 shall be provided for instances of the <tt>shared_ptr</tt> template
21593 suitable for use as a key in unordered associative containers
21594 (23.5 [unord]). For an object <tt>p</tt> of type <tt>shared_ptr&lt;T&gt;</tt>
21595 the <tt>hash</tt> shall evaluate
21596 to the same value as <tt>hash&lt;T*&gt;{}(p.get())</tt>.
21597 </blockquote>
21598 </blockquote>
21599
21600
21601
21602
21603
21604 <hr>
21605 <h3><a name="983"></a>983. <tt>unique_ptr</tt> reference deleters should not be moved from</h3>
21606 <p><b>Section:</b> 20.8.9.2 [unique.ptr.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
21607  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-10  <b>Last modified:</b> 2009-05-23</p>
21608 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single">active issues</a> in [unique.ptr.single].</p>
21609 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single">issues</a> in [unique.ptr.single].</p>
21610 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
21611 <p><b>Discussion:</b></p>
21612 <p>
21613 Dave brought to my attention that when a <tt>unique_ptr</tt> has a non-const reference
21614 type deleter, move constructing from it, even when the <tt>unique_ptr</tt> containing
21615 the reference is an rvalue, could have surprising results:
21616 </p>
21617
21618 <blockquote><pre>D d(some-state);
21619 unique_ptr&lt;A, D&amp;&gt; p(new A, d);
21620 unique_ptr&lt;A, D&gt; p2 = std::move(p);
21621 <font color="#c80000">// has d's state changed here?</font>
21622 </pre></blockquote>
21623
21624 <p>
21625 I agree with him.  It is the <tt>unique_ptr</tt> that is the rvalue, not the
21626 deleter.  When the deleter is a reference type, the <tt>unique_ptr</tt> should
21627 respect the "lvalueness" of the deleter.
21628 </p>
21629
21630 <p>
21631 Thanks Dave.
21632 </p>
21633
21634 <p><i>[
21635 Batavia (2009-05):
21636 ]</i></p>
21637
21638 <blockquote>
21639 Seems correct, but complicated enough that we recommend moving to Review.
21640 </blockquote>
21641
21642
21643 <p><b>Proposed resolution:</b></p>
21644 <p>
21645 Change 20.8.9.2.1 [unique.ptr.single.ctor], p20-21
21646 </p>
21647
21648 <blockquote>
21649 <pre>template &lt;class U, class E&gt; unique_ptr(unique_ptr&lt;U, E&gt;&amp;&amp; u);
21650 </pre>
21651
21652 <blockquote>
21653
21654 <p>
21655 -20- <i>Requires:</i> If <tt><del>D</del> <ins>E</ins></tt> is not a reference type,
21656 construction of the deleter <tt>D</tt> from an rvalue of type <tt>E</tt>
21657 shall be well formed and shall not throw an exception.
21658 <ins>
21659 Otherwise <tt>E</tt> is a reference type and construction of the deleter
21660 <tt>D</tt> from an lvalue of type <tt>E</tt> shall be well formed and
21661 shall not throw an exception.
21662 </ins>
21663 If <tt>D</tt> is
21664 a reference type, then <tt>E</tt> shall be the same type as <tt>D</tt>
21665 (diagnostic required). <tt>unique_ptr&lt;U, E&gt;::pointer</tt> shall be
21666 implicitly convertible to <tt>pointer</tt>. [<tt>Note:</tt> These
21667 requirements imply that <tt>T</tt> and <tt>U</tt> are complete types.
21668 <i>-- end note</i>]
21669 </p>
21670
21671 <p>
21672 -21- <i>Effects:</i> Constructs a <tt>unique_ptr</tt> which owns the
21673 pointer which <tt>u</tt> owns (if any). If the deleter
21674 <ins><tt>E</tt></ins> is not a reference type, <del>it</del> <ins>this
21675 deleter</ins> is move constructed from <tt>u</tt>'s deleter, otherwise
21676 <del>the reference</del> <ins>this deleter</ins> is copy constructed
21677 from <tt>u</tt>.'s deleter. After the construction, <tt>u</tt> no longer
21678 owns a pointer. [<i>Note:</i> The deleter constructor can be implemented
21679 with <tt>std::forward&lt;<del>D</del><ins>E</ins>&gt;</tt>. <i>-- end
21680 note</i>]
21681 </p>
21682
21683 </blockquote>
21684 </blockquote>
21685
21686 <p>
21687 Change 20.8.9.2.3 [unique.ptr.single.asgn], p1-3
21688 </p>
21689
21690 <blockquote>
21691 <pre>unique_ptr&amp; operator=(unique_ptr&amp;&amp; u);
21692 </pre>
21693 <blockquote>
21694
21695 <p>
21696 -1- <i>Requires:</i> <ins>If the deleter <tt>D</tt> is not a reference type,</ins>
21697 <del>A</del><ins>a</ins>ssignment of the deleter <tt>D</tt> from an rvalue <tt>D</tt> shall not throw an exception.
21698 <ins>
21699 Otherwise the deleter <tt>D</tt> is a reference type,
21700 and assignment of the deleter <tt>D</tt> from an lvalue <tt>D</tt> shall not throw an exception.</ins>
21701 </p>
21702
21703 <p>
21704 -2- <i>Effects:</i> reset(u.release()) followed by
21705 a<ins>n</ins> <del>move</del> assignment from <del><tt>u</tt>'s deleter to this deleter</del>
21706 <ins><tt>std::forward&lt;D&gt;(u.get_deleter())</tt></ins>.
21707 </p>
21708
21709 <p>
21710 -3- <i>Postconditions:</i> This <tt>unique_ptr</tt> now owns the pointer
21711 which <tt>u</tt> owned, and <tt>u</tt> no longer owns it. <del>[<i>Note:</i> If
21712 <tt>D</tt> is a reference type, then the referenced lvalue deleters are
21713 move assigned. <i>-- end note</i>]</del>
21714 </p>
21715 </blockquote>
21716 </blockquote>
21717
21718 <p>
21719 Change 20.8.9.2.3 [unique.ptr.single.asgn], p6-7
21720 </p>
21721
21722 <blockquote>
21723 <pre>template &lt;class U, class E&gt; unique_ptr&amp; operator=(unique_ptr&lt;U, E&gt;&amp;&amp; u);
21724 </pre>
21725 <blockquote>
21726
21727 <p>
21728 <i>Requires:</i> <ins>If the deleter <tt>E</tt> is not a reference type,</ins>
21729 <del>A</del><ins>a</ins>ssignment of the deleter <tt>D</tt> from an rvalue
21730 <tt><del>D</del><ins>E</ins></tt> shall not throw an exception.
21731 <ins>
21732 Otherwise the deleter <tt>E</tt> is a reference type,
21733 and assignment of the deleter <tt>D</tt> from an lvalue <tt>E</tt> shall not throw an exception.</ins>
21734 <tt>unique_ptr&lt;U, E&gt;::pointer</tt> shall be implicitly convertible to <tt>pointer</tt>.
21735 [<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U&gt;</tt>
21736 are complete types. <i>-- end note</i>]
21737 </p>
21738
21739 <p>
21740 <i>Effects:</i> <tt>reset(u.release())</tt> followed by
21741 a<ins>n</ins> <del>move</del> assignment from <del><tt>u</tt>'s deleter to this deleter</del>
21742 <ins><tt>std::forward&lt;E&gt;(u.get_deleter())</tt></ins>.
21743 <del>If either
21744 <tt>D</tt> or <tt>E</tt> is a reference type, then the referenced lvalue
21745 deleter participates in the move assignment.</del>
21746 </p>
21747
21748 </blockquote>
21749 </blockquote>
21750
21751
21752
21753
21754
21755
21756 <hr>
21757 <h3><a name="985"></a>985. Allowing throwing move</h3>
21758 <p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
21759  <b>Submitter:</b> Rani Sharoni <b>Opened:</b> 2009-02-12  <b>Last modified:</b> 2009-05-23</p>
21760 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
21761 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
21762 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
21763 <p><b>Discussion:</b></p>
21764 <p>
21765 <b>Introduction</b>
21766 </p>
21767
21768 <p>This proposal is meant to resolve potential regression of the
21769 <a href="" ref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>
21770 draft, see
21771 next section, and to relax the requirements for containers of types with
21772 throwing move constructors.</p>
21773
21774 <p>The basic problem is that some containers operations, like <tt>push_back</tt>,
21775 have a strong exception safety
21776 guarantee (i.e. no side effects upon exception) that are not achievable when
21777 throwing move constructors are used since there is no way to guarantee revert
21778 after partial move. For such operations the implementation can at most provide
21779 the basic guarantee (i.e. valid but unpredictable) as it does with multi
21780 copying operations (e.g. range insert).</p>
21781
21782 <p>For example, <tt>vector&lt;T&gt;::push_back()</tt> (where <tt>T</tt> has a move
21783 constructor) might resize the <tt>vector</tt> and move the objects to the new underlying
21784 buffer. If move constructor throws it might
21785 not be possible to recover the throwing object or to move the old objects back to
21786 the original buffer.</p>
21787
21788 <p>The current draft is explicit by disallowing throwing move
21789 for some operations (e.g. <tt>vector&lt;&gt;::reserve</tt>) and not clear about other
21790 operations mentioned in 23.2.1 [container.requirements.general]/10
21791 (e.g. single element <tt>insert</tt>): it guarantees strong exception
21792 safety without explicitly disallowing a throwing move constructor.
21793 </p>
21794
21795 <p>
21796 <b>Regression</b>
21797 </p>
21798
21799 <p>This section only refers to cases in which the contained object
21800 is by itself a standard container.</p>
21801
21802 <p>Move constructors of standard containers are allowed to throw and therefore
21803 existing operations are broken, compared with C++03, due to move optimization.
21804 (In fact existing implementations like Dinkumware are actually throwing).</p>
21805
21806 <p>For example, <tt>vector&lt; list&lt;int&gt; &gt;::reserve</tt> yields
21807 undefined behavior since <tt>list&lt;int&gt;</tt>'s move constructor is allowed to throw.
21808 On the other hand, the same operation has strong exception safety guarantee in
21809 C++03.</p>
21810
21811 <p>There are few options to solve this regression:</p>
21812
21813 <ol>
21814 <li>
21815 Disallow throwing move and throwing default constructor
21816 </li>
21817
21818 <li>
21819 Disallow throwing move but disallowing usage after move
21820 </li>
21821
21822 <li>
21823 Special casing
21824 </li>
21825
21826 <li>
21827 Disallow throwing move and making it optional
21828 </li>
21829
21830 </ol>
21831
21832 <p>Option 1 is suggested by proposal
21833 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2815.html">N2815</a>
21834 but it might not be applicable for existing implementations for which
21835 containers default constructors are throwing.</p>
21836
21837 <p>Option 2 limits the usage significantly and it's error prone
21838 by allowing zombie objects that are nothing but destructible (e.g. no <tt>clear()</tt>
21839 is allowed after move). It also potentially complicates the implementation by
21840 introducing special state.</p>
21841
21842 <p>Option 3 is possible, for example, using default
21843 construction and <tt>swap</tt> instead of move for standard containers case. The
21844 implementation is also free to provide special hidden operation for non
21845 throwing move without forcing the user the cope with the limitation of option-2
21846 when using the public move.</p>
21847
21848 <p>Option 4 impact the efficiency in all use cases due to rare throwing move.</p>
21849
21850 <p>The proposed wording will imply option 1 or 3 though option 2 is also
21851 achievable using more wording. I personally oppose to option 2 that has impact
21852 on usability.</p>
21853
21854 <p>
21855 <b>Relaxation for user types</b>
21856 </p>
21857
21858 <p>Disallowing throwing move constructors in general seems very restrictive
21859 since, for example, common implementation of move will be default construction
21860 + <tt>swap</tt> so move will throw if the
21861 default constructor will throw. This is currently the case with the Dinkumware
21862 implementation of node based containers (e.g. <tt>std::list</tt>)
21863 though this section doesn't refer to standard types.</p>
21864
21865 <p>For throwing move constructors it seem that the implementation should have
21866 no problems to provide the basic guarantee instead of the strong one. It's
21867 better to allow throwing move constructors with basic guarantee than to
21868 disallow it silently (compile and run), via undefined behavior.</p>
21869
21870 <p>There might still be cases in which the relaxation will break existing generic
21871 code that assumes the strong guarantee but it's broken either way given a
21872 throwing move constructor since this is not a preserving optimization. </p>
21873
21874 <p><i>[
21875 Batavia (2009-05):
21876 ]</i></p>
21877
21878 <blockquote>
21879 <p>
21880 Bjarne comments (referring to his draft paper):
21881 "I believe that my suggestion simply solves that.
21882 Thus, we don't need a throwing move."
21883 </p>
21884 <p>
21885 Move to Open and recommend it be deferred until after the next
21886 Committee Draft is issued.
21887 </p>
21888 </blockquote>
21889
21890
21891 <p><b>Proposed resolution:</b></p>
21892
21893 <p>
21894 23.2.1 [container.requirements.general]  paragraph 10 add footnote:
21895 </p>
21896
21897 <blockquote>
21898 <p>
21899 -10- Unless otherwise specified (see 23.1.4.1, 23.1.5.1, 23.2.2.3, and
21900 23.2.6.4) all container types defined in this Clause meet the following
21901 additional requirements:
21902 </p>
21903 <ul>
21904 <li>...</li>
21905 </ul>
21906
21907 <p>
21908 <ins>[<i>Note</i>: for compatibility with C++
21909 2003, when "no effect" is required, standard containers should not use the
21910 value_type's throwing move constructor when the contained object is by itself a
21911 standard container. -- <i>end note</i>]</ins>
21912 </p>
21913
21914 </blockquote>
21915
21916 <p>23.2.5.1 [unord.req.except] change paragraph 2 to say: </p>
21917
21918 <blockquote>
21919 <p>
21920 -2- For unordered associative containers, if an exception is
21921 thrown by any operation other than the container's hash function from within an
21922 <tt>insert()</tt> function inserting a single element, the <tt>insert()</tt>
21923 function has no effect<ins> unless the exception is thrown by the contained
21924 object move constructor</ins>.
21925 </p>
21926
21927 <p>
21928 -4- For unordered associative containers, if an exception is
21929 thrown from within a <tt>rehash()</tt> function other than by the container's hash
21930 function or comparison function, the <tt>rehash()</tt> function has no effect
21931 <ins>unless the exception is thrown by the contained
21932 object move constructor</ins>.</p>
21933
21934 </blockquote>
21935
21936 <p>
21937 23.3.2.3 [deque.modifiers] change paragraph 2 to say:
21938 </p>
21939
21940 <blockquote>
21941 -2- <i>Remarks:</i> If an exception is thrown other than by
21942 the copy constructor<ins>, move constructor</ins>
21943 or assignment operator of <tt>T</tt>
21944 there are no effects.
21945 <ins>If an exception is thrown by <tt>push_back()</tt> or <tt>emplace_back()</tt>
21946 function, that function has no effects unless the exception is thrown by
21947 the move constructor of <tt>T</tt>.</ins>
21948 </blockquote>
21949
21950 <p>
21951 23.3.2.3 [deque.modifiers] change paragraph 6 to say:
21952 </p>
21953
21954 <blockquote>
21955 -6- <i>Throws:</i> Nothing unless an exception is thrown by the copy
21956 constructor<ins>, move constructor</ins> or assignment operator of <tt>T</tt>.
21957 </blockquote>
21958
21959 <p>
21960 23.3.6.2 [vector.capacity] remove paragraph 2
21961 </p>
21962
21963 <blockquote>
21964 <del>-2- <i>Requires:</i> If <tt>value_type</tt> has a move constructor,
21965 that constructor shall not throw any exceptions.</del>
21966 </blockquote>
21967
21968 <p>
21969 23.3.6.2 [vector.capacity] paragraph 3 change to say:
21970 </p>
21971
21972 <blockquote>
21973 -3- <i>Effects:</i> A directive that informs a <tt>vector</tt>
21974 of a planned change in size, so
21975 that it can manage the storage allocation accordingly. After <tt>reserve()</tt>,
21976 <tt>capacity()</tt> is greater or equal to the argument of <tt>reserve</tt>
21977 if reallocation happens; and equal
21978 to the previous value of <tt>capacity()</tt>
21979 otherwise. Reallocation happens at this point if and only if the current
21980 capacity is less than the argument of <tt>reserve()</tt>.
21981 If an exception is thrown, there are no effects<ins>
21982 unless the exception is thrown by the contained object move constructor</ins>.
21983 </blockquote>
21984
21985 <p>
21986 23.3.6.2 [vector.capacity] paragraph 12 change to say:
21987 </p>
21988
21989 <blockquote>
21990 -12- <i>Requires:</i> <del>If <tt>value_type</tt> has a move constructor,
21991 that constructor shall not throw any exceptions.</del>
21992 <ins>If an exception is thrown, there are no effects unless the exception is thrown by
21993 the contained object move constructor.</ins>
21994 </blockquote>
21995
21996 <p>
21997 23.3.6.4 [vector.modifiers] change paragraph 1 to say:
21998 </p>
21999
22000 <blockquote>
22001 -1- <del><i>Requires:</i> If <tt>value_type</tt> has a move constructor,
22002 that constructor shall not throw any exceptions.</del>
22003 <ins><i>Remarks:</i> If an exception is thrown by <tt>push_back()</tt>
22004 or <tt>emplace_back()</tt> function, that function has no effect unless the
22005 exception is thrown by the move constructor of <tt>T</tt>.</ins>
22006 </blockquote>
22007
22008 <p>
22009 23.3.6.4 [vector.modifiers] change paragraph 2 to say:
22010 </p>
22011
22012 <blockquote>
22013 -2- <i>Remarks:</i> Causes reallocation if the new size is greater than
22014 the old capacity. If no reallocation happens, all the iterators and
22015 references before the insertion point remain valid. If an exception is
22016 thrown other than by the copy constructor<ins>, move constructor</ins>
22017 or assignment operator of <tt>T</tt> or by any <tt>InputIterator</tt>
22018 operation there are no effects.
22019 </blockquote>
22020
22021 <p>
22022 23.3.6.4 [vector.modifiers] change paragraph 6 to say:
22023 </p>
22024
22025 <blockquote>
22026 -6- <i>Throws:</i> Nothing unless an exception is thrown by the copy
22027 constructor<ins>, move constructor</ins> or assignment operator of <tt>T</tt>.
22028 </blockquote>
22029
22030
22031
22032
22033
22034
22035 <hr>
22036 <h3><a name="987"></a>987. <tt>reference_wrapper</tt> and function types</h3>
22037 <p><b>Section:</b> 20.7.5 [refwrap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
22038  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-18  <b>Last modified:</b> 2009-07-14</p>
22039 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#refwrap">issues</a> in [refwrap].</p>
22040 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
22041 <p><b>Discussion:</b></p>
22042 <p>
22043 The synopsis in 20.7.5 [refwrap] says:
22044 </p>
22045
22046 <blockquote><pre>template &lt;<b>ObjectType</b> T&gt; class reference_wrapper
22047 ...
22048 </pre></blockquote>
22049
22050 <p>
22051 And then paragraph 3 says:
22052 </p>
22053
22054 <blockquote>
22055 <p>
22056 The template instantiation <tt>reference_wrapper&lt;T&gt;</tt> shall be
22057 derived from <tt>std::unary_function&lt;T1, R&gt;</tt> only if the type
22058 <tt>T</tt> is any of the following:
22059 </p>
22060
22061 <ul>
22062 <li>
22063 a <b>function type</b> or a pointer to function type taking one argument of
22064 type <tt>T1</tt> and returning <tt>R</tt>
22065 </li>
22066 </ul>
22067 </blockquote>
22068
22069 <p>
22070 But function types are not <tt>ObjectType</tt>s.
22071 </p>
22072
22073 <p>
22074 Paragraph 4 contains the same contradiction.
22075 </p>
22076
22077 <p><i>[
22078 Post Summit:
22079 ]</i></p>
22080
22081
22082 <blockquote>
22083 <p>
22084 Jens: restricted reference to ObjectType
22085 </p>
22086 <p>
22087 Recommend Review.
22088 </p>
22089 </blockquote>
22090
22091 <p><i>[
22092 Post Summit, Peter adds:
22093 ]</i></p>
22094
22095
22096 <blockquote>
22097 <p>
22098 In <a href="https://svn.boost.org/trac/boost/ticket/1846">https://svn.boost.org/trac/boost/ticket/1846</a>
22099 however Eric Niebler makes the very reasonable point that <tt>reference_wrapper&lt;F&gt;</tt>,
22100 where <tt>F</tt> is a function type, represents a reference to a function,
22101 a legitimate entity. So <tt>boost::ref</tt> was changed to allow it.
22102 </p>
22103 <p>
22104 <a href="https://svn.boost.org/trac/boost/browser/trunk/libs/bind/test/ref_fn_test.cpp">https://svn.boost.org/trac/boost/browser/trunk/libs/bind/test/ref_fn_test.cpp</a>
22105 </p>
22106 <p>
22107 Therefore, I believe an alternative proposed resolution for issue 987 could simply
22108 allow <tt>reference_wrapper</tt> to be used with function types.
22109 </p>
22110 </blockquote>
22111
22112 <p><i>[
22113 Post Summit, Howard adds:
22114 ]</i></p>
22115
22116
22117 <blockquote>
22118 <p>
22119 I agree with Peter (and Eric).  I got this one wrong on my first try.  Here
22120 is code that demonstrates how easy (and useful) it is to instantiate
22121 <tt>reference_wrapper</tt> with a function type:
22122 </p>
22123
22124 <blockquote><pre>#include &lt;functional&gt;
22125
22126 template &lt;class F&gt;
22127 void test(F f);
22128
22129 void f() {}
22130
22131 int main()
22132 {
22133     test(std::ref(f));
22134 }
22135 </pre></blockquote>
22136
22137 <p>
22138 Output (link time error shows type of <tt>reference_wrapper</tt> instantiated
22139 with function type):
22140 </p>
22141
22142 <blockquote><pre>Undefined symbols:
22143   "void test&lt;std::reference_wrapper&lt;void ()()&gt; &gt;(std::reference_wrapper&lt;void ()()&gt;)",...
22144 </pre></blockquote>
22145
22146 <p>
22147 I've taken the liberty of changing the proposed wording to allow function types
22148 and set to Open.  I'll also freely admit that I'm not positive <tt>ReferentType</tt>
22149 is the correct concept.
22150 </p>
22151
22152 </blockquote>
22153
22154
22155
22156 <p><i>[
22157 Batavia (2009-05):
22158 ]</i></p>
22159
22160 <blockquote>
22161 <p>
22162 Howard observed that <tt>FunctionType</tt>,
22163 a concept not (yet?) in the Working Paper,
22164 is likely the correct constraint to be applied.
22165 However, the proposed resolution provides an adequate approximation.
22166 </p>
22167 <p>
22168 Move to Review.
22169 </p>
22170 </blockquote>
22171
22172 <p><i>[
22173 2009-05-23 Alisdair adds:
22174 ]</i></p>
22175
22176
22177 <blockquote>
22178 <p>
22179 By constraining to <tt>PointeeType</tt> we rule out the ability for <tt>T</tt> to be a
22180 reference, and call in reference-collapsing.  I'm not sure if this is
22181 correct and intended, but would like to be sure the case was considered.
22182 </p>
22183 <p>
22184 Is dis-allowing reference types and the
22185 implied reference collapsing the intended result?
22186 </p>
22187 </blockquote>
22188
22189 <p><i>[
22190 2009-07 Frankfurt
22191 ]</i></p>
22192
22193
22194 <blockquote>
22195 Moved from Review to Open only because the wording needs to be
22196 tweaked for concepts removal.
22197 </blockquote>
22198
22199
22200
22201 <p><b>Proposed resolution:</b></p>
22202 <p>
22203 Change the synopsis in 20.7 [function.objects]:
22204 </p>
22205
22206 <blockquote><pre>// 20.6.5, reference_wrapper:
22207 template &lt;<del>ObjectType</del> <ins>ReferentType</ins> T&gt;
22208   <ins>requires PointeeType&lt;T&gt;</ins>
22209   class reference_wrapper;
22210
22211 template &lt;<del>ObjectType</del> <ins>PointeeType</ins> T&gt;
22212   reference_wrapper&lt;T&gt; ref(T&amp;);
22213
22214 template &lt;<del>ObjectType</del> <ins>PointeeType</ins> T&gt;
22215   reference_wrapper&lt;const T&gt; cref(const T&amp;);
22216
22217 template &lt;<del>ObjectType</del> <ins>PointeeType</ins> T&gt;
22218   reference_wrapper&lt;T&gt; ref(reference_wrapper&lt;T&gt;);
22219 template &lt;<del>ObjectType</del> <ins>PointeeType</ins> T&gt;
22220   reference_wrapper&lt;const T&gt; cref(reference_wrapper&lt;T&gt;);
22221 </pre></blockquote>
22222
22223 <p>
22224 Change the synopsis in 20.7.5 [refwrap]:
22225 </p>
22226
22227 <blockquote><pre>template &lt;<del>ObjectType</del> <ins>ReferentType</ins> T&gt;
22228   <ins>requires PointeeType&lt;T&gt;</ins>
22229   class reference_wrapper
22230    ...
22231 </pre></blockquote>
22232
22233 <p>
22234 Change the prototypes in 20.7.5.5 [refwrap.helpers]:
22235 </p>
22236
22237 <blockquote><pre>template &lt;<del>ObjectType</del> <ins>PointeeType</ins> T&gt;
22238   reference_wrapper&lt;T&gt; ref(T&amp;);
22239 ...
22240 template &lt;<del>ObjectType</del> <ins>PointeeType</ins> T&gt;
22241   reference_wrapper&lt;const T&gt; cref(const T&amp;);
22242 ...
22243 template &lt;<del>ObjectType</del> <ins>PointeeType</ins> T&gt;
22244   reference_wrapper&lt;T&gt; ref(reference_wrapper&lt;T&gt;);
22245 ...
22246 template &lt;<del>ObjectType</del> <ins>PointeeType</ins> T&gt;
22247   reference_wrapper&lt;const T&gt; cref(reference_wrapper&lt;T&gt;);
22248 </pre></blockquote>
22249
22250
22251
22252 <p><b>Rationale:</b></p>
22253 <p>
22254 a) The occurrence of <tt>T&amp;</tt> in the function signature auto-implies
22255 <tt>std::ReferentType</tt>,
22256 this is due to 14.11.1.2 [temp.req.impl]/4 bullet 4
22257 </p>
22258 <p>
22259 b) The occurrence of the constrained template <tt>reference_wrapper&lt;T&gt;</tt> in
22260 the remaining
22261 signatures lets kick in 14.11.1.2 [temp.req.impl]/4 bullet 1 and adds *all* requirements of
22262 this template. But we need to add at least *one* requirement (and it
22263 was an arbitrary,
22264 but natural decision to require <tt>std::PointeeType</tt> here) to *activate*
22265 this. If we hadn't done
22266 this, we were in unconstrained mode!
22267 </p>
22268
22269
22270
22271
22272
22273 <hr>
22274 <h3><a name="996"></a>996. Move operation not well specified</h3>
22275 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
22276  <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-03-06  <b>Last modified:</b> 2009-05-23</p>
22277 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
22278 <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>
22279 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
22280 <p><b>Discussion:</b></p>
22281 <p>
22282 There are lots of places in the standard where we talk about "the move
22283 constructor" but where we mean "the move operation," i.e.  <tt>T( move( x ) )</tt>.
22284 </p>
22285 <p>
22286 We also don't account for whether that operation modifies <tt>x</tt> or not, and
22287 we need to.
22288 </p>
22289
22290 <p><i>[
22291 Batavia (2009-05):
22292 ]</i></p>
22293
22294 <blockquote>
22295 Move to Open, pending proposed wording from Dave for further
22296 review.
22297 </blockquote>
22298
22299
22300 <p><b>Proposed resolution:</b></p>
22301 <p>
22302 </p>
22303
22304
22305
22306
22307
22308 <hr>
22309 <h3><a name="999"></a>999. Taking the address of a function</h3>
22310 <p><b>Section:</b> 20.8.8.1 [object.addressof] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
22311  <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2009-03-09  <b>Last modified:</b> 2009-07-14</p>
22312 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#object.addressof">issues</a> in [object.addressof].</p>
22313 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
22314 <p><b>Discussion:</b></p>
22315 <p>
22316 The same fix (reference <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#987">987</a>) may be applied to <tt>addressof</tt>, which is also constrained to
22317 <tt>ObjectType</tt>. (That was why <tt>boost::ref</tt> didn't work with functions - it
22318 tried to apply <tt>boost::addressof</tt> and the <tt>reinterpret_cast&lt;char&amp;&gt;</tt>
22319 implementation of <tt>addressof</tt> failed.)
22320 </p>
22321
22322
22323
22324 <p><i>[
22325 Batavia (2009-05):
22326 ]</i></p>
22327
22328 <blockquote>
22329 <p>
22330 We agree.
22331 </p>
22332 <p>
22333 Move to Tentatively Ready.
22334 </p>
22335 </blockquote>
22336
22337 <p><i>[
22338 2009-07 Frankfurt
22339 ]</i></p>
22340
22341
22342 <blockquote>
22343 Moved from Tentatively Ready to Open only because the wording needs to be
22344 tweaked for concepts removal.
22345 </blockquote>
22346
22347
22348
22349 <p><b>Proposed resolution:</b></p>
22350 <p>
22351 Change the synopsis in 20.8 [memory]:
22352 </p>
22353
22354 <blockquote><pre>template &lt;<del>ObjectType</del> <ins>PointeeType</ins> T&gt;
22355   T* addressof(T&amp; r);
22356 </pre></blockquote>
22357
22358 <p>
22359 Change 20.8.8.1 [object.addressof]:
22360 </p>
22361
22362 <blockquote><pre>template &lt;<del>ObjectType</del> <ins>PointeeType</ins> T&gt;
22363   T* addressof(T&amp; r);
22364 </pre></blockquote>
22365
22366
22367 <p><b>Rationale:</b></p>
22368 <p>
22369 a) The occurrence of <tt>T&amp;</tt> in the function signature auto-implies
22370 <tt>std::ReferentType</tt>,
22371 this is due to 14.11.1.2 [temp.req.impl]/4 bullet 4
22372 </p>
22373
22374
22375
22376
22377
22378 <hr>
22379 <h3><a name="1004"></a>1004. Response to UK 179</h3>
22380 <p><b>Section:</b> 17.6.3.8 [res.on.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
22381  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-18</p>
22382 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.functions">issues</a> in [res.on.functions].</p>
22383 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
22384 <p><b>Discussion:</b></p>
22385
22386 <p><b>Addresses UK 179</b></p>
22387
22388 <p>
22389 According to the 4th bullet there is a problem if "if any replacement
22390 function or handler function or destructor operation throws an
22391 exception". There should be no problem throwing exceptions so long as
22392 they are caught within the function.
22393 </p>
22394
22395 <p><i>[
22396 Batavia (2009-05):
22397 ]</i></p>
22398
22399 <blockquote>
22400 The phrasing "throws an exception" is commonly used elsewhere
22401 to mean "throws or propagates an exception."
22402 Move to Open pending a possible more general resolution.
22403 </blockquote>
22404
22405 <p><i>[
22406 2009-07 Frankfurt:
22407 ]</i></p>
22408
22409
22410 <blockquote>
22411 Replace "propagates" in the proposed resolution with the phrase "exits
22412 via" and move to Ready.
22413 </blockquote>
22414
22415
22416
22417 <p><b>Proposed resolution:</b></p>
22418 <p>
22419 Change the 4th bullet of 17.6.3.8 [res.on.functions], p2:
22420 </p>
22421
22422 <blockquote>
22423 <ul>
22424 <li>
22425 if any replacement function or handler function or destructor operation
22426 <del>throws</del> <ins>exits via</ins> an exception, unless specifically
22427 allowed in the applicable <i>Required behavior:</i> paragraph.
22428 </li>
22429 </ul>
22430 </blockquote>
22431
22432
22433
22434
22435
22436
22437 <hr>
22438 <h3><a name="1008"></a>1008. <tt>nested_exception</tt> wording unclear</h3>
22439 <p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
22440  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-04</p>
22441 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p>
22442 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p>
22443 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
22444 <p><b>Discussion:</b></p>
22445
22446 <p><b>Addresses JP 31</b></p>
22447
22448 <p>
22449 It is difficult to understand in which case <tt>nested_exception</tt> is applied.
22450 </p>
22451
22452 <p><i>[
22453 Summit:
22454 ]</i></p>
22455
22456
22457 <blockquote>
22458 Alisdair will add an example in an update to
22459 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2619.pdf">N2619</a>.
22460 </blockquote>
22461
22462
22463
22464 <p><b>Proposed resolution:</b></p>
22465
22466
22467
22468
22469
22470 <hr>
22471 <h3><a name="1009"></a>1009. <tt>InputIterator</tt> post-increment dangerous</h3>
22472 <p><b>Section:</b> 24.2.1 [iterator.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
22473  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-28</p>
22474 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
22475 <p><b>Discussion:</b></p>
22476
22477 <p><b>Addresses UK 251</b></p>
22478
22479 <p>
22480 The post-increment operator is dangerous for a general InputIterator.
22481 The multi-pass guarantees that make it meaningful are defined as part of
22482 the ForwardIterator refinement. Any change will affect only constrained
22483 templates that have not yet been written, so should not break existing
22484 user iterators which remain free to add these operations. This change
22485 will also affect the generalised OutputIterator, although there is no
22486 percieved need for the post-increment operator in this case either.
22487 </p>
22488
22489 <p><i>[
22490 2009-07-28 Alisdair adds:
22491 ]</i></p>
22492
22493
22494 <blockquote>
22495 We still think the issue is relevant, but needs totally rewording in
22496 non-concept language.  We would like to see the issue retained as Open,
22497 rather than deferred as NAD Concepts.  Review status is no longer
22498 appropriate.
22499 </blockquote>
22500
22501
22502
22503 <p><b>Proposed resolution:</b></p>
22504 <p>
22505 Change 24.2.1 [iterator.iterators]:
22506 </p>
22507
22508 <blockquote><pre>concept Iterator&lt;typename X&gt; : Semiregular&lt;X&gt; {
22509   MoveConstructible reference = typename X::reference;
22510   <del>MoveConstructible postincrement_result;</del>
22511
22512   <del>requires HasDereference&lt;postincrement_result&gt;;</del>
22513
22514   reference operator*(X&amp;&amp;);
22515   X&amp; operator++(X&amp;);
22516   <del>postincrement_result operator++(X&amp;, int);</del>
22517 }
22518 </pre>
22519
22520 <p>...</p>
22521 <pre><del>postincrement_result operator++(X&amp; r, int);</del>
22522 </pre>
22523
22524 <blockquote>
22525 <del>-3- <i>Effects:</i> equivalent to <tt>{ X tmp = r; ++r; return tmp; }</tt>.</del>
22526 </blockquote>
22527
22528 </blockquote>
22529
22530 <p>
22531 Change 24.2.2 [input.iterators]:
22532 </p>
22533
22534 <blockquote>
22535 <pre>concept InputIterator&lt;typename X&gt; : Iterator&lt;X&gt;, EqualityComparable&lt;X&gt; {
22536   ObjectType value_type = typename X::value_type;
22537   MoveConstructible pointer = typename X::pointer;
22538
22539   SignedIntegralLike difference_type = typename X::difference_type;
22540
22541   requires IntegralType&lt;difference_type&gt;
22542         &amp;&amp; Convertible&lt;reference, const value_type &amp;&gt;;
22543         &amp;&amp; Convertible&lt;pointer, const value_type*&gt;;
22544
22545   <del>requires Convertible&lt;HasDereference&lt;postincrement_result&gt;::result_type, const value_type&amp;&gt;;</del>
22546
22547   pointer operator-&gt;(const X&amp;);
22548 }
22549 </pre>
22550 </blockquote>
22551
22552 <p>
22553 Change 24.2.3 [output.iterators]:
22554 </p>
22555
22556 <blockquote>
22557 <pre>auto concept OutputIterator&lt;typename X, typename Value&gt; {
22558   requires Iterator&lt;X&gt;;
22559
22560   typename reference = Iterator&lt;X&gt;::reference;
22561   <del>typename postincrement_result = Iterator&lt;X&gt;::postincrement_result;</del>
22562   requires SameType&lt;reference, Iterator&lt;X&gt;::reference&gt;
22563         <del>&amp;&amp; SameType&lt;postincrement_result, Iterator&lt;X&gt;::postincrement_result&gt;</del>
22564         <del>&amp;&amp; Convertible&lt;postincrement_result, const X&amp;&gt;</del>
22565         &amp;&amp; HasAssign&lt;reference, Value&gt;
22566         <del>&amp;&amp; HasAssign&lt;HasDereference&lt;postincrement_result&gt;::result_type, Value&gt;</del>;
22567 }
22568 </pre>
22569 </blockquote>
22570
22571 <p>
22572 Change 24.2.4 [forward.iterators]:
22573 </p>
22574
22575 <p><i>[
22576 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1084">1084</a> which is attempting to change this same area in a compatible
22577 way.
22578 ]</i></p>
22579
22580
22581 <blockquote>
22582 <pre>concept ForwardIterator&lt;typename X&gt; : InputIterator&lt;X&gt;, Regular&lt;X&gt; {
22583   <del>requires Convertible&lt;postincrement_result, const X&amp;&gt;;</del>
22584
22585   <ins>MoveConstructible postincrement_result;</ins>
22586   <ins>requires HasDereference&lt;postincrement_result&gt;
22587         &amp;&amp; Convertible&lt;HasDereference&lt;postincrement_result&gt;::result_type, const value_type&amp;&gt;;</ins>
22588
22589   <ins>postincrement_result operator++(X&amp;, int);</ins>
22590
22591   axiom MultiPass(X a, X b) {
22592     if (a == b) *a == *b;
22593     if (a == b) ++a == ++b;
22594   }
22595 }
22596 </pre>
22597
22598 <blockquote>
22599 <p>-4- ...</p>
22600 </blockquote>
22601
22602 <pre><ins>postincrement_result operator++(X&amp; r, int);</ins>
22603 </pre>
22604
22605 <blockquote>
22606 <p>
22607 <ins>-5- <i>Effects:</i> equivalent to <tt>{ X tmp = r; ++r; return tmp; }</tt>.</ins>
22608 </p>
22609 </blockquote>
22610
22611 </blockquote>
22612
22613
22614
22615
22616
22617
22618 <hr>
22619 <h3><a name="1011"></a>1011. <tt>next/prev</tt> wrong iterator type</h3>
22620 <p><b>Section:</b> 24.4 [iterator.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
22621  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-14</p>
22622 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.operations">active issues</a> in [iterator.operations].</p>
22623 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.operations">issues</a> in [iterator.operations].</p>
22624 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
22625 <p><b>Discussion:</b></p>
22626
22627 <p><b>Addresses UK 271</b></p>
22628
22629 <p>
22630 <tt>next/prev</tt> return an incremented iterator without changing the value of
22631 the original iterator. However, even this may invalidate an
22632 <tt>InputIterator</tt>. A <tt>ForwardIterator</tt> is required to guarantee the
22633 'multipass' property.
22634 </p>
22635
22636 <p><i>[
22637 Batavia (2009-05):
22638 ]</i></p>
22639
22640 <blockquote>
22641 We agree with the proposed resolution.
22642 Move to Tentatively Ready.
22643 </blockquote>
22644
22645 <p><i>[
22646 2009-07 Frankfurt
22647 ]</i></p>
22648
22649
22650 <blockquote>
22651 Moved from Tentatively Ready to Open only because the wording needs to be
22652 tweaked for concepts removal.
22653 </blockquote>
22654
22655
22656
22657 <p><b>Proposed resolution:</b></p>
22658 <p>
22659 Change  [iterator.synopsis]:
22660 </p>
22661
22662 <blockquote><pre>template &lt;<del>InputIterator</del> <ins>ForwardIterator</ins> Iter&gt;
22663   Iter next(Iter x,
22664     Iter::difference_type n = 1);
22665 </pre></blockquote>
22666
22667 <p>
22668 Change 24.4 [iterator.operations], p6:
22669 </p>
22670
22671 <blockquote><pre>template &lt;<del>InputIterator</del> <ins>ForwardIterator</ins> Iter&gt;
22672   Iter next(Iter x,
22673     Iter::difference_type n = 1);
22674 </pre></blockquote>
22675
22676
22677
22678
22679
22680
22681 <hr>
22682 <h3><a name="1012"></a>1012. <tt>reverse_iterator</tt> default ctor should value initialize</h3>
22683 <p><b>Section:</b> 24.5.1.2.1 [reverse.iter.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
22684  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-18</p>
22685 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
22686 <p><b>Discussion:</b></p>
22687
22688 <p><b>Addresses UK 277</b></p>
22689
22690 <p>
22691 The default constructor default-initializes current, rather than
22692 value-initializes. This means that when Iterator corresponds to a
22693 trivial type, the current member is left un-initialized, even when the
22694 user explictly requests value intialization! At this point, it is not
22695 safe to perform any operations on the reverse_iterator other than assign
22696 it a new value or destroy it. Note that this does correspond to the
22697 basic definition of a singular iterator.
22698 </p>
22699
22700 <p><i>[
22701 Summit:
22702 ]</i></p>
22703
22704
22705 <blockquote>
22706 Agree with option i.
22707 </blockquote>
22708
22709 <p>
22710 Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#408">408</a>
22711 </p>
22712
22713 <p><i>[
22714 Batavia (2009-05):
22715 ]</i></p>
22716
22717 <blockquote>
22718 We believe this should be revisited
22719 in conjunction with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#408">408</a>,
22720 which nearly duplicates this issue.
22721 Move to Open.
22722 </blockquote>
22723
22724 <p><i>[
22725 2009-07 post-Frankfurt:
22726 ]</i></p>
22727
22728
22729 <blockquote>
22730 <p>
22731 Change "constructed" to "initialized" in two places in the proposed resolution.
22732 </p>
22733 <p>
22734 Move to Tentatively Ready.
22735 </p>
22736 </blockquote>
22737
22738
22739
22740 <p><b>Proposed resolution:</b></p>
22741 <p>
22742 Change  [reverse.iter.con]:
22743 </p>
22744
22745 <blockquote><pre>reverse_iterator();
22746 </pre>
22747 <blockquote>
22748 -1- <i>Effects:</i> <del>Default</del> <ins>Value</ins> initializes <tt>current</tt>. Iterator
22749 operations applied to the resulting iterator have defined behavior if and
22750 only if the corresponding operations are defined on a <del>default constructed</del>
22751 <ins>value initialized</ins>
22752 iterator of type <tt>Iterator</tt>.
22753 </blockquote>
22754 </blockquote>
22755
22756 <p>
22757 Change 24.5.2.2.1 [move.iter.op.const]:
22758 </p>
22759
22760 <blockquote><pre>move_iterator();
22761 </pre>
22762 <blockquote>
22763 -1- <i>Effects:</i> Constructs a <tt>move_iterator</tt>, <del>default</del> <ins>value</ins>
22764 initializing <tt>current</tt>.
22765 <ins>Iterator
22766 operations applied to the resulting iterator have defined behavior if and
22767 only if the corresponding operations are defined on a
22768 value initialized
22769 iterator of type <tt>Iterator</tt>.</ins>
22770 </blockquote>
22771 </blockquote>
22772
22773
22774
22775
22776
22777
22778 <hr>
22779 <h3><a name="1019"></a>1019. Response to UK 205</h3>
22780 <p><b>Section:</b> 20.6.3 [meta.help] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Tentatively Ready</a>
22781  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-18</p>
22782 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.help">issues</a> in [meta.help].</p>
22783 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20Ready">Tentatively Ready</a> status.</p>
22784 <p><b>Discussion:</b></p>
22785
22786 <p><b>Addresses UK 205</b></p>
22787
22788 <p>
22789 <tt>integral_constant</tt> objects should be usable in integral-constant-expressions.
22790 The addition to the language of literal types and the enhanced rules for
22791 constant expressions make this possible.
22792 </p>
22793
22794 <p><i>[
22795 Batavia (2009-05):
22796 ]</i></p>
22797
22798 <blockquote>
22799 We agree that the <tt>static</tt> data member
22800 ought be declared <tt>constexpr</tt>,
22801 but do not see a need for the proposed <tt>operator value_type()</tt>.
22802 (A use case would be helpful.)
22803 Move to Open.
22804 </blockquote>
22805
22806 <p><i>[
22807 2009-05-23 Alisdair adds:
22808 ]</i></p>
22809
22810
22811 <blockquote>
22812 <p>
22813 The motivating case in my mind is that we can then use
22814 <tt>true_type</tt> and <tt>false_type</tt> as integral Boolean expressions, for example inside
22815 a <tt>static_assert</tt> declaration.  In that sense it is purely a matter of style.
22816 </p>
22817 <p>
22818 Note that Boost has applied the non-explicit conversion operator for many
22819 years as it has valuable properties for extension into other metaprogramming
22820 libraries, such as MPL.  If additional rationale is desired I will poll the
22821 Boost lists for why this extension was originally applied.  I would argue
22822 that explicit conversion is more appropriate for 0x though.
22823 </p>
22824 </blockquote>
22825
22826 <p><i>[
22827 2009-07-04 Howard adds:
22828 ]</i></p>
22829
22830
22831 <blockquote>
22832 <p>
22833 Here's a use case which demonstrates the syntactic niceness which Alisdair describes:
22834 </p>
22835
22836 <blockquote><pre>#define requires(...) class = typename std::enable_if&lt;(__VA_ARGS__)&gt;::type
22837
22838 template &lt;class T, class U,
22839     requires(!is_lvalue_reference&lt;T&gt;() ||
22840               is_lvalue_reference&lt;T&gt;() &amp;&amp; is_lvalue_reference&lt;U&gt;()),
22841     requires(is_same&lt;typename base_type&lt;T&gt;::type,
22842                      typename base_type&lt;U&gt;::type&gt;)&gt;
22843 inline
22844 T&amp;&amp;
22845 forward(U&amp;&amp; t)
22846 {
22847     return static_cast&lt;T&amp;&amp;&gt;(t);
22848 }
22849 </pre></blockquote>
22850 </blockquote>
22851
22852 <p><i>[
22853 2009-07 post-Frankfurt:
22854 ]</i></p>
22855
22856
22857 <blockquote>
22858 Move to Tentatively Ready.
22859 </blockquote>
22860
22861
22862
22863 <p><b>Proposed resolution:</b></p>
22864 <p>
22865 Add to the <tt>integral_constant</tt> struct definition in 20.6.3 [meta.help]:
22866 </p>
22867
22868 <blockquote><pre>template &lt;class T, T v&gt;
22869 struct integral_constant {
22870   static const<ins>expr</ins> T value = v;
22871   typedef T value_type;
22872   typedef integral_constant&lt;T,v&gt; type;
22873   <ins>constexpr operator value_type() { return value; }</ins>
22874 };
22875 </pre></blockquote>
22876
22877
22878
22879
22880
22881 <hr>
22882 <h3><a name="1020"></a>1020. Response to UK 204</h3>
22883 <p><b>Section:</b> 20.6.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
22884  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-03-12</p>
22885 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.trans.other">active issues</a> in [meta.trans.other].</p>
22886 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
22887 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
22888 <p><b>Discussion:</b></p>
22889
22890 <p><b>Addresses UK 204</b></p>
22891
22892 <p>
22893 It is not possible to create a variant union based on a parameter pack
22894 expansion, e.g. to implement a classic discriminated union template.
22895 </p>
22896
22897 <p><b>Original proposed resolutuion:</b></p>
22898
22899 <p>
22900 Restore <tt>aligned_union</tt> template that was removed by LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#856">856</a>.
22901 </p>
22902
22903 <p><i>[
22904 Summit:
22905 ]</i></p>
22906
22907
22908 <blockquote>
22909 Agree. The need for <tt>aligned_union</tt> is compelling enough to reinstate.
22910 </blockquote>
22911
22912 <p><i>[
22913 Post Summit, Alisdair adds:
22914 ]</i></p>
22915
22916
22917 <blockquote>
22918 paper
22919 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2843.html">N2843</a>
22920 proposes an extension to the <tt>[[align]]</tt> attribute
22921 that further diminishes the need for this template.  Recommend NAD.
22922 </blockquote>
22923
22924
22925
22926 <p><b>Proposed resolution:</b></p>
22927
22928
22929
22930
22931
22932 <hr>
22933 <h3><a name="1030"></a>1030. Response to JP 44</h3>
22934 <p><b>Section:</b> 20.8.10.6 [util.smartptr.shared.atomic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
22935  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-18</p>
22936 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
22937 <p><b>Discussion:</b></p>
22938
22939 <p><b>Addresses JP 44</b></p>
22940
22941 <p>
22942 The 1st parameter <tt>p</tt> and 2nd parameter <tt>v</tt> is now
22943 <tt>shared_ptr&lt;T&gt;*</tt>.
22944 </p>
22945 <p>
22946 It should be <tt>shared_ptr&lt;T&gt;&amp;</tt>, or if these are
22947 <tt>shared_ptr&lt;T&gt;*</tt> then add the "<tt>p</tt> shall not be a
22948 null pointer" at the requires.
22949 </p>
22950
22951 <p><i>[
22952 Summit:
22953 ]</i></p>
22954
22955
22956 <blockquote>
22957 Agree. All of the functions need a requirement that <tt>p</tt> (or
22958 <tt>v</tt>) is a pointer to a valid object.
22959 </blockquote>
22960
22961 <p><i>[
22962 2009-07 post-Frankfurt:
22963 ]</i></p>
22964
22965
22966 <blockquote>
22967 <p>
22968 Lawrence explained that these signatures match the regular atomics. The
22969 regular atomics must not use references because these signatures are
22970 shared with C. The decision to pass shared_ptrs by pointer rather than
22971 by reference was deliberate and was motivated by the principle of least
22972 surprise.
22973 </p>
22974 <p>
22975 Lawrence to write wording that requires that the pointers not be null.
22976 </p>
22977 </blockquote>
22978
22979
22980
22981 <p><b>Proposed resolution:</b></p>
22982
22983
22984
22985
22986
22987 <hr>
22988 <h3><a name="1031"></a>1031. Response to US 78</h3>
22989 <p><b>Section:</b> 20.8.10.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">Tentatively NAD Future</a>
22990  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-26</p>
22991 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
22992 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
22993 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Future">Tentatively NAD Future</a> status.</p>
22994 <p><b>Discussion:</b></p>
22995
22996 <p><b>Addresses US 78</b></p>
22997
22998 <p>
22999 There is presently no way to convert directly from a <tt>shared_ptr</tt> to a
23000 <tt>unique_ptr</tt>. Add an interface that performs the conversion.
23001 </p>
23002
23003 <p><i>[
23004 Summit:
23005 ]</i></p>
23006
23007
23008 <blockquote>
23009 We look forward to a paper on this topic. We recommend no action until a
23010 paper is available. We believe that the shared pointer must use the default
23011 deleter for the conversion to succeed.
23012 </blockquote>
23013
23014 <p><i>[
23015 Peter Dimov adds:
23016 ]</i></p>
23017
23018
23019 <blockquote>
23020 This is basically a request for <tt>shared_ptr&lt;&gt;::release</tt> in
23021 disguise, with all the associated problems. Not a good idea.
23022 </blockquote>
23023
23024 <p><i>[
23025 2009-07 post-Frankfurt:
23026 ]</i></p>
23027
23028
23029 <blockquote>
23030 <p>
23031 The rationale for the omission of a release() member function from shared_ptr is given in:
23032 <a href="http://www.boost.org/doc/libs/1_39_0/libs/smart_ptr/shared_ptr.htm">http://www.boost.org/doc/libs/1_39_0/libs/smart_ptr/shared_ptr.htm</a>
23033 </p>
23034 <p>
23035 The implementation of such a member is non-trivial (and maybe
23036 impossible), because it would need to account for the deleter.
23037 </p>
23038 </blockquote>
23039
23040 <p><i>[
23041 2009-07-26 Howard sets to Tentatively NAD Future.
23042 ]</i></p>
23043
23044
23045 <blockquote>
23046 <p>
23047 I took an online poll and got 3 votes for NAD and 3 for NAD Future.  Personally
23048 I prefer NAD Future as this does refer to an extension that could conceivably be
23049 considered beyond C++0X.
23050 </p>
23051
23052 <p>
23053 However such an extension would need to solve a couple of problems:
23054 </p>
23055
23056 <ol>
23057 <li>What is the interface for such a conversion when the <tt>shared_ptr</tt> does
23058 not have unique ownership?  Throw an exception?  Create a null <tt>unique_ptr</tt>?
23059 Undefined behavior?
23060 </li>
23061
23062 <li>
23063 <p>
23064 How does one handle custom deleters given to the <tt>shared_ptr</tt> constructor?
23065 </p>
23066 <p>
23067 I do not believe it is possible to implement a general answer to this question.
23068 The <tt>shared_ptr</tt> deleter is a run time (or construction time) characteristic.
23069 The <tt>unique_ptr</tt> deleter is a compile time characteristic.  In general one
23070 can not know to what type of <tt>unqiue_ptr</tt> you are converting to.
23071 </p>
23072 <p>
23073 One answer is for the user of the conversion to specify the deleter type and perhaps
23074 throw an exception if the specification turns out to be incorrect.
23075 </p>
23076 <p>
23077 Another answer is for the conversion to only be valid when the underlying deleter
23078 is <tt>default_delete</tt>.  We would probalby need to specify that this is indeed the
23079 underlying deleter of a <tt>shared_ptr</tt> when a custom deleter is not given in
23080 the constructor.
23081 </p>
23082 </li>
23083 </ol>
23084
23085 <p>
23086 At any rate, there are non-trivial design issues which would need to be implemented
23087 and tested in the field for usability prior to standardization.
23088 </p>
23089 </blockquote>
23090
23091
23092
23093 <p><b>Proposed resolution:</b></p>
23094
23095
23096
23097
23098
23099 <hr>
23100 <h3><a name="1033"></a>1033. <tt>thread::join()</tt> effects?</h3>
23101 <p><b>Section:</b> 30.3.1.5 [thread.thread.member] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
23102  <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-05-23</p>
23103 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.member">active issues</a> in [thread.thread.member].</p>
23104 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.member">issues</a> in [thread.thread.member].</p>
23105 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
23106 <p><b>Discussion:</b></p>
23107
23108 <p>
23109 While looking at <tt>thread::join()</tt> I think I spotted a couple of
23110 possible defects in the specifications. I could not find a previous
23111 issue or NB comment about that, but I might have missed it.
23112 </p>
23113
23114 <p>
23115 The postconditions clause for <tt>thread::join()</tt> is:
23116 </p>
23117
23118 <blockquote>
23119 <i>Postconditions:</i> If <tt>join()</tt> throws an exception, the value
23120 returned by <tt>get_id()</tt> is unchanged. Otherwise, <tt>get_id() == id()</tt>.
23121 </blockquote>
23122
23123 <p>
23124 and the throws clause is:
23125 </p>
23126
23127 <blockquote>
23128 <i>Throws:</i> <tt>std::system_error</tt> when the postconditions cannot be achieved.
23129 </blockquote>
23130
23131 <p>
23132 Now... how could the postconditions <em>not</em> be achieved?
23133 It's just a matter of resetting the value of <tt>get_id()</tt> or leave it
23134 unchanged! I bet we can always do that. Moreover, it's a chicken-and-egg
23135 problem: in order to decide whether to throw or not I depend on the
23136 postconditions, but the postconditions are different in the two cases.
23137 </p>
23138
23139 <p>
23140 I believe the throws clause should be:
23141 </p>
23142
23143 <blockquote>
23144 <i>Throws:</i> <tt>std::system_error</tt> when the effects or postconditions
23145 cannot be achieved.
23146 </blockquote>
23147
23148 <p>
23149 as it is in <tt>detach()</tt>, or, even better, as the postcondition is
23150 trivially satisfiable and to remove the circular dependency:
23151 </p>
23152
23153
23154 <blockquote>
23155 <i>Throws:</i> <tt>std::system_error</tt> if the effects cannot be achieved.
23156 </blockquote>
23157
23158 <p>
23159 Problem is that... ehm... <tt>join()</tt> has no "Effects" clause. Is that intentional?
23160 </p>
23161
23162 <p><i>[
23163 See the thread starting at c++std-lib-23204 for more discussion.
23164 ]</i></p>
23165
23166
23167 <p><i>[
23168 Batavia (2009-05):
23169 ]</i></p>
23170
23171 <blockquote>
23172 <p>
23173 Pete believes there may be some more general language (in frontmatter)
23174 that can address this and related issues such as <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#962">962</a>.
23175 </p>
23176 <p>
23177 Move to Open.
23178 </p>
23179 </blockquote>
23180
23181
23182 <p><b>Proposed resolution:</b></p>
23183
23184
23185
23186
23187
23188 <hr>
23189 <h3><a name="1034"></a>1034. Response to UK 222</h3>
23190 <p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
23191  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-07-18</p>
23192 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
23193 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
23194 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
23195 <p><b>Discussion:</b></p>
23196
23197 <p><b>Addresses UK 222</b></p>
23198
23199 <p>
23200 It is not clear what purpose the Requirement tables serve in the
23201 Containers clause. Are they the definition of a library Container? Or
23202 simply a conventient shorthand to factor common semantics into a single
23203 place, simplifying the description of each subsequent container? This
23204 becomes an issue for 'containers' like <tt>array</tt>, which does not meet the
23205 default-construct-to-empty requirement, or <tt>forward_list</tt> which does not
23206 support the size operation. Are these components no longer containers?
23207 Does that mean the remaining requirements don't apply? Or are these
23208 contradictions that need fixing, despite being a clear design decision?
23209 </p>
23210
23211 <p>
23212 Recommend:
23213 </p>
23214
23215 <p>
23216 Clarify all the tables in 23.2 [container.requirements] are
23217 there as a convenience for documentation, rather than a strict set of
23218 requirements. Containers should be allowed to relax specific
23219 requirements if they call attention to them in their documentation. The
23220 introductory text for <tt>array</tt> should be expanded to mention a
23221 default constructed <tt>array</tt> is not empty, and
23222 <tt>forward_list</tt> introduction should mention it does not provide
23223 the required <tt>size</tt> operation as it cannot be implemented
23224 efficiently.
23225 </p>
23226
23227 <p><i>[
23228 Summit:
23229 ]</i></p>
23230
23231
23232 <blockquote>
23233 Agree in principle.
23234 </blockquote>
23235
23236 <p><i>[
23237 2009-07 post-Frankfurt:
23238 ]</i></p>
23239
23240
23241 <blockquote>
23242 We agree in principle, but we have a timetable. This group feels that
23243 the issue should be closed as NAD unless a proposed resolution is
23244 submitted prior to the March 2010 meeting.
23245 </blockquote>
23246
23247
23248
23249 <p><b>Proposed resolution:</b></p>
23250
23251
23252
23253
23254
23255 <hr>
23256 <h3><a name="1035"></a>1035. Response to UK 226</h3>
23257 <p><b>Section:</b> 23.2.1 [container.requirements.general] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
23258  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-08-01</p>
23259 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
23260 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
23261 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
23262 <p><b>Discussion:</b></p>
23263
23264 <p><b>Addresses UK 226</b></p>
23265
23266 <p>
23267 <tt>&lt;array&gt;</tt> must be added to this list. In particular it
23268 doesn't satisfy: - no <tt>swap()</tt> function invalidates any
23269 references, pointers, or iterators referring to the elements of the
23270 containers being swapped. and probably doesn't satisfy: - no
23271 <tt>swap()</tt> function throws an exception.
23272 </p>
23273 <p>
23274 If <tt>&lt;array&gt;</tt> remains a container, this will have to also
23275 reference <tt>array</tt>, which will then have to say which of these
23276 points it satisfies.
23277 </p>
23278
23279 <p><i>[
23280 Summit:
23281 ]</i></p>
23282
23283
23284 <blockquote>
23285 Agree. The proposed resolution is incomplete. Further work required.
23286 </blockquote>
23287
23288 <p><i>[
23289 2009-05-01 Daniel adds:
23290 ]</i></p>
23291
23292
23293 <blockquote>
23294 Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1099">1099</a> also suggests
23295 adding move constructor to this.
23296 </blockquote>
23297
23298 <p><i>[
23299 2009-07 post-Frankfurt:
23300 ]</i></p>
23301
23302
23303 <blockquote>
23304 Howard is to draft a note that explains what happens to references.
23305 </blockquote>
23306
23307
23308
23309 <p><i>[
23310 2009-08-01 Howard provided wording.
23311 ]</i></p>
23312
23313
23314 <p><b>Proposed resolution:</b></p>
23315 <p>
23316 Add a paragraph to 23.3.1.2 [array.special]:
23317 </p>
23318
23319 <blockquote><pre>template &lt;Swappable T, size_t N&gt; void swap(array&lt;T,N&gt;&amp; x, array&lt;T,N&gt;&amp; y);
23320 </pre>
23321 <blockquote>
23322 <p>
23323 <i>Effects:</i>
23324 </p>
23325 <blockquote><pre>swap_ranges(x.begin(), x.end(), y.begin());
23326 </pre></blockquote>
23327
23328 <p><ins>
23329 [<i>Note:</i>
23330 Outstanding iterators, references and pointers may be invalidated.
23331 &#8212; <i>end note</i>]
23332 </ins></p>
23333 </blockquote>
23334 </blockquote>
23335
23336
23337
23338
23339
23340 <hr>
23341 <h3><a name="1041"></a>1041. Response to UK 239</h3>
23342 <p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
23343  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-07-18</p>
23344 <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>
23345 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
23346 <p><b>Discussion:</b></p>
23347
23348 <p><b>Addresses UK 239</b></p>
23349
23350 <p>
23351 It is not possible to take a move-only key out of an unordered
23352 container, such as (<tt>multi</tt>)<tt>set</tt> or
23353 (<tt>multi</tt>)<tt>map</tt>, or the new unordered containers.
23354 </p>
23355
23356 <p>
23357 Add below <tt>a.erase(q)</tt>, <tt>a.extract(q)</tt>, with the following notation:
23358 </p>
23359 <p>
23360 <tt>a.extract(q)&gt;</tt>, Return type <tt>pair&lt;key, iterator&gt;</tt>
23361 Extracts the element pointed to by <tt>q</tt> and erases it from the
23362 <tt>set</tt>. Returns a <tt>pair</tt> containing the value pointed to by
23363 <tt>q</tt> and an <tt>iterator</tt> pointing to the element immediately
23364 following <tt>q</tt> prior to the element being erased. If no such
23365 element exists,returns <tt>a.end()</tt>.
23366 </p>
23367
23368 <p><i>[
23369 Summit:
23370 ]</i></p>
23371
23372
23373 <blockquote>
23374 We look forward to a paper on this topic. We recommend no action until a
23375 paper is available. The paper would need to address exception safety.
23376 </blockquote>
23377
23378 <p><i>[
23379 Post Summit Alisdair adds:
23380 ]</i></p>
23381
23382
23383 <blockquote>
23384 Would <tt>value_type</tt> be a better return type than <tt>key_type</tt>?
23385 </blockquote>
23386
23387 <p><i>[
23388 2009-07 post-Frankfurt:
23389 ]</i></p>
23390
23391
23392 <blockquote>
23393 Leave Open. Alisdair to contact Chris Jefferson about this.
23394 </blockquote>
23395
23396
23397
23398 <p><b>Proposed resolution:</b></p>
23399 <p>
23400 In 23.2.4 [associative.reqmts] Table 85, add:
23401 </p>
23402
23403 <blockquote>
23404 <table border="1">
23405 <caption>Table 85 --  Associative container requirements (in addition to container)</caption>
23406 <tbody><tr>
23407 <th>Expression</th>
23408 <th>Return type</th>
23409 <th>Assertion/note<br>pre-/post-condition</th>
23410 <th>Complexity</th>
23411 </tr>
23412 <tr><td><tt>a.erase(q)</tt></td>
23413 <td>...</td>
23414 <td>...</td>
23415 <td>...</td>
23416 </tr><tr>
23417 <td><ins><tt>a.extract(q)</tt></ins></td>
23418 <td><ins><tt>pair&lt;key_type, iterator&gt;</tt></ins></td>
23419 <td><ins>Extracts the element pointed to by <tt>q</tt> and erases it from the <tt>set</tt>.
23420 Returns a <tt>pair</tt> containing the value pointed to by <tt>q</tt> and an <tt>iterator</tt>
23421 pointing to the element immediately following <tt>q</tt> prior to the element being
23422 erased. If no such element
23423 exists, returns <tt>a.end()</tt>.</ins></td>
23424 <td><ins>amortized constant</ins></td>
23425 </tr>
23426 </tbody></table>
23427 </blockquote>
23428
23429 <p>
23430 In 23.2.5 [unord.req] Table 87, add:
23431 </p>
23432
23433 <blockquote>
23434 <table border="1">
23435 <caption>Table 87 -- Unordered associative container requirements (in addition to container)</caption>
23436 <tbody><tr>
23437 <th>Expression</th>
23438 <th>Return type</th>
23439 <th>Assertion/note<br>pre-/post-condition</th>
23440 <th>Complexity</th>
23441 </tr>
23442 <tr><td><tt>a.erase(q)</tt></td>
23443 <td>...</td>
23444 <td>...</td>
23445 <td>...</td>
23446 </tr><tr>
23447 <td><ins><tt>a.extract(q)</tt></ins></td>
23448 <td><ins><tt>pair&lt;key_type, iterator&gt;</tt></ins></td>
23449 <td><ins>Extracts the element pointed to by <tt>q</tt> and erases it from the <tt>set</tt>.
23450 Returns a <tt>pair</tt> containing the value pointed to by <tt>q</tt> and an <tt>iterator</tt>
23451 pointing to the element immediately following <tt>q</tt> prior to the element being
23452 erased. If no such element
23453 exists, returns <tt>a.end()</tt>.</ins></td>
23454 <td><ins>amortized constant</ins></td>
23455 </tr>
23456 </tbody></table>
23457 </blockquote>
23458
23459
23460
23461
23462
23463 <hr>
23464 <h3><a name="1042"></a>1042. Response to UK 244</h3>
23465 <p><b>Section:</b> 23.3 [sequences] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
23466  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-07-18</p>
23467 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequences">issues</a> in [sequences].</p>
23468 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
23469 <p><b>Discussion:</b></p>
23470
23471 <p><b>Addresses UK 244</b></p>
23472
23473 <p>
23474 The validity of the expression <tt>&amp;a[n] == &amp;a[0] + n</tt> is contingent on
23475 <tt>operator&amp;</tt> doing the "right thing" (as captured by the <tt>CopyConstructible</tt>
23476 requirements in table 30 in C++2003). However this constraint has been
23477 lost in the Concepts of C++0x. This applies to <tt>vector</tt> and <tt>array</tt> (it
23478 actually applies to <tt>string</tt> also, but that's a different chapter, so I'll
23479 file a separate comment there and cross-reference).
23480 </p>
23481
23482 <p>
23483 Suggested solution:
23484 </p>
23485
23486 <p>
23487 Define a <tt>ContiguousStrorage</tt> and apply it to
23488 <tt>vector</tt>, <tt>array</tt> and <tt>string</tt>.
23489 </p>
23490
23491 <p><i>[
23492 Summit:
23493 ]</i></p>
23494
23495
23496 <blockquote>
23497 Agree with the issue but not the details of the proposed solution. Walter to
23498 provide wording for the new concept.
23499 </blockquote>
23500
23501 <p><i>[
23502 Post Summit Alisdair adds:
23503 ]</i></p>
23504
23505
23506 <blockquote>
23507 Another LWG subgroup wondered if this concept
23508 should extend to <tt>complex&lt;T&gt;</tt>, and so not be built on the container concept at
23509 all?
23510 </blockquote>
23511
23512 <p><i>[
23513 2009-07 post-Frankfurt:
23514 ]</i></p>
23515
23516
23517 <blockquote>
23518 Leave Open, pending a post-Concepts Working Draft.
23519 </blockquote>
23520
23521
23522
23523 <p><b>Proposed resolution:</b></p>
23524 <p>
23525 Add to <tt>&lt;container_concepts&gt;</tt> synopsis in 23.2.6 [container.concepts]
23526 </p>
23527
23528 <blockquote><pre><ins>concept&lt; typename C &gt; ContiguousStorageContainer <i>see below</i>;</ins>
23529 </pre></blockquote>
23530
23531 <p>
23532 Add a new section to the end of 23.2.6 [container.concepts]
23533 </p>
23534
23535 <blockquote>
23536 <p>
23537 23.1.6.x ContiguousStorageContainer concept [container.concepts.contiguous]
23538 </p>
23539
23540 <pre>concept ContiguousStorageContainer&lt; typename C &gt;
23541   : Container&lt;C&gt;
23542 {
23543   value_type* data(C&amp;);
23544
23545   axiom Contiguity(C&amp; c, size_type i) {
23546     if( i &lt; size(c) ) {
23547          addressof( * (data(c) + i) )
23548       == addressof( * advance(data(c), i) );
23549     }
23550   }
23551 }
23552 </pre>
23553
23554 <p>
23555 The <tt>ContiguousStorageContainer</tt> concept describes a container whose elements
23556 are allocated in a single region of memory, and are stored sequentially
23557 without intervening padding other than to meet alignment requirements.
23558 For example, the elements may be stored in a
23559 single array of suitable length.
23560 </p>
23561
23562 <pre>value_type * data( C&amp; );
23563 </pre>
23564
23565 <blockquote>
23566 <i>Returns:</i> a pointer to the first element in the region of storage.
23567 Result is unspecified for an empty container.
23568 </blockquote>
23569
23570 </blockquote>
23571
23572 <p>
23573 Change 23.3.1 [array] p1:
23574 </p>
23575
23576 <blockquote>
23577 -1- The header <tt>&lt;array&gt;</tt> defines a class template for
23578 storing fixed-size sequences of objects. An <tt>array</tt> supports
23579 random access iterators. An instance of <tt>array&lt;T, N&gt;</tt>
23580 stores <tt>N</tt> elements of type <tt>T</tt>, so that <tt>size() ==
23581 N</tt> is an invariant. The elements of an <tt>array</tt> are stored
23582 contiguously, meaning that <del>if <tt>a</tt> is</del> an
23583 <tt>array&lt;T, N&gt;</tt> <del>then it obeys the identity <tt>&amp;a[n]
23584 == &amp;a[0] + n</tt> for all <tt>0 &lt;= n &lt; N</tt></del>
23585 <ins>satisfies the concept <tt>ContiguousStorageContainer&lt; array&lt;T,
23586 N&gt;&gt;</tt></ins>.
23587 </blockquote>
23588
23589 <p>
23590 Add to the synopsis in 23.3.1 [array]:
23591 </p>
23592
23593 <blockquote><pre>    ...
23594     T * data();
23595     const T * data() const;
23596   };
23597
23598   <ins>template&lt; typename T, size_t N &gt;</ins>
23599     <ins>concept_map ContiguousStorageContainer&lt; array&lt;T, N&gt;&gt; {};</ins>
23600 }
23601 </pre></blockquote>
23602
23603 <p>
23604 Change 23.3.6 [vector] p1:
23605 </p>
23606
23607 <blockquote>
23608 A <tt>vector</tt> is a sequence container that supports random access
23609 iterators. In addition, it supports (amortized) constant time insert and
23610 erase operations at the end; insert and erase in the middle take linear
23611 time. Storage management is handled automatically, though hints can be
23612 given to improve efficiency. The elements of a vector are stored
23613 contiguously, meaning that <del>if <tt>v</tt> is</del> a
23614 <tt>vector&lt;T, Alloc&gt;</tt> <ins>(</ins>where <tt>T</tt> is some
23615 type other than <tt>bool</tt><ins>)</ins><del>, then it obeys the
23616 identity <tt>&amp;v[n] == &amp;v[0] + n</tt> for all <tt>0 &lt;= n &lt;
23617 v.size()</tt></del> <ins>satisfies the concept <tt>ContiguousStorageContainer&lt;
23618 vector&lt; T, Alloc&gt;&gt;</tt></ins>.
23619 </blockquote>
23620
23621 <p>
23622 Add at the end of the synopsis in 23.3.6 [vector] p2:
23623 </p>
23624
23625 <blockquote><pre><ins>template&lt; typename T, typename A &gt;
23626   requires !SameType&lt; T, bool &gt;
23627   concept_map ContiguousStorageContainer&lt; vector&lt;T, A&gt;&gt; {};</ins>
23628 </pre></blockquote>
23629
23630
23631
23632
23633
23634
23635 <hr>
23636 <h3><a name="1043"></a>1043. Response to US 91</h3>
23637 <p><b>Section:</b> 29.6 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
23638  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-07-18</p>
23639 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics.types.operations">active issues</a> in [atomics.types.operations].</p>
23640 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.operations">issues</a> in [atomics.types.operations].</p>
23641 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
23642 <p><b>Discussion:</b></p>
23643
23644 <p><b>Addresses US 91</b></p>
23645
23646 <p>
23647 It is unclear whether or not a failed <tt>compare_exchange</tt> is a RMW operation
23648 (as used in 1.10 [intro.multithread]).
23649 </p>
23650
23651 <p>
23652 Suggested solution:
23653 </p>
23654
23655 <p>
23656 Make failing <tt>compare_exchange</tt> operations <b>not</b> be RMW.
23657 </p>
23658
23659 <p><i>[
23660 Anthony Williams adds:
23661 ]</i></p>
23662
23663
23664 <blockquote>
23665 In 29.6 [atomics.types.operations] p18 it says that "These
23666 operations are atomic read-modify-write operations" (final sentence).
23667 This is overly restrictive on the implementations of
23668 <tt>compare_exchange_weak</tt> and <tt>compare_exchange_strong</tt> on platforms without a
23669 native CAS instruction.
23670 </blockquote>
23671
23672
23673 <p><i>[
23674 Summit:
23675 ]</i></p>
23676
23677
23678 <blockquote>
23679 Group agrees with the resolution as proposed by Anthony Williams in the attached note.
23680 </blockquote>
23681
23682 <p><i>[
23683 Batavia (2009-05):
23684 ]</i></p>
23685
23686 <blockquote>
23687 We recommend the proposed resolution be reviewed
23688 by members of the Concurrency Subgroup.
23689 </blockquote>
23690
23691 <p><i>[
23692 2009-07 post-Frankfurt:
23693 ]</i></p>
23694
23695
23696 <blockquote>
23697 This is likely to be addressed by Lawrence's upcoming paper. He will
23698 adopt the proposed resolution.
23699 </blockquote>
23700
23701
23702
23703 <p><b>Proposed resolution:</b></p>
23704 <p>
23705 Change 29.6 [atomics.types.operations] p18:
23706 </p>
23707
23708 <blockquote>
23709 -18- <i>Effects:</i> Atomically, compares the value pointed to by
23710 <tt>object</tt> or by <tt>this</tt> for equality with that in
23711 <tt>expected</tt>, and if true, replaces the value pointed to by
23712 <tt>object</tt> or by <tt>this</tt> with desired, and if false, updates
23713 the value in <tt>expected</tt> with the value pointed to by
23714 <tt>object</tt> or by <tt>this</tt>. Further, if the comparison is true,
23715 memory is affected according to the value of <tt>success</tt>, and if the
23716 comparison is false, memory is affected according to the value of
23717 <tt>failure</tt>. When only one <tt>memory_order</tt> argument is
23718 supplied, the value of <tt>success</tt> is <tt>order</tt>, and the value
23719 of <tt>failure</tt> is <tt>order</tt> except that a value of
23720 <tt>memory_order_acq_rel</tt> shall be replaced by the value
23721 <tt>memory_order_acquire</tt> and a value of
23722 <tt>memory_order_release</tt> shall be replaced by the value
23723 <tt>memory_order_relaxed</tt>. <ins>If the comparison is <tt>true</tt>, </ins>
23724 <del>T</del><ins>t</ins>hese operations are atomic
23725 read-modify-write operations (1.10).
23726 <ins>If the comparison is <tt>false</tt>, these
23727 operations are atomic load operations.</ins>
23728 </blockquote>
23729
23730
23731
23732
23733
23734
23735 <hr>
23736 <h3><a name="1046"></a>1046. Response to UK 329</h3>
23737 <p><b>Section:</b> 30.6 [futures] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
23738  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-03-13</p>
23739 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
23740 <p><b>Discussion:</b></p>
23741
23742 <p><b>Addresses UK 329</b></p>
23743
23744 <p>
23745 <tt>future</tt>, <tt>promise</tt> and <tt>packaged_task</tt> provide a
23746 framework for creating future values, but a simple function to tie all
23747 three components together is missing. Note that we only need a *simple*
23748 facility for C++0x. Advanced thread pools are to be left for TR2.
23749 </p>
23750
23751 <p>
23752 Simple Proposal:
23753 </p>
23754
23755 <p>
23756 Provide a simple function along the lines of:
23757 </p>
23758 <blockquote><pre>template&lt; typename F, typename ... Args &gt;
23759   requires Callable&lt; F, Args... &gt;
23760     future&lt; Callable::result_type &gt; async( F&amp;&amp; f, Args &amp;&amp; ... );
23761 </pre></blockquote>
23762
23763 <p>
23764 Semantics are similar to creating a <tt>thread</tt> object with a <tt>packaged_task</tt>
23765 invoking <tt>f</tt> with <tt>forward&lt;Args&gt;(args...)</tt>
23766 but details are left unspecified to allow different scheduling and thread
23767 spawning implementations.
23768 </p>
23769 <p>
23770 It is unspecified whether a task submitted to async is run on its own thread
23771 or a thread previously used for another async task. If a call to <tt>async</tt>
23772 succeeds, it shall be safe to wait for it from any thread.
23773 </p>
23774 <p>
23775 The state of <tt>thread_local</tt> variables shall be preserved during <tt>async</tt> calls.
23776 </p>
23777 <p>
23778 No two incomplete async tasks shall see the same value of
23779 <tt>this_thread::get_id()</tt>.
23780 </p>
23781 <p>
23782 [<i>Note:</i> this effectively forces new tasks to be run on a new thread, or a
23783 fixed-size pool with no queue. If the
23784 library is unable to spawn a new thread or there are no free worker threads
23785 then the <tt>async</tt> call should fail. <i>--end note</i>]
23786 </p>
23787
23788 <p><i>[
23789 Summit:
23790 ]</i></p>
23791
23792
23793 <blockquote>
23794 <p>
23795 The concurrency subgroup has revisited this issue and decided that it
23796 could be considered a defect according to the Kona compromise. A task
23797 group was formed lead by Lawrence Crowl and Bjarne Stroustrup to write a
23798 paper for Frankfort proposing a simple asynchronous launch facility
23799 returning a <tt>future</tt>. It was agreed that the callable must be run on a
23800 separate thread from the caller, but not necessarily a brand-new thread.
23801 The proposal might or might not allow for an implementation that uses
23802 fixed-size or unlimited thread pools.
23803 </p>
23804 <p>
23805 Bjarne in c++std-lib-23121: I think that what we agreed was that to
23806 avoid deadlock <tt>async()</tt> would almost certainly be specified to  launch in
23807 a different thread from the thread that executed <tt>async()</tt>, but I don't
23808 think it was a specific design constraint.
23809 </p>
23810 </blockquote>
23811
23812
23813
23814 <p><b>Proposed resolution:</b></p>
23815
23816
23817
23818
23819
23820 <hr>
23821 <h3><a name="1047"></a>1047. Response to UK 334</h3>
23822 <p><b>Section:</b> 30.6.5 [futures.unique_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
23823  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-05-23</p>
23824 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.unique_future">active issues</a> in [futures.unique_future].</p>
23825 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.unique_future">issues</a> in [futures.unique_future].</p>
23826 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
23827 <p><b>Discussion:</b></p>
23828
23829 <p><b>Addresses UK 334</b></p>
23830
23831 <p>
23832 Behaviour of <tt>get()</tt> is undefined if calling <tt>get()</tt> while
23833 not <tt>is_ready()</tt>. The intent is that <tt>get()</tt> is a blocking
23834 call, and will wait for the future to become ready.
23835 </p>
23836
23837 <p><i>[
23838 Summit:
23839 ]</i></p>
23840
23841
23842 <blockquote>
23843 <p>
23844 Agree, move to Review.
23845 </p>
23846 </blockquote>
23847
23848 <p><i>[
23849 2009-04-03 Thomas J. Gritzan adds:
23850 ]</i></p>
23851
23852
23853 <blockquote>
23854 <p>
23855 This issue also applies to <tt>shared_future::get()</tt>.
23856 </p>
23857
23858 <p>
23859 Suggested wording:
23860 </p>
23861
23862 <p>
23863 Add a paragraph to  [futures.shared_future]:
23864 </p>
23865
23866 <blockquote><pre>void shared_future&lt;void&gt;::get() const;
23867 </pre>
23868 <blockquote>
23869 <i>Effects:</i> If <tt>is_ready()</tt> would return <tt>false</tt>, block on the asynchronous
23870 result associated with <tt>*this</tt>.
23871 </blockquote>
23872 </blockquote>
23873 </blockquote>
23874
23875 <p><i>[
23876 Batavia (2009-05):
23877 ]</i></p>
23878
23879 <blockquote>
23880 It is not clear to us that this is an issue,
23881 because the proposed resolution's Effects clause seems to duplicate
23882 information already present in the Synchronization clause.
23883 Keep in Review status.
23884 </blockquote>
23885
23886
23887 <p><b>Proposed resolution:</b></p>
23888 <p>
23889 Add a paragraph to 30.6.5 [futures.unique_future]:
23890 </p>
23891
23892 <blockquote><pre>R&amp;&amp; unique_future::get();
23893 R&amp; unique_future&lt;R&amp;&gt;::get();
23894 void unique_future&lt;void&gt;::get();
23895 </pre>
23896 <blockquote>
23897 <p><i>Note:</i>...</p>
23898 <p>
23899 <ins><i>Effects:</i> If <tt>is_ready()</tt> would return <tt>false</tt>,
23900 block on the asynchronous result associated with <tt>*this</tt>.</ins>
23901 </p>
23902 <p>
23903 <i>Synchronization:</i> if <tt>*this</tt> is associated with a
23904 <tt>promise</tt> object, the completion of <tt>set_value()</tt> or
23905 <tt>set_exception()</tt> to that <tt>promise</tt> happens before (1.10)
23906 <tt>get()</tt> returns.
23907 </p>
23908 </blockquote>
23909 </blockquote>
23910
23911
23912
23913
23914
23915 <hr>
23916 <h3><a name="1048"></a>1048. Response to UK 335</h3>
23917 <p><b>Section:</b> 30.6.5 [futures.unique_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
23918  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-03-13</p>
23919 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.unique_future">active issues</a> in [futures.unique_future].</p>
23920 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.unique_future">issues</a> in [futures.unique_future].</p>
23921 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
23922 <p><b>Discussion:</b></p>
23923
23924 <p><b>Addresses UK 335</b></p>
23925
23926 <p>
23927 <tt>std::unique_future</tt> is <tt>MoveConstructible</tt>, so you can transfer the
23928 association with an asynchronous result from one instance to another.
23929 However, there is no way to determine whether or not an instance has
23930 been moved from, and therefore whether or not it is safe to wait for it.
23931 </p>
23932
23933 <blockquote><pre>std::promise&lt;int&gt; p;
23934 std::unique_future&lt;int&gt; uf(p.get_future());
23935 std::unique_future&lt;int&gt; uf2(std::move(uf));
23936 uf.wait(); <font color="#c80000">// oops, uf has no result to wait for. </font>
23937 </pre></blockquote>
23938
23939 <p>
23940 Suggest we add a <tt>waitable()</tt> function to <tt>unique_future</tt>
23941 (and <tt>shared_future</tt>) akin to <tt>std::thread::joinable()</tt>,
23942 which returns <tt>true</tt> if there is an associated result to wait for
23943 (whether or not it is ready).
23944 </p>
23945
23946 <p>
23947 Then we can say:
23948 </p>
23949
23950 <blockquote><pre>if(uf.waitable()) uf.wait();
23951 </pre></blockquote>
23952
23953 <p><i>[
23954 Summit:
23955 ]</i></p>
23956
23957
23958 <blockquote>
23959 <p>
23960 Create an issue. Requires input from Howard. Probably NAD.
23961 </p>
23962 </blockquote>
23963
23964 <p><i>[
23965 Post Summit, Howard thows in his two cents:
23966 ]</i></p>
23967
23968
23969 <blockquote>
23970 <p>
23971 Here is a copy/paste of my last prototype of <tt>unique_future</tt> which was
23972 several years ago.  At that time I was calling <tt>unique_future</tt> <tt>future</tt>:
23973 </p>
23974
23975 <blockquote><pre>template &lt;class R&gt;
23976 class future
23977 {
23978 public:
23979     typedef R result_type;
23980 private:
23981     future(const future&amp;);// = delete;
23982     future&amp; operator=(const future&amp;);// = delete;
23983
23984     template &lt;class R1, class F1&gt; friend class prommise;
23985 public:
23986     future();
23987     ~future();
23988
23989     future(future&amp;&amp; f);
23990     future&amp; operator=(future&amp;&amp; f);
23991
23992     void swap(future&amp;&amp; f);
23993
23994     <b>bool joinable() const;</b>
23995     bool is_normal() const;
23996     bool is_exceptional() const;
23997     bool is_ready() const;
23998
23999     R get();
24000
24001     void join();
24002     template &lt;class ElapsedTime&gt;
24003         bool timed_join(const ElapsedTime&amp;);
24004 };
24005 </pre></blockquote>
24006
24007 <p>
24008 <tt>shared_future</tt> had a similar interface.  I intentionally reused
24009 the <tt>thread</tt> interface where possible to lessen the learning
24010 curve std::lib clients will be faced with.
24011 </p>
24012 </blockquote>
24013
24014
24015
24016 <p><b>Proposed resolution:</b></p>
24017
24018
24019
24020
24021
24022 <hr>
24023 <h3><a name="1049"></a>1049. Response to UK 339</h3>
24024 <p><b>Section:</b> 30.6.4 [futures.promise] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
24025  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-05-23</p>
24026 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
24027 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.promise">issues</a> in [futures.promise].</p>
24028 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
24029 <p><b>Discussion:</b></p>
24030
24031 <p><b>Addresses UK 339</b></p>
24032
24033 <p>
24034 Move assignment is goiing in the wrong direction, assigning from
24035 <tt>*this</tt> to the passed rvalue, and then returning a reference to
24036 an unusable <tt>*this</tt>.
24037 </p>
24038
24039 <p><i>[
24040 Summit:
24041 ]</i></p>
24042
24043
24044 <blockquote>
24045 <p>
24046 Agree, move to Review.
24047 </p>
24048 </blockquote>
24049
24050 <p><i>[
24051 Batavia (2009-05):
24052 ]</i></p>
24053
24054 <blockquote>
24055 We recommend deferring this issue until after Detlef's paper (on futures)
24056 has been issued.
24057 </blockquote>
24058
24059
24060 <p><b>Proposed resolution:</b></p>
24061 <p>
24062 Strike 30.6.4 [futures.promise] p6 and change p7:
24063 </p>
24064
24065 <blockquote><pre>promise&amp; operator=(promise&amp;&amp; rhs);
24066 </pre>
24067 <blockquote>
24068 <p>
24069 <del>-6- <i>Effects:</i> move assigns its associated state to <tt>rhs</tt>.</del>
24070 </p>
24071 <p>
24072 -7- <i>Postcondition:</i> <del><tt>*this</tt> has no associated
24073 state.</del> <ins>associated state of <tt>*this</tt> is the same as the
24074 associated state of <tt>rhs</tt> before the call. <tt>rhs</tt> has no
24075 associated state.</ins>
24076 </p>
24077 </blockquote>
24078 </blockquote>
24079
24080
24081
24082
24083
24084
24085 <hr>
24086 <h3><a name="1050"></a>1050. Response to UK 340</h3>
24087 <p><b>Section:</b> 30.6.4 [futures.promise] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
24088  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-05-23</p>
24089 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
24090 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.promise">issues</a> in [futures.promise].</p>
24091 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
24092 <p><b>Discussion:</b></p>
24093
24094 <p><b>Addresses UK 340</b></p>
24095
24096 <p>
24097 There is an implied postcondition for <tt>get_future()</tt> that the state of the
24098 <tt>promise</tt> is transferred into the <tt>future</tt> leaving the <tt>promise</tt> with no
24099 associated state. It should be spelled out.
24100 </p>
24101
24102 <p><i>[
24103 Summit:
24104 ]</i></p>
24105
24106
24107 <blockquote>
24108 <p>
24109 Agree, move to Review.
24110 </p>
24111 </blockquote>
24112
24113 <p><i>[
24114 2009-04-03 Thomas J. Gritzan adds:
24115 ]</i></p>
24116
24117
24118 <blockquote>
24119 <p>
24120 <tt>promise::get_future()</tt> must not invalidate the state of the promise object.
24121 </p>
24122 <p>
24123 A promise is used like this:
24124 </p>
24125 <blockquote><pre>promise&lt;int&gt; p;
24126 unique_future&lt;int&gt; f = p.get_future();
24127 <font color="#c80000">// post 'p' to a thread that calculates a value </font>
24128 <font color="#c80000">// use 'f' to retrieve the value. </font>
24129 </pre></blockquote>
24130 <p>
24131 So <tt>get_future()</tt> must return an object that shares the same associated
24132 state with <tt>*this</tt>.
24133 </p>
24134 <p>
24135 But still, this function should throw an <tt>future_already_retrieved</tt> error
24136 when it is called twice.
24137 </p>
24138 <p>
24139 <tt>packaged_task::get_future()</tt> throws <tt>std::bad_function_call</tt> if its <tt>future</tt>
24140 was already retrieved. It should throw
24141 <tt>future_error(future_already_retrieved)</tt>, too.
24142 </p>
24143 <p>
24144 Suggested resolution:
24145 </p>
24146 <p>
24147 Replace p12/p13 30.6.4 [futures.promise]:
24148 </p>
24149 <blockquote>
24150 <p>
24151 -12- <i>Throws:</i> <tt>future_error</tt> if <del><tt>*this</tt> has no associated state</del>
24152 <ins>the <tt>future</tt> has already been retrieved</ins>.
24153 </p>
24154 <p>
24155 -13- <i>Error conditions:</i> <tt>future_already_retrieved</tt> if <del><tt>*this</tt>
24156 has no associated state</del>
24157 <ins>the <tt>future</tt> associated with
24158 the associated state has already been retrieved</ins>.
24159 </p>
24160 <p>
24161 <ins><i>Postcondition:</i> The returned object and <tt>*this</tt> share the associated state.</ins>
24162 </p>
24163 </blockquote>
24164 <p>
24165 Replace p14 30.6.7 [futures.task]:
24166 </p>
24167 <blockquote>
24168 <p>
24169 -14- <i>Throws:</i> <tt><del>std::bad_function_call</del> <ins>future_error</ins></tt> if the future <del>associated with
24170 the task</del> has already been retrieved.
24171 </p>
24172
24173 <p><ins>
24174 <i>Error conditions:</i> <tt>future_already_retrieved</tt> if the <tt>future</tt> associated with
24175 the task has already been retrieved.
24176 </ins></p>
24177 <p>
24178 <ins><i>Postcondition:</i> The returned object and <tt>*this</tt> share the associated task.</ins>
24179 </p>
24180 </blockquote>
24181 </blockquote>
24182
24183 <p><i>[
24184 Batavia (2009-05):
24185 ]</i></p>
24186
24187 <blockquote>
24188 Keep in Review status
24189 pending Detlef's forthcoming paper on futures.
24190 </blockquote>
24191
24192
24193 <p><b>Proposed resolution:</b></p>
24194 <p>
24195 Add after p13 30.6.4 [futures.promise]:
24196 </p>
24197
24198 <blockquote><pre>unique_future&lt;R&gt; get_future();
24199 </pre>
24200 <blockquote>
24201 <p>
24202 -13- ...
24203 </p>
24204 <p>
24205 <i>Postcondition:</i> <tt>*this</tt> has no associated state.
24206 </p>
24207 </blockquote>
24208 </blockquote>
24209
24210
24211
24212
24213
24214
24215 <hr>
24216 <h3><a name="1051"></a>1051. Response to UK 279</h3>
24217 <p><b>Section:</b> 24.5.1.2.12 [reverse.iter.opindex], 24.5.2.2.12 [move.iter.op.index] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
24218  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-07-27</p>
24219 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
24220 <p><b>Discussion:</b></p>
24221
24222 <p><b>Addresses UK 279</b></p>
24223
24224 <p>
24225 The reason the return type became unspecified is LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#386">386</a>. This
24226 reasoning no longer applies as there are at least two ways to get the right
24227 return type with the new language facilities added since the previous
24228 standard.
24229 </p>
24230
24231 <p>
24232 Proposal: Specify the return type using either decltype or the Iter concept_map.
24233 </p>
24234
24235 <p><i>[
24236 Summit:
24237 ]</i></p>
24238
24239
24240 <blockquote>
24241 <p>
24242 Under discussion. This is a general question about all iterator
24243 adapters.
24244 </p>
24245 </blockquote>
24246
24247 <p><i>[
24248 Howard adds post Summit:
24249 ]</i></p>
24250
24251
24252 <blockquote>
24253 I am requesting test cases to demonstrate a position.
24254 </blockquote>
24255
24256 <p><i>[
24257 2009-07-24 Daniel adds:
24258 ]</i></p>
24259
24260
24261 <blockquote>
24262 <p>
24263 I recommend NAD. Without concepts we can no longer
24264 restrict this member in a trivial way. Using <tt>decltype</tt> the
24265 declaration would be along the lines of
24266 </p>
24267 <blockquote><pre>static const Iter&amp; __base(); // not defined
24268 auto operator[](difference_type n) const -&gt; decltype(__base()[-n-1]);
24269 </pre></blockquote>
24270
24271 <p>
24272 but once <tt>reverse_iterator</tt> is instantiated for some given type
24273 <tt>Iter</tt> which cannot form a well-formed expression <tt>__base()[-n-1]</tt>
24274 this would cause an ill-formed function declaration, diagnostic
24275 required, and no silent SFINAE elimination.
24276 </p>
24277
24278 </blockquote>
24279
24280
24281
24282 <p><b>Proposed resolution:</b></p>
24283
24284
24285
24286
24287
24288 <hr>
24289 <h3><a name="1052"></a>1052. Response to UK 281</h3>
24290 <p><b>Section:</b> 24.5.1.2.5 [reverse.iter.opref] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
24291  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-08-01</p>
24292 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
24293 <p><b>Discussion:</b></p>
24294
24295 <p><b>Addresses UK 281</b></p>
24296
24297 <p>
24298 The current specification for return value for <tt>reverse_iterator::operator-&gt;</tt>
24299 will always be a true pointer type, but <tt>reverse_iterator</tt> supports proxy
24300 iterators where the pointer type may be some kind of 'smart pointer'.
24301 </p>
24302
24303 <p><i>[
24304 Summit:
24305 ]</i></p>
24306
24307
24308 <blockquote>
24309 <p>
24310 <tt>move_iterator</tt> avoids this problem by returning a value of the wrapped
24311 Iterator type.
24312 study group formed to come up with a suggested resolution.
24313 </p>
24314 <p>
24315 <tt>move_iterator</tt> solution shown in proposed wording.
24316 </p>
24317 </blockquote>
24318
24319 <p><i>[
24320 2009-07 post-Frankfurt:
24321 ]</i></p>
24322
24323
24324 <blockquote>
24325 Howard to deconceptize. Move to Review after that happens.
24326 </blockquote>
24327
24328 <p><i>[
24329 2009-08-01 Howard deconceptized:
24330 ]</i></p>
24331
24332
24333 <blockquote>
24334 </blockquote>
24335
24336
24337
24338 <p><b>Proposed resolution:</b></p>
24339 <p>
24340 Change synopsis in 24.5.1.1 [reverse.iterator]:
24341 </p>
24342
24343 <blockquote><pre>template &lt;class Iterator&gt;
24344 class reverse_iterator {
24345   ...
24346   typedef <del>typename iterator_traits&lt;</del>Iterator<del>&gt;::pointer</del> pointer;
24347 </pre></blockquote>
24348
24349 <p>
24350 Change 24.5.1.2.5 [reverse.iter.opref]:
24351 </p>
24352
24353 <blockquote><pre>pointer operator-&gt;() const;
24354 </pre>
24355 <blockquote>
24356 <i>Returns:</i>
24357 <blockquote><pre><del>&amp;(operator*());</del>
24358 <ins>this-&gt;tmp = current;</ins>
24359 <ins>--this-&gt;tmp;</ins>
24360 <ins>return this-&gt;tmp;</ins>
24361 </pre></blockquote>
24362 </blockquote>
24363 </blockquote>
24364
24365
24366
24367
24368
24369
24370 <hr>
24371 <h3><a name="1053"></a>1053. Response to UK 295</h3>
24372 <p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
24373  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-03-13</p>
24374 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#algorithms">active issues</a> in [algorithms].</p>
24375 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#algorithms">issues</a> in [algorithms].</p>
24376 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
24377 <p><b>Discussion:</b></p>
24378
24379 <p><b>Addresses UK 295</b></p>
24380
24381 <p>
24382 There is a level of redundancy in the library specification for many
24383 algorithms that can be eliminated with the combination of concepts and
24384 default parameters for function templates. Eliminating redundancy simplified
24385 specification and reduces the risk of introducing accidental
24386 inconsistencies.
24387 </p>
24388 <p>
24389 Proposed resolution: Adopt
24390 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2743.pdf">N2743</a>.
24391 </p>
24392
24393 <p><i>[
24394 Summit:
24395 ]</i></p>
24396
24397
24398 <blockquote>
24399 <p>
24400 NAD, this change would break code that takes the address of an
24401 algorithm.
24402 </p>
24403 </blockquote>
24404
24405 <p><i>[
24406 Post Summit Alisdair adds:
24407 ]</i></p>
24408
24409
24410 <blockquote>
24411 <p>
24412 Request 'Open'.  The issues in the paper go beyond just reducing
24413 the number of signatures, but cover unifying the idea of the ordering
24414 operation used by algorithms, containers and other library components.  At
24415 least, it takes a first pass at the problem.
24416 </p>
24417
24418 <p>
24419 For me (personally) that was the more important part of the paper, and not
24420 clearly addressed by the Summit resolution.
24421 </p>
24422 </blockquote>
24423
24424
24425
24426 <p><b>Proposed resolution:</b></p>
24427
24428
24429
24430
24431
24432 <hr>
24433 <h3><a name="1054"></a>1054. <tt>forward</tt> broken</h3>
24434 <p><b>Section:</b> 20.3.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
24435  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-13  <b>Last modified:</b> 2009-08-02</p>
24436 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forward">active issues</a> in [forward].</p>
24437 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward">issues</a> in [forward].</p>
24438 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
24439 <p><b>Discussion:</b></p>
24440
24441 <p>
24442 This is a placeholder issue to track the fact that we (well I) put the standard
24443 into an inconsistent state by requesting that we accept
24444 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>
24445 except for the proposed changes to [forward].
24446 </p>
24447
24448 <p>
24449 There will exist in the post meeting mailing
24450 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2835.html">N2835</a>
24451 which in its current state reflects the state of affairs prior to the Summit
24452 meeting.  I hope to update it in time for the post Summit mailing, but as I write
24453 this issue I have not done so yet.
24454 </p>
24455
24456 <p><i>[
24457 Batavia (2009-05):
24458 ]</i></p>
24459
24460 <blockquote>
24461 Move to Open, awaiting the promised paper.
24462 </blockquote>
24463
24464 <p><i>[
24465 2009-08-02 Howard adds:
24466 ]</i></p>
24467
24468
24469 <blockquote>
24470 <p>
24471 My current preferred solution is:
24472 </p>
24473
24474 <blockquote><pre>template &lt;class T&gt;
24475 struct __base_type
24476 {
24477    typedef typename remove_cv&lt;typename remove_reference&lt;T&gt;::type&gt;::type type;
24478 };
24479
24480 template &lt;class T, class U,
24481    class = typename enable_if&lt;
24482        !is_lvalue_reference&lt;T&gt;::value ||
24483         is_lvalue_reference&lt;T&gt;::value &amp;&amp;
24484         is_lvalue_reference&lt;U&gt;::value&gt;::type,
24485    class = typename enable_if&lt;
24486         is_same&lt;typename __base_type&lt;T&gt;::type,
24487                 typename __base_type&lt;U&gt;::type&gt;::value&gt;::type&gt;
24488 inline
24489 T&amp;&amp;
24490 forward(U&amp;&amp; t)
24491 {
24492    return static_cast&lt;T&amp;&amp;&gt;(t);
24493 }
24494 </pre></blockquote>
24495
24496 <p>
24497 This has been tested by Bill, Jason and myself.
24498 </p>
24499
24500 <p>
24501 It allows the following lvalue/rvalue casts:
24502 </p>
24503
24504 <ol>
24505 <li>
24506 Cast an lvalue <tt>t</tt> to an lvalue <tt>T</tt> (identity).
24507 </li>
24508 <li>
24509 Cast an lvalue <tt>t</tt> to an rvalue <tt>T</tt>.
24510 </li>
24511 <li>
24512 Cast an rvalue <tt>t</tt> to an rvalue <tt>T</tt> (identity).
24513 </li>
24514 </ol>
24515
24516 <p>
24517 It disallows:
24518 </p>
24519
24520 <ol type="a">
24521 <li>
24522 Cast an rvalue <tt>t</tt> to an lvalue <tt>T</tt>.
24523 </li>
24524 <li>
24525 Cast one type <tt>t</tt> to another type <tt>T</tt> (such as <tt>int</tt> to <tt>double</tt>).
24526 </li>
24527 </ol>
24528
24529 <p>
24530 "a." is disallowed as it can easily lead to dangling references.
24531 "b." is disallowed as this function is meant to only change the lvalue/rvalue
24532 characteristic of an expression.
24533 </p>
24534
24535 <p>
24536 Jason has expressed concern that "b." is not dangerous and is useful in contexts
24537 where you want to "forward" a derived type as a base type.  I find this use case
24538 neither dangerous, nor compelling.  I.e. I could live with or without the "b."
24539 constraint.  Without it, forward would look like:
24540 </p>
24541
24542 <blockquote><pre>template &lt;class T, class U,
24543    class = typename enable_if&lt;
24544        !is_lvalue_reference&lt;T&gt;::value ||
24545         is_lvalue_reference&lt;T&gt;::value &amp;&amp;
24546         is_lvalue_reference&lt;U&gt;::value&gt;::type&gt;
24547 inline
24548 T&amp;&amp;
24549 forward(U&amp;&amp; t)
24550 {
24551    return static_cast&lt;T&amp;&amp;&gt;(t);
24552 }
24553 </pre></blockquote>
24554
24555 <p>
24556 Or possibly:
24557 </p>
24558
24559 <blockquote><pre>template &lt;class T, class U,
24560    class = typename enable_if&lt;
24561        !is_lvalue_reference&lt;T&gt;::value ||
24562         is_lvalue_reference&lt;T&gt;::value &amp;&amp;
24563         is_lvalue_reference&lt;U&gt;::value&gt;::type,
24564    class = typename enable_if&lt;
24565         is_base_of&lt;typename __base_type&lt;U&gt;::type,
24566                    typename __base_type&lt;T&gt;::type&gt;::value&gt;::type&gt;
24567 inline
24568 T&amp;&amp;
24569 forward(U&amp;&amp; t)
24570 {
24571    return static_cast&lt;T&amp;&amp;&gt;(t);
24572 }
24573 </pre></blockquote>
24574
24575
24576 <p>
24577 The "promised paper" is not in the post-Frankfurt mailing only because I'm waiting
24578 for the non-concepts draft.  But I'm hoping that by adding this information here
24579 I can keep people up to date.
24580 </p>
24581 </blockquote>
24582
24583
24584
24585 <p><b>Proposed resolution:</b></p>
24586
24587
24588
24589
24590
24591 <hr>
24592 <h3><a name="1055"></a>1055. Response to UK 98</h3>
24593 <p><b>Section:</b> 20.6.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
24594  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-05-23</p>
24595 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.trans.other">active issues</a> in [meta.trans.other].</p>
24596 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
24597 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
24598 <p><b>Discussion:</b></p>
24599
24600 <p><b>Addresses UK 98</b></p>
24601
24602 <p>
24603 It would be useful to be able to determine the underlying
24604 type of an arbitrary enumeration type. This would allow
24605 safe casting to an integral type (especially needed for
24606 scoped enums, which do not promote), and would allow
24607 use of <tt>numeric_limits</tt>. In general it makes generic
24608 programming with enumerations easier.
24609 </p>
24610
24611 <p><i>[
24612 Batavia (2009-05):
24613 ]</i></p>
24614
24615 <blockquote>
24616 Pete observes (and Tom concurs)
24617 that the proposed resolution seems to require compiler support
24618 for its implementation,
24619 as it seems necessary to look at the range of values
24620 of the enumerated type.
24621 To a first approximation,
24622 a library solution could give an answer based on the size of the type.
24623 If the user has specialized <tt>numeric_limits</tt> for the enumerated type,
24624 then the library might be able to do better,
24625 but there is no such requirement.
24626 Keep status as Open
24627 and solicit input from CWG.
24628 </blockquote>
24629
24630 <p><i>[
24631 2009-05-23 Alisdair adds:
24632 ]</i></p>
24633
24634
24635 <blockquote>
24636 Just to confirm that the BSI originator of this comment assumed it did
24637 indeed imply a compiler intrinsic.  Rather than request a Core extension, it
24638 seemed in keeping with that the type traits interface provides a library API
24639 to unspecified compiler features - where we require several other traits
24640 (e.g. <tt>has_trivial_*</tt>) to get the 'right' answer now, unlike in TR1.
24641 </blockquote>
24642
24643
24644 <p><b>Proposed resolution:</b></p>
24645 <p>
24646 Add a new row to the table in 20.6.7 [meta.trans.other]:
24647 </p>
24648
24649 <blockquote>
24650 <table border="1">
24651 <caption>Table 41 -- Other transformations</caption>
24652 <tbody><tr>
24653 <th>Template</th>
24654 <th>Condition</th>
24655 <th>Comments</th>
24656 </tr>
24657 <tr>
24658 <td>
24659 <tt>template&lt;&nbsp;class&nbsp;T&nbsp;&gt; struct enum_base;</tt>
24660 </td>
24661 <td>
24662 <tt>T</tt> shall be an enumeration type (7.2 [dcl.enum])
24663 </td>
24664 <td>
24665 The member typedef <tt>type</tt> shall name the underlying type
24666 of the enum <tt>T</tt>.
24667 </td>
24668 </tr>
24669 </tbody></table>
24670 </blockquote>
24671
24672
24673
24674
24675
24676 <hr>
24677 <h3><a name="1056"></a>1056. Must all Engines and Distributions be Streamable?</h3>
24678 <p><b>Section:</b> 26.5 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
24679  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-05-31</p>
24680 <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>
24681 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
24682 <p><b>Discussion:</b></p>
24683
24684 <p>
24685 Both the concepts <tt>RandomNumberEngine</tt> and <tt>RandomNumberDistribution</tt> have
24686 requirements to be <tt>InputStreamable</tt> and <tt>OutputStreamable</tt>.
24687 </p>
24688 <p>
24689 I have no problems leaving the WP in an inconsistent state on the best-faith
24690 assumption these concepts will be provided later, however disagree with the
24691 proposers that these constraints are not separable, orthogonal to the basic
24692 concepts of generating random number distributions.
24693 </p>
24694 <p>
24695 These constraints should be dropped, and applied to specific algorithms as
24696 needed.
24697 </p>
24698 <p>
24699 If a more refined concept (certainly deemed useful by the proposers) is
24700 proposed there is no objection, but the basic concept should not require
24701 persistence via streaming.
24702 </p>
24703
24704 <p><i>[
24705 Batavia (2009-05):
24706 ]</i></p>
24707
24708 <blockquote>
24709 Move to Open.
24710 </blockquote>
24711
24712 <p><i>[
24713 2009-05-31 Alisdair adds:
24714 ]</i></p>
24715
24716
24717 <blockquote>
24718 <p>
24719 Working on constraining the stream iterators, I have a few more observations
24720 to make on the concepts proposed while constraining the random number
24721 facility.
24722 </p>
24723 <p>
24724 While I still believe the concerns are orthogonal, I don't believe the
24725 existing constraints go far enough either!  The goal we want to achieve is
24726 not that a <tt>RandomNumberEngine</tt> / <tt>RandomNumberDistribution</tt> supports the stream
24727 operators, but that it is <tt>Serializable</tt>.  I.e. there is a relationship
24728 between the insert and extract operations that guarantees to restore the
24729 state of the original object.  This implies a coupling of the concepts
24730 together in a broader concept (<tt>Serializable</tt>) with at least one axiom to
24731 assert the semantics.
24732 </p>
24733 <p>
24734 One problem is that <tt>istream</tt> and <tt>ostream</tt> may be fundamentally different
24735 types, although we can hook a relation if we are prepared to drop down to
24736 the <tt>char</tt> type and <tt>char_traits</tt> template parameters.  Doing so ties us to a
24737 form of serialization that demands implementation via the std iostreams
24738 framework, which seems overly prescriptive.  I believe the goal is generally
24739 to support serialization without regard to how it is expressed - although
24740 this is getting even more inventive in terms of concepts we do not have
24741 today.
24742 </p>
24743 </blockquote>
24744
24745
24746 <p><b>Proposed resolution:</b></p>
24747
24748
24749
24750
24751
24752 <hr>
24753 <h3><a name="1062"></a>1062. Missing insert_iterator for stacks/queues</h3>
24754 <p><b>Section:</b> 24.7 [insert.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">Tentatively NAD Future</a>
24755  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-13  <b>Last modified:</b> 2009-07-29</p>
24756 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#insert.iterators">active issues</a> in [insert.iterators].</p>
24757 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#insert.iterators">issues</a> in [insert.iterators].</p>
24758 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Tentatively%20NAD%20Future">Tentatively NAD Future</a> status.</p>
24759 <p><b>Discussion:</b></p>
24760
24761 <p>
24762 It is odd that we have an iterator to insert into a <tt>vector</tt>, but not an
24763 iterator to insert into a <tt>vector</tt> that is adapted as a <tt>stack</tt>. The standard
24764 container adapters all have a common interface to <tt>push</tt> and <tt>pop</tt> so it should
24765 be simple to create an iterator adapter to complete the library support.
24766 </p>
24767
24768 <p>
24769 We should provide an <tt>AdaptedContainer</tt> concept supporting <tt>push</tt> and <tt>pop</tt>
24770 operations. Create a new insert iterator and factory function that inserts
24771 values into the container by calling <tt>push</tt>.
24772 </p>
24773
24774 <p><i>[
24775 Batavia (2009-05):
24776 ]</i></p>
24777
24778 <blockquote>
24779 <p>
24780 Walter recommends NAD Future.
24781 </p>
24782 <p>
24783 Move to Open, and recommend deferring the issue until after the next
24784 Committee Draft is issued.
24785 </p>
24786 </blockquote>
24787
24788 <p><i>[
24789 2009-07-29 Howard moves to Tentatively NAD Future.
24790 ]</i></p>
24791
24792
24793 <blockquote>
24794 A poll on the LWG reflector voted unanimously to move this issue to Tentatively NAD Future.
24795 </blockquote>
24796
24797
24798 <p><b>Proposed resolution:</b></p>
24799
24800
24801
24802
24803
24804 <hr>
24805 <h3><a name="1064"></a>1064. Response to UK 152</h3>
24806 <p><b>Section:</b> 17.3.15 [defns.obj.state] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
24807  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-15  <b>Last modified:</b> 2009-03-15</p>
24808 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
24809 <p><b>Discussion:</b></p>
24810
24811 <p><b>Addresses UK 152</b></p>
24812
24813 <p>
24814 Object state is using a definition of object (instance of a class) from
24815 outside the standard, rather than the 'region of storage' definiton in
24816 1.8 [intro.object]p1
24817 </p>
24818
24819 <p><i>[
24820 Summit:
24821 ]</i></p>
24822
24823 <blockquote>
24824 We think we're removing this; See X [func.referenceclosure.cons].
24825 </blockquote>
24826
24827
24828 <p><b>Proposed resolution:</b></p>
24829 <p>
24830 </p>
24831
24832
24833
24834
24835
24836 <hr>
24837 <h3><a name="1068"></a>1068. class random_device should be movable</h3>
24838 <p><b>Section:</b> 26.5.6 [rand.device] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
24839  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-18  <b>Last modified:</b> 2009-05-23</p>
24840 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.device">issues</a> in [rand.device].</p>
24841 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
24842 <p><b>Discussion:</b></p>
24843
24844 <p>
24845 class <tt>random_device</tt> should be movable.
24846 </p>
24847
24848 <p><i>[
24849 Batavia (2009-05):
24850 ]</i></p>
24851
24852 <blockquote>
24853 Move to Open, and recommend this issue be deferred until after the next
24854 Committee Draft is issued.
24855 </blockquote>
24856
24857
24858 <p><b>Proposed resolution:</b></p>
24859
24860
24861
24862
24863
24864 <hr>
24865 <h3><a name="1069"></a>1069. class seed_seq should support efficient move operations</h3>
24866 <p><b>Section:</b> 26.5.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
24867  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-18  <b>Last modified:</b> 2009-05-23</p>
24868 <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>
24869 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
24870 <p><b>Discussion:</b></p>
24871
24872 <p>
24873 class <tt>seed_seq</tt> should support efficient move operations.
24874 </p>
24875
24876 <p><i>[
24877 Batavia (2009-05):
24878 ]</i></p>
24879
24880 <blockquote>
24881 Move to Open, and recommend this issue be deferred until after the next
24882 Committee Draft is issued.
24883 </blockquote>
24884
24885
24886 <p><b>Proposed resolution:</b></p>
24887
24888
24889
24890
24891
24892 <hr>
24893 <h3><a name="1071"></a>1071. is_bind_expression should derive from integral_constant&lt;bool&gt;</h3>
24894 <p><b>Section:</b> 20.7.12.1.1 [func.bind.isbind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
24895  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-19  <b>Last modified:</b> 2009-05-31</p>
24896 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
24897 <p><b>Discussion:</b></p>
24898
24899 <p>
24900 Class template is_bind_expression 20.7.12.1.1 [func.bind.isbind]:
24901 </p>
24902
24903 <blockquote><pre>namespace std {
24904   template&lt;class T&gt; struct is_bind_expression {
24905     static const bool value = see below;
24906   };
24907 }
24908 </pre></blockquote>
24909 <p>
24910 <tt>is_bind_expression</tt> should derive from <tt>std::integral_constant&lt;bool&gt;</tt> like
24911 other similar trait types.
24912 </p>
24913
24914 <p><i>[
24915 Daniel adds:
24916 ]</i></p>
24917
24918 <blockquote>
24919 We need the same thing for the trait <tt>is_placeholder</tt> as well.
24920 </blockquote>
24921 <p><i>[
24922 2009-03-22 Daniel provided wording.
24923 ]</i></p>
24924
24925
24926 <p><i>[
24927 Batavia (2009-05):
24928 ]</i></p>
24929
24930 <blockquote>
24931 <p>
24932 We recommend this be deferred until after the next Committee Draft is issued.
24933 </p>
24934 <p>
24935 Move to Open.
24936 </p>
24937 </blockquote>
24938
24939 <p><i>[
24940 2009-05-31 Peter adds:
24941 ]</i></p>
24942
24943
24944 <blockquote>
24945 <p>
24946 I am opposed to the proposed resolution and to the premise of the issue
24947 in general. The traits's default definitions should NOT derive from
24948 <tt>integral_constant</tt>, because this is harmful, as it misleads people into
24949 thinking that <tt>is_bind_expression&lt;E&gt;</tt> always derives from
24950 <tt>integral_constant</tt>, whereas it may not.
24951 </p>
24952 <p>
24953 <tt>is_bind_expression</tt> and <tt>is_placeholder</tt> allow user
24954 specializations, and in fact, this is their primary purpose. Such user
24955 specializations may not derive from <tt>integral_constant</tt>, and the
24956 places where <tt>is_bind_expression</tt> and <tt>is_placeholder</tt> are
24957 used intentionally do not require such derivation.
24958 </p>
24959 <p>
24960 The long-term approach here is to switch to
24961 <tt>BindExpression&lt;E&gt;</tt> and <tt>Placeholder&lt;P&gt;</tt>
24962 explicit concepts, of course, but until that happens, I say leave them
24963 alone.
24964 </p>
24965 </blockquote>
24966
24967
24968
24969 <p><b>Proposed resolution:</b></p>
24970 <ol>
24971 <li>
24972 <p>
24973 In 20.7.12.1.1 [func.bind.isbind] change as indicated:
24974 </p>
24975 <blockquote><pre>namespace std {
24976  template&lt;class T&gt; struct is_bind_expression <ins>: integral_constant&lt;bool, <i>see below</i>&gt; { };</ins><del>{
24977    static const bool value = <i>see below</i>;
24978  };</del>
24979 }
24980 </pre></blockquote>
24981 </li>
24982 <li>
24983 <p>
24984 In 20.7.12.1.1 [func.bind.isbind]/2 change as indicated:
24985 </p>
24986 <blockquote><pre><del>static const bool value;</del>
24987 </pre>
24988 <blockquote>
24989 -2- <del><tt>true</tt> if <tt>T</tt> is a type returned from <tt>bind</tt>, <tt>false</tt> otherwise.</del>
24990   <ins>If <tt>T</tt> is a type returned from <tt>bind</tt>, <tt>is_bind_expression&lt;T&gt;</tt> shall
24991 be publicly derived from
24992         <tt>integral_constant&lt;bool, true&gt;</tt>, otherwise it shall be
24993 publicly derived from
24994           <tt>integral_constant&lt;bool, false&gt;</tt>.</ins>
24995 </blockquote>
24996 </blockquote>
24997 </li>
24998 <li>
24999 <p>
25000 In 20.7.12.1.2 [func.bind.isplace] change as indicated:
25001 </p>
25002 <blockquote><pre>namespace std {
25003  template&lt;class T&gt; struct is_placeholder <ins>: integral_constant&lt;int, <i>see below</i>&gt; { };</ins><del>{
25004    static const int value = <i>see below</i>;
25005  };</del>
25006 }
25007 </pre></blockquote>
25008 </li>
25009 <li>
25010 <p>
25011 In 20.7.12.1.2 [func.bind.isplace]/2 change as indicated:
25012 </p>
25013 <blockquote><pre><del>static const int value;</del>
25014 </pre>
25015 <blockquote>
25016 -2- <del>value is <tt>J</tt> if <tt>T</tt> is the type of <tt>std::placeholders::_J</tt>, 0 otherwise.</del>
25017   <ins>If <tt>T</tt> is the type of <tt>std::placeholders::_J</tt>, <tt>is_placeholder&lt;T&gt;</tt>
25018 shall be publicly
25019           derived from <tt>integral_constant&lt;int, J&gt;</tt> otherwise it shall
25020 be publicly derived
25021           from <tt>integral_constant&lt;int, 0&gt;</tt>.</ins>
25022 </blockquote>
25023 </blockquote>
25024 </li>
25025 </ol>
25026
25027
25028
25029
25030
25031 <hr>
25032 <h3><a name="1075"></a>1075. Response to US 65, US 74.1</h3>
25033 <p><b>Section:</b> 20 [utilities], 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
25034  <b>Submitter:</b> Alan Talbot <b>Opened:</b> 2009-03-20  <b>Last modified:</b> 2009-06-10</p>
25035 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utilities">issues</a> in [utilities].</p>
25036 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
25037 <p><b>Discussion:</b></p>
25038 <p><b>Addresses US 65 and US 74.1</b></p>
25039
25040 <p>US 65:</p>
25041
25042 <blockquote>
25043 Scoped allocators and allocator propagation traits add a small amount of
25044 utility at the cost of a great deal of machinery. The machinery is user
25045 visible, and it extends to library components that don't have any
25046 obvious connection to allocators, including basic concepts and simple
25047 components like <tt>pair</tt> and <tt>tuple</tt>.
25048
25049 <p>Suggested resolution:</p>
25050
25051 <p>
25052 Sketch of proposed resolution: Eliminate scoped allocators, replace
25053 allocator propagation traits with a simple uniform rule (e.g. always
25054 propagate on copy and move), remove all mention of allocators from
25055 components that don't explicitly allocate memory (e.g. pair), and adjust
25056 container interfaces to reflect this simplification.
25057 </p>
25058 <p>
25059 Components that I propose eliminating include HasAllocatorType,
25060 is_scoped_allocator, allocator_propagation_map, scoped_allocator_adaptor,
25061 and ConstructibleAsElement.
25062 </p>
25063 </blockquote>
25064
25065 <p>US 74.1:</p>
25066
25067 <blockquote>
25068 <p>
25069 Scoped allocators represent a poor trade-off for standardization, since
25070 (1) scoped-allocator--aware containers can be implemented outside the
25071 C++ standard library but used with its algorithms, (2) scoped
25072 allocators only benefit a tiny proportion of the C++ community
25073 (since few C++ programmers even use today's allocators), and (3) all C++
25074 users, especially the vast majority of the C++ community that won't ever
25075 use scoped allocators are forced to cope with the interface complexity
25076 introduced by scoped allocators.
25077 </p>
25078 <p>
25079 In essence, the larger community will suffer to support a very small
25080 subset of the community who can already implement their own
25081 data structures outside of the standard library. Therefore, scoped
25082 allocators should be removed from the working paper.
25083 </p>
25084 <p>
25085 Some evidence of the complexity introduced by scoped allocators:
25086 </p>
25087 <blockquote>
25088 <p>
25089 20.3.3 [pairs], 20.5 [tuple]: Large increase in the
25090 number of pair and tuple constructors.
25091 </p>
25092 <p>
25093 23 [containers]: Confusing "AllocatableElement" requirements throughout.
25094 </p>
25095 </blockquote>
25096 <p>Suggested resolution:</p>
25097
25098 <p>
25099 Remove support for scoped allocators from the working paper. This
25100 includes at least the following changes:
25101 </p>
25102
25103 <blockquote>
25104 <p>
25105 Remove 20.8.3 [allocator.element.concepts]
25106 </p>
25107 <p>
25108 Remove 20.8.5 [allocator.adaptor]
25109 </p>
25110 <p>
25111 Remove  [construct.element]
25112 </p>
25113 <p>
25114 In Clause 23 [containers]: replace requirements naming the
25115 <tt>AllocatableElement</tt> concept with requirements naming <tt>CopyConstructible</tt>,
25116 <tt>MoveConstructible</tt>, <tt>DefaultConstructible</tt>, or <tt>Constructible</tt>, as
25117 appropriate.
25118 </p>
25119 </blockquote>
25120
25121 </blockquote>
25122
25123 <p><i>[
25124 Post Summit Alan moved from NAD to Open.
25125 ]</i></p>
25126
25127
25128 <p><i>[
25129 2009-05-15 Ganesh adds:
25130 ]</i></p>
25131
25132
25133 <blockquote>
25134 <p>
25135 The requirement <tt>AllocatableElement</tt> should not be replaced with
25136 <tt>Constructible</tt> on the <tt>emplace_xxx()</tt> functions as suggested. In the
25137 one-parameter case the <tt>Constructible</tt> requirement is not satisfied when
25138 the constructor is explicit (as per 14.10.2.1 [concept.map.fct], twelfth
25139 bullet) but we do want to allow explicit constructors in emplace, as the
25140 following example shows:
25141 </p>
25142
25143 <blockquote><pre>vector&lt;shared_ptr&lt;int&gt;&gt; v;
25144 v.emplace_back(new int); <font color="#c80000">// should be allowed</font>
25145 </pre></blockquote>
25146
25147 <p>
25148 If the issue is accepted and scoped allocators are removed, I suggest to
25149 add a new pair of concepts to 20.2.7 [concept.construct], namely:
25150 </p>
25151
25152 <blockquote><pre>auto concept HasExplicitConstructor&lt;typename T, typename... Args&gt; {
25153  explicit T::T(Args...);
25154 }
25155
25156 auto concept ExplicitConstructible&lt;typename T, typename... Args&gt;
25157  : HasExplicitConstructor&lt;T, Args...&gt;, NothrowDestructible&lt;T&gt;
25158 { }
25159 </pre></blockquote>
25160
25161 <p>
25162 We should then use <tt>ExplicitConstructible</tt> as the requirement for all
25163 <tt>emplace_xxx()</tt> member functions.
25164 </p>
25165 <p>
25166 For coherence and consistency with the similar concepts
25167 <tt>Convertible/ExplicitlyConvertible</tt>, we might also consider changing
25168 <tt>Constructible</tt> to:
25169 </p>
25170
25171 <blockquote><pre>auto concept Constructible&lt;typename T, typename... Args&gt;
25172  : HasConstructor&lt;T, Args...&gt;, ExplicitConstructible&lt;T, Args...&gt;
25173 { }
25174 </pre></blockquote>
25175
25176 <p>
25177 Moreover, all emplace-related concepts in 23.2.6 [container.concepts]
25178 should also use <tt>ExplicitConstructible</tt> instead of <tt>Constructible</tt> in the
25179 definitions of their axioms. In fact the concepts in 23.2.6 [container.concepts] should be
25180 corrected even if the issue is not accepted.
25181 </p>
25182 <p>
25183 On the other hand, if the issue is not accepted, the scoped allocator
25184 adaptors should be fixed because the following code:
25185 </p>
25186
25187 <blockquote><pre>template &lt;typename T&gt; using scoped_allocator = scoped_allocator_adaptor&lt;allocator&lt;T&gt;&gt;;
25188
25189 vector&lt;shared_ptr&lt;int&gt;, scoped_allocator&lt;shared_ptr&lt;int&gt;&gt;&gt; v;
25190 v.emplace_back(new int); <font color="#c80000">// ops! doesn't compile</font>
25191 </pre></blockquote>
25192
25193 <p>
25194 doesn't compile, as the member function <tt>construct()</tt> of the scoped
25195 allocator requires non-explicit constructors through concept
25196 <tt>ConstructibleWithAllocator</tt>. Fixing that is not difficult but probably
25197 more work than it's worth and is therefore, IMHO, one more reason in
25198 support of the complete removal of scoped allocators.
25199 </p>
25200 </blockquote>
25201
25202 <p><i>[
25203 2009-06-09 Alan adds:
25204 ]</i></p>
25205
25206
25207 <blockquote>
25208 <p>
25209 I reopened this issue because I did not think that these National Body
25210 comments were adequately addressed by marking them NAD. My understanding
25211 is that something can be marked NAD if it is clearly a misunderstanding
25212 or trivial, but a substantive issue that has any technical merit
25213 requires a disposition that addresses the concerns.
25214 </p>
25215 <p>
25216 The notes in the NB comment list (US 65 &amp; US 74.1) say that:
25217 </p>
25218 <ol type="a">
25219 <li>
25220 this issue has not introduced any new arguments not previously discussed,
25221 </li>
25222 <li>
25223 the vote (4-9-3) was not a consensus for removing scoped allocators,
25224 </li>
25225 <li>
25226 the issue is resolved by
25227 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">N2840</a>.
25228 </li>
25229 </ol>
25230 <p>
25231 My opinion is:
25232 </p>
25233 <ol type="a">
25234 <li>
25235 there are new arguments in both comments regarding concepts (which were
25236 not present in the library when the scoped allocator proposal was voted
25237 in),
25238 </li>
25239 <li>
25240 the vote was clearly not a consensus for removal, but just saying there
25241 was a vote does not provide a rationale,
25242 </li>
25243 <li>
25244 I do not believe that N2840 addresses these comments (although it does
25245 many other things and was voted in with strong approval).
25246 </li>
25247 </ol>
25248
25249 <p>
25250 My motivation to open the issue was to ensure that the NB comments were
25251 adequately addressed in a way that would not risk a "no" vote on our
25252 FCD. If there are responses to the technical concerns raised, then
25253 perhaps they should be recorded. If the members of the NB who authored
25254 the comments are satisfied with N2840 and the other disposition remarks
25255 in the comment list, then I am sure they will say so. In either case,
25256 this issue can be closed very quickly in Frankfurt, and hopefully will
25257 have helped make us more confident of approval with little effort. If in
25258 fact there is controversy, my thought is that it is better to know now
25259 rather than later so there is more time to deal with it.
25260 </p>
25261 </blockquote>
25262
25263
25264
25265 <p><b>Proposed resolution:</b></p>
25266
25267
25268
25269
25270
25271 <hr>
25272 <h3><a name="1076"></a>1076. unary/binary_negate need constraining and move support</h3>
25273 <p><b>Section:</b> 20.7.11 [negators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
25274  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-20  <b>Last modified:</b> 2009-05-23</p>
25275 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
25276 <p><b>Discussion:</b></p>
25277 <p>
25278 The class templates <tt>unary/binary_negate</tt> need constraining and move support.
25279 </p>
25280 <p>
25281 Ideally these classes would be deprecated, allowing <tt>unary/binary_function</tt> to
25282 also be deprecated.  However, until a generic negate adaptor is introduced
25283 that can negate any <tt>Callable</tt> type, they must be supported so should be
25284 constrained.  Likewise, they should be movable, and support adopting a
25285 move-only predicate type.
25286 </p>
25287 <p>
25288 In order to preserve ABI compatibility, new rvalue overloads are supplied in
25289 preference to changing the existing pass-by-const-ref to pass-by-value.
25290 </p>
25291 <p>
25292 Do not consider the issue of forwarding mutable lvalues at this point,
25293 although remain open to another issue on the topic.
25294 </p>
25295
25296 <p><i>[
25297 2009-05-01 Daniel adds:
25298 ]</i></p>
25299
25300 <blockquote>
25301 <p>
25302 IMO the currently proposed resolution needs some updates
25303 because it is ill-formed at several places:
25304 </p>
25305
25306 <ol>
25307 <li>
25308 <p>
25309 In concept AdaptableUnaryFunction change
25310 </p>
25311 <blockquote><pre>typename X::result_type;
25312 typename X::argument_type;
25313 </pre></blockquote>
25314 <p>
25315 to
25316 </p>
25317 <blockquote><pre>Returnable result_type = typename X::result_type;
25318 typename argument_type = typename X::argument_type;
25319 </pre></blockquote>
25320 <p>
25321 [The replacement "Returnable result_type" instead of "typename
25322 result_type" is non-editorial, but maybe you prefer that as well]
25323 </p>
25324 </li>
25325 <li>
25326 <p>
25327 In concept AdaptableBinaryFunction change
25328 </p>
25329 <blockquote><pre>typename X::result_type;
25330 typename X::first_argument_type;
25331 typename X::second_argument_type;
25332 </pre></blockquote>
25333 <p>
25334 to
25335 </p>
25336 <blockquote><pre>Returnable result_type = typename X::result_type;
25337 typename first_argument_type = typename X::first_argument_type;
25338 typename second_argument_type = typename X::second_argument_type;
25339 </pre></blockquote>
25340 <p>
25341 [The replacement "Returnable result_type" instead of "typename
25342 result_type" is non-editorial, but maybe you prefer that as well.]
25343 </p>
25344 </li>
25345
25346 <li>
25347 <p>
25348 In class unary/binary_function
25349 </p>
25350 <ol type="a">
25351 <li>
25352 I suggest to change "ReturnType" to "Returnable" in both cases.
25353 </li>
25354 <li>
25355 I think you want to replace the remaining occurrences of "Predicate" by "P"
25356 (in both classes in copy/move from a predicate)
25357 </li>
25358 </ol>
25359 </li>
25360 <li>
25361 <p>
25362 I think you need to change the proposed signatures of not1 and not2, because
25363 they would still remain unconstrained: To make them constrained at least a
25364 single requirement needs to be added to enable requirement implication. This
25365 could be done via a dummy ("requires True&lt;true&gt;") or just explicit as follows:
25366 </p>
25367 <ol type="a">
25368 <li>
25369 <blockquote><pre>template &lt;AdaptableUnaryFunction P&gt;
25370 requires Predicate&lt; P, P::argument_type&gt;
25371 unary_negate&lt;P&gt; not1(const P&amp;&amp; pred);
25372 template &lt;AdaptableUnaryFunction P&gt;
25373 requires Predicate&lt; P, P::argument_type &gt;
25374 unary_negate&lt;P&gt; not1(P&amp;&amp; pred);
25375 </pre>
25376 <blockquote>
25377 -3- Returns: unary_negate&lt;P&gt;(pred).
25378 </blockquote>
25379 </blockquote>
25380 <p>
25381 [Don't we want a move call for the second overload as in
25382 </p>
25383 <blockquote><pre>unary_negate&lt;P&gt;(std::move(pred))
25384 </pre></blockquote>
25385 <p>
25386 in the Returns clause ?]
25387 </p>
25388 </li>
25389 <li>
25390 <pre>template &lt;AdaptableBinaryFunction P&gt;
25391 requires Predicate&lt; P, P::first_argument_type, P::second_argument_type &gt;
25392 binary_negate&lt;P&gt; not2(const P&amp; pred);
25393 template &lt;AdaptableBinaryFunction P&gt;
25394 requires Predicate&lt; P, P::first_argument_type, P::second_argument_type &gt;
25395 binary_negate&lt;P&gt; not2(P&amp;&amp; pred);
25396 </pre>
25397 <p>
25398 -5- Returns: binary_negate&lt;P&gt;(pred).
25399 </p>
25400 <p>
25401 [Don't we want a move call for the second overload as in
25402 </p>
25403 <blockquote><pre>binary_negate&lt;P&gt;(std::move(pred))
25404 </pre></blockquote>
25405 <p>
25406 in the Returns clause ?]
25407 </p>
25408 </li>
25409 </ol>
25410 </li>
25411 </ol>
25412 </blockquote>
25413
25414 <p><i>[
25415 Batavia (2009-05):
25416 ]</i></p>
25417
25418 <blockquote>
25419 <p>
25420 There is concern that complicating the solution
25421 to preserve the ABI seems unnecessary,
25422 since we're not in general preserving the ABI.
25423 </p>
25424 <p>
25425 We would prefer a separate paper consolidating all Clause 20
25426 issues that are for the purpose of providing constrained versions
25427 of the existing facilities.
25428 </p>
25429 <p>
25430 Move to Open.
25431 </p>
25432 </blockquote>
25433
25434
25435 <p><b>Proposed resolution:</b></p>
25436 <p>
25437 Add new concepts where appropriate::
25438 </p>
25439
25440 <blockquote><pre>auto concept AdaptableUnaryFunction&lt; typename X &gt; {
25441   typename X::result_type;
25442   typename X::argument_type;
25443 }
25444
25445 auto concept AdaptableBinaryFunction&lt; typename X &gt; {
25446   typename X::result_type;
25447   typename X::first_argument_type;
25448   typename X::second_argument_type;
25449 }
25450 </pre></blockquote>
25451
25452 <p>
25453 Revise as follows:
25454 </p>
25455
25456 <p>
25457 Base 20.7.3 [base] (Only change is constrained Result)
25458 </p>
25459
25460 <blockquote>
25461 <p>
25462 -1-  The following classes are provided to simplify the typedefs of the
25463 argument and result types:
25464 </p>
25465 <pre>namespace std {
25466   template &lt;class Arg, <del>class</del> <ins>ReturnType</ins> Result&gt;
25467   struct unary_function {
25468      typedef Arg    argument_type;
25469      typedef Result result_type;
25470   };
25471
25472   template &lt;class Arg1, class Arg2, <del>class</del> <ins>ReturnType</ins> Result&gt;
25473   struct binary_function {
25474      typedef Arg1   first_argument_type;
25475      typedef Arg2   second_argument_type;
25476      typedef Result result_type;
25477   };
25478 }
25479 </pre></blockquote>
25480
25481 <p>
25482 Negators 20.7.11 [negators]:
25483 </p>
25484
25485 <blockquote>
25486 <p>
25487 -1- Negators <tt>not1</tt> and <tt>not2</tt> take a unary and a binary predicate,
25488 respectively, and return their complements (5.3.1).
25489 </p>
25490
25491 <pre>template &lt;<del>class</del> <ins>AdaptableUnaryFunction</ins> P<del>redicate</del>&gt;
25492   <ins>requires Predicate&lt; P, P::argument_type &gt;</ins>
25493   class unary_negate
25494     : public unary_function&lt;<del>typename</del> P<del>redicate</del>::argument_type,bool&gt; {
25495   public:
25496     <ins>unary_negate(const unary_negate &amp; ) = default;</ins>
25497     <ins>unary_negate(unary_negate &amp;&amp; );</ins>
25498
25499     <ins>requires CopyConstructible&lt; P &gt;</ins>
25500        explicit unary_negate(const Predicate&amp; pred);
25501     <ins>requires MoveConstructible&lt; P &gt;
25502        explicit unary_negate(Predicate &amp;&amp; pred);</ins>
25503
25504     bool operator()(const <del>typename</del> P<del>redicate</del>::argument_type&amp; x) const;
25505   };
25506 </pre>
25507 <blockquote>
25508 -2 <tt>operator()</tt> returns <tt>!pred(x)</tt>.
25509 </blockquote>
25510
25511 <pre>template &lt;class Predicate&gt;
25512   unary_negate&lt;Predicate&gt; not1(const Predicate&amp;amp; pred);
25513 <ins>template &lt;class Predicate&gt;
25514   unary_negate&lt;Predicate&gt; not1(Predicate&amp;&amp; pred);</ins>
25515 </pre>
25516 <blockquote>
25517 -3-  <i>Returns:</i> <tt>unary_negate&lt;Predicate&gt;(pred)</tt>.
25518 </blockquote>
25519
25520 <pre>template &lt;<del>class</del> <ins>AdaptableBinaryFunction</ins> P<del>redicate</del> &gt;
25521   <ins>requires Predicate&lt; P, P::first_argument_type, P::second_argument_type &gt;</ins>
25522   class binary_negate
25523     : public binary_function&lt;<del>typename</del> P<del>redicate</del>::first_argument_type,
25524                               <del>typename</del> P<del>redicate</del>::second_argument_type, bool&gt; {
25525   public:
25526     <ins>biary_negate(const binary_negate &amp; ) = default;</ins>
25527     <ins>binary_negate(binary_negate &amp;&amp; );</ins>
25528
25529     <ins>requires CopyConstructible&lt; P &gt;</ins>
25530        explicit binary_negate(const Predicate&amp; pred);
25531     <ins>requires MoveConstructible&lt; P &gt;
25532        explicit binary_negate(const Predicate&amp; pred);</ins>
25533
25534     bool operator()(const <del>typename</del> P<del>redicate</del>::first_argument_type&amp; x,
25535                     const <del>typename</del> P<del>redicate</del>::second_argument_type&amp; y) const;
25536   };
25537 </pre>
25538 <blockquote>
25539 -4- <tt>operator()</tt> returns <tt>!pred(x,y)</tt>.
25540 </blockquote>
25541
25542 <pre>template &lt;class Predicate&gt;
25543   binary_negate&lt;Predicate&gt; not2(const Predicate&amp; pred);
25544 <ins>template &lt;class Predicate&gt;
25545   binary_negate&lt;Predicate&gt; not2(Predicate&amp;&amp; pred);</ins>
25546 </pre>
25547
25548 <blockquote>
25549 -5- <i>Returns:</i> <tt>binary_negate&lt;Predicate&gt;(pred)</tt>.
25550 </blockquote>
25551 </blockquote>
25552
25553
25554
25555
25556
25557
25558 <hr>
25559 <h3><a name="1079"></a>1079. UK-265: <code>RandomAccessIterator</code>'s <code>operator-</code> has nonsensical effects clause</h3>
25560 <p><b>Section:</b> 24.2.6 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
25561  <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2009-03-20  <b>Last modified:</b> 2009-03-22</p>
25562 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#random.access.iterators">active issues</a> in [random.access.iterators].</p>
25563 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#random.access.iterators">issues</a> in [random.access.iterators].</p>
25564 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
25565 <p><b>Discussion:</b></p>
25566 <p><b>Addresses UK 265</b></p>
25567
25568 <p>UK-265:</p>
25569 <p>
25570 This effects clause is nonesense. It looks more like an axiom stating
25571 equivalence, and certainly an effects clause cannot change the state of
25572 two arguments passed by const reference
25573 </p>
25574
25575
25576
25577 <p><b>Proposed resolution:</b></p>
25578
25579 <p>Modify 24.2.6 [random.access.iterators]p7-9 as follows:</p>
25580
25581 <blockquote><pre>difference_type operator-(const X&amp; a, const X&amp; b);
25582 </pre>
25583 <ol start="7">
25584   <li><i>Precondition</i>: there exists a value <code>n</code> of
25585   <code>difference_type</code> such that <code>a == b + n</code>.</li>
25586   <li><del><i>Effects</i>: <code>b == a + (b - a)</code></del></li>
25587   <li><i>Returns</i>: <del><code>(a &lt; b) ? distance(a,b) :
25588   -distance(b,a)</code></del><ins><code>n</code></ins></li>
25589 </ol>
25590 </blockquote>
25591
25592
25593
25594
25595
25596 <hr>
25597 <h3><a name="1088"></a>1088. Response to UK 342</h3>
25598 <p><b>Section:</b> 30.6.4 [futures.promise] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
25599  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22  <b>Last modified:</b> 2009-03-22</p>
25600 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
25601 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.promise">issues</a> in [futures.promise].</p>
25602 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
25603 <p><b>Discussion:</b></p>
25604 <p><b>Addresses UK 342</b></p>
25605
25606 <p>
25607 <tt>std::promise</tt> is missing a non-member overload of <tt>swap</tt>. This is
25608 inconsistent with other types that provide a <tt>swap</tt> member function.
25609 </p>
25610
25611 <p>
25612 Add a non-member overload <tt>void swap(promise&amp;&amp; x,promise&amp;&amp; y){ x.swap(y); }</tt>
25613 </p>
25614
25615 <p><i>[
25616 Summit:
25617 ]</i></p>
25618
25619 <blockquote>
25620 Create an issue. Move to review, attention: Howard. Detlef will also
25621 look into it.
25622 </blockquote>
25623
25624 <p><i>[
25625 Post Summit Daniel provided wording.
25626 ]</i></p>
25627
25628
25629
25630 <p><b>Proposed resolution:</b></p>
25631 <ol>
25632 <li>
25633 <p>
25634 In 30.6.4 [futures.promise], before p.1, immediately after class template
25635 promise add:
25636 </p>
25637 <blockquote><pre><ins>
25638 template &lt;class R&gt;
25639 void swap(promise&lt;R&gt;&amp; x, promise&lt;R&gt;&amp; y);
25640 </ins>
25641 </pre></blockquote>
25642 </li>
25643 <li>
25644 <p>
25645 Change 30.6.4 [futures.promise]/10 as indicated (to fix a circular definition):
25646 </p>
25647 <blockquote>
25648 <p>
25649 -10- <i>Effects:</i> <del>swap(*this, other)</del><ins>Swaps the associated state
25650 of <tt>*this</tt> and <tt>other</tt></ins>
25651 </p>
25652 <p>
25653 <ins><i>Throws:</i> Nothing.</ins>
25654 </p>
25655 </blockquote>
25656 </li>
25657 <li>
25658 <p>
25659 After the last paragraph in 30.6.4 [futures.promise] add the following
25660 prototype description:
25661 </p>
25662 <blockquote><pre><ins>
25663 template &lt;class R&gt;
25664 void swap(promise&lt;R&gt;&amp; x, promise&lt;R&gt;&amp; y);
25665 </ins></pre>
25666 <blockquote>
25667 <p>
25668 <ins><i>Effects:</i> <tt>x.swap(y)</tt></ins>
25669 </p>
25670 <p>
25671 <ins><i>Throws:</i> Nothing.</ins>
25672 </p>
25673 </blockquote>
25674 </blockquote>
25675 </li>
25676
25677 </ol>
25678
25679
25680
25681
25682
25683
25684 <hr>
25685 <h3><a name="1089"></a>1089. Response to JP 76</h3>
25686 <p><b>Section:</b> 30 [thread] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
25687  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22  <b>Last modified:</b> 2009-08-02</p>
25688 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread">issues</a> in [thread].</p>
25689 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
25690 <p><b>Discussion:</b></p>
25691 <p><b>Addresses JP 76</b></p>
25692
25693 <p>
25694 A description for "Throws: Nothing." are not unified.
25695 </p>
25696
25697 <p>
25698 At the part without throw, "Throws: Nothing." should be described.
25699 </p>
25700
25701 <p>
25702 Add "Throws: Nothing." to the following.
25703 </p>
25704
25705 <ul>
25706 <li>
25707 30.3.1.6 [thread.thread.static] p1
25708 </li>
25709 <li>
25710 30.4.3.1 [thread.lock.guard] p4
25711 </li>
25712 <li>
25713 30.4.3.2.1 [thread.lock.unique.cons] p6
25714 </li>
25715 <li>
25716 30.5.1 [thread.condition.condvar] p7 and p8
25717 </li>
25718 <li>
25719 30.5.2 [thread.condition.condvarany] p6, p7, p19, p21 and p25
25720 </li>
25721 </ul>
25722
25723 <p><i>[
25724 Summit:
25725 ]</i></p>
25726
25727 <blockquote>
25728 Pass on to editor.
25729 </blockquote>
25730
25731 <p><i>[
25732 Post Summit:  Editor declares this non-editorial.
25733 ]</i></p>
25734
25735
25736 <p><i>[
25737 2009-08-01 Howard provided wording:
25738 ]</i></p>
25739
25740
25741 <blockquote>
25742
25743 <p>
25744 The definition of "<i>Throws:</i> Nothing." that I added is probably going to
25745 be controversial, but I beg you to consider it seriously.
25746 </p>
25747
25748 <blockquote>
25749 <p>
25750 In C++ there are three "flow control" options for a function:
25751 </p>
25752
25753 <ol>
25754 <li>
25755 It can return, either with a value, or with <tt>void</tt>.
25756 </li>
25757 <li>
25758 It can call a function which never returns, such as <tt>std::exit</tt> or
25759 <tt>std::terminate</tt>.
25760 </li>
25761 <li>
25762 It can throw an exception.
25763 </li>
25764 </ol>
25765
25766 The above list can be abbreviated with:
25767
25768 <ol>
25769 <li><b>R</b>eturns.</li>
25770 <li><b>E</b>nds program.</li>
25771 <li><b>T</b>hrows exception.</li>
25772 </ol>
25773
25774 <p>
25775 In general a function can have the behavior of any of these 3, or any combination
25776 of any of these three, depending upon run time data.
25777 </p>
25778
25779 <ol>
25780 <li><b>R</b></li>
25781 <li><b>E</b></li>
25782 <li><b>T</b></li>
25783 <li><b>RE</b></li>
25784 <li><b>RT</b></li>
25785 <li><b>ET</b></li>
25786 <li><b>RET</b></li>
25787 </ol>
25788
25789 <p>
25790 A function with no throw spec, and no documentation, is in general a <b>RET</b>
25791 function.  It may return, it may end the program, or it may throw.  When we
25792 specify a function with an empty throw spec:
25793 </p>
25794
25795 <blockquote><pre>void f() throw();
25796 </pre></blockquote>
25797
25798 <p>
25799 We are saying that <tt>f()</tt> is an <b>RE</b> function:  It may return or end
25800 the program, but it will not throw.
25801 </p>
25802
25803 <p>
25804 I posit that there are very few places in the library half of the standard
25805 where we intend for functions to be able to end the program (call <tt>terminate</tt>).
25806 And none of those places where we do say <tt>terminate</tt> could be called,
25807 do we currently say "<i>Throws:</i> Nothing.".
25808 </p>
25809
25810 <p>
25811 I believe that if we define "<i>Throws:</i> Nothing." to mean <b>R</b>,
25812 we will both clarify many, many places in the standard, <em>and</em> give us a
25813 good rationale for choosing between "<i>Throws:</i> Nothing." (<b>R</b>)
25814 and <tt>throw()</tt> (<b>RE</b>) in the future.  Indeed, this may give us motivation
25815 to change several <tt>throw()</tt>s to "<i>Throws:</i> Nothing.".
25816 </p>
25817 </blockquote>
25818
25819 <p>
25820 I did not add the following changes as JP 76 requested as I believe we want to
25821 allow these functions to throw:
25822 </p>
25823
25824 <blockquote>
25825 <p>
25826 Add a paragraph under 30.4.3.1 [thread.lock.guard] p4:
25827 </p>
25828
25829 <blockquote><pre>explicit lock_guard(mutex_type&amp; m);
25830 </pre>
25831
25832 <p><ins>
25833 <i>Throws:</i> Nothing.
25834 </ins></p>
25835 </blockquote>
25836
25837 <p>
25838 Add a paragraph under 30.4.3.2.1 [thread.lock.unique.cons] p6:
25839 </p>
25840
25841 <blockquote><pre>explicit unique_lock(mutex_type&amp; m);
25842 </pre>
25843
25844 <p><ins>
25845 <i>Throws:</i> Nothing.
25846 </ins></p>
25847 </blockquote>
25848
25849 <p>
25850 Add a paragraph under 30.5.2 [thread.condition.condvarany] p19, p21 and p25:
25851 </p>
25852
25853 <blockquote><pre>template &lt;class Lock, class Rep, class Period&gt;
25854   bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time);
25855 </pre>
25856
25857 <p><ins>
25858 <i>Throws:</i> Nothing.
25859 </ins></p>
25860 </blockquote>
25861
25862 <blockquote><pre>template &lt;class Lock, class Duration, class Predicate&gt;
25863   bool wait_until(Lock&amp; lock, const chrono::time_point&lt;Clock, Duration&gt;&amp; rel_time, Predicate pred);
25864 </pre>
25865
25866 <p><ins>
25867 <i>Throws:</i> Nothing.
25868 </ins></p>
25869 </blockquote>
25870
25871 <blockquote><pre>template &lt;class Lock, class Rep, class Period, class Predicate&gt;
25872   bool wait_for(Lock&amp; lock, const chrono::duration&lt;Rep, Period&gt;&amp; rel_time, Predicate pred);
25873 </pre>
25874
25875 <p><ins>
25876 <i>Throws:</i> Nothing.
25877 </ins></p>
25878 </blockquote>
25879
25880 </blockquote>
25881
25882 </blockquote>
25883
25884
25885
25886
25887
25888 <p><b>Proposed resolution:</b></p>
25889 <p>
25890 Add a paragraph after 17.5.1.4 [structure.specifications] p4:
25891 </p>
25892
25893 <blockquote>
25894 <p>
25895 -3- Descriptions of function semantics contain the following elements
25896 (as appropriate):<sup>158</sup>
25897 </p>
25898 <ul>
25899 <li>...</li>
25900 <li>
25901 <i>Throws:</i> any exceptions thrown by the function, and the conditions
25902 that would cause the exception
25903 </li>
25904 <li>...</li>
25905 </ul>
25906
25907 <p>
25908 -4- For non-reserved replacement and handler functions, ...
25909 </p>
25910
25911 <p><ins>
25912 A "<i>Throws:</i> Nothing." element indicates that the function shall
25913 return ordinarily, and not via an exception.  This element also
25914 indicates that the function <em>shall</em> return. [<i>Note:</i> This
25915 differs from an empty throw specification which may cause a function to
25916 call <tt>unexpected</tt> and subsequently <tt>terminate</tt>. &#8212;
25917 <i>end note</i>]
25918 </ins></p>
25919 </blockquote>
25920
25921 <p>
25922 Add a paragraph under 30.3.1.6 [thread.thread.static] p1:
25923 </p>
25924
25925 <blockquote><pre>unsigned hardware_concurrency();
25926 </pre>
25927
25928 <p>
25929 -1- <i>Returns:</i> ...
25930 </p>
25931
25932 <p><ins>
25933 <i>Throws:</i> Nothing.
25934 </ins></p>
25935 </blockquote>
25936
25937 <p>
25938 Add a paragraph under 30.5.1 [thread.condition.condvar] p7 and p8:
25939 </p>
25940
25941 <blockquote>
25942 <p>
25943 <i>[Informational, not to be incluced in the WP: The POSIX spec allows only:</i>
25944 </p>
25945 <dl>
25946 <dt><i>[EINVAL]</i></dt>
25947 <dd><i>The value <tt>cond</tt> does not refer to an initialized condition variable. &#8212; end informational]</i></dd>
25948 </dl>
25949
25950 <pre>void notify_one();
25951 </pre>
25952
25953 <p>
25954 -7- <i>Effects:</i> ...
25955 </p>
25956
25957 <p><ins>
25958 <i>Throws:</i> Nothing.
25959 </ins></p>
25960 </blockquote>
25961
25962 <blockquote><pre>void notify_all();
25963 </pre>
25964
25965 <p>
25966 -8- <i>Effects:</i> ...
25967 </p>
25968
25969 <p><ins>
25970 <i>Throws:</i> Nothing.
25971 </ins></p>
25972 </blockquote>
25973
25974
25975 <p>
25976 Add a paragraph under 30.5.2 [thread.condition.condvarany] p6 and p7:
25977 </p>
25978
25979 <blockquote>
25980 <pre>void notify_one();
25981 </pre>
25982
25983 <p>
25984 -6- <i>Effects:</i> ...
25985 </p>
25986
25987 <p><ins>
25988 <i>Throws:</i> Nothing.
25989 </ins></p>
25990 </blockquote>
25991
25992 <blockquote><pre>void notify_all();
25993 </pre>
25994
25995 <p>
25996 -7- <i>Effects:</i> ...
25997 </p>
25998
25999 <p><ins>
26000 <i>Throws:</i> Nothing.
26001 </ins></p>
26002 </blockquote>
26003
26004
26005
26006
26007
26008
26009
26010 <hr>
26011 <h3><a name="1090"></a>1090. Missing description of <tt>packaged_task</tt> member <tt>swap</tt>,  missing non-member <tt>swap</tt></h3>
26012 <p><b>Section:</b> 30.6.7 [futures.task] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
26013  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-03-22  <b>Last modified:</b> 2009-05-24</p>
26014 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
26015 <p><b>Discussion:</b></p>
26016 <p>
26017 Class template <tt>packaged_task</tt> in 30.6.7 [futures.task] shows a member <tt>swap</tt>
26018 declaration, but misses to
26019 document it's effects (No prototype provided). Further on this class
26020 misses to provide a non-member
26021 swap.
26022 </p>
26023
26024 <p><i>[
26025 Batavia (2009-05):
26026 ]</i></p>
26027
26028 <blockquote>
26029 <p>
26030 Alisdair notes that paragraph 2 of the proposed resolution has already been
26031 applied in the current Working Draft.
26032 </p>
26033 <p>
26034 We note a pending <tt>future</tt>-related paper by Detlef;
26035 we would like to wait for this paper before proceeding.
26036 </p>
26037 <p>
26038 Move to Open.
26039 </p>
26040 </blockquote>
26041
26042 <p><i>[
26043 2009-05-24 Daniel removed part 2 of the proposed resolution.
26044 ]</i></p>
26045
26046
26047
26048 <p><b>Proposed resolution:</b></p>
26049 <ol>
26050 <li>
26051 <p>
26052 In 30.6.7 [futures.task], immediately after the definition of class
26053 template packaged_task add:
26054 </p>
26055 <blockquote><pre><ins>
26056 template&lt;class R, class... Argtypes&gt;
26057 void swap(packaged_task&lt;R(ArgTypes...)&gt;&amp;, packaged_task&lt;R(ArgTypes...)&gt;&amp;);
26058 </ins>
26059 </pre></blockquote>
26060 </li>
26061 </ol>
26062
26063 <ol start="3">
26064 <li>
26065 <p>
26066 In 30.6.7 [futures.task], immediately after <tt>operator=</tt> prototype
26067 description (After p. 8) add:
26068 </p>
26069 <blockquote><pre><ins>void swap(packaged_task&amp; other);</ins>
26070 </pre>
26071 <blockquote>
26072 <p><ins>
26073 <i>Effects:</i> Swaps the associated state of <tt>*this</tt> and <tt>other</tt>.
26074 </ins></p>
26075 <p><ins>
26076 <i>Throws:</i> Nothing.
26077 </ins></p>
26078 </blockquote>
26079 </blockquote>
26080 </li>
26081 <li>
26082 <p>
26083 At the end of 30.6.7 [futures.task] (after p. 20), add add the following
26084 prototype description:
26085 </p>
26086
26087 <blockquote><pre><ins>
26088 template&lt;class R, class... Argtypes&gt;
26089 void swap(packaged_task&lt;R(ArgTypes...)&gt;&amp; x, packaged_task&lt;R(ArgTypes...)&gt;&amp; y);
26090 </ins></pre>
26091 <blockquote>
26092 <p><ins>
26093 <i>Effects:</i> <tt>x.swap(y)</tt>
26094 </ins></p>
26095 <p><ins>
26096 <i>Throws:</i> Nothing.
26097 </ins></p>
26098 </blockquote>
26099 </blockquote>
26100 </li>
26101 </ol>
26102
26103
26104
26105
26106
26107 <hr>
26108 <h3><a name="1091"></a>1091. Multimap description confusing</h3>
26109 <p><b>Section:</b> 23.4.2.2 [multimap.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
26110  <b>Submitter:</b> LWG <b>Opened:</b> 2009-03-22  <b>Last modified:</b> 2009-07-04</p>
26111 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
26112 <p><b>Discussion:</b></p>
26113
26114 <p><b>Addresses UK 246</b></p>
26115 <p>
26116 The content of this sub-clause is purely trying to describe in words the
26117 effect of the requires clauses on these operations, now that we have
26118 Concepts. As such, the description is more confusing than the signature
26119 itself. The semantic for these functions is adequately covered in the
26120 requirements tables in 23.2.4 [associative.reqmts].
26121 </p>
26122
26123 <p><i>[
26124 Beman adds:
26125 ]</i></p>
26126
26127
26128 <blockquote>
26129 Pete is clearly right that
26130 this one is technical rather than editorial.
26131 </blockquote>
26132
26133 <p><i>[
26134 Batavia (2009-05):
26135 ]</i></p>
26136
26137 <blockquote>
26138 <p>
26139 We agree with the proposed resolution.
26140 </p>
26141 <p>
26142 Move to Review.
26143 </p>
26144 </blockquote>
26145
26146
26147 <p><b>Proposed resolution:</b></p>
26148 <p>
26149 Strike 23.4.2.2 [multimap.modifiers] entirely
26150 (but do NOT strike these signatures from the class template definition!).
26151 </p>
26152
26153
26154
26155
26156
26157 <hr>
26158 <h3><a name="1093"></a>1093. Multiple definitions for random_shuffle algorithm</h3>
26159 <p><b>Section:</b> 25.4.12 [alg.random.shuffle] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
26160  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-22  <b>Last modified:</b> 2009-07-28</p>
26161 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.random.shuffle">issues</a> in [alg.random.shuffle].</p>
26162 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
26163 <p><b>Discussion:</b></p>
26164
26165 <p>
26166 There are a couple of issues with the declaration of the <tt>random_shuffle</tt>
26167 algorithm accepting a random number engine.
26168 </p>
26169
26170 <ol type="i">
26171 <li>
26172 The Iterators must be shuffle iterators, yet this requirement is missing.
26173 </li>
26174 <li>
26175 The <tt>RandomNumberEngine</tt> concept is now provided by the random number
26176 library
26177 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">n2836</a>)
26178 and the placeholder should be removed.
26179 </li>
26180 </ol>
26181
26182 <p><i>[
26183 2009-05-02 Daniel adds:
26184 ]</i></p>
26185
26186
26187 <blockquote>
26188 <p>
26189 this issue completes adding necessary requirement to the
26190 third new <tt>random_shuffle</tt> overload. The current suggestion is:
26191 </p>
26192
26193 <blockquote><pre>template&lt;RandomAccessIterator Iter, UniformRandomNumberGenerator Rand&gt;
26194 requires ShuffleIterator&lt;Iter&gt;
26195 void random_shuffle(Iter first, Iter last, Rand&amp;&amp; g);
26196 </pre></blockquote>
26197
26198 <p>
26199 IMO this is still insufficient and I suggest to add the requirement
26200 </p>
26201 <blockquote><pre>Convertible&lt;Rand::result_type, Iter::difference_type&gt;
26202 </pre></blockquote>
26203 <p>
26204 to the list (as the two other overloads already have).
26205 </p>
26206
26207 <p>
26208 Rationale:
26209 </p>
26210
26211 <blockquote>
26212 <p>
26213 Its true that this third overload is somewhat different from the remaining
26214 two. Nevertheless we know from <tt>UniformRandomNumberGenerator</tt>, that
26215 it's <tt>result_type</tt> is an integral type and that it satisfies
26216 <tt>UnsignedIntegralLike&lt;result_type&gt;</tt>.
26217 </p>
26218 <p>
26219 To realize it's designated task, the algorithm has to invoke the
26220 <tt>Callable</tt> aspect of <tt>g</tt> and needs to perform some algebra involving
26221 it's <tt>min()/max()</tt> limits to compute another index value that
26222 at this point is converted into <tt>Iter::difference_type</tt>. This is so,
26223 because 24.2.6 [random.access.iterators] uses this type as argument
26224 of it's algebraic operators. Alternatively consider the equivalent
26225 iterator algorithms in 24.4 [iterator.operations] with the same result.
26226 </p>
26227 <p>
26228 This argument leads us to the conclusion that we also need
26229 <tt>Convertible&lt;Rand::result_type, Iter::difference_type&gt;</tt> here.
26230 </p>
26231 </blockquote>
26232
26233 </blockquote>
26234
26235 <p><i>[
26236 Batavia (2009-05):
26237 ]</i></p>
26238
26239 <blockquote>
26240 <p>
26241 Alisdair notes that point (ii) has already been addressed.
26242 </p>
26243 <p>
26244 We agree with the proposed resolution to point (i)
26245 with Daniel's added requirement.
26246 </p>
26247 <p>
26248 Move to Review.
26249 </p>
26250 </blockquote>
26251
26252 <p><i>[
26253 2009-06-05 Daniel updated proposed wording as recommended in Batavia.
26254 ]</i></p>
26255
26256
26257 <p><i>[
26258 2009-07-28 Alisdair adds:
26259 ]</i></p>
26260
26261
26262 <blockquote>
26263 Revert to Open, with a note there is consensus on direction but the
26264 wording needs updating to reflect removal of concepts.
26265 </blockquote>
26266
26267
26268 <p><b>Proposed resolution:</b></p>
26269 <p>
26270 Change in 25.2 [algorithms.syn] and 25.4.12 [alg.random.shuffle]:
26271 </p>
26272
26273 <blockquote><pre><del>concept UniformRandomNumberGenerator&lt;typename Rand&gt; { }</del>
26274 template&lt;RandomAccessIterator Iter, UniformRandomNumberGenerator Rand&gt;
26275   <ins>requires ShuffleIterator&lt;Iter&gt; &amp;&amp;
26276   Convertible&lt;Rand::result_type, Iter::difference_type&gt;</ins>
26277   void random_shuffle(Iter first, Iter last, Rand&amp;&amp; g);
26278 </pre></blockquote>
26279
26280
26281
26282
26283
26284
26285 <hr>
26286 <h3><a name="1094"></a>1094. Response to JP 65 and JP 66</h3>
26287 <p><b>Section:</b> 27.5.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
26288  <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2009-03-24  <b>Last modified:</b> 2009-05-23</p>
26289 <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>
26290 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
26291 <p><b>Discussion:</b></p>
26292 <p><b>Addresses JP 65 and JP 66</b></p>
26293
26294 <p>
26295 Switch from "unspecified-bool-type" to "explicit operator bool() const".
26296 </p>
26297
26298 <p>
26299 Replace <tt>operator unspecified-bool-type() const;</tt>" with <tt>explicit operator bool() const;</tt>
26300 </p>
26301
26302 <p><i>[
26303 Batavia (2009-05):
26304 ]</i></p>
26305
26306 <blockquote>
26307 We agree with the proposed resolution.
26308 Move to Review.
26309 </blockquote>
26310
26311
26312 <p><b>Proposed resolution:</b></p>
26313 <p>
26314 Change the synopis in 27.5.4 [ios]:
26315 </p>
26316
26317 <blockquote><pre><ins>explicit</ins> operator <del><i>unspecified-bool-type</i></del> <ins>bool</ins>() const;
26318 </pre></blockquote>
26319
26320 <p>
26321 Change 27.5.4.3 [iostate.flags]:
26322 </p>
26323
26324 <blockquote><pre><ins>explicit</ins> operator <del><i>unspecified-bool-type</i></del> <ins>bool</ins>() const;
26325 </pre>
26326
26327 <blockquote>
26328 <p>
26329 -1- <i>Returns:</i> <ins><tt>!fail()</tt></ins> <del>If <tt>fail()</tt> then a value that will evaluate
26330 false in a boolean context; otherwise a value that will evaluate true in
26331 a boolean context. The value type returned shall not be convertible to
26332 int.</del>
26333 </p>
26334 <p>
26335 <del>[<i>Note:</i> This conversion can be used in contexts where a bool is expected
26336 (e.g., an <tt>if</tt> condition); however, implicit conversions (e.g.,
26337 to <tt>int</tt>) that can occur with <tt>bool</tt> are not allowed,
26338 eliminating some sources of user error. One possible implementation
26339 choice for this type is pointer-to-member. <i>-- end note</i>]</del>
26340 </p>
26341 </blockquote>
26342 </blockquote>
26343
26344
26345
26346
26347
26348
26349
26350 <hr>
26351 <h3><a name="1095"></a>1095. <i>Shared objects and the library</i> wording unclear</h3>
26352 <p><b>Section:</b> 17.6.3.10 [res.on.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
26353  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-03-27  <b>Last modified:</b> 2009-05-23</p>
26354 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
26355 <p><b>Discussion:</b></p>
26356 <p>
26357 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2775.htm">N2775</a>,
26358 <i>Small library thread-safety revisions</i>, among other changes, removed a note from
26359 17.6.3.10 [res.on.objects] that read:
26360 </p>
26361
26362 <blockquote>
26363 [<i>Note:</i> This prohibition against concurrent non-const access means that
26364 modifying an object of a standard library type shared between threads
26365 without using a locking mechanism may result in a data race. <i>--end note</i>.]
26366 </blockquote>
26367
26368 <p>
26369 That resulted in wording which is technically correct but can only be
26370 understood by reading the lengthy and complex 17.6.4.7 [res.on.data.races]
26371 Data race avoidance. This has the effect of making
26372 17.6.3.10 [res.on.objects] unclear, and has already resulted in a query
26373 to the LWG reflector. See c++std-lib-23194.
26374 </p>
26375
26376 <p><i>[
26377 Batavia (2009-05):
26378 ]</i></p>
26379
26380 <blockquote>
26381 <p>
26382 The proposed wording seems to need a bit of tweaking
26383 ("really bad idea" isn't quite up to standardese).
26384 We would like feedback
26385 as to whether the original Note's removal was intentional.
26386 </p>
26387 <p>
26388 Change the phrase "is a really bad idea"
26389 to "risks undefined behavior" and
26390 move to Review status.
26391 </p>
26392 </blockquote>
26393
26394
26395 <p><b>Proposed resolution:</b></p>
26396 <p>
26397 Change 17.6.3.10 [res.on.objects] as indicated:
26398 </p>
26399
26400 <blockquote>
26401 <p>
26402 The behavior of a program is undefined if calls to standard library
26403 functions from different threads may introduce a data race. The
26404 conditions under which this may occur are specified in 17.6.4.7.
26405 </p>
26406 <p><ins>
26407 [<i>Note:</i> Thus modifying an object of a standard library type shared between
26408 threads risks undefined behavior unless objects of the type are explicitly
26409 specified as being sharable without data races or the user supplies a
26410 locking mechanism. <i>--end note</i>]
26411 </ins></p>
26412 </blockquote>
26413
26414
26415
26416
26417
26418 <hr>
26419 <h3><a name="1097"></a>1097. #define __STDCPP_THREADS</h3>
26420 <p><b>Section:</b> 18.2 [support.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
26421  <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2009-04-03  <b>Last modified:</b> 2009-05-23</p>
26422 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.types">issues</a> in [support.types].</p>
26423 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
26424 <p><b>Discussion:</b></p>
26425 <p><b>Addresses DE 18</b></p>
26426
26427 <p>
26428 Freestanding implementations do not (necessarily) have
26429   support for multiple threads (see 1.10 [intro.multithread]).
26430   Applications and libraries may want to optimize for the
26431   absence of threads.  I therefore propose a preprocessor
26432   macro to indicate whether multiple threads can occur.
26433 </p>
26434
26435 <p>
26436 There is ample prior implementation experience for this
26437   feature with various spellings of the macro name.  For
26438   example, gcc implicitly defines <tt>_REENTRANT</tt>
26439   if multi-threading support is selected on the compiler
26440   command-line.
26441 </p>
26442
26443 <p>
26444 While this is submitted as a library issue, it may be more
26445   appropriate to add the macro in 16.8 cpp.predefined in the
26446   core language.
26447 </p>
26448
26449 <p>
26450 See also
26451 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2693.html">N2693</a>.
26452 </p>
26453
26454 <p><i>[
26455 Batavia (2009-05):
26456 ]</i></p>
26457
26458 <blockquote>
26459 <p>
26460 We agree with the issue, and believe it is properly a library issue.
26461 </p>
26462 <p>
26463 We prefer that the macro be conditionally defined
26464 as part of the <tt>&lt;thread&gt;</tt> header.
26465 </p>
26466 <p>
26467 Move to Review.
26468 </p>
26469 </blockquote>
26470
26471
26472 <p><b>Proposed resolution:</b></p>
26473 <p>
26474 Insert a new subsection before 18.2 [support.types], entitled
26475 "Feature Macros" (support.macros):
26476 </p>
26477 <blockquote>
26478 <p>
26479 The standard library defines the following macros; no explicit
26480 prior inclusion of any header file is necessary.
26481 </p>
26482 <blockquote>
26483 <dl>
26484 <dt><tt>__STDCPP_THREADS</tt></dt>
26485 <dd>
26486 The macro <tt>__STDCPP_THREADS</tt> shall be defined if and only if a
26487     program can have more than one thread of execution (1.10 [intro.multithread]).
26488 If the macro is defined, it shall have the same
26489     value as the predefined macro <tt>__cplusplus</tt> (16.8 [cpp.predefined]).
26490 </dd>
26491 </dl>
26492 </blockquote>
26493 </blockquote>
26494
26495
26496
26497
26498
26499
26500 <hr>
26501 <h3><a name="1098"></a>1098. definition of get_pointer_safety()</h3>
26502 <p><b>Section:</b> 20.8.10.7 [util.dynamic.safety] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
26503  <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2009-04-03  <b>Last modified:</b> 2009-05-23</p>
26504 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.dynamic.safety">issues</a> in [util.dynamic.safety].</p>
26505 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
26506 <p><b>Discussion:</b></p>
26507 <p><b>Addresses DE 18</b></p>
26508
26509 <p>
26510  In 20.8.10.7 [util.dynamic.safety], <tt>get_pointer_safety()</tt> purports
26511 to define behavior for
26512  non-safely derived pointers (3.7.4.3 [basic.stc.dynamic.safety]).  However,
26513  the cited core-language section in paragraph 4 specifies undefined behavior
26514  for the use of such pointer values.  This seems an unfortunate near-contradiction.
26515  I suggest to specify the term <i>relaxed pointer safety</i> in
26516  the core language section and refer to it from the library description.
26517  This issue deals with the library part, the corresponding core issue (c++std-core-13940)
26518  deals with the core modifications.
26519 </p>
26520
26521 <p>
26522 See also
26523 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2693.html">N2693</a>.
26524 </p>
26525
26526 <p><i>[
26527 Batavia (2009-05):
26528 ]</i></p>
26529
26530 <blockquote>
26531 <p>
26532 We recommend if this issue is to be moved,
26533 the issue be moved concurrently with the cited Core issue.
26534 </p>
26535 <p>
26536 We agree with the intent of the proposed resolution.
26537 We would like input from garbage collection specialists.
26538 </p>
26539 <p>
26540 Move to Open.
26541 </p>
26542 </blockquote>
26543
26544
26545
26546 <p><b>Proposed resolution:</b></p>
26547 <p>
26548 In 20.8.10.7 [util.dynamic.safety] p16, replace the description of
26549 <tt>get_pointer_safety()</tt> with:
26550 </p>
26551
26552 <blockquote>
26553 <p>
26554 <tt>pointer_safety get_pointer_safety();</tt>
26555 </p>
26556 <blockquote>
26557 <p>
26558 <del><i>Returns:</i> an enumeration value indicating the implementation's treatment
26559 of pointers that are not safely derived (3.7.4.3). Returns
26560 <tt>pointer_safety::relaxed</tt> if pointers that are not safely derived will be
26561 treated the same as pointers that are safely derived for the duration of
26562 the program. Returns <tt>pointer_safety::preferred</tt> if pointers that are not
26563 safely derived will be treated the same as pointers that are safely
26564 derived for the duration of the program but allows the implementation to
26565 hint that it could be desirable to avoid dereferencing pointers that are
26566 not safely derived as described. [<i>Example:</i> <tt>pointer_safety::preferred</tt>
26567 might be returned to detect if a leak detector is running to avoid
26568 spurious leak reports. -- <i>end note</i>] Returns <tt>pointer_safety::strict</tt> if
26569 pointers that are not safely derived might be treated differently than
26570 pointers that are safely derived.</del>
26571 </p>
26572 <p><ins>
26573 <i>Returns:</i> Returns <tt>pointer_safety::strict</tt> if the implementation has
26574    strict pointer safety (3.7.4.3 [basic.stc.dynamic.safety]). It is
26575    implementation-defined whether <tt>get_pointer_safety</tt> returns
26576    <tt>pointer_safety::relaxed</tt> or <tt>pointer_safety::preferred</tt> if the
26577    implementation has relaxed pointer safety
26578    (3.7.4.3 [basic.stc.dynamic.safety]).<sup>Footnote</sup>
26579 </ins></p>
26580
26581 <p><ins>
26582 <i>Throws:</i> nothing
26583 </ins></p>
26584
26585 <p><ins>
26586 Footnote) <tt>pointer_safety::preferred</tt> might be returned to indicate to the
26587    program that a leak detector is running so that the program can avoid
26588    spurious leak reports.
26589 </ins>
26590 </p>
26591
26592 </blockquote>
26593 </blockquote>
26594
26595
26596
26597
26598
26599 <hr>
26600 <h3><a name="1099"></a>1099. Various issues</h3>
26601 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
26602  <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-03-21  <b>Last modified:</b> 2009-05-23</p>
26603 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
26604 <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>
26605 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
26606 <p><b>Discussion:</b></p>
26607 <p>
26608 Notes
26609 </p>
26610 <blockquote>
26611 <p>
26612 [2009-03-21 Sat] p. 535 at the top we need MoveConstructible V1,
26613 MoveConstructible V2 (where V1,V2 are defined on 539).  Also make_tuple
26614 on 550
26615 </p>
26616 <p>
26617 [2009-03-21 Sat] p1183 thread ctor, and in general, we need a way to
26618 talk about "copiable from generalized rvalue ref argument" for cases
26619 where we're going to forward and copy.
26620 </p>
26621 <blockquote>
26622 <p>
26623    This issue may well be quite large.  Language in para 4 about "if
26624    an lvalue" is wrong because types aren't expressions.
26625 </p>
26626 <p>
26627    p1199, call_once has all the same issues.
26628 </p>
26629 </blockquote>
26630 <p>
26631 [2009-03-21 Sat] p869 InputIterator pointer type should not be required
26632 to be convertible to const value_type*, rather it needs to have a
26633 operator-&gt; of its own that can be used for the value type.
26634 </p>
26635 <p>
26636 [2009-03-21 Sat] p818 stack has the same problem with default ctor.
26637 </p>
26638 <p>
26639 [2009-03-21 Sat] p816 priority_queue has the same sorts of problems as queue, only more so
26640 </p>
26641 <blockquote><pre>   requires MoveConstructible&lt;Cont&gt;
26642      explicit priority_queue(const Compare&amp; x = Compare(), Cont&amp;&amp; = Cont());
26643 </pre>
26644 <p>
26645    Don't require MoveConstructible when default constructing Cont.
26646    Also missing semantics for move ctor.
26647 </p>
26648 </blockquote>
26649 <p>
26650  [2009-03-21 Sat] Why are Allocators required to be CopyConstructible as
26651  opposed to MoveConstructible?
26652 </p>
26653 <p>
26654  [2009-03-21 Sat] p813 queue needs a separate default ctor (Cont needn't
26655  be MoveConstructible).  No documented semantics for move c'tor.  Or
26656  *any* of its 7 ctors!
26657 </p>
26658 <p>
26659  [2009-03-21 Sat] std::array should have constructors for C++0x,
26660  consequently must consider move construction.
26661 </p>
26662
26663 <p><i>[
26664 2009-05-01 Daniel adds:
26665 ]</i></p>
26666
26667
26668 <blockquote>
26669 This could be done as part of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1035">1035</a>, which already handles
26670 deviation of <tt>std::array</tt> from container tables.
26671 </blockquote>
26672
26673 <p>
26674  [2009-03-21 Sat] p622 all messed up.
26675 </p>
26676 <blockquote>
26677 <p>
26678    para 8 "implementation-defined" is the wrong term; should be "see
26679    below" or something.
26680 </p>
26681 <p>
26682    para 12 "will be selected" doesn't make any sense because we're not
26683    talking about actual arg types.
26684 </p>
26685 <p>
26686    paras 9-13 need to be totally rewritten for concepts.
26687 </p>
26688 </blockquote>
26689
26690 <p>
26691  [2009-03-21 Sat] Null pointer comparisons (p587) have all become
26692  unconstrained.  Need to fix that
26693 </p>
26694 <p>
26695  [2009-03-21 Sat] mem_fun_t etc. definition doesn't match declaration.
26696   We think CopyConstructible is the right reqt.
26697 </p>
26698 <p>
26699  make_pair needs Constructible&lt;V1, T1&amp;&amp;&gt; requirements!
26700 </p>
26701 <p>
26702  make_tuple needs something similar
26703 </p>
26704 <p>
26705  tuple bug in synopsis:
26706 </p>
26707 <blockquote><pre>   template &lt;class... UTypes&gt;
26708    requires Constructible&lt;Types, const UTypes&amp;&gt;...
26709    template &lt;class... UTypes&gt;
26710    requires Constructible&lt;Types, RvalueOf&lt;UTypes&gt;::type&gt;...
26711 </pre>
26712 <p>
26713    Note: removal of MoveConstructible requirements in std::function makes
26714    these routines unconstrained!
26715 </p>
26716 </blockquote>
26717
26718 <p><i>[
26719 2009-05-02 Daniel adds:
26720 ]</i></p>
26721
26722
26723 <blockquote>
26724 This part of the issue is already covered by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1077">1077</a>.
26725 </blockquote>
26726
26727 <p>
26728  these unique_ptr constructors are broken [ I think this is covered in "p622 all messed up" ]
26729 </p>
26730 <blockquote><pre> unique_ptr(pointer p, implementation-defined d);
26731  unique_ptr(pointer p, implementation-defined d);
26732 </pre></blockquote>
26733 <p>
26734  multimap range constructor should not have MoveConstructible&lt;value_type&gt; requirement.
26735 </p>
26736 <blockquote>
26737    same with insert(..., P&amp;&amp;); multiset has the same issue, as do
26738    unordered_multiset and unordered_multimap. Review these!
26739 </blockquote>
26740
26741 </blockquote>
26742
26743 <p><i>[
26744 Batavia (2009-05):
26745 ]</i></p>
26746
26747 <blockquote>
26748 Move to Open, pending proposed wording from Dave for further review.
26749 </blockquote>
26750
26751
26752 <p><b>Proposed resolution:</b></p>
26753 <p>
26754 </p>
26755
26756
26757
26758
26759
26760 <hr>
26761 <h3><a name="1100"></a>1100. <tt>auto_ptr</tt> to <tt>unique_ptr</tt> conversion</h3>
26762 <p><b>Section:</b> 20.8.9.2.1 [unique.ptr.single.ctor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
26763  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-04-25  <b>Last modified:</b> 2009-08-01</p>
26764 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unique.ptr.single.ctor">active issues</a> in [unique.ptr.single.ctor].</p>
26765 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr.single.ctor">issues</a> in [unique.ptr.single.ctor].</p>
26766 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
26767 <p><b>Discussion:</b></p>
26768 <p>
26769 Message c++std-lib-23182 led to a discussion in which several people
26770 expressed interest in being able to convert an <tt>auto_ptr</tt> to a
26771 <tt>unique_ptr</tt> without the need to call <tt>release</tt>.  Below is
26772 wording to accomplish this.
26773 </p>
26774
26775 <p><i>[
26776 Batavia (2009-05):
26777 ]</i></p>
26778
26779 <blockquote>
26780 <p>
26781 Pete believes it not a good idea to separate parts of a class's definition.
26782 Therefore, if we do this,
26783 it should be part of <tt>unique-ptr</tt>'s specification.
26784 </p>
26785 <p>
26786 Alisdair believes the lvalue overload may be not necessary.
26787 </p>
26788 <p>
26789 Marc believes it is more than just sugar,
26790 as it does ease the transition to <tt>unique-ptr</tt>.
26791 </p>
26792 <p>
26793 We agree with the resolution as presented.
26794 Move to Tentatively Ready.
26795 </p>
26796 </blockquote>
26797
26798 <p><i>[
26799 2009-07 Frankfurt
26800 ]</i></p>
26801
26802
26803 <blockquote>
26804 Moved from Tentatively Ready to Open only because the wording needs to be
26805 tweaked for concepts removal.
26806 </blockquote>
26807
26808 <p><i>[
26809 2009-08-01 Howard deconceptifies wording:
26810 ]</i></p>
26811
26812
26813 <blockquote>
26814 I also moved the change from D.9 [depr.auto.ptr]
26815 to 20.8.9.2 [unique.ptr.single] per the Editor's request
26816 in Batavia (as long as I was making changes anyway).  Set back
26817 to Review.
26818 </blockquote>
26819
26820
26821
26822 <p><b>Proposed resolution:</b></p>
26823 <p>
26824 Add to 20.8.9.2 [unique.ptr.single]:
26825 </p>
26826
26827 <blockquote><pre>template &lt;class T, class D&gt;
26828 class unique_ptr
26829 {
26830 public:
26831 <ins>    template &lt;class U&gt;
26832       unique_ptr(auto_ptr&lt;U&gt;&amp; u);
26833     template &lt;class U&gt;
26834       unique_ptr(auto_ptr&lt;U&gt;&amp;&amp; u);</ins>
26835 };
26836 </pre></blockquote>
26837
26838 <p>
26839 Add to 20.8.9.2.1 [unique.ptr.single.ctor]:
26840 </p>
26841
26842 <blockquote><pre>template &lt;class U&gt;
26843   unique_ptr(auto_ptr&lt;U&gt;&amp; u);
26844 template &lt;class U&gt;
26845   unique_ptr(auto_ptr&lt;U&gt;&amp;&amp; u);
26846 </pre>
26847 <blockquote>
26848 <p>
26849 <i>Effects:</i> Constructs a <tt>unique_ptr</tt> with <tt>u.release()</tt>.
26850 </p>
26851
26852 <p>
26853 <i>Postconditions:</i> <tt>get() == </tt> the value <tt>u.get()</tt> had before
26854 the construciton, modulo any required offset adjustments resulting from the cast from
26855 <tt>U*</tt> to <tt>T*</tt>.  <tt>u.get() == nullptr</tt>.
26856 </p>
26857
26858 <p>
26859 <i>Throws:</i> nothing.
26860 </p>
26861
26862 <p>
26863 <i>Remarks:</i> <tt>U*</tt> shall be implicitly convertible to <tt>T*</tt> and
26864 <tt>D</tt> shall be the same type as <tt>default_delete&lt;T&gt;</tt>, else these
26865 constructors shall not participate in overload resolution.
26866 </p>
26867 </blockquote>
26868 </blockquote>
26869
26870
26871
26872
26873
26874
26875 <hr>
26876 <h3><a name="1102"></a>1102. <tt>std::vector</tt>'s reallocation policy still unclear</h3>
26877 <p><b>Section:</b> 23.3.6.2 [vector.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
26878  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-04-20  <b>Last modified:</b> 2009-05-23</p>
26879 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p>
26880 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
26881 <p><b>Discussion:</b></p>
26882 <p>
26883 I have the impression that even the wording of current draft
26884 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>
26885 does insufficiently express the intent of <tt>vector</tt>'s
26886 reallocation strategy. This has produced not too old library
26887 implementations which release memory in the <tt>clear()</tt> function
26888 and even modern articles about C++ programming cultivate
26889 the belief that <tt>clear</tt> is allowed to do exactly this. A typical
26890 example is something like this:
26891 </p>
26892
26893 <blockquote><pre>const int buf_size = ...;
26894 std::vector&lt;T&gt; buf(buf_size);
26895 for (int i = 0; i &lt; some_condition; ++i) {
26896   buf.resize(buf_size);
26897   write_or_read_data(buf.data());
26898   buf.clear(); // Ensure that the next round get's 'zeroed' elements
26899 }
26900 </pre></blockquote>
26901 <p>
26902 where still the myth is ubiquitous that <tt>buf</tt> might be
26903 allowed to reallocate it's memory *inside* the <tt>for</tt> loop.
26904 </p>
26905 <p>
26906 IMO the problem is due to the fact, that
26907 </p>
26908
26909 <ol type="a">
26910 <li>
26911 the actual memory-reallocation stability of <tt>std::vector</tt>
26912 is explained in 23.3.6.2 [vector.capacity]/3 and /6 which
26913 are describing just the effects of the <tt>reserve</tt>
26914 function, but in many examples (like above) there
26915 is no explicit call to <tt>reserve</tt> involved. Further-more
26916 23.3.6.2 [vector.capacity]/6 does only mention <em>insertions</em>
26917 and never mentions the consequences of erasing
26918 elements.
26919 </li>
26920 <li>
26921 <p>
26922 the effects clause of <tt>std::vector</tt>'s <tt>erase</tt> overloads in
26923 23.3.6.4 [vector.modifiers]/4 is silent about capacity changes. This
26924 easily causes a misunderstanding, because the counter
26925 parting insert functions described in 23.3.6.4 [vector.modifiers]/2
26926 explicitly say, that
26927 </p>
26928 <blockquote>
26929 Causes reallocation if the new size is greater than the
26930 old capacity. If no reallocation happens, all the iterators
26931 and references before the insertion point remain valid.
26932 </blockquote>
26933 <p>
26934 It requires a complex argumentation chain about four
26935 different places in the standard to provide the - possibly
26936 weak - proof that calling <tt>clear()</tt> also does <em>never</em> change
26937 the capacity of the <tt>std::vector</tt> container. Since <tt>std::vector</tt>
26938 is the de-facto replacement of C99's dynamic arrays this
26939 type is near to a built-in type and it's specification should
26940 be clear enough that usual programmers can trust their
26941 own reading.
26942 </p>
26943 </li>
26944 </ol>
26945
26946 <p><i>[
26947 Batavia (2009-05):
26948 ]</i></p>
26949
26950 <blockquote>
26951 <p>
26952 Bill believes paragraph 1 of the proposed resolution is unnecessary
26953 because it is already implied (even if tortuously) by the current wording.
26954 </p>
26955 <p>
26956 Move to Review.
26957 </p>
26958 </blockquote>
26959
26960
26961 <p><b>Proposed resolution:</b></p>
26962 <p><i>[
26963 This is a minimum version. I also
26964 suggest that the wording explaining the allocation strategy
26965 of <tt>std::vector</tt> in 23.3.6.2 [vector.capacity]/3 and /6 is moved into
26966 a separate sub paragraph of 23.3.6.2 [vector.capacity] <em>before</em>
26967 any of the prototype's are discussed, but I cannot provide
26968 reasonable wording changes now
26969 ]</i></p>
26970
26971
26972 <ol>
26973 <li>
26974 <p>
26975 Change 23.3.6.2 [vector.capacity]/6 as follows:
26976 </p>
26977 <blockquote>
26978 It is guaranteed that no reallocation takes place during
26979 insertions <ins>or erasures</ins> that happen after a call
26980 to <tt>reserve()</tt> until the time when an insertion would make
26981 the size of the vector greater than the value of <tt>capacity()</tt>.
26982 </blockquote>
26983 </li>
26984 <li>
26985 <p>
26986 Change 23.3.6.4 [vector.modifiers]/4 as follows:
26987 </p>
26988 <blockquote>
26989 <i>Effects:</i> <ins>The capacity shall remain unchanged and no reallocation shall
26990 happen.</ins>
26991 Invalidates iterators and references at or after the point
26992 of the erase.
26993 </blockquote>
26994 </li>
26995 </ol>
26996
26997
26998
26999
27000
27001 <hr>
27002 <h3><a name="1104"></a>1104. <tt>basic_ios::move</tt> should accept lvalues</h3>
27003 <p><b>Section:</b> 27.5.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
27004  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-04-25  <b>Last modified:</b> 2009-05-23</p>
27005 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p>
27006 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
27007 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
27008 <p><b>Discussion:</b></p>
27009 <p>
27010 With the rvalue reference changes in
27011 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>
27012 <tt>basic_ios::move</tt> no longer has the most convenient signature:
27013 </p>
27014
27015 <blockquote><pre>void move(basic_ios&amp;&amp; rhs);
27016 </pre></blockquote>
27017
27018 <p>
27019 This signature should be changed to accept lvalues.  It does not need to be
27020 overloaded to accept rvalues.  This is a special case that only derived clients
27021 will see.  The generic <tt>move</tt> still needs to accept rvalues.
27022 </p>
27023
27024 <p><i>[
27025 Batavia (2009-05):
27026 ]</i></p>
27027
27028 <blockquote>
27029 <p>
27030 Tom prefers, on general principles, to provide both overloads.
27031 Alisdair agrees.
27032 </p>
27033 <p>
27034 Howard points out that there is no backward compatibility issue
27035 as this is new to C++0X.
27036 </p>
27037 <p>
27038 We agree that both overloads should be provided,
27039 and Howard will provide the additional wording.
27040 Move to Open.
27041 </p>
27042 </blockquote>
27043
27044 <p><i>[
27045 2009-05-23 Howard adds:
27046 ]</i></p>
27047
27048
27049 <blockquote>
27050 Added overload, moved to Review.
27051 </blockquote>
27052
27053
27054
27055 <p><b>Proposed resolution:</b></p>
27056 <p>
27057 Add a signature to the existing prototype in the synopsis of 27.5.4 [ios]
27058 and in 27.5.4.2 [basic.ios.members]:
27059 </p>
27060
27061 <blockquote><pre><ins>void move(basic_ios&amp; rhs);</ins>
27062 void move(basic_ios&amp;&amp; rhs);
27063 </pre></blockquote>
27064
27065
27066
27067
27068
27069 <hr>
27070 <h3><a name="1106"></a>1106. Multiple exceptions from connected <tt>shared_future::get()</tt>?</h3>
27071 <p><b>Section:</b> 30.6.6 [future.shared_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
27072  <b>Submitter:</b> Thomas J. Gritzan <b>Opened:</b> 2009-04-03  <b>Last modified:</b> 2009-05-23</p>
27073 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#future.shared_future">active issues</a> in [future.shared_future].</p>
27074 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#future.shared_future">issues</a> in [future.shared_future].</p>
27075 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
27076 <p><b>Discussion:</b></p>
27077 <p>
27078 It is not clear, if multiple threads are waiting in a
27079 <tt>shared_future::get()</tt> call, if each will rethrow the stored exception.
27080 </p>
27081 <p>
27082 Paragraph 9 reads:
27083 </p>
27084 <blockquote>
27085 <i>Throws:</i> the stored exception, if an exception was stored and not
27086 retrieved before.
27087 </blockquote>
27088 <p>
27089 The "not retrieved before" suggests that only one exception is thrown,
27090 but one exception for each call to <tt>get()</tt> is needed, and multiple calls
27091 to <tt>get()</tt> even on the same <tt>shared_future</tt> object seem to be allowed.
27092 </p>
27093 <p>
27094 I suggest removing "and not retrieved before" from the Throws paragraph.
27095 I recommend adding a note that explains that multiple calls on <tt>get()</tt> are
27096 allowed, and each call would result in an exception if an exception was
27097 stored.
27098 </p>
27099
27100 <p><i>[
27101 Batavia (2009-05):
27102 ]</i></p>
27103
27104 <blockquote>
27105 <p>
27106 We note there is a pending paper by Detlef
27107 on such <tt>future</tt>-related issues;
27108 we would like to wait for his paper before proceeding.
27109 </p>
27110 <p>
27111 Alisdair suggests we may want language to clarify that this
27112 <tt>get()</tt> function can be called from several threads
27113 with no need for explicit locking.
27114 </p>
27115 <p>
27116 Move to Open.
27117 </p>
27118 </blockquote>
27119
27120
27121 <p><b>Proposed resolution:</b></p>
27122 <p>
27123 Change 30.6.6 [future.shared_future]:
27124 </p>
27125
27126 <blockquote><pre>const R&amp; shared_future::get() const;
27127 R&amp; shared_future&lt;R&amp;&gt;::get() const;
27128 void shared_future&lt;void&gt;::get() const;
27129 </pre>
27130 <blockquote>
27131 <p>...</p>
27132 <p>
27133 -9- <i>Throws:</i> the stored exception, if an exception was stored<del> and not retrieved before</del>.
27134 <ins>
27135 [<i>Note:</i> Multiple calls on <tt>get()</tt> are
27136 allowed, and each call would result in an exception if an exception was
27137 stored. &#8212; <i>end note</i>]
27138 </ins>
27139 </p>
27140 </blockquote>
27141 </blockquote>
27142
27143
27144
27145
27146
27147
27148 <hr>
27149 <h3><a name="1108"></a>1108. thread.req.exception overly constrains implementations</h3>
27150 <p><b>Section:</b> 30.2.2 [thread.req.exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
27151  <b>Submitter:</b> Christopher Kohlhoff <b>Opened:</b> 2009-04-25  <b>Last modified:</b> 2009-05-23</p>
27152 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
27153 <p><b>Discussion:</b></p>
27154 <p>
27155 The current formulation of 30.2.2 [thread.req.exception]/2 reads:
27156 </p>
27157 <blockquote>
27158 The error_category of the <tt>error_code</tt> reported by such an
27159 exception's <tt>code()</tt> member function is as specified in the error
27160 condition Clause.
27161 </blockquote>
27162 <p>
27163 This constraint on the code's associated <tt>error_categor</tt> means an
27164 implementation must perform a mapping from the system-generated
27165 error to a <tt>generic_category()</tt> error code. The problems with this
27166 include:
27167 </p>
27168
27169 <ul>
27170 <li>
27171 The mapping is always performed, even if the resultant value is
27172  never used.
27173 </li>
27174 <li>
27175 <p>
27176 The original error produced by the operating system is lost.
27177 </p>
27178 </li>
27179 </ul>
27180 <p>
27181 The latter was one of Peter Dimov's main objections (in a private
27182 email discussion) to the original <tt>error_code</tt>-only design, and led to
27183 the creation of <tt>error_condition</tt> in the first place. Specifically,
27184 <tt>error_code</tt> and <tt>error_condition</tt> are intended to perform the following
27185 roles:
27186 </p>
27187 <ul>
27188 <li>
27189 <tt>error_code</tt> holds the original error produced by the operating
27190  system.
27191 </li>
27192 <li>
27193 <tt>error_condition</tt> and the generic category provide a set of well
27194  known error constants that error codes may be tested against.
27195 </li>
27196 </ul>
27197 <p>
27198 Any mapping determining correspondence of the returned error code to
27199 the conditions listed in the error condition clause falls under the
27200 "latitude" granted to implementors in 19.5.1.5 [syserr.errcat.objects].
27201 (Although obviously their latitude is restricted a little by the
27202 need to match the right error condition when returning an error code
27203 from a library function.)
27204 </p>
27205 <p>
27206 It is important that this <tt>error_code/error_condition</tt> usage is done
27207 correctly for the thread library since it is likely to set the
27208 pattern for future TR libraries that interact with the operating
27209 system.
27210 </p>
27211
27212 <p><i>[
27213 Batavia (2009-05):
27214 ]</i></p>
27215
27216 <blockquote>
27217 Move to Open, and recommend the issue be deferred until after the next
27218 Committee Draft is issued.
27219 </blockquote>
27220
27221
27222 <p><b>Proposed resolution:</b></p>
27223 <p>
27224 Change 30.2.2 [thread.req.exception]/2:
27225 </p>
27226
27227 <blockquote>
27228 <p>
27229 -2- <del>The <tt>error_category</tt> (19.5.1.1) of the <tt>error_code</tt> reported by
27230 such an exception's <tt>code()</tt> member function
27231 is as specified in the error condition Clause.</del>
27232 <ins>
27233 The <tt>error_code</tt> reported by such an exception's <tt>code()</tt> member
27234 function shall compare equal to one of the conditions specified in
27235 the function's error condition Clause. [<i>Example:</i> When the thread
27236 constructor fails:
27237 </ins>
27238 </p>
27239 <blockquote><pre><ins>
27240 ec.category() == implementation-defined // probably system_category
27241 ec == errc::resource_unavailable_try_again // holds true
27242 </ins></pre></blockquote>
27243
27244 <p><ins>
27245 &#8212; <i>end example</i>]
27246 </ins></p>
27247
27248 </blockquote>
27249
27250
27251
27252
27253
27254
27255 <hr>
27256 <h3><a name="1110"></a>1110. Is <tt>for_each</tt> overconstrained?</h3>
27257 <p><b>Section:</b> 25.3.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
27258  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-04-29  <b>Last modified:</b> 2009-05-23</p>
27259 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.foreach">issues</a> in [alg.foreach].</p>
27260 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
27261 <p><b>Discussion:</b></p>
27262 <p>
27263 Quoting working paper for reference (25.3.4 [alg.foreach]):
27264 </p>
27265
27266 <blockquote>
27267 <pre>template&lt;InputIterator Iter, Callable&lt;auto, Iter::reference&gt; Function&gt;
27268   requires CopyConstructible&lt;Function&gt;
27269   Function for_each(Iter first, Iter last, Function f);
27270 </pre>
27271 <blockquote>
27272 <p>
27273 1 Effects: Applies f to the result of dereferencing every iterator in the
27274  range [first,last), starting from first and proceeding to last - 1.
27275 </p>
27276 <p>
27277 2 Returns: f.
27278 </p>
27279 <p>
27280 3 Complexity: Applies f exactly last - first times.
27281 </p>
27282 </blockquote>
27283 </blockquote>
27284
27285 <p>
27286 P2 implies the passed object <tt>f</tt> should be invoked at each stage, rather than
27287 some copy of <tt>f</tt>.  This is important if the return value is to usefully
27288 accumulate changes.  So the requirements are an object of type <tt>Function</tt> can
27289 be passed-by-value, invoked multiple times, and then return by value.  In
27290 this case, <tt>MoveConstructible</tt> is sufficient. This would open support for
27291 move-only functors, which might become important in concurrent code as you
27292 can assume there are no other references (copies) of a move-only type and so
27293 freely use them concurrently without additional locks.
27294 </p>
27295
27296 <p><i>[
27297 See further discussion starting with c++std-lib-23686.
27298 ]</i></p>
27299
27300
27301 <p><i>[
27302 Batavia (2009-05):
27303 ]</i></p>
27304
27305 <blockquote>
27306 <p>
27307 Pete suggests we may want to look at this in a broader context
27308 involving other algorithms.
27309 We should also consider the implications of parallelism.
27310 </p>
27311 <p>
27312 Move to Open, and recommend the issue be deferred until after the next
27313 Committee Draft is issued.
27314 </p>
27315 </blockquote>
27316
27317
27318 <p><b>Proposed resolution:</b></p>
27319 <p>
27320 Change 25.2 [algorithms.syn] and 25.3.4 [alg.foreach]:
27321 </p>
27322
27323 <blockquote><pre>template&lt;InputIterator Iter, Callable&lt;auto, Iter::reference&gt; Function&gt;
27324   requires <del>CopyConstructible</del> <ins>MoveConstructible</ins>&lt;Function&gt;
27325   Function for_each(Iter first, Iter last, Function f);
27326 </pre></blockquote>
27327
27328
27329
27330
27331
27332 <hr>
27333 <h3><a name="1112"></a>1112. bitsets and new style for loop</h3>
27334 <p><b>Section:</b> 20.3.6 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
27335  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-06  <b>Last modified:</b> 2009-07-25</p>
27336 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p>
27337 <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>
27338 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
27339 <p><b>Discussion:</b></p>
27340 <p>
27341 <tt>Std::bitset</tt> is a homogeneous container-like sequence of bits, yet it does
27342 not model the Range concept so cannot be used with the new for-loop syntax.
27343 It is the only such type in the library that does NOT support the new for
27344 loop.
27345 </p>
27346 <p>
27347 The obvious reason is that bitset does not support iterators.
27348 </p>
27349 <p>
27350 At least two reasonable solutions are available:
27351 </p>
27352 <ol type="i">
27353 <li>
27354 Add an iterator interface to <tt>bitset</tt>, bringing its interface close to that
27355 of <tt>std::array</tt>
27356 </li>
27357 <li>
27358 Provide an unspecified concept_map for <tt>Range&lt;bitset&gt;</tt>.
27359 </li>
27360 </ol>
27361 <p>
27362 The latter will still need some kind of iterator-like adapter for <tt>bitset</tt>,
27363 but gives implementers greater freedom on the details. E.g. begin/end return
27364 some type that simply invokes <tt>operator[]</tt> on the object it wraps, and
27365 increments its index on <tt>operator++</tt>.  A vendor can settle for <tt>InputIterator</tt>
27366 support, rather than wrapping up a full <tt>RandomAccessIterator</tt>.
27367 </p>
27368 <p>
27369 I have a mild preference for option (ii) as I think it is less work to
27370 specify at this stage of the process, although (i) is probably more useful
27371 in the long run.
27372 </p>
27373 <p>
27374 Hmm, my wording looks a little woolly, as it does not say what the element
27375 type of the range is.  Do I get a range of <tt>bool</tt>, <tt>bitset&lt;N&gt;::reference</tt>, or
27376 something else entirely?
27377 </p>
27378 <p>
27379 I guess most users will assume the behaviour of reference, but expect to
27380 work with <tt>bool</tt>.  <tt>Bool</tt> is OK for read-only traversal, but you really need to
27381 take a reference to a <tt>bitset::reference</tt> if you want to write back.
27382 </p>
27383
27384 <p><i>[
27385 Batavia (2009-05):
27386 ]</i></p>
27387
27388 <blockquote>
27389 Move to Open.
27390 We further recommend this be deferred until after the next Committee Draft.
27391 </blockquote>
27392
27393 <p><i>[
27394 2009-05-25 Alisdair adds:
27395 ]</i></p>
27396
27397
27398 <blockquote>
27399 <p>
27400 I just stumbled over the <tt>Range concept_map</tt> for <tt>valarray</tt> and this should
27401 probably set the precedent on how to write the wording.
27402 </p>
27403
27404 <p><i>[
27405 Howard: I've replaced the proposed wording with Alisdair's suggestion.
27406 ]</i></p>
27407
27408
27409 </blockquote>
27410
27411 <p><i>[
27412 2009-07-24 Daniel modifies the proposed wording for non-concepts.
27413 ]</i></p>
27414
27415
27416
27417
27418 <p><b>Proposed resolution:</b></p>
27419 <ol>
27420 <li>
27421 <p>
27422 Modify the section 20.3.6 [template.bitset] <tt>&lt;bitset&gt;</tt> synopsis by adding
27423 the following at the end of the synopsis:
27424 </p>
27425 <blockquote><pre><ins>
27426 // XX.X.X bitset range access [bitset.range]
27427 template&lt;size_t N&gt; <i>unspecified-1</i> begin(bitset&lt;N&gt;&amp;);
27428 template&lt;size_t N&gt; <i>unspecified-2</i> begin(const bitset&lt;N&gt;&amp;);
27429 template&lt;size_t N&gt; <i>unspecified-1</i> end(bitset&lt;N&gt;&amp;);
27430 template&lt;size_t N&gt; <i>unspecified-2</i> end(const bitset&lt;N&gt;&amp;);
27431 </ins>
27432 </pre></blockquote>
27433 </li>
27434 <li>
27435 <p>
27436 Add a new section <ins>"bitset range access" [bitset.range]</ins>
27437 after the current section 20.3.6.3 [bitset.operators] with the following series of
27438 paragraphs:
27439 </p>
27440 <blockquote>
27441 <p>
27442 <ins>
27443 1.  In the <tt>begin</tt> and <tt>end</tt> function templates that follow, <i>unspecified-1</i>
27444 is a type that meets the requirements of a mutable random access
27445 iterator (24.2.6 [random.access.iterators]) whose <tt>value_type</tt> is <tt>bool</tt> and
27446 whose reference type is <tt>bitset&lt;N&gt;::reference</tt>.
27447 <i>unspecified-2</i> is a type that meets the requirements of a constant
27448 random access iterator (24.2.6 [random.access.iterators]) whose <tt>value_type</tt>
27449 is <tt>bool</tt> and whose reference type is <tt>bool</tt>.
27450 </ins>
27451 </p>
27452 <pre><ins>
27453 template&lt;size_t N&gt; <i>unspecified-1</i> begin(bitset&lt;N&gt;&amp;);
27454 template&lt;size_t N&gt; <i>unspecified-2</i> begin(const bitset&lt;N&gt;&amp;);
27455 </ins>
27456 </pre>
27457 <blockquote>
27458 <ins>2.  Returns: an iterator referencing the first bit in the bitset.</ins>
27459 </blockquote>
27460
27461 <pre><ins>
27462 template&lt;size_t N&gt; <i>unspecified-1</i> end(bitset&lt;N&gt;&amp;);
27463 template&lt;size_t N&gt; <i>unspecified-2</i> end(const bitset&lt;N&gt;&amp;);
27464 </ins></pre>
27465
27466 <blockquote>
27467 <ins>3.  Returns: an iterator referencing one past the last bit in the
27468 bitset.</ins>
27469 </blockquote>
27470 </blockquote>
27471 </li>
27472 </ol>
27473
27474
27475
27476
27477
27478
27479
27480
27481
27482
27483
27484
27485 <hr>
27486 <h3><a name="1113"></a>1113. <tt>bitset::to_string</tt> could be simplified</h3>
27487 <p><b>Section:</b> 20.3.6 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
27488  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-09  <b>Last modified:</b> 2009-05-23</p>
27489 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#template.bitset">active issues</a> in [template.bitset].</p>
27490 <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>
27491 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
27492 <p><b>Discussion:</b></p>
27493 <p>
27494 In <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a> our resolution is changing the signature by adding two
27495 defaulting arguments to 3 calls.  In principle, this means that ABI breakage
27496 is not an issue, while API is preserved.
27497 </p>
27498 <p>
27499 With that observation, it would be very nice to use the new ability to
27500 supply default template parameters to function templates to collapse all 3
27501 signatures into 1.  In that spirit, this issue offers an alternative resolution
27502 than that of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a>.
27503 </p>
27504
27505 <p><i>[
27506 Batavia (2009-05):
27507 ]</i></p>
27508
27509 <blockquote>
27510 Move to Open,
27511 and look at the issue again after <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853">853</a> has been accepted.
27512 We further recommend this be deferred until after the next Committee Draft.
27513 </blockquote>
27514
27515
27516 <p><b>Proposed resolution:</b></p>
27517
27518 <ol type="A">
27519 <li>
27520 <p>
27521 In 20.3.6 [template.bitset]/1 (class bitset) ammend:
27522 </p>
27523 <blockquote><pre>template &lt;class charT <ins>= char</ins>,
27524             class traits <ins>= char_traits&lt;charT&gt;</ins>,
27525             class Allocator <ins>= allocator&lt;charT&gt;</ins>&gt;
27526   basic_string&lt;charT, traits, Allocator&gt;
27527   to_string(charT zero = charT('0'), charT one = charT('1')) const;
27528 <del>template &lt;class charT, class traits&gt;
27529   basic_string&lt;charT, traits, allocator&lt;charT&gt; &gt; to_string() const;
27530 template &lt;class charT&gt;
27531   basic_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt; to_string() const;
27532 basic_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt; to_string() const;</del>
27533 </pre></blockquote>
27534 </li>
27535 <li>
27536 <p>
27537 In 20.3.6.2 [bitset.members] prior to p35 ammend:
27538 </p>
27539 <blockquote><pre>template &lt;class charT <ins>= char</ins>,
27540             class traits <ins>= char_traits&lt;charT&gt;</ins>,
27541             class Allocator <ins>= allocator&lt;charT&gt;</ins>&gt;
27542   basic_string&lt;charT, traits, Allocator&gt;
27543   to_string(charT zero = charT('0'), charT one = charT('1')) const;
27544 </pre></blockquote>
27545 </li>
27546 <li>
27547 Strike 20.3.6.2 [bitset.members] paragraphs 37 -&gt; 39 (including signature
27548 above 37)
27549 </li>
27550 </ol>
27551
27552
27553
27554
27555
27556
27557 <hr>
27558 <h3><a name="1114"></a>1114. Type traits underspecified</h3>
27559 <p><b>Section:</b> 20.6 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
27560  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-05-12  <b>Last modified:</b> 2009-05-23</p>
27561 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta">active issues</a> in [meta].</p>
27562 <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>
27563 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
27564 <p><b>Discussion:</b></p>
27565
27566 <p>
27567 Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#975">975</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1023">1023</a>.
27568 </p>
27569
27570 <p>
27571 The current wording in 20.6.1 [meta.rqmts] is still unclear concerning
27572 it's requirements on the type traits classes regarding ambiguities.
27573 Specifically it's unclear
27574 </p>
27575
27576 <ul>
27577 <li>
27578 if a predicate trait (20.6.4 [meta.unary], 20.6.5 [meta.rel]) could derive from both
27579 <tt>true_type</tt>/<tt>false_type</tt>.
27580 </li>
27581 <li>
27582 if any of the type traits (20.6.1 [meta.rqmts], 20.6.4 [meta.unary], 20.6.5 [meta.rel]) could ambiguously derive
27583 from the same specified result type.
27584 </li>
27585 <li>
27586 if any of the type traits (20.6.1 [meta.rqmts], 20.6.4 [meta.unary], 20.6.5 [meta.rel]) could derive from other
27587 <tt>integral_constant</tt> types making the contained names ambiguous
27588 </li>
27589 <li>
27590 if any of the type traits (20.6.1 [meta.rqmts], 20.6.4 [meta.unary], 20.6.5 [meta.rel]) could have other base
27591 classes that contain members hiding the name of the result type members
27592 or make the contained member names ambiguous.
27593 </li>
27594 </ul>
27595
27596 <p><i>[
27597 Batavia (2009-05):
27598 ]</i></p>
27599
27600 <blockquote>
27601 <p>
27602 Alisdair would prefer to factor some of the repeated text,
27603 but modulo a corner case or two,
27604 he believes the proposed wording is otherwise substantially correct.
27605 </p>
27606 <p>
27607 Move to Open.
27608 </p>
27609 </blockquote>
27610
27611
27612 <p><b>Proposed resolution:</b></p>
27613 <p><i>[
27614 The usage of the notion of a <i>BaseCharacteristic</i> below
27615 might be
27616 useful in other places - e.g. to define the base class relation in
27617 20.7.5 [refwrap], 20.7.15 [func.memfn], or 20.7.16.2 [func.wrap.func].
27618 In this case it's definition should probably
27619 be moved to Clause 17
27620 ]</i></p>
27621
27622
27623 <ol>
27624 <li>
27625 <p>
27626 Change 20.6.1 [meta.rqmts]/1 as indicated:
27627 </p>
27628 <blockquote>
27629 [..] It shall be <tt>DefaultConstructible</tt>, <tt>CopyConstructible</tt>, and publicly
27630 <ins>and unambiguously</ins> derived, directly or indirectly, from
27631 <ins>its <i>BaseCharacteristic</i>, which is</ins> a specialization of the
27632 template <tt>integral_constant</tt> (20.6.3), with the arguments to the template
27633 <tt>integral_constant</tt> determined by the requirements for the particular
27634 property being described. <ins>The member names of the
27635 <i>BaseCharacteristic</i> shall be unhidden and unambiguously
27636 available in the <i>UnaryTypeTrait</i>.</ins>
27637 </blockquote>
27638 </li>
27639 <li>
27640 <p>
27641 Change 20.6.1 [meta.rqmts]/2 as indicated:
27642 </p>
27643 <blockquote>
27644 [..] It shall be <tt>DefaultConstructible</tt>, <tt>CopyConstructible</tt>, and publicly
27645 <ins>and unambiguously</ins> derived, directly or indirectly, from
27646 <del>an instance</del> <ins>its <i>BaseCharacteristic</i>, which is a
27647 specialization</ins> of the template <tt>integral_constant</tt> (20.6.3), with
27648 the arguments to the template <tt>integral_constant</tt> determined by the
27649 requirements for the particular relationship being described. <ins>The
27650 member names of the <i>BaseCharacteristic</i> shall be unhidden
27651 and unambiguously available in the <i>BinaryTypeTrait</i>.</ins>
27652 </blockquote>
27653 </li>
27654 <li>
27655 <p>
27656 Change 20.6.4 [meta.unary]/2 as indicated:
27657 </p>
27658 <blockquote>
27659 Each of these templates shall be a <i>UnaryTypeTrait</i> (20.6.1),
27660 <del>publicly derived directly or indirectly from <tt>true_type</tt> if the
27661 corresponding condition is true, otherwise from <tt>false_type</tt></del>
27662 <ins>where its <i>BaseCharacteristic</i> shall be <tt>true_type</tt> if the
27663 corresponding condition is true, otherwise <tt>false_type</tt></ins>.
27664 </blockquote>
27665 </li>
27666 <li>
27667 <p>
27668 Change 20.6.5 [meta.rel]/2 as indicated:
27669 </p>
27670
27671 <blockquote>
27672 Each of these templates shall be a <i>BinaryTypeTrait</i> (20.6.1),
27673 <del>publicly derived directly or indirectly from <tt>true_type</tt> if the
27674 corresponding condition is true, otherwise from <tt>false_type</tt></del>
27675 <ins>where its <i>BaseCharacteristic</i> shall be <tt>true_type</tt> if the
27676 corresponding condition is true, otherwise <tt>false_type</tt></ins>.
27677 </blockquote>
27678 </li>
27679 </ol>
27680
27681
27682
27683
27684
27685
27686 <hr>
27687 <h3><a name="1115"></a>1115. <tt>va_copy</tt> missing from Standard macros table</h3>
27688 <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#New">New</a>
27689  <b>Submitter:</b> Miles Zhao <b>Opened:</b> 2009-05-23  <b>Last modified:</b> 2009-05-23</p>
27690 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#diff.library">active issues</a> in [diff.library].</p>
27691 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#diff.library">issues</a> in [diff.library].</p>
27692 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
27693 <p><b>Discussion:</b></p>
27694 <p>
27695 In "Table 122 -- Standard macros" of C.2 [diff.library], which lists the 56 macros
27696 inherited from C library, <tt>va_copy</tt> seems to be missing. But in
27697 "Table 21 -- Header <tt>&lt;cstdarg&gt;</tt> synopsis" (18.10 [support.runtime]), there is.
27698 </p>
27699
27700
27701 <p><b>Proposed resolution:</b></p>
27702 <p>
27703 Add <tt>va_copy</tt> to Table 122 -- Standard macros in C.2 [diff.library].
27704 </p>
27705
27706
27707
27708
27709
27710 <hr>
27711 <h3><a name="1116"></a>1116. Literal constructors for tuple</h3>
27712 <p><b>Section:</b> 20.5.2 [tuple.tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
27713  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23  <b>Last modified:</b> 2009-05-24</p>
27714 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.tuple">issues</a> in [tuple.tuple].</p>
27715 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
27716 <p><b>Discussion:</b></p>
27717 <p>
27718 It is not currently possible to construct <tt>tuple</tt> literal values,
27719 even if the elements are all literal types.  This is because parameters
27720 are passed to constructor by reference.
27721 </p>
27722 <p>
27723 An alternative would be to pass all constructor arguments by value, where it
27724 is known that *all* elements are literal types.  This can be determined with
27725 concepts, although note that the negative constraint really requires
27726 factoring out a separate concept, as there is no way to provide an 'any of
27727 these fails' constraint inline.
27728 </p>
27729 <p>
27730 Note that we will have similar issues with <tt>pair</tt> (and
27731 <tt>tuple</tt> constructors from <tt>pair</tt>) although I am steering
27732 clear of that class while other constructor-related issues settle.
27733 </p>
27734
27735
27736 <p><b>Proposed resolution:</b></p>
27737 <p>
27738 Ammend the tuple class template declaration in 20.5.2 [tuple.tuple] as
27739 follows
27740 </p>
27741
27742 <blockquote>
27743 <p>
27744 Add the following concept:
27745 </p>
27746
27747 <blockquote><pre>auto concept AllLiteral&lt; typename ... Types &gt; {
27748   requires LiteralType&lt;Types&gt;...;
27749 }
27750 </pre></blockquote>
27751
27752 <p>
27753 ammend the constructor
27754 </p>
27755
27756 <blockquote><pre><ins>template &lt;class... UTypes&gt;
27757   requires AllLiteral&lt;Types...&gt;
27758         &amp;&amp; Constructible&lt;Types, UTypes&gt;...
27759   explicit tuple(UTypes...);</ins>
27760
27761 template &lt;class... UTypes&gt;
27762   requires <ins>!AllLiteral&lt;Types...&gt;</ins>
27763         <ins>&amp;&amp;</ins> Constructible&lt;Types, UTypes&amp;&amp;&gt;...
27764   explicit tuple(UTypes&amp;&amp;...);
27765 </pre></blockquote>
27766
27767 <p>
27768 ammend the constructor
27769 </p>
27770
27771 <blockquote><pre><ins>template &lt;class... UTypes&gt;
27772   requires AllLiteral&lt;Types...&gt;
27773         &amp;&amp; Constructible&lt;Types, UTypes&gt;...
27774   tuple(tuple&lt;UTypes...&gt;);</ins>
27775
27776 template &lt;class... UTypes&gt;
27777   requires <ins>!AllLiteral&lt;Types...&gt;</ins>
27778         <ins>&amp;&amp;</ins> Constructible&lt;Types, const UTypes&amp;&gt;...
27779   tuple(const tuple&lt;UTypes...&gt;&amp;);
27780 </pre></blockquote>
27781
27782 </blockquote>
27783
27784 <p>
27785 Update the same signatures in 20.5.2.1 [tuple.cnstr], paras 3 and 5.
27786 </p>
27787
27788
27789
27790
27791
27792 <hr>
27793 <h3><a name="1117"></a>1117. tuple copy constructor</h3>
27794 <p><b>Section:</b> 20.5.2.1 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
27795  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23  <b>Last modified:</b> 2009-05-30</p>
27796 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.cnstr">active issues</a> in [tuple.cnstr].</p>
27797 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.cnstr">issues</a> in [tuple.cnstr].</p>
27798 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
27799 <p><b>Discussion:</b></p>
27800 <p>
27801 The copy constructor for the <tt>tuple</tt> template is constrained.  This seems an
27802 unusual strategy, as the copy constructor will be implicitly deleted if the
27803 constraints are not met.  This is exactly the same effect as requesting an
27804 <tt>=default;</tt> constructor.  The advantage of the latter is that it retains
27805 triviality, and provides support for <tt>tuple</tt>s as literal types if issue
27806 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1116">1116</a> is also accepted.
27807 </p>
27808 <p>
27809 Actually, it might be worth checking with core if a constrained copy
27810 constructor is treated as a constructor template, and as such does not
27811 suppress the implicit generation of the copy constructor which would hide
27812 the template in this case.
27813 </p>
27814
27815 <p><i>[
27816 2009-05-27 Daniel adds:
27817 ]</i></p>
27818
27819
27820 <blockquote>
27821 This would solve one half of the suggested changes in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#801">801</a>.
27822 </blockquote>
27823
27824
27825 <p><b>Proposed resolution:</b></p>
27826 <p>
27827 Change 20.5.2 [tuple.tuple] and 20.5.2.1 [tuple.cnstr] p4:
27828 </p>
27829
27830 <blockquote><pre><del>requires CopyConstructible&lt;Types&gt;...</del> tuple(const tuple&amp;)<ins> = default</ins>;
27831 </pre></blockquote>
27832
27833
27834
27835
27836
27837 <hr>
27838 <h3><a name="1118"></a>1118. tuple query APIs do not support cv-qualification</h3>
27839 <p><b>Section:</b> 20.5.2.3 [tuple.helper] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
27840  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23  <b>Last modified:</b> 2009-05-25</p>
27841 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.helper">active issues</a> in [tuple.helper].</p>
27842 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.helper">issues</a> in [tuple.helper].</p>
27843 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
27844 <p><b>Discussion:</b></p>
27845 <p>
27846 The APIs <tt>tuple_size</tt> and <tt>tuple_element</tt> do not support
27847 cv-qualified <tt>tuple</tt>s, <tt>pair</tt>s or <tt>array</tt>s.
27848 </p>
27849 <p>
27850 The most generic solution would be to supply partial specializations once
27851 for each cv-type in the <tt>tuple</tt> header.  However, requiring this header for
27852 cv-qualified <tt>pair</tt>s/<tt>array</tt>s seems unhelpful.  The BSI editorial
27853 suggestion (UK-198/US-69,
27854 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2533.html">N2533</a>)
27855 to merge <tt>tuple</tt> into <tt>&lt;utility&gt;</tt> would help with <tt>pair</tt>,
27856 but not <tt>array</tt>.  That might be resolved by making a dependency between the
27857 <tt>&lt;array&gt;</tt> header and <tt>&lt;utility&gt;</tt>, or simply recognising
27858 the dependency be fulfilled in a Remark.
27859 </p>
27860
27861 <p><i>[
27862 2009-05-24 Daniel adds:
27863 ]</i></p>
27864
27865
27866 <blockquote>
27867 <p>
27868 All <tt>tuple_size</tt> templates with a base class need to derive publicly, e.g.
27869 </p>
27870
27871 <blockquote><pre>template &lt;IdentityOf T&gt; class tuple_size&lt; const T &gt; :
27872    <ins>public</ins> tuple_size&lt;T&gt; {};
27873 </pre></blockquote>
27874
27875 <p>
27876 The same applies to the tuple_element class hierarchies.
27877 </p>
27878 <p>
27879 What is actually meant with the comment
27880 </p>
27881 <blockquote>
27882 this solution relies on 'metafunction forwarding' to inherit the
27883 nested typename type
27884 </blockquote>
27885 <p>
27886 ?
27887 </p>
27888 <p>
27889 I ask, because all base classes are currently unconstrained and their
27890 instantiation is invalid in the constrained context of the <tt>tuple_element</tt> partial
27891 template specializations.
27892 </p>
27893 </blockquote>
27894
27895 <p><i>[
27896 2009-05-24 Alisdair adds:
27897 ]</i></p>
27898
27899
27900 <blockquote>
27901 <p>
27902 I think a better solution might be to ask Pete editorially to change all
27903 declarations of tupling APIs to use the struct specifier instead of class.
27904 </p>
27905 <p>
27906 "metafunction forwarding" refers to the MPL metafunction protocol, where a
27907 metafunction result is declared as a nested typedef with the name "type",
27908 allowing metafunctions to be chained by means of inheritance.  It is a
27909 neater syntax than repeatedly declaring a typedef, and inheritance syntax is
27910 slightly nicer when it comes to additional typename keywords.
27911 </p>
27912 <p>
27913 The constrained template with an unconstrained base is a good observation
27914 though.
27915 </p>
27916 </blockquote>
27917
27918
27919
27920 <p><b>Proposed resolution:</b></p>
27921 <p>
27922 Add to 20.5.1 [tuple.general] p2 (Header <tt>&lt;tuple&gt;</tt> synopsis)
27923 </p>
27924
27925 <blockquote><pre>// 20.5.2.3, tuple helper classes:
27926 template &lt;IdentityOf T&gt; class tuple_size; // undefined
27927 <ins>template &lt;IdentityOf T&gt; class tuple_size&lt; const T &gt; : tuple_size&lt;T&gt; {};</ins>
27928 <ins>template &lt;IdentityOf T&gt; class tuple_size&lt; volatile T &gt; : tuple_size&lt;T&gt; {};</ins>
27929 <ins>template &lt;IdentityOf T&gt; class tuple_size&lt; const volatile T &gt; : tuple_size&lt;T&gt; {};</ins>
27930
27931 template &lt;VariableType... Types&gt; class tuple_size&lt;tuple&lt;Types...&gt; &gt;;
27932
27933 template &lt;size_t I, IdentityOf T&gt; class tuple_element; // undefined
27934 <ins>template &lt;size_t I, IdentityOf T&gt; class tuple_element&lt;I, const T&gt;;</ins>
27935 <ins>template &lt;size_t I, IdentityOf T&gt; class tuple_element&lt;I, volatile T&gt;;</ins>
27936 <ins>template &lt;size_t I, IdentityOf T&gt; class tuple_element&lt;I, const volatile T&gt;;</ins>
27937
27938 template &lt;size_t I, VariableType... Types&gt;
27939   requires True&lt;(I &lt; sizeof...(Types))&gt; class tuple_element&lt;I, tuple&lt;Types...&gt; &gt;;
27940 </pre></blockquote>
27941
27942 <p>
27943 Add to 20.5.2.3 [tuple.helper]
27944 </p>
27945 <p><i>[
27946 (note that this solution relies on 'metafunction forwarding' to inherit the
27947 nested typename type)
27948 ]</i></p>
27949
27950
27951 <blockquote><pre>template &lt;class... Types&gt;
27952 class tuple_size&lt;tuple&lt;Types...&gt; &gt;
27953   : public integral_constant&lt;size_t, sizeof...(Types)&gt; { };
27954
27955 template &lt;size_t I, class... Types&gt;
27956 requires True&lt;(I &lt; sizeof...(Types))&gt;
27957 class tuple_element&lt;I, tuple&lt;Types...&gt; &gt; {
27958 public:
27959   typedef TI type;
27960 };
27961
27962 <ins>template &lt;size_t I, IdentityOf T&gt;
27963   class tuple_element&lt;I, const T&gt; : add_const&lt;tuple_element&lt;I,T&gt;&gt; {};</ins>
27964
27965 <ins>template &lt;size_t I, IdentityOf T&gt;
27966   class tuple_element&lt;I, volatile T&gt; : add_volatile&lt;tuple_element&lt;I,T&gt;&gt; {};</ins>
27967
27968 <ins>template &lt;size_t I, IdentityOf T&gt;
27969   class tuple_element&lt;I, const volatile T&gt; : add_cv&lt;tuple_element&lt;I,T&gt;&gt; {};</ins>
27970 </pre></blockquote>
27971
27972
27973
27974
27975
27976 <hr>
27977 <h3><a name="1119"></a>1119. tuple query APIs do not support references</h3>
27978 <p><b>Section:</b> 20.5.2.3 [tuple.helper] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
27979  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23  <b>Last modified:</b> 2009-05-24</p>
27980 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple.helper">active issues</a> in [tuple.helper].</p>
27981 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple.helper">issues</a> in [tuple.helper].</p>
27982 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
27983 <p><b>Discussion:</b></p>
27984 <p>
27985 The <tt>tuple</tt> query APIs <tt>tuple_size</tt> and
27986 <tt>tuple_element</tt> do not support references-to-tuples.  This can be
27987 annoying when a template deduced a parameter type to be a reference,
27988 which must be explicitly stripped with <tt>remove_reference</tt> before calling
27989 these APIs.
27990 </p>
27991 <p>
27992 I am not proposing a resolution at this point, as there is a
27993 combinatorial explosion with lvalue/rvalue references and
27994 cv-qualification (see previous issue) that suggests some higher
27995 refactoring is in order.  This might be something to kick back over to
27996 Core/Evolution.
27997 </p>
27998 <p>
27999 Note that we have the same problem in numeric_limits.
28000 </p>
28001
28002
28003 <p><b>Proposed resolution:</b></p>
28004
28005
28006
28007
28008
28009 <hr>
28010 <h3><a name="1120"></a>1120. New type trait - remove_all</h3>
28011 <p><b>Section:</b> 20.6 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
28012  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23  <b>Last modified:</b> 2009-05-24</p>
28013 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta">active issues</a> in [meta].</p>
28014 <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>
28015 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
28016 <p><b>Discussion:</b></p>
28017 <p>
28018 Sometimes it is necessary to remove all qualifiers from a type before
28019 passing on to a further API.  A good example would be calling the
28020 <tt>tuple</tt> query APIs <tt>tuple_size</tt> or <tt>tuple_element</tt>
28021 with a deduced type inside a function template.  If the deduced type is
28022 cv-qualified or a reference then the call will fail.  The solution is to
28023 chain calls to
28024 <tt>remove_cv&lt;remove_reference&lt;T&gt;::type&gt;::type</tt>, and
28025 note that the order matters.
28026 </p>
28027 <p>
28028 Suggest it would be helpful to add a new type trait,
28029 <tt>remove_all</tt>, that removes all top-level qualifiers from a type
28030 i.e. cv-qualification and any references.  Define the term in such a way
28031 that if additional qualifiers are added to the language, then
28032 <tt>remove_all</tt> is defined as stripping those as well.
28033 </p>
28034
28035
28036 <p><b>Proposed resolution:</b></p>
28037
28038
28039
28040
28041
28042 <hr>
28043 <h3><a name="1121"></a>1121. Support for multiple arguments</h3>
28044 <p><b>Section:</b> 20.4.2 [ratio.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
28045  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-25  <b>Last modified:</b> 2009-05-25</p>
28046 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ratio.arithmetic">issues</a> in [ratio.arithmetic].</p>
28047 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
28048 <p><b>Discussion:</b></p>
28049 <p>
28050 Both add and multiply could sensibly be called with more than two arguments.
28051 The variadic template facility makes such declarations simple, and is likely
28052 to be frequently wrapped by end users if we do not supply the variant
28053 ourselves.
28054 </p>
28055 <p>
28056 We deliberately ignore divide at this point as it is not transitive.
28057 Likewise, subtract places special meaning on the first argument so I do not
28058 suggest extending that immediately.  Both could be supported with analogous
28059 wording to that for add/multiply below.
28060 </p>
28061 <p>
28062 Note that the proposed resolution is potentially incompatible with that
28063 proposed for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#921">921</a>, although the addition of the typedef to ratio would be
28064 equally useful.
28065 </p>
28066
28067
28068 <p><b>Proposed resolution:</b></p>
28069 <p><i>[
28070 note that this wording relies on 'metafunction forwarding' as described by
28071 Boost MPL
28072 ]</i></p>
28073
28074
28075 <p>
28076 20.4 [ratio] p3 synopsis: change
28077 </p>
28078
28079 <blockquote><pre>// ratio arithmetic
28080 template &lt;class R1, class R2<ins>, class ... RList</ins>&gt; struct ratio_add;
28081 template &lt;class R1, class R2&gt; struct ratio_subtract;
28082 template &lt;class R1, class R2<ins>, class ... RList</ins>&gt; struct ratio_multiply;
28083 template &lt;class R1, class R2&gt; struct ratio_divide;
28084 </pre></blockquote>
28085
28086 <p>
28087 20.4.2 [ratio.arithmetic] p1: change
28088 </p>
28089
28090 <blockquote><pre><ins>template &lt;class R1, class R2, class ... RList&gt; struct ratio_add
28091   : ratio_add&lt; R1, ratio_add&lt;R2, RList...&gt;&gt; {
28092 };</ins>
28093
28094 template &lt;class R1, class R2&gt; struct ratio_add<ins>&lt;R1, R2&gt;</ins> {
28095   typedef <i>see below</i> type;
28096 };
28097 </pre></blockquote>
28098
28099
28100 <p>
28101 20.4.2 [ratio.arithmetic] p3: change
28102 </p>
28103
28104 <blockquote><pre><ins>template &lt;class R1, class R2, class ... RList&gt; struct ratio_multiply
28105   : ratio_multiply&lt; R1, ratio_ multiply &lt;R2, RList...&gt;&gt; {
28106 };</ins>
28107
28108 template &lt;class R1, class R2&gt; struct ratio_ multiply<ins>&lt;R1, R2&gt;</ins> {
28109   typedef <i>see below</i> type;
28110 };
28111 </pre></blockquote>
28112
28113
28114
28115
28116
28117
28118 <hr>
28119 <h3><a name="1122"></a>1122. Ratio values should be constexpr</h3>
28120 <p><b>Section:</b> 20.4.1 [ratio.ratio] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
28121  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-25  <b>Last modified:</b> 2009-05-25</p>
28122 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ratio.ratio">active issues</a> in [ratio.ratio].</p>
28123 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ratio.ratio">issues</a> in [ratio.ratio].</p>
28124 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
28125 <p><b>Discussion:</b></p>
28126 <p>
28127 The values <tt>num</tt> and <tt>den</tt> in the <tt>ratio</tt> template
28128 should be declared <tt>constexpr</tt>.
28129 </p>
28130
28131
28132 <p><b>Proposed resolution:</b></p>
28133 <p>
28134 20.4.1 [ratio.ratio]
28135 </p>
28136
28137 <blockquote><pre>namespace std {
28138   template &lt;intmax_t N, intmax_t D = 1&gt;
28139   class ratio {
28140   public:
28141     static const<ins>expr</ins> intmax_t num;
28142     static const<ins>expr</ins> intmax_t den;
28143   };
28144 }
28145 </pre></blockquote>
28146
28147
28148
28149
28150
28151
28152 <hr>
28153 <h3><a name="1123"></a>1123. no requirement that standard streams be flushed</h3>
28154 <p><b>Section:</b> 27.5.2.1.6 [ios::Init] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
28155  <b>Submitter:</b> James Kanze <b>Opened:</b> 2009-05-14  <b>Last modified:</b> 2009-05-30</p>
28156 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios::Init">issues</a> in [ios::Init].</p>
28157 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
28158 <p><b>Discussion:</b></p>
28159 <p>
28160 As currently formulated, the standard doesn't require that there
28161 is ever a flush of <tt>cout</tt>, etc.  (This implies, for example, that
28162 the classical hello, world program may have no output.)  In the
28163 current draft
28164 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>),
28165 there is a requirement that the objects
28166 be constructed before <tt>main</tt>, and before the dynamic
28167 initialization of any non-local objects defined after the
28168 inclusion of <tt>&lt;iostream&gt;</tt> in the same translation unit.  The only
28169 requirement that I can find concerning flushing, however, is in
28170 27.5.2.1.6 [ios::Init], where the destructor of the last
28171 <tt>std::ios_base::Init</tt> object flushes.  But there is, as far as I
28172 can see, no guarantee that such an object ever exists.
28173 </p>
28174 <p>
28175 Also, the wording in  [iostreams.objects] says that:
28176 </p>
28177 <blockquote>
28178 The objects
28179 are constructed and the associations are established at some
28180 time prior to or during the first time an object of class
28181 <tt>ios_base::Init</tt> is constructed, and in any case before the body
28182 of main begins execution.
28183 </blockquote>
28184 <p>
28185 In 27.5.2.1.6 [ios::Init], however, as an
28186 effect of the constructor, it says that
28187 </p>
28188 <blockquote>
28189 If <tt>init_cnt</tt> is zero,
28190 the function stores the value one in <tt>init_cnt</tt>, then constructs
28191 and initializes the objects <tt>cin</tt>, <tt>cout</tt>, <tt>cerr</tt>, <tt>clog</tt>
28192 <tt>wcin</tt>, <tt>wcout</tt>, <tt>wcerr</tt>, and <tt>wclog</tt>"
28193 </blockquote>
28194
28195 <p>
28196 which seems to forbid earlier
28197 construction.
28198 </p>
28199
28200 <p>
28201 (Note that with these changes, the exposition only "<tt>static
28202 int init_cnt</tt>" in <tt>ios_base::Init</tt> can be dropped.)
28203 </p>
28204 <p>
28205 Of course, a determined programmer can still inhibit the
28206 flush with things like:
28207 </p>
28208 <blockquote><pre>new std::ios_base::Init ;       //  never deleted
28209 </pre></blockquote>
28210 <p>
28211 or (in a function):
28212 </p>
28213 <blockquote><pre>std::ios_base::Init ensureConstruction ;
28214 //  ...
28215 exit( EXIT_SUCCESS ) ;
28216 </pre></blockquote>
28217 <p>
28218 Perhaps some words somewhere to the effect that all
28219 <tt>std::ios_base::Init</tt> objects should have static lifetime
28220 would be in order.
28221 </p>
28222
28223
28224 <p><b>Proposed resolution:</b></p>
28225 <p>
28226 Change 27.4 [iostream.objects]/2:
28227 </p>
28228
28229 <blockquote>
28230 -2- The objects are constructed and the associations are established at
28231 some time prior to or during the first time an object of class
28232 <tt>ios_base::Init</tt> is constructed, and in any case before the body
28233 of main begins execution.<sup>292</sup> The objects are not destroyed
28234 during program execution.<sup>293</sup>
28235 <del>If a translation unit includes
28236 <tt>&lt;iostream&gt;</tt> or explicitly constructs an
28237 <tt>ios_base::Init</tt> object, these stream objects shall be
28238 constructed before dynamic initialization of non-local objects defined
28239 later in that translation unit.</del>
28240 <ins>The results of including <tt>&lt;iostream&gt;</tt> in a translation
28241 unit shall be as if <tt>&lt;iostream&gt;</tt> defined an instance of
28242 <tt>ios_base::Init</tt> with static lifetime. Similarly, the entire
28243 program shall behave as if there were at least one instance of
28244 <tt>ios_base::Init</tt> with static lifetime.</ins>
28245 </blockquote>
28246
28247 <p>
28248 Change 27.5.2.1.6 [ios::Init]/3:
28249 </p>
28250
28251 <blockquote>
28252 <pre>Init();
28253 </pre>
28254 <blockquote>
28255 -3- <i>Effects:</i> Constructs an object of class <tt>Init</tt>.
28256 <del>If <tt>init_cnt</tt> is zero, the function stores the value one in
28257 <tt>init_cnt</tt>, then constructs and initializes the objects
28258 <tt>cin</tt>, <tt>cout</tt>, <tt>cerr</tt>, <tt>clog</tt> (27.4.1),
28259 <tt>wcin</tt>, <tt>wcout</tt>, <tt>wcerr</tt>, and <tt>wclog</tt>
28260 (27.4.2). In any case, the function then adds one to the value stored in
28261 <tt>init_cnt</tt>.</del>
28262 <ins>Constructs and initializes the objects <tt>cin</tt>, <tt>cout</tt>,
28263 <tt>cerr</tt>, <tt>clog</tt>, <tt>wcin</tt>, <tt>wcout</tt>,
28264 <tt>wcerr</tt> and <tt>wclog</tt> if they have not already been
28265 constructed and initialized.</ins>
28266 </blockquote>
28267 </blockquote>
28268
28269 <p>
28270 Change 27.5.2.1.6 [ios::Init]/4:
28271 </p>
28272
28273 <blockquote>
28274 <pre>~Init();
28275 </pre>
28276 <blockquote>
28277 -4- <i>Effects:</i> Destroys an object of class <tt>Init</tt>.
28278 <del>The function subtracts one from the value stored in <tt>init_cnt</tt> and,
28279 if the resulting stored value is one,</del>
28280 <ins>If there are no other instances of the class still in
28281 existance,</ins>
28282 calls <tt>cout.flush()</tt>,
28283 <tt>cerr.flush()</tt>, <tt>clog.flush()</tt>, <tt>wcout.flush()</tt>,
28284 <tt>wcerr.flush()</tt>, <tt>wclog.flush()</tt>.
28285 </blockquote>
28286 </blockquote>
28287
28288
28289
28290
28291
28292
28293 <hr>
28294 <h3><a name="1125"></a>1125. ostream_iterator does not work with movable types</h3>
28295 <p><b>Section:</b> 24.6.2.2 [ostream.iterator.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
28296  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-28  <b>Last modified:</b> 2009-05-30</p>
28297 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
28298 <p><b>Discussion:</b></p>
28299 <p>
28300 <tt>ostream_iterator</tt> has not been updated to support moveable types, in a
28301 similar manner to the insert iterators.
28302 Note that this is not a problem for <tt>ostreambuf_iterator</tt>, as the types it is
28303 restricted to dealing with do not support extra-efficient moving.
28304 </p>
28305
28306
28307 <p><b>Proposed resolution:</b></p>
28308 <p>
28309 Add second <tt>operator=</tt> overload to class <tt>template ostream_iterator</tt>
28310 in 24.6.2 [ostream.iterator], para 2:
28311 </p>
28312
28313 <blockquote><pre>ostream_iterator&lt;T,charT,traits&gt;&amp; operator=(const T&amp; value);
28314 <ins>ostream_iterator&lt;T,charT,traits&gt;&amp; operator=(T&amp;&amp; value);</ins>
28315 </pre></blockquote>
28316
28317 <p>
28318 Add a new paragraph: in 24.6.2.2 [ostream.iterator.ops]:
28319 </p>
28320
28321 <blockquote>
28322 <pre>ostream_iterator&amp; operator=(T&amp;&amp; value);
28323 </pre>
28324 <blockquote>
28325 <p>
28326 -2- <i>Effects:</i>
28327 </p>
28328 <blockquote><pre>*out_stream &lt;&lt; std::move(value);
28329 if(delim != 0)
28330   *out_stream &lt;&lt; delim;
28331 return (*this);
28332 </pre></blockquote>
28333 </blockquote>
28334 </blockquote>
28335
28336
28337
28338
28339
28340
28341 <hr>
28342 <h3><a name="1126"></a>1126. <tt>istreambuff_iterator::equal</tt> needs a const &amp; parameter</h3>
28343 <p><b>Section:</b> 24.6.3.5 [istreambuf.iterator::equal] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
28344  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-28  <b>Last modified:</b> 2009-05-30</p>
28345 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istreambuf.iterator::equal">issues</a> in [istreambuf.iterator::equal].</p>
28346 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
28347 <p><b>Discussion:</b></p>
28348 <p>
28349 The <tt>equal</tt> member function of <tt>istreambuf_iterator</tt> is
28350 declared <tt>const</tt>, but takes its argument by non-const reference.
28351 </p>
28352 <p>
28353 This is not compatible with the <tt>operator==</tt> free function overload, which is
28354 defined in terms of calling <tt>equal</tt> yet takes both arguments by reference to
28355 const.
28356 </p>
28357
28358 <p><i>[
28359 The proposed wording is consistent with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a> with status TC1.
28360 ]</i></p>
28361
28362
28363
28364
28365 <p><b>Proposed resolution:</b></p>
28366 <p>
28367 Ammend in both:<br>
28368 24.6.3 [istreambuf.iterator]<br>
28369 24.6.3.5 [istreambuf.iterator::equal]<br>
28370 </p>
28371
28372 <blockquote><pre>bool equal(<ins>const </ins>istreambuf_iterator&amp; b) const;
28373 </pre></blockquote>
28374
28375
28376
28377
28378
28379
28380 <hr>
28381 <h3><a name="1129"></a>1129. <tt>istream(buf)_iterator</tt> should support literal sentinel value</h3>
28382 <p><b>Section:</b> 24.6.1.1 [istream.iterator.cons], 24.6.3 [istreambuf.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
28383  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-30  <b>Last modified:</b> 2009-06-09</p>
28384 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
28385 <p><b>Discussion:</b></p>
28386 <p>
28387 <tt>istream_iterator</tt> and <tt>istreambuf_iterator</tt> should support literal sentinel
28388 values.  The default constructor is frequently used to terminate ranges, and
28389 could easily be a literal value for <tt>istreambuf_iterator</tt>, and
28390 <tt>istream_iterator</tt> when iterating value types.  A little more work using a
28391 suitably sized/aligned char-array for storage (or an updated component like
28392 <tt>boost::optional</tt> proposed for TR2) would allow <tt>istream_iterator</tt> to support
28393 <tt>constexpr</tt> default constructor in all cases, although we might leave this
28394 tweak as a QoI issue.  Note that requiring <tt>constexpr</tt> be supported also
28395 allows us to place no-throw guarantees on this constructor too.
28396 </p>
28397
28398 <p><i>[
28399 2009-06-02 Daniel adds:
28400 ]</i></p>
28401
28402
28403 <blockquote>
28404 <p>
28405 I agree with the usefulness of the issue suggestion, but we need
28406 to ensure that <tt>istream_iterator</tt> <em>can</em> satisfy be literal if needed.
28407 Currently this is not clear, because 24.6.1 [istream.iterator]/3 declares
28408 a copy constructor and a destructor and explains their semantic in
28409 24.6.1.1 [istream.iterator.cons]/3+4.
28410 </p>
28411 <p>
28412 The prototype semantic specification is ok (although it seems
28413 somewhat redundant to me, because the semantic doesn't say
28414 anything interesting in both cases), but for support of trivial class
28415 types we also need a trivial copy constructor and destructor as of
28416 9 [class]/6. The current non-informative specification of these
28417 two special members suggests to remove their explicit declaration
28418 in the class and add explicit wording that says that if <tt>T</tt> is
28419 trivial a default constructed iterator is also literal, alternatively it
28420 would be possible to mark both as defaulted and add explicit
28421 (memberwise) wording that guarantees that they are trivial.
28422 </p>
28423 <p>
28424 Btw.: I'm quite sure that the <tt>istreambuf_iterator</tt> additions to
28425 ensure triviality are not sufficient as suggested, because the
28426 library does not yet give general guarantees that a defaulted
28427 special member declaration makes this member also trivial.
28428 Note that e.g. the atomic types do give a general statement!
28429 </p>
28430 <p>
28431 Finally there is a wording issue: There does not exist something
28432 like a "literal constructor". The core language uses the term
28433 "constexpr constructor" for this.
28434 </p>
28435 <p>
28436 Suggestion:
28437 </p>
28438 <ol>
28439 <li>
28440 <p>
28441 Change 24.6.1 [istream.iterator]/3 as indicated:
28442 </p>
28443 <blockquote><pre><ins>constexpr</ins> istream_iterator();
28444 istream_iterator(istream_type&amp; s);
28445 istream_iterator(const istream_iterator<del>&lt;T,charT,traits,Distance&gt;</del>&amp; x)<ins> = default</ins>;
28446 ~istream_iterator()<ins> = default</ins>;
28447 </pre></blockquote>
28448 </li>
28449 <li>
28450 <p>
28451 Change 24.6.1.1 [istream.iterator.cons]/1 as indicated:
28452 </p>
28453 <blockquote><pre><ins>constexpr</ins> istream_iterator();
28454 </pre>
28455 <blockquote>
28456 -1- <i>Effects:</i> Constructs the end-of-stream iterator. <ins>If <tt>T</tt> is a literal type,
28457 then this constructor shall be a constexpr constructor.</ins>
28458 </blockquote>
28459 </blockquote>
28460 </li>
28461 <li>
28462 <p>
28463 Change 24.6.1.1 [istream.iterator.cons]/3 as indicated:
28464 </p>
28465 <blockquote><pre>istream_iterator(const istream_iterator<del>&lt;T,charT,traits,Distance&gt;</del>&amp; x)<ins> = default</ins>;
28466 </pre>
28467 <blockquote>
28468 -3- <i>Effects:</i> Constructs a copy of <tt>x</tt>. <ins>If <tt>T</tt> is a literal type, then
28469 this constructor shall be a trivial copy constructor.</ins>
28470 </blockquote>
28471 </blockquote>
28472 </li>
28473 <li>
28474 <p>
28475 Change 24.6.1.1 [istream.iterator.cons]/4 as indicated:
28476 </p>
28477
28478 <blockquote><pre>~istream_iterator()<ins> = default</ins>;
28479 </pre>
28480 <blockquote>
28481 -4- <i>Effects:</i> The iterator is destroyed. <ins>If <tt>T</tt> is a literal type, then
28482 this destructor shall be a trivial
28483 destructor.</ins>
28484 </blockquote>
28485 </blockquote>
28486 </li>
28487 <li>
28488 <p>
28489 Change 24.6.3 [istreambuf.iterator] before p. 1 as indicated:
28490 </p>
28491
28492 <blockquote><pre><ins>constexpr</ins> istreambuf_iterator() throw();
28493 <ins>istreambuf_iterator(const istreambuf_iterator&amp;)  throw() = default;</ins>
28494 <ins>~istreambuf_iterator()  throw() = default;</ins>
28495 </pre></blockquote>
28496 </li>
28497 <li>
28498 <p>
28499 Change 24.6.3 [istreambuf.iterator]/1 as indicated:
28500 </p>
28501 <blockquote>
28502 [..] The default constructor <tt>istreambuf_iterator()</tt> and the constructor
28503 <tt>istreambuf_iterator(0)</tt> both
28504 construct an end of stream iterator object suitable for use as an
28505 end-of-range. <ins>All
28506 specializations of <tt>istreambuf_iterator</tt> shall have a trivial copy
28507 constructor, a constexpr default
28508 constructor and a trivial destructor.</ins>
28509 </blockquote>
28510 </li>
28511 </ol>
28512 </blockquote>
28513
28514
28515 <p><b>Proposed resolution:</b></p>
28516 <p>
28517 24.6.1 [istream.iterator] para 3
28518 </p>
28519
28520 <blockquote><pre><ins>constexpr</ins> istream_iterator();
28521 </pre></blockquote>
28522
28523 <p>
28524 24.6.1.1 [istream.iterator.cons]
28525 </p>
28526
28527 <blockquote><pre><ins>constexpr</ins> istream_iterator();
28528 </pre>
28529 <blockquote>
28530 -1- <i>Effects:</i> Constructs the end-of-stream iterator.
28531 <ins>If <tt>T</tt> is a literal type, then this constructor shall
28532 be a literal constructor.</ins>
28533 </blockquote>
28534 </blockquote>
28535
28536 <p>
28537 24.6.3 [istreambuf.iterator]
28538 </p>
28539
28540 <blockquote><pre><ins>constexpr</ins> istreambuf_iterator() throw();
28541 </pre></blockquote>
28542
28543
28544
28545
28546
28547
28548 <hr>
28549 <h3><a name="1130"></a>1130. <tt>copy_exception</tt> name misleading</h3>
28550 <p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
28551  <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2009-05-13  <b>Last modified:</b> 2009-06-02</p>
28552 <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>
28553 <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>
28554 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
28555 <p><b>Discussion:</b></p>
28556 <p>
28557 The naming of <tt>std::copy_exception</tt> misleads almost everyone
28558 (experts included!) to think that it is the function that copies an
28559 <tt>exception_ptr</tt>:
28560 </p>
28561
28562 <blockquote><pre>exception_ptr p1 = current_exception();
28563 exception_ptr p2 = copy_exception( p1 );
28564 </pre></blockquote>
28565
28566 <p>
28567 But this is not at all what it does. The above actually creates an
28568 <tt>exception_ptr p2</tt> that contains a copy of <tt>p1</tt>, not of
28569 the exception to which <tt>p1</tt> refers!
28570 </p>
28571 <p>
28572 This is, of course, all my fault; in my defence, I used <tt>copy_exception</tt>
28573 because I was unable to think of a better name.
28574 </p>
28575 <p>
28576 But I believe that, based on what we've seen so far, <em>any</em> other name would be better.
28577 </p>
28578 <p>
28579 Therefore, I propose <tt>copy_exception</tt> to be renamed to
28580 <tt>create_exception</tt>:
28581 </p>
28582
28583 <blockquote><pre>template&lt;class E&gt; exception_ptr create_exception(E e);
28584 </pre></blockquote>
28585
28586 <p>
28587 with the following explanatory paragraph after it:
28588 </p>
28589
28590 <blockquote>
28591 Creates an <tt>exception_ptr</tt> that refers to a copy of <tt>e</tt>.
28592 </blockquote>
28593
28594 <p><i>[
28595 2009-05-13 Daniel adds:
28596 ]</i></p>
28597
28598
28599 <blockquote>
28600 <p>
28601 What about
28602 </p>
28603 <blockquote><pre>make_exception_ptr
28604 </pre></blockquote>
28605 <p>
28606 in similarity to <tt>make_pair</tt> and <tt>make_tuple</tt>, <tt>make_error_code</tt> and
28607 <tt>make_error_condition</tt>, or <tt>make_shared</tt>? Or, if a stronger symmetry to
28608 <tt>current_exception</tt> is preferred:
28609 </p>
28610
28611 <blockquote><pre>make_exception
28612 </pre></blockquote>
28613 <p>
28614 We have not a single <tt>create_*</tt> function in the library, it was always
28615 <tt>make_*</tt> used.
28616 </p>
28617 </blockquote>
28618
28619 <p><i>[
28620 2009-05-13 Peter adds:
28621 ]</i></p>
28622
28623
28624 <blockquote>
28625 <tt>make_exception_ptr</tt> works for me.
28626 </blockquote>
28627
28628 <p><i>[
28629 2009-06-02 Thomas J. Gritzan adds:
28630 ]</i></p>
28631
28632
28633 <blockquote>
28634 <p>
28635 To avoid surprises and unwanted recursion, how about making a call to
28636 <tt>std::make_exception_ptr</tt> with an <tt>exception_ptr</tt> illegal?
28637 </p>
28638 <p>
28639 It might work like this:
28640 </p>
28641 <blockquote><pre>template&lt;class E&gt;
28642 exception_ptr make_exception_ptr(E e);
28643 template&lt;&gt;
28644 exception_ptr make_exception_ptr&lt;exception_ptr&gt;(exception_ptr e) = delete;
28645 </pre></blockquote>
28646 </blockquote>
28647
28648
28649
28650 <p><b>Proposed resolution:</b></p>
28651 <p>
28652 Change 18.8.5 [propagation]:
28653 </p>
28654
28655 <blockquote>
28656 <pre>template&lt;class E&gt; exception_ptr <del>copy_exception</del><ins>make_exception_ptr</ins>(E e);
28657 </pre>
28658
28659 <blockquote>
28660 <p>
28661 -11- <i>Effects:</i> <ins>Creates an <tt>exception_ptr</tt> that refers
28662 to a copy of <tt>e</tt>,</ins> as if
28663 </p>
28664
28665 <blockquote><pre>try {
28666   throw e;
28667 } catch(...) {
28668   return current_exception();
28669 }
28670 </pre></blockquote>
28671
28672 <p>...</p>
28673 </blockquote>
28674
28675 </blockquote>
28676
28677
28678
28679
28680
28681
28682 <hr>
28683 <h3><a name="1131"></a>1131. C++0x does not need <tt>alignment_of</tt></h3>
28684 <p><b>Section:</b> 20.6.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
28685  <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2009-06-01  <b>Last modified:</b> 2009-06-02</p>
28686 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
28687 <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>
28688 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
28689 <p><b>Discussion:</b></p>
28690 <p>
28691 The <tt>alignment_of</tt> template is no longer necessary, now that the
28692 core language will provide <tt>alignof</tt>. Scott Meyers raised this
28693 issue at comp.std.c++,
28694 <a href="http://groups.google.com/group/comp.std.c++/browse_thread/thread/9b020306e803f08a">C++0x: alignof vs. alignment_of</a>,
28695 May 21, 2009.  In a reply, Daniel Krügler pointed out that
28696 <tt>alignof</tt> was added to the working paper <i>after</i>
28697 <tt>alignment_of</tt>. So it appears that <tt>alignment_of</tt> is only
28698 part of the current Working Draft
28699 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>)
28700 because it is in TR1.
28701 </p>
28702 <p>
28703 Having both <tt>alignof</tt> and <tt>alignment_of</tt> would cause
28704 unwanted confusion. In general, I think TR1 functionality should not be
28705 brought into C++0x if it is entirely redundant with other C++0x language
28706 or library features.
28707 </p>
28708
28709
28710 <p><b>Proposed resolution:</b></p>
28711 <p>
28712 Remove from Header &lt;type_traits&gt; synopsis 20.6.2 [meta.type.synop]:
28713 </p>
28714 <blockquote><pre><del>template &lt;class T&gt; struct alignment_of;</del>
28715 </pre></blockquote>
28716
28717 <p>
28718 Remove the first row of Table 34 ("Type property queries"), from
28719 Type properties 20.6.4.3 [meta.unary.prop]:
28720 </p>
28721 <blockquote>
28722 <table border="1">
28723 <caption>Table 34 -- Type property queries</caption>
28724 <tbody><tr>
28725 <td><del><tt>template &lt;class T&gt; struct alignment_of;</tt></del></td>
28726 <td><del><tt>alignof(T)</tt>.</del><br>
28727 <del><i>Precondition:</i> <tt>T</tt> shall be a complete type, a reference
28728 type, or an array of unknown bound, but shall not be a function type or
28729 (possibly cv-qualified) <tt>void</tt>.</del>
28730 </td>
28731 </tr>
28732 </tbody></table>
28733 </blockquote>
28734
28735 <p>
28736 Change text in Table 41 ("Other transformations"), from Other
28737 transformations 20.6.7 [meta.trans.other], as follows:
28738 </p>
28739 <blockquote>
28740 <table border="1">
28741 <caption>Table 41 -- Other transformations</caption>
28742 <tbody><tr><td>...</td>
28743 <td>
28744  Align shall be equal to <tt>
28745  <del>alignment_of&lt;T&gt;::value</del>
28746  <ins>alignof(T)</ins>
28747  </tt> for some type <tt>T</tt> or to <i>default-alignment</i>.
28748 </td>
28749 <td>...</td>
28750 </tr></tbody></table>
28751 </blockquote>
28752
28753
28754
28755
28756
28757 <hr>
28758 <h3><a name="1132"></a>1132. JP-30: nested exceptions</h3>
28759 <p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
28760  <b>Submitter:</b> Seiji Hayashida <b>Opened:</b> 2009-06-01  <b>Last modified:</b> 2009-06-02</p>
28761 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p>
28762 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p>
28763 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
28764 <p><b>Discussion:</b></p>
28765 <p><b>Addresses JP 30</b></p>
28766
28767 <p>
28768 C++0x <tt>nested_exception</tt> cannot handle a structured exception well. The
28769 following codes show two types of tree structured exception handling.
28770 </p>
28771 <p>
28772 The first one is based on <tt>nested_exception</tt> in C++0x,
28773 while the second one is based on my library <tt>trickerr.h</tt> (in Japanese).
28774 <a href="http://tricklib.com/cxx/dagger/trickerr.h">http://tricklib.com/cxx/dagger/trickerr.h</a>
28775 </p>
28776 <p>
28777 Assume that Function <tt>A()</tt> calls two sub functions <tt>A_a()</tt> and <tt>A_b()</tt>, both might
28778 throw tree structured exceptions, and <tt>A_b()</tt> must be called even if <tt>A_a()</tt>
28779 throws an exception.
28780 </p>
28781 <p>
28782 List A (code of tree structured exception handling based on nested_exception
28783 in C++0x)
28784 </p>
28785
28786 <blockquote><pre>void A()
28787 {
28788     try
28789     {
28790         std::vector&lt;exception_ptr&gt; exception_list;
28791         try
28792         {
28793             // A_a() does a similar processing as A().
28794             A_a();
28795         }
28796         catch(...)
28797         {
28798             exception_list.push_back(current_exception());
28799         }
28800
28801         // ***The processing A() has to do even when A_a() fails. ***
28802         try
28803         {
28804             // A_b() does a similar processing as A().
28805             A_b();
28806         }
28807         catch(...)
28808         {
28809             exception_list.push_back(current_exception());
28810         }
28811         if (!exception_list.empty())
28812         {
28813             throw exception_list;
28814         }
28815     }
28816     catch(...)
28817     {
28818         throw_with_nested(A_exception("someone error"));
28819     }
28820 }
28821 void print_tree_exception(exception_ptr e, const std::string &amp; indent ="")
28822 {
28823     const char * indent_unit = " ";
28824     const char * mark = "- ";
28825     try
28826     {
28827         rethow_exception(e);
28828     }
28829     catch(const std::vector&lt;exception_ptr&gt; e)
28830     {
28831         for(std::vector&lt;exception_ptr&gt;::const_iterator i = e.begin(); i!=e.end(); ++i)
28832         {
28833             print_tree_exception(i, indent);
28834         }
28835     }
28836     catch(const std::nested_exception  e)
28837     {
28838         print_tree_exception(evil_i(e), indent +indent_unit);
28839     }
28840     catch(const std::exception e)
28841     {
28842         std::cout &lt;&lt; indent &lt;&lt; mark &lt;&lt; e.what() &lt;&lt; std::endl;
28843     }
28844     catch(...)
28845     {
28846         std::cout &lt;&lt; indent &lt;&lt; mark &lt;&lt; "unknown exception" &lt;&lt; std::endl;
28847     }
28848 }
28849 int main(int, char * [])
28850 {
28851     try
28852     {
28853         A();
28854     }
28855     catch()
28856     {
28857         print_tree_exception(current_exception());
28858     }
28859     return EXIT_SUCCESS;
28860 }
28861 </pre></blockquote>
28862
28863 <p>
28864 List B ( code of tree structured exception handling based on <tt>trickerr.h</tt>. )
28865 "trickerr.h" (in Japanese), refer to:
28866 <a href="http://tricklib.com/cxx/dagger/trickerr.h">http://tricklib.com/cxx/dagger/trickerr.h</a>.
28867 </p>
28868
28869 <blockquote><pre>void A()
28870 {
28871     tricklib::error_listener_type error_listener;
28872     // A_a() is like A(). A_a() can throw tree structured exception.
28873     A_a();
28874
28875     // *** It must do process so that A_a() throws exception in A(). ***
28876     // A_b() is like A(). A_b() can throw tree structured exception.
28877     A_b();
28878
28879     if (error_listener.has_error()) // You can write this "if block" in destructor
28880                                     //  of class derived from error_listener_type.
28881     {
28882         throw_error(new A_error("someone error",error_listener.listener_off().extract_pending_error()));
28883     }
28884 }
28885 void print_tree_error(const tricklib::error_type &amp;a_error, const std::string &amp; indent = "")
28886 {
28887     const char * indent_unit = " ";
28888     const char * mark = "- ";
28889
28890     tricklib::error_type error = a_error;
28891     while(error)
28892     {
28893         std::cout &lt;&lt; indent &lt;&lt; mark &lt;&lt; error-&gt;message &lt;&lt; std::endl;
28894         if (error-&gt;children)
28895         {
28896             print_tree_error(error-&gt;children, indent +indent_unit);
28897         }
28898         error = error-&gt;next;
28899     }
28900 }
28901 int main(int, char * [])
28902 {
28903     tricklib::error_thread_power error_thread_power_on; // This object is necessary per thread.
28904
28905     try
28906     {
28907         A();
28908     }
28909     catch(error_type error)
28910     {
28911         print_tree_error(error);
28912     }
28913     catch(...)
28914     {
28915         std::cout &lt;&lt; "- unknown exception" &lt;&lt; std::endl;
28916     }
28917     return EXIT_SUCCESS;
28918 }
28919 </pre></blockquote>
28920
28921 <p>
28922 Prospect
28923 </p>
28924 <p>
28925 We will focus on the method A() since the other methods, also main(), occur
28926 only once respectively.
28927 </p>
28928
28929 <ul>
28930 <li>
28931  In the List A above (of the nested exception handling), it is hard to
28932  find out an active reason to use the nested exception handling at this
28933  scene. Rather, we can take a simpler description by throwing the entire
28934  exception_list directly to the top level.
28935 </li>
28936 <li>
28937  The code in the same example gives us a kind of redundant impression,
28938  which might have come from the fact that the try-throw-catch framework does
28939  not assume a tree structured exception handling.
28940 </li>
28941 </ul>
28942
28943 <p>
28944 According to the above observation, we cannot help concluding that it is not
28945 so easy to use the nested_exception handling as a tree structured exception
28946 handling mechanism in a practical sense.
28947 </p>
28948 <p>
28949 This text is based on the web page below (in Japanese).
28950 <a href="http://d.hatena.ne.jp/wraith13/20081231/1230715424">http://d.hatena.ne.jp/wraith13/20081231/1230715424</a>
28951 </p>
28952
28953
28954 <p><b>Proposed resolution:</b></p>
28955 <p>
28956 </p>
28957
28958
28959
28960
28961
28962 <hr>
28963 <h3><a name="1133"></a>1133. Does N2844 break current specification of list::splice?</h3>
28964 <p><b>Section:</b> 23.3.3.5 [forwardlist.ops], 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
28965  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-09  <b>Last modified:</b> 2009-06-09</p>
28966 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forwardlist.ops">active issues</a> in [forwardlist.ops].</p>
28967 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forwardlist.ops">issues</a> in [forwardlist.ops].</p>
28968 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
28969 <p><b>Discussion:</b></p>
28970 <p>
28971 IIUC,
28972 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>
28973 means that lvalues will no longer bind to rvalue references.
28974 Therefore, the current specification of <tt>list::splice</tt> (list
28975 operations 23.3.4.4 [list.ops]) will be a breaking change of behaviour for existing
28976 programs.  That is because we changed the signature to swallow via an rvalue
28977 reference rather than the lvalue reference used in 03.
28978 </p>
28979 <p>
28980 Retaining this form would be safer, requiring an explicit move when splicing
28981 from lvalues.  However, this will break existing programs.
28982 We have the same problem with <tt>forward_list</tt>, although without the risk of
28983 breaking programs so here it might be viewed as a positive feature.
28984 </p>
28985 <p>
28986 The problem signatures:
28987 </p>
28988 <blockquote><pre>void splice_after(const_iterator position, forward_list&lt;T,Alloc&gt;&amp;&amp; x);
28989 void splice_after(const_iterator position, forward_list&lt;T,Alloc&gt;&amp;&amp; x,
28990                   const_iterator i);
28991 void splice_after(const_iterator position, forward_list&lt;T,Alloc&gt;&amp;&amp; x,
28992                   const_iterator first, const_iterator last);
28993
28994 void splice(const_iterator position, list&lt;T,Alloc&gt;&amp;&amp; x);
28995 void splice(const_iterator position, list&lt;T,Alloc&gt;&amp;&amp; x,
28996             const_iterator i);
28997 void splice(const_iterator position, list&lt;T,Alloc&gt;&amp;&amp; x,
28998             const_iterator first, const_iterator last);
28999 </pre></blockquote>
29000
29001 <b>Possible resolutions:</b>
29002
29003 <p>
29004 Option A.       Add an additional (non-const) lvalue-reference
29005 overload in each case
29006 </p>
29007 <p>
29008 Option B.       Change rvalue reference back to (non-const)
29009 lvalue-reference overload in each case
29010 </p>
29011 <p>
29012 Option C.       Add an additional (non-const) lvalue-reference
29013 overload in just the <tt>std::list</tt> cases
29014 </p>
29015 <p>
29016 I think (B) would be very unfortunate, I really like the <tt>forward_list</tt>
29017 behaviour in (C) but feel (A) is needed for consistency.
29018 </p>
29019 <p>
29020 My actual preference would be NAD, ship with this as a breaking change as it
29021 is a more explicit interface.  I don't think that will fly though!
29022 </p>
29023
29024 <p>
29025 See the thread starting with c++std-lib-23725 for more discussion.
29026 </p>
29027
29028
29029 <p><b>Proposed resolution:</b></p>
29030
29031
29032
29033
29034
29035 <hr>
29036 <h3><a name="1134"></a>1134. Redundant specification of stdint.h, fenv.h, tgmath.h, and maybe complex.h</h3>
29037 <p><b>Section:</b> 18.4.2 [stdinth], 26.3.2 [fenv], 26.8 [c.math], 26.4.11 [cmplxh] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
29038  <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2009-05-26  <b>Last modified:</b> 2009-06-14</p>
29039 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
29040 <p><b>Discussion:</b></p>
29041 <p>
29042 This is probably editorial.
29043 </p>
29044 <p>
29045 The following items should be removed from the draft, because they're
29046 redundant with Annex D, and they arguably make some *.h headers
29047 non-deprecated:
29048 </p>
29049 <p>
29050 18.4.2 [stdinth] (regarding <tt>&lt;stdint.h&gt;</tt>)
29051 </p>
29052 <p>
29053 26.3.2 [fenv] (regarding <tt>&lt;fenv.h&gt;</tt>
29054 </p>
29055 <p>
29056 Line 3 of 26.8 [c.math] (regarding <tt>&lt;tgmath.h&gt;</tt>)
29057 </p>
29058 <p>
29059 26.4.11 [cmplxh] (regarding <tt>&lt;complex.h&gt;</tt>, though the note in this subclause is not redundant)
29060 </p>
29061
29062 <p><i>[
29063 2009-06-10 Ganesh adds:
29064 ]</i></p>
29065
29066
29067 <blockquote>
29068 While searching for <tt>stdint</tt> in the CD, I found that <tt>&lt;stdint.h&gt;</tt> is also
29069 mentioned in 3.9.1 [basic.fundamental] /5. It guess it should refer to
29070 <tt>&lt;cstdint&gt;</tt> instead.
29071 </blockquote>
29072
29073
29074 <p><b>Proposed resolution:</b></p>
29075 <p>
29076 Remove the section 18.4.2 [stdinth].
29077 </p>
29078 <p>
29079 Remove the section 26.3.2 [fenv].
29080 </p>
29081 <p>
29082 Remove 26.8 [c.math], p3:
29083 </p>
29084
29085 <blockquote>
29086 <del>-3- The header <tt>&lt;tgmath.h&gt;</tt> effectively includes the headers <tt>&lt;complex.h&gt;</tt>
29087 and <tt>&lt;math.h&gt;</tt>.</del>
29088 </blockquote>
29089 <p>
29090 Remove the section 26.4.11 [cmplxh].
29091 </p>
29092
29093
29094
29095
29096
29097 <hr>
29098 <h3><a name="1135"></a>1135. <tt>exception_ptr</tt> should support contextual conversion to <tt>bool</tt></h3>
29099 <p><b>Section:</b> 18.8.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
29100  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-06-06  <b>Last modified:</b> 2009-06-09</p>
29101 <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>
29102 <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>
29103 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
29104 <p><b>Discussion:</b></p>
29105 <p>
29106 As of
29107 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>
29108 18.8.5 [propagation]/5, the implementation-defined type
29109 <tt>exception_ptr</tt> does provide the following ways to check whether
29110 it is a null value:
29111 </p>
29112 <blockquote><pre>void f(std::exception_ptr p) {
29113   p == nullptr;
29114   p == 0;
29115   p == exception_ptr();
29116 }
29117 </pre></blockquote>
29118 <p>
29119 This is rather cumbersome way of checking for the null value
29120 and I suggest to require support for evaluation in a boolean
29121 context like so:
29122 </p>
29123
29124 <blockquote><pre>void g(std::exception_ptr p) {
29125   if (p) {}
29126   !p;
29127 }
29128 </pre></blockquote>
29129
29130
29131 <p><b>Proposed resolution:</b></p>
29132 <p>
29133 In section 18.8.5 [propagation] insert a new paragraph between p.5 and p.6:
29134 </p>
29135
29136 <blockquote>
29137 <ins>
29138 An object <tt>e</tt> of type <tt>exception_ptr</tt> can be contextually converted to <tt>bool</tt>.
29139 The effect shall be as if <tt>e != exception_ptr()</tt> had been evaluated in place
29140 of <tt>e</tt>. There shall be no implicit conversion to arithmetic type, to
29141 enumeration type or to pointer type.
29142 </ins>
29143 </blockquote>
29144
29145
29146
29147
29148
29149 <hr>
29150 <h3><a name="1136"></a>1136. Incomplete specification of <tt>nested_exception::rethrow_nested()</tt></h3>
29151 <p><b>Section:</b> 18.8.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
29152  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2007-06-06  <b>Last modified:</b> 2009-06-09</p>
29153 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#except.nested">active issues</a> in [except.nested].</p>
29154 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#except.nested">issues</a> in [except.nested].</p>
29155 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
29156 <p><b>Discussion:</b></p>
29157 <p>
29158 It was recently mentioned in a newsgroup article
29159 <a href="http://groups.google.de/group/comp.std.c++/msg/f82022aff68edf3d">http://groups.google.de/group/comp.std.c++/msg/f82022aff68edf3d</a>
29160 that the specification of the member function <tt>rethrow_nested()</tt> of the
29161 class <tt>nested_exception</tt> is incomplete, specifically it remains unclear
29162 what happens, if member <tt>nested_ptr()</tt> returns a null value. In
29163 18.8.6 [except.nested] we find only the following paragraph related to that:
29164 </p>
29165 <blockquote><pre>void rethrow_nested() const; // [[noreturn]]
29166 </pre>
29167 <blockquote>
29168 -4- <i>Throws:</i> the stored exception captured by this <tt>nested_exception</tt> object.
29169 </blockquote>
29170 </blockquote>
29171 <p>
29172 This is a problem, because it is possible to create an object of
29173 <tt>nested_exception</tt> with exactly such a state, e.g.
29174 </p>
29175 <blockquote><pre>#include &lt;exception&gt;
29176 #include &lt;iostream&gt;
29177
29178 int main() try {
29179   std::nested_exception e; // OK, calls current_exception() and stores it's null value
29180   e.rethrow_nested(); // ?
29181   std::cout &lt;&lt; "A" &lt;&lt; std::endl;
29182 }
29183 catch(...) {
29184   std::cout &lt;&lt; "B" &lt;&lt; std::endl;
29185 }
29186 </pre></blockquote>
29187 <p>
29188 I suggest to follow the proposal of the reporter, namely to invoke
29189 <tt>terminate()</tt> if <tt>nested_ptr()</tt> return a null value of <tt>exception_ptr</tt> instead
29190 of relying on the fallback position of undefined behavior. This would
29191 be consistent to the behavior of a <tt>throw;</tt> statement when no
29192 exception is being handled.
29193 </p>
29194
29195
29196 <p><b>Proposed resolution:</b></p>
29197 <p>
29198 Change around 18.8.6 [except.nested]/4 as indicated:
29199 </p>
29200 <blockquote>
29201 <p>
29202 -4- <i>Throws:</i> the stored exception captured by this <tt>nested_exception</tt>
29203 object<ins>, if <tt>nested_ptr() != nullptr</tt></ins>
29204 </p>
29205 <p>
29206 <ins>- <i>Remarks:</i> If <tt>nested_ptr() == nullptr</tt>, <tt>terminate()</tt>
29207 shall be called.</ins>
29208 </p>
29209 </blockquote>
29210
29211
29212
29213
29214
29215 <hr>
29216 <h3><a name="1137"></a>1137. Return type of <tt>conj</tt> and <tt>proj</tt></h3>
29217 <p><b>Section:</b> 26.4.9 [cmplx.over] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
29218  <b>Submitter:</b> Marc Steinbach <b>Opened:</b> 2009-06-11  <b>Last modified:</b> 2009-06-27</p>
29219 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cmplx.over">issues</a> in [cmplx.over].</p>
29220 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
29221 <p><b>Discussion:</b></p>
29222 <p>
29223 In clause 1, the Working Draft
29224 (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>)
29225 specifies overloads of the
29226 functions
29227 </p>
29228 <blockquote><pre>arg, conj, imag, norm, proj, real
29229 </pre></blockquote>
29230 <p>
29231 for non-complex arithmetic types (<tt>float</tt>, <tt>double</tt>,
29232 <tt>long double</tt>, and integers).
29233 The only requirement (clause 2) specifies effective type promotion of arguments.
29234 </p>
29235 <p>
29236 I strongly suggest to add the following requirement on the return types:
29237 </p>
29238 <blockquote>
29239 All the specified overloads must return real (i.e., non-complex) values,
29240 specifically, the nested <tt>value_type</tt> of effectively promoted arguments.
29241 </blockquote>
29242
29243 <p>
29244 (This has no effect on <tt>arg</tt>, <tt>imag</tt>, <tt>norm</tt>, <tt>real</tt>:
29245 they are real-valued anyway.)
29246 </p>
29247 <p><b>Rationale:</b></p>
29248 <p>
29249 Mathematically, <tt>conj()</tt> and <tt>proj()</tt>, like the transcendental functions, are
29250 complex-valued in general but map the (extended) real line to itself.
29251 In fact, both functions act as identity on the reals.
29252 A typical user will expect <tt>conj()</tt> and <tt>proj()</tt> to preserve this essential
29253 mathematical property in the same way as <tt>exp()</tt>, <tt>sin()</tt>, etc.
29254 A typical use of <tt>conj()</tt>, e.g., is the generic scalar product of n-vectors:
29255 </p>
29256
29257 <blockquote><pre>template&lt;typename T&gt;
29258 inline T
29259 scalar_product(size_t n, T const* x, T const* y) {
29260   T result = 0;
29261   for (size_t i = 0; i &lt; n; ++i)
29262     result += x[i] * std::conj(y[i]);
29263   return result;
29264 }
29265 </pre></blockquote>
29266 <p>
29267 This will work equally well for real and complex floating-point types <tt>T</tt> if
29268 <tt>conj()</tt> returns <tt>T</tt>. It will not work with real types if <tt>conj()</tt>
29269 returns complex values.
29270 </p>
29271 <p>
29272 Instead, the implementation of <tt>scalar_product</tt> becomes either less efficient
29273 and less useful (if a complex result is always returned), or unnecessarily
29274 complicated (if overloaded versions with proper return types are defined).
29275 In the second case, the real-argument overload of <tt>conj()</tt> cannot be used.
29276 In fact, it must be avoided.
29277 </p>
29278 <p>
29279 Overloaded <tt>conj()</tt> and <tt>proj()</tt> are principally needed in generic programming.
29280 All such use cases will benefit from the proposed return type requirement,
29281 in a similar way as the <tt>scalar_product</tt> example.
29282 The requirement will not harm use cases where a complex return value
29283 is expected, because of implicit conversion to complex.
29284 Without the proposed return type guarantee, I find overloaded versions
29285 of <tt>conj()</tt> and <tt>proj()</tt> not only useless but actually troublesome.
29286 </p>
29287
29288
29289
29290 <p><b>Proposed resolution:</b></p>
29291 <p>
29292 Insert a new paragraph after 26.4.9 [cmplx.over]/2:
29293 </p>
29294
29295 <blockquote>
29296 <ins>
29297 All of the specified overloads shall have a return type which is the nested <tt>value_type</tt> of
29298 the effectively promoted arguments.
29299 </ins>
29300 </blockquote>
29301
29302
29303
29304
29305
29306 <hr>
29307 <h3><a name="1138"></a>1138. unusal return value for operator+</h3>
29308 <p><b>Section:</b> 21.4.8.1 [string::op+] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
29309  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-06-12  <b>Last modified:</b> 2009-06-15</p>
29310 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
29311 <p><b>Discussion:</b></p>
29312 <p>
29313 Many of the <tt>basic_string operator+</tt> overloads return an rvalue-reference.  Is
29314 that really intended?
29315 </p>
29316 <p>
29317 I'm considering it might be a mild performance tweak to avoid making
29318 un-necessary copies of a cheaply movable type, but it opens risk to dangling
29319 references in code like:
29320 </p>
29321
29322 <blockquote><pre>auto &amp;&amp; s = string{"x"} + string{y};
29323 </pre></blockquote>
29324
29325 <p>
29326 and I'm not sure about:
29327 </p>
29328
29329 <blockquote><pre>auto s = string{"x"} + string{y};
29330 </pre></blockquote>
29331
29332
29333 <p><b>Proposed resolution:</b></p>
29334 <p>
29335 Strike the <tt>&amp;&amp;</tt> from the return type in the following function
29336 signatures:
29337 </p>
29338
29339 <blockquote>
29340 <p>
29341 21.3 [string.classes] p2 Header Synopsis
29342 </p>
29343
29344 <blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
29345   basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
29346     operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs,
29347               const basic_string&lt;charT,traits,Allocator&gt;&amp; rhs);
29348
29349 template&lt;class charT, class traits, class Allocator&gt;
29350   basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
29351     operator+(const basic_string&lt;charT,traits,Allocator&gt;&amp; lhs,
29352               basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
29353
29354 template&lt;class charT, class traits, class Allocator&gt;
29355   basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
29356     operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs,
29357               basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
29358
29359
29360 template&lt;class charT, class traits, class Allocator&gt;
29361   basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
29362     operator+(const charT* lhs,
29363               basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
29364
29365 template&lt;class charT, class traits, class Allocator&gt;
29366   basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
29367     operator+(charT lhs, basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
29368
29369 template&lt;class charT, class traits, class Allocator&gt;
29370   basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
29371     operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs,
29372               const charT* rhs);
29373
29374 template&lt;class charT, class traits, class Allocator&gt;
29375   basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
29376     operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs, charT rhs);
29377 </pre></blockquote>
29378
29379 <p>
29380 21.4.8.1 [string::op+]
29381 </p>
29382
29383 <blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
29384   basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
29385     operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs,
29386               const basic_string&lt;charT,traits,Allocator&gt;&amp; rhs);
29387
29388 template&lt;class charT, class traits, class Allocator&gt;
29389   basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
29390     operator+(const basic_string&lt;charT,traits,Allocator&gt;&amp; lhs,
29391               basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
29392
29393 template&lt;class charT, class traits, class Allocator&gt;
29394   basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
29395     operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs,
29396               basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
29397
29398
29399 template&lt;class charT, class traits, class Allocator&gt;
29400   basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
29401     operator+(const charT* lhs,
29402               basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
29403
29404 template&lt;class charT, class traits, class Allocator&gt;
29405   basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
29406     operator+(charT lhs, basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);
29407
29408 template&lt;class charT, class traits, class Allocator&gt;
29409   basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
29410     operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs,
29411               const charT* rhs);
29412
29413 template&lt;class charT, class traits, class Allocator&gt;
29414   basic_string&lt;charT,traits,Allocator&gt;<del>&amp;&amp;</del>
29415     operator+(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs, charT rhs);
29416 </pre></blockquote>
29417
29418 </blockquote>
29419
29420
29421
29422
29423
29424
29425 <hr>
29426 <h3><a name="1144"></a>1144. "thread safe" is undefined</h3>
29427 <p><b>Section:</b> 18.5 [support.start.term] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
29428  <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-16  <b>Last modified:</b> 2009-07-04</p>
29429 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.start.term">issues</a> in [support.start.term].</p>
29430 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
29431 <p><b>Discussion:</b></p>
29432
29433 <p><b>Addresses UK 187</b></p>
29434
29435 <p>
29436 The term "thread safe" is not defined nor used in this context
29437 anywhere else in the standard.
29438 </p>
29439
29440 <p><b>Suggested action:</b></p>
29441 <p>
29442 Clarify the meaning of "thread safe".
29443 </p>
29444
29445
29446 <p><b>Proposed resolution:</b></p>
29447
29448
29449
29450
29451
29452 <hr>
29453 <h3><a name="1145"></a>1145. inappropriate headers for atomics</h3>
29454 <p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
29455  <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-16  <b>Last modified:</b> 2009-07-04</p>
29456 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics">active issues</a> in [atomics].</p>
29457 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics">issues</a> in [atomics].</p>
29458 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
29459 <p><b>Discussion:</b></p>
29460
29461 <p><b>Addresses UK 312</b></p>
29462
29463 <p>
29464 The contents of the <tt>&lt;stdatomic.h&gt;</tt> header are not listed anywhere,
29465 and <tt>&lt;cstdatomic&gt;</tt> is listed as a C99 header in chapter 17.
29466 If we intend to use these for compatibility with a future C standard,
29467 we should not use them now.
29468 </p>
29469
29470
29471 <p><b>Proposed resolution:</b></p>
29472 <p>
29473 Remove <tt>&lt;cstdatomic&gt;</tt> from the C99 headers in table 14.
29474 Add a new header <tt>&lt;atomic&gt;</tt> to the headers in table 13.
29475 Update chapter 29 to remove reference to <tt>&lt;stdatomic.h&gt;</tt>
29476 and replace the use of <tt>&lt;cstdatomic&gt;</tt> with <tt>&lt;atomic&gt;</tt>.
29477 </p>
29478 <p><i>[
29479 If and when WG14 adds atomic operations to C
29480 we can add corresponding headers to table 14 with a TR.
29481 ]</i></p>
29482
29483
29484
29485
29486
29487
29488 <hr>
29489 <h3><a name="1146"></a>1146. "lockfree" does not say enough</h3>
29490 <p><b>Section:</b> 29.4 [atomics.lockfree] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
29491  <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2009-06-16  <b>Last modified:</b> 2009-07-04</p>
29492 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
29493 <p><b>Discussion:</b></p>
29494
29495 <p><b>Addresses US 88</b></p>
29496
29497 <p>
29498 The "lockfree" facilities do not tell the programmer enough.
29499 </p>
29500
29501 <p>
29502 There are 2 problems here.
29503 First, at least on x86,
29504 it's less important to me whether some integral types are lock free
29505 than what is the largest type I can pass to atomic and have it be lock-free.
29506 For example, if <tt>long long</tt>s are not lock-free,
29507 <tt>ATOMIC_INTEGRAL_LOCK_FREE</tt> is probably 1,
29508 but I'd still be interested in knowing whether longs are always lock-free.
29509 Or if long longs at any address are lock-free,
29510 I'd expect <tt>ATOMIC_INTEGRAL_LOCK_FREE</tt> to be 2,
29511 but I may actually care whether I have access to
29512 the <code>cmpxchg16b</code> instruction.
29513 None of the support here helps with that question.
29514 (There are really 2 related questions here:
29515 what alignment requirements are there for lock-free access;
29516 and what processor is the program actually running on,
29517 as opposed to what it was compiled for?)
29518 </p>
29519
29520 <p>
29521 Second, having <tt>atomic_is_lock_free</tt> only apply to individual objects
29522 is pretty useless
29523 (except, as Lawrence Crowl points out,
29524 for throwing an exception when an object is unexpectedly not lock-free).
29525 I'm likely to want to use its result to decide what algorithm to use,
29526 and that algorithm is probably going to allocate new memory
29527 containing atomic objects and then try to act on them.
29528 If I can't predict the lock-freedom of the new object
29529 by checking the lock-freedom of an existing object,
29530 I may discover after starting the algorithm that I can't continue.
29531 </p>
29532
29533 <p><i>[
29534 2009-06-16 Jeffrey Yasskin adds:
29535 ]</i></p>
29536
29537
29538 <blockquote>
29539 <p>
29540 To solve the first problem, I think 2 macros would help:
29541 <tt>MAX_POSSIBLE_LOCK_FREE_SIZE</tt> and <tt>MAX_GUARANTEED_LOCK_FREE_SIZE</tt>,
29542 which expand to the maximum value of <tt>sizeof(T)</tt> for which atomic may
29543 (or will, respectively) use lock-free operations.
29544 Lawrence points out that this
29545 "relies heavily on implementations
29546 using word-size compare-swap on sub-word-size types,
29547 which in turn requires address modulation."
29548 He expects that to be the end state anyway, so it doesn't bother him much.
29549 </p>
29550
29551 <p>
29552 To solve the second,
29553 I think one could specify that equally aligned objects of the same type
29554 will return the same value from <tt>atomic_is_lock_free()</tt>.
29555 I don't know how to specify "equal alignment".
29556 Lawrence suggests an additional function, <tt>atomic_is_always_lock_free()</tt>.
29557 </p>
29558 </blockquote>
29559
29560
29561
29562 <p><b>Proposed resolution:</b></p>
29563
29564
29565
29566
29567
29568 <hr>
29569 <h3><a name="1147"></a>1147. non-volatile atomic functions</h3>
29570 <p><b>Section:</b> 29.6 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
29571  <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2009-06-16  <b>Last modified:</b> 2009-07-04</p>
29572 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics.types.operations">active issues</a> in [atomics.types.operations].</p>
29573 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.operations">issues</a> in [atomics.types.operations].</p>
29574 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
29575 <p><b>Discussion:</b></p>
29576
29577 <p><b>Addresses US 90</b></p>
29578
29579 <p>
29580 The C++0X draft
29581 declares all of the functions dealing with atomics (section 29.6 [atomics.types.operations])
29582 to take volatile arguments.
29583 Yet it also says (29.4-3),
29584 </p>
29585
29586 <blockquote>
29587 <p>
29588 [ Note: Many operations are volatile-qualified.
29589 The "volatile as device register" semantics have not changed in the standard.
29590 This qualification means that volatility is preserved
29591 when applying these operations to volatile objects.
29592 It does not mean that operations on non-volatile objects become volatile.
29593 Thus, volatile qualified operations on non-volatile objects
29594 may be merged under some conditions. &#8212;end note ]
29595 </p>
29596 </blockquote>
29597
29598 <p>
29599 I was thinking about how to implement this in gcc,
29600 and I believe that we'll want to overload most of the functions
29601 on volatile and non-volatile.
29602 Here's why:
29603 </p>
29604
29605 <p>
29606 To let the compiler take advantage of the permission
29607 to merge non-volatile atomic operations and reorder atomics in certain,
29608 we'll need to tell the compiler backend
29609 about exactly which atomic operation was used.
29610 So I expect most of the functions of the form atomic_&lt;op&gt;_explicit()
29611 (e.g. atomic_load_explicit, atomic_exchange_explicit,
29612 atomic_fetch_add_explicit, etc.)
29613 to become compiler builtins.
29614 A builtin can tell whether its argument was volatile or not,
29615 so those functions don't really need extra explicit overloads.
29616 However, I don't expect that we'll want to add builtins
29617 for every function in chapter 29,
29618 since most can be implemented in terms of the _explicit free functions:
29619 </p>
29620
29621 <pre><code>class atomic_int {
29622   __atomic_int_storage value;
29623  public:
29624   int fetch_add(int increment, memory_order order = memory_order_seq_cst) volatile {
29625     // &amp;value has type "volatile __atomic_int_storage*".
29626     atomic_fetch_add_explicit(&amp;value, increment, order);
29627   }
29628   ...
29629 };
29630 </code></pre>
29631
29632 <p>
29633 But now this <em>always</em> calls
29634 the volatile builtin version of atomic_fetch_add_explicit(),
29635 even if the atomic_int wasn't declared volatile.
29636 To preserve volatility and the compiler's permission to optimize,
29637 I'd need to write:
29638 </p>
29639
29640 <pre><code>class atomic_int {
29641   __atomic_int_storage value;
29642  public:
29643   int fetch_add(int increment, memory_order order = memory_order_seq_cst) volatile {
29644     atomic_fetch_add_explicit(&amp;value, increment, order);
29645   }
29646   int fetch_add(int increment, memory_order order = memory_order_seq_cst) {
29647     atomic_fetch_add_explicit(&amp;value, increment, order);
29648   }
29649   ...
29650 };
29651 </code></pre>
29652
29653 <p>
29654 But this is visibly different from the declarations in the standard
29655 because it's now overloaded.
29656 (Consider passing &amp;atomic_int::fetch_add as a template parameter.)
29657 </p>
29658
29659 <p>
29660 The implementation may already have permission to add overloads
29661 to the member functions:
29662 </p>
29663
29664 <blockquote>
29665 <p>
29666 17.6.4.5 [member.functions] An implementation may declare additional non-virtual
29667 member function signatures within a class:<br>
29668 ...
29669 </p>
29670 <ul>
29671 <li>by adding a member function signature for a member function name.</li>
29672 </ul>
29673 </blockquote>
29674
29675 <p>
29676 but I don't see an equivalent permission to add overloads to the free functions.
29677 </p>
29678
29679 <p><i>[
29680 2009-06-16 Lawrence adds:
29681 ]</i></p>
29682
29683
29684 <blockquote>
29685 <p>
29686 I recommend allowing non-volatile overloads.
29687 </p>
29688 </blockquote>
29689
29690
29691
29692 <p><b>Proposed resolution:</b></p>
29693
29694
29695
29696
29697
29698 <hr>
29699 <h3><a name="1148"></a>1148. Wrong argument type of I/O stream manipulators <tt>setprecision()</tt>
29700 and <tt>setw()</tt></h3>
29701 <p><b>Section:</b> 27.7 [iostream.format] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
29702  <b>Submitter:</b> Marc Steinbach <b>Opened:</b> 2009-06-20  <b>Last modified:</b> 2009-07-30</p>
29703 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.format">issues</a> in [iostream.format].</p>
29704 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
29705 <p><b>Discussion:</b></p>
29706 <p>
29707 The header <tt>&lt;iomanip&gt;</tt> synopsis in 27.7 [iostream.format] specifies
29708 </p>
29709 <blockquote><pre>T5 setprecision(int n);
29710 T6 setw(int n);
29711 </pre></blockquote>
29712
29713 <p>
29714 The argument types should be streamsize, as in class <tt>ios_base</tt>
29715 (see 27.5.2 [ios.base]):
29716 </p>
29717 <blockquote><pre>streamsize precision() const;
29718 streamsize precision(streamsize prec);
29719 streamsize width() const;
29720 streamsize width(streamsize wide);
29721 </pre></blockquote>
29722
29723 <p>
29724 (Editorial: 'wide' should probably be renamed as 'width', or maybe just 'w'.)
29725 </p>
29726
29727 <p><i>[
29728 2009-07-29 Daniel clarified wording.
29729 ]</i></p>
29730
29731
29732
29733 <p><b>Proposed resolution:</b></p>
29734 <ol>
29735 <li>
29736 <p>
29737 In 27.7 [iostream.format], header <tt>&lt;iomanip&gt;</tt> synopsis change as indicated:
29738 </p>
29739
29740 <blockquote><pre>T5 setprecision(<del>int</del><ins>streamsize</ins> n);
29741 T6 setw(<del>int</del><ins>streamsize</ins> n);
29742 </pre></blockquote>
29743 </li>
29744
29745 <li>
29746 <p>
29747 In 27.7.3 [std.manip], just before p. 6 change as indicated:
29748 </p>
29749
29750 <blockquote><pre>unspecified setprecision(<del>int</del><ins>streamsize</ins> n);
29751 </pre></blockquote>
29752 </li>
29753
29754 <li>
29755 <p>
29756 In 27.7.3 [std.manip], just before p. 7 change as indicated:
29757 </p>
29758
29759 <blockquote><pre>unspecified setw(<del>int</del><ins>streamsize</ins> n);
29760 </pre></blockquote>
29761 </li>
29762 </ol>
29763
29764
29765
29766
29767
29768
29769
29770
29771 <hr>
29772 <h3><a name="1150"></a>1150. wchar_t, char16_t and char32_t filenames</h3>
29773 <p><b>Section:</b> 27.9.1.14 [fstream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
29774  <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-07-04</p>
29775 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
29776 <p><b>Discussion:</b></p>
29777 <p><b>Addresses JP 73</b></p>
29778
29779    <p><b>Description</b></p>
29780         <p>It is a problem
29781         from C++98, <tt>fstream</tt> cannot appoint a filename of wide
29782         character string(<tt>const wchar_t</tt> and <tt>const wstring&amp;</tt>).</p>
29783 <p><b>Suggestion</b></p>
29784         <p>Add
29785         interface corresponding to <tt>wchar_t</tt>, <tt>char16_t</tt> and <tt>char32_t</tt>.</p>
29786
29787 <p><i>[
29788 2009-07-01 Alisdair notes that this is a duplicate of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#454">454</a> which has more
29789 in-depth rationale.
29790 ]</i></p>
29791
29792
29793
29794 <p><b>Proposed resolution:</b></p>
29795
29796
29797
29798
29799
29800 <hr>
29801 <h3><a name="1151"></a>1151. Behavior of the library in the presence of threads is incompletely specified</h3>
29802 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
29803  <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-06-28</p>
29804 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
29805 <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>
29806 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
29807 <p><b>Discussion:</b></p>
29808 <p><b>Addresses US 63</b></p>
29809
29810    <p><b>Description</b></p>
29811         <p>The behavior of the library in the presence of threads
29812         is incompletely specified.</p>
29813         <p>For example, if thread 1 assigns to <tt>X</tt>, then writes data
29814         to file <tt>f</tt>, which is read by thread 2, and then accesses
29815         variable <tt>X</tt>, is thread 2 guaranteed to be able to see the
29816         value assigned to <tt>X</tt> by thread 1? In other words, does the
29817         write of the data "happen before" the read?</p>
29818         <p>Another example: does simultaneous access using <tt>operator
29819         at()</tt> to different characters in the same non-const string
29820         really introduce a data race?</p>
29821 <p><b>Suggestion</b></p>
29822 <p><b>Notes</b></p><p>17 SG: should go to threads group; misclassified in document
29823 </p>
29824
29825     <p>Concurrency SG: Create an issue. Hans will look into it.</p>
29826
29827
29828 <p><b>Proposed resolution:</b></p>
29829
29830
29831
29832
29833
29834 <hr>
29835 <h3><a name="1152"></a>1152. expressions parsed differently than intended</h3>
29836 <p><b>Section:</b> 22.4.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
29837  <b>Submitter:</b> Seungbeom Kim <b>Opened:</b> 2009-06-27  <b>Last modified:</b> 2009-07-24</p>
29838 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.put.virtuals">active issues</a> in [facet.num.put.virtuals].</p>
29839 <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>
29840 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
29841 <p><b>Discussion:</b></p>
29842 <p>
29843 In Table 73 -- Floating-point conversions, 22.4.2.2.2 [facet.num.put.virtuals],
29844 in
29845 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>,
29846 we have the following entries:
29847 </p>
29848 <table border="1">
29849 <caption>Table 73 &#8212; Floating-point conversions</caption>
29850 <tbody><tr>
29851 <th>State</th> <th><tt>stdio</tt> equivalent</th>
29852 </tr>
29853 <tr>
29854 <td><tt>floatfield == ios_base::fixed | ios_base::scientific &amp;&amp; !uppercase</tt></td>
29855 <td align="center"><tt>%a</tt></td>
29856 </tr>
29857
29858 <tr>
29859 <td><tt>floatfield == ios_base::fixed | ios_base::scientific</tt></td>
29860 <td align="center"><tt>%A</tt></td>
29861 </tr>
29862 </tbody></table>
29863
29864 <p>
29865 These expressions are supposed to mean:
29866 </p>
29867
29868 <blockquote><pre>floatfield == (ios_base::fixed | ios_base::scientific) &amp;&amp; !uppercase
29869 floatfield == (ios_base::fixed | ios_base::scientific)
29870 </pre></blockquote>
29871 <p>
29872 but technically parsed as:
29873 </p>
29874 <blockquote><pre>((floatfield == ios_base::fixed) | ios_base::scientific) &amp;&amp; (!uppercase)
29875 ((floatfield == ios_base::fixed) | ios_base::scientific)
29876 </pre></blockquote>
29877 <p>
29878 and should be corrected with additional parentheses, as shown above.
29879 </p>
29880
29881
29882 <p><b>Proposed resolution:</b></p>
29883 <p>
29884 Change Table 73 &#8212; Floating-point conversions in  22.4.2.2.2 [facet.num.put.virtuals]:
29885 </p>
29886
29887 <table border="1">
29888 <caption>Table 73 &#8212; Floating-point conversions</caption>
29889 <tbody><tr>
29890 <th>State</th> <th><tt>stdio</tt> equivalent</th>
29891 </tr>
29892 <tr>
29893 <td><tt>floatfield == <ins>(</ins>ios_base::fixed | ios_base::scientific<ins>)</ins> &amp;&amp; !uppercase</tt></td>
29894 <td align="center"><tt>%a</tt></td>
29895 </tr>
29896
29897 <tr>
29898 <td><tt>floatfield == <ins>(</ins>ios_base::fixed | ios_base::scientific<ins>)</ins></tt></td>
29899 <td align="center"><tt>%A</tt></td>
29900 </tr>
29901 </tbody></table>
29902
29903
29904
29905
29906
29907 <hr>
29908 <h3><a name="1153"></a>1153. Standard library needs review for constructors to be
29909 explicit to avoid treatment as initializer-list constructor</h3>
29910 <p><b>Section:</b> 17 [library], 30 [thread], D [depr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
29911  <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-07-04</p>
29912 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
29913 <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>
29914 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
29915 <p><b>Discussion:</b></p>
29916
29917 <p><b>Addresses DE 2</b></p>
29918
29919 <p><b>Description</b></p>
29920         <p>Marking a constructor with <tt>explicit</tt> has semantics
29921         even for a constructor with zero or several parameters:
29922         Such a constructor cannot be used with list-initialization
29923         in a copy-initialization context, see 13.3.1.7 [over.match.list]. The
29924         standard library apparently has not been reviewed for
29925         marking non-single-parameter constructors as <tt>explicit</tt>.</p>
29926 <p><b>Suggestion</b></p>
29927         <p>Consider marking zero-parameter and multi-parameter
29928         constructors <tt>explicit</tt> in classes that have at least one
29929         constructor marked <tt>explicit</tt> and that do not have an
29930         initializer-list constructor.</p>
29931
29932 <p><b>Notes</b></p>
29933         <p>Robert Klarer to address this one.</p>
29934
29935
29936
29937 <p><b>Proposed resolution:</b></p>
29938
29939
29940
29941
29942
29943 <hr>
29944 <h3><a name="1154"></a>1154. <tt>complex</tt> should accept integral types</h3>
29945 <p><b>Section:</b> 26.4 [complex.numbers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
29946  <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-07-04</p>
29947 <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>
29948 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
29949 <p><b>Discussion:</b></p>
29950
29951 <p><b>Addresses FR 35</b></p>
29952
29953 <p><b>Description</b></p>
29954         <p>Instantiations of the class
29955         template <tt>complex&lt;&gt;</tt> have to be allowed for integral
29956         types, to reflect existing practice and ISO standards
29957         (LIA-III).</p>
29958
29959 <p><b>Suggestion</b></p>
29960
29961
29962
29963 <p><b>Proposed resolution:</b></p>
29964
29965
29966
29967
29968
29969 <hr>
29970 <h3><a name="1155"></a>1155. Reference should be to C99</h3>
29971 <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#New">New</a>
29972  <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-07-25</p>
29973 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#diff.library">active issues</a> in [diff.library].</p>
29974 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#diff.library">issues</a> in [diff.library].</p>
29975 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
29976 <p><b>Discussion:</b></p>
29977
29978 <p><b>Addresses FR 38</b></p>
29979
29980 <p><b>Description</b></p>
29981         <p>What is ISO/IEC 1990:9899/DAM
29982         1? My guess is that's a typo for ISO/IEC
29983         9899/Amd.1:1995 which I'd
29984         have expected to be referenced here (the tables
29985         make reference to things
29986         which were introduced by Amd.1).</p>
29987 <p><b>Suggestion</b></p>
29988         <p>One need probably a reference
29989         to the document which introduce <tt>char16_t</tt> and
29990         <tt>char32_t</tt> in C (ISO/IEC TR 19769:2004?).</p>
29991 <p><b>Notes</b></p>
29992 <p>Create issue. Document in question should be C99, not C90+amendment1. The
29993     rest of the section requires careful review for completeness. Example &lt;cstdint&gt;
29994     18.4.1 [cstdint.syn]. Assign to C liasons.</p>
29995
29996
29997
29998 <p><b>Proposed resolution:</b></p>
29999
30000
30001
30002
30003
30004 <hr>
30005 <h3><a name="1156"></a>1156. Constraints on bitmask and enumeration types to be tightened</h3>
30006 <p><b>Section:</b> 17.5.2.1.2 [enumerated.types], 17.5.2.1.3 [bitmask.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
30007  <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-07-25</p>
30008 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
30009 <p><b>Discussion:</b></p>
30010
30011 <p><b>Addresses UK 165</b></p>
30012
30013 <p><b>Description</b></p>
30014         <p>Constraints on
30015         bitmask and enumeration types were supposed to be tightened
30016         up as part of the motivation for the <tt>constexpr</tt> feature -
30017         see paper
30018         <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf">N2235</a>
30019         for details</p>
30020 <p><b>Suggestion</b></p>
30021         <p>Adopt wording in line with the motivation
30022         described in
30023         <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf">N2235</a></p>
30024 <p><b>Notes</b></p>
30025         <p>Robert Klarer to review</p>
30026
30027
30028
30029 <p><b>Proposed resolution:</b></p>
30030
30031
30032
30033
30034
30035 <hr>
30036 <h3><a name="1157"></a>1157. Local types can now instantiate templates</h3>
30037 <p><b>Section:</b> 17.6.3.2.1 [namespace.std] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
30038  <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-07-28</p>
30039 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
30040 <p><b>Discussion:</b></p>
30041
30042 <p><b>Addresses UK 175</b></p>
30043
30044 <p><b>Description</b></p>
30045         <p>Local types can
30046         now be used to instantiate templates, but don't have
30047         external linkage.</p>
30048 <p><b>Suggestion</b></p>
30049         <p>Remove the reference to external linkage.</p>
30050
30051 <p><b>Notes</b></p>
30052 <p>We accept the proposed solution. Martin will draft an issue.</p>
30053
30054 <p><i>[
30055 2009-07-28 Alisdair provided wording.
30056 ]</i></p>
30057
30058
30059
30060
30061 <p><b>Proposed resolution:</b></p>
30062 <p>
30063 17.6.3.2.1 [namespace.std]
30064 </p>
30065 <p>
30066 Strike "of external linkage" in p1 and p2:
30067 </p>
30068
30069 <blockquote>
30070 <p>
30071 -1- The behavior of a C++ program is undefined if it adds declarations or
30072 definitions to namespace <tt>std</tt> or to a namespace within namespace <tt>std</tt>
30073 unless otherwise specified. A program may add a concept map for any
30074 standard library concept or a template specialization for any standard
30075 library template to namespace <tt>std</tt> only if the declaration depends on a
30076 user-defined type <del>of external linkage</del> and the specialization meets the
30077 standard library requirements for the original template and is not
30078 explicitly prohibited.<sup>179</sup>
30079 </p>
30080
30081 <p>
30082 -2- The behavior of a C++ program is undefined if it declares
30083 </p>
30084 <ul>
30085 <li>
30086 an explicit specialization of any member function of a standard library
30087 class template, or
30088 </li>
30089 <li>
30090 an explicit specialization of any member function template of a standard
30091 library class or class template, or
30092 </li>
30093 <li>
30094 an explicit or partial specialization of any member class template of a
30095 standard library class or class template.
30096 </li>
30097 </ul>
30098 <p>
30099 A program may explicitly instantiate a template defined in the standard
30100 library only if the declaration depends on the name of a user-defined
30101 type <del>of external linkage</del> and the instantiation meets the standard
30102 library requirements for the original template.
30103 </p>
30104 </blockquote>
30105
30106
30107
30108
30109
30110
30111 <hr>
30112 <h3><a name="1158"></a>1158. Encouragement to use monotonic clock</h3>
30113 <p><b>Section:</b> 30.2.4 [thread.req.timing] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
30114  <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-07-05</p>
30115 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
30116 <p><b>Discussion:</b></p>
30117
30118 <p><b>Addresses UK 322, US 96</b></p>
30119
30120 <p><b>Description</b></p>
30121         <p>Not all systems
30122         can provide a monotonic clock. How are they expected to
30123         treat a _for function?</p>
30124 <p><b>Suggestion</b></p>
30125         <p>Add at least a note explaining the intent
30126         for systems that do not support a monotonic clock.</p>
30127
30128 <p><b>Notes</b></p>
30129 <p>Create an issue, together with UK 96. Note that the specification as is
30130     already allows a non-monotonic clock due to the word &#8220;should&#8221; rather than
30131     &#8220;shall&#8221;. If this wording is kept, a footnote should be added to make the
30132     meaning clear.</p>
30133
30134 <p><i>[ 2009-06-29 Beman provided a proposed resolution. ] </i></p>
30135
30136
30137
30138 <p><b>Proposed resolution:</b></p>
30139
30140 <p><i>Change Timing specifications 30.2.4 [thread.req.timing] as indicated:</i></p>
30141
30142 <p>The member functions whose names end in <tt>_for</tt> take an argument that
30143 specifies a relative time. Implementations
30144 <del>should</del> <ins>are encouraged but not required to</ins> use a
30145 monotonic clock to measure time for these functions.</p>
30146
30147
30148
30149
30150
30151
30152 <hr>
30153 <h3><a name="1159"></a>1159. Unclear spec for <tt>resource_deadlock_would_occur</tt></h3>
30154 <p><b>Section:</b> 30.4.3.2.2 [thread.lock.unique.locking] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
30155  <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-07-04</p>
30156 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.lock.unique.locking">active issues</a> in [thread.lock.unique.locking].</p>
30157 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.lock.unique.locking">issues</a> in [thread.lock.unique.locking].</p>
30158 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
30159 <p><b>Discussion:</b></p>
30160
30161 <p><b>Addresses UK 327, UK 328</b></p>
30162
30163 <p><b>UK 327 Description</b></p>
30164         <p>Not clear what
30165         the specification for error condition
30166         <tt>resource_deadlock_would_occur</tt> means. It is perfectly
30167         possible for this thread to own the mutex without setting
30168         owns to true on this specific lock object. It is also
30169         possible for lock operations to succeed even if the thread
30170         does own the mutex, if the mutex is recursive. Likewise, if
30171         the mutex is not recursive and the mutex has been locked
30172         externally, it is not always possible to know that this
30173         error condition should be raised, depending on the host
30174         operating system facilities. It is possible that 'i.e.' was
30175         supposed to be 'e.g.' and that suggests that recursive
30176         locks are not allowed. That makes sense, as the
30177         exposition-only member owns is boolean and not a integer to
30178         count recursive locks.</p>
30179
30180 <p><b>UK 327 Suggestion</b></p>
30181         <p>Add a precondition <tt>!owns</tt>. Change the 'i.e.'
30182         in the error condition to be 'e.g.' to allow for this
30183         condition to propogate deadlock detection by the host OS.</p>
30184 <p><b>UK 327 Notes</b></p>
30185 <p>Create an issue. Assigned to Lawrence Crowl. Note: not sure what try_lock
30186     means for recursive locks when you are the owner. POSIX has language on
30187     this, which should ideally be followed. Proposed fix is not quite right, for
30188     example, try_lock should have different wording from lock.</p>
30189
30190 <p><b>UK 328 Description</b></p>
30191
30192         <p>There is a missing precondition that <tt>owns</tt>
30193         is true, or an <tt>if(owns)</tt> test is missing from the effect
30194         clause</p>
30195 <p><b>UK 328 Suggestion</b></p>
30196         <p>Add a
30197         precondition that <tt>owns == true</tt>. Add an error condition to
30198         detect a violation, rather than yield undefined behaviour.</p>
30199 <p><b>UK 328 Notes</b></p>
30200 <p>Handle in same issue as UK 327. Also uncertain that the proposed resolution
30201     is the correct one.</p>
30202
30203
30204
30205
30206 <p><b>Proposed resolution:</b></p>
30207
30208
30209
30210
30211
30212 <hr>
30213 <h3><a name="1160"></a>1160. <tt>future_error</tt> public constructor is 'exposition only'</h3>
30214 <p><b>Section:</b> 30.6.3 [futures.future_error] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
30215  <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-07-17</p>
30216 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
30217 <p><b>Discussion:</b></p>
30218
30219 <p><b>Addresses UK 331</b></p>
30220
30221 <p><b>Description</b></p>
30222         <p>Not clear what
30223         it means for a public constructor to be 'exposition only'.
30224         If the intent is purely to support the library calling this
30225         constructor then it can be made private and accessed
30226         through friendship. Otherwise it should be documented for
30227         public consumption.</p>
30228 <p><b>Suggestion</b></p>
30229         <p>Declare the constructor as private with a
30230         note about intended friendship, or remove the
30231         exposition-only comment and document the semantics.</p>
30232 <p><b>Notes</b></p>
30233 <p>Create an issue. Assigned to Detlef. Suggested resolution probably makes
30234     sense.</p>
30235
30236 <p><i>[
30237 2009-07 Frankfurt
30238 ]</i></p>
30239
30240
30241 <blockquote>
30242 Pending a paper from Anthony Williams / Detleff Volleman.
30243 </blockquote>
30244
30245
30246
30247 <p><b>Proposed resolution:</b></p>
30248
30249
30250
30251
30252
30253 <hr>
30254 <h3><a name="1161"></a>1161. Unnecessary <tt>unique_future</tt> limitations</h3>
30255 <p><b>Section:</b> 30.6.5 [futures.unique_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
30256  <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-07-17</p>
30257 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.unique_future">active issues</a> in [futures.unique_future].</p>
30258 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.unique_future">issues</a> in [futures.unique_future].</p>
30259 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
30260 <p><b>Discussion:</b></p>
30261
30262 <p><b>Addresses UK 336</b></p>
30263
30264 <p><b>Description</b></p>
30265
30266         <p>It is possible
30267         to transfer ownership of the asynchronous result from one
30268         unique_future instance to another via the move-constructor.
30269         However, it is not possible to transfer it back, and nor is
30270         it possible to create a default-constructed unique_future
30271         instance to use as a later move target. This unduly limits
30272         the use of <tt>unique_future</tt> in code. Also, the lack of a
30273         move-assignment operator restricts the use of <tt>unique_future</tt>
30274         in containers such as <tt>std::vector</tt> - <tt>vector::insert</tt> requires
30275         move-assignable for example.</p>
30276 <p><b>Suggestion</b></p>
30277         <p>Add a default constructor with the
30278         semantics that it creates a <tt>unique_future</tt> with no
30279         associated asynchronous result. Add a move-assignment
30280         operator which transfers ownership.</p>
30281 <p><b>Notes</b></p>
30282 <p>Create an issue. Detlef will look into it.</p>
30283
30284 <p><i>[
30285 2009-07 Frankfurt
30286 ]</i></p>
30287
30288
30289 <blockquote>
30290 Pending a paper from Anthony Williams / Detleff Volleman.
30291 </blockquote>
30292
30293
30294
30295 <p><b>Proposed resolution:</b></p>
30296
30297
30298
30299
30300
30301 <hr>
30302 <h3><a name="1162"></a>1162. <tt>shared_future</tt> should support an efficient move constructor</h3>
30303 <p><b>Section:</b> 30.6.6 [future.shared_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
30304  <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-07-17</p>
30305 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#future.shared_future">active issues</a> in [future.shared_future].</p>
30306 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#future.shared_future">issues</a> in [future.shared_future].</p>
30307 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
30308 <p><b>Discussion:</b></p>
30309
30310 <p><b>Addresses UK 337</b></p>
30311
30312 <p><b>Description</b></p>
30313         <p><tt>shared_future</tt>
30314         should support an efficient move constructor that can avoid
30315         unnecessary manipulation of a reference count, much like
30316         <tt>shared_ptr</tt></p>
30317 <p><b>Suggestion</b></p>
30318         <p>Add a move constructor</p>
30319 <p><b>Notes</b></p>
30320 <p>Create an issue. Detlef will look into it.</p>
30321
30322 <p><i>[
30323 2009-07 Frankfurt
30324 ]</i></p>
30325
30326
30327 <blockquote>
30328 Pending a paper from Anthony Williams / Detleff Volleman.
30329 </blockquote>
30330
30331
30332
30333 <p><b>Proposed resolution:</b></p>
30334
30335
30336
30337
30338
30339 <hr>
30340 <h3><a name="1163"></a>1163. <tt>shared_future</tt> is inconsistent with <tt>shared_ptr</tt></h3>
30341 <p><b>Section:</b> 30.6.6 [future.shared_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
30342  <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-07-17</p>
30343 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#future.shared_future">active issues</a> in [future.shared_future].</p>
30344 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#future.shared_future">issues</a> in [future.shared_future].</p>
30345 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
30346 <p><b>Discussion:</b></p>
30347
30348 <p><b>Addresses UK 338</b></p>
30349
30350 <p><b>Description</b></p>
30351
30352         <p><tt>shared_future</tt> is currently
30353         CopyConstructible, but not CopyAssignable. This is
30354         inconsistent with <tt>shared_ptr</tt>, and will surprise users.
30355         Users will then write work-arounds to provide this
30356         behaviour. We should provide it simply and efficiently as
30357         part of shared_future. Note that since the shared_future
30358         member functions for accessing the state are all declared
30359         const, the original usage of an immutable shared_future
30360         value that can be freely copied by multiple threads can be
30361         retained by declaring such an instance as "<tt>const
30362         shared_future</tt>".</p>
30363 <p><b>Suggestion</b></p>
30364         <p>Remove "=delete"
30365         from the copy-assignment operator of shared_future. Add a
30366         move-constructor <tt>shared_future(shared_future&amp;&amp;
30367         rhs)</tt>, and a move-assignment operator <tt>shared_future&amp;
30368         operator=(shared_future&amp;&amp; rhs)</tt>. The postcondition
30369         for the copy-assignment operator is that <tt>*this</tt> has the same
30370         associated state as <tt>rhs</tt>. The postcondition for the
30371         move-constructor and move assignment is that <tt>*this</tt> has the
30372         same associated as <tt>rhs</tt> had before the
30373         constructor/assignment call and that <tt>rhs</tt> has no associated
30374         state.</p>
30375 <p><b>Notes</b></p>
30376 <p>Create an issue. Detlef will look into it.</p>
30377
30378 <p><i>[
30379 2009-07 Frankfurt
30380 ]</i></p>
30381
30382
30383 <blockquote>
30384 Pending a paper from Anthony Williams / Detleff Volleman.
30385 </blockquote>
30386
30387
30388
30389 <p><b>Proposed resolution:</b></p>
30390
30391
30392
30393
30394
30395 <hr>
30396 <h3><a name="1165"></a>1165. Unneeded promise move constructor</h3>
30397 <p><b>Section:</b> 30.6.4 [futures.promise] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
30398  <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-07-17</p>
30399 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#futures.promise">active issues</a> in [futures.promise].</p>
30400 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures.promise">issues</a> in [futures.promise].</p>
30401 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
30402 <p><b>Discussion:</b></p>
30403
30404 <p><b>Addresses UK 343</b></p>
30405
30406 <p><b>Description</b></p>
30407         <p>The move constructor of a std::promise
30408         object does not need to allocate any memory, so the
30409         move-construct-with-allocator overload of the constructor
30410         is superfluous.</p>
30411 <p><b>Suggestion</b></p>
30412         <p>Remove the
30413         constructor with the signature <tt>template &lt;class
30414         Allocator&gt; promise(allocator_arg_t, const Allocator&amp;
30415         a, promise&amp; rhs);</tt></p>
30416 <p><b>Notes</b></p>
30417 <p>Create an issue. Detlef will look into it. Will solicit feedback from Pablo.
30418     Note that &#8220;rhs&#8221; argument should also be an rvalue reference in any case.</p>
30419
30420 <p><i>[
30421 2009-07 Frankfurt
30422 ]</i></p>
30423
30424
30425 <blockquote>
30426 Pending a paper from Anthony Williams / Detleff Volleman.
30427 </blockquote>
30428
30429
30430
30431 <p><b>Proposed resolution:</b></p>
30432
30433
30434
30435
30436
30437 <hr>
30438 <h3><a name="1166"></a>1166. Allocator-specific move/copy break model of move-constructor and
30439         move-assignment</h3>
30440 <p><b>Section:</b> X [allocator.propagation], X [allocator.propagation.map], 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
30441  <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-07-04</p>
30442 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
30443 <p><b>Discussion:</b></p>
30444
30445 <p><b>Addresses US 77</b></p>
30446
30447 <p><b>Description</b></p>
30448         <p>Allocator-specific move and copy behavior for containers
30449         (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>) complicates a little-used and already-complicated
30450         portion of the standard library (allocators), and breaks
30451         the conceptual model of move-constructor and
30452         move-assignment operations on standard containers being
30453         efficient operations. The extensions for allocator-specific
30454         move and copy behavior should be removed from the working
30455         paper.</p>
30456         <p>With the
30457         introduction of rvalue references, we are teaching
30458         programmers that moving from a standard container (e.g., a
30459         <tt>vector&lt;string&gt;</tt>) is an efficient, constant-time
30460         operation. The introduction of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a> removed that
30461         guarantee; depending on the behavior of four different
30462         traits (20.8.4), the complexity of copy and move operations
30463         can be constant or linear time. This level of customization
30464         greatly increases the complexity of standard containers,
30465         and benefits only a tiny fraction of the C++ community.</p>
30466 <p><b>Suggestion</b></p>
30467
30468         <p>Remove 20.8.4.</p>
30469
30470         <p>Remove 20.8.5.</p>
30471
30472         <p>Remove all references to the facilities in
30473         20.8.4 and 20.8.5 from clause 23.</p>
30474
30475
30476
30477
30478 <p><b>Proposed resolution:</b></p>
30479
30480
30481
30482
30483
30484 <hr>
30485 <h3><a name="1169"></a>1169. <tt>num_get</tt> not fully compatible with <tt>strto*</tt></h3>
30486 <p><b>Section:</b> 22.4.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
30487  <b>Submitter:</b> Cosmin Truta <b>Opened:</b> 2009-07-04  <b>Last modified:</b> 2009-07-07</p>
30488 <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>
30489 <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>
30490 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
30491 <p><b>Discussion:</b></p>
30492 <p>
30493 As specified in the latest draft,
30494 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>,
30495 <code>num_get</code> is still not fully compatible with the following C
30496 functions: <code>strtoul</code>, <code>strtoull</code>,
30497 <code>strtof</code> and
30498 <code>strtod</code>.
30499 </p>
30500 <p>
30501 In C, when conversion of a string to an unsigned integer type falls
30502 outside the
30503 representable range, <code>strtoul</code> and <code>strtoull</code> return
30504 <code>ULONG_MAX</code> and <code>ULLONG_MAX</code>, respectively,
30505 regardless
30506 whether the input field represents a positive or a negative value.
30507 On the other hand, the result of <code>num_get</code> conversion of
30508 negative
30509 values to unsigned integer types is zero. This raises a compatibility
30510 issue.
30511 </p>
30512 <p>
30513 Moreover, in C, when conversion of a string to a floating-point type falls
30514 outside the representable range, <code>strtof</code>, <code>strtod</code>
30515 and
30516 <code>strtold</code> return <code>±HUGE_VALF</code>,
30517 <code>±HUGE_VAL</code> and <code>±HUGE_VALL</code>, respectively.
30518 On the other hand, the result of <code>num_get</code> conversion of such
30519 out-of-range floating-point values results in the most positive/negative
30520 representable value.
30521 Although many C library implementations do implement <code>HUGE_VAL</code>
30522 (etc.) as the highest representable (which is, usually, the infinity),
30523 this
30524 isn't required by the C standard. The C library specification makes no
30525 statement regarding the value of <code>HUGE_VAL</code> and friends, which
30526 potentially raises the same compatibility issue as in the above case of
30527 unsigned integers.
30528 In addition, neither C nor C++ define symbolic constants for the maximum
30529 representable floating-point values (they only do so only for the maximum
30530 representable <i>finite</i> floating-point values), which raises a
30531 usability
30532 issue (it would be hard for the programmer to check the result of
30533 <code>num_get</code> against overflow).
30534 </p>
30535 <p>
30536 As such, we propose to adjust the specification of <code>num_get</code> to
30537 closely follow the behavior of all of its underlying C functions.
30538 </p>
30539
30540
30541 <p><b>Proposed resolution:</b></p>
30542
30543 <p>
30544 Change 22.4.2.1.2 [facet.num.get.virtuals] as follows:
30545 </p>
30546 <blockquote>
30547 <p>
30548 <b>Stage 3:</b>
30549 The sequence of <code>char</code>s accumulated in stage 2 (the field) is
30550 converted to a numeric value by the rules of one of the functions declared in
30551 the header <code>&lt;cstdlib&gt;</code>:
30552 </p>
30553 <ul>
30554 <li>For a signed integer value, the function <code>strtoll</code>.</li>
30555 <li>For an unsigned integer value, the function <code>strtoull</code>.</li>
30556 <li><ins>For a <code>float</code> value, the function
30557     <code>strtof</code>.</ins></li>
30558 <li><ins>For a <code>double</code> value, the function
30559     <code>strtod</code>.</ins></li>
30560 <li>For a <del>floating-point</del> <ins><code>long double</code></ins>
30561     value, the function <code>strtold</code>.</li>
30562 </ul>
30563 <p>
30564 The numeric value to be stored can be one of:
30565 </p>
30566 <ul>
30567 <li>zero, if the conversion function fails to convert the entire field.
30568     <del><code>ios_base::failbit</code> is assigned to <code>err</code>.</del></li>
30569 <li>the most positive <ins>(or negative)</ins> representable value, if
30570     the field <ins>to be converted to a signed integer type</ins> represents a
30571     value too large positive <ins>(or negative)</ins> to be represented in
30572     <code>val</code>.
30573     <del><code>ios_base::failbit</code> is assigned to <code>err</code>.</del></li>
30574 <li><del>the most negative representable value or zero for an unsigned integer
30575     type, if the field represents a value too large negative to be represented
30576     in <code>val</code>.
30577     <code>ios_base::failbit</code> is assigned to <code>err</code>.</del></li>
30578 <li><ins>the most positive representable value, if the field to be converted to
30579     an unsigned integer type represents a value that cannot be represented in
30580     <code>val</code>.</ins></li>
30581 <li>the converted value, otherwise.</li>
30582 </ul>
30583 <p>
30584 The resultant numeric value is stored in <code>val</code>.
30585 <ins>If the conversion function fails to convert the entire field, or if the
30586 field represents a value outside the range of representable values,
30587 <code>ios_base::failbit</code> is assigned to <code>err</code>.</ins>
30588 </p>
30589 </blockquote>
30590
30591
30592
30593
30594
30595
30596 <hr>
30597 <h3><a name="1170"></a>1170. String <i>char-like types</i> no longer PODs</h3>
30598 <p><b>Section:</b> 21.1 [strings.general] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
30599  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-06-22  <b>Last modified:</b> 2009-07-28</p>
30600 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
30601 <p><b>Discussion:</b></p>
30602
30603 <p>Prior to the introduction of constant expressions into the library,
30604 <tt>basic_string</tt> elements had to be POD types, and thus had to be both trivially
30605 copyable and standard-layout. This ensured that they could be memcpy'ed and
30606 would be compatible with other libraries and languages, particularly the C
30607 language and its library.</p>
30608 <p>
30609 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2349.pdf">N2349</a>,
30610 Constant Expressions in the Standard Library Revision 2, changed the
30611 requirement in 21/1 from "POD type" to "literal type". That change had the
30612 effect of removing the trivially copyable and standard-layout requirements from
30613 <tt>basic_string</tt> elements.</p>
30614 <p>This means that <tt>basic_string</tt> elements no longer are guaranteed to be
30615 memcpy'able, and are no longer guaranteed to be standard-layout types:</p>
30616 <blockquote>
30617   <p>3.9/p2 and 3.9/p3 both make it clear that a "trivially copyable type" is
30618   required for memcpy to be guaranteed to work.</p>
30619   <p>Literal types (3.9p12) may have a non-trivial copy assignment operator, and
30620   that violates the trivially copyable requirements given in 9/p 6, bullet item
30621   2. </p>
30622   <p>Literal types (3.9p12) have no standard-layout requirement, either.</p>
30623 </blockquote>
30624 <p>This situation probably arose because the wording for "Constant Expressions
30625 in the Standard Library" was in process at the same time the C++ POD
30626 deconstruction wording was in process. </p>
30627 <p>Since trivially copyable types meet the C++0x requirements for literal types,
30628 and thus work with constant expressions, it seems an easy fix to revert the
30629 <tt>basic_string</tt> element wording to its original state.</p>
30630
30631  <p><i>[
30632  2009-07-28 Alisdair adds:
30633  ]</i></p>
30634
30635
30636 <blockquote>
30637 When looking for any resolution for this issue, consider the definition of
30638 "character container type" in 17.3.4 [defns.character.container].  This
30639 does require the character type to be a POD, and this term is used in a
30640 number of places through clause 21 and 28. This suggests the PODness
30641 constraint remains, but is much more subtle than before.  Meanwhile, I
30642 suspect the change from POD type to literal type was intentional with
30643 the assumption that trivially copyable types with
30644 non-trivial-but-constexpr constructors should serve as well.  I don't
30645 believe the current wording offers the right guarantees for either of
30646 the above designs.
30647 </blockquote>
30648
30649
30650
30651 <p><b>Proposed resolution:</b></p>
30652
30653 <p><i>Change General 21.1 [strings.general] as indicated:</i></p>
30654 <blockquote>
30655 <p>This Clause describes components for manipulating sequences of any <del>literal</del> <ins>POD</ins>
30656 (3.9) type. In this Clause
30657 such types are called <i>char-like types</i>, and objects of char-like types are
30658 called <i>char-like objects</i> or simply <i>characters</i>.</p>
30659 </blockquote>
30660
30661
30662
30663
30664
30665
30666 <hr>
30667 <h3><a name="1171"></a>1171. duration types shoud be literal</h3>
30668 <p><b>Section:</b> 20.9.3 [time.duration] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
30669  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-07-06  <b>Last modified:</b> 2009-07-07</p>
30670 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.duration">active issues</a> in [time.duration].</p>
30671 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration">issues</a> in [time.duration].</p>
30672 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
30673 <p><b>Discussion:</b></p>
30674 <p>
30675 The <tt>duration</tt> types in 20.9.3 [time.duration] are exactly the sort of type
30676 that should be "literal types" in the new standard.  Likewise,
30677 arithmetic operations on <tt>duration</tt>s should be declared <tt>constexpr</tt>.
30678 </p>
30679
30680
30681 <p><b>Proposed resolution:</b></p>
30682 <p>
30683 Add <tt>constexpr</tt> to declaration of following functions and constructors:
30684 </p>
30685 <p>
30686 p1 20.9 [time]
30687 </p>
30688
30689 <blockquote>
30690 <p>
30691 <b>Header <tt>&lt;chrono&gt;</tt> synopsis</b>
30692 </p>
30693
30694 <p><i>[Draughting note - observe switch to pass-by-value to support constexpr]</i></p>
30695
30696
30697 <pre><i>// duration arithmetic</i>
30698 template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
30699    typename common_type&lt;duration&lt;Rep1, Period1&gt;, duration&lt;Rep2, Period2&gt;&gt;::type
30700    <ins>constexpr</ins> operator+(<del>const</del> duration&lt;Rep1, Period1&gt;<del>&amp;</del> lhs, <del>const</del> duration&lt;Rep2, Period2&gt;<del>&amp;</del> rhs);
30701 template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
30702    typename common_type&lt;duration&lt;Rep1, Period1&gt;, duration&lt;Rep2, Period2&gt;&gt;::type
30703    <ins>constexpr</ins> operator-(<del>const</del> duration&lt;Rep1, Period1&gt;<del>&amp;</del> lhs, <del>const</del> duration&lt;Rep2, Period2&gt;<del>&amp;</del> rhs);
30704 template &lt;class Rep1, class Period, class Rep2&gt;
30705    duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
30706    <ins>constexpr</ins> operator*(<del>const</del> duration&lt;Rep1, Period&gt;<del>&amp;</del> d, <del>const</del> Rep2<del>&amp;</del> s);
30707 template &lt;class Rep1, class Period, class Rep2&gt;
30708    duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
30709    <ins>constexpr</ins> operator*(<del>const</del> Rep1<del>&amp;</del> s, <del>const</del> duration&lt;Rep2, Period&gt;<del>&amp;</del> d);
30710 template &lt;class Rep1, class Period, class Rep2&gt;
30711    duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
30712    <ins>constexpr</ins> operator/(<del>const</del> duration&lt;Rep1, Period&gt;<del>&amp;</del> d, <del>const</del> Rep2<del>&amp;</del> s);
30713 template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
30714    typename common_type&lt;Rep1, Rep2&gt;::type
30715    <ins>constexpr</ins> operator/(<del>const</del> duration&lt;Rep1, Period1&gt;<del>&amp;</del> lhs, <del>const</del> duration&lt;Rep2, Period2&gt;<del>&amp;</del> rhs);
30716
30717 <i>// duration comparisons</i>
30718 template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
30719    <ins>constexpr</ins> bool operator==(<del>const</del> duration&lt;Rep1, Period1&gt;<del>&amp;</del> lhs, <del>const</del> duration&lt;Rep2, Period2&gt;<del>&amp;</del> rhs);
30720 template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
30721    <ins>constexpr</ins> bool operator!=(<del>const</del> duration&lt;Rep1, Period1&gt;<del>&amp;</del> lhs, <del>const</del> duration&lt;Rep2, Period2&gt;<del>&amp;</del> rhs);
30722 template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
30723    <ins>constexpr</ins> bool operator&lt; (<del>const</del> duration&lt;Rep1, Period1&gt;<del>&amp;</del> lhs, <del>const</del> duration&lt;Rep2, Period2&gt;<del>&amp;</del> rhs);
30724 template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
30725    <ins>constexpr</ins> bool operator&lt;=(<del>const</del> duration&lt;Rep1, Period1&gt;<del>&amp;</del> lhs, <del>const</del> duration&lt;Rep2, Period2&gt;<del>&amp;</del> rhs);
30726 template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
30727    <ins>constexpr</ins> bool operator&gt; (<del>const</del> duration&lt;Rep1, Period1&gt;<del>&amp;</del> lhs, <del>const</del> duration&lt;Rep2, Period2&gt;<del>&amp;</del> rhs);
30728 template &lt;class Rep1, class Period1, class Rep2, class Period2&gt;
30729    <ins>constexpr</ins> bool operator&gt;=(<del>const</del>  duration&lt;Rep1, Period1&gt;<del>&amp;</del> lhs, <del>const</del> duration&lt;Rep2, Period2&gt;<del>&amp;</del> rhs);
30730
30731 <i>// duration_cast</i>
30732 template &lt;class ToDuration, class Rep, class Period&gt;
30733    <ins>constexpr</ins> ToDuration duration_cast(<del>const</del> duration&lt;Rep, Period&gt;<del>&amp;</del> d);
30734 </pre>
30735
30736 <p>
30737 <b>20.9.3 [time.duration]</b>
30738 </p>
30739
30740 <pre>template &lt;class Rep, class Period = ratio&lt;1&gt;&gt;
30741 class duration {
30742   ....
30743 public:
30744   <i>// 20.9.3.1, construct/copy/destroy:</i>
30745  <ins>constexpr</ins> duration() = default;
30746
30747  template &lt;class Rep2&gt;
30748    <ins>constexpr</ins> explicit duration(const Rep2&amp; r);
30749  template &lt;class Rep2, class Period2&gt;
30750    <ins>constexpr</ins> duration(const duration&lt;Rep2, Period2&gt;&amp; d);
30751
30752   <ins>constexpr</ins> duration(const duration&amp;) = default;
30753
30754   <i>// 20.9.3.2, observer:</i>
30755   <ins>constexpr</ins> rep count() const;
30756
30757   <i>// 20.9.3.3, arithmetic:</i>
30758   <ins>constexpr</ins> duration operator+() const;
30759   <ins>constexpr</ins> duration operator-() const;
30760   ...
30761
30762 };
30763 </pre>
30764 </blockquote>
30765 <p><i>[
30766 Note - this edit already seems assumed by definition of the duration static members <tt>zero/min/max</tt>.
30767 They cannot meaningfully be <tt>constexpr</tt> without this change.
30768 ]</i></p>
30769
30770
30771
30772
30773
30774
30775 <hr>
30776 <h3><a name="1172"></a>1172. <tt>select_on_container_(copy|move)_construction</tt> over-constrained</h3>
30777 <p><b>Section:</b> 20.8.2.4 [allocator.concepts.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
30778  <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2009-07-08  <b>Last modified:</b> 2009-07-14</p>
30779 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
30780 <p><b>Discussion:</b></p>
30781 <p>
30782 I believe the two functions
30783 <tt>select_on_container_(copy|move)_construction()</tt> are over-constrained. For
30784 example, the return value of the "copy" version is (see
30785 20.8.2.4 [allocator.concepts.members]/21):
30786 </p>
30787 <blockquote>
30788 <i>Returns:</i> <tt>x</tt> if the allocator should propagate from the existing
30789 container to the new container on copy construction, otherwise <tt>X()</tt>.
30790 </blockquote>
30791 <p>
30792 Consider the case where a user decides to provide an explicit concept
30793 map for Allocator to adapt some legacy allocator class, as he wishes to
30794 provide customizations that the <tt>LegacyAllocator</tt> concept map template
30795 does not provide.  Now, although it's true that the legacy class is
30796 required to have a default constructor, the user might have reasons to
30797 prefer a different constructor to implement
30798 <tt>select_on_container_copy_construction()</tt>. However, the current wording
30799 requires the use of the default constructor.
30800 </p>
30801 <p>
30802 Moreover, it's not said explicitly that <tt>x</tt> is supposed to be the
30803 allocator of the existing container. A clarification would do no harm.
30804 </p>
30805
30806
30807 <p><b>Proposed resolution:</b></p>
30808 <p>
30809 Replace 20.8.2.4 [allocator.concepts.members]/21 with:
30810 </p>
30811
30812 <blockquote><pre>X select_on_container_copy_construction(const X&amp; x);
30813 </pre>
30814 <p>
30815 -21- <i>Returns:</i> <del><tt>x</tt> if the allocator should propagate from the existing
30816 container to the new container on copy construction, otherwise <tt>X()</tt>.</del>
30817 <ins>an allocator object to be used by the new container on copy
30818 construction. [<i>Note:</i> <tt>x</tt> is the allocator of the existing container that
30819 is being copied. The most obvious choices for the return value are <tt>x</tt>, if
30820 the allocator should propagate from the existing container, and <tt>X()</tt>.
30821 <i>&#8212; end note</i>]</ins>
30822 </p>
30823 </blockquote>
30824
30825 <p>
30826 Replace 20.8.2.4 [allocator.concepts.members]/25 with:
30827 </p>
30828
30829 <blockquote><pre>X select_on_container_move_construction(X&amp;&amp; x);
30830 </pre>
30831 <p>
30832 -25- <i>Returns:</i> <del><tt>move(x)</tt> if the allocator should propagate from the existing
30833 container to the new container on move construction, otherwise <tt>X()</tt>.</del>
30834 <ins>an allocator object to be used by the new container on move
30835 construction. [<i>Note:</i> <tt>x</tt> is the allocator of the existing container that
30836 is being moved. The most obvious choices for the return value are <tt>move(x)</tt>, if
30837 the allocator should propagate from the existing container, and <tt>X()</tt>.
30838 <i>&#8212; end note</i>]</ins>
30839 </p>
30840 </blockquote>
30841
30842
30843
30844
30845
30846
30847 <hr>
30848 <h3><a name="1173"></a>1173. "Equivalence" wishy-washiness</h3>
30849 <p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
30850  <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-07-14  <b>Last modified:</b> 2009-07-14</p>
30851 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
30852 <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>
30853 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
30854 <p><b>Discussion:</b></p>
30855 <p>
30856 Issue: The <tt>CopyConstructible</tt> requirements are wishy-washy.  It requires
30857 that the copy is "equivalent" to the original, but "equivalent" is never
30858 defined.
30859 </p>
30860 <p>
30861 I believe this to be an example of a more general lack of rigor around
30862 copy and assignment, although I haven't done the research to dig up all
30863 the instances.
30864 </p>
30865 <p>
30866 It's a problem because if you don't know what <tt>CopyConstructible</tt> means,
30867 you also don't know what it means to copy a pair of <tt>CopyConstructible</tt>
30868 types.  It doesn't prevent us from writing code, but it is a hole in our
30869 ability to understand the meaning of copy.
30870 </p>
30871 <p>
30872 Furthermore, I'm pretty sure that vector's copy constructor doesn't
30873 require the elements to be <tt>EqualityComparable</tt>, so that table is actually
30874 referring to some ill-defined notion of equivalence when it uses ==.
30875 </p>
30876
30877
30878 <p><b>Proposed resolution:</b></p>
30879
30880
30881
30882
30883
30884 <hr>
30885 <h3><a name="1174"></a>1174.    type property predicates</h3>
30886 <p><b>Section:</b> 20.6.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
30887  <b>Submitter:</b> Jason Merrill <b>Opened:</b> 2009-07-16  <b>Last modified:</b> 2009-07-17</p>
30888 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
30889 <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>
30890 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
30891 <p><b>Discussion:</b></p>
30892 <p>
30893 I've been implementing compiler support for <tt>is_standard_layout</tt>, and
30894 noticed a few nits about 20.6.4.3 [meta.unary.prop]:
30895 </p>
30896
30897 <ol>
30898 <li>
30899 There's no trait for "trivially copyable type", which is now the
30900 property that lets you do bitwise copying of a type, and therefore seems
30901 useful to be able to query.  <tt>has_trivial_assign</tt> &amp;&amp;
30902 <tt>has_trivial_copy_constructor</tt> &amp;&amp; <tt>has_trivial_destructor</tt>
30903 is similar, but
30904 not identical, specifically with respect to const types.
30905 </li>
30906 <li>
30907 <tt>has_trivial_copy_constructor</tt> and <tt>has_trivial_assign</tt> lack the "or an
30908 array of such a class type" language that most other traits in that
30909 section, including <tt>has_nothrow_copy_constructor</tt> and <tt>has_nothrow_assign</tt>,
30910 have; this seems like an oversight.
30911 </li>
30912 </ol>
30913
30914 <p><i>[
30915 See the thread starting with c++std-lib-24420 for further discussion.
30916 ]</i></p>
30917
30918
30919
30920
30921 <p><b>Proposed resolution:</b></p>
30922 <p>
30923 </p>
30924
30925
30926
30927
30928
30929 <hr>
30930 <h3><a name="1175"></a>1175. <tt>unordered</tt> complexity</h3>
30931 <p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
30932  <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2009-07-17  <b>Last modified:</b> 2009-07-19</p>
30933 <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>
30934 <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>
30935 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
30936 <p><b>Discussion:</b></p>
30937 <p>
30938 When I look at the <tt>unordered_*</tt> constructors, I think the complexity is poorly
30939 described and does not follow the style of the rest of the standard.
30940 </p>
30941
30942 <p>
30943 The complexity for the default constructor is specified as constant.
30944  Actually, it is proportional to <tt>n</tt>, but there are no invocations of
30945 <tt>value_type</tt> constructors or other <tt>value_type</tt> operations.
30946 </p>
30947
30948 <p>
30949 For the iterator-based constructor the complexity should be:
30950 </p>
30951
30952 <blockquote>
30953 <i>Complexity:</i> exactly <tt>n</tt> calls to construct <tt>value_type</tt>
30954 from <tt>InputIterator::value_type</tt> (where <tt>n = distance(f,l)</tt>).
30955 The number of calls to <tt>key_equal::operator()</tt> is proportional to
30956 <tt>n</tt> in the average case and <tt>n*n</tt> in the worst case.
30957 </blockquote>
30958
30959
30960
30961 <p><b>Proposed resolution:</b></p>
30962 <p>
30963 </p>
30964
30965
30966
30967
30968
30969 <hr>
30970 <h3><a name="1176"></a>1176. Make <tt>thread</tt> constructor non-variadic</h3>
30971 <p><b>Section:</b> 30.3.1.2 [thread.thread.constr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
30972  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-07-18  <b>Last modified:</b> 2009-07-18</p>
30973 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#thread.thread.constr">active issues</a> in [thread.thread.constr].</p>
30974 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#thread.thread.constr">issues</a> in [thread.thread.constr].</p>
30975 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
30976 <p><b>Discussion:</b></p>
30977 <p>
30978 The variadic <tt>thread</tt> constructor is causing controversy, e.g.
30979 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2901.pdf">N2901</a>.
30980 This issue has been created as a placeholder for this course of action.
30981 </p>
30982
30983 <blockquote><pre>template &lt;class F<del>, class ...Args</del>&gt; thread(F&amp;&amp; f<del>, Args&amp;&amp;... args</del>);
30984 </pre></blockquote>
30985
30986 <p>
30987 See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a> for wording which specifies an rvalue-ref signature but
30988 with "decay behavior", but using variadics.
30989 </p>
30990
30991
30992 <p><b>Proposed resolution:</b></p>
30993 <p>
30994 </p>
30995
30996
30997
30998
30999
31000 <hr>
31001 <h3><a name="1177"></a>1177. Improve "diagnostic required" wording</h3>
31002 <p><b>Section:</b> 20.9.3 [time.duration] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
31003  <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-07-18  <b>Last modified:</b> 2009-08-01</p>
31004 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#time.duration">active issues</a> in [time.duration].</p>
31005 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration">issues</a> in [time.duration].</p>
31006 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
31007 <p><b>Discussion:</b></p>
31008 <p>
31009 "diagnostic required" has been used (by me) for code words meaning "use
31010 <tt>enable_if</tt> to constrain templated functions.  This needs to be
31011 improved by referring to the function signature as not participating in
31012 the overload set, and moving this wording to a <i>Remarks</i> paragraph.
31013 </p>
31014
31015
31016
31017 <p><b>Proposed resolution:</b></p>
31018 <p><i>[
31019 This proposed resolution addresses <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#947">947</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#974">974</a>.
31020 ]</i></p>
31021
31022
31023 <p>
31024 Change 20.9.3.1 [time.duration.cons]:
31025 </p>
31026
31027 <blockquote>
31028 <pre>template &lt;class Rep2&gt;
31029   explicit duration(const Rep2&amp; r);
31030 </pre>
31031 <blockquote>
31032 <p>
31033 <i><del>Requires:</del> <ins>Remarks:</ins></i>
31034 <tt>Rep2</tt> shall be implicitly convertible to <tt>rep</tt> and
31035 </p>
31036 <ul>
31037 <li>
31038 <tt>treat_as_floating_point&lt;rep&gt;::value</tt> shall be <tt>true</tt> or
31039 </li>
31040 <li>
31041 <tt>treat_as_floating_point&lt;Rep2&gt;::value</tt> shall be <tt>false</tt>.
31042 </li>
31043 </ul>
31044 <p>
31045 <del>Diagnostic required</del> <ins>If these constraints are not met, this
31046 constructor shall not participate in overload resolution</ins>. [<i>Example:</i>
31047 </p>
31048 <blockquote><pre>duration&lt;int, milli&gt; d(3); // OK
31049 duration&lt;int, milli&gt; d(3.5); // error
31050 </pre></blockquote>
31051
31052 <p>
31053 &#8212; <i>end example</i>]
31054 </p>
31055
31056 <p>
31057 <i>Effects:</i> Constructs an object of type <tt>duration</tt>.
31058 </p>
31059
31060 <p>
31061 <i>Postcondition:</i> <tt>count() == static_cast&lt;rep&gt;(r)</tt>.
31062 </p>
31063
31064 </blockquote>
31065
31066 <pre>template &lt;class Rep2, class Period2&gt;
31067   duration(const duration&lt;Rep2, Period2&gt;&amp; d);
31068 </pre>
31069 <blockquote>
31070 <p>
31071 <i><del>Requires:</del> <ins>Remarks:</ins></i> <tt>treat_as_floating_point&lt;rep&gt;::value</tt> shall be <tt>true</tt> or
31072 <tt>ratio_divide&lt;Period2, period&gt;::type::den</tt> shall be 1<del>. Diagnostic
31073 required</del><ins>, else this constructor shall not participate in overload
31074 resolution</ins>. [<i>Note:</i> This requirement prevents implicit truncation error
31075 when converting between integral-based duration types. Such a
31076 construction could easily lead to confusion about the value of the
31077 duration. &#8212; <i>end note</i>] [<i>Example:</i>
31078 </p>
31079
31080 <blockquote><pre>duration&lt;int, milli&gt; ms(3);
31081 duration&lt;int, micro&gt; us = ms; // OK
31082 duration&lt;int, milli&gt; ms2 = us; // error
31083 </pre></blockquote>
31084
31085 <p>
31086 &#8212; <i>end example</i>]
31087 </p>
31088
31089 <p>
31090 <i>Eff&#65533;ects:</i> Constructs an object of type <tt>duration</tt>, constructing
31091 <tt>rep_</tt> from
31092 <tt>duration_cast&lt;duration&gt;(d).count()</tt>.
31093 </p>
31094
31095 </blockquote>
31096
31097
31098 </blockquote>
31099
31100 <p>
31101 Change the following paragraphs in 20.9.3.5 [time.duration.nonmember]:
31102 </p>
31103
31104 <blockquote>
31105 <pre>template &lt;class Rep1, class Period, class Rep2&gt;
31106   duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
31107   operator*(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
31108 </pre>
31109 <blockquote>
31110 <i><del>Requires</del> <ins>Remarks</ins>:</i> <tt>Rep2</tt> shall be implicitly convertible to
31111 <tt>CR(Rep1, Rep2)</tt><ins>, else this signature shall not participate in
31112 overload resolution</ins>. <del>Diagnostic required.</del>
31113 </blockquote>
31114
31115 <pre>template &lt;class Rep1, class Period, class Rep2&gt;
31116   duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
31117   operator*(const Rep1&amp; s, const duration&lt;Rep2, Period&gt;&amp; d);
31118 </pre>
31119 <blockquote>
31120 <i><del>Requires</del> <ins>Remarks</ins>:</i> <tt>Rep1</tt> shall be implicitly convertible to
31121 <tt>CR(Rep1, Rep2)</tt><ins>, else this signature shall not participate in
31122 overload resolution</ins>. <del>Diagnostic required.</del>
31123 </blockquote>
31124
31125 <pre>template &lt;class Rep1, class Period, class Rep2&gt;
31126   duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
31127   operator/(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
31128 </pre>
31129 <blockquote>
31130 <i><del>Requires</del> <ins>Remarks</ins>:</i> <tt>Rep2</tt> shall be implicitly convertible to
31131 <tt>CR(Rep1, Rep2)</tt> and <tt>Rep2</tt> shall not be an instantiation of
31132 <tt>duration</tt><ins>, else this signature shall not participate in
31133 overload resolution</ins>. <del>Diagnostic required.</del>
31134 </blockquote>
31135
31136 <pre>template &lt;class Rep1, class Period, class Rep2&gt;
31137   duration&lt;typename common_type&lt;Rep1, Rep2&gt;::type, Period&gt;
31138   operator%(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
31139 </pre>
31140 <blockquote>
31141 <i><del>Requires</del> <ins>Remarks</ins>:</i> <tt>Rep2</tt> shall be implicitly convertible to
31142 <tt>CR(Rep1, Rep2)</tt> and <tt>Rep2</tt> shall not be an instantiation of
31143 <tt>duration</tt><ins>, else this signature shall not participate in
31144 overload resolution</ins>. <del>Diagnostic required.</del>
31145 </blockquote>
31146
31147 </blockquote>
31148
31149
31150
31151
31152
31153
31154 <hr>
31155 <h3><a name="1178"></a>1178. Header dependencies</h3>
31156 <p><b>Section:</b> 17.6.4.2 [res.on.headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
31157  <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-07-18  <b>Last modified:</b> 2009-07-18</p>
31158 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
31159 <p><b>Discussion:</b></p>
31160 <p>
31161 See Frankfurt notes of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1001">1001</a>.
31162 </p>
31163
31164
31165 <p><b>Proposed resolution:</b></p>
31166 <p><i>Change 17.6.4.2 [res.on.headers], Headers, paragraph 1, as indicated:</i></p>
31167
31168 <blockquote>
31169
31170 <p>
31171 A C++ header may include other C++
31172 headers.<del><sup>[footnote]</sup></del> <ins>A C++ header shall provide
31173 the declarations and definitions that appear in its synopsis
31174 (3.2 [basic.def.odr]). A C++ header shown in its synopsis as including
31175 other C++ headers shall provide the declarations and definitions that appear in
31176 the synopses of those other headers.</ins>
31177 </p>
31178
31179   <p><del><sup>[footnote]</sup> C++ headers must include a C++ header that contains
31180   any needed definition (3.2).</del></p>
31181 </blockquote>
31182
31183
31184
31185
31186
31187
31188 <hr>
31189 <h3><a name="1179"></a>1179. Probably editorial in [structure.specifications]</h3>
31190 <p><b>Section:</b> 17.5.1.4 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
31191  <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2009-07-21  <b>Last modified:</b> 2009-07-22</p>
31192 <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>
31193 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
31194 <p><b>Discussion:</b></p>
31195 <p>
31196 While reviewing <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#971">971</a> I noted that 17.5.1.4 [structure.specifications]/7 says:
31197 </p>
31198
31199 <blockquote>
31200 -7- Error conditions specify conditions where a function may fail. The
31201 conditions are listed, together with a suitable explanation, as the <tt>enum
31202 class errc</tt> constants (19.5) that could be used as an argument to
31203 function <tt>make_error_condition</tt> (19.5.3.6).
31204 </blockquote>
31205
31206 <p>
31207 This paragraph should mention <tt>make_error_code</tt> or the text "that
31208 could be used as an argument to function <tt>make_error_condition</tt>
31209 (19.5.3.6)" should be deleted.  I believe this is editorial.
31210 </p>
31211
31212 <p><i>[
31213 2009-07-21 Chris adds:
31214 ]</i></p>
31215
31216
31217 <blockquote>
31218 <p>
31219 I'm not convinced there's a problem there, because as far as the "Error
31220 conditions" clauses are concerned, make_error_condition() is used by a
31221 user to test for the condition, whereas make_error_code is not. For
31222 example:
31223 </p>
31224
31225 <blockquote><pre>void foobar(error_code&amp; ec = throws());
31226 </pre></blockquote>
31227
31228 <p>
31229  Error conditions:
31230 </p>
31231 <blockquote>
31232 permission_denied - Insufficient privilege to perform operation.
31233 </blockquote>
31234
31235 <p>
31236 When a user writes:
31237 </p>
31238
31239 <blockquote><pre>error_code ec;
31240 foobar(ec);
31241 if (ec == errc::permission_denied)
31242    ...
31243 </pre></blockquote>
31244
31245 <p>
31246 the implicit conversion <tt>errc-&gt;error_condition</tt> makes the if-test
31247 equivalent to:
31248 </p>
31249
31250 <blockquote><pre>if (ec == make_error_condition(errc::permission_denied))
31251 </pre></blockquote>
31252
31253 <p>
31254 On the other hand, if the user had written:
31255 </p>
31256
31257 <blockquote><pre>if (ec == make_error_code(errc::permission_denied))
31258 </pre></blockquote>
31259
31260 <p>
31261 the test is now checking for a specific error code. The test may
31262 evaluate to <tt>false</tt> even though <tt>foobar()</tt> failed due to the documented
31263 error condition "Insufficient privilege".
31264 </p>
31265 </blockquote>
31266
31267
31268 <p><b>Proposed resolution:</b></p>
31269 <p>
31270 </p>
31271
31272
31273
31274
31275
31276 <hr>
31277 <h3><a name="1180"></a>1180. Missing string_type member typedef in class <tt>sub_match</tt></h3>
31278 <p><b>Section:</b> 28.9.1 [re.submatch.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
31279  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-07-25  <b>Last modified:</b> 2009-07-26</p>
31280 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
31281 <p><b>Discussion:</b></p>
31282 <p>
31283 The definition of class template <tt>sub_match</tt> is strongly dependent
31284 on the type <tt>basic_string&lt;value_type&gt;</tt>, both in interface and effects,
31285 but does not provide a corresponding typedef <tt>string_type</tt>, as e.g.
31286 class <tt>match_results</tt> does, which looks like an oversight to me that
31287 should be fixed.
31288 </p>
31289
31290
31291 <p><b>Proposed resolution:</b></p>
31292
31293 <ol>
31294 <li>
31295 <p>
31296 In the class template <tt>sub_match</tt> synopsis 28.9 [re.submatch]/1
31297 change as indicated:
31298 </p>
31299
31300 <blockquote><pre>template &lt;class BidirectionalIterator&gt;
31301 class sub_match : public std::pair&lt;BidirectionalIterator, BidirectionalIterator&gt; {
31302 public:
31303   typedef typename iterator_traits&lt;BidirectionalIterator&gt;::value_type value_type;
31304   typedef typename iterator_traits&lt;BidirectionalIterator&gt;::difference_type difference_type;
31305   typedef BidirectionalIterator iterator;
31306   <ins>typedef basic_string&lt;value_type&gt; string_type;</ins>
31307
31308   bool matched;
31309
31310   difference_type length() const;
31311   operator <del>basic_string&lt;value_type&gt;</del><ins>string_type</ins>() const;
31312   <del>basic_string&lt;value_type&gt;</del><ins>string_type</ins> str() const;
31313   int compare(const sub_match&amp; s) const;
31314   int compare(const <del>basic_string&lt;value_type&gt;</del><ins>string_type</ins>&amp; s) const;
31315   int compare(const value_type* s) const;
31316 };
31317 </pre></blockquote>
31318 </li>
31319
31320 <li>
31321 <p>
31322 In 28.9.1 [re.submatch.members]/2 change as indicated:
31323 </p>
31324
31325 <blockquote><pre>operator <del>basic_string&lt;value_type&gt;</del><ins>string_type</ins>() const;
31326 </pre>
31327
31328 <blockquote>
31329 <i>Returns:</i> <tt>matched ? <del>basic_string&lt;value_type&gt;</del>
31330 <ins>string_type</ins>(first, second) : <del>basic_string&lt;value_type&gt;</del>
31331 <ins>string_type</ins>()</tt>.
31332 </blockquote>
31333 </blockquote>
31334 </li>
31335
31336 <li>
31337 <p>
31338 In 28.9.1 [re.submatch.members]/3 change as indicated:
31339 </p>
31340
31341 <blockquote><pre><del>basic_string&lt;value_type&gt;</del><ins>string_type</ins> str() const;
31342 </pre>
31343
31344 <blockquote>
31345 <i>Returns:</i> <tt>matched ? <del>basic_string&lt;value_type&gt;</del>
31346 <ins>string_type</ins>(first, second) : <del>basic_string&lt;value_type&gt;</del>
31347 <ins>string_type</ins>()</tt>.
31348 </blockquote>
31349 </blockquote>
31350 </li>
31351 </ol>
31352
31353
31354
31355
31356
31357
31358 <hr>
31359 <h3><a name="1181"></a>1181. Invalid <tt>sub_match</tt> comparison operators</h3>
31360 <p><b>Section:</b> 28.9.2 [re.submatch.op] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
31361  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-07-25  <b>Last modified:</b> 2009-07-28</p>
31362 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.submatch.op">issues</a> in [re.submatch.op].</p>
31363 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
31364 <p><b>Discussion:</b></p>
31365 <p>
31366 Several heterogeneous comparison operators of class template
31367 <tt>sub_match</tt> are specified by return clauses that are not valid
31368 in general. E.g. 28.9.2 [re.submatch.op]/7:
31369 </p>
31370
31371 <blockquote><pre>template &lt;class BiIter, class ST, class SA&gt;
31372 bool operator==(
31373   const basic_string&lt;
31374     typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
31375   const sub_match&lt;BiIter&gt;&amp; rhs);
31376 </pre>
31377 <blockquote>
31378 <i>Returns:</i> <tt>lhs == rhs.str()</tt>.
31379 </blockquote>
31380 </blockquote>
31381
31382 <p>
31383 The returns clause would be ill-formed for all cases where
31384 <tt>ST != std::char_traits&lt;iterator_traits&lt;BiIter&gt;::value_type&gt;</tt>
31385 or <tt>SA != std::allocator&lt;iterator_traits&lt;BiIter&gt;::value_type&gt;</tt>.
31386 </p>
31387 <p>
31388 The generic character of the comparison was intended, so
31389 there are basically two approaches to fix the problem: The
31390 first one would define the semantics of the comparison
31391 using the traits class <tt>ST</tt> (The semantic of <tt>basic_string::compare</tt>
31392 is defined in terms of the compare function of the corresponding
31393 traits class), the second one would define the semantics of the
31394 comparison using the traits class
31395 </p>
31396
31397 <blockquote><pre>std::char_traits&lt;iterator_traits&lt;BiIter&gt;::value_type&gt;
31398 </pre></blockquote>
31399
31400 <p>
31401 which is essentially identical to
31402 </p>
31403
31404 <blockquote><pre>std::char_traits&lt;sub_match&lt;BiIter&gt;::value_type&gt;
31405 </pre></blockquote>
31406
31407 <p>
31408 I suggest to follow the second approach, because
31409 this emphasizes the central role of the <tt>sub_match</tt>
31410 object as part of the comparison and would also
31411 make sure that a <tt>sub_match</tt> comparison using some
31412 <tt>basic_string&lt;char_t, ..&gt;</tt> always is equivalent to
31413 a corresponding comparison with a string literal
31414 because of the existence of further overloads (beginning
31415 from 28.9.2 [re.submatch.op]/19). If users really want to
31416 take advantage of their own <tt>traits::compare</tt>, they can
31417 simply write a corresponding compare function that
31418 does so.
31419 </p>
31420
31421
31422 <p><b>Proposed resolution:</b></p>
31423 <ol>
31424 <li>
31425 <p>
31426 In 28.9.2 [re.submatch.op] change as indicated:
31427 </p>
31428
31429 <ol type="a">
31430 <li>
31431
31432 <p>
31433 If <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1180">1180</a> is accepted:
31434 </p>
31435
31436 <blockquote>
31437 <pre>template &lt;class BiIter, class ST, class SA&gt;
31438   bool operator==(
31439     const basic_string&lt;
31440       typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
31441     const sub_match&lt;BiIter&gt;&amp; rhs);
31442 </pre>
31443 <blockquote>
31444 7 <i>Returns:</i> <tt><del>lhs</del><ins>typename
31445 sub_match&lt;BiIter&gt;::string_type(lhs.begin(), lhs.end())</ins> ==
31446 rhs.str()</tt>.
31447 </blockquote>
31448
31449 <pre>template &lt;class BiIter, class ST, class SA&gt;
31450   bool operator!=(
31451     const basic_string&lt;
31452       typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
31453     const sub_match&lt;BiIter&gt;&amp; rhs);
31454 </pre>
31455
31456 <blockquote>
31457 8 <i>Returns:</i> <tt><del>lhs</del><ins>typename
31458 sub_match&lt;BiIter&gt;::string_type(lhs.begin(), lhs.end())</ins> !=
31459 rhs.str()</tt>.
31460 </blockquote>
31461
31462 <pre>template &lt;class BiIter, class ST, class SA&gt;
31463   bool operator&lt;(
31464     const basic_string&lt;
31465       typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
31466     const sub_match&lt;BiIter&gt;&amp; rhs);
31467 </pre>
31468
31469 <blockquote>
31470 9 <i>Returns:</i> <tt><del>lhs</del><ins>typename
31471 sub_match&lt;BiIter&gt;::string_type(lhs.begin(), lhs.end())</ins> &lt;
31472 rhs.str()</tt>.
31473 </blockquote>
31474
31475 <pre>template &lt;class BiIter, class ST, class SA&gt;
31476   bool operator&gt;(
31477     const basic_string&lt;
31478       typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
31479     const sub_match&lt;BiIter&gt;&amp; rhs);
31480 </pre>
31481
31482 <blockquote>
31483 10 <i>Returns:</i> <tt><del>lhs</del><ins>typename
31484 sub_match&lt;BiIter&gt;::string_type(lhs.begin(), lhs.end())</ins> &gt;
31485 rhs.str()</tt>.
31486 </blockquote>
31487
31488 <pre>template &lt;class BiIter, class ST, class SA&gt;
31489   bool operator&gt;=(
31490     const basic_string&lt;
31491       typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
31492     const sub_match&lt;BiIter&gt;&amp; rhs);
31493 </pre>
31494
31495 <blockquote>
31496 11 <i>Returns:</i> <tt><del>lhs</del><ins>typename
31497 sub_match&lt;BiIter&gt;::string_type(lhs.begin(), lhs.end())</ins> &gt;=
31498 rhs.str()</tt>.
31499 </blockquote>
31500
31501 <pre>template &lt;class BiIter, class ST, class SA&gt;
31502   bool operator&lt;=(
31503     const basic_string&lt;
31504       typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
31505     const sub_match&lt;BiIter&gt;&amp; rhs);
31506 </pre>
31507
31508 <blockquote>
31509 12 <i>Returns:</i> <tt><del>lhs</del><ins>typename
31510 sub_match&lt;BiIter&gt;::string_type(lhs.begin(), lhs.end())</ins> &lt;=
31511 rhs.str()</tt>.
31512 </blockquote>
31513
31514 <pre>template &lt;class BiIter, class ST, class SA&gt;
31515   bool operator==(const sub_match&lt;BiIter&gt;&amp; lhs,
31516     const basic_string&lt;
31517       typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; rhs);
31518 </pre>
31519
31520 <blockquote>
31521 13 <i>Returns:</i> <tt>lhs.str() == <del>rhs</del><ins>typename
31522 sub_match&lt;BiIter&gt;::string_type(rhs.begin(), rhs.end())</ins></tt>.
31523 </blockquote>
31524
31525 <pre>template &lt;class BiIter, class ST, class SA&gt;
31526   bool operator!=(const sub_match&lt;BiIter&gt;&amp; lhs,
31527     const basic_string&lt;
31528       typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; rhs);
31529 </pre>
31530
31531 <blockquote>
31532 14 <i>Returns:</i> <tt>lhs.str() != <del>rhs</del><ins>typename
31533 sub_match&lt;BiIter&gt;::string_type(rhs.begin(), rhs.end())</ins></tt>.
31534 </blockquote>
31535
31536 <pre>template &lt;class BiIter, class ST, class SA&gt;
31537   bool operator&lt;(const sub_match&lt;BiIter&gt;&amp; lhs,
31538     const basic_string&lt;
31539       typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; rhs);
31540 </pre>
31541
31542 <blockquote>
31543 15 <i>Returns:</i> <tt>lhs.str() &lt; <del>rhs</del><ins>typename
31544 sub_match&lt;BiIter&gt;::string_type(rhs.begin(), rhs.end())</ins></tt>.
31545 </blockquote>
31546
31547 <pre>template &lt;class BiIter, class ST, class SA&gt;
31548   bool operator&gt;(const sub_match&lt;BiIter&gt;&amp; lhs,
31549     const basic_string&lt;
31550       typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; rhs);
31551 </pre>
31552
31553 <blockquote>
31554 16 <i>Returns:</i> <tt>lhs.str() &gt; <del>rhs</del><ins>typename
31555 sub_match&lt;BiIter&gt;::string_type(rhs.begin(), rhs.end())</ins></tt>.
31556 </blockquote>
31557
31558 <pre>template &lt;class BiIter, class ST, class SA&gt;
31559   bool operator&gt;=(const sub_match&lt;BiIter&gt;&amp; lhs,
31560     const basic_string&lt;
31561       typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; rhs);
31562 </pre>
31563
31564 <blockquote>
31565 17 <i>Returns:</i> <tt>lhs.str() &gt;= <del>rhs</del><ins>typename
31566 sub_match&lt;BiIter&gt;::string_type(rhs.begin(), rhs.end())</ins></tt>.
31567 </blockquote>
31568
31569 <pre>template &lt;class BiIter, class ST, class SA&gt;
31570   bool operator&lt;=(const sub_match&lt;BiIter&gt;&amp; lhs,
31571     const basic_string&lt;
31572       typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; rhs);
31573 </pre>
31574
31575 <blockquote>
31576 18 <i>Returns:</i> <tt>lhs.str() &lt;= <del>rhs</del><ins>typename
31577 sub_match&lt;BiIter&gt;::string_type(rhs.begin(), rhs.end())</ins></tt>.
31578 </blockquote>
31579 </blockquote>
31580
31581 </li>
31582
31583 <li>
31584
31585 <p>
31586 If <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1180">1180</a> is <em>not</em> accepted:
31587 </p>
31588
31589 <blockquote>
31590 <pre>template &lt;class BiIter, class ST, class SA&gt;
31591   bool operator==(
31592     const basic_string&lt;
31593       typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
31594     const sub_match&lt;BiIter&gt;&amp; rhs);
31595 </pre>
31596 <blockquote>
31597 7 <i>Returns:</i> <tt><del>lhs</del><ins>basic_string&lt;typename
31598 sub_match&lt;BiIter&gt;::value_type&gt;(lhs.begin(), lhs.end())</ins> ==
31599 rhs.str()</tt>.
31600 </blockquote>
31601
31602 <pre>template &lt;class BiIter, class ST, class SA&gt;
31603   bool operator!=(
31604     const basic_string&lt;
31605       typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
31606     const sub_match&lt;BiIter&gt;&amp; rhs);
31607 </pre>
31608
31609 <blockquote>
31610 8 <i>Returns:</i> <tt><del>lhs</del><ins>basic_string&lt;typename
31611 sub_match&lt;BiIter&gt;::value_type&gt;(lhs.begin(), lhs.end())</ins> !=
31612 rhs.str()</tt>.
31613 </blockquote>
31614
31615 <pre>template &lt;class BiIter, class ST, class SA&gt;
31616   bool operator&lt;(
31617     const basic_string&lt;
31618       typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
31619     const sub_match&lt;BiIter&gt;&amp; rhs);
31620 </pre>
31621
31622 <blockquote>
31623 9 <i>Returns:</i> <tt><del>lhs</del><ins>basic_string&lt;typename
31624 sub_match&lt;BiIter&gt;::value_type&gt;(lhs.begin(), lhs.end())</ins> &lt;
31625 rhs.str()</tt>.
31626 </blockquote>
31627
31628 <pre>template &lt;class BiIter, class ST, class SA&gt;
31629   bool operator&gt;(
31630     const basic_string&lt;
31631       typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
31632     const sub_match&lt;BiIter&gt;&amp; rhs);
31633 </pre>
31634
31635 <blockquote>
31636 10 <i>Returns:</i> <tt><del>lhs</del><ins>basic_string&lt;typename
31637 sub_match&lt;BiIter&gt;::value_type&gt;(lhs.begin(), lhs.end())</ins> &gt;
31638 rhs.str()</tt>.
31639 </blockquote>
31640
31641 <pre>template &lt;class BiIter, class ST, class SA&gt;
31642   bool operator&gt;=(
31643     const basic_string&lt;
31644       typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
31645     const sub_match&lt;BiIter&gt;&amp; rhs);
31646 </pre>
31647
31648 <blockquote>
31649 11 <i>Returns:</i> <tt><del>lhs</del><ins>basic_string&lt;typename
31650 sub_match&lt;BiIter&gt;::value_type&gt;(lhs.begin(), lhs.end())</ins> &gt;=
31651 rhs.str()</tt>.
31652 </blockquote>
31653
31654 <pre>template &lt;class BiIter, class ST, class SA&gt;
31655   bool operator&lt;=(
31656     const basic_string&lt;
31657       typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; lhs,
31658     const sub_match&lt;BiIter&gt;&amp; rhs);
31659 </pre>
31660
31661 <blockquote>
31662 12 <i>Returns:</i> <tt><del>lhs</del><ins>basic_string&lt;typename
31663 sub_match&lt;BiIter&gt;::value_type&gt;(lhs.begin(), lhs.end())</ins> &lt;=
31664 rhs.str()</tt>.
31665 </blockquote>
31666
31667 <pre>template &lt;class BiIter, class ST, class SA&gt;
31668   bool operator==(const sub_match&lt;BiIter&gt;&amp; lhs,
31669     const basic_string&lt;
31670       typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; rhs);
31671 </pre>
31672
31673 <blockquote>
31674 13 <i>Returns:</i> <tt>lhs.str() == <del>rhs</del><ins>basic_string&lt;typename
31675 sub_match&lt;BiIter&gt;::value_type&gt;(rhs.begin(), rhs.end())</ins></tt>.
31676 </blockquote>
31677
31678 <pre>template &lt;class BiIter, class ST, class SA&gt;
31679   bool operator!=(const sub_match&lt;BiIter&gt;&amp; lhs,
31680     const basic_string&lt;
31681       typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; rhs);
31682 </pre>
31683
31684 <blockquote>
31685 14 <i>Returns:</i> <tt>lhs.str() != <del>rhs</del><ins>basic_string&lt;typename
31686 sub_match&lt;BiIter&gt;::value_type&gt;(rhs.begin(), rhs.end())</ins></tt>.
31687 </blockquote>
31688
31689 <pre>template &lt;class BiIter, class ST, class SA&gt;
31690   bool operator&lt;(const sub_match&lt;BiIter&gt;&amp; lhs,
31691     const basic_string&lt;
31692       typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; rhs);
31693 </pre>
31694
31695 <blockquote>
31696 15 <i>Returns:</i> <tt>lhs.str() &lt; <del>rhs</del><ins>basic_string&lt;typename
31697 sub_match&lt;BiIter&gt;::value_type&gt;(rhs.begin(), rhs.end())</ins></tt>.
31698 </blockquote>
31699
31700 <pre>template &lt;class BiIter, class ST, class SA&gt;
31701   bool operator&gt;(const sub_match&lt;BiIter&gt;&amp; lhs,
31702     const basic_string&lt;
31703       typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; rhs);
31704 </pre>
31705
31706 <blockquote>
31707 16 <i>Returns:</i> <tt>lhs.str() &gt; <del>rhs</del><ins>basic_string&lt;typename
31708 sub_match&lt;BiIter&gt;::value_type&gt;(rhs.begin(), rhs.end())</ins></tt>.
31709 </blockquote>
31710
31711 <pre>template &lt;class BiIter, class ST, class SA&gt;
31712   bool operator&gt;=(const sub_match&lt;BiIter&gt;&amp; lhs,
31713     const basic_string&lt;
31714       typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; rhs);
31715 </pre>
31716
31717 <blockquote>
31718 17 <i>Returns:</i> <tt>lhs.str() &gt;= <del>rhs</del><ins>basic_string&lt;typename
31719 sub_match&lt;BiIter&gt;::value_type&gt;(rhs.begin(), rhs.end())</ins></tt>.
31720 </blockquote>
31721
31722 <pre>template &lt;class BiIter, class ST, class SA&gt;
31723   bool operator&lt;=(const sub_match&lt;BiIter&gt;&amp; lhs,
31724     const basic_string&lt;
31725       typename iterator_traits&lt;BiIter&gt;::value_type, ST, SA&gt;&amp; rhs);
31726 </pre>
31727
31728 <blockquote>
31729 18 <i>Returns:</i> <tt>lhs.str() &lt;= <del>rhs</del><ins>basic_string&lt;typename
31730 sub_match&lt;BiIter&gt;::value_type&gt;(rhs.begin(), rhs.end())</ins></tt>.
31731 </blockquote>
31732 </blockquote>
31733
31734 </li>
31735
31736 </ol>
31737
31738 </li>
31739 </ol>
31740
31741
31742
31743
31744
31745 <hr>
31746 <h3><a name="1182"></a>1182. Unfortunate hash dependencies</h3>
31747 <p><b>Section:</b> 20.7.17 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
31748  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-07-28  <b>Last modified:</b> 2009-07-30</p>
31749 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.hash">active issues</a> in [unord.hash].</p>
31750 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.hash">issues</a> in [unord.hash].</p>
31751 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
31752 <p><b>Discussion:</b></p>
31753 <p>
31754 The implied library dependencies created by spelling out all the <tt>hash</tt>
31755 template specializations in the <tt>&lt;functional&gt;</tt> synopsis are unfortunate.
31756 The potential coupling is greatly reduced if the <tt>hash</tt> specialization is
31757 declared in the appropriate header for each library type, as it is much
31758 simpler to forward declare the primary template and provide a single
31759 specialization than it is to implement a <tt>hash</tt> function for a <tt>string</tt> or
31760 <tt>vector</tt> without providing a definition for the whole <tt>string/vector</tt>
31761 template in order to access the necessary bits.
31762 </p>
31763
31764 <p>
31765 Note that the proposed resolution purely involves moving the
31766 declarations of a few specializations, it specifically does not make any
31767 changes to 20.7.17 [unord.hash].
31768 </p>
31769
31770
31771 <p><b>Proposed resolution:</b></p>
31772 <p>
31773 Strike the following specializations declared in the <tt>&lt;functional&gt;</tt>
31774 synopsis p2 20.7 [function.objects]
31775 </p>
31776
31777 <blockquote><pre><del>template &lt;&gt; struct hash&lt;std::string&gt;;</del>
31778 <del>template &lt;&gt; struct hash&lt;std::u16string&gt;;</del>
31779 <del>template &lt;&gt; struct hash&lt;std::u32string&gt;;</del>
31780 <del>template &lt;&gt; struct hash&lt;std::wstring&gt;;</del>
31781
31782 <del>template &lt;class Allocator&gt; struct hash&lt;std::vector&lt;bool, Allocator&gt; &gt;;</del>
31783 <del>template &lt;std::size_t N&gt; struct hash&lt;std::bitset&lt;N&gt; &gt;;</del>
31784 </pre></blockquote>
31785
31786 <p>
31787 Add the following declarations to the synopsis of <tt>&lt;string&gt;</tt> in
31788 21.3 [string.classes]
31789 </p>
31790
31791 <blockquote><pre><ins>// 21.4.x hash support
31792 template &lt;class T&gt; struct hash;
31793 template &lt;&gt; struct hash&lt;string&gt;;
31794 template &lt;&gt; struct hash&lt;u16string&gt;;
31795 template &lt;&gt; struct hash&lt;u32string&gt;;
31796 template &lt;&gt; struct hash&lt;wstring&gt;;</ins>
31797 </pre></blockquote>
31798
31799 <p>
31800 Add a new clause 21.4.X
31801 </p>
31802
31803 <blockquote>
31804 <p>
31805 21.4.X Hash support [basic.string.hash]
31806 </p>
31807
31808 <pre>template &lt;&gt; struct hash&lt;string&gt;;
31809 template &lt;&gt; struct hash&lt;u16string&gt;;
31810 template &lt;&gt; struct hash&lt;u32string&gt;;
31811 template &lt;&gt; struct hash&lt;wstring&gt;;
31812 </pre>
31813
31814 <blockquote>
31815 Explicit specializations of the class template hash (20.7.17 [unord.hash])
31816 shall be provided for the types <tt>string</tt>, <tt>u16string</tt>,
31817 <tt>u32string</tt> and <tt>wstring</tt> suitable for using these types as keys in
31818 unordered associative containers (23.5 [unord]).
31819 </blockquote>
31820 </blockquote>
31821
31822 <p>
31823 Add the following declarations to the synopsis of <tt>&lt;vector&gt;</tt> in
31824 23.3 [sequences]
31825 </p>
31826
31827 <blockquote><pre><ins>
31828 // 21.4.x hash support
31829 template &lt;class T&gt; struct hash;
31830 template &lt;class Allocator&gt; struct hash&lt;vector&lt;bool, Allocator&gt;&gt;;
31831 </ins></pre></blockquote>
31832
31833 <p>
31834 Add a new paragraph to the end of 23.3.7 [vector.bool]
31835 </p>
31836
31837 <blockquote><pre>template &lt;class Allocator&gt; struct hash&lt;vector&lt;bool, Allocator&gt;&gt;;
31838 </pre>
31839 <blockquote>
31840 A partial specialization of the class template hash (20.7.17 [unord.hash])
31841 shall be provided for vectors of boolean values suitable for use as a key
31842 in unordered associative containers (23.5 [unord]).
31843 </blockquote>
31844 </blockquote>
31845
31846 <p>
31847 Add the following declarations to the synopsis of <tt>&lt;bitset&gt;</tt>
31848 in 20.3.6 [template.bitset]
31849 </p>
31850
31851 <blockquote><pre><ins>
31852 // 20.3.6.X hash support
31853 template &lt;class T&gt; struct hash;
31854 template &lt;size_t N&gt; struct hash&lt;bitset&lt;N&gt; &gt;;
31855 </ins></pre></blockquote>
31856
31857 <p>
31858 Add a new subclause 20.3.6.X [bitset.hash]
31859 </p>
31860
31861 <blockquote>
31862 <p>
31863 20.3.6.X bitset hash support [bitset.hash]
31864 </p>
31865
31866 <pre>template &lt;size_t N&gt; struct hash&lt;bitset&lt;N&gt; &gt;;
31867 </pre>
31868
31869 <blockquote>
31870 A partial specialization of the class template hash
31871 (20.7.17 [unord.hash]) shall be provided for bitsets suitable for use as a key in
31872 unordered associative containers (23.5 [unord]).
31873 </blockquote>
31874 </blockquote>
31875
31876
31877
31878
31879
31880
31881 <hr>
31882 <h3><a name="1183"></a>1183. <tt>basic_ios::set_rdbuf</tt> may break class invariants</h3>
31883 <p><b>Section:</b> 27.5.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
31884  <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2009-07-28  <b>Last modified:</b> 2009-07-28</p>
31885 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p>
31886 <p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
31887 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
31888 <p><b>Discussion:</b></p>
31889 <p>
31890 The protected member function <tt>set_rdbuf</tt> had been added during the
31891 process of adding move and swap semantics to IO classes. A relevant
31892 property of this function is described by it's effects in
31893 27.5.4.2 [basic.ios.members]/19:
31894 </p>
31895
31896 <blockquote>
31897 <i>Effects:</i> Associates the <tt>basic_streambuf</tt> object pointed to by sb with
31898 this stream without calling <tt>clear()</tt>.
31899 </blockquote>
31900
31901 <p>
31902 This means that implementors of or those who derive from existing IO classes
31903 could cause an internal state where the stream buffer could be 0, but the
31904 IO class has the state <tt>good()</tt>. This would break several currently existing
31905 implementations which rely on the fact that setting a stream buffer via the
31906 currently only ways, i.e. either by calling
31907 </p>
31908
31909 <blockquote><pre>void init(basic_streambuf&lt;charT,traits&gt;* sb);
31910 </pre></blockquote>
31911
31912 <p>
31913 or by calling
31914 </p>
31915
31916 <blockquote><pre>basic_streambuf&lt;charT,traits&gt;* rdbuf(basic_streambuf&lt;charT,traits&gt;* sb);
31917 </pre></blockquote>
31918
31919 <p>
31920 to set <tt>rdstate()</tt> to <tt>badbit</tt>, if the buffer is 0. This has the effect that many
31921 internal functions can simply check <tt>rdstate()</tt> instead of <tt>rdbuf()</tt> for being 0.
31922 </p>
31923
31924 <p>
31925 I therefore suggest that a requirement is added for callers of <tt>set_rdbuf</tt> to
31926 set a non-0 value.
31927 </p>
31928
31929
31930 <p><b>Proposed resolution:</b></p>
31931 <p>
31932 Change 27.5.4.2 [basic.ios.members] around p. 19 as indicated (The proposed
31933 resolution fixes also two editorial problems: Some wrong letters in "<tt>clear()</tt>"
31934 and moving the post conditions into a separate paragraph):
31935 </p>
31936
31937 <blockquote><pre>void set_rdbuf(basic_streambuf&lt;charT, traits&gt;* sb);
31938 </pre>
31939
31940 <blockquote>
31941 <p>
31942 <ins><i>Requires:</i> <tt>sb != nullptr</tt>.</ins>
31943 </p>
31944
31945 <p>
31946 <i>Effects:</i> Associates the <tt>basic_streambuf</tt> object pointed to by <tt>sb</tt> with
31947 this stream without
31948 calling <tt>clear()</tt>. <del>Postconditions: rdbuf() == sb.</del>
31949 </p>
31950
31951 <p>
31952 <ins><i>Postconditions:</i> <tt>rdbuf() == sb</tt>.</ins>
31953 </p>
31954
31955 <p>
31956 <i>Throws:</i> Nothing.
31957 </p>
31958
31959 </blockquote>
31960 </blockquote>
31961
31962
31963
31964
31965
31966 <hr>
31967 <h3><a name="1184"></a>1184. Feature request: dynamic bitset</h3>
31968 <p><b>Section:</b> 23.3.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
31969  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-07-29  <b>Last modified:</b> 2009-07-29</p>
31970 <p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#vector">active issues</a> in [vector].</p>
31971 <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>
31972 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
31973 <p><b>Discussion:</b></p>
31974 <p>
31975 Opened at Alisdair's request, steming from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#96">96</a>.
31976 Alisdair recommends NAD Future.
31977 </p>
31978
31979
31980 <p><b>Proposed resolution:</b></p>
31981
31982
31983
31984
31985
31986 <hr>
31987 <h3><a name="1185"></a>1185. iterator categories and output iterators</h3>
31988 <p><b>Section:</b> X [iterator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
31989  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-07-31  <b>Last modified:</b> 2009-07-31</p>
31990 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
31991 <p><b>Discussion:</b></p>
31992 <p>
31993 (wording relative to
31994 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
31995 pending new working paper)
31996 </p>
31997
31998 <p>
31999 According to p3 X [iterator.requirements], Forward iterators,
32000 Bidirectional iterators and Random Access iterators all satisfy the
32001 requirements for an Output iterator:
32002 </p>
32003
32004 <blockquote>
32005 XXX iterators satisfy all the requirements of the input and output iterators
32006 and can be used whenever either kind is specified ...
32007 </blockquote>
32008
32009 <p>
32010 Meanwhile, p4 goes on to contradict this:
32011 </p>
32012
32013 <blockquote>
32014 Besides its category, a forward, bidirectional, or random access
32015 iterator can also be mutable or constant...
32016 </blockquote>
32017
32018 <blockquote>
32019 ... Constant iterators do not satisfy the requirements for output iterators
32020 </blockquote>
32021
32022 <p>
32023 The latter seems to be the overriding concern, as the iterator tag
32024 hierarchy does not define <tt>forward_iterator_tag</tt> as multiply derived from
32025 both <tt>input_iterator_tag</tt> and <tt>output_iterator_tag</tt>.
32026 </p>
32027
32028 <p>
32029 The work on concepts for iterators showed us that output iterator really
32030 is fundamentally a second dimension to the iterator categories, rather
32031 than part of the linear input -&gt; forward -&gt; bidirectional -&gt;
32032 random-access sequence.  It would be good to clear up these words to
32033 reflect that, and separately list output iterator requirements in the
32034 requires clauses for the appropriate algorithms and operations.
32035 </p>
32036
32037
32038 <p><b>Proposed resolution:</b></p>
32039
32040
32041
32042
32043
32044 <hr>
32045 <h3><a name="1186"></a>1186. Forward list could model a stack</h3>
32046 <p><b>Section:</b> 23.3.5.3 [stack] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
32047  <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-07-31  <b>Last modified:</b> 2009-08-01</p>
32048 <p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
32049 <p><b>Discussion:</b></p>
32050 <p>
32051 The library template <tt>forward_list</tt> could easily model the idea of a
32052 <tt>stack</tt>, where the operations work on the front of the list rather than
32053 the back.  However, the standard library <tt>stack</tt> adaptor cannot support
32054 this.
32055 </p>
32056
32057 <p>
32058 It would be relatively easy to write a partial specialization for <tt>stack</tt>
32059 to support <tt>forward_list</tt>, but that opens the question of which header to
32060 place it in.  A much better solution would be to add a <tt>concept_map</tt> for
32061 the <tt>StackLikeContainer</tt> concept to the <tt>&lt;forward_list&gt;</tt> header and then
32062 everything just works, including a user's own further uses in a
32063 stack-like context.
32064 </p>
32065
32066 <p>
32067 Therefore while I am submitting the issue now so that it is on record, I
32068 <em>strongly recommend</em> we resolve as "NAD Concepts" as any non-concepts
32069 based solution will be inferior to the final goal, and the feature is
32070 not so compelling it must be supported ahead of the concepts-based
32071 library.
32072 </p>
32073
32074
32075 <p><b>Proposed resolution:</b></p>
32076
32077
32078
32079
32080
32081 </body></html>