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 Closed Issues List</title>
7<style type="text/css">
8p {text-align:justify}
9li {text-align:justify}
10blockquote.note
11{
12    background-color:#E0E0E0;
13    padding-left: 15px;
14    padding-right: 15px;
15    padding-top: 1px;
16    padding-bottom: 1px;
17}
18ins {background-color:#A0FFA0}
19del {background-color:#FFA0A0}
20</style>
21</head><body>
22<table>
23<tbody><tr>
24<td align="left">Doc. no.</td>
25<td align="left">N3013=09-0203</td>
26</tr>
27<tr>
28<td align="left">Date:</td>
29<td align="left">2009-11-08</td>
30</tr>
31<tr>
32<td align="left">Project:</td>
33<td align="left">Programming Language C++</td>
34</tr>
35<tr>
36<td align="left">Reply to:</td>
37<td align="left">Howard Hinnant &lt;<a href="mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>&gt;</td>
38</tr>
39</tbody></table>
40<h1>C++ Standard Library Closed Issues List (Revision R68)</h1>
41
42  <p>Reference ISO/IEC IS 14882:2003(E)</p>
43  <p>Also see:</p>
44    <ul>
45      <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html">Table of Contents</a> for all library issues.</li>
46      <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html">Index by Section</a> for all library issues.</li>
47      <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html">Index by Status</a> for all library issues.</li>
48      <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a></li>
49      <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a></li>
50    </ul>
51
52  <p>This document contains only library issues which have been closed
53  by the Library Working Group as duplicates or not defects. That is,
54  issues which have a status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> or
55  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>. See the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a> active issues and more
56  information. See the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a> for issues considered
57  defects.  The introductory material in that document also applies to
58  this document.</p>
59
60<h2>Revision History</h2>
61<ul>
62<li>R68: 
632009-11-06 post-Santa Cruz mailing.
64<ul>
65<li><b>Summary:</b><ul>
66<li>205 open issues, down by 77.</li>
67<li>1055 closed issues, up by 120.</li>
68<li>1260 issues total, up by 43.</li>
69</ul></li>
70<li><b>Details:</b><ul>
71<li>Added the following Dup issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1230">1230</a>.</li>
72<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1229">1229</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1236">1236</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1243">1243</a>.</li>
73<li>Added the following NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1232">1232</a>.</li>
74<li>Added the following NAD Future issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1235">1235</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1242">1242</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1248">1248</a>.</li>
75<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1218">1218</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1219">1219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1221">1221</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1222">1222</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1223">1223</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1224">1224</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1225">1225</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1234">1234</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1240">1240</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1244">1244</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1245">1245</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1246">1246</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1249">1249</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1250">1250</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1251">1251</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1252">1252</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1253">1253</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1254">1254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1255">1255</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1256">1256</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1257">1257</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1258">1258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1259">1259</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1260">1260</a>.</li>
76<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1228">1228</a>.</li>
77<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1227">1227</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1237">1237</a>.</li>
78<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1247">1247</a>.</li>
79<li>Added the following Tentatively NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1233">1233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1239">1239</a>.</li>
80<li>Added the following Tentatively NAD Future issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1238">1238</a>.</li>
81<li>Added the following Tentatively Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1220">1220</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1226">1226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1231">1231</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1241">1241</a>.</li>
82<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1132">1132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1148">1148</a>.</li>
83<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#96">96</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#458">458</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#919">919</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#955">955</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#977">977</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1009">1009</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1020">1020</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1035">1035</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1042">1042</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1051">1051</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1064">1064</a>.</li>
84<li>Changed the following issues from Review to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1102">1102</a>.</li>
85<li>Changed the following issues from Tentatively NAD to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#971">971</a>.</li>
86<li>Changed the following issues from Tentatively NAD Future to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1062">1062</a>.</li>
87<li>Changed the following issues from NAD Concepts to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1143">1143</a>.</li>
88<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1116">1116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1117">1117</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1122">1122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1129">1129</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1145">1145</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1146">1146</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1147">1147</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1155">1155</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1166">1166</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1172">1172</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1174">1174</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1179">1179</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1195">1195</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1196">1196</a>.</li>
89<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#431">431</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#880">880</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#908">908</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#947">947</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#958">958</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1046">1046</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1048">1048</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1054">1054</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1055">1055</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1075">1075</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1088">1088</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1160">1160</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1161">1161</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1162">1162</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1163">1163</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1165">1165</a>.</li>
90<li>Changed the following issues from Review to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1043">1043</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1047">1047</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1049">1049</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1050">1050</a>.</li>
91<li>Changed the following issues from New to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1120">1120</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1150">1150</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1184">1184</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1203">1203</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1217">1217</a>.</li>
92<li>Changed the following issues from Open to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#484">484</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#851">851</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#961">961</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1041">1041</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1053">1053</a>.</li>
93<li>Changed the following issues from Tentatively NAD Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1031">1031</a>.</li>
94<li>Changed the following issues from New to Open: <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#1151">1151</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#1156">1156</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#1173">1173</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#1191">1191</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1211">1211</a>.</li>
95<li>Changed the following issues from Ready to Open: <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#834">834</a>.</li>
96<li>Changed the following issues from Review to Open: <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#835">835</a>.</li>
97<li>Changed the following issues from Tentatively NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</a>.</li>
98<li>Changed the following issues from New to Ready: <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-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#1144">1144</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#1194">1194</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1204">1204</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1216">1216</a>.</li>
99<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#296">296</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#485">485</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</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#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#872">872</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#920">920</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#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-active.html#960">960</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#974">974</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#1011">1011</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#1079">1079</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1098">1098</a>.</li>
100<li>Changed the following issues from Review to Ready: <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#854">854</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#871">871</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#921">921</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#954">954</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#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>, <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-active.html#1052">1052</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#1100">1100</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-active.html#1157">1157</a>.</li>
101<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1130">1130</a>.</li>
102<li>Changed the following issues from Open to Review: <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#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#929">929</a>.</li>
103<li>Changed the following issues from Open to Tentatively NAD: <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-active.html#1099">1099</a>.</li>
104<li>Changed the following issues from New to Tentatively NAD Concepts: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1186">1186</a>.</li>
105<li>Changed the following issues from New to Tentatively NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1115">1115</a>.</li>
106<li>Changed the following issues from New to Tentatively NAD Future: <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#1201">1201</a>.</li>
107<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#1112">1112</a>.</li>
108<li>Changed the following issues from New to Tentatively Ready: <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-active.html#1138">1138</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#1158">1158</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1189">1189</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1192">1192</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1208">1208</a>.</li>
109<li>Changed the following issues from Open to Tentatively Ready: <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#999">999</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-active.html#1090">1090</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#1113">1113</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1114">1114</a>.</li>
110<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#419">419</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#696">696</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#838">838</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#881">881</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#883">883</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#886">886</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1004">1004</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1178">1178</a>.</li>
111<li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1019">1019</a>.</li>
112</ul></li>
113</ul>
114</li>
115<li>R67: 
1162009-09-25 pre-Santa Cruz mailing.
117<ul>
118<li><b>Summary:</b><ul>
119<li>282 open issues, up by 32.</li>
120<li>935 closed issues, down by 1.</li>
121<li>1217 issues total, up by 31.</li>
122</ul></li>
123<li><b>Details:</b><ul>
124<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1187">1187</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1188">1188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1189">1189</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1190">1190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1191">1191</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1192">1192</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1193">1193</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1194">1194</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1195">1195</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1196">1196</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1197">1197</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1198">1198</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1199">1199</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1200">1200</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1201">1201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1202">1202</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1203">1203</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1204">1204</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1205">1205</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1206">1206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1207">1207</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1208">1208</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1209">1209</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1210">1210</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1211">1211</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1212">1212</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1213">1213</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1214">1214</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1215">1215</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1216">1216</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1217">1217</a>.</li>
125<li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#296">296</a>.</li>
126<li>Changed the following issues from WP to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#970">970</a>.</li>
127<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1052">1052</a>.</li>
128<li>Changed the following issues from Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>.</li>
129</ul></li>
130</ul>
131</li>
132<li>R66: 
1332009-07-31 post-Frankfurt mailing.
134<ul>
135<li><b>Summary:</b><ul>
136<li>250 open issues, down by 128.</li>
137<li>936 closed issues, up by 171.</li>
138<li>1186 issues total, up by 43.</li>
139</ul></li>
140<li><b>Details:</b><ul>
141<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1164">1164</a>.</li>
142<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>
143<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>
144<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-closed.html#1145">1145</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1146">1146</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1147">1147</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1148">1148</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.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-closed.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-closed.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-closed.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-closed.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-closed.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>
145<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1160">1160</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1161">1161</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1162">1162</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1163">1163</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1165">1165</a>.</li>
146<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1178">1178</a>.</li>
147<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1157">1157</a>.</li>
148<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>
149<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>
150<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>
151<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>
152<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>
153<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>
154<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>
155<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>
156<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>
157<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>
158<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>
159<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>
160<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>
161<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>
162<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>
163<li>Changed the following issues from CD1 to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#823">823</a>.</li>
164<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-closed.html#484">484</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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>
165<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#1009">1009</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1093">1093</a>.</li>
166<li>Changed the following issues from Tentatively NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#458">458</a>.</li>
167<li>Changed the following issues from Tentatively NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#96">96</a>.</li>
168<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-closed.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>
169<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#696">696</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#838">838</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#881">881</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#883">883</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#886">886</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1004">1004</a>.</li>
170<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>
171<li>Changed the following issues from Tentatively NAD to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#822">822</a>.</li>
172<li>Changed the following issues from Tentatively Ready to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#934">934</a>.</li>
173<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>
174<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-closed.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>
175<li>Changed the following issues from Tentatively NAD to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#668">668</a>.</li>
176<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>
177<li>Changed the following issues from Open to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#971">971</a>.</li>
178<li>Changed the following issues from Open to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1031">1031</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1062">1062</a>.</li>
179<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1012">1012</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1019">1019</a>.</li>
180<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>
181</ul></li>
182</ul>
183</li>
184<li>R65: 
1852009-06-19 pre-Frankfurt mailing.
186<ul>
187<li><b>Summary:</b><ul>
188<li>378 open issues, up by 32.</li>
189<li>765 closed issues, up by 0.</li>
190<li>1143 issues total, up by 32.</li>
191</ul></li>
192<li><b>Details:</b><ul>
193<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-closed.html#1116">1116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.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-closed.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-closed.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-closed.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>
194<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>
195<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>
196<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#696">696</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.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-closed.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-closed.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-closed.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-closed.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>
197<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-closed.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-defects.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-defects.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-defects.html#1019">1019</a>.</li>
198<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-closed.html#897">897</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.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-closed.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>
199<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>
200<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>
201<li>Changed the following issues from Open to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>.</li>
202<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>
203<li>Changed the following issues from Tentatively Ready to Tentatively NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#988">988</a>.</li>
204<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>
205<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>
206<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>
207<li>Changed the following issues from Open to Tentatively NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#96">96</a>.</li>
208<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-closed.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>
209<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>
210<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-defects.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>
211</ul></li>
212</ul>
213</li>
214<li>R64: 
2152009-05-01 mid-term mailing.
216<ul>
217<li><b>Summary:</b><ul>
218<li>346 open issues, up by 19.</li>
219<li>765 closed issues, up by 0.</li>
220<li>1111 issues total, up by 19.</li>
221</ul></li>
222<li><b>Details:</b><ul>
223<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-closed.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>
224<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>
225<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>
226</ul></li>
227</ul>
228</li>
229<li>R63: 
2302009-03-20 post-Summit mailing.
231<ul>
232<li><b>Summary:</b><ul>
233<li>327 open issues, up by 96.</li>
234<li>765 closed issues, up by 14.</li>
235<li>1092 issues total, up by 110.</li>
236</ul></li>
237<li><b>Details:</b><ul>
238<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>
239<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>
240<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-closed.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-closed.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-closed.html#1091">1091</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1092">1092</a>.</li>
241<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-closed.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-closed.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-closed.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-closed.html#1041">1041</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1042">1042</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1046">1046</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1048">1048</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#1053">1053</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1055">1055</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1064">1064</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#1088">1088</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1089">1089</a>.</li>
242<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-defects.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-closed.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-defects.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-defects.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-closed.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-closed.html#1047">1047</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1049">1049</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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>
243<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>
244<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>
245<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>
246<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>
247<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>
248<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>
249<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>
250<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>
251<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-defects.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>.</li>
252<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.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-closed.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#924">924</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#926">926</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#930">930</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#936">936</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#944">944</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.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>
253<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#788">788</a>.</li>
254<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>
255<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.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-closed.html#971">971</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#975">975</a>.</li>
256<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>
257<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>
258<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>
259<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-defects.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>
260<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>
261</ul></li>
262</ul>
263</li>
264<li>R62: 
2652009-02-06 pre-Summit mailing.
266<ul>
267<li><b>Summary:</b><ul>
268<li>231 open issues, up by 44.</li>
269<li>751 closed issues, up by 0.</li>
270<li>982 issues total, up by 44.</li>
271</ul></li>
272<li><b>Details:</b><ul>
273<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-closed.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-closed.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-closed.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-closed.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-closed.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-closed.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-closed.html#976">976</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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>
274</ul></li>
275</ul>
276</li>
277<li>R61: 
2782008-12-05 mid-term mailing.
279<ul>
280<li><b>Summary:</b><ul>
281<li>187 open issues, up by 20.</li>
282<li>751 closed issues, up by 0.</li>
283<li>938 issues total, up by 20.</li>
284</ul></li>
285<li><b>Details:</b><ul>
286<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#923">923</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.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-closed.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-closed.html#933">933</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#934">934</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#935">935</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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>
287</ul></li>
288</ul>
289</li>
290<li>R60: 
2912008-10-03 post-San Francisco mailing.
292<ul>
293<li><b>Summary:</b><ul>
294<li>167 open issues, down by 25.</li>
295<li>751 closed issues, up by 65.</li>
296<li>918 issues total, up by 40.</li>
297</ul></li>
298<li><b>Details:</b><ul>
299<li>Added the following CD1 issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#882">882</a>.</li>
300<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#879">879</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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#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-closed.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-closed.html#916">916</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#917">917</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#918">918</a>.</li>
301<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#881">881</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.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>
302<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>
303<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#894">894</a>.</li>
304<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#888">888</a>.</li>
305<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>
306<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>
307<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-closed.html#823">823</a>.</li>
308<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>
309<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>
310<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>
311<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>
312<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>
313<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-closed.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>
314<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#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>
315<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-closed.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-defects.html#838">838</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#877">877</a>.</li>
316<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>
317<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#851">851</a>.</li>
318<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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>
319<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>
320<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>
321<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-defects.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>
322<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>
323</ul></li>
324</ul>
325</li>
326<li>R59: 
3272008-08-22 pre-San Francisco mailing.
328<ul>
329<li><b>Summary:</b><ul>
330<li>192 open issues, up by 9.</li>
331<li>686 closed issues, up by 0.</li>
332<li>878 issues total, up by 9.</li>
333</ul></li>
334<li><b>Details:</b><ul>
335<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-defects.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>
336</ul></li>
337</ul>
338</li>
339<li>R58: 
3402008-07-28 mid-term mailing.
341<ul>
342<li><b>Summary:</b><ul>
343<li>183 open issues, up by 12.</li>
344<li>686 closed issues, down by 4.</li>
345<li>869 issues total, up by 8.</li>
346</ul></li>
347<li><b>Details:</b><ul>
348<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>
349<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>
350<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>
351<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>
352<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>
353</ul></li>
354</ul>
355</li>
356<li>R57: 
3572008-06-27 post-Sophia Antipolis mailing.
358<ul>
359<li><b>Summary:</b><ul>
360<li>171 open issues, down by 20.</li>
361<li>690 closed issues, up by 43.</li>
362<li>861 issues total, up by 23.</li>
363</ul></li>
364<li><b>Details:</b><ul>
365<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#840">840</a>.</li>
366<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-defects.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-defects.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-defects.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>
367<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#839">839</a>.</li>
368<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>
369<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#851">851</a>.</li>
370<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>
371<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>
372<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>
373<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>
374<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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>
375<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>
376<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-defects.html#711">711</a>.</li>
377<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>
378<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>
379<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>
380<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-closed.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#832">832</a>.</li>
381<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>
382<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>
383<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>
384</ul></li>
385</ul>
386</li>
387<li>R56: 
3882008-05-16 pre-Sophia Antipolis mailing.
389<ul>
390<li><b>Summary:</b><ul>
391<li>191 open issues, up by 24.</li>
392<li>647 closed issues, up by 1.</li>
393<li>838 issues total, up by 25.</li>
394</ul></li>
395<li><b>Details:</b><ul>
396<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-defects.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-defects.html#838">838</a>.</li>
397<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>
398</ul></li>
399</ul>
400</li>
401<li>R55: 
4022008-03-14 post-Bellevue mailing.
403<ul>
404<li><b>Summary:</b><ul>
405<li>167 open issues, down by 39.</li>
406<li>646 closed issues, up by 65.</li>
407<li>813 issues total, up by 26.</li>
408</ul></li>
409<li><b>Details:</b><ul>
410<li>Added the following Dup issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a>.</li>
411<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>
412<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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>
413<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>
414<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>
415<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>
416<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>
417<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>
418<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>
419<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>
420<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>
421<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>
422<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>
423<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.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>
424<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>
425<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>
426<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>
427<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>
428<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>
429<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>
430<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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>
431<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>
432<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>
433<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>
434</ul></li>
435</ul>
436</li>
437<li>R54: 
4382008-02-01 pre-Bellevue mailing.
439<ul>
440<li><b>Summary:</b><ul>
441<li>206 open issues, up by 23.</li>
442<li>581 closed issues, up by 0.</li>
443<li>787 issues total, up by 23.</li>
444</ul></li>
445<li><b>Details:</b><ul>
446<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>
447<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>
448<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>
449<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>
450<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>
451<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>
452</ul></li>
453</ul>
454</li>
455<li>R53: 
4562007-12-09 mid-term mailing.
457<ul>
458<li><b>Summary:</b><ul>
459<li>183 open issues, up by 11.</li>
460<li>581 closed issues, down by 1.</li>
461<li>764 issues total, up by 10.</li>
462</ul></li>
463<li><b>Details:</b><ul>
464<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>
465<li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>.</li>
466<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>
467</ul></li>
468</ul>
469</li>
470<li>R52: 
4712007-10-19 post-Kona mailing.
472<ul>
473<li><b>Summary:</b><ul>
474<li>172 open issues, up by 4.</li>
475<li>582 closed issues, up by 27.</li>
476<li>754 issues total, up by 31.</li>
477</ul></li>
478<li><b>Details:</b><ul>
479<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>
480<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>
481<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>
482<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>
483<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-defects.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.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-defects.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-closed.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-defects.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-closed.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>
484<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>
485<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>
486<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>
487<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>
488<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>
489<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>
490<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>
491<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>
492</ul></li>
493</ul>
494</li>
495<li>R51: 
4962007-09-09 pre-Kona mailing.
497<ul>
498<li><b>Summary:</b><ul>
499<li>168 open issues, up by 15.</li>
500<li>555 closed issues, up by 0.</li>
501<li>723 issues total, up by 15.</li>
502</ul></li>
503<li><b>Details:</b><ul>
504<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-defects.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-defects.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-closed.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-defects.html#723">723</a>.</li>
505</ul></li>
506</ul>
507</li>
508<li>R50: 
5092007-08-05 post-Toronto mailing.
510<ul>
511<li><b>Summary:</b><ul>
512<li>153 open issues, down by 5.</li>
513<li>555 closed issues, up by 17.</li>
514<li>708 issues total, up by 12.</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#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>
518<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>
519<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>
520<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>
521<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>
522<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>
523<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>
524<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>
525<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>
526<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>
527<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>
528<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>
529<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>
530<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>
531<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>
532</ul></li>
533</ul>
534</li>
535<li>R49: 
5362007-06-23 pre-Toronto mailing.
537<ul>
538<li><b>Summary:</b><ul>
539<li>158 open issues, up by 13.</li>
540<li>538 closed issues, up by 7.</li>
541<li>696 issues total, up by 20.</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#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-defects.html#696">696</a>.</li>
545<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>
546<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>
547<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>
548<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>
549</ul></li>
550</ul>
551</li>
552<li>R48: 
5532007-05-06 post-Oxford mailing.
554<ul>
555<li><b>Summary:</b><ul>
556<li>145 open issues, down by 33.</li>
557<li>531 closed issues, up by 53.</li>
558<li>676 issues total, up by 20.</li>
559</ul></li>
560<li><b>Details:</b><ul>
561<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-defects.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-closed.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>
562<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>
563<li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
564<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>
565<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>
566<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-defects.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>
567<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>
568<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>
569<li>Changed the following issues from Tentatively Ready to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#594">594</a>.</li>
570<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>
571<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>
572<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>
573<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>
574<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>
575<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>
576</ul></li>
577</ul>
578</li>
579<li>R47: 
5802007-03-09 pre-Oxford mailing.
581<ul>
582<li><b>Summary:</b><ul>
583<li>178 open issues, up by 37.</li>
584<li>478 closed issues, up by 0.</li>
585<li>656 issues total, up by 37.</li>
586</ul></li>
587<li><b>Details:</b><ul>
588<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-defects.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-closed.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>
589<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>
590<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-closed.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>
591<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>
592<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>.</li>
593<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>
594</ul></li>
595</ul>
596</li>
597<li>R46: 
5982007-01-12 mid-term mailing.
599<ul>
600<li><b>Summary:</b><ul>
601<li>141 open issues, up by 11.</li>
602<li>478 closed issues, down by 1.</li>
603<li>619 issues total, up by 10.</li>
604</ul></li>
605<li><b>Details:</b><ul>
606<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-closed.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>
607</ul></li>
608</ul>
609</li>
610<li>R45: 
6112006-11-03 post-Portland mailing.
612<ul>
613<li><b>Summary:</b><ul>
614<li>130 open issues, up by 0.</li>
615<li>479 closed issues, up by 17.</li>
616<li>609 issues total, up by 17.</li>
617</ul></li>
618<li><b>Details:</b><ul>
619<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>
620<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>
621<li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Dup.</li>
622<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>
623<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>
624<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>
625<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>
626</ul></li>
627</ul>
628</li>
629<li>R44: 
6302006-09-08 pre-Portland mailing.
631<ul>
632<li><b>Summary:</b><ul>
633<li>130 open issues, up by 6.</li>
634<li>462 closed issues, down by 1.</li>
635<li>592 issues total, up by 5.</li>
636</ul></li>
637<li><b>Details:</b><ul>
638<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-closed.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>
639</ul></li>
640</ul>
641</li>
642<li>R43: 
6432006-06-23 mid-term mailing.
644<ul>
645<li><b>Summary:</b><ul>
646<li>124 open issues, up by 14.</li>
647<li>463 closed issues, down by 1.</li>
648<li>587 issues total, up by 13.</li>
649</ul></li>
650<li><b>Details:</b><ul>
651<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-closed.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>
652<li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#255">255</a>.</li>
653<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>
654</ul></li>
655</ul>
656</li>
657<li>R42: 
6582006-04-21 post-Berlin mailing.
659<ul>
660<li><b>Summary:</b><ul>
661<li>110 open issues, down by 16.</li>
662<li>464 closed issues, up by 24.</li>
663<li>574 issues total, up by 8.</li>
664</ul></li>
665<li><b>Details:</b><ul>
666<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>
667<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>
668<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-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a> to Open.</li>
669<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>
670<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>
671<li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li>
672</ul></li>
673</ul>
674</li>
675<li>R41: 
6762006-02-24 pre-Berlin mailing.
677<ul>
678<li><b>Summary:</b><ul>
679<li>126 open issues, up by 31.</li>
680<li>440 closed issues, up by 0.</li>
681<li>566 issues total, up by 31.</li>
682</ul></li>
683<li><b>Details:</b><ul>
684<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-defects.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>.</li>
685<li>Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#342">342</a> from Ready to Open.</li>
686<li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#309">309</a>.</li>
687</ul></li>
688</ul>
689</li>
690<li>R40: 
6912005-12-16 mid-term mailing.
692<ul>
693<li><b>Summary:</b><ul>
694<li>95 open issues.</li>
695<li>440 closed issues.</li>
696<li>535 issues total.</li>
697</ul></li>
698<li><b>Details:</b><ul>
699<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-closed.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>
700</ul></li>
701</ul>
702</li>
703<li>R39: 
7042005-10-14 post-Mont Tremblant mailing.
705Added 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>.
706Moved 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.
707Moved 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.
708Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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.
709Moved 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.
710Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
711Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a> from New to Review.
712</li>
713<li>R38: 
7142005-07-03 pre-Mont Tremblant mailing.
715Merged 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>.
716Added 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>
717</li>
718<li>R37: 
7192005-06 mid-term mailing.
720Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#498">498</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#503">503</a>.
721</li>
722<li>R36: 
7232005-04 post-Lillehammer mailing. All issues in "ready" status except
724for <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
725previously in "DR" status were moved to "WP".
726</li>
727<li>R35: 
7282005-03 pre-Lillehammer mailing.
729</li>
730<li>R34: 
7312005-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>.
732</li>
733<li>R33: 
7342004-11 post-Redmond mailing. Reflects actions taken in Redmond.
735</li>
736<li>R32: 
7372004-09 pre-Redmond mailing: reflects new proposed resolutions and
738new issues received after the 2004-07 mailing.  Added
739new 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>.
740</li>
741<li>R31: 
7422004-07 mid-term mailing: reflects new proposed resolutions and
743new issues received after the post-Sydney mailing.  Added
744new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>.
745</li>
746<li>R30: 
747Post-Sydney mailing: reflects decisions made at the Sydney meeting.
748Voted all "Ready" issues from R29 into the working paper.
749Added 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>.
750</li>
751<li>R29: 
752Pre-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>.
753</li>
754<li>R28: 
755Post-Kona mailing: reflects decisions made at the Kona meeting.
756Added 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>.
757</li>
758<li>R27: 
759Pre-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-closed.html#431">431</a>.
760</li>
761<li>R26: 
762Post-Oxford mailing: reflects decisions made at the Oxford meeting.
763All issues in Ready status were voted into DR status.  All issues in
764DR status were voted into WP status.
765</li>
766<li>R25: 
767Pre-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>.
768</li>
769<li>R24: 
770Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
771meeting.  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
772moved 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
773at 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
774concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
775</li>
776<li>R23: 
777Pre-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>.
778Moved issues in the TC to TC status.
779</li>
780<li>R22: 
781Post-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>.
782</li>
783<li>R21: 
784Pre-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>.
785</li>
786<li>R20: 
787Post-Redmond mailing; reflects actions taken in Redmond.  Added
788new 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 
789<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
790not discussed at the meeting.  
791
792All Ready issues were moved to DR status, with the exception of issues
793<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>.
794
795Noteworthy issues discussed at Redmond include 
796<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>, 
797<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>.
798</li>
799<li>R19: 
800Pre-Redmond mailing.  Added new issues 
801<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>.
802</li>
803<li>R18: 
804Post-Copenhagen mailing; reflects actions taken in Copenhagen.
805Added 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
806new 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>.
807
808Changed status of issues
809<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>
810<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>
811<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>
812<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>
813<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>
814<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>
815<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>
816to DR.
817
818Changed status of issues
819<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>
820<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>
821<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>
822<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>
823<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>
824<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>
825<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>
826<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>
827<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>
828to Ready.
829
830Closed issues 
831<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>
832<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>
833<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
834as NAD.
835
836</li>
837<li>R17: 
838Pre-Copenhagen mailing.  Converted issues list to XML.  Added proposed
839resolutions 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>.
840Added 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>.
841</li>
842<li>R16:  
843post-Toronto mailing; reflects actions taken in Toronto. Added new
844issues <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
845<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>,
846<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>,
847<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>,
848<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>,
849<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>,
850<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>,
851<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>,
852<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>,
853<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>,
854<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>,
855<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>,
856<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>,
857<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
858issue <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
859<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
860issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#70">70</a>: signature should be changed both places it
861appears. Fixed issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#160">160</a>: previous version didn't fix
862the bug in enough places.
863</li>
864<li>R15: 
865pre-Toronto mailing. Added issues
866<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
867changes so that we pass Weblint tests.
868</li>
869<li>R14: 
870post-Tokyo II mailing; reflects committee actions taken in
871Tokyo. 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)
872</li>
873<li>R13: 
874pre-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>.
875</li>
876<li>R12: 
877pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to
878<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
879of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>.  Add further rationale to issue
880<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>.
881</li>
882<li>R11: 
883post-Kona mailing: Updated to reflect LWG and full committee actions
884in Kona (99-0048/N1224). Note changed resolution of issues
885<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>
886to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#198">198</a>. Closed issues list split into "defects" and
887"closed" documents.  Changed the proposed resolution of issue
888<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
889of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>.
890</li>
891<li>R10: 
892pre-Kona updated.  Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
893<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>,
894<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
895<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
896</li>
897<li>R9: 
898pre-Kona mailing.  Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to
899<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
900"closed" documents. (99-0030/N1206, 25 Aug 99)
901</li>
902<li>R8: 
903post-Dublin mailing. Updated to reflect LWG and full committee actions
904in Dublin. (99-0016/N1193, 21 Apr 99)
905</li>
906<li>R7: 
907pre-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>,
908<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>,
909<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>,
910<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)
911</li>
912<li>R6: 
913pre-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>,
914and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>.  (99-0007/N1194, 22 Feb 99)
915</li>
916<li>R5: 
917update 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
918<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
919for making list public. (30 Dec 98)
920</li>
921<li>R4: 
922post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
923<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
924issues corrected. (22 Oct 98)
925</li>
926<li>R3: 
927post-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>
928added, many issues updated to reflect LWG consensus (12 Oct 98)
929</li>
930<li>R2: 
931pre-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,
932issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98)
933</li>
934<li>R1: 
935Correction 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
936format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98)
937</li>
938</ul>
939
940<h2>Closed Issues</h2>
941<hr>
942<h3><a name="2"></a>2. Auto_ptr conversions effects incorrect</h3>
943<p><b>Section:</b> D.10.1.3 [auto.ptr.conv] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
944 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1997-12-04  <b>Last modified:</b> 2006-12-29</p>
945<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
946<p><b>Discussion:</b></p>
947<p>Paragraph 1 in "Effects", says "Calls
948p-&gt;release()" where it clearly must be "Calls
949p.release()". (As it is, it seems to require using
950auto_ptr&lt;&gt;::operator-&gt; to refer to X::release, assuming that
951exists.)</p>
952
953
954<p><b>Proposed resolution:</b></p>
955<p>Change 20.6.4.3 [meta.unary.prop] paragraph 1 Effects from 
956"Calls p-&gt;release()" to "Calls p.release()".</p>
957
958
959<p><b>Rationale:</b></p>
960<p>Not a defect: the proposed change is already found in the standard.
961[Originally classified as a defect, later reclassified.]</p>
962
963
964
965
966
967<hr>
968<h3><a name="4"></a>4. Basic_string size_type and difference_type should be implementation defined</h3>
969<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#NAD">NAD</a>
970 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 1997-11-16  <b>Last modified:</b> 2006-12-27</p>
971<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>
972<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
973<p><b>Discussion:</b></p>
974<p>In Morristown we changed the size_type and difference_type typedefs
975for all the other containers to implementation defined with a
976reference to 23.2 [container.requirements].  This should probably also have been
977done for strings. </p>
978
979
980<p><b>Rationale:</b></p>
981<p>Not a defect.  [Originally classified as a defect, later
982reclassified.]  basic_string, unlike the other standard library
983template containers, is severely constrained by its use of
984char_traits. Those types are dictated by the traits class, and are far
985from implementation defined.</p>
986
987
988
989
990
991<hr>
992<h3><a name="6"></a>6. File position not an offset unimplementable</h3>
993<p><b>Section:</b> 27.5.3 [fpos] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
994 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1997-12-15  <b>Last modified:</b> 2006-12-27</p>
995<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fpos">issues</a> in [fpos].</p>
996<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
997<p><b>Discussion:</b></p>
998<p>Table 88, in I/O, is too strict; it's unimplementable on systems
999where a file position isn't just an offset. It also never says just
1000what fpos&lt;&gt; is really supposed to be.  [Here's my summary, which
1001Jerry agrees is more or less accurate. "I think I now know what
1002the class really is, at this point: it's a magic cookie that
1003encapsulates an mbstate_t and a file position (possibly represented as
1004an fpos_t), it has syntactic support for pointer-like arithmetic, and
1005implementors are required to have real, not just syntactic, support
1006for arithmetic." This isn't standardese, of course.] </p>
1007
1008
1009<p><b>Rationale:</b></p>
1010<p>Not a defect. The LWG believes that the Standard is already clear,
1011and that the above summary is what the Standard in effect says.</p>
1012
1013
1014
1015
1016
1017<hr>
1018<h3><a name="10"></a>10. Codecvt&lt;&gt;::do unclear</h3>
1019<p><b>Section:</b> 22.4.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
1020 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-01-14  <b>Last modified:</b> 2006-12-30</p>
1021<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p>
1022<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
1023<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#19">19</a></p>
1024<p><b>Discussion:</b></p>
1025<p>Section 22.2.1.5.2 says that codecvt&lt;&gt;::do_in and do_out
1026should return the value noconv if "no conversion was
1027needed". However, I don't see anything anywhere that defines what
1028it means for a conversion to be needed or not needed. I can think of
1029several circumstances where one might plausibly think that a
1030conversion is not "needed", but I don't know which one is
1031intended here. </p>
1032
1033
1034<p><b>Rationale:</b></p>
1035
1036
1037
1038
1039
1040
1041<hr>
1042<h3><a name="12"></a>12. Way objects hold allocators unclear</h3>
1043<p><b>Section:</b> 20.2.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1044 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1998-02-23  <b>Last modified:</b> 2006-12-30</p>
1045<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>
1046<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1047<p><b>Discussion:</b></p>
1048<p>I couldn't find a statement in the standard saying whether the allocator object held by
1049a container is held as a copy of the constructor argument or whether a pointer of
1050reference is maintained internal. There is an according statement for compare objects and
1051how they are maintained by the associative containers, but I couldn't find anything
1052regarding allocators. </p>
1053
1054<p>Did I overlook it? Is it an open issue or known defect? Or is it deliberately left
1055unspecified? </p>
1056
1057
1058<p><b>Rationale:</b></p>
1059<p>Not a defect. The LWG believes that the Standard is already
1060clear.&nbsp; See 23.2 [container.requirements], paragraph 8.</p>
1061
1062
1063
1064
1065
1066<hr>
1067<h3><a name="43"></a>43. Locale table correction</h3>
1068<p><b>Section:</b> 22.4.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
1069 <b>Submitter:</b> Brendan Kehoe <b>Opened:</b> 1998-06-01  <b>Last modified:</b> 2006-12-30</p>
1070<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p>
1071<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
1072<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#33">33</a></p>
1073<p><b>Discussion:</b></p>
1074
1075
1076<p><b>Rationale:</b></p>
1077
1078
1079
1080
1081
1082
1083<hr>
1084<h3><a name="45"></a>45. Stringstreams read/write pointers initial position unclear</h3>
1085<p><b>Section:</b> 27.8.3 [ostringstream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1086 <b>Submitter:</b> Matthias Mueller <b>Opened:</b> 1998-05-27  <b>Last modified:</b> 2006-12-27</p>
1087<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1088<p><b>Discussion:</b></p>
1089<p>In a comp.lang.c++.moderated Matthias Mueller wrote:</p>
1090
1091<p>"We are not sure how to interpret the CD2 (see 27.3
1092[iostream.forward], 27.8.3.1 [ostringstream.cons], 27.8.1.1
1093[stringbuf.cons])
1094with respect to the question as to what the correct initial positions
1095of the write and&nbsp; read pointers of a stringstream should
1096be."</p>
1097
1098<p>"Is it the same to output two strings or to initialize the stringstream with the
1099first and to output the second?"</p>
1100
1101<p><i>[PJ Plauger, Bjarne Stroustrup, Randy Smithey, Sean Corfield, and
1102Jerry Schwarz have all offered opinions; see reflector messages
1103lib-6518, 6519, 6520, 6521, 6523, 6524.]</i></p>
1104
1105
1106
1107
1108<p><b>Rationale:</b></p>
1109<p>The LWG believes the Standard is correct as written. The behavior
1110of stringstreams is consistent with fstreams, and there is a
1111constructor which can be used to obtain the desired effect. This
1112behavior is known to be different from strstreams.</p>
1113
1114
1115
1116
1117
1118<hr>
1119<h3><a name="58"></a>58. Extracting a char from a wide-oriented stream</h3>
1120<p><b>Section:</b> 27.7.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1121 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-07-01  <b>Last modified:</b> 2006-12-27</p>
1122<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p>
1123<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1124<p><b>Discussion:</b></p>
1125<p>27.6.1.2.3 has member functions for extraction of signed char and
1126unsigned char, both singly and as strings. However, it doesn't say
1127what it means to extract a <tt>char</tt> from a
1128<tt>basic_streambuf&lt;charT, Traits&gt;</tt>. </p>
1129
1130<p>basic_streambuf, after all, has no members to extract a char, so
1131basic_istream must somehow convert from charT to signed char or
1132unsigned char. The standard doesn't say how it is to perform that
1133conversion. </p>
1134
1135
1136<p><b>Rationale:</b></p>
1137<p>The Standard is correct as written.  There is no such extractor and
1138this is the intent of the LWG.</p>
1139
1140
1141
1142
1143<hr>
1144<h3><a name="65"></a>65. Underspecification of strstreambuf::seekoff</h3>
1145<p><b>Section:</b> D.8.1.3 [depr.strstreambuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1146 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-18  <b>Last modified:</b> 2006-12-27</p>
1147<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.strstreambuf.virtuals">issues</a> in [depr.strstreambuf.virtuals].</p>
1148<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1149<p><b>Discussion:</b></p>
1150<p>The standard says how this member function affects the current
1151stream position. (<tt>gptr</tt> or <tt>pptr</tt>) However, it does not
1152say how this member function affects the beginning and end of the
1153get/put area. </p>
1154
1155<p>This is an issue when seekoff is used to position the get pointer
1156beyond the end of the current read area. (Which is legal. This is
1157implicit in the definition of <i>seekhigh</i> in D.7.1, paragraph 4.)
1158</p>
1159
1160
1161<p><b>Rationale:</b></p>
1162<p>The LWG agrees that seekoff() is underspecified, but does not wish
1163to invest effort in this deprecated feature.</p>
1164
1165
1166
1167
1168
1169<hr>
1170<h3><a name="67"></a>67. Setw useless for strings</h3>
1171<p><b>Section:</b> 21.4.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
1172 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1998-07-09  <b>Last modified:</b> 2006-12-30</p>
1173<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</p>
1174<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
1175<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#25">25</a></p>
1176<p><b>Discussion:</b></p>
1177<p>In a comp.std.c++ posting Michel Michaud wrote: What
1178should be output by: </p>
1179
1180<pre>   string text("Hello");
1181   cout &lt;&lt; '[' &lt;&lt; setw(10) &lt;&lt; right &lt;&lt; text &lt;&lt; ']';
1182</pre>
1183
1184<p>Shouldn't it be:</p>
1185
1186<pre>   [     Hello]</pre>
1187
1188<p>Another person replied: Actually, according to the FDIS, the width
1189of the field should be the minimum of width and the length of the
1190string, so the output shouldn't have any padding. I think that this is
1191a typo, however, and that what is wanted is the maximum of the
1192two. (As written, setw is useless for strings. If that had been the
1193intent, one wouldn't expect them to have mentioned using its value.)
1194</p>
1195
1196<p>It's worth pointing out that this is a recent correction anyway;
1197IIRC, earlier versions of the draft forgot to mention formatting
1198parameters whatsoever.</p>
1199
1200
1201<p><b>Rationale:</b></p>
1202
1203
1204
1205
1206
1207
1208<hr>
1209<h3><a name="72"></a>72. Do_convert phantom member function</h3>
1210<p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
1211 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-08-24  <b>Last modified:</b> 2006-12-30</p>
1212<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
1213<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
1214<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#24">24</a></p>
1215<p><b>Discussion:</b></p>
1216<p>In 22.4.1.4 [locale.codecvt] par 3, and in 22.4.1.4.2 [locale.codecvt.virtuals] par 8, a nonexistent member function
1217"do_convert" is mentioned. This member was replaced with
1218"do_in" and "do_out", the proper referents in the
1219contexts above.</p>
1220
1221
1222<p><b>Rationale:</b></p>
1223
1224
1225
1226
1227
1228<hr>
1229<h3><a name="73"></a>73. <tt>is_open</tt> should be const</h3>
1230<p><b>Section:</b> 27.9.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1231 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-08-27  <b>Last modified:</b> 2006-12-27</p>
1232<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fstreams">issues</a> in [fstreams].</p>
1233<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1234<p><b>Discussion:</b></p>
1235<p>Classes <tt>basic_ifstream</tt>, <tt>basic_ofstream</tt>, and
1236<tt>basic_fstream</tt> all have a member function <tt>is_open</tt>. It
1237should be a <tt>const</tt> member function, since it does nothing but
1238call one of <tt>basic_filebuf</tt>'s const member functions. </p>
1239
1240
1241<p><b>Rationale:</b></p>
1242<p>Not a defect. This is a deliberate feature; const streams would be
1243meaningless.</p>
1244
1245
1246
1247
1248<hr>
1249<h3><a name="77"></a>77. Valarray operator[] const returning value</h3>
1250<p><b>Section:</b> 26.6.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
1251 <b>Submitter:</b> Levente Farkas <b>Opened:</b> 1998-09-09  <b>Last modified:</b> 2007-10-11</p>
1252<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.access">issues</a> in [valarray.access].</p>
1253<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
1254<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a></p>
1255<p><b>Discussion:</b></p>
1256<p>valarray:<br>
1257<br>
1258&nbsp;&nbsp;&nbsp; <tt>T operator[] (size_t) const;</tt><br>
1259<br>
1260why not <br>
1261<br>
1262&nbsp;&nbsp;&nbsp; <tt>const T&amp; operator[] (size_t) const;</tt><br>
1263<br>
1264as in vector ???<br>
1265<br>
1266One can't copy even from a const valarray eg:<br>
1267<br>
1268&nbsp;&nbsp;&nbsp; <tt>memcpy(ptr, &amp;v[0], v.size() * sizeof(double));<br>
1269</tt><br>
1270[I] find this bug in valarray is very difficult.</p>
1271
1272
1273<p><b>Rationale:</b></p>
1274<p>The LWG believes that the interface was deliberately designed that
1275way. That is what valarray was designed to do; that's where the
1276"value array" name comes from. LWG members further comment
1277that "we don't want valarray to be a full STL container."
127826.6.2.3 [valarray.access] specifies properties that indicate "an
1279absence of aliasing" for non-constant arrays; this allows
1280optimizations, including special hardware optimizations, that are not
1281otherwise possible. </p>
1282
1283
1284
1285
1286
1287<hr>
1288<h3><a name="81"></a>81. Wrong declaration of slice operations</h3>
1289<p><b>Section:</b> 26.6.5 [template.slice.array], 26.6.7 [template.gslice.array], 26.6.8 [template.mask.array], 26.6.9 [template.indirect.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1290 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29  <b>Last modified:</b> 2006-12-29</p>
1291<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.slice.array">issues</a> in [template.slice.array].</p>
1292<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1293<p><b>Discussion:</b></p>
1294<p>Isn't the definition of copy constructor and assignment operators wrong?
1295&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Instead of</p>
1296
1297<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; slice_array(const slice_array&amp;); 
1298&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; slice_array&amp; operator=(const slice_array&amp;);</pre>
1299
1300<p>IMHO they have to be</p>
1301
1302<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;slice_array(const slice_array&lt;T&gt;&amp;); 
1303&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;slice_array&amp; operator=(const slice_array&lt;T&gt;&amp;);</pre>
1304
1305<p>Same for gslice_array. </p>
1306
1307
1308<p><b>Rationale:</b></p>
1309<p>Not a defect. The Standard is correct as written. </p>
1310
1311
1312
1313
1314<hr>
1315<h3><a name="82"></a>82. Missing constant for set elements</h3>
1316<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#NAD">NAD</a>
1317 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29  <b>Last modified:</b> 2007-01-15</p>
1318<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
1319<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>
1320<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1321<p><b>Discussion:</b></p>
1322<p>Paragraph 5 specifies:</p>
1323
1324<blockquote><p>
1325For set and multiset the value type is the same as the key type. For
1326map and multimap it is equal to pair&lt;const Key, T&gt;.  
1327</p></blockquote>
1328
1329<p>Strictly speaking, this is not correct because for set and multiset
1330the value type is the same as the <b>constant</b> key type.</p>
1331
1332
1333<p><b>Rationale:</b></p>
1334<p>Not a defect. The Standard is correct as written; it uses a
1335different mechanism (const &amp;) for <tt>set</tt> and
1336<tt>multiset</tt>. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> for a related
1337issue.</p>
1338
1339
1340
1341
1342<hr>
1343<h3><a name="84"></a>84. Ambiguity with string::insert()</h3>
1344<p><b>Section:</b> 21.4.5 [string.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1345 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29  <b>Last modified:</b> 2006-12-27</p>
1346<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1347<p><b>Discussion:</b></p>
1348<p>If I try</p>
1349<pre>    s.insert(0,1,' ');</pre>
1350
1351<p>&nbsp; I get an nasty ambiguity. It might be</p>
1352<pre>    s.insert((size_type)0,(size_type)1,(charT)' ');</pre>
1353
1354<p>which inserts 1 space character at position 0, or</p>
1355<pre>    s.insert((char*)0,(size_type)1,(charT)' ')</pre>
1356
1357<p>which inserts 1 space character at iterator/address 0 (bingo!), or</p>
1358<pre>    s.insert((char*)0, (InputIterator)1, (InputIterator)' ')</pre>
1359
1360<p>which normally inserts characters from iterator 1 to iterator '
1361'. But according to 23.1.1.9 (the "do the right thing" fix)
1362it is equivalent to the second. However, it is still ambiguous,
1363because of course I mean the first!</p>
1364
1365
1366<p><b>Rationale:</b></p>
1367<p>Not a defect. The LWG believes this is a "genetic
1368misfortune" inherent in the design of string and thus not a
1369defect in the Standard as such .</p>
1370
1371
1372
1373
1374<hr>
1375<h3><a name="85"></a>85. String char types</h3>
1376<p><b>Section:</b> 21 [strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1377 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29  <b>Last modified:</b> 2006-12-27</p>
1378<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#strings">issues</a> in [strings].</p>
1379<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1380<p><b>Discussion:</b></p>
1381<p>The standard seems not to require that charT is equivalent to
1382traits::char_type. So, what happens if charT is not equivalent to
1383traits::char_type?</p>
1384
1385
1386<p><b>Rationale:</b></p>
1387<p>There is already wording in 21.2 [char.traits] paragraph 3 that
1388requires them to be the same.</p>
1389
1390
1391
1392
1393<hr>
1394<h3><a name="87"></a>87. Error in description of string::compare()</h3>
1395<p><b>Section:</b> 21.4.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
1396 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29  <b>Last modified:</b> 2006-12-30</p>
1397<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::swap">issues</a> in [string::swap].</p>
1398<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
1399<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#5">5</a></p>
1400<p><b>Discussion:</b></p>
1401<p>The following compare() description is obviously a bug:</p>
1402
1403<pre>int compare(size_type pos, size_type n1, 
1404            charT *s, size_type n2 = npos) const;
1405</pre>
1406
1407<p>because without passing n2 it should compare up to the end of the
1408string instead of comparing npos characters (which throws an
1409exception) </p>
1410
1411
1412<p><b>Rationale:</b></p>
1413
1414
1415
1416
1417
1418<hr>
1419<h3><a name="88"></a>88. Inconsistency between string::insert() and string::append()</h3>
1420<p><b>Section:</b> 21.4.6.4 [string::insert], 21.4.6.2 [string::append] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1421 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29  <b>Last modified:</b> 2006-12-27</p>
1422<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::insert">issues</a> in [string::insert].</p>
1423<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1424<p><b>Discussion:</b></p>
1425<p>Why does </p>
1426<pre>  template&lt;class InputIterator&gt; 
1427       basic_string&amp; append(InputIterator first, InputIterator last);</pre>
1428
1429<p>return a string, while</p>
1430<pre>  template&lt;class InputIterator&gt; 
1431       void insert(iterator p, InputIterator first, InputIterator last);</pre>
1432
1433<p>returns nothing ?</p>
1434
1435
1436<p><b>Rationale:</b></p>
1437<p>The LWG believes this stylistic inconsistency is not sufficiently 
1438serious to constitute a defect.</p>
1439
1440
1441
1442
1443<hr>
1444<h3><a name="89"></a>89. Missing throw specification for string::insert() and string::replace()</h3>
1445<p><b>Section:</b> 21.4.6.4 [string::insert], 21.4.6.6 [string::replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
1446 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29  <b>Last modified:</b> 2006-12-30</p>
1447<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::insert">issues</a> in [string::insert].</p>
1448<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
1449<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a></p>
1450<p><b>Discussion:</b></p>
1451<p>All insert() and replace() members for strings with an iterator as
1452first argument lack a throw specification. The throw
1453specification should probably be: length_error if size exceeds
1454maximum. </p>
1455
1456
1457<p><b>Rationale:</b></p>
1458<p>Considered a duplicate because it will be solved by the resolution
1459of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>.</p>
1460
1461
1462
1463
1464
1465<hr>
1466<h3><a name="93"></a>93. Incomplete Valarray Subset Definitions</h3>
1467<p><b>Section:</b> 26.6 [numarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1468 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1998-09-29  <b>Last modified:</b> 2006-12-29</p>
1469<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numarray">issues</a> in [numarray].</p>
1470<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1471<p><b>Discussion:</b></p>
1472<p>You can easily create subsets, but you can't easily combine them
1473with other subsets.  Unfortunately, you almost always needs an
1474explicit type conversion to valarray. This is because the standard
1475does not specify that valarray subsets provide the same operations as
1476valarrays. </p>
1477
1478<p>For example, to multiply two subsets and assign the result to a third subset, you can't
1479write the following:</p>
1480
1481<pre>va[slice(0,4,3)] = va[slice(1,4,3)] * va[slice(2,4,3)];</pre>
1482
1483<p>Instead, you have to code as follows:</p>
1484
1485<pre>va[slice(0,4,3)] = static_cast&lt;valarray&lt;double&gt; &gt;(va[slice(1,4,3)]) * 
1486                   static_cast&lt;valarray&lt;double&gt; &gt;(va[slice(2,4,3)]);</pre>
1487
1488<p>This is tedious and error-prone. Even worse, it costs performance because each cast
1489creates a temporary objects, which could be avoided without the cast. </p>
1490
1491
1492<p><b>Proposed resolution:</b></p>
1493<p>Extend all valarray subset types so that they offer all valarray operations.</p>
1494
1495
1496<p><b>Rationale:</b></p>
1497<p>This is not a defect in the Standard; it is a request for an extension.</p>
1498
1499
1500
1501
1502<hr>
1503<h3><a name="94"></a>94. May library implementors add template parameters to Standard Library classes?</h3>
1504<p><b>Section:</b> 17.6.4 [conforming] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1505 <b>Submitter:</b> Matt Austern <b>Opened:</b> 1998-01-22  <b>Last modified:</b> 2006-12-27</p>
1506<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1507<p><b>Discussion:</b></p>
1508<p>Is it a permitted extension for library implementors to add template parameters to
1509standard library classes, provided that those extra parameters have defaults? For example,
1510instead of defining <tt>template &lt;class T, class Alloc = allocator&lt;T&gt; &gt; class
1511vector;</tt> defining it as <tt>template &lt;class T, class Alloc = allocator&lt;T&gt;,
1512int N = 1&gt; class vector;</tt> </p>
1513
1514<p>The standard may well already allow this (I can't think of any way that this extension
1515could break a conforming program, considering that users are not permitted to
1516forward-declare standard library components), but it ought to be explicitly permitted or
1517forbidden. </p>
1518
1519<p>comment from Steve Cleary via comp.std.c++:</p>
1520<blockquote>
1521<p>I disagree [with the proposed resolution] for the following reason:
1522consider user library code with template template parameters. For
1523example, a user library object may be templated on the type of
1524underlying sequence storage to use (deque/list/vector), since these
1525classes all take the same number and type of template parameters; this
1526would allow the user to determine the performance tradeoffs of the
1527user library object. A similar example is a user library object
1528templated on the type of underlying set storage (set/multiset) or map
1529storage (map/multimap), which would allow users to change (within
1530reason) the semantic meanings of operations on that object.</p>
1531<p>I think that additional template parameters should be forbidden in
1532the Standard classes. Library writers don't lose any expressive power,
1533and can still offer extensions because additional template parameters
1534may be provided by a non-Standard implementation class:</p>
1535<pre> 
1536   template &lt;class T, class Allocator = allocator&lt;T&gt;, int N = 1&gt;
1537   class __vector
1538   { ... };
1539   template &lt;class T, class Allocator = allocator&lt;T&gt; &gt;
1540   class vector: public __vector&lt;T, Allocator&gt;
1541   { ... };
1542</pre>
1543
1544</blockquote>
1545
1546
1547
1548<p><b>Proposed resolution:</b></p>
1549<p>Add a new subclause [presumably 17.4.4.9] following 17.6.4.11 [res.on.exception.handling]:</p>
1550
1551<blockquote>
1552  <p>17.4.4.9 Template Parameters</p> <p>A specialization of a
1553  template class described in the C++ Standard Library behaves the
1554  same as if the implementation declares no additional template
1555  parameters.</p> <p>Footnote: Additional template parameters with
1556  default values are thus permitted.</p>
1557</blockquote>
1558
1559<p>Add "template parameters" to the list of subclauses at
1560the end of 17.6.4 [conforming] paragraph 1.</p>
1561
1562<p><i>[Kona: The LWG agreed the standard needs clarification. After
1563discussion with John Spicer, it seems added template parameters can be
1564detected by a program using template-template parameters. A straw vote
1565- "should implementors be allowed to add template
1566parameters?" found no consensus ; 5 - yes, 7 - no.]</i></p>
1567
1568
1569
1570
1571<p><b>Rationale:</b></p>
1572<p>
1573There is no ambiguity; the standard is clear as written.  Library
1574implementors are not permitted to add template parameters to standard
1575library classes.  This does not fall under the "as if" rule,
1576so it would be permitted only if the standard gave explicit license
1577for implementors to do this.  This would require a change in the 
1578standard.
1579</p>
1580
1581<p>
1582The LWG decided against making this change, because it would break
1583user code involving template template parameters or specializations
1584of standard library class templates.
1585</p>
1586
1587
1588
1589
1590
1591<hr>
1592<h3><a name="95"></a>95. Members added by the implementation</h3>
1593<p><b>Section:</b> 17.6.4.5 [member.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1594 <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07  <b>Last modified:</b> 2006-12-27</p>
1595<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1596<p><b>Discussion:</b></p>
1597<p>In 17.3.4.4/2 vs 17.3.4.7/0 there is a hole; an implementation could add virtual
1598members a base class and break user derived classes.</p>
1599
1600<p>Example: </p>
1601
1602<blockquote>
1603  <pre>// implementation code:
1604struct _Base { // _Base is in the implementer namespace
1605        virtual void foo ();
1606};
1607class vector : _Base // deriving from a class is allowed
1608{ ... };
1609
1610// user code:
1611class vector_checking : public vector 
1612{
1613        void foo (); // don't want to override _Base::foo () as the 
1614                     // user doesn't know about _Base::foo ()
1615};</pre>
1616</blockquote>
1617
1618
1619<p><b>Proposed resolution:</b></p>
1620<p>Clarify the wording to make the example illegal.</p>
1621
1622
1623<p><b>Rationale:</b></p>
1624<p>This is not a defect in the Standard.&nbsp; The example is already
1625illegal.&nbsp; See 17.6.4.5 [member.functions] paragraph 2.</p>
1626
1627
1628
1629
1630<hr>
1631<h3><a name="96"></a>96. Vector&lt;bool&gt; is not a container</h3>
1632<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#NAD">NAD</a>
1633 <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07  <b>Last modified:</b> 2009-10-26</p>
1634<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>
1635<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1636<p><b>Discussion:</b></p>
1637<p><tt>vector&lt;bool&gt;</tt> is not a container as its reference and
1638pointer types are not references and pointers. </p>
1639
1640<p>Also it forces everyone to have a space optimization instead of a
1641speed one.</p>
1642
1643<p><b>See also:</b> 99-0008 == N1185 Vector&lt;bool&gt; is
1644Nonconforming, Forces Optimization Choice.</p>
1645
1646<p><i>[In Santa Cruz the LWG felt that this was Not A Defect.]</i></p>
1647
1648
1649<p><i>[In Dublin many present felt that failure to meet Container
1650requirements was a defect. There was disagreement as to whether
1651or not the optimization requirements constituted a defect.]</i></p>
1652
1653
1654<p><i>[The LWG looked at the following resolutions in some detail:
1655<br>
1656&nbsp;&nbsp;&nbsp;&nbsp; * Not A Defect.<br>
1657&nbsp;&nbsp;&nbsp;&nbsp; * Add a note explaining that vector&lt;bool&gt; does not meet
1658Container requirements.<br>
1659&nbsp;&nbsp;&nbsp;&nbsp; * Remove vector&lt;bool&gt;.<br>
1660&nbsp;&nbsp;&nbsp;&nbsp; * Add a new category of container requirements which
1661vector&lt;bool&gt; would meet.<br>
1662&nbsp;&nbsp;&nbsp;&nbsp; * Rename vector&lt;bool&gt;.<br>
1663<br>
1664No alternative had strong, wide-spread, support and every alternative
1665had at least one "over my dead body" response.<br>
1666<br>
1667There was also mention of a transition scheme something like (1) add
1668vector_bool and deprecate vector&lt;bool&gt; in the next standard. (2)
1669Remove vector&lt;bool&gt; in the following standard.]</i></p>
1670
1671
1672<p><i>[Modifying container requirements to permit returning proxies
1673(thus allowing container requirements conforming vector&lt;bool&gt;)
1674was also discussed.]</i></p>
1675
1676
1677<p><i>[It was also noted that there is a partial but ugly workaround in
1678that vector&lt;bool&gt; may be further specialized with a customer
1679allocator.]</i></p>
1680
1681
1682<p><i>[Kona: Herb Sutter presented his paper J16/99-0035==WG21/N1211,
1683vector&lt;bool&gt;: More Problems, Better Solutions. Much discussion
1684of a two step approach: a) deprecate, b) provide replacement under a
1685new name.  LWG straw vote on that: 1-favor, 11-could live with, 2-over
1686my dead body.  This resolution was mentioned in the LWG report to the
1687full committee, where several additional committee members indicated
1688over-my-dead-body positions.]</i></p>
1689
1690
1691<p>Discussed at Lillehammer.  General agreement that we should
1692  deprecate vector&lt;bool&gt; and introduce this functionality under
1693  a different name, e.g. bit_vector.  This might make it possible to
1694  remove the vector&lt;bool&gt; specialization in the standard that comes
1695  after C++0x. There was also a suggestion that
1696  in C++0x we could additional say that it's implementation defined
1697  whether vector&lt;bool&gt; refers to the specialization or to the
1698  primary template, but there wasn't general agreement that this was a
1699  good idea.</p>
1700
1701<p>We need a paper for the new bit_vector class.</p>
1702
1703<p><i>[
1704Batavia:
1705]</i></p>
1706
1707<blockquote>
1708The LWG feels we need something closer to SGI's <tt>bitvector</tt> to ease migration
1709from <tt>vector&lt;bool&gt;</tt>.  Although some of the funcitonality from
1710<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2050.pdf">N2050</a>
1711could well be used in such a template.  The concern is easing the API migration for those
1712users who want to continue using a bit-packed container.  Alan and Beman to work.
1713</blockquote>
1714
1715<p><i>[
1716Post Summit Alisdair adds:
1717]</i></p>
1718
1719
1720<blockquote>
1721<p>
1722<tt>vector&lt;bool&gt;</tt> is now a conforming container under the revised terms of C++0x,
1723which supports containers of proxies.
1724</p>
1725<p>
1726Recommend NAD.
1727</p>
1728<p>
1729Two issues remain:
1730</p>
1731<p>
1732i/ premature optimization in the specification.
1733There is still some sentiment that deprecation is the correct way to go,
1734although it is still not clear what it would mean to deprecate a single
1735specialization of a template.
1736</p>
1737<p>
1738Recommend: Create a new issue for the discussion, leave as Open.
1739</p>
1740<p>
1741ii/ Request for a new bitvector class to guarantee the optimization, perhaps
1742with a better tuned interface.
1743</p>
1744<p>
1745This is a clear extension request that may be handled via a future TR.
1746</p>
1747</blockquote>
1748
1749<p><i>[
1750Batavia (2009-05):
1751]</i></p>
1752
1753<blockquote>
1754We note that most of this issue has become moot over time,
1755and agree with Alisdair's recommendations.
1756Move to NAD Future for reconsideration of part (ii).
1757</blockquote>
1758
1759<p><i>[
17602009-07-29 Alisdair reopens:
1761]</i></p>
1762
1763
1764<blockquote>
1765<p>
1766This infamous issue was closed as NAD Future when concepts introduced
1767support for proxy iterators, so the only remaining requirement was to
1768provide a better type to support bitsets of dynamic length.  I fear we
1769must re-open this issue until the post-concept form of iterators is
1770available, and hopefully will support the necessary proxy functionality
1771to allow us to close this issue as NAD.
1772</p>
1773
1774<p>
1775I recommend we spawn a separate issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1184">1184</a>) requesting a dynamic length bitset
1776and pre-emptively file it as NAD Future.  It is difficult to resolve #96
1777when it effectively contains two separate sub-issues.
1778</p>
1779</blockquote>
1780
1781<p><i>[
17822009-10 Santa Cruz:
1783]</i></p>
1784
1785
1786<blockquote>
1787Mark as NAD, and give rationale.
1788</blockquote>
1789
1790
1791
1792<p><b>Proposed resolution:</b></p>
1793<p>
1794We now have:
1795<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2050.pdf">N2050</a>
1796and
1797<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2160.html">N2160</a>.
1798</p>
1799
1800
1801
1802<p><b>Rationale:</b></p>
1803<p>
1804We want to support proxy iterators but that is going to be separate
1805work. Don't want to see this issue come back in these kinds of terms.
1806We're interested in a separate container, and proxy iterators, but both
1807of those are separate issues.
1808</p>
1809<p>
1810We've looked at a lot of ways to fix this that would be close to this,
1811but those things would break existing code. Attempts to fix this
1812directly have not been tractable, and removing it has not been
1813tractable. Therefore we are closing.
1814</p>
1815
1816
1817
1818
1819
1820<hr>
1821<h3><a name="97"></a>97. Insert inconsistent definition</h3>
1822<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1823 <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07  <b>Last modified:</b> 2006-12-27</p>
1824<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>
1825<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>
1826<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1827<p><b>Discussion:</b></p>
1828<p><tt>insert(iterator, const value_type&amp;)</tt> is defined both on
1829sequences and on set, with unrelated semantics: insert here (in
1830sequences), and insert with hint (in associative containers). They
1831should have different names (B.S. says: do not abuse overloading).</p>
1832
1833
1834<p><b>Rationale:</b></p>
1835<p>This is not a defect in the Standard. It is a genetic misfortune of
1836the design, for better or for worse.</p>
1837
1838
1839
1840
1841<hr>
1842<h3><a name="99"></a>99. Reverse_iterator comparisons completely wrong</h3>
1843<p><b>Section:</b> 24.5.1.3.13 [reverse.iter.op==] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1844 <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07  <b>Last modified:</b> 2006-12-27</p>
1845<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1846<p><b>Discussion:</b></p>
1847<p>The &lt;, &gt;, &lt;=, &gt;= comparison operator are wrong: they
1848return the opposite of what they should.</p>
1849
1850<p>Note: same problem in CD2, these were not even defined in CD1.  SGI
1851STL code is correct; this problem is known since the Morristown
1852meeting but there it was too late</p>
1853
1854
1855<p><b>Rationale:</b></p>
1856<p>This is not a defect in the Standard. A careful reading shows the Standard is correct
1857as written. A review of several implementations show that they implement
1858exactly what the Standard says.</p>
1859
1860
1861
1862
1863<hr>
1864<h3><a name="100"></a>100. Insert iterators/ostream_iterators overconstrained</h3>
1865<p><b>Section:</b> 24.5.2 [insert.iterators], 24.6.4 [ostreambuf.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1866 <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07  <b>Last modified:</b> 2006-12-27</p>
1867<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>
1868<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1869<p><b>Discussion:</b></p>
1870<p>Overspecified For an insert iterator it, the expression *it is
1871required to return a reference to it. This is a simple possible
1872implementation, but as the SGI STL documentation says, not the only
1873one, and the user should not assume that this is the case.</p>
1874
1875
1876<p><b>Rationale:</b></p>
1877<p>The LWG believes this causes no harm and is not a defect in the
1878standard. The only example anyone could come up with caused some
1879incorrect code to work, rather than the other way around.</p>
1880
1881
1882
1883
1884
1885<hr>
1886<h3><a name="101"></a>101. No way to free storage for vector and deque</h3>
1887<p><b>Section:</b> 23.3.6 [vector], 23.3.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1888 <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07  <b>Last modified:</b> 2007-02-19</p>
1889<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>
1890<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1891<p><b>Discussion:</b></p>
1892<p>Reserve can not free storage, unlike string::reserve</p>
1893
1894
1895<p><b>Rationale:</b></p>
1896<p>This is not a defect in the Standard. The LWG has considered this
1897issue in the past and sees no need to change the Standard. Deque has
1898no reserve() member function. For vector, shrink-to-fit can be
1899expressed in a single line of code (where <tt>v</tt> is
1900<tt>vector&lt;T&gt;</tt>):
1901</p>
1902
1903<blockquote>
1904  <p><tt>vector&lt;T&gt;(v).swap(v);&nbsp; // shrink-to-fit v</tt></p>
1905</blockquote>
1906
1907
1908
1909
1910
1911<hr>
1912<h3><a name="102"></a>102. Bug in insert range in associative containers</h3>
1913<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#Dup">Dup</a>
1914 <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07  <b>Last modified:</b> 2006-12-30</p>
1915<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
1916<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>
1917<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
1918<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a></p>
1919<p><b>Discussion:</b></p>
1920<p>Table 69 of Containers say that a.insert(i,j) is linear if [i, j) is ordered. It seems
1921impossible to implement, as it means that if [i, j) = [x], insert in an associative
1922container is O(1)!</p>
1923
1924
1925<p><b>Proposed resolution:</b></p>
1926<p>N+log (size()) if [i,j) is sorted according to value_comp()</p>
1927
1928
1929<p><b>Rationale:</b></p>
1930<p>Subsumed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a>.</p>
1931
1932
1933
1934
1935
1936<hr>
1937<h3><a name="104"></a>104. Description of basic_string::operator[] is unclear</h3>
1938<p><b>Section:</b> 21.4.4 [string.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1939 <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07  <b>Last modified:</b> 2006-12-27</p>
1940<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.capacity">issues</a> in [string.capacity].</p>
1941<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1942<p><b>Discussion:</b></p>
1943<p>It is not clear that undefined behavior applies when pos == size ()
1944for the non const version.</p>
1945
1946
1947<p><b>Proposed resolution:</b></p>
1948<p>Rewrite as: Otherwise, if pos &gt; size () or pos == size () and
1949the non-const version is used, then the behavior is undefined.</p>
1950
1951
1952<p><b>Rationale:</b></p>
1953<p>The Standard is correct. The proposed resolution already appears in
1954the Standard.</p>
1955
1956
1957
1958
1959<hr>
1960<h3><a name="105"></a>105. fstream ctors argument types desired</h3>
1961<p><b>Section:</b> 27.9 [file.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
1962 <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07  <b>Last modified:</b> 2008-01-05</p>
1963<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
1964<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#454">454</a></p>
1965<p><b>Discussion:</b></p>
1966
1967
1968<p>fstream ctors take a const char* instead of string.<br>
1969fstream ctors can't take wchar_t</p>
1970
1971<p>An extension to add a const wchar_t* to fstream would make the
1972implementation non conforming.</p>
1973
1974
1975<p><b>Rationale:</b></p>
1976<p>This is not a defect in the Standard. It might be an
1977interesting extension for the next Standard. </p>
1978
1979
1980
1981
1982<hr>
1983<h3><a name="107"></a>107. Valarray constructor is strange</h3>
1984<p><b>Section:</b> 26.6.2 [template.valarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
1985 <b>Submitter:</b> AFNOR <b>Opened:</b> 1998-10-07  <b>Last modified:</b> 2006-12-29</p>
1986<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.valarray">issues</a> in [template.valarray].</p>
1987<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
1988<p><b>Discussion:</b></p>
1989<p>The order of the arguments is (elem, size) instead of the normal
1990(size, elem) in the rest of the library. Since elem often has an
1991integral or floating point type, both types are convertible to each
1992other and reversing them leads to a well formed program.</p>
1993
1994
1995<p><b>Proposed resolution:</b></p>
1996<p>Inverting the arguments could silently break programs. Introduce
1997the two signatures (const T&amp;, size_t) and (size_t, const T&amp;),
1998but make the one we do not want private so errors result in a
1999diagnosed access violation. This technique can also be applied to STL
2000containers.</p>
2001
2002
2003<p><b>Rationale:</b></p>
2004<p>The LWG believes that while the order of arguments is unfortunate,
2005it does not constitute a defect in the standard. The LWG believes that
2006the proposed solution will not work for valarray&lt;size_t&gt; and
2007perhaps other cases.</p>
2008
2009
2010
2011
2012<hr>
2013<h3><a name="111"></a>111. istreambuf_iterator::equal overspecified, inefficient</h3>
2014<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#NAD">NAD</a>
2015 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 1998-10-15  <b>Last modified:</b> 2009-07-14</p>
2016<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>
2017<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2018<p><b>Discussion:</b></p>
2019<p>The member istreambuf_iterator&lt;&gt;::equal is specified to be
2020unnecessarily inefficient. While this does not affect the efficiency
2021of conforming implementations of iostreams, because they can
2022"reach into" the iterators and bypass this function, it does
2023affect users who use istreambuf_iterators. </p>
2024
2025<p>The inefficiency results from a too-scrupulous definition, which
2026requires a "true" result if neither iterator is at eof. In
2027practice these iterators can only usefully be compared with the
2028"eof" value, so the extra test implied provides no benefit,
2029but slows down users' code. </p>
2030
2031<p>The solution is to weaken the requirement on the function to return
2032true only if both iterators are at eof. </p>
2033
2034<p><i>[
2035Summit:
2036]</i></p>
2037
2038
2039<blockquote>
2040Reopened by Alisdair.
2041</blockquote>
2042
2043<p><i>[
2044Post Summit Daniel adds:
2045]</i></p>
2046
2047
2048<blockquote>
2049<p>
2050Recommend NAD. The proposed wording would violate the axioms of
2051concept requirement <tt>EqualityComparable</tt> axioms as part of concept <tt>InputIterator</tt>
2052and more specifically it would violate the explicit wording of
205324.2.1 [input.iterators]/7:
2054</p>
2055
2056<blockquote>
2057If two iterators <tt>a</tt> and <tt>b</tt> of the same type are equal, then either <tt>a</tt>
2058and <tt>b</tt> are both
2059dereferenceable or else neither is dereferenceable.
2060</blockquote>
2061
2062<p><i>[
20632009-07 Frankfurt
2064]</i></p>
2065
2066
2067<blockquote>
2068Agree NAD.
2069</blockquote>
2070
2071</blockquote>
2072
2073
2074
2075<p><b>Proposed resolution:</b></p>
2076<p>Replace 24.6.3.5 [istreambuf.iterator::equal],
2077paragraph 1, </p>
2078
2079<blockquote>
2080  <p>-1- Returns: true if and only if both iterators are at end-of-stream, or neither is at
2081  end-of-stream, regardless of what streambuf object they use. </p>
2082</blockquote>
2083
2084<p>with</p>
2085
2086<blockquote>
2087  <p>-1- Returns: true if and only if both iterators are at
2088  end-of-stream, regardless of what streambuf object they use. </p>
2089</blockquote>
2090
2091
2092
2093<p><b>Rationale:</b></p>
2094<p>It is not clear that this is a genuine defect.  Additionally, the
2095LWG was reluctant to make a change that would result in 
2096operator== not being a equivalence relation.  One consequence of
2097this change is that an algorithm that's passed the range [i, i)
2098would no longer treat it as an empty range.</p>
2099
2100
2101
2102
2103
2104<hr>
2105<h3><a name="113"></a>113. Missing/extra iostream sync semantics</h3>
2106<p><b>Section:</b> 27.7.1.1 [istream], 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2107 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1998-10-13  <b>Last modified:</b> 2006-12-27</p>
2108<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream">issues</a> in [istream].</p>
2109<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2110<p><b>Discussion:</b></p>
2111<p>In 27.6.1.1, class basic_istream has a member function sync, described in 27.6.1.3,
2112paragraph 36. </p>
2113
2114<p>Following the chain of definitions, I find that the various sync functions have defined
2115semantics for output streams, but no semantics for input streams. On the other hand,
2116basic_ostream has no sync function. </p>
2117
2118<p>The sync function should at minimum be added to basic_ostream, for internal
2119consistency. </p>
2120
2121<p>A larger question is whether sync should have assigned semantics for input streams. </p>
2122
2123<p>Classic iostreams said streambuf::sync flushes pending output and attempts to return
2124unread input characters to the source. It is a protected member function. The filebuf
2125version (which is public) has that behavior (it backs up the read pointer). Class
2126strstreambuf does not override streambuf::sync, and so sync can't be called on a
2127strstream. </p>
2128
2129<p>If we can add corresponding semantics to the various sync functions, we should. If not,
2130we should remove sync from basic_istream.</p>
2131
2132
2133<p><b>Rationale:</b></p>
2134<p>A sync function is not needed in basic_ostream because the flush function provides the
2135desired functionality.</p>
2136
2137<p>As for the other points, the LWG finds the standard correct as written.</p>
2138
2139
2140
2141
2142
2143<hr>
2144<h3><a name="116"></a>116. bitset cannot be constructed with a const char*</h3>
2145<p><b>Section:</b> 20.3.7 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
2146 <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-11-06  <b>Last modified:</b> 2008-03-14</p>
2147<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>
2148<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>
2149<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2150<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a></p>
2151<p><b>Discussion:</b></p>
2152
2153
2154
2155<p>The following code does not compile with the EDG compiler:</p>
2156
2157<blockquote>
2158  <pre>#include &lt;bitset&gt;
2159using namespace std;
2160bitset&lt;32&gt; b("111111111");</pre>
2161</blockquote>
2162
2163<p>If you cast the ctor argument to a string, i.e.:</p>
2164
2165<blockquote>
2166  <pre>bitset&lt;32&gt; b(string("111111111"));</pre>
2167</blockquote>
2168
2169<p>then it will compile. The reason is that bitset has the following templatized
2170constructor:</p>
2171
2172<blockquote>
2173  <pre>template &lt;class charT, class traits, class Allocator&gt;
2174explicit bitset (const basic_string&lt;charT, traits, Allocator&gt;&amp; str, ...);</pre>
2175</blockquote>
2176
2177<p>According to the compiler vendor, Steve Adamcyk at EDG, the user
2178cannot pass this template constructor a <tt>const char*</tt> and
2179expect a conversion to <tt>basic_string</tt>.  The reason is
2180"When you have a template constructor, it can get used in
2181contexts where type deduction can be done. Type deduction basically
2182comes up with exact matches, not ones involving conversions."
2183</p>
2184
2185<p>I don't think the intention when this constructor became
2186templatized was for construction from a <tt>const char*</tt> to no
2187longer work.</p>
2188
2189
2190<p><b>Proposed resolution:</b></p>
2191<p>Add to 20.3.7 [template.bitset] a bitset constructor declaration</p>
2192
2193<blockquote>
2194  <pre>explicit bitset(const char*);</pre>
2195</blockquote>
2196
2197<p>and in Section 20.3.7.1 [bitset.cons] add:</p>
2198
2199<blockquote>
2200  <pre>explicit bitset(const char* str);</pre>
2201  <p>Effects: <br>
2202  &nbsp;&nbsp;&nbsp; Calls <tt>bitset((string) str, 0, string::npos);</tt></p>
2203</blockquote>
2204
2205
2206<p><b>Rationale:</b></p>
2207<p>Although the problem is real, the standard is designed that way so
2208it is not a defect.  Education is the immediate workaround. A future
2209standard may wish to consider the Proposed Resolution as an
2210extension.</p>
2211
2212
2213
2214
2215
2216<hr>
2217<h3><a name="121"></a>121. Detailed definition for ctype&lt;wchar_t&gt; specialization</h3>
2218<p><b>Section:</b> 22.3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2219 <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15  <b>Last modified:</b> 2006-12-27</p>
2220<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</p>
2221<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2222<p><b>Discussion:</b></p>
2223<p>Section 22.1.1.1.1 has the following listed in Table 51: ctype&lt;char&gt; ,
2224ctype&lt;wchar_t&gt;. </p>
2225
2226<p>Also Section 22.4.1.1 [locale.ctype] says: </p>
2227
2228<blockquote>
2229  <p>The instantiations required in Table 51 (22.1.1.1.1) namely ctype&lt;char&gt; and
2230  ctype&lt;wchar_t&gt; , implement character classing appropriate to the implementation's
2231  native character set. </p>
2232</blockquote>
2233
2234<p>However, Section 22.4.1.3 [facet.ctype.special]
2235only has a detailed description of the ctype&lt;char&gt; specialization, not the
2236ctype&lt;wchar_t&gt; specialization. </p>
2237
2238
2239<p><b>Proposed resolution:</b></p>
2240<p>Add the ctype&lt;wchar_t&gt; detailed class description to Section 
224122.4.1.3 [facet.ctype.special]. </p>
2242
2243
2244<p><b>Rationale:</b></p>
2245<p>Specialization for wchar_t is not needed since the default is acceptable.</p>
2246
2247
2248
2249
2250
2251<hr>
2252<h3><a name="128"></a>128. Need open_mode() function for file stream, string streams, file buffers, and string&nbsp; buffers</h3>
2253<p><b>Section:</b> 27.8 [string.streams], 27.9 [file.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2254 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1999-02-22  <b>Last modified:</b> 2009-07-14</p>
2255<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.streams">issues</a> in [string.streams].</p>
2256<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2257<p><b>Discussion:</b></p>
2258<p>The following question came from Thorsten Herlemann:</p>
2259
2260<blockquote>
2261  <p>You can set a mode when constructing or opening a file-stream or
2262  filebuf, e.g.  ios::in, ios::out, ios::binary, ... But how can I get
2263  that mode later on, e.g. in my own operator &lt;&lt; or operator
2264  &gt;&gt; or when I want to check whether a file-stream or
2265  file-buffer object passed as parameter is opened for input or output
2266  or binary? Is there no possibility? Is this a design-error in the
2267  standard C++ library? </p>
2268</blockquote>
2269
2270<p>It is indeed impossible to find out what a stream's or stream
2271buffer's open mode is, and without that knowledge you don't know
2272how certain operations behave. Just think of the append mode. </p>
2273
2274<p>Both streams and stream buffers should have a <tt>mode()</tt> function that returns the
2275current open mode setting. </p>
2276
2277<p><i>[
2278post Bellevue:  Alisdair requested to re-Open.
2279]</i></p>
2280
2281
2282<p><i>[
22832009-07 Frankfurt
2284]</i></p>
2285
2286
2287<blockquote>
2288<p>
2289Neither Howard nor Bill has received a customer request for this.
2290</p>
2291<p>
2292No consensus for change. The programmer can save this information to the side.
2293</p>
2294<p>
2295Moved to NAD.
2296</p>
2297</blockquote>
2298
2299
2300
2301<p><b>Proposed resolution:</b></p>
2302<p>For stream buffers, add a function to the base class as a non-virtual function
2303qualified as const to 27.6.2 [streambuf]:</p>
2304
2305<p>&nbsp;&nbsp;&nbsp;&nbsp;<tt>openmode mode() const</tt>;</p>
2306
2307<p><b>&nbsp;&nbsp;&nbsp; Returns</b> the current open mode.</p>
2308
2309<p>With streams, I'm not sure what to suggest. In principle, the mode
2310could already be returned by <tt>ios_base</tt>, but the mode is only
2311initialized for file and string stream objects, unless I'm overlooking
2312anything. For this reason it should be added to the most derived
2313stream classes. Alternatively, it could be added to <tt>basic_ios</tt>
2314and would be default initialized in <tt>basic_ios&lt;&gt;::init()</tt>.</p>
2315
2316
2317<p><b>Rationale:</b></p>
2318<p>This might be an interesting extension for some future, but it is
2319not a defect in the current standard. The Proposed Resolution is
2320retained for future reference.</p>
2321
2322
2323
2324
2325
2326<hr>
2327<h3><a name="131"></a>131. list::splice throws nothing</h3>
2328<p><b>Section:</b> 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2329 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-03-06  <b>Last modified:</b> 2007-02-19</p>
2330<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#list.ops">active issues</a> in [list.ops].</p>
2331<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p>
2332<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2333<p><b>Discussion:</b></p>
2334<p>What happens if a splice operation causes the size() of a list to grow 
2335beyond max_size()?</p>
2336
2337
2338<p><b>Rationale:</b></p>
2339<p>Size() cannot grow beyond max_size().&nbsp; </p>
2340
2341
2342
2343
2344
2345<hr>
2346<h3><a name="135"></a>135. basic_iostream doubly initialized</h3>
2347<p><b>Section:</b> 27.7.1.5.1 [iostream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2348 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 1999-03-06  <b>Last modified:</b> 2006-12-27</p>
2349<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2350<p><b>Discussion:</b></p>
2351<p>-1- Effects Constructs an object of class basic_iostream, assigning
2352initial values to the base classes by calling
2353basic_istream&lt;charT,traits&gt;(sb) (lib.istream) and
2354basic_ostream&lt;charT,traits&gt;(sb) (lib.ostream)</p>
2355
2356<p>The called for basic_istream and basic_ostream constructors call
2357init(sb). This means that the basic_iostream's virtual base class is
2358initialized twice.</p>
2359
2360
2361<p><b>Proposed resolution:</b></p>
2362<p>Change 27.6.1.5.1, paragraph 1 to:</p>
2363
2364<p>-1- Effects Constructs an object of class basic_iostream, assigning
2365initial values to the base classes by calling
2366basic_istream&lt;charT,traits&gt;(sb) (lib.istream).</p>
2367
2368
2369<p><b>Rationale:</b></p>
2370<p>The LWG agreed that the <tt> init()</tt> function is called
2371twice, but said that this is harmless and so not a defect in the
2372standard.</p>
2373
2374
2375
2376
2377<hr>
2378<h3><a name="138"></a>138. Class ctype_byname&lt;char&gt; redundant and misleading</h3>
2379<p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2380 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1999-03-18  <b>Last modified:</b> 2009-07-14</p>
2381<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
2382<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2383<p><b>Discussion:</b></p>
2384<p>Section 22.4.1.4 [locale.codecvt] specifies that
2385ctype_byname&lt;char&gt; must be a specialization of the ctype_byname
2386template.</p>
2387
2388<p>It is common practice in the standard that specializations of class templates are only
2389mentioned where the interface of the specialization deviates from the interface of the
2390template that it is a specialization of. Otherwise, the fact whether or not a required
2391instantiation is an actual instantiation or a specialization is left open as an
2392implementation detail. </p>
2393
2394<p>Clause 22.2.1.4 deviates from that practice and for that reason is misleading. The
2395fact, that ctype_byname&lt;char&gt; is specified as a specialization suggests that there
2396must be something "special" about it, but it has the exact same interface as the
2397ctype_byname template. Clause 22.2.1.4 does not have any explanatory value, is at best
2398redundant, at worst misleading - unless I am missing anything. </p>
2399
2400<p>Naturally, an implementation will most likely implement ctype_byname&lt;char&gt; as a
2401specialization, because the base class ctype&lt;char&gt; is a specialization with an
2402interface different from the ctype template, but that's an implementation detail and need
2403not be mentioned in the standard. </p>
2404
2405<p><i>[
2406Summit:
2407]</i></p>
2408
2409
2410<blockquote>
2411Reopened by Alisdair.
2412</blockquote>
2413
2414<p><i>[
24152009-07 Frankfurt
2416]</i></p>
2417
2418
2419<blockquote>
2420Moved to NAD.
2421</blockquote>
2422
2423
2424
2425<p><b>Rationale:</b></p>
2426<p> The standard as written is mildly misleading, but the correct fix
2427is to deal with the underlying problem in the ctype_byname base class,
2428not in the specialization. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>.</p>
2429
2430
2431
2432
2433<hr>
2434<h3><a name="140"></a>140. map&lt;Key, T&gt;::value_type does not satisfy the assignable requirement</h3>
2435<p><b>Section:</b> 23.4.1 [map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
2436 <b>Submitter:</b> Mark Mitchell <b>Opened:</b> 1999-04-14  <b>Last modified:</b> 2008-03-14</p>
2437<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map">issues</a> in [map].</p>
2438<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
2439<p><b>Discussion:</b></p>
2440<blockquote>
2441  <p>23.2 [container.requirements]<br>
2442  <br>
2443  expression&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return type
2444  &nbsp;&nbsp;&nbsp;&nbsp; pre/post-condition<br>
2445  -------------&nbsp;&nbsp;&nbsp;&nbsp; ----------- &nbsp;&nbsp;&nbsp;&nbsp;
2446  -------------------<br>
2447  X::value_type&nbsp;&nbsp;&nbsp; T
2448  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2449  T is assignable<br>
2450  <br>
2451  23.4.1 [map]<br>
2452  <br>
2453  A map satisfies all the requirements of a container.<br>
2454  <br>
2455  For a map&lt;Key, T&gt; ... the value_type is pair&lt;const Key, T&gt;.</p>
2456</blockquote>
2457
2458<p>There's a contradiction here. In particular, `pair&lt;const Key,
2459T&gt;' is not assignable; the `const Key' cannot be assigned
2460to. So,&nbsp; map&lt;Key, T&gt;::value_type does not satisfy the
2461assignable requirement imposed by a container.</p>
2462
2463<p><i>[See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> for the slightly related issue of
2464modification of set keys.]</i></p>
2465
2466
2467
2468<p><b>Rationale:</b></p>
2469<p>The LWG believes that the standard is inconsistent, but that this
2470is a design problem rather than a strict defect. May wish to
2471reconsider for the next standard.</p>
2472
2473
2474
2475
2476<hr>
2477<h3><a name="143"></a>143. C .h header wording unclear</h3>
2478<p><b>Section:</b> D.6 [depr.c.headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2479 <b>Submitter:</b> Christophe de Dinechin <b>Opened:</b> 1999-05-04  <b>Last modified:</b> 2006-12-27</p>
2480<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2481<p><b>Discussion:</b></p>
2482<p>[depr.c.headers] paragraph 2 reads:</p>
2483
2484<blockquote>
2485
2486<p>Each C header, whose name has the form name.h, behaves as if each
2487name placed in the Standard library namespace by the corresponding
2488cname header is also placed within the namespace scope of the
2489namespace std and is followed by an explicit using-declaration
2490(_namespace.udecl_)</p>
2491
2492</blockquote>
2493
2494<p>I think it should mention the global name space somewhere...&nbsp;
2495Currently, it indicates that name placed in std is also placed in
2496std...</p>
2497
2498<p>I don't know what is the correct wording. For instance, if struct
2499tm is defined in time.h, ctime declares std::tm. However, the current
2500wording seems ambiguous regarding which of the following would occur
2501for use of both ctime and time.h:</p>
2502
2503<blockquote>
2504  <pre>// version 1:
2505namespace std {
2506        struct tm { ... };
2507}
2508using std::tm;
2509
2510// version 2:
2511struct tm { ... };
2512namespace std {
2513        using ::tm;
2514}
2515
2516// version 3:
2517struct tm { ... };
2518namespace std {
2519        struct tm { ... };
2520}</pre>
2521</blockquote>
2522
2523<p>I think version 1 is intended.</p>
2524
2525<p><i>[Kona: The LWG agreed that the wording is not clear. It also
2526agreed that version 1 is intended, version 2 is not equivalent to
2527version 1, and version 3 is clearly not intended. The example below
2528was constructed by Nathan Myers to illustrate why version 2 is not
2529equivalent to version 1.</i></p>
2530
2531<p><i>Although not equivalent, the LWG is unsure if (2) is enough of
2532a problem to be prohibited. Points discussed in favor of allowing
2533(2):</i></p>
2534
2535<blockquote>
2536  <ul>
2537    <li><i>It may be a convenience to implementors.</i></li>
2538    <li><i>The only cases that fail are structs, of which the C library
2539      contains only a few.</i></li>
2540  </ul>
2541</blockquote>
2542
2543<p><i>]</i></p>
2544
2545<p><b>Example:</b></p>
2546
2547<blockquote>
2548
2549<pre>#include &lt;time.h&gt;
2550#include &lt;utility&gt;
2551
2552int main() {
2553    std::tm * t;
2554    make_pair( t, t ); // okay with version 1 due to Koenig lookup
2555                       // fails with version 2; make_pair not found
2556    return 0;
2557}</pre>
2558
2559</blockquote>
2560
2561
2562<p><b>Proposed resolution:</b></p>
2563
2564<p>Replace D.6 [depr.c.headers] paragraph 2 with:</p>
2565
2566<blockquote>
2567
2568<p> Each C header, whose name has the form name.h, behaves as if each
2569name placed in the Standard library namespace by the corresponding
2570cname header is also placed within the namespace scope of the
2571namespace std by name.h and is followed by an explicit
2572using-declaration (_namespace.udecl_) in global scope.</p>
2573
2574</blockquote>
2575
2576
2577
2578<p><b>Rationale:</b></p>
2579<p> The current wording in the standard is the result of a difficult
2580compromise that averted delay of the standard. Based on discussions
2581in Tokyo it is clear that there is no still no consensus on stricter
2582wording, so the issue has been closed. It is suggested that users not
2583write code that depends on Koenig lookup of C library functions.</p>
2584
2585
2586
2587
2588<hr>
2589<h3><a name="145"></a>145. adjustfield lacks default value</h3>
2590<p><b>Section:</b> 27.5.4.1 [basic.ios.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2591 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 1999-05-12  <b>Last modified:</b> 2006-12-27</p>
2592<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.cons">issues</a> in [basic.ios.cons].</p>
2593<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2594<p><b>Discussion:</b></p>
2595<p>There is no initial value for the adjustfield defined, although
2596many people believe that the default adjustment were right. This is a
2597common misunderstanding. The standard only defines that, if no
2598adjustment is specified, all the predefined inserters must add fill
2599characters before the actual value, which is "as if" the
2600right flag were set. The flag itself need not be set.</p>
2601
2602<p>When you implement a user-defined inserter you cannot rely on right
2603being the default setting for the adjustfield. Instead, you must be
2604prepared to find none of the flags set and must keep in mind that in
2605this case you should make your inserter behave "as if" the
2606right flag were set. This is surprising to many people and complicates
2607matters more than necessary.</p>
2608
2609<p>Unless there is a good reason why the adjustfield should not be
2610initialized I would suggest to give it the default value that
2611everybody expects anyway.</p>
2612
2613
2614
2615<p><b>Rationale:</b></p>
2616<p>This is not a defect. It is deliberate that the default is no bits
2617set. Consider Arabic or Hebrew, for example. See 22.4.2.2.2 [facet.num.put.virtuals] paragraph 19, Table 61 - Fill padding.</p>
2618
2619
2620
2621
2622<hr>
2623<h3><a name="157"></a>157. Meaningless error handling for <tt>pword()</tt> and <tt>iword()</tt></h3>
2624<p><b>Section:</b> 27.5.2.5 [ios.base.storage] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
2625 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20  <b>Last modified:</b> 2007-01-15</p>
2626<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base.storage">issues</a> in [ios.base.storage].</p>
2627<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2628<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#41">41</a></p>
2629<p><b>Discussion:</b></p>
2630<p>According to paragraphs 2 and 4 of 27.5.2.5 [ios.base.storage], the
2631functions <tt>iword()</tt> and <tt>pword()</tt> "set the
2632<tt>badbit</tt> (which might throw an exception)" on
2633failure. ... but what does it mean for <tt>ios_base</tt> to set the
2634<tt>badbit</tt>? The state facilities of the IOStream library are
2635defined in <tt>basic_ios</tt>, a derived class! It would be possible
2636to attempt a down cast but then it would be necessary to know the
2637character type used...</p>
2638
2639
2640<p><b>Rationale:</b></p>
2641
2642
2643
2644
2645
2646<hr>
2647<h3><a name="162"></a>162. Really "formatted input functions"?</h3>
2648<p><b>Section:</b> 27.7.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
2649 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20  <b>Last modified:</b> 2007-01-15</p>
2650<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p>
2651<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2652<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a></p>
2653<p><b>Discussion:</b></p>
2654<p>It appears to be somewhat nonsensical to consider the functions
2655defined in the paragraphs 1 to 5 to be "Formatted input
2656function" but since these functions are defined in a section
2657labeled "Formatted input functions" it is unclear to me
2658whether these operators are considered formatted input functions which
2659have to conform to the "common requirements" from 27.7.1.2.1
2660[istream.formatted.reqmts]: If this is the case, all manipulators, not
2661just
2662<tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is set
2663(... but setting <tt>noskipws</tt> using the manipulator syntax would
2664also skip whitespace :-)</p>
2665
2666<p>See also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#166">166</a> for the same problem in formatted
2667output</p>
2668
2669
2670<p><b>Rationale:</b></p>
2671
2672
2673
2674
2675
2676<hr>
2677<h3><a name="163"></a>163. Return of <tt>gcount()</tt> after a call to <tt>gcount</tt></h3>
2678<p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
2679 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20  <b>Last modified:</b> 2007-01-15</p>
2680<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
2681<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2682<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a></p>
2683<p><b>Discussion:</b></p>
2684<p>It is not clear which functions are to be considered unformatted
2685input functions. As written, it seems that all functions in 27.7.1.3
2686[istream.unformatted] are unformatted input functions. However, it does
2687not
2688really make much sense to construct a sentry object for
2689<tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is unclear what
2690happens to the <tt>gcount()</tt> if eg. <tt>gcount()</tt>,
2691<tt>putback()</tt>, <tt>unget()</tt>, or <tt>sync()</tt> is called:
2692These functions don't extract characters, some of them even
2693"unextract" a character. Should this still be reflected in
2694<tt>gcount()</tt>? Of course, it could be read as if after a call to
2695<tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt> (the last
2696unformatted input function, <tt>gcount()</tt>, didn't extract any
2697character) and after a call to <tt>putback()</tt> <tt>gcount()</tt>
2698returns <tt>-1</tt> (the last unformatted input function
2699<tt>putback()</tt> did "extract" back into the
2700stream). Correspondingly for <tt>unget()</tt>. Is this what is
2701intended?  If so, this should be clarified. Otherwise, a corresponding
2702clarification should be used.</p>
2703
2704
2705<p><b>Rationale:</b></p>
2706
2707
2708
2709
2710
2711<hr>
2712<h3><a name="166"></a>166. Really "formatted output functions"?</h3>
2713<p><b>Section:</b> 27.7.2.6.3 [ostream.inserters] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
2714 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 1999-07-20  <b>Last modified:</b> 2007-01-15</p>
2715<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
2716<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a></p>
2717<p><b>Discussion:</b></p>
2718<p>From 27.7.2.6.1 [ostream.formatted.reqmts] it appears that all the functions
2719defined in 27.7.2.6.3 [ostream.inserters] have to construct a
2720<tt>sentry</tt> object. Is this really intended?</p> 
2721
2722<p>This is basically the same problem as issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#162">162</a> but
2723for output instead of input.</p>
2724
2725
2726<p><b>Rationale:</b></p>
2727
2728
2729
2730
2731
2732<hr>
2733<h3><a name="177"></a>177. Complex operators cannot be explicitly instantiated</h3>
2734<p><b>Section:</b> 26.4.6 [complex.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2735 <b>Submitter:</b> Judy Ward <b>Opened:</b> 1999-07-02  <b>Last modified:</b> 2006-12-27</p>
2736<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.ops">issues</a> in [complex.ops].</p>
2737<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2738<p><b>Discussion:</b></p>
2739<p>A user who tries to explicitly instantiate a complex non-member operator will
2740get compilation errors. Below is a simplified example of the reason why. The
2741problem is that iterator_traits cannot be instantiated on a non-pointer type
2742like float, yet when the compiler is trying to decide which operator+ needs to
2743be instantiated it must instantiate the declaration to figure out the first
2744argument type of a reverse_iterator operator.</p>
2745<pre>namespace std {
2746template &lt;class Iterator&gt; 
2747struct iterator_traits
2748{
2749    typedef typename Iterator::value_type value_type;
2750};
2751
2752template &lt;class T&gt; class reverse_iterator;
2753
2754// reverse_iterator operator+
2755template &lt;class T&gt; 
2756reverse_iterator&lt;T&gt; operator+
2757(typename iterator_traits&lt;T&gt;::difference_type, const reverse_iterator&lt;T&gt;&amp;);
2758
2759template &lt;class T&gt; struct complex {};
2760
2761// complex operator +
2762template &lt;class T&gt;
2763complex&lt;T&gt; operator+ (const T&amp; lhs, const complex&lt;T&gt;&amp; rhs) 
2764{ return complex&lt;T&gt;();} 
2765}
2766
2767// request for explicit instantiation
2768template std::complex&lt;float&gt; std::operator+&lt;float&gt;(const float&amp;, 
2769     const std::complex&lt;float&gt;&amp;);</pre>
2770<p>See also c++-stdlib reflector messages: lib-6814, 6815, 6816.</p>
2771
2772
2773<p><b>Rationale:</b></p>
2774<p>Implementors can make minor changes and the example will
2775work. Users are not affected in any case.</p> <p>According to John
2776Spicer, It is possible to explicitly instantiate these operators using
2777different syntax: change "std::operator+&lt;float&gt;" to
2778"std::operator+".</p>
2779
2780<p>The proposed resolution of issue 120 is that users will not be able
2781to explicitly instantiate standard library templates. If that
2782resolution is accepted then library implementors will be the only ones
2783that will be affected by this problem, and they must use the indicated
2784syntax.</p>
2785
2786
2787
2788
2789<hr>
2790<h3><a name="178"></a>178. Should clog and cerr initially be tied to cout?</h3>
2791<p><b>Section:</b> 27.4.1 [narrow.stream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2792 <b>Submitter:</b> Judy Ward <b>Opened:</b> 1999-07-02  <b>Last modified:</b> 2006-12-27</p>
2793<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#narrow.stream.objects">issues</a> in [narrow.stream.objects].</p>
2794<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2795<p><b>Discussion:</b></p>
2796<p>
2797Section 27.3.1 says "After the object cerr is initialized,
2798cerr.flags() &amp; unitbuf is nonzero. Its state is otherwise the same as
2799required for ios_base::init (lib.basic.ios.cons).  It doesn't say
2800anything about the the state of clog.  So this means that calling
2801cerr.tie() and clog.tie() should return 0 (see Table 89 for
2802ios_base::init effects).
2803</p>
2804<p>
2805Neither of the popular standard library implementations
2806that I tried does this, they both tie cerr and clog
2807to &amp;cout. I would think that would be what users expect.
2808</p>
2809
2810
2811<p><b>Rationale:</b></p>
2812<p>The standard is clear as written.</p>
2813<p>27.3.1/5 says that "After the object cerr is initialized, cerr.flags()
2814&amp; unitbuf is nonzero. Its state is otherwise the same as required for
2815ios_base::init (27.4.4.1)." Table 89 in 27.4.4.1, which gives the
2816postconditions of basic_ios::init(), says that tie() is 0. (Other issues correct
2817ios_base::init to basic_ios::init().)</p>
2818
2819
2820
2821
2822<hr>
2823<h3><a name="188"></a>188. valarray helpers missing augmented assignment operators</h3>
2824<p><b>Section:</b> 26.6.2.6 [valarray.cassign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2825 <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 1999-08-15  <b>Last modified:</b> 2008-03-11</p>
2826<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cassign">issues</a> in [valarray.cassign].</p>
2827<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2828<p><b>Discussion:</b></p>
2829<p>26.5.2.6 defines augmented assignment operators
2830valarray&lt;T&gt;::op=(const T&amp;), but fails to provide
2831corresponding versions for the helper classes. Thus making the
2832following illegal:</p>
2833<blockquote>
2834<pre>#include &lt;valarray&gt;
2835
2836int main()
2837{
2838std::valarray&lt;double&gt; v(3.14, 1999);
2839
2840v[99] *= 2.0; // Ok
2841
2842std::slice s(0, 50, 2);
2843
2844v[s] *= 2.0; // ERROR
2845}</pre>
2846</blockquote>
2847<p>I can't understand the intent of that omission.  It makes the
2848valarray library less intuitive and less useful.</p>
2849
2850
2851<p><b>Rationale:</b></p>
2852<p>Although perhaps an unfortunate
2853design decision, the omission is not a defect in the current
2854standard.&nbsp; A future standard may wish to add the missing
2855operators.</p>
2856
2857
2858
2859
2860<hr>
2861<h3><a name="190"></a>190. min() and max() functions should be std::binary_functions</h3>
2862<p><b>Section:</b> 25.4.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2863 <b>Submitter:</b> Mark Rintoul <b>Opened:</b> 1999-08-26  <b>Last modified:</b> 2009-07-14</p>
2864<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>
2865<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2866<p><b>Discussion:</b></p>
2867<p>Both std::min and std::max are defined as template functions.  This
2868is very different than the definition of std::plus (and similar
2869structs) which are defined as function objects which inherit
2870std::binary_function.<br>
2871<br>
2872        This lack of inheritance leaves std::min and std::max somewhat useless in standard library algorithms which require
2873a function object that inherits std::binary_function.</p>
2874
2875<p><i>[
2876post Bellevue:  Alisdair requested to re-Open.
2877]</i></p>
2878
2879
2880<p><i>[
28812009-07 Frankfurt
2882]</i></p>
2883
2884
2885<blockquote>
2886<p>
2887C++0x has lambdas to address this problem now.
2888</p>
2889<p>
2890Moved to NAD.
2891</p>
2892</blockquote>
2893
2894
2895
2896<p><b>Rationale:</b></p>
2897<p>Although perhaps an unfortunate design decision, the omission is not a defect
2898in the current standard.&nbsp; A future standard may wish to consider additional
2899function objects.</p>
2900
2901
2902
2903
2904<hr>
2905<h3><a name="191"></a>191. Unclear complexity for algorithms such as binary search</h3>
2906<p><b>Section:</b> 25.4.3 [alg.binary.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
2907 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 1999-10-10  <b>Last modified:</b> 2006-12-27</p>
2908<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.binary.search">issues</a> in [alg.binary.search].</p>
2909<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2910<p><b>Discussion:</b></p>
2911<p>The complexity of binary_search() is stated as "At most
2912log(last-first) + 2 comparisons", which seems to say that the
2913algorithm has logarithmic complexity. However, this algorithms is
2914defined for forward iterators. And for forward iterators, the need to
2915step element-by-element results into linear complexity. But such a
2916statement is missing in the standard. The same applies to
2917lower_bound(), upper_bound(), and equal_range().&nbsp;<br>
2918<br>
2919However, strictly speaking the standard contains no bug here. So this
2920might considered to be a clarification or improvement.
2921</p>
2922
2923
2924<p><b>Rationale:</b></p>
2925<p>The complexity is expressed in terms of comparisons, and that
2926complexity can be met even if the number of iterators accessed is
2927linear. Paragraph 1 already says exactly what happens to
2928iterators.</p>
2929
2930
2931
2932
2933<hr>
2934<h3><a name="192"></a>192. a.insert(p,t) is inefficient and overconstrained</h3>
2935<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#NAD">NAD</a>
2936 <b>Submitter:</b> Ed Brey <b>Opened:</b> 1999-06-06  <b>Last modified:</b> 2006-12-30</p>
2937<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
2938<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>
2939<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
2940<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a></p>
2941<p><b>Discussion:</b></p>
2942<p>As defined in 23.1.2, paragraph 7 (table 69), a.insert(p,t) suffers from
2943several problems:</p>
2944<table border="1" cellpadding="5">
2945  <tbody><tr>
2946    <td><b>expression</b></td>
2947    <td><b>return type</b></td>
2948    <td><b>pre/post-condition</b></td>
2949    <td><b>complexity</b></td>
2950  </tr>
2951  <tr>
2952    <td><tt>a.insert(p,t)</tt></td>
2953    <td><tt>iterator</tt></td>
2954    <td>inserts t if and only if there is no element with key equivalent to the key of 
2955       t in containers with unique keys; always inserts t in containers with equivalent 
2956       keys. always returns the iterator pointing to the element with key equivalent to 
2957       the key of t . iterator p is a hint pointing to where the insert should start to search.</td>
2958    <td>logarithmic in general, but amortized constant if t is inserted right after p .</td>
2959  </tr>
2960</tbody></table>
2961<p>1. For a container with unique keys, only logarithmic complexity is
2962guaranteed if no element is inserted, even though constant complexity is always
2963possible if p points to an element equivalent to t.</p>
2964<p>2. For a container with equivalent keys, the amortized constant complexity
2965guarantee is only useful if no key equivalent to t exists in the container.
2966Otherwise, the insertion could occur in one of multiple locations, at least one
2967of which would not be right after p.</p>
2968<p>3. By guaranteeing amortized constant complexity only when t is inserted
2969after p, it is impossible to guarantee constant complexity if t is inserted at
2970the beginning of the container. Such a problem would not exist if amortized
2971constant complexity was guaranteed if t is inserted before p, since there is
2972always some p immediately before which an insert can take place.</p>
2973<p>4. For a container with equivalent keys, p does not allow specification of
2974where to insert the element, but rather only acts as a hint for improving
2975performance. This negates the added functionality that p would provide if it
2976specified where within a sequence of equivalent keys the insertion should occur.
2977Specifying the insert location provides more control to the user, while
2978providing no disadvantage to the container implementation.</p>
2979
2980
2981<p><b>Proposed resolution:</b></p>
2982<p>In 23.2.4 [associative.reqmts] paragraph 7, replace the row in table 69
2983for a.insert(p,t) with the following two rows:</p>
2984<table border="1" cellpadding="5">
2985  <tbody><tr>
2986    <td><b>expression</b></td>
2987    <td><b>return type</b></td>
2988    <td><b>pre/post-condition</b></td>
2989    <td><b>complexity</b></td>
2990  </tr>
2991  <tr>
2992    <td><tt>a_uniq.insert(p,t)</tt></td>
2993    <td><tt>iterator</tt></td>
2994    <td>inserts t if and only if there is no element with key equivalent to the
2995      key of t. returns the iterator pointing to the element with key equivalent
2996      to the key of t.</td>
2997    <td>logarithmic in general, but amortized constant if t is inserted right
2998      before p or p points to an element with key equivalent to t.</td>
2999  </tr>
3000  <tr>
3001    <td><tt>a_eq.insert(p,t)</tt></td>
3002    <td><tt>iterator</tt></td>
3003    <td>inserts t and returns the iterator pointing to the newly inserted
3004      element. t is inserted right before p if doing so preserves the container
3005      ordering.</td>
3006    <td>logarithmic in general, but amortized constant if t is inserted right
3007      before p.</td>
3008  </tr>
3009</tbody></table>
3010
3011
3012
3013<p><b>Rationale:</b></p>
3014<p>Too big a change.&nbsp; Furthermore, implementors report checking
3015both before p and after p, and don't want to change this behavior.</p>
3016
3017
3018
3019
3020
3021<hr>
3022<h3><a name="194"></a>194. rdbuf() functions poorly specified</h3>
3023<p><b>Section:</b> 27.5.4 [ios] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3024 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 1999-09-07  <b>Last modified:</b> 2006-12-27</p>
3025<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3026<p><b>Discussion:</b></p>
3027<p>In classic iostreams, base class ios had an rdbuf function that returned a
3028pointer to the associated streambuf. Each derived class had its own rdbuf
3029function that returned a pointer of a type reflecting the actual type derived
3030from streambuf. Because in ARM C++, virtual function overrides had to have the
3031same return type, rdbuf could not be virtual.</p>
3032<p>In standard iostreams, we retain the non-virtual rdbuf function design, and
3033in addition have an overloaded rdbuf function that sets the buffer pointer.
3034There is no need for the second function to be virtual nor to be implemented in
3035derived classes.</p>
3036<p>Minor question: Was there a specific reason not to make the original rdbuf
3037function virtual?</p>
3038<p>Major problem: Friendly compilers warn about functions in derived classes
3039that hide base-class overloads. Any standard implementation of iostreams will
3040result in such a warning on each of the iostream classes, because of the
3041ill-considered decision to overload rdbuf only in a base class.</p>
3042<p>In addition, users of the second rdbuf function must use explicit
3043qualification or a cast to call it from derived classes. An explicit
3044qualification or cast to basic_ios would prevent access to any later overriding
3045version if there was one.</p>
3046<p>What I'd like to do in an implementation is add a using- declaration for the
3047second rdbuf function in each derived class. It would eliminate warnings about
3048hiding functions, and would enable access without using explicit qualification.
3049Such a change I don't think would change the behavior of any valid program, but
3050would allow invalid programs to compile:</p>
3051<blockquote>
3052  <pre> filebuf mybuf;
3053 fstream f;
3054 f.rdbuf(mybuf); // should be an error, no visible rdbuf</pre>
3055</blockquote>
3056<p>I'd like to suggest this problem as a defect, with the proposed resolution to
3057require the equivalent of a using-declaration for the rdbuf function that is not
3058replaced in a later derived class. We could discuss whether replacing the
3059function should be allowed.</p>
3060
3061
3062<p><b>Rationale:</b></p>
3063<p>For historical reasons, the standard is correct as written. There is a subtle difference between the base
3064class <tt> rdbuf()</tt> and derived class <tt>rdbuf()</tt>. The derived
3065class <tt> rdbuf()</tt> always returns the original streambuf, whereas the base class
3066<tt> rdbuf()</tt> will return the "current streambuf" if that has been changed by the variant you mention.</p>
3067
3068<p>Permission is not required to add such an extension.  See 
306917.6.4.5 [member.functions].</p>
3070
3071
3072
3073
3074<hr>
3075<h3><a name="196"></a>196. Placement new example has alignment problems</h3>
3076<p><b>Section:</b> 18.6.1.3 [new.delete.placement] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
3077 <b>Submitter:</b> Herb Sutter <b>Opened:</b> 1998-12-15  <b>Last modified:</b> 2006-12-30</p>
3078<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete.placement">issues</a> in [new.delete.placement].</p>
3079<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
3080<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a></p>
3081<p><b>Discussion:</b></p>
3082<p>The example in 18.6.1.3 [new.delete.placement] paragraph 4 reads: </p>
3083
3084<blockquote>
3085
3086<p>[Example: This can be useful for constructing an object at a known address:<br>
3087<br>
3088<tt>&nbsp;&nbsp; char place[sizeof(Something)];<br>
3089&nbsp;&nbsp; Something* p = new (place) Something();<br>
3090<br>
3091</tt>end example] </p>
3092
3093</blockquote>
3094
3095<p>This example has potential alignment problems. </p>
3096
3097
3098<p><b>Rationale:</b></p>
3099
3100
3101
3102
3103
3104<hr>
3105<h3><a name="197"></a>197. max_size() underspecified</h3>
3106<p><b>Section:</b> 20.2.2 [allocator.requirements], 23.2 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3107 <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 1999-10-21  <b>Last modified:</b> 2006-12-30</p>
3108<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>
3109<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3110<p><b>Discussion:</b></p>
3111<p>Must the value returned by max_size() be unchanged from call to call? </p>
3112
3113<p>Must the value returned from max_size() be meaningful? </p>
3114
3115<p>Possible meanings identified in lib-6827: </p>
3116
3117<p>1) The largest container the implementation can support given "best
3118case" conditions - i.e. assume the run-time platform is "configured to
3119the max", and no overhead from the program itself. This may possibly
3120be determined at the point the library is written, but certainly no
3121later than compile time.<br>
3122<br>
31232) The largest container the program could create, given "best case"
3124conditions - i.e. same platform assumptions as (1), but take into
3125account any overhead for executing the program itself. (or, roughly
3126"storage=storage-sizeof(program)"). This does NOT include any resource
3127allocated by the program. This may (or may not) be determinable at
3128compile time.<br>
3129<br>
31303) The largest container the current execution of the program could
3131create, given knowledge of the actual run-time platform, but again,
3132not taking into account any currently allocated resource. This is
3133probably best determined at program start-up.<br>
3134<br>
31354) The largest container the current execution program could create at
3136the point max_size() is called (or more correctly at the point
3137max_size() returns :-), given it's current environment (i.e. taking
3138into account the actual currently available resources). This,
3139obviously, has to be determined dynamically each time max_size() is
3140called. </p>
3141
3142
3143<p><b>Proposed resolution:</b></p>
3144
3145
3146<p><b>Rationale:</b></p>
3147<p>max_size() isn't useful for very many things, and the existing
3148  wording is sufficiently clear for the few cases that max_size() can
3149  be used for.  None of the attempts to change the existing wording
3150  were an improvement.</p>
3151
3152<p>It is clear to the LWG that the value returned by max_size() can't
3153  change from call to call.</p>
3154
3155
3156
3157
3158
3159
3160<hr>
3161<h3><a name="203"></a>203. basic_istream::sentry::sentry() is uninstantiable with ctype&lt;user-defined type&gt;</h3>
3162<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#NAD">NAD</a>
3163 <b>Submitter:</b> Matt McClure and Dietmar K�hl <b>Opened:</b> 2000-01-01  <b>Last modified:</b> 2007-01-15</p>
3164<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>
3165<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3166<p><b>Discussion:</b></p>
3167<p>27.6.1.1.2 Paragraph 4 states:</p>
3168<blockquote>
3169  <p>To decide if the character c is a whitespace character, the constructor      
3170     performs ''as if'' it executes the following code fragment:&nbsp;</p>
3171  <pre>const ctype&lt;charT&gt;&amp; ctype = use_facet&lt;ctype&lt;charT&gt; &gt;(is.getloc());
3172if (ctype.is(ctype.space,c)!=0)
3173// c is a whitespace character.</pre>
3174</blockquote>
3175
3176<p> But Table 51 in 22.1.1.1.1 only requires an implementation to
3177provide specializations for ctype&lt;char&gt; and
3178ctype&lt;wchar_t&gt;.  If sentry's constructor is implemented using
3179ctype, it will be uninstantiable for a user-defined character type
3180charT, unless the implementation has provided non-working (since it
3181would be impossible to define a correct ctype&lt;charT&gt; specialization
3182for an arbitrary charT) definitions of ctype's virtual member
3183functions.</p>
3184
3185<p>
3186It seems the intent the standard is that sentry should behave, in
3187every respect, not just during execution, as if it were implemented
3188using ctype, with the burden of providing a ctype specialization
3189falling on the user.  But as it is written, nothing requires the
3190translation of sentry's constructor to behave as if it used the above
3191code, and it would seem therefore, that sentry's constructor should be
3192instantiable for all character types.
3193</p>
3194
3195<p> 
3196Note: If I have misinterpreted the intent of the standard with
3197respect to sentry's constructor's instantiability, then a note should
3198be added to the following effect:
3199</p>
3200
3201<blockquote><p>
3202An implementation is forbidden from using the above code if it renders
3203the constructor uninstantiable for an otherwise valid character
3204type.
3205</p></blockquote>
3206
3207<p>In any event, some clarification is needed.</p>
3208
3209
3210
3211<p><b>Rationale:</b></p>
3212<p>It is possible but not easy to instantiate on types other than char
3213or wchar_t; many things have to be done first. That is by intention
3214and is not a defect.</p>
3215
3216
3217
3218
3219<hr>
3220<h3><a name="204"></a>204. distance(first, last) when "last" is before "first"</h3>
3221<p><b>Section:</b> 24.4.4 [iterator.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3222 <b>Submitter:</b> Rintala Matti <b>Opened:</b> 2000-01-28  <b>Last modified:</b> 2008-09-30</p>
3223<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>
3224<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>
3225<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3226<p><b>Discussion:</b></p>
3227<p>Section 24.3.4 describes the function distance(first, last) (where first and
3228last are iterators) which calculates "the number of increments or
3229decrements needed to get from 'first' to 'last'".</p>
3230<p>The function should work for forward, bidirectional and random access
3231iterators, and there is a requirement 24.3.4.5 which states that "'last'
3232must be reachable from 'first'".</p>
3233<p>With random access iterators the function is easy to implement as "last
3234- first".</p>
3235<p>With forward iterators it's clear that 'first' must point to a place before
3236'last', because otherwise 'last' would not be reachable from 'first'.</p>
3237<p>But what about bidirectional iterators? There 'last' is reachable from
3238'first' with the -- operator even if 'last' points to an earlier position than
3239'first'. However, I cannot see how the distance() function could be implemented
3240if the implementation does not know which of the iterators points to an earlier
3241position (you cannot use ++ or -- on either iterator if you don't know which
3242direction is the "safe way to travel").</p>
3243<p>The paragraph 24.3.4.1 states that "for ... bidirectional iterators they
3244use ++ to provide linear time implementations". However, the ++ operator is
3245not mentioned in the reachability requirement. Furthermore 24.3.4.4 explicitly
3246mentions that distance() returns the number of increments _or decrements_,
3247suggesting that it could return a negative number also for bidirectional
3248iterators when 'last' points to a position before 'first'.</p>
3249<p>Is a further requirement is needed to state that for forward and
3250bidirectional iterators "'last' must be reachable from 'first' using the ++
3251operator". Maybe this requirement might also apply to random access
3252iterators so that distance() would work the same way for every iterator
3253category?</p>
3254
3255
3256<p><b>Rationale:</b></p>
3257<p>"Reachable" is defined in the standard in X [iterator.concepts] paragraph 6.
3258The definition is only in terms of operator++(). The LWG sees no defect in
3259the standard.</p>
3260
3261
3262
3263
3264<hr>
3265<h3><a name="205"></a>205.  numeric_limits unclear on how to determine floating point types</h3>
3266<p><b>Section:</b> 18.3.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3267 <b>Submitter:</b> Steve Cleary <b>Opened:</b> 2000-01-28  <b>Last modified:</b> 2006-12-27</p>
3268<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.limits.members">issues</a> in [numeric.limits.members].</p>
3269<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3270<p><b>Discussion:</b></p>
3271<p>In several places in 18.3.1.2 [numeric.limits.members], a member is
3272described as "Meaningful for all floating point types."
3273However, no clear method of determining a floating point type is
3274provided.</p>
3275
3276<p>In 18.3.1.5 [numeric.special], paragraph 1 states ". . . (for
3277example, epsilon() is only meaningful if is_integer is
3278false). . ." which suggests that a type is a floating point type
3279if is_specialized is true and is_integer is false; however, this is
3280unclear.</p>
3281
3282<p>When clarifying this, please keep in mind this need of users: what
3283exactly is the definition of floating point? Would a fixed point or
3284rational representation be considered one? I guess my statement here
3285is that there could also be types that are neither integer or
3286(strictly) floating point.</p>
3287
3288
3289<p><b>Rationale:</b></p>
3290<p>It is up to the implementor of a user define type to decide if it is a
3291floating point type.</p>
3292
3293
3294
3295
3296<hr>
3297<h3><a name="207"></a>207. ctype&lt;char&gt; members return clause incomplete</h3>
3298<p><b>Section:</b> 22.4.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
3299 <b>Submitter:</b> Robert Klarer <b>Opened:</b> 1999-11-02  <b>Last modified:</b> 2006-12-30</p>
3300<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.ctype.char.members">issues</a> in [facet.ctype.char.members].</p>
3301<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
3302<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a></p>
3303<p><b>Discussion:</b></p>
3304<p>
3305The <tt>widen</tt> and <tt>narrow</tt> member functions are described
3306in 22.2.1.3.2, paragraphs 9-11.  In each case we have two overloaded
3307signatures followed by a <b>Returns</b> clause.  The <b>Returns</b>
3308clause only describes one of the overloads.
3309</p>
3310
3311
3312<p><b>Proposed resolution:</b></p>
3313<p>Change the returns clause in 22.4.1.3.2 [facet.ctype.char.members]
3314paragraph 10 from:</p>
3315<p>&nbsp;&nbsp;&nbsp; Returns: do_widen(low, high, to).</p>
3316
3317<p>to:</p>
3318<p>&nbsp;&nbsp;&nbsp; Returns: do_widen(c) or do_widen(low, high, to), 
3319respectively.</p>
3320
3321<p>Change the returns clause in 22.4.1.3.2 [facet.ctype.char.members] paragraph 11
3322from:</p> 
3323<p>&nbsp;&nbsp;&nbsp; Returns: do_narrow(low, high, to).</p>
3324
3325<p>to:</p>
3326<p>&nbsp;&nbsp;&nbsp; Returns: do_narrow(c) or do_narrow(low, high, to), 
3327respectively.</p>
3328
3329
3330<p><b>Rationale:</b></p>
3331<p>Subsumed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a>, which addresses the same
3332paragraphs.</p>
3333
3334
3335
3336
3337
3338
3339<hr>
3340<h3><a name="213"></a>213. Math function overloads ambiguous</h3>
3341<p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3342 <b>Submitter:</b> Nico Josuttis <b>Opened:</b> 2000-02-26  <b>Last modified:</b> 2006-12-29</p>
3343<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
3344<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3345<p><b>Discussion:</b></p>
3346<p>Due to the additional overloaded versions of numeric functions for
3347float and long double according to Section 26.5, calls such as int x;
3348std::pow (x, 4) are ambiguous now in a standard conforming
3349implementation. Current implementations solve this problem very
3350different (overload for all types, don't overload for float and long
3351double, use preprocessor, follow the standard and get
3352ambiguities).</p> <p>This behavior should be standardized or at least
3353identified as implementation defined.</p>
3354
3355
3356<p><b>Rationale:</b></p>
3357<p>These math issues are an
3358understood and accepted consequence of the design. They have
3359been discussed several times in the past. Users must write casts
3360or write floating point expressions as arguments.</p>
3361
3362
3363
3364
3365<hr>
3366<h3><a name="215"></a>215. Can a map's key_type be const?</h3>
3367<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#NAD">NAD</a>
3368 <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-02-29  <b>Last modified:</b> 2006-12-27</p>
3369<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
3370<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>
3371<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3372<p><b>Discussion:</b></p>
3373<p>A user noticed that this doesn't compile with the Rogue Wave library because
3374the rb_tree class declares a key_allocator, and allocator&lt;const int&gt; is
3375not legal, I think:</p>
3376<blockquote>
3377  <pre>map &lt; const int, ... &gt; // legal?</pre>
3378</blockquote>
3379<p>which made me wonder whether it is legal for a map's key_type to be const. In
3380email from Matt Austern he said:</p>
3381<blockquote>
3382<p>I'm not sure whether it's legal to declare a map with a const key type. I
3383hadn't thought about that question until a couple weeks ago. My intuitive
3384feeling is that it ought not to be allowed, and that the standard ought to say
3385so. It does turn out to work in SGI's library, though, and someone in the
3386compiler group even used it. Perhaps this deserves to be written up as an issue
3387too.</p>
3388</blockquote>
3389
3390
3391<p><b>Rationale:</b></p>
3392<p>The "key is assignable" requirement from table 69 in
339323.2.4 [associative.reqmts] already implies the key cannot be const.</p>
3394
3395
3396
3397
3398<hr>
3399<h3><a name="216"></a>216. setbase manipulator description flawed</h3>
3400<p><b>Section:</b> 27.7.3 [std.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
3401 <b>Submitter:</b> Hyman Rosen <b>Opened:</b> 2000-02-29  <b>Last modified:</b> 2006-12-30</p>
3402<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#std.manip">issues</a> in [std.manip].</p>
3403<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
3404<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#193">193</a></p>
3405<p><b>Discussion:</b></p>
3406<p>27.7.3 [std.manip] paragraph 5 says:</p>
3407<blockquote>
3408<pre>smanip setbase(int base);</pre>
3409<p> Returns: An object s of unspecified type such that if out is an
3410(instance of) basic_ostream then the expression out&lt;&lt;s behaves
3411as if f(s) were called, in is an (instance of) basic_istream then the
3412expression in&gt;&gt;s behaves as if f(s) were called. Where f can be
3413defined as:</p>
3414<pre>ios_base&amp; f(ios_base&amp; str, int base)
3415{
3416  // set basefield
3417  str.setf(n == 8 ? ios_base::oct :
3418                n == 10 ? ios_base::dec :
3419                n == 16 ? ios_base::hex :
3420                  ios_base::fmtflags(0), ios_base::basefield);
3421  return str;
3422}</pre>
3423</blockquote>
3424<p>There are two problems here. First, f takes two parameters, so the
3425description needs to say that out&lt;&lt;s and in&gt;&gt;s behave as if f(s,base)
3426had been called. Second, f is has a parameter named base, but is written as if
3427the parameter was named n.</p>
3428<p>Actually, there's a third problem. The paragraph has grammatical errors.
3429There needs to be an "and" after the first comma, and the "Where
3430f" sentence fragment needs to be merged into its preceding sentence. You
3431may also want to format the function a little better. The formatting above is
3432more-or-less what the Standard contains.</p>
3433
3434
3435<p><b>Rationale:</b></p>
3436<p>The resolution of this defect is subsumed by the proposed resolution for
3437issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#193">193</a>.</p>
3438
3439<p><i>[Tokyo: The LWG agrees that this is a defect and notes that it
3440occurs additional places in the section, all requiring fixes.]</i></p>
3441
3442
3443
3444
3445
3446
3447
3448
3449<hr>
3450<h3><a name="218"></a>218. Algorithms do not use binary predicate objects for default comparisons</h3>
3451<p><b>Section:</b> 25.4 [alg.sorting] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3452 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2000-03-06  <b>Last modified:</b> 2006-12-27</p>
3453<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>
3454<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3455<p><b>Discussion:</b></p>
3456<p>Many of the algorithms take an argument, pred, of template parameter type
3457BinaryPredicate or an argument comp of template parameter type Compare. These
3458algorithms usually have an overloaded version that does not take the predicate
3459argument. In these cases pred is usually replaced by the use of operator== and
3460comp is replaced by the use of operator&lt;.</p>
3461<p>This use of hard-coded operators is inconsistent with other parts of the
3462library, particularly the containers library, where equality is established
3463using equal_to&lt;&gt; and ordering is established using less&lt;&gt;. Worse,
3464the use of operator&lt;, would cause the following innocent-looking code to have
3465undefined behavior:</p>
3466<blockquote>
3467  <pre>vector&lt;string*&gt; vec;
3468sort(vec.begin(), vec.end());</pre>
3469</blockquote>
3470<p>The use of operator&lt; is not defined for pointers to unrelated objects. If
3471std::sort used less&lt;&gt; to compare elements, then the above code would be
3472well-defined, since less&lt;&gt; is explicitly specialized to produce a total
3473ordering of pointers.</p>
3474
3475
3476<p><b>Rationale:</b></p>
3477<p>This use of operator== and operator&lt; was a very deliberate, conscious, and
3478explicitly made design decision; these operators are often more efficient. The
3479predicate forms are available for users who don't want to rely on operator== and
3480operator&lt;.</p>
3481
3482
3483
3484
3485<hr>
3486<h3><a name="219"></a>219. find algorithm missing version that takes a binary predicate argument</h3>
3487<p><b>Section:</b> 25.2.5 [alg.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3488 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2000-03-06  <b>Last modified:</b> 2009-07-14</p>
3489<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find">issues</a> in [alg.find].</p>
3490<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3491<p><b>Discussion:</b></p>
3492<p>The find function always searches for a value using operator== to compare the
3493value argument to each element in the input iterator range. This is inconsistent
3494with other find-related functions such as find_end and find_first_of, which
3495allow the caller to specify a binary predicate object to be used for determining
3496equality. The fact that this can be accomplished using a combination of find_if
3497and bind_1st or bind_2nd does not negate the desirability of a consistent,
3498simple, alternative interface to find.</p>
3499
3500<p><i>[
3501Summit:
3502]</i></p>
3503
3504
3505<blockquote>
3506Reopened by Alisdair.
3507</blockquote>
3508
3509<p><i>[
35102009-07 Frankfurt
3511]</i></p>
3512
3513
3514<blockquote>
3515<p>
3516The same thing can be achieved using find_if (as noted in the issue).
3517</p>
3518<p>
3519Moved to NAD.
3520</p>
3521</blockquote>
3522
3523
3524
3525<p><b>Proposed resolution:</b></p>
3526<blockquote>
3527<p>In section 25.2.5 [alg.find], add a second prototype for find
3528(between the existing prototype and the prototype for find_if), as
3529follows:</p>
3530<pre>    template&lt;class InputIterator, class T, class BinaryPredicate&gt;
3531      InputIterator find(InputIterator first, InputIterator last,
3532                         const T&amp; value, BinaryPredicate bin_pred);</pre>
3533<p>Change the description of the return from:</p>
3534<blockquote>
3535  <p>Returns: The first iterator i in the range [first, last) for which the following corresponding
3536  conditions hold: *i == value, pred(*i) != false. Returns last if no such iterator is found.</p>
3537</blockquote>
3538<p>&nbsp;to:</p>
3539<blockquote>
3540  <p>Returns: The first iterator i in the range [first, last) for which the following&nbsp;
3541  corresponding condition holds: *i == value, bin_pred(*i,value) != false, pred(*)
3542  != false. Return last if no such iterator is found.</p>
3543</blockquote>
3544</blockquote>
3545
3546
3547<p><b>Rationale:</b></p>
3548<p>This is request for a pure extension, so it is not a defect in the
3549current standard.&nbsp; As the submitter pointed out, "this can
3550be accomplished using a combination of find_if and bind_1st or
3551bind_2nd".</p>
3552
3553
3554
3555
3556<hr>
3557<h3><a name="236"></a>236. ctype&lt;char&gt;::is() member modifies facet</h3>
3558<p><b>Section:</b> 22.4.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
3559 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 2000-04-24  <b>Last modified:</b> 2007-01-15</p>
3560<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.ctype.char.members">issues</a> in [facet.ctype.char.members].</p>
3561<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
3562<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#28">28</a></p>
3563<p><b>Discussion:</b></p>
3564<p>The description of the <tt>is()</tt> member in paragraph 4 of 22.4.1.3.2 [facet.ctype.char.members] is broken: According to this description, the
3565second form of the <tt>is()</tt> method modifies the masks in the
3566<tt>ctype</tt> object. The correct semantics if, of course, to obtain
3567an array of masks. The corresponding method in the general case,
3568ie. the <tt>do_is()</tt> method as described in 22.4.1.1.2 [locale.ctype.virtuals] paragraph 1 does the right thing.</p>
3569
3570
3571<p><b>Proposed resolution:</b></p>
3572  <p>Change paragraph 4 from</p>
3573    <blockquote><p>
3574    The second form, for all *p in the range [low, high), assigns
3575    vec[p-low] to table()[(unsigned char)*p].
3576    </p></blockquote>
3577  <p>to become</p>
3578    <blockquote><p>
3579    The second form, for all *p in the range [low, high), assigns
3580    table()[(unsigned char)*p] to vec[p-low].
3581  </p></blockquote>
3582
3583
3584<p><b>Rationale:</b></p>
3585
3586
3587
3588
3589
3590<hr>
3591<h3><a name="244"></a>244. Must <tt>find</tt>'s third argument be CopyConstructible?</h3>
3592<p><b>Section:</b> 25.2.5 [alg.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3593 <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 2000-05-02  <b>Last modified:</b> 2006-12-27</p>
3594<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find">issues</a> in [alg.find].</p>
3595<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3596<p><b>Discussion:</b></p>
3597<p>Is the following implementation of <tt>find</tt> acceptable?</p>
3598
3599<pre>        template&lt;class Iter, class X&gt;
3600        Iter find(Iter begin, Iter end, const X&amp; x)
3601        {
3602            X x1 = x;           // this is the crucial statement
3603            while (begin != end &amp;&amp; *begin != x1)
3604                ++begin;
3605            return begin;
3606        }
3607</pre>
3608
3609<p>If the answer is yes, then it is implementation-dependent as to
3610whether the following fragment is well formed:</p>
3611
3612<pre>        vector&lt;string&gt; v;
3613
3614        find(v.begin(), v.end(), "foo");
3615</pre>
3616
3617<p>At issue is whether there is a requirement that the third argument
3618of find be CopyConstructible.  There may be no problem here, but
3619analysis is necessary.</p>
3620
3621
3622<p><b>Rationale:</b></p>
3623<p>There is no indication in the standard that find's third argument
3624is required to be Copy Constructible.  The LWG believes that no such
3625requirement was intended.  As noted above, there are times when a user
3626might reasonably pass an argument that is not Copy Constructible.</p>
3627
3628
3629
3630
3631<hr>
3632<h3><a name="245"></a>245. Which operations on <tt>istream_iterator</tt> trigger input operations?</h3>
3633<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#NAD">NAD</a>
3634 <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 2000-05-02  <b>Last modified:</b> 2006-12-27</p>
3635<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>
3636<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3637<p><b>Discussion:</b></p>
3638<p>I do not think the standard specifies what operation(s) on istream
3639iterators trigger input operations.  So, for example:</p>
3640
3641<pre>        istream_iterator&lt;int&gt; i(cin);
3642
3643        int n = *i++;
3644</pre>
3645
3646<p>I do not think it is specified how many integers have been read
3647from cin.  The number must be at least 1, of course, but can it be 2?
3648More?</p>
3649
3650
3651<p><b>Rationale:</b></p>
3652<p>The standard is clear as written: the stream is read every time
3653operator++ is called, and it is also read either when the iterator is
3654constructed or when operator* is called for the first time.  In the
3655example above, exactly two integers are read from cin.</p>
3656
3657<p>There may be a problem with the interaction between istream_iterator
3658and some STL algorithms, such as find.  There are no guarantees about
3659how many times find may invoke operator++.</p>
3660
3661
3662
3663
3664<hr>
3665<h3><a name="246"></a>246. <tt>a.insert(p,t)</tt> is incorrectly specified</h3>
3666<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#Dup">Dup</a>
3667 <b>Submitter:</b> Mark Rodgers <b>Opened:</b> 2000-05-19  <b>Last modified:</b> 2007-01-15</p>
3668<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
3669<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>
3670<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
3671<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a></p>
3672<p><b>Discussion:</b></p>
3673<p>Closed issue 192 raised several problems with the specification of
3674this function, but was rejected as Not A Defect because it was too big
3675a change with unacceptable impacts on existing implementations.
3676However, issues remain that could be addressed with a smaller change
3677and with little or no consequent impact.</p>
3678
3679<ol>
3680   <li><p> The specification is inconsistent with the original
3681   proposal and with several implementations.</p>
3682
3683   <p>The initial implementation by Hewlett Packard only ever looked
3684   immediately <i>before</i> p, and I do not believe there was any
3685   intention to standardize anything other than this behavior.
3686   Consequently, current implementations by several leading
3687   implementors also look immediately before p, and will only insert
3688   after p in logarithmic time.  I am only aware of one implementation
3689   that does actually look after p, and it looks before p as well.  It
3690   is therefore doubtful that existing code would be relying on the
3691   behavior defined in the standard, and it would seem that fixing
3692   this defect as proposed below would standardize existing
3693   practice.</p></li>
3694
3695   <li><p>
3696   The specification is inconsistent with insertion for sequence
3697   containers.</p>
3698
3699   <p>This is difficult and confusing to teach to newcomers.  All
3700   insert operations that specify an iterator as an insertion location
3701   should have a consistent meaning for the location represented by
3702   that iterator.</p></li>
3703
3704   <li><p> As specified, there is no way to hint that the insertion
3705   should occur at the beginning of the container, and the way to hint
3706   that it should occur at the end is long winded and unnatural.</p>
3707
3708   <p>For a container containing n elements, there are n+1 possible
3709   insertion locations and n+1 valid iterators.  For there to be a
3710   one-to-one mapping between iterators and insertion locations, the
3711   iterator must represent an insertion location immediately before
3712   the iterator.</p></li>
3713
3714   <li><p> When appending sorted ranges using insert_iterators,
3715   insertions are guaranteed to be sub-optimal.</p>
3716
3717   <p>In such a situation, the optimum location for insertion is
3718   always immediately after the element previously inserted.  The
3719   mechanics of the insert iterator guarantee that it will try and
3720   insert after the element after that, which will never be correct.
3721   However, if the container first tried to insert before the hint,
3722   all insertions would be performed in amortized constant
3723   time.</p></li>
3724</ol>
3725
3726
3727<p><b>Proposed resolution:</b></p>
3728<p>In 23.1.2 [lib.associative.reqmts] paragraph 7, table 69, make
3729the following changes in the row for a.insert(p,t):</p>
3730
3731<p><i>assertion/note pre/post condition:</i>
3732<br>Change the last sentence from</p>
3733     <blockquote><p>
3734     "iterator p is a hint pointing to where the insert should
3735     start to search."
3736     </p></blockquote>
3737<p>to</p>
3738     <blockquote><p>
3739     "iterator p is a hint indicating that immediately before p
3740     may be a correct location where the insertion could occur."
3741     </p></blockquote>
3742
3743<p><i>complexity:</i><br>
3744Change the words "right after" to "immediately before".</p>
3745
3746
3747<p><b>Rationale:</b></p>
3748
3749
3750
3751
3752
3753<hr>
3754<h3><a name="249"></a>249. Return Type of <tt>auto_ptr::operator=</tt></h3>
3755<p><b>Section:</b> D.10.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3756 <b>Submitter:</b> Joseph Gottman <b>Opened:</b> 2000-06-30  <b>Last modified:</b> 2006-12-29</p>
3757<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>
3758<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3759<p><b>Discussion:</b></p>
3760<p>According to section 20.4.5, the function
3761<tt>auto_ptr::operator=()</tt> returns a reference to an auto_ptr.
3762The reason that <tt>operator=()</tt> usually returns a reference is to
3763facilitate code like</p>
3764
3765<pre>    int x,y,z;
3766    x = y = z = 1;
3767</pre>
3768
3769<p>However, given analogous code for <tt>auto_ptr</tt>s,</p>
3770<pre>    auto_ptr&lt;int&gt; x, y, z;
3771    z.reset(new int(1));
3772    x = y = z;
3773</pre>
3774
3775<p>the result would be that <tt>z</tt> and <tt>y</tt> would both be set to 
3776NULL, instead of all the <tt>auto_ptr</tt>s being set to the same value. 
3777This makes such cascading assignments useless and counterintuitive for 
3778<tt>auto_ptr</tt>s.</p>
3779
3780
3781<p><b>Proposed resolution:</b></p>
3782<p>Change <tt>auto_ptr::operator=()</tt> to return <tt>void</tt> instead
3783of an <tt>auto_ptr</tt> reference.</p>
3784
3785
3786<p><b>Rationale:</b></p>
3787<p>The return value has uses other than cascaded assignments: a user can
3788call an auto_ptr member function, pass the auto_ptr to a
3789function, etc.  Removing the return value could break working user
3790code.</p>
3791
3792
3793
3794
3795<hr>
3796<h3><a name="255"></a>255. Why do <tt>basic_streambuf&lt;&gt;::pbump()</tt> and <tt>gbump()</tt> take an int?</h3>
3797<p><b>Section:</b> 27.6.2 [streambuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
3798 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-08-12  <b>Last modified:</b> 2009-07-14</p>
3799<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf">issues</a> in [streambuf].</p>
3800<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
3801<p><b>Discussion:</b></p>
3802<p>
3803The basic_streambuf members gbump() and pbump() are specified to take an
3804int argument. This requirement prevents the functions from effectively
3805manipulating buffers larger than std::numeric_limits&lt;int&gt;::max()
3806characters. It also makes the common use case for these functions
3807somewhat difficult as many compilers will issue a warning when an
3808argument of type larger than int (such as ptrdiff_t on LLP64
3809architectures) is passed to either of the function. Since it's often the
3810result of the subtraction of two pointers that is passed to the
3811functions, a cast is necessary to silence such warnings. Finally, the
3812usage of a native type in the functions signatures is inconsistent with
3813other member functions (such as sgetn() and sputn()) that manipulate the
3814underlying character buffer. Those functions take a streamsize argument.
3815</p>
3816
3817<p><i>[
38182009-07 Frankfurt
3819]</i></p>
3820
3821
3822<blockquote>
3823<p>
3824This is part of a bigger problem. If anyone cares enough, they should
3825write a paper solving the bigger problem of offset types in iostreams.
3826</p>
3827<p>
3828This is related to the paper about large file sizes. Beman has already
3829agreed to drop the section of that paper that deals with this.
3830</p>
3831<p>
3832int is big enough for reasonable buffers.
3833</p>
3834<p>
3835Move to NAD Future.
3836</p>
3837<p>
3838This is related to LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#423">423</a>.
3839</p>
3840</blockquote>
3841
3842
3843
3844<p><b>Proposed resolution:</b></p>
3845<p>
3846Change the signatures of these functions in the synopsis of template
3847class basic_streambuf (27.5.2) and in their descriptions (27.5.2.3.1, p4
3848and 27.5.2.3.2, p4) to take a streamsize argument.
3849</p>
3850
3851<p>
3852Although this change has the potential of changing the ABI of the
3853library, the change will affect only platforms where int is different
3854than the definition of streamsize. However, since both functions are
3855typically inline (they are on all known implementations), even on such
3856platforms the change will not affect any user code unless it explicitly
3857relies on the existing type of the functions (e.g., by taking their
3858address). Such a possibility is IMO quite remote.
3859</p>
3860
3861<p>
3862Alternate Suggestion from Howard Hinnant, c++std-lib-7780:
3863</p>
3864
3865<p>
3866This is something of a nit, but I'm wondering if streamoff wouldn't be a 
3867better choice than streamsize.  The argument to pbump and gbump MUST be 
3868signed.  But the standard has this to say about streamsize 
3869(27.4.1/2/Footnote):
3870</p>
3871
3872<blockquote><p>
3873     [Footnote: streamsize is used in most places where ISO C would use
3874     size_t.  Most of the uses of streamsize could use size_t, except for
3875     the strstreambuf constructors, which require negative values. It
3876     should probably be the signed type corresponding to size_t (which is
3877     what Posix.2 calls ssize_t). --- end footnote]
3878</p></blockquote>
3879
3880<p>
3881This seems a little weak for the argument to pbump and gbump.  Should we 
3882ever really get rid of strstream, this footnote might go with it, along 
3883with the reason to make streamsize signed.
3884</p>
3885
3886
3887<p><b>Rationale:</b></p>
3888<p>The LWG believes this change is too big for now.  We may wish to
3889reconsider this for a future revision of the standard.  One
3890possibility is overloading pbump, rather than changing the
3891signature.</p>
3892<p><i>[
3893[2006-05-04: Reopened at the request of Chris (Krzysztof ?elechowski)]
3894]</i></p>
3895
3896
3897
3898
3899
3900<hr>
3901<h3><a name="257"></a>257. STL functional object and iterator inheritance.</h3>
3902<p><b>Section:</b> 20.7.3 [base], 24.4.2 [iterator.basic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3903 <b>Submitter:</b> Robert Dick  <b>Opened:</b> 2000-08-17  <b>Last modified:</b> 2006-12-29</p>
3904<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p>
3905<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3906<p><b>Discussion:</b></p>
3907<p>
3908According to the November 1997 Draft Standard, the results of deleting an
3909object of a derived class through a pointer to an object of its base class are
3910undefined if the base class has a non-virtual destructor.  Therefore, it is
3911potentially dangerous to publicly inherit from such base classes.
3912</p>
3913
3914<p>Defect:
3915<br>
3916The STL design encourages users to publicly inherit from a number of classes
3917which do nothing but specify interfaces, and which contain non-virtual
3918destructors.
3919</p>
3920
3921<p>Attribution:
3922<br>
3923Wil Evers and William E. Kempf suggested this modification for functional
3924objects.
3925</p>
3926
3927
3928<p><b>Proposed resolution:</b></p>
3929<p>
3930When a base class in the standard library is useful only as an interface
3931specifier, i.e., when an object of the class will never be directly
3932instantiated, specify that the class contains a protected destructor.  This
3933will prevent deletion through a pointer to the base class without performance,
3934or space penalties (on any implementation I'm aware of).
3935</p>
3936
3937<p>
3938As an example, replace...
3939</p>
3940
3941<pre>    template &lt;class Arg, class Result&gt;
3942    struct unary_function {
3943            typedef Arg    argument_type;
3944            typedef Result result_type;
3945    };
3946</pre>
3947
3948<p>
3949... with...
3950</p>
3951
3952<pre>    template &lt;class Arg, class Result&gt;
3953    struct unary_function {
3954            typedef Arg    argument_type;
3955            typedef Result result_type;
3956    protected:
3957            ~unary_function() {}
3958    };
3959</pre>
3960
3961<p>
3962Affected definitions:
3963<br>
3964  &nbsp;20.3.1 [lib.function.objects] -- unary_function, binary_function
3965  <br>
3966  &nbsp;24.3.2 [lib.iterator.basic] -- iterator
3967</p>
3968
3969
3970<p><b>Rationale:</b></p>
3971<p>
3972The standard is clear as written; this is a request for change, not a
3973defect in the strict sense.  The LWG had several different objections
3974to the proposed change.  One is that it would prevent users from
3975creating objects of type <tt>unary_function</tt> and
3976<tt>binary_function</tt>.  Doing so can sometimes be legitimate, if users
3977want to pass temporaries as traits or tag types in generic code.
3978</p>
3979
3980
3981
3982
3983
3984<hr>
3985<h3><a name="267"></a>267. interaction of strstreambuf::overflow() and seekoff()</h3>
3986<p><b>Section:</b> D.8.1.3 [depr.strstreambuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
3987 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2000-10-05  <b>Last modified:</b> 2007-01-15</p>
3988<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.strstreambuf.virtuals">issues</a> in [depr.strstreambuf.virtuals].</p>
3989<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
3990<p><b>Discussion:</b></p>
3991<p>
3992It appears that the interaction of the strstreambuf members overflow()
3993and seekoff() can lead to undefined behavior in cases where defined
3994behavior could reasonably be expected. The following program
3995demonstrates this behavior:
3996</p>
3997
3998<pre>    #include &lt;strstream&gt;
3999
4000    int main ()
4001    {
4002         std::strstreambuf sb;
4003         sb.sputc ('c');
4004
4005         sb.pubseekoff (-1, std::ios::end, std::ios::in);
4006         return !('c' == sb.sgetc ());
4007    }
4008</pre>
4009
4010<p>
4011D.7.1.1, p1 initializes strstreambuf with a call to basic_streambuf&lt;&gt;(),
4012which in turn sets all pointers to 0 in 27.5.2.1, p1.
4013</p>
4014 
4015<p>
401627.5.2.2.5, p1 says that basic_streambuf&lt;&gt;::sputc(c) calls
4017overflow(traits::to_int_type(c)) if a write position isn't available (it
4018isn't due to the above).
4019</p>
4020
4021<p>
4022D.7.1.3, p3 says that strstreambuf::overflow(off, ..., ios::in) makes at
4023least one write position available (i.e., it allows the function to make
4024any positive number of write positions available).
4025</p>
4026
4027<p>
4028D.7.1.3, p13 computes newoff = seekhigh - eback(). In D.7.1, p4 we see
4029seekhigh = epptr() ? epptr() : egptr(), or seekhigh = epptr() in this
4030case. newoff is then epptr() - eback().
4031</p>
4032
4033<p>
4034D.7.1.4, p14 sets gptr() so that gptr() == eback() + newoff + off, or
4035gptr() == epptr() + off holds.
4036</p>
4037
4038<p>
4039If strstreambuf::overflow() made exactly one write position available
4040then gptr() will be set to just before epptr(), and the program will
4041return 0. Buf if the function made more than one write position
4042available, epptr() and gptr() will both point past pptr() and the
4043behavior of the program is undefined.
4044</p>
4045
4046
4047<p><b>Proposed resolution:</b></p>
4048
4049
4050   <p>Change the last sentence of D.8.1 [depr.strstreambuf] paragraph 4 from</p>
4051
4052      <blockquote><p>
4053      Otherwise, seeklow equals gbeg and seekhigh is either pend, if
4054      pend is not a null pointer, or gend.
4055      </p></blockquote>
4056
4057   <p>to become</p>
4058
4059      <blockquote><p>
4060      Otherwise, seeklow equals gbeg and seekhigh is either gend if
4061      0 == pptr(), or pbase() + max where max is the maximum value of
4062      pptr() - pbase() ever reached for this stream.
4063      </p></blockquote>
4064
4065<p><i>[
4066  pre-Copenhagen: Dietmar provided wording for proposed resolution.
4067]</i></p>
4068
4069
4070<p><i>[
4071  post-Copenhagen: Fixed a typo: proposed resolution said to fix
4072  4.7.1, not D.7.1.
4073]</i></p>
4074
4075
4076
4077
4078<p><b>Rationale:</b></p>
4079<p>This is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#65">65</a>: it's not clear what it
4080means to seek beyond the current area.  Without resolving issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#65">65</a> we can't resolve this.  As with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#65">65</a>, 
4081the library working group does not wish to invest time nailing down
4082corner cases in a deprecated feature.</p>
4083
4084
4085
4086
4087
4088<hr>
4089<h3><a name="269"></a>269. cstdarg and unnamed parameters</h3>
4090<p><b>Section:</b> 18.8 [support.exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4091 <b>Submitter:</b> J. Stephen Adamczyk <b>Opened:</b> 2000-10-10  <b>Last modified:</b> 2006-12-27</p>
4092<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.exception">issues</a> in [support.exception].</p>
4093<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4094<p><b>Discussion:</b></p>
4095<p>
4096One of our customers asks whether this is valid C++:
4097</p>
4098
4099<pre>   #include &lt;cstdarg&gt;
4100
4101   void bar(const char *, va_list);
4102
4103   void
4104   foo(const char *file, const char *, ...)
4105   {
4106     va_list ap;
4107     va_start(ap, file);
4108     bar(file, ap);
4109     va_end(ap);
4110   }
4111</pre>
4112
4113<p>
4114The issue being whether it is valid to use cstdarg when the final
4115parameter before the "..." is unnamed.  cstdarg is, as far
4116as I can tell, inherited verbatim from the C standard. and the
4117definition there (7.8.1.1 in the ISO C89 standard) refers to "the
4118identifier of the rightmost parameter".  What happens when there
4119is no such identifier?
4120</p>
4121
4122<p>
4123My personal opinion is that this should be allowed, but some tweak
4124might be required in the C++ standard.
4125</p>
4126
4127
4128<p><b>Rationale:</b></p>
4129<p>
4130Not a defect, the C and C++ standards are clear.  It is impossible to
4131use varargs if the parameter immediately before "..." has no
4132name, because that is the parameter that must be passed to va_start.
4133The example given above is broken, because va_start is being passed
4134the wrong parameter.
4135</p>
4136
4137<p>
4138There is no support for extending varargs to provide additional
4139functionality beyond what's currently there.  For reasons of C/C++
4140compatibility, it is especially important not to make gratuitous
4141changes in this part of the C++ standard.  The C committee has already
4142been requested not to touch this part of the C standard unless
4143necessary.
4144</p>
4145
4146
4147
4148
4149<hr>
4150<h3><a name="277"></a>277. Normative encouragement in allocator requirements unclear</h3>
4151<p><b>Section:</b> 20.2.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4152 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2000-11-07  <b>Last modified:</b> 2006-12-30</p>
4153<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>
4154<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4155<p><b>Discussion:</b></p>
4156<p>
4157In 20.1.5, paragraph 5, the standard says that "Implementors are
4158encouraged to supply libraries that can accept allocators that
4159encapsulate more general memory models and that support non-equal
4160instances." This is intended as normative encouragement to
4161standard library implementors.  However, it is possible to interpret
4162this sentence as applying to nonstandard third-party libraries.
4163</p>
4164
4165
4166<p><b>Proposed resolution:</b></p>
4167<p>
4168In 20.1.5, paragraph 5, change "Implementors" to
4169"Implementors of the library described in this International
4170Standard".
4171</p>
4172
4173
4174<p><b>Rationale:</b></p>
4175<p>The LWG believes the normative encouragement is already
4176sufficiently clear, and that there are no important consequences
4177even if it is misunderstood.</p>
4178
4179
4180
4181
4182
4183<hr>
4184<h3><a name="279"></a>279. const and non-const iterators should have equivalent typedefs</h3>
4185<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#NAD">NAD</a>
4186 <b>Submitter:</b> Steve Cleary <b>Opened:</b> 2000-11-27  <b>Last modified:</b> 2006-12-27</p>
4187<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>
4188<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>
4189<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4190<p><b>Discussion:</b></p>
4191
4192<p>
4193This came from an email from Steve Cleary to Fergus in reference to
4194issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>. The library working group briefly discussed
4195this in Toronto and believes it should be a separate issue.
4196</p>
4197
4198<p>
4199Steve said: "We may want to state that the const/non-const iterators must have
4200the same difference type, size_type, and category."
4201</p>
4202
4203<p>
4204(Comment from Judy)
4205I'm not sure if the above sentence should be true for all
4206const and non-const iterators in a particular container, or if it means 
4207the container's iterator can't be compared with the container's
4208const_iterator unless the above it true. I suspect the former.
4209</p>
4210
4211
4212<p><b>Proposed resolution:</b></p>
4213<p>
4214In <b>Section:</b> 23.2 [container.requirements],
4215table 65, in the assertion/note pre/post condition for X::const_iterator,
4216add the following:
4217</p>
4218
4219<blockquote>
4220<p>
4221typeid(X::const_iterator::difference_type) == typeid(X::iterator::difference_type)
4222</p>
4223
4224<p>
4225typeid(X::const_iterator::size_type) == typeid(X::iterator::size_type)
4226</p>
4227
4228<p>
4229typeid(X::const_iterator::category) == typeid(X::iterator::category)
4230</p>
4231</blockquote>
4232
4233
4234<p><b>Rationale:</b></p>
4235<p>Going through the types one by one: Iterators don't have a
4236<tt>size_type</tt>.  We already know that the difference types are
4237identical, because the container requirements already say that the
4238difference types of both X::iterator and X::const_iterator are both
4239X::difference_type.  The standard does not require that X::iterator
4240and X::const_iterator have the same iterator category, but the LWG
4241does not see this as a defect: it's possible to imagine cases in which
4242it would be useful for the categories to be different.</p>
4243
4244<p>It may be desirable to require X::iterator and X::const_iterator to
4245have the same value type, but that is a new issue. (Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#322">322</a>.)</p>
4246
4247
4248
4249
4250
4251
4252<hr>
4253<h3><a name="287"></a>287. conflicting ios_base fmtflags</h3>
4254<p><b>Section:</b> 27.5.2.2 [fmtflags.state] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4255 <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-12-30  <b>Last modified:</b> 2006-12-27</p>
4256<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fmtflags.state">issues</a> in [fmtflags.state].</p>
4257<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4258<p><b>Discussion:</b></p>
4259<p>
4260The Effects clause for ios_base::setf(fmtflags fmtfl) says
4261"Sets fmtfl in flags()".  What happens if the user first calls
4262ios_base::scientific and then calls ios_base::fixed or vice-versa?
4263This is an issue for all of the conflicting flags, i.e. ios_base::left
4264and ios_base::right or ios_base::dec, ios_base::hex and ios_base::oct.
4265</p>
4266
4267<p>
4268I see three possible solutions: 
4269</p>
4270
4271<ol>
4272<li>Set ios_base::failbit whenever the user specifies a conflicting
4273flag with one previously explicitly set. If the constructor is
4274supposed to set ios_base::dec (see discussion below), then
4275the user setting hex or oct format after construction will not
4276set failbit. </li>
4277<li>The last call to setf "wins", i.e. it clears any conflicting
4278previous setting.</li>
4279<li>All the flags that the user specifies are set, but when actually 
4280interpreting them, fixed always override scientific, right always 
4281overrides left, dec overrides hex which overrides oct.</li>
4282</ol>
4283
4284<p>
4285Most existing implementations that I tried seem to conform to resolution #3,
4286except that when using the iomanip manipulator hex or oct then that always 
4287overrides dec, but calling setf(ios_base::hex) doesn't. 
4288</p>
4289
4290<p>
4291There is a sort of related issue, which is that although the ios_base
4292constructor says that each ios_base member has an indeterminate value
4293after construction, all the existing implementations I tried explicitly set 
4294ios_base::dec.
4295</p>
4296
4297
4298<p><b>Proposed resolution:</b></p>
4299
4300
4301<p><b>Rationale:</b></p>
4302<p>
4303<tt>adjustfield</tt>, <tt>basefield</tt>, and <tt>floatfield</tt>
4304are each multi-bit fields.  It is possible to set multiple bits within
4305each of those fields.  (For example, <tt>dec</tt> and
4306<tt>oct</tt>). These fields are used by locale facets. The LWG
4307reviewed the way in which each of those three fields is used, and
4308believes that in each case the behavior is well defined for any
4309possible combination of bits. See for example Table 58, in 22.4.2.2.2
4310[facet.num.put.virtuals], noting the requirement in paragraph 6 of that
4311section.
4312</p>
4313<p>
4314Users are advised to use manipulators, or else use the two-argument
4315version of <tt>setf</tt>, to avoid unexpected behavior.
4316</p>
4317
4318
4319
4320
4321
4322<hr>
4323<h3><a name="289"></a>289. &lt;cmath&gt; requirements missing C float and long double versions</h3>
4324<p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4325 <b>Submitter:</b> Judy Ward <b>Opened:</b> 2000-12-30  <b>Last modified:</b> 2007-01-15</p>
4326<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
4327<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4328<p><b>Discussion:</b></p>
4329<p>
4330    In ISO/IEC 9899:1990 Programming Languages C we find the following
4331    concerning &lt;math.h&gt;:
4332</p>
4333
4334<blockquote><p>
4335         7.13.4 Mathematics &lt;math.h&gt;
4336         <br>
4337         The names of all existing functions declared in the &lt;math.h&gt;
4338         header, suffixed with f or l, are reserved respectively for
4339         corresponding functions with float and long double arguments
4340         are return values.
4341</p></blockquote>
4342
4343<p>
4344    For example, <tt>float&nbsp;sinf(float)</tt>
4345    is reserved.
4346</p>
4347
4348<p>
4349    In the C99 standard, &lt;math.h&gt; must contain declarations
4350    for these functions.
4351</p>
4352
4353<p>
4354So, is it acceptable for an implementor to add these prototypes to the
4355C++ versions of the math headers? Are they required?
4356</p>
4357
4358
4359<p><b>Proposed resolution:</b></p>
4360<p>
4361Add these Functions to Table 80, section 26.5 and to Table 99,
4362section C.2:
4363</p>
4364
4365<pre>    acosf asinf atanf atan2f ceilf cosf coshf 
4366    expf fabsf floorf fmodf frexpf ldexpf 
4367    logf log10f modff powf sinf sinhf sqrtf 
4368    tanf tanhf 
4369    acosl asinl atanl atan2l ceill cosl coshl 
4370    expl fabsl floorl fmodl frexpl ldexpl 
4371    logl log10l modfl powl sinl sinhl sqrtl 
4372    tanl tanhl
4373</pre>
4374
4375<p>
4376There should probably be a note saying that these functions
4377are optional and, if supplied, should match the description in
4378the 1999 version of the C standard. In the next round
4379of C++ standardization they can then become mandatory. 
4380</p>
4381
4382
4383<p><b>Rationale:</b></p>
4384<p>The C90 standard, as amended, already permits (but does not
4385require) these functions, and the C++ standard incorporates the
4386C90 standard by reference.  C99 is not an issue, because it is
4387never referred to by the C++ standard.</p>
4388
4389
4390
4391
4392
4393<hr>
4394<h3><a name="290"></a>290. Requirements to for_each and its function object</h3>
4395<p><b>Section:</b> 25.2.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4396 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 2001-01-03  <b>Last modified:</b> 2009-07-14</p>
4397<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>
4398<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4399<p><b>Discussion:</b></p>
4400<p>The specification of the for_each algorithm does not have a
4401"Requires" section, which means that there are no
4402restrictions imposed on the function object whatsoever. In essence it
4403means that I can provide any function object with arbitrary side
4404effects and I can still expect a predictable result. In particular I
4405can expect that the function object is applied exactly last - first
4406times, which is promised in the "Complexity" section.
4407</p>
4408
4409<p>I don't see how any implementation can give such a guarantee
4410without imposing requirements on the function object.
4411</p>
4412
4413<p>Just as an example: consider a function object that removes
4414elements from the input sequence.  In that case, what does the
4415complexity guarantee (applies f exactly last - first times) mean?
4416</p>
4417
4418<p>One can argue that this is obviously a nonsensical application and
4419a theoretical case, which unfortunately it isn't.  I have seen
4420programmers shooting themselves in the foot this way, and they did not
4421understand that there are restrictions even if the description of the
4422algorithm does not say so.
4423</p>
4424<p><i>[Lillehammer: This is more general than for_each.  We don't want
4425  the function object in transform invalidiating iterators
4426  either. There should be a note somewhere in clause 17 (17, not 25)
4427  saying that user code operating on a range may not invalidate
4428  iterators unless otherwise specified.  Bill will provide wording.]</i></p>
4429
4430
4431<p><i>[
44322009-07 Frankfurt
4433]</i></p>
4434
4435
4436<blockquote>
4437<p>
4438Moved to NAD.
4439</p>
4440<p>
4441It was felt that the current description is adequate, and that there are
4442limits to what the standard can reasonably say to prohibit perverse uses
4443of the library.
4444</p>
4445</blockquote>
4446
4447
4448
4449<p><b>Proposed resolution:</b></p>
4450
4451
4452
4453
4454
4455
4456<hr>
4457<h3><a name="293"></a>293. Order of execution in transform algorithm</h3>
4458<p><b>Section:</b> 25.3.4 [alg.transform] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4459 <b>Submitter:</b> Angelika Langer <b>Opened:</b> 2001-01-04  <b>Last modified:</b> 2007-01-15</p>
4460<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.transform">issues</a> in [alg.transform].</p>
4461<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4462<p><b>Discussion:</b></p>
4463<p>This issue is related to issue 242.  In case that the resolution
4464proposed for issue 242 is accepted, we have have the following
4465situation: The 4 numeric algorithms (accumulate and consorts) as well
4466as transform would allow a certain category of side effects.  The
4467numeric algorithms specify that they invoke the functor "for
4468every iterator i in the range [first, last) in order". transform,
4469in contrast, would not give any guarantee regarding order of
4470invocation of the functor, which means that the functor can be invoked
4471in any arbitrary order.
4472</p>
4473
4474<p>Why would that be a problem?  Consider an example: say the
4475transformator that is a simple enumerator ( or more generally
4476speaking, "is order-sensitive" ).  Since a standard
4477compliant implementation of transform is free to invoke the enumerator
4478in no definite order, the result could be a garbled enumeration.
4479Strictly speaking this is not a problem, but it is certainly at odds
4480with the prevalent understanding of transform as an algorithms that
4481assigns "a new _corresponding_ value" to the output
4482elements.
4483</p>
4484
4485<p>All implementations that I know of invoke the transformator in
4486definite order, namely starting from first and proceeding to last -
44871. Unless there is an optimization conceivable that takes advantage of
4488the indefinite order I would suggest to specify the order, because it
4489eliminate the uncertainty that users would otherwise have regarding
4490the order of execution of their potentially order-sensitive function
4491objects.
4492</p>
4493
4494
4495<p><b>Proposed resolution:</b></p>
4496<p>In section 25.2.3 - Transform [lib.alg.transform] change:</p>
4497<blockquote><p>
4498-1- Effects: Assigns through every iterator i in the range [result,
4499result + (last1 - first1)) a new corresponding
4500value equal to op(*(first1 + (i - result)) or binary_op(*(first1 +
4501(i - result), *(first2 + (i - result))).
4502</p></blockquote>
4503<p>to:</p>
4504<blockquote><p>
4505-1- Effects: Computes values by  invoking the operation op or binary_op 
4506for every iterator in the range [first1, last1) in order. Assigns through
4507every iterator i in the range [result, result + (last1 - first1)) a new
4508corresponding
4509value equal to op(*(first1 + (i - result)) or binary_op(*(first1 +
4510(i - result), *(first2 + (i - result))).
4511</p></blockquote>
4512
4513
4514<p><b>Rationale:</b></p>
4515<p>For Input Iterators an order is already guaranteed, because
4516only one order is possible.  If a user who passes a Forward
4517Iterator to one of these algorithms really needs a specific
4518order of execution, it's possible to achieve that effect by
4519wrapping it in an Input Iterator adaptor.</p>
4520
4521
4522
4523
4524
4525<hr>
4526<h3><a name="302"></a>302. Need error indication from codecvt&lt;&gt;::do_length</h3>
4527<p><b>Section:</b> 22.4.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4528 <b>Submitter:</b> Gregory Bumgardner <b>Opened:</b> 2001-01-25  <b>Last modified:</b> 2006-12-27</p>
4529<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p>
4530<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4531<p><b>Discussion:</b></p>
4532<p>
4533The effects of <tt>codecvt&lt;&gt;::do_length()</tt> are described in
453422.2.1.5.2, paragraph 10.  As implied by that paragraph, and clarified
4535in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#75">75</a>, <tt>codecvt&lt;&gt;::do_length()</tt> must
4536process the source data and update the <tt>stateT</tt> argument just
4537as if the data had been processed by <tt>codecvt&lt;&gt;::in()</tt>.
4538However, the standard does not specify how <tt>do_length()</tt> would
4539report a translation failure, should the source sequence contain
4540untranslatable or illegal character sequences.
4541</p>
4542
4543<p>
4544The other conversion methods return an "error" result value
4545to indicate that an untranslatable character has been encountered, but
4546<tt>do_length()</tt> already has a return value (the number of source
4547characters that have been processed by the method).
4548</p>
4549
4550
4551<p><b>Proposed resolution:</b></p>
4552<p>
4553This issue cannot be resolved without modifying the interface. An exception
4554cannot be used, as there would be no way to determine how many characters
4555have been processed and the state object would be left in an indeterminate
4556state.
4557</p>
4558
4559<p>
4560A source compatible solution involves adding a fifth argument to length()
4561and do_length() that could be used to return position of the offending
4562character sequence. This argument would have a default value that would
4563allow it to be ignored:
4564</p>
4565
4566<pre>  int length(stateT&amp; state, 
4567             const externT* from, 
4568             const externT* from_end, 
4569             size_t max,
4570             const externT** from_next = 0);
4571
4572  virtual
4573  int do_length(stateT&amp; state, 
4574                const externT* from, 
4575                const externT* from_end, 
4576                size_t max,
4577                const externT** from_next);
4578</pre>
4579
4580<p>
4581Then an exception could be used to report any translation errors and
4582the from_next argument, if used, could then be used to retrieve the
4583location of the offending character sequence.
4584</p>
4585
4586
4587<p><b>Rationale:</b></p>
4588<p>The standard is already clear: the return value is the number of
4589"valid complete characters".  If it encounters an invalid sequence of
4590external characters, it stops.</p>
4591
4592
4593
4594
4595
4596<hr>
4597<h3><a name="304"></a>304. Must <tt>*a</tt> return an lvalue when <tt>a</tt> is an input iterator?</h3>
4598<p><b>Section:</b> X [iterator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4599 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2001-02-05  <b>Last modified:</b> 2008-09-30</p>
4600<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>
4601<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4602<p><b>Discussion:</b></p>
4603<p>
4604We all "know" that input iterators are allowed to produce
4605values when dereferenced of which there is no other in-memory copy.
4606</p>
4607
4608<p>
4609But: Table 72, with a careful reading, seems to imply that this can only be
4610the case if the value_type has no members (e.g. is a built-in type).
4611</p>
4612
4613<p>The problem occurs in the following entry:</p>
4614
4615<pre>  a-&gt;m     pre: (*a).m is well-defined
4616           Equivalent to (*a).m
4617</pre>
4618
4619<p>
4620<tt>*a.m</tt> can be well-defined if <tt>*a</tt> is not a reference
4621type, but since <tt>operator-&gt;()</tt> must return a pointer for
4622<tt>a-&gt;m</tt> to be well-formed, it needs something to return a
4623pointer <i>to</i>. This seems to indicate that <tt>*a</tt> must be
4624buffered somewhere to make a legal input iterator.
4625</p>
4626
4627<p>I don't think this was intentional.</p>
4628
4629
4630<p><b>Rationale:</b></p>
4631<p>The current standard is clear and consistent.  Input iterators that
4632  return rvalues are in fact implementable.  They may in some cases
4633  require extra work, but it is still possible to define an operator-&gt;
4634  in such cases: it doesn't have to return a T*, but may return a
4635  proxy type.  No change to the standard is justified.</p>
4636
4637
4638
4639
4640
4641<hr>
4642<h3><a name="309"></a>309. Does sentry catch exceptions?</h3>
4643<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#NAD">NAD</a>
4644 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-03-19  <b>Last modified:</b> 2009-07-14</p>
4645<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>
4646<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4647<p><b>Discussion:</b></p>
4648<p>
4649The descriptions of the constructors of basic_istream&lt;&gt;::sentry
4650(27.7.1.1.3 [istream::sentry]) and basic_ostream&lt;&gt;::sentry
4651(27.7.2.4 [ostream::sentry]) do not explain what the functions do in
4652case an exception is thrown while they execute. Some current
4653implementations allow all exceptions to propagate, others catch them
4654and set ios_base::badbit instead, still others catch some but let
4655others propagate.
4656</p>
4657
4658<p>
4659The text also mentions that the functions may call setstate(failbit)
4660(without actually saying on what object, but presumably the stream
4661argument is meant).  That may have been fine for
4662basic_istream&lt;&gt;::sentry prior to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>, since
4663the function performs an input operation which may fail. However,
4664issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a> amends 27.7.1.1.3 [istream::sentry], p2 to
4665clarify that the function should actually call setstate(failbit |
4666eofbit), so the sentence in p3 is redundant or even somewhat
4667contradictory.
4668</p>
4669
4670<p>
4671The same sentence that appears in 27.7.2.4 [ostream::sentry], p3
4672doesn't seem to be very meaningful for basic_istream&lt;&gt;::sentry
4673which performs no input. It is actually rather misleading since it
4674would appear to guide library implementers to calling
4675setstate(failbit) when os.tie()-&gt;flush(), the only called function,
4676throws an exception (typically, it's badbit that's set in response to
4677such an event).
4678</p>
4679
4680<p><b>Additional comments from Martin, who isn't comfortable with the
4681    current proposed resolution</b> (see c++std-lib-11530)</p>
4682
4683<p>
4684The istream::sentry ctor says nothing about how the function
4685deals with exemptions (27.6.1.1.2, p1 says that the class is
4686responsible for doing "exception safe"(*) prefix and suffix
4687operations but it doesn't explain what level of exception
4688safety the class promises to provide). The mockup example
4689of a "typical implementation of the sentry ctor" given in
469027.6.1.1.2, p6, removed in ISO/IEC 14882:2003, doesn't show
4691exception handling, either. Since the ctor is not classified
4692as a formatted or unformatted input function, the text in
469327.6.1.1, p1 through p4 does not apply. All this would seem
4694to suggest that the sentry ctor should not catch or in any
4695way handle exceptions thrown from any functions it may call.
4696Thus, the typical implementation of an istream extractor may
4697look something like [1].
4698</p>
4699
4700<p>
4701The problem with [1] is that while it correctly sets ios::badbit
4702if an exception is thrown from one of the functions called from
4703the sentry ctor, if the sentry ctor reaches EOF while extracting
4704whitespace from a stream that has eofbit or failbit set in
4705exceptions(), it will cause an ios::failure to be thrown, which
4706will in turn cause the extractor to set ios::badbit.
4707</p>
4708
4709<p>
4710The only straightforward way to prevent this behavior is to
4711move the definition of the sentry object in the extractor
4712above the try block (as suggested by the example in 22.2.8,
4713p9 and also indirectly supported by 27.6.1.3, p1). See [2].
4714But such an implementation will allow exceptions thrown from
4715functions called from the ctor to freely propagate to the
4716caller regardless of the setting of ios::badbit in the stream
4717object's exceptions().
4718</p>
4719
4720<p>
4721So since neither [1] nor [2] behaves as expected, the only
4722possible solution is to have the sentry ctor catch exceptions
4723thrown from called functions, set badbit, and propagate those
4724exceptions if badbit is also set in exceptions(). (Another
4725solution exists that deals with both kinds of sentries, but
4726the code is non-obvious and cumbersome -- see [3].)
4727</p>
4728
4729<p>
4730Please note that, as the issue points out, current libraries
4731do not behave consistently, suggesting  that implementors are
4732not quite clear on the exception handling in istream::sentry,
4733despite the fact that some LWG members might feel otherwise.
4734(As documented by the parenthetical comment here:
4735http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1480.html#309)
4736</p>
4737
4738<p>
4739Also please note that those LWG members who in Copenhagen
4740felt that "a sentry's constructor should not catch exceptions,
4741because sentries should only be used within (un)formatted input
4742functions and that exception handling is the responsibility of
4743those functions, not of the sentries," as noted here
4744http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1310.html#309
4745would in effect be either arguing for the behavior described
4746in [1] or for extractors implemented along the lines of [3].
4747</p>
4748
4749<p>
4750The original proposed resolution (Revision 25 of the issues
4751list) clarifies the role of the sentry ctor WRT exception
4752handling by making it clear that extractors (both library
4753or user-defined) should be implemented along the lines of
4754[2] (as opposed to [1]) and that no exception thrown from
4755the callees should propagate out of either function unless
4756badbit is also set in exceptions().
4757</p>
4758
4759
4760<p>[1] Extractor that catches exceptions thrown from sentry:</p>
4761
4762<blockquote>
4763<pre>struct S { long i; };
4764
4765istream&amp; operator&gt;&gt; (istream &amp;strm, S &amp;s)
4766{
4767    ios::iostate err = ios::goodbit;
4768    try {
4769        const istream::sentry guard (strm, false);
4770        if (guard) {
4771            use_facet&lt;num_get&lt;char&gt; &gt;(strm.getloc ())
4772                .get (istreambuf_iterator&lt;char&gt;(strm),
4773                      istreambuf_iterator&lt;char&gt;(),
4774                      strm, err, s.i);
4775        }
4776    }
4777    catch (...) {
4778        bool rethrow;
4779        try {
4780            strm.setstate (ios::badbit);
4781            rethrow = false;
4782        }
4783        catch (...) {
4784            rethrow = true;
4785        }
4786        if (rethrow)
4787            throw;
4788    }
4789    if (err)
4790        strm.setstate (err);
4791    return strm;
4792}
4793</pre>
4794</blockquote>
4795
4796<p>[2] Extractor that propagates exceptions thrown from sentry:</p>
4797
4798<blockquote>
4799<pre>istream&amp; operator&gt;&gt; (istream &amp;strm, S &amp;s)
4800{
4801    istream::sentry guard (strm, false);
4802    if (guard) {
4803        ios::iostate err = ios::goodbit;
4804        try {
4805            use_facet&lt;num_get&lt;char&gt; &gt;(strm.getloc ())
4806                .get (istreambuf_iterator&lt;char&gt;(strm),
4807                      istreambuf_iterator&lt;char&gt;(),
4808                      strm, err, s.i);
4809        }
4810        catch (...) {
4811            bool rethrow;
4812            try {
4813                strm.setstate (ios::badbit);
4814                rethrow = false;
4815            }
4816            catch (...) {
4817                rethrow = true;
4818            }
4819            if (rethrow)
4820                throw;
4821        }
4822        if (err)
4823            strm.setstate (err);
4824    }
4825    return strm;
4826}
4827</pre>
4828</blockquote>
4829
4830<p>
4831[3] Extractor that catches exceptions thrown from sentry
4832but doesn't set badbit if the exception was thrown as a
4833result of a call to strm.clear().
4834</p>
4835
4836<blockquote>
4837<pre>istream&amp; operator&gt;&gt; (istream &amp;strm, S &amp;s)
4838{
4839    const ios::iostate state = strm.rdstate ();
4840    const ios::iostate except = strm.exceptions ();
4841    ios::iostate err = std::ios::goodbit;
4842    bool thrown = true;
4843    try {
4844        const istream::sentry guard (strm, false);
4845        thrown = false;
4846        if (guard) {
4847            use_facet&lt;num_get&lt;char&gt; &gt;(strm.getloc ())
4848                .get (istreambuf_iterator&lt;char&gt;(strm),
4849                      istreambuf_iterator&lt;char&gt;(),
4850                      strm, err, s.i);
4851        }
4852    }
4853    catch (...) {
4854        if (thrown &amp;&amp; state &amp; except)
4855            throw;
4856        try {
4857            strm.setstate (ios::badbit);
4858            thrown = false;
4859        }
4860        catch (...) {
4861            thrown = true;
4862        }
4863        if (thrown)
4864            throw;
4865    }
4866    if (err)
4867        strm.setstate (err);
4868
4869    return strm;
4870}
4871</pre>
4872</blockquote>
4873
4874<p>
4875[Pre-Berlin] Reopened at the request of Paolo Carlini and Steve Clamage.
4876</p>
4877
4878<p>
4879[Pre-Portland] A relevant newsgroup post:
4880</p>
4881
4882<p>
4883The current proposed resolution of issue #309
4884(http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309)  is
4885unacceptable.   I write commerical software and coding around this
4886makes my code ugly, non-intuitive, and requires comments referring
4887people to this very issue.   Following is the full explanation of my
4888experience.
4889</p>
4890<p>
4891In the course of writing software for commercial use, I constructed
4892std::ifstream's based on user-supplied pathnames on typical POSIX
4893systems.
4894</p>
4895<p>
4896It was expected that some files that opened successfully might not read
4897successfully -- such as a pathname which actually refered to a
4898directory.   Intuitively, I expected the streambuffer underflow() code
4899to throw an exception in this situation, and recent implementations of
4900libstdc++'s basic_filebuf do just that (as well as many of my own
4901custom streambufs).
4902</p>
4903<p>
4904I also intuitively expected that the istream code would convert these
4905exceptions to the "badbit' set on the stream object, because I had not
4906requested exceptions.    I refer to 27.6.1.1. P4.
4907</p>
4908<p>
4909However, this was not the case on at least two implementations -- if
4910the first thing I did with an istream was call operator&gt;&gt;( T&amp; ) for T
4911among the basic arithmetic types and std::string.   Looking further I
4912found that the sentry's constructor was invoking the exception when it
4913pre-scanned for whitespace, and the extractor function (operator&gt;&gt;())
4914was not catching exceptions in this situation.
4915</p>
4916<p>
4917So, I was in a situation where setting 'noskipws' would change the
4918istream's behavior even though no characters (whitespace or not) could
4919ever be successfully read.
4920</p>
4921<p>
4922Also, calling .peek() on the istream before calling the extractor()
4923changed the behavior (.peek() had the effect of setting the badbit
4924ahead of time).
4925</p>
4926<p>
4927I found this all to be so inconsistent and inconvenient for me and my
4928code design, that I filed a bugzilla entry for libstdc++.   I was then
4929told that the bug cannot be fixed until issue #309 is resolved by the
4930committee.
4931</p>
4932
4933<p><i>[
49342009-07 Frankfurt
4935]</i></p>
4936
4937
4938<blockquote>
4939<p>
4940Moved to NAD.
4941</p>
4942<p>
4943See the rationale in the issue. Paolo, who requested that the issue be
4944reopened, agreed with the rationale.
4945</p>
4946</blockquote>
4947
4948
4949
4950<p><b>Proposed resolution:</b></p>
4951
4952
4953<p><b>Rationale:</b></p>
4954<p>The LWG agrees there is minor variation between implementations,
4955  but believes that it doesn't matter. This is a rarely used corner
4956  case. There is no evidence that this has any commercial importance
4957  or that it causes actual portability problems for customers trying
4958  to write code that runs on multiple implementations.</p>
4959
4960
4961
4962
4963
4964<hr>
4965<h3><a name="313"></a>313. set_terminate and set_unexpected question</h3>
4966<p><b>Section:</b> 18.8.3.3 [terminate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
4967 <b>Submitter:</b> Judy Ward <b>Opened:</b> 2001-04-03  <b>Last modified:</b> 2006-12-27</p>
4968<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#terminate">issues</a> in [terminate].</p>
4969<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
4970<p><b>Discussion:</b></p>
4971<p>
4972According to section 18.7.3.3 of the standard, std::terminate() is
4973supposed to call the terminate_handler in effect immediately after
4974evaluating the throw expression.
4975</p>
4976
4977<p>
4978Question: what if the terminate_handler in effect is itself
4979std::terminate?
4980</p>
4981
4982<p>For example:</p>
4983
4984<pre>  #include &lt;exception&gt;
4985
4986  int main () {
4987      std::set_terminate(std::terminate);
4988      throw 5;
4989      return 0;
4990  }
4991</pre>
4992
4993<p>
4994Is the implementation allowed to go into an infinite loop?
4995</p>
4996
4997<p>
4998I think the same issue applies to std::set_unexpected.
4999</p>
5000
5001
5002<p><b>Proposed resolution:</b></p>
5003
5004
5005<p><b>Rationale:</b></p>
5006<p>Infinite recursion is to be expected: users who set the terminate
5007handler to <tt>terminate</tt> are explicitly asking for <tt>terminate</tt>
5008to call itself.</p>
5009
5010
5011
5012
5013
5014<hr>
5015<h3><a name="314"></a>314. Is the stack unwound when terminate() is called?</h3>
5016<p><b>Section:</b> 18.8.3.3 [terminate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5017 <b>Submitter:</b> Detlef Vollmann <b>Opened:</b> 2001-04-11  <b>Last modified:</b> 2007-01-15</p>
5018<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#terminate">issues</a> in [terminate].</p>
5019<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5020<p><b>Discussion:</b></p>
5021
5022<p>
5023The standard appears to contradict itself about whether the stack is
5024unwound when the implementation calls terminate().
5025</p>
5026
5027<p>From 18.7.3.3p2:</p>
5028<blockquote><p>
5029    Calls the terminate_handler function in effect immediately
5030    after evaluating the throw-expression (lib.terminate.handler),
5031    if called by the implementation [...]
5032</p></blockquote>
5033
5034<p>So the stack is guaranteed not to be unwound.</p>
5035
5036<p>But from 15.3p9:</p>
5037<blockquote><p>
5038    [...]whether or not the stack is unwound before this call
5039    to terminate() is implementation-defined (except.terminate).
5040</p></blockquote>
5041
5042<p>
5043And 15.5.1 actually defines that in most cases the stack is unwound.
5044</p>
5045
5046
5047<p><b>Proposed resolution:</b></p>
5048
5049
5050<p><b>Rationale:</b></p>
5051<p>There is definitely no contradiction between the core and library
5052clauses; nothing in the core clauses says that stack unwinding happens
5053after <tt>terminate</tt> is called.  18.7.3.3p2 does not say anything
5054about when terminate() is called; it merely specifies which
5055<tt>terminate_handler</tt> is used.</p>
5056
5057
5058
5059
5060
5061<hr>
5062<h3><a name="323"></a>323. abs() overloads in different headers</h3>
5063<p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5064 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2001-06-04  <b>Last modified:</b> 2008-03-12</p>
5065<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
5066<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5067<p><b>Discussion:</b></p>
5068<p>Currently the standard mandates the following overloads of
5069abs():</p>
5070
5071<pre>    abs(long), abs(int) in &lt;cstdlib&gt;
5072
5073    abs(float), abs(double), abs(long double) in &lt;cmath&gt;
5074
5075    template&lt;class T&gt; T abs(const complex&lt;T&gt;&amp;) in &lt;complex&gt;
5076
5077    template&lt;class T&gt; valarray&lt;T&gt; abs(const valarray&lt;T&gt;&amp;); in &lt;valarray&gt;
5078</pre>
5079
5080<p>
5081The problem is that having only some overloads visible of a function
5082that works on "implicitly inter-convertible" types is dangerous in
5083practice. The headers that get included at any point in a translation
5084unit can change unpredictably during program
5085development/maintenance. The wrong overload might be unintentionally
5086selected.
5087</p>
5088
5089<p>
5090Currently, there is nothing that mandates the simultaneous visibility
5091of these overloads. Indeed, some vendors have begun fastidiously
5092reducing dependencies among their (public) headers as a QOI issue: it
5093helps people to write portable code by refusing to compile unless all
5094the correct headers are #included.
5095</p>
5096
5097<p>The same issue may exist for other functions in the library.</p>
5098
5099<p>Redmond: PJP reports that C99 adds two new kinds of abs: complex,
5100and int_max_abs.</p>
5101
5102<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#343">343</a>.</p>
5103
5104<p><i>[
5105Bellevue:
5106]</i></p>
5107
5108
5109<blockquote>
5110The situation is not sufficiently severe to warrant a change.
5111</blockquote>
5112
5113
5114
5115
5116<p><b>Rationale:</b></p>
5117<p>The programs that could potentially be broken by this situation are
5118  already fragile, and somewhat contrived: For example, a user-defined
5119  class that has conversion overloads both to <tt>long</tt> and
5120  to <tt>float</tt>.  If <tt>x</tt> is a value of such a class, then
5121  <tt>abs(x)</tt> would give the <tt>long</tt> version if the user
5122  included &lt;cstdlib&gt;, the <tt>float</tt> version if the user
5123  included &lt;cmath&gt;, and would be diagnosed as ambiguous at
5124  compile time if the user included both headers.  The LWG couldn't
5125  find an example of a program whose meaning would be changed (as
5126  opposed to changing it from well-formed to ill-formed) simply by
5127  adding another standard header.</p>
5128
5129<p>Since the harm seems minimal, and there don't seem to be any simple
5130  and noninvasive solutions, this is being closed as NAD.  It is
5131  marked as "Future" for two reasons.  First, it might be useful to
5132  define an <tt>&lt;all&gt;</tt> header that would include all
5133  Standard Library headers.  Second, we should at least make sure that
5134  future library extensions don't make this problem worse.</p>
5135
5136
5137
5138
5139
5140<hr>
5141<h3><a name="326"></a>326. Missing typedef in moneypunct_byname</h3>
5142<p><b>Section:</b> 22.4.6.4 [locale.moneypunct.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5143 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-07-05  <b>Last modified:</b> 2006-12-27</p>
5144<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5145<p><b>Discussion:</b></p>
5146<p>The definition of the moneypunct facet contains the typedefs char_type
5147and string_type. Only one of these names, string_type, is defined in
5148the derived facet, moneypunct_byname.</p>
5149
5150
5151<p><b>Proposed resolution:</b></p>
5152<p>For consistency with the numpunct facet, add a typedef for
5153char_type to the definition of the moneypunct_byname facet in
515422.4.6.4 [locale.moneypunct.byname].</p>
5155
5156
5157<p><b>Rationale:</b></p>
5158<p>The absence of the typedef is irrelevant.  Users can still access
5159the typedef, because it is inherited from the base class.</p>
5160
5161
5162
5163
5164
5165<hr>
5166<h3><a name="330"></a>330. Misleading "exposition only" value in class locale definition</h3>
5167<p><b>Section:</b> 22.3.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5168 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-07-15  <b>Last modified:</b> 2006-12-27</p>
5169<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</p>
5170<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5171<p><b>Discussion:</b></p>
5172<p>
5173The "exposition only" value of the std::locale::none constant shown in
5174the definition of class locale is misleading in that it on many
5175systems conflicts with the value assigned to one if the LC_XXX
5176constants (specifically, LC_COLLATE on AIX, LC_ALL on HP-UX, LC_CTYPE
5177on Linux and SunOS). This causes incorrect behavior when such a
5178constant is passed to one of the locale member functions that accept a
5179locale::category argument and interpret it as either the C LC_XXX
5180constant or a bitmap of locale::category values. At least three major
5181implementations adopt the suggested value without a change and
5182consequently suffer from this problem.
5183</p>
5184
5185<p>
5186For instance, the following code will (presumably) incorrectly copy facets
5187belonging to the collate category from the German locale on AIX:
5188</p>
5189
5190<pre>  std::locale l (std::locale ("C"), "de_DE", std::locale::none);
5191</pre>
5192
5193
5194<p><b>Rationale:</b></p>
5195<p>The LWG agrees that it may be difficult to implement locale member
5196functions in such a way that they can take either <tt>category</tt>
5197arguments or the LC_ constants defined in &lt;cctype&gt;.  In light of
5198this requirement (22.3.1.1.1 [locale.category], paragraph 2), and in light
5199of the requirement in the preceding paragraph that it is possible to
5200combine <tt>category</tt> bitmask elements with bitwise operations,
5201defining the <tt>category</tt> elements is delicate,
5202particularly if an implementor is constrained to work with a
5203preexisting C library.  (Just using the existing LC_ constants would
5204not work in general.)  There's no set of "exposition only" values that
5205could give library implementors proper guidance in such a delicate
5206matter.  The non-normative example we're giving is no worse than
5207any other choice would be.</p>
5208
5209<p>See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#347">347</a>.</p>
5210
5211
5212
5213
5214
5215<hr>
5216<h3><a name="332"></a>332. Consider adding increment and decrement operators to std::fpos&lt; T &gt; </h3>
5217<p><b>Section:</b> 27.5.3 [fpos] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5218 <b>Submitter:</b> PremAnand M. Rao <b>Opened:</b> 2001-08-27  <b>Last modified:</b> 2006-12-27</p>
5219<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fpos">issues</a> in [fpos].</p>
5220<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5221<p><b>Discussion:</b></p>
5222<p>
5223Increment and decrement operators are missing from 
5224Table 88 -- Position type requirements in 27.5.3 [fpos].
5225</p>
5226
5227
5228<p><b>Proposed resolution:</b></p>
5229<p>
5230Table 88 (section 27.4.3) -- Position type requirements
5231be updated to include increment and decrement operators.
5232</p>
5233
5234<pre>expression        return type     operational    note
5235
5236++p               fpos&amp;           p += O(1)
5237p++               fpos            { P tmp = p;
5238                                    ++p;
5239                                    return tmp; }
5240--p               fpos&amp;           p -= O(1)
5241p--               fpos            { P tmp = p;
5242                                    --p;
5243                                    return tmp; }
5244</pre>
5245
5246
5247
5248<p><b>Rationale:</b></p>
5249<p>The LWG believes this is a request for extension, not a defect
5250report.  Additionally, nobody saw a clear need for this extension;
5251<tt>fpos</tt> is used only in very limited ways.</p>
5252
5253
5254
5255
5256
5257<hr>
5258<h3><a name="342"></a>342. seek and eofbit</h3>
5259<p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5260 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2001-10-09  <b>Last modified:</b> 2009-07-14</p>
5261<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
5262<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5263<p><b>Discussion:</b></p>
5264<p>I think we have a defect.</p>
5265
5266<p>According to lwg issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a> which is now a dr, the
5267description of seekg in 27.7.1.3 [istream.unformatted] paragraph 38 now looks
5268like:</p>
5269
5270<blockquote><p>
5271Behaves as an unformatted input function (as described in 27.6.1.3, 
5272paragraph 1), except that it does not count the number of characters 
5273extracted and does not affect the value returned by subsequent calls to 
5274gcount(). After constructing a sentry object, if fail() != true, 
5275executes rdbuf()-&gt;pubseekpos( pos).
5276</p></blockquote>
5277
5278<p>And according to lwg issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#243">243</a> which is also now a dr,
527927.6.1.3, paragraph 1 looks like:</p>
5280
5281<blockquote><p>
5282Each unformatted input function begins execution by constructing an 
5283object of class sentry with the default argument noskipws (second) 
5284argument true. If the sentry object returns true, when converted to a 
5285value of type bool, the function endeavors to obtain the requested 
5286input.  Otherwise, if the sentry constructor exits by throwing an 
5287exception or if the sentry object returns false, when converted to a 
5288value of type bool, the function returns without attempting to obtain 
5289any input. In either case the number of extracted characters is set to 
52900; unformatted input functions taking a character array of non-zero 
5291size as an argument shall also store a null character (using charT()) 
5292in the first location of the array. If an exception is thrown during 
5293input then ios::badbit is turned on in *this'ss error state. If 
5294(exception()&amp;badbit)!= 0 then the exception is rethrown. It also counts 
5295the number of characters extracted. If no exception has been thrown it 
5296ends by storing the count in a member object and returning the value 
5297specified. In any event the sentry object is destroyed before leaving 
5298the unformatted input function.
5299</p></blockquote>
5300
5301<p>And finally 27.6.1.1.2/5 says this about sentry:</p>
5302
5303<blockquote><p>
5304If, after any preparation is completed, is.good() is true, ok_ != false 
5305otherwise, ok_ == false.
5306</p></blockquote>
5307
5308<p>
5309So although the seekg paragraph says that the operation proceeds if 
5310!fail(), the behavior of unformatted functions says the operation 
5311proceeds only if good().  The two statements are contradictory when only 
5312eofbit is set.  I don't think the current text is clear which condition 
5313should be respected.
5314</p>
5315
5316<p><b>Further discussion from Redmond:</b></p>
5317
5318<p>PJP: It doesn't seem quite right to say that <tt>seekg</tt> is
5319"unformatted". That makes specific claims about sentry that
5320aren't quite appropriate for seeking, which has less fragile failure
5321modes than actual input.  If we do really mean that it's unformatted
5322input, it should behave the same way as other unformatted input.  On
5323the other hand, "principle of least surprise" is that seeking from EOF
5324ought to be OK.</p>
5325
5326<p>
5327Pre-Berlin:  Paolo points out several problems with the proposed resolution in
5328Ready state:
5329</p>
5330
5331<ul>
5332<li>It should apply to both overloads of seekg.</li>
5333<li>tellg has similar issues, except that it should not call clear().</li>
5334<li>The point about clear() seems to apply to seekp().</li>
5335<li>Depending on the outcome of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#419">419</a>
5336if the sentry
5337sets <tt>failbit</tt> when it finds <tt>eofbit</tt> already set, then
5338you can never seek away from the end of stream.</li>
5339</ul>
5340
5341<p><i>[
53422009-07 Frankfurt
5343]</i></p>
5344
5345
5346<blockquote>
5347<p>
5348Moved to NAD. Will reopen if proposed resolution is supplied.
5349</p>
5350</blockquote>
5351
5352
5353
5354<p><b>Proposed resolution:</b></p>
5355
5356<p>Change 27.7.1.3 [istream.unformatted] to:</p>
5357<blockquote><p>
5358Behaves as an unformatted input function (as described in 27.6.1.3,
5359paragraph 1), except that it does not count the number of characters
5360extracted, does not affect the value returned by subsequent calls to
5361gcount(), and does not examine the value returned by the sentry
5362object. After constructing a sentry object, if <tt>fail() !=
5363true</tt>, executes <tt>rdbuf()-&gt;pubseekpos(pos)</tt>.  In
5364case of success, the function calls clear().
5365In case of failure, the function calls <tt>setstate(failbit)</tt>
5366(which may throw <tt>ios_base::failure</tt>).
5367</p></blockquote>
5368
5369<p><i>[Lillehammer: Matt provided wording.]</i></p>
5370
5371
5372
5373
5374<p><b>Rationale:</b></p>
5375<p>In C, fseek does clear EOF.  This is probably what most users would
5376  expect.  We agree that having eofbit set should not deter a seek,
5377  and that a successful seek should clear eofbit. Note
5378  that <tt>fail()</tt> is true only if <tt>failbit</tt>
5379  or <tt>badbit</tt> is set, so using <tt>!fail()</tt>, rather
5380  than <tt>good()</tt>, satisfies this goal.</p>
5381
5382
5383
5384
5385
5386<hr>
5387<h3><a name="343"></a>343. Unspecified library header dependencies</h3>
5388<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5389 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-10-09  <b>Last modified:</b> 2009-07-28</p>
5390<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>
5391<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>
5392<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5393<p><b>Discussion:</b></p>
5394<p>
5395The synopses of the C++ library headers clearly show which names are
5396required to be defined in each header. Since in order to implement the
5397classes and templates defined in these headers declarations of other
5398templates (but not necessarily their definitions) are typically
5399necessary the standard in 17.4.4, p1 permits library implementers to
5400include any headers needed to implement the definitions in each header.
5401</p>
5402
5403<p>
5404For instance, although it is not explicitly specified in the synopsis of
5405&lt;string&gt;, at the point of definition of the std::basic_string template
5406the declaration of the std::allocator template must be in scope. All
5407current implementations simply include &lt;memory&gt; from within &lt;string&gt;,
5408either directly or indirectly, to bring the declaration of
5409std::allocator into scope.
5410</p>
5411
5412<p>
5413Additionally, however, some implementation also include &lt;istream&gt; and
5414&lt;ostream&gt; at the top of &lt;string&gt; to bring the declarations of
5415std::basic_istream and std::basic_ostream into scope (which are needed
5416in order to implement the string inserter and extractor operators
5417(21.3.7.9 [lib.string.io])). Other implementations only include
5418&lt;iosfwd&gt;, since strictly speaking, only the declarations and not the
5419full definitions are necessary.
5420</p>
5421
5422<p>
5423Obviously, it is possible to implement &lt;string&gt; without actually
5424providing the full definitions of all the templates std::basic_string
5425uses (std::allocator, std::basic_istream, and std::basic_ostream).
5426Furthermore, not only is it possible, doing so is likely to have a
5427positive effect on compile-time efficiency.
5428</p>
5429
5430<p>
5431But while it may seem perfectly reasonable to expect a program that uses
5432the std::basic_string insertion and extraction operators to also
5433explicitly include &lt;istream&gt; or &lt;ostream&gt;, respectively, it doesn't seem
5434reasonable to also expect it to explicitly include &lt;memory&gt;. Since
5435what's reasonable and what isn't is highly subjective one would expect
5436the standard to specify what can and what cannot be assumed.
5437Unfortunately, that isn't the case.
5438</p>
5439
5440<p>The examples below demonstrate the issue.</p>
5441
5442<p>Example 1:</p>
5443
5444<p>It is not clear whether the following program is complete:</p>
5445
5446<pre>#include &lt;string&gt;
5447
5448extern std::basic_ostream&lt;char&gt; &amp;strm;
5449
5450int main () {
5451    strm &lt;&lt; std::string ("Hello, World!\n");
5452}
5453</pre>    
5454
5455<p>or whether one must explicitly include &lt;memory&gt; or
5456&lt;ostream&gt; (or both) in addition to &lt;string&gt; in order for
5457the program to compile.</p>
5458
5459
5460<p>Example 2:</p>
5461
5462<p>Similarly, it is unclear whether the following program is complete:</p>
5463
5464<pre>#include &lt;istream&gt;
5465
5466extern std::basic_iostream&lt;char&gt; &amp;strm;
5467
5468int main () {
5469    strm &lt;&lt; "Hello, World!\n";
5470}
5471</pre>
5472
5473<p>
5474or whether one needs to explicitly include &lt;ostream&gt;, and
5475perhaps even other headers containing the definitions of other
5476required templates:</p>
5477
5478<pre>#include &lt;ios&gt;
5479#include &lt;istream&gt;
5480#include &lt;ostream&gt;
5481#include &lt;streambuf&gt;
5482
5483extern std::basic_iostream&lt;char&gt; &amp;strm;
5484
5485int main () {
5486    strm &lt;&lt; "Hello, World!\n";
5487}
5488</pre>
5489
5490<p>Example 3:</p>
5491
5492<p>Likewise, it seems unclear whether the program below is complete:</p>
5493<pre>#include &lt;iterator&gt;
5494
5495bool foo (std::istream_iterator&lt;int&gt; a, std::istream_iterator&lt;int&gt; b)
5496{
5497    return a == b;
5498}
5499
5500int main () { }
5501</pre>
5502
5503<p>or whether one should be required to include &lt;istream&gt;.</p>
5504
5505<p>There are many more examples that demonstrate this lack of a
5506requirement.  I believe that in a good number of cases it would be
5507unreasonable to require that a program explicitly include all the
5508headers necessary for a particular template to be specialized, but I
5509think that there are cases such as some of those above where it would
5510be desirable to allow implementations to include only as much as
5511necessary and not more.</p>
5512
5513<p><i>[
5514post Bellevue:
5515]</i></p>
5516
5517
5518<blockquote>
5519Position taken in prior reviews is that the idea of a table of header
5520dependencies is a good one. Our view is that a full paper is needed to
5521do justice to this, and we've made that recommendation to the issue
5522author.
5523</blockquote>
5524
5525<p><i>[
55262009-07 Frankfurt
5527]</i></p>
5528
5529
5530<blockquote>
5531NAD. Handled by LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1178">1178</a>.
5532</blockquote>
5533
5534
5535
5536<p><b>Proposed resolution:</b></p>
5537<p>
5538For every C++ library header, supply a minimum set of other C++ library
5539headers that are required to be included by that header. The proposed
5540list is below (C++ headers for C Library Facilities, table 12 in
554117.4.1.2, p3, are omitted):
5542</p>
5543
5544<pre>+------------+--------------------+
5545| C++ header |required to include |
5546+============+====================+
5547|&lt;algorithm&gt; |                    |
5548+------------+--------------------+
5549|&lt;bitset&gt;    |                    |
5550+------------+--------------------+
5551|&lt;complex&gt;   |                    |
5552+------------+--------------------+
5553|&lt;deque&gt;     |&lt;memory&gt;            |
5554+------------+--------------------+
5555|&lt;exception&gt; |                    |
5556+------------+--------------------+
5557|&lt;fstream&gt;   |&lt;ios&gt;               |
5558+------------+--------------------+
5559|&lt;functional&gt;|                    |
5560+------------+--------------------+
5561|&lt;iomanip&gt;   |&lt;ios&gt;               |
5562+------------+--------------------+
5563|&lt;ios&gt;       |&lt;streambuf&gt;         |
5564+------------+--------------------+
5565|&lt;iosfwd&gt;    |                    |
5566+------------+--------------------+
5567|&lt;iostream&gt;  |&lt;istream&gt;, &lt;ostream&gt;|
5568+------------+--------------------+
5569|&lt;istream&gt;   |&lt;ios&gt;               |
5570+------------+--------------------+
5571|&lt;iterator&gt;  |                    |
5572+------------+--------------------+
5573|&lt;limits&gt;    |                    |
5574+------------+--------------------+
5575|&lt;list&gt;      |&lt;memory&gt;            |
5576+------------+--------------------+
5577|&lt;locale&gt;    |                    |
5578+------------+--------------------+
5579|&lt;map&gt;       |&lt;memory&gt;            |
5580+------------+--------------------+
5581|&lt;memory&gt;    |                    |
5582+------------+--------------------+
5583|&lt;new&gt;       |&lt;exception&gt;         |
5584+------------+--------------------+
5585|&lt;numeric&gt;   |                    |
5586+------------+--------------------+
5587|&lt;ostream&gt;   |&lt;ios&gt;               |
5588+------------+--------------------+
5589|&lt;queue&gt;     |&lt;deque&gt;             |
5590+------------+--------------------+
5591|&lt;set&gt;       |&lt;memory&gt;            |
5592+------------+--------------------+
5593|&lt;sstream&gt;   |&lt;ios&gt;, &lt;string&gt;     |
5594+------------+--------------------+
5595|&lt;stack&gt;     |&lt;deque&gt;             |
5596+------------+--------------------+
5597|&lt;stdexcept&gt; |                    |
5598+------------+--------------------+
5599|&lt;streambuf&gt; |&lt;ios&gt;               |
5600+------------+--------------------+
5601|&lt;string&gt;    |&lt;memory&gt;            |
5602+------------+--------------------+
5603|&lt;strstream&gt; |                    |
5604+------------+--------------------+
5605|&lt;typeinfo&gt;  |&lt;exception&gt;         |
5606+------------+--------------------+
5607|&lt;utility&gt;   |                    |
5608+------------+--------------------+
5609|&lt;valarray&gt;  |                    |
5610+------------+--------------------+
5611|&lt;vector&gt;    |&lt;memory&gt;            |
5612+------------+--------------------+
5613</pre>
5614
5615
5616<p><b>Rationale:</b></p>
5617<p>The portability problem is real.  A program that works correctly on
5618one implementation might fail on another, because of different header
5619dependencies.  This problem was understood before the standard was
5620completed, and it was a conscious design choice.</p>
5621<p>One possible way to deal with this, as a library extension, would
5622be an &lt;all&gt; header.</p>
5623
5624<p>
5625Hinnant:  It's time we dealt with this issue for C++0X.  Reopened.
5626</p>
5627
5628
5629
5630
5631
5632
5633
5634<hr>
5635<h3><a name="344"></a>344. grouping + showbase</h3>
5636<p><b>Section:</b> 22.4.2 [category.numeric] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5637 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2001-10-13  <b>Last modified:</b> 2007-01-15</p>
5638<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5639<p><b>Discussion:</b></p>
5640<p>
5641When both grouping and showbase are active and the basefield is octal, 
5642does the leading 0 participate in the grouping or not?  For example, 
5643should one format as: 0,123,456 or 0123,456?
5644</p>
5645<p>
5646An analogy can be drawn with hexadecimal.  It appears that 0x123,456 is 
5647preferred over 0x,123,456.  However, this analogy is not universally 
5648accepted to apply to the octal base.  The standard is not clear on how 
5649to format (or parse) in this manner.
5650</p>
5651
5652<p><b>Proposed resolution:</b></p>
5653<p>
5654Insert into 22.4.3.1.2 [facet.numpunct.virtuals] paragraph 3, just before the last
5655sentence:
5656</p>
5657<blockquote><p>
5658The leading hexadecimal base specifier "0x" does not participate in 
5659grouping.  The leading '0' octal base specifier may participate in 
5660grouping.  It is unspecified if the leading '0' participates in 
5661formatting octal numbers.  In parsing octal numbers, the implementation 
5662is encouraged to accept both the leading '0' participating in the 
5663grouping, and not participating (e.g. 0123,456 or 0,123,456).
5664</p></blockquote>
5665
5666<p><b>Rationale:</b></p>
5667<p>
5668The current behavior may be unspecified, but it's not clear that it
5669matters.  This is an obscure corner case, since grouping is usually
5670intended for the benefit of humans and oct/hex prefixes are usually
5671intended for the benefit of machines.  There is not a strong enough
5672consensus in the LWG for action.
5673</p>
5674
5675
5676
5677
5678<hr>
5679<h3><a name="348"></a>348. Minor issue with std::pair operator&lt;</h3>
5680<p><b>Section:</b> 20.3.4 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
5681 <b>Submitter:</b> Andy Sawyer <b>Opened:</b> 2001-10-23  <b>Last modified:</b> 2008-01-05</p>
5682<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>
5683<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>
5684<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
5685<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a></p>
5686<p><b>Discussion:</b></p>
5687
5688
5689<p>
5690The current wording of 20.2.2 [lib.pairs] p6 precludes the use of
5691operator&lt; on any pair type which contains a pointer.
5692</p>
5693
5694
5695<p><b>Proposed resolution:</b></p>
5696<p>In 20.3.4 [pairs] paragraph 6, replace:</p>
5697<pre>    Returns: x.first &lt; y.first || (!(y.first &lt; x.first) &amp;&amp; x.second &lt;
5698        y.second).
5699</pre>
5700<p>With:</p>
5701<pre>    Returns: std::less&lt;T1&gt;()( x.first, y.first ) ||
5702             (!std::less&lt;T1&gt;()( y.first, x.first) &amp;&amp; 
5703             std::less&lt;T2&gt;()( x.second, y.second ) )
5704</pre>
5705
5706
5707
5708<p><b>Rationale:</b></p>
5709<p>This is an instance of a much more general problem.  If we want
5710  operator&lt; to translate to std::less for pairs of pointers, where
5711  do we draw the line?  The same issue applies to individual
5712  pointers, smart pointer wrappers, std::vector&lt;T*&gt;, and so
5713  on.</p>
5714
5715<p>Andy Koenig suggests that the real issue here is that we aren't
5716  distinguishing adequately between two different orderings, a
5717  "useful ordering" and a "canonical ordering" that's used just
5718  because we sometimes need <i>some</i> ordering without caring much
5719  which ordering it is.  Another example of the later is typeinfo's
5720  <tt>before</tt>.</p>
5721
5722
5723
5724
5725
5726
5727<hr>
5728<h3><a name="350"></a>350. allocator&lt;&gt;::address</h3>
5729<p><b>Section:</b> 20.8.8.1 [allocator.members], 20.2.2 [allocator.requirements], 17.6.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
5730 <b>Submitter:</b> Nathan Myers <b>Opened:</b> 2001-10-25  <b>Last modified:</b> 2007-10-11</p>
5731<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
5732<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
5733<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a></p>
5734<p><b>Discussion:</b></p>
5735<p>See c++std-lib-9006 and c++std-lib-9007.  This issue is taken
5736verbatim from -9007.</p>
5737
5738<p>
5739The core language feature allowing definition of operator&amp;() applied 
5740to any non-builtin type makes that operator often unsafe to use in 
5741implementing libraries, including the Standard Library.  The result
5742is that many library facilities fail for legal user code, such as
5743the fragment</p>
5744<pre>  class A { private: A* operator&amp;(); };
5745  std::vector&lt;A&gt; aa;
5746
5747  class B { };
5748  B* operator&amp;(B&amp;) { return 0; }
5749  std::vector&lt;B&gt; ba;
5750</pre>
5751
5752<p>
5753In particular, the requirements table for Allocator (Table 32) specifies
5754no semantics at all for member address(), and allocator&lt;&gt;::address is 
5755defined in terms of unadorned operator &amp;.
5756</p>
5757
5758
5759
5760<p><b>Proposed resolution:</b></p>
5761<p>
5762In 20.6.1.1, Change the definition of allocator&lt;&gt;::address from:</p>
5763<blockquote><p>
5764  Returns: &amp;x
5765</p></blockquote>
5766
5767<p>to:</p>
5768
5769<p>
5770  Returns: The value that the built in operator&amp;(x) would return if not 
5771  overloaded.
5772</p>
5773
5774<p>
5775In 20.1.6, Table 32, add to the Notes column of the a.address(r) and
5776a.address(s) lines, respectively: 
5777</p>
5778
5779<pre>  allocator&lt;T&gt;::address(r)
5780  allocator&lt;T&gt;::address(s)
5781</pre> 
5782
5783<p>In addition, in clause 17.4.1.1, add a statement:</p>
5784
5785<blockquote><p>
5786 The Standard Library does not apply operator&amp; to any type for which
5787 operator&amp; may be overloaded.
5788</p></blockquote> 
5789
5790
5791
5792<p><b>Rationale:</b></p>
5793<p>The LWG believes both examples are ill-formed.  The contained type
5794is required to be CopyConstructible (20.2.1 [utility.arg.requirements]), and that
5795includes the requirement that &amp;t return the usual types and
5796values. Since allocators are intended to be used in conjunction with
5797containers, and since the CopyConstructible requirements appear to
5798have been written to deal with the concerns of this issue, the LWG
5799feels it is NAD unless someone can come up with a well-formed example
5800exhibiting a problem.</p>
5801
5802<p>It may well be that the CopyConstructible requirements are too
5803  restrictive and that either the container requirements or the
5804  CopyConstructive requirements should be relaxed, but that's a far
5805  larger issue.  Marking this issue as "future" as a pointer to that
5806  larger issue.</p>
5807
5808
5809
5810
5811
5812<hr>
5813<h3><a name="351"></a>351. unary_negate and binary_negate: struct or class?</h3>
5814<p><b>Section:</b> 20.7 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
5815 <b>Submitter:</b> Dale Riley <b>Opened:</b> 2001-11-12  <b>Last modified:</b> 2007-04-24</p>
5816<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p>
5817<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
5818<p><b>Discussion:</b></p>
5819<p>
5820In 20.7 [function.objects] the header &lt;functional&gt; synopsis declares
5821the unary_negate and binary_negate function objects as struct.
5822However in 20.7.10 [negators] the unary_negate and binary_negate
5823function objects are defined as class.  Given the context, they are
5824not "basic function objects" like negate, so this is either a typo or
5825an editorial oversight.
5826</p>
5827
5828<p><i>[Taken from comp.std.c++]</i></p>
5829
5830
5831
5832<p><b>Proposed resolution:</b></p>
5833<p>Change the synopsis to reflect the useage in 20.7.10 [negators]</p>
5834
5835<p><i>[Cura�ao: Since the language permits "struct", the LWG
5836views this as NAD. They suggest, however, that the Project Editor
5837might wish to make the change as editorial.]</i></p>
5838
5839
5840
5841
5842
5843
5844
5845<hr>
5846<h3><a name="353"></a>353. <tt>std::pair</tt> missing template assignment</h3>
5847<p><b>Section:</b> 20.3.4 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
5848 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2001-12-02  <b>Last modified:</b> 2008-01-05</p>
5849<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>
5850<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>
5851<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
5852<p><b>Discussion:</b></p>
5853<p>
5854The class template <tt>std::pair</tt> defines a template ctor (20.2.2, p4) but
5855no template assignment operator. This may lead to inefficient code since
5856assigning an object of <tt>pair&lt;C, D&gt;</tt> to <tt>pair&lt;A, B&gt;</tt>
5857where the types <tt>C</tt> and <tt>D</tt> are distinct from but convertible to
5858<tt>A</tt> and <tt>B</tt>, respectively, results in a call to the template copy
5859ctor to construct an unnamed temporary of type <tt>pair&lt;A, B&gt;</tt>
5860followed by an ordinary (perhaps implicitly defined) assignment operator,
5861instead of just a straight assignment.
5862</p>
5863
5864
5865<p><b>Proposed resolution:</b></p>
5866<p>
5867Add the following declaration to the definition of <tt>std::pair</tt>:
5868</p>
5869<pre>    template&lt;class U, class V&gt;
5870    pair&amp; operator=(const pair&lt;U, V&gt; &amp;p);
5871</pre>
5872<p>
5873And also add a paragraph describing the effects of the function template to the
5874end of 20.2.2:
5875</p>
5876<pre>    template&lt;class U, class V&gt;
5877    pair&amp; operator=(const pair&lt;U, V&gt; &amp;p);
5878</pre>
5879<p>
5880    <b>Effects</b>: <tt>first = p.first;</tt>
5881                    <tt>second = p.second;</tt>
5882    <b>Returns</b>: <tt>*this</tt>
5883</p>
5884
5885<p><i>[Cura�ao: There is no indication this is was anything other than
5886a design decision, and thus NAD.&nbsp; May be appropriate for a future
5887standard.]</i></p>
5888
5889
5890<p><i>[
5891Pre Bellevue:  It was recognized that this was taken care of by
5892<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a>,
5893and thus moved from NAD Future to NAD Editorial.
5894]</i></p>
5895
5896
5897
5898
5899
5900
5901<hr>
5902<h3><a name="356"></a>356. Meaning of ctype_base::mask enumerators</h3>
5903<p><b>Section:</b> 22.4.1 [category.ctype] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
5904 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2002-01-23  <b>Last modified:</b> 2006-12-27</p>
5905<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#category.ctype">issues</a> in [category.ctype].</p>
5906<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
5907<p><b>Discussion:</b></p>
5908
5909<p>What should the following program print?</p>
5910
5911<pre>  #include &lt;locale&gt;
5912  #include &lt;iostream&gt;
5913
5914  class my_ctype : public std::ctype&lt;char&gt;
5915  {
5916    typedef std::ctype&lt;char&gt; base;
5917  public:
5918    my_ctype(std::size_t refs = 0) : base(my_table, false, refs)
5919    {
5920      std::copy(base::classic_table(), base::classic_table() + base::table_size,
5921                my_table);
5922      my_table[(unsigned char) '_'] = (base::mask) (base::print | base::space);
5923    }
5924  private:
5925    mask my_table[base::table_size];
5926  };
5927
5928  int main()
5929  {
5930    my_ctype ct;
5931    std::cout &lt;&lt; "isspace: " &lt;&lt; ct.is(std::ctype_base::space, '_') &lt;&lt; "    "
5932              &lt;&lt; "isalpha: " &lt;&lt; ct.is(std::ctype_base::alpha, '_') &lt;&lt; std::endl;
5933  }
5934</pre>
5935
5936<p>The goal is to create a facet where '_' is treated as whitespace.</p>
5937
5938<p>On gcc 3.0, this program prints "isspace: 1 isalpha: 0".  On
5939Microsoft C++ it prints "isspace: 1 isalpha: 1".</p>
5940
5941<p>
5942I believe that both implementations are legal, and the standard does not
5943give enough guidance for users to be able to use std::ctype's
5944protected interface portably.</p>
5945
5946<p>
5947The above program assumes that ctype_base::mask enumerators like
5948<tt>space</tt> and <tt>print</tt> are disjoint, and that the way to
5949say that a character is both a space and a printing character is to or
5950those two enumerators together.  This is suggested by the "exposition
5951only" values in 22.4.1 [category.ctype], but it is nowhere specified in
5952normative text.  An alternative interpretation is that the more
5953specific categories subsume the less specific.  The above program
5954gives the results it does on the Microsoft compiler because, on that
5955compiler, <tt>print</tt> has all the bits set for each specific
5956printing character class.
5957</p>
5958
5959<p>From the point of view of std::ctype's public interface, there's no
5960important difference between these two techniques.  From the point of
5961view of the protected interface, there is.  If I'm defining a facet
5962that inherits from std::ctype&lt;char&gt;, I'm the one who defines the
5963value that table()['a'] returns.  I need to know what combination of
5964mask values I should use.  This isn't so very esoteric: it's exactly
5965why std::ctype has a protected interface.  If we care about users
5966being able to write their own ctype facets, we have to give them a
5967portable way to do it.
5968</p>
5969
5970<p>
5971Related reflector messages:
5972lib-9224, lib-9226, lib-9229, lib-9270, lib-9272, lib-9273, lib-9274,
5973lib-9277, lib-9279.
5974</p>
5975
5976<p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a> is related, but not identical.  The
5977proposed resolution if issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a> says that
5978ctype_base::mask must be a bitmask type. It does not say that the
5979ctype_base::mask elements are bitmask elements, so it doesn't
5980directly affect this issue.</p>
5981
5982<p>More comments from Benjamin Kosnik, who believes that 
5983that C99 compatibility essentially requires what we're
5984calling option 1 below.</p>
5985
5986<blockquote>
5987<pre>I think the C99 standard is clear, that isspace -&gt; !isalpha.
5988--------
5989
5990#include &lt;locale&gt;
5991#include &lt;iostream&gt;
5992
5993class my_ctype : public std::ctype&lt;char&gt;
5994{
5995private:
5996  typedef std::ctype&lt;char&gt; base;
5997  mask my_table[base::table_size];
5998
5999public:
6000  my_ctype(std::size_t refs = 0) : base(my_table, false, refs)
6001  {
6002    std::copy(base::classic_table(), base::classic_table() + base::table_size,
6003              my_table);
6004    mask both = base::print | base::space;
6005    my_table[static_cast&lt;mask&gt;('_')] = both;
6006  }
6007};
6008
6009int main()
6010{
6011  using namespace std;
6012  my_ctype ct;
6013  cout &lt;&lt; "isspace: " &lt;&lt; ct.is(ctype_base::space, '_') &lt;&lt; endl;
6014  cout &lt;&lt; "isprint: " &lt;&lt; ct.is(ctype_base::print, '_') &lt;&lt; endl;
6015
6016  // ISO C99, isalpha iff upper | lower set, and !space.
6017  // 7.5, p 193
6018  // -&gt; looks like g++ behavior is correct.
6019  // 356 -&gt; bitmask elements are required for ctype_base
6020  // 339 -&gt; bitmask type required for mask
6021  cout &lt;&lt; "isalpha: " &lt;&lt; ct.is(ctype_base::alpha, '_') &lt;&lt; endl;
6022}
6023</pre>
6024</blockquote>
6025
6026
6027
6028<p><b>Proposed resolution:</b></p>
6029<p>Informally, we have three choices:</p> 
6030<ol>
6031<li>Require that the enumerators are disjoint (except for alnum and
6032graph)</li>
6033<li>Require that the enumerators are not disjoint, and specify which
6034of them subsume which others.  (e.g. mandate that lower includes alpha
6035and print)</li>
6036<li>Explicitly leave this unspecified, which the result that the above
6037program is not portable.</li>
6038</ol>
6039
6040<p>Either of the first two options is just as good from the standpoint
6041of portability.  Either one will require some implementations to
6042change.</p>
6043
6044
6045<p><b>Rationale:</b></p>
6046<p>The LWG agrees that this is a real ambiguity, and that both
6047interpretations are conforming under the existing standard. However,
6048there's no evidence that it's causing problems for real users. Users
6049who want to define ctype facets portably can test the ctype_base masks
6050to see which interpretation is being used.</p>
6051
6052
6053
6054
6055
6056<hr>
6057<h3><a name="357"></a>357. &lt;cmath&gt; float functions cannot return HUGE_VAL</h3>
6058<p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
6059 <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2002-02-26  <b>Last modified:</b> 2007-04-24</p>
6060<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
6061<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
6062<p><b>Discussion:</b></p>
6063<p>
6064The float versions of the math functions have no meaningful value to return 
6065for a range error. The long double versions have a value they can return, 
6066but it isn't necessarily the most reasonable value.
6067</p>
6068
6069<p>
6070Section 26.5 [lib.c.math], paragraph 5, says that C++ "adds float and long 
6071double overloaded versions of these functions, with the same semantics," 
6072referring to the math functions from the C90 standard.
6073</p>
6074
6075<p>
6076The C90 standard, in section 7.5.1, paragraph 3, says that functions return 
6077"the value of the macro HUGE_VAL" when they encounter a range error. 
6078Section 7.5, paragraph 2, defines HUGE_VAL as a macro that "expands to a 
6079positive double expression, not necessarily representable as a float."
6080</p>
6081
6082<p>
6083Therefore, the float versions of the math functions have no way to
6084signal a range error. <i>[Cura�ao: The LWG notes that this isn't
6085strictly correct, since errno is set.]</i> The semantics require that they
6086return HUGE_VAL, but they cannot because HUGE_VAL might not be
6087representable as a float.
6088</p>
6089
6090<p>
6091The problem with long double functions is less severe because HUGE_VAL is 
6092representable as a long double. On the other hand, it might not be a "huge" 
6093long double value, and might fall well within the range of normal return 
6094values for a long double function. Therefore, it does not make sense for a 
6095long double function to return a double (HUGE_VAL) for a range error.
6096</p>
6097
6098
6099<p><b>Proposed resolution:</b></p>
6100<p>Cura�ao: C99 was faced with a similar problem, which they fixed by
6101adding HUGE_VALF and HUGE_VALL in addition to HUGE_VAL.</p>
6102
6103<p>C++ must also fix, but it should be done in the context of the
6104general C99 based changes to C++, not via DR. Thus the LWG in Cura�ao
6105felt the resolution should be NAD, FUTURE, but the issue is being held
6106open for one more meeting to ensure LWG members not present during the
6107discussion concur.</p>
6108
6109
6110<p><b>Rationale:</b></p>
6111<p>Will be fixed as part of more general work in the TR.</p>
6112
6113
6114
6115
6116
6117<hr>
6118<h3><a name="361"></a>361. num_get&lt;&gt;::do_get (..., void*&amp;) checks grouping</h3>
6119<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#NAD">NAD</a>
6120 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-03-12  <b>Last modified:</b> 2007-01-15</p>
6121<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>
6122<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>
6123<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6124<p><b>Discussion:</b></p>
6125<p>
612622.2.2.2.2, p12 specifies that <tt>thousands_sep</tt> is to be inserted only
6127for integral types (issue 282 suggests that this should be done for
6128all arithmetic types).
6129</p>
6130
6131<p>
613222.2.2.1.2, p12 requires that grouping be checked for all extractors
6133including that for <tt>void*</tt>.
6134</p>
6135
6136<p>
6137I don't think that's right. <tt>void*</tt> values should not be checked for
6138grouping, should they? (Although if they should, then <tt>num_put</tt> needs
6139to write them out, otherwise their extraction will fail.)
6140</p>
6141
6142
6143<p><b>Proposed resolution:</b></p>
6144<p>
6145Change the first sentence of 22.2.2.2.2, p12 from
6146</p>
6147<blockquote><p>
6148    Digit grouping is checked. That is, the positions of discarded
6149    separators is examined for consistency with
6150    use_facet&lt;numpunct&lt;charT&gt; &gt;(loc).grouping().
6151    If they are not consistent then ios_base::failbit is assigned
6152    to err.
6153</p></blockquote>
6154
6155<p>to</p>
6156<blockquote><p>
6157    Except for conversions to void*, digit grouping is checked...
6158</p></blockquote>
6159
6160
6161
6162<p><b>Rationale:</b></p>
6163<p>This would be a change: as it stands, the standard clearly
6164  specifies that grouping applies to void*.  A survey of existing
6165  practice shows that most existing implementations do that, as they
6166  should.</p>
6167
6168
6169
6170
6171
6172<hr>
6173<h3><a name="366"></a>366. Excessive const-qualification</h3>
6174<p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6175 <b>Submitter:</b> Walter Brown, Marc Paterno <b>Opened:</b> 2002-05-10  <b>Last modified:</b> 2006-12-27</p>
6176<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</p>
6177<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6178<p><b>Discussion:</b></p>
6179<p>
6180The following member functions are declared const, yet return non-const
6181pointers. We believe they are should be changed, because they allow code
6182that may surprise the user. See document N1360 for details and
6183rationale.
6184</p>
6185
6186<p><i>[Santa Cruz: the real issue is that we've got const member
6187functions that return pointers to non-const, and N1360 proposes
6188replacing them by overloaded pairs.  There isn't a consensus about
6189whether this is a real issue, since we've never said what our
6190constness policy is for iostreams.  N1360 relies on a distinction
6191between physical constness and logical constness; that distinction, or
6192those terms, does not appear in the standard.]</i></p>
6193
6194
6195
6196
6197<p><b>Proposed resolution:</b></p>
6198<p>In 27.4.4 and 27.4.4.2</p>
6199<p>Replace</p>
6200<pre>  basic_ostream&lt;charT,traits&gt;* tie() const;
6201</pre>
6202<p>with</p>
6203<pre>  basic_ostream&lt;charT,traits&gt;* tie();
6204  const basic_ostream&lt;charT,traits&gt;* tie() const;
6205</pre>
6206
6207<p>and replace</p>
6208<pre>  basic_streambuf&lt;charT,traits&gt;* rdbuf() const;
6209</pre>
6210<p>with</p>
6211<pre>  basic_streambuf&lt;charT,traits&gt;* rdbuf();
6212  const basic_streambuf&lt;charT,traits&gt;* rdbuf() const;
6213</pre>
6214
6215<p>In 27.5.2 and 27.5.2.3.1</p>
6216<p>Replace</p>
6217<pre>  char_type* eback() const;
6218</pre>
6219<p>with</p>
6220<pre>  char_type* eback();
6221  const char_type* eback() const;
6222</pre>
6223
6224<p>Replace</p>
6225<pre>  char_type gptr() const;
6226</pre>
6227<p>with</p>
6228<pre>  char_type* gptr();
6229  const char_type* gptr() const;
6230</pre>
6231
6232<p>Replace</p>
6233<pre>  char_type* egptr() const;
6234</pre>
6235<p>with</p>
6236<pre>  char_type* egptr();
6237  const char_type* egptr() const;
6238</pre>
6239
6240<p>In 27.5.2 and 27.5.2.3.2</p>
6241<p>Replace</p>
6242<pre>  char_type* pbase() const;
6243</pre>
6244<p>with</p>
6245<pre>  char_type* pbase();
6246  const char_type* pbase() const;
6247</pre>
6248
6249<p>Replace</p>
6250<pre>  char_type* pptr() const;
6251</pre>
6252<p>with</p>
6253<pre>  char_type* pptr();
6254  const char_type* pptr() const;
6255</pre>
6256
6257<p>Replace</p>
6258<pre>  char_type* epptr() const;
6259</pre>
6260<p>with</p>
6261<pre>  char_type* epptr();
6262  const char_type* epptr() const;
6263</pre>
6264
6265<p>In 27.7.2, 27.7.2.2, 27.7.3 27.7.3.2, 27.7.4, and 27.7.6</p>
6266<p>Replace</p>
6267<pre>  basic_stringbuf&lt;charT,traits,Allocator&gt;* rdbuf() const;
6268</pre>
6269<p>with</p>
6270<pre>  basic_stringbuf&lt;charT,traits,Allocator&gt;* rdbuf();
6271  const basic_stringbuf&lt;charT,traits,Allocator&gt;* rdbuf() const;
6272</pre>
6273
6274<p>In  27.8.1.5, 27.8.1.7, 27.8.1.8, 27.8.1.10, 27.8.1.11, and 27.8.1.13</p>
6275<p>Replace</p>
6276<pre>  basic_filebuf&lt;charT,traits&gt;* rdbuf() const;
6277</pre>
6278<p>with</p>
6279<pre>  basic_filebuf&lt;charT,traits&gt;* rdbuf();
6280  const basic_filebuf&lt;charT,traits&gt;* rdbuf() const;
6281</pre>
6282
6283
6284<p><b>Rationale:</b></p>
6285<p>The existing specification is a bit sloppy, but there's no
6286  particular reason to change this other than tidiness, and there are
6287  a number of ways in which streams might have been designed
6288  differently if we were starting today.  There's no evidence that the
6289  existing constness policy is harming users.  We might consider
6290  a different constness policy as part of a full stream redesign.</p>
6291
6292
6293
6294
6295
6296<hr>
6297<h3><a name="367"></a>367. remove_copy/remove_copy_if and Input Iterators</h3>
6298<p><b>Section:</b> 25.3.8 [alg.remove] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6299 <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2002-05-13  <b>Last modified:</b> 2006-12-27</p>
6300<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.remove">issues</a> in [alg.remove].</p>
6301<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6302<p><b>Discussion:</b></p>
6303<p>
6304remove_copy and remove_copy_if (25.3.8 [alg.remove]) permit their
6305input range to be marked with Input Iterators. However, since two
6306operations are required against the elements to copy (comparison and
6307assigment), when the input range uses Input Iterators, a temporary
6308copy must be taken to avoid dereferencing the iterator twice. This
6309therefore requires the value type of the InputIterator to be
6310CopyConstructible. If the iterators are at least Forward Iterators,
6311then the iterator can be dereferenced twice, or a reference to the
6312result maintained, so the temporary is not required.
6313</p>
6314
6315
6316<p><b>Proposed resolution:</b></p>
6317<p>
6318Add "If InputIterator does not meet the requirements of forward
6319iterator, then the value type of InputIterator must be copy
6320constructible. Otherwise copy constructible is not required." to
632125.3.8 [alg.remove] paragraph 6.
6322</p>
6323
6324
6325<p><b>Rationale:</b></p>
6326<p>The assumption is that an input iterator can't be dereferenced
6327  twice.  There's no basis for that assumption in the Standard.</p>
6328
6329
6330
6331
6332
6333<hr>
6334<h3><a name="368"></a>368. basic_string::replace has two "Throws" paragraphs</h3>
6335<p><b>Section:</b> 21.4.6.6 [string::replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
6336 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2002-06-03  <b>Last modified:</b> 2007-04-24</p>
6337<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
6338<p><b>Discussion:</b></p>
6339<p>
634021.4.6.6 [string::replace] basic_string::replace, second
6341signature, given in paragraph 1, has two "Throws" paragraphs (3 and
63425).
6343</p>
6344
6345<p>
6346In addition, the second "Throws" paragraph (5) includes specification
6347(beginning with "Otherwise, the function replaces ...") that should be
6348part of the "Effects" paragraph.
6349</p>
6350
6351
6352<p><b>Proposed resolution:</b></p>
6353
6354
6355<p><b>Rationale:</b></p>
6356<p>This is editorial. Both "throws" statements are true. The bug is
6357  just that the second one should be a sentence, part of the "Effects"
6358  clause, not a separate "Throws".  The project editor has been
6359  notified.</p>
6360
6361
6362
6363
6364
6365<hr>
6366<h3><a name="372"></a>372. Inconsistent description of stdlib exceptions</h3>
6367<p><b>Section:</b> 17.6.4.11 [res.on.exception.handling], 18.7.1 [type.info] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6368 <b>Submitter:</b> Randy Maddox <b>Opened:</b> 2002-07-22  <b>Last modified:</b> 2006-12-27</p>
6369<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.exception.handling">issues</a> in [res.on.exception.handling].</p>
6370<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6371<p><b>Discussion:</b></p>
6372
6373<p>Paragraph 3 under clause 17.6.4.11 [res.on.exception.handling], Restrictions on
6374Exception Handling, states that "Any other functions defined in the
6375C++ Standard Library that do not have an exception-specification may
6376throw implementation-defined exceptions unless otherwise specified."
6377This statement is followed by a reference to footnote 178 at the
6378bottom of that page which states, apparently in reference to the C++
6379Standard Library, that "Library implementations are encouraged (but
6380not required) to report errors by throwing exceptions from (or derived
6381from) the standard exceptions."</p>
6382
6383<p>These statements appear to be in direct contradiction to clause
638418.7.1 [type.info], which states "The class exception defines the
6385base class for the types of objects thrown as exceptions by the C++
6386Standard library components ...".</p>
6387
6388<p>Is this inconsistent?</p>
6389
6390
6391
6392<p><b>Proposed resolution:</b></p>
6393
6394
6395<p><b>Rationale:</b></p>
6396<p>Clause 17 is setting the overall library requirements, and it's
6397  clear and consistent.  This sentence from Clause 18 is descriptive,
6398  not setting a requirement on any other class.
6399</p>
6400
6401
6402
6403
6404
6405<hr>
6406<h3><a name="374"></a>374. moneypunct::frac_digits returns int not unsigned</h3>
6407<p><b>Section:</b> 22.4.6.3.1 [locale.moneypunct.members], 22.4.6.3.2 [locale.moneypunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6408 <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2002-08-08  <b>Last modified:</b> 2006-12-27</p>
6409<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6410<p><b>Discussion:</b></p>
6411<p>
6412In section 22.4.6.3.1 [locale.moneypunct.members], frac_digits() returns type
6413"int". This implies that frac_digits() might return a negative value,
6414but a negative value is nonsensical. It should return "unsigned".
6415</p>
6416
6417<p>
6418Similarly, in section 22.4.6.3.2 [locale.moneypunct.virtuals], do_frac_digits()
6419should return "unsigned".
6420</p>
6421
6422
6423
6424<p><b>Proposed resolution:</b></p>
6425
6426
6427<p><b>Rationale:</b></p>
6428<p>Regardless of whether the return value is int or unsigned, it's
6429always conceivable that frac_digits might return a nonsensical
6430value. (Is 4294967295 really any better than -1?)  The clients of
6431moneypunct, the get and put facets, can and do perform range
6432checks.</p>
6433
6434
6435
6436
6437
6438<hr>
6439<h3><a name="377"></a>377. basic_string::insert and length_error</h3>
6440<p><b>Section:</b> 21.4.6.4 [string::insert] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6441 <b>Submitter:</b> Ray Lischner <b>Opened:</b> 2002-08-16  <b>Last modified:</b> 2006-12-27</p>
6442<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::insert">issues</a> in [string::insert].</p>
6443<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6444<p><b>Discussion:</b></p>
6445<p>
6446Section 21.4.6.4 [string::insert], paragraph 4, contains the following,
6447"Then throws length_error if size() &gt;= npos - rlen."
6448</p>
6449
6450<p>
6451Related to DR 83, this sentence should probably be removed.
6452</p>
6453
6454
6455<p><b>Proposed resolution:</b></p>
6456
6457
6458<p><b>Rationale:</b></p><p>This requirement is redundant but correct.  No change is
6459needed.</p>
6460
6461
6462
6463
6464<hr>
6465<h3><a name="378"></a>378. locale immutability and locale::operator=()</h3>
6466<p><b>Section:</b> 22.3.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
6467 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-09-06  <b>Last modified:</b> 2006-12-30</p>
6468<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</p>
6469<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
6470<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a></p>
6471<p><b>Discussion:</b></p>
6472<p>
6473I think there is a problem with 22.1.1, p6 which says that
6474</p>
6475<pre>    -6- An instance of locale is immutable; once a facet reference
6476        is obtained from it, that reference remains usable as long
6477        as the locale value itself exists.
6478</pre>
6479<p>
6480and 22.1.1.2, p4:
6481</p>
6482<pre>    const locale&amp; operator=(const locale&amp; other) throw();
6483
6484    -4- Effects: Creates a copy of other, replacing the current value.
6485</pre>
6486<p>
6487How can a reference to a facet obtained from a locale object remain
6488valid after an assignment that clearly must replace all the facets
6489in the locale object? Imagine a program such as this
6490</p>
6491<pre>    std::locale loc ("de_DE");
6492    const std::ctype&lt;char&gt; &amp;r0 = std::use_facet&lt;std::ctype&lt;char&gt; &gt;(loc);
6493    loc = std::locale ("en_US");
6494    const std::ctype&lt;char&gt; &amp;r1 = std::use_facet&lt;std::ctype&lt;char&gt; &gt;(loc);
6495</pre>
6496<p>
6497Is r0 really supposed to be preserved and destroyed only when loc goes
6498out of scope?
6499</p>
6500
6501
6502<p><b>Proposed resolution:</b></p>
6503<p><i>[Summer '04 mid-meeting mailing: Martin and Dietmar believe this
6504  is a duplicate of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a> and recommend that it be
6505  closed.
6506]</i></p>
6507
6508
6509
6510
6511
6512
6513<hr>
6514<h3><a name="382"></a>382. codecvt do_in/out result</h3>
6515<p><b>Section:</b> 22.4.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6516 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-08-30  <b>Last modified:</b> 2009-07-14</p>
6517<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
6518<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6519<p><b>Discussion:</b></p>
6520<p>
6521It seems that the descriptions of codecvt do_in() and do_out() leave
6522sufficient room for interpretation so that two implementations of
6523codecvt may not work correctly with the same filebuf. Specifically,
6524the following seems less than adequately specified:
6525</p>
6526
6527<ol>
6528<li>
6529  the conditions under which the functions terminate
6530</li>
6531<li>
6532  precisely when the functions return ok
6533</li>
6534<li>
6535  precisely when the functions return partial
6536</li>
6537<li>
6538  the full set of conditions when the functions return error
6539</li>
6540</ol>
6541
6542<ol>
6543<li>
6544   22.4.1.4.2 [locale.codecvt.virtuals], p2 says this about the effects of the
6545   function: ...Stops if it encounters a character it cannot
6546   convert...  This assumes that there *is* a character to
6547   convert. What happens when there is a sequence that doesn't form a
6548   valid source character, such as an unassigned or invalid UNICODE
6549   character, or a sequence that cannot possibly form a character
6550   (e.g., the sequence "\xc0\xff" in UTF-8)?
6551</li>
6552<li>
6553   Table 53 says that the function returns codecvt_base::ok
6554   to indicate that the function(s) "completed the conversion."
6555   Suppose that the source sequence is "\xc0\x80" in UTF-8,
6556   with from pointing to '\xc0' and (from_end==from + 1).
6557   It is not clear whether the return value should be ok
6558   or partial (see below).
6559</li>
6560<li>
6561   Table 53 says that the function returns codecvt_base::partial
6562   if "not all source characters converted." With the from pointers
6563   set up the same way as above, it is not clear whether the return
6564   value should be partial or ok (see above).
6565</li>
6566<li>
6567   Table 53, in the row describing the meaning of error mistakenly
6568   refers to a "from_type" character, without the symbol from_type
6569   having been defined. Most likely, the word "source" character
6570   is intended, although that is not sufficient. The functions
6571   may also fail when they encounter an invalid source sequence
6572   that cannot possibly form a valid source character (e.g., as
6573   explained in bullet 1 above).
6574</li>
6575</ol>
6576<p>
6577Finally, the conditions described at the end of 22.4.1.4.2 [locale.codecvt.virtuals], p4 don't seem to be possible:
6578</p>
6579<blockquote><p>
6580    "A return value of partial, if (from_next == from_end),
6581    indicates that either the destination sequence has not
6582    absorbed all the available destination elements, or that
6583    additional source elements are needed before another
6584    destination element can be produced."
6585</p></blockquote>
6586<p>
6587If the value is partial, it's not clear to me that (from_next
6588==from_end) could ever hold if there isn't enough room
6589in the destination buffer. In order for (from_next==from_end) to
6590hold, all characters in that range must have been successfully
6591converted (according to 22.4.1.4.2 [locale.codecvt.virtuals], p2) and since there are no
6592further source characters to convert, no more room in the
6593destination buffer can be needed.
6594</p>
6595<p>
6596It's also not clear to me that (from_next==from_end) could ever
6597hold if additional source elements are needed to produce another
6598destination character (not element as incorrectly stated in the
6599text). partial is returned if "not all source characters have
6600been converted" according to Table 53, which also implies that
6601(from_next==from) does NOT hold.
6602</p>
6603<p>
6604Could it be that the intended qualifying condition was actually
6605(from_next != from_end), i.e., that the sentence was supposed
6606to read
6607</p>
6608<blockquote><p>
6609    "A return value of partial, if (from_next != from_end),..."
6610</p></blockquote>
6611<p>
6612which would make perfect sense, since, as far as I understand it,
6613partial can only occur if (from_next != from_end)?
6614</p>
6615<p><i>[Lillehammer: Defer for the moment, but this really needs to be
6616  fixed. Right now, the description of codecvt is too vague for it to
6617  be a useful contract between providers and clients of codecvt
6618  facets.  (Note that both vendors and users can be both providers and
6619  clients of codecvt facets.) The major philosophical issue is whether
6620  the standard should only describe mappings that take a single wide
6621  character to multiple narrow characters (and vice versa), or whether
6622  it should describe fully general N-to-M conversions. When the
6623  original standard was written only the former was contemplated, but
6624  today, in light of the popularity of utf8 and utf16, that doesn't
6625  seem sufficient for C++0x. Bill supports general N-to-M conversions;
6626  we need to make sure Martin and Howard agree.]</i></p>
6627
6628
6629<p><i>[
66302009-07 Frankfurt
6631]</i></p>
6632
6633
6634<blockquote>
6635<p>
6636codecvt is meant to be a 1-to-N to N-to-1 conversion. It does not work
6637well for N-to-M conversions. wbuffer_convert now exists, and handles
6638N-to-M cases. Also, there is a new specialization of codecvt that
6639permits UTF-16 &lt;-&gt; UTF-8 conversions.
6640</p>
6641<p>
6642NAD without prejudice. Will reopen if proposed resolution is supplied.
6643</p>
6644</blockquote>
6645
6646
6647
6648<p><b>Proposed resolution:</b></p>
6649
6650
6651
6652
6653<hr>
6654<h3><a name="385"></a>385. Does call by value imply the CopyConstructible requirement?</h3>
6655<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6656 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2002-10-23  <b>Last modified:</b> 2007-04-18</p>
6657<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>
6658<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>
6659<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6660<p><b>Discussion:</b></p>
6661<p>
6662Many function templates have parameters that are passed by value;
6663a typical example is <tt>find_if</tt>'s <i>pred</i> parameter in
666425.2.5 [alg.find].  Are the corresponding template parameters
6665(<tt>Predicate</tt> in this case) implicitly required to be
6666CopyConstructible, or does that need to be spelled out explicitly?
6667</p>
6668
6669<p>
6670This isn't quite as silly a question as it might seem to be at first
6671sight.  If you call <tt>find_if</tt> in such a way that template
6672argument deduction applies, then of course you'll get call by value
6673and you need to provide a copy constructor.  If you explicitly provide
6674the template arguments, however, you can force call by reference by
6675writing something like <tt>find_if&lt;my_iterator,
6676my_predicate&amp;&gt;</tt>.  The question is whether implementation
6677are required to accept this, or whether this is ill-formed because
6678my_predicate&amp; is not CopyConstructible.
6679</p>
6680
6681<p>
6682The scope of this problem, if it is a problem, is unknown.  Function
6683object arguments to generic algorithms in clauses 25 [algorithms]
6684and 26 [numerics] are obvious examples.  A review of the whole
6685library is necessary.
6686</p>
6687<p><i>[
6688This is really two issues.  First, predicates are typically passed by
6689value but we don't say they must be Copy Constructible.  They should
6690be. Second: is specialization allowed to transform value arguments
6691into references? References aren't copy constructible, so this should
6692not be allowed.
6693]</i></p>
6694
6695<p><i>[
66962007-01-12, Howard: First, despite the note above, references <b>are</b>
6697copy constructible. They just aren't assignable.  Second, this is very
6698closely related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a> and should be consistent with that.
6699That issue already says that implementations are allowed to copy
6700function objects.  If one passes in a reference, it is copyable, but
6701susceptible to slicing if one passes in a reference to a base.  Third,
6702with rvalue reference in the language one only needs to satisfy
6703MoveConstructible to pass an rvalue "by value".  Though the function
6704might still copy the function object internally (requiring
6705CopyConstructible). Finally (and fwiw), if we wanted to, it is easy to
6706code all of the std::algorithms such that they do not copy function
6707objects internally.  One merely passes them by reference internally if
6708desired (this has been fully implemented and shipped for several years).
6709 If this were mandated, it would reverse <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>, allowing
6710function objects to reliably maintain state.  E.g. the example in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a> would reliably remove only the third element.
6711]</i></p>
6712
6713
6714
6715<p><b>Proposed resolution:</b></p>
6716<p>
6717Recommend NAD.
6718</p>
6719
6720
6721<p><b>Rationale:</b></p>
6722<p>
6723Generic algorithms will be marked with concepts and these will imply a requirement
6724of MoveConstructible (not CopyConstructible).  The signature of the function will
6725then precisely describe and enforce the precise requirements.
6726</p>
6727
6728
6729
6730
6731
6732<hr>
6733<h3><a name="388"></a>388. Use of complex as a key in associative containers</h3>
6734<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#NAD">NAD</a>
6735 <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2002-11-08  <b>Last modified:</b> 2008-02-27</p>
6736<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>
6737<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6738<p><b>Discussion:</b></p>
6739<p>
6740Practice with std::complex&lt;&gt; and the associative containers
6741occasionally reveals artificial and distracting issues with constructs
6742resembling: std::set&lt;std::complex&lt;double&gt; &gt; s;
6743</p>
6744
6745<p>
6746The main reason for the above to fail is the absence of an approriate
6747definition for std::less&lt;std::complex&lt;T&gt; &gt;. That in turn comes from
6748the definition of the primary template std::less&lt;&gt; in terms of
6749operator&lt;.
6750</p>
6751
6752<p>
6753The usual argument goes as follows: Since there is no ordering over
6754the complex field compatible with field operations it makes little
6755sense to define a function operator&lt; operating on the datatype
6756std::complex&lt;T&gt;.  That is fine. However, that reasoning does not carry
6757over to std::less&lt;T&gt; which is used, among other things, by associative
6758containers as an ordering useful to meet complexity requirements.
6759</p>
6760
6761<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>.</p>
6762
6763<p><i>[
6764Pre Bellevue: Reopened at the request of Alisdair.
6765]</i></p>
6766
6767
6768<p><i>[
6769Bellevue:
6770]</i></p>
6771
6772
6773<blockquote>
6774This is a request for a design change, and not a defect in the standard.
6775It is in scope to consider, but the group feels that it is not a change
6776that we need to do. Is there a total ordering for floating point values,
6777including NaN? There is not a clear enough solution or big enough
6778problem for us to solve. Solving this problem would require solving the
6779problem for floating point, which is equally unclear. The LWG noted that
6780users who want to put objects into an associative container for which
6781operator&lt; isn't defined can simply provide their own comparison function
6782object. NAD
6783</blockquote>
6784
6785
6786<p><b>Proposed resolution:</b></p>
6787<p>Informally: Add a specialization of std::less for std::complex.</p>
6788
6789
6790<p><b>Rationale:</b></p>
6791<p>Discussed in Santa Cruz.  An overwhelming majority of the LWG
6792believes this should not be treated a DR: it's a request for a design
6793change, not a defect in the existing standard.  Most people (10-3)
6794believed that we probably don't want this change, period: as with
6795issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, it's hard to know where to draw the line.
6796The LWG noted that users who want to put objects into an associative
6797container for which <tt>operator&lt;</tt> isn't defined can simply
6798provide their own comparison function object.</p>
6799
6800
6801
6802
6803
6804<hr>
6805<h3><a name="390"></a>390. CopyConstructible requirements too strict</h3>
6806<p><b>Section:</b> 20.2.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
6807 <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2002-10-24  <b>Last modified:</b> 2008-03-14</p>
6808<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>
6809<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>
6810<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
6811<p><b>Discussion:</b></p>
6812<p>
6813The CopyConstructible requirements in Table 30 state that for an
6814object t of type T (where T is CopyConstructible), the expression &amp;t
6815returns the address of t (with type T*). This requirement is overly
6816strict, in that it disallows types that overload operator&amp; to not
6817return a value of type T*. This occurs, for instance, in the <a href="http://www.boost.org/libs/lambda">Boost.Lambda</a> library, where
6818operator&amp; is overloaded for a Boost.Lambda function object to return
6819another function object.
6820</p>
6821
6822<p>Example:</p>
6823
6824<pre>  std::vector&lt;int&gt; u, v;
6825  int x;
6826  // ...
6827  std::transform(u.begin(), u.end(), std::back_inserter(v), _1 * x);
6828</pre>
6829
6830<p>
6831_1 * x returns an unnamed function object with operator&amp; overloaded to
6832not return T* , therefore rendering the std::transform call ill-formed.
6833However, most standard library implementations will compile this code
6834properly, and the viability of such binder libraries is severely hindered
6835by the unnecessary restriction in the CopyConstructible requirements.
6836</p>
6837
6838<p>
6839For reference, the address of an object can be retrieved without using
6840the address-of operator with the following function template:
6841</p>
6842
6843<pre>  template &lt;typename T&gt; T* addressof(T&amp; v)
6844  {
6845    return reinterpret_cast&lt;T*&gt;(
6846         &amp;const_cast&lt;char&amp;&gt;(reinterpret_cast&lt;const volatile char &amp;&gt;(v)));
6847  }
6848</pre>
6849
6850<p>
6851Note: this relates directly to library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, which
6852will need to be reexamined if the CopyConstructible requirements
6853change.
6854</p>
6855
6856
6857<p><b>Proposed resolution:</b></p>
6858<p>
6859Remove the last two rows of Table 30, eliminating the requirements
6860that &amp;t and &amp;u return the address of t and u, respectively.
6861</p>
6862
6863
6864<p><b>Rationale:</b></p>
6865<p>This was a deliberate design decision.  Perhaps it should be
6866   reconsidered for C++0x. </p>
6867
6868
6869
6870
6871
6872<hr>
6873<h3><a name="392"></a>392. 'equivalence' for input iterators</h3>
6874<p><b>Section:</b> 24.2.1 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
6875 <b>Submitter:</b> Corwin Joy <b>Opened:</b> 2002-12-11  <b>Last modified:</b> 2006-12-27</p>
6876<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>
6877<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
6878<p><b>Discussion:</b></p>
6879
6880<p>
6881In section 24.2.1 [input.iterators] table 72 -
6882'Input Iterator Requirements' we have as a postcondition of *a:
6883"If a==b and (a, b) is in the domain of == then *a is equivalent to *b".
6884</p>
6885
6886<p>
6887In section 24.6.3.5 [istreambuf.iterator::equal] it states that
6888"istreambuf_iterator::equal returns true if and only if both iterators
6889are at end-of-stream, or neither is at end-of-stream, <i>regardless of
6890what streambuf object they use</i>."  (My emphasis).
6891</p>
6892
6893<p>
6894The defect is that either 'equivalent' needs to be more precisely
6895defined or the conditions for equality in 24.6.3.5 [istreambuf.iterator::equal]
6896are incorrect. (Or both).
6897</p>
6898
6899<p>Consider the following example:</p>
6900<pre>   #include &lt;iostream&gt;
6901   #include &lt;fstream&gt;
6902   #include &lt;iterator&gt;
6903   using namespace std;
6904
6905   int main() {
6906    ifstream file1("file1.txt"), file2("file2.txt");
6907    istreambuf_iterator&lt;char&gt; f1(file1), f2(file2);
6908    cout &lt;&lt; "f1 == f2 : " &lt;&lt; boolalpha &lt;&lt; (f1 == f2) &lt;&lt; endl;
6909    cout &lt;&lt; "f1 = " &lt;&lt; *f1 &lt;&lt; endl;
6910    cout &lt;&lt; "f2 = " &lt;&lt; *f2 &lt;&lt; endl;
6911    return 0;
6912   }
6913</pre>
6914
6915<p>Now assuming that neither f1 or f2 are at the end-of-stream then
6916f1 == f2 by 24.6.3.5 [istreambuf.iterator::equal].</p>
6917
6918<p>However, it is unlikely that *f1 will give the same value as *f2 except
6919by accident.</p>
6920
6921<p>So what does *f1 'equivalent' to *f2 mean?  I think the standard should
6922be clearer on this point, or at least be explicit that this does not
6923mean that *f1 and *f2 are required to have the same value in the case
6924of input iterators.</p>
6925
6926
6927<p><b>Proposed resolution:</b></p>
6928
6929
6930<p><b>Rationale:</b></p><p>The two iterators aer not in the domain of ==</p>
6931
6932
6933
6934
6935
6936
6937<hr>
6938<h3><a name="393"></a>393. do_in/do_out operation on state unclear</h3>
6939<p><b>Section:</b> 22.4.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
6940 <b>Submitter:</b> Alberto Barbati <b>Opened:</b> 2002-12-24  <b>Last modified:</b> 2008-07-02</p>
6941<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.virtuals">issues</a> in [locale.codecvt.virtuals].</p>
6942<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
6943<p><b>Discussion:</b></p>
6944<p>
6945this DR follows the discussion on the previous thread "codecvt::do_in
6946not consuming external characters". It's just a clarification issue
6947and not a request for a change.
6948</p>
6949<p>
6950Can do_in()/do_out() produce output characters without consuming input 
6951characters as a result of operation on state?
6952</p>
6953
6954
6955<p><b>Proposed resolution:</b></p>
6956<p>
6957Add a note at the end of 22.4.1.4.2 [locale.codecvt.virtuals], 
6958paragraph 3:
6959</p>
6960
6961<p>
6962[Note: As a result of operations on state, it can return ok or partial 
6963and set from_next == from and to_next != to. --end note]
6964</p>
6965
6966
6967<p><b>Rationale:</b></p>
6968<p>
6969The submitter believes that standard already provides an affirmative
6970answer to the question. However, the current wording has induced a few
6971library implementors to make the incorrect assumption that
6972do_in()/do_out() always consume at least one internal character when
6973they succeed.
6974</p>
6975
6976<p>
6977The submitter also believes that the proposed resolution is not in
6978conflict with the related issue 76. Moreover, by explicitly allowing
6979operations on state to produce characters, a codecvt implementation
6980may effectively implement N-to-M translations without violating the
6981"one character at a time" principle described in such issue. On a side
6982note, the footnote in the proposed resolution of issue 76 that
6983informally rules out N-to-M translations for basic_filebuf should be
6984removed if this issue is accepted as valid.
6985</p>
6986
6987
6988<p><i>[
6989Kona (2007): The proposed resolution is to add a note. Since this is
6990non-normative, the issue is editorial, but we believe that the note is
6991correct. Proposed Disposition: NAD, Editorial
6992]</i></p>
6993
6994
6995
6996
6997
6998
6999<hr>
7000<h3><a name="394"></a>394. behavior of formatted output on failure</h3>
7001<p><b>Section:</b> 27.7.2.6.1 [ostream.formatted.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7002 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2002-12-27  <b>Last modified:</b> 2009-07-14</p>
7003<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7004<p><b>Discussion:</b></p>
7005<p>
7006There is a contradiction in Formatted output about what bit is
7007supposed to be set if the formatting fails. On sentence says it's
7008badbit and another that it's failbit.
7009</p>
7010<p>
701127.6.2.5.1, p1 says in the Common Requirements on Formatted output
7012functions:
7013</p>
7014<pre>     ... If the generation fails, then the formatted output function
7015     does setstate(ios::failbit), which might throw an exception.
7016</pre>
7017<p>
701827.6.2.5.2, p1 goes on to say this about Arithmetic Inserters:
7019</p>
7020<p>
7021     ... The formatting conversion occurs as if it performed the
7022     following code fragment:
7023</p>
7024<pre>     bool failed =
7025         use_facet&lt;num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt;
7026         &gt; &gt;
7027         (getloc()).put(*this, *this, fill(), val). failed();
7028
7029     ... If failed is true then does setstate(badbit) ...
7030</pre>
7031<p>
7032The original intent of the text, according to Jerry Schwarz (see
7033c++std-lib-10500), is captured in the following paragraph:
7034</p>
7035<p>
7036In general "badbit" should mean that the stream is unusable because
7037of some underlying failure, such as disk full or socket closure;
7038"failbit" should mean that the requested formatting wasn't possible
7039because of some inconsistency such as negative widths.  So typically
7040if you clear badbit and try to output something else you'll fail
7041again, but if you clear failbit and try to output something else
7042you'll succeed.
7043</p>
7044<p>
7045In the case of the arithmetic inserters, since num_put cannot
7046report failure by any means other than exceptions (in response
7047to which the stream must set badbit, which prevents the kind of
7048recoverable error reporting mentioned above), the only other
7049detectable failure is if the iterator returned from num_put
7050returns true from failed().
7051</p>
7052<p>
7053Since that can only happen (at least with the required iostream
7054specializations) under such conditions as the underlying failure
7055referred to above (e.g., disk full), setting badbit would seem
7056to be the appropriate response (indeed, it is required in
705727.6.2.5.2, p1). It follows that failbit can never be directly
7058set by the arithmetic (it can only be set by the sentry object
7059under some unspecified conditions).
7060</p>
7061<p>
7062The situation is different for other formatted output functions
7063which can fail as a result of the streambuf functions failing
7064(they may do so by means other than exceptions), and which are
7065then required to set failbit.
7066</p>
7067<p>
7068The contradiction, then, is that ostream::operator&lt;&lt;(int) will
7069set badbit if the disk is full, while operator&lt;&lt;(ostream&amp;,
7070char) will set failbit under the same conditions. To make the behavior
7071consistent, the Common requirements sections for the Formatted output
7072functions should be changed as proposed below.
7073</p>
7074<p><i>[Kona: There's agreement that this is a real issue.  What we
7075  decided at Kona: 1. An error from the buffer (which can be detected
7076  either directly from streambuf's member functions or by examining a
7077  streambuf_iterator) should always result in badbit getting set.
7078  2. There should never be a circumstance where failbit gets set.
7079  That represents a formatting error, and there are no circumstances
7080  under which the output facets are specified as signaling a
7081  formatting error. (Even more so for string output that for numeric
7082  because there's nothing to format.)  If we ever decide to make it
7083  possible for formatting errors to exist then the facets can signal
7084  the error directly, and that should go in clause 22, not clause 27.
7085  3. The phrase "if generation fails" is unclear and should be
7086  eliminated.  It's not clear whether it's intended to mean a buffer
7087  error (e.g. a full disk), a formatting error, or something else.
7088  Most people thought it was supposed to refer to buffer errors; if
7089  so, we should say so.  Martin will provide wording.]</i></p>
7090
7091
7092<p><i>[
70932009-07 Frankfurt
7094]</i></p>
7095
7096
7097<blockquote>
7098NAD. This issue is already fixed.
7099</blockquote>
7100
7101
7102
7103<p><b>Proposed resolution:</b></p>
7104
7105
7106<p><b>Rationale:</b></p>
7107
7108
7109
7110
7111
7112
7113<hr>
7114<h3><a name="398"></a>398. effects of end-of-file on unformatted input functions</h3>
7115<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#NAD">NAD</a>
7116 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-01-05  <b>Last modified:</b> 2009-07-14</p>
7117<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>
7118<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7119<p><b>Discussion:</b></p>
7120    <p>
7121While reviewing unformatted input member functions of istream
7122for their behavior when they encounter end-of-file during input
7123I found that the requirements vary, sometimes unexpectedly, and
7124in more than one case even contradict established practice (GNU
7125libstdc++ 3.2, IBM VAC++ 6.0, STLPort 4.5, SunPro 5.3, HP aCC
71265.38, Rogue Wave libstd 3.1, and Classic Iostreams).
7127    </p>
7128    <p>
7129The following unformatted input member functions set eofbit if they
7130encounter an end-of-file (this is the expected behavior, and also
7131the behavior of all major implementations):
7132    </p>
7133    <pre>    basic_istream&lt;charT, traits&gt;&amp;
7134    get (char_type*, streamsize, char_type);
7135    </pre>
7136    <p>
7137    Also sets failbit if it fails to extract any characters.
7138    </p>
7139    <pre>    basic_istream&lt;charT, traits&gt;&amp;
7140    get (char_type*, streamsize);
7141    </pre>
7142    <p>
7143    Also sets failbit if it fails to extract any characters.
7144    </p>
7145    <pre>    basic_istream&lt;charT, traits&gt;&amp;
7146    getline (char_type*, streamsize, char_type);
7147    </pre>
7148    <p>
7149    Also sets failbit if it fails to extract any characters.
7150    </p>
7151    <pre>    basic_istream&lt;charT, traits&gt;&amp;
7152    getline (char_type*, streamsize);
7153    </pre>
7154    <p>
7155    Also sets failbit if it fails to extract any characters.
7156    </p>
7157    <pre>    basic_istream&lt;charT, traits&gt;&amp;
7158    ignore (int, int_type);
7159    </pre>
7160    <pre>    basic_istream&lt;charT, traits&gt;&amp;
7161    read (char_type*, streamsize);
7162    </pre>
7163    <p>
7164    Also sets failbit if it encounters end-of-file.
7165    </p>
7166    <pre>    streamsize readsome (char_type*, streamsize);
7167    </pre>
7168
7169    <p>
7170The following unformated input member functions set failbit but
7171not eofbit if they encounter an end-of-file (I find this odd
7172since the functions make it impossible to distinguish a general
7173failure from a failure due to end-of-file; the requirement is
7174also in conflict with all major implementation which set both
7175eofbit and failbit):
7176    </p>
7177    <pre>    int_type get();
7178    </pre>
7179    <pre>    basic_istream&lt;charT, traits&gt;&amp;
7180    get (char_type&amp;);
7181    </pre>
7182    <p>
7183These functions only set failbit of they extract no characters,
7184otherwise they don't set any bits, even on failure (I find this
7185inconsistency quite unexpected; the requirement is also in
7186conflict with all major implementations which set eofbit
7187whenever they encounter end-of-file):
7188    </p>
7189    <pre>    basic_istream&lt;charT, traits&gt;&amp;
7190    get (basic_streambuf&lt;charT, traits&gt;&amp;, char_type);
7191    </pre>
7192    <pre>    basic_istream&lt;charT, traits&gt;&amp;
7193    get (basic_streambuf&lt;charT, traits&gt;&amp;);
7194    </pre>
7195    <p>
7196This function sets no bits (all implementations except for
7197STLport and Classic Iostreams set eofbit when they encounter
7198end-of-file):
7199    </p>
7200    <pre>    int_type peek ();
7201    </pre>
7202<p>Informally, what we want is a global statement of intent saying
7203  that eofbit gets set if we trip across EOF, and then we can take
7204  away the specific wording for individual functions.  A full review
7205  is necessary.  The wording currently in the standard is a mishmash,
7206  and changing it on an individual basis wouldn't make things better.
7207  Dietmar will do this work.</p>
7208
7209<p><i>[
72102009-07 Frankfurt
7211]</i></p>
7212
7213
7214<blockquote>
7215Moved to NAD.  See 27.7.1.1 [istream] p3.
7216</blockquote>
7217
7218
7219
7220<p><b>Proposed resolution:</b></p>
7221
7222
7223
7224
7225<hr>
7226<h3><a name="399"></a>399. volations of unformatted input function requirements</h3>
7227<p><b>Section:</b> 27.7.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7228 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-01-05  <b>Last modified:</b> 2006-12-27</p>
7229<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
7230<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7231<p><b>Discussion:</b></p>
7232    <p>
7233The Effects clauses for the two functions below violate the
7234general requirements on unformatted input functions outlined
7235in 27.6.1.3: they do not begin by constructing a sentry object.
7236Instead, they begin by calling widen ('\n'), which may throw
7237an exception. The exception is then allowed to propagate from
7238the unformatted input function irrespective of the setting of
7239exceptions().
7240    </p>
7241    <p>
7242Note that in light of 27.6.1.1, p3 and p4, the fact that the
7243functions allow exceptions thrown from widen() to propagate
7244may not strictly speaking be a defect (but the fact that the
7245functions do not start by constructing a sentry object still
7246is). However, since an exception thrown from ctype&lt;charT&gt;
7247::widen() during any other input operation (say, from within
7248a call to num_get&lt;charT&gt;::get()) will be caught and cause
7249badbit to be set, these two functions should not be treated
7250differently for the sake of consistency.
7251    </p>
7252  
7253
7254<p><b>Proposed resolution:</b></p>
7255
7256
7257<p><b>Rationale:</b></p>
7258<p>
7259Not a defect.  The standard is consistent, and the behavior required
7260by the standard is unambiguous.  Yes, it's theoretically possible for
7261widen to throw.  (Not that this will happen for the default ctype
7262facet or for most real-world replacement ctype facets.)  Users who
7263define ctype facets that can throw, and who care about this behavior,
7264can use alternative signatures that don't call widen.
7265</p>
7266
7267
7268
7269
7270
7271
7272<hr>
7273<h3><a name="417"></a>417. what does ctype::do_widen() return on failure</h3>
7274<p><b>Section:</b> 22.4.1.1.2 [locale.ctype.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7275 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18  <b>Last modified:</b> 2009-07-14</p>
7276<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.virtuals">issues</a> in [locale.ctype.virtuals].</p>
7277<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7278<p><b>Discussion:</b></p>
7279<p>
7280The Effects and Returns clauses of the do_widen() member function of
7281the ctype facet fail to specify the behavior of the function on failure.
7282That the function may not be able to simply cast the narrow character
7283argument to the type of the result since doing so may yield the wrong value
7284for some wchar_t encodings. Popular implementations of ctype&lt;wchar_t&gt; that
7285use mbtowc() and UTF-8 as the native encoding (e.g., GNU glibc) will fail
7286when the argument's MSB is set. There is no way for the the rest of locale
7287and iostream to reliably detect this failure. 
7288</p>
7289<p><i>[Kona: This is a real problem.  Widening can fail.  It's unclear
7290  what the solution should be.  Returning WEOF works for the wchar_t
7291  specialization, but not in general.  One option might be to add a
7292  default, like <i>narrow</i>.  But that's an incompatible change.
7293  Using <i>traits::eof</i> might seem like a good idea, but facets
7294  don't have access to traits (a recurring problem).  We could
7295  have <i>widen</i> throw an exception, but that's a scary option;
7296  existing library components aren't written with the assumption
7297  that <i>widen</i> can throw.]</i></p>
7298
7299
7300<p><i>[
73012009-07 Frankfurt
7302]</i></p>
7303
7304
7305<blockquote>
7306NAD. The behavior is specified for all of the facets that an
7307implementation is required to provide, for the basic character set.
7308</blockquote>
7309
7310
7311
7312<p><b>Proposed resolution:</b></p>
7313
7314
7315
7316
7317<hr>
7318<h3><a name="418"></a>418. exceptions thrown during iostream cleanup</h3>
7319<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#NAD">NAD</a>
7320 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18  <b>Last modified:</b> 2009-07-14</p>
7321<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>
7322<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7323<p><b>Discussion:</b></p>
7324<p>
7325The dtor of the ios_base::Init object is supposed to call flush() on the
73266 standard iostream objects cout, cerr, clog, wcout, wcerr, and wclog.
7327This call may cause an exception to be thrown.
7328</p>
7329
7330<p>
733117.4.4.8, p3 prohibits all library destructors from throwing exceptions.
7332</p>
7333
7334<p>
7335The question is: What should this dtor do if one or more of these calls
7336to flush() ends up throwing an exception? This can happen quite easily
7337if one of the facets installed in the locale imbued in the iostream
7338object throws.
7339</p>
7340<p><i>[Kona: We probably can't do much better than what we've got, so
7341  the LWG is leaning toward NAD.  At the point where the standard
7342  stream objects are being cleaned up, the usual error reporting
7343  mechanism are all unavailable.  And exception from flush at this
7344  point will definitely cause problems.  A quality implementation
7345  might reasonably swallow the exception, or call abort, or do
7346  something even more drastic.]</i></p>
7347
7348
7349<p><i>[
7350See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#397">397</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a> for related issues.
7351]</i></p>
7352
7353
7354<p><i>[
73552009-07 Frankfurt
7356]</i></p>
7357
7358
7359<blockquote>
7360Moved to NAD, no consensus for change.
7361</blockquote>
7362
7363
7364
7365<p><b>Proposed resolution:</b></p>
7366
7367
7368
7369
7370<hr>
7371<h3><a name="421"></a>421. is basic_streambuf copy-constructible?</h3>
7372<p><b>Section:</b> 27.6.2.1 [streambuf.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7373 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18  <b>Last modified:</b> 2009-07-14</p>
7374<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf.cons">issues</a> in [streambuf.cons].</p>
7375<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7376<p><b>Discussion:</b></p>
7377<p>
7378The reflector thread starting with c++std-lib-11346 notes that the class
7379template basic_streambuf, along with basic_stringbuf and basic_filebuf,
7380is copy-constructible but that the semantics of the copy constructors
7381are not defined anywhere. Further, different implementations behave
7382differently in this respect: some prevent copy construction of objects
7383of these types by declaring their copy ctors and assignment operators
7384private, others exhibit undefined behavior, while others still give
7385these operations well-defined semantics.
7386</p>
7387
7388<p>
7389Note that this problem doesn't seem to be isolated to just the three
7390types mentioned above. A number of other types in the library section
7391of the standard provide a compiler-generated copy ctor and assignment
7392operator yet fail to specify their semantics.  It's believed that the
7393only types for which this is actually a problem (i.e. types where the
7394compiler-generated default may be inappropriate and may not have been
7395intended) are locale facets.  See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#439">439</a>.
7396</p>
7397
7398<p><i>[
73992009-07 Frankfurt
7400]</i></p>
7401
7402
7403<blockquote>
7404NAD. Option B is already in the Working Draft.
7405</blockquote>
7406
7407
7408
7409<p><b>Proposed resolution:</b></p>
7410<p>
741127.5.2 [lib.streambuf]:  Add into the synopsis, public section, just above the destructor declaration:
7412</p>
7413
7414<blockquote>
7415<pre>basic_streambuf(const basic_streambuf&amp; sb);
7416basic_streambuf&amp; operator=(const basic_streambuf&amp; sb);
7417</pre>
7418</blockquote>
7419
7420<p>Insert after 27.5.2.1, paragraph 2:</p>
7421<blockquote>
7422<pre>basic_streambuf(const basic_streambuf&amp; sb);
7423</pre>
7424
7425<p>Constructs a copy of sb.</p>
7426<p>Postcondtions:</p>
7427<pre>                eback() == sb.eback()
7428                gptr()  == sb.gptr()
7429                egptr() == sb.egptr()
7430                pbase() == sb.pbase()
7431                pptr()  == sb.pptr()
7432                epptr() == sb.epptr()
7433                getloc() == sb.getloc()
7434</pre>
7435
7436<pre>basic_streambuf&amp; operator=(const basic_streambuf&amp; sb);
7437</pre>
7438
7439<p>Assigns the data members of sb to this.</p>
7440
7441<p>Postcondtions:</p>
7442<pre>                eback() == sb.eback()
7443                gptr()  == sb.gptr()
7444                egptr() == sb.egptr()
7445                pbase() == sb.pbase()
7446                pptr()  == sb.pptr()
7447                epptr() == sb.epptr()
7448                getloc() == sb.getloc()
7449</pre>
7450
7451<p>Returns: *this.</p>
7452</blockquote>
7453
7454<p>27.7.1 [lib.stringbuf]:</p>
7455
7456<p><b>Option A:</b></p>
7457
7458<blockquote>
7459<p>Insert into the basic_stringbuf synopsis in the private section:</p>
7460
7461<pre>basic_stringbuf(const basic_stringbuf&amp;);             // not defined
7462basic_stringbuf&amp; operator=(const basic_stringbuf&amp;);  // not defined
7463</pre>
7464</blockquote>
7465
7466<p><b>Option B:</b></p>
7467
7468<blockquote>
7469<p>Insert into the basic_stringbuf synopsis in the public section:</p>
7470
7471<pre>basic_stringbuf(const basic_stringbuf&amp; sb);
7472basic_stringbuf&amp; operator=(const basic_stringbuf&amp; sb);
7473</pre>
7474
7475<p>27.7.1.1, insert after paragraph 4:</p>
7476
7477<pre>basic_stringbuf(const basic_stringbuf&amp; sb);</pre>
7478
7479<p>
7480Constructs an independent copy of sb as if with sb.str(), and with the openmode that sb was constructed with.
7481</p>
7482
7483<p>Postcondtions: </p>
7484<pre>               str() == sb.str()
7485               gptr()  - eback() == sb.gptr()  - sb.eback()
7486               egptr() - eback() == sb.egptr() - sb.eback()
7487               pptr()  - pbase() == sb.pptr()  - sb.pbase()
7488               getloc() == sb.getloc()
7489</pre>
7490
7491<p>Note: The only requirement on epptr() is that it point beyond the
7492initialized range if an output sequence exists. There is no requirement
7493that epptr() - pbase() == sb.epptr() - sb.pbase().
7494</p>
7495
7496<pre>basic_stringbuf&amp; operator=(const basic_stringbuf&amp; sb);</pre>
7497<p>After assignment the basic_stringbuf has the same state as if it
7498were initially copy constructed from sb, except that the
7499basic_stringbuf is allowed to retain any excess capacity it might have,
7500which may in turn effect the value of epptr().
7501</p>
7502</blockquote>
7503
7504<p>27.8.1.1 [lib.filebuf]</p>
7505
7506<p>Insert at the bottom of the basic_filebuf synopsis:</p>
7507
7508<blockquote>
7509<pre>private:
7510  basic_filebuf(const basic_filebuf&amp;);             // not defined
7511  basic_filebuf&amp; operator=(const basic_filebuf&amp;);  // not defined
7512</pre>
7513</blockquote>
7514<p><i>[Kona: this is an issue for basic_streambuf itself and for its
7515  derived classes.  We are leaning toward allowing basic_streambuf to
7516  be copyable, and specifying its precise semantics.  (Probably the
7517  obvious: copying the buffer pointers.)  We are less sure whether
7518  the streambuf derived classes should be copyable.  Howard will
7519  write up a proposal.]</i></p>
7520
7521
7522<p><i>[Sydney: Dietmar presented a new argument against basic_streambuf
7523  being copyable: it can lead to an encapsulation violation. Filebuf
7524  inherits from streambuf. Now suppose you inhert a my_hijacking_buf
7525  from streambuf. You can copy the streambuf portion of a filebuf to a
7526  my_hijacking_buf, giving you access to the pointers into the
7527  filebuf's internal buffer. Perhaps not a very strong argument, but
7528  it was strong enough to make people nervous. There was weak
7529  preference for having streambuf not be copyable. There was weak
7530  preference for having stringbuf not be copyable even if streambuf
7531  is. Move this issue to open for now.
7532]</i></p>
7533
7534
7535<p><i>[
75362007-01-12, Howard:
7537<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1862.html#27.5.2%20-%20Class%20template%20basic_streambuf%3CcharT,traits%3E">Rvalue Reference Recommendations for Chapter 27</a>
7538recommends protected copy constructor and assignment for <tt>basic_streambuf</tt> with the same semantics
7539as would be generated by the compiler.  These members aid in derived classes implementing move semantics.
7540A protected copy constructor and copy assignment operator do not expose encapsulation more so than it is
7541today as each data member of a <tt>basic_streambuf</tt> is already both readable and writable by derived
7542classes via various get/set protected member functions (<tt>eback()</tt>, <tt>setp()</tt>, etc.).  Rather
7543a protected copy constructor and copy assignment operator simply make the job of derived classes implementing
7544move semantics less tedious and error prone.
7545]</i></p>
7546
7547
7548
7549
7550<p><b>Rationale:</b></p>
7551<p>
755227.5.2 [lib.streambuf]: The proposed basic_streambuf copy constructor
7553and assignment operator are the same as currently implied by the lack
7554of declarations: public and simply copies the data members.  This
7555resolution is not a change but a clarification of the current
7556standard.
7557</p>
7558
7559<p>
756027.7.1 [lib.stringbuf]: There are two reasonable options: A) Make
7561basic_stringbuf not copyable.  This is likely the status-quo of
7562current implementations.  B) Reasonable copy semantics of
7563basic_stringbuf can be defined and implemented.  A copyable
7564basic_streambuf is arguably more useful than a non-copyable one.  This
7565should be considered as new functionality and not the fixing of a
7566defect.  If option B is chosen, ramifications from issue 432 are taken
7567into account.
7568</p>
7569
7570<p>
757127.8.1.1 [lib.filebuf]: There are no reasonable copy semantics for
7572basic_filebuf.
7573</p>
7574
7575
7576
7577
7578
7579
7580<hr>
7581<h3><a name="423"></a>423. effects of negative streamsize in iostreams</h3>
7582<p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
7583 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18  <b>Last modified:</b> 2009-07-14</p>
7584<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</p>
7585<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
7586<p><b>Discussion:</b></p>
7587
7588<p>
7589A third party test suite tries to exercise istream::ignore(N) with
7590a negative value of N and expects that the implementation will treat
7591N as if it were 0. Our implementation asserts that (N &gt;= 0) holds and
7592aborts the test.
7593</p>
7594
7595<p>
7596I can't find anything in section 27 that prohibits such values but I don't
7597see what the effects of such calls should be, either (this applies to
7598a number of unformatted input functions as well as some member functions
7599of the basic_streambuf template).
7600</p>
7601
7602<p><i>[
76032009-07 Frankfurt
7604]</i></p>
7605
7606
7607<blockquote>
7608<p>
7609This is related to LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#255">255</a>.
7610</p>
7611<p>
7612Move to NAD Future.
7613</p>
7614</blockquote>
7615
7616
7617
7618<p><b>Proposed resolution:</b></p>
7619<p>
7620I propose that we add to each function in clause 27 that takes an argument,
7621say N, of type streamsize a Requires clause saying that "N &gt;= 0." The intent
7622is to allow negative streamsize values in calls to precision() and width()
7623but disallow it in calls to streambuf::sgetn(), istream::ignore(), or
7624ostream::write().
7625</p>
7626
7627<p><i>[Kona: The LWG agreed that this is probably what we want.  However, we
7628  need a review to find all places where functions in clause 27 take
7629  arguments of type streamsize that shouldn't be allowed to go
7630  negative.  Martin will do that review.]</i></p>
7631
7632
7633
7634
7635
7636
7637<hr>
7638<h3><a name="424"></a>424. normative notes</h3>
7639<p><b>Section:</b> 17.5.1.2 [structure.summary] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
7640 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18  <b>Last modified:</b> 2009-07-13</p>
7641<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
7642<p><b>Discussion:</b></p>
7643
7644<p>
7645The text in 17.3.1.1, p1 says:
7646<br>
7647
7648"Paragraphs labelled "Note(s):" or "Example(s):" are informative, other
7649paragraphs are normative."
7650<br>
7651
7652The library section makes heavy use of paragraphs labeled "Notes(s),"
7653some of which are clearly intended to be normative (see list 1), while
7654some others are not (see list 2). There are also those where the intent
7655is not so clear (see list 3).
7656<br><br>
7657
7658List 1 -- Examples of (presumably) normative Notes:
7659<br>
7660
766120.8.8.1 [allocator.members], p3,<br>
766220.8.8.1 [allocator.members], p10,<br>
766321.4.2 [string.cons], p11,<br>
766422.3.1.2 [locale.cons], p11,<br>
766523.3.2.3 [deque.modifiers], p2,<br>
766625.4.7 [alg.min.max], p3,<br>
766726.4.6 [complex.ops], p15,<br>
766827.6.2.4.3 [streambuf.virt.get], p7.<br>
7669<br>
7670
7671List 2 -- Examples of (presumably) informative Notes:
7672<br>
7673
767418.6.1.3 [new.delete.placement], p3,<br>
767521.4.6.6 [string::replace], p14,<br>
767622.4.1.4.2 [locale.codecvt.virtuals], p3,<br>
767725.2.4 [alg.foreach], p4,<br>
767826.4.5 [complex.member.ops], p1,<br>
767927.5.2.5 [ios.base.storage], p6.<br>
7680<br>
7681
7682List 3 -- Examples of Notes that are not clearly either normative
7683or informative:
7684<br>
7685
768622.3.1.2 [locale.cons], p8,<br>
768722.3.1.5 [locale.statics], p6,<br>
768827.6.2.4.5 [streambuf.virt.put], p4.<br>
7689<br>
7690
7691None of these lists is meant to be exhaustive.
7692</p>
7693
7694<p><i>[Definitely a real problem.  The big problem is there's material
7695  that doesn't quite fit any of the named paragraph categories
7696  (e.g. <b>Effects</b>).  Either we need a new kind of named
7697  paragraph, or we need to put more material in unnamed paragraphs
7698  jsut after the signature.  We need to talk to the Project Editor
7699  about how to do this.
7700]</i></p>
7701
7702
7703<p><i>[
7704Bellevue: Specifics of list 3: First 2 items correct in std (22.1.1.2,
770522.1.1.5) Third item should be non-normative (27.5.2.4.5), which Pete
7706will handle editorially.
7707]</i></p>
7708
7709
7710<p><i>[
7711post San Francisco:  Howard: reopened, needs attention.
7712]</i></p>
7713
7714
7715<p><i>[Pete: I changed the paragraphs marked "Note" and "Notes" to use "Remark" and "Remarks".
7716Fixed as editorial.  This change has been in the WD since the post-Redmond mailing, in 2004.
7717Recommend NAD.]</i></p>
7718
7719
7720<p><i>[
7721Batavia:  We feel that the references in List 2 above should be changed from <i>Remarks</i>
7722to <i>Notes</i>.  We also feel that those items in List 3 need to be double checked for
7723the same change.  Alan and Pete to review.
7724]</i></p>
7725
7726
7727<p><i>[
7728Batavia (2009-05):
7729]</i></p>
7730
7731<blockquote>
7732<p>
7733A spot-check of List 2 suggests the issue is still relevant,
7734and a review of List 3 still seems called-for.
7735</p>
7736<p>
7737Move to NAD Editorial.
7738</p>
7739</blockquote>
7740
7741
7742
7743<p><b>Proposed resolution:</b></p>
7744
7745
7746
7747
7748<hr>
7749<h3><a name="429"></a>429. typo in basic_ios::clear(iostate)</h3>
7750<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#Dup">Dup</a>
7751 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2003-09-18  <b>Last modified:</b> 2006-12-30</p>
7752<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>
7753<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
7754<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#412">412</a></p>
7755<p><b>Discussion:</b></p>
7756        <p>
7757
7758The Effects clause in 27.4.4.3, p5 describing the effects of a call to
7759the ios_base member function clear(iostate state) says that the function
7760only throws if the respective bits are already set prior to the function
7761call. That's obviously not the intent. If it was, a call to clear(badbit)
7762on an object for which (rdstate() == goodbit &amp;&amp; exceptions() == badbit)
7763holds would not result in an exception being thrown.
7764
7765        </p>
7766    
7767    <p><b>Proposed resolution:</b></p>
7768        <p>
7769
7770The text ought to be changed from
7771<br>
7772
7773"If (rdstate() &amp; exceptions()) == 0, returns. ..."
7774<br>
7775
7776to
7777<br>
7778
7779"If (state &amp; exceptions()) == 0, returns. ..."
7780        </p>
7781
7782
7783<p><b>Rationale:</b></p>
7784
7785
7786
7787
7788
7789
7790<hr>
7791<h3><a name="431"></a>431. Swapping containers with unequal allocators</h3>
7792<p><b>Section:</b> 20.2.2 [allocator.requirements], 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
7793 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2003-09-20  <b>Last modified:</b> 2009-10-26</p>
7794<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>
7795<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
7796<p><b>Discussion:</b></p>
7797<p>Clause 20.2.2 [allocator.requirements] paragraph 4 says that implementations
7798  are permitted to supply containers that are unable to cope with
7799  allocator instances and that container implementations may assume
7800  that all instances of an allocator type compare equal.  We gave
7801  implementers this latitude as a temporary hack, and eventually we
7802  want to get rid of it.  What happens when we're dealing with
7803  allocators that <i>don't</i> compare equal?
7804</p>
7805
7806<p>In particular: suppose that <tt>v1</tt> and <tt>v2</tt> are both
7807  objects of type <tt>vector&lt;int, my_alloc&gt;</tt> and that
7808  <tt>v1.get_allocator() != v2.get_allocator()</tt>.  What happens if
7809  we write <tt>v1.swap(v2)</tt>?  Informally, three possibilities:</p>
7810
7811<p>1. This operation is illegal.  Perhaps we could say that an
7812  implementation is required to check and to throw an exception, or
7813  perhaps we could say it's undefined behavior.</p>
7814<p>2. The operation performs a slow swap (i.e. using three
7815  invocations of <tt>operator=</tt>, leaving each allocator with its
7816  original container.  This would be an O(N) operation.</p>
7817<p>3. The operation swaps both the vectors' contents and their
7818  allocators.  This would be an O(1) operation. That is:</p>
7819  <blockquote>
7820  <pre>    my_alloc a1(...);
7821    my_alloc a2(...);
7822    assert(a1 != a2);
7823
7824    vector&lt;int, my_alloc&gt; v1(a1);
7825    vector&lt;int, my_alloc&gt; v2(a2);
7826    assert(a1 == v1.get_allocator());
7827    assert(a2 == v2.get_allocator());
7828
7829    v1.swap(v2);
7830    assert(a1 == v2.get_allocator());
7831    assert(a2 == v1.get_allocator());
7832  </pre>
7833  </blockquote>
7834
7835<p><i>[Kona: This is part of a general problem.  We need a paper
7836  saying how to deal with unequal allocators in general.]</i></p>
7837
7838
7839<p><i>[pre-Sydney: Howard argues for option 3 in
7840<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1599.html">N1599</a>.
7841]</i></p>
7842
7843
7844<p><i>[
78452007-01-12, Howard:  This issue will now tend to come up more often with move constructors
7846and move assignment operators.  For containers, these members transfer resources (i.e.
7847the allocated memory) just like swap.
7848]</i></p>
7849
7850
7851<p><i>[
7852Batavia:  There is agreement to overload the container <tt>swap</tt> on the allocator's Swappable
7853requirement using concepts.  If the allocator supports Swappable, then container's swap will
7854swap allocators, else it will perform a "slow swap" using copy construction and copy assignment.
7855]</i></p>
7856
7857
7858<p><i>[
78592009-04-28 Pablo adds:
7860]</i></p>
7861
7862<blockquote>
7863Fixed in
7864<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>.
7865I argued for marking this Tentatively-Ready right after Bellevue,
7866but there was a concern that
7867<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>
7868would break in the presence of the RVO. (That breakage had nothing to do with
7869swap, but never-the-less). I addressed that breakage in in
7870<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">N2840</a>
7871(Summit) by means of a non-normative reference:
7872
7873<blockquote>
7874[<i>Note:</i> in situations where the copy constructor for a container is elided,
7875this function is not called. The behavior in these cases is as if
7876<tt>select_on_container_copy_construction</tt> returned <tt>x</tt> &#8212; <i>end note</i>]
7877</blockquote>
7878
7879</blockquote>
7880
7881<p><i>[
78822009-10 Santa Cruz:
7883]</i></p>
7884
7885
7886<blockquote>
7887NAD Editorial.  Addressed by
7888<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>.
7889</blockquote>
7890
7891
7892
7893<p><b>Proposed resolution:</b></p>
7894
7895
7896
7897
7898
7899<hr>
7900<h3><a name="433"></a>433. Contradiction in specification of unexpected()</h3>
7901<p><b>Section:</b> 18.8.2.4 [unexpected] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7902 <b>Submitter:</b> Vyatcheslav Sysoltsev <b>Opened:</b> 2003-09-29  <b>Last modified:</b> 2006-12-27</p>
7903<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7904<p><b>Discussion:</b></p>
7905<p>
7906Clause 15.5.2 [except.unexpected] paragraph 1 says that "void unexpected();
7907is called (18.7.2) immediately after completing the stack unwinding
7908for the former function", but 18.7.2.4 (Effects) says that "void
7909unexpected(); . . . Calls the unexpected_handler function in effect
7910immediately after evaluating the throwexpression (18.7.2.2),".  Isn't
7911here a contradiction: 15.5.2 requires stack have been unwound when in
7912void unexpected() and therefore in unexpected_handler but 18.7.2.4
7913claims that unexpected_handler is called "in effect immediately" after
7914evaluation of throw expression is finished, so there is no space left
7915for stack to be unwound therefore?  I think the phrase "in effect
7916immediately" should be removed from the standard because it brings
7917ambiguity in understanding.
7918</p>
7919
7920
7921<p><b>Proposed resolution:</b></p>
7922
7923
7924<p><b>Rationale:</b></p>
7925<p>There is no contradiction.  The phrase "in effect immediately" is
7926  just to clarify which handler is to be called.</p>
7927
7928
7929
7930
7931
7932<hr>
7933<h3><a name="437"></a>437. Formatted output of function pointers is confusing</h3>
7934<p><b>Section:</b> 27.7.2.6.2 [ostream.inserters.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7935 <b>Submitter:</b> Ivan Godard <b>Opened:</b> 2003-10-24  <b>Last modified:</b> 2006-12-27</p>
7936<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.inserters.arithmetic">issues</a> in [ostream.inserters.arithmetic].</p>
7937<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7938<p><b>Discussion:</b></p>
7939<p>
7940Given:
7941</p>
7942<pre>void f(int) {}
7943void(*g)(int) = f;
7944cout &lt;&lt; g;
7945</pre>
7946
7947<p>
7948(with the expected #include and usings), the value printed is a rather
7949surprising "true". Rather useless too.
7950</p>
7951
7952<p>The standard defines:</p>
7953
7954<pre>ostream&amp; operator&lt;&lt;(ostream&amp;, void*);</pre>
7955
7956<p>which picks up all data pointers and prints their hex value, but does
7957not pick up function pointers because there is no default conversion
7958from function pointer to void*. Absent that, we fall back to legacy
7959conversions from C and the function pointer is converted to bool.
7960</p>
7961
7962<p>There should be an analogous inserter that prints the address of a
7963  function pointer.</p>
7964
7965
7966<p><b>Proposed resolution:</b></p>
7967
7968
7969<p><b>Rationale:</b></p>
7970<p>This is indeed a wart, but there is no good way to solve it.  C
7971  doesn't provide a portable way of outputting the address of a
7972  function point either.</p>
7973
7974
7975
7976
7977
7978<hr>
7979<h3><a name="439"></a>439. Should facets be copyable?</h3>
7980<p><b>Section:</b> 22.4 [locale.categories] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
7981 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2003-11-02  <b>Last modified:</b> 2006-12-27</p>
7982<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.categories">issues</a> in [locale.categories].</p>
7983<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
7984<p><b>Discussion:</b></p>
7985<p>The following facets classes have no copy constructors described in
7986  the standard, which, according to the standard, means that they are
7987  supposed to use the compiler-generated defaults.  Default copy
7988  behavior is probably inappropriate.  We should either make these
7989  classes uncopyable or else specify exactly what their constructors do.</p>
7990
7991<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#421">421</a>.</p>
7992
7993<pre>        ctype_base
7994        ctype
7995        ctype_byname
7996        ctype&lt;char&gt;
7997        ctype_byname&lt;char&gt;
7998        codecvt_base
7999        codecvt
8000        codecvt_byname
8001        num_get
8002        num_put
8003        numpunct
8004        numpunct_byname
8005        collate
8006        collate_byname
8007        time_base
8008        time_get
8009        time_get_byname
8010        time_put
8011        time_put_byname
8012        money_get
8013        money_put
8014        money_base
8015        moneypunct
8016        moneypunct_byname
8017        messages_base
8018        messages
8019        messages_byname
8020</pre>
8021
8022
8023
8024<p><b>Proposed resolution:</b></p>
8025
8026
8027<p><b>Rationale:</b></p>
8028<p>The copy constructor in the base class is private.</p>
8029
8030
8031
8032
8033
8034<hr>
8035<h3><a name="440"></a>440. Should std::complex use unqualified transcendentals?</h3>
8036<p><b>Section:</b> 26.4.8 [complex.transcendentals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
8037 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2003-11-05  <b>Last modified:</b> 2009-03-21</p>
8038<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8039<p><b>Discussion:</b></p>
8040<p>
8041Operations like <tt>pow</tt> and <tt>exp</tt> on
8042<tt>complex&lt;T&gt;</tt> are typically implemented in terms of
8043operations like <tt>sin</tt> and <tt>cos</tt> on <tt>T</tt>.  
8044Should implementations write this as <tt>std::sin</tt>, or as plain
8045unqualified <tt>sin</tt>?
8046</p>
8047
8048<p>The issue, of course, is whether we want to use
8049argument-dependent lookup in the case where <tt>T</tt> is a
8050user-defined type.  This is similar to the issue of valarray
8051transcendentals, as discussed in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>.</p>
8052
8053<p>This issue differs from valarray transcendentals in two important
8054ways.  First, "the effect of instantiating the template
8055<tt>complex</tt> for types other than float, double or long double is
8056unspecified." (26.4.1 [complex.syn]) Second, the standard does not
8057dictate implementation, so there is no guarantee that a particular
8058real math function is used in the implementation of a particular
8059complex function.</p>
8060
8061
8062
8063<p><b>Proposed resolution:</b></p>
8064
8065
8066<p><b>Rationale:</b></p>
8067<p>If you instantiate std::complex for user-defined types, all bets
8068are off.</p>
8069
8070
8071
8072
8073
8074<hr>
8075<h3><a name="447"></a>447. Wrong template argument for time facets</h3>
8076<p><b>Section:</b> 22.3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
8077 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2003-12-26  <b>Last modified:</b> 2007-01-15</p>
8078<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</p>
8079<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
8080<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#327">327</a></p>
8081<p><b>Discussion:</b></p>
8082<p>
808322.1.1.1.1/4, table 52, "Required Instantiations", lists, among others:
8084</p>
8085<pre>    time_get&lt;char,InputIterator&gt;
8086    time_get_byname&lt;char,InputIterator&gt;
8087    time_get&lt;wchar_t,OutputIterator&gt;
8088    time_get_byname&lt;wchar_t,OutputIterator&gt;
8089</pre>
8090
8091<p>
8092The second argument to the last two should be InputIterator, not
8093OutputIterator.
8094</p>
8095
8096
8097<p><b>Proposed resolution:</b></p>
8098<p>
8099Change the second template argument to InputIterator.
8100</p>
8101
8102
8103<p><b>Rationale:</b></p>
8104
8105
8106
8107
8108
8109
8110<hr>
8111<h3><a name="450"></a>450. set::find is inconsistent with associative container requirements</h3>
8112<p><b>Section:</b> 23.4.3 [set] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
8113 <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-01-30  <b>Last modified:</b> 2009-05-01</p>
8114<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#set">issues</a> in [set].</p>
8115<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
8116<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#214">214</a></p>
8117<p><b>Discussion:</b></p>
8118<p>map/multimap have:</p>
8119
8120<pre>    iterator find(const key_type&amp; x) const;
8121    const_iterator find(const key_type&amp; x) const;
8122</pre>
8123
8124<p>
8125which is consistent with the table of associative container requirements.
8126But set/multiset have:
8127</p>
8128<pre>    iterator find(const key_type&amp;) const;
8129</pre>
8130
8131<p>
8132set/multiset should look like map/multimap, and honor the requirements
8133table, in this regard.
8134</p>
8135
8136
8137<p><b>Proposed resolution:</b></p>
8138
8139
8140<p><b>Rationale:</b></p>
8141
8142
8143
8144
8145
8146
8147<hr>
8148<h3><a name="451"></a>451. Associative erase should return an iterator</h3>
8149<p><b>Section:</b> 23.2.4 [associative.reqmts], 23.4 [associative] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
8150 <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-01-30  <b>Last modified:</b> 2009-05-01</p>
8151<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
8152<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>
8153<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
8154<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a></p>
8155<p><b>Discussion:</b></p>
8156<p>map/multimap/set/multiset have:</p>
8157<pre>    void erase(iterator);
8158    void erase(iterator, iterator);
8159</pre>
8160
8161<p>But there's no good reason why these can't return an iterator, as for
8162vector/deque/list:</p>
8163<pre>    iterator erase(iterator);
8164    iterator erase(iterator, iterator);
8165</pre>
8166
8167
8168
8169<p><b>Proposed resolution:</b></p>
8170<p>
8171Informally: The table of associative container requirements, and the
8172relevant template classes, should return an iterator designating the
8173first element beyond the erased subrange.
8174</p>
8175
8176
8177<p><b>Rationale:</b></p>
8178
8179
8180
8181
8182
8183
8184<hr>
8185<h3><a name="452"></a>452.  locale::combine should be permitted to generate a named locale</h3>
8186<p><b>Section:</b> 22.3.1.3 [locale.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
8187 <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-01-30  <b>Last modified:</b> 2009-05-01</p>
8188<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.members">issues</a> in [locale.members].</p>
8189<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8190<p><b>Discussion:</b></p>
8191<pre>template&lt;class Facet&gt;
8192    locale::combine(const locale&amp;) const;
8193</pre>
8194<p>
8195is obliged to create a locale that has no name. This is overspecification
8196and overkill. The resulting locale should follow the usual rules -- it
8197has a name if the locale argument has a name and Facet is one of the
8198standard facets.
8199</p>
8200
8201<p><i>[
8202 Sydney and post-Sydney (see c++std-lib-13439, c++std-lib-13440,
8203 c++std-lib-13443): agreed that it's overkill to say that the locale
8204 is obligated to be nameless.  However, we also can't require it to
8205 have a name.  At the moment, locale names are based on categories
8206 and not on individual facets.  If a locale contains two different
8207 facets of different names from the same category, then this would
8208 not fit into existing naming schemes.  We need to give
8209 implementations more freedom.  Bill will provide wording.
8210]</i></p>
8211
8212
8213
8214
8215<p><b>Rationale:</b></p>
8216<p>After further discussion the LWG decided to close this as NAD.
8217  The fundamental problem is that names right now are per-category,
8218  not per-facet.  The <tt>combine</tt> member function works at the
8219  wrong level of granularity.</p>
8220
8221
8222
8223
8224
8225<hr>
8226<h3><a name="454"></a>454. basic_filebuf::open should accept wchar_t names</h3>
8227<p><b>Section:</b> 27.9.1.4 [filebuf.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
8228 <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-01-30  <b>Last modified:</b> 2009-05-01</p>
8229<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#filebuf.members">issues</a> in [filebuf.members].</p>
8230<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8231<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a></p>
8232<p><b>Discussion:</b></p>
8233<pre>    basic_filebuf *basic_filebuf::open(const char *, ios_base::open_mode);
8234</pre>
8235
8236<p>should be supplemented with the overload:</p>
8237
8238<pre>    basic_filebuf *basic_filebuf::open(const wchar_t *, ios_base::open_mode);
8239</pre>
8240
8241<p>
8242Depending on the operating system, one of these forms is fundamental and
8243the other requires an implementation-defined mapping to determine the
8244actual filename.
8245</p>
8246
8247<p><i>[Sydney: Yes, we want to allow wchar_t filenames.  Bill will
8248  provide wording.]</i></p>
8249
8250
8251<p><i>[
8252In Toronto we noted that this is issue 5 from
8253<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1569.htm">N1569</a>.
8254]</i></p>
8255
8256<p>
8257How does this interact with the newly-defined character types, and how
8258do we avoid interface explosion considering <tt>std::string</tt> overloads that
8259were added? Propose another solution that is different than the
8260suggestion proposed by PJP.
8261</p>
8262<p>
8263Suggestion is to make a member template function for <tt>basic_string</tt> (for
8264<tt>char</tt>, <tt>wchar_t</tt>, <tt>u16char</tt>, <tt>u32char</tt> instantiations), and then just keep a
8265<tt>const char*</tt> member.
8266</p>
8267<p>
8268Goal is to do implicit conversion between character string literals to
8269appropriate <tt>basic_string</tt> type. Not quite sure if this is possible.
8270</p>
8271<p>
8272Implementors are free to add specific overloads for non-char character
8273types.
8274</p>
8275
8276<p><i>[
8277Martin adds pre-Sophia Antipolis:
8278]</i></p>
8279
8280
8281<blockquote>
8282Please see <a href="http://wiki.dinkumware.com/twiki/pub/Wg21sophiaAntipolis/LibraryWorkingGroup/issue-454.html">issue 454: problems and solutions</a>.
8283</blockquote>
8284
8285<p><i>[
8286Sophia Antipolis:
8287]</i></p>
8288
8289
8290<blockquote>
8291<p>
8292Beman is concerned that making these changes to <tt>basic_filebuf</tt> is not
8293usefully changed unless <tt>fstream</tt> is also changed; this also only handles
8294<tt>wchar_t</tt> and not other character types.
8295</p>
8296<p>
8297The TR2 filesystem library is a more complete solution, but is not available soon.
8298</p>
8299</blockquote>
8300
8301<p><i>[
8302Martin adds:  please reference
8303<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2683.html">N2683</a> for
8304problems and solutions.
8305]</i></p>
8306
8307
8308
8309
8310<p><b>Proposed resolution:</b></p>
8311
8312<p>Change from:</p>
8313<blockquote>
8314<pre>basic_filebuf&lt;charT,traits&gt;* open(
8315    const char* s,
8316    ios_base::openmode mode );
8317</pre>
8318
8319<p>
8320Effects: If is_open() != false, returns a null pointer.
8321Otherwise, initializes the filebuf as required. It then
8322opens a file, if possible, whose name is the NTBS s ("as if"
8323by calling std::fopen(s,modstr)).</p>
8324</blockquote>
8325
8326<p>to:</p>
8327
8328<blockquote>
8329<pre>basic_filebuf&lt;charT,traits&gt;* open(
8330    const char* s,
8331    ios_base::openmode mode );
8332
8333basic_filebuf&lt;charT,traits&gt;* open(
8334    const wchar_t* ws,
8335    ios_base::openmode mode );
8336</pre>
8337
8338<p>
8339Effects: If is_open() != false, returns a null pointer.
8340Otherwise, initializes the filebuf as required. It then
8341opens a file, if possible, whose name is the NTBS s ("as if"
8342by calling std::fopen(s,modstr)).
8343For the second signature, the NTBS s is determined from the
8344WCBS ws in an implementation-defined manner.
8345</p>
8346
8347<p>
8348(NOTE: For a system that "naturally" represents a filename
8349as a WCBS, the NTBS s in the first signature may instead
8350be mapped to a WCBS; if so, it follows the same mapping
8351rules as the first argument to open.)
8352</p>
8353</blockquote>
8354
8355
8356
8357<p><b>Rationale:</b></p>
8358<p>
8359Slightly controversial, but by a 7-1 straw poll the LWG agreed to move
8360this to Ready.  The controversy was because the mapping between wide
8361names and files in a filesystem is implementation defined.  The
8362counterargument, which most but not all LWG members accepted, is that
8363the mapping between narrow files names and files is also
8364implemenation defined.</p>
8365
8366<p><i>[Lillehammer: Moved back to "open" status, at Beman's urging.
8367(1) Why just basic_filebuf, instead of also basic_fstream (and
8368possibly other things too). (2) Why not also constructors that take
8369std::basic_string? (3) We might want to wait until we see Beman's
8370filesystem library; we might decide that it obviates this.]</i></p>
8371
8372
8373<p><i>[
8374post Bellevue:
8375]</i></p>
8376
8377
8378<blockquote>
8379<p>
8380Move again to Ready.
8381</p>
8382<p>
8383There is a timing issue here. Since the filesystem library will not be
8384in C++0x, this should be brought forward. This solution would remain
8385valid in the context of the proposed filesystem.
8386</p>
8387<p>
8388This issue has been kicking around for a while, and the wchar_t addition
8389alone would help many users. Thus, we suggest putting this on the
8390reflector list with an invitation for someone to produce proposed
8391wording that covers basic_fstream. In the meantime, we suggest that the
8392proposed wording be adopted as-is.
8393</p>
8394<p>
8395If more of the Lillehammer questions come back, they should be
8396introduced as separate issues.
8397</p>
8398</blockquote>
8399
8400<p><i>[
8401San Francisco:
8402]</i></p>
8403
8404
8405<blockquote>
8406Some existing implementations provide overload already. Expected
8407filesystem "path" object overloads neatly, without surprises; implying
8408NAD.
8409</blockquote>
8410
8411
8412
8413
8414
8415
8416
8417<hr>
8418<h3><a name="458"></a>458. 24.1.5 contains unintended limitation for operator-</h3>
8419<p><b>Section:</b> 24.2.5 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
8420 <b>Submitter:</b> Daniel Frey <b>Opened:</b> 2004-02-27  <b>Last modified:</b> 2009-10-26</p>
8421<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>
8422<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8423<p><b>Discussion:</b></p>
8424<p>
8425In 24.1.5 [lib.random.access.iterators], table 76 the operational
8426semantics for the expression "r -= n" are defined as "return r += -n".
8427This means, that the expression -n must be valid, which is not the case
8428for unsigned types.
8429</p>
8430
8431<p><i>[
8432Sydney: Possibly not a real problem, since difference type is required
8433to be a signed integer type. However, the wording in the standard may
8434be less clear than we would like.
8435]</i></p>
8436
8437
8438<p><i>[
8439Post Summit Alisdair adds:
8440]</i></p>
8441
8442
8443<blockquote>
8444<p>
8445This issue refers to a requirements table we have removed.
8446</p>
8447<p>
8448The issue might now relate to 24.2.5 [random.access.iterators] p5.
8449However, the rationale in the issue already recognises that the
8450<tt>difference_type</tt> must be signed, so this really looks NAD.
8451</p>
8452</blockquote>
8453
8454<p><i>[
8455Batavia (2009-05):
8456]</i></p>
8457
8458<blockquote>
8459<p>
8460We agree with Alisdair's observations.
8461</p>
8462<p>
8463Move to NAD.
8464</p>
8465</blockquote>
8466
8467<p><i>[
84682009-07 Frankfurt:
8469]</i></p>
8470
8471
8472<blockquote>
8473<p>
8474Need to look at again without concepts.
8475</p>
8476<p>
8477There was a question about this phrase in the discussion: "the
8478expression -n must be valid, which is not the case for unsigned types."
8479If n is an object ofthe iterator difference_type (eg ptrdiff_t), then it
8480is never unsigned.
8481</p>
8482</blockquote>
8483
8484<p><i>[
84852009-10 Santa Cruz:
8486]</i></p>
8487
8488
8489<blockquote>
8490The group reviewed the wording in the draft and agreed that n is of
8491difference type, the difference type is signed, and the current wording
8492is correct.  Moved to NAD.
8493</blockquote>
8494
8495
8496
8497<p><b>Proposed resolution:</b></p>
8498<p>
8499To remove this limitation, I suggest to change the
8500operational semantics for this column to:
8501</p>
8502<blockquote><pre>    { Distance m = n;
8503      if (m &gt;= 0)
8504        while (m--) --r;
8505      else
8506        while (m++) ++r;
8507      return r; }
8508</pre></blockquote>
8509
8510
8511
8512
8513
8514
8515<hr>
8516<h3><a name="459"></a>459. Requirement for widening in stage 2 is overspecification</h3>
8517<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#NAD">NAD</a>
8518 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-03-16  <b>Last modified:</b> 2009-07-14</p>
8519<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>
8520<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>
8521<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8522<p><b>Discussion:</b></p>
8523<p>When parsing strings of wide-character digits, the standard
8524  requires the library to widen narrow-character "atoms" and compare
8525  the widened atoms against the characters that are being parsed.
8526  Simply narrowing the wide characters would be far simpler, and
8527  probably more efficient.  The two choices are equivalent except in
8528  convoluted test cases, and many implementations already ignore the
8529  standard and use narrow instead of widen.</p>
8530
8531<p>
8532First, I disagree that using narrow() instead of widen() would
8533necessarily have unfortunate performance implications. A possible
8534implementation of narrow() that allows num_get to be implemented
8535in a much simpler and arguably comparably efficient way as calling
8536widen() allows, i.e. without making a virtual call to do_narrow every
8537time, is as follows:
8538</p>
8539
8540<pre>  inline char ctype&lt;wchar_t&gt;::narrow (wchar_t wc, char dflt) const
8541  {
8542      const unsigned wi = unsigned (wc);
8543
8544      if (wi &gt; UCHAR_MAX)
8545          return typeid (*this) == typeid (ctype&lt;wchar_t&gt;) ?
8546                 dflt : do_narrow (wc, dflt);
8547
8548      if (narrow_ [wi] &lt; 0) {
8549         const char nc = do_narrow (wc, dflt);
8550         if (nc == dflt)
8551             return dflt;
8552         narrow_ [wi] = nc;
8553      }
8554
8555      return char (narrow_ [wi]);
8556  }
8557</pre>
8558
8559<p>
8560Second, I don't think the change proposed in the issue (i.e., to use
8561narrow() instead of widen() during Stage 2) would be at all
8562drastic. Existing implementations with the exception of libstdc++
8563currently already use narrow() so the impact of the change on programs
8564would presumably be isolated to just a single implementation. Further,
8565since narrow() is not required to translate alternate wide digit
8566representations such as those mentioned in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a>
8567to
8568their narrow equivalents (i.e., the portable source characters '0'
8569through '9'), the change does not necessarily imply that these
8570alternate digits would be treated as ordinary digits and accepted as
8571part of numbers during parsing. In fact, the requirement in 22.4.1.1.2
8572[locale.ctype.virtuals], p13 forbids narrow() to translate an alternate
8573digit character, wc, to an ordinary digit in the basic source
8574character set unless the expression
8575(ctype&lt;charT&gt;::is(ctype_base::digit, wc) == true) holds. This in
8576turn is prohibited by the C standard (7.25.2.1.5, 7.25.2.1.5, and
85775.2.1, respectively) for charT of either char or wchar_t.
8578</p>
8579
8580<p><i>[Sydney: To a large extent this is a nonproblem. As long as
8581you're only trafficking in char and wchar_t we're only dealing with a
8582stable character set, so you don't really need either 'widen' or
8583'narrow': can just use literals. Finally, it's not even clear whether
8584widen-vs-narrow is the right question; arguably we should be using
8585codecvt instead.]</i></p>
8586
8587
8588<p><i>[
85892009-07 Frankfurt
8590]</i></p>
8591
8592
8593<blockquote>
8594NAD. The standard is clear enough as written.
8595</blockquote>
8596
8597
8598
8599<p><b>Proposed resolution:</b></p>
8600<p>Change stage 2 so that implementations are permitted to use either
8601technique to perform the comparison:</p>
8602<ol>
8603  <li> call widen on the atoms and compare (either by using
8604      operator== or char_traits&lt;charT&gt;::eq) the input with
8605      the widened atoms, or</li>
8606  <li> call narrow on the input and compare the narrow input
8607      with the atoms</li>
8608  <li> do (1) or (2) only if charT is not char or wchar_t,
8609      respectively; i.e., avoid calling widen or narrow
8610      if it the source and destination types are the same</li>
8611</ol>
8612
8613
8614
8615
8616
8617<hr>
8618<h3><a name="462"></a>462. Destroying objects with static storage duration</h3>
8619<p><b>Section:</b> 3.6.3 [basic.start.term], 18.4 [cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
8620 <b>Submitter:</b> Bill Plauger <b>Opened:</b> 2004-03-23  <b>Last modified:</b> 2008-02-25</p>
8621<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8622<p><b>Discussion:</b></p>
8623<p>
86243.6.3 Termination spells out in detail the interleaving of static
8625destructor calls and calls to functions registered with atexit. To
8626match this behavior requires intimate cooperation between the code
8627that calls destructors and the exit/atexit machinery. The former
8628is tied tightly to the compiler; the latter is a primitive mechanism
8629inherited from C that traditionally has nothing to do with static
8630construction and destruction. The benefits of intermixing destructor
8631calls with atexit handler calls is questionable at best, and <i>very</i>
8632difficult to get right, particularly when mixing third-party C++
8633libraries with different third-party C++ compilers and C libraries
8634supplied by still other parties.
8635</p>
8636
8637<p>
8638I believe the right thing to do is defer all static destruction
8639until after all atexit handlers are called. This is a change in
8640behavior, but one that is likely visible only to perverse test
8641suites. At the very least, we should <i>permit</i> deferred destruction
8642even if we don't require it.
8643</p>
8644
8645<p><i>[If this is to be changed, it should probably be changed by CWG.
8646  At this point, however, the LWG is leaning toward NAD.  Implementing
8647  what the standard says is hard work, but it's not impossible and
8648  most vendors went through that pain years ago.  Changing this
8649  behavior would be a user-visible change, and would break at least
8650  one real application.]</i></p>
8651
8652
8653<p><i>[
8654Batavia:  Send to core with our recommendation that we should permit deferred
8655destruction but not require it.
8656]</i></p>
8657
8658
8659<p><i>[
8660Howard:  The course of action recommended in Batavia would undo LWG
8661issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3">3</a> and break current code implementing the "phoenix
8662singleton". Search the net for "phoenix singleton atexit" to get a feel
8663for the size of the adverse impact this change would have.  Below is
8664sample code which implements the phoenix singleton and would break if
8665<tt>atexit</tt> is changed in this way:
8666]</i></p>
8667
8668
8669<blockquote><pre>#include &lt;cstdlib&gt;
8670#include &lt;iostream&gt;
8671#include &lt;type_traits&gt;
8672#include &lt;new&gt;
8673
8674class A
8675{
8676    bool alive_;
8677    A(const A&amp;);
8678    A&amp; operator=(const A&amp;);
8679public:
8680    A() : alive_(true) {std::cout &lt;&lt; "A()\n";}
8681    ~A() {alive_ = false; std::cout &lt;&lt; "~A()\n";}
8682    void use()
8683    {
8684        if (alive_)
8685            std::cout &lt;&lt; "A is alive\n";
8686        else
8687            std::cout &lt;&lt; "A is dead\n";
8688    }
8689};
8690
8691void deallocate_resource();
8692
8693// This is the phoenix singleton pattern
8694A&amp; get_resource(bool create = true)
8695{
8696    static std::aligned_storage&lt;sizeof(A), std::alignment_of&lt;A&gt;::value&gt;::type buf;
8697    static A* a;
8698    if (create)
8699    {
8700        if (a != (A*)&amp;buf)
8701        {
8702            a = ::new (&amp;buf) A;
8703            std::atexit(deallocate_resource);
8704        }
8705    }
8706    else
8707    {
8708        a-&gt;~A();
8709        a = (A*)&amp;buf + 1;
8710    }
8711    return *a;
8712}
8713
8714void deallocate_resource()
8715{
8716    get_resource(false);
8717}
8718
8719void use_A(const char* message)
8720{
8721    A&amp; a = get_resource();
8722    std::cout &lt;&lt; "Using A " &lt;&lt; message &lt;&lt; "\n";
8723    a.use();
8724}
8725
8726struct B
8727{
8728    ~B() {use_A("from ~B()");}
8729};
8730
8731B b;
8732
8733int main()
8734{
8735    use_A("from main()");
8736}
8737</pre></blockquote>
8738
8739<p>
8740The correct output is:
8741</p>
8742
8743<blockquote><pre>A()
8744Using A from main()
8745A is alive
8746~A()
8747A()
8748Using A from ~B()
8749A is alive
8750~A()
8751</pre></blockquote>
8752
8753<p><i>[
8754Bellevue: Confirmed no interaction with <tt>quick_exit</tt>.
8755Strong feeling against mandating the change. Leaning towards NAD rather than permitting the change,
8756as this would make common implementations of pheonix-singleton pattern implementation defined, as noted by Howard.
8757Bill agrees issue is no longer serious, and accepts NAD.
8758]</i></p>
8759
8760
8761
8762
8763<p><b>Proposed resolution:</b></p>
8764<p>
8765</p>
8766
8767
8768
8769
8770
8771<hr>
8772<h3><a name="463"></a>463. auto_ptr usability issues</h3>
8773<p><b>Section:</b> D.10.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
8774 <b>Submitter:</b> Rani Sharoni <b>Opened:</b> 2003-12-07  <b>Last modified:</b> 2009-10-26</p>
8775<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>
8776<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
8777<p><b>Discussion:</b></p>
8778
8779<p>
8780TC1 CWG DR #84 effectively made the template&lt;class Y&gt; operator auto_ptr&lt;Y&gt;()
8781member of auto_ptr (20.4.5.3/4) obsolete.
8782</p>
8783
8784<p>
8785The sole purpose of this obsolete conversion member is to enable copy
8786initialization base from r-value derived (or any convertible types like
8787cv-types) case:
8788</p>
8789<pre>#include &lt;memory&gt;
8790using std::auto_ptr;
8791
8792struct B {};
8793struct D : B {};
8794
8795auto_ptr&lt;D&gt; source();
8796int sink(auto_ptr&lt;B&gt;);
8797int x1 = sink( source() ); // #1 EDG - no suitable copy constructor
8798</pre>
8799
8800<p>
8801The excellent analysis of conversion operations that was given in the final
8802auto_ptr proposal
8803(http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/1997/N1128.pdf)
8804explicitly specifies this case analysis (case 4). DR #84 makes the analysis
8805wrong and actually comes to forbid the loophole that was exploited by the
8806auto_ptr designers.
8807</p>
8808
8809<p>
8810I didn't encounter any compliant compiler (e.g. EDG, GCC, BCC and VC) that
8811ever allowed this case. This is probably because it requires 3 user defined
8812conversions and in fact current compilers conform to DR #84.
8813</p>
8814
8815<p>
8816I was surprised to discover that the obsolete conversion member actually has
8817negative impact of the copy initialization base from l-value derived
8818case:</p>
8819<pre>auto_ptr&lt;D&gt; dp;
8820int x2 = sink(dp); // #2 EDG - more than one user-defined conversion applies
8821</pre>
8822
8823<p>
8824I'm sure that the original intention was allowing this initialization using
8825the template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;&amp; a) constructor (20.4.5.1/4) but
8826since in this copy initialization it's merely user defined conversion (UDC)
8827and the obsolete conversion member is UDC with the same rank (for the early
8828overloading stage) there is an ambiguity between them.
8829</p>
8830
8831<p>
8832Removing the obsolete member will have impact on code that explicitly
8833invokes it:
8834</p>
8835<pre>int y = sink(source().operator auto_ptr&lt;B&gt;());
8836</pre>
8837
8838<p>
8839IMHO no one ever wrote such awkward code and the reasonable workaround for
8840#1 is:
8841</p>
8842<pre>int y = sink( auto_ptr&lt;B&gt;(source()) );
8843</pre>
8844
8845<p>
8846I was even more surprised to find out that after removing the obsolete
8847conversion member the initialization was still ill-formed:
8848int x3 = sink(dp); // #3 EDG - no suitable copy constructor
8849</p>
8850
8851<p>
8852This copy initialization semantically requires copy constructor which means
8853that both template conversion constructor and the auto_ptr_ref conversion
8854member (20.4.5.3/3) are required which is what was explicitly forbidden in
8855DR #84. This is a bit amusing case in which removing ambiguity results with
8856no candidates.
8857</p>
8858
8859<p>
8860I also found exception safety issue with auto_ptr related to auto_ptr_ref:
8861</p>
8862<pre>int f(auto_ptr&lt;B&gt;, std::string);
8863auto_ptr&lt;B&gt; source2();
8864
8865// string constructor throws while auto_ptr_ref
8866// "holds" the pointer
8867int x4 = f(source2(), "xyz"); // #4
8868</pre>
8869
8870<p>
8871The theoretic execution sequence that will cause a leak:
8872</p>
8873<ol>
8874<li>call auto_ptr&lt;B&gt;::operator auto_ptr_ref&lt;B&gt;()</li>
8875<li>call string::string(char const*) and throw</li>
8876</ol>
8877
8878<p>
8879According to 20.4.5.3/3 and 20.4.5/2 the auto_ptr_ref conversion member
8880returns auto_ptr_ref&lt;Y&gt; that holds *this and this is another defect since
8881the type of *this is auto_ptr&lt;X&gt; where X might be different from Y. Several
8882library vendors (e.g. SGI) implement auto_ptr_ref&lt;Y&gt; with Y* as member which
8883is much more reasonable. Other vendor implemented auto_ptr_ref as
8884defectively required and it results with awkward and catastrophic code:
8885int oops = sink(auto_ptr&lt;B&gt;(source())); // warning recursive on all control
8886paths
8887</p>
8888
8889<p>
8890Dave Abrahams noticed that there is no specification saying that
8891auto_ptr_ref copy constructor can't throw.
8892</p>
8893
8894<p>
8895My proposal comes to solve all the above issues and significantly simplify
8896auto_ptr implementation. One of the fundamental requirements from auto_ptr
8897is that it can be constructed in an intuitive manner (i.e. like ordinary
8898pointers) but with strict ownership semantics which yield that source
8899auto_ptr in initialization must be non-const. My idea is to add additional
8900constructor template with sole propose to generate ill-formed, diagnostic
8901required, instance for const auto_ptr arguments during instantiation of
8902declaration. This special constructor will not be instantiated for other
8903types which is achievable using 14.8.2/2 (SFINAE). Having this constructor
8904in hand makes the constructor template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp;)
8905legitimate since the actual argument can't be const yet non const r-value
8906are acceptable.
8907</p>
8908
8909<p>
8910This implementation technique makes the "private auxiliary class"
8911auto_ptr_ref obsolete and I found out that modern C++ compilers (e.g. EDG,
8912GCC and VC) consume the new implementation as expected and allow all
8913intuitive initialization and assignment cases while rejecting illegal cases
8914that involve const auto_ptr arguments.
8915</p>
8916
8917<p>The proposed auto_ptr interface:</p>
8918
8919<pre>namespace std {
8920    template&lt;class X&gt; class auto_ptr {
8921    public:
8922        typedef X element_type;
8923
8924        // 20.4.5.1 construct/copy/destroy:
8925        explicit auto_ptr(X* p=0) throw();
8926        auto_ptr(auto_ptr&amp;) throw();
8927        template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp;) throw();
8928        auto_ptr&amp; operator=(auto_ptr&amp;) throw();
8929        template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;) throw();
8930        ~auto_ptr() throw();
8931
8932        // 20.4.5.2 members:
8933        X&amp; operator*() const throw();
8934        X* operator-&gt;() const throw();
8935        X* get() const throw();
8936        X* release() throw();
8937        void reset(X* p=0) throw();
8938
8939    private:
8940        template&lt;class U&gt;
8941        auto_ptr(U&amp; rhs, typename
8942unspecified_error_on_const_auto_ptr&lt;U&gt;::type = 0);
8943    };
8944}
8945</pre>
8946
8947<p>
8948One compliant technique to implement the unspecified_error_on_const_auto_ptr
8949helper class is using additional private auto_ptr member class template like
8950the following:
8951</p>
8952<pre>template&lt;typename T&gt; struct unspecified_error_on_const_auto_ptr;
8953
8954template&lt;typename T&gt;
8955struct unspecified_error_on_const_auto_ptr&lt;auto_ptr&lt;T&gt; const&gt;
8956{ typedef typename auto_ptr&lt;T&gt;::const_auto_ptr_is_not_allowed type; };
8957</pre>
8958
8959<p>
8960There are other techniques to implement this helper class that might work
8961better for different compliers (i.e. better diagnostics) and therefore I
8962suggest defining its semantic behavior without mandating any specific
8963implementation. IMO, and I didn't found any compiler that thinks otherwise,
896414.7.1/5 doesn't theoretically defeat the suggested technique but I suggest
8965verifying this with core language experts.
8966</p>
8967
8968<p><b>Further changes in standard text:</b></p>
8969<p>Remove section 20.4.5.3</p>
8970
8971<p>Change 20.4.5/2 to read something like:
8972Initializing auto_ptr&lt;X&gt; from const auto_ptr&lt;Y&gt; will result with unspecified
8973ill-formed declaration that will require unspecified diagnostic.</p>
8974
8975<p>Change 20.4.5.1/4,5,6 to read:</p>
8976
8977<pre>template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp; a) throw();</pre>
8978<p> 4 Requires: Y* can be implicitly converted to X*.</p>
8979<p> 5 Effects: Calls const_cast&lt;auto_ptr&lt;Y&gt;&amp;&gt;(a).release().</p>
8980<p> 6 Postconditions: *this holds the pointer returned from a.release().</p>
8981
8982<p>Change 20.4.5.1/10</p>
8983<pre>template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt; a) throw();
8984</pre>
8985<p>
898610 Requires: Y* can be implicitly converted to X*. The expression delete
8987get() is well formed.
8988</p>
8989
8990<p>LWG TC DR #127 is obsolete.</p>
8991
8992<p>
8993Notice that the copy constructor and copy assignment operator should remain
8994as before and accept non-const auto_ptr&amp; since they have effect on the form
8995of the implicitly declared copy constructor and copy assignment operator of
8996class that contains auto_ptr as member per 12.8/5,10:
8997</p>
8998<pre>struct X {
8999    // implicit X(X&amp;)
9000    // implicit X&amp; operator=(X&amp;)
9001    auto_ptr&lt;D&gt; aptr_;
9002};
9003</pre>
9004
9005<p>
9006In most cases this indicates about sloppy programming but preserves the
9007current auto_ptr behavior.
9008</p>
9009
9010<p>
9011Dave Abrahams encouraged me to suggest fallback implementation in case that
9012my suggestion that involves removing of auto_ptr_ref will not be accepted.
9013In this case removing the obsolete conversion member to auto_ptr&lt;Y&gt; and
901420.4.5.3/4,5 is still required in order to eliminate ambiguity in legal
9015cases. The two constructors that I suggested will co exist with the current
9016members but will make auto_ptr_ref obsolete in initialization contexts.
9017auto_ptr_ref will be effective in assignment contexts as suggested in DR
9018#127 and I can't see any serious exception safety issues in those cases
9019(although it's possible to synthesize such). auto_ptr_ref&lt;X&gt; semantics will
9020have to be revised to say that it strictly holds pointer of type X and not
9021reference to an auto_ptr for the favor of cases in which auto_ptr_ref&lt;Y&gt; is
9022constructed from auto_ptr&lt;X&gt; in which X is different from Y (i.e. assignment
9023from r-value derived to base).
9024</p>
9025
9026<p><i>[Redmond: punt for the moment. We haven't decided yet whether we
9027  want to fix auto_ptr for C++-0x, or remove it and replace it with
9028  move_ptr and unique_ptr.]</i></p>
9029
9030
9031<p><i>[
9032Oxford 2007: Recommend NAD.  We're just going to deprecate it.  It still works for simple use cases
9033and people know how to deal with it.  Going forward <tt>unique_ptr</tt> is the recommended
9034tool.
9035]</i></p>
9036
9037
9038<p><i>[
90392007-11-09: Reopened at the request of David Abrahams, Alisdair Meredith and Gabriel Dos Reis.
9040]</i></p>
9041
9042
9043<p><i>[
90442009-07 Frankfurt
9045]</i></p>
9046
9047
9048<blockquote>
9049This is a complicated issue, so we agreed to defer discussion until
9050later in the week so that interested parties can read up on it.
9051</blockquote>
9052
9053<p><i>[
9054209-10-04 Daniel adds:
9055]</i></p>
9056
9057
9058<blockquote>
9059<p>
9060I suggest to close this issue as NAD. The reasons are two-fold: First, the
9061suggested proposed resolution uses no longer appropriate language means
9062to solve this issue, which has the effect that the recommended resolution is
9063another - but better - form of hack. Second, either following the suggested
9064resolution or the now more natural alternative via the added member set
9065</p>
9066
9067<blockquote><pre>template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;&amp;&amp;) throw();
9068template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;&amp;&amp;) throw();
9069</pre></blockquote>
9070
9071<p>
9072would still have a non-zero probability to break user-code that actively
9073references <tt>auto_ptr_ref</tt>. This risk seems to indicate that a
9074decision which would not touch the current spec of <tt>auto_ptr</tt> at
9075all (but deprecating it) and instead recommending to use
9076<tt>unique_ptr</tt> for new code instead might have the best
9077cost-benefit ratio. IMO the current solution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1100">1100</a> can
9078be considered as an active user-support for this transition.
9079</p>
9080</blockquote>
9081
9082<p><i>[
90832009-10 Santa Cruz:
9084]</i></p>
9085
9086
9087<blockquote>
9088Mark as NAD. Alisdair will open a new issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1247">1247</a>) with
9089proposed wording to handle <tt>auto_ptr_ref</tt>.
9090</blockquote>
9091
9092
9093
9094<p><b>Proposed resolution:</b></p>
9095<p>
9096Change the synopsis in D.10.1 [auto.ptr]:
9097</p>
9098
9099<blockquote><pre>namespace std { 
9100  <del>template &lt;class Y&gt; struct auto_ptr_ref {};</del>
9101
9102  <ins>// exposition only</ins>
9103  <ins>template &lt;class T&gt; struct constant_object;</ins>
9104
9105  <ins>// exposition only</ins>
9106  <ins>template &lt;class T&gt;</ins>
9107  <ins>struct cannot_transfer_ownership_from</ins>
9108    <ins>: constant_object&lt;T&gt; {};</ins>
9109
9110  template &lt;class X&gt; class auto_ptr { 
9111  public: 
9112    typedef X element_type; 
9113
9114    // D.9.1.1 construct/copy/destroy: 
9115    explicit auto_ptr(X* p =0) throw(); 
9116    auto_ptr(auto_ptr&amp;) throw(); 
9117    template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;<ins> const</ins>&amp;) throw(); 
9118    auto_ptr&amp; operator=(auto_ptr&amp;) throw(); 
9119    template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del>) throw();
9120    <del>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw();</del>
9121    ~auto_ptr() throw(); 
9122
9123    // D.9.1.2 members: 
9124    X&amp; operator*() const throw();
9125    X* operator-&gt;() const throw();
9126    X* get() const throw();
9127    X* release() throw();
9128    void reset(X* p =0) throw();
9129
9130    <del>// D.9.1.3 conversions:</del>
9131    <del>auto_ptr(auto_ptr_ref&lt;X&gt;) throw();</del>
9132    <del>template&lt;class Y&gt; operator auto_ptr_ref&lt;Y&gt;() throw();</del>
9133    <del>template&lt;class Y&gt; operator auto_ptr&lt;Y&gt;() throw();</del>
9134
9135    <ins>// exposition only</ins>
9136    <ins>template&lt;class U&gt;</ins>
9137    <ins>auto_ptr(U&amp; rhs, typename cannot_transfer_ownership_from&lt;U&gt;::error = 0);</ins>
9138  }; 
9139
9140  template &lt;&gt; class auto_ptr&lt;void&gt; 
9141  { 
9142  public: 
9143    typedef void element_type; 
9144  }; 
9145
9146}
9147</pre></blockquote>
9148
9149<p>
9150Remove D.10.1.3 [auto.ptr.conv].
9151</p>
9152
9153<p>
9154Change D.10.1 [auto.ptr], p3:
9155</p>
9156
9157<blockquote>
9158The <tt>auto_ptr</tt> provides a semantics of strict ownership. An
9159<tt>auto_ptr</tt> owns the object it holds a pointer to. Copying an
9160<tt>auto_ptr</tt> copies the pointer and transfers ownership to the
9161destination. If more than one <tt>auto_ptr</tt> owns the same object at
9162the same time the behavior of the program is undefined. <ins>Templates
9163<tt>constant_object</tt> and <tt>cannot_transfer_ownership_from</tt>,
9164and the final constructor of <tt>auto_ptr</tt> are for exposition only.
9165For any types <tt>X</tt> and <tt>Y</tt>, initializing
9166<tt>auto_ptr&lt;X&gt;</tt> from <tt>const auto_ptr&lt;Y&gt;</tt> is
9167ill-formed, diagnostic required.</ins> [<i>Note:</i> The uses of
9168<tt>auto_ptr</tt> include providing temporary exception-safety for
9169dynamically allocated memory, passing ownership of dynamically allocated
9170memory to a function, and returning dynamically allocated memory from a
9171function. <tt>auto_ptr</tt> does not meet the <tt>CopyConstructible</tt>
9172and <tt>Assignable</tt> requirements for Standard Library container
9173elements and thus instantiating a Standard Library container with an
9174<tt>auto_ptr</tt> results in undefined behavior. <i>-- end note</i>]
9175</blockquote>
9176
9177<p>
9178Change D.10.1.1 [auto.ptr.cons], p5:
9179</p>
9180
9181<blockquote>
9182<pre>template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;<ins> const</ins>&amp; a) throw();
9183</pre>
9184<blockquote>
9185<p>
9186<i>Requires:</i> <tt>Y*</tt> can be implicitly converted to <tt>X*</tt>.
9187</p>
9188<p>
9189<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>.
9190</p>
9191<p>
9192<i>Postconditions:</i> <tt>*this</tt> holds the pointer returned from <tt>a.release()</tt>.
9193</p>
9194</blockquote>
9195</blockquote>
9196
9197<p>
9198Change D.10.1.1 [auto.ptr.cons], p10:
9199</p>
9200
9201<blockquote>
9202<pre>template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del> a) throw();
9203</pre>
9204<blockquote>
9205<p>
9206<i>Requires:</i> <tt>Y*</tt> can be implicitly converted to <tt>X*</tt>.
9207The expression <tt>delete get()</tt> is well formed.
9208</p>
9209<p>
9210<i>Effects:</i> Calls <tt>reset(a.release())</tt>.
9211</p>
9212<p>
9213<i>Returns:</i> <tt>*this</tt>.
9214</p>
9215</blockquote>
9216</blockquote>
9217
9218
9219
9220
9221
9222
9223<hr>
9224<h3><a name="466"></a>466. basic_string ctor should prevent null pointer error</h3>
9225<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#NAD">NAD</a>
9226 <b>Submitter:</b> Daniel Frey <b>Opened:</b> 2004-06-10  <b>Last modified:</b> 2009-07-14</p>
9227<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>
9228<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
9229<p><b>Discussion:</b></p>
9230<p>
9231Today, my colleagues and me wasted a lot of time. After some time, I
9232found the problem. It could be reduced to the following short example:
9233</p>
9234
9235<pre>  #include &lt;string&gt;
9236  int main() { std::string( 0 ); }
9237</pre>
9238
9239<p>The problem is that the tested compilers (GCC 2.95.2, GCC 3.3.1 and
9240Comeau online) compile the above without errors or warnings! The
9241programs (at least for the GCC) resulted in a SEGV.</p>
9242
9243<p>I know that the standard explicitly states that the ctor of string
9244requires a char* which is not zero. STLs could easily detect the above
9245case with a private ctor for basic_string which takes a single 'int'
9246argument. This would catch the above code at compile time and would not
9247ambiguate any other legal ctors.</p>
9248
9249<p><i>[Redmond: No great enthusiasm for doing this.  If we do,
9250  however, we want to do it for all places that take <tt>charT*</tt>
9251  pointers, not just the single-argument constructor.  The other
9252  question is whether we want to catch this at compile time (in which
9253  case we catch the error of a literal 0, but not an expression whose
9254  value is a null pointer), at run time, or both.
9255  Recommend NAD.  Relegate this functionality to debugging implementations.]</i></p>
9256
9257
9258<p><i>[
9259Post Summit: Alisdair requests this be re-opened as several new language facilities are
9260designed to solve exactly this kind of problem.
9261]</i></p>
9262
9263
9264<p><i>[
9265Batavia (2009-05):
9266]</i></p>
9267
9268<blockquote>
9269We are unable to achieve consensus on an approach to a resolution.
9270There is some sentiment for treating this as a QOI matter.
9271It is also possible
9272that when <tt>string</tt> is brought into the concepts world,
9273this issue might be addressed in that context.
9274</blockquote>
9275
9276<p><i>[
92772009-07 Frankfurt
9278]</i></p>
9279
9280
9281<blockquote>
9282<p>
9283We considered three options:
9284</p>
9285
9286<ul>
9287<li>The proposed resolution.</li>
9288<li>NAD</li>
9289<li>Interpret a null pointer as the empty string.</li>
9290</ul>
9291
9292<p>
9293The consensus was NAD.
9294</p>
9295</blockquote>
9296
9297
9298
9299<p><b>Proposed resolution:</b></p>
9300<p>
9301Add to the synopsis in 21.4 [basic.string]
9302</p>
9303
9304<blockquote><pre><ins>basic_string( nullptr_t ) = delete;</ins>
9305</pre></blockquote>
9306
9307
9308
9309
9310
9311<hr>
9312<h3><a name="470"></a>470. accessing containers from their elements' special functions</h3>
9313<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
9314 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2004-06-28  <b>Last modified:</b> 2007-04-18</p>
9315<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>
9316<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>
9317<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
9318<p><b>Discussion:</b></p>
9319
9320<p>
9321The standard doesn't prohibit the destructors (or any other special
9322functions) of containers' elements invoked from a member function
9323of the container from "recursively" calling the same (or any other)
9324member function on the same container object, potentially while the
9325container is in an intermediate state, or even changing the state
9326of the container object while it is being modified. This may result
9327in some surprising (i.e., undefined) behavior.
9328</p>
9329
9330<p>Read email thread starting with c++std-lib-13637 for more.</p>
9331
9332
9333
9334<p><b>Proposed resolution:</b></p>
9335
9336<p>Add to Container Requirements the following new paragraph:</p>
9337
9338<pre>    Unless otherwise specified, the behavior of a program that
9339    invokes a container member function f from a member function
9340    g of the container's value_type on a container object c that
9341    called g from its mutating member function h, is undefined.
9342    I.e., if v is an element of c, directly or indirectly calling
9343    c.h() from v.g() called from c.f(), is undefined.
9344</pre>
9345
9346<p><i>[Redmond: This is a real issue, but it's probably a clause 17
9347  issue, not clause 23.  We get the same issue, for example, if we
9348  try to destroy a stream from one of the stream's callback functions.]</i></p>
9349
9350  
9351
9352
9353<p><b>Rationale:</b></p>
9354<p>
9355Recommend NAD.  We agree this is an issue, but not a defect.
9356We believe that there is no wording we can put in the standard
9357that will cover all cases without introducing unfortunate
9358corner cases.
9359</p>
9360
9361
9362
9363
9364
9365<hr>
9366<h3><a name="472"></a>472. Missing "Returns" clause in std::equal_range</h3>
9367<p><b>Section:</b> 25.4.3.3 [equal.range] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
9368 <b>Submitter:</b> Prateek R Karandikar <b>Opened:</b> 2004-06-30  <b>Last modified:</b> 2006-12-30</p>
9369<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#equal.range">issues</a> in [equal.range].</p>
9370<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
9371<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a></p>
9372<p><b>Discussion:</b></p>
9373<p>
9374There is no "Returns:" clause for std::equal_range, which returns non-void.
9375</p>
9376
9377
9378<p><b>Proposed resolution:</b></p>
9379
9380
9381<p><b>Rationale:</b></p>
9382<p>Fixed as part of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a>.</p>
9383
9384
9385
9386
9387
9388
9389<hr>
9390<h3><a name="476"></a>476. Forward Iterator implied mutability</h3>
9391<p><b>Section:</b> 24.2.3 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
9392 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2004-07-09  <b>Last modified:</b> 2007-01-15</p>
9393<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward.iterators">issues</a> in [forward.iterators].</p>
9394<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
9395<p><b>Discussion:</b></p>
9396
9397<p>24.1/3 says:</p>
9398<blockquote><p>
9399  Forward iterators satisfy all the requirements of the input and
9400  output iterators and can be used whenever either kind is specified
9401</p></blockquote>
9402
9403<p>
9404The problem is that satisfying the requirements of output iterator
9405means that you can always assign *something* into the result of
9406dereferencing it.  That makes almost all non-mutable forward
9407iterators non-conforming.  I think we need to sever the refinement
9408relationship between forward iterator and output iterator.
9409</p>
9410
9411<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>.  But this is not a dup.</p>
9412
9413
9414
9415<p><b>Proposed resolution:</b></p>
9416
9417
9418<p><b>Rationale:</b></p>
9419<p>Yes, 24.1/3 does say that. But it's introductory material. The
9420precise specification is in 24.1.3, and the requrements table there is
9421right.  We don't need to fine-tune introductory wording.  (Especially
9422since this wording is likely to be changed as part of the iterator
9423overhaul.)</p> 
9424
9425
9426
9427
9428
9429<hr>
9430<h3><a name="477"></a>477. Operator-&gt; for const forward iterators</h3>
9431<p><b>Section:</b> 24.2.3 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
9432 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2004-07-11  <b>Last modified:</b> 2007-01-15</p>
9433<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward.iterators">issues</a> in [forward.iterators].</p>
9434<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
9435<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a></p>
9436<p><b>Discussion:</b></p>
9437<p>
9438The Forward Iterator requirements table contains the following:
9439</p>
9440<pre> expression  return type         operational  precondition
9441                                  semantics
9442  ==========  ==================  ===========  ==========================
9443  a-&gt;m        U&amp; if X is mutable, (*a).m       pre: (*a).m is well-defined.
9444              otherwise const U&amp;
9445
9446  r-&gt;m        U&amp;                  (*r).m       pre: (*r).m is well-defined.
9447</pre>
9448
9449<p>
9450The first line is exactly right.  The second line is wrong.  Basically
9451it implies that the const-ness of the iterator affects the const-ness
9452of referenced members.  But Paragraph 11 of [lib.iterator.requirements] says:
9453</p>
9454
9455<blockquote><p>
9456   In the following sections, a and b denote values of type const X, n
9457   denotes a value of the difference type Distance, u, tmp, and m
9458   denote identifiers, r denotes a value of X&amp;, t denotes a value of
9459   value type T, o denotes a value of some type that is writable to
9460   the output iterator.
9461</p></blockquote>
9462
9463<p>AFAICT if we need the second line at all, it should read the same
9464as the first line.</p>
9465
9466<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a></p>
9467
9468
9469<p><b>Proposed resolution:</b></p>
9470
9471
9472<p><b>Rationale:</b></p>
9473<p>The LWG agrees that this is a real problem.  Marked as a DUP
9474  because the LWG chose to adopt the solution proposed in
9475  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>.
9476</p>
9477
9478
9479
9480
9481
9482<hr>
9483<h3><a name="479"></a>479. Container requirements and placement new</h3>
9484<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#Dup">Dup</a>
9485 <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2004-08-01  <b>Last modified:</b> 2007-04-18</p>
9486<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>
9487<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>
9488<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
9489<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#580">580</a></p>
9490<p><b>Discussion:</b></p>
9491<p>Nothing in the standard appears to make this program ill-formed:</p>
9492
9493<pre>  struct C {
9494    void* operator new( size_t s ) { return ::operator new( s ); }
9495    // NOTE: this hides in-place and nothrow new
9496  };
9497
9498  int main() {
9499    vector&lt;C&gt; v;
9500    v.push_back( C() );
9501  }
9502</pre>
9503
9504<p>Is that intentional?  We should clarify whether or not we intended
9505  to require containers to support types that define their own special
9506  versions of <tt>operator new</tt>.</p>
9507
9508<p><i>[
9509Lillehammer: A container will definitely never use this overridden
9510operator new, but whether it will fail to compile is unclear from the
9511standard.  Are containers supposed to use qualified or unqualified
9512placement new?  20.4.1.1 is somewhat relevant, but the standard
9513doesn't make it completely clear whether containers have to use
9514Allocator::construct(). If containers don't use it, the details of how
9515containers use placement new are unspecified. That is the real bug,
9516but it needs to be fixed as part of the allocator overhaul.  Weak
9517support that the eventual solution should make this code well formed.
9518]</i></p>
9519
9520
9521
9522
9523<p><b>Proposed resolution:</b></p>
9524
9525
9526
9527
9528
9529
9530
9531<hr>
9532<h3><a name="480"></a>480. unary_function and binary_function should have protected nonvirtual destructors</h3>
9533<p><b>Section:</b> 20.7.3 [base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
9534 <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2004-08-19  <b>Last modified:</b> 2006-12-29</p>
9535<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p>
9536<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
9537<p><b>Discussion:</b></p>
9538<p>The classes std::unary_function and std::binary_function are both
9539designed to be inherited from but contain no virtual functions.  This
9540makes it too easy for a novice programmer to write code like
9541binary_function&lt;int, int, int&gt; *p = new plus&lt;int&gt;; delete p;</p>
9542
9543<p>There are two common ways to prevent this source of undefined
9544behavior: give the base class a public virtual destructor, or give it
9545a protected nonvirtual destructor.  Since unary_function and
9546binary_function have no other virtual functions, (note in particular
9547the absence of an operator()() ), it would cost too much to give them
9548public virtual destructors.  Therefore, they should be given protected
9549nonvirtual destructors.</p>
9550
9551
9552<p><b>Proposed resolution:</b></p>
9553<p>Change Paragraph 20.3.1 of the Standard from</p>
9554<pre>    template &lt;class Arg, class Result&gt;
9555    struct unary_function {
9556        typedef Arg argument_type;
9557        typedef Result result_type;
9558    };
9559
9560    template &lt;class Arg1, class Arg2, class Result&gt;
9561    struct binary_function {
9562        typedef Arg1 first_argument_type;
9563        typedef Arg2 second_argument_type;
9564        typedef Result result_type;
9565    };
9566</pre>
9567
9568<p>to</p>
9569<pre>    template &lt;class Arg, class Result&gt;
9570        struct unary_function {
9571        typedef Arg argument_type;
9572        typedef Result result_type;
9573    protected:
9574        ~unary_function() {}
9575    };
9576
9577    template &lt;class Arg1, class Arg2, class Result&gt;
9578    struct binary_function {
9579        typedef Arg1 first_argument_type;
9580        typedef Arg2 second_argument_type;
9581        typedef Result result_type;
9582    protected:
9583        ~binary_function() {}
9584    };
9585</pre>
9586
9587
9588<p><b>Rationale:</b></p>
9589<p>The LWG doesn't believe the existing definition causes anybody any
9590  concrete harm.</p>
9591
9592
9593
9594
9595
9596<hr>
9597<h3><a name="481"></a>481. unique's effects on the range [result, last)</h3>
9598<p><b>Section:</b> 25.3.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
9599 <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 2004-08-30  <b>Last modified:</b> 2006-12-27</p>
9600<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
9601<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
9602<p><b>Discussion:</b></p>
9603<p>
9604The standard says that unique(first, last) "eliminates all but the
9605first element from every consecutive group of equal elements" in
9606[first, last) and returns "the end of the resulting range".  So a
9607postcondition is that [first, result) is the same as the old [first,
9608last) except that duplicates have been eliminated.
9609</p>
9610
9611<p>What postconditions are there on the range [result, last)?  One
9612  might argue that the standard says nothing about those values, so
9613  they can be anything.  One might also argue that the standard
9614  doesn't permit those values to be changed, so they must not be.
9615  Should the standard say something explicit one way or the other?</p>
9616
9617
9618
9619<p><b>Proposed resolution:</b></p>
9620<p>
9621</p>
9622
9623
9624<p><b>Rationale:</b></p>
9625<p>We don't want to make many guarantees about what's in [result,
9626end). Maybe we aren't being quite explicit enough about not being
9627explicit, but it's hard to think that's a major problem.</p>
9628
9629
9630
9631
9632
9633<hr>
9634<h3><a name="482"></a>482. Swapping pairs</h3>
9635<p><b>Section:</b> 20.3.4 [pairs], 20.5 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
9636 <b>Submitter:</b> Andrew Koenig <b>Opened:</b> 2004-09-14  <b>Last modified:</b> 2007-05-06</p>
9637<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>
9638<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>
9639<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
9640<p><b>Discussion:</b></p>
9641<p>(Based on recent comp.std.c++ discussion)</p>
9642
9643<p>Pair (and tuple) should specialize std::swap to work in terms of
9644std::swap on their components.  For example, there's no obvious reason
9645why swapping two objects of type pair&lt;vector&lt;int&gt;,
9646list&lt;double&gt; &gt; should not take O(1).</p>
9647
9648<p><i>[Lillehammer: We agree it should be swappable.  Howard will
9649  provide wording.]</i></p>
9650
9651
9652<p><i>[
9653Post Oxford:  We got <tt>swap</tt> for <tt>pair</tt> but accidently
9654missed <tt>tuple</tt>.  <tt>tuple::swap</tt> is being tracked by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>.
9655]</i></p>
9656
9657
9658
9659
9660<p><b>Proposed resolution:</b></p>
9661<p>
9662Wording provided in
9663<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html#20.2.3%20-%20Pairs">N1856</a>.
9664</p>
9665
9666<p><b>Rationale:</b></p>
9667<p>
9668Recommend NAD, fixed by 
9669<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html#20.2.3%20-%20Pairs">N1856</a>.
9670</p>
9671
9672
9673
9674
9675
9676<hr>
9677<h3><a name="483"></a>483. Heterogeneous equality and EqualityComparable</h3>
9678<p><b>Section:</b> 25.2 [alg.nonmodifying], 25.3 [alg.modifying.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
9679 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2004-09-20  <b>Last modified:</b> 2007-01-15</p>
9680<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
9681<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a></p>
9682<p><b>Discussion:</b></p>
9683<p>c++std-lib-14262</p>
9684
9685<p>[lib.alg.find] requires T to be EqualityComparable:</p>
9686
9687<pre>template &lt;class InputIterator, class T&gt;
9688   InputIterator find(InputIterator first, InputIterator last,
9689                      const T&amp; value);
9690</pre>
9691
9692<p>
9693However the condition being tested, as specified in the Effects
9694clause, is actually *i == value, where i is an InputIterator.
9695</p>
9696
9697<p>
9698The two clauses are in agreement only if the type of *i is T, but this
9699isn't necessarily the case. *i may have a heterogeneous comparison
9700operator that takes a T, or a T may be convertible to the type of *i.
9701</p>
9702
9703<p>Further discussion (c++std-lib-14264): this problem affects a
9704  number of algorithsm in clause 25, not just <tt>find</tt>.  We
9705  should try to resolve this problem everywhere it appears.</p>
9706
9707
9708<p><b>Proposed resolution:</b></p>
9709
9710<p>[lib.alg.find]:</p>
9711<blockquote><p>
9712   Remove [lib.alg.find]/1.
9713</p></blockquote>
9714
9715<p>[lib.alg.count]:</p>
9716<blockquote><p>
9717   Remove [lib.alg.count]/1.
9718</p></blockquote>
9719
9720<p>[lib.alg.search]:</p>
9721<blockquote><p>
9722   Remove "Type T is EqualityComparable (20.1.1), " from [lib.alg.search]/4.
9723</p></blockquote>
9724
9725<p>[lib.alg.replace]:</p>
9726
9727<blockquote>
9728   <p>
9729   Remove [lib.alg.replace]/1.
9730   Replace [lb.alg.replace]/2 with:
9731   </p>
9732
9733       <blockquote><p>
9734       For every iterator i in the range [first, last) for which *i == value
9735       or pred(*i) holds perform *i = new_value.
9736       </p></blockquote>
9737
9738   <p>
9739   Remove the first sentence of /4.
9740   Replace the beginning of /5 with:
9741   </p>
9742
9743       <blockquote><p>
9744       For every iterator i in the range [result, result + (last -
9745       first)), assign to *i either...
9746       </p></blockquote>
9747
9748   <p>(Note the defect here, current text says assign to i, not *i).</p>
9749</blockquote>
9750
9751<p>[lib.alg.fill]:</p>
9752
9753<blockquote>
9754   <p>
9755   Remove "Type T is Assignable (23.1), " from /1.
9756   Replace /2 with:
9757   </p>
9758
9759       <blockquote><p>
9760       For every iterator i in the range [first, last) or [first, first + n),
9761       perform *i = value.
9762       </p></blockquote>
9763</blockquote>
9764
9765<p>[lib.alg.remove]:</p>
9766<blockquote><p>
9767   Remove /1.
9768   Remove the first sentence of /6.
9769</p></blockquote>
9770
9771
9772
9773<p><b>Rationale:</b></p>
9774<p>Duplicate of (a subset of) issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a>.</p>
9775
9776
9777
9778
9779
9780
9781<hr>
9782<h3><a name="484"></a>484. Convertible to T</h3>
9783<p><b>Section:</b> 24.2.1 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
9784 <b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2004-09-16  <b>Last modified:</b> 2009-10-26</p>
9785<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>
9786<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
9787<p><b>Discussion:</b></p>
9788<p>From comp.std.c++:</p>
9789
9790<p>
9791I note that given an input iterator a for type T, 
9792then *a only has to be "convertable to T", not actually of type T.
9793</p>
9794
9795<p>Firstly, I can't seem to find an exact definition of "convertable to T". 
9796While I assume it is the obvious definition (an implicit conversion), I 
9797can't find an exact definition. Is there one?</p>
9798
9799<p>Slightly more worryingly, there doesn't seem to be any restriction on 
9800the this type, other than it is "convertable to T". Consider two input 
9801iterators a and b. I would personally assume that most people would 
9802expect *a==*b would perform T(*a)==T(*b), however it doesn't seem that 
9803the standard requires that, and that whatever type *a is (call it U) 
9804could have == defined on it with totally different symantics and still 
9805be a valid inputer iterator.</p>
9806
9807<p>Is this a correct reading? When using input iterators should I write 
9808T(*a) all over the place to be sure that the object i'm using is the 
9809class I expect?</p>
9810
9811<p>This is especially a nuisance for operations that are defined to be
9812  "convertible to bool".  (This is probably allowed so that
9813  implementations could return say an int and avoid an unnessary
9814  conversion. However all implementations I have seen simply return a
9815  bool anyway.  Typical implemtations of STL algorithms just write
9816  things like <tt>while(a!=b &amp;&amp; *a!=0)</tt>.  But strictly
9817  speaking, there are lots of types that are convertible to T but
9818  that also overload the appropriate operators so this doesn't behave
9819  as expected.</p>
9820
9821<p>If we want to make code like this legal (which most people seem to
9822  expect), then we'll need to tighten up what we mean by "convertible
9823  to T".</p>
9824
9825<p><i>[Lillehammer: The first part is NAD, since "convertible" is
9826 well-defined in core. The second part is basically about pathological
9827 overloads. It's a minor problem but a real one. So leave open for
9828 now, hope we solve it as part of iterator redesign.]</i></p>
9829
9830
9831<p><i>[
98322009-07-28 Reopened by Alisdair.  No longer solved by concepts.
9833]</i></p>
9834
9835
9836<p><i>[
98372009-10 Santa Cruz:
9838]</i></p>
9839
9840
9841<blockquote>
9842Mark as NAD Future. We agree there's an issue, but there is no
9843proposed solution at this time and this will be solved by concepts in
9844the future.
9845</blockquote>
9846
9847
9848
9849<p><b>Proposed resolution:</b></p>
9850
9851
9852<p><b>Rationale:</b></p>
9853<p><i>[
9854San Francisco:
9855]</i></p>
9856
9857
9858<blockquote>
9859Solved by
9860<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2758.pdf">N2758</a>.
9861</blockquote>
9862
9863
9864
9865
9866
9867
9868
9869<hr>
9870<h3><a name="486"></a>486. min/max CopyConstructible requirement is too strict</h3>
9871<p><b>Section:</b> 25.4.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
9872 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2004-10-13  <b>Last modified:</b> 2006-12-30</p>
9873<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>
9874<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
9875<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#281">281</a></p>
9876<p><b>Discussion:</b></p>
9877<p>A straightforward implementation of these algorithms does not need to
9878copy T.</p>
9879
9880
9881<p><b>Proposed resolution:</b></p>
9882<p>drop the the words "and CopyConstructible" from paragraphs 1 and 4</p>
9883
9884
9885<p><b>Rationale:</b></p>
9886
9887
9888
9889
9890
9891
9892<hr>
9893<h3><a name="487"></a>487. Allocator::construct is too limiting</h3>
9894<p><b>Section:</b> 20.2.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
9895 <b>Submitter:</b> Dhruv Matani <b>Opened:</b> 2004-10-17  <b>Last modified:</b> 2006-12-30</p>
9896<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>
9897<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
9898<p><b>Discussion:</b></p>
9899<p>
9900The standard's version of allocator::construct(pointer,
9901const_reference) severely limits what you can construct using this
9902function.  Say you can construct a socket from a file descriptor. Now,
9903using this syntax, I first have to manually construct a socket from
9904the fd, and then pass the constructed socket to the construct()
9905function so it will just to an uninitialized copy of the socket I
9906manually constructed. Now it may not always be possible to copy
9907construct a socket eh! So, I feel that the changes should go in the
9908allocator::construct(), making it:
9909</p>
9910<pre>    template&lt;typename T&gt;
9911    struct allocator{
9912      template&lt;typename T1&gt;
9913      void construct(pointer T1 const&amp; rt1);
9914    };
9915</pre>
9916
9917<p>
9918Now, the ctor of the class T which matches the one that takes a T1 can
9919be called! Doesn't that sound great?
9920</p>
9921
9922
9923<p><b>Proposed resolution:</b></p>
9924
9925
9926<p><b>Rationale:</b></p>
9927<p>NAD. STL uses copying all the time, and making it possible for
9928  allocators to construct noncopyable objects is useless in the
9929  absence of corresponding container changes. We might consider this
9930  as part of a larger redesign of STL.</p>
9931
9932
9933
9934
9935
9936<hr>
9937<h3><a name="489"></a>489. std::remove / std::remove_if wrongly specified</h3>
9938<p><b>Section:</b> 25.3.8 [alg.remove] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
9939 <b>Submitter:</b> Thomas Mang <b>Opened:</b> 2004-12-12  <b>Last modified:</b> 2006-12-27</p>
9940<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.remove">issues</a> in [alg.remove].</p>
9941<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
9942<p><b>Discussion:</b></p>
9943<p>In Section 25.2.7 [lib.alg.remove], paragraphs 1 to 5 describe the
9944behavior of the mutating sequence operations std::remove and
9945std::remove_if. However, the wording does not reflect the intended
9946behavior [Note: See definition of intended behavior below] of these
9947algorithms, as it is known to the C++ community [1].
9948</p>
9949
9950
9951
9952<p>1) Analysis of current wording:</p>
9953
9954
9955<p>25.2.7 [lib.alg.remove], paragraph 2:</p>
9956
9957<p>Current wording says:
9958"Effects: Eliminates all the elements referred to by iterator i in the
9959range [first, last) for which the following corresponding conditions
9960hold: *i == value, pred(*i) != false."</p>
9961
9962<p>
9963This sentences expresses specifically that all elements denoted by the
9964(original) range [first, last) for which the corresponding condition
9965hold will be eliminated. Since there is no formal definition of the term
9966"eliminate" provided, the meaning of "eliminate" in everyday language
9967implies that as postcondition, no element in the range denoted by
9968[first, last) will hold the corresponding condition on reiteration over
9969the range [first, last).
9970</p>
9971
9972<p>
9973However, this is neither the intent [Note: See definition of intended
9974behavior below] nor a general possible approach. It can be easily proven
9975that if all elements of the original range[first, last) will hold the
9976condition, it is not possible to substitute them by an element for which
9977the condition will not hold.
9978</p>
9979
9980
9981<p>25.2.7 [lib.alg.remove], paragraph 3:</p>
9982
9983<p>
9984Current wording says:
9985"Returns: The end of the resulting range."
9986</p>
9987
9988<p>
9989The resulting range is not specified. In combination with 25.2.7
9990[lib.alg.remove], paragraph 2, the only reasonable interpretation of
9991this so-called resulting range is the range [first,last) - thus
9992returning always the ForwardIterator 'last' parameter.
9993</p>
9994
9995
9996<p>
999725.2.7 [lib.alg.remove], paragraph 4:
9998</p>
9999
10000<p>
10001Current wording says:
10002"Notes: Stable: the relative order of the elements that are not removed
10003is the same as their relative order in the original range"
10004</p>
10005
10006<p>
10007This sentences makes use of the term "removed", which is neither
10008specified, nor used in a previous paragraph (which uses the term
10009"eliminate"), nor unamgiuously separated from the name of the algorithm.
10010</p>
10011
10012
10013<p>2) Description of intended behavior:</p>
10014
10015<p>
10016For the rest of this Defect Report, it is assumed that the intended
10017behavior was that all elements of the range [first, last) which do not
10018hold the condition *i == value (std::remove) or  pred(*i) != false
10019(std::remove_if)], call them s-elements [Note: s...stay], will be placed
10020into a contiguous subrange of [first, last), denoted by the iterators
10021[first, return value). The number of elements in the resulting range
10022[first, return value) shall be equal to the number of s-elements in the
10023original range [first, last). The relative order of the elements in the
10024resulting subrange[first, return value) shall be the same as the
10025relative order of the corresponding elements in the original range. It
10026is undefined whether any elements in the resulting subrange [return
10027value, last) will hold the corresponding condition, or not.
10028</p>
10029
10030<p>
10031All implementations known to the author of this Defect Report comply
10032with this intent. Since the intent  of the behavior (contrary to the
10033current wording) is also described in various utility references serving
10034the C++ community [1], it is not expected that fixing the paragraphs
10035will influence current code - unless the code relies on the behavior as
10036it is described by current wording and the implementation indeed
10037reflects the current wording, and not the intent.
10038</p>
10039
10040
10041
10042<p>3) Proposed fixes:</p>
10043
10044
10045<p>Change 25.2.7 [lib.alg.remove], paragraph 2 to:</p>
10046
10047<p>
10048"Effect: Places all the elements referred to by iterator i in the range
10049[first, last) for which the following corresponding conditions hold :
10050!(*i == value), pred(*i) == false into the subrange [first, k) of the
10051original range, where k shall denote a value of type ForwardIterator. It
10052is undefined whether any elements in the resulting subrange [k, last)
10053will hold the corresponding condition, or not."
10054</p>
10055
10056<p>Comments to the new wording:</p>
10057
10058<p>
10059a) "Places" has no special meaning, and the everyday language meaning
10060should fit.
10061b) The corresponding conditions were negated compared to the current
10062wording, becaue the new wording requires it.
10063c) The wording "of the original range" might be redundant, since any
10064subrange starting at 'first' and containing no more elements than the
10065original range is implicitly a subrange of the original range [first,
10066last).
10067d) The iterator k was introduced instead of "return value" in order to
10068avoid a cyclic dependency on 25.2.7/3. The wording ", where k shall
10069denote a value of type ForwardIterator" might be redundant, because it
10070follows implicitly by 25.2.7/3.
10071e) "Places" does, in the author's opinion, explicitly forbid duplicating
10072any element holding the corresponding condition in the original range
10073[first, last) within the resulting range [first, k). If there is doubt
10074this term might be not unambiguous regarding this, it is suggested that
10075k is specified more closely by the following wording: "k shall denote a
10076value of type ForwardIterator [Note: see d)] so that k - first is equal
10077to the number of elements in the original range [first, last) for which
10078the corresponding condition did hold". This could also be expressed as a
10079separate paragraph "Postcondition:"
10080f) The senctence "It is undefined whether any elements in the resulting
10081subrange [k, last) will hold the corresponding condition, or not." was
10082added consciously so the term "Places" does not imply if the original
10083range [first, last) contains n elements holding the corresponding
10084condition, the identical range[first, last) will also contain exactly n
10085elements holding the corresponding condition after application of the
10086algorithm.
10087</p>
10088
10089<p>
10090Change 25.2.7 [lib.alg.remove], paragraph 3 to:
10091
10092"Returns: The iterator k."
10093</p>
10094
10095<p>
10096Change 25.2.7 [lib.alg.remove], paragraph 4 to:
10097
10098"Notes: Stable: the relative order of the elements that are placed into
10099the subrange [first, return value) shall be the same as their relative
10100order was in the original range [first, last) prior to application of
10101the algorithm."
10102</p>
10103
10104<p>
10105Comments to the new wording:
10106</p>
10107
10108<p>
10109a) the wording "was ...  prior to application of the algorithm" is used
10110to explicitly distinguish the original range not only by means of
10111iterators, but also by a 'chronological' factor from the resulting range
10112[first, return value). It might be redundant.
10113</p>
10114
10115<p>
10116[1]:
10117The wording of these references is not always unambiguous, and provided
10118examples partially contradict verbal description of the algorithms,
10119because the verbal description resembles the problematic wording of
10120ISO/IEC 14882:2003.
10121</p>
10122
10123
10124<p><b>Proposed resolution:</b></p>
10125
10126
10127<p><b>Rationale:</b></p>
10128<p>The LWG believes that the standard is sufficiently clear, and that
10129  there is no evidence of any real-world confusion about this point.</p>
10130
10131
10132
10133
10134
10135<hr>
10136<h3><a name="490"></a>490. std::unique wrongly specified</h3>
10137<p><b>Section:</b> 25.3.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
10138 <b>Submitter:</b> Thomas Mang <b>Opened:</b> 2004-12-12  <b>Last modified:</b> 2006-12-27</p>
10139<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
10140<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
10141<p><b>Discussion:</b></p>
10142<p>In Section 25.2.8 [lib.alg.unique], paragraphs 1 to 3 describe the
10143behavior of the mutating sequence operation std::unique. However, the
10144wording does not reflect the intended behavior [Note: See definition of
10145intended behavior below] of these algorithms, as it is known to the C++
10146community [1].</p>
10147
10148
10149
10150<p>1) Analysis of current wording:</p>
10151
10152
10153<p>25.2.8 [lib.alg.unique], paragraph 1:</p>
10154
10155<p>
10156Current wording says:
10157"Effects: Eliminates all but the first element from every consecutive
10158group of equal elements referred to by the iterator i in the range
10159[first, last) for which the following corresponding conditions hold: *i
10160== *(i - 1) or pred(*i, *(i -1)) != false"
10161</p>
10162
10163<p>
10164This sentences expresses specifically that all elements denoted by the
10165(original) range [first, last) which are not but the first element from
10166a consecutive group of equal elements (where equality is defined as *i
10167== *(i - 1) or pred(*i, *(i - 1)) ! = false) [Note: See DR 202], call
10168them r-elements [Note: r...remove], will be eliminated. Since there is
10169no formal definition of the term "eliminate" provided, it is undefined
10170how this "elimination" takes place. But the meaning of "eliminate" in
10171everyday language seems to disallow explicitly that after application of
10172the algorithm, any r-element will remain at any position of the range
10173[first, last) [2].
10174</p>
10175
10176<p>
10177Another defect in the current wording concerns the iterators used to
10178compare two elements for equality: The current wording contains the
10179expression "(i - 1)", which is not covered by 25/9 [Note: See DR
10180submitted by Thomas Mang regarding invalid iterator arithmetic
10181expressions].
10182</p>
10183
10184
10185<p>
1018625.2.8 [lib.alg.unique], paragraph 2:
10187</p>
10188<p>Current wording says:
10189"Returns: The end of the resulting range."</p>
10190
10191<p>
10192The resulting range is not specified. In combination with 25.2.8
10193[lib.alg.unique], paragraph 1, one reasonable interpretation (in the
10194author's opinion even the only possible interpretation) of this
10195so-called resulting range is the range [first, last) - thus returning
10196always the ForwardIterator 'last' parameter.
10197</p>
10198
10199<p>2) Description of intended behavior:</p>
10200
10201<p>
10202For the rest of this Defect Report, it is assumed that the intended
10203behavior was that all elements denoted by the original range [first,
10204last) which are the first element from a consecutive group of elements
10205for which the corresponding conditions: *(i-1) == *i (for the version of
10206unique without a predicate argument) or pred(*(i-1), *i) ! = false (for
10207the version of unique with a predicate argument) [Note: If such a group
10208of elements consists of only a single element, this is also considered
10209the first element] [Note: See resolutions of DR 202], call them
10210s-elements [Note: s...stay], will be placed into a contiguous subrange
10211of [first, last), denoted by the iterators [first, return value). The
10212number of elements in the resulting range [first, return value) shall be
10213equal to the number of s-elements in the original range [first, last).
10214Invalid iterator arithmetic expressions are expected to be resolved as
10215proposed in DR submitted by Thomas Mang regarding invalid iterator
10216arithmetic expressions. It is also assumed by the author that the
10217relative order of the elements in the resulting subrange [first, return
10218value) shall be the same as the relative order of the corresponding
10219elements (the s-elements) in the original range [Note: If this was not
10220intended behavior, the additional proposed paragraph about stable order
10221will certainly become obsolete].
10222Furthermore, the resolutions of DR 202 are partially considered.
10223</p>
10224
10225<p>
10226All implementations known to the author of this Defect Report comply
10227with this intent [Note: Except possible effects of DR 202]. Since this
10228intent of the behavior (contrary to the current wording) is also
10229described in various utility references serving the C++ community [1],
10230it is not expected that fixing the paragraphs will influence current
10231code [Note: Except possible effects of DR 202] - unless the code relies
10232on the behavior as it is described by current wording and the
10233implementation indeed reflects the current wording, and not the intent.
10234</p>
10235
10236
10237
10238<p>3) Proposed fixes:</p>
10239
10240<p>
10241Change 25.2.8 [lib.alg.unique], paragraph 1 to:
10242</p>
10243
10244<p>
10245"Effect: Places the first element from every consecutive group of
10246elements, referred to by the iterator i in the range [first, last), for
10247which the following conditions hold: *(i-1) == *i (for the version of
10248unique without a predicate argument) or pred(*(i -1), *i) != false (for
10249the version of unique with a predicate argument), into the subrange
10250[first, k) of the original range, where k shall denote a value of type
10251ForwardIterator."
10252</p>
10253
10254<p>Comments to the new wording:</p>
10255
10256<p>
10257a) The new wording was influenced by the resolutions of DR 202. If DR
10258202 is resolved in another way, the proposed wording need also
10259additional review.
10260b) "Places" has no special meaning, and the everyday language meaning
10261should fit.
10262c) The expression "(i - 1)" was left, but is expected that DR submitted
10263by Thomas Mang regarding invalid iterator arithmetic expressions will
10264take this into account.
10265d) The wording "(for the version of unique without a predicate
10266argument)" and "(for the version of unique with a predicate argument)"
10267was added consciously for clarity and is in resemblence with current
1026823.2.2.4 [lib.list.ops], paragraph 19. It might be considered redundant.
10269e) The wording "of the original range" might be redundant, since any
10270subrange starting at first and containing no more elements than the
10271original range is implicitly a subrange of the original range [first,
10272last).
10273f) The iterator k was introduced instead of "return value" in order to
10274avoid a cyclic dependency on 25.2.8 [lib.alg.unique], paragraph 2. The
10275wording ", where k shall denote a value of type ForwardIterator" might
10276be redundant, because it follows implicitly by 25.2.8 [lib.alg.unique],
10277paragraph 2.
10278g) "Places" does, in the author's opinion, explicitly forbid duplicating
10279any s-element in the original range [first, last) within the resulting
10280range [first, k). If there is doubt this term might be not unambiguous
10281regarding this, it is suggested that k is specified more closely by the
10282following wording: "k shall denote a value of type ForwardIterator
10283[Note: See f)] so that k - first is equal to the number of elements in
10284the original range [first, last) being the first element from every
10285consecutive group of elements for which the corresponding condition did
10286hold". This could also be expressed as a separate paragraph
10287"Postcondition:".
10288h) If it is considered that the wording is unclear whether it declares
10289the element of a group which consists of only a single element
10290implicitly to be the first element of this group [Note: Such an
10291interpretation could eventually arise especially in case last - first ==
102921] , the following additional sentence is proposed: "If such a group of
10293elements consists of only a single element, this element is also
10294considered the first element."
10295</p>
10296
10297<p>
10298Change 25.2.8 [lib.alg.unique], paragraph 2 to:
10299"Returns: The iterator k."
10300</p>
10301
10302<p>
10303Add a separate paragraph "Notes:" as 25.2.8 [lib.alg.unique], paragraph
103042a or 3a, or a separate paragraph "Postcondition:" before 25.2.8
10305[lib.alg.unique], paragraph 2 (wording inside {} shall be eliminated if
10306the preceding expressions are used, or the preceding expressions shall
10307be eliminated if wording inside {} is used):
10308</p>
10309
10310<p>
10311"Notes:{Postcondition:} Stable: the relative order of the elements that
10312are placed into the subrange [first, return value {k}) shall be the same
10313as their relative order was in the original range [first, last) prior to
10314application of the algorithm."
10315</p>
10316
10317<p>Comments to the new wording:</p>
10318
10319<p>
10320a) It is assumed by the author that the algorithm was intended to be
10321stable.
10322In case this was not the intent, this paragraph becomes certainly
10323obsolete.
10324b) The wording "was ...  prior to application of the algorithm" is used
10325to explicitly distinguish the original range not only by means of
10326iterators, but also by a 'chronological' factor from the resulting range
10327[first, return value). It might be redundant.
10328</p>
10329
10330<p>
1033125.2.8 [lib.alg.unique], paragraph 3:
10332</p>
10333<p>See DR 239.</p>
10334
10335<p>
103364) References to other DRs:
10337</p>
10338
10339<p>
10340See DR 202, but which does not address any of the problems described in
10341this Defect Report [Note: This DR is supposed to complement DR 202].
10342See DR 239.
10343See DR submitted by Thomas Mang regarding invalid iterator arithmetic
10344expressions.
10345</p>
10346
10347<p>
10348[1]:
10349The wording of these references is not always unambiguous, and provided
10350examples partially contradict verbal description of the algorithms,
10351because the verbal description resembles the problematic wording of
10352ISO/IEC 14882:2003.
10353</p>
10354
10355<p>
10356[2]:
10357Illustration of conforming implementations according to current wording:
10358</p>
10359
10360<p>
10361One way the author of this DR considers how this "elimination" could be
10362achieved by a conforming implementation according to current wording is
10363by substituting each r-element by _any_ s-element [Note: s...stay; any
10364non-r-element], since all r-elements are "eliminated".
10365</p>
10366
10367<p>
10368In case of a sequence consisting of elements being all 'equal' [Note:
10369See DR 202], substituting each r-element by the single s-element is the
10370only possible solution according to current wording.
10371</p>
10372
10373
10374<p><b>Proposed resolution:</b></p>
10375
10376
10377<p><b>Rationale:</b></p>
10378<p>The LWG believes the standard is sufficiently clear. No
10379implementers get it wrong, and changing it wouldn't cause any code to
10380change, so there is no real-world harm here.</p>
10381
10382
10383
10384
10385
10386<hr>
10387<h3><a name="491"></a>491. std::list&lt;&gt;::unique incorrectly specified</h3>
10388<p><b>Section:</b> 23.3.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
10389 <b>Submitter:</b> Thomas Mang <b>Opened:</b> 2004-12-12  <b>Last modified:</b> 2007-02-19</p>
10390<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#list.ops">active issues</a> in [list.ops].</p>
10391<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p>
10392<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
10393<p><b>Discussion:</b></p>
10394<p>In Section 23.3.4.4 [list.ops], paragraphs 19 to 21 describe the
10395behavior of the std::list&lt;T, Allocator&gt;::unique operation. However, the
10396current wording is defective for various reasons.</p>
10397
10398
10399
10400<p>
104011) Analysis of current wording:
10402</p>
10403
10404<p>23.3.4.4 [list.ops], paragraph 19:</p>
10405
10406<p>
10407Current wording says:
10408"Effects:  Eliminates all but the first element from every consecutive
10409group of equal elements referred to by the iterator i in the range
10410[first + 1, last) for which *i == *(i - 1) (for the version of unique
10411with no argument) or pred(*i, *(i -1)) (for the version of unique with a
10412predicate argument) holds."</p>
10413
10414<p>
10415This sentences makes use of the undefined term "Eliminates". Although it
10416is, to a certain degree, reasonable to consider the term "eliminate"
10417synonymous with "erase", using "Erase" in the first place, as the
10418wording of 23.3.4.4 [list.ops], paragraph 15 does, would be clearer.</p>
10419
10420<p>
10421The range of the elements referred to by iterator i is "[first + 1,
10422last)". However, neither "first" nor "last" is defined.</p>
10423
10424<p>
10425The sentence makes three times use of iterator arithmetic expressions (
10426"first + 1", "*i == *(i - 1)", "pred(*i, *(i -1))" ) which is not
10427defined for bidirectional iterator [see DR submitted by Thomas Mang
10428regarding invalid iterator arithmetic expressions].</p>
10429
10430<p>
10431The same problems as pointed out in DR 202 (equivalence relation / order
10432of arguments for pred()) apply to this paragraph.</p>
10433
10434<p>
1043523.3.4.4 [list.ops], paragraph 20:
10436</p>
10437
10438<p>
10439Current wording says:
10440"Throws: Nothing unless an exception in thrown by *i == *(i-1) or
10441pred(*i, *(i - 1))"</p>
10442
10443<p>
10444The sentence makes two times use of invalid iterator arithmetic
10445expressions ( "*i == *(i - 1)", "pred(*i, *(i -1))" ).
10446</p>
10447<p>
10448[Note: Minor typos: "in" / missing dot at end of sentence.]
10449</p>
10450
10451<p>
1045223.3.4.4 [list.ops], paragraph 21:</p>
10453
10454<p>
10455Current wording says:
10456"Complexity: If the range (last - first) is not empty, exactly (last -
10457first) - 1 applications of the corresponding predicate, otherwise no
10458application of the predicate.</p>
10459
10460<p>
10461See DR 315 regarding "(last - first)" not yielding a range.</p>
10462
10463<p>
10464Invalid iterator arithmetic expression "(last - first) - 1" left .</p>
10465
10466
10467<p>2) Description of intended behavior:</p>
10468
10469<p>
10470For the rest of this Defect Report, it is assumed that "eliminate" is
10471supposed to be synonymous to "erase", that "first" is equivalent to an
10472iterator obtained by a call to begin(), "last" is equivalent to an
10473iterator obtained by a call to end(), and that all invalid iterator
10474arithmetic expressions are resolved as described in DR submitted by
10475Thomas Mang regarding invalid iterator arithmetic expressions.</p>
10476
10477<p>
10478Furthermore, the resolutions of DR 202 are considered regarding
10479equivalence relation and order of arguments for a call to pred.</p>
10480
10481<p>
10482All implementations known to the author of this Defect Report comply
10483with these assumptions, apart from the impact of the alternative
10484resolution of DR 202. Except for the changes implied by the resolutions
10485of DR 202, no impact on current code is expected.</p>
10486
10487<p>
104883) Proposed fixes:</p>
10489
10490<p>
10491Change 23.3.4.4 [list.ops], paragraph 19 to:</p>
10492
10493<p>
10494"Effect: Erases all but the first element from every consecutive group
10495of elements, referred to by the iterator i in the range [begin(),
10496end()), for which the following conditions hold: *(i-1) == *i (for the
10497version of unique with no argument) or pred(*(i-1), *i) != false (for
10498the version of unique with a predicate argument)."</p>
10499
10500<p>
10501Comments to the new wording:</p>
10502
10503<p>
10504a) The new wording was influenced by DR 202 and the resolutions
10505presented there. If DR 202 is resolved in another way, the proposed
10506wording need also additional review.
10507b) "Erases" refers in the author's opinion unambiguously to the member
10508function "erase". In case there is doubt this might not be unamgibuous,
10509a direct reference to the member function "erase" is suggested [Note:
10510This would also imply a change of 23.3.4.4 [list.ops], paragraph
1051115.].
10512c) The expression "(i - 1)" was left, but is expected that DR submitted
10513by Thomas Mang regarding invalid iterator arithmetic expressions will
10514take this into account.
10515d) The wording "(for the version of unique with no argument)" and "(for
10516the version of unique with a predicate argument)" was kept consciously
10517for clarity.
10518e) "begin()" substitutes "first", and "end()" substitutes "last". The
10519range need adjustment from "[first + 1, last)" to "[begin(), end())" to
10520ensure a valid range in case of an empty list.
10521f) If it is considered that the wording is unclear whether it declares
10522the element of a group which consists of only a single element
10523implicitly to be the first element of this group [Note: Such an
10524interpretation could eventually arise especially in case size() == 1] ,
10525the following additional sentence is proposed: "If such a group of
10526elements consists of only a single element, this element is also
10527considered the first element."</p>
10528
10529<p>
10530Change 23.3.4.4 [list.ops], paragraph 20 to:</p>
10531
10532<p>
10533"Throws: Nothing unless an exception is thrown by *(i-1) == *i or
10534pred(*(i-1), *i)."</p>
10535
10536<p>
10537Comments to the new wording:</p>
10538
10539<p>
10540a) The wording regarding the conditions is identical to proposed
1054123.3.4.4 [list.ops], paragraph 19. If 23.3.4.4 [list.ops],
10542paragraph 19 is resolved in another way, the proposed wording need also
10543additional review.
10544b) The expression "(i - 1)" was left, but is expected that DR submitted
10545by Thomas Mang regarding invalid iterator arithmetic expressions will
10546take this into account.
10547c) Typos fixed.</p>
10548
10549<p>
10550Change 23.3.4.4 [list.ops], paragraph 21 to:</p>
10551
10552<p>
10553"Complexity: If empty() == false, exactly size() - 1 applications of the
10554corresponding predicate, otherwise no applications of the corresponding
10555predicate."</p>
10556
10557<p>
10558Comments to the new wording:</p>
10559
10560<p>
10561a) The new wording is supposed to also replace the proposed resolution
10562of DR 315, which suffers from the problem of undefined "first" / "last".
10563</p>
10564
10565<p>
105665) References to other DRs:</p>
10567
10568<p>See DR 202.
10569See DR 239.
10570See DR 315.
10571See DR submitted by Thomas Mang regarding invalid iterator arithmetic
10572expressions.</p>
10573
10574
10575
10576<p><b>Proposed resolution:</b></p>
10577
10578
10579<p><b>Rationale:</b></p>
10580<p>"All implementations known to the author of this Defect Report
10581comply with these assumption", and "no impact on current code is
10582expected", i.e. there is no evidence of real-world confusion or
10583harm.</p>
10584
10585
10586
10587
10588
10589<hr>
10590<h3><a name="492"></a>492. Invalid iterator arithmetic expressions</h3>
10591<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#NAD">NAD</a>
10592 <b>Submitter:</b> Thomas Mang <b>Opened:</b> 2004-12-12  <b>Last modified:</b> 2009-07-15</p>
10593<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>
10594<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
10595<p><b>Discussion:</b></p>
10596<p>Various clauses other than clause 25 make use of iterator arithmetic not
10597supported by the iterator category in question.
10598Algorithms in clause 25 are exceptional because of 25 [lib.algorithms],
10599paragraph 9, but this paragraph does not provide semantics to the
10600expression "iterator - n", where n denotes a value of a distance type
10601between iterators.</p>
10602
10603<p>1) Examples of current wording:</p>
10604
10605<p>Current wording outside clause 25:</p>
10606
10607<p>
1060823.2.2.4 [lib.list.ops], paragraphs 19-21: "first + 1", "(i - 1)",
10609"(last - first)"
1061023.3.1.1 [lib.map.cons], paragraph 4: "last - first"
1061123.3.2.1 [lib.multimap.cons], paragraph 4: "last - first"
1061223.3.3.1 [lib.set.cons], paragraph 4: "last - first"
1061323.3.4.1 [lib.multiset.cons], paragraph 4: "last - first"
1061424.4.1 [lib.reverse.iterators], paragraph 1: "(i - 1)"
10615</p>
10616
10617<p>
10618[Important note: The list is not complete, just an illustration. The
10619same issue might well apply to other paragraphs not listed here.]</p>
10620
10621<p>None of these expressions is valid for the corresponding iterator
10622category.</p>
10623
10624<p>Current wording in clause 25:</p>
10625
10626<p>
1062725.1.1 [lib.alg.foreach], paragraph 1: "last - 1"
1062825.1.3 [lib.alg.find.end], paragraph 2: "[first1, last1 -
10629(last2-first2))"
1063025.2.8 [lib.alg.unique], paragraph 1: "(i - 1)"
1063125.2.8 [lib.alg.unique], paragraph 5: "(i - 1)"
10632</p>
10633
10634<p>
10635However, current wording of 25 [lib.algorithms], paragraph 9 covers
10636neither of these four cases:</p>
10637
10638<p>Current wording of 25 [lib.algorithms], paragraph 9:</p>
10639
10640<p>
10641"In the description of the algorithms operator + and - are used for some
10642of the iterator categories for which they do not have to be defined. In
10643these cases the semantics of a+n is the same as that of</p>
10644<pre>{X tmp = a;
10645advance(tmp, n);
10646return tmp;
10647}
10648</pre>
10649<p>and that of b-a is the same as of return distance(a, b)"</p>
10650
10651<p>
10652This paragrpah does not take the expression "iterator - n" into account,
10653where n denotes a value of a distance type between two iterators [Note:
10654According to current wording, the expression "iterator - n" would be
10655resolved as equivalent to "return distance(n, iterator)"]. Even if the
10656expression "iterator - n" were to be reinterpreted as equivalent to
10657"iterator + -n" [Note: This would imply that "a" and "b" were
10658interpreted implicitly as values of iterator types, and "n" as value of
10659a distance type], then 24.3.4/2 interfers because it says: "Requires: n
10660may be negative only for random access and bidirectional iterators.",
10661and none of the paragraphs quoted above requires the iterators on which
10662the algorithms operate to be of random access or bidirectional category.
10663</p>
10664
10665<p>2) Description of intended behavior:</p>
10666
10667<p>
10668For the rest of this Defect Report, it is assumed that the expression
10669"iterator1 + n" and "iterator1 - iterator2" has the semantics as
10670described in current 25 [lib.algorithms], paragraph 9, but applying to
10671all clauses. The expression "iterator1 - n" is equivalent to an
10672result-iterator for which the expression "result-iterator + n" yields an
10673iterator denoting the same position as iterator1 does. The terms
10674"iterator1", "iterator2" and "result-iterator" shall denote the value of
10675an iterator type, and the term "n" shall denote a value of a distance
10676type between two iterators.</p>
10677
10678<p>
10679All implementations known to the author of this Defect Report comply
10680with these assumptions.
10681No impact on current code is expected.</p>
10682
10683<p>3) Proposed fixes:</p>
10684
10685
10686<p>Change 25 [lib.algorithms], paragraph 9 to:</p>
10687
10688<p>
10689"In the description of the algorithms operator + and - are used for some
10690of the iterator categories for which they do not have to be defined. In
10691this paragraph, a and b denote values of an iterator type, and n denotes
10692a value of a distance type between two iterators. In these cases the
10693semantics of a+n is the same as that of</p>
10694<pre>{X tmp = a;
10695advance(tmp, n);
10696return tmp;
10697}
10698</pre>
10699<p>,the semantics of a-n denotes the value of an iterator i for which the
10700following condition holds:
10701advance(i, n) == a,
10702and that of b-a is the same as of
10703return distance(a, b)".
10704</p>
10705
10706<p>Comments to the new wording:</p>
10707
10708<p>
10709a) The wording " In this paragraph, a and b denote values of an iterator
10710type, and n denotes a value of a distance type between two iterators."
10711was added so the expressions "b-a" and "a-n" are distinguished regarding
10712the types of the values on which they operate.
10713b) The wording ",the semantics of a-n denotes the value of an iterator i
10714for which the following condition holds: advance(i, n) == a" was added
10715to cover the expression 'iterator - n'. The wording "advance(i, n) == a"
10716was used to avoid a dependency on the semantics of a+n, as the wording
10717"i + n == a" would have implied. However, such a dependency might well
10718be deserved.
10719c) DR 225 is not considered in the new wording.
10720</p>
10721
10722<p>
10723Proposed fixes regarding invalid iterator arithmetic expressions outside
10724clause 25:</p>
10725
10726<p>
10727Either
10728a) Move modified 25 [lib.algorithms], paragraph 9 (as proposed above)
10729before any current invalid iterator arithmetic expression. In that case,
10730the first sentence of 25 [lib.algorithms], paragraph 9, need also to be
10731modified and could read: "For the rest of this International Standard,
10732...." / "In the description of the following clauses including this
10733...." / "In the description of the text below ..." etc. - anyways
10734substituting the wording "algorithms", which is a straight reference to
10735clause 25.
10736In that case, 25 [lib.algorithms] paragraph 9 will certainly become
10737obsolete.
10738Alternatively,
10739b) Add an appropiate paragraph similar to resolved 25 [lib.algorithms],
10740paragraph 9, to the beginning of each clause containing invalid iterator
10741arithmetic expressions.
10742Alternatively,
10743c) Fix each paragraph (both current wording and possible resolutions of
10744DRs) containing invalid iterator arithmetic expressions separately.
10745</p>
10746
10747<p>5) References to other DRs:</p>
10748
10749<p>
10750See DR 225.
10751See DR 237. The resolution could then also read "Linear in last -
10752first".
10753</p>
10754
10755<p><i>[
10756Bellevue:
10757]</i></p>
10758
10759
10760<blockquote>
10761Keep open and ask Bill to provide wording.
10762</blockquote>
10763
10764<p><i>[
107652009-05-09 Alisdair adds:
10766]</i></p>
10767
10768
10769<blockquote>
10770This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#997">997</a>.
10771</blockquote>
10772
10773<p><i>[
107742009-07 Frankfurt
10775]</i></p>
10776
10777
10778<blockquote>
10779<p>
10780Hinnant: this isn't going to change any user's code or any vendor's implementation.
10781</p>
10782<p>
10783No objection to "NAD without prejudice." If anyone proposes a
10784resolution, the LWG will consider it.
10785</p>
10786<p>
10787Move to NAD.
10788</p>
10789</blockquote>
10790
10791
10792
10793<p><b>Proposed resolution:</b></p>
10794
10795<p><i>[Lillehammer: Minor issue, but real. We have a blanket statement
10796about this in 25/11. But (a) it should be in 17, not 25; and (b) it's
10797not quite broad enough, because there are some arithmetic expressions
10798it doesn't cover. Bill will provide wording.]</i></p>
10799
10800
10801
10802
10803
10804
10805
10806<hr>
10807<h3><a name="493"></a>493. Undefined Expression in Input Iterator Note Title</h3>
10808<p><b>Section:</b> 24.2.1 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
10809 <b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2004-12-13  <b>Last modified:</b> 2006-12-27</p>
10810<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>
10811<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
10812<p><b>Discussion:</b></p>
10813<p>1) In 24.1.1/3, the following text is currently present.</p>
10814
10815<p>"Note: For input iterators, a==b does not imply ++a=++b (Equality does
10816not guarantee the substitution property or referential transparency)."</p>
10817
10818<p>However, when in Table 72, part of the definition of ++r is given as:</p>
10819
10820<p>"pre: r is dereferenceable.
10821post: any copies of the previous value of r are no longer required
10822either to be dereferenceable ..."</p>
10823
10824<p>While a==b does not imply that b is a copy of a, this statement should
10825perhaps still be made more clear.</p>
10826
10827<p>2) There are no changes to intended behaviour</p>
10828
10829<p>
108303) This Note should be altered to say "Note: For input iterators a==b,
10831when its behaviour is defined ++a==++b may still be false (Equality does
10832not guarantee the substitution property or referential transparency).</p>
10833
10834
10835
10836<p><b>Proposed resolution:</b></p>
10837
10838
10839<p><b>Rationale:</b></p>
10840<p>This is descriptive text, not normative, and the meaning is clear.</p>
10841
10842
10843
10844
10845
10846<hr>
10847<h3><a name="494"></a>494. Wrong runtime complexity for associative container's insert and delete</h3>
10848<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#NAD">NAD</a>
10849 <b>Submitter:</b> Hans B os <b>Opened:</b> 2004-12-19  <b>Last modified:</b> 2006-12-27</p>
10850<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
10851<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>
10852<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
10853<p><b>Discussion:</b></p>
10854<p>According to [lib.associative.reqmts] table 69, the runtime comlexity
10855of insert(p, t) and erase(q) can be done in amortized constant time.</p>
10856
10857<p>It was my understanding that an associative container could be
10858implemented as a balanced binary tree.</p>
10859
10860<p>For inser(p, t), you 'll have to iterate to p's next node to see if t
10861can be placed next to p.  Furthermore, the insertion usually takes
10862place at leaf nodes. An insert next to the root node will be done at
10863the left of the root next node</p>
10864
10865<p>So when p is the root node you 'll have to iterate from the root to
10866its next node, which  takes O(log(size)) time in a balanced tree.</p>
10867
10868<p>If you insert all values with insert(root, t) (where root is the
10869root of the tree before insertion) then each insert takes O(log(size))
10870time.  The amortized complexity per insertion will be O(log(size))
10871also.</p>
10872
10873<p>For erase(q), the normal algorithm for deleting a node that has no
10874empty left or right subtree, is to iterate to the next (or previous),
10875which is a leaf node. Then exchange the node with the next and delete
10876the leaf node.  Furthermore according to DR 130, erase should return
10877the next node of the node erased.  Thus erasing the root node,
10878requires iterating to the next node.</p>
10879
10880<p>Now if you empty a map by deleting the root node until the map is
10881empty, each operation will take O(log(size)), and the amortized
10882complexity is still O(log(size)).</p>
10883
10884<p>The operations can be done in amortized constant time if iterating
10885to the next node can be done in (non amortized) constant time.  This
10886can be done by putting all nodes in a double linked list.  This
10887requires two extra links per node.  To me this is a bit overkill since
10888you can already efficiently insert or erase ranges with erase(first,
10889last) and insert(first, last).</p>
10890
10891
10892
10893<p><b>Proposed resolution:</b></p>
10894
10895
10896<p><b>Rationale:</b></p>
10897<p>Only "amortized constant" in special circumstances, and we believe
10898  that's implementable. That is: doing this N times will be O(N), not
10899  O(log N).</p>
10900
10901
10902
10903
10904
10905<hr>
10906<h3><a name="499"></a>499. Std. doesn't seem to require stable_sort() to be stable!</h3>
10907<p><b>Section:</b> 25.4.1.2 [stable.sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
10908 <b>Submitter:</b> Prateek Karandikar <b>Opened:</b> 2005-04-12  <b>Last modified:</b> 2008-03-13</p>
10909<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
10910<p><b>Discussion:</b></p>
10911<blockquote><p>
1091217.3.1.1 Summary</p>
10913
10914<p>
109151 The Summary provides a synopsis of the category, and introduces the 
10916first-level subclauses. Each subclause also provides a summary, listing 
10917the headers specified in the subclause and the library entities 
10918provided in each header. 
10919</p>
10920<p>
109212 Paragraphs labelled "Note(s):" or "Example(s):" are informative, 
10922other paragraphs are normative.
10923</p></blockquote> 
10924
10925<p>So this means that a "Notes" paragraph wouldn't be normative. </p>
10926
10927<blockquote><p>
1092825.3.1.2 stable_sort
10929</p>
10930<pre>template&lt;class RandomAccessIterator&gt; 
10931void stable_sort(RandomAccessIterat or first, RandomAccessIterator last); 
10932
10933template&lt;class RandomAccessIterator, class Compare&gt; 
10934void stable_sort(RandomAccessIterat or first, RandomAccessIterator last, Compare comp);
10935</pre>
10936<p>
109371 Effects: Sorts the elements in the range [first, last).
10938</p>
10939<p>
109402 Complexity: It does at most N(log N)^2 (where N == last - first) 
10941comparisons; if enough extra memory is available, it is N log N.
10942</p>
10943<p>
109443 Notes: Stable: the relative order of the equivalent elements is 
10945preserved. 
10946</p></blockquote> 
10947
10948<p>
10949The Notes para is informative, and nowhere else is stability mentioned above. 
10950</p>
10951
10952<p>
10953Also, I just searched for the word "stable" in my copy of the Standard. 
10954and the phrase "Notes: Stable: the relative order of the elements..." 
10955is repeated several times in the Standard library clauses for 
10956describing various functions. How is it that stability is talked about 
10957in the informative paragraph? Or am I missing something obvious? 
10958</p>
10959
10960
10961<p><b>Proposed resolution:</b></p>
10962<p>
10963</p>
10964
10965
10966<p><b>Rationale:</b></p>
10967<p>
10968This change has already been made.
10969</p>
10970
10971
10972
10973
10974
10975<hr>
10976<h3><a name="500"></a>500. do_length cannot be implemented correctly</h3>
10977<p><b>Section:</b> 22.4.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
10978 <b>Submitter:</b> Krzysztof &#379;elechowski <b>Opened:</b> 2005-05-24  <b>Last modified:</b> 2008-03-13</p>
10979<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p>
10980<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
10981<p><b>Discussion:</b></p>
10982<ol>
10983<li>codecvt::do_length is of type int;</li>
10984<li>it is assumed to be sort-of returning from_next - from of type ptrdiff_t;</li>
10985<li>ptrdiff_t cannot be cast to an int without data loss.</li>
10986</ol>
10987<p>
10988Contradiction.
10989</p>
10990
10991
10992<p><b>Proposed resolution:</b></p>
10993<p>
10994</p>
10995
10996
10997
10998
10999
11000<hr>
11001<h3><a name="501"></a>501. Proposal: strengthen guarantees of lib.comparisons</h3>
11002<p><b>Section:</b> 20.7.3 [base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
11003 <b>Submitter:</b> Me &lt;anti_spam_email2003@yahoo.com&gt; <b>Opened:</b> 2005-06-07  <b>Last modified:</b> 2008-03-13</p>
11004<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p>
11005<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
11006<p><b>Discussion:</b></p>
11007<blockquote><p>
11008"For templates greater, less, greater_equal, and less_equal,
11009the specializations for any pointer type yield a total order, even if
11010the built-in operators &lt;, &gt;, &lt;=, &gt;= do not."
11011</p></blockquote>
11012
11013<p>
11014The standard should do much better than guarantee that these provide a
11015total order, it should guarantee that it can be used to test if memory
11016overlaps, i.e. write a portable memmove. You can imagine a platform
11017where the built-in operators use a uint32_t comparison (this tests for
11018overlap on this platform) but the less&lt;T*&gt; functor is allowed to be
11019defined to use a int32_t comparison. On this platform, if you use
11020std::less with the intent of making a portable memmove, comparison on
11021an array that straddles the 0x7FFFFFFF/0x8000000 boundary can give
11022incorrect results.
11023</p>
11024
11025
11026<p><b>Proposed resolution:</b></p>
11027<p>
11028Add a footnote to 20.5.3/8 saying:
11029</p>
11030
11031<blockquote><p>
11032Given a p1 and p2 such that p1 points to N objects of type T and p2
11033points to M objects of type T. If [p1,p1+N) does not overlap [p2,p2+M),
11034less returns the same value when comparing all pointers in [p1,p1+N) to
11035all pointers in [p2,p2+M). Otherwise, there is a value Q and a value R
11036such that less returns the same value when comparing all pointers in
11037[p1,p1+Q) to all pointers in [p2,p2+R) and an opposite value when
11038comparing all pointers in [p1+Q,p1+N) to all pointers in [p2+R,p2+M).
11039For the sake of completeness, the null pointer value (4.10) for T is
11040considered to be an array of 1 object that doesn't overlap with any
11041non-null pointer to T. less_equal, greater, greater_equal, equal_to,
11042and not_equal_to give the expected results based on the total ordering
11043semantics of less. For T of void, treat it as having similar semantics
11044as T of char i.e. less&lt;cv T*&gt;(a, b) gives the same results as less&lt;cv
11045void*&gt;(a, b) which gives the same results as less&lt;cv char*&gt;((cv
11046char*)(cv void*)a, (cv char*)(cv void*)b).
11047</p></blockquote>
11048
11049<p>
11050I'm also thinking there should be a footnote to 20.5.3/1 saying that if
11051A and B are similar types (4.4/4), comp&lt;A&gt;(a,b) returns the same value
11052as comp&lt;B&gt;(a,b) (where comp is less, less_equal, etc.). But this might
11053be problematic if there is some really funky operator overloading going
11054on that does different things based on cv (that should be undefined
11055behavior if somebody does that though). This at least should be
11056guaranteed for all POD types (especially pointers) that use the
11057built-in comparison operators.
11058</p>
11059
11060
11061
11062<p><b>Rationale:</b></p>
11063<p>
11064less is already required to provide a strict weak ordering which is good enough
11065to detect overlapping memory situations.
11066</p>
11067
11068
11069
11070
11071
11072<hr>
11073<h3><a name="502"></a>502. Proposition: Clarification of the interaction between a facet and an iterator</h3>
11074<p><b>Section:</b> 22.3.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
11075 <b>Submitter:</b> Christopher Conrade Zseleghovski <b>Opened:</b> 2005-06-07  <b>Last modified:</b> 2009-07-15</p>
11076<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</p>
11077<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
11078<p><b>Discussion:</b></p>
11079<p>
11080Motivation:
11081</p>
11082
11083<p>
11084This requirement seems obvious to me, it is the essence of code modularity. 
11085I have complained to Mr. Plauger that the Dinkumware library does not 
11086observe this principle but he objected that this behaviour is not covered in 
11087the standard.
11088</p>
11089
11090<p><i>[
110912009-07 Frankfurt
11092]</i></p>
11093
11094
11095<blockquote>
11096<p>
11097No objection to NAD, Fixed.
11098</p>
11099<p>
11100Move to NAD.
11101</p>
11102</blockquote>
11103
11104
11105
11106<p><b>Proposed resolution:</b></p>
11107<p>
11108Append the following point to 22.1.1.1.1:
11109</p>
11110
11111<p>
111126. The implementation of a facet of Table 52 parametrized with an 
11113InputIterator/OutputIterator should use that iterator only as character 
11114source/sink respectively.
11115For a *_get facet, it means that the value received depends only on the 
11116sequence of input characters and not on how they are accessed.
11117For a *_put facet, it means that the sequence of characters output depends 
11118only on the value to be formatted and not of how the characters are stored.
11119</p>
11120
11121<p><i>[
11122Berlin:  Moved to Open, Need to clean up this area to make it clear
11123locales don't have to contain open ended sets of facets. Jack, Howard,
11124Bill.
11125]</i></p>
11126
11127
11128
11129
11130
11131
11132
11133<hr>
11134<h3><a name="503"></a>503. more on locales</h3>
11135<p><b>Section:</b> 22.4 [locale.categories] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
11136 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2005-06-20  <b>Last modified:</b> 2009-07-15</p>
11137<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.categories">issues</a> in [locale.categories].</p>
11138<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
11139<p><b>Discussion:</b></p>
11140<p>
11141a) In 22.2.1.1 para. 2 we refer to "the instantiations required in Table
1114251" to refer to the facet *objects* associated with a locale. And we
11143almost certainly mean just those associated with the default or "C"
11144locale. Otherwise, you can't switch to a locale that enforces a different
11145mapping between narrow and wide characters, or that defines additional
11146uppercase characters.
11147</p>
11148
11149<p>
11150b) 22.2.1.5 para. 3 (codecvt) has the same issues.
11151</p>
11152
11153<p>
11154c) 22.2.1.5.2 (do_unshift) is even worse. It *forbids* the generation of
11155a homing sequence for the basic character set, which might very well need
11156one.
11157</p>
11158
11159<p>
11160d) 22.2.1.5.2 (do_length) likewise dictates that the default mapping
11161between wide and narrow characters be taken as one-for-one.
11162</p>
11163
11164<p>
11165e) 22.2.2 para. 2 (num_get/put) is both muddled and vacuous, as far as
11166I can tell. The muddle is, as before, calling Table 51 a list of
11167instantiations. But the constraint it applies seems to me to cover
11168*all* defined uses of num_get/put, so why bother to say so?
11169</p>
11170
11171<p>
11172f) 22.2.3.1.2 para. 1(do_decimal_point) says "The required instantiations
11173return '.' or L'.'.) Presumably this means "as appropriate for the
11174character type. But given the vague definition of "required" earlier,
11175this overrules *any* change of decimal point for non "C" locales.
11176Surely we don't want to do that.
11177</p>
11178
11179<p>
11180g) 22.2.3.1.2 para. 2 (do_thousands_sep) says "The required instantiations
11181return ',' or L','.) As above, this probably means "as appropriate for the
11182character type. But this overrules the "C" locale, which requires *no*
11183character ('\0') for the thousands separator. Even if we agree that we
11184don't mean to block changes in decimal point or thousands separator,
11185we should also eliminate this clear incompatibility with C.
11186</p>
11187
11188<p>
11189h) 22.2.3.1.2 para. 2 (do_grouping) says "The required instantiations
11190return the empty string, indicating no grouping." Same considerations
11191as for do_decimal_point.
11192</p>
11193
11194<p>
11195i) 22.2.4.1 para. 1 (collate) refers to "instantiations required in Table
1119651". Same bad jargon.
11197</p>
11198
11199<p>
11200j) 22.2.4.1.2 para. 1 (do_compare) refers to "instantiations required
11201in Table 51". Same bad jargon.
11202</p>
11203
11204<p>
11205k) 22.2.5 para. 1 (time_get/put) uses the same muddled and vacuous
11206as num_get/put.
11207</p>
11208
11209<p>
11210l) 22.2.6 para. 2 (money_get/put) uses the same muddled and vacuous
11211as num_get/put.
11212</p>
11213
11214<p>
11215m) 22.2.6.3.2 (do_pos/neg_format) says "The instantiations required
11216in Table 51 ... return an object of type pattern initialized to
11217{symbol, sign, none, value}." This once again *overrides* the "C"
11218locale, as well as any other locale."
11219</p>
11220
11221<p>
112223) We constrain the use_facet calls that can be made by num_get/put,
11223so why don't we do the same for money_get/put? Or for any of the
11224other facets, for that matter?
11225</p>
11226
11227<p>
112284) As an almost aside, we spell out when a facet needs to use the ctype
11229facet, but several also need to use a codecvt facet and we don't say so.
11230</p>
11231<p><i>[
11232Berlin: Bill to provide wording.
11233]</i></p>
11234
11235
11236<p><i>[
112372009-07 Frankfurt
11238]</i></p>
11239
11240
11241<blockquote>
11242<p>
11243No objection to NAD.
11244</p>
11245<p>
11246Move to NAD.
11247</p>
11248</blockquote>
11249
11250
11251
11252<p><b>Proposed resolution:</b></p>
11253<p>
11254</p>
11255
11256
11257
11258
11259
11260<hr>
11261<h3><a name="504"></a>504. Integer types in pseudo-random number engine requirements</h3>
11262<p><b>Section:</b> X [rand.req], TR1 5.1.1 [tr.rand.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
11263 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03  <b>Last modified:</b> 2008-03-13</p>
11264<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req">issues</a> in [rand.req].</p>
11265<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
11266<p><b>Discussion:</b></p>
11267<p>
11268In [tr.rand.req], Paragraph 2 states that "... s is a value of integral type,
11269g is an ... object returning values of unsigned integral type ..."
11270</p>
11271
11272
11273<p><b>Proposed resolution:</b></p>
11274<p>
11275In 5.1.1 [tr.rand.req], Paragraph 2 replace
11276</p>
11277
11278<blockquote><p>
11279... s is a value of integral type, g is an lvalue of a type other than X that
11280defines a zero-argument function object returning values of <del>unsigned integral</del> type
11281<ins><tt>unsigned long int</tt></ins>,
11282...
11283</p></blockquote>
11284
11285<p>
11286In 5.1.1 [tr.rand.seq], Table 16, replace in the line for X(s)
11287</p>
11288
11289<blockquote><p>
11290creates an engine with the initial internal state
11291determined by <ins><tt>static_cast&lt;unsigned long&gt;(</tt></ins><tt><i>s</i></tt><ins><tt>)</tt></ins>
11292</p></blockquote>
11293
11294<p><i>[
11295Mont Tremblant:  Both s and g should be unsigned long.
11296This should refer to the constructor signatures. Jens  provided wording post Mont Tremblant.
11297]</i></p>
11298
11299
11300<p><i>[
11301Berlin:  N1932 adopts the proposed resolution:  see 26.3.1.3/1e and Table 3 row 2. Moved
11302to Ready.
11303]</i></p>
11304
11305
11306
11307
11308<p><b>Rationale:</b></p>
11309<p>
11310Jens:  Just requiring X(unsigned long) still makes it possible
11311for an evil library writer to also supply a X(int) that does something
11312unexpected.  The wording above requires that X(s) always performs
11313as if X(unsigned long) would have been called.  I believe that is
11314sufficient and implements our intentions from Mont Tremblant.  I
11315see no additional use in actually requiring a X(unsigned long)
11316signature.  u.seed(s) is covered by its reference to X(s), same
11317arguments.
11318</p>
11319
11320
11321<p><i>[
11322Portland:  Subsumed by N2111.
11323]</i></p>
11324
11325
11326
11327
11328
11329<hr>
11330<h3><a name="506"></a>506. Requirements of Distribution parameter for variate_generator</h3>
11331<p><b>Section:</b> 26.5 [rand], TR1 5.1.3 [tr.rand.var] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
11332 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03  <b>Last modified:</b> 2008-03-13</p>
11333<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>
11334<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
11335<p><b>Discussion:</b></p>
11336<p>
11337Paragraph 3 requires that template argument U (which corresponds to template
11338parameter Engine) satisfy all uniform random number generator requirements.
11339However, there is no  analogous requirement regarding the template argument
11340that corresponds to template parameter Distribution.  We believe there should
11341be, and that it should require that this template argument satisfy all random
11342distribution requirements.
11343</p>
11344
11345
11346<p><b>Proposed resolution:</b></p>
11347<p>
11348Consequence 1: Remove the precondition clauses [tr.rand.var]/16 and /18.
11349</p>
11350<p>
11351Consequence 2: Add max() and min() functions to those distributions that
11352do not already have them.
11353</p>
11354
11355<p><i>[
11356Mont Tremblant: Jens reccommends NAD, min/max not needed everywhere.
11357Marc supports having min and max to satisfy generic programming interface.
11358]</i></p>
11359
11360
11361
11362
11363<p><b>Rationale:</b></p>
11364<p>Berlin:  N1932 makes this moot: variate_generator has been eliminated.</p>
11365
11366
11367
11368
11369
11370<hr>
11371<h3><a name="509"></a>509. Uniform_int template parameters</h3>
11372<p><b>Section:</b> 26.5.8.1 [rand.dist.uni], TR1 5.1.7.1 [tr.rand.dist.iunif] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
11373 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03  <b>Last modified:</b> 2008-03-13</p>
11374<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.uni">issues</a> in [rand.dist.uni].</p>
11375<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
11376<p><b>Discussion:</b></p>
11377<p>
11378In [tr.rand.dist.iunif] the uniform_int distribution currently has a single
11379template parameter, IntType, used as the input_type and as the result_type
11380of the distribution.  We believe there is no reason to conflate these types
11381in this way.
11382</p>
11383
11384
11385<p><b>Proposed resolution:</b></p>
11386<p>
11387We recommend that there be a second template  parameter to
11388reflect the distribution's input_type, and that the existing first template
11389parameter continue to reflect (solely) the result_type:
11390</p>
11391<blockquote><pre>template&lt; class IntType = int, UIntType = unsigned int &gt;
11392class uniform_int
11393{
11394public:
11395  // types
11396  typedef  UIntType  input_type;
11397  typedef  IntType   result_type;
11398</pre></blockquote>
11399
11400<p><i>[
11401Berlin: Moved to NAD.  N1932 makes this moot: the input_type template parameter has been
11402eliminated.
11403]</i></p>
11404
11405
11406
11407
11408
11409
11410
11411<hr>
11412<h3><a name="510"></a>510. Input_type for bernoulli_distribution</h3>
11413<p><b>Section:</b> 26.5.8.2 [rand.dist.bern], TR1 5.1.7.2 [tr.rand.dist.bern] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
11414 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03  <b>Last modified:</b> 2008-03-13</p>
11415<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
11416<p><b>Discussion:</b></p>
11417<p>
11418In [tr.rand.dist.bern] the distribution currently requires;
11419</p>
11420<blockquote><pre>typedef  int  input_type;
11421</pre></blockquote>
11422
11423
11424<p><b>Proposed resolution:</b></p>
11425<p>
11426We believe this is an unfortunate choice, and recommend instead:
11427</p>
11428<blockquote><pre>typedef  unsigned int  input_type;
11429</pre></blockquote>
11430
11431<p><i>[
11432Berlin:  Moved to NAD. N1932 makes this moot: the input_type template parameter has been
11433eliminated.
11434]</i></p>
11435
11436
11437
11438
11439
11440
11441
11442<hr>
11443<h3><a name="511"></a>511. Input_type for binomial_distribution</h3>
11444<p><b>Section:</b> 26.5.8 [rand.dist], TR1 5.1.7.5 [tr.rand.dist.bin] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
11445 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03  <b>Last modified:</b> 2008-03-13</p>
11446<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist">issues</a> in [rand.dist].</p>
11447<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
11448<p><b>Discussion:</b></p>
11449<p>
11450Unlike all other distributions in TR1, this binomial_distribution has an
11451implementation-defined  input_type.  We believe this is an unfortunate choice,
11452because it hinders users from writing portable code.  It also hinders the
11453writing of compliance tests.  We recommend instead:
11454</p>
11455<blockquote><pre>typedef  RealType  input_type;
11456</pre></blockquote>
11457<p>
11458While this choice is somewhat arbitrary (as it was for some of the other
11459distributions), we make  this particular choice because (unlike all other
11460distributions) otherwise this template would not publish its RealType
11461argument and so users could not write generic code that accessed this
11462second template parameter.  In this respect, the choice is consistent with
11463the other distributions in  TR1. 
11464</p>
11465<p>
11466We have two reasons for recommending that a real type be specified instead.
11467One reason is  based specifically on characteristics of binomial distribution
11468implementations, while the other is based on mathematical characteristics of
11469probability distribution functions in general.
11470</p>
11471<p>
11472Implementations of binomial distributions commonly use Stirling approximations
11473for values in certain ranges.  It is far more natural to use real values to
11474represent these approximations than it would be to use integral values to do
11475so.  In other ranges, implementations reply on the Bernoulli  distribution to
11476obtain values.  While TR1's bernoulli_distribution::input_type is specified as
11477int, we believe this would be better specified as double.
11478</p>
11479<p>
11480This brings us to our main point:  The notion of a random distribution rests
11481on the notion of a cumulative distribution function, which in turn mathematically
11482depends on a continuous dependent variable.  Indeed, such a distribution function
11483would be meaningless if it depended on  discrete values such as integers - and this
11484remains true even if the distribution function were to take discrete steps.
11485</p>
11486<p>
11487Although this note is specifically about binomial_distribution::input_type,
11488we intend to recommend that all of the random distributions input_types be
11489specified as a real type (either a RealType template parameter, or double,
11490as appropriate).
11491</p>
11492<p>
11493Of the nine distributions in TR1, four already have this characteristic
11494(uniform_real, exponential_distribution, normal_distribution, and
11495gamma_distribution).  We have already argued the case for the binomial the
11496remaining four distributions.
11497</p>
11498<p>
11499In the case of uniform_int, we believe that the calculations to produce an
11500integer result in a  specified range from an integer in a different specified
11501range is best done using real arithmetic.  This is because it involves a
11502product, one of whose terms is the ratio of the extents of the two ranges.
11503Without real arithmetic, the results become less uniform: some numbers become
11504more  (or less) probable that they should be.  This is, of course, undesireable
11505behavior in a uniform distribution.
11506</p>
11507<p>
11508Finally, we believe that in the case of the bernoulli_distribution (briefly
11509mentioned earlier), as well as the cases of the geometric_distribution and the
11510poisson_distribution, it would be far more natural to have a real input_type.
11511This is because the most natural computation involves the  random number
11512delivered and the distribution's parameter p (in the case of bernoulli_distribution,
11513for example, the computation is a comparison against p), and p is already specified
11514in each case as having some real type.
11515</p>
11516
11517
11518<p><b>Proposed resolution:</b></p>
11519<blockquote><pre>typedef  RealType  input_type;
11520</pre></blockquote>
11521
11522<p><i>[
11523Berlin:  Moved to NAD.  N1932 makes this moot: the input_type template parameter has been
11524eliminated.
11525]</i></p>
11526
11527
11528
11529
11530
11531
11532<hr>
11533<h3><a name="512"></a>512. Seeding subtract_with_carry_01 from a single unsigned long</h3>
11534<p><b>Section:</b> 26.5.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
11535 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03  <b>Last modified:</b> 2008-03-13</p>
11536<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng">issues</a> in [rand.eng].</p>
11537<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
11538<p><b>Discussion:</b></p>
11539<p>
11540Paragraph 8 specifies the algorithm by which a subtract_with_carry_01  engine
11541is to be seeded given a single unsigned long.  This algorithm is seriously
11542flawed in the case where the engine parameter w (also known as word_size)
11543exceeds 31 [bits].  The key part of the paragraph reads:
11544</p>
11545<blockquote><p>
11546sets x(-r) ... x(-1) to (lcg(1)*2**(-w)) mod 1
11547</p></blockquote>
11548<p>
11549and so forth. 
11550</p>
11551<p>
11552Since the specified linear congruential engine, lcg, delivers numbers with
11553a maximum of 2147483563 (just a shade under 31 bits), then when w is, for
11554example, 48, each of the x(i) will be less than 2**-17.  The consequence
11555is that roughly the first 400 numbers delivered will be  conspicuously
11556close to either zero or one.
11557</p>
11558<p>
11559Unfortunately, this is not an innocuous flaw:  One of the predefined engines
11560in [tr.rand.predef],  namely ranlux64_base_01, has w = 48 and would exhibit
11561this poor behavior, while the original N1378 proposal states that these
11562pre-defined engines are intended to be of "known good properties."
11563</p>
11564
11565
11566<p><b>Proposed resolution:</b></p>
11567<p>
11568In 5.1.4.4 [tr.rand.eng.sub1], replace the "effects" clause for
11569void seed(unsigned long value = 19780503) by
11570</p>
11571
11572<blockquote><p>
11573<i>Effects:</i> If <tt>value == 0</tt>, sets value to <tt>19780503</tt>. In any
11574case, <del>with a linear congruential generator <tt>lcg</tt>(i) having parameters
11575<tt><i>m<sub>lcg</sub></i> = 2147483563</tt>, <tt><i>a<sub>lcg</sub></i> = 40014</tt>,
11576<tt><i>c<sub>lcg</sub></i> = 0</tt>, and <tt><i>lcg</i>(0) = value</tt>,</del>
11577sets <ins>carry<tt>(-1)</tt> and</ins> <tt>x(-r) &#8230; x(-1)</tt>
11578<ins>as if executing</ins></p>
11579
11580<blockquote><pre><ins>
11581linear_congruential&lt;unsigned long, 40014, 0, 2147483563&gt; lcg(value);
11582seed(lcg);
11583</ins></pre></blockquote>
11584
11585<p>
11586<del>to <tt>(<i>lcg</i>(1) � 2<sup>-<i>w</i></sup>) mod 1
11587&#8230; (<i>lcg</i>(<i>r</i>) � 2<sup>-<i>w</i></sup>) mod 1</tt>,
11588respectively. If <tt><i>x</i>(-1) == 0</tt>, sets carry<tt>(-1) = 2<sup>-<i>w</i></sup></tt>,
11589else sets carry<tt>(-1) = 0</tt>.</del></p>
11590</blockquote>
11591
11592<p><i>[
11593Jens provided revised wording post Mont Tremblant.
11594]</i></p>
11595
11596
11597<p><i>[
11598Berlin: N1932 adopts the originally-proposed resolution of the issue.
11599Jens's supplied wording is a clearer description of what is
11600intended.  Moved to Ready.
11601]</i></p>
11602
11603
11604
11605
11606<p><b>Rationale:</b></p>
11607<p>
11608Jens: I'm using an explicit type here, because fixing the
11609prose would probably not qualify for the (with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a> even
11610stricter) requirements we have for seed(Gen&amp;).
11611</p>
11612
11613<p><i>[
11614Portland:  Subsumed by N2111.
11615]</i></p>
11616
11617
11618
11619
11620
11621
11622<hr>
11623<h3><a name="513"></a>513. Size of state for subtract_with_carry_01</h3>
11624<p><b>Section:</b> 26.5.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
11625 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03  <b>Last modified:</b> 2008-03-13</p>
11626<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng">issues</a> in [rand.eng].</p>
11627<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
11628<p><b>Discussion:</b></p>
11629<p>
11630Paragraph 3 begins:
11631</p>
11632<blockquote><p>
11633The size of the state is r.
11634</p></blockquote>
11635<p>
11636However, this is not quite consistent with the remainder of the paragraph
11637which specifies a total  of nr+1 items in the textual representation of
11638the state.  We recommend the sentence be corrected to match:
11639</p>
11640<blockquote><p>
11641The size of the state is nr+1.
11642</p></blockquote>
11643<p>
11644To give meaning to the coefficient n, it may be also desirable to move
11645n's definition from later in the paragraph.  Either of the following
11646seem reasonable formulations:
11647</p>
11648<blockquote><p>
11649With n=..., the size of the state is nr+1.
11650</p></blockquote>
11651<blockquote><p>
11652The size of the state is nr+1, where n=... .
11653</p></blockquote>
11654
11655
11656
11657<p><b>Proposed resolution:</b></p>
11658<p><i>[
11659Jens:  I plead for "NAD" on the grounds that "size of state" is only
11660used as an argument for big-O complexity notation, thus
11661constant factors and additions don't count.
11662]</i></p>
11663
11664
11665<p><i>[
11666Berlin: N1932 adopts the proposed NAD.
11667]</i></p>
11668
11669
11670
11671
11672
11673
11674
11675<hr>
11676<h3><a name="514"></a>514. Size of state for subtract_with_carry</h3>
11677<p><b>Section:</b> 26.5.3.3 [rand.eng.sub], TR1 5.1.4.3 [tr.rand.eng.sub] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
11678 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03  <b>Last modified:</b> 2008-03-13</p>
11679<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
11680<p><b>Discussion:</b></p>
11681<p>
11682Paragraph 2 begins:
11683</p>
11684<blockquote><p>
11685The size of the state is r.
11686</p></blockquote>
11687<p>
11688However, the next sentence specifies a total of r+1 items in the textual
11689representation of the state,  r specific x's as well as a specific carry.
11690This makes a total of r+1 items that constitute the size of the state,
11691rather than r.
11692</p>
11693
11694
11695<p><b>Proposed resolution:</b></p>
11696<p>
11697We recommend the sentence be corrected to match:
11698</p>
11699<blockquote><p>
11700 The size of the state is r+1.
11701</p></blockquote>
11702
11703<p><i>[
11704Jens:  I plead for "NAD" on the grounds that "size of state" is only
11705used as an argument for big-O complexity notation, thus
11706constant factors and additions don't count.
11707]</i></p>
11708
11709
11710<p><i>[
11711Berlin: N1932 adopts the proposed NAD.
11712]</i></p>
11713
11714
11715
11716
11717
11718
11719
11720<hr>
11721<h3><a name="515"></a>515. Random number engine traits</h3>
11722<p><b>Section:</b> 26.5.1 [rand.synopsis], TR1 5.1.2 [tr.rand.synopsis] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
11723 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03  <b>Last modified:</b> 2008-03-13</p>
11724<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.synopsis">issues</a> in [rand.synopsis].</p>
11725<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
11726<p><b>Discussion:</b></p>
11727<p>
11728To accompany the concept of a pseudo-random number engine as defined in Table 17,
11729we propose and recommend an adjunct template, engine_traits, to be declared in
11730[tr.rand.synopsis] as:
11731</p>
11732<blockquote><pre>template&lt; class PSRE &gt;
11733class engine_traits;
11734</pre></blockquote>
11735<p>
11736This template's primary purpose would be as an aid to generic programming involving
11737pseudo-random number engines.  Given only the facilities described in tr1, it would
11738be very difficult to produce any algorithms involving the notion of a generic engine.
11739The intent of this proposal is to  provide, via engine_traits&lt;&gt;, sufficient
11740descriptive information to allow an algorithm to employ a pseudo-random number engine
11741without regard to its exact type, i.e., as a template parameter.
11742</p>
11743<p>
11744For example, today it is not possible to write an efficient generic function that
11745requires any specific number of random bits.  More specifically, consider a
11746cryptographic application that internally needs 256 bits of randomness per call:
11747</p>
11748<blockquote><pre>template&lt; class Eng, class InIter, class OutIter &gt;
11749void crypto( Eng&amp; e, InIter in, OutIter out );
11750</pre></blockquote>
11751<p>
11752Without knowning the number of bits of randomness produced per call to a provided
11753engine, the algorithm has no means of determining how many times to call the engine.
11754</p>
11755<p>
11756In a new section [tr.rand.eng.traits], we proposed to define the engine_traits
11757template as: 
11758</p>
11759<blockquote><pre>template&lt; class PSRE &gt;
11760class engine_traits
11761{
11762  static  std::size_t  bits_of_randomness = 0u;
11763  static  std::string  name()  { return "unknown_engine"; }
11764  // TODO: other traits here
11765};
11766</pre></blockquote>
11767<p>
11768Further, each engine described in [tr.rand.engine] would be accompanied by a
11769complete specialization of this new engine_traits template.
11770</p>
11771
11772
11773
11774<p><b>Proposed resolution:</b></p>
11775<p><i>[
11776Berlin:  Walter: While useful for implementation per TR1, N1932 has no need for this
11777feature.  Recommend close as NAD.
11778]</i></p>
11779
11780
11781
11782<p><b>Rationale:</b></p>
11783<p>
11784Recommend NAD,
11785<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1932.pdf">N1932</a>,
11786<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2111.pdf">N2111</a>
11787covers this.  Already in WP.
11788</p>
11789
11790
11791
11792
11793
11794<hr>
11795<h3><a name="516"></a>516. Seeding subtract_with_carry_01 using a generator</h3>
11796<p><b>Section:</b> 26.5.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
11797 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03  <b>Last modified:</b> 2008-03-13</p>
11798<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng">issues</a> in [rand.eng].</p>
11799<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
11800<p><b>Discussion:</b></p>
11801<p>
11802Paragraph 6 says:
11803</p>
11804<blockquote><p>
11805... obtained by successive invocations of g, ... 
11806</p></blockquote>
11807<p>
11808We recommend instead:
11809</p>
11810<blockquote><p>
11811... obtained by taking successive invocations of g mod 2**32, ...
11812</p></blockquote>
11813<p>
11814as the context seems to require only 32-bit quantities be used here.
11815</p>
11816
11817
11818<p><b>Proposed resolution:</b></p>
11819<p>
11820Berlin: N1932 adopts the proposed resultion: see 26.3.3.4/7.  Moved to Ready.
11821</p>
11822
11823<p><i>[
11824Portland:  Subsumed by N2111.
11825]</i></p>
11826
11827
11828
11829
11830
11831
11832<hr>
11833<h3><a name="517"></a>517. Should include name in external representation</h3>
11834<p><b>Section:</b> X [rand.req], TR1 5.1.1 [tr.rand.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
11835 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2005-07-03  <b>Last modified:</b> 2008-03-13</p>
11836<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req">issues</a> in [rand.req].</p>
11837<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
11838<p><b>Discussion:</b></p>
11839<p>
11840The last two rows of Table 16 deal with the i/o requirements of an engine,
11841specifying that the textual representation of an engine's state,
11842appropriately formatted, constitute the engine's  external representation.
11843</p>
11844<p>
11845This seems adequate when an engine's type is known.  However, it seems
11846inadequate in the  context of generic code, where it becomes useful and
11847perhaps even necessary to determine an engine's type via input.
11848</p>
11849<p>
11850</p>
11851
11852
11853<p><b>Proposed resolution:</b></p>
11854<p>
11855We therefore recommend that, in each of these two rows of Table 16, the
11856text "textual representation" be expanded so as to read "engine name
11857followed by the textual representation."
11858</p>
11859
11860<p><i>[
11861Berlin: N1932 considers this NAD. This is a QOI issue.
11862]</i></p>
11863
11864
11865
11866
11867
11868
11869
11870<hr>
11871<h3><a name="523"></a>523. regex case-insensitive character ranges are unimplementable as specified</h3>
11872<p><b>Section:</b> 28 [re] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
11873 <b>Submitter:</b> Eric Niebler <b>Opened:</b> 2005-07-01  <b>Last modified:</b> 2009-07-15</p>
11874<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re">issues</a> in [re].</p>
11875<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
11876<p><b>Discussion:</b></p>
11877<p>
11878A problem with TR1 regex is currently being discussed on the Boost 
11879developers list. It involves the handling of case-insensitive matching 
11880of character ranges such as [Z-a]. The proper behavior (according to the 
11881ECMAScript standard) is unimplementable given the current specification 
11882of the TR1 regex_traits&lt;&gt; class template. John Maddock, the author of 
11883the TR1 regex proposal, agrees there is a problem. The full discussion 
11884can be found at http://lists.boost.org/boost/2005/06/28850.php (first 
11885message copied below). We don't have any recommendations as yet.
11886</p>
11887<p>
11888-- Begin original message --
11889</p>
11890<p>
11891The situation of interest is described in the ECMAScript specification
11892(ECMA-262), section 15.10.2.15:
11893</p>
11894<p>
11895"Even if the pattern ignores case, the case of the two ends of a range
11896is significant in determining which characters belong to the range.
11897Thus, for example, the pattern /[E-F]/i matches only the letters E, F,
11898e, and f, while the pattern /[E-f]/i matches all upper and lower-case
11899ASCII letters as well as the symbols [, \, ], ^, _, and `."
11900</p>
11901<p>
11902A more interesting case is what should happen when doing a
11903case-insentitive match on a range such as [Z-a]. It should match z, Z,
11904a, A and the symbols [, \, ], ^, _, and `. This is not what happens with
11905Boost.Regex (it throws an exception from the regex constructor).
11906</p>
11907<p>
11908The tough pill to swallow is that, given the specification in TR1, I
11909don't think there is any effective way to handle this situation.
11910According to the spec, case-insensitivity is handled with
11911regex_traits&lt;&gt;::translate_nocase(CharT) -- two characters are equivalent
11912if they compare equal after both are sent through the translate_nocase
11913function. But I don't see any way of using this translation function to
11914make character ranges case-insensitive. Consider the difficulty of
11915detecting whether "z" is in the range [Z-a]. Applying the transformation
11916to "z" has no effect (it is essentially std::tolower). And we're not
11917allowed to apply the transformation to the ends of the range, because as
11918ECMA-262 says, "the case of the two ends of a range is significant."
11919</p>
11920<p>
11921So AFAICT, TR1 regex is just broken, as is Boost.Regex. One possible fix
11922is to redefine translate_nocase to return a string_type containing all
11923the characters that should compare equal to the specified character. But
11924this function is hard to implement for Unicode, and it doesn't play nice
11925with the existing ctype facet. What a mess!
11926</p>
11927<p>
11928-- End original message --
11929</p>
11930
11931<p><i>[
11932John Maddock adds:
11933]</i></p>
11934
11935
11936<p>
11937One small correction, I have since found that ICU's regex package does 
11938implement this correctly, using a similar mechanism to the current 
11939TR1.Regex.
11940</p>
11941<p>
11942Given an expression [c1-c2] that is compiled as case insensitive it:
11943</p>
11944<p>
11945Enumerates every character in the range c1 to c2 and converts it to it's 
11946case folded equivalent.  That case folded character is then used a key to a 
11947table of equivalence classes, and each member of the class is added to the 
11948list of possible matches supported by the character-class.  This second step 
11949isn't possible with our current traits class design, but isn't necessary if 
11950the input text is also converted to a case-folded equivalent on the fly.
11951</p>
11952<p>
11953ICU applies similar brute force mechanisms to character classes such as 
11954[[:lower:]] and [[:word:]], however these are at least cached, so the impact 
11955is less noticeable in this case.
11956</p>
11957<p>
11958Quick and dirty performance comparisons show that expressions such as 
11959"[X-\\x{fff0}]+" are indeed very slow to compile with ICU (about 200 times 
11960slower than a "normal" expression).  For an application that uses a lot of 
11961regexes this could have a noticeable performance impact.  ICU also has an 
11962advantage in that it knows the range of valid characters codes: code points 
11963outside that range are assumed not to require enumeration, as they can not 
11964be part of any equivalence class.  I presume that if we want the TR1.Regex 
11965to work with arbitrarily large character sets enumeration really does become 
11966impractical.
11967</p>
11968<p>
11969Finally note that Unicode has:
11970</p>
11971<p>
11972Three cases (upper, lower and title).
11973One to many, and many to one case transformations.
11974Character that have context sensitive case translations - for example an 
11975uppercase sigma has two different lowercase forms  - the form chosen depends 
11976on context(is it end of a word or not), a caseless match for an upper case 
11977sigma should match either of the lower case forms, which is why case folding 
11978is often approximated by tolower(toupper(c)).
11979</p>
11980<p>
11981Probably we need some way to enumerate character equivalence classes, 
11982including digraphs (either as a result or an input), and some way to tell 
11983whether the next character pair is a valid digraph in the current locale.
11984</p>
11985<p>
11986Hoping this doesn't make this even more complex that it was already,
11987</p>
11988
11989<p><i>[
11990Portland:  Alisdair: Detect as invalid, throw an exception.
11991Pete: Possible general problem with case insensitive ranges.
11992]</i></p>
11993
11994
11995<p><i>[
119962009-07 Frankfurt
11997]</i></p>
11998
11999
12000<blockquote>
12001<p>
12002We agree that this is a problem, but we do not know the answer.
12003</p>
12004<p>
12005We are going to declare this NAD until existing practice leads us in some direction.
12006</p>
12007<p>
12008No objection to NAD Future.
12009</p>
12010<p>
12011Move to NAD Future.
12012</p>
12013</blockquote>
12014
12015
12016
12017<p><b>Proposed resolution:</b></p>
12018
12019
12020
12021
12022
12023<hr>
12024<h3><a name="525"></a>525. type traits definitions not clear</h3>
12025<p><b>Section:</b> 20.6.4 [meta.unary], TR1 4.5 [tr.meta.unary] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
12026 <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2005-07-11  <b>Last modified:</b> 2008-03-13</p>
12027<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
12028<p><b>Discussion:</b></p>
12029<p>
12030It is not completely clear how the primary type traits deal with
12031cv-qualified types.  And several of the secondary type traits
12032seem to be lacking a definition.
12033</p>
12034
12035<p><i>[
12036Berlin:  Howard to provide wording.
12037]</i></p>
12038
12039
12040
12041<p><b>Proposed resolution:</b></p>
12042<p>
12043Wording provided in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2028.html">N2028</a>.
12044A
12045<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html">revision (N2157)</a>
12046provides more detail for motivation.
12047</p>
12048
12049
12050<p><b>Rationale:</b></p>
12051Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html">revision (N2157)</a>
12052in the WP.
12053
12054
12055
12056
12057
12058<hr>
12059<h3><a name="526"></a>526. Is it undefined if a function in the standard changes in parameters?</h3>
12060<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#NAD">NAD</a>
12061 <b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2005-09-14  <b>Last modified:</b> 2008-03-13</p>
12062<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</p>
12063<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>
12064<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
12065<p><b>Discussion:</b></p>
12066<p>
12067Problem: There are a number of places in the C++ standard library where
12068it is possible to write what appear to be sensible ways of calling
12069functions, but which can cause problems in some (or all)
12070implementations, as they cause the values given to the function to be
12071changed in a way not specified in standard (and therefore not coded to
12072correctly work). These fall into two similar categories.
12073</p>
12074
12075<p>
120761) Parameters taken by const reference can be changed during execution
12077of the function
12078</p>
12079
12080<p>
12081Examples:
12082</p>
12083
12084<p>
12085Given std::vector&lt;int&gt; v:
12086</p>
12087<p>
12088v.insert(v.begin(), v[2]);
12089</p>
12090<p>
12091v[2] can be changed by moving elements of vector
12092</p>
12093
12094
12095<p>
12096Given std::list&lt;int&gt; l:
12097</p>
12098<p>
12099l.remove(*l.begin());
12100</p>
12101<p>
12102Will delete the first element, and then continue trying to access it.
12103This is particularily vicious, as it will appear to work in almost all
12104cases.
12105</p>
12106
12107<p>
121082) A range is given which changes during the execution of the function:
12109Similarly,
12110</p>
12111
12112<p>
12113v.insert(v.begin(), v.begin()+4, v.begin()+6);
12114</p>
12115
12116<p>
12117This kind of problem has been partly covered in some cases. For example
12118std::copy(first, last, result) states that result cannot be in the range
12119[first, last). However, does this cover the case where result is a
12120reverse_iterator built from some iterator in the range [first, last)?
12121Also, std::copy would still break if result was reverse_iterator(last +
121221), yet this is not forbidden by the standard
12123</p>
12124
12125<p>
12126Solution:
12127</p>
12128
12129<p>
12130One option would be to try to more carefully limit the requirements of
12131each function. There are many functions which would have to be checked.
12132However as has been shown in the std::copy case, this may be difficult.
12133A simpler, more global option would be to somewhere insert text similar to:
12134</p>
12135
12136<p>
12137If the execution of any function would change either any values passed
12138by reference or any value in any range passed to a function in a way not
12139defined in the definition of that function, the result is undefined.
12140</p>
12141
12142<p>
12143Such code would have to at least cover chapters 23 and 25 (the sections
12144I read through carefully). I can see no harm on applying it to much of
12145the rest of the standard.
12146</p>
12147
12148<p>
12149Some existing parts of the standard could be improved to fit with this,
12150for example the requires for 25.2.1 (Copy) could be adjusted to:
12151</p>
12152
12153<p>
12154Requires: For each non-negative integer n &lt; (last - first), assigning to
12155*(result + n) must not alter any value in the range [first + n, last).
12156</p>
12157
12158<p>
12159However, this may add excessive complication.
12160</p>
12161
12162<p>
12163One other benefit of clearly introducing this text is that it would
12164allow a number of small optimisations, such as caching values passed
12165by const reference.
12166</p>
12167
12168<p>
12169Matt Austern adds that this issue also exists for the <tt>insert</tt> and
12170<tt>erase</tt> members of the ordered and unordered associative containers.
12171</p>
12172
12173<p><i>[
12174Berlin: Lots of controversey over how this should be solved. Lots of confusion
12175as to whether we're talking about self referencing iterators or references.
12176Needs a good survey as to the cases where this matters, for which
12177implementations, and how expensive it is to fix each case.
12178]</i></p>
12179
12180
12181
12182
12183<p><b>Proposed resolution:</b></p>
12184
12185
12186<p><b>Rationale:</b></p>
12187<p>
12188Recommend NAD.
12189</p>
12190<ul>
12191<li><tt>vector::insert(iter, value)</tt> is required to work because the standard
12192doesn't give permission for it not to work.</li>
12193<li><tt>list::remove(value)</tt> is required to work because the standard
12194doesn't give permission for it not to work.</li>
12195<li><tt>vector::insert(iter, iter, iter)</tt> is not required to work because
1219623.2.3 [sequence.reqmts], p4 says so.</li>
12197<li><tt>copy</tt> has to work, except where 25.3.1 [alg.copy] says
12198it doesn't have to work.  While a language lawyer can tear this wording apart,
12199it is felt that the wording is not prone to accidental interpretation.</li>
12200<li>The current working draft provide exceptions for the unordered associative
12201containers similar to the containers requirements which exempt the member
12202template insert functions from self referencing.</li>
12203</ul>
12204
12205
12206
12207
12208
12209<hr>
12210<h3><a name="528"></a>528. <tt>const_iterator</tt> <tt>iterator</tt> issue when they are the same type</h3>
12211<p><b>Section:</b> 23.5 [unord], TR1 6.3.4 [tr.unord.unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
12212 <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2005-10-12  <b>Last modified:</b> 2008-03-13</p>
12213<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>
12214<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
12215<p><b>Discussion:</b></p>
12216<p>
12217while implementing the resolution of issue 6.19 I'm noticing the
12218following: according to 6.3.4.3/2 (and 6.3.4.5/2), for unordered_set and
12219unordered_multiset:
12220</p>
12221
12222<blockquote><p>
12223    "The iterator and const_iterator types are both const types. It is
12224unspecified whether they are the same type"
12225</p></blockquote>
12226
12227<p>
12228Now, according to the resolution of 6.19, we have overloads of insert
12229with hint and erase (single and range) both for iterator and
12230const_iterator, which, AFAICS, can be meaningful at the same time *only*
12231if iterator and const_iterator *are* in fact different types.
12232</p>
12233<p>
12234Then, iterator and const_iterator are *required* to be different types?
12235Or that is an unintended consequence? Maybe the overloads for plain
12236iterators should be added only to unordered_map and unordered_multimap?
12237Or, of course, I'm missing something?
12238</p>
12239
12240
12241
12242<p><b>Proposed resolution:</b></p>
12243<p>
12244Add to 6.3.4.3p2 (and 6.3.4.5p2):
12245</p>
12246<p>
122472  ... The iterator and const_iterator types are both <del>const</del>
12248<ins>constant</ins> iterator types.
12249It is unspecified whether they are the same type. 
12250</p>
12251
12252<p>
12253Add a new subsection to 17.4.4 [lib.conforming]:
12254</p>
12255
12256<blockquote>
12257<p>
12258An implementation shall not supply an overloaded function
12259       signature specified in any library clause if such a signature
12260       would be inherently ambiguous during overload resolution
12261       due to two library types referring to the same type.
12262</p>
12263<p>
12264       [Note: For example, this occurs when a container's iterator
12265       and const_iterator types are the same. -- end note]
12266</p>
12267</blockquote>
12268
12269<p><i>[
12270Post-Berlin: Beman supplied wording.
12271]</i></p>
12272
12273
12274
12275
12276<p><b>Rationale:</b></p>
12277Toronto:  The first issue has been fixed by N2350 (the insert and erase members
12278are collapsed into one signature).  Alisdair to open a separate issue on the
12279chapter 17 wording.
12280
12281
12282
12283
12284
12285<hr>
12286<h3><a name="529"></a>529. The standard encourages redundant and confusing preconditions</h3>
12287<p><b>Section:</b> 17.6.3.11 [res.on.required] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
12288 <b>Submitter:</b> David Abrahams <b>Opened:</b> 2005-10-25  <b>Last modified:</b> 2008-03-13</p>
12289<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
12290<p><b>Discussion:</b></p>
12291<p>
1229217.4.3.8/1 says:
12293</p>
12294
12295<blockquote><p>
12296Violation of the preconditions specified in a function's 
12297Required behavior: paragraph results in undefined behavior unless the 
12298function's Throws: paragraph specifies throwing an exception when the 
12299precondition is violated.
12300</p></blockquote>
12301
12302<p>
12303This implies that a precondition violation can lead to defined
12304behavior.  That conflicts with the only reasonable definition of
12305precondition: that a violation leads to undefined behavior.  Any other
12306definition muddies the waters when it comes to analyzing program
12307correctness, because precondition violations may be routinely done in
12308correct code (e.g. you can use std::vector::at with the full
12309expectation that you'll get an exception when your index is out of
12310range, catch the exception, and continue).  Not only is it a bad
12311example to set, but it encourages needless complication and redundancy
12312in the standard.  For example:
12313</p>
12314
12315<blockquote><pre>  21 Strings library 
12316  21.3.3 basic_string capacity
12317
12318  void resize(size_type n, charT c);
12319
12320  5 Requires: n &lt;= max_size()
12321  6 Throws: length_error if n &gt; max_size().
12322  7 Effects: Alters the length of the string designated by *this as follows:
12323</pre></blockquote>
12324
12325<p>
12326The Requires clause is entirely redundant and can be dropped.  We
12327could make that simplifying change (and many others like it) even
12328without changing 17.4.3.8/1; the wording there just seems to encourage
12329the redundant and error-prone Requires: clause.
12330</p>
12331
12332<p><i>[
12333Batavia:  Alan and Pete to work.
12334]</i></p>
12335
12336
12337<p><i>[
12338Bellevue:  NAD Editorial, this group likes 
12339<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2121.html">N2121</a>,
12340Pete agrees, accepting it is Pete's business.
12341General agreement that precondition violations are synonymous with UB.
12342]</i></p>
12343
12344
12345
12346<p><b>Proposed resolution:</b></p>
12347<p>
123481. Change 17.4.3.8/1 to read:
12349</p>
12350
12351<blockquote><p>
12352Violation of the preconditions specified in a function's
12353<i>Required behavior:</i> paragraph results in undefined behavior
12354<del>unless the function's <i>Throws:</i> paragraph specifies throwing
12355an exception when the precondition is violated</del>.
12356</p></blockquote>
12357
12358<p>
123592. Go through and remove redundant Requires: clauses.  Specifics to be
12360   provided by Dave A.
12361</p>
12362
12363<p><i>[
12364Berlin: The LWG requests a detailed survey of part 2 of the proposed resolution.
12365]</i></p>
12366
12367
12368<p><i>[
12369Alan provided the survey
12370<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2121.html">N2121</a>.
12371]</i></p>
12372
12373
12374
12375
12376
12377
12378
12379<hr>
12380<h3><a name="532"></a>532. Tuple comparison</h3>
12381<p><b>Section:</b> 20.5.2.7 [tuple.rel], TR1 6.1.3.5 [tr.tuple.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
12382 <b>Submitter:</b> David Abrahams <b>Opened:</b> 2005-11-29  <b>Last modified:</b> 2009-10-24</p>
12383<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>
12384<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
12385<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a></p>
12386<p><b>Discussion:</b></p>
12387<p>
12388Where possible, tuple comparison operators &lt;,&lt;=,=&gt;, and &gt; ought to be
12389defined in terms of std::less rather than operator&lt;, in order to
12390support comparison of tuples of pointers.  
12391</p>
12392
12393<p><i>[
123942009-07-28 Reopened by Alisdair.  No longer solved by concepts.
12395]</i></p>
12396
12397
12398<p><i>[
123992009-10 Santa Cruz:
12400]</i></p>
12401
12402
12403<blockquote>
12404<p>
12405If we solve this for <tt>tuple</tt> we would have to solve it for <tt>pair</tt>
12406algorithms, etc.  It is too late to do that at this time.  Move to NAD Future.
12407</p>
12408</blockquote>
12409
12410
12411
12412<p><b>Proposed resolution:</b></p>
12413<p>
12414change 6.1.3.5/5 from:
12415</p>
12416
12417<blockquote><p>
12418  Returns: The result of a lexicographical comparison between t and
12419  u. The result is defined as: (bool)(get&lt;0&gt;(t) &lt; get&lt;0&gt;(u)) ||
12420  (!(bool)(get&lt;0&gt;(u) &lt; get&lt;0&gt;(t)) &amp;&amp; ttail &lt; utail), where rtail for
12421  some tuple r is a tuple containing all but the first element of
12422  r. For any two zero-length tuples e and f, e &lt; f returns false.
12423</p></blockquote>
12424
12425<p>
12426to:
12427</p>
12428
12429<blockquote>
12430<p>
12431  Returns: The result of a lexicographical comparison between t and
12432  u. For any two zero-length tuples e and f, e &lt; f returns false.
12433  Otherwise, the result is defined as: cmp( get&lt;0&gt;(t), get&lt;0&gt;(u)) ||
12434  (!cmp(get&lt;0&gt;(u), get&lt;0&gt;(t)) &amp;&amp; ttail &lt; utail), where rtail for some
12435  tuple r is a tuple containing all but the first element of r, and
12436  cmp(x,y) is an unspecified function template defined as follows.
12437</p>
12438<p>
12439  Where T is the type of x and U is the type of y:
12440</p>
12441
12442<p>
12443     if T and U are pointer types and T is convertible to U, returns
12444     less&lt;U&gt;()(x,y)
12445</p>
12446
12447<p>
12448     otherwise, if T and U are pointer types, returns less&lt;T&gt;()(x,y)
12449</p>
12450
12451<p>
12452     otherwise, returns (bool)(x &lt; y)
12453</p>
12454</blockquote>
12455
12456<p><i>[
12457Berlin: This issue is much bigger than just tuple (pair, containers,
12458algorithms). Dietmar will survey and work up proposed wording.
12459]</i></p>
12460
12461
12462
12463
12464<p><b>Rationale:</b></p>
12465<p>
12466Recommend NAD.  This will be fixed with the next revision of concepts.
12467</p>
12468
12469<p><i>[
12470San Francisco:
12471]</i></p>
12472
12473
12474<blockquote>
12475Solved by
12476<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2770.pdf">N2770</a>.
12477</blockquote>
12478
12479
12480
12481
12482
12483<hr>
12484<h3><a name="536"></a>536. Container iterator constructor and explicit convertibility</h3>
12485<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#Dup">Dup</a>
12486 <b>Submitter:</b> Joaqu�n M L�pez Mu�oz <b>Opened:</b> 2005-12-17  <b>Last modified:</b> 2007-04-18</p>
12487<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>
12488<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>
12489<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
12490<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a></p>
12491<p><b>Discussion:</b></p>
12492<p>
12493The iterator constructor X(i,j) for containers as defined in 23.1.1 and
1249423.2.2 does only require that i and j be input iterators but
12495nothing is said about their associated value_type. There are three
12496sensible
12497options:
12498</p>
12499<ol>
12500<li>iterator's value_type is exactly X::value_type (modulo cv).</li>
12501<li>iterator's value_type is *implicitly* convertible to X::value_type.</li>
12502<li>iterator's value_type is *explicitly* convertible to X::value_type.</li>
12503</ol>
12504<p>
12505The issue has practical implications, and stdlib vendors have
12506taken divergent approaches to it: Dinkumware follows 2,
12507libstdc++ follows 3.
12508</p>
12509<p>
12510The same problem applies to the definition of insert(p,i,j) for
12511sequences and insert(i,j) for associative contianers, as well as
12512assign.
12513</p>
12514
12515<p><i>[
12516The following added by Howard and the example code was originally written by
12517Dietmar.
12518]</i></p>
12519
12520<p>
12521Valid code below?
12522</p>
12523
12524<blockquote><pre>#include &lt;vector&gt; 
12525#include &lt;iterator&gt; 
12526#include &lt;iostream&gt; 
12527
12528struct foo 
12529{ 
12530    explicit foo(int) {} 
12531}; 
12532
12533int main() 
12534{ 
12535    std::vector&lt;int&gt; v_int; 
12536    std::vector&lt;foo&gt; v_foo1(v_int.begin(), v_int.end()); 
12537    std::vector&lt;foo&gt; v_foo2((std::istream_iterator&lt;int&gt;(std::cin)), 
12538                             std::istream_iterator&lt;int&gt;()); 
12539} 
12540</pre></blockquote>
12541<p><i>[
12542Berlin: Some support, not universal, for respecting the explicit qualifier.
12543]</i></p>
12544
12545
12546
12547
12548<p><b>Proposed resolution:</b></p>
12549
12550
12551
12552
12553
12554
12555<hr>
12556<h3><a name="544"></a>544. minor NULL problems in C.2</h3>
12557<p><b>Section:</b> C.2 [diff.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
12558 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2005-11-25  <b>Last modified:</b> 2007-04-24</p>
12559<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>
12560<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
12561<p><b>Discussion:</b></p>
12562<p>
12563According to C.2.2.3, p1, "the macro NULL, defined in any of &lt;clocale&gt;,
12564&lt;cstddef&gt;, &lt;cstdio&gt;, &lt;cstdlib&gt;, &lt;cstring&gt;, &lt;ctime&gt;,
12565or &lt;cwchar&gt;." This is consistent with the C standard.
12566</p>
12567<p>
12568However, Table 95 in C.2 fails to mention &lt;clocale&gt; and &lt;cstdlib&gt;.
12569</p>
12570<p>
12571In addition, C.2, p2 claims that "The C++ Standard library provides
1257254 standard macros from the C library, as shown in Table 95." While
12573table 95 does have 54 entries, since a couple of them (including the
12574NULL macro) are listed more than once, the actual number of macros
12575defined by the C++ Standard Library may not be 54.
12576</p>
12577
12578
12579<p><b>Proposed resolution:</b></p>
12580<p>
12581I propose we add &lt;clocale&gt; and &lt;cstdlib&gt; to Table 96 and remove the
12582number of macros from C.2, p2 and reword the sentence as follows:
12583</p>
12584<blockquote><p>
12585The C++ Standard library <del>provides 54 standard macros from</del>
12586<ins>defines a number macros corresponding to those defined by</ins> the C 
12587<ins>Standard</ins> library, as shown in Table 96.
12588</p></blockquote>
12589
12590<p><i>[
12591Portland:  Resolution is considered editorial.  It will be incorporated into the WD.
12592]</i></p>
12593
12594
12595
12596
12597
12598
12599
12600<hr>
12601<h3><a name="546"></a>546. _Longlong and _ULonglong are integer types</h3>
12602<p><b>Section:</b> TR1 5.1.1 [tr.rand.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
12603 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2006-01-10  <b>Last modified:</b> 2009-07-15</p>
12604<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
12605<p><b>Discussion:</b></p>
12606<p>
12607The TR sneaks in two new integer types, _Longlong and _Ulonglong, in [tr.c99].
12608The rest of the TR should use that type.  I believe this affects two places.
12609First, the random number requirements, 5.1.1/10-11, lists all of the types with
12610which template parameters named IntType and UIntType may be instantiated.
12611_Longlong (or "long long", assuming it is added to C++0x) should be added to the
12612IntType list, and UIntType (again, or "unsigned long long") should be added to
12613the UIntType list.  Second, 6.3.2 lists the types for which hash&lt;&gt; is
12614required to be instantiable. _Longlong and _Ulonglong should be added to that
12615list, so that people may use long long as a hash key.
12616</p>
12617
12618<p><i>[
126192009-07 Frankfurt
12620]</i></p>
12621
12622
12623<blockquote>
12624<p>
12625We are not going to fix TR1.
12626</p>
12627<p>
12628The paper "long long goes to the library" addresses the integration of
12629long long into the C++0x library.
12630</p>
12631<p>
12632Move to NAD.
12633</p>
12634</blockquote>
12635
12636
12637
12638<p><b>Proposed resolution:</b></p>
12639<p>
12640</p>
12641
12642
12643
12644
12645
12646<hr>
12647<h3><a name="547"></a>547. division should be floating-point, not integer</h3>
12648<p><b>Section:</b> 26.5 [rand], TR1 5.1 [tr.rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
12649 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2006-01-10  <b>Last modified:</b> 2007-04-18</p>
12650<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>
12651<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
12652<p><b>Discussion:</b></p>
12653<p>
12654Paragraph 10 describes how a variate generator uses numbers produced by an
12655engine to pass to a generator. The sentence that concerns me is: "Otherwise, if
12656the value for engine_value_type::result_type is true and the value for
12657Distribution::input_type is false [i.e. if the engine produces integers and the
12658engine wants floating-point values], then the numbers in s_eng are divided by
12659engine().max() - engine().min() + 1 to obtain the numbers in s_e." Since the
12660engine is producing integers, both the numerator and the denominator are
12661integers and we'll be doing integer division, which I don't think is what we
12662want. Shouldn't we be performing a conversion to a floating-point type first?
12663</p>
12664
12665
12666<p><b>Proposed resolution:</b></p>
12667
12668
12669<p><b>Rationale:</b></p>
12670<p>
12671Recommend NAD as the affected section is now gone and so the issue is moot.
12672<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2111.pdf">N2111</a>.
12673</p>
12674
12675
12676
12677
12678
12679<hr>
12680<h3><a name="548"></a>548. May random_device block?</h3>
12681<p><b>Section:</b> 26.5.6 [rand.device], TR1 5.1.6 [tr.rand.device] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
12682 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2006-01-10  <b>Last modified:</b> 2007-10-18</p>
12683<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>
12684<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
12685<p><b>Discussion:</b></p>
12686<p>
12687Class random_device "produces non-deterministic random numbers", using some
12688external source of entropy. In most real-world systems, the amount of available
12689entropy is limited. Suppose that entropy has been exhausted. What is an
12690implementation permitted to do? In particular, is it permitted to block
12691indefinitely until more random bits are available, or is the implementation
12692required to detect failure immediately? This is not an academic question. On
12693Linux a straightforward implementation would read from /dev/random, and "When
12694the entropy pool is empty, reads to /dev/random will block until additional
12695environmental noise is gathered." Programmers need to know whether random_device
12696is permitted to (or possibly even required to?) behave the same way.
12697</p>
12698
12699<p><i>[
12700Berlin: Walter: N1932 considers this NAD. Does the standard specify whether std::cin
12701may block?
12702]</i></p>
12703
12704
12705<p>
12706See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
12707<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
12708for some further discussion.
12709</p>
12710
12711
12712<p><b>Proposed resolution:</b></p>
12713<p>
12714Adopt the proposed resolution in
12715<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> (NAD).
12716</p>
12717
12718
12719
12720
12721
12722<hr>
12723<h3><a name="549"></a>549. Undefined variable in binomial_distribution</h3>
12724<p><b>Section:</b> 26.5.8 [rand.dist], TR1 5.1.7.5 [tr.rand.dist.bin] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
12725 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2006-01-10  <b>Last modified:</b> 2007-04-24</p>
12726<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist">issues</a> in [rand.dist].</p>
12727<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
12728<p><b>Discussion:</b></p>
12729<p>
12730Paragraph 1 says that "A binomial distributon random distribution produces
12731integer values i&gt;0 with p(i) = (n choose i) * p*i * (1-p)^(t-i), where t and
12732p are the parameters of the distribution. OK, that tells us what t, p, and i
12733are. What's n?
12734</p>
12735
12736
12737<p><b>Proposed resolution:</b></p>
12738<p>
12739Berlin: Typo: "n" replaced by "t" in N1932: see 26.3.7.2.2/1.
12740</p>
12741
12742<p><i>[
12743Portland:  Subsumed by N2111.
12744]</i></p>
12745
12746
12747
12748
12749
12750
12751<hr>
12752<h3><a name="553"></a>553. very minor editorial change intptr_t / uintptr_t</h3>
12753<p><b>Section:</b> 18.4.1 [cstdint.syn], TR1 8.22.1 [tr.c99.cstdint.syn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
12754 <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2006-01-30  <b>Last modified:</b> 2007-07-02</p>
12755<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint.syn">issues</a> in [cstdint.syn].</p>
12756<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
12757<p><b>Discussion:</b></p>
12758<p>
12759In the synopsis, some types are identified as optional: int8_t, int16_t,
12760and so on, consistently with C99, indeed.
12761</p>
12762<p>
12763On the other hand, intptr_t and uintptr_t, are not marked as such and
12764probably should, consistently with C99, 7.18.1.4.
12765</p>
12766
12767
12768<p><b>Proposed resolution:</b></p>
12769<p>
12770Change 18.4.1 [cstdint.syn]:
12771</p>
12772
12773<blockquote><pre>...
12774typedef <i>signed integer type</i> intptr_t;    <ins><i>// optional</i></ins>
12775...
12776typedef <i>unsigned integer type</i> uintptr_t;    <ins><i>// optional</i></ins>
12777...
12778</pre></blockquote>
12779
12780
12781
12782<p><b>Rationale:</b></p>
12783Recommend NAD and fix as editorial with the proposed resolution.
12784
12785
12786
12787
12788
12789<hr>
12790<h3><a name="554"></a>554. Problem with lwg DR 184 numeric_limits&lt;bool&gt;</h3>
12791<p><b>Section:</b> 18.3.1.5 [numeric.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
12792 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2006-01-29  <b>Last modified:</b> 2007-01-15</p>
12793<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.special">issues</a> in [numeric.special].</p>
12794<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
12795<p><b>Discussion:</b></p>
12796<p>
12797I believe we have a bug in the resolution of:
12798<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#184">lwg 184</a>
12799(WP status).
12800</p>
12801
12802<p>
12803The resolution spells out each member of <tt>numeric_limits&lt;bool&gt;</tt>.
12804The part I'm having a little trouble with is:
12805</p>
12806<blockquote><pre>static const bool traps = false;
12807</pre></blockquote>
12808
12809<p>
12810Should this not be implementation defined?  Given:
12811</p>
12812
12813<blockquote><pre>int main()
12814{
12815     bool b1 = true;
12816     bool b2 = false;
12817     bool b3 = b1/b2;
12818}
12819</pre></blockquote>
12820
12821<p>
12822If this causes a trap, shouldn't <tt>numeric_limits&lt;bool&gt;::traps</tt> be
12823<tt>true</tt>?
12824</p>
12825
12826
12827<p><b>Proposed resolution:</b></p>
12828<p>
12829Change 18.2.1.5p3:
12830</p>
12831
12832<blockquote><p>
12833-3- The specialization for <tt>bool</tt> shall be provided as follows: </p>
12834<blockquote><pre>namespace std { 
12835   template &lt;&gt; class numeric_limits&lt;bool&gt; {
12836      ...
12837      static const bool traps = <del>false</del> <ins><i>implementation-defined</i></ins>;
12838      ...
12839   };
12840}
12841</pre></blockquote>
12842</blockquote>
12843
12844<p><i>[
12845Redmond:  NAD because traps refers to values, not operations.  There is no bool
12846value that will trap.
12847]</i></p>
12848
12849
12850
12851
12852
12853
12854
12855<hr>
12856<h3><a name="555"></a>555. TR1, 8.21/1: typo</h3>
12857<p><b>Section:</b> TR1 8.21 [tr.c99.boolh] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
12858 <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2006-02-02  <b>Last modified:</b> 2007-04-24</p>
12859<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
12860<p><b>Discussion:</b></p>
12861<p>
12862This one, if nobody noticed it yet, seems really editorial:
12863s/cstbool/cstdbool/
12864</p>
12865
12866
12867<p><b>Proposed resolution:</b></p>
12868<p>
12869Change 8.21p1:
12870</p>
12871<blockquote><p>
12872-1- The header behaves as if it defines the additional macro defined in
12873<tt>&lt;cst<ins>d</ins>bool&gt;</tt> by including the header <tt>&lt;cstdbool&gt;</tt>.
12874</p></blockquote>
12875
12876<p><i>[
12877Redmond:  Editorial.
12878]</i></p>
12879
12880
12881
12882
12883
12884
12885
12886<hr>
12887<h3><a name="557"></a>557. TR1: div(_Longlong, _Longlong) vs div(intmax_t, intmax_t)</h3>
12888<p><b>Section:</b> 18.4 [cstdint], TR1 8.22 [tr.c99.cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
12889 <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2006-02-06  <b>Last modified:</b> 2008-07-02</p>
12890<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint">issues</a> in [cstdint].</p>
12891<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
12892<p><b>Discussion:</b></p>
12893<p>
12894I'm seeing a problem with such overloads: when, _Longlong == intmax_t ==
12895long long we end up, essentially, with the same arguments and different
12896return types (lldiv_t and imaxdiv_t, respectively). Similar issue with
12897abs(_Longlong) and abs(intmax_t), of course.
12898</p>
12899<p>
12900Comparing sections 8.25 and 8.11, I see an important difference,
12901however: 8.25.3 and 8.25.4 carefully describe div and abs for _Longlong
12902types (rightfully, because not moved over directly from C99), whereas
12903there is no equivalent in 8.11: the abs and div overloads for intmax_t
12904types appear only in the synopsis and are not described anywhere, in
12905particular no mention in 8.11.2 (at variance with 8.25.2).
12906</p>
12907<p>
12908I'm wondering whether we really, really, want div and abs for intmax_t...
12909</p>
12910
12911
12912
12913<p><b>Proposed resolution:</b></p>
12914
12915
12916
12917<p><i>[
12918Portland: no consensus.
12919]</i></p>
12920
12921
12922<p><b>Rationale:</b></p>
12923<p><i>[
12924Batavia, Bill: The <tt>&lt;cstdint&gt;</tt> synopsis in TR1 8.11.1 [tr.c99.cinttypes.syn] contains:
12925]</i></p>
12926
12927<blockquote><pre>intmax_t imaxabs(intmax_t i);
12928intmax_t abs(intmax_t i);
12929
12930imaxdiv_t imaxdiv(intmax_t numer, intmax_t denom);
12931imaxdiv_t div(intmax_t numer, intmax_t denom);
12932</pre></blockquote>
12933
12934<p><i>[
12935and in TR1 8.11.2 [tr.c99.cinttypes.def]:
12936]</i></p>
12937
12938
12939<blockquote><p>
12940The header defines all functions, types, and macros the same as C99
12941subclause 7.8.
12942</p></blockquote>
12943
12944<p><i>[
12945This is as much definition as we give for most other C99 functions,
12946so nothing need change. We might, however, choose to add the footnote:
12947]</i></p>
12948
12949
12950<blockquote><p>
12951[<i>Note:</i> These overloads for <tt>abs</tt> and <tt>div</tt> may well be equivalent to
12952those that take <tt>long long</tt> arguments. If so, the implementation is
12953responsible for avoiding conflicting declarations. -- <i>end note</i>]
12954</p></blockquote>
12955
12956<p><i>[
12957Bellevue: NAD Editorial. Pete must add a footnote, as described below.
12958]</i></p>
12959
12960
12961<blockquote>
12962<p><i>[
12963Looks like a real problem. Dietmar suggests div() return a template
12964type. Matt: looks like imaxdiv_t is loosly defined. Can it be a typedef
12965for lldiv_t when _Longlong == intmax_t? PJP seems to agree. We would
12966need a non-normative note declaring that the types lldiv_t and imaxdiv_t
12967may not be unique if intmax_t==_longlong.
12968]</i></p>
12969
12970</blockquote>
12971
12972
12973
12974
12975
12976
12977<hr>
12978<h3><a name="558"></a>558. lib.input.iterators Defect</h3>
12979<p><b>Section:</b> 24.2.1 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
12980 <b>Submitter:</b> David Abrahams <b>Opened:</b> 2006-02-09  <b>Last modified:</b> 2007-04-24</p>
12981<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>
12982<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
12983<p><b>Discussion:</b></p>
12984<blockquote>
12985<p>
12986  24.1.1 Input iterators [lib.input.iterators]
12987</p>
12988<p>
12989  1 A class or a built-in type X satisfies the requirements of an
12990  input iterator for the value type T if the following expressions are
12991  valid, where U is the type of any specified member of type T, as
12992  shown in Table 73.
12993</p>
12994</blockquote>
12995<p>
12996There is no capital U used in table 73.  There is a lowercase u, but
12997that is clearly not meant to denote a member of type T.  Also, there's
12998no description in 24.1.1 of what lowercase a means.  IMO the above
12999should have been...Hah, a and b are already covered in 24.1/11, so maybe it
13000should have just been:
13001</p>
13002
13003
13004<p><b>Proposed resolution:</b></p>
13005<p>
13006Change 24.1.1p1:
13007</p>
13008<blockquote><p>
13009-1- A class or a built-in type <tt>X</tt> satisfies the requirements of an
13010input iterator for the value type <tt>T</tt> if the following expressions 
13011are valid<del>, where <tt>U</tt> is the type of any specified member of type
13012<tt>T</tt>,</del> as shown in Table 73.
13013</p></blockquote>
13014
13015<p><i>[
13016Portland: Editorial.
13017]</i></p>
13018
13019
13020
13021
13022
13023
13024
13025<hr>
13026<h3><a name="560"></a>560. User-defined allocators without default constructor</h3>
13027<p><b>Section:</b> 20.2.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
13028 <b>Submitter:</b> Sergey P. Derevyago <b>Opened:</b> 2006-02-17  <b>Last modified:</b> 2007-04-18</p>
13029<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>
13030<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
13031<p><b>Discussion:</b></p>
13032<h4>1. The essence of the problem.</h4>
13033<p>
13034User-defined allocators without default constructor are not explicitly
13035supported by the standard but they can be supported just like std::vector
13036supports elements without default constructor.
13037</p>
13038<p>
13039As a result, there exist implementations that work well with such allocators
13040and implementations that don't.
13041</p>
13042
13043<h4>2. The cause of the problem.</h4>
13044<p>
130451) The standard doesn't explicitly state this intent but it should. In
13046particular, 20.1.5p5 explicitly state the intent w.r.t. the allocator
13047instances that compare non-equal. So it can similarly state the intent w.r.t.
13048the user-defined allocators without default constructor.
13049</p>
13050<p>
130512) Some container operations are obviously underspecified. In particular,
1305221.3.7.1p2 tells:
13053</p>
13054<blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
13055  basic_string&lt;charT,traits,Allocator&gt; operator+(
13056    const charT* lhs,
13057    const basic_string&lt;charT,traits,Allocator&gt;&amp; rhs
13058  );
13059</pre>
13060<p>
13061Returns: <tt>basic_string&lt;charT,traits,Allocator&gt;(lhs) + rhs</tt>.
13062</p>
13063</blockquote>
13064<p>
13065That leads to the basic_string&lt;charT,traits,Allocator&gt;(lhs, Allocator()) call.
13066Obviously, the right requirement is:
13067</p>
13068<blockquote><p>
13069Returns: <tt>basic_string&lt;charT,traits,Allocator&gt;(lhs, rhs.get_allocator()) + rhs</tt>.
13070</p></blockquote>
13071<p>
13072It seems like a lot of DRs can be submitted on this "Absent call to
13073get_allocator()" topic.
13074</p>
13075
13076<h4>3. Proposed actions.</h4>
13077<p>
130781) Explicitly state the intent to allow for user-defined allocators without
13079default constructor in 20.1.5 Allocator requirements.
13080</p>
13081<p>
130822) Correct all the places, where a correct allocator object is available
13083through the get_allocator() call but default Allocator() gets passed instead.
13084</p>
13085<h4>4. Code sample.</h4>
13086<p>
13087Let's suppose that the following memory pool is available:
13088</p>
13089<blockquote><pre>class mem_pool {
13090      // ...
13091      void* allocate(size_t size);
13092      void deallocate(void* ptr, size_t size);
13093};
13094</pre></blockquote>
13095<p>
13096So the following allocator can be implemented via this pool:
13097</p>
13098<blockquote><pre>class stl_allocator {
13099      mem_pool&amp; pool;
13100
13101 public:
13102      explicit stl_allocator(mem_pool&amp; mp) : pool(mp) {}
13103      stl_allocator(const stl_allocator&amp; sa) : pool(sa.pool) {}
13104      template &lt;class U&gt;
13105      stl_allocator(const stl_allocator&lt;U&gt;&amp; sa)  : pool(sa.get_pool()) {}
13106      ~stl_allocator() {}
13107
13108      pointer allocate(size_type n, std::allocator&lt;void&gt;::const_pointer = 0)
13109      {
13110       return (n!=0) ? static_cast&lt;pointer&gt;(pool.allocate(n*sizeof(T))) : 0;
13111      }
13112
13113      void deallocate(pointer p, size_type n)
13114      {
13115       if (n!=0) pool.deallocate(p, n*sizeof(T));
13116      }
13117
13118      // ...
13119};
13120</pre></blockquote>
13121<p>
13122Then the following code works well on some implementations and doesn't work on
13123another:
13124</p>
13125<blockquote><pre>typedef basic_string&lt;char, char_traits&lt;char&gt;, stl_allocator&lt;char&gt; &gt; 
13126  tl_string;
13127mem_pool mp;
13128tl_string s1("abc", stl_allocator&lt;int&gt;(mp));
13129printf("(%s)\n", ("def"+s1).c_str());
13130</pre></blockquote>
13131<p>
13132In particular, on some implementations the code can't be compiled without
13133default stl_allocator() constructor.
13134</p>
13135<p>
13136The obvious way to solve the compile-time problems is to intentionally define
13137a NULL pointer dereferencing default constructor
13138</p>
13139<blockquote><pre>stl_allocator() : pool(*static_cast&lt;mem_pool*&gt;(0)) {}
13140</pre></blockquote>
13141<p>
13142in a hope that it will not be called. The problem is that it really gets
13143called by operator+(const char*, const string&amp;) under the current 21.3.7.1p2
13144wording.
13145</p>
13146
13147
13148<p><b>Proposed resolution:</b></p>
13149<p>
13150</p>
13151
13152
13153<p><b>Rationale:</b></p>
13154<p>
13155Recommend NAD.  <tt>operator+()</tt> with <tt>string</tt> already requires the desired
13156semantics of copying the allocator from one of the strings (<i>lhs</i> when there is a choice).
13157</p>
13158
13159
13160
13161
13162
13163<hr>
13164<h3><a name="568"></a>568. log2 overloads missing</h3>
13165<p><b>Section:</b> TR1 8.16.4 [tr.c99.cmath.over] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
13166 <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2006-03-07  <b>Last modified:</b> 2009-07-13</p>
13167<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
13168<p><b>Discussion:</b></p>
13169<p>
13170<tt>log2</tt> is missing from the list of "additional overloads" in TR1 8.16.4 [tr.c99.cmath.over] p1.
13171</p>
13172
13173<p>
13174Hinnant:  This is a TR1 issue only.  It is fixed in the current (N2135) WD.
13175</p>
13176
13177<p><i>[
13178Batavia (2009-05):
13179]</i></p>
13180
13181<blockquote>
13182We agree this has been fixed in the Working Draft.
13183Move to NAD.
13184</blockquote>
13185
13186
13187<p><b>Proposed resolution:</b></p>
13188<p>
13189Add <tt>log2</tt> to the list of functions in TR1 8.16.4 [tr.c99.cmath.over] p1.
13190</p>
13191
13192
13193
13194
13195
13196<hr>
13197<h3><a name="569"></a>569. Postcondition for basic_ios::clear(iostate) incorrectly stated</h3>
13198<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#Dup">Dup</a>
13199 <b>Submitter:</b> Seungbeom Kim <b>Opened:</b> 2006-03-10  <b>Last modified:</b> 2006-12-30</p>
13200<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>
13201<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
13202<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#272">272</a></p>
13203<p><b>Discussion:</b></p>
13204<p>
13205Section: 27.4.4.3 [lib.iostate.flags]
13206</p>
13207<p>
13208Paragraph 4 says:
13209</p>
13210<blockquote>
13211<blockquote><pre>void clear(iostate <i>state</i> = goodbit);
13212</pre></blockquote>
13213<p>
13214<i>Postcondition:</i> If <tt>rdbuf()!=0</tt> then <tt><i>state</i> == rdstate();</tt>
13215otherwise <tt>rdstate()==<i>state</i>|ios_base::badbit</tt>.
13216</p>
13217</blockquote>
13218
13219<p>
13220The postcondition "rdstate()==state|ios_base::badbit" is parsed as
13221"(rdstate()==state)|ios_base::badbit", which is probably what the
13222committee meant.
13223</p>
13224
13225
13226
13227
13228<p><b>Rationale:</b></p>
13229
13230
13231
13232
13233
13234
13235<hr>
13236<h3><a name="570"></a>570. Request adding additional explicit specializations of char_traits</h3>
13237<p><b>Section:</b> 21.2 [char.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
13238 <b>Submitter:</b> Jack Reeves <b>Opened:</b> 2006-04-06  <b>Last modified:</b> 2008-06-18</p>
13239<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits">issues</a> in [char.traits].</p>
13240<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
13241<p><b>Discussion:</b></p>
13242<p>
13243Currently, the Standard Library specifies only a declaration for template class
13244char_traits&lt;&gt; and requires the implementation provide two explicit
13245specializations: char_traits&lt;char&gt; and char_traits&lt;wchar_t&gt;. I feel the Standard
13246should require explicit specializations for all built-in character types, i.e.
13247char, wchar_t, unsigned char, and signed char.
13248</p>
13249<p>
13250I have put together a paper
13251(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1985.htm">N1985</a>)
13252that describes this in more detail and
13253includes all the necessary wording.
13254</p>
13255<p><i>[
13256Portland: Jack will rewrite
13257<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1985.htm">N1985</a>
13258to propose a primary template that will work with other integral types.
13259]</i></p>
13260
13261<p><i>[
13262Toronto: issue has grown with addition of <tt>char16_t</tt> and <tt>char32_t</tt>.
13263]</i></p>
13264
13265
13266<p><i>[
13267post Bellevue:
13268]</i></p>
13269
13270
13271<blockquote>
13272<p>
13273We suggest that Jack be asked about the status of his paper, and if it
13274is not forthcoming, the work-item be assigned to someone else. If no one
13275steps forward to do the paper before the next meeting, we propose to
13276make this NAD without further discussion. We leave this Open for now,
13277but our recommendation is NAD.
13278</p>
13279<p>
13280Note: the issue statement should be updated, as the Toronto comment has
13281already been resolved. E.g., char_traits specializations for char16_t
13282and char32_t are now in the working paper.
13283</p>
13284</blockquote>
13285
13286<p><i>[
13287Sophia Antipolis:
13288]</i></p>
13289
13290
13291<blockquote>
13292Nobody has submitted the requested paper, so we move to NAD, as suggested by the decision at the last meeting.
13293</blockquote>
13294
13295
13296<p><b>Proposed resolution:</b></p>
13297
13298
13299
13300
13301
13302<hr>
13303<h3><a name="571"></a>571. Update C90 references to C99?</h3>
13304<p><b>Section:</b> 1.2 [intro.refs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
13305 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2006-04-08  <b>Last modified:</b> 2007-07-02</p>
13306<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#intro.refs">issues</a> in [intro.refs].</p>
13307<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
13308<p><b>Discussion:</b></p>
13309<p>
133101.2 Normative references [intro.refs] of the WP currently refers to ISO/IEC
133119899:1990, Programming languages - C. Should that be changed to ISO/IEC
133129899:1999?
13313</p>
13314<p>
13315What impact does this have on the library?
13316</p>
13317
13318
13319<p><b>Proposed resolution:</b></p>
13320<p>
13321In 1.2/1 [intro.refs] of the WP, change:
13322</p>
13323<blockquote>
13324<ul>
13325<li>ISO/IEC 9899:<del>1990</del><ins>1999 + TC1 + TC2</ins>, <i>Programming languages - C</i></li>
13326</ul>
13327</blockquote>
13328
13329
13330
13331<p><b>Rationale:</b></p>
13332Recommend NAD, fixed editorially.
13333
13334
13335
13336
13337
13338<hr>
13339<h3><a name="572"></a>572. Oops, we gave 507 WP status</h3>
13340<p><b>Section:</b> 26.5 [rand], TR1 5.1 [tr.rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
13341 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2006-04-11  <b>Last modified:</b> 2007-04-18</p>
13342<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>
13343<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
13344<p><b>Discussion:</b></p>
13345<p>
13346In Berlin, as a working group, we voted in favor of N1932 which makes issue 507 moot:
13347variate_generator has been eliminated.  Then in full committee we voted to give
13348this issue WP status (mistakenly).
13349</p>
13350
13351
13352<p><b>Proposed resolution:</b></p>
13353<p>
13354Strike the proposed resolution of issue 507.
13355</p>
13356<p><i>[
13357post-Portland:  Walter and Howard recommend NAD.  The proposed resolution of 507 no longer
13358exists in the current WD.
13359]</i></p>
13360
13361
13362
13363<p><b>Rationale:</b></p>
13364<p>
13365NAD.  Will be moot once
13366<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2135.pdf">N2135</a>
13367is adopted.
13368</p>
13369
13370
13371
13372
13373
13374<hr>
13375<h3><a name="573"></a>573. C++0x file positioning should handle modern file sizes</h3>
13376<p><b>Section:</b> 27.5.3 [fpos] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
13377 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2006-04-12  <b>Last modified:</b> 2009-07-15</p>
13378<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fpos">issues</a> in [fpos].</p>
13379<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
13380<p><b>Discussion:</b></p>
13381<p>
13382There are two deficiencies related to file sizes:
13383</p>
13384<ol>
13385<li>It doesn't appear that the Standard Library is specified in
13386      a way that handles modern file sizes, which are often too
13387      large to be represented by an unsigned long.</li>
13388
13389<li>The std::fpos class does not currently have the ability to
13390      set/get file positions.</li>
13391</ol>
13392<p>
13393The Dinkumware implementation of the Standard Library as shipped with the Microsoft compiler copes with these issues by:
13394</p>
13395<ol type="A">
13396<li>Defining fpos_t be long long, which is large enough to
13397      represent any file position likely in the foreseeable future.</li>
13398
13399<li>Adding member functions to class fpos. For example,
13400<blockquote><pre>fpos_t seekpos() const;
13401</pre></blockquote>
13402</li>
13403</ol>
13404<p>
13405Because there are so many types relating to file positions and offsets (fpos_t,
13406fpos, pos_type, off_type, streamoff, streamsize, streampos, wstreampos, and
13407perhaps more), it is difficult to know if the Dinkumware extensions are
13408sufficient. But they seem a useful starting place for discussions, and they do
13409represent existing practice.
13410</p>
13411
13412<p><i>[
13413Kona (2007): We need a paper. It would be nice if someone proposed
13414clarifications to the definitions of <tt>pos_type</tt> and <tt>off_type</tt>. Currently
13415these definitions are horrible. Proposed Disposition: Open
13416]</i></p>
13417
13418
13419<p><i>[
134202009-07 Frankfurt
13421]</i></p>
13422
13423
13424<blockquote>
13425<p>
13426This is the subject of paper N2926.
13427</p>
13428<p>
13429If we choose to take any action, we will move the paper, so the issue can be closed.
13430</p>
13431<p>
13432Move to NAD.
13433</p>
13434</blockquote>
13435
13436
13437
13438<p><b>Proposed resolution:</b></p>
13439<p>
13440</p>
13441
13442
13443
13444
13445
13446<hr>
13447<h3><a name="579"></a>579. erase(iterator) for unordered containers should not return an iterator</h3>
13448<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#NAD">NAD</a>
13449 <b>Submitter:</b> Joaqu�n M L�pez Mu�oz <b>Opened:</b> 2006-06-13  <b>Last modified:</b> 2008-03-12</p>
13450<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>
13451<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>
13452<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
13453<p><b>Discussion:</b></p>
13454<p>
13455See
13456<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2023.pdf">N2023</a>
13457for full discussion.
13458</p>
13459
13460
13461<p><b>Proposed resolution:</b></p>
13462<p>
13463Option 1:
13464</p>
13465
13466<p>
13467The problem can be eliminated by omitting the requirement that <tt>a.erase(q)</tt> return an 
13468iterator. This is, however, in contrast with the equivalent requirements for other 
13469standard containers.
13470</p>
13471
13472<p>
13473Option 2:
13474</p>
13475
13476<p>
13477<tt>a.erase(q)</tt> can be made to compute the next iterator only when explicitly requested: 
13478the technique consists in returning a proxy object implicitly convertible to <tt>iterator</tt>, so 
13479that
13480</p>
13481
13482<blockquote><pre>iterator q1=a.erase(q);
13483</pre></blockquote>
13484
13485<p>
13486works as expected, while
13487</p>
13488
13489<blockquote><pre>a.erase(q);
13490</pre></blockquote>
13491
13492<p>
13493does not ever invoke the conversion-to-iterator operator, thus avoiding the associated 
13494computation. To allow this technique, some sections of TR1 along the line "return value 
13495is an iterator..." should be changed to "return value is an unspecified object implicitly 
13496convertible to an iterator..." Although this trick is expected to work transparently, it can 
13497have some collateral effects when the expression <tt>a.erase(q)</tt> is used inside generic 
13498code.
13499</p>
13500
13501
13502
13503<p><b>Rationale:</b></p>
13504<p>
13505<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2023.pdf">N2023</a>
13506was discussed in Portland and the consensus was that there appears to be
13507no need for either change proposed in the paper.  The consensus opinion
13508was that since the iterator could serve as its own proxy, there appears
13509to be no need for the change. In general, "converts to" is undesirable
13510because it interferes with template matching.
13511</p>
13512
13513<p>
13514Post Toronto:  There does not at this time appear to be consensus with the Portland consensus. 
13515</p>
13516
13517<p><i>[
13518Bellevue:
13519]</i></p>
13520
13521
13522<blockquote>
13523The Bellevue review of this issue reached consensus with the Portland
13524consensus, in contravention of the Toronto non-consensus. Common
13525implementations have the iterator readily available, and most common
13526uses depend on the iterator being returned.
13527</blockquote>
13528
13529
13530
13531
13532
13533
13534<hr>
13535<h3><a name="580"></a>580. unused allocator members</h3>
13536<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#NAD%20Editorial">NAD Editorial</a>
13537 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-14  <b>Last modified:</b> 2009-10-26</p>
13538<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>
13539<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>
13540<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
13541<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a></p>
13542<p><b>Discussion:</b></p>
13543        <p>
13544
13545C++ Standard Library  templates that take an allocator  as an argument
13546are    required    to    call    the    <code>allocate()</code>    and
13547<code>deallocate()</code>  members of the  allocator object  to obtain
13548storage.  However, they do not appear to be required to call any other
13549allocator      members      such     as      <code>construct()</code>,
13550<code>destroy()</code>,           <code>address()</code>,          and
13551<code>max_size()</code>.  This makes these allocator members less than
13552useful in portable programs.
13553
13554        </p>
13555        <p>
13556
13557It's unclear to me whether the absence of the requirement to use these
13558allocator  members  is  an  unintentional  omission  or  a  deliberate
13559choice. However,  since the functions exist in  the standard allocator
13560and  since  they are  required  to  be  provided by  any  user-defined
13561allocator I  believe the standard  ought to be clarified  to explictly
13562specify  whether programs  should or  should not  be able  to  rely on
13563standard containers calling the functions.
13564
13565        </p>
13566        <p>
13567
13568I  propose  that all  containers  be required  to  make  use of  these
13569functions.
13570
13571        </p>
13572<p><i>[
13573Batavia:  We support this resolution.  Martin to provide wording.
13574]</i></p>
13575
13576<p><i>[
13577pre-Oxford:  Martin provided wording.
13578]</i></p>
13579
13580
13581<p><i>[
135822009-04-28 Pablo adds:
13583]</i></p>
13584
13585
13586<blockquote>
13587<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2554.pdf">N2554</a>
13588(scoped allocators),
13589<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2768.pdf">N2768</a>
13590(allocator concepts), and
13591<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2810.pdf">N2810</a>
13592(allocator defects), address all of these points EXCEPT <tt>max_size()</tt>.
13593So, I would add a note to that affect and re-class the defect as belonging
13594to section 23.2.1 [container.requirements.general].
13595</blockquote>
13596
13597<p><i>[
135982009-07 Frankfurt
13599]</i></p>
13600
13601
13602<blockquote>
13603The comment in the description of this issue that this "would be"
13604rendered editorial by the adoption of N2257 is confusing. It appears
13605that N2257 was never adopted.
13606</blockquote>
13607
13608<p><i>[
136092009-10 Santa Cruz:
13610]</i></p>
13611
13612
13613<blockquote>
13614NAD Editorial.  Addressed by
13615<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>.
13616</blockquote>
13617
13618
13619
13620    <p><b>Proposed resolution:</b></p>
13621       <p>
13622
13623Specifically, I propose to change 23.2 [container.requirements],
13624p9 as follows:
13625
13626       </p>
13627           <blockquote>
13628<p>
13629-9- Copy constructors  for all container types defined  in this clause
13630<ins>that   are  parametrized  on   <code>Allocator</code></ins>  copy
13631<del>an</del><ins>the</ins>  allocator argument from  their respective
13632first parameters.
13633
13634All other  constructors for  these container types  take a<del>n</del>
13635<ins>const</ins>  <code>Allocator&amp;</code>  argument  (20.1.6),  an
13636allocator whose <code>value_type</code> is the same as the container's
13637<code>value_type</code>.
13638
13639A copy of this  argument <del>is</del><ins>shall be</ins> used for any
13640memory  allocation <ins> and  deallocation</ins> performed<del>,</del>
13641by these  constructors and by all  member functions<del>,</del> during
13642the  lifetime  of each  container  object.   <ins>Allocation shall  be
13643performed  "as  if"  by  calling  the  <code>allocate()</code>  member
13644function on  a copy  of the allocator  object of the  appropriate type
13645<sup>New  Footnote)</sup>,   and  deallocation  "as   if"  by  calling
13646<code>deallocate()</code> on  a copy of  the same allocator  object of
13647the corresponding type.</ins>
13648
13649<ins>A  copy of  this argument  shall also  be used  to  construct and
13650destroy objects whose lifetime  is managed by the container, including
13651but not  limited to those of  the container's <code>value_type</code>,
13652and  to  obtain  their  address.   All  objects  residing  in  storage
13653allocated by a  container's allocator shall be constructed  "as if" by
13654calling the <code>construct()</code> member  function on a copy of the
13655allocator object of  the appropriate type.  The same  objects shall be
13656destroyed "as if"  by calling <code>destroy()</code> on a  copy of the
13657same allocator object  of the same type.  The  address of such objects
13658shall be obtained "as if" by calling the <code>address()</code> member
13659function  on  a  copy  of  the allocator  object  of  the  appropriate
13660type.</ins>
13661
13662<ins>Finally, a copy  of this argument shall be  used by its container
13663object to determine  the maximum number of objects  of the container's
13664<code>value_type</code> the container may  store at the same time. The
13665container  member function <code>max_size()</code> obtains  this number
13666from      the      value      returned      by     a      call      to
13667<code>get_allocator().max_size()</code>.</ins>
13668
13669In   all  container   types  defined   in  this   clause <ins>that  are
13670parametrized     on    <code>Allocator</code></ins>,     the    member
13671<code>get_allocator()</code>     returns     a     copy     of     the
13672<code>Allocator</code>     object     used     to    construct     the
13673container.<sup>258)</sup>
13674</p>
13675<p>
13676New Footnote: This type  may be different from <code>Allocator</code>:
13677it     may    be     derived    from     <code>Allocator</code>    via
13678<code>Allocator::rebind&lt;U&gt;::other</code>   for  the  appropriate
13679type <code>U</code>.
13680</p>
13681           </blockquote>
13682       <p>
13683
13684The proposed wording seems cumbersome but I couldn't think of a better
13685way   to  describe   the   requirement  that   containers  use   their
13686<code>Allocator</code>  to manage  only objects  (regardless  of their
13687type)  that  persist  over  their  lifetimes  and  not,  for  example,
13688temporaries  created on the  stack. That  is, containers  shouldn't be
13689required  to  call  <code>Allocator::construct(Allocator::allocate(1),
13690elem)</code>  just to  construct a  temporary copy  of an  element, or
13691<code>Allocator::destroy(Allocator::address(temp),     1)</code>    to
13692destroy temporaries.
13693
13694       </p>
13695
13696
13697<p><i>[
13698Howard: This same paragraph will need some work to accommodate <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#431">431</a>.
13699]</i></p>
13700
13701
13702<p><i>[
13703post Oxford:  This would be rendered NAD Editorial by acceptance of
13704<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
13705]</i></p>
13706
13707
13708
13709
13710
13711<hr>
13712<h3><a name="582"></a>582. specialized algorithms and volatile storage</h3>
13713<p><b>Section:</b> 20.8.13.2 [uninitialized.copy] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
13714 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-14  <b>Last modified:</b> 2009-07-15</p>
13715<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#uninitialized.copy">issues</a> in [uninitialized.copy].</p>
13716<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
13717<p><b>Discussion:</b></p>
13718
13719<p>Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1029">1029</a></p>
13720        <p>
13721
13722The specialized  algorithms [lib.specialized.algorithms] are specified
13723as having the general effect of invoking the following expression:
13724
13725        </p>
13726            <pre>
13727new (static_cast&lt;void*&gt;(&amp;*i))
13728    typename iterator_traits&lt;ForwardIterator&gt;::value_type (x)
13729
13730            </pre>
13731        <p>
13732
13733This  expression is  ill-formed  when the  type  of the  subexpression
13734<code>&amp;*i</code> is some volatile-qualified <code>T</code>.
13735
13736        </p>
13737
13738<p><i>[
13739Batavia:  Lack of support for proposed resolution but agree there is a
13740defect.  Howard to look at wording.  Concern that move semantics
13741properly expressed if iterator returns rvalue.
13742]</i></p>
13743
13744
13745
13746<p><i>[
137472009-06-17 Pablo adds:
13748]</i></p>
13749
13750
13751<blockquote>
13752
13753<p>Propose that Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#582">582</a> be closed NAD.</p>
13754<p>
13755Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#582">582</a> asks that <tt>uninitialized_copy</tt>,
13756<tt>uninitialized_fill</tt>, and <tt>uninitialized_fill_n</tt> should be
13757well-formed if the result type is volatile.  My feeling is that the
13758standard does not, and should not, guarantee any useful behavior when
13759constructors are invoked on volatile storage, so making it syntactically
13760legal to call <tt>uninitialized_copy</tt> on volatile storage is not useful. A
13761possible editorial change would be to put my previous sentence into a
13762non-normative note.
13763</p>
13764<p>
13765Note that the three sections starting with 20.8.13.2 [uninitialized.copy] do not
13766yet have concepts.  Here's a first crack at the first one:
13767</p>
13768<blockquote><pre>template &lt;InputIterator InIter, OutputIterator OutIter&gt;
13769requires ExplicitConvertible&lt;HasDereference&lt;OutIter::reference&gt;::result,
13770                             OutIter::value_type&amp;&gt;
13771      &amp;&amp; Convertible&lt;OutIter::value_type*, void*&gt;
13772      &amp;&amp; ExplicitConvertible&lt;OutIter::value_type, InIter::reference&gt;
13773  OutIter uninitialized_copy(InIter first, InIter last, OutIter result);
13774</pre>
13775<blockquote>
13776<p>
13777Effects:
13778</p>
13779<blockquote><pre>while (first != last) {
13780  typedef OutIter::value_type value_type;
13781  value_type&amp; outRef = static_cast&lt;value_type&amp;&gt;(*result++);
13782  ::new (static_cast&lt;void*&gt;(addressof(outRef))) value_type(*first++);
13783}
13784</pre></blockquote>
13785</blockquote>
13786
13787</blockquote>
13788
13789<p>
13790Notes:
13791</p>
13792<ol>
13793<li>This definition is actually LESS constrained than in C++03 because
13794there is no requirement that the result be a forward iterator.
13795</li>
13796<li>
13797If
13798OutIter returns a proxy type with an overloaded operator&amp;, this
13799definition probably won't compile.  Lifting this limitation while
13800allowing value_type to have an overloaded operator&amp; would be hard, but
13801is probably possible with careful overloading.  I'm not sure it's worth
13802it.
13803</li>
13804<li>
13805This definition retains the prohibition on the use of volatile types for the result.
13806</li>
13807</ol>
13808
13809</blockquote>
13810
13811<p><i>[
138122009-07 Frankfurt
13813]</i></p>
13814
13815
13816<blockquote>
13817<p>
13818We don't deal with volatile in the library.
13819</p>
13820<p>
13821Jim: should we state that explicitly somewhere?
13822</p>
13823<p>
13824Beman: you might argue that clause 17 should say something about
13825volatile. However, if you want to raise we argument, we should open it
13826as a separate issue and consult with experts on concurrency.
13827</p>
13828<p>
13829Hinnant: actually, some library components do handle volatile, so we'd
13830need to be very careful about what we say in clause 17.
13831</p>
13832<p>
13833No objection to NAD.
13834</p>
13835<p>
13836Move to NAD.
13837</p>
13838</blockquote>
13839
13840    
13841
13842    <p><b>Proposed resolution:</b></p>
13843        <p>
13844
13845In order  to allow these algorithms  to operate on  volatile storage I
13846propose to change the expression so as to make it well-formed even for
13847pointers  to volatile  types.  Specifically,  I propose  the following
13848changes to clauses 20 and 24. Change 20.6.4.1, p1 to read:
13849
13850        </p>
13851            <pre>
13852<i>Effects</i>:
13853
13854typedef typename iterator_traits&lt;ForwardIterator&gt;::pointer    pointer;
13855typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type value_type;
13856
13857for (; first != last; ++result, ++first)
13858    new (static_cast&lt;void*&gt;(const_cast&lt;pointer&gt;(&amp;*result))
13859        value_type (*first);
13860
13861            </pre>
13862        <p>
13863
13864change 20.6.4.2, p1 to read
13865
13866        </p>
13867            <pre>
13868<i>Effects</i>:
13869
13870typedef typename iterator_traits&lt;ForwardIterator&gt;::pointer    pointer;
13871typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type value_type;
13872
13873for (; first != last; ++result, ++first)
13874    new (static_cast&lt;void*&gt;(const_cast&lt;pointer&gt;(&amp;*first))
13875        value_type (*x);
13876
13877            </pre>
13878        <p>
13879
13880and change 20.6.4.3, p1 to read
13881
13882        </p>
13883            <pre>
13884<i>Effects</i>:
13885
13886typedef typename iterator_traits&lt;ForwardIterator&gt;::pointer    pointer;
13887typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type value_type;
13888
13889for (; n--; ++first)
13890    new (static_cast&lt;void*&gt;(const_cast&lt;pointer&gt;(&amp;*first))
13891        value_type (*x);
13892
13893            </pre>
13894        <p>
13895
13896In   addition,  since   there   is  no   partial  specialization   for
13897<code>iterator_traits&lt;volatile T*&gt;</code>  I propose to  add one
13898to parallel such specialization  for &lt;const T*&gt;. Specifically, I
13899propose to add the following text to the end of 24.3.1, p3:
13900
13901        </p>
13902        <p>
13903
13904and for pointers to volatile as 
13905
13906        </p>
13907            <pre>
13908namespace std {
13909template&lt;class T&gt; struct iterator_traits&lt;volatile T*&gt; {
13910typedef ptrdiff_t difference_type;
13911typedef T value_type;
13912typedef volatile T* pointer;
13913typedef volatile T&amp; reference;
13914typedef random_access_iterator_tag iterator_category;
13915};
13916}
13917
13918            </pre>
13919        <p>
13920
13921Note that  the change to  <code>iterator_traits</code> isn't necessary
13922in order to implement the  specialized algorithms in a way that allows
13923them to operate on volatile  strorage. It is only necesassary in order
13924to specify  their effects in terms  of <code>iterator_traits</code> as
13925is  done here.   Implementations can  (and some  do) achieve  the same
13926effect by means of function template overloading.
13927
13928        </p>
13929    
13930
13931
13932
13933<hr>
13934<h3><a name="583"></a>583. div() for unsigned integral types</h3>
13935<p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
13936 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2006-06-15  <b>Last modified:</b> 2007-07-25</p>
13937<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
13938<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
13939<p><b>Discussion:</b></p>
13940<p>
13941There is no div() function for unsigned integer types.
13942</p>
13943<p>
13944There are several possible resolutions.  The simplest one is noted below.  Other
13945possibilities include a templated solution.
13946</p>
13947
13948
13949<p><b>Proposed resolution:</b></p>
13950<p>
13951Add to 26.7 [lib.c.math] paragraph 8:
13952</p>
13953
13954<blockquote><pre>struct udiv_t div(unsigned, unsigned);
13955struct uldiv_t div(unsigned long, unsigned long);
13956struct ulldiv_t div(unsigned long long, unsigned long long);
13957</pre></blockquote>
13958
13959
13960
13961<p><b>Rationale:</b></p>
13962Toronto:  C99 does not have these unsigned versions because
13963the signed version exist just to define the implementation-defined behavior
13964of signed integer division.  Unsigned integer division has no implementation-defined
13965behavior and thus does not need this treatment.
13966
13967
13968
13969
13970
13971<hr>
13972<h3><a name="584"></a>584. missing int pow(int,int) functionality</h3>
13973<p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
13974 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2006-06-15  <b>Last modified:</b> 2007-07-25</p>
13975<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
13976<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
13977<p><b>Discussion:</b></p>
13978<p>
13979There is no pow() function for any integral type.
13980</p>
13981
13982
13983<p><b>Proposed resolution:</b></p>
13984<p>
13985Add something like:
13986</p>
13987
13988<blockquote><pre>template&lt; typename T&gt;
13989T power( T x, int n );
13990// requires: n &gt;=0
13991</pre></blockquote>
13992
13993
13994<p><b>Rationale:</b></p>
13995Toronto:  We already have double pow(integral, integral) from 26.8 [c.math] p11.
13996
13997
13998
13999
14000
14001<hr>
14002<h3><a name="585"></a>585. facet error reporting</h3>
14003<p><b>Section:</b> 22.4 [locale.categories] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
14004 <b>Submitter:</b> Martin Sebor, Paolo Carlini <b>Opened:</b> 2006-06-22  <b>Last modified:</b> 2009-07-15</p>
14005<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.categories">issues</a> in [locale.categories].</p>
14006<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
14007<p><b>Discussion:</b></p>
14008        <p>
14009
14010Section  22.2, paragraph 2  requires facet  <code>get()</code> members
14011that    take    an    <code>ios_base::iostate&amp;</code>    argument,
14012<code><i>err</i></code>,  to   ignore  the  (initial)   value  of  the
14013argument, but to set it to <code>ios_base::failbit</code> in case of a
14014parse error.
14015
14016        </p>
14017        <p>
14018
14019We  believe  there  are  a   few  minor  problems  with  this  blanket
14020requirement  in   conjunction  with   the  wording  specific   to  each
14021<code>get()</code> member function.
14022
14023        </p>
14024        <p>
14025
14026First,  besides <code>get()</code>  there are  other  member functions
14027with     a      slightly     different     name      (for     example,
14028<code>get_date()</code>). It's not completely clear that the intent of
14029the  paragraph  is  to  include  those  as  well,  and  at  least  one
14030implementation has interpreted the requirement literally.
14031
14032        </p>
14033        <p>
14034
14035Second,    the     requirement    to    "set     the    argument    to
14036<code>ios_base::failbit</code>  suggests that  the  functions are  not
14037permitted    to   set    it   to    any   other    value    (such   as
14038<code>ios_base::eofbit</code>,   or   even  <code>ios_base::eofbit   |
14039ios_base::failbit</code>).
14040
14041        </p>
14042        <p>
14043
14044However, 22.2.2.1.2, p5 (Stage  3 of <code>num_get</code> parsing) and
14045p6 (<code>bool</code> parsing)  specifies that the <code>do_get</code>
14046functions  perform <code><i>err</i> |=  ios_base::eofbit</code>, which
14047contradicts  the earlier  requirement to  ignore  <i>err</i>'s initial
14048value.
14049
14050        </p>
14051        <p>
14052
1405322.2.6.1.2,  p1  (the  Effects  clause of  the  <code>money_get</code>
14054facet's  <code>do_get</code>  member  functions) also  specifies  that
14055<code><i>err</i></code>'s initial  value be used to  compute the final
14056value  by  ORing  it  with  either  <code>ios_base::failbit</code>  or
14057with<code>ios_base::eofbit | ios_base::failbit</code>.
14058
14059        </p>
14060
14061<p><i>[
140622009-07 Frankfurt
14063]</i></p>
14064
14065
14066<blockquote>
14067Move to NAD.
14068</blockquote>
14069
14070    
14071
14072    <p><b>Proposed resolution:</b></p>
14073        <p>
14074
14075We believe the  intent is for all facet member  functions that take an
14076<code>ios_base::iostate&amp;</code> argument to:
14077
14078        </p>
14079            <ul>
14080                <li>
14081
14082ignore the initial value of the <code><i>err</i></code> argument,
14083
14084                </li>
14085                <li>
14086
14087reset <code><i>err</i></code>  to <code>ios_base::goodbit</code> prior
14088to any further processing,
14089
14090                </li>
14091                <li>
14092
14093and       set      either       <code>ios_base::eofbit</code>,      or
14094<code>ios_base::failbit</code>, or both in <code><i>err</i></code>, as
14095appropriate,  in response  to  reaching the  end-of-file  or on  parse
14096error, or both.
14097
14098                </li>
14099            </ul>
14100        <p>
14101
14102To that effect we propose to change 22.2, p2 as follows:
14103
14104        </p>
14105        <p>
14106
14107The  <i>put</i><del>()</del>  members  make  no  provision  for  error
14108reporting.   (Any  failures of  the  OutputIterator  argument must  be
14109extracted   from  the   returned  iterator.)    <ins>Unless  otherwise
14110specified, </ins>the <i>get</i><del>()</del>  members  <ins>that</ins>
14111take an  <code>ios_base::iostate&amp;</code> argument <del>whose value
14112they  ignore,  but  set  to  ios_base::failbit  in  case  of  a  parse
14113error.</del><ins>,   <code><i>err</i></code>,   start  by   evaluating
14114<code>err  =   ios_base::goodbit</code>,  and  may   subsequently  set
14115<i>err</i>     to     either     <code>ios_base::eofbit</code>,     or
14116<code>ios_base::failbit</code>,     or     <code>ios_base::eofbit    |
14117ios_base::failbit</code> in response to reaching the end-of-file or in
14118case of a parse error, or both, respectively.</ins>
14119
14120        </p>
14121    
14122    
14123<p><i>[
14124Kona (2007): We need to change the proposed wording to clarify that the
14125phrase "the get members" actually denotes <tt>get()</tt>, <tt>get_date()</tt>, etc.
14126Proposed Disposition: Open
14127]</i></p>
14128
14129
14130
14131
14132<hr>
14133<h3><a name="587"></a>587. iststream ctor missing description</h3>
14134<p><b>Section:</b> D.8.2.1 [depr.istrstream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
14135 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-22  <b>Last modified:</b> 2007-05-11</p>
14136<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
14137<p><b>Discussion:</b></p>
14138        <p>
14139
14140The  <code>iststream(char*, streamsize)</code>  ctor is  in  the class
14141synopsis  in D.7.2  but its  signature is  missing in  the description
14142below (in D.7.2.1).
14143
14144        </p>
14145    
14146
14147    <p><b>Proposed resolution:</b></p>
14148        <p>
14149
14150This seems like a simple editorial issue and the missing signature can
14151be added to the one for <code>const char*</code> in paragraph 2.
14152
14153        </p>
14154
14155<p><i>[
14156post Oxford: Noted that it is already fixed in
14157<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a>
14158]</i></p>
14159
14160
14161    
14162
14163
14164
14165<hr>
14166<h3><a name="588"></a>588. requirements on zero sized tr1::arrays and other details</h3>
14167<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">NAD</a>
14168 <b>Submitter:</b> Gennaro Prota <b>Opened:</b> 2006-07-18  <b>Last modified:</b> 2009-10-20</p>
14169<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>
14170<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
14171<p><b>Discussion:</b></p>
14172<p>
14173The wording used for section 23.2.1 [lib.array] seems to be subtly
14174ambiguous about zero sized arrays (N==0). Specifically:
14175</p>
14176<p>
14177* "An instance of array&lt;T, N&gt; stores N elements of type T, so that
14178[...]"
14179</p>
14180<p>
14181Does this imply that a zero sized array object stores 0 elements, i.e.
14182that it cannot store any element of type T? The next point clarifies
14183the rationale behind this question, basically how to implement begin()
14184and end():
14185</p>
14186<p>
14187* 23.2.1.5 [lib.array.zero], p2: "In the case that N == 0, begin() ==
14188end() == unique value."
14189</p>
14190<p>
14191What does "unique" mean in this context? Let's consider the following
14192possible implementations, all relying on a partial specialization:
14193</p>
14194<blockquote><pre>a)
14195    template&lt; typename T &gt;
14196    class array&lt; T, 0 &gt; {
14197    
14198        ....
14199
14200        iterator begin()
14201        { return iterator( reinterpret_cast&lt; T * &gt;( this ) ); }
14202        ....
14203
14204    };
14205</pre></blockquote>
14206<p>
14207This has been used in boost, probably intending that the return value
14208had to be unique to the specific array object and that array couldn't
14209store any T. Note that, besides relying on a reinterpret_cast, has
14210(more than potential) alignment problems.
14211</p>
14212<blockquote><pre>b)
14213    template&lt; typename T &gt;
14214    class array&lt; T, 0 &gt; {
14215    
14216        T t;
14217
14218        iterator begin()
14219        { return iterator( &amp;t ); }
14220        ....
14221
14222    };
14223</pre></blockquote>
14224<p>
14225This provides a value which is unique to the object and to the type of
14226the array, but requires storing a T. Also, it would allow the user to
14227mistakenly provide an initializer list with one element.
14228</p>
14229<p>
14230A slight variant could be returning *the* null pointer of type T
14231</p>
14232<blockquote><pre>    return static_cast&lt;T*&gt;(0);
14233</pre></blockquote>
14234<p>
14235In this case the value would be unique to the type array&lt;T, 0&gt; but not
14236to the objects (all objects of type array&lt;T, 0&gt; with the same value
14237for T would yield the same pointer value).
14238</p>
14239<p>
14240Furthermore this is inconsistent with what the standard requires from
14241allocation functions (see library issue 9).
14242</p>
14243<p>
14244c) same as above but with t being a static data member; again, the
14245value would be unique to the type, not to the object.
14246</p>
14247<p>
14248d) to avoid storing a T *directly* while disallowing the possibility
14249to use a one-element initializer list a non-aggregate nested class
14250could be defined
14251</p>
14252<blockquote><pre>    struct holder { holder() {} T t; } h;
14253</pre></blockquote>
14254<p>
14255and then begin be defined as
14256</p>
14257<blockquote><pre> iterator begin() { return &amp;h.t; }
14258</pre></blockquote>
14259<p>
14260But then, it's arguable whether the array stores a T or not.
14261Indirectly it does.
14262</p>
14263<p>
14264-----------------------------------------------------
14265</p>
14266<p>
14267Now, on different issues:
14268</p>
14269<p>
14270* what's the effect of calling assign(T&amp;) on a zero-sized array? There
14271seems to be only mention of front() and back(), in 23.2.1 [lib.array]
14272p4 (I would also suggest to move that bullet to section 23.2.1.5
14273[lib.array.zero], for locality of reference)
14274</p>
14275<p>
14276* (minor) the opening paragraph of 23.2.1 [lib.array] wording is a bit
14277inconsistent with that of other sequences: that's not a problem in
14278itself, but compare it for instance with "A vector is a kind of
14279sequence that supports random access iterators"; though the intent is
14280obvious one might argue that the wording used for arrays doesn't tell
14281what an array is, and relies on the reader to infer that it is what
14282the &lt;array&gt; header defines.
14283</p>
14284<p>
14285* it would be desiderable to have a static const data member of type
14286std::size_t, with value N, for usage as integral constant expression
14287</p>
14288<p>
14289* section 23.1 [lib.container.requirements] seem not to consider
14290fixed-size containers at all, as it says: "[containers] control
14291allocation and deallocation of these objects [the contained objects]
14292through constructors, destructors, *insert and erase* operations"
14293</p>
14294<p>
14295* max_size() isn't specified: the result is obvious but, technically,
14296it relies on table 80: "size() of the largest possible container"
14297which, again, doesn't seem to consider fixed size containers
14298</p>
14299
14300<p><i>[
143012009-05-29 Daniel adds:
14302]</i></p>
14303
14304
14305<blockquote>
14306<ol type="a">
14307<li>
14308<p>
14309star bullet 1 ("what's the effect of calling <tt>assign(T&amp;)</tt> on a
14310zero-sized array?[..]");
14311</p>
14312<blockquote>
14313<tt>assign</tt> has been renamed to <tt>fill</tt> and the semantic of <tt>fill</tt> is now
14314defined in terms of
14315the free algorithm <tt>fill_n</tt>, which is well-defined for this situation.
14316</blockquote>
14317</li>
14318<li>
14319<p>
14320star bullet 3 ("it would be desiderable to have a static const data
14321member..."):
14322</p>
14323<blockquote>
14324It seems that <tt>tuple_size&lt;array&lt;T, N&gt; &gt;::value</tt> as of 23.3.1.7 [array.tuple] does
14325provide this functionality now.
14326</blockquote>
14327</li>
14328</ol>
14329</blockquote>
14330
14331<p><i>[
143322009-07 Frankfurt
14333]</i></p>
14334
14335
14336<blockquote>
14337<p>
14338Alisdair to address by the next meeting, or declare NAD.
14339</p>
14340<p>
14341Moved to Tentatively NAD.
14342</p>
14343</blockquote>
14344
14345<p><i>[
143462009 Santa Cruz:
14347]</i></p>
14348
14349
14350<blockquote>
14351Moved to NAD.
14352</blockquote>
14353
14354
14355
14356<p><b>Proposed resolution:</b></p>
14357<p>
14358</p>
14359
14360
14361<p><i>[
14362Kona (2007): requirements on zero sized <tt>tr1::array</tt>s and other details
14363Issue 617: <tt>std::array</tt> is a sequence that doesn't satisfy the sequence
14364requirements? Alisdair will prepare a paper. Proposed Disposition: Open
14365]</i></p>
14366
14367
14368
14369
14370
14371<hr>
14372<h3><a name="590"></a>590. Type traits implementation latitude should be removed for C++0x</h3>
14373<p><b>Section:</b> 20.6 [meta], TR1 4.9 [tr.meta.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
14374 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2006-08-10  <b>Last modified:</b> 2007-05-11</p>
14375<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>
14376<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
14377<p><b>Discussion:</b></p>
14378<p>
1437920.4.9 [lib.meta.req], Implementation requirements, provides latitude for type
14380traits implementers that is not needed in C++0x. It includes the wording:
14381</p>
14382
14383<blockquote><p>
14384[<i>Note:</i> the latitude granted to implementers in this clause is temporary,
14385and is expected to be removed in future revisions of this document. -- <i>end note</i>]
14386</p></blockquote>
14387
14388<p>
14389Note:
14390<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html">N2157: Minor Modifications to the type traits Wording</a>
14391also has the intent of removing this wording from the WP.
14392</p>
14393
14394
14395
14396<p><b>Proposed resolution:</b></p>
14397<p>
14398Remove 20.4.9 [lib.meta.req] in its entirety from the WP.
14399</p>
14400
14401<p><i>[
14402post-Oxford: Recommend NAD Editorial.  This resolution is now in the
14403current working draft.
14404]</i></p>
14405
14406
14407
14408
14409
14410
14411
14412<hr>
14413<h3><a name="591"></a>591. Misleading "built-in</h3>
14414<p><b>Section:</b> 18.3.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
14415 <b>Submitter:</b> whyglinux <b>Opened:</b> 2006-08-08  <b>Last modified:</b> 2007-07-02</p>
14416<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.limits.members">issues</a> in [numeric.limits.members].</p>
14417<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
14418<p><b>Discussion:</b></p>
14419<p>
1442018.2.1.2 numeric_limits members [lib.numeric.limits.members]
14421Paragraph 7:
14422</p>
14423<blockquote><p>
14424"For built-in integer types, the number of non-sign bits in the
14425representation."
14426</p></blockquote>
14427
14428<p>
1442926.1 Numeric type requirements [lib.numeric.requirements]
14430Footnote:
14431</p>
14432
14433<blockquote><p>
14434"In other words, value types. These include built-in arithmetic types,
14435pointers, the library class complex, and instantiations of valarray for
14436value types."
14437</p></blockquote>
14438
14439<p>
14440Integer types (which are bool, char, wchar_t, and the signed and
14441unsigned integer types) and arithmetic types (which are integer and
14442floating types) are all built-in types and thus there are no
14443non-built-in (that is, user-defined) integer or arithmetic types. Since
14444the redundant "built-in" in the above 2 sentences can mislead that
14445there may be built-in or user-defined integer and arithmetic types
14446(which is not correct), the "built-in" should be removed.
14447</p>
14448
14449
14450<p><b>Proposed resolution:</b></p>
14451<p>
1445218.2.1.2 numeric_limits members [lib.numeric.limits.members]
14453Paragraph 7:
14454</p>
14455<blockquote><p>
14456"For <del>built-in</del> integer types, the number of non-sign bits in the
14457representation."
14458</p></blockquote>
14459
14460<p>
1446126.1 Numeric type requirements [lib.numeric.requirements]
14462Footnote:
14463</p>
14464
14465<blockquote><p>
14466"In other words, value types. These include <del>built-in</del> arithmetic types,
14467pointers, the library class complex, and instantiations of valarray for
14468value types."
14469</p></blockquote>
14470
14471
14472<p><b>Rationale:</b></p>
14473<p>
14474Recommend NAD / Editorial.  The proposed resolution is accepted as editorial.
14475</p>
14476
14477
14478
14479
14480
14481<hr>
14482<h3><a name="592"></a>592. Incorrect treatment of rdbuf()-&gt;close() return type</h3>
14483<p><b>Section:</b> 27.9.1.9 [ifstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
14484 <b>Submitter:</b> Christopher Kohlhoff <b>Opened:</b> 2006-08-17  <b>Last modified:</b> 2008-07-02</p>
14485<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ifstream.members">issues</a> in [ifstream.members].</p>
14486<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
14487<p><b>Discussion:</b></p>
14488<p>
14489I just spotted a minor problem in 27.8.1.7
14490[lib.ifstream.members] para 4 and also 27.8.1.13
14491[lib.fstream.members] para 4. In both places it says:
14492</p>
14493<blockquote>
14494<pre>void close();
14495</pre>
14496<p>
14497Effects: Calls rdbuf()-&gt;close() and, if that function returns false, ...
14498</p>
14499</blockquote>
14500<p>
14501However, basic_filebuf::close() (27.8.1.2) returns a pointer to the
14502filebuf on success, null on failure, so I think it is meant to
14503say "if that function returns a null pointer". Oddly, it is
14504correct for basic_ofstream.
14505</p>
14506
14507
14508<p><b>Proposed resolution:</b></p>
14509<p>
14510Change 27.9.1.9 [ifstream.members], p5:
14511</p>
14512
14513<blockquote><p>
14514<i>Effects:</i> Calls <tt>rdbuf()-&gt;close()</tt> and, if that function
14515<ins>fails (</ins>returns <del><tt>false</tt></del> <ins>a null pointer)</ins>,
14516calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>
14517(27.4.4.3)).
14518</p></blockquote>
14519
14520<p>
14521Change 27.9.1.17 [fstream.members], p5:
14522</p>
14523
14524<blockquote><p>
14525<i>Effects:</i> Calls <tt>rdbuf()-&gt;close()</tt> and, if that function
14526<ins>fails (</ins>returns <del><tt>false</tt></del> <ins>a null pointer)</ins>,
14527calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>
14528(27.4.4.3)).
14529</p></blockquote>
14530
14531
14532
14533<p><i>[
14534Kona (2007): Proposed Disposition: NAD, Editorial
14535]</i></p>
14536
14537
14538
14539
14540
14541<hr>
14542<h3><a name="597"></a>597. Decimal: The notion of 'promotion' cannot be emulated by user-defined types.</h3>
14543<p><b>Section:</b> TRDecimal 3.2 [trdec.types.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
14544 <b>Submitter:</b> Daveed Vandevoorde <b>Opened:</b> 2006-04-05  <b>Last modified:</b> 2009-07-15</p>
14545<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types.types">issues</a> in [trdec.types.types].</p>
14546<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
14547<p><b>Discussion:</b></p>
14548<p>
14549In a private email, Daveed writes:
14550</p>
14551<blockquote>
14552<p>
14553I am not familiar with the C TR, but my guess is that the
14554class type approach still won't match a built-in type
14555approach because the notion of "promotion" cannot be
14556emulated by user-defined types.
14557</p>
14558<p>
14559Here is an example:
14560</p>
14561</blockquote>
14562<pre>
14563         struct S {
14564           S(_Decimal32 const&amp;);  // Converting constructor
14565         };
14566         void f(S);
14567
14568         void f(_Decimal64);
14569
14570         void g(_Decimal32 d) {
14571           f(d);
14572         }
14573</pre>
14574
14575<blockquote>
14576<p>
14577If _Decimal32 is a built-in type, the call f(d) will likely
14578resolve to f(_Decimal64) because that requires only a
14579promotion, whereas f(S) requires a user-defined conversion.
14580</p>
14581<p>
14582If _Decimal32 is a class type, I think the call f(d) will be
14583ambiguous because both the conversion to _Decimal64 and the
14584conversion to S will be user-defined conversions with neither
14585better than the other.
14586</p>
14587</blockquote>
14588<p>
14589Robert comments:
14590</p>
14591<p>In general, a library of arithmetic types cannot exactly emulate the
14592behavior of the intrinsic numeric types. There are several ways to tell
14593whether an implementation of the decimal types uses compiler
14594intrinisics or a library. For example:
14595</p>
14596<pre>                 _Decimal32 d1;
14597                 d1.operator+=(5);  // If d1 is a builtin type, this won't compile.
14598</pre>
14599<p>
14600In preparing the decimal TR, we have three options:
14601</p>
14602<ol>
14603<li>require that the decimal types be class types</li>
14604<li>require that the decimal types be builtin types, like float and double</li>
14605<li>specify a library of class types, but allow enough implementor
14606latitude that a conforming implementation could instead provide builtin
14607types</li>
14608</ol>
14609<p>
14610We decided as a group to pursue option #3, but that approach implies
14611that implementations may not agree on the semantics of certain use
14612cases (first example, above), or on whether certain other cases are
14613well-formed (second example). Another potentially important problem is
14614that, under the present definition of POD, the decimal classes are not
14615POD types, but builtins will be.
14616</p>
14617<p>Note that neither example above implies any problems with respect to
14618C-to-C++ compatibility, since neither example can be expressed in C.
14619</p>
14620
14621<p><i>[
146222009-07 Frankfurt
14623]</i></p>
14624
14625
14626<blockquote>
14627<p>
14628Decimal numeric types may either be builtin types or library types. We
14629only intend to specify the common subset of behaviors of the two
14630implementation approaches. The front matter of the Decimal TR says this
14631explicitly.
14632</p>
14633<p>
14634Move to NAD.
14635</p>
14636</blockquote>
14637
14638
14639
14640<p><b>Proposed resolution:</b></p>
14641
14642
14643
14644
14645
14646<hr>
14647<h3><a name="606"></a>606. Decimal: allow narrowing conversions</h3>
14648<p><b>Section:</b> TRDecimal 3.2 [trdec.types.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
14649 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-15  <b>Last modified:</b> 2009-07-15</p>
14650<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types.types">issues</a> in [trdec.types.types].</p>
14651<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
14652<p><b>Discussion:</b></p>
14653<p>
14654In c++std-lib-17205, Martin writes:
14655</p>
14656<blockquote><p>...was it a deliberate design choice to make narrowing
14657assignments ill-formed while permitting narrowing compound assignments?
14658For instance:
14659</p></blockquote>
14660<pre>      decimal32 d32;
14661      decimal64 d64;
14662
14663      d32 = 64;     // error
14664      d32 += 64;    // okay
14665</pre>
14666<p>
14667In c++std-lib-17229, Robert responds:
14668</p>
14669<blockquote><p>It is a vestige of an old idea that I forgot to remove
14670from the paper. Narrowing assignments should be permitted. The bug is
14671that the converting constructors that cause narrowing should not be
14672explicit. Thanks for pointing this out.
14673</p></blockquote>
14674
14675<p><i>[
146762009-07 Frankfurt
14677]</i></p>
14678
14679
14680<blockquote>
14681<p>
14682The current state of the Decimal TR is the result of a deliberate design
14683decision that has been examined many times.
14684</p>
14685<p>
14686Move to NAD.
14687</p>
14688</blockquote>
14689
14690
14691<p><b>Proposed resolution:</b></p>
14692<p>
146931.  In "3.2.2 Class <code>decimal32</code>" synopsis, remove the <code>explicit</code> specifier from the narrowing conversions:
14694</p>
14695<pre>                // <i>3.2.2.2 conversion from floating-point type:</i>
14696                <del>explicit</del> decimal32(decimal64 <i>d64</i>);
14697                <del>explicit</del> decimal32(decimal128 <i>d128</i>);
14698</pre>
14699<p>
147002.  Do the same thing in "3.2.2.2. Conversion from floating-point type."
14701</p>
14702<p>
147033.  In "3.2.3 Class <code>decimal64</code>" synopsis, remove the <code>explicit</code> specifier from the narrowing conversion:
14704</p>
14705<pre>                // <i>3.2.3.2 conversion from floating-point type:</i>
14706                <del>explicit</del> decimal64(decimal128 <i>d128</i>);
14707</pre>
14708<p>
147094.  Do the same thing in "3.2.3.2. Conversion from floating-point type."
14710</p>
14711
14712<p><i>[
14713Redmond: We prefer explicit conversions for narrowing and implicit for widening.
14714]</i></p>
14715
14716
14717
14718
14719
14720
14721<hr>
14722<h3><a name="614"></a>614. std::string allocator requirements still inconsistent</h3>
14723<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#NAD">NAD</a>
14724 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2006-12-05  <b>Last modified:</b> 2009-07-15</p>
14725<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>
14726<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
14727<p><b>Discussion:</b></p>
14728<p>
14729This is based on N2134, where 21.3.1/2 states:
14730"... The Allocator object used shall be a copy of the Allocator object 
14731passed to the basic_string object's constructor or, if the constructor does 
14732not take an Allocator argument, a copy of a default-constructed Allocator 
14733object."
14734</p>
14735<p>
14736Section 21.3.2/1 lists two constructors:
14737</p>
14738<blockquote><pre>basic_string(const basic_string&lt;charT,traits,Allocator&gt;&amp; str );
14739
14740basic_string(const basic_string&lt;charT,traits,Allocator&gt;&amp; str ,
14741             size_type pos , size_type n = npos,
14742             const Allocator&amp; a = Allocator());
14743</pre></blockquote>
14744<p>
14745and then says "In the first form, the Allocator value used is copied from 
14746str.get_allocator().", which isn't an option according to 21.3.1.
14747</p>
14748<p><i>[
14749Batavia:  We need blanket statement to the effect of:
14750]</i></p>
14751
14752
14753<ol>
14754<li>If an allocator is passed in, use it, or,</li>
14755<li>If a string is passed in, use its allocator.</li>
14756</ol>
14757<p><i>[
14758Review constructors and functions that return a string; make sure we follow these
14759rules (substr, operator+, etc.).  Howard to supply wording.
14760]</i></p>
14761
14762
14763<p><i>[
14764Bo adds:  The new container constructor which takes only a <tt>size_type</tt> is not
14765consistent with 23.2 [container.requirements], p9 which says in part:
14766
14767<blockquote>
14768All other constructors for these container types take an
14769<tt>Allocator&amp;</tt> argument (20.1.2), an allocator whose value type
14770is the same as the container's value type. A copy of this argument is
14771used for any memory allocation performed, by these constructors and by
14772all member functions, during the lifetime of each container object.
14773</blockquote>
14774]</i></p>
14775
14776
14777<p><i>[
14778post Bellevue: We re-confirm that the issue is real. Pablo will provide wording.
14779]</i></p>
14780
14781
14782<p><i>[
147832009-07 Frankfurt
14784]</i></p>
14785
14786
14787<blockquote>
14788Move to NAD.
14789</blockquote>
14790
14791
14792
14793<p><b>Proposed resolution:</b></p>
14794<p>
14795</p>
14796
14797
14798
14799
14800
14801<hr>
14802<h3><a name="615"></a>615. Inconsistencies in Section 21.4</h3>
14803<p><b>Section:</b> 21.6 [c.strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
14804 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2006-12-11  <b>Last modified:</b> 2007-04-24</p>
14805<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.strings">issues</a> in [c.strings].</p>
14806<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
14807<p><b>Discussion:</b></p>
14808<p>
14809In the current draft N2134, 21.4/1 says
14810</p>
14811<p>
14812"Tables 59,228) 60, 61, 62,and 63 229) 230) describe headers &lt;cctype&gt;, 
14813&lt;cwctype&gt;, &lt;cstring&gt;, &lt;cwchar&gt;, and &lt;cstdlib&gt; (character conversions), 
14814respectively."
14815</p>
14816<p>
14817Here footnote 229 applies to table 62, not table 63.
14818</p>
14819<p>
14820Also, footnote 230 lists the new functions in table 63, "atoll, strtoll, 
14821strtoull, strtof, and strtold added by TR1". However, strtof is not present 
14822in table 63.
14823</p>
14824
14825
14826<p><b>Proposed resolution:</b></p>
14827<p>
14828</p>
14829
14830
14831<p><b>Rationale:</b></p>
14832<p>
14833Recommend NAD, editorial.  Send to Pete.
14834</p>
14835
14836
14837
14838
14839
14840<hr>
14841<h3><a name="617"></a>617. std::array is a sequence that doesn't satisfy the sequence requirements?</h3>
14842<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">NAD</a>
14843 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2006-12-30  <b>Last modified:</b> 2009-10-20</p>
14844<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>
14845<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
14846<p><b>Discussion:</b></p>
14847<p>
14848The <tt>&lt;array&gt;</tt> header is given under 23.3 [sequences].
1484923.3.1 [array]/paragraph 3 says:
14850</p>
14851<blockquote><p>
14852"Unless otherwise specified, all array operations are as described in
1485323.2 [container.requirements]".
14854</p></blockquote>
14855<p>
14856However, array isn't mentioned at all in section 23.2 [container.requirements].
14857In particular, Table 82 "Sequence requirements" lists several operations (insert, erase, clear) 
14858that std::array does not have in 23.3.1 [array].
14859</p>
14860<p>
14861Also, Table 83 "Optional sequence operations" lists several operations that 
14862std::array does have, but array isn't mentioned.
14863</p>
14864
14865<p><i>[
148662009-07 Frankfurt
14867]</i></p>
14868
14869
14870<blockquote>
14871<p>
14872The real issue seems to be different than what is described here.
14873Non-normative text says that std::array is a sequence container, but
14874there is disagreement about what that really means. There are two
14875possible interpretations:
14876</p>
14877<ol>
14878<li>
14879a sequence container is one that satisfies all sequence container requirements
14880</li>
14881<li>
14882a sequence container is one that satisfies some of the sequence
14883container requirements. Any operation that the container supports is
14884specified by one or more sequence container requirements, unless that
14885operation is specifically singled out and defined alongside the
14886description of the container itself.
14887</li>
14888</ol>
14889<p>
14890Move to Tentatively NAD.
14891</p>
14892</blockquote>
14893
14894<p><i>[
148952009-07-15 Lo�c Joly adds:
14896]</i></p>
14897
14898
14899<blockquote>
14900<p>
14901The section 23.2.3 [sequence.reqmts]/1 states that array is a sequence. 23.2.3 [sequence.reqmts]/3
14902introduces table 83, named Sequence container requirements. This seems
14903to me to be defining the requirements for all sequences. However, array
14904does not follow all of this requirements (this can be read in the array
14905specific section, for the standard is currently inconsistent).
14906</p>
14907
14908<p>
14909Proposed resolution 1 (minimal change): 
14910</p>
14911<blockquote>
14912<p>
14913Say that array is a container, that in addition follows only some of the
14914sequence requirements, as described in the array section:
14915</p>
14916
14917<blockquote>
14918The library provides <del>five</del> <ins>three</ins> basic kinds of sequence containers: <del><tt>array</tt></del>,
14919<tt>vector</tt>, 
14920<del><tt>forward_list</tt></del>, <tt>list</tt>, and <tt>deque</tt>. <ins>In addition, <tt>array</tt>
14921and <tt>forward_list</tt> follows some of the requirements 
14922of sequences, as described in their respective sections.</ins>
14923</blockquote>
14924
14925</blockquote>
14926
14927<p>
14928Proposed resolution 2 (most descriptive description, no full wording provided): 
14929</p>
14930<blockquote>
14931Introduce the notion of a Fixed Size Sequence, with it requirement table
14932that would be a subset of the current Sequence container. array would be
14933the only Fixed Size Sequence (but dynarray is in the queue for TR2).
14934Sequence requirements would now be requirements in addition to Fixed
14935Size Sequence requirements (it is currently in addition to container).
14936</blockquote>
14937</blockquote>
14938
14939<p><i>[
149402009-07 Frankfurt:
14941]</i></p>
14942
14943
14944<blockquote>
14945Move to NAD Editorial
14946</blockquote>
14947
14948<p><i>[
149492009 Santa Cruz:
14950]</i></p>
14951
14952
14953<blockquote>
14954This will require a lot of reorganization. Editor doesn't think this is really
14955an issue, since the description of array can be considered as overriding
14956what's specified about sequences. Move to NAD.
14957</blockquote>
14958
14959
14960
14961<p><b>Proposed resolution:</b></p>
14962<p>
14963</p>
14964
14965
14966
14967
14968
14969<hr>
14970<h3><a name="626"></a>626. new <i>Remark</i> clauses not documented</h3>
14971<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#NAD%20Editorial">NAD Editorial</a>
14972 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2007-01-20  <b>Last modified:</b> 2008-02-25</p>
14973<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>
14974<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
14975<p><b>Discussion:</b></p>
14976        <p>
14977
14978The <i>Remark</i> clauses newly  introduced into the Working Paper 
14979(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>)
14980are  not mentioned  in  17.5.1.4 [structure.specifications] where  we list  the
14981meaning  of <i>Effects</i>, <i>Requires</i>,  and other  clauses (with
14982the exception  of <i>Notes</i> which are documented  as informative in
1498317.5.1.2 [structure.summary], p2, and which they replace in many cases).
14984
14985        </p>
14986        <p>
14987
14988Propose add a bullet for <i>Remarks</i> along with a brief description.
14989
14990        </p>
14991<p><i>[
14992Batavia:  Alan and Pete to work.
14993]</i></p>
14994
14995
14996<p><i>[
14997Bellevue: Already resolved in current working paper.
14998]</i></p>
14999
15000
15001
15002<p><b>Proposed resolution:</b></p>
15003<p>
15004</p>
15005
15006
15007
15008
15009
15010<hr>
15011<h3><a name="627"></a>627. Low memory and exceptions</h3>
15012<p><b>Section:</b> 18.6.1.1 [new.delete.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
15013 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2007-01-23  <b>Last modified:</b> 2008-02-25</p>
15014<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete.single">issues</a> in [new.delete.single].</p>
15015<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
15016<p><b>Discussion:</b></p>
15017<p>
15018I recognize the need for nothrow guarantees in the exception reporting
15019mechanism, but I strongly believe that implementors also need an escape hatch
15020when memory gets really low. (Like, there's not enough heap to construct and
15021copy exception objects, or not enough stack to process the throw.) I'd like to
15022think we can put this escape hatch in 18.6.1.1 [new.delete.single],
15023<tt>operator new</tt>, but I'm not sure how to do it. We need more than a
15024footnote, but the wording has to be a bit vague. The idea is that if
15025<tt>new</tt> can't allocate something sufficiently small, it has the right to
15026<tt>abort</tt>/call <tt>terminate</tt>/call <tt>unexpected</tt>.
15027</p>
15028
15029<p><i>[
15030Bellevue: NAD.  1.4p2 specifies a program must behave correctly "within
15031its resource limits", so no further escape hatch is necessary.
15032]</i></p>
15033
15034
15035
15036<p><b>Proposed resolution:</b></p>
15037<p>
15038</p>
15039
15040
15041
15042
15043
15044<hr>
15045<h3><a name="632"></a>632. Time complexity of size() for std::set</h3>
15046<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#NAD">NAD</a>
15047 <b>Submitter:</b> Lionel B <b>Opened:</b> 2007-02-01  <b>Last modified:</b> 2009-07-15</p>
15048<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>
15049<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>
15050<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
15051<p><b>Discussion:</b></p>
15052<p>
15053A recent news group discussion:
15054</p>
15055<blockquote>
15056<p>
15057Anyone know if the Standard has anything to say about the time complexity
15058of size() for std::set?   I need to access a set's size (/not/ to know if it is empty!) heavily
15059during an algorithm and was thus wondering whether I'd be better off
15060tracking the size "manually" or whether that'd be pointless.
15061</p>
15062<p>
15063That would be pointless. size() is O(1).
15064</p>
15065<p>
15066Nit: the standard says "should" have constant time. Implementations may take
15067license to do worse. I know that some do this for <tt>std::list&lt;&gt;</tt> as a part of
15068some trade-off with other operation.
15069</p>
15070
15071<p>
15072I was aware of that, hence my reluctance to use size() for std::set.
15073</p>
15074<p>
15075However, this reason would not apply to <tt>std::set&lt;&gt;</tt> as far as I can see.
15076</p>
15077<p>
15078Ok, I guess the only option is to try it and see...
15079</p>
15080</blockquote>
15081
15082<p>
15083If I have any recommendation to the C++ Standards Committee it is that
15084implementations must (not "should"!) document clearly[1], where known, the
15085time complexity of *all* container access operations.
15086</p>
15087<p>
15088[1] In my case (gcc 4.1.1) I can't swear that the time complexity of size()
15089for std::set is not documented... but if it is it's certainly well hidden
15090away.
15091</p>
15092
15093<p><i>[
15094Kona (2007): This issue affects all the containers. We'd love to see a
15095paper dealing with the broad issue. We think that the complexity of the
15096<tt>size()</tt> member of every container -- except possibly <tt>list</tt> -- should be
15097O(1). Alan has volunteered to provide wording.
15098]</i></p>
15099
15100
15101<p><i>[
15102Bellevue:
15103]</i></p>
15104
15105
15106<blockquote>
15107Mandating O(1) size will not fly, too many implementations would be
15108invalidated. Alan to provide wording that toughens wording, but that
15109does not absolutely mandate O(1).
15110</blockquote>
15111
15112<p><i>[
15113Batavia (2009-05):
15114]</i></p>
15115
15116<blockquote>
15117We observed that the wording "should" (in note a) has no effect.
15118Howard prefers that O(1) size be mandated.
15119It is not clear that this issue can be resolved to everyone's satisfaction,
15120but Alan will provide wording nonetheless.
15121</blockquote>
15122
15123<p><i>[
151242009-07 Frankfurt
15125]</i></p>
15126
15127
15128<blockquote>
15129Fixed by paper N2923.
15130</blockquote>
15131
15132
15133
15134<p><b>Proposed resolution:</b></p>
15135<p>
15136</p>
15137
15138
15139
15140
15141
15142<hr>
15143<h3><a name="633"></a>633. Return clause mentions undefined "type()"</h3>
15144<p><b>Section:</b> 20.7.15.2.5 [func.wrap.func.targ] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
15145 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-02-03  <b>Last modified:</b> 2007-07-02</p>
15146<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
15147<p><b>Discussion:</b></p>
15148<p>
1514920.7.15.2.5 [func.wrap.func.targ], p4 says:
15150</p>
15151<blockquote><p>
15152<i>Returns:</i> If <tt>type() == typeid(T)</tt>, a pointer to the stored
15153function target; otherwise a null pointer.
15154</p></blockquote>
15155
15156<ol>
15157<li>
15158There exists neither a type, a typedef <tt>type</tt>, nor member
15159function <tt>type()</tt> in class template function nor in the global or
15160<tt>std</tt> namespace.
15161</li>
15162<li>
15163Assuming that <tt>type</tt> should have been <tt>target_type()</tt>,
15164this description would lead to false results, if <tt>T = <i>cv</i>
15165void</tt> due to returns clause 20.7.15.2.5 [func.wrap.func.targ], p1.
15166</li>
15167</ol>
15168
15169
15170
15171<p><b>Proposed resolution:</b></p>
15172<p>
15173Change 20.7.15.2.5 [func.wrap.func.targ], p4:
15174</p>
15175
15176<blockquote><p>
15177<i>Returns:</i> If <tt><del>type()</del> <ins>target_type()</ins> == typeid(T) <ins>&amp;&amp; typeid(T) !=
15178typeid(void)</ins></tt>, a pointer to the stored function target;
15179otherwise a null pointer.
15180</p></blockquote>
15181
15182<p><i>[
15183Pete: Agreed. It's editorial, so I'll fix it.
15184]</i></p>
15185
15186
15187
15188
15189
15190
15191
15192<hr>
15193<h3><a name="635"></a>635. domain of <tt>allocator::address</tt></h3>
15194<p><b>Section:</b> 20.2.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
15195 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2007-02-08  <b>Last modified:</b> 2009-10-26</p>
15196<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>
15197<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
15198<p><b>Discussion:</b></p>
15199<p>
15200The table of allocator requirements in 20.2.2 [allocator.requirements] describes
15201<tt>allocator::address</tt> as:
15202</p>
15203<blockquote><pre>a.address(r)
15204a.address(s)
15205</pre></blockquote>
15206<p>
15207where <tt>r</tt> and <tt>s</tt> are described as:
15208</p>
15209<blockquote><p>
15210a value of type <tt>X::reference</tt> obtained by the expression <tt>*p</tt>. 
15211</p></blockquote>
15212
15213<p>
15214and <tt>p</tt> is 
15215</p>
15216
15217<blockquote><p>
15218a value of type <tt>X::pointer</tt>, obtained by calling <tt>a1.allocate</tt>, 
15219where <tt>a1 == a</tt>
15220</p></blockquote>
15221
15222<p>
15223This all implies that to get the address of some value of type <tt>T</tt> that
15224value must have been allocated by this allocator or a copy of it.
15225</p>
15226
15227<p>
15228However sometimes container code needs to compare the address of an external value of
15229type <tt>T</tt> with an internal value.  For example <tt>list::remove(const T&amp; t)</tt>
15230may want to compare the address of the external value <tt>t</tt> with that of a value
15231stored within the list.  Similarly <tt>vector</tt> or <tt>deque insert</tt> may
15232want to make similar comparisons (to check for self-referencing calls).
15233</p>
15234
15235<p>
15236Mandating that <tt>allocator::address</tt> can only be called for values which the
15237allocator allocated seems overly restrictive.
15238</p>
15239
15240<p><i>[
15241post San Francisco:
15242]</i></p>
15243
15244
15245<blockquote>
15246Pablo recommends NAD Editorial, solved by
15247<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2768.pdf">N2768</a>.
15248</blockquote>
15249
15250<p><i>[
152512009-04-28 Pablo adds:
15252]</i></p>
15253
15254
15255<blockquote>
15256Tentatively-ready NAD Editorial as fixed by
15257<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2768.pdf">N2768</a>.
15258</blockquote>
15259
15260<p><i>[
152612009-07 Frankfurt
15262]</i></p>
15263
15264
15265<blockquote>
15266Fixed by N2768.
15267</blockquote>
15268
15269<p><i>[
152702009-07-28 Reopened by Alisdair.  No longer solved by concepts.
15271]</i></p>
15272
15273
15274<p><i>[
152752009-10 Santa Cruz:
15276]</i></p>
15277
15278
15279<blockquote>
15280NAD Editorial.  Addressed by
15281<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>.
15282</blockquote>
15283
15284
15285
15286<p><b>Proposed resolution:</b></p>
15287<p>
15288Change 20.2.2 [allocator.requirements]:
15289</p>
15290
15291<blockquote>
15292<p>
15293<tt>r</tt> : a value of type <tt>X::reference</tt> <del>obtained by the expression *p</del>.
15294</p>
15295<p>
15296<tt>s</tt> : a value of type <tt>X::const_reference</tt> <del>obtained by the 
15297expression <tt>*q</tt> or by conversion from a value <tt>r</tt></del>.
15298</p>
15299</blockquote>
15300
15301<p><i>[
15302post Oxford:  This would be rendered NAD Editorial by acceptance of
15303<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
15304]</i></p>
15305
15306
15307<p><i>[
15308Kona (2007):  This issue is section 8 of N2387.  There was some discussion of it but
15309no resolution to this issue was recorded.  Moved to Open.
15310]</i></p>
15311
15312
15313
15314
15315
15316
15317
15318<hr>
15319<h3><a name="636"></a>636. 26.5.2.3 valarray::operator[]</h3>
15320<p><b>Section:</b> 26.6.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
15321 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-02-11  <b>Last modified:</b> 2007-07-02</p>
15322<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.access">issues</a> in [valarray.access].</p>
15323<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
15324<p><b>Discussion:</b></p>
15325<p>
15326The signature of the const operator[] has been changed to return a const 
15327reference.
15328</p>
15329<p>
15330The description in paragraph 1 still says that the operator returns by 
15331value.
15332</p>
15333<p><i>[
15334Pete recommends editorial fix.
15335]</i></p>
15336
15337
15338
15339<p><b>Proposed resolution:</b></p>
15340<p>
15341</p>
15342
15343
15344
15345
15346
15347<hr>
15348<h3><a name="637"></a>637. [c.math]/10 inconsistent return values</h3>
15349<p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
15350 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-02-13  <b>Last modified:</b> 2007-07-26</p>
15351<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
15352<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
15353<p><b>Discussion:</b></p>
15354<p>
1535526.8 [c.math], paragraph 10 has long lists of added signatures for float and long double 
15356functions. All the signatures have float/long double return values, which is 
15357inconsistent with some of the double functions they are supposed to 
15358overload.
15359</p>
15360
15361
15362<p><b>Proposed resolution:</b></p>
15363<p>
15364Change 26.8 [c.math], paragraph 10,
15365</p>
15366
15367<blockquote><pre><del>float</del> <ins>int</ins> ilogb(float);
15368<del>float</del> <ins>long</ins> lrint(float);
15369<del>float</del> <ins>long</ins> lround(float);
15370<del>float</del> <ins>long long</ins> llrint(float);
15371<del>float</del> <ins>long long</ins> llround(float);
15372
15373<del>long double</del> <ins>int</ins> ilogb(long double);
15374<del>long double</del> <ins>long</ins> lrint(long double);
15375<del>long double</del> <ins>long</ins> lround(long double);
15376<del>long double</del> <ins>long long</ins> llrint(long double);
15377<del>long double</del> <ins>long long</ins> llround(long double);
15378</pre></blockquote>
15379
15380
15381
15382
15383
15384<hr>
15385<h3><a name="639"></a>639. Still problems with exceptions during streambuf IO</h3>
15386<p><b>Section:</b> 27.7.1.2.3 [istream::extractors], 27.7.2.6.3 [ostream.inserters] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
15387 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-02-17  <b>Last modified:</b> 2007-10-10</p>
15388<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p>
15389<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
15390<p><b>Discussion:</b></p>
15391<p>
15392There already exist two active DR's for the wording of 27.7.1.2.3 [istream::extractors]/13
15393from 14882:2003(E), namely <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#413">413</a>.
15394</p>
15395
15396<p>
15397Even with these proposed corrections, already maintained in N2134,
15398I have the feeling, that the current wording does still not properly
15399handle the "exceptional" situation. The combination of para 14
15400</p>
15401
15402<blockquote><p>
15403"[..] Characters are extracted and inserted until
15404any of the following occurs:
15405</p>
15406<p>
15407[..]
15408</p>
15409<p>
15410- an exception occurs (in which case the exception is caught)."
15411</p></blockquote>
15412
15413<p>
15414and 15
15415</p>
15416
15417<blockquote><p>
15418"If the function inserts no characters, it calls setstate(failbit),
15419which
15420may throw ios_base::failure (27.4.4.3). If it inserted no characters
15421because it caught an exception thrown while extracting characters
15422from *this and failbit is on in exceptions() (27.4.4.3), then the
15423caught
15424exception is rethrown."
15425</p></blockquote>
15426
15427<p>
15428both in N2134 seems to imply that any exception, which occurs
15429*after* at least one character has been inserted is caught and lost
15430for
15431ever. It seems that even if failbit is on in exceptions() rethrow is
15432not
15433allowed due to the wording "If it inserted no characters because it
15434caught an exception thrown while extracting".
15435</p>
15436
15437<p>
15438Is this behaviour by design?
15439</p>
15440
15441<p>
15442I would like to add that its output counterpart in 27.7.2.6.3 [ostream.inserters]/7-9
15443(also
15444N2134) does not demonstrate such an exception-loss-behaviour.
15445On the other side, I wonder concerning several subtle differences
15446compared to input::
15447</p>
15448<p>
154491) Paragraph 8 says at its end:
15450</p>
15451
15452<blockquote><p>
15453"- an exception occurs while getting a character from sb."
15454</p></blockquote>
15455
15456<p>
15457Note that there is nothing mentioned which would imply that such
15458an exception will be caught compared to 27.7.1.2.3 [istream::extractors]/14.
15459</p>
15460
15461<p>
154622) Paragraph 9 says:
15463</p>
15464
15465<blockquote><p>
15466"If the function inserts no characters, it calls setstate(failbit)
15467(which
15468may throw ios_base::failure (27.4.4.3)). If an exception was thrown
15469while extracting a character, the function sets failbit in error
15470state,
15471and if failbit is on in exceptions() the caught exception is
15472rethrown."
15473</p></blockquote>
15474
15475<p>
15476The sentence starting with "If an exception was thrown" seems to
15477imply that such an exception *should* be caught before.
15478</p>
15479
15480
15481<p><b>Proposed resolution:</b></p>
15482<p>
15483(a) In 27.7.1.2.3 [istream::extractors]/15 (N2134) change the sentence
15484</p>
15485
15486<blockquote><p>
15487If the function inserts no characters, it calls
15488<tt>setstate(failbit)</tt>, which may throw <tt>ios_base::failure</tt>
15489(27.4.4.3). If <del>it inserted no characters because it caught an
15490exception thrown while extracting characters from <tt>*this</tt></del>
15491<ins>an exception was thrown while extracting a character from
15492<tt>*this</tt>, the function sets <tt>failbit</tt> in error state,</ins>
15493and <tt>failbit</tt> is on in <tt>exceptions()</tt> (27.4.4.3), then the
15494caught exception is rethrown.
15495</p></blockquote>
15496
15497<p>
15498(b) In 27.7.2.6.3 [ostream.inserters]/8 (N2134) change the sentence:
15499</p>
15500
15501<blockquote>
15502<p>
15503Gets characters from <tt>sb</tt> and inserts them in <tt>*this</tt>.
15504Characters are read from <tt>sb</tt> and inserted until any of the
15505following occurs:
15506</p>
15507<ul>
15508<li>end-of-file occurs on the input sequence;</li>
15509<li>inserting in the output sequence fails (in which case the character to be inserted is not extracted);</li>
15510<li>an exception occurs while getting a character from <tt>sb</tt> <ins>(in which
15511case the exception is caught)</ins>.</li>
15512</ul>
15513</blockquote>
15514
15515
15516
15517<p><b>Rationale:</b></p>
15518This extractor is described as a formatted input function so the
15519exception behavior is already specified. There is additional behavior
15520described in this section that applies to the case in which failbit is
15521set. This doesn't contradict the usual exception behavior for formatted
15522input functions because that applies to the case in which badbit is set.
15523
15524
15525
15526
15527
15528<hr>
15529<h3><a name="641"></a>641. Editorial fix for 27.6.4 (N2134)</h3>
15530<p><b>Section:</b> 27.7.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
15531 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-02-18  <b>Last modified:</b> 2007-07-02</p>
15532<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ext.manip">issues</a> in [ext.manip].</p>
15533<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
15534<p><b>Discussion:</b></p>
15535<p>
15536The function <tt>f</tt> in para 4 (27.7.4 [ext.manip]) references an unknown <tt>strm</tt>
15537in the following line:
15538</p>
15539
15540<blockquote><pre>mg.get(Iter(str.rdbuf()), Iter(), intl, strm, err, mon);
15541</pre></blockquote>
15542
15543
15544<p><b>Proposed resolution:</b></p>
15545<p>
15546Change 27.7.4 [ext.manip], p4:
15547</p>
15548
15549<blockquote><pre>mg.get(Iter(str.rdbuf()), Iter(), intl, str<del>m</del>, err, mon);
15550</pre></blockquote>
15551
15552<p><i>[
15553Oxford:  Editorial.
15554]</i></p>
15555
15556
15557
15558
15559
15560
15561
15562<hr>
15563<h3><a name="642"></a>642. Invalidated fstream footnotes in N2134</h3>
15564<p><b>Section:</b> 27.9.1.9 [ifstream.members], 27.9.1.13 [ofstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
15565 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-02-20  <b>Last modified:</b> 2007-07-02</p>
15566<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ifstream.members">issues</a> in [ifstream.members].</p>
15567<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
15568<p><b>Discussion:</b></p>
15569<p>
15570The standard wording of N2134 has extended the 14882:2003(E)
15571wording for the ifstream/ofstream/fstream open function to fix
15572a long standing problem, see <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#409">409</a>.
15573</p>
15574
15575<p>
15576Now it's properly written as
15577</p>
15578
15579<blockquote><p>
15580"If that function does not return a null pointer calls clear(),
15581otherwise
15582calls setstate(failbit)[..]"
15583</p></blockquote>
15584
15585<p>
15586instead of the previous
15587</p>
15588
15589<blockquote><p>
15590"If that function returns a null pointer, calls setstate(failbit)[..]
15591</p></blockquote>
15592
15593<p>
15594While the old footnotes saying
15595</p>
15596
15597<blockquote><p>
15598"A successful open does not change the error state."
15599</p></blockquote>
15600
15601<p>
15602where correct and important, they are invalid now for ifstream and
15603ofstream (because clear *does* indeed modify the error state) and
15604should be removed (Interestingly fstream itself never had these,
15605although
15606they where needed for that time).
15607</p>
15608
15609
15610<p><b>Proposed resolution:</b></p>
15611<p>
15612In 27.9.1.9 [ifstream.members], remove footnote:
15613</p>
15614
15615<blockquote><p>
15616<del><sup>334)</sup> A successful open does not change the error state.</del>
15617</p></blockquote>
15618
15619<p>
15620In 27.9.1.13 [ofstream.members], remove footnote:
15621</p>
15622
15623<blockquote><p>
15624<del><sup>335)</sup> A successful open does not change the error state.</del>
15625</p></blockquote>
15626
15627
15628
15629
15630
15631
15632<hr>
15633<h3><a name="644"></a>644. Possible typos in 'function' description</h3>
15634<p><b>Section:</b> 20.7.15.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
15635 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-02-25  <b>Last modified:</b> 2009-07-13</p>
15636<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
15637<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
15638<p><b>Discussion:</b></p>
15639<p>
1564020.7.15.2 [func.wrap.func]
15641</p>
15642<p>
15643The note in paragraph 2 refers to 'undefined void operators', while the
15644section declares a pair of operators returning bool.
15645</p>
15646
15647<p><i>[
15648Post-Sophia Antipolis:
15649]</i></p>
15650
15651
15652<blockquote>
15653Changed from Pending WP to Open.  This issue was voted to WP at the same time the operators were
15654changed from private to deleted.  The two issues stepped on each other.  What do we want the return
15655type of these deleted functions to be?
15656</blockquote>
15657
15658<p><i>[
156592009-05-02 Daniel adds:
15660]</i></p>
15661
15662
15663<blockquote>
15664<p>
15665I suggest harmonizing this issue with similar classes. E.g. in
1566620.8.15.3 [util.smartptr.weak] <tt>bool</tt> return values for
15667</p>
15668<blockquote><pre>template &lt;class Y&gt; bool operator&lt;(weak_ptr&lt;Y&gt; const&amp;) const = delete;
15669template &lt;class Y&gt; bool operator&lt;=(weak_ptr&lt;Y&gt; const&amp;) const = delete;
15670template &lt;class Y&gt; bool operator&gt;(weak_ptr&lt;Y&gt; const&amp;) const = delete;
15671template &lt;class Y&gt; bool operator&gt;=(weak_ptr&lt;Y&gt; const&amp;) const = delete;
15672</pre></blockquote>
15673
15674<p>
15675are used and basically all <em>newer</em> provided deleted copy assignment operators
15676of type <tt>X</tt> use the canonical return type <tt>X&amp;</tt> instead of <tt>void</tt>. Since the note
15677mentioned in the issue description has now already been changed to
15678</p>
15679<blockquote>
15680deleted overloads close possible hole in the type system
15681</blockquote>
15682<p>
15683it seems to be of even lesser need to perform the change. Therefore
15684I recommend declaring the issue as NAD.
15685</p>
15686</blockquote>
15687
15688<p><i>[
15689Batavia (2009-05):
15690]</i></p>
15691
15692<blockquote>
15693<p>
15694We agree with Daniel's recommendation.
15695</p>
15696<p>
15697Move to NAD.
15698</p>
15699</blockquote>
15700
15701
15702<p><b>Proposed resolution:</b></p>
15703<p>
15704Change 20.7.15.2 [func.wrap.func]
15705</p>
15706
15707<blockquote><pre>...
15708private:
15709   // 20.7.15.2 [func.wrap.func], undefined operators:
15710   template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator==(const function&lt;Function2&gt;&amp;);
15711   template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator!=(const function&lt;Function2&gt;&amp;);
15712};
15713</pre></blockquote>
15714
15715<p>
15716Change 20.7.15.2 [func.wrap.func]
15717</p>
15718
15719<blockquote><pre>template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator==(const function&lt;Function2&gt;&amp;);
15720template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator!=(const function&lt;Function2&gt;&amp;);
15721</pre></blockquote>
15722
15723
15724
15725
15726
15727<hr>
15728<h3><a name="645"></a>645. Missing members in match_results</h3>
15729<p><b>Section:</b> 28.10 [re.results] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
15730 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-02-26  <b>Last modified:</b> 2008-03-12</p>
15731<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.results">issues</a> in [re.results].</p>
15732<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
15733<p><b>Discussion:</b></p>
15734<p>
15735According to the description given in 28.10 [re.results]/2 the class template
15736match_results "shall satisfy the requirements of a Sequence, [..],
15737except that only operations defined for const-qualified Sequences
15738are supported".
15739Comparing the provided operations from 28.10 [re.results]/3 with the
15740sequence/container tables 80 and 81 one recognizes the following
15741missing operations:
15742</p>
15743
15744<p>
157451) The members
15746</p>
15747
15748<blockquote><pre>const_iterator rbegin() const;
15749const_iterator rend() const;
15750</pre></blockquote>
15751
15752<p>
15753should exists because 23.1/10 demands these for containers
15754(all sequences are containers) which support bidirectional
15755iterators. Aren't these supported by match_result? This is not
15756explicitely expressed, but it's somewhat implied by two arguments:
15757</p>
15758<p>
15759(a) Several typedefs delegate to
15760<tt>iterator_traits&lt;BidirectionalIterator&gt;</tt>.
15761</p>
15762<p>
15763(b) The existence of <tt>const_reference operator[](size_type n) const</tt>
15764implies even random-access iteration.
15765I also suggest, that <tt>match_result</tt> should explicitly mention,
15766which minimum iterator category is supported and if this does
15767not include random-access the existence of <tt>operator[]</tt> is
15768somewhat questionable.
15769</p>
15770<p>
157712) The new "convenience" members
15772</p>
15773<blockquote><pre>const_iterator cbegin() const;
15774const_iterator cend() const;
15775const_iterator crbegin() const;
15776const_iterator crend() const;
15777</pre></blockquote>
15778<p>
15779should be added according to tables 80/81.
15780</p>
15781
15782
15783<p><b>Proposed resolution:</b></p>
15784<p>
15785Add the following members to the <tt>match_results</tt> synopsis after <tt>end()</tt> in 28.10 [re.results]
15786para 3:
15787</p>
15788
15789<blockquote><pre>const_iterator cbegin() const; 
15790const_iterator cend() const;
15791</pre></blockquote>
15792
15793<p>
15794In section 28.10.3 [re.results.acc] change:
15795</p>
15796
15797<blockquote>
15798<pre>const_iterator begin() const;
15799<ins>const_iterator cbegin() const;</ins>
15800</pre>
15801<blockquote>
15802<p>
15803-7- <i>Returns:</i> A starting iterator that enumerates over all the sub-expressions stored in <tt>*this</tt>.
15804</p>
15805</blockquote>
15806
15807<pre>const_iterator end() const;
15808<ins>const_iterator cend() const;</ins>
15809</pre>
15810<blockquote>
15811<p>
15812-8- <i>Returns:</i> A terminating iterator that enumerates over all the sub-expressions stored in <tt>*this</tt>.
15813</p>
15814</blockquote>
15815</blockquote>
15816
15817
15818
15819<p><i>[
15820Kona (2007): Voted to adopt proposed wording in
15821<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>
15822except removing the entry in the table container requirements.  Moved to Review.
15823]</i></p>
15824
15825
15826<p><i>[
15827Bellevue:  Proposed wording now in the WP.
15828]</i></p>
15829
15830
15831
15832
15833
15834<hr>
15835<h3><a name="647"></a>647. Inconsistent regex_search params</h3>
15836<p><b>Section:</b> 28.11.3 [re.alg.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
15837 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-02-26  <b>Last modified:</b> 2007-07-26</p>
15838<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
15839<p><b>Discussion:</b></p>
15840<p>
1584128.11.3 [re.alg.search]/5 declares
15842</p>
15843
15844<blockquote><pre>template &lt;class iterator, class charT, class traits&gt;
15845bool regex_search(iterator first, iterator last,
15846                  const basic_regex&lt;charT, traits&gt;&amp; e,
15847                  regex_constants::match_flag_type flags =
15848                      regex_constants::match_default);
15849</pre></blockquote>
15850
15851<p>
15852where it's not explained, which iterator category
15853the parameter iterator belongs to. This is inconsistent
15854to the preceding declaration in the synopsis section
1585528.4 [re.syn], which says:
15856</p>
15857
15858<blockquote><pre>template &lt;class BidirectionalIterator, class charT, class traits&gt;
15859bool regex_search(BidirectionalIterator first, BidirectionalIterator last,
15860                  const basic_regex&lt;charT, traits&gt;&amp; e,
15861                  regex_constants::match_flag_type flags =
15862                      regex_constants::match_default);
15863</pre></blockquote>
15864
15865
15866<p><b>Proposed resolution:</b></p>
15867<p>
15868In 28.11.3 [re.alg.search]/5 replace all three occurences of param "iterator" with
15869"BidirectionalIterator"
15870</p>
15871
15872<blockquote><pre>template &lt;class <del>iterator</del> <ins>BidirectionalIterator</ins>, class charT, class traits&gt;
15873  bool regex_search(<del>iterator</del> <ins>BidirectionalIterator</ins> first, <del>iterator</del> <ins>BidirectionalIterator</ins> last, 
15874                    const basic_regex&lt;charT, traits&gt;&amp; e, 
15875                    regex_constants::match_flag_type flags = 
15876                      regex_constants::match_default);
15877</pre>
15878<p>
15879-6- <i>Effects:</i> Behaves "as if" by constructing an object what of
15880type <tt>match_results&lt;<del>iterator</del>
15881<ins>BidirectionalIterator</ins>&gt;</tt> and then returning the result
15882of <tt>regex_search(first, last, what, e, flags)</tt>.
15883</p>
15884</blockquote>
15885
15886
15887<p><b>Rationale:</b></p>
15888Applied to working paper while issue was still in New status.
15889
15890
15891
15892
15893
15894<hr>
15895<h3><a name="648"></a>648. regex_iterator c'tor needs clarification/editorial fix</h3>
15896<p><b>Section:</b> 28.12.1.1 [re.regiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
15897 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-03-03  <b>Last modified:</b> 2007-07-02</p>
15898<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
15899<p><b>Discussion:</b></p>
15900<p>
15901In 28.12.1.1 [re.regiter.cnstr]/2 the effects paragraph starts with:
15902</p>
15903
15904<blockquote>
15905<p>
15906<i>Effects:</i> Initializes begin and end to point to the beginning and the
15907end of the target sequence, sets pregex to &amp;re, sets flags to f,[..]
15908</p></blockquote>
15909
15910<p>
15911There are two issues with this description:
15912</p>
15913
15914<ol>
15915<li>
15916The meaning of very first part of this quote is unclear, because
15917there is no target sequence provided, instead there are given two
15918parameters a and b, both of type BidirectionalIterator. The mentioned
15919part does not explain what a and b represent.
15920</li>
15921<li>
15922There does not exist any parameter f, but instead a parameter
15923m in the constructor declaration, so this is actually an editorial
15924fix.
15925</li>
15926</ol>
15927
15928
15929<p><b>Proposed resolution:</b></p>
15930<p>
15931In 28.12.1.1 [re.regiter.cnstr]/2 change the above quoted part by
15932</p>
15933
15934<blockquote><p>
15935<i>Effects:</i> Initializes <tt>begin</tt> and <tt>end</tt> to point to
15936the beginning and the end of the target sequence <ins>designated by the
15937iterator range <tt>[a, b)</tt></ins>, sets <tt>pregex</tt> to
15938<tt>&amp;re</tt>, sets <tt>flags</tt> to <tt><del>f</del>
15939<ins>m</ins></tt>, then calls <tt>regex_search(begin, end, match,
15940*pregex, flags)</tt>. If this call returns <tt>false</tt> the
15941constructor sets <tt>*this</tt> to the end-of-sequence iterator.
15942</p></blockquote>
15943
15944
15945
15946
15947
15948<hr>
15949<h3><a name="649"></a>649. Several typos in regex_token_iterator constructors</h3>
15950<p><b>Section:</b> 28.12.2.1 [re.tokiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
15951 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-03-03  <b>Last modified:</b> 2007-07-02</p>
15952<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.tokiter.cnstr">issues</a> in [re.tokiter.cnstr].</p>
15953<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
15954<p><b>Discussion:</b></p>
15955<p>
15956In 28.12.2.1 [re.tokiter.cnstr]/1+2 both the constructor declaration
15957and the following text shows some obvious typos:
15958</p>
15959<p>
159601) The third constructor form is written as
15961</p>
15962<blockquote><pre>template &lt;std::size_t N&gt;
15963  regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b, 
15964                       const regex_type&amp; re, 
15965                       const int (&amp;submatches)[R], 
15966                       regex_constants::match_flag_type m = 
15967                         regex_constants::match_default);
15968</pre></blockquote>
15969
15970<p>
15971where the dimensions of submatches are specified by an
15972unknown value R, which should be N.
15973</p>
15974<p>
159752) Paragraph 2 of the same section says in its last sentence:
15976</p>
15977
15978<blockquote><p>
15979The third constructor initializes the member <tt>subs</tt> to hold a
15980copy of the sequence of integer values pointed to by the iterator range
15981<tt>[&amp;submatches, &amp;submatches + R)</tt>.
15982</p></blockquote>
15983
15984<p>
15985where again R must be replaced by N.
15986</p>
15987
15988<p>
159893) Paragraph 3 of the same section says in its first sentence:
15990</p>
15991
15992<blockquote><p>
15993Each constructor then sets <tt>N</tt> to <tt>0</tt>, and
15994<tt>position</tt> to <tt>position_iterator(a, b, re, f)</tt>.
15995</p></blockquote>
15996
15997<p>
15998where a non-existing parameter "f" is mentioned, which must be
15999replaced
16000by the parameter "m".
16001</p>
16002
16003
16004<p><b>Proposed resolution:</b></p>
16005<p>
16006Change 28.12.2.1 [re.tokiter.cnstr]/1:
16007</p>
16008<blockquote><pre>template &lt;std::size_t N&gt;
16009  regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b, 
16010                       const regex_type&amp; re, 
16011                       const int (&amp;submatches)[<del>R</del> <ins>N</ins>], 
16012                       regex_constants::match_flag_type m = 
16013                         regex_constants::match_default);
16014</pre></blockquote>
16015
16016<p>
16017Change 28.12.2.1 [re.tokiter.cnstr]/2:
16018</p>
16019
16020<blockquote><p>
16021<i>Effects:</i> The first constructor initializes the member
16022<tt>subs</tt> to hold the single value <tt>submatch</tt>. The second
16023constructor initializes the member <tt>subs</tt> to hold a copy of the
16024argument <tt>submatches</tt>. The third constructor initializes the
16025member <tt>subs</tt> to hold a copy of the sequence of integer values
16026pointed to by the iterator range <tt>[&amp;submatches, &amp;submatches +
16027<del>R</del> <ins>N</ins>)</tt>.
16028</p></blockquote>
16029
16030<p>
16031Change 28.12.2.1 [re.tokiter.cnstr]/3:
16032</p>
16033
16034<blockquote><p>
16035Each constructor then sets <tt>N</tt> to <tt>0</tt>, and
16036<tt>position</tt> to <tt>position_iterator(a, b, re, <del>f</del>
16037<ins>m</ins>)</tt>. If <tt>position</tt> is not an end-of-sequence
16038iterator the constructor sets <tt>result</tt> to the address of the
16039current match. Otherwise if any of the values stored in <tt>subs</tt> is
16040equal to <tt>-1</tt> the constructor sets <tt>*this</tt> to a suffix
16041iterator that points to the range <tt>[a, b)</tt>, otherwise the
16042constructor sets <tt>*this</tt> to an end-of-sequence iterator.
16043</p></blockquote>
16044
16045
16046
16047
16048
16049
16050<hr>
16051<h3><a name="653"></a>653. Library reserved names</h3>
16052<p><b>Section:</b> 1.2 [intro.refs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
16053 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-03-08  <b>Last modified:</b> 2008-02-25</p>
16054<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#intro.refs">issues</a> in [intro.refs].</p>
16055<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
16056<p><b>Discussion:</b></p>
16057<p>
16058</p>
16059<blockquote>
16060<p>
160611.2 [intro.refs] Normative references
16062</p>
16063
16064<p>
16065The following standards contain provisions which, through reference in
16066this text, constitute provisions of this Interna- tional Standard. At
16067the time of publication, the editions indicated were valid. All
16068standards are subject to revision, and parties to agreements based on
16069this International Standard are encouraged to investigate the
16070possibility of applying the most recent editions of the standards
16071indicated below. Members of IEC and ISO maintain registers of currently
16072valid International Standards.
16073</p>
16074
16075<ul>
16076<li>Ecma International, ECMAScript Language Specification, Standard
16077Ecma-262, third edition, 1999.</li>
16078<li>ISO/IEC 2382 (all parts), Information technology - Vocabulary</li>
16079<li>ISO/IEC 9899:1990, Programming languages - C</li>
16080<li>ISO/IEC 9899/Amd.1:1995, Programming languages - C, AMENDMENT 1: C
16081Integrity</li>
16082<li>ISO/IEC 9899:1999, Programming languages - C</li>
16083<li>ISO/IEC 9899:1999/Cor.1:2001 Programming languages - C</li>
16084<li>ISO/IEC 9899:1999/Cor.2:2004 Programming languages - C</li>
16085<li>ISO/IEC 9945:2003, Information Technology-Portable Operating System
16086Interface (POSIX)</li>
16087<li>ISO/IEC 10646-1:1993 Information technology - Universal Multiple-Octet
16088Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual
16089Plane</li>
16090</ul>
16091</blockquote>
16092
16093<p>
16094I'm not sure how many of those reserve naming patterns that might affect
16095us, but I am equally sure I don't own a copy of any of these to check!
16096</p>
16097<p>
16098The point is to list the reserved naming patterns, rather than the
16099individual names themselves - although we may want to list C keywords
16100that are valid identifiers in C++ but likely to cause trouble in shared
16101headers (e.g. restrict)
16102</p>
16103
16104<p><i>[
16105Kona (2007): Recommend NAD.  No one has identified a specific defect, just the possibility of one.
16106]</i></p>
16107
16108
16109<p><i>[
16110Post-Kona: Alisdair request Open. A good example of the problem was a
16111discussion of the system error proposal, where it was pointed out an all-caps
16112identifier starting with a capital E conflicted with reserved macro names for
16113both Posix and C.  I had absolutely no idea of this rule, and suspect I was
16114not the only one in the room.<br>
16115<br>
16116Resolution will require someone with access to all the listed documents to
16117research their respective name reservation rules, or people with access to
16118specific documents add their rules to this issue until the list is complete.
16119]</i></p>
16120
16121
16122<p><i>[
16123Bellevue: Wording is aleady present in various standards, and no-one has come forward with wording.
16124Suggest a formal paper rather than a defect report is the correct way to proceed.
16125]</i></p>
16126
16127
16128
16129
16130<p><b>Proposed resolution:</b></p>
16131
16132
16133
16134
16135
16136<hr>
16137<h3><a name="656"></a>656. Typo in subtract_with_carry_engine declaration</h3>
16138<p><b>Section:</b> 26.5.1 [rand.synopsis] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
16139 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-03-08  <b>Last modified:</b> 2007-07-02</p>
16140<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.synopsis">issues</a> in [rand.synopsis].</p>
16141<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
16142<p><b>Discussion:</b></p>
16143<p>
1614426.5.1 [rand.synopsis] the header <tt>&lt;random&gt;</tt> synopsis
16145contains an unreasonable closing curly brace inside the
16146<tt>subtract_with_carry_engine</tt> declaration.
16147</p>
16148
16149
16150<p><b>Proposed resolution:</b></p>
16151<p>
16152Change the current declaration in 26.5.1 [rand.synopsis]
16153</p>
16154
16155<blockquote><pre>template &lt;class UIntType, size_t w<del>}</del>, size_t s, size_t r&gt;
16156class subtract_with_carry_engine;
16157</pre></blockquote>
16158
16159
16160<p><i>[
16161Pete: Recommends editorial.
16162]</i></p>
16163
16164
16165
16166
16167
16168<hr>
16169<h3><a name="657"></a>657. unclear requirement about header inclusion</h3>
16170<p><b>Section:</b> 17.6.2.2 [using.headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
16171 <b>Submitter:</b> Gennaro Prota <b>Opened:</b> 2007-03-14  <b>Last modified:</b> 2007-10-10</p>
16172<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
16173<p><b>Discussion:</b></p>
16174<p>
1617517.6.2.2 [using.headers] states:
16176</p>
16177
16178<blockquote><p>
16179A translation unit shall include a header only outside of any
16180external declaration or definition, [...]
16181</p></blockquote>
16182
16183<p>
16184I see three problems with this requirement:
16185</p>
16186
16187<ol type="a">
16188<li><p>The C++ standard doesn't define what an "external declaration" or
16189an "external definition" are (incidentally the C99 standard does, and
16190has a sentence very similar to the above regarding header inclusion).
16191</p><p>
16192I think the intent is that the #include directive shall lexically
16193appear outside *any* declaration; instead, when the issue was pointed
16194out on comp.std.c++ at least one poster interpreted "external
16195declaration" as "declaration of an identifier with external linkage".
16196If this were the correct interpretation, then the two inclusions below
16197would be legal:
16198</p>
16199<blockquote><pre>  // at global scope
16200  static void f()
16201  {
16202# include &lt;cstddef&gt;
16203  }
16204
16205  static void g()
16206  {
16207# include &lt;stddef.h&gt;
16208  }
16209</pre></blockquote>
16210<p>
16211(note that while the first example is unlikely to compile correctly,
16212the second one may well do)
16213</p></li>
16214
16215<li><p>as the sentence stands, violations will require a diagnostic; is
16216this the intent? It was pointed out on comp.std.c++ (by several
16217posters) that at least one way to ensure a diagnostic exists:
16218</p>
16219<blockquote><p>
16220   [If there is an actual file for each header,] one simple way
16221   to implement this would be to insert a reserved identifier
16222   such as __begin_header  at the start of each standard header.
16223   This reserved identifier would be ignored for all other
16224   purposes, except that, at the appropriate point in phase 7, if
16225   it is found inside an external definition, a diagnostic is
16226   generated. There's many other similar ways to achieve the same
16227   effect.
16228   </p>
16229<p>                                 --James Kuyper, on comp.std.c++
16230</p></blockquote></li>
16231
16232<li><p>is the term "header" meant to be limited to standard headers?
16233Clause 17 is all about the library, but still the general question is
16234interesting and affects one of the points in the explicit namespaces
16235proposal (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1691.html">n1691</a>):
16236</p>
16237<blockquote><p>
16238    Those seeking to conveniently enable argument-dependent
16239    lookups for all operators within an explicit namespace
16240    could easily create a header file that does so:
16241</p><pre>    namespace mymath::
16242    {
16243        #include "using_ops.hpp"
16244    }
16245</pre></blockquote>
16246</li>
16247</ol>
16248
16249
16250<p><b>Proposed resolution:</b></p>
16251<p>
16252</p>
16253
16254
16255<p><b>Rationale:</b></p>
16256We believe that the existing language does not cause any real confusion
16257and any new formulation of the rules that we could come up with are
16258unlikely to be better than what's already in the standard.
16259
16260
16261
16262
16263
16264<hr>
16265<h3><a name="658"></a>658. Two unspecified function comparators in [function.objects]</h3>
16266<p><b>Section:</b> 20.7 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
16267 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-03-19  <b>Last modified:</b> 2007-08-05</p>
16268<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p>
16269<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
16270<p><b>Discussion:</b></p>
16271<p>
16272The header <tt>&lt;functional&gt;</tt> synopsis in 20.7 [function.objects]
16273contains the following two free comparison operator templates
16274for the <tt>function</tt> class template
16275</p>
16276
16277<blockquote><pre>template&lt;class Function1, class Function2&gt;
16278void operator==(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);
16279template&lt;class Function1, class Function2&gt;
16280void operator!=(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);
16281</pre></blockquote>
16282
16283<p>
16284which are nowhere described. I assume that they are relicts before the
16285corresponding two private and undefined member templates in the function
16286template (see 20.7.15.2 [func.wrap.func] and  [func.wrap.func.undef]) have been introduced. The original free
16287function templates should be removed, because using an undefined entity
16288would lead to an ODR violation of the user.
16289</p>
16290
16291
16292<p><b>Proposed resolution:</b></p>
16293<p>
16294Remove the above mentioned two function templates from
16295the header <tt>&lt;functional&gt;</tt> synopsis (20.7 [function.objects])
16296</p>
16297
16298<blockquote><pre><del>template&lt;class Function1, class Function2&gt;
16299void operator==(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);
16300template&lt;class Function1, class Function2&gt;
16301void operator!=(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);</del>
16302</pre></blockquote>
16303
16304
16305
16306<p><b>Rationale:</b></p>
16307Fixed by
16308<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2292.html">N2292</a>
16309Standard Library Applications for Deleted Functions.
16310
16311
16312
16313
16314
16315<hr>
16316<h3><a name="662"></a>662. Inconsistent handling of incorrectly-placed thousands separators</h3>
16317<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#NAD">NAD</a>
16318 <b>Submitter:</b> Cosmin Truta <b>Opened:</b> 2007-04-05  <b>Last modified:</b> 2007-07-25</p>
16319<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>
16320<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>
16321<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
16322<p><b>Discussion:</b></p>
16323<p>
16324From Section 22.4.2.1.2 [facet.num.get.virtuals], paragraphs 11 and 12, it is implied
16325that the value read from a stream must be stored
16326even if the placement of thousands separators does not conform to the
16327<code>grouping()</code> specification from the <code>numpunct</code> facet.
16328Since incorrectly-placed thousands separators are flagged as an extraction
16329failure (by the means of <code>failbit</code>), we believe it is better not
16330to store the value. A consistent strategy, in which any kind of extraction
16331failure leaves the input item intact, is conceptually cleaner, is able to avoid
16332corner-case traps, and is also more understandable from the programmer's point
16333of view.
16334</p>
16335<p>
16336Here is a quote from <i>"The C++ Programming Language (Special Edition)"</i>
16337by B.&nbsp;Stroustrup (Section&nbsp;D.4.2.3, pg.&nbsp;897):
16338</p>
16339<blockquote><p>
16340<i>"If a value of the desired type could not be read, failbit is set in r.
16341[...] An input operator will use r to determine how to set the state of its
16342stream. If no error was encountered, the value read is assigned through v;
16343otherwise, v is left unchanged."</i>
16344</p></blockquote>
16345<p>
16346This statement implies that <code>rdstate()</code> alone is sufficient to
16347determine whether an extracted value is to be assigned to the input item
16348<i>val</i> passed to <code>do_get</code>. However, this is in disagreement
16349with the current C++ Standard. The above-mentioned assumption is true in all
16350cases, except when there are mismatches in digit grouping. In the latter case,
16351the parsed value is assigned to <i>val</i>, and, at the same time, <i>err</i>
16352is assigned to <code>ios_base::failbit</code> (essentially "lying" about the
16353success of the operation). Is this intentional? The current behavior raises
16354both consistency and usability concerns.
16355</p>
16356<p>
16357Although digit grouping is outside the scope of <code>scanf</code> (on which
16358the virtual methods of <code>num_get</code> are based), handling of grouping
16359should be consistent with the overall behavior of scanf. The specification of
16360<code>scanf</code> makes a distinction between input failures and matching
16361failures, and yet both kinds of failures have no effect on the input items
16362passed to <code>scanf</code>. A mismatch in digit grouping logically falls in
16363the category of matching failures, and it would be more consistent, and less
16364surprising to the user, to leave the input item intact whenever a failure is
16365being signaled.
16366</p>
16367<p>
16368The extraction of <code>bool</code> is another example outside the scope of
16369<code>scanf</code>, and yet consistent, even in the event of a successful
16370extraction of a <code>long</code> but a failed conversion from
16371<code>long</code> to <code>bool</code>.
16372</p>
16373<p>
16374Inconsistency is further aggravated by the fact that, when failbit is set,
16375subsequent extraction operations are no-ops until <code>failbit</code> is
16376explicitly cleared. Assuming that there is no explicit handling of
16377<code>rdstate()</code> (as in <code>cin&gt;&gt;i&gt;&gt;j</code>) it is
16378counter-intuitive to be able to extract an integer with mismatched digit
16379grouping, but to be unable to extract another, properly-formatted integer
16380that immediately follows.
16381</p>
16382<p>
16383Moreover, setting <code>failbit</code>, and selectively assigning a value to
16384the input item, raises usability problems. Either the strategy of
16385<code>scanf</code> (when there is no extracted value in case of failure), or
16386the strategy of the <code>strtol</code> family (when there is always an
16387extracted value, and there are well-defined defaults in case of a failure) are
16388easy to understand and easy to use. On the other hand, if <code>failbit</code>
16389alone cannot consistently make a difference between a failed extraction, and a
16390successful but not-quite-correct extraction whose output happens to be the same
16391as the previous value, the programmer must resort to implementation tricks.
16392Consider the following example:
16393</p>
16394<pre>    int i = old_i;
16395    cin &gt;&gt; i;
16396    if (cin.fail())
16397        // can the value of i be trusted?
16398        // what does it mean if i == old_i?
16399        // ...
16400</pre>
16401<p>
16402Last but not least, the current behvaior is not only confusing to the casual
16403reader, but it has also been confusing to some book authors. Besides
16404Stroustrup's book, other books (e.g. "Standard C++ IOStreams and Locales" by
16405Langer and Kreft) are describing the same mistaken assumption. Although books
16406are not to be used instead of the standard reference, the readers of these
16407books, as well as the people who are generally familiar to <code>scanf</code>,
16408are even more likely to misinterpret the standard, and expect the input items
16409to remain intact when a failure occurs.
16410</p>
16411
16412
16413<p><b>Proposed resolution:</b></p>
16414
16415<p>
16416Change 22.4.2.1.2 [facet.num.get.virtuals]:
16417</p>
16418
16419<blockquote>
16420<p>
16421<b>Stage 3:</b> The result of stage 2 processing can be one of
16422</p>
16423<ul>
16424<li>A sequence of <code>chars</code> has been accumulated in stage 2 that is converted (according to the rules of <code>scanf</code>) to a value of the type of <code><i>val</i></code>.  <del>This value is stored in <code><i>val</i></code> and <code>ios_base::goodbit</code> is stored in <code><i>err</i></code>.</del></li>
16425
16426<li>The sequence of <code>chars</code> accumulated in stage 2 would have caused <code>scanf</code> to report an input failure. <code>ios_base::failbit</code> is assigned to <code><i>err</i></code>.</li>
16427</ul>
16428<p>
16429<ins>In the first case,</ins> <del>D</del><ins>d</ins>igit grouping is checked.  That is, the positions of discarded separators is examined for consistency with <code>use_facet&lt;numpunct&lt;charT&gt; &gt;(<i>loc</i>).grouping()</code>.  If they are not consistent then <code>ios_base::failbit</code> is assigned to <code><i>err</i></code>.  <ins>Otherwise, the value that was converted in stage 2 is stored in <code><i>val</i></code> and <code>ios_base::goodbit</code> is stored in <code><i>err</i></code>.</ins>
16430</p>
16431</blockquote>
16432
16433
16434<p><b>Rationale:</b></p>
16435post-Toronto: Changed from New to NAD at the request of the author.  The preferred solution of
16436<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2327.pdf">N2327</a>
16437makes this resolution obsolete.
16438
16439
16440
16441
16442
16443<hr>
16444<h3><a name="663"></a>663. Complexity Requirements</h3>
16445<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#NAD">NAD</a>
16446 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16  <b>Last modified:</b> 2009-05-01</p>
16447<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>
16448<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
16449<p><b>Discussion:</b></p>
16450<p>
1645117.5.1.4 [structure.specifications] para 5 says
16452</p>
16453
16454<blockquote><p>
16455-5- Complexity requirements specified in the library
16456clauses are upper bounds, and implementations that provide better
16457complexity guarantees satisfy the requirements.
16458</p></blockquote>
16459
16460<p>
16461The following
16462objection has been raised:
16463</p>
16464
16465<blockquote><p>
16466The library clauses suggest general
16467guidelines regarding complexity, but we have been unable to discover
16468any absolute hard-and-fast formulae for these requirements. Unless
16469or until the Library group standardizes specific hard-and-fast
16470formulae, we regard all the complexity requirements as subject to a
16471"fudge factor" without any intrinsic upper bound.
16472</p></blockquote>
16473
16474<p>
16475[Plum ref
16476_23213Y31 etc]
16477</p>
16478
16479
16480<p><b>Proposed resolution:</b></p>
16481<p>
16482</p>
16483
16484
16485<p><b>Rationale:</b></p>
16486Kona (2007): No specific instances of underspecification have been
16487identified, and big-O notation always involves constant factors.
16488
16489
16490
16491
16492
16493<hr>
16494<h3><a name="667"></a>667. <tt>money_get</tt>'s widened minus sign</h3>
16495<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#NAD">NAD</a>
16496 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16  <b>Last modified:</b> 2009-07-13</p>
16497<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>
16498<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
16499<p><b>Discussion:</b></p>
16500<p>
1650122.4.6.1.2 [locale.money.get.virtuals], para 1 says:
16502</p>
16503
16504<blockquote><p>
16505The result is returned as an integral value
16506stored in <tt>units</tt> or as a sequence of digits possibly preceded by a
16507minus sign (as produced by <tt>ct.widen(c)</tt> where <tt>c</tt> is '-' or in the range
16508from '0' through '9', inclusive) stored in <tt>digits</tt>.
16509</p></blockquote>
16510
16511<p>
16512The following
16513objection has been raised:
16514</p>
16515
16516<blockquote><p>
16517Some implementations interpret this to mean that a facet derived from
16518<tt>ctype&lt;wchar_t&gt;</tt> can provide its own member <tt>do_widen(char)</tt>
16519which produces e.g. <tt>L'@'</tt> for the "widened" minus sign, and that the
16520<tt>'@'</tt> symbol will appear in the resulting sequence of digits.  Other
16521implementations have assumed that one or more places in the standard permit the
16522implementation to "hard-wire" <tt>L'-'</tt> as the "widened" minus sign.  Are
16523both interpretations permissible, or only  one?
16524</p></blockquote>
16525
16526<p>
16527[Plum ref _222612Y14]
16528</p>
16529
16530<p>
16531Furthermore: if <tt>ct.widen('9')</tt> produces <tt>L'X'</tt> (a non-digit), does a
16532parse fail if a <tt>'9'</tt> appears in the subject string? [Plum ref _22263Y33]
16533</p>
16534
16535<p><i>[
16536Kona (2007): Bill and Dietmar to provide proposed wording.
16537]</i></p>
16538
16539
16540<p><i>[
16541post Bellevue: Bill adds:
16542]</i></p>
16543
16544
16545<blockquote>
16546The Standard is clear that the minus sign stored in <tt>digits</tt> is <tt>ct.widen('-')</tt>.
16547The subject string must contain characters <tt>c</tt> in the set <tt>[-0123456789]</tt>
16548which are translated by <tt>ct.widen(c)</tt> calls before being stored in <tt>digits</tt>;
16549the widened characters are not relevant to the parsing of the subject string.
16550</blockquote>
16551
16552<p><i>[
16553Batavia (2009-05):
16554]</i></p>
16555
16556<blockquote>
16557We agree with Bill's comment above,
16558in line with the first of the interpretations offered in the issue.
16559Move to NAD.
16560</blockquote>
16561
16562
16563<p><b>Proposed resolution:</b></p>
16564<p>
16565</p>
16566
16567
16568
16569
16570
16571<hr>
16572<h3><a name="668"></a>668. <tt>money_get</tt>'s empty minus sign</h3>
16573<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#NAD">NAD</a>
16574 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16  <b>Last modified:</b> 2009-10-21</p>
16575<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>
16576<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
16577<p><b>Discussion:</b></p>
16578<p>
1657922.4.6.1.2 [locale.money.get.virtuals], para 3 says:
16580</p>
16581
16582<blockquote><p>
16583If <tt>pos</tt> or <tt>neg</tt> is empty, the sign component is
16584optional, and if no sign is detected, the result is given the sign
16585that corresponds to the source of the empty string.
16586</p></blockquote>
16587
16588<p>
16589The following objection has been raised:
16590</p>
16591
16592<blockquote><p>
16593A <tt>negative_sign</tt> of "" means "there is no
16594way to write a negative sign" not "any null sequence is a negative
16595sign, so it's always there when you look for it".
16596</p></blockquote>
16597
16598<p>
16599[Plum ref _222612Y32]
16600</p>
16601
16602<p><i>[
16603Kona (2007): Bill to provide proposed wording and interpretation of existing wording.
16604]</i></p>
16605
16606
16607<p>
16608Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>.
16609</p>
16610
16611<p><i>[
166122009-05-17 Howard adds:
16613]</i></p>
16614
16615
16616<blockquote>
16617<p>
16618I disagree that a <tt>negative_sign</tt> of "" means "there is no
16619way to
16620write a negative sign". The meaning requires the sentences of
1662122.4.6.1.2 [locale.money.get.virtuals] p3 following that quoted above
16622to be
16623taken into account:
16624</p>
16625
16626<blockquote>
16627-3- ... If <tt>pos</tt> or <tt>neg</tt> is empty, the sign component is
16628optional, and if no sign is detected, the result is given the sign that
16629corresponds to the source of the empty string. Otherwise, the character
16630in the indicated position must match the first character of <tt>pos</tt>
16631or <tt>neg</tt>, and the result is given the corresponding sign. If the
16632first character of <tt>pos</tt> is equal to the first character of
16633<tt>neg</tt>, or if both strings are empty, the result is given a
16634positive sign.
16635</blockquote>
16636
16637<p>
16638So a <tt>negative_sign</tt> of "" means "there is no way to write a
16639negative sign" only when <tt>positive_sign</tt> is also "".  However
16640when <tt>negative_sign</tt> is "" and <tt>postive_sign.size() &gt;
166410</tt>, then one writes a negative value by not writing the
16642<tt>postive_sign</tt> in the position indicated by
16643<tt>money_base::sign</tt>.
16644For example:
16645</p>
16646
16647<blockquote><pre>pattern = {symbol, sign, value, none}
16648positive_sign = "+"
16649negative_sign = ""
16650$123   // a negative value, using optional sign
16651$+123  // a positive value
16652$-123  // a parse error
16653</pre></blockquote>
16654
16655<p>
16656And:
16657</p>
16658
16659<blockquote><pre>pattern = {symbol, sign, value, none}
16660positive_sign = ""
16661negative_sign = ""
16662$123   // a positive value, no sign possible
16663$+123  // a parse error
16664$-123  // a parse error
16665</pre></blockquote>
16666
16667
16668<p>
16669And (regarding <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a>):
16670</p>
16671
16672<blockquote><pre>pattern = {symbol, sign, value, none}
16673positive_sign = "-"
16674negative_sign = "-"
16675$123   // a parse error, sign is mandatory
16676$+123  // a parse error
16677$-123  // a positive value
16678</pre></blockquote>
16679
16680
16681<p>
16682The text seems both unambiguous and clear to me.  I recommend NAD for
16683both 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
16684objection to adding examples such as those above.
16685</p>
16686</blockquote>
16687
16688<p><i>[
16689Batavia (2009-05):
16690]</i></p>
16691
16692<blockquote>
16693<p>
16694This discussion applies equally to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a> (q.v.).
16695Howard has added examples above,
16696and recommends either NAD or a resolution that adds his (or similar) examples
16697to the Working Paper.
16698</p>
16699<p>
16700Alan would like to rewrite paragraph 3.
16701</p>
16702<p>
16703We recommend moving to NAD.
16704Anyone who feels strongly about adding the examples
16705is invited to submit corresponding wording.
16706We further recommend issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#669">669</a> be handled identically.
16707</p>
16708</blockquote>
16709
16710<p><i>[
167112009-07-14 Alan reopens with improved wording.
16712]</i></p>
16713
16714
16715<p><i>[
167162009-07 Frankfurt
16717]</i></p>
16718
16719
16720<blockquote>
16721No consensus for closing as NAD.  Leave in Review.
16722</blockquote>
16723
16724<p><i>[
167252009-10 Santa Cruz:
16726]</i></p>
16727
16728
16729<blockquote>
16730NAD.  Agreed that the original assessment as NAD was correct.
16731</blockquote>
16732
16733
16734
16735<p><b>Proposed resolution:</b></p>
16736<p>
16737Change 22.4.6.1.2 [locale.money.get.virtuals] p3:
16738</p>
16739
16740<blockquote>
16741-3- <del>If the first character (if any) in the string pos returned by
16742<tt>mp.positive_sign()</tt> or the string <tt>neg</tt> returned by
16743<tt>mp.negative_sign()</tt> is recognized in the position indicated by
16744sign in the format pattern, it is consumed and any remaining characters
16745in the string are required after all the other format components.
16746[<i>Example:</i> If <tt>showbase</tt> is off, then for a <tt>neg</tt>
16747value of "()" and a currency symbol of "L", in "(100 L)" the "L" is
16748consumed; but if <tt>neg</tt> is "-", the "L" in "-100 L" is not
16749consumed. -- <i>end example</i>] If <tt>pos</tt> or <tt>neg</tt> is
16750empty, the sign component is optional, and if no sign is detected, the
16751result is given the sign that corresponds to the source of the empty
16752string. Otherwise, the character in the indicated position must match
16753the first character of <tt>pos</tt> or <tt>neg</tt>, and the result is
16754given the corresponding sign. If the first character of <tt>pos</tt> is
16755equal to the first character of <tt>neg</tt>, or if both strings are
16756empty, the result is given a positive sign.</del>
16757
16758<ins>The sign pattern strings <tt>pos</tt> and <tt>neg</tt> are returned by
16759<tt>mp.positive_sign()</tt> and <tt>mp.negative_sign()</tt> respectively. A sign pattern
16760is matched if its first character is recognized in <tt>s</tt> in the position
16761indicated by <tt>sign</tt> in the format pattern, or if the pattern is empty and
16762there is no sign recognized in <tt>s</tt>. A match is required to occur. If both
16763patterns are matched, the result is given a positive sign, otherwise the
16764result is given the sign corresponding to the matched pattern. 
16765If the pattern contains more than one character, the characters after the first 
16766must be matched in <tt>s</tt> after all other format components. 
16767If any sign
16768characters are matched, <tt>s</tt> is consumed up to and including those characters.
16769[<i>Example:</i> If <tt>showbase</tt> is off, then for a <tt>neg</tt>
16770value of "<tt>()</tt>" and a currency symbol of "<tt>L</tt>", in
16771"<tt>(100 L)</tt>" the entire string is consumed; but for a <tt>neg</tt>
16772value of "<tt>-</tt>", in "<tt>-100 L</tt>", the string is consumed
16773through the second "<tt>0</tt>" (the space and "<tt>L</tt>" are not consumed). &#8212; <i>end
16774example</i>] </ins>
16775</blockquote>
16776
16777
16778
16779
16780
16781<hr>
16782<h3><a name="669"></a>669. Equivalent postive and negative signs in <tt>money_get</tt></h3>
16783<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#NAD">NAD</a>
16784 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16  <b>Last modified:</b> 2009-07-13</p>
16785<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>
16786<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
16787<p><b>Discussion:</b></p>
16788<p>
1678922.4.6.1.2 [locale.money.get.virtuals], para 3 sentence 4 says:
16790</p>
16791
16792<blockquote><p>
16793If the first character of <tt>pos</tt> is equal to the first character of <tt>neg</tt>, 
16794or if both strings are empty, the result is given a positive sign.
16795</p></blockquote>
16796
16797<p>
16798One interpretation is that an input sequence must match either the
16799positive pattern or the negative pattern, and then in either event it
16800is interpreted as positive.  The following objections has been raised:
16801</p>
16802
16803<blockquote><p>
16804The input can successfully match only a positive sign, so the negative
16805pattern is an unsuccessful match.
16806</p></blockquote>
16807
16808<p>
16809[Plum ref _222612Y34, 222612Y51b]
16810</p>
16811
16812<p><i>[
16813Bill to provide proposed wording and interpretation of existing wording.
16814]</i></p>
16815
16816
16817<p><i>[
168182009-05-17 See Howard's comments in related issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#668">668</a>.
16819]</i></p>
16820
16821
16822<p><i>[
16823Batavia (2009-05):
16824]</i></p>
16825
16826<blockquote>
16827<p>
16828This discussion applies equally to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#668">668</a> (q.v.).
16829Howard has added examples there,
16830and recommends either NAD or a resolution that adds his (or similar) examples
16831to the Working Paper.
16832</p>
16833<p>
16834We recommend moving to NAD.
16835Anyone who feels strongly about adding the examples
16836is invited to submit corresponding wording.
16837We further recommend issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#668">668</a> be handled identically.
16838</p>
16839</blockquote>
16840
16841
16842<p><b>Proposed resolution:</b></p>
16843<p>
16844</p>
16845
16846
16847
16848
16849
16850<hr>
16851<h3><a name="670"></a>670. <tt>money_base::pattern</tt> and <tt>space</tt></h3>
16852<p><b>Section:</b> 22.4.6.3 [locale.moneypunct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
16853 <b>Submitter:</b> Thomas Plum <b>Opened:</b> 2007-04-16  <b>Last modified:</b> 2008-09-22</p>
16854<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
16855<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a></p>
16856<p><b>Discussion:</b></p>
16857<p>
1685822.4.6.3 [locale.moneypunct], para 2 says:
16859</p>
16860
16861<blockquote><p>
16862The value <tt>space</tt> indicates that at least one space is required at 
16863that position.
16864</p></blockquote>
16865
16866<p>
16867The following objection has been raised:
16868</p>
16869
16870<blockquote><p>
16871Whitespace is optional when matching space. (See 22.4.6.1.2 [locale.money.get.virtuals], para 2.)
16872</p></blockquote>
16873
16874<p>
16875[Plum ref _22263Y22]
16876</p>
16877
16878<p><i>[
16879Kona (2007): Bill to provide proposed wording. We agree that C++03 is
16880ambiguous, and that we want C++0X to say "space" means 0 or more
16881whitespace characters on input.
16882]</i></p>
16883
16884
16885
16886
16887<p><b>Proposed resolution:</b></p>
16888
16889
16890
16891
16892
16893<hr>
16894<h3><a name="683"></a>683. regex_token_iterator summary error</h3>
16895<p><b>Section:</b> 28.12.2 [re.tokiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
16896 <b>Submitter:</b> Eric Niebler <b>Opened:</b> 2007-06-02  <b>Last modified:</b> 2009-03-09</p>
16897<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.tokiter">issues</a> in [re.tokiter].</p>
16898<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
16899<p><b>Discussion:</b></p>
16900<p>
1690128.12.2 [re.tokiter], p3 says:
16902</p>
16903<blockquote>
16904<p>
16905After it is constructed, the iterator finds and stores a value
16906<tt>match_results&lt;BidirectionalIterator&gt;</tt> position and sets the
16907internal count <tt>N</tt> to zero.
16908</p>
16909</blockquote>
16910
16911<p>
16912Should read:
16913</p>
16914
16915<blockquote>
16916<p>
16917After it is constructed, the iterator finds and stores a value
16918<tt><del>match_results</del><ins>regex_iterator</ins>&lt;BidirectionalIterator<ins>, charT, traits</ins>&gt;</tt>
16919position and sets the internal count <tt>N</tt> to zero.
16920</p>
16921</blockquote>
16922
16923<p><i>[
16924John adds:
16925]</i></p>
16926
16927
16928<blockquote><p>
16929Yep, looks like a typo/administrative fix to me.
16930</p></blockquote>
16931
16932
16933
16934<p><b>Proposed resolution:</b></p>
16935<p>
16936</p>
16937
16938
16939
16940
16941
16942<hr>
16943<h3><a name="684"></a>684. Unclear which members of match_results should be used in comparison</h3>
16944<p><b>Section:</b> 28.10 [re.results] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
16945 <b>Submitter:</b> Nozomu Katoo <b>Opened:</b> 2007-05-27  <b>Last modified:</b> 2008-03-12</p>
16946<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.results">issues</a> in [re.results].</p>
16947<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
16948<p><b>Discussion:</b></p>
16949<p>
16950In 28.4 [re.syn] of N2284, two template functions 
16951are declared here: 
16952</p>
16953<blockquote><pre>// 28.10, class template match_results: 
16954  &lt;<i>snip</i>&gt;
16955// match_results comparisons 
16956  template &lt;class BidirectionalIterator, class Allocator&gt; 
16957    bool operator== (const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1, 
16958                     const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2); 
16959  template &lt;class BidirectionalIterator, class Allocator&gt; 
16960    bool operator!= (const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1, 
16961                     const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2); 
16962
16963// 28.10.6, match_results swap:
16964</pre></blockquote>
16965
16966<p>
16967But the details of these two bool operator functions (i.e., which members of
16968<tt>match_results</tt> should be used in comparison) are not described in any
16969following sections.
16970</p>
16971
16972<p><i>[
16973John adds:
16974]</i></p>
16975
16976
16977<blockquote><p>
16978That looks like a bug: <tt>operator==</tt> should return <tt>true</tt> only if
16979the two objects refer to the same match - ie if one object was constructed as a
16980copy of the other.
16981</p></blockquote>
16982
16983<p><i>[
16984Kona (2007): Bill and Pete to add minor wording to that proposed in
16985<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
16986]</i></p>
16987
16988
16989
16990<p><b>Proposed resolution:</b></p>
16991<p>
16992Add a new section after 28.10.6 [re.results.swap], which reads:
16993</p>
16994<p>
1699528.10.7 match_results non-member functions.
16996</p>
16997
16998<blockquote>
16999<pre>template&lt;class BidirectionalIterator, class Allocator&gt; 
17000  bool operator==(const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1, 
17001                  const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2);
17002</pre>
17003<blockquote>
17004<p>
17005<i>Returns:</i> <tt>true</tt> only if the two objects refer to the same match.
17006</p>
17007</blockquote>
17008</blockquote>
17009
17010<blockquote>
17011<pre>template&lt;class BidirectionalIterator, class Allocator&gt; 
17012  bool operator!=(const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1, 
17013                  const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2);
17014</pre>
17015<blockquote>
17016<p>
17017<i>Returns:</i> <tt>!(m1 == m2)</tt>.
17018</p>
17019</blockquote>
17020</blockquote>
17021
17022<blockquote>
17023<pre>template&lt;class BidirectionalIterator, class Allocator&gt; 
17024  void swap(match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1, 
17025            match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2);
17026</pre>
17027<blockquote>
17028<p>
17029<i>Returns:</i> <tt>m1.swap(m2)</tt>.
17030</p>
17031</blockquote>
17032</blockquote>
17033
17034
17035<p><i>[
17036Bellevue:  Proposed wording now in WP.
17037]</i></p>
17038
17039
17040
17041
17042
17043<hr>
17044<h3><a name="686"></a>686. Unique_ptr and shared_ptr fail to specify non-convertibility to int for unspecified-bool-type</h3>
17045<p><b>Section:</b> 20.8.14.2.4 [unique.ptr.single.observers], 20.8.15.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
17046 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2007-06-14  <b>Last modified:</b> 2008-02-27</p>
17047<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
17048<p><b>Discussion:</b></p>
17049<p>
17050The standard library uses the <tt>operator <i>unspecified-bool-type</i>() const</tt> idiom in
17051five places. In three of those places (20.7.15.2.3 [func.wrap.func.cap], function capacity 
17052for example) the returned value is constrained to disallow
17053unintended conversions to int. The standardese is
17054</p>
17055<blockquote><p>
17056The return type shall not be convertible to <tt>int</tt>.
17057</p></blockquote>
17058<p>
17059This constraint is omitted for <tt>unique_ptr</tt> and <tt>shared_ptr</tt>. It should be added for those.
17060</p>
17061
17062<p><i>[
17063Bellevue:
17064]</i></p>
17065
17066
17067<blockquote>
17068Close as NAD. Accepting paper
17069<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2435.htm">N2435</a>
17070makes it irrelevant.
17071</blockquote>
17072
17073
17074
17075<p><b>Proposed resolution:</b></p>
17076<p>
17077To the <i>Returns</i> paragraph for <tt>operator <i>unspecified-bool-type</i>()
17078const</tt>
17079of 20.8.14.2.4 [unique.ptr.single.observers] paragraph 11 and
1708020.8.15.2.5 [util.smartptr.shared.obs] paragraph 16, add the sentence:
17081</p>
17082<blockquote><p>
17083The return type shall not be convertible to <tt>int</tt>.
17084</p></blockquote>
17085
17086
17087<p><i>[
17088Kona (2007): Uncertain if <tt>nullptr</tt> will address this issue.
17089]</i></p>
17090
17091
17092
17093
17094
17095<hr>
17096<h3><a name="690"></a>690. abs(long long) should return long long</h3>
17097<p><b>Section:</b> 26.8 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
17098 <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2007-06-10  <b>Last modified:</b> 2007-07-25</p>
17099<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
17100<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
17101<p><b>Discussion:</b></p>
17102<p>
17103Quoting the latest draft (n2135), 26.8 [c.math]: 
17104</p>
17105
17106<blockquote>
17107<p>
17108The added signatures are:
17109</p>
17110<blockquote><pre>long abs(long); // labs()
17111long abs(long long); // llabs()
17112</pre></blockquote>
17113</blockquote>
17114<p>
17115Shouldn't <tt>abs(long long)</tt> have <tt>long long</tt> as return type?
17116</p>
17117
17118
17119<p><b>Proposed resolution:</b></p>
17120<p>
17121Change 26.8 [c.math]: 
17122</p>
17123<blockquote><pre><ins>long </ins>long abs(long long); // llabs()
17124</pre></blockquote>
17125
17126
17127<p><b>Rationale:</b></p>
17128Had already been fixed in the WP by the time the LWG reviewed this.
17129
17130
17131
17132
17133
17134<hr>
17135<h3><a name="697"></a>697. New <tt>&lt;system_error&gt;</tt> header leads to name clashes</h3>
17136<p><b>Section:</b> 19.5 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
17137 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-06-24  <b>Last modified:</b> 2008-01-06</p>
17138<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p>
17139<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
17140<p><b>Discussion:</b></p>
17141<p>
17142The most recent state of 
17143<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html">N2241</a>
17144as well as the current draft
17145<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a>
17146(section 19.5 [syserr], p.2) proposes a
17147new
17148enumeration type <tt>posix_errno</tt> immediatly in the namespace <tt>std</tt>. One of
17149the enumerators has the name <tt>invalid_argument</tt>, or fully qualified:
17150<tt>std::invalid_argument</tt>. This name clashes with the exception type
17151<tt>std::invalid_argument</tt>, see 19.2 [std.exceptions]/p.3. This clash makes
17152e.g. the following snippet invalid:
17153</p>
17154
17155<blockquote><pre>#include &lt;system_error&gt;
17156#include &lt;stdexcept&gt;
17157
17158void foo() { throw std::invalid_argument("Don't call us - we call you!"); }
17159</pre></blockquote>
17160
17161<p>
17162I propose that this enumeration type (and probably the remaining parts
17163of
17164<tt>&lt;system_error&gt;</tt> as well) should be moved into one additional inner
17165namespace, e.g. <tt>sys</tt> or <tt>system</tt> to reduce foreseeable future clashes
17166due
17167to the great number of members that <tt>std::posix_errno</tt> already contains
17168(Btw.: Why has the already proposed <tt>std::sys</tt> sub-namespace from
17169<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2066.html">N2066</a>
17170been rejected?). A further clash <em>candidate</em> seems to be
17171<tt>std::protocol_error</tt>
17172(a reasonable name for an exception related to a std network library,
17173I guess).
17174</p>
17175
17176<p>
17177Another possible resolution would rely on the proposed strongly typed
17178enums,
17179as described in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2213.pdf">N2213</a>.
17180But maybe the forbidden implicit conversion to integral types would
17181make
17182these enumerators less attractive in this special case?
17183</p>
17184
17185
17186<p><b>Proposed resolution:</b></p>
17187<p>
17188Fixed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2422.htm#Issue7">issue 7 of N2422</a>.
17189</p>
17190
17191
17192
17193
17194
17195
17196<hr>
17197<h3><a name="701"></a>701. assoc laguerre poly's</h3>
17198<p><b>Section:</b> TR1 5.2.1.1 [tr.num.sf.Lnm] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
17199 <b>Submitter:</b> Christopher Crawford <b>Opened:</b> 2007-06-30  <b>Last modified:</b> 2009-07-13</p>
17200<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
17201<p><b>Discussion:</b></p>
17202<p>
17203I see that the definition the associated Laguerre
17204polynomials TR1 5.2.1.1 [tr.num.sf.Lnm] has been corrected since
17205<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1687.pdf">N1687</a>.
17206However, the draft standard only specifies ranks of integer value <tt>m</tt>,
17207while the associated Laguerre polynomials are actually valid for real
17208values of <tt>m &gt; -1</tt>.  In the case of non-integer values of <tt>m</tt>, the
17209definition  <tt><i>L</i><sub>n</sub><sup>(m)</sup> = (1/n!)e<sup>x</sup>x<sup>-m</sup> (d/dx)<sup>n</sup> (e<sup>-x</sup>x<sup>m+n</sup>)</tt>
17210must be used, which also holds for integer values of <tt>m</tt>.  See
17211Abramowitz &amp; Stegun, 22.11.6 for the general case, and 22.5.16-17 for
17212the integer case.  In fact fractional values are most commonly used in
17213physics, for example to <tt>m = +/- 1/2</tt> to describe the harmonic
17214oscillator in 1 dimension, and <tt>1/2, 3/2, 5/2, ...</tt> in 3
17215dimensions.
17216</p>
17217<p>
17218If I am correct, the calculation of the more general case is no
17219more difficult, and is in fact the function implemented in the GNU
17220Scientific Library.  I would urge you to consider upgrading the 
17221standard, either adding extra functions for real <tt>m</tt> or switching the
17222current ones to <tt>double</tt>.
17223</p>
17224
17225<p><i>[
17226Batavia (2009-05):
17227]</i></p>
17228
17229<blockquote>
17230<p>
17231We understand the issue, and have opted not to extend as recommended.
17232</p>
17233<p>
17234Move to NAD.
17235</p>
17236</blockquote>
17237
17238
17239<p><b>Proposed resolution:</b></p>
17240<p>
17241</p>
17242
17243
17244
17245
17246
17247<hr>
17248<h3><a name="702"></a>702. Restriction in associated Legendre functions</h3>
17249<p><b>Section:</b> TR1 5.2.1.2 [tr.num.sf.Plm] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
17250 <b>Submitter:</b> Christopher Crawford <b>Opened:</b> 2007-06-30  <b>Last modified:</b> 2009-07-13</p>
17251<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
17252<p><b>Discussion:</b></p>
17253<p>
17254One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should  be
17255<tt>|x| &lt;= 1</tt>, not <tt>x &gt;= 0</tt>.</p>
17256
17257<p><i>[
17258Batavia (2009-05):
17259]</i></p>
17260
17261<blockquote>
17262<p>
17263The error has been corrected in the pending IS.
17264</p>
17265<p>
17266Move to NAD.
17267</p>
17268</blockquote>
17269
17270
17271<p><b>Proposed resolution:</b></p>
17272<p>
17273</p>
17274
17275
17276
17277
17278
17279<hr>
17280<h3><a name="707"></a>707. null pointer constant for <tt>exception_ptr</tt></h3>
17281<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#NAD">NAD</a>
17282 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2007-07-20  <b>Last modified:</b> 2008-02-25</p>
17283<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>
17284<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>
17285<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
17286<p><b>Discussion:</b></p>
17287
17288<p>
17289From the Toronto Core wiki:
17290</p>
17291
17292<p>
17293What do you mean by "null pointer constant"? How do you guarantee that
17294<tt>exception_ptr() == 1</tt> doesn't work?  Do you even want to prevent that?
17295What's the semantics?  What about <tt>void *p = 0; exception_ptr() == p</tt>?
17296Maybe disallow those in the interface, but how do you do that with
17297portable C++? Could specify just "make it work".
17298</p>
17299
17300<p>
17301Peter's response:
17302</p>
17303
17304<p>
17305null pointer constant as defined in 4.10 [conv.ptr]. Intent is "just make it
17306work", can be implemented as assignment operator taking a unique pointer
17307to member, as in the unspecified bool type idiom.
17308</p>
17309
17310<p><i>[
17311Bellevue:
17312]</i></p>
17313
17314
17315<blockquote>
17316<p>
17317Original implementation was possible using the "unspecified-null-pointer" idiom, similar to unspecified-bool.
17318</p>
17319<p>
17320Even simpler now with nullptr_t.
17321</p>
17322<p>
17323NAD Rationale : null pointer constant is a perfectly defined term, and
17324while API is clearly implementable there is no need to spell out
17325implementation details.
17326</p>
17327</blockquote>
17328
17329
17330
17331<p><b>Proposed resolution:</b></p>
17332<p>
17333</p>
17334
17335
17336
17337
17338
17339<hr>
17340<h3><a name="708"></a>708. Locales need to be per thread and updated for POSIX changes</h3>
17341<p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
17342 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2007-07-28  <b>Last modified:</b> 2009-07-16</p>
17343<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#localization">issues</a> in [localization].</p>
17344<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
17345<p><b>Discussion:</b></p>
17346<p>
17347The POSIX "Extended API Set Part 4,"
17348</p>
17349<blockquote><p>
17350<a href="http://www.opengroup.org/sib/details.tpl?id=C065">http://www.opengroup.org/sib/details.tpl?id=C065</a>
17351</p></blockquote>
17352<p>
17353introduces extensions to the C locale mechanism that
17354allow multiple concurrent locales to be used in the same application
17355by introducing a type <tt>locale_t</tt> that is very similar to
17356<tt>std::locale</tt>, and a number of <tt>_l</tt> functions that make use of it.
17357</p>
17358<p>
17359The global locale (set by setlocale) is now specified to be per-
17360process. If a thread does not call <tt>uselocale</tt>, the global locale is
17361in effect for that thread. It can install a per-thread locale by
17362using <tt>uselocale</tt>.
17363</p>
17364<p>
17365There is also a nice <tt>querylocale</tt> mechanism by which one can obtain
17366the name (such as "de_DE") for a specific <tt>facet</tt>, even for combined
17367locales, with no <tt>std::locale</tt> equivalent.
17368</p>
17369<p>
17370<tt>std::locale</tt> should be harmonized with the new POSIX <tt>locale_t</tt>
17371mechanism and provide equivalents for <tt>uselocale</tt> and <tt>querylocale</tt>.
17372</p>
17373
17374<p><i>[
17375Kona (2007): Bill and Nick to provide wording.
17376]</i></p>
17377
17378
17379<p><i>[
17380San Francisco: Bill and Nick still intend to provide wording, but this
17381is a part of the task to be addressed by the group that will look into
17382issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#860">860</a>.
17383]</i></p>
17384
17385
17386<p><i>[
173872009-07 Frankfurt:
17388]</i></p>
17389
17390
17391<blockquote>
17392<p>
17393It's our intention to stay in sync with WG14. If WG14 makes a decision
17394that requires a change in WG21 the issue will be reopened.
17395</p>
17396<p>
17397Move to NAD Future.
17398</p>
17399</blockquote>
17400
17401
17402
17403<p><b>Proposed resolution:</b></p>
17404<p>
17405</p>
17406
17407
17408
17409
17410
17411<hr>
17412<h3><a name="717"></a>717. Incomplete <tt>valarray::operator[]</tt> specification in [valarray.access]</h3>
17413<p><b>Section:</b> 26.6.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
17414 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-08-27  <b>Last modified:</b> 2008-09-22</p>
17415<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.access">issues</a> in [valarray.access].</p>
17416<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
17417<p><b>Discussion:</b></p>
17418<p>
17419Since the return type of <tt>valarray</tt>'s <tt>operator[] const</tt> overload has been
17420changed to <tt>const T&amp;</tt> as described in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> several paragraphs of
17421the section 26.6.2.3 [valarray.access] are now
17422incompletely
17423specified, because many requirements and guarantees should now also
17424apply to the const overload. Most notably, the address and reference
17425guarantees should be extended to the const overload case.
17426</p>
17427
17428
17429<p><b>Proposed resolution:</b></p>
17430<p>
17431Change 26.6.2.3 [valarray.access]:
17432</p>
17433
17434<blockquote>
17435<p>
17436-1- <del>When applied to a constant array, the subscript operator returns a
17437reference to the corresponding element of the array. When applied to a
17438non-constant array, t</del><ins>T</ins>he subscript operator returns a
17439reference to the corresponding element of the array.
17440</p>
17441
17442<p>
17443-3- The expression <tt>&amp;a[i+j] == &amp;a[i] + j</tt> evaluates as <tt>true</tt> for all <tt>size_t i</tt>
17444and <tt>size_t j</tt> such that <tt>i+j</tt> is less 
17445than the length of the <del>non-constant</del> array <tt>a</tt>.
17446</p>
17447
17448<p>
17449-4- Likewise, the expression <tt>&amp;a[i] != &amp;b[j]</tt> evaluates
17450as <tt>true</tt> for any two <del>non-constant</del> arrays <tt>a</tt> and
17451<tt>b</tt> and for any <tt>size_t i</tt> and <tt>size_t j</tt> such that
17452<tt>i</tt> is less than the length of <tt>a</tt> and <tt>j</tt> is less
17453than the length of <tt>b</tt>. This property indicates an absence of
17454aliasing and may be used to advantage by optimizing
17455compilers.<sup>281)</sup>
17456</p>
17457
17458<p>
17459-5- The reference returned by the subscript operator for a<ins>n</ins> <del>non-constant</del> array is guaranteed to be valid until
17460the member function <tt>resize(size_t, T)</tt> (26.5.2.7) is called for that array or until the lifetime 
17461of that array ends, whichever happens first.
17462</p>
17463
17464</blockquote>
17465
17466
17467
17468
17469
17470
17471<hr>
17472<h3><a name="718"></a>718. <tt>basic_string</tt> is not a sequence</h3>
17473<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#NAD%20Editorial">NAD Editorial</a>
17474 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-08-18  <b>Last modified:</b> 2009-07-16</p>
17475<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>
17476<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
17477<p><b>Discussion:</b></p>
17478<p>
17479Paragraph 21.4 [basic.string]/3 states:
17480</p>
17481
17482<blockquote>
17483<p>
17484The class template <tt>basic_string</tt> conforms to the requirements for a 
17485Sequence (23.1.1) and for a Reversible Container (23.1).
17486</p>
17487</blockquote>
17488
17489<p>
17490First of all, 23.2.3 [sequence.reqmts] is no longer "Sequence" but "Sequence container". 
17491Secondly, after the resent changes to containers (<tt>emplace</tt>, <tt>push_back</tt>, 
17492<tt>const_iterator</tt> parameters to <tt>insert</tt> and <tt>erase</tt>), <tt>basic_string</tt> is not 
17493even close to conform to the current requirements.
17494</p>
17495
17496<p><i>[
17497Bellevue:
17498]</i></p>
17499
17500
17501<blockquote>
17502<ul>
17503<li>emplace, for example, may not make sense for strings. Is also likely suboptimal</li>
17504<li>with concepts do we need to maintain string as sequence container?</li>
17505<li>One approach might be to say something like: string is a sequence except it doesn't have these functions</li>
17506</ul>
17507<ul>
17508<li>basic_string already has push_back</li>
17509<li>const_iterator parameters to insert and erase should be added to basic_string</li>
17510<li>this leaves emplace to handle -- we have the following options:
17511<ul>
17512<li>option 1: add it to string even though it's optional</li>
17513<li>option 2: make emplace optional to sequences (move from table 89 to 90)</li>
17514<li>option 3: say string not sequence (the proposal),</li>
17515<li>option 4: add an exception to basic string wording.</li>
17516</ul>
17517</li>
17518</ul>
17519General consensus is to suggest option 2.
17520</blockquote>
17521
17522<p><i>[
175232009-07 Frankfurt:
17524]</i></p>
17525
17526
17527<blockquote>
17528Move to NAD Editorial
17529</blockquote>
17530
17531
17532
17533<p><b>Proposed resolution:</b></p>
17534<p>
17535Remove this sentence, in recognition of the fact that <tt>basic_string</tt> is 
17536not just a <tt>vector</tt>-light for literal types, but something quite 
17537different, a string abstraction in its own right.
17538</p>
17539
17540
17541
17542
17543
17544<hr>
17545<h3><a name="719"></a>719. <tt>std::is_literal</tt> type traits should be provided</h3>
17546<p><b>Section:</b> 20.6 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
17547 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-08-25  <b>Last modified:</b> 2009-10-26</p>
17548<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>
17549<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
17550<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#750">750</a></p>
17551<p><b>Discussion:</b></p>
17552<p>
17553Since the inclusion of <tt>constexpr</tt> in the standard draft N2369 we have
17554a new type category "literal", which is defined in 3.9 [basic.types]/p.11:
17555</p>
17556
17557<blockquote>
17558<p>
17559-11- A type is a <i>literal</i> type if it is:
17560</p>
17561<ul>
17562<li>a scalar type; or</li>
17563<li><p>a class type (clause 9) with</p>
17564<ul>
17565<li>a trivial copy constructor,</li>
17566<li>a trivial destructor,</li>
17567<li>at least one constexpr constructor other than the copy constructor,</li>
17568<li>no virtual base classes, and</li>
17569<li>all non-static data members and base classes of literal types; or</li>
17570</ul>
17571</li>
17572<li>an array of literal type.</li>
17573</ul>
17574</blockquote>
17575
17576<p>
17577I strongly suggest that the standard provides a type traits for
17578literal types in 20.6.4.3 [meta.unary.prop] for several reasons:
17579</p>
17580
17581<ol type="a">
17582<li>To keep the traits in sync with existing types.</li>
17583<li>I see many reasons for programmers to use this trait in template
17584   code to provide optimized template definitions for these types,
17585   see below.</li>
17586<li>A user-provided definition of this trait is practically impossible
17587to write portably.</li>
17588</ol>
17589
17590<p>
17591The special problem of reason (c) is that I don't see currently a
17592way to portably test the condition for literal class types:
17593</p>
17594
17595<blockquote>
17596<ul>
17597<li>at least one constexpr constructor other than the copy constructor,</li>
17598</ul>
17599</blockquote>
17600
17601
17602
17603<p><i>[
17604Alisdair is considering preparing a paper listing a number of missing
17605type traits, and feels that it might be useful to handle them all
17606together rather than piecemeal. This would affect issue 719 and 750.
17607These two issues should move to OPEN pending AM paper on type traits.
17608]</i></p>
17609
17610
17611<p><i>[
176122009-07 Frankfurt:
17613]</i></p>
17614
17615
17616<blockquote>
17617Beman, Daniel, and Alisdair will work on a paper proposing new type traits.
17618</blockquote>
17619
17620<p><i>[
17621Addressed in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2947.html">N2947</a>.
17622]</i></p>
17623
17624
17625<p><i>[
176262009-10 Santa Cruz:
17627]</i></p>
17628
17629
17630<blockquote>
17631NAD Editorial.  Solved by
17632<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2984.html">N2984</a>.
17633</blockquote>
17634
17635
17636
17637<p><b>Proposed resolution:</b></p>
17638<p>
17639In 20.6.2 [meta.type.synop] in the group "type properties",
17640just below the line
17641</p>
17642
17643<blockquote><pre>template &lt;class T&gt; struct is_pod;
17644</pre></blockquote>
17645
17646<p>
17647add a new one:
17648</p>
17649
17650<blockquote><pre>template &lt;class T&gt; struct is_literal;
17651</pre></blockquote>
17652
17653<p>
17654In 20.6.4.3 [meta.unary.prop], table Type Property Predicates, just
17655below the line for the <tt>is_pod</tt> property add a new line:
17656</p>
17657
17658<table border="1">
17659<tbody><tr>
17660<th>Template</th><th>Condition</th><th>Preconditions</th>
17661</tr>
17662<tr>
17663<td><tt>template &lt;class T&gt; struct is_literal;</tt></td>
17664<td><tt>T</tt> is a literal type (3.9)</td>
17665<td><tt>T</tt> shall be a complete type, an
17666array of unknown bound, or
17667(possibly cv-qualified) <tt>void</tt>.</td>
17668</tr>
17669</tbody></table>
17670
17671
17672
17673
17674
17675
17676<hr>
17677<h3><a name="721"></a>721. <tt>wstring_convert</tt> inconsistensies</h3>
17678<p><b>Section:</b> 22.3.3.2.2 [conversions.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
17679 <b>Submitter:</b> Bo Persson <b>Opened:</b> 2007-08-27  <b>Last modified:</b> 2009-07-16</p>
17680<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#conversions.string">issues</a> in [conversions.string].</p>
17681<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
17682<p><b>Discussion:</b></p>
17683<p>
17684Paragraph 3 says that the <tt>Codecvt</tt> template parameter shall meet the 
17685requirements of <tt>std::codecvt</tt>, even though <tt>std::codecvt</tt> itself cannot 
17686be used (because of a protected destructor).
17687</p>
17688
17689<p>
17690How are we going to explain this code to beginning programmers?
17691</p>
17692
17693<blockquote><pre>template&lt;class I, class E, class S&gt;
17694struct codecvt : std::codecvt&lt;I, E, S&gt;
17695{
17696    ~codecvt()
17697    { }
17698};
17699
17700void main()
17701{
17702    std::wstring_convert&lt;codecvt&lt;wchar_t, char, std::mbstate_t&gt; &gt; compiles_ok;
17703    
17704    std::wstring_convert&lt;std::codecvt&lt;wchar_t, char, std::mbstate_t&gt; &gt;   not_ok;
17705}
17706</pre></blockquote>
17707
17708<p><i>[
17709San Francisco:
17710]</i></p>
17711
17712
17713<blockquote>
17714Bill will propose a resolution.
17715</blockquote>
17716
17717<p><i>[
177182009-07 Frankfurt:
17719]</i></p>
17720
17721
17722<blockquote>
17723<p>
17724codecvt isn't intended for beginning programmers. This is a regrettable
17725consequence of the original design of the facet.
17726</p>
17727<p>
17728Move to NAD.
17729</p>
17730</blockquote>
17731
17732
17733<p><b>Proposed resolution:</b></p>
17734<p>
17735</p>
17736
17737
17738
17739
17740
17741<hr>
17742<h3><a name="725"></a>725. Optional sequence container requirements column label</h3>
17743<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#NAD%20Editorial">NAD Editorial</a>
17744 <b>Submitter:</b> David Abrahams <b>Opened:</b> 2007-09-16  <b>Last modified:</b> 2008-09-22</p>
17745<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</p>
17746<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>
17747<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
17748<p><b>Discussion:</b></p>
17749<p>
17750Table 90: (Optional sequence container operations) states the
17751"assertion note pre/post-condition" of <tt>operator[]</tt> to be
17752</p>
17753
17754<blockquote><pre>*(a.begin() + n)
17755</pre></blockquote>
17756
17757<p>
17758Surely that's meant to be "operational semantics?"
17759</p>
17760
17761
17762
17763<p><b>Proposed resolution:</b></p>
17764<blockquote>
17765<table border="1">
17766<caption>Table 90: Optional sequence container operations</caption>
17767<tbody><tr>
17768<th>expression</th> <th>return type</th> <th><del>assertion/note<br>pre/post-condition</del><br> <ins>operational semantics</ins></th> <th>container</th>
17769</tr>
17770</tbody></table>
17771</blockquote>
17772
17773
17774
17775
17776
17777
17778<hr>
17779<h3><a name="729"></a>729. Problem in [rand.req.eng]/3</h3>
17780<p><b>Section:</b> X [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
17781 <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21  <b>Last modified:</b> 2008-02-27</p>
17782<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req.eng">issues</a> in [rand.req.eng].</p>
17783<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
17784<p><b>Discussion:</b></p>
17785<p>
17786The 3rd table row in X [rand.req.eng]/3 requires random number engines to accept any 
17787arithmetic type as a seed, which is then casted to the engine's <tt>result_type</tt> and subsequently 
17788used for seeding the state of the engine. The requirement stated as "Creates an engine with 
17789initial state determined by <tt>static_cast&lt;X::result_type&gt;(s)</tt>" forces random number engines 
17790to either use a seeding method that completely depends on the <tt>result_type</tt> (see the discussion 
17791of seeding for the <tt>mersenne_twister_engine</tt> in point T2 above) or at least to throw away "bits 
17792of randomness" in the seed value if the <tt>result_type</tt> is smaller than the seed type. This seems 
17793to be inappropriate for many modern random number generators, in particular F2-linear or 
17794cryptographic ones, which operate on an internal bit array that in principle is independent of the 
17795type of numbers returned.
17796</p>
17797
17798<p>
17799<b>Posible resolution:</b> I propose to change the wording to a version similar to "Creates an 
17800engine with initial state determined by <tt>static_cast&lt;UintType&gt;(s)</tt>, where <tt>UintType</tt> is an 
17801implementation specific unsigned integer type."
17802</p>
17803
17804<p>
17805Additionally, the definition of s in X [rand.req.eng]/1 c) could be restricted to unsigned integer types.
17806</p>
17807
17808<p>
17809Similarly, the type of the seed in X [rand.req.adapt]/3 e) could be left unspecified.
17810</p>
17811
17812<p>
17813See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
17814for further discussion.
17815</p>
17816
17817<p><i>[
17818Stephan Tolksdorf adds pre-Bellevue:
17819]</i></p>
17820
17821
17822<blockquote>
17823<p>
17824In reply to the discussion in
17825<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
17826regarding this issue:
17827</p>
17828<p>
17829The descriptions of all engines and engine adaptors given in sections
1783026.5.3 [rand.eng] and 26.5.4 [rand.adapt] already specify the concrete
17831types of the integer arguments for seeding. Hence, relaxing the general
17832requirement in X [rand.req.eng] would not affect portability and
17833reproducibility of the standard library. Furthermore, it is not clear to
17834me what exactly the guarantee "with initial state determined by
17835<tt>static_cast&lt;X::result_type&gt;(s)</tt>" is useful for. On the other hand,
17836relaxing the requirement would allow developers to implement  other
17837random number engines that do not have to cast all arithmetic seed
17838arguments to their result_types.
17839</p>
17840</blockquote>
17841
17842<p><i>[
17843Bellevue:
17844]</i></p>
17845
17846
17847<blockquote>
17848Propose close NAD for the reasons given in N2424.
17849</blockquote>
17850
17851
17852
17853
17854<p><b>Proposed resolution:</b></p>
17855<p>
17856See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
17857for further discussion.
17858</p>
17859
17860<p><i>[
17861Stephan Tolksdorf adds pre-Bellevue:
17862]</i></p>
17863
17864
17865<blockquote>
17866<p>
17867Change row 3 of table 105 "Random number engine requirements" in X [rand.req.eng]/3
17868</p>
17869
17870<blockquote>
17871Creates an engine with initial state determined by
17872<tt><del>static_cast&lt;X::result_type&gt;(</del>s<del>)</del></tt>
17873</blockquote>
17874
17875<p>
17876Similarly, change X [rand.req.adapt]/3 e)
17877</p>
17878
17879<blockquote>
17880When <tt>X::X</tt> is invoked with <del>an <tt>X::result_type</tt></del> value <tt>s</tt>
17881<ins>of arithmetic type (3.9.1)</ins>, ...
17882</blockquote>
17883
17884</blockquote>
17885
17886
17887
17888
17889
17890
17891<hr>
17892<h3><a name="730"></a>730. Comment on [rand.req.adapt]/3 e)</h3>
17893<p><b>Section:</b> X [rand.req.adapt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
17894 <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21  <b>Last modified:</b> 2008-02-27</p>
17895<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
17896<p><b>Discussion:</b></p>
17897<p>
17898If an engine adaptor is invoked with an argument of type <tt>seed_seq</tt>, then all base 
17899engines are specified to be seeded with this <tt>seed_seq</tt>. As <tt>seed_seq</tt>'s randomization method is 
17900qualified as constant, this procedure will ef fectively initialize all base engines with the same seed 
17901(though the resulting state might still dif fer to a certain degree if the engines are of different types). 
17902It is not clear whether this mode of operation is in general appropriate, hence -- as far as the 
17903stated requirements are of general nature and not just specific to the engine adaptors provided by 
17904the library -- it might be better to leave the behaviour unspecified, since the current definition of 
17905<tt>seed_seq</tt> does not allow for a generally satisfying specification.
17906</p>
17907
17908<p>
17909<b>Posssible resolution:</b> [As above]
17910</p>
17911
17912<p>
17913See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
17914for further discussion.
17915</p>
17916
17917<p><i>[
17918Bellevue:
17919]</i></p>
17920
17921
17922<blockquote>
17923Close NAD for the reasons given in N2424.
17924</blockquote>
17925
17926
17927
17928<p><b>Proposed resolution:</b></p>
17929<p>
17930See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
17931for the proposed resolution.
17932</p>
17933
17934
17935
17936
17937
17938<hr>
17939<h3><a name="731"></a>731. proposal for a customizable <tt>seed_seq</tt></h3>
17940<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#NAD">NAD</a>
17941 <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21  <b>Last modified:</b> 2008-02-27</p>
17942<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>
17943<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
17944<p><b>Discussion:</b></p>
17945<p>
17946The proper way to seed random number engines seems to be the most frequently 
17947discussed issue of the 26.5 [rand] proposal. While the new <tt>seed_seq</tt> approach is already rather 
17948general and probably sufficient for most situations, it is unlikely to be optimal in every case (one 
17949problem was pointed out in point T5 above). In some situations it might, for instance, be better to 
17950seed the state with a cryptographic generator. 
17951</p>
17952<p>
17953In my opinion this is a pretty strong argument for extending the standard with a simple facility to 
17954customize the seeding procedure. This could, for example, be done with the following minimal 
17955changes:
17956</p>
17957
17958<p>
17959<b>Possible resolution:</b>
17960</p>
17961
17962<ol type="a">
17963<li>
17964Turn the interface specification of 26.5.7.1 [rand.util.seedseq]/2 into a "SeedSeq" requirement, where the 
17965exact behaviour of the constructors and the randomize method are left unspecified and where the
17966const qualification for randomize is removed. Classes implementing this interface are additionally 
17967required to specialize the traits class in c).
17968</li>
17969<li>
17970Provide the class <tt>seed_seq</tt> as a default implementation of the SeedSeq interface.
17971</li>
17972<li>
17973<p>
17974Supplement the <tt>seed_seq</tt> with a traits class
17975</p>
17976<blockquote><pre>template &lt;typename T&gt; 
17977struct is_seed_seq { static const bool value = false; }
17978</pre></blockquote>
17979<p>and the specialization</p>
17980<blockquote><pre>template &lt;&gt; 
17981struct is_seed_seq&lt;seed_seq&gt; { static const bool value = true; }
17982</pre></blockquote>
17983<p>which users can supplement with further specializations.</p>
17984</li>
17985<li>
17986Change X [rand.req.eng]/1 d) to "q is an lvalue of a type that fulfils the SeedSeq requirements", and 
17987modify the constructors and seed methods in 26.5.3 [rand.eng] appropriately (the actual implementation 
17988could be done using the SFINAE technique).
17989</li>
17990</ol>
17991
17992<p><i>[
17993Bellevue:
17994]</i></p>
17995
17996
17997<blockquote>
17998See N2424. Close NAD but note that "conceptizing" the library may cause
17999this problem to be solved by that route.
18000</blockquote>
18001
18002
18003<p><b>Proposed resolution:</b></p>
18004<p>
18005See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
18006for the proposed resolution.
18007</p>
18008
18009
18010
18011
18012
18013<hr>
18014<h3><a name="732"></a>732. Defect in [rand.dist.samp.genpdf]</h3>
18015<p><b>Section:</b> X [rand.dist.samp.genpdf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
18016 <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21  <b>Last modified:</b> 2009-03-09</p>
18017<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.genpdf">issues</a> in [rand.dist.samp.genpdf].</p>
18018<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
18019<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a></p>
18020<p><b>Discussion:</b></p>
18021<p>
18022X [rand.dist.samp.genpdf] describes the interface for a distribution template that is 
18023meant to simulate random numbers from any general distribution given only the density and the 
18024support of the distribution. I'm not aware of any general purpose algorithm that would be capable 
18025of correctly and efficiently implementing the described functionality. From what I know, this is 
18026essentially an unsolved research problem. Existing algorithms either require more knowledge 
18027about the distribution and the problem domain or work only under very limited circumstances. 
18028Even the state of the art special purpose library UNU.RAN does not solve the problem in full 
18029generality, and in any case, testing and customer support for such a library feature would be a 
18030nightmare.
18031</p>
18032
18033<p>
18034<b>Possible resolution:</b> For these reasons, I propose to delete section X [rand.dist.samp.genpdf].
18035</p>
18036
18037<p><i>[
18038Bellevue:
18039]</i></p>
18040
18041
18042<blockquote>
18043<p>
18044Disagreement persists.
18045</p>
18046<p>
18047Objection to this issue is that this function takes a general functor.
18048The general approach would be to normalize this function, integrate it,
18049and take the inverse of the integral, which is not possible in general.
18050An example function is sin(1+n*x) -- for any spatial frequency that the
18051implementor chooses, there is a value of n that renders that choice
18052arbitrarily erroneous.
18053</p>
18054<p>
18055Correction: The formula above should instead read 1+sin(n*x).
18056</p>
18057<p>
18058Objector proposes the following possible compromise positions:
18059</p>
18060<ul>
18061<li>
18062rand.dist.samp.genpdf takes an number of points so that implementor need not guess.
18063</li>
18064<li>replace rand.disk.samp.genpdf with an extension to either or both
18065of the discrete functions to take arguments that take a functor and
18066number of points in place of the list of probabilities. Reference
18067issues 793 and 794.
18068</li>
18069</ul>
18070</blockquote>
18071
18072
18073
18074<p><b>Proposed resolution:</b></p>
18075<p>
18076See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2813.pdf">N2813</a>
18077for the proposed resolution.
18078</p>
18079
18080
18081<p><b>Rationale:</b></p>
18082Addressed by
18083<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
18084
18085
18086
18087
18088
18089<hr>
18090<h3><a name="733"></a>733. Comment on [rand.req.dist]/9</h3>
18091<p><b>Section:</b> X [rand.req.dist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
18092 <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21  <b>Last modified:</b> 2008-02-27</p>
18093<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
18094<p><b>Discussion:</b></p>
18095<p>
18096The requirement "P shall have a declaration of the form <tt>typedef X distribution_- 
18097type</tt>" effectively makes the use of inheritance for implementing distributions very inconvenient, 
18098because the child of a distribution class in general will not satisfy this requirement. In my opinion 
18099the benefits of having a typedef in the parameter class pointing back to the distribution class are 
18100not worth the hassle this requirement causes. [In my code base I never made use of the nested 
18101typedef but on several occasions could have profited from being able to use simple inheritance for 
18102the implementation of a distribution class.]
18103</p>
18104
18105<p>
18106<b>Proposed resolution:</b> I propose to drop this requirement.
18107</p>
18108
18109<p><i>[
18110Bellevue:
18111]</i></p>
18112
18113
18114<blockquote>
18115Close NAD for the reasons given in N2424. In practice it is not inconvenient to meet these requirements.
18116</blockquote>
18117
18118
18119
18120<p><b>Proposed resolution:</b></p>
18121<p>
18122See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
18123for the proposed resolution.
18124</p>
18125
18126
18127
18128
18129
18130<hr>
18131<h3><a name="735"></a>735. Unfortunate naming</h3>
18132<p><b>Section:</b> 26.5.8.2.2 [rand.dist.bern.bin], 26.5.8.2.4 [rand.dist.bern.negbin] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
18133 <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21  <b>Last modified:</b> 2008-02-27</p>
18134<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
18135<p><b>Discussion:</b></p>
18136<p>
18137In my opinion the choice of name for the <tt>t</tt> parameter of the <tt>binomial_distribution</tt>
18138is very unfortunate. In virtually every internet reference, book and software implementation 
18139this parameter is called <tt>n</tt> instead, see for example Wikipedia, Mathworld, Evans et al. (1993) 
18140Statistical Distributions, 2nd E., Wiley, p. 38, the R statistical computing language, p. 926, 
18141Mathematica and Matlab.
18142</p>
18143
18144<p>
18145Similarly, the choice of <tt>k</tt> for the parameter of the negative binomial distributions is rather unusual. 
18146The most common choice for the negative binomial distribution seems to be <tt>r</tt> instead.
18147</p>
18148
18149<p>
18150Choosing unusual names for the parameters causes confusion among users and makes the 
18151interface unnecessarily inconvenient to use.
18152</p>
18153
18154<p>
18155<b>Possible resolution:</b> For these reasons, I propose to change the name of the respective parameters
18156to <tt>n</tt> and <tt>r</tt>.
18157</p>
18158
18159<p><i>[
18160Bellevue:
18161]</i></p>
18162
18163
18164<blockquote>
18165In N2424. NAD It has been around for a while. It is hardly universal,
18166there is prior art, and this would confuse people.
18167</blockquote>
18168
18169
18170<p><b>Proposed resolution:</b></p>
18171<p>
18172See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
18173for the proposed resolution.
18174</p>
18175
18176
18177
18178
18179
18180<hr>
18181<h3><a name="736"></a>736. Comment on [rand.dist.samp.discrete]</h3>
18182<p><b>Section:</b> 26.5.8.5.1 [rand.dist.samp.discrete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
18183 <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21  <b>Last modified:</b> 2008-02-27</p>
18184<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.discrete">issues</a> in [rand.dist.samp.discrete].</p>
18185<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
18186<p><b>Discussion:</b></p>
18187<ol type="a">
18188<li>
18189The specification for <tt>discrete_distribution</tt> requires the member <tt>probabilities()</tt>
18190to return a vector of <i>standardized</i> probabilities, which forces the implementation every time to 
18191divide each probability by the sum of all probabilities, as the sum will in practice almost never be 
18192exactly 1.0. This is unnecessarily inef ficient as the implementation would otherwise not need to 
18193compute the standardized probabilities at all and could instead work with the non-standardized 
18194probabilities and the sum. If there was no standardization the user would just get back the 
18195probabilities that were previously supplied to the distribution object, which to me seems to be the 
18196more obvious solution.
18197</li>
18198<li>
18199The behaviour of <tt>discrete_distribution</tt> is not specified in case the number of given
18200probabilities is larger than the maximum number representable by the IntType.
18201</li>
18202</ol>
18203
18204<p>
18205<b>Possible resolution:</b> I propose to change the specification such that the non-standardized 
18206probabilities need to be returned and that an additional requirement is included for the number 
18207of probabilities to be smaller than the maximum of IntType.
18208</p>
18209
18210<p><i>[
18211Stephan Tolksdorf adds pre-Bellevue:
18212]</i></p>
18213
18214
18215<blockquote>
18216<p>
18217In reply to the discussion in 
18218<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
18219of this issue:
18220</p>
18221<p>
18222Rescaled floating-point parameter vectors can not be expected to compare
18223equal because of the limited precision of floating-point numbers.
18224My proposal would at least guarantee that a parameter
18225vector (of type double) passed into the distribution would compare equal
18226with the one returned by the <tt>probabilities()</tt> method. Furthermore, I do
18227not understand why "the changed requirement would lead to a significant
18228increase in the amount of state in the distribution object". A typical
18229implementation's state would increase by exactly one number: the sum of
18230all probabilities. The textual representation for serialization would
18231not need to grow at all. Finally, the proposed replacement "<tt>0 &lt; n &lt;=
18232numeric_limits&lt;IntType&gt;::max() + 1</tt>" makes the implementation
18233unnecessarily complicated, "<tt>0 &lt; n &lt;= numeric_limits&lt;IntType&gt;::max()</tt>"
18234would be better.
18235</p>
18236</blockquote>
18237
18238<p><i>[
18239Bellevue:
18240]</i></p>
18241
18242
18243<blockquote>
18244<p>
18245In N2424. We agree with the observation and the proposed resolution to
18246part b). We recommend the wording n &gt; 0 be replaced with 0 &lt; n
18247numeric_limits::max() + 1. However, we disagree with part a), as it
18248would interfere with the definition of parameters' equality. Further,
18249the changed requirement would lead to a significant increase in the
18250amount of state of the distribution object.
18251</p>
18252
18253<p>
18254As it stands now, it is convenient, and the changes proposed make it
18255much less so.
18256</p>
18257
18258<p>
18259NAD. Part a the current behavior is desirable. Part b, any constructor
18260can fail, but the rules under which it can fail do not need to be listed
18261here.
18262</p>
18263</blockquote>
18264
18265
18266<p><b>Proposed resolution:</b></p>
18267<p>
18268See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
18269for the proposed resolution.
18270</p>
18271
18272<p><i>[
18273Stephan Tolksdorf adds pre-Bellevue:
18274]</i></p>
18275
18276
18277<blockquote>
18278<p>
18279In 26.5.8.5.1 [rand.dist.samp.discrete]:
18280</p>
18281
18282<p>
18283Proposed wording a):
18284</p>
18285
18286<blockquote>
18287<p>
18288Changae in para. 2
18289</p>
18290
18291<blockquote>
18292Constructs a <tt>discrete_distribution</tt> object with <tt>n=1</tt> and <tt>p<sub>0</sub> <ins>= w<sub>0</sub></ins> = 1</tt>
18293</blockquote>
18294
18295<p>
18296and change in para. 5
18297</p>
18298
18299<blockquote>
18300<i>Returns:</i> A <tt>vector&lt;double&gt;</tt> whose <tt>size</tt> member returns <tt>n</tt> and whose
18301<tt>operator[]</tt> member returns <del><tt>p<sub>k</sub></tt></del>
18302<ins>the weight <tt>w<sub>k</sub></tt> as a double value</ins>
18303when invoked with argument <tt>k</tt> for <tt>k = 0,
18304..., n-1</tt>
18305</blockquote>
18306
18307</blockquote>
18308
18309<p>
18310Proposed wording b):
18311</p>
18312
18313<blockquote>
18314<p>
18315Change in para. 3:
18316</p>
18317
18318<blockquote>
18319If <tt>firstW == lastW</tt>, let the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist
18320of the single value <tt>w<sub>0</sub> = 1</tt>. Otherwise, <tt>[firstW,lastW)</tt> shall form a
18321sequence <tt>w</tt> of length <tt>n <del>&gt; 0</del></tt> 
18322<ins>such that <tt>0 &lt; n &lt;= numeric_limits&lt;IntType&gt;::max()</tt>,</ins>
18323and <tt>*firstW</tt> shall yield a value <tt>w<sub>0</sub></tt>
18324convertible to <tt>double</tt>. [<i>Note:</i> The values <tt>w<sub>k</sub></tt> are commonly known
18325as the weights . <i>-- end note</i>]
18326</blockquote>
18327
18328</blockquote>
18329
18330</blockquote>
18331
18332
18333
18334
18335
18336<hr>
18337<h3><a name="737"></a>737. Comment on [rand.dist.samp.pconst]</h3>
18338<p><b>Section:</b> 26.5.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
18339 <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21  <b>Last modified:</b> 2008-02-27</p>
18340<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p>
18341<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
18342<p><b>Discussion:</b></p>
18343<ol type="a">
18344<li>
18345The discussion in point T11 above regarding <tt>probabilities()</tt> similarly applies 
18346to the method <tt>densities()</tt> of <tt>piecewise_constant_distribution</tt>.
18347</li>
18348<li>
18349<p>
18350The design of the constructor
18351</p>
18352<blockquote><pre>template &lt;class InputIteratorB, class InputIteratorW&gt; 
18353piecewise_constant_distribution( InputIteratorB firstB, InputIteratorB lastB, 
18354                                 InputIteratorW firstW);
18355</pre></blockquote>
18356<p>
18357is unnecessarily unsafe, as there is no separate end-iterator given for the weights. I can't see 
18358any performance or convenience reasons that would justify the risks inherent in such a function 
18359interface, in particular the risk that input error might go unnoticed.
18360</p>
18361</li>
18362</ol>
18363
18364<p>
18365<b>Possible resolution:</b> I propose to add an <tt>InputIteratorW lastW</tt> argument to the interface.
18366</p>
18367
18368<p><i>[
18369Stephan Tolksdorf adds pre-Bellevue:
18370]</i></p>
18371
18372<blockquote>
18373In reply to the discussion in
18374<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
18375I'd like to make the same comments as for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>.
18376</blockquote>
18377
18378<p><i>[
18379Bellevue:
18380]</i></p>
18381
18382
18383<blockquote>
18384In N2424. There is already precedent elsewhere in the library. Follows existing convention. NAD.
18385</blockquote>
18386
18387
18388<p><b>Proposed resolution:</b></p>
18389<p>
18390See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
18391for the proposed resolution.
18392</p>
18393
18394<p><i>[
18395Stephan Tolksdorf adds pre-Bellevue:
18396]</i></p>
18397
18398
18399<blockquote>
18400<p>
18401In 26.5.8.5.2 [rand.dist.samp.pconst]:
18402</p>
18403
18404<p>
18405Proposed wording a)
18406</p>
18407
18408<blockquote>
18409<p>
18410Change in para. 2
18411</p>
18412<blockquote>
18413Constructs a <tt>piecewise_constant_distribution</tt> object with <tt>n = 1</tt>, <tt>p<sub>0</sub> <ins>= w<sub>0</sub></ins> = 1</tt>,
18414<tt>b<sub>0</sub> = 0</tt>, and <tt>b<sub>1</sub> = 1</tt>
18415</blockquote>
18416
18417<p>
18418and change in para. 5
18419</p>
18420
18421<blockquote>
18422A <tt>vector&lt;result_type&gt;</tt> whose <tt>size</tt> member returns <tt>n</tt> and whose <tt>operator[]</tt>
18423member returns <del><tt>p<sub>k</sub></tt></del>
18424<ins>the weight <tt>w<sub>k</sub></tt> as a double value</ins>
18425when invoked with argument <tt>k</tt> for <tt>k = 0, ..., n-1</tt>
18426</blockquote>
18427
18428</blockquote>
18429
18430<p>
18431Proposed wording b)
18432</p>
18433
18434<blockquote>
18435<p>
18436Change both occurrences of
18437</p>
18438
18439<blockquote>
18440"piecewise_constant_distribution(InputIteratorB firstB, InputIteratorB lastB,
18441                                 InputIteratorW firstW<ins>, InputIteratorW lastW</ins>)
18442</blockquote>
18443
18444<p>
18445and change in para. 3
18446</p>
18447
18448<blockquote>
18449<del>the length of the sequence <tt>w</tt> starting from <tt>firstW</tt> shall be at least <tt>n</tt>,
18450<tt>*firstW</tt> shall return a value <tt>w<sub>0</sub></tt> that is convertible to <tt>double</tt>, and any
18451<tt>w<sub>k</sub></tt> for <tt>k &gt;= n</tt> shall be ignored by the distribution</del>
18452<ins><tt>[firstW, lastW)</tt> shall form a sequence <tt>w</tt> of length <tt>n</tt> whose leading element
18453<tt>w<sub>0</sub></tt> shall be convertible to <tt>double</tt></ins>
18454</blockquote>
18455
18456</blockquote>
18457
18458
18459</blockquote>
18460
18461
18462
18463
18464
18465
18466<hr>
18467<h3><a name="738"></a>738. Editorial issue in [rand.adapt.disc]/3</h3>
18468<p><b>Section:</b> 26.5.4.1 [rand.adapt.disc] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
18469 <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21  <b>Last modified:</b> 2008-09-22</p>
18470<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
18471<p><b>Discussion:</b></p>
18472<p>
18473Since the template parameter <tt>p</tt> and <tt>r</tt> are of type <tt>size_t</tt>, the member <tt>n</tt> in the class 
18474exposition should have type <tt>size_t</tt>, too.
18475</p>
18476
18477
18478<p><b>Proposed resolution:</b></p>
18479<p>
18480See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
18481for the proposed resolution.
18482</p>
18483
18484
18485
18486
18487
18488<hr>
18489<h3><a name="739"></a>739. Defect in [rand.util.canonical]/3</h3>
18490<p><b>Section:</b> 26.5.7.2 [rand.util.canonical] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
18491 <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2007-09-21  <b>Last modified:</b> 2008-02-27</p>
18492<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.canonical">issues</a> in [rand.util.canonical].</p>
18493<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
18494<p><b>Discussion:</b></p>
18495<p>
18496The complexity of <tt>generate_canonical</tt> is specified to be "exactly k=max(1, ceil(b/log2 
18497R)) invocations of g". This terms involves a logarithm that is not rounded and hence can not (in 
18498general) be computed at compile time. As this function template is performance critical, I propose 
18499to replace ceil(b/log2 R) with ceil(b/floor(log2 R)).
18500</p>
18501
18502<p>
18503See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
18504for further discussion.
18505</p>
18506
18507<p><i>[
18508Bellevue:
18509]</i></p>
18510
18511
18512<blockquote>
18513In N2424. Close NAD as described there.
18514</blockquote>
18515
18516
18517
18518<p><b>Proposed resolution:</b></p>
18519<p>
18520See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
18521for the proposed resolution.
18522</p>
18523
18524
18525
18526
18527
18528<hr>
18529<h3><a name="741"></a>741. Const-incorrect <tt>get_deleter</tt> function for <tt>shared_ptr</tt></h3>
18530<p><b>Section:</b> 20.8.15.2.11 [util.smartptr.getdeleter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
18531 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-09-27  <b>Last modified:</b> 2008-02-27</p>
18532<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.getdeleter">issues</a> in [util.smartptr.getdeleter].</p>
18533<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
18534<p><b>Discussion:</b></p>
18535<p>
18536The following issue was raised by Alf P. Steinbach in c.l.c++.mod:
18537</p>
18538
18539<p>
18540According to the recent draft N2369, both the header memory synopsis
18541of 20.8 [memory] and 20.8.15.2.11 [util.smartptr.getdeleter] declare:
18542</p>
18543
18544<blockquote><pre>template&lt;class D, class T&gt; D* get_deleter(shared_ptr&lt;T&gt; const&amp; p);
18545</pre></blockquote>
18546
18547<p>
18548This allows to retrieve the pointer to a mutable deleter of a <tt>const
18549shared_ptr</tt> (if that owns one) and therefore contradicts the usual
18550philosophy that associated functors are either read-only (e.g.
18551<tt>key_comp</tt> or <tt>value_comp</tt> of <tt>std::map</tt>) or do at least reflect
18552the mutability of the owner (as seen for the both overloads of
18553<tt>unique_ptr::get_deleter</tt>).
18554Even the next similar counter-part of <tt>get_deleter</tt> - the two
18555overloads of <tt>function::target</tt> in the class template function
18556synopsis 20.7.15.2 [func.wrap.func] or in 20.7.15.2.5 [func.wrap.func.targ] - do
18557properly mirror the const-state of the owner.
18558</p>
18559
18560<b>Possible proposed resolutions:</b>
18561
18562<p>
18563Replace the declarations of <tt>get_deleter</tt> in the header <tt>&lt;memory&gt;</tt>
18564synopsis of 20.8 [memory] and in 20.8.15.2.11 [util.smartptr.getdeleter] by one of the
18565following alternatives (A) or (B):
18566</p>
18567
18568<ol type="A">
18569<li>
18570Provide <b>only</b> the immutable variant. This would reflect the
18571current praxis of <tt>container::get_allocator()</tt>, <tt>map::key_comp()</tt>, or
18572<tt>map::value_comp</tt>.
18573
18574<blockquote><pre>template&lt;class D, class T&gt; const D* get_deleter(shared_ptr&lt;T&gt; const&amp; p);
18575</pre></blockquote>
18576</li>
18577<li>
18578Just remove the function.
18579</li>
18580</ol>
18581
18582<p>
18583Alberto Ganesh Barbati adds:
18584</p>
18585
18586<ol start="3" type="A">
18587<li>
18588<p>
18589Replace it with two functions:
18590</p>
18591<blockquote><pre>template &lt;class D, class T&gt; D get_deleter(shared_ptr&lt;T&gt; const&amp;);
18592template &lt;class D, class T&gt; bool has_deleter(shared_ptr&lt;T&gt; const&amp;);
18593</pre></blockquote>
18594
18595<p>
18596The first one would throw if <tt>D</tt> is the wrong type, while the latter would
18597never throw. This approach would reflect the current praxis of
18598<tt>use_facet/has_facet</tt>, with the twist of returning the deleter by value as
18599<tt>container::get_allocator()</tt> do.
18600</p>
18601</li>
18602</ol>
18603
18604<p>
18605Peter Dimov adds:
18606</p>
18607
18608<blockquote>
18609<p>
18610My favorite option is "not a defect". A, B and C break useful code.
18611</p>
18612</blockquote>
18613
18614<p><i>[
18615Bellevue:
18616]</i></p>
18617
18618
18619<blockquote>
18620Concern this is similar to confusing "pointer to const" with "a constant pointer".
18621</blockquote>
18622
18623
18624<p><b>Proposed resolution:</b></p>
18625<p>
18626</p>
18627
18628
18629
18630
18631
18632<hr>
18633<h3><a name="745"></a>745. copy_exception API slices.</h3>
18634<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#NAD">NAD</a>
18635 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10  <b>Last modified:</b> 2008-02-25</p>
18636<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>
18637<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>
18638<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
18639<p><b>Discussion:</b></p>
18640<p>
18641It could be I did not understand the design rationale, but I thought
18642copy_exception would produce an exception_ptr to the most-derived (dynamic)
18643type of the passed exception.  Instead it slices, which appears to be less
18644useful, and a likely source of FAQ questions in the future.
18645</p>
18646<p>
18647(Peter Dimov suggests NAD)
18648</p>
18649
18650<p><i>[
18651Bellevue: 
18652]</i></p>
18653
18654
18655<blockquote>
18656<p>
18657How could this be implemented in a way that the dynamic type is cloned?
18658</p>
18659<p>
18660The feature is designed to create an exception_ptr from an object whose
18661static type is identical to the dynamic type and thus there is no
18662slicing involved.
18663</p>
18664</blockquote>
18665
18666
18667<p><b>Proposed resolution:</b></p>
18668<p>
18669</p>
18670
18671
18672
18673
18674
18675<hr>
18676<h3><a name="747"></a>747. We have 3 separate type traits to identify classes supporting no-throw operations</h3>
18677<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#NAD">NAD</a>
18678 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10  <b>Last modified:</b> 2009-07-16</p>
18679<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>
18680<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>
18681<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
18682<p><b>Discussion:</b></p>
18683<p>
18684We have 3 separate type traits to identify classes supporting no-throw
18685operations, which are very useful when trying to provide exception safety
18686guarantees.  However, I'm not entirely clear on what the current wording
18687requires of a conforming implementation.  To quote from
18688<tt>has_nothrow_default_constructor</tt>:
18689</p>
18690<blockquote><p>
18691or <tt>T</tt> is a class type with a default constructor that is known not to throw
18692any exceptions
18693</p></blockquote>
18694<p>
18695What level of magic do we expect to deduce if this is known?
18696</p>
18697<p>
18698E.g.
18699</p>
18700
18701<blockquote><pre>struct test{
18702 int x;
18703 test() : x() {}
18704};
18705</pre></blockquote>
18706<p>
18707Should I expect a conforming compiler to 
18708 <tt>assert( has_nothrow_constructor&lt;test&gt;::value )</tt>
18709</p>
18710<p>
18711Is this a QoI issue?
18712</p>
18713<p>
18714Should I expect to 'know' only if-and-only-if there is an inline definition
18715available?
18716</p>
18717<p>
18718Should I never expect that to be true, and insist that the user supplies an
18719empty throw spec if they want to assert the no-throw guarantee?
18720</p>
18721<p>
18722It would be helpful to maybe have a footnote explaining what is required,
18723but right now I don't know what to suggest putting in the footnote.
18724</p>
18725<p>
18726(agreement since is that trivial ops and explicit no-throws are required.
18727Open if QoI should be allowed to detect further)
18728</p>
18729
18730<p><i>[
18731Bellevue:
18732]</i></p>
18733
18734
18735<blockquote>
18736This looks like a QoI issue.
18737In the case of trivial and nothrow it is known. Static analysis of the program is definitely into QoI.
18738Move to OPEN. Need to talk to Core about this.
18739</blockquote>
18740
18741<p><i>[
187422009-07 Frankfurt:
18743]</i></p>
18744
18745
18746<blockquote>
18747<p>
18748This is QoI.
18749</p>
18750<p>
18751Move to NAD.
18752</p>
18753</blockquote>
18754
18755
18756<p><b>Proposed resolution:</b></p>
18757<p>
18758</p>
18759
18760
18761
18762
18763
18764<hr>
18765<h3><a name="748"></a>748. The is_abstract type trait is defined by reference to 10.4.</h3>
18766<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#NAD">NAD</a>
18767 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10  <b>Last modified:</b> 2009-05-01</p>
18768<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>
18769<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>
18770<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
18771<p><b>Discussion:</b></p>
18772<p>
18773I am trying to decide is a pure virtual function is a <i>necessary</i> as well as
18774sufficient requirement to be classified as abstract?
18775</p>
18776<p>
18777For instance, is the following (non-polymorphic) type considered abstract?
18778</p>
18779<blockquote><pre>struct abstract {
18780protected:
18781 abstract(){}
18782 abstract( abstract const &amp; ) {}
18783 ~abstract() {}
18784};
18785</pre></blockquote>
18786<p>
18787(Suggested that this may be NAD, with an editorial fix-up from Pete on the
18788core wording to make clear that abstract requires a pure virtual function)
18789</p>
18790
18791
18792<p><b>Proposed resolution:</b></p>
18793<p>
18794Core has clarified that the definition abstract is adequate. Issue withdrawn by submitter. NAD.
18795</p>
18796
18797
18798
18799
18800
18801<hr>
18802<h3><a name="750"></a>750. The current definition for <tt>is_convertible</tt> requires that the type be
18803implicitly convertible, so explicit constructors are ignored.</h3>
18804<p><b>Section:</b> 20.6.5 [meta.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
18805 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10  <b>Last modified:</b> 2009-09-13</p>
18806<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.rel">issues</a> in [meta.rel].</p>
18807<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
18808<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#719">719</a></p>
18809<p><b>Discussion:</b></p>
18810<p>
18811With the pending arrival of explicit conversion functions though, I'm
18812wondering if we want an additional trait, <tt>is_explictly_convertible</tt>?
18813</p>
18814
18815<p><i>[
18816Bellevue:
18817]</i></p>
18818
18819
18820<blockquote>
18821Alisdair is considering preparing a paper listing a number of missing
18822type traits, and feels that it might be useful to handle them all
18823together rather than piecemeal. This would affect issue 719 and 750.
18824These two issues should move to OPEN pending AM paper on type traits.
18825</blockquote>
18826
18827<p><i>[
188282009-07 Frankfurt:
18829]</i></p>
18830
18831
18832<blockquote>
18833Duplicate of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#719">719</a> (for our purposes).
18834</blockquote>
18835
18836<p><i>[
18837Addressed in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2947.html">N2947</a>.
18838]</i></p>
18839
18840
18841
18842
18843<p><b>Proposed resolution:</b></p>
18844
18845
18846
18847
18848
18849
18850<hr>
18851<h3><a name="751"></a>751. change pass-by-reference members of <tt>vector&lt;bool&gt;</tt> to pass-by-value?</h3>
18852<p><b>Section:</b> 23.3.7 [vector.bool] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
18853 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2007-10-10  <b>Last modified:</b> 2009-07-16</p>
18854<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.bool">issues</a> in [vector.bool].</p>
18855<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
18856<p><b>Discussion:</b></p>
18857<p>
18858A number of vector&lt;bool&gt; members take const bool&amp; as arguments.
18859Is there any chance we could change them to pass-by-value or would I 
18860be wasting everyone's time if wrote up an issue?
18861</p>
18862
18863<p><i>[
18864post Bellevue:
18865]</i></p>
18866
18867
18868<blockquote>
18869<p>
18870As we understand it, the original requester (Martin Sebor) would like
18871for implementations to be permitted to pass-by-value. Alisdair suggests
18872that if this is to be resolved, it should be resolved more generally,
18873e.g. in other containers as well.
18874</p>
18875<p>
18876We note that this would break ABI. However, we also suspect that this
18877might be covered under the "as-if" rule in section 1.9.
18878</p>
18879<p>
18880Many in the group feel that for vector&lt;bool&gt;, this is a "don't care",
18881and that at this point in the process it's not worth the bandwidth.
18882</p>
18883<p>
18884Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a> -- which was in ready status pre-Bellevue and is
18885now in the working paper -- is related to this, though not a duplicate.
18886</p>
18887<p>
18888Moving to Open with a task for Alisdair to craft a informative note to
18889be put whereever appropriate in the WP. This note would clarify places
18890where pass-by-const-ref can be transformed to pass-by-value under the
18891as-if rule.
18892</p>
18893</blockquote>
18894
18895<p><i>[
18896San Francisco:
18897]</i></p>
18898
18899
18900<blockquote>
18901<p>
18902This is really a clause 17 issue, rather than something specific to vector&lt;bool&gt;.
18903</p>
18904<p>
18905Move to Open. Alisdair to provide a resolution. Alternately, Howard can
18906close this as NAD and then open a new issue to handle the general issue
18907(rather than the vector&lt;bool&gt; one).
18908</p>
18909<p>
18910Howard:  Haven't yet opened new issue.  Lacking wording for it.
18911</p>
18912</blockquote>
18913
18914<p><i>[
189152009-07 Frankfurt:
18916]</i></p>
18917
18918
18919<blockquote>
18920NAD.  Insufficient motivation to make any changes.
18921</blockquote>
18922
18923
18924<p><b>Proposed resolution:</b></p>
18925<p>
18926</p>
18927
18928
18929
18930
18931
18932<hr>
18933<h3><a name="754"></a>754. Ambiguous return clause for <tt>std::uninitialized_copy</tt></h3>
18934<p><b>Section:</b> 20.8.13.2 [uninitialized.copy] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
18935 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2007-10-15  <b>Last modified:</b> 2008-07-02</p>
18936<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#uninitialized.copy">issues</a> in [uninitialized.copy].</p>
18937<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
18938<p><b>Discussion:</b></p>
18939<p>
1894014882-2003, [lib.uninitialized.copy] is currently written as follows:
18941</p>
18942
18943<blockquote>
18944<pre>template &lt;class InputIterator, class ForwardIterator&gt;
18945  ForwardIterator uninitialized_copy(InputIterator <i>first</i>, InputIterator <i>last</i>,
18946                                     ForwardIterator <i>result</i>);
18947</pre>
18948<blockquote>
18949<p>
18950-1- <i>Effects:</i>
18951</p>
18952<blockquote><pre>for (; first != last; ++result, ++first)
18953  new (static_cast&lt;void*&gt;(&amp;*result))
18954    typename iterator_traits&lt;ForwardIterator&gt;::value_type(*first);
18955</pre></blockquote>
18956<p>
18957-2- <i>Returns:</i> <tt><i>result</i></tt>
18958</p>
18959</blockquote>
18960</blockquote>
18961
18962<p>
18963similarily for N2369, and its corresponding section
1896420.8.13.2 [uninitialized.copy].
18965</p>
18966
18967<p>
18968It's not clear to me what the return clause is supposed to mean, I see
18969two
18970possible interpretations:
18971</p>
18972
18973<ol type="a">
18974<li>
18975The notion of <tt><i>result</i></tt> is supposed to mean the value given by the
18976function parameter <tt><i>result</i></tt> [Note to the issue editor: Please use italics for
18977<tt><i>result</i></tt>].
18978This seems somewhat implied by recognizing that both the function
18979parameter
18980and the name used in the clause do have the same italic font.
18981</li>
18982<li>
18983The notion of "result" is supposed to mean the value of <tt><i>result</i></tt>
18984after the
18985preceding effects clause. This is in fact what all implementations I
18986checked
18987do (and which is probably it's intend, because it matches the
18988specification of <tt>std::copy</tt>).
18989</li>
18990</ol>
18991
18992<p>
18993The problem is: I see nothing in the standard which grants that this
18994interpretation
18995is correct, specifically [lib.structure.specifications] or
1899617.5.1.4 [structure.specifications]
18997resp. do not clarify which "look-up" rules apply for names found in
18998the elements
18999of the detailed specifications - Do they relate to the corresponding
19000synopsis or
19001to the effects clause (or possibly other elements)? Fortunately most
19002detailed
19003descriptions are unambigious in this regard, e.g. this problem does
19004not apply
19005for <tt>std::copy</tt>.
19006</p>
19007
19008
19009
19010<p><b>Proposed resolution:</b></p>
19011<p>
19012Change the wording of the return clause to say (20.8.13.2 [uninitialized.copy]):
19013</p>
19014
19015<blockquote>
19016<p>
19017-2- <i>Returns:</i> <ins>The value of</ins> <tt><i>result</i></tt> <ins>after effects have taken place.</ins>
19018</p>
19019</blockquote>
19020
19021
19022<p><i>[
19023Bellevue:
19024]</i></p>
19025
19026
19027<blockquote>
19028Resolution: NAD editorial -- project editor to decide if change is
19029worthwhile. Concern is that there are many other places this might
19030occur.
19031</blockquote>
19032
19033
19034
19035
19036<hr>
19037<h3><a name="756"></a>756. Container adaptors push</h3>
19038<p><b>Section:</b> 23.3.5 [container.adaptors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
19039 <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2007-10-31  <b>Last modified:</b> 2008-06-18</p>
19040<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.adaptors">active issues</a> in [container.adaptors].</p>
19041<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.adaptors">issues</a> in [container.adaptors].</p>
19042<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
19043<p><b>Discussion:</b></p>
19044<p>
19045After n2369 we have a single <tt>push_back</tt> overload in the sequence containers,
19046of the "emplace" type. At variance with that, still in n2461, we have
19047two separate overloads, the C++03 one + one taking an rvalue reference
19048in the container adaptors. Therefore, simply from a consistency point of
19049view, I was wondering whether the container adaptors should be aligned
19050with the specifications of the sequence container themselves: thus have
19051a single <tt>push</tt> along the lines:
19052</p>
19053
19054<blockquote><pre>template&lt;typename... _Args&gt;
19055void
19056push(_Args&amp;&amp;... __args)
19057  { c.push_back(std::forward&lt;_Args&gt;(__args)...); }
19058</pre></blockquote>
19059
19060<p><i>[
19061Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>
19062]</i></p>
19063
19064
19065
19066<p><b>Proposed resolution:</b></p>
19067<p>
19068Change 23.3.5.1.1 [queue.defn]:
19069</p>
19070
19071<blockquote><pre><del>void push(const value_type&amp; x) { c.push_back(x); }</del>
19072<del>void push(value_type&amp;&amp; x) { c.push_back(std::move(x)); }</del>
19073<ins>template&lt;class... Args&gt; void push(Args&amp;&amp;... args) { c.push_back(std::forward&lt;Args&gt;(args)...); }</ins>
19074</pre></blockquote>
19075
19076<p>
19077Change 23.3.5.2 [priority.queue]:
19078</p>
19079
19080<blockquote><pre><del>void push(const value_type&amp; x) { c.push_back(x); }</del>
19081<del>void push(value_type&amp;&amp; x) { c.push_back(std::move(x)); }</del>
19082<ins>template&lt;class... Args&gt; void push(Args&amp;&amp;... args) { c.push_back(std::forward&lt;Args&gt;(args)...); }</ins>
19083</pre></blockquote>
19084
19085<p>
19086Change 23.3.5.2.2 [priqueue.members]:
19087</p>
19088
19089<blockquote>
19090<pre><del>void push(const value_type&amp; x);</del>
19091</pre>
19092<blockquote>
19093<p>
19094<del><i>Effects:</i></del>
19095</p>
19096<blockquote><pre><del>c.push_back(x);</del>
19097<del>push_heap(c.begin(), c.end(), comp);</del>
19098</pre></blockquote>
19099</blockquote>
19100
19101<pre><ins>template&lt;class... Args&gt;</ins> void push(<del>value_type</del> <ins>Args</ins>&amp;&amp;<ins>...</ins> <del>x</del> <ins>args</ins>);
19102</pre>
19103<blockquote>
19104<p>
19105<i>Effects:</i>
19106</p>
19107<blockquote><pre>c.push_back(std::<del>move</del><ins>forward&lt;Args&gt;</ins>(<del>x</del> <ins>args</ins>)<ins>...</ins>);
19108push_heap(c.begin(), c.end(), comp);
19109</pre></blockquote>
19110</blockquote>
19111</blockquote>
19112
19113<p>
19114Change 23.3.5.3.1 [stack.defn]:
19115</p>
19116
19117<blockquote><pre><del>void push(const value_type&amp; x) { c.push_back(x); }</del>
19118<del>void push(value_type&amp;&amp; x) { c.push_back(std::move(x)); }</del>
19119<ins>template&lt;class... Args&gt; void push(Args&amp;&amp;... args) { c.push_back(std::forward&lt;Args&gt;(args)...); }</ins>
19120</pre></blockquote>
19121
19122
19123
19124<p><b>Rationale:</b></p>
19125<p>
19126Addressed by
19127<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2680.pdf">N2680 Proposed Wording for Placement Insert (Revision 1)</a>.
19128</p>
19129
19130
19131
19132
19133
19134<hr>
19135<h3><a name="757"></a>757. Typo in the synopsis of vector</h3>
19136<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#NAD%20Editorial">NAD Editorial</a>
19137 <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2007-11-04  <b>Last modified:</b> 2008-07-02</p>
19138<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>
19139<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
19140<p><b>Discussion:</b></p>
19141<p>
19142In the synopsis 23.3.6 [vector], there is the signature:
19143</p>
19144
19145<blockquote><pre>void insert(const_iterator position, size_type n, T&amp;&amp; x);
19146</pre></blockquote>
19147
19148<p>
19149instead of:
19150</p>
19151
19152<blockquote><pre>iterator insert(const_iterator position, T&amp;&amp; x);
19153</pre></blockquote>
19154
19155<p>
1915623.3.6.4 [vector.modifiers] is fine.
19157</p>
19158
19159
19160
19161<p><b>Proposed resolution:</b></p>
19162<p>
19163Change the synopsis in 23.3.6 [vector]:
19164</p>
19165
19166<blockquote><pre>iterator insert(const_iterator position, const T&amp; x); 
19167<ins>iterator insert(const_iterator position, T&amp;&amp; x);</ins>
19168void     insert(const_iterator position, size_type n, const T&amp; x); 
19169<del>void     insert(const_iterator position, size_type n, T&amp;&amp; x);</del>
19170</pre></blockquote>
19171
19172
19173
19174
19175
19176<hr>
19177<h3><a name="760"></a>760. The emplace issue</h3>
19178<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#NAD%20Future">NAD Future</a>
19179 <b>Submitter:</b> Paolo Carlini <b>Opened:</b> 2007-11-11  <b>Last modified:</b> 2009-07-17</p>
19180<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>
19181<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>
19182<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
19183<p><b>Discussion:</b></p>
19184<p>
19185In an emplace member function the function parameter pack may be bound
19186to a priori unlimited number of objects: some or all of them can be
19187elements of the container itself. Apparently, in order to conform to the
19188blanket statement 23.2 [container.requirements]/11, the
19189implementation must check all of them for that possibility. A possible
19190solution can involve extending the exception in 23.2 [container.requirements]/12 also to the emplace member. As a
19191side note, the <tt>push_back</tt> and <tt>push_front</tt> member
19192functions are luckily not affected by this problem, can be efficiently
19193implemented anyway
19194</p>
19195
19196<p><i>[
19197Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>
19198]</i></p>
19199
19200
19201<p><i>[
19202Bellevue:
19203]</i></p>
19204
19205
19206<blockquote>
19207<p>
19208The proposed addition (13) is partially redundant with the existing
19209paragraph 12. Why was the qualifier "rvalues" added to paragraph 12? Why
19210does it not cover subelements and pointers?
19211</p>
19212<p>
19213Resolution: Alan Talbot to rework language, then set state to Review.
19214</p>
19215</blockquote>
19216
19217<p><i>[
192182009-07 Frankfurt
19219]</i></p>
19220
19221
19222<blockquote>
19223<p>
19224The problem is broader than emplace. The LWG doesn't
19225feel that it knows how to write wording that prohibits all of the
19226problematic use cases at this time.
19227</p>
19228<p>
19229NAD Future.
19230</p>
19231</blockquote>
19232
19233
19234
19235<p><b>Proposed resolution:</b></p>
19236<p>
19237Add after 23.2 [container.requirements]/12:
19238</p>
19239
19240<blockquote>
19241<p>
19242-12- Objects passed to member functions of a container as rvalue
19243references shall not be elements of that container. No diagnostic
19244required.
19245</p>
19246<p>
19247<ins>
19248-13- Objects bound to the function parameter pack of the
19249<tt>emplace</tt> member function shall not be elements or sub-objects of
19250elements of the container. No diagnostic required.
19251</ins>
19252</p>
19253
19254</blockquote>
19255
19256
19257
19258
19259
19260
19261<hr>
19262<h3><a name="763"></a>763. Renaming <tt>emplace()</tt> overloads</h3>
19263<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#NAD">NAD</a>
19264 <b>Submitter:</b> Sylvain Pion <b>Opened:</b> 2007-12-04  <b>Last modified:</b> 2008-03-12</p>
19265<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
19266<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>
19267<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
19268<p><b>Discussion:</b></p>
19269<p>
19270The associative containers provide 2 overloads of <tt>emplace()</tt>:
19271</p>
19272
19273<blockquote><pre>template &lt;class... Args&gt; pair&lt;iterator, bool&gt; emplace(Args&amp;&amp;... args);
19274template &lt;class... Args&gt; iterator emplace(const_iterator position, Args&amp;&amp;... args);
19275</pre></blockquote>
19276
19277<p>
19278This is a problem if you mean the first overload while passing
19279a <tt>const_iterator</tt> as first argument.
19280</p>
19281
19282<p><i>[
19283Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>
19284]</i></p>
19285
19286
19287<p><i>[
19288Bellevue:
19289]</i></p>
19290
19291
19292<blockquote>
19293</blockquote>
19294<p>
19295This can be disambiguated by passing "begin" as the first argument in
19296the case when the non-default choice is desired. We believe that desire
19297will be rare.
19298</p>
19299<p>
19300Resolution: Change state to NAD.
19301</p>
19302
19303
19304<p><b>Proposed resolution:</b></p>
19305<p>
19306Rename one of the two overloads.
19307For example to <tt>emplace_here</tt>, <tt>hint_emplace</tt>...
19308</p>
19309
19310
19311
19312
19313
19314<hr>
19315<h3><a name="764"></a>764. <tt>equal_range</tt> on unordered containers should return a <tt>pair</tt> of <tt>local_iterators</tt></h3>
19316<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#NAD">NAD</a>
19317 <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2007-11-29  <b>Last modified:</b> 2008-03-12</p>
19318<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>
19319<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>
19320<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
19321<p><b>Discussion:</b></p>
19322<p>
19323    A major attribute of the unordered containers is that iterating 
19324though them inside a bucket is very fast while iterating between buckets 
19325can be much slower.  If an unordered container has a low load factor, 
19326iterating between the last iterator in one bucket and the next iterator, 
19327which is in another bucket, is <tt>O(bucket_count())</tt> which may be much 
19328larger than <tt>O(size())</tt>.
19329</p>
19330<p>
19331    If <tt>b</tt> is an non-const unordered container of type <tt>B</tt> and <tt>k</tt> is an 
19332object of it's <tt>key_type</tt>, then <tt>b.equal_range(k)</tt> currently returns 
19333<tt>pair&lt;B::iterator, B::iterator&gt;</tt>. Consider the following code:
19334</p>
19335
19336<blockquote><pre>B::iterator lb, ub;
19337tie(lb, ub) = b.equal_range(k);
19338for (B::iterator it = lb; it != ub; ++it) {
19339        // Do something with *it
19340}
19341</pre></blockquote>
19342
19343<p>
19344If <tt>b.equal_range(k)</tt> returns a non-empty range (i.e. <tt>b</tt> contains at least 
19345on element whose key is equivalent to <tt>k</tt>), then every iterator in the 
19346half-open range <tt>[lb, ub)</tt> will be in the same bucket, but <tt>ub</tt> will likely 
19347either be in a different bucket or be equal to <tt>b.end()</tt>.  In either case, 
19348iterating between <tt>ub - 1</tt> and <tt>ub</tt> could take a much longer time than 
19349iterating through the rest of the range.
19350</p>
19351<p>
19352If instead of returning <tt>pair&lt;iterator, iterator&gt;</tt>, <tt>equal_range</tt> were to 
19353return <tt>pair&lt;local_iterator, local_iterator&gt;</tt>, then <tt>ub</tt> (which, like <tt>lb</tt>, 
19354would now be a <tt>local_iterator</tt>) could be guaranteed to always be in the 
19355same bucket as <tt>lb</tt>. In the cases where currently <tt>ub</tt> is equal to <tt>b.end()</tt>
19356or is in a different bucket, <tt>ub</tt> would be equal to <tt>b.end(b.bucket(key))</tt>. 
19357  This would make iterating between <tt>lb</tt> and <tt>ub</tt> much faster, as every 
19358iteration would be constant time.
19359</p>
19360
19361<p><i>[
19362Bellevue:
19363]</i></p>
19364
19365
19366<blockquote>
19367The proposed resolution breaks consistency with other container types
19368for dubious benefit, and iterators are already constant time.
19369</blockquote>
19370
19371
19372
19373<p><b>Proposed resolution:</b></p>
19374<p>
19375Change the entry for <tt>equal_range</tt> in Table 93 (23.2.5 [unord.req]) as follows:
19376</p>
19377<table border="1">
19378<tbody><tr>
19379<th>expression</th> <th>return type</th> <th>assertion/note pre/post-condition</th> <th>complexity</th>
19380</tr>
19381
19382<tr>
19383<td><tt>b.equal_range(k)</tt></td>
19384<td><tt>pair&lt;<ins>local_</ins>iterator,<ins>local_</ins>iterator&gt;; pair&lt;const_<ins>local_</ins>iterator,const_<ins>local_</ins>iterator&gt;</tt> for <tt>const b</tt>.</td>
19385<td>Returns a range containing all elements with keys equivalent to <tt>k</tt>. Returns <tt>make_pair(b.end(<ins>b.bucket(key)</ins>),b.end(<ins>b.bucket(key)</ins>))</tt> if no such elements exist.</td>
19386<td>Average case &#920;<tt>(b.count(k))</tt>. Worst case &#920;<tt>(b.size())</tt>. </td>
19387</tr>
19388</tbody></table>
19389
19390
19391
19392
19393
19394<hr>
19395<h3><a name="767"></a>767. Forwarding and backward compatibility</h3>
19396<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
19397 <b>Submitter:</b> Sylvain Pion <b>Opened:</b> 2007-12-28  <b>Last modified:</b> 2008-06-18</p>
19398<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>
19399<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>
19400<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
19401<p><b>Discussion:</b></p>
19402<p>
19403Playing with g++'s C++0X mode, I noticed that the following
19404code, which used to compile:
19405</p>
19406
19407<blockquote><pre>#include &lt;vector&gt;
19408
19409int main()
19410{
19411    std::vector&lt;char *&gt; v;
19412    v.push_back(0);
19413}
19414</pre></blockquote>
19415
19416<p>
19417now fails with the following error message:
19418</p>
19419
19420<blockquote>.../include/c++/4.3.0/ext/new_allocator.h: In member
19421function 'void __gnu_cxx::new_allocator&lt;_Tp&gt;::construct(_Tp*,
19422_Args&amp;&amp; ...) [with _Args = int, _Tp = char*]':
19423.../include/c++/4.3.0/bits/stl_vector.h:707: instantiated from 'void
19424std::vector&lt;_Tp, _Alloc&gt;::push_back(_Args&amp;&amp; ...) [with
19425_Args = int, _Tp = char*, _Alloc = std::allocator&lt;char*&gt;]'
19426test.cpp:6: instantiated from here
19427.../include/c++/4.3.0/ext/new_allocator.h:114: error: invalid
19428conversion from 'int' to 'char*'
19429</blockquote>
19430
19431<p>
19432As far as I know, g++ follows the current draft here.
19433</p>
19434<p>
19435Does the committee really intend to break compatibility for such cases?
19436</p>
19437
19438<p><i>[
19439Sylvain adds: 
19440]</i></p>
19441
19442
19443<blockquote>
19444<p>
19445I just noticed that <tt>std::pair</tt> has the same issue.
19446The following now fails with GCC's -std=c++0x mode:
19447</p>
19448
19449<blockquote><pre>#include &lt;utility&gt;
19450
19451int main()
19452{
19453   std::pair&lt;char *, char *&gt; p (0,0);
19454}
19455</pre></blockquote>
19456
19457<p>
19458I have not made any general audit for such problems elsewhere.
19459</p>
19460</blockquote>
19461
19462<p><i>[
19463Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>
19464]</i></p>
19465
19466
19467<p><i>[
19468Bellevue:
19469]</i></p>
19470
19471
19472<blockquote>
19473<p>
19474Motivation is to handle the old-style int-zero-valued NULL pointers.
19475Problem: this solution requires concepts in some cases, which some users
19476will be slow to adopt. Some discussion of alternatives involving
19477prohibiting variadic forms and additional library-implementation
19478complexity.
19479</p>
19480<p>
19481Discussion of "perfect world" solutions, the only such solution put
19482forward being to retroactively prohibit use of the integer zero for a
19483NULL pointer. This approach was deemed unacceptable given the large
19484bodies of pre-existing code that do use integer zero for a NULL pointer.
19485</p>
19486<p>
19487Another approach is to change the member names. Yet another approach is
19488to forbid the extension in absence of concepts.
19489</p>
19490<p>
19491Resolution: These issues (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>) will be subsumed into a
19492paper to be produced by Alan Talbot in time for review at the 2008
19493meeting in France. Once this paper is produced, these issues will be
19494moved to NAD.
19495</p>
19496</blockquote>
19497
19498
19499
19500<p><b>Proposed resolution:</b></p>
19501<p>
19502Add the following rows to Table 90 "Optional sequence container operations", 23.2.3 [sequence.reqmts]:
19503</p>
19504
19505<blockquote>
19506<table border="1">
19507<tbody><tr>
19508<th>expression</th> <th>return type</th> <th>assertion/note<br>pre-/post-condition</th> <th>container</th>
19509</tr>
19510
19511<tr>
19512<td>
19513<tt>a.push_front(t)</tt>
19514</td>
19515<td>
19516<tt>void</tt>
19517</td>
19518<td>
19519<tt>a.insert(a.begin(), t)</tt><br>
19520<i>Requires:</i> <tt>T</tt> shall be <tt>CopyConstructible</tt>.
19521</td>
19522<td>
19523<tt>list, deque</tt>
19524</td>
19525</tr>
19526
19527<tr>
19528<td>
19529<tt>a.push_front(rv)</tt>
19530</td>
19531<td>
19532<tt>void</tt>
19533</td>
19534<td>
19535<tt>a.insert(a.begin(), rv)</tt><br>
19536<i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt>.
19537</td>
19538<td>
19539<tt>list, deque</tt>
19540</td>
19541</tr>
19542
19543<tr>
19544<td>
19545<tt>a.push_back(t)</tt>
19546</td>
19547<td>
19548<tt>void</tt>
19549</td>
19550<td>
19551<tt>a.insert(a.end(), t)</tt><br>
19552<i>Requires:</i> <tt>T</tt> shall be <tt>CopyConstructible</tt>.
19553</td>
19554<td>
19555<tt>list, deque, vector, basic_string</tt>
19556</td>
19557</tr>
19558
19559<tr>
19560<td>
19561<tt>a.push_back(rv)</tt>
19562</td>
19563<td>
19564<tt>void</tt>
19565</td>
19566<td>
19567<tt>a.insert(a.end(), rv)</tt><br>
19568<i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt>.
19569</td>
19570<td>
19571<tt>list, deque, vector, basic_string</tt>
19572</td>
19573</tr>
19574
19575</tbody></table>
19576</blockquote>
19577
19578<p>
19579Change the synopsis in 23.3.2 [deque]:
19580</p>
19581
19582<blockquote><pre><ins>void push_front(const T&amp; x);</ins>
19583<ins>void push_front(T&amp;&amp; x);</ins>
19584<ins>void push_back(const T&amp; x);</ins>
19585<ins>void push_back(T&amp;&amp; x);</ins>
19586template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_front(Args&amp;&amp;... args);
19587template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
19588</pre></blockquote>
19589
19590<p>
19591Change 23.3.2.3 [deque.modifiers]:
19592</p>
19593
19594<blockquote><pre><ins>void push_front(const T&amp; x);</ins>
19595<ins>void push_front(T&amp;&amp; x);</ins>
19596<ins>void push_back(const T&amp; x);</ins>
19597<ins>void push_back(T&amp;&amp; x);</ins>
19598template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_front(Args&amp;&amp;... args);
19599template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
19600</pre></blockquote>
19601
19602<p>
19603Change the synopsis in 23.3.4 [list]:
19604</p>
19605
19606<blockquote><pre><ins>void push_front(const T&amp; x);</ins>
19607<ins>void push_front(T&amp;&amp; x);</ins>
19608<ins>void push_back(const T&amp; x);</ins>
19609<ins>void push_back(T&amp;&amp; x);</ins>
19610template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_front(Args&amp;&amp;... args);
19611template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
19612</pre></blockquote>
19613
19614<p>
19615Change 23.3.4.3 [list.modifiers]:
19616</p>
19617
19618<blockquote><pre><ins>void push_front(const T&amp; x);</ins>
19619<ins>void push_front(T&amp;&amp; x);</ins>
19620<ins>void push_back(const T&amp; x);</ins>
19621<ins>void push_back(T&amp;&amp; x);</ins>
19622template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_front(Args&amp;&amp;... args);
19623template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
19624</pre></blockquote>
19625
19626<p>
19627Change the synopsis in 23.3.6 [vector]:
19628</p>
19629
19630<blockquote><pre><ins>void push_back(const T&amp; x);</ins>
19631<ins>void push_back(T&amp;&amp; x);</ins>
19632template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
19633</pre></blockquote>
19634
19635<p>
19636Change 23.3.6.4 [vector.modifiers]:
19637</p>
19638
19639<blockquote><pre><ins>void push_back(const T&amp; x);</ins>
19640<ins>void push_back(T&amp;&amp; x);</ins>
19641template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
19642</pre></blockquote>
19643
19644
19645
19646
19647<p><b>Rationale:</b></p>
19648<p>
19649Addressed by
19650<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2680.pdf">N2680 Proposed Wording for Placement Insert (Revision 1)</a>.
19651</p>
19652
19653<p>
19654If there is still an issue with pair, Howard should submit another issue.
19655</p>
19656
19657
19658
19659
19660
19661<hr>
19662<h3><a name="773"></a>773. issues with random</h3>
19663<p><b>Section:</b> 26.5.8.1 [rand.dist.uni] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
19664 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-01-14  <b>Last modified:</b> 2008-02-27</p>
19665<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.uni">issues</a> in [rand.dist.uni].</p>
19666<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
19667<p><b>Discussion:</b></p>
19668<ol>
19669<li>
1967026.5.8.1.1 [rand.dist.uni.int] <tt>uniform_int</tt> constructor has changed the default
19671max constructor parameter from 9 (in TR1) to <tt>max()</tt>. The value
19672is arbitrary at best and shouldn't be lightly changed because
19673it breaks backward compatibility.
19674</li>
19675
19676<li>
1967726.5.8.1.1 [rand.dist.uni.int] <tt>uniform_int</tt> has a parameter <tt>param</tt> that you can
19678provide on construction or <tt>operator()</tt>, set, and get. But there
19679is not even a hint of what this might be for.
19680</li>
19681
19682<li>
1968326.5.8.1.2 [rand.dist.uni.real] <tt>uniform_real</tt>. Same issue as #2.
19684</li>
19685</ol>
19686
19687<p><i>[
19688Bellevue:
19689]</i></p>
19690
19691
19692<blockquote>
19693NAD. Withdrawn.
19694</blockquote>
19695
19696
19697<p><b>Proposed resolution:</b></p>
19698<p>
19699</p>
19700
19701
19702
19703
19704
19705<hr>
19706<h3><a name="784"></a>784. unique_lock::release</h3>
19707<p><b>Section:</b> 30.4.3.2.3 [thread.lock.unique.mod] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
19708 <b>Submitter:</b> Constantine Sapuntzakis <b>Opened:</b> 2008-02-02  <b>Last modified:</b> 2008-02-27</p>
19709<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
19710<p><b>Discussion:</b></p>
19711<p>
19712<tt>unique_lock::release</tt> will probably lead to many mistakes where people
19713call <tt>release</tt> instead of <tt>unlock</tt>. I just coded such a mistake using the
19714boost pre-1.35 threads library last week.
19715</p>
19716
19717<p>
19718In many threading libraries, a call with <tt>release</tt> in it unlocks the
19719lock (e.g. ReleaseMutex in Win32, java.util.concurrent.Semaphore).
19720</p>
19721
19722<p>
19723I don't call <tt>unique_lock::lock</tt> much at all, so I don't get to see the
19724symmetry between <tt>::lock</tt> and <tt>::unlock</tt>. I usually use the constructor to
19725lock the mutex. So I'm left to remember whether to call <tt>release</tt> or
19726<tt>unlock</tt> during the few times I need to release the mutex before the scope
19727ends. If I get it wrong, the compiler doesn't warn me.
19728</p>
19729
19730<p>
19731An alternative name for release may be <tt>disown</tt>.
19732</p>
19733
19734<p>
19735This might be a rare case where usability is hurt by consistency with
19736the rest of the C++ standard (e.g. <tt>std::auto_ptr::release</tt>).
19737</p>
19738
19739<p><i>[
19740Bellevue:
19741]</i></p>
19742
19743
19744<blockquote>
19745Change a name from release to disown. However prior art uses the release
19746name. Compatibility with prior art is more important that any possible
19747benefit such a change might make. We do not see the benefit for
19748changing. NAD
19749</blockquote>
19750
19751
19752<p><b>Proposed resolution:</b></p>
19753<p>
19754Change the synopsis in 30.4.3.2 [thread.lock.unique]:
19755</p>
19756
19757<blockquote><pre>template &lt;class Mutex&gt; 
19758class unique_lock 
19759{ 
19760public:
19761   ...
19762   mutex_type* <del>release</del> <ins>disown</ins>();
19763   ...
19764};
19765</pre></blockquote>
19766
19767<p>
19768Change 30.4.3.2.3 [thread.lock.unique.mod]:
19769</p>
19770
19771<blockquote><pre>mutex_type *<del>release</del> <ins>disown</ins>();
19772</pre></blockquote>
19773
19774
19775
19776
19777
19778<hr>
19779<h3><a name="785"></a>785. Random Number Requirements in TR1</h3>
19780<p><b>Section:</b> TR1 5.1.4.5 [tr.rand.eng.disc], TR1 5.1.4.6 [tr.rand.eng.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
19781 <b>Submitter:</b> John Maddock <b>Opened:</b> 2008-01-15  <b>Last modified:</b> 2009-07-13</p>
19782<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
19783<p><b>Discussion:</b></p>
19784<p>
19785Table 16 of TR1 requires that all Pseudo Random Number generators have a
19786</p>
19787
19788<blockquote><pre>seed(integer-type s)
19789</pre></blockquote>
19790
19791<p>
19792member function that is equivalent to:
19793</p>
19794
19795<blockquote><pre>mygen = Generator(s)
19796</pre></blockquote>
19797
19798<p>
19799But the generators <tt>xor_combine</tt> and <tt>discard_block</tt> have no such seed member, only the
19800</p>
19801
19802<blockquote><pre>template &lt;class Gen&gt;
19803seed(Gen&amp;);
19804</pre></blockquote>
19805
19806<p>
19807member, which will not accept an integer literal as an argument: something that appears to violate the intent of Table 16.
19808</p>
19809
19810<p>
19811So... is this a bug in TR1?
19812</p>
19813
19814<p>This is a real issue BTW, since the Boost implementation does adhere
19815to the requirements of Table 16, while at least one commercial
19816implementation does not and follows a strict adherence to sections
198175.1.4.5 and 5.1.4.6 instead.
19818</p>
19819
19820<p><i>[
19821Jens adds:
19822]</i></p>
19823
19824
19825<blockquote>
19826Both engines do have the necessary
19827constructor, therefore the omission of the <tt>seed()</tt> member
19828functions appears to be an oversight.
19829</blockquote>
19830
19831<p><i>[
19832Post Summit Daniel adds:
19833]</i></p>
19834
19835
19836<blockquote>
19837Recommend NAD: <tt>xor_combine</tt> does no longer exist and <tt>discard_block[_engine]</tt>
19838has now the required seed overload accepting a <tt>result_type</tt>, which shall be an
19839unsigned integral type.
19840</blockquote>
19841
19842<p><i>[
19843Batavia (2009-05):
19844]</i></p>
19845
19846<blockquote>
19847Move to NAD as recommended.
19848</blockquote>
19849
19850
19851<p><b>Proposed resolution:</b></p>
19852<p>
19853NAD Recommended.
19854</p>
19855
19856
19857
19858
19859
19860<hr>
19861<h3><a name="786"></a>786. Thread library timed waits, UTC and monotonic clocks</h3>
19862<p><b>Section:</b> 20.9 [time] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
19863 <b>Submitter:</b> Christopher Kohlhoff, Jeff Garland <b>Opened:</b> 2008-02-03  <b>Last modified:</b> 2008-09-30</p>
19864<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time">issues</a> in [time].</p>
19865<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
19866<p><b>Discussion:</b></p>
19867<p>
19868The draft C++0x thread library requires that the time points of type
19869<tt>system_time</tt> and returned by <tt>get_system_time()</tt> represent Coordinated
19870Universal Time (UTC) (section  [datetime.system]). This can lead to
19871surprising behavior when a library user performs a duration-based wait,
19872such as <tt>condition_variable::timed_wait()</tt>. A complete explanation of the
19873problem may be found in the
19874<a href="http://www.opengroup.org/onlinepubs/009695399/xrat/xsh_chap02.html#tag_03_02_08_19">Rationale for the Monotonic Clock</a>
19875section in POSIX, but in summary:
19876</p>
19877
19878<ul>
19879<li>
19880Operations such as <tt>condition_variable::timed_wait()</tt> (and its POSIX
19881equivalent, <tt>pthread_cond_timedwait()</tt>) are specified using absolute times
19882to address the problem of spurious wakeups.
19883</li>
19884
19885<li>
19886The typical use of the timed wait operations is to perform a relative
19887wait. This may be achieved by first calculating an absolute time as the
19888sum of the current time and the desired duration. In fact, the C++0x
19889thread library includes duration-based overloads of
19890<tt>condition_variable::timed_wait()</tt> that behave as if by calling the
19891corresponding absolute time overload with a time point value of
19892<tt>get_system_time() + rel_time</tt>.
19893</li>
19894
19895<li>
19896A UTC clock may be affected by changes to the system time, such as
19897synchronization with an external source, leap seconds, or manual changes
19898to the clock.
19899</li>
19900
19901<li>
19902Should the clock change during a timed wait operation, the actual
19903duration of the wait will not be the expected length. For example, a
19904user may intend a timed wait of one second duration but, due to an
19905adjustment of the system clock backwards by a minute, the wait instead
19906takes 61 seconds.
19907</li>
19908</ul>
19909
19910<p>
19911POSIX solves the problem by introducing a new monotonic clock, which is
19912unaffected by changes to the system time. When a condition variable is
19913initialized, the user may specify whether the monotonic clock is to be
19914used. (It is worth noting that on POSIX systems it is not possible to
19915use <tt>condition_variable::native_handle()</tt> to access this facility, since
19916the desired clock type must be specified during construction of the
19917condition variable object.)
19918</p>
19919
19920<p>
19921In the context of the C++0x thread library, there are added dimensions
19922to the problem due to the need to support platforms other than POSIX:
19923</p>
19924
19925<ul>
19926<li>
19927Some environments (such as embedded systems) do not have a UTC clock, but do have a monotonic clock.
19928</li>
19929
19930<li>
19931Some environments do not have a monotonic clock, but do have a UTC clock.
19932</li>
19933
19934<li>
19935The Microsoft Windows API's synchronization functions use relative
19936timeouts based on an implied monotonic clock. A program that switches
19937from the Windows API to the C++0x thread library will now find itself
19938susceptible to clock changes.
19939</li>
19940</ul>
19941
19942<p>
19943One possible minimal solution:
19944</p>
19945
19946<ul>
19947<li>
19948Strike normative references to UTC and an epoch based on 1970-01-01.
19949</li>
19950
19951<li>
19952Make the semantics of <tt>system_time</tt> and <tt>get_system_time()</tt>
19953implementation-defined (i.e standard library implementors may choose the
19954appropriate underlying clock based on the capabilities of the target
19955platform).
19956</li>
19957
19958<li>
19959Add a non-normative note encouraging use of a monotonic clock.
19960</li>
19961
19962<li>
19963Remove <tt>system_time::seconds_since_epoch()</tt>.
19964</li>
19965
19966<li>
19967Change the constructor <tt>explicit system_time(time_t secs, nanoseconds ns
19968= 0)</tt> to <tt>explicit system_time(nanoseconds ns)</tt>.
19969</li>
19970</ul>
19971
19972
19973
19974<p><b>Proposed resolution:</b></p>
19975<p>
19976</p>
19977
19978
19979<p><b>Rationale:</b></p>
19980Addressed by
19981<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.html">N2661: A Foundation to Sleep On</a>.
19982
19983
19984
19985
19986
19987<hr>
19988<h3><a name="790"></a>790. <tt>xor_combine::seed</tt> not specified</h3>
19989<p><b>Section:</b> X [rand.adapt.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
19990 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09  <b>Last modified:</b> 2008-02-27</p>
19991<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.adapt.xor">issues</a> in [rand.adapt.xor].</p>
19992<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
19993<p><b>Discussion:</b></p>
19994<p>
19995<tt>xor_combine::seed(result_type)</tt> and <tt>seed(seed_seq&amp;)</tt> don't say what
19996happens to each of the sub-engine seeds. (Should probably do the same
19997to both, unlike TR1.)
19998</p>
19999
20000<p><i>[
20001Bellevue:
20002]</i></p>
20003
20004
20005<blockquote>
20006Overcome by the previous proposal. NAD mooted by resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>.
20007</blockquote>
20008
20009
20010
20011<p><b>Proposed resolution:</b></p>
20012
20013
20014
20015
20016
20017<hr>
20018<h3><a name="791"></a>791. <tt>piecewise_constant_distribution::densities</tt> has wrong name</h3>
20019<p><b>Section:</b> 26.5.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
20020 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09  <b>Last modified:</b> 2008-03-11</p>
20021<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p>
20022<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
20023<p><b>Discussion:</b></p>
20024<p>
20025<tt>piecewise_constant_distribution::densities()</tt> should be <tt>probabilities()</tt>,
20026just like <tt>discrete_distribution</tt>. (There's no real use for weights divided
20027by areas.)
20028</p>
20029
20030<p><i>[
20031Bellevue:
20032]</i></p>
20033
20034
20035<blockquote>
20036<p>
20037Fermilab does not agree with this summary. As defined in the equation in
2003826.4.8.5.2/4, the quantities are indeed probability densities not
20039probabilities. Because we view this distribution as a parameterization
20040of a *probability density function*, we prefer to work in terms of
20041probability densities.
20042</p>
20043
20044<p>
20045We don't think this should be changed.
20046</p>
20047
20048<p>
20049If there is a technical argument about why the implementation dealing
20050with these values can't be as efficient as one dealing with
20051probabilities, we might reconsider. We don't care about this one member
20052function being somewhat more or less efficient; we care about the size
20053of the distribution object and the speed of the calls to generate
20054variates.
20055</p>
20056</blockquote>
20057
20058
20059
20060<p><b>Proposed resolution:</b></p>
20061
20062<p>
20063Change synopsis in 26.5.8.5.2 [rand.dist.samp.pconst]:
20064</p>
20065
20066<blockquote><pre>template &lt;class RealType = double&gt; 
20067class piecewise_constant_distribution 
20068{ 
20069public:
20070    ...
20071    vector&lt;double&gt; <del>densities</del> <ins>probabilities</ins>() const;
20072    ...
20073};
20074</pre></blockquote>
20075
20076<p>
20077Change 26.5.8.5.2 [rand.dist.samp.pconst]/6:
20078</p>
20079
20080<blockquote><pre>vector&lt;double&gt; <del>densities</del> <ins>probabilities</ins>() const;
20081</pre></blockquote>
20082
20083
20084
20085
20086
20087
20088<hr>
20089<h3><a name="793"></a>793. <tt>discrete_distribution</tt> missing constructor</h3>
20090<p><b>Section:</b> 26.5.8.5.1 [rand.dist.samp.discrete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
20091 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09  <b>Last modified:</b> 2009-03-09</p>
20092<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.discrete">issues</a> in [rand.dist.samp.discrete].</p>
20093<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
20094<p><b>Discussion:</b></p>
20095<p>
20096<tt>discrete_distribution</tt> should have a constructor like:
20097</p>
20098
20099<blockquote><pre>template&lt;class _Fn&gt;
20100  discrete_distribution(result_type _Count, double _Low, double _High,
20101                        _Fn&amp; _Func);
20102</pre></blockquote>
20103
20104<p>
20105(Makes it easier to fill a histogram with function values over a range.)
20106</p>
20107
20108<p><i>[
20109Bellevue:
20110]</i></p>
20111
20112
20113<blockquote>
20114How do you specify the function so that it does not return negative
20115values? If you do it is a bad construction. This requirement is already
20116there. Where in each bin does one evaluate the function? In the middle.
20117Need to revisit tomorrow.
20118</blockquote>
20119
20120<p><i>[
20121Sophia Antipolis:
20122]</i></p>
20123
20124
20125<blockquote>
20126<p>
20127Bill is not requesting this.
20128</p>
20129<p>
20130Marc Paterno: <tt>_Fn</tt> cannot return negative values at the points where the
20131function is sampled. It is sampled in the middle of each bin. <tt>_Fn</tt> cannot
20132return 0 everywhere it is sampled.
20133</p>
20134<p>
20135Jens: lambda expressions are rvalues
20136</p>
20137<p>
20138Add a library issue to provide an
20139<tt>initializer_list&lt;double&gt;</tt> constructor for
20140<tt>discrete_distribution</tt>.
20141</p>
20142<p>
20143Marc Paterno: dislikes reference for <tt>_Fn</tt> parameter. Make it pass-by-value (to use lambda),
20144use <tt>std::ref</tt> to wrap giant-state function objects.
20145</p>
20146<p>
20147Daniel: See <tt>random_shuffle</tt>, pass-by-rvalue-reference.
20148</p>
20149<p>
20150Daniel to draft wording.
20151</p>
20152</blockquote>
20153
20154<p><i>[
20155Pre San Francisco, Daniel provided wording:
20156]</i></p>
20157
20158
20159<blockquote>
20160The here proposed changes of the WP refer to the current state of
20161<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>.
20162During the Sophia Antipolis meeting two different proposals came up
20163regarding the functor argument type, either by value or by rvalue-reference.
20164For consistence with existing conventions (state-free algorithms and the
20165<tt>general_pdf_distribution</tt> c'tor signature) the author decided to propose a
20166function argument that is provided by value. If severe concerns exists that
20167stateful functions would be of dominant relevance, it should be possible to
20168replace the two occurrences of <tt>Func</tt> by <tt>Func&amp;&amp;</tt> in this proposal as part
20169of an editorial process.
20170</blockquote>
20171
20172
20173
20174<p><b>Proposed resolution:</b></p>
20175
20176<p><b>Non-concept version of the proposed resolution</b></p>
20177
20178<ol>
20179<li>
20180<p>
20181In 26.5.8.5.1 [rand.dist.samp.discrete]/1, class <tt>discrete_distribution</tt>, just
20182<em>before</em> the member declaration
20183</p>
20184
20185<blockquote><pre>explicit discrete_distribution(const param_type&amp; parm);
20186</pre></blockquote>
20187
20188<p>
20189insert:
20190</p>
20191
20192
20193<blockquote><pre>template&lt;typename Func&gt;
20194discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
20195</pre></blockquote>
20196</li>
20197
20198<li>
20199<p>
20200Between p.4 and p.5 insert a series of new paragraphs as part of the
20201new member description::
20202</p>
20203<blockquote><pre>template&lt;typename Func&gt;
20204discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
20205</pre>
20206
20207<p>
20208<i>Complexity:</i> Exactly nf invocations of fw.
20209</p>
20210<p>
20211<i>Requires:</i>
20212</p>
20213<ol type="a">
20214<li>
20215fw shall be callable with one argument of type double, and shall
20216return values of a type convertible to double;</li>
20217
20218<li>If nf &gt; 0, the relation <tt><i>x</i><sub><i>min</i></sub></tt> &lt; <tt><i>x</i><sub><i>max</i></sub></tt> shall hold, and for all sample values
20219<tt><i>x</i><sub><i>k</i></sub></tt>, fw(<tt><i>x</i><sub><i>k</i></sub></tt>) shall return a weight value <tt><i>w</i><sub><i>k</i></sub></tt> that is non-negative, non-NaN,
20220and non-infinity;</li>
20221
20222<li>The following relations shall hold: nf &#8805; 0, and 0 &lt; S = <tt><i>w</i><sub><i>0</i></sub></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.</li>
20223
20224</ol>
20225
20226<p>
20227<i>Effects:</i>
20228</p>
20229<ol type="a">
20230<li>If nf == 0, sets n = 1 and lets the sequence w have length n = 1 and
20231   consist of the single value <tt><i>w</i><sub><i>0</i></sub></tt> = 1.</li>
20232
20233<li>
20234<p>Otherwise, sets n = nf, deltax = (<tt><i>x</i><sub><i>max</i></sub></tt> - <tt><i>x</i><sub><i>min</i></sub></tt>)/n and <tt><i>x</i><sub><i>cent</i></sub></tt> = <tt><i>x</i><sub><i>min</i></sub></tt> +
202350.5 * deltax.</p>
20236<blockquote><pre>For each k = 0, . . . ,n-1, calculates:
20237  <tt><i>x</i><sub><i>k</i></sub></tt> = <tt><i>x</i><sub><i>cent</i></sub></tt> + k * deltax
20238  <tt><i>w</i><sub><i>k</i></sub></tt> = fw(<tt><i>x</i><sub><i>k</i></sub></tt>)
20239</pre></blockquote>
20240</li>
20241<li>
20242<p>Constructs a discrete_distribution object with probabilities:</p>
20243<blockquote><pre><tt><i>p</i><sub><i>k</i></sub></tt> = <tt><i>w</i><sub><i>k</i></sub></tt>/S  for k = 0, . . . , n-1.
20244</pre></blockquote>
20245</li>
20246</ol>
20247</blockquote>
20248</li>
20249</ol>
20250
20251<p><b>Concept version of the proposed resolution</b></p>
20252
20253
20254<ol>
20255<li>
20256<p>
20257In 26.5.8.5.1 [rand.dist.samp.discrete]/1, class <tt>discrete_distribution</tt>, just
20258<em>before</em> the member declaration
20259</p>
20260
20261<blockquote><pre>explicit discrete_distribution(const param_type&amp; parm);
20262</pre></blockquote>
20263
20264<p>
20265insert:
20266</p>
20267
20268
20269<blockquote><pre>template&lt;Callable&lt;auto, double&gt; Func&gt;
20270 requires Convertible&lt;Func::result_type, double&gt;
20271discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
20272</pre></blockquote>
20273</li>
20274
20275<li>
20276<p>
20277Between p.4 and p.5 insert a series of new paragraphs as part of the
20278new member description::
20279</p>
20280<blockquote><pre>template&lt;Callable&lt;auto, double&gt; Func&gt;
20281 requires Convertible&lt;Func::result_type, double&gt;
20282discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
20283</pre>
20284
20285<p>
20286<i>Complexity:</i> Exactly nf invocations of fw.
20287</p>
20288<p>
20289<i>Requires:</i>
20290</p>
20291<ol type="a">
20292<li>If nf &gt; 0, the relation <tt><i>x</i><sub><i>min</i></sub></tt> &lt; <tt><i>x</i><sub><i>max</i></sub></tt> shall hold, and for all sample values
20293<tt><i>x</i><sub><i>k</i></sub></tt>, fw(<tt><i>x</i><sub><i>k</i></sub></tt>) shall return a weight value <tt><i>w</i><sub><i>k</i></sub></tt> that is non-negative, non-NaN,
20294and non-infinity;</li>
20295
20296<li>The following relations shall hold: nf &#8805; 0, and 0 &lt; S = <tt><i>w</i><sub><i>0</i></sub></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.</li>
20297
20298</ol>
20299
20300<p>
20301<i>Effects:</i>
20302</p>
20303<ol type="a">
20304<li>If nf == 0, sets n = 1 and lets the sequence w have length n = 1 and
20305   consist of the single value <tt><i>w</i><sub><i>0</i></sub></tt> = 1.</li>
20306
20307<li>
20308<p>Otherwise, sets n = nf, deltax = (<tt><i>x</i><sub><i>max</i></sub></tt> - <tt><i>x</i><sub><i>min</i></sub></tt>)/n and <tt><i>x</i><sub><i>cent</i></sub></tt> = <tt><i>x</i><sub><i>min</i></sub></tt> +
203090.5 * deltax.</p>
20310<blockquote><pre>For each k = 0, . . . ,n-1, calculates:
20311  <tt><i>x</i><sub><i>k</i></sub></tt> = <tt><i>x</i><sub><i>cent</i></sub></tt> + k * deltax
20312  <tt><i>w</i><sub><i>k</i></sub></tt> = fw(<tt><i>x</i><sub><i>k</i></sub></tt>)
20313</pre></blockquote>
20314</li>
20315<li>
20316<p>Constructs a discrete_distribution object with probabilities:</p>
20317<blockquote><pre><tt><i>p</i><sub><i>k</i></sub></tt> = <tt><i>w</i><sub><i>k</i></sub></tt>/S  for k = 0, . . . , n-1.
20318</pre></blockquote>
20319</li>
20320</ol>
20321</blockquote>
20322</li>
20323</ol>
20324
20325
20326
20327<p><b>Rationale:</b></p>
20328Addressed by
20329<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
20330
20331
20332
20333
20334
20335<hr>
20336<h3><a name="794"></a>794. <tt>piecewise_constant_distribution</tt> missing constructor</h3>
20337<p><b>Section:</b> 26.5.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
20338 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09  <b>Last modified:</b> 2009-03-09</p>
20339<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p>
20340<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
20341<p><b>Discussion:</b></p>
20342<p>
20343<tt>piecewise_constant_distribution</tt> should have a constructor like:
20344</p>
20345
20346<blockquote><pre>template&lt;class _Fn&gt;
20347   piecewise_constant_distribution(size_t _Count,
20348            _Ty _Low, _Ty _High, _Fn&amp; _Func);
20349</pre></blockquote>
20350
20351<p>
20352(Makes it easier to fill a histogram with function values over a range.
20353The two (reference <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>) make a sensible replacement for
20354<tt>general_pdf_distribution</tt>.)
20355</p>
20356
20357<p><i>[
20358Sophia Antipolis:
20359]</i></p>
20360
20361
20362<blockquote>
20363<p>
20364Marc: uses variable width of bins and weight for each bin. This is not
20365giving enough flexibility to control both variables.
20366</p>
20367<p>
20368Add a library issue to provide an constructor taking an
20369<tt>initializer_list&lt;double&gt;</tt> and <tt>_Fn</tt> for <tt>piecewise_constant_distribution</tt>.
20370</p>
20371<p>
20372Daniel to draft wording.
20373</p>
20374</blockquote>
20375
20376<p><i>[
20377Pre San Francisco, Daniel provided wording.
20378]</i></p>
20379
20380
20381<blockquote>
20382The here proposed changes of the WP refer to the current state of
20383<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>.
20384For reasons explained in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>, the author decided to propose a function
20385argument that is provided by value. The issue proposes a c'tor signature,
20386that does not take advantage of the full flexibility of
20387<tt>piecewise_constant_distribution</tt>,
20388because it restricts on a constant bin width, but the use-case seems to
20389be popular enough to justify it's introduction.
20390</blockquote>
20391
20392
20393
20394<p><b>Proposed resolution:</b></p>
20395
20396<p><b>Non-concept version of the proposed resolution</b></p>
20397
20398<ol>
20399<li>
20400<p>
20401In 26.5.8.5.2 [rand.dist.samp.pconst]/1, class <tt>piecewise_constant_distribution</tt>,
20402just <em>before</em> the member declaration
20403</p>
20404
20405<blockquote><pre>explicit piecewise_constant_distribution(const param_type&amp; parm);
20406</pre></blockquote>
20407<p>
20408insert:
20409</p>
20410<blockquote><pre>template&lt;typename Func&gt;
20411piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
20412</pre></blockquote>
20413</li>
20414
20415<li>
20416<p>
20417Between p.4 and p.5 insert a new sequence of paragraphs nominated
20418below as [p5_1], [p5_2],
20419[p5_3], and [p5_4] as part of the new member description:
20420</p>
20421
20422<blockquote><pre>template&lt;typename Func&gt;
20423piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
20424</pre>
20425<blockquote>
20426<p>
20427[p5_1] <i>Complexity:</i> Exactly <tt>nf</tt> invocations of <tt>fw</tt>.
20428</p>
20429<p>
20430[p5_2] <i>Requires:</i>
20431</p>
20432<ol type="a">
20433<li><tt>fw</tt> shall be callable with one argument of type <tt>RealType</tt>, and shall
20434return values of a type convertible to double;
20435</li>
20436<li>
20437For all sample values <tt><i>x<sub>k</sub></i></tt> defined below, fw(<tt><i>x<sub>k</sub></i></tt>) shall return a weight
20438value <tt><i>w<sub>k</sub></i></tt> that is non-negative, non-NaN, and non-infinity;
20439</li>
20440<li>
20441The following relations shall hold: <tt><i>x<sub>min</sub></i></tt> &lt; <tt><i>x<sub>max</sub></i></tt>, and
204420 &lt; S = <tt><i>w<sub>0</sub></i></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.
20443</li>
20444</ol>
20445<p>
20446[p5_3] <i>Effects:</i>
20447</p>
20448<ol type="a">
20449<li>
20450<p>If nf == 0,</p>
20451 <ol type="a">
20452 <li>
20453sets deltax = <tt><i>x<sub>max</sub></i></tt> - <tt><i>x<sub>min</sub></i></tt>, and</li>
20454<li> lets the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist of the single
20455    value <tt><i>w<sub>0</sub></i></tt> = 1, and</li>
20456<li> lets the sequence <tt>b</tt> have length <tt>n+1</tt> with <tt><i>b<sub>0</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> and 
20457              <tt><i>b<sub>1</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt>
20458</li>
20459</ol>
20460</li>
20461<li>
20462<p>Otherwise,</p>
20463<ol type="a">
20464<li> sets <tt>n = nf</tt>, <tt>deltax = </tt>(<tt><i>x<sub>max</sub></i></tt> - <tt><i>x<sub>min</sub></i></tt>)/n,
20465                 <tt><i>x<sub>cent</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> + 0.5 * deltax, and
20466</li>
20467<li><p>lets the sequences <tt>w</tt> and <tt>b</tt> have length <tt>n</tt> and <tt>n+1</tt>, resp. and</p>
20468<blockquote><pre>for each k = 0, . . . ,n-1, calculates:
20469  <tt><i>dx<sub>k</sub></i></tt> = k * deltax
20470  <tt><i>b<sub>k</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> + <tt><i>dx<sub>k</sub></i></tt>
20471  <tt><i>x<sub>k</sub></i></tt> = <tt><i>x<sub>cent</sub></i></tt> + <tt><i>dx<sub>k</sub></i></tt>
20472  <tt><i>w<sub>k</sub></i></tt> = fw(<tt><i>x<sub>k</sub></i></tt>),
20473</pre></blockquote> 
20474<p> and</p>
20475</li>
20476<li> sets <tt><i>b<sub>n</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt></li>
20477</ol>
20478</li>
20479<li>
20480<p>
20481Constructs a <tt>piecewise_constant_distribution</tt> object with
20482the above computed sequence <tt>b</tt> as the interval boundaries
20483and with the probability densities:
20484</p>
20485<blockquote><pre><tt><i>&#961;<sub>k</sub></i></tt> = <tt><i>w<sub>k</sub></i></tt>/(S * deltax)  for k = 0, . . . , n-1.
20486</pre></blockquote> 
20487</li>
20488</ol>
20489<p>
20490[p5_4] [<i>Note:</i> In this context, the subintervals [<tt><i>b<sub>k</sub></i></tt>, <tt><i>b<sub>k+1</sub></i></tt>) are commonly
20491 known as the <i>bins</i> of a histogram. <i>-- end note</i>]
20492 </p>
20493</blockquote>
20494</blockquote>
20495</li>
20496</ol>
20497
20498<p><b>Concept version of the proposed resolution</b></p>
20499
20500<ol>
20501<li>
20502<p>
20503In 26.5.8.5.2 [rand.dist.samp.pconst]/1, class <tt>piecewise_constant_distribution</tt>,
20504just <em>before</em> the member declaration
20505</p>
20506
20507<blockquote><pre>explicit piecewise_constant_distribution(const param_type&amp; parm);
20508</pre></blockquote>
20509<p>
20510insert:
20511</p>
20512<blockquote><pre>template&lt;Callable&lt;auto, RealType&gt; Func&gt;
20513 requires Convertible&lt;Func::result_type, double&gt;
20514piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
20515</pre></blockquote>
20516</li>
20517
20518<li>
20519<p>
20520Between p.4 and p.5 insert a new sequence of paragraphs nominated
20521below as [p5_1], [p5_2],
20522[p5_3], and [p5_4] as part of the new member description:
20523</p>
20524
20525<blockquote><pre>template&lt;Callable&lt;auto, RealType&gt; Func&gt;
20526 requires Convertible&lt;Func::result_type, double&gt;
20527piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
20528</pre>
20529<blockquote>
20530<p>
20531[p5_1] <i>Complexity:</i> Exactly <tt>nf</tt> invocations of <tt>fw</tt>.
20532</p>
20533<p>
20534[p5_2] <i>Requires:</i>
20535</p>
20536<ol type="a">
20537<li>
20538For all sample values <tt><i>x<sub>k</sub></i></tt> defined below, fw(<tt><i>x<sub>k</sub></i></tt>) shall return a weight
20539value <tt><i>w<sub>k</sub></i></tt> that is non-negative, non-NaN, and non-infinity;
20540</li>
20541<li>
20542The following relations shall hold: <tt><i>x<sub>min</sub></i></tt> &lt; <tt><i>x<sub>max</sub></i></tt>, and
205430 &lt; S = <tt><i>w<sub>0</sub></i></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.
20544</li>
20545</ol>
20546<p>
20547[p5_3] <i>Effects:</i>
20548</p>
20549<ol type="a">
20550<li>
20551<p>If nf == 0,</p>
20552 <ol type="a">
20553 <li>
20554sets deltax = <tt><i>x<sub>max</sub></i></tt> - <tt><i>x<sub>min</sub></i></tt>, and</li>
20555<li> lets the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist of the single
20556    value <tt><i>w<sub>0</sub></i></tt> = 1, and</li>
20557<li> lets the sequence <tt>b</tt> have length <tt>n+1</tt> with <tt><i>b<sub>0</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> and 
20558              <tt><i>b<sub>1</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt>
20559</li>
20560</ol>
20561</li>
20562<li>
20563<p>Otherwise,</p>
20564<ol type="a">
20565<li> sets <tt>n = nf</tt>, <tt>deltax = </tt>(<tt><i>x<sub>max</sub></i></tt> - <tt><i>x<sub>min</sub></i></tt>)/n,
20566                 <tt><i>x<sub>cent</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> + 0.5 * deltax, and
20567</li>
20568<li><p>lets the sequences <tt>w</tt> and <tt>b</tt> have length <tt>n</tt> and <tt>n+1</tt>, resp. and</p>
20569<blockquote><pre>for each k = 0, . . . ,n-1, calculates:
20570  <tt><i>dx<sub>k</sub></i></tt> = k * deltax
20571  <tt><i>b<sub>k</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> + <tt><i>dx<sub>k</sub></i></tt>
20572  <tt><i>x<sub>k</sub></i></tt> = <tt><i>x<sub>cent</sub></i></tt> + <tt><i>dx<sub>k</sub></i></tt>
20573  <tt><i>w<sub>k</sub></i></tt> = fw(<tt><i>x<sub>k</sub></i></tt>),
20574</pre></blockquote> 
20575<p> and</p>
20576</li>
20577<li> sets <tt><i>b<sub>n</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt></li>
20578</ol>
20579</li>
20580<li>
20581<p>
20582Constructs a <tt>piecewise_constant_distribution</tt> object with
20583the above computed sequence <tt>b</tt> as the interval boundaries
20584and with the probability densities:
20585</p>
20586<blockquote><pre><tt><i>&#961;<sub>k</sub></i></tt> = <tt><i>w<sub>k</sub></i></tt>/(S * deltax)  for k = 0, . . . , n-1.
20587</pre></blockquote> 
20588</li>
20589</ol>
20590<p>
20591[p5_4] [<i>Note:</i> In this context, the subintervals [<tt><i>b<sub>k</sub></i></tt>, <tt><i>b<sub>k+1</sub></i></tt>) are commonly
20592 known as the <i>bins</i> of a histogram. <i>-- end note</i>]
20593 </p>
20594</blockquote>
20595</blockquote>
20596</li>
20597</ol>
20598
20599
20600
20601<p><b>Rationale:</b></p>
20602Addressed by
20603<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
20604
20605
20606
20607
20608
20609<hr>
20610<h3><a name="795"></a>795. <tt>general_pdf_distribution</tt> should be dropped</h3>
20611<p><b>Section:</b> X [rand.dist.samp.genpdf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
20612 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09  <b>Last modified:</b> 2008-03-11</p>
20613<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.genpdf">issues</a> in [rand.dist.samp.genpdf].</p>
20614<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
20615<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#732">732</a></p>
20616<p><b>Discussion:</b></p>
20617<p>
20618<tt>general_pdf_distribution</tt> should be dropped. (It's a research topic in
20619adaptive numerical integration.)
20620</p>
20621
20622<p><i>[
20623Stephan Tolksdorf notes:
20624]</i></p>
20625
20626
20627<blockquote>
20628This appears to be a duplicate of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#732">732</a>.
20629</blockquote>
20630
20631
20632<p><b>Proposed resolution:</b></p>
20633
20634
20635
20636
20637
20638
20639<hr>
20640<h3><a name="796"></a>796. <tt>ranlux48_base</tt> returns wrong value</h3>
20641<p><b>Section:</b> 26.5.5 [rand.predef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
20642 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09  <b>Last modified:</b> 2008-02-27</p>
20643<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.predef">issues</a> in [rand.predef].</p>
20644<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
20645<p><b>Discussion:</b></p>
20646<p>
20647The 10,000<sup>th</sup> value returned by <tt>ranlux48_base</tt> is supposed to be
2064861839128582725. We get 192113843633948. (Note that the underlying
20649generator was changed in Kona.)
20650</p>
20651
20652<p><i>[
20653Bellevue:
20654]</i></p>
20655
20656
20657<blockquote>
20658Submitter withdraws defect.
20659</blockquote>
20660
20661
20662
20663<p><b>Proposed resolution:</b></p>
20664<p>
20665Change 26.5.5 [rand.predef]/p5:
20666</p>
20667
20668<blockquote>
20669<pre>typedef subtract_with_carry_engine&lt;uint_fast64_t, 48, 5, 12&gt; 
20670        ranlux48_base; 
20671</pre>
20672<blockquote>
20673<i>Required behavior:</i> The 10000<sup>th</sup> consecutive invocation of a default-constructed
20674object of type <tt>ranlux48_base</tt> shall produce the value
20675<del>61839128582725</del> <ins>192113843633948</ins>.
20676</blockquote>
20677</blockquote>
20678
20679
20680
20681
20682
20683<hr>
20684<h3><a name="797"></a>797. <tt>ranlux48</tt> returns wrong value</h3>
20685<p><b>Section:</b> 26.5.5 [rand.predef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
20686 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-09  <b>Last modified:</b> 2008-02-27</p>
20687<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.predef">issues</a> in [rand.predef].</p>
20688<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
20689<p><b>Discussion:</b></p>
20690<p>
20691The 10,000<sup>th</sup> value returned by <tt>ranlux48</tt> is supposed to be
20692249142670248501. We get 88229545517833. (Note that this depends
20693on <tt>ranlux48_base</tt>.)
20694</p>
20695<p><i>[
20696Bellevue:
20697]</i></p>
20698
20699
20700<blockquote>
20701Submitter withdraws defect.
20702</blockquote>
20703
20704
20705
20706<p><b>Proposed resolution:</b></p>
20707<p>
20708Change 26.5.5 [rand.predef]/p6:
20709</p>
20710
20711<blockquote>
20712<pre>typedef discard_block_engine&lt;ranlux48_base, 389, 11&gt; 
20713        ranlux48
20714</pre>
20715<blockquote>
20716<i>Required behavior:</i> The 10000<sup>th</sup> consecutive invocation of a default-constructed
20717object of type <tt>ranlux48</tt> shall produce the value
20718<del>249142670248501</del> <ins>88229545517833</ins>.
20719</blockquote>
20720</blockquote>
20721
20722
20723
20724
20725
20726<hr>
20727<h3><a name="799"></a>799. [tr.rand.eng.mers] and [rand.eng.mers]</h3>
20728<p><b>Section:</b> 26.5.3.2 [rand.eng.mers], TR1 5.1.4.2 [tr.rand.eng.mers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
20729 <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2008-02-18  <b>Last modified:</b> 2008-03-11</p>
20730<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng.mers">issues</a> in [rand.eng.mers].</p>
20731<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
20732<p><b>Discussion:</b></p>
20733<p>
20734TR1 5.1.4.2 [tr.rand.eng.mers](10) requires that <tt>operator==</tt> for the <tt>mersenne_twister</tt>
20735returns <tt>true</tt> if and only if the states of two <tt>mersenne_twisters</tt>,
20736consisting each of <tt>n</tt> integers between <tt>0</tt> and <tt>2<sup>w</sup> - 1</tt>, are completely
20737equal. This is a contradiction with TR1 5.1.1 [tr.rand.req](3) because the given
20738definition of the state also includes the lower <tt>r</tt> bits of <tt>x(i-n)</tt>, which
20739will never be used to generate a random number. If two <tt>mersenne_twister</tt>s
20740only differ in the lower bits of <tt>x(i-n)</tt> they will not compare equal,
20741although they will produce an identical sequence of random numbers.
20742</p>
20743
20744<p>
2074526.5.3.2 [rand.eng.mers] in the latest C++ draft does not specify the behaviour
20746of <tt>operator==</tt> but uses a similar definition of the state and, just like
20747TR1 5.1.4.2 [tr.rand.eng.mers], requires the textual representation of a
20748<tt>mersenne_twister_engine</tt> to consist of <tt>X<sub>i-n</sub></tt> to <tt>X<sub>i-1</sub></tt>, including the
20749lower bits of <tt>X<sub>i-n</sub></tt>. This leads to two problems: First, the
20750unsuspecting implementer is likely to erroneously compare the lower <tt>r</tt>
20751bits of <tt>X<sub>i-n</sub></tt> in <tt>operator==</tt>. Second, if only the lower <tt>r</tt> bits differ,
20752two <tt>mersenne_twister_engine</tt>s will compare equal (if correctly
20753implemented) but have different textual representations, which
20754conceptually is a bit ugly.
20755</p>
20756
20757<p>
20758I propose that a paragraph or footnote is added to 26.5.3.2 [rand.eng.mers] which
20759clarifies that the lower <tt>r</tt> bits of <tt>X<sub>i-n</sub></tt> are not to be compared in
20760<tt>operator==</tt> and <tt>operator!=</tt>. It would only be consequent if furthermore
20761the specification for the textual respresentation was changed to
20762<tt>X<sub>i-n</sub> bitand ((2<sup>w</sup> - 1) - (2<sup>r</sup> - 1)), X<sub>i-(n-1)</sub>, ...,  X<sub>i-1</sub></tt> or
20763something similar.
20764</p>
20765
20766<p>
20767These changes would likely have no practical effect, but would allow an
20768implementation that does the right thing to be standard-conformant.
20769</p>
20770
20771<p><i>[
20772Bellevue:
20773]</i></p>
20774
20775
20776<blockquote>
20777<p>
20778Fermi Lab has no objection to the proposed change. However it feels that
20779more time is needed to check the details, which would suggest a change
20780to REVIEW.
20781</p>
20782<p>
20783Bill feels that this is NAD, not enough practical importance to abandon
20784the simple definition of equality, and someone would have to do a lot
20785more study to ensure that all cases are covered for a very small
20786payback. The submitter admits that "These changes would likely have no
20787practical effect,", and according to Plum's razor this means that it is
20788not worth the effort!
20789</p>
20790<p>
20791Revisted: Agree that the fact that there is no practical difference means that no change can be justified.
20792</p>
20793</blockquote>
20794
20795
20796<p><b>Proposed resolution:</b></p>
20797<p>
20798In 26.5.3.2 [rand.eng.mers]:
20799</p>
20800
20801<blockquote>
20802<p>
20803Insert at the end of para 2.:
20804</p>
20805
20806<blockquote>
20807[<i>Note:</i> The lower <tt>r</tt> bits of <tt>X<sub>i-n</sub></tt> do not influence
20808the state transition and hence should not be compared when comparing two
20809<tt>mersenne_twister_engine</tt> objects. <i>-- end note</i>]
20810</blockquote>
20811
20812<p>
20813In para 5. change:
20814</p>
20815
20816<blockquote>
20817The textual representation of <tt>x<sub>i</sub></tt> consists of the values of
20818<tt>X<sub>i-n</sub> <ins>bitand ((2<sup>w</sup> - 1) - (2<sup>r</sup> - 1)),  X<sub>i-(n-1)</sub></ins>,
20819..., X<sub>i-1</sub></tt>, in that order.
20820</blockquote>
20821</blockquote>
20822
20823
20824
20825
20826
20827<hr>
20828<h3><a name="800"></a>800. Issues in 26.4.7.1 [rand.util.seedseq](6)</h3>
20829<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#NAD%20Editorial">NAD Editorial</a>
20830 <b>Submitter:</b> Stephan Tolksdorf <b>Opened:</b> 2008-02-18  <b>Last modified:</b> 2009-03-09</p>
20831<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>
20832<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
20833<p><b>Discussion:</b></p>
20834<p>
20835The for-loop in the algorithm specification has <tt>n</tt> iterations, where <tt>n</tt> is
20836defined to be <tt>end - begin</tt>, i.e. the number of supplied w-bit quantities.
20837Previous versions of this algorithm and the general logic behind it
20838suggest that this is an oversight and that in the context of the
20839for-loop <tt>n</tt> should be the number of full 32-bit quantities in <tt>b</tt> (rounded
20840upwards). If <tt>w</tt> is 64, the current algorithm throws away half of all bits
20841in <tt>b</tt>. If <tt>w</tt> is 16, the current algorithm sets half of all elements in <tt>v</tt>
20842to 0.
20843</p>
20844
20845<p>
20846There are two more minor issues:
20847</p>
20848
20849<ul>
20850<li>
20851Strictly speaking <tt>end - begin</tt> is not defined since
20852<tt>InputIterator</tt> is not required to be a random access iterator.
20853</li>
20854<li>
20855Currently all integral types are allowed as input to the <tt>seed_seq</tt>
20856constructor, including <tt>bool</tt>. IMHO allowing <tt>bool</tt>s unnecessarily
20857complicates the implementation without any real benefit to the user.
20858I'd suggest to exclude <tt>bool</tt>s as input.
20859</li>
20860</ul>
20861
20862<p><i>[
20863Bellevue:
20864]</i></p>
20865
20866
20867<blockquote>
20868Move to OPEN Bill will try to propose a resolution by the next meeting.
20869</blockquote>
20870
20871<p><i>[
20872post Bellevue:  Bill provided wording.
20873]</i></p>
20874
20875
20876<p>
20877This issue is made moot if <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#803">803</a> is accepted.
20878</p>
20879
20880
20881
20882<p><b>Proposed resolution:</b></p>
20883<p>
20884Replace 26.5.7.1 [rand.util.seedseq] paragraph 6 with:
20885</p>
20886
20887<blockquote>
20888<p>
20889<i>Effects:</i> Constructs a <tt>seed_seq</tt> object by effectively concatenating the
20890low-order <tt>u</tt> bits of each of the elements of the supplied sequence <tt>[begin,
20891end)</tt>
20892in ascending order of significance to make a (possibly very large) unsigned
20893binary number <tt>b</tt> having a total of <tt>n</tt> bits, and then carrying out the
20894following
20895algorithm:
20896</p>
20897
20898<blockquote><pre>for( v.clear(); n &gt; 0; n -= 32 )
20899   v.push_back(b mod 2<sup>32</sup>), b /= 2<sup>32</sup>;
20900</pre></blockquote>
20901</blockquote>
20902
20903
20904<p><b>Rationale:</b></p>
20905Addressed by
20906<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
20907
20908
20909
20910
20911
20912<hr>
20913<h3><a name="802"></a>802. <tt>knuth_b</tt> returns wrong value</h3>
20914<p><b>Section:</b> 26.5.5 [rand.predef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
20915 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2008-02-20  <b>Last modified:</b> 2008-03-17</p>
20916<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.predef">issues</a> in [rand.predef].</p>
20917<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
20918<p><b>Discussion:</b></p>
20919<p>
20920The 10,000<sup>th</sup> value returned by <tt>knuth_b</tt> is supposed to be
209211112339016. We get 2126698284.
20922</p>
20923
20924
20925<p><b>Proposed resolution:</b></p>
20926<p>
20927Change 26.5.5 [rand.predef]/p8:
20928</p>
20929
20930<blockquote>
20931<pre>typedef shuffle_order_engine&lt;minstd_rand0, 256&gt; 
20932        knuth_b; 
20933</pre>
20934<blockquote>
20935<i>Required behavior:</i> The 10000<sup>th</sup> consecutive invocation of a default-constructed
20936object of type <tt>knuth_b</tt> shall produce the value
20937<del>1112339016</del> <ins>2126698284</ins>.
20938</blockquote>
20939</blockquote>
20940
20941
20942<p><i>[
20943Bellevue: Submitter withdraws defect. "We got the wrong value for entirely the right reasons". NAD.
20944]</i></p>
20945
20946
20947
20948
20949
20950<hr>
20951<h3><a name="803"></a>803. Simplification of <tt>seed_seq::seq_seq</tt></h3>
20952<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#NAD%20Editorial">NAD Editorial</a>
20953 <b>Submitter:</b> Charles Karney <b>Opened:</b> 2008-02-22  <b>Last modified:</b> 2009-03-09</p>
20954<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>
20955<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
20956<p><b>Discussion:</b></p>
20957<p>
20958<tt>seed_seq(InputIterator begin, InputIterator end);</tt> constructs a <tt>seed_seq</tt>
20959object repacking the bits of supplied sequence <tt>[begin, end)</tt> into a
2096032-bit vector.
20961</p>
20962<p>
20963This repacking triggers several problems:
20964</p>
20965<ol>
20966<li>
20967Distinctness of the output of <tt>seed_seq::generate</tt> required the
20968introduction of the initial "<tt>if (w &lt; 32) v.push_back(n);</tt>"  (Otherwise
20969the unsigned short vectors [1, 0] and [1] generate the same sequence.)
20970</li>
20971<li>
20972Portability demanded the introduction of the template parameter <tt>u</tt>.
20973(Otherwise some sequences could not be obtained on computers where no
20974integer types are exactly 32-bits wide.)
20975</li>
20976<li>
20977The description and algorithm have become unduly complicated.
20978</li>
20979</ol>
20980<p>
20981I propose simplifying this <tt>seed_seq</tt> constructor to be "32-bit only".
20982Despite it's being simpler, there is NO loss of functionality (see
20983below).
20984</p>
20985<p>
20986Here's how the description would read
20987</p>
20988<blockquote>
20989<p>
2099026.5.7.1 [rand.util.seedseq] Class <tt>seed_seq</tt>
20991</p>
20992
20993<blockquote>
20994<pre>template&lt;class InputIterator&gt;
20995  seed_seq(InputIterator begin, InputIterator end);
20996</pre>
20997<blockquote>
20998<p>
209995 <i>Requires:</i> NO CHANGE
21000</p>
21001<p>
210026 <i>Effects:</i> Constructs a <tt>seed_seq</tt> object by
21003</p>
21004<blockquote>
21005<pre>for (InputIterator s = begin; s != end; ++s)
21006   v.push_back((*s) mod 2^32);
21007</pre>
21008</blockquote>
21009</blockquote>
21010</blockquote>
21011</blockquote>
21012
21013<p>
21014Discussion:
21015</p>
21016<p>
21017The chief virtues here are simplicity, portability, and generality.
21018</p>
21019<ul>
21020<li>
21021Simplicity -- compare the above specification with the
21022<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a> proposal.
21023</li>
21024<li>
21025Portability -- with <tt>iterator_traits&lt;InputIterator&gt;::value_type =
21026uint_least32_t</tt> the user is guaranteed to get the same behavior across
21027platforms.
21028</li>
21029<li>
21030Generality -- any behavior that the
21031<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
21032proposal can achieve can be
21033obtained with this simpler proposal (albeit with a shuffling of bits
21034in the input sequence).
21035</li>
21036</ul>
21037<p>
21038Arguments (and counter-arguments) against making this change (and
21039retaining the
21040<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
21041behavior) are:
21042</p>
21043<ul>
21044<li>
21045<p>
21046The user can pass an array of <tt>unsigned char</tt> and <tt>seed_seq</tt> will nicely
21047 repack it.
21048</p>
21049<p>
21050 Response: So what?  Consider the seed string "ABC".  The
21051 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
21052 proposal results in
21053</p>
21054<blockquote><pre>v = { 0x3, 0x434241 };
21055</pre></blockquote>
21056<p>
21057while the simplified proposal yields
21058</p>
21059<blockquote><pre>v = { 0x41, 0x42, 0x43 };
21060</pre></blockquote>
21061<p>
21062The results produced by <tt>seed_seq::generate</tt> with the two inputs are
21063different but nevertheless equivalently "mixed up" and this remains
21064true even if the seed string is long.
21065</p>
21066</li>
21067<li>
21068<p>
21069With long strings (e.g., with bit-length comparable to the number of
21070 bits in the state), <tt>v</tt> is longer (by a factor of 4) with the simplified
21071 proposal and <tt>seed_seq::generate</tt> will be slower.
21072</p>
21073<p>
21074Response: It's unlikely that the efficiency of <tt>seed_seq::generate</tt> will
21075 be a big issue.  If it is, the user is free to repack the seed vector
21076 before constructing <tt>seed_seq</tt>.
21077</p>
21078</li>
21079<li>
21080<p>
21081A user can pass an array of 64-bit integers and all the bits will be
21082 used.
21083</p>
21084<p>
21085 Response: Indeed.  However, there are many instances in the 
21086 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
21087 where integers are silently coerced to a narrower width and this
21088 should just be a case of the user needing to read the documentation.
21089 The user can of course get equivalent behavior by repacking his seed
21090 into 32-bit pieces.  Furthermore, the unportability of the 
21091 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
21092 proposal with
21093</p>
21094<blockquote><pre>unsigned long s[] = {1, 2, 3, 4};
21095seed_seq q(s, s+4);
21096</pre></blockquote>
21097<p>
21098 which typically results in <tt>v = {1, 2, 3, 4}</tt> on 32-bit machines and in
21099<tt>v = {1, 0, 2, 0, 3, 0, 4, 0}</tt> on 64-bit machines is a major pitfall for
21100 unsuspecting users.
21101</p>
21102</li>
21103</ul>
21104
21105<p>
21106Note: this proposal renders moot issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#800">800</a>.
21107</p>
21108
21109<p><i>[
21110Bellevue:
21111]</i></p>
21112
21113
21114<blockquote>
21115Walter needs to ask Fermilab for guidance. Defer till tomorrow. Bill likes the proposed resolution.
21116</blockquote>
21117
21118<p><i>[
21119Sophia Antipolis:
21120]</i></p>
21121
21122
21123<blockquote>
21124<p>
21125Marc Paterno wants portable behavior between 32bit and 64bit machines;
21126we've gone to significant trouble to support portability of engines and
21127their values.
21128</p>
21129<p>
21130Jens: the new algorithm looks perfectly portable
21131</p>
21132<p>
21133Marc Paterno to review off-line.
21134</p>
21135<p>
21136Modify the proposed resolution to read "Constructs a seed_seq object by the following algorithm ..."
21137</p>
21138<p>
21139Disposition: move to review; unanimous consent.
21140</p>
21141<p>
21142(moots <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#800">800</a>)
21143</p>
21144</blockquote>
21145
21146
21147
21148<p><b>Proposed resolution:</b></p>
21149<p>
21150Change 26.5.7.1 [rand.util.seedseq]:
21151</p>
21152
21153<blockquote>
21154<pre>template&lt;class InputIterator<del>, 
21155  size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</del>&gt;
21156  seed_seq(InputIterator begin, InputIterator end);
21157</pre>
21158<blockquote>
21159<p>
21160-5- <i>Requires:</i> <tt>InputIterator</tt> shall satisfy the requirements of an input iterator (24.1.1)
21161such that <tt>iterator_traits&lt;InputIterator&gt;::value_type</tt> shall denote an integral type.
21162</p>
21163<p>
21164-6- Constructs a <tt>seed_seq</tt> object by <ins>the following algorithm</ins> <del>rearranging some or all of the bits of the supplied sequence
21165<tt>[begin,end)</tt> of w-bit quantities into 32-bit units, as if by the following: </del>
21166</p>
21167<p>
21168<del>First extract the rightmost <tt>u</tt> bits from each of the <tt>n = end
21169- begin</tt> elements of the supplied sequence and concatenate all the
21170extracted bits to initialize a single (possibly very large) unsigned
21171binary number, <tt>b = &#8721;<sup>n-1</sup><sub>i=0</sub> (begin[i] 
21172mod 2<sup>u</sup>) � 2<sup>w�i</sup></tt> (in which the bits of each <tt>begin[i]</tt>
21173are treated as denoting an unsigned quantity). Then carry out 
21174the following algorithm:</del>
21175</p>
21176<blockquote><pre><del>
21177v.clear(); 
21178if ($w$ &lt; 32) 
21179  v.push_back($n$); 
21180for( ; $n$ &gt; 0; --$n$) 
21181  v.push_back(b mod 2<sup>32</sup>), b /= 2<sup>32</sup>;
21182</del></pre></blockquote>
21183<blockquote>
21184<pre><ins>
21185for (InputIterator s = begin; s != end; ++s)
21186   v.push_back((*s) mod 2<sup>32</sup>);
21187</ins></pre>
21188</blockquote>
21189</blockquote>
21190</blockquote>
21191
21192
21193<p><b>Rationale:</b></p>
21194Addressed by
21195<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
21196
21197
21198
21199
21200
21201<hr>
21202<h3><a name="812"></a>812. unsolicited multithreading considered harmful?</h3>
21203<p><b>Section:</b> 25.4.1 [alg.sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
21204 <b>Submitter:</b> Paul McKenney <b>Opened:</b> 2008-02-27  <b>Last modified:</b> 2008-09-17</p>
21205<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
21206<p><b>Discussion:</b></p>
21207<p>
21208Multi-threading is a good thing, but unsolicited multi-threading can
21209potentially be harmful.  For example, <tt>sort()</tt> performance might be
21210greatly increased via a multithreaded implementation.  However, such
21211a multithreaded implementation could result in concurrent invocations
21212of the user-supplied comparator.  This would in turn result in problems
21213given a caching comparator that might be written for complex sort keys.
21214Please note that this is not a theoretical issue, as multithreaded
21215implementations of <tt>sort()</tt> already exist.
21216</p>
21217<p>
21218Having a multithreaded <tt>sort()</tt> available is good, but it should not
21219be the default for programs that are not explicitly multithreaded.
21220Users should not be forced to deal with concurrency unless they have
21221asked for it.
21222</p>
21223
21224<p><i>[
21225This may be covered by
21226<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2410.html">N2410</a>
21227Thread-Safety in the Standard Library (Rev 1).
21228]</i></p>
21229
21230
21231
21232<p><b>Proposed resolution:</b></p>
21233<p>
21234</p>
21235
21236
21237<p><b>Rationale:</b></p>
21238This is already covered by 17.6.5.6/20 in N2723.
21239
21240
21241
21242
21243
21244<hr>
21245<h3><a name="823"></a>823. <tt>identity&lt;void&gt;</tt> seems broken</h3>
21246<p><b>Section:</b> 20.3.3 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
21247 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2008-04-09  <b>Last modified:</b> 2009-10-23</p>
21248<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>
21249<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
21250<p><b>Discussion:</b></p>
21251<p>
21252N2588 seems to have added an <tt>operator()</tt> member function to the
21253<tt>identity&lt;&gt;</tt> helper in 20.3.3 [forward].  I believe this change makes it no
21254longer possible to instantiate <tt>identity&lt;void&gt;</tt>, as it would require
21255forming a reference-to-<tt>void</tt> type as this <tt>operator()</tt>'s parameter type.
21256</p>
21257
21258<p>
21259Suggested resolution:  Specialize <tt>identity&lt;void&gt;</tt> so as not to require
21260the member function's presence.
21261</p>
21262
21263<p><i>[
21264Sophia Antipolis:
21265]</i></p>
21266
21267
21268<blockquote>
21269<p>
21270Jens: suggests to add a requires clause to avoid specializing on <tt>void</tt>.
21271</p>
21272<p>
21273Alisdair: also consider cv-qualified <tt>void</tt>.
21274</p>
21275<p>
21276Alberto provided proposed wording.
21277</p>
21278</blockquote>
21279
21280<p><i>[
212812009-07-30 Daniel reopens:
21282]</i></p>
21283
21284
21285<blockquote>
21286<p>
21287This issue became closed, because the <tt>ReferentType</tt> requirement
21288fixed the problem - this is no longer the case. In retrospective it seems
21289to 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>,
21290<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#939">939</a>)
21291is that it was standardized as something very different (an unconditional
21292type mapper) than traditional usage indicated (a function object that should
21293derive from <tt>std::unary_function)</tt>, as the SGI definition does. This issue could
21294be 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
21295has been decided, this issue should remain open. An alternative for
21296removing it, would be, to do the following:
21297</p>
21298
21299<ol type="a">
21300<li>
21301<p>
21302Let <tt>identity</tt> stay as a <em>real</em> function object, which would
21303now properly
21304derive from <tt>unary_function</tt>:
21305</p>
21306
21307<blockquote><pre>template &lt;class T&gt; struct identity : unary_function&lt;T, T&gt; {
21308  const T&amp; operator()(const T&amp;) const;
21309};
21310</pre></blockquote>
21311</li>
21312
21313<li>
21314<p>
21315Invent (if needed) a generic type wrapper (corresponding to concept
21316<tt>IdentityOf</tt>),
21317e.g. <tt>identity_of</tt>, and move it's prototype description back to 20.3.3 [forward]:
21318</p>
21319
21320<blockquote><pre>template &lt;class T&gt; struct identity_of {
21321  typedef T type;
21322};
21323</pre></blockquote>
21324
21325<p>
21326and adapt the <tt>std::forward</tt> signature to use <tt>identity_of</tt>
21327instead of <tt>identity</tt>.
21328</p>
21329</li>
21330</ol>
21331</blockquote>
21332
21333<p><i>[
213342009-10 Santa Cruz:
21335]</i></p>
21336
21337
21338<blockquote>
21339Mark as NAD Editorial, fixed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#939">939</a>.
21340</blockquote>
21341
21342
21343
21344<p><b>Proposed resolution:</b></p>
21345<p>
21346Change definition of <tt>identity</tt> in 20.3.3 [forward], paragraph 2, to:
21347</p>
21348
21349<blockquote><pre>template &lt;class T&gt;  struct identity {
21350    typedef T type;
21351
21352    <ins>requires ReferentType&lt;T&gt;</ins>
21353      const T&amp; operator()(const T&amp; x) const;
21354  };
21355</pre></blockquote>
21356<p>...</p>
21357<blockquote><pre>  <ins>requires ReferentType&lt;T&gt;</ins>
21358    const T&amp; operator()(const T&amp; x) const;
21359</pre></blockquote>
21360
21361
21362<p><b>Rationale:</b></p>
21363<p>
21364The point here is to able to write <tt>T&amp;</tt> given <tt>T</tt> and <tt>ReferentType</tt> is
21365precisely the concept that guarantees so, according to N2677
21366(Foundational concepts). Because of this, it seems preferable than an
21367explicit check for <tt>cv void</tt> using <tt>SameType/remove_cv</tt> as it was suggested
21368in Sophia. In particular, Daniel remarked that there may be types other
21369than <tt>cv void</tt> which aren't referent types (<tt>int[]</tt>, perhaps?).
21370</p>
21371
21372
21373
21374
21375
21376<hr>
21377<h3><a name="825"></a>825. Missing rvalues reference stream insert/extract operators?</h3>
21378<p><b>Section:</b> 19.5.2.1 [syserr.errcode.overview], 20.8.15.2.8
21379[util.smartptr.shared.io], 22.4.8 [facets.examples], 20.3.7.3
21380[bitset.operators], 26.4.6 [complex.ops], 27.6 [stream.buffers], 28.9
21381[re.submatch] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
21382 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-04-10  <b>Last modified:</b> 2009-10-26</p>
21383<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
21384<p><b>Discussion:</b></p>
21385<p><b>Addresses UK 220</b></p>
21386
21387<p>
21388Should the following use rvalues references to stream in insert/extract
21389operators?
21390</p>
21391
21392<ul>
21393<li>19.5.2.1 [syserr.errcode.overview]</li>
21394<li>20.8.15.2.8 [util.smartptr.shared.io]</li>
21395<li>22.4.8 [facets.examples]</li>
21396<li>20.3.7.3 [bitset.operators]</li>
21397<li>26.4.6 [complex.ops]</li>
21398<li>Doubled signatures in 27.6 [stream.buffers] for character inserters
21399(ref 27.7.2.6.4 [ostream.inserters.character])
21400+ definition 27.7.2.6.4 [ostream.inserters.character]</li>
21401<li>28.9 [re.submatch]</li>
21402</ul>
21403
21404<p><i>[
21405Sophia Antipolis
21406]</i></p>
21407
21408
21409<blockquote>
21410Agree with the idea in the issue, Alisdair to provide wording.
21411</blockquote>
21412
21413<p><i>[
21414Daniel adds 2009-02-14:
21415]</i></p>
21416
21417
21418<blockquote>
21419The proposal given in the paper
21420<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2831.html">N2831</a>
21421apparently resolves this issue.
21422</blockquote>
21423
21424<p><i>[
21425Batavia (2009-05):
21426]</i></p>
21427
21428<blockquote>
21429<p>
21430The cited paper is an earlier version of
21431<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>,
21432which changed the rvalue reference binding rules.
21433That paper includes generic templates
21434<tt>operator&lt;&lt;</tt> and <tt>operator&gt;&gt;</tt>
21435that adapt rvalue streams.
21436</p>
21437<p>
21438We therefore agree with Daniel's observation.
21439Move to NAD Editorial.
21440</p>
21441</blockquote>
21442
21443
21444<p><b>Proposed resolution:</b></p>
21445<p>
21446</p>
21447
21448
21449
21450
21451
21452<hr>
21453<h3><a name="826"></a>826. Equivalent of <tt>%'d</tt>, or rather, lack thereof?</h3>
21454<p><b>Section:</b> 22.4.2.2 [locale.nm.put] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
21455 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-04-07  <b>Last modified:</b> 2008-06-18</p>
21456<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
21457<p><b>Discussion:</b></p>
21458<p>
21459In the spirit of <tt>printf vs iostream</tt>...
21460</p>
21461
21462<p>
21463POSIX <tt>printf</tt> says that <tt>%'d</tt> should insert grouping characters (and the
21464implication is that in the absence of <tt>'</tt> no grouping characters are
21465inserted). The <tt>num_put</tt> facet, on the other hand, seems to always insert
21466grouping characters. Can this be considered a defect worth fixing for
21467C++0x? Maybe <tt>ios_base</tt> needs an additional flag?
21468</p>
21469
21470<p><i>[
21471Pablo Halpern:
21472]</i></p>
21473
21474
21475<blockquote>
21476I'm not sure it constitutes a defect, but I would be in favor of adding
21477another flag (and corresponding manipulator).
21478</blockquote>
21479
21480<p><i>[
21481Martin Sebor:
21482]</i></p>
21483
21484
21485<blockquote>
21486I don't know if it qualifies as a defect but I agree that there
21487should be an easy way to control whether the thousands separator
21488should or shouldn't be inserted. A new flag would be in line with
21489the current design of iostreams (like <tt>boolalpha</tt>, <tt>showpos</tt>, or
21490<tt>showbase</tt>).
21491</blockquote>
21492
21493<p><i>[
21494Sophia Antipolis:
21495]</i></p>
21496
21497
21498<blockquote>
21499This is not a part of C99. LWG suggests submitting a paper may be appropriate.
21500</blockquote>
21501
21502
21503
21504<p><b>Proposed resolution:</b></p>
21505<p>
21506</p>
21507
21508
21509
21510
21511
21512<hr>
21513<h3><a name="827"></a>827. <tt>constexpr shared_ptr::shared_ptr()?</tt></h3>
21514<p><b>Section:</b> 20.8.15.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
21515 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-04-11  <b>Last modified:</b> 2009-10-26</p>
21516<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>
21517<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
21518<p><b>Discussion:</b></p>
21519<p>
21520Would anyone object to making the default constructor of <tt>shared_ptr</tt> (and
21521<tt>weak_ptr</tt> and <tt>enable_shared_from_this) constexpr</tt>? This would enable
21522static initialization for <tt>shared_ptr</tt> variables, eliminating another
21523unfair advantage of raw pointers.
21524</p>
21525
21526<p><i>[
21527San Francisco:
21528]</i></p>
21529
21530
21531<blockquote>
21532<p>
21533It's not clear to us that you can initialize a pointer with the literal
215340 in a constant expression. We need to ask CWG to make sure this works.
21535Bjarne has been appointed to do this.
21536</p>
21537<p>
21538Core got back to us and assured as that <tt>nullptr</tt> would do the job
21539nicely here.
21540</p>
21541</blockquote>
21542
21543<p><i>[
215442009-05-01 Alisdair adds:
21545]</i></p>
21546
21547
21548<blockquote>
21549<p>
21550I don't believe that constexpr will buy anything in this case.
21551<tt>shared_ptr/weak_ptr/enable_shared_from_this</tt> cannot be literal types as they
21552have a non-trivial copy constructor.  As they do not produce literal types,
21553then the constexpr default constructor will <em>not</em> guarantee constant
21554initialization, and so not buy the hoped for optimization.
21555</p>
21556<p>
21557I recommend referring this back to Core to see if we can get static
21558initialization for types with constexpr constructors, even if they are not
21559literal types.  Otherwise this should be closed as NAD.
21560</p>
21561</blockquote>
21562
21563<p><i>[
215642009-05-26 Daniel adds:
21565]</i></p>
21566
21567
21568<blockquote>
21569If Alisdair's 2009-05-01 comment is correct, wouldn't that also make
21570<tt>constexpr mutex()</tt> useless, because this class has a non-trivial
21571destructor? (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#828">828</a>)
21572</blockquote>
21573
21574<p><i>[
215752009-07-21 Alisdair adds:
21576]</i></p>
21577
21578
21579<blockquote>
21580<p>
21581The feedback from core is that this and similar uses of constexpr
21582constructors to force static initialization should be supported.  If
21583there are any problems with this in the working draught, we should file
21584core issues.
21585</p>
21586
21587<p>
21588Recommend we declare the default constructor constexpr as the issue suggests
21589(proposed wording added).
21590</p>
21591</blockquote>
21592
21593<p><i>[
215942009-10 Santa Cruz:
21595]</i></p>
21596
21597
21598<blockquote>
21599NAD Editorial.  Solved by
21600<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2994.html">N2994</a>.
21601</blockquote>
21602
21603
21604<p><b>Proposed resolution:</b></p>
21605<p>
21606Change 20.8.15.2 [util.smartptr.shared] and 20.8.15.2.1 [util.smartptr.shared.const]:
21607</p>
21608
21609<blockquote><pre><ins>consexpr</ins> shared_ptr();
21610</pre></blockquote>
21611
21612<p>
21613Change 20.8.15.3 [util.smartptr.weak] and 20.8.15.3.1 [util.smartptr.weak.const]:
21614</p>
21615
21616<blockquote><pre><ins>consexpr</ins> weak_ptr();
21617</pre></blockquote>
21618
21619<p>
21620Change 20.8.15.4 [util.smartptr.enab] (2 places):
21621</p>
21622
21623<blockquote><pre><ins>consexpr</ins> enable_shared_from_this();
21624</pre></blockquote>
21625
21626
21627
21628
21629
21630
21631<hr>
21632<h3><a name="828"></a>828. Static initialization for <tt>std::mutex</tt>?</h3>
21633<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#NAD%20Editorial">NAD Editorial</a>
21634 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2008-04-18  <b>Last modified:</b> 2009-10-26</p>
21635<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>
21636<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
21637<p><b>Discussion:</b></p>
21638<p>
21639[Note: I'm assuming here that 3.6.2 [basic.start.init]/1 will be fixed.]
21640</p>
21641<p>
21642Currently <tt>std::mutex</tt> doesn't support static initialization. This is a
21643regression with respect to <tt>pthread_mutex_t</tt>, which does. I believe that
21644we should strive to eliminate such regressions in expressive power where
21645possible, both to ease migration and to not provide incentives to (or
21646force) people to forego the C++ primitives in favor of pthreads.
21647</p>
21648
21649<p><i>[
21650Sophia Antipolis:
21651]</i></p>
21652
21653
21654<blockquote>
21655<p>
21656We believe this is implementable on POSIX, because the initializer-list
21657feature and the constexpr feature make this work. Double-check core
21658language about static initialization for this case. Ask core for a core
21659issue about order of destruction of statically-initialized objects wrt.
21660dynamically-initialized objects (should come afterwards). Check
21661non-POSIX systems for implementability.
21662</p>
21663<p>
21664If ubiquitous implementability cannot be assured, plan B is to introduce
21665another constructor, make this constexpr, which is
21666conditionally-supported. To avoid ambiguities, this new constructor needs
21667to have an additional parameter.
21668</p>
21669</blockquote>
21670
21671<p><i>[
21672Post Summit:
21673]</i></p>
21674
21675
21676<blockquote>
21677<p>
21678Jens: constant initialization seems to be ok core-language wise
21679</p>
21680<p>
21681Consensus: Defer to threading experts, in particular a Microsoft platform expert.
21682</p>
21683<p>
21684Lawrence to send e-mail to Herb Sutter, Jonathan Caves, Anthony Wiliams,
21685Paul McKenney, Martin Tasker, Hans Boehm, Bill Plauger, Pete Becker,
21686Peter Dimov to alert them of this issue.
21687</p>
21688<p>
21689Lawrence: What about header file shared with C? The initialization
21690syntax is different in C and C++.
21691</p>
21692<p>
21693Recommend Keep in Review
21694</p>
21695</blockquote>
21696
21697<p><i>[
21698Batavia (2009-05):
21699]</i></p>
21700
21701<blockquote>
21702Keep in Review status pending feedback from members of the Concurrency subgroup.
21703</blockquote>
21704
21705<p><i>[
21706See related comments from Alisdiar and Daniel in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#827">827</a>.
21707]</i></p>
21708
21709
21710<p><i>[
217112009-10 Santa Cruz:
21712]</i></p>
21713
21714
21715<blockquote>
21716NAD Editorial.  Solved by
21717<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2994.html">N2994</a>.
21718</blockquote>
21719
21720
21721
21722<p><b>Proposed resolution:</b></p>
21723<p>
21724Change 30.4.1.1 [thread.mutex.class]:
21725</p>
21726
21727<blockquote><pre>class mutex {
21728public:
21729  <ins>constexpr</ins> mutex();
21730  ...
21731</pre></blockquote>
21732
21733
21734
21735
21736
21737<hr>
21738<h3><a name="830"></a>830. Incomplete list of char_traits specializations</h3>
21739<p><b>Section:</b> 21.2 [char.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
21740 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 2008-04-23  <b>Last modified:</b> 2009-07-13</p>
21741<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits">issues</a> in [char.traits].</p>
21742<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
21743<p><b>Discussion:</b></p>
21744<p>
21745  Paragraph 4 of 21.2 [char.traits] mentions that this
21746  section specifies two specializations (<code>char_traits&lt;char&gt;</code>
21747  and (<code>char_traits&lt;wchar_t&gt;</code>). However, there are actually
21748  four specializations provided, i.e. in addition to the two above also
21749  <code>char_traits&lt;char16_t&gt;</code> and <code>char_traits&lt;char32_t&gt;</code>).
21750  I guess this was just an oversight and there is nothing wrong with just
21751  fixing this.
21752</p>
21753
21754<p><i>[
21755Alisdair adds:
21756]</i></p>
21757
21758<blockquote>
21759<tt>char_traits&lt; char16/32_t &gt;</tt>
21760should also be added to <tt>&lt;ios_fwd&gt;</tt> in 27.3 [iostream.forward], and all the specializations
21761taking a <tt>char_traits</tt> parameter in that header.
21762</blockquote>
21763
21764<p><i>[
21765Sophia Antipolis:
21766]</i></p>
21767
21768
21769<blockquote>
21770<p>
21771Idea of the issue is ok.
21772</p>
21773<p>
21774Alisdair to provide wording, once that wording arrives, move to review.
21775</p>
21776
21777</blockquote>
21778
21779<p><i>[
217802009-05-04 Alisdair adds:
21781]</i></p>
21782
21783
21784<blockquote>
21785<p>
21786The main point of the issue was resolved editorially in
21787<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>,
21788so we are
21789close to NAD Editorial.
21790However, exploring the issue we found a second tweak was necessary for
21791<tt>&lt;iosfwd&gt;</tt> and that is still outstanding, so here are the words I am long
21792overdue delivering:
21793</p>
21794
21795<p><i>[
21796Howard:  I've put Alisdair's words into the proposed wording section and
21797moved the issue to Review.
21798]</i></p>
21799
21800
21801</blockquote>
21802
21803<p><i>[
21804Original proposed wording.
21805]</i></p>
21806
21807
21808<blockquote>
21809
21810<p>
21811  Replace paragraph 4 of 21.2 [char.traits] by:
21812</p>
21813<blockquote>
21814<p>
21815  This subclause specifies a struct template, <code>char_traits&lt;charT&gt;</code>,
21816  and four explicit specializations of it, <code>char_traits&lt;char&gt;</code>,
21817  <code>char_traits&lt;char16_t&gt;</code>, <code>char_traits&lt;char32_t&gt;</code>, and
21818  <code>char_traits&lt;wchar_t&gt;</code>, all of which appear in the header
21819  &lt;string&gt; and satisfy the requirements below.
21820</p>
21821</blockquote>
21822</blockquote>
21823
21824<p><i>[
21825Batavia (2009-05):
21826]</i></p>
21827
21828<blockquote>
21829We agree.  Move to NAD Editorial.
21830</blockquote>
21831
21832
21833<p><b>Proposed resolution:</b></p>
21834<p>
21835Change Forward declarations 27.3 [iostream.forward]:
21836</p>
21837
21838<blockquote>
21839<p>
21840<b>Header <tt>&lt;iosfwd&gt;</tt> synopsis</b>
21841</p>
21842<pre>namespace std {
21843   template&lt;class charT&gt; class char_traits;
21844   template&lt;&gt; class char_traits&lt;char&gt;;
21845   <ins>template&lt;&gt; class char_traits&lt;char16_t&gt;;</ins>
21846   <ins>template&lt;&gt; class char_traits&lt;char32_t&gt;;</ins>
21847   template&lt;&gt; class char_traits&lt;wchar_t&gt;;
21848...
21849}
21850</pre>
21851</blockquote>
21852
21853
21854
21855
21856
21857<hr>
21858<h3><a name="831"></a>831. wrong type for not_eof()</h3>
21859<p><b>Section:</b> 21.2.3 [char.traits.specializations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
21860 <b>Submitter:</b> Dietmar K�hl <b>Opened:</b> 2008-04-23  <b>Last modified:</b> 2008-06-19</p>
21861<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits.specializations">issues</a> in [char.traits.specializations].</p>
21862<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
21863<p><b>Discussion:</b></p>
21864<p>
21865  In Table 56 (Traits requirements) the <tt>not_eof()</tt> member function
21866  is using an argument of type <i>e</i> which denotes an object of
21867  type <code>X::int_type</code>. However, the specializations in
21868  21.2.3 [char.traits.specializations] all use <code>char_type</code>.
21869  This would effectively mean that the argument type actually can't
21870  represent EOF in the first place. I'm pretty sure that the type used
21871  to be <code>int_type</code> which is quite obviously the only sensible
21872  argument.
21873</p>
21874<p>
21875  This issue is close to being editorial. I suspect that the proposal
21876  changing this section to include the specializations for <code>char16_t</code>
21877  and <code>char32_t</code> accidentally used the wrong type.
21878</p>
21879
21880
21881<p><b>Proposed resolution:</b></p>
21882<p>
21883  In 21.2.3.1 [char.traits.specializations.char],
21884  21.2.3.2 [char.traits.specializations.char16_t],
21885  21.2.3.3 [char.traits.specializations.char32_t], and
21886   [char.traits.specializations.wchar_t] correct the
21887  argument type from <code>char_type</code> to <code>int_type</code>.
21888</p>
21889
21890
21891<p><b>Rationale:</b></p>
21892Already fixed in WP.
21893
21894
21895
21896
21897
21898<hr>
21899<h3><a name="832"></a>832. Applying constexpr to System error support</h3>
21900<p><b>Section:</b> 19.5 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
21901 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-05-14  <b>Last modified:</b> 2008-09-17</p>
21902<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p>
21903<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
21904<p><b>Discussion:</b></p>
21905<p>
21906Initialization of objects of class <tt>error_code</tt>
21907(19.5.2 [syserr.errcode]) and class
21908<tt>error_condition</tt> (19.5.3 [syserr.errcondition]) can be made simpler and more reliable by use of
21909the new <tt>constexpr</tt> feature 
21910[<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2349.pdf">N2349</a>]
21911of C++0x. Less code will need to be
21912generated for both library implementations and user programs when
21913manipulating constant objects of these types. 
21914</p>
21915
21916<p>
21917This was not proposed originally because the constant expressions
21918proposal was moving into the standard at about the same time as the
21919Diagnostics Enhancements proposal 
21920[<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html">N2241</a>],
21921and it wasn't desirable to
21922make the later depend on the former. There were also technical concerns
21923as to how <tt>constexpr</tt> would apply to references. Those concerns are now
21924resolved; <tt>constexpr</tt> can't be used for references, and that fact is
21925reflected in the proposed resolution.
21926</p>
21927
21928<p>
21929Thanks to Jens Maurer, Gabriel Dos Reis, and Bjarne Stroustrup for clarification of <tt>constexpr</tt> requirements.
21930</p>
21931
21932<p>
21933LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a> is related in that it raises the question of whether the
21934exposition only member <tt>cat_</tt> of class <tt>error_code</tt> (19.5.2 [syserr.errcode]) and class
21935<tt>error_condition</tt> (19.5.3 [syserr.errcondition]) should be presented as a reference or pointer.
21936While in the context of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#804">804</a> that is arguably an editorial question,
21937presenting it as a pointer becomes more or less required with this
21938proposal, given <tt>constexpr</tt> does not play well with references. The
21939proposed resolution thus changes the private member to a pointer, which
21940also brings it in sync with real implementations.
21941</p>
21942
21943<p><i>[
21944Sophia Antipolis:
21945]</i></p>
21946
21947
21948<blockquote>
21949On going question of extern pointer vs. inline functions for interface.
21950</blockquote>
21951
21952<p><i>[
21953Pre-San Francisco:
21954]</i></p>
21955
21956
21957<blockquote>
21958<p>
21959Beman Dawes reports that this proposal is unimplementable, and thus NAD.
21960</p>
21961<p>
21962Implementation would require <tt>constexpr</tt> objects of classes derived
21963from class <tt>error_category</tt>, which has virtual functions, and that is
21964not allowed by the core language. This was determined when trying to
21965implement the proposal using a constexpr enabled compiler provided
21966by Gabriel Dos Reis, and subsequently verified in discussions with
21967Gabriel and Jens Maurer.
21968</p>
21969
21970</blockquote>
21971
21972
21973<p><b>Proposed resolution:</b></p>
21974<p>
21975The proposed wording assumes the LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a> proposed wording has been
21976applied to the WP, resulting in the former <tt>posix_category</tt> being renamed
21977<tt>generic_category</tt>. If <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#805">805</a> has not been applied, the names in this
21978proposal must be adjusted accordingly.
21979</p>
21980
21981<p>
21982Change 19.5.1.1 [syserr.errcat.overview] Class
21983<tt>error_category</tt> overview <tt>error_category</tt> synopsis  as
21984indicated:
21985</p>
21986
21987<blockquote><pre><del>const error_category&amp; get_generic_category();</del>
21988<del>const error_category&amp; get_system_category();</del>
21989
21990<del>static</del> <ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> generic_category<del> = get_generic_category()</del>;
21991<del>static</del> <ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> <del>native_category</del> system_category<del> = get_system_category()</del>;
21992</pre></blockquote>
21993
21994<p>
21995Change 19.5.1.5 [syserr.errcat.objects] Error category objects as indicated:
21996</p>
21997
21998<blockquote>
21999<pre><ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> <del>get_</del>generic_category<del>()</del>;
22000</pre>
22001<p>
22002<del><i>Returns:</i> A reference</del> <ins><tt>generic_category</tt> shall point</ins>
22003to <del>an</del> <ins>a statically initialized</ins> object of a type derived from
22004class <tt>error_category</tt>.
22005</p>
22006
22007<p>
22008<del><i>Remarks:</i></del> The object's <tt>default_error_condition</tt> and <tt>equivalent</tt> virtual
22009functions shall behave as specified for the class <tt>error_category</tt>. The
22010object's <tt>name</tt> virtual function shall return a pointer to the string
22011<tt>"GENERIC"</tt>.
22012</p>
22013
22014<pre><ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> <del>get_</del>system_category<del>()</del>;
22015</pre>
22016
22017<p>
22018<del><i>Returns:</i> A reference</del> <ins><tt>system_category</tt> shall point</ins>
22019to <del>an</del> <ins>a statically
22020initialized</ins> object of a type derived from class <tt>error_category</tt>.
22021</p>
22022
22023<p>
22024<del><i>Remarks:</i></del>  The object's <tt>equivalent</tt> virtual functions shall behave as
22025specified for class <tt>error_category</tt>. The object's <tt>name</tt> virtual function
22026shall return a pointer to the string <tt>"system"</tt>. The object's
22027<tt>default_error_condition</tt> virtual function shall behave as follows:
22028</p>
22029
22030<p>
22031If the argument <tt>ev</tt> corresponds to a POSIX <tt>errno</tt> value <tt>posv</tt>, the function
22032shall return <tt>error_condition(posv, generic_category)</tt>. Otherwise, the
22033function shall return <tt>error_condition(ev, system_category)</tt>. What
22034constitutes correspondence for any given operating system is
22035unspecified. [<i>Note:</i> The number of potential system error codes is large
22036and unbounded, and some may not correspond to any POSIX <tt>errno</tt> value.
22037Thus implementations are given latitude in determining correspondence.
22038<i>-- end note</i>]
22039</p>
22040</blockquote>
22041
22042<p>
22043Change 19.5.2.1 [syserr.errcode.overview] Class <tt>error_code</tt> overview as indicated:
22044</p>
22045
22046<blockquote><pre>class error_code {
22047public:
22048  ...;
22049  <ins>constexpr</ins> error_code(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
22050  ...
22051  void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
22052  ...
22053  const error_category<del>&amp;</del><ins>*</ins> category() const;
22054  ...
22055private:
22056  int val_;                    // exposition only
22057  const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
22058</pre></blockquote>
22059
22060<p>
22061Change 19.5.2.2 [syserr.errcode.constructors] Class <tt>error_code</tt> constructors as indicated:
22062</p>
22063
22064<blockquote>
22065<pre><ins>constexpr</ins> error_code(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
22066</pre>
22067<p>
22068<i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
22069</p>
22070<p>
22071<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
22072</p>
22073<p>
22074<i>Throws:</i> Nothing.
22075</p>
22076</blockquote>
22077
22078<p>
22079Change 19.5.2.3 [syserr.errcode.modifiers] Class <tt>error_code</tt> modifiers  as indicated:
22080</p>
22081
22082<blockquote>
22083<pre>void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
22084</pre>
22085<p>
22086<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
22087</p>
22088<p>
22089<i>Throws:</i> Nothing.
22090</p>
22091</blockquote>
22092
22093<p>
22094Change 19.5.2.4 [syserr.errcode.observers] Class <tt>error_code</tt> observers  as indicated:
22095</p>
22096
22097<blockquote>
22098<pre>const error_category<del>&amp;</del><ins>*</ins> category() const;
22099</pre>
22100
22101<p>
22102<i>Returns:</i> <tt>cat_</tt>.
22103</p>
22104<p>
22105<i>Throws:</i> Nothing.
22106</p>
22107</blockquote>
22108
22109<p>
22110Change 19.5.3.1 [syserr.errcondition.overview] Class <tt>error_condition</tt> overview   as indicated:
22111</p>
22112
22113<blockquote>
22114<pre>class error_condition {
22115public:
22116  ...;
22117  <ins>constexpr</ins> error_condition(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
22118  ...
22119  void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
22120  ...
22121  const error_category<del>&amp;</del><ins>*</ins> category() const;
22122  ...
22123private:
22124  int val_;                    // exposition only
22125  const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
22126</pre>
22127</blockquote>
22128
22129<p>
22130Change 19.5.3.2 [syserr.errcondition.constructors] Class <tt>error_condition</tt> constructors as indicated:
22131</p>
22132
22133<blockquote>
22134<pre><ins>constexpr</ins> error_condition(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
22135</pre>
22136<p>
22137<i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
22138</p>
22139<p>
22140<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
22141</p>
22142<p>
22143<i>Throws:</i> Nothing.
22144</p>
22145</blockquote>
22146
22147<p>
22148Change 19.5.3.3 [syserr.errcondition.modifiers] Class <tt>error_condition</tt> modifiers as indicated:
22149</p>
22150
22151<blockquote>
22152<pre>void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
22153</pre>
22154<p>
22155<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
22156</p>
22157<p>
22158<i>Throws:</i> Nothing.
22159</p>
22160</blockquote>
22161
22162<p>
22163Change 19.5.3.4 [syserr.errcondition.observers] Class <tt>error_condition</tt> observers as indicated:
22164</p>
22165
22166<blockquote>
22167<pre>const error_category<del>&amp;</del><ins>*</ins> category() const;
22168</pre>
22169<p>
22170<i>Returns:</i> <tt>cat_</tt>.
22171</p>
22172<p>
22173<i>Throws:</i> Nothing.
22174</p>
22175</blockquote>
22176
22177<p>
22178Throughout 19.5 [syserr] System error support, change "<tt>category().</tt>"  to "<tt>category()-&gt;</tt>".
22179Appears approximately six times.
22180</p>
22181
22182<p>
22183<i>[Partially Editorial]</i> In 19.5.4 [syserr.compare] Comparison operators,
22184paragraphs 2 and 4, change "<tt>category.equivalent(</tt>"  to
22185"<tt>category()-&gt;equivalent(</tt>".
22186</p>
22187
22188<p>
22189Change 19.5.5.1 [syserr.syserr.overview] Class system_error overview as indicated:
22190</p>
22191
22192<blockquote><pre>public:
22193  system_error(error_code ec, const string&amp; what_arg);
22194  system_error(error_code ec);
22195  system_error(int ev, const error_category<del>&amp;</del><ins>*</ins> ecat,
22196      const string&amp; what_arg);
22197  system_error(int ev, const error_category<del>&amp;</del><ins>*</ins> ecat);
22198</pre></blockquote>
22199
22200<p>
22201Change 19.5.5.2 [syserr.syserr.members] Class system_error members as indicated:
22202</p>
22203
22204<blockquote>
22205<pre>system_error(int ev, const error_category<del>&amp;</del><ins>*</ins> ecat, const string&amp; what_arg);
22206</pre>
22207<blockquote>
22208<p>
22209<i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
22210</p>
22211<p>
22212<i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and
22213<tt>strcmp(runtime_error::what(), what_arg.c_str()) == 0</tt>.
22214</p>
22215</blockquote>
22216
22217<pre>system_error(int ev, const error_category<del>&amp;</del><ins>*</ins> ecat);
22218</pre>
22219<blockquote>
22220<p>
22221<i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
22222</p>
22223<p>
22224<i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and
22225<tt>strcmp(runtime_error::what(), "") == 0</tt>.
22226</p>
22227</blockquote>
22228</blockquote>
22229
22230
22231
22232<p><b>Rationale:</b></p>
22233<p><i>[
22234San Francisco:
22235]</i></p>
22236
22237
22238<blockquote>
22239NAD because Beman said so.
22240</blockquote>
22241
22242
22243
22244
22245
22246<hr>
22247<h3><a name="833"></a>833. Freestanding implementations header list needs review for C++0x</h3>
22248<p><b>Section:</b> 17.6.1.3 [compliance] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
22249 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-05-14  <b>Last modified:</b> 2009-07-16</p>
22250<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#compliance">issues</a> in [compliance].</p>
22251<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
22252<p><b>Discussion:</b></p>
22253<p>
22254Once the C++0x standard library is feature complete, the LWG needs to
22255review 17.6.1.3 [compliance] Freestanding implementations header list to
22256ensure it reflects LWG consensus.
22257</p>
22258
22259<p><i>[
22260San Francisco:
22261]</i></p>
22262
22263
22264<blockquote>
22265<p>
22266This is a placeholder defect to remind us to review the table once we've
22267stopped adding headers to the library.
22268</p>
22269<p>
22270Three new headers that need to be added to the list:
22271</p>
22272<blockquote><pre>&lt;initializer_list&gt; &lt;concept&gt; &lt;iterator_concepts&gt;
22273</pre></blockquote>
22274<p>
22275<tt>&lt;iterator_concepts&gt;</tt>, in particular, has lots of stuff
22276that isn't needed, so maybe the stuff that is needed should be broken
22277out into a separate header.
22278</p>
22279<p>
22280Robert: What about <tt>reference_closure</tt>? It's currently in
22281<tt>&lt;functional&gt;</tt>.
22282</p>
22283</blockquote>
22284
22285<p><i>[
22286Post Summit Daniel adds:
22287]</i></p>
22288
22289
22290<blockquote>
22291<ol>
22292<li>
22293The comment regarding <tt>reference_closure</tt> seems moot since it was just
22294recently decided to remove that.
22295</li>
22296<li>
22297A reference to proposal
22298<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2814.pdf">N2814</a>
22299("Fixing freestanding") should be added. This
22300paper e.g. proposes to add only <tt>&lt;initializer_list&gt;</tt> to the include list
22301of freestanding.
22302</li>
22303</ol>
22304</blockquote>
22305
22306<p><i>[
223072009-07 Frankfurt:
22308]</i></p>
22309
22310
22311<blockquote>
22312<p>
22313Addressed by paper
22314<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2814.pdf">N2814</a>.
22315</p>
22316<p>
22317Move to NAD.
22318</p>
22319</blockquote>
22320
22321
22322
22323<p><b>Proposed resolution:</b></p>
22324
22325
22326
22327
22328
22329<hr>
22330<h3><a name="837"></a>837. 
22331   <code>basic_ios::copyfmt()</code> overly loosely specified
22332 </h3>
22333<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#NAD%20Editorial">NAD Editorial</a>
22334 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-05-17  <b>Last modified:</b> 2009-07-13</p>
22335<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>
22336<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>
22337<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
22338<p><b>Discussion:</b></p>
22339   <p>
22340
22341The <code>basic_ios::copyfmt()</code> member function is specified in 27.5.4.2 [basic.ios.members] to have the following effects:
22342
22343   </p>
22344   <blockquote>
22345
22346<i>Effects</i>: If <code>(this == &amp;rhs)</code> does
22347nothing. Otherwise assigns to the member objects of <code>*this</code>
22348the corresponding member objects of <code>rhs</code>, except that
22349
22350     <ul>
22351       <li>
22352
22353<code>rdstate()</code> and <code>rdbuf()</code> are left unchanged;
22354
22355       </li>
22356       <li>
22357
22358<code>exceptions()</code> is altered last by
22359calling <code>exceptions(rhs.except)</code>
22360
22361       </li>
22362       <li>
22363
22364the contents of arrays pointed at by <code>pword</code>
22365and <code>iword</code> are copied not the pointers themselves
22366
22367       </li>
22368     </ul>
22369   </blockquote>
22370   <p>
22371
22372Since the rest of the text doesn't specify what the member objects
22373of <code>basic_ios</code> are this seems a little too loose.
22374
22375</p>
22376
22377<p><i>[
22378Batavia (2009-05):
22379]</i></p>
22380
22381<blockquote>
22382We agree with the proposed resolution.
22383Move to NAD Editorial.
22384</blockquote>
22385
22386
22387<p><b>Proposed resolution:</b></p>
22388<p>
22389
22390I propose to tighten things up by adding a <i>Postcondition</i> clause
22391to the function like so:
22392
22393   </p>
22394   <blockquote>
22395     <i>Postconditions:</i>
22396
22397     <table border="1">
22398       <thead>
22399         <tr>
22400           <th colspan="2"><code>copyfmt()</code> postconditions</th>
22401         </tr>
22402         <tr>
22403           <th>Element</th>
22404           <th>Value</th>
22405         </tr>
22406       </thead>
22407       <tbody>
22408         <tr>
22409           <td><code>rdbuf()</code></td>
22410           <td><i>unchanged</i></td>
22411         </tr>
22412         <tr> 
22413           <td><code>tie()</code></td>
22414           <td><code>rhs.tie()</code></td>
22415         </tr>
22416         <tr> 
22417           <td><code>rdstate()</code></td>
22418           <td><i>unchanged</i></td>
22419         </tr>
22420         <tr> 
22421           <td><code>exceptions()</code></td>
22422           <td><code>rhs.exceptions()</code></td>
22423         </tr>
22424         <tr> 
22425           <td><code>flags()</code></td>
22426           <td><code>rhs.flags()</code></td>
22427         </tr>
22428         <tr> 
22429           <td><code>width()</code></td>
22430           <td><code>rhs.width()</code></td>
22431         </tr>
22432         <tr> 
22433           <td><code>precision()</code></td>
22434           <td><code>rhs.precision()</code></td>
22435         </tr>
22436         <tr> 
22437           <td><code>fill()</code></td>
22438           <td><code>rhs.fill()</code></td>
22439         </tr>
22440         <tr> 
22441           <td><code>getloc()</code></td>
22442           <td><code>rhs.getloc()</code></td>
22443         </tr>
22444       </tbody>
22445     </table>
22446   </blockquote>
22447   <p>
22448
22449The format of the table follows Table 117 (as
22450of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2588.pdf">N2588</a>): <code>basic_ios::init()</code>
22451effects.
22452
22453   </p>
22454   <p>
22455
22456The intent of the new table is not to impose any new requirements or
22457change existing ones, just to be more explicit about what I believe is
22458already there.
22459
22460   </p>
22461 
22462
22463
22464
22465<hr>
22466<h3><a name="839"></a>839. Maps and sets missing splice operation</h3>
22467<p><b>Section:</b> 23.4 [associative], 23.5 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
22468 <b>Submitter:</b> Alan Talbot <b>Opened:</b> 2008-05-18  <b>Last modified:</b> 2009-09-20</p>
22469<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative">issues</a> in [associative].</p>
22470<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
22471<p><b>Discussion:</b></p>
22472<p>
22473Splice is a very useful feature of <tt>list</tt>. This functionality is also very
22474useful for any other node based container, and I frequently wish it were
22475available for maps and sets. It seems like an omission that these
22476containers lack this capability. Although the complexity for a splice is
22477the same as for an insert, the actual time can be much less since the
22478objects need not be reallocated and copied. When the element objects are
22479heavy and the compare operations are fast (say a <tt>map&lt;int, huge_thingy&gt;</tt>)
22480this can be a big win.
22481</p>
22482
22483<p>
22484<b>Suggested resolution:</b>
22485</p>
22486
22487<p>
22488Add the following signatures to map, set, multimap, multiset, and the unordered associative containers:
22489</p>
22490<blockquote><pre> 
22491void splice(list&lt;T,Allocator&gt;&amp;&amp; x);
22492void splice(list&lt;T,Allocator&gt;&amp;&amp; x, const_iterator i);
22493void splice(list&lt;T,Allocator&gt;&amp;&amp; x, const_iterator first, const_iterator last);
22494</pre></blockquote>
22495
22496<p>
22497Hint versions of these are also useful to the extent hint is useful.
22498(I'm looking for guidance about whether hints are in fact useful.)
22499</p>
22500 
22501<blockquote><pre> 
22502void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x);
22503void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x, const_iterator i);
22504void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x, const_iterator first, const_iterator last);
22505</pre></blockquote>
22506
22507<p><i>[
22508Sophia Antipolis:
22509]</i></p>
22510
22511
22512<blockquote>
22513<p>
22514Don't try to <tt>splice "list"</tt> into the other containers, it should be container-type.
22515</p>
22516<p>
22517<tt>forward_list</tt> already has <tt>splice_after</tt>.
22518</p>
22519<p>
22520Would "<tt>splice</tt>" make sense for an <tt>unordered_map</tt>?
22521</p>
22522<p>
22523Jens, Robert: "<tt>splice</tt>" is not the right term, it implies maintaining ordering in <tt>list</tt>s.
22524</p>
22525<p>
22526Howard: <tt>adopt</tt>?
22527</p>
22528<p>
22529Jens: <tt>absorb</tt>?
22530</p>
22531<p>
22532Alan: <tt>subsume</tt>?
22533</p>
22534<p>
22535Robert: <tt>recycle</tt>?
22536</p>
22537<p>
22538Howard: <tt>transfer</tt>? (but no direction)
22539</p>
22540<p>
22541Jens: <tt>transfer_from</tt>. No.
22542</p>
22543<p>
22544Alisdair: Can we give a nothrow guarantee? If your <tt>compare()</tt> and <tt>hash()</tt> doesn't throw, yes.
22545</p>
22546<p>
22547Daniel: For <tt>unordered_map</tt>, we can't guarantee nothrow.
22548</p>
22549</blockquote>
22550
22551<p><i>[
22552San Francisco:
22553]</i></p>
22554
22555
22556<blockquote>
22557<p>
22558Martin: this would possibly outlaw an implementation technique that is
22559currently in use; caching nodes in containers.
22560</p>
22561<p>
22562Alan: if you cache in the allocator, rather than the individual
22563container, this proposal doesn't interfere with that.
22564</p>
22565<p>
22566Martin: I'm not opposed to this, but I'd like to see an implementation
22567that demonstrates that it works.
22568</p>
22569</blockquote>
22570
22571<p><i>[
225722009-07 Frankfurt:
22573]</i></p>
22574
22575
22576<blockquote>
22577NAD Future.
22578</blockquote>
22579
22580<p><i>[
225812009-09-19 Howard adds:
22582]</i></p>
22583
22584
22585<blockquote>
22586<p>
22587I'm not disagreeing with the NAD Future resolution.  But when the future gets
22588here, here is a possibility worth exploring:
22589</p>
22590
22591<blockquote>
22592<p>
22593Add to the "unique" associative containers:
22594</p>
22595
22596<blockquote><pre>typedef <i>details</i>      node_ptr;
22597
22598node_ptr             remove(const_iterator p);
22599pair&lt;iterator, bool&gt; insert(node_ptr&amp;&amp; nd);
22600iterator             insert(const_iterator p, node_ptr&amp;&amp; nd);
22601</pre></blockquote>
22602
22603<p>
22604And add to the "multi" associative containers:
22605</p>
22606
22607<blockquote><pre>typedef <i>details</i> node_ptr;
22608
22609node_ptr remove(const_iterator p);
22610iterator insert(node_ptr&amp;&amp; nd);
22611iterator insert(const_iterator p, node_ptr&amp;&amp; nd);
22612</pre></blockquote>
22613
22614<p>
22615<tt>Container::node_ptr</tt> is a smart pointer much like <tt>unique_ptr</tt>.
22616It owns a node obtained from the container it was removed from.  It maintains a
22617reference to the allocator in the container so that it can properly deallocate
22618the node if asked to, even if the allocator is stateful.  This being said, the
22619<tt>node_ptr</tt> can not outlive the container for this reason.
22620</p>
22621
22622<p>
22623The <tt>node_ptr</tt> offers "<tt>const</tt>-free" access to the node's
22624<tt>value_type</tt>.
22625</p>
22626
22627<p>
22628With this interface, clients have a great deal of flexibility:
22629</p>
22630
22631<ul>
22632<li>
22633A client can remove a node from one container, and insert it into another
22634(without any heap allocation).  This is the splice functionality this issue
22635asks for.
22636</li>
22637<li>
22638A client can remove a node from a container, change its key or value, and insert
22639it back into the same container, or another container, all without the cost of
22640allocating a node.
22641</li>
22642<li>
22643If the Compare function is nothrow (which is very common), then this functionality
22644is nothrow unless modifying the value throws.  And if this does throw, it does
22645so outside of the containers involved.
22646</li>
22647<li>
22648If the Compare function does throw, the <tt>insert</tt> function will have the
22649argument <tt>nd</tt> retain ownership of the node.
22650</li>
22651<li>
22652The <tt>node_ptr</tt> should be independent of the <tt>Compare</tt> parameter
22653so that a node can be transferred from <tt>set&lt;T, C1, A&gt;</tt>
22654to <tt>set&lt;T, C2, A&gt;</tt> (for example).
22655</li>
22656</ul>
22657
22658<p>
22659Here is how the customer might use this functionality:
22660</p>
22661
22662<ul>
22663<li>
22664<p>
22665Splice a node from one container to another:
22666</p>
22667<blockquote><pre>m2.insert(m1.remove(i));
22668</pre></blockquote>
22669</li>
22670
22671<li>
22672<p>
22673Change the "key" in a <tt>std::map</tt> without the cost of node reallocation:
22674</p>
22675<blockquote><pre>auto p = m.remove(i);
22676p-&gt;first = new_key;
22677m.insert(std::move(p));
22678</pre></blockquote>
22679</li>
22680
22681<li>
22682<p>
22683Change the "value" in a <tt>std::set</tt> without the cost of node reallocation:
22684</p>
22685<blockquote><pre>auto p = s.remove(i);
22686*p = new_value;
22687s.insert(std::move(p));
22688</pre></blockquote>
22689</li>
22690
22691<li>
22692<p>
22693Move a move-only or heavy object out of an associative container (as opposed to
22694the proposal in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1041">1041</a>):
22695</p>
22696<blockquote><pre>MoveOnly x = std::move(*s.remove(i));
22697</pre></blockquote>
22698<ol>
22699<li>
22700<tt>remove(i)</tt> transfers ownership of the node from the set to a temporary
22701<tt>node_ptr</tt>.
22702</li>
22703<li>
22704The <tt>node_ptr</tt> is dereferenced, and that non-const reference is sent to
22705<tt>move</tt> to cast it to an rvalue.
22706</li>
22707<li>
22708The rvalue <tt>MoveOnly</tt> is move constructed into <tt>x</tt> from
22709the <tt>node_ptr</tt>.
22710</li>
22711<li>
22712<tt>~node_ptr()</tt> destructs the moved-from <tt>MoveOnly</tt> and deallocates
22713the node.
22714</li>
22715</ol>
22716
22717<p>
22718Contrast this with the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1041">1041</a> solution:
22719</p>
22720<blockquote><pre>MoveOnly x = std::move(s.extract(i).first);
22721</pre></blockquote>
22722
22723<p>
22724The former requires one move construction for <tt>x</tt> while the latter
22725requires two (one into the <tt>pair</tt> and then one into <tt>x</tt>).  Either
22726of these constructions can throw (say if there is only a copy constructor for
22727<tt>x</tt>).  With the former, the point of throw is outside of the container
22728<tt>s</tt>, after the element has been removed from the container.  With the latter,
22729one throwing construction takes place prior to the removal of the element, and
22730the second takes place after the element is removed.
22731</p>
22732
22733</li>
22734</ul>
22735
22736<p>
22737The "node insertion" API maintains the API associated with inserting <tt>value_type</tt>s
22738so the customer can use familiar techniques for getting an iterator to the 
22739inserted node, or finding out whether it was inserted or not for the "unique"
22740containers.
22741</p>
22742
22743<p>
22744Lightly prototyped.  No implementation problems.  Appears to work great
22745for the client.
22746</p>
22747
22748</blockquote>
22749</blockquote>
22750
22751
22752
22753<p><b>Proposed resolution:</b></p>
22754
22755
22756
22757
22758
22759<hr>
22760<h3><a name="840"></a>840. <tt>pair</tt> default template argument</h3>
22761<p><b>Section:</b> 20.3.4 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
22762 <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2008-05-23  <b>Last modified:</b> 2008-06-18</p>
22763<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>
22764<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>
22765<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
22766<p><b>Discussion:</b></p>
22767<p>
22768I have one issue with <tt>std::pair</tt>. Well, it might just be a very annoying
22769historical accident, but why is there no default template argument for
22770the second template argument? This is so annoying when the type in
22771question is looong and hard to write (type deduction with <tt>auto</tt> won't
22772help those cases where we use it as a return or argument type).
22773</p>
22774
22775
22776<p><b>Proposed resolution:</b></p>
22777<p>
22778Change the synopsis in 20.3 [utility] to read:
22779</p>
22780
22781<blockquote><pre>template &lt;class T1, class T2 <ins>= T1</ins>&gt; struct pair;
22782</pre></blockquote>
22783
22784<p>
22785Change 20.3.4 [pairs] to read:
22786</p>
22787
22788<blockquote><pre>namespace std {
22789 template &lt;class T1, class T2 <ins>= T1</ins>&gt;
22790 struct pair {
22791   typedef T1 first_type;
22792   typedef T2 second_type;
22793   ...
22794</pre></blockquote>
22795
22796
22797<p><b>Rationale:</b></p>
22798<tt>std::pair</tt> is a heterogeneous container.
22799
22800
22801
22802
22803
22804<hr>
22805<h3><a name="841"></a>841. cstdint.syn inconsistent with C99</h3>
22806<p><b>Section:</b> 18.4.1 [cstdint.syn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
22807 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-05-17  <b>Last modified:</b> 2008-09-17</p>
22808<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint.syn">issues</a> in [cstdint.syn].</p>
22809<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
22810<p><b>Discussion:</b></p>
22811   <p>
22812
22813In specifying the names of macros and types defined in
22814header <code>&lt;stdint.h&gt;</code>, C99 makes use of the
22815symbol <code><i>N</i></code> to accommodate unusual platforms with
22816word sizes that aren't powers of two. C99
22817permits <code><i>N</i></code> to take on any positive integer value
22818(including, for example, 24).
22819
22820   </p>
22821   <p>
22822
22823In  cstdint.syn Header <code>&lt;cstdint&gt;</code>
22824synopsis, C++ on the other hand, fixes the value
22825of <code><i>N</i></code> to 8, 16, 32, and 64, and specifies only
22826types with these exact widths. 
22827
22828   </p>
22829   <p>
22830   </p>
22831
22832In addition, paragraph 1 of the same section makes use of a rather
22833informal shorthand notation to specify sets of macros. When
22834interpreted strictly, the notation specifies macros such
22835as <code>INT_8_MIN</code> that are not intended to be specified.
22836
22837   <p>
22838
22839Finally, the section is missing the usual table of symbols defined
22840in that header, making it inconsistent with the rest of the
22841specification.
22842
22843   </p>
22844 
22845 <p><b>Proposed resolution:</b></p>
22846   <p>
22847
22848I propose to use the same approach in the C++ spec as C99 uses, that
22849is, to specify the header synopsis in terms of "exposition only" types
22850that make use of the symbol <code><i>N</i></code> to denote one or
22851more of a theoretically unbounded set of widths.
22852
22853   </p>
22854   <p>
22855
22856Further, I propose to add a new table to section listing the symbols
22857defined in the header using a more formal notation that avoids
22858introducing inconsistencies.
22859
22860   </p>
22861   <p>
22862
22863To this effect, in  cstdint.syn
22864Header <code>&lt;cstdint&gt;</code> synopsis, replace both the
22865synopsis and paragraph 1 with the following text:
22866
22867   </p>
22868   <blockquote>
22869     <p>
22870       </p><ol>
22871         <li>
22872
22873In the names defined in the <code>&lt;cstdint&gt;</code> header, the
22874symbol <code><i>N</i></code> represents a positive decimal integer
22875with no leading zeros (e.g., 8 or 24, but not 0, 04, or 048). With the
22876exception of exact-width types, macros and types for values
22877of <code><i>N</i></code> in the set of 8, 16, 32, and 64 are
22878required. Exact-width types, and any macros and types for values
22879of <code><i>N</i></code> other than 8, 16, 32, and 64 are
22880optional. However, if an implementation provides integer types with
22881widths of 8, 16, 32, or 64 bits, the corresponding exact-width types
22882and macros are required.
22883
22884         </li>
22885       </ol>
22886     
22887     <pre>namespace std {
22888
22889   // required types
22890
22891   // Fastest minimum-width integer types
22892   typedef <i>signed integer type</i>   int_fast8_t;
22893   typedef <i>signed integer type</i>   int_fast16_t;
22894   typedef <i>signed integer type</i>   int_fast32_t;
22895   typedef <i>signed integer type</i>   int_fast64_t;
22896
22897   typedef <i>unsigned integer type</i> uint_fast8_t;
22898   typedef <i>unsigned integer type</i> uint_fast16_t;
22899   typedef <i>unsigned integer type</i> uint_fast32_t;
22900   typedef <i>unsigned integer type</i> uint_fast64_t;
22901
22902   // Minimum-width integer types
22903   typedef <i>signed integer type</i>   int_least8_t;
22904   typedef <i>signed integer type</i>   int_least16_t;
22905   typedef <i>signed integer type</i>   int_least32_t;
22906   typedef <i>signed integer type</i>   int_least64_t;
22907
22908   typedef <i>unsigned integer type</i> uint_least8_t;
22909   typedef <i>unsigned integer type</i> uint_least16_t;
22910   typedef <i>unsigned integer type</i> uint_least32_t;
22911   typedef <i>unsigned integer type</i> uint_least64_t;
22912
22913   // Greatest-width integer types
22914   typedef <i>signed integer type</i>   intmax_t;
22915   typedef <i>unsigned integer type</i> uintmax_t;
22916
22917   // optionally defined types
22918
22919   // Exact-width integer types
22920   typedef <i>signed integer type</i>   int<i>N</i>_t;
22921   typedef <i>unsigned integer type</i> uint<i>N</i>_t;
22922
22923   // Fastest minimum-width integer types for values
22924   // of <i>N</i> other than 8, 16, 32, and 64
22925   typedef <i>signed integer type</i>   uint_fast<i>N</i>_t;
22926   typedef <i>unsigned integer type</i> uint_fast<i>N</i>_t;
22927
22928   // Minimum-width integer types for values
22929   // of <i>N</i> other than 8, 16, 32, and 64
22930   typedef <i>signed integer type</i>   uint_least<i>N</i>_t;
22931   typedef <i>unsigned integer type</i> uint_least<i>N</i>_t;
22932
22933   // Integer types capable of holding object pointers
22934   typedef <i>signed integer type</i>   intptr_t;
22935   typedef <i>signed integer type</i>   intptr_t;
22936
22937}</pre>
22938   </blockquote>
22939   <p>
22940
22941[Note to editor: Remove all of the existing paragraph 1 from  cstdint.syn.]
22942
22943   </p>
22944   <blockquote>
22945     Table ??: Header <code>&lt;cstdint&gt;</code> synopsis
22946     <table border="1">
22947       <thead>
22948         <tr>
22949           <th>Type</th>
22950           <th colspan="3">Name(s)</th>
22951         </tr>
22952       </thead>
22953       <tbody>
22954         <tr>
22955           <td rowspan="11"><b>Macros:</b></td>
22956           <td><tt>INT<i>N</i>_MIN</tt></td>
22957           <td><tt>INT<i>N</i>_MAX</tt></td>
22958           <td><tt>UINT<i>N</i>_MAX</tt></td>
22959         </tr>
22960         <tr>
22961           <td><tt>INT_FAST<i>N</i>_MIN</tt></td>
22962           <td><tt>INT_FAST<i>N</i>_MAX</tt></td>
22963           <td><tt>UINT_FAST<i>N</i>_MAX</tt></td>
22964         </tr>
22965         <tr>
22966           <td><tt>INT_LEAST<i>N</i>_MIN</tt></td>
22967           <td><tt>INT_LEAST<i>N</i>_MAX</tt></td>
22968           <td><tt>UINT_LEAST<i>N</i>_MAX</tt></td>
22969         </tr>
22970         <tr>
22971           <td><tt>INTPTR_MIN</tt></td>
22972           <td><tt>INTPTR_MAX</tt></td>
22973           <td><tt>UINTPTR_MAX</tt></td>
22974         </tr>
22975         <tr>
22976           <td><tt>INTMAX_MIN</tt></td>
22977           <td><tt>INTMAX_MAX</tt></td>
22978           <td><tt>UINTMAX_MAX</tt></td>
22979         </tr>
22980         <tr>
22981           <td><tt>PTRDIFF_MIN</tt></td>
22982           <td><tt>PTRDIFF_MAX</tt></td>
22983           <td><tt>PTRDIFF_MAX</tt></td>
22984         </tr>
22985         <tr>
22986           <td><tt>SIG_ATOMIC_MIN</tt></td>
22987           <td><tt>SIG_ATOMIC_MAX</tt></td>
22988           <td><tt>SIZE_MAX</tt></td>
22989         </tr>
22990         <tr>
22991           <td><tt>WCHAR_MIN</tt></td>
22992           <td><tt>WCHAR_MAX</tt></td>
22993         <td></td>
22994         </tr>
22995         <tr>
22996           <td><tt>WINT_MIN</tt></td>
22997           <td><tt>WINT_MAX</tt></td>
22998           <td></td>
22999         </tr>
23000         <tr>
23001           <td><tt>INT<i>N</i>_C()</tt></td>
23002           <td><tt>UINT<i>N</i>_C()</tt></td>
23003           <td></td>
23004         </tr>
23005         <tr>
23006           <td><tt>INTMAX_C()</tt></td>
23007           <td><tt>UINTMAX_C()</tt></td>
23008           <td></td>
23009         </tr>
23010         <tr>
23011           <td rowspan="5"><b>Types:</b></td>
23012           <td><tt>int<i>N</i>_t</tt></td>
23013           <td><tt>uint<i>N</i>_t</tt></td>
23014           <td></td>
23015         </tr>
23016         <tr>
23017           <td><tt>int_fast<i>N</i>_t</tt></td>
23018           <td><tt>uint_fast<i>N</i>_t</tt></td>
23019           <td></td>
23020         </tr>
23021         <tr>
23022           <td><tt>int_least<i>N</i>_t</tt></td>
23023           <td><tt>uint_least<i>N</i>_t</tt></td>
23024           <td></td>
23025         </tr>
23026         <tr>
23027           <td><tt>intptr_t</tt></td>
23028           <td><tt>uintptr_t</tt></td>
23029           <td></td>
23030         </tr>
23031         <tr>
23032           <td><tt>intmax_t</tt></td>
23033           <td><tt>uintmax_t</tt></td>
23034           <td></td>
23035         </tr>
23036       </tbody>
23037     </table>
23038   </blockquote>
23039 
23040
23041
23042
23043
23044<hr>
23045<h3><a name="849"></a>849. missing type traits to compute root class and derived class of types in a class hierachy</h3>
23046<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#NAD">NAD</a>
23047 <b>Submitter:</b> Thorsten Ottosen <b>Opened:</b> 2008-06-05  <b>Last modified:</b> 2008-09-16</p>
23048<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>
23049<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
23050<p><b>Discussion:</b></p>
23051<p>
23052The type traits library contains various traits to dealt with
23053polymorphic types, e.g. <tt>std::has_virtual_destructor</tt>, <tt>std::is_polymorphic</tt>
23054and <tt>std::is_base_of</tt>. However, there is no way to compute the unique
23055public base class of a type  if such  one exists.  Such a trait could be
23056very useful if one needs to instantiate a specialization made for the
23057root class whenever a derived class is passed as parameter. For example,
23058imagine that you wanted to specialize <tt>std::hash</tt> for a class
23059hierarchy---instead of specializing each class, you could specialize the
23060<tt>std::hash&lt;root_class&gt;</tt> and provide a partial specialization that worked
23061for all derived classes.
23062</p>
23063
23064<p>
23065This ability---to specify operations in terms of their equivalent in the
23066root class---can be done with e.g. normal functions, but there is,
23067AFAIK, no way to do it for class templates. Being able to access
23068compile-time information about the type-hierachy can be very powerful,
23069and I therefore also suggest traits that computes the directly derived
23070class whenever that is possible.
23071</p>
23072
23073<p>
23074If the computation can not be done, the traits should fall back on an
23075identity transformation. I expect this gives the best overall usability.
23076</p>
23077
23078
23079<p><b>Proposed resolution:</b></p>
23080<p>
23081Add the following to the synopsis in 20.6.2 [meta.type.synop] under "other transformations":
23082</p>
23083
23084<blockquote><pre>template&lt; class T &gt; struct direct_base_class;
23085template&lt; class T &gt; struct direct_derived_class;
23086template&lt; class T &gt; struct root_base_class;
23087</pre></blockquote>
23088
23089<p>
23090Add three new entries to table 51 (20.6.7 [meta.trans.other]) with the following content
23091</p>
23092
23093<blockquote>
23094<table border="1">
23095<tbody><tr>
23096<th>Template</th><th>Condition</th><th>Comments</th>
23097</tr>
23098<tr>
23099<td><tt>template&lt; class T &gt; struct direct_base_class;</tt></td>
23100<td><tt>T</tt> shall be a complete type.</td>
23101<td>The member typedef <tt>type</tt> shall equal the accessible unambiguous direct base class of <tt>T</tt>.
23102If no such type exists, the member typedef <tt>type</tt> shall equal <tt>T</tt>.</td>
23103</tr>
23104<tr>
23105<td><tt>template&lt; class T &gt; struct direct_derived_class;</tt></td>
23106<td><tt>T</tt> shall be a complete type.</td>
23107<td>The member typedef <tt>type</tt> shall equal the unambiguous type which has <tt>T</tt>
23108as an accessible unambiguous direct base class. If no such type exists, the member typedef
23109<tt>type</tt> shall equal <tt>T</tt>.</td>
23110</tr>
23111<tr>
23112<td><tt>template&lt; class T &gt; struct root_base_class;</tt></td>
23113<td><tt>T</tt> shall be a complete type.</td>
23114<td>The member typedef <tt>type</tt> shall equal the accessible unambiguous most indirect base class of
23115<tt>T</tt>. If no such type exists, the member typedef type shall equal <tt>T</tt>.</td>
23116</tr>
23117</tbody></table>
23118</blockquote>
23119
23120
23121
23122<p><b>Rationale:</b></p>
231232008-9-16 San Francisco:  Issue pulled by author prior to being reviewed by the LWG.
23124
23125
23126
23127
23128
23129<hr>
23130<h3><a name="851"></a>851. simplified array construction</h3>
23131<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%20Future">NAD Future</a>
23132 <b>Submitter:</b> Benjamin Kosnik <b>Opened:</b> 2008-06-05  <b>Last modified:</b> 2009-10-23</p>
23133<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>
23134<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
23135<p><b>Discussion:</b></p>
23136<p>
23137This is an issue that came up on the libstdc++ list, where a
23138discrepancy between "C" arrays and C++0x's <tt>std::array</tt> was pointed
23139out.
23140</p>
23141
23142<p>
23143In "C," this array usage is possible:
23144</p>
23145
23146<blockquote><pre>int ar[] = {1, 4, 6};
23147</pre></blockquote>
23148
23149<p>
23150But for C++, 
23151</p>
23152
23153<blockquote><pre>std::array&lt;int&gt; a = { 1, 4, 6 }; // error
23154</pre></blockquote>
23155
23156<p>
23157Instead, the second parameter of the <tt>array</tt> template must be
23158explicit, like so:
23159</p>
23160
23161<blockquote><pre>std::array&lt;int, 3&gt; a = { 1, 4, 6 };
23162</pre></blockquote>
23163
23164<p>
23165Doug Gregor proposes the following solution, that assumes
23166generalized initializer lists.
23167</p>
23168
23169<blockquote><pre>template&lt;typename T, typename... Args&gt;
23170inline array&lt;T, sizeof...(Args)&gt; 
23171make_array(Args&amp;&amp;... args) 
23172{ return { std::forward&lt;Args&gt;(args)... };  }
23173</pre></blockquote>
23174
23175<p>
23176Then, the way to build an <tt>array</tt> from a list of unknown size is:
23177</p>
23178
23179<blockquote><pre>auto a = make_array&lt;T&gt;(1, 4, 6);
23180</pre></blockquote>
23181
23182<p><i>[
23183San Francisco:
23184]</i></p>
23185
23186
23187<blockquote>
23188<p>
23189Benjamin: Move to Ready?
23190</p>
23191<p>
23192Bjarne: I'm not convinced this is useful enough to add, so I'd like us
23193to have time to reflect on it.
23194</p>
23195<p>
23196Alisdair: the constraints are wrong, they should be
23197</p>
23198<blockquote><pre>template&lt;ValueType T, ValueType... Args&gt;
23199requires Convertible&lt;Args, T&gt;...
23200array&lt;T, sizeof...(Args)&gt; make_array(Args&amp;&amp;... args);
23201</pre></blockquote>
23202<p>
23203Alidair: this would be useful if we had a constexpr version.
23204</p>
23205<p>
23206Bjarne: this is probably useful for arrays with a small number of
23207elements, but it's not clearly useful otherwise.
23208</p>
23209<p>
23210Consensus is to move to Open.
23211</p>
23212</blockquote>
23213
23214<p><i>[
232152009-06-07 Daniel adds:
23216]</i></p>
23217
23218
23219<blockquote>
23220<p>
23221I suggest a fix and a simplification of the current proposal: Recent
23222prototyping by
23223Howard showed, that a fix is required because narrowing conversion
232248.5.4 [dcl.init.list]/6 b.3
23225would severely limit the possible distribution of argument types, e.g.
23226the expression
23227<tt>make_array&lt;double&gt;(1, 2.0)</tt> is ill-formed, because the narrowing
23228happens <em>inside</em> the
23229function body where no constant expressions exist anymore. Furthermore
23230given e.g.
23231</p>
23232<blockquote><pre>int f();
23233double g();
23234</pre></blockquote>
23235<p>
23236we probably want to support
23237</p>
23238<blockquote><pre>make_array&lt;double&gt;(f(), g());
23239</pre></blockquote>
23240
23241<p>
23242as well. To make this feasible, the currently suggested expansion
23243</p>
23244
23245<blockquote><pre>{ std::forward&lt;Args&gt;(args)... }
23246</pre></blockquote>
23247
23248<p>
23249needs to be replaced by
23250</p>
23251
23252<blockquote><pre>{ static_cast&lt;T&gt;(std::forward&lt;Args&gt;(args))... }
23253</pre></blockquote>
23254
23255<p>
23256which is safe, because we already ensure convertibility via the
23257element-wise <tt>Convertible&lt;Args, T&gt;</tt> requirement. Some other fixes are
23258necessary: The <tt>ValueType</tt> requirement for the function <em>parameters</em>
23259is invalid, because all lvalue arguments will deduce to an lvalue-reference,
23260thereby no longer satisfying this requirement.
23261</p>
23262
23263<p>
23264The suggested simplification is to provide a default-computed effective
23265type for the result array based on common_type and decay, in
23266unconstrained form:
23267</p>
23268
23269<blockquote><pre>template&lt;typename... Args&gt;
23270array&lt;typename decay&lt;typename common_type&lt;Args...&gt;::type&gt;::type,
23271sizeof...(Args)&gt;
23272make_array(Args&amp;&amp;... args);
23273</pre></blockquote>
23274
23275<p>
23276The approach used below is similar to that of <tt>make_pair</tt> and <tt>make_tuple</tt>
23277using a symbol <tt>C</tt> to represent the decayed common type [Note: Special
23278handling of <tt>reference_wrapper</tt> types is intentionally <em>not</em> provided, because
23279our target has so satisfy <tt>ValueType</tt>, thus under the revised proposal only
23280an all-<tt>reference_wrapper</tt>-arguments would be well-formed and an array of
23281<tt>reference_wrapper</tt> will be constructed]. I do currently not suggest to
23282add new concepts reflecting <tt>decay</tt> and <tt>common_type</tt>, but an implementor will
23283need something like this to succeed. Note that we use a similar fuzziness for
23284<tt>make_pair</tt> and <tt>make_tuple</tt> currently. This fuzziness is not related to
23285the currently
23286missing <tt>Constructible&lt;Vi, Ti&amp;&amp;&gt;</tt> requirement for those functions. The following
23287proposal fixes that miss for <tt>make_array</tt>. If the corresponding <tt>C</tt> type
23288deduction is
23289explicitly wanted for standardization, here the implementation
23290</p>
23291
23292<blockquote><pre>auto concept DC&lt;typename... T&gt; {
23293  typename type = typename decay&lt;typename common_type&lt;T...&gt;::type&gt;::type;
23294}
23295</pre></blockquote>
23296
23297<p>
23298where <tt>C</tt> is identical to <tt>DC&lt;Args...&gt;::type</tt> in the proposed resolution below.
23299</p>
23300<p>
23301I intentionally added no further type relation between type and the concept
23302template parameters, but instead added this requirement below to make
23303the specification as transparent as possible. As written this concept is
23304satisfied, if the corresponding associated type exists.
23305</p>
23306
23307<p><b>Suggested Resolution:</b></p>
23308
23309<ol>
23310<li>
23311<p>
23312Add to the array synopsis in 23.3 [sequences]:
23313</p>
23314<blockquote><pre><ins>
23315template&lt;ReferentType... Args&gt;
23316requires ValueType&lt;C&gt; &amp;&amp; IdentityOf&lt;Args&gt; &amp;&amp; Constructible&lt;C, Args&amp;&amp;&gt;...
23317array&lt;C, sizeof...(Args)&gt;
23318make_array(Args&amp;&amp;... args);
23319</ins>
23320</pre></blockquote>
23321</li>
23322
23323<li>
23324<p>
23325Append after 23.3.1.7 [array.tuple] Tuple interface to class template array
23326the following new section:
23327</p>
23328<blockquote>
23329<p>
2333023.4.1.7 Array creation functions [array.creation]
23331</p>
23332
23333<pre><ins>
23334template&lt;ReferentType... Args&gt;
23335requires ValueType&lt;C&gt; &amp;&amp; IdentityOf&lt;Args&gt; &amp;&amp; Constructible&lt;C, Args&amp;&amp;&gt;...
23336array&lt;C, sizeof...(Args)&gt;
23337make_array(Args&amp;&amp;... args);</ins>
23338</pre>
23339
23340<blockquote>
23341<p><ins>
23342Let <tt>C</tt> be <tt>decay&lt;common_type&lt;Args...&gt;::type&gt;::type</tt>.
23343</ins></p>
23344<p>
23345<ins><i>Returns:</i> an <tt>array&lt;C, sizeof...(Args)&gt;</tt> initialized with
23346<tt>{ static_cast&lt;C&gt;(std::forward&lt;Args&gt;(args))... }</tt>.
23347</ins></p>
23348</blockquote>
23349</blockquote>
23350
23351</li>
23352
23353</ol>
23354
23355</blockquote>
23356
23357<p><i>[
233582009-07 Frankfurt:
23359]</i></p>
23360
23361
23362<blockquote>
23363<p>
23364The proposed resolution uses concepts.
23365</p>
23366<p>
23367Daniel to rewrite the proposed resolution.
23368</p>
23369<p>
23370Leave Open.
23371</p>
23372</blockquote>
23373
23374<p><i>[
233752009-07-25 Daniel provides rewritten proposed resolution.
23376]</i></p>
23377
23378
23379<p><i>[
233802009-10 Santa Cruz:
23381]</i></p>
23382
23383
23384<blockquote>
23385Argument for NAD future: everything about this could be added on. This
23386does not require changes to the existing text.
23387</blockquote>
23388
23389
23390
23391<p><b>Proposed resolution:</b></p>
23392
23393<ol>
23394<li>
23395<p>
23396Add to the array synopsis in 23.3 [sequences]:
23397</p>
23398
23399<blockquote><pre><ins>template&lt;class... Args&gt;
23400  array&lt;<i>CT</i>, sizeof...(Args)&gt;
23401  make_array(Args&amp;&amp;... args);</ins>
23402</pre></blockquote>
23403</li>
23404
23405<li>
23406<p>
23407Append after 23.3.1.7 [array.tuple] "Tuple interface to class template array" the
23408following new section:
23409</p>
23410
23411<blockquote>
23412<p>
23413<ins>XX.X.X.X Array creation functions [array.creation]</ins>
23414</p>
23415
23416<pre><ins>
23417template&lt;class... Args&gt;
23418array&lt;<i>CT</i>, sizeof...(Args)&gt;
23419make_array(Args&amp;&amp;... args)
23420</ins></pre>
23421
23422<blockquote>
23423<p>
23424<ins>Let <i>CT</i> be <tt>decay&lt;common_type&lt;Args...&gt;::type&gt;::type</tt>.</ins>
23425</p>
23426<p>
23427<ins><i>Returns:</i> An <tt>array&lt;<i>CT</i>, sizeof...(Args)&gt;</tt> initialized with <tt>{
23428static_cast&lt;<i>CT</i>&gt;(std::forward&lt;Args&gt;(args))... }</tt>.</ins>
23429</p>
23430
23431<p><ins>
23432[<i>Example:</i>
23433</ins></p>
23434<blockquote><pre><ins>
23435int i = 0; int&amp; ri = i;
23436make_array(42u, i, 2.78, ri);
23437</ins></pre></blockquote>
23438<p><ins>
23439returns an array of type
23440</ins></p>
23441<blockquote><pre><ins>
23442array&lt;double, 4&gt;
23443</ins></pre></blockquote>
23444
23445<p><ins>
23446&#8212;<i>end example</i>]</ins>
23447</p>
23448</blockquote>
23449</blockquote>
23450</li>
23451
23452</ol>
23453
23454
23455
23456
23457
23458
23459
23460
23461<hr>
23462<h3><a name="855"></a>855. capacity() and reserve() for deque?</h3>
23463<p><b>Section:</b> 23.3.2.2 [deque.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
23464 <b>Submitter:</b> Herv� Br�nnimann <b>Opened:</b> 2008-06-11  <b>Last modified:</b> 2008-09-22</p>
23465<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#deque.capacity">issues</a> in [deque.capacity].</p>
23466<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
23467<p><b>Discussion:</b></p>
23468<p>
23469The main point is that <tt>capacity</tt> can be viewed as a mechanism to  
23470guarantee the validity of <tt>iterators</tt> when only <tt>push_back/pop_back</tt>
23471operations are used.  For <tt>vector</tt>, this goes with reallocation.  For  
23472<tt>deque</tt>, this is a bit more subtle:  <tt>capacity()</tt> of a <tt>deque</tt> may shrink,  
23473whereas that of <tt>vector</tt> doesn't.   In a circular buffer impl. of the  
23474map, as Howard did, there is very similar notion of capacity: as long  
23475as <tt>size()</tt> is less than <tt>B * (</tt>total size of the map <tt>- 2)</tt>, it is  
23476guaranteed that no <tt>iterator</tt> is invalidated after any number of  
23477<tt>push_front/back</tt> and <tt>pop_front/back</tt> operations.  But this does not  
23478hold for other implementations.
23479</p>
23480<p>
23481Still, I believe, <tt>capacity()</tt> can be defined by <tt>size() +</tt>  how many  
23482<tt>push_front/back</tt> minus <tt>pop_front/back</tt> that can be performed before  
23483terators are invalidated.  In a classical impl., <tt>capacity() = size()
23484+ </tt> the min distance to either "physical" end of the deque (i.e.,  
23485counting the empty space in the last block plus all the blocks until  
23486the end of the map of block pointers).  In Howard's circular buffer  
23487impl., <tt>capacity() = B * (</tt>total size of the map <tt>- 2)</tt> still works with  
23488this definition, even though the guarantee could be made stronger.
23489</p>
23490<p>
23491A simple picture of a deque:
23492</p>
23493<blockquote><pre>A-----|----|-----|---F+|++++|++B--|-----|-----Z
23494</pre></blockquote>
23495<p>
23496(A,Z mark the beginning/end, | the block boundaries, F=front, B=back,  
23497and - are uninitialized, + are initialized)
23498In that picture:  <tt>capacity = size() + min(dist(A,F),dist(B,Z)) = min 
23499(dist(A,B),dist(F,Z))</tt>.
23500</p>
23501<p>
23502<tt>Reserve(n)</tt> can grow the map of pointers and add possibly a number of  
23503empty blocks to it, in order to guarantee that the next <tt>n-size()
23504push_back/push_front</tt> operations will not invalidate iterators, and  
23505also will not allocate (i.e. cannot throw).  The second guarantee is  
23506not essential and can be left as a QoI.  I know well enough existing  
23507implementations of <tt>deque</tt> (sgi/stl, roguewave, stlport, and  
23508dinkumware) to know that either can be implemented with no change to  
23509the existing class layout and code, and only a few modifications if  
23510blocks are pre-allocated (instead of always allocating a new block,  
23511check if the next entry in the map of block pointers is not zero).
23512</p>
23513<p>
23514Due to the difference with <tt>vector</tt>, wording is crucial.  Here's a  
23515proposed wording to make things concrete;  I tried to be reasonably  
23516careful but please double-check me:
23517</p>
23518
23519<p><i>[
23520San Francisco:
23521]</i></p>
23522
23523
23524<blockquote>
23525<p>
23526Hans: should the Returns clause for capacity read "1 Returns: A lower
23527bound..." rather than "1 Returns: An upper bound..."
23528</p>
23529<p>
23530Howard: maybe what's needed is capacity_front and capacity_back. In
23531fact, I think I implemented a deque that had these members as
23532implementation details.
23533</p>
23534</blockquote>
23535
23536
23537
23538<p><b>Proposed resolution:</b></p>
23539
23540<p>
23541Add new signatures to synopsis in 23.3.2 [deque]:
23542</p>
23543
23544<blockquote><pre>size_type capacity() const;
23545bool reserve(size_type n);
23546</pre></blockquote>
23547
23548<p>
23549Add new signatures to 23.3.2.2 [deque.capacity]:
23550</p>
23551
23552<blockquote>
23553<pre>size_type capacity() const;
23554</pre>
23555<blockquote>
23556<p>
235571 <i>Returns:</i> An upper bound on <tt>n + max(n_f - m_f, n_b - m_b)</tt>  such  
23558that, for any sequence of <tt>n_f push_front</tt>, <tt>m_f pop_front</tt>, <tt>n_b  
23559push_back</tt>, and <tt>m_b pop_back</tt> operations, interleaved in any order,  
23560starting with the current <tt>deque</tt> of size <tt>n</tt>, the <tt>deque</tt> does not  
23561invalidate any of its iterators except to the erased elements.
23562</p>
23563<p>
235642 <i>Remarks:</i>  Unlike a <tt>vector</tt>'s capacity, the capacity of a <tt>deque</tt> can  
23565decrease after a sequence of insertions at both ends, even if none of  
23566the operations caused the <tt>deque</tt> to invalidate any of its iterators  
23567except to the erased elements.
23568</p>
23569</blockquote>
23570</blockquote>
23571
23572<blockquote>
23573<pre>bool reserve(size_type n);
23574</pre>
23575<blockquote>
23576<p>
235772 <i>Effects:</i> A directive that informs a <tt>deque</tt> of a planned sequence of  
23578<tt>push_front</tt>, <tt>pop_front</tt>, <tt>push_back</tt>, and <tt>pop_back</tt> operations, so that it  
23579can manage iterator invalidation accordingly. After <tt>reserve()</tt>,  
23580<tt>capacity()</tt> is greater or equal to the argument of <tt>reserve</tt> if this  
23581operation returns <tt>true</tt>; and equal to the previous value of <tt>capacity()</tt>
23582otherwise.  If an exception is thrown, there are no effects.
23583</p>
23584<p>
235853 <i>Returns:</i> <tt>true</tt> if iterators are invalidated as a result of this  
23586operation, and false otherwise.
23587</p>
23588<p>
235894 <i>Complexity:</i> It does not change the size of the sequence and takes  
23590at most linear time in <tt>n</tt>.
23591</p>
23592<p>
235935 <i>Throws:</i> <tt>length_error</tt> if <tt>n &gt; max_size()</tt>.
23594</p>
23595<p>
235966 <i>Remarks:</i> It is guaranteed that no invalidation takes place during a  
23597sequence of <tt>insert</tt> or <tt>erase</tt> operations at either end that happens  
23598after a call to <tt>reserve()</tt> except to the erased elements, until the  
23599time when an insertion would make <tt>max(n_f-m_f, n_b-m_b)</tt> larger than  
23600<tt>capacity()</tt>, where <tt>n_f</tt> is the number of <tt>push_front</tt>, <tt>m_f</tt> of <tt>pop_front</tt>,  
23601<tt>n_b</tt> of <tt>push_back</tt>, and <tt>m_b</tt> of <tt>pop_back</tt> operations since the call to  
23602<tt>reserve()</tt>.
23603</p>
23604<p>
236057        An implementation is free to pre-allocate buffers so as to  
23606offer the additional guarantee that no exception will be thrown  
23607during such a sequence other than by the element constructors.
23608</p>
23609</blockquote>
23610</blockquote>
23611
23612<p>
23613And 23.3.2.3 [deque.modifiers] para 1, can be enhanced:
23614</p>
23615
23616<blockquote>
236171 <i>Effects:</i> An insertion in the middle of the deque invalidates all the iterators and references to elements of the
23618deque. An insertion at either end of the deque invalidates all the iterators to the deque,
23619<ins>unless provisions have been made with reserve,</ins>
23620but has no effect on the validity of references to elements of the deque.
23621</blockquote>
23622
23623
23624<p><b>Rationale:</b></p>
23625Complication outweighs the benefit.
23626
23627
23628
23629
23630
23631<hr>
23632<h3><a name="862"></a>862. Impossible complexity for 'includes'</h3>
23633<p><b>Section:</b> 25.4.5.1 [includes] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
23634 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-07-02  <b>Last modified:</b> 2009-07-13</p>
23635<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#includes">issues</a> in [includes].</p>
23636<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
23637<p><b>Discussion:</b></p>
23638<p>
23639In 25.4.5.1 [includes] the complexity is "at most -1 comparisons" if passed
23640two empty ranges.  I don't know how to perform a negative number of
23641comparisions!
23642</p>
23643
23644<p>
23645This same issue also applies to:
23646</p>
23647
23648<ul>
23649<li><tt>set_union</tt></li>
23650<li><tt>set_intersection</tt></li>
23651<li><tt>set_difference</tt></li>
23652<li><tt>set_symmetric_difference</tt></li>
23653<li><tt>merge</tt></li>
23654</ul>
23655
23656<p><i>[
236572009-03-30 Beman adds:
23658]</i></p>
23659
23660
23661<blockquote>
23662Suggest NAD. The complexity of empty ranges is -1 in other places in the
23663standard. See 25.4.4 [alg.merge] <tt>merge</tt> and
23664<tt>inplace_merge</tt>, and <tt>forward_list</tt> merge, for example.
23665The time and effort to find and fix all places in the standard where
23666empty range[s] result in negative complexity isn't worth the very
23667limited benefit.
23668</blockquote>
23669
23670<p><i>[
236712009-05-09 Alisdair adds:
23672]</i></p>
23673
23674
23675<blockquote>
23676<p>
23677I'm not happy with NAD if we can find a simple solution.
23678</p>
23679<p>
23680How about adding a rider somewhere in clause 17 suggesting that complexities
23681that specify a negative number of operations are treated as specifying zero
23682operations?  That should generically solve the issue without looking for
23683further cases.
23684</p>
23685</blockquote>
23686
23687<p><i>[
23688Batavia (2009-05):
23689]</i></p>
23690
23691<blockquote>
23692Pete to provide "straightforward" wording.
23693Move to NAD Editorial.
23694</blockquote>
23695
23696
23697<p><b>Proposed resolution:</b></p>
23698<p>
23699Recommend NAD.
23700</p>
23701
23702
23703
23704
23705
23706<hr>
23707<h3><a name="863"></a>863. What is the state of a stream after close() succeeds</h3>
23708<p><b>Section:</b> 27.9.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
23709 <b>Submitter:</b> Steve Clamage <b>Opened:</b> 2008-07-08  <b>Last modified:</b> 2009-07-13</p>
23710<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fstreams">issues</a> in [fstreams].</p>
23711<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
23712<p><b>Discussion:</b></p>
23713<p>
23714Suppose writing to an <tt>[o]fstream</tt> fails and you later close the <tt>stream</tt>.
23715The <tt>overflow()</tt> function is called to flush the buffer (if it exists).
23716Then the file is unconditionally closed, as if by calling <tt>flcose</tt>.
23717</p>
23718<p>
23719If either <tt>overflow</tt> or <tt>fclose</tt> fails, <tt>close()</tt> reports failure, and clearly
23720the <tt>stream</tt> should be in a failed or bad state.
23721</p>
23722<p>
23723Suppose the buffer is empty or non-existent (so that <tt>overflow()</tt> does not
23724fail), and <tt>fclose</tt> succeeds. The <tt>close()</tt> function reports success, but
23725what is the state of the <tt>stream</tt>?
23726</p>
23727
23728<p><i>[
23729Batavia (2009-05):
23730]</i></p>
23731
23732<blockquote>
23733<p>
23734Tom's impression is that the issue is about the <tt>failbit</tt>, etc.
23735</p>
23736<p>
23737Bill responds that the stream is now closed,
23738and any status bits remain unchanged.
23739</p>
23740<p>
23741See the description of <tt>close()</tt> in 27.9.1.17 [fstream.members].
23742</p>
23743<p>
23744We prefer not to add wording to say that nothing changes.
23745Move to NAD.
23746</p>
23747</blockquote>
23748
23749
23750<p><b>Proposed resolution:</b></p>
23751<p>
23752</p>
23753
23754
23755
23756
23757
23758<hr>
23759<h3><a name="864"></a>864. Defect in atomic wording</h3>
23760<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#NAD%20Editorial">NAD Editorial</a>
23761 <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2008-07-10  <b>Last modified:</b> 2008-09-17</p>
23762<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>
23763<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
23764<p><b>Discussion:</b></p>
23765<p>
23766There's an error in 29.6 [atomics.types.operations]/p9:
23767</p>
23768
23769<blockquote>
23770<pre>C atomic_load(const volatile A * object);
23771C atomic_load_explicit(const volatile A * object, memory_order);
23772C A ::load(memory_order order = memory_order_seq_cst) const volatile;
23773</pre>
23774<blockquote>
23775<p>
23776<i>Requires:</i> The <tt>order</tt> argument shall not be <tt>memory_order_acquire</tt> nor
23777<tt>memory_order_acq_rel</tt>.
23778</p>
23779</blockquote>
23780</blockquote>
23781
23782<p>
23783I believe that this should state
23784</p>
23785<blockquote>
23786shall not be <tt>memory_order_release</tt>.
23787</blockquote>
23788
23789<p>
23790There's also an error in 29.6 [atomics.types.operations]/p17:
23791</p>
23792
23793<blockquote>
23794... When only one <tt>memory_order</tt> argument is supplied, the value of success
23795is <tt>order</tt>, and
23796the value of failure is <tt>order</tt> except that a value of
23797<tt>memory_order_acq_rel</tt> shall be replaced by the value
23798<tt>memory_order_require</tt> ...
23799</blockquote>
23800<p>
23801I believe this should state
23802</p>
23803<blockquote>
23804shall be replaced by the value <tt>memory_order_acquire</tt> ...
23805</blockquote>
23806
23807
23808<p><b>Proposed resolution:</b></p>
23809<p>
23810Change 29.6 [atomics.types.operations]/p9:
23811</p>
23812
23813<blockquote>
23814<pre>C atomic_load(const volatile A * object);
23815C atomic_load_explicit(const volatile A * object, memory_order);
23816C A ::load(memory_order order = memory_order_seq_cst) const volatile;
23817</pre>
23818<blockquote>
23819<p>
23820<i>Requires:</i> The <tt>order</tt> argument shall not be <del><tt>memory_order_acquire</tt></del>
23821<ins><tt>memory_order_release</tt></ins> nor <tt>memory_order_acq_rel</tt>.
23822</p>
23823</blockquote>
23824</blockquote>
23825
23826<p>
23827Change 29.6 [atomics.types.operations]/p17:
23828</p>
23829
23830<blockquote>
23831... When only one <tt>memory_order</tt> argument is supplied, the value of success
23832is <tt>order</tt>, and
23833the value of failure is <tt>order</tt> except that a value of
23834<tt>memory_order_acq_rel</tt> shall be replaced by the value
23835<del><tt>memory_order_require</tt></del> <ins><tt>memory_order_acquire</tt></ins> ...
23836</blockquote>
23837
23838
23839
23840<p><b>Rationale:</b></p>
23841Already fixed by the time the LWG processed it.
23842
23843
23844
23845
23846
23847<hr>
23848<h3><a name="867"></a>867. Valarray and value-initialization</h3>
23849<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#NAD%20Editorial">NAD Editorial</a>
23850 <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2008-07-20  <b>Last modified:</b> 2009-07-13</p>
23851<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>
23852<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
23853<p><b>Discussion:</b></p>
23854<p>
23855From 26.6.2.1 [valarray.cons], paragraph 2:
23856</p>
23857
23858<blockquote><pre>explicit  valarray(size_t);
23859</pre>
23860<blockquote>
23861The array created by this constructor has a length equal to the value of the argument. The elements
23862of the array are constructed using the default constructor for the instantiating type <tt>T</tt>.
23863</blockquote>
23864</blockquote>
23865
23866<p>
23867The problem is that the most obvious <tt>T</tt>s for <tt>valarray</tt> are <tt>float</tt>
23868and <tt>double</tt>, they don't have a default constructor. I guess the intent is to value-initialize
23869the elements, so I suggest replacing:
23870</p>
23871
23872<blockquote>
23873The elements of the array are constructed using the default constructor for the instantiating type <tt>T</tt>.
23874</blockquote>
23875<p>
23876with
23877</p>
23878<blockquote>
23879The elements of the array are value-initialized.
23880</blockquote>
23881
23882<p>
23883There is another reference to the default constructor of <tt>T</tt> in the non-normative note in paragraph 9.
23884That reference should also be replaced. (The normative wording in paragraph 8 refers to <tt>T()</tt>
23885and so it doesn't need changes).
23886</p>
23887
23888<p><i>[
23889Batavia (2009-05):
23890]</i></p>
23891
23892<blockquote>
23893We agree with the proposed resolution.
23894Move to NAD Editorial.
23895</blockquote>
23896
23897
23898<p><b>Proposed resolution:</b></p>
23899<p>
23900Change 26.6.2.1 [valarray.cons], paragraph 2:
23901</p>
23902
23903<blockquote>
23904<pre>explicit  valarray(size_t);
23905</pre>
23906<blockquote>
23907The array created by this constructor has a length equal to the value of the argument. The elements
23908of the array are <del>constructed using the default constructor for the instantiating type <tt>T</tt></del>
23909<ins>value-initialized (8.5 [dcl.init])</ins>.
23910</blockquote>
23911</blockquote>
23912
23913<p>
23914Change 26.6.2.7 [valarray.members], paragraph 9:
23915</p>
23916
23917<blockquote>
23918[<i>Example:</i> If the argument has the value -2, the first two elements of the result will be <del>constructed using the 
23919default constructor</del>
23920<ins>value-initialized (8.5 [dcl.init])</ins>;
23921the third element of the result will be assigned the value of the first element of the argument; etc. <i>-- end example</i>]
23922</blockquote>
23923
23924
23925
23926
23927
23928
23929<hr>
23930<h3><a name="873"></a>873. signed integral type and unsigned integral type are not clearly defined</h3>
23931<p><b>Section:</b> 3.9.1 [basic.fundamental] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
23932 <b>Submitter:</b> Travis Vitek <b>Opened:</b> 2008-06-30  <b>Last modified:</b> 2009-07-17</p>
23933<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
23934<p><b>Discussion:</b></p>
23935    <p>
23936      Neither the term "signed integral type" nor the term "unsigned
23937      integral type" is defined in the core language section of the
23938      standard, therefore the library section should avoid its use.  The
23939      terms <i>signed integer type</i> and <i>unsigned integer type</i> are
23940      indeed defined (in 3.9.1 [basic.fundamental]), thus the usages should be
23941      replaced accordingly.
23942    </p>
23943
23944    <p>
23945      Note that the key issue here is that "signed" + "integral type" !=
23946      "signed integral type".
23947      
23948      The types <code>bool</code>, <code>char</code>, <code>char16_t</code>,
23949      <code>char32_t</code> and <code>wchar_t</code> are all listed as
23950      integral types, but are neither of <i>signed integer type</i> or
23951      <i>unsigned integer type</i>. According to 3.9 [basic.types] p7, a synonym for
23952      integral type is <i>integer type</i>.
23953      
23954      Given this, one may choose to assume that an <i>integral type</i> that
23955      can represent values less than zero is a <i>signed integral type</i>.
23956      Unfortunately this can cause ambiguities.
23957      
23958      As an example, if <code>T</code> is <code>unsigned char</code>, the
23959      expression <code>make_signed&lt;T&gt;::type</code>, is supposed to
23960      name a signed integral type. There are potentially two types that
23961      satisfy this requirement, namely <code>signed char</code> and
23962      <code>char</code> (assuming <code>CHAR_MIN &lt; 0</code>).
23963    </p>
23964
23965<p><i>[
23966San Francisco:
23967]</i></p>
23968
23969
23970<blockquote>
23971Plum, Sebor to review.
23972</blockquote>
23973
23974<p><i>[
23975Post Summit Daniel adds:
23976]</i></p>
23977
23978
23979<blockquote>
23980The proposed resolution needs to be "conceptualized". Currently we have
23981in  [concept.support] only concept <tt>IntegralType</tt>
23982for all "integral types", thus indeed the current <tt>Container</tt>
23983concept and Iterator concepts are sufficiently satisfied with "integral
23984types". If the changes are applied, we might ask core for concept
23985<tt>BilateralIntegerType</tt> and add proper restrictions to the library
23986concepts.
23987</blockquote>
23988
23989  
23990
23991  <p><b>Proposed resolution:</b></p>
23992    <p>
23993      I propose to use the terms "signed integer type" and "unsigned integer
23994      type" in place of "signed integral type" and "unsigned integral type"
23995      to eliminate such ambiguities.
23996    </p>
23997    
23998    <p>
23999      The proposed change makes it absolutely clear that the difference
24000      between two pointers cannot be <tt>char</tt> or <tt>wchar_t</tt>,
24001      but could be any of the signed integer types.
24002      5.7 [expr.add] paragraph 6...
24003    </p>
24004    <blockquote>
24005      <p>
24006        </p><ol>
24007          <li>
24008            When two pointers to elements of the same array object are
24009            subtracted, the result is the difference of the subscripts of
24010            the two array elements. The type of the result is an
24011            implementation-defined <del>signed integral
24012            type</del><ins>signed integer type</ins>; this type shall be the
24013            same type that is defined as <code>std::ptrdiff_t</code> in the
24014            <code>&lt;cstdint&gt;</code> header (18.1)...
24015          </li>
24016        </ol>
24017      
24018    </blockquote>
24019
24020    <p>
24021      The proposed change makes it clear that <tt>X::size_type</tt> and
24022      <tt>X::difference_type</tt> cannot be <tt>char</tt> or
24023      <tt>wchar_t</tt>, but could be one of the signed or unsigned integer
24024      types as appropriate.
24025      20.2.2 [allocator.requirements] table 40...
24026    </p>
24027    <blockquote>
24028      Table 40: Allocator requirements
24029      <table border="1">
24030        <thead>
24031          <tr>
24032            <th>expression</th>
24033            <th>return type</th>
24034            <th>assertion/note/pre/post-condition</th>
24035          </tr>
24036        </thead>
24037        <tbody>
24038          <tr>
24039            <td><tt>X::size_type</tt></td>
24040            <td>
24041              <del>unsigned integral type</del>
24042              <ins>unsigned integer type</ins>
24043            </td>
24044            <td>a type that can represent the size of the largest object in
24045            the allocation model.</td>
24046          </tr>
24047          <tr>
24048            <td><tt>X::difference_type</tt></td>
24049            <td>
24050              <del>signed integral type</del>
24051              <ins>signed integer type</ins>
24052            </td>
24053            <td>a type that can represent the difference between any two
24054            pointers in the allocation model.</td>
24055          </tr>
24056        </tbody>
24057      </table>
24058    </blockquote>
24059
24060    <p>
24061      The proposed change makes it clear that <tt>make_signed&lt;T&gt;::type</tt>
24062      must be one of the signed integer types as defined in 3.9.1. Ditto for
24063      <tt>make_unsigned&lt;T&gt;type</tt> and unsigned integer types.
24064      20.6.6.3 [meta.trans.sign] table 48...
24065    </p>
24066    <blockquote>
24067      Table 48: Sign modifications
24068      <table border="1">
24069        <thead>
24070          <tr>
24071            <th>Template</th>
24072            <th>Comments</th>
24073          </tr>
24074        </thead>
24075        <tbody>
24076          <tr>
24077            <td>
24078              <tt>template &lt;class T&gt; struct make_signed;</tt>
24079            </td>
24080            <td>
24081              If <code>T</code> names a (possibly cv-qualified) <del>signed
24082              integral type</del><ins>signed integer type</ins> (3.9.1) then
24083              the member typedef <code>type</code> shall name the type
24084              <code>T</code>; otherwise, if <code>T</code> names a (possibly
24085              cv-qualified) <del>unsigned integral type</del><ins>unsigned
24086              integer type</ins> then <code>type</code> shall name the
24087              corresponding <del>signed integral type</del><ins>signed
24088              integer type</ins>, with the same cv-qualifiers as
24089              <code>T</code>; otherwise, <code>type</code> shall name the
24090              <del>signed integral type</del><ins>signed integer type</ins>
24091              with the smallest rank (4.13) for which <code>sizeof(T) ==
24092              sizeof(type)</code>, with the same cv-qualifiers as
24093              <code>T</code>.
24094
24095              <i>Requires:</i> <code>T</code> shall be a (possibly
24096              cv-qualified) integral type or enumeration but not a
24097              <code>bool</code> type.
24098            </td>
24099          </tr>
24100          <tr>
24101            <td>
24102              <tt>template &lt;class T&gt; struct make_unsigned;</tt>
24103            </td>
24104            <td>
24105              If <code>T</code> names a (possibly cv-qualified)
24106              <del>unsigned integral type</del><ins>unsigned integer
24107              type</ins> (3.9.1) then the member typedef <code>type</code>
24108              shall name the type <code>T</code>; otherwise, if
24109              <code>T</code> names a (possibly cv-qualified) <del>signed
24110              integral type</del><ins>signed integer type</ins> then
24111              <code>type</code> shall name the corresponding <del>unsigned
24112              integral type</del><ins>unsigned integer type</ins>, with the
24113              same cv-qualifiers as <code>T</code>; otherwise,
24114              <code>type</code> shall name the <del>unsigned integral
24115              type</del><ins>unsigned integer type</ins> with the smallest
24116              rank (4.13) for which <code>sizeof(T) == sizeof(type)</code>,
24117              with the same cv-qualifiers as <code>T</code>.
24118
24119              <i>Requires:</i> <code>T</code> shall be a (possibly
24120              cv-qualified) integral type or enumeration but not a
24121              <code>bool</code> type.
24122            </td>
24123          </tr>
24124        </tbody>
24125      </table>
24126    </blockquote>
24127
24128
24129    <p>
24130      Note: I believe that the basefield values should probably be
24131      prefixed with <tt>ios_base::</tt> as they are in 22.4.2.2.2 [facet.num.put.virtuals]
24132
24133      The listed virtuals are all overloaded on signed and unsigned integer
24134      types, the new wording just maintains consistency.
24135
24136      22.4.2.1.2 [facet.num.get.virtuals] table 78...
24137    </p>
24138    <blockquote>
24139      Table 78: Integer Conversions
24140      <table border="1">
24141        <thead>
24142          <tr>
24143            <th>State</th>
24144            <th><tt>stdio</tt> equivalent</th>
24145          </tr>
24146        </thead>
24147        <tbody>
24148          <tr>
24149            <td><tt>basefield == oct</tt></td>
24150            <td><tt>%o</tt></td>
24151          </tr>
24152          <tr>
24153            <td><tt>basefield == hex</tt></td>
24154            <td><tt>%X</tt></td>
24155          </tr>
24156          <tr>
24157            <td><tt>basefield == 0</tt></td>
24158            <td><tt>%i</tt></td>
24159          </tr>
24160          <tr>
24161            <td><del>signed integral type</del><ins>signed integer
24162            type</ins></td>
24163            <td><tt>%d</tt></td>
24164          </tr>
24165          <tr>
24166            <td><del>unsigned integral type</del><ins>unsigned integer
24167            type</ins></td>
24168            <td><tt>%u</tt></td>
24169          </tr>
24170        </tbody>
24171      </table>
24172    </blockquote>
24173
24174    
24175    
24176    <p>
24177      Rationale is same as above.
24178      22.4.2.2.2 [facet.num.put.virtuals] table 80...
24179    </p>
24180    <blockquote>
24181      Table 80: Integer Conversions
24182      <table border="1">
24183        <thead>
24184          <tr>
24185            <th>State</th>
24186            <th><tt>stdio</tt> equivalent</th>
24187          </tr>
24188        </thead>
24189        <tbody>
24190          <tr>
24191            <td><tt>basefield == ios_base::oct</tt></td>
24192            <td><tt>%o</tt></td>
24193          </tr>
24194          <tr>
24195            <td><tt>(basefield == ios_base::hex) &amp;&amp;
24196            !uppercase</tt></td>
24197            <td><tt>%x</tt></td>
24198          </tr>
24199          <tr>
24200            <td><tt>(basefield == ios_base::hex)</tt></td>
24201            <td><tt>%X</tt></td>
24202          </tr>
24203          <tr>
24204            <td><tt>basefield == 0</tt></td>
24205            <td><tt>%i</tt></td>
24206          </tr>
24207          <tr>
24208            <td>for a <del>signed integral type</del><ins>signed integer
24209            type</ins></td>
24210            <td><tt>%d</tt></td>
24211          </tr>
24212          <tr>
24213            <td>for a <del>unsigned integral type</del><ins>unsigned integer
24214            type</ins></td>
24215            <td><tt>%u</tt></td>
24216          </tr>
24217        </tbody>
24218      </table>
24219    </blockquote>
24220
24221    
24222    <p>
24223      23.2 [container.requirements] table 80...
24224    </p>
24225    <blockquote>
24226      Table 89: Container requirements
24227      <table border="1">
24228        <thead>
24229          <tr>
24230            <th>expression</th>
24231            <th>return type</th>
24232            <th>operational semantics</th>
24233            <th>assertion/note/pre/post-condition</th>
24234            <th>complexity</th>
24235          </tr>
24236        </thead>
24237        <tbody>
24238          <tr>
24239            <td><tt>X::difference_type</tt></td>
24240            <td><del>signed integral type</del><ins>signed integer type</ins></td>
24241            <td>&nbsp;</td>
24242            <td>is identical to the difference type of <tt>X::iterator</tt>
24243            and <tt>X::const_iterator</tt></td>
24244            <td>compile time</td>
24245          </tr>
24246          <tr>
24247            <td><tt>X::size_type</tt></td>
24248            <td><del>unsigned integral type</del><ins>unsigned integer type</ins></td>
24249            <td>&nbsp;</td>
24250            <td><tt>size_type</tt> can represent any non-negative value of
24251            <tt>difference_type</tt></td>
24252            <td>compile time</td>
24253          </tr>
24254        </tbody>
24255      </table>
24256    </blockquote>
24257
24258    <p>
24259      X [iterator.concepts] paragraph 1...
24260    </p>
24261    <blockquote>
24262      Iterators are a generalization of pointers that allow a C++ program to
24263      work with different data structures (containers) in a uniform manner.
24264      To be able to construct template algorithms that work correctly and
24265      efficiently on different types of data structures, the library
24266      formalizes not just the interfaces but also the semantics and
24267      complexity assumptions of iterators. All input iterators
24268      <code>i</code> support the expression <code>*i</code>, resulting in a
24269      value of some class, enumeration, or built-in type <code>T</code>,
24270      called the <i>value type</i> of the iterator. All output iterators
24271      support the expression <code>*i = o</code> where <code>o</code> is a
24272      value of some type that is in the set of types that are
24273      <i>writable</i> to the particular iterator type of <code>i</code>. All
24274      iterators <code>i</code> for which the expression <code>(*i).m</code>
24275      is well-defined, support the expression <code>i-&gt;m</code> with the
24276      same semantics as <code>(*i).m</code>. For every iterator type
24277      <code>X</code> for which equality is defined, there is a corresponding
24278      <del>signed integral type</del> <ins>signed integer type</ins> called
24279      the <i>difference type</i> of the iterator.
24280    </blockquote>
24281    
24282    <p>
24283      I'm a little unsure of this change. Previously this paragraph would
24284      allow instantiations of <tt>linear_congruential_engine</tt> on
24285      <tt>char</tt>, <tt>wchar_t</tt>, <tt>bool</tt>, and other types. The
24286      new wording prohibits this.
24287      26.5.3.1 [rand.eng.lcong] paragraph 2...
24288    </p>
24289    <blockquote>
24290      The template parameter <code>UIntType</code> shall denote an
24291      <del>unsigned integral type</del><ins>unsigned integer type</ins>
24292      large enough to store values as large as <code>m - 1</code>. If the
24293      template parameter <code>m</code> is 0, the modulus <code>m</code>
24294      used throughout this section 26.4.3.1 is
24295      <code>numeric_limits&lt;result_type&gt;::max()</code> plus 1.  [Note:
24296      The result need not be representable as a value of type
24297      <code>result_type</code>. --end note] Otherwise, the following
24298      relations shall hold: <code>a &lt; m</code> and <code>c &lt;
24299      m</code>.
24300    </blockquote>
24301    
24302    <p>
24303      Same rationale as the previous change.
24304      X [rand.adapt.xor] paragraph 6...
24305    </p>
24306    <blockquote>
24307      Both <code>Engine1::result_type</code> and
24308      <code>Engine2::result_type</code> shall denote (possibly different)
24309      <del>unsigned integral types</del><ins>unsigned integer types</ins>.
24310      The member <i>result_type</i> shall denote either the type
24311      <i>Engine1::result_type</i> or the type <i>Engine2::result_type</i>,
24312      whichever provides the most storage according to clause 3.9.1.
24313    </blockquote>
24314    
24315    <p>
24316      26.5.7.1 [rand.util.seedseq] paragraph 7...
24317    </p>
24318    <blockquote>
24319      <i>Requires:</i><code>RandomAccessIterator</code> shall meet the
24320      requirements of a random access iterator (24.1.5) such that
24321      <code>iterator_traits&lt;RandomAccessIterator&gt;::value_type</code>
24322      shall denote an <del>unsigned integral type</del><ins>unsigned integer
24323      type</ins> capable of accomodating 32-bit quantities.  
24324    </blockquote>
24325
24326    <p>
24327      By making this change, integral types that happen to have a signed
24328      representation, but are not signed integer types, would no longer be
24329      required to use a two's complement representation. This may go against
24330      the original intent, and should be reviewed.
24331      29.6 [atomics.types.operations] paragraph 24...
24332    </p>
24333    <blockquote>
24334      <i>Remark:</i> For <del>signed integral types</del><ins>signed integer
24335      types</ins>, arithmetic is defined using two's complement
24336      representation. There are no undefined results. For address types, the
24337      result may be an undefined address, but the operations otherwise have
24338      no undefined behavior.
24339    </blockquote>
24340    
24341  
24342
24343
24344
24345
24346<hr>
24347<h3><a name="874"></a>874. Missing <tt>initializer_list</tt> constructor for <tt>discrete_distribution</tt></h3>
24348<p><b>Section:</b> 26.5.8.5.1 [rand.dist.samp.discrete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
24349 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-08-22  <b>Last modified:</b> 2009-03-09</p>
24350<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.discrete">issues</a> in [rand.dist.samp.discrete].</p>
24351<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
24352<p><b>Discussion:</b></p>
24353<p>
24354During the Sophia Antipolis meeting it was decided to separate from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a> a
24355subrequest that adds initializer list support to
24356<tt>discrete_distribution</tt>, specifically,
24357the issue proposed to add a c'tor taking a <tt>initializer_list&lt;double&gt;</tt>.
24358</p>
24359
24360
24361
24362<p><b>Proposed resolution:</b></p>
24363<ol>
24364<li>
24365<p>
24366In 26.5.8.5.1 [rand.dist.samp.discrete]/1, class <tt>discrete_distribution</tt>,
24367just <em>before</em> the member declaration
24368</p>
24369
24370<blockquote><pre>explicit discrete_distribution(const param_type&amp; parm);
24371</pre></blockquote>
24372
24373<p>
24374insert
24375</p>
24376
24377<blockquote><pre>discrete_distribution(initializer_list&lt;double&gt; wl);
24378</pre></blockquote>
24379</li>
24380
24381<li>
24382<p>
24383Between p.4 and p.5 of the same section insert a new
24384paragraph as part of the new member description:
24385</p>
24386
24387<blockquote><pre>discrete_distribution(initializer_list&lt;double&gt; wl);
24388</pre>
24389
24390<blockquote>
24391<i>Effects:</i> Same as <tt>discrete_distribution(wl.begin(), wl.end())</tt>.
24392</blockquote>
24393</blockquote>
24394</li>
24395</ol>
24396
24397
24398<p><b>Rationale:</b></p>
24399Addressed by
24400<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
24401
24402
24403
24404
24405
24406<hr>
24407<h3><a name="875"></a>875. Missing <tt>initializer_list</tt> constructor for <tt>piecewise_constant_distribution</tt></h3>
24408<p><b>Section:</b> 26.5.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
24409 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-08-22  <b>Last modified:</b> 2009-03-09</p>
24410<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p>
24411<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
24412<p><b>Discussion:</b></p>
24413<p>
24414During the Sophia Antipolis meeting it was decided to separate from
24415<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#794">794</a> a subrequest that adds initializer list support to
24416<tt>piecewise_constant_distribution</tt>, specifically, the issue proposed
24417to add a c'tor taking a <tt>initializer_list&lt;double&gt;</tt> and a <tt>Callable</tt> to evaluate
24418weight values. For consistency with the remainder of this class and
24419the remainder of the <tt>initializer_list</tt>-aware library the author decided to
24420change the list argument type to the template parameter <tt>RealType</tt>
24421instead. For the reasoning to use <tt>Func</tt> instead of <tt>Func&amp;&amp;</tt> as c'tor
24422function argument see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#793">793</a>.
24423</p>
24424
24425
24426<p><b>Proposed resolution:</b></p>
24427<p><b>Non-concept version of the proposed resolution</b></p>
24428
24429<ol>
24430<li>
24431<p>
24432In 26.5.8.5.2 [rand.dist.samp.pconst]/1, class <tt>piecewise_constant_distribution</tt>,
24433just <em>before</em> the member declaration
24434</p>
24435
24436<blockquote><pre>explicit piecewise_constant_distribution(const param_type&amp; parm);
24437</pre></blockquote>
24438
24439<p>
24440insert
24441</p>
24442
24443<blockquote><pre>template&lt;typename Func&gt;
24444piecewise_constant_distribution(initializer_list&lt;RealType&gt; bl, Func fw);
24445</pre></blockquote>
24446</li>
24447
24448<li>
24449<p>
24450Between p.4 and p.5 of the same section insert a series of
24451new paragraphs nominated below as [p5_1], [p5_2], and [p5_3]
24452as part of the new member description:
24453</p>
24454
24455<blockquote><pre>template&lt;typename Func&gt;
24456piecewise_constant_distribution(initializer_list&lt;RealType&gt; bl, Func fw);
24457</pre>
24458
24459<blockquote>
24460
24461<p>
24462[p5_1] <i>Complexity:</i> Exactly <tt>nf = max(bl.size(), 1) - 1</tt> invocations of <tt>fw</tt>.
24463</p>
24464
24465<p>
24466[p5_2] <i>Requires:</i>
24467</p>
24468
24469<ol type="a">
24470<li>
24471<tt>fw</tt> shall be callable with one argument of type <tt>RealType</tt>, and shall
24472   return values of a type convertible to <tt>double</tt>;
24473</li>
24474<li>
24475The relation <tt>0 &lt; S = w<sub>0</sub>+. . .+w<sub>n-1</sub></tt> shall hold. 
24476For all sampled values <tt><i>x<sub>k</sub></i></tt> defined below, <tt>fw(<i>x<sub>k</sub></i>)</tt> shall return a weight
24477   value <tt><i>w<sub>k</sub></i></tt> that is non-negative, non-NaN, and non-infinity;
24478</li>
24479<li>
24480If <tt>nf &gt; 0</tt> let <tt>b<sub><i>k</i></sub> = *(bl.begin() + k), k = 0, . . . , bl.size()-1</tt> and the
24481following relations shall hold for <tt>k = 0, . . . , nf-1: b<sub><i>k</i></sub> &lt; b<sub><i>k+1</i></sub></tt>.
24482</li>
24483</ol>
24484
24485<p>
24486[p5_3] <i>Effects:</i>
24487</p>
24488
24489<ol type="a">
24490<li>
24491<p>If <tt>nf == 0</tt>,</p>
24492<ol type="a">
24493<li>
24494lets the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist of the single
24495     value <tt>w<sub>0</sub> = 1</tt>, and
24496</li>
24497<li>
24498lets the sequence <tt>b</tt> have length <tt>n+1</tt> with <tt>b<sub>0</sub> = 0</tt> and <tt>b<sub>1</sub> = 1</tt>.
24499</li>
24500</ol>
24501</li>
24502
24503<li>
24504<p>Otherwise,</p>
24505<ol type="a">
24506<li>
24507sets <tt>n = nf</tt>, and <tt>[bl.begin(), bl.end())</tt> shall form the sequence <tt>b</tt> of
24508length <tt>n+1</tt>, and
24509</li>
24510<li>
24511<p>lets the sequences <tt>w</tt> have length <tt>n</tt> and for each <tt>k = 0, . . . ,n-1</tt>,
24512     calculates:</p>
24513<blockquote><pre>x<sub><i>k</i></sub> = 0.5*(b<sub><i>k+1</i></sub> + b<sub><i>k</i></sub>)
24514w<sub><i>k</i></sub> = fw(x<sub><i>k</i></sub>)
24515</pre></blockquote>
24516</li>
24517</ol>
24518</li>
24519
24520<li>
24521<p>
24522Constructs a <tt>piecewise_constant_distribution</tt> object with
24523the above computed sequence <tt>b</tt> as the interval boundaries
24524and with the probability densities:
24525</p>
24526<blockquote><pre>&#961;<sub><i>k</i></sub> = w<sub><i>k</i></sub>/(S * (b<sub><i>k+1</i></sub> - b<sub><i>k</i></sub>)) for k = 0, . . . , n-1.
24527</pre></blockquote>
24528
24529</li>
24530</ol>
24531
24532</blockquote>
24533</blockquote>
24534</li>
24535</ol>
24536
24537<p><b>Concept version of the proposed resolution</b></p>
24538
24539<ol>
24540<li>
24541<p>
24542In 26.5.8.5.2 [rand.dist.samp.pconst]/1, class <tt>piecewise_constant_distribution</tt>,
24543just <em>before</em> the member declaration
24544</p>
24545
24546<blockquote><pre>explicit piecewise_constant_distribution(const param_type&amp; parm);
24547</pre></blockquote>
24548
24549<p>
24550insert
24551</p>
24552
24553<blockquote><pre>template&lt;Callable&lt;auto, RealType&gt; Func&gt;
24554 requires Convertible&lt;Func::result_type, double&gt;
24555piecewise_constant_distribution(initializer_list&lt;RealType&gt; bl, Func fw);
24556</pre></blockquote>
24557</li>
24558
24559<li>
24560<p>
24561Between p.4 and p.5 of the same section insert a series of
24562new paragraphs nominated below as [p5_1], [p5_2], and [p5_3]
24563as part of the new member description:
24564</p>
24565
24566<blockquote><pre>template&lt;Callable&lt;auto, RealType&gt; Func&gt;
24567 requires Convertible&lt;Func::result_type, double&gt;
24568piecewise_constant_distribution(initializer_list&lt;RealType&gt; bl, Func fw);
24569</pre>
24570
24571<blockquote>
24572
24573<p>
24574[p5_1] <i>Complexity:</i> Exactly <tt>nf = max(bl.size(), 1) - 1</tt> invocations of <tt>fw</tt>.
24575</p>
24576
24577<p>
24578[p5_2] <i>Requires:</i>
24579</p>
24580
24581<ol type="a">
24582<li>
24583The relation <tt>0 &lt; S = w<sub>0</sub>+. . .+w<sub>n-1</sub></tt> shall hold. 
24584For all sampled values <tt><i>x<sub>k</sub></i></tt> defined below, <tt>fw(<i>x<sub>k</sub></i>)</tt> shall return a weight
24585   value <tt><i>w<sub>k</sub></i></tt> that is non-negative, non-NaN, and non-infinity;
24586</li>
24587<li>
24588If <tt>nf &gt; 0</tt> let <tt>b<sub><i>k</i></sub> = *(bl.begin() + k), k = 0, . . . , bl.size()-1</tt> and the
24589following relations shall hold for <tt>k = 0, . . . , nf-1: b<sub><i>k</i></sub> &lt; b<sub><i>k+1</i></sub></tt>.
24590</li>
24591</ol>
24592
24593<p>
24594[p5_3] <i>Effects:</i>
24595</p>
24596
24597<ol type="a">
24598<li>
24599<p>If <tt>nf == 0</tt>,</p>
24600<ol type="a">
24601<li>
24602lets the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist of the single
24603     value <tt>w<sub>0</sub> = 1</tt>, and
24604</li>
24605<li>
24606lets the sequence <tt>b</tt> have length <tt>n+1</tt> with <tt>b<sub>0</sub> = 0</tt> and <tt>b<sub>1</sub> = 1</tt>.
24607</li>
24608</ol>
24609</li>
24610
24611<li>
24612<p>Otherwise,</p>
24613<ol type="a">
24614<li>
24615sets <tt>n = nf</tt>, and <tt>[bl.begin(), bl.end())</tt> shall form the sequence <tt>b</tt> of
24616length <tt>n+1</tt>, and
24617</li>
24618<li>
24619<p>lets the sequences <tt>w</tt> have length <tt>n</tt> and for each <tt>k = 0, . . . ,n-1</tt>,
24620     calculates:</p>
24621<blockquote><pre>x<sub><i>k</i></sub> = 0.5*(b<sub><i>k+1</i></sub> + b<sub><i>k</i></sub>)
24622w<sub><i>k</i></sub> = fw(x<sub><i>k</i></sub>)
24623</pre></blockquote>
24624</li>
24625</ol>
24626</li>
24627
24628<li>
24629<p>
24630Constructs a <tt>piecewise_constant_distribution</tt> object with
24631the above computed sequence <tt>b</tt> as the interval boundaries
24632and with the probability densities:
24633</p>
24634<blockquote><pre>&#961;<sub><i>k</i></sub> = w<sub><i>k</i></sub>/(S * (b<sub><i>k+1</i></sub> - b<sub><i>k</i></sub>)) for k = 0, . . . , n-1.
24635</pre></blockquote>
24636
24637</li>
24638</ol>
24639
24640</blockquote>
24641</blockquote>
24642</li>
24643</ol>
24644
24645
24646
24647<p><b>Rationale:</b></p>
24648Addressed by
24649<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a> "Wording Tweaks for Concept-enabled Random Number Generation in C++0X".
24650
24651
24652
24653
24654
24655<hr>
24656<h3><a name="877"></a>877. to <tt>throw()</tt> or to <i>Throw:</i> Nothing.</h3>
24657<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
24658 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2008-08-23  <b>Last modified:</b> 2009-07-17</p>
24659<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>
24660<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>
24661<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
24662<p><b>Discussion:</b></p>
24663       <p>
24664
24665Recent changes to
24666the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">working
24667draft</a> have introduced a gratuitous inconsistency with the C++ 2003
24668version of the specification with respect to exception guarantees
24669provided by standard functions. While the C++ 2003 standard
24670consistenly uses the empty exception specification, <tt>throw()</tt>,
24671to declare functions that are guaranteed not to throw exceptions, the
24672current working draft contains a number of "<i>Throws:</i> Nothing."
24673clause to specify essentially the same requirement. The difference
24674between the two approaches is that the former specifies the behavior
24675of programs that violate the requirement (<tt>std::unexpected()</tt>
24676is called) while the latter leaves the behavior undefined.
24677
24678       </p>
24679       <p>
24680
24681A survey of the working draft reveals that there are a total of 209
24682occurrences of <tt>throw()</tt> in the library portion of the spec,
24683the majority in clause 18, a couple (literally) in 19, a handful in
2468420, a bunch in 22, four in 24, one in 27, and about a dozen in D.9.
24685
24686       </p>
24687       <p>
24688
24689There are also 203 occurrences of "<i>Throws:</i> Nothing." scattered
24690throughout the spec.
24691
24692       </p>
24693       <p>
24694
24695While sometimes there are good reasons to use the "<i>Throws:</i>
24696Nothing."  approach rather than making use of <tt>throw()</tt>, these
24697reasons do not apply in most of the cases where this new clause has
24698been introduced and the empty exception specification would be a
24699better approach.
24700
24701       </p>
24702       <p>
24703
24704First, functions declared with the empty exception specification
24705permit compilers to generate better code for calls to such
24706functions. In some cases, the compiler might even be able to eliminate
24707whole chunks of user-written code when instantiating a generic
24708template on a type whose operations invoked from the template
24709specialization are known not to throw. The prototypical example are
24710the <tt>std::uninitialized_copy()</tt>
24711and <tt>std::uninitialized_fill()</tt> algorithms where the
24712entire <tt>catch(...)</tt> block can be optimized away.
24713
24714       </p>
24715       <p>
24716
24717For example, given the following definition of
24718the <tt>std::uninitialized_copy</tt> function template and a
24719user-defined type <tt>SomeType</tt>:
24720
24721       </p>
24722       <blockquote>
24723           <pre>template &lt;class InputIterator, class ForwardIterator&gt;
24724ForwardIterator
24725uninitialized_copy (InputIterator first, InputIterator last, ForwardIterator res)
24726{
24727   typedef iterator_traits&lt;ForwardIterator&gt;::value_type ValueType;
24728
24729   ForwardIterator start = res;
24730
24731   try {
24732       for (; first != last; ++first, ++res)
24733           ::new (&amp;*res) ValueType (*first);
24734   }
24735   catch (...) {
24736       for (; start != res; --start)
24737           (&amp;*start)-&gt;~ValueType ();
24738       throw;
24739   }
24740   return res;
24741}
24742
24743struct SomeType {
24744   SomeType (const SomeType&amp;) <ins>throw ()</ins>;
24745}</pre>
24746       </blockquote>
24747       <p>
24748
24749compilers are able to emit the following efficient specialization
24750of <tt>std::uninitialized_copy&lt;const SomeType*, SomeType*&gt;</tt>
24751(note that the <tt>catch</tt> block has been optimized away):
24752
24753       </p>
24754       <blockquote>
24755           <pre>template &lt;&gt; SomeType*
24756uninitialized_copy (const SomeType *first, const SomeType *last, SomeType *res)
24757{
24758   for (; first != last; ++first, ++res)
24759       ::new (res) SomeType (*first);
24760
24761   return res;
24762}</pre>
24763       </blockquote>
24764       <p>
24765
24766Another general example is default constructors which, when decorated
24767with <tt>throw()</tt>, allow the compiler to eliminate the
24768implicit <tt>try</tt> and <tt>catch</tt> blocks that it otherwise must
24769emit around each the invocation of the constructor
24770in <i>new-expressions</i>.
24771
24772       </p>
24773       <p>
24774
24775For example, given the following definitions of
24776class <tt>MayThrow</tt> and <tt>WontThrow</tt> and the two
24777statements below:
24778
24779       </p>
24780       <blockquote>
24781           <pre>struct MayThrow {
24782   MayThrow ();
24783};
24784
24785struct WontThrow {
24786   WontThrow () <ins>throw ()</ins>;
24787};
24788
24789MayThrow  *a = new MayThrow [N];
24790WontThrow *b = new WontThrow [N];</pre>
24791
24792       </blockquote>
24793       <p>
24794
24795the compiler generates the following code for the first statement:
24796
24797       </p>
24798       <blockquote>
24799           <pre>MayThrow *a;
24800{
24801   MayThrow *first = operator new[] (N * sizeof (*a));
24802   MayThrow *last  = first + N;
24803   MayThrow *next  = first;
24804   try {
24805       for ( ; next != last; ++next)
24806           new (next) MayThrow;
24807   }
24808   catch (...) {
24809       for ( ; first != first; --next)
24810           next-&gt;~MayThrow ();
24811       operator delete[] (first);
24812       throw;
24813   }
24814   a = first;
24815}</pre>
24816       </blockquote>
24817       <p>
24818
24819but it is can generate much more compact code for the second statement:
24820
24821       </p>
24822       <blockquote>
24823           <pre>WontThrow *b    = operator new[] (N * sizeof (*b));
24824WontThrow *last = b + N;
24825for (WontThrow *next = b; next != last; ++next)
24826   new (next) WontThrow;
24827</pre>
24828       </blockquote>
24829       <p>
24830
24831Second, in order for users to get the maximum benefit out of the new
24832<tt>std::has_nothrow_xxx</tt> traits when using standard library types
24833it will be important for implementations to decorate all non throwing
24834copy constructors and assignment operators with <tt>throw()</tt>. Note
24835that while an optimizer may be able to tell whether a function without
24836an explicit exception specification can throw or not based on its
24837definition, it can only do so when it can see the source code of the
24838definition. When it can't it must assume that the function may
24839throw. To prevent violating the One Definition Rule,
24840the <tt>std::has_nothrow_xxx</tt> trait must return the most
24841pessimistic guess across all translation units in the program, meaning
24842that <tt>std::has_nothrow_xxx&lt;T&gt;::value</tt> must evaluate to
24843<tt>false</tt> for any <tt>T</tt> whose <tt>xxx</tt>
24844(where <tt>xxx</tt> is default or copy ctor, or assignment operator)
24845is defined out-of-line.
24846
24847       </p>
24848       <p>
24849
24850<b>Counterarguments:</b>
24851
24852       </p>
24853       <p>
24854
24855During the discussion of this issue
24856on <a href="mailto:c++std-lib@accu.org">c++std-lib@accu.org</a>
24857(starting with post <tt>c++std-lib-21950</tt>) the following arguments
24858in favor of the "<i>Throws:</i> Nothing." style have been made.
24859
24860       </p>
24861       <p>
24862         </p><ol>
24863           <li>
24864
24865Decorating functions that cannot throw with the empty exception
24866specification can cause the compiler to generate suboptimal code for
24867the implementation of the function when it calls other functions that
24868aren't known to the compiler not to throw (i.e., that aren't decorated
24869with <tt>throw()</tt> even if they don't actually throw). This is a
24870common situation when the called function is a C or POSIX function.
24871
24872           </li>
24873           <li>
24874
24875Alternate, proprietary mechanisms exist (such as
24876GCC <a href="http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Function-Attributes.html#index-g_t_0040code_007bnothrow_007d-function-attribute-2160"><tt>__attribute__((nothrow))</tt></a>
24877or Visual
24878C++ <a href="http://msdn.microsoft.com/en-us/library/49147z04%28VS.80%29.aspx"><tt>__declspec(nothrow)</tt></a>)
24879that let implementers mark up non-throwing functions, often without
24880the penalty mentioned in (1) above. The C++ standard shouldn't
24881preclude the use of these potentially more efficient mechanisms.
24882
24883           </li>
24884           <li>
24885
24886There are functions, especially function templates, that invoke
24887user-defined functions that may or may not be
24888declared <tt>throw()</tt>. Declaring such functions with the empty
24889exception specification will cause compilers to generate suboptimal
24890code when the user-defined function isn't also declared not to throw.
24891
24892           </li>
24893        </ol>
24894       
24895       <p>
24896
24897The answer to point (1) above is that implementers can (and some have)
24898declare functions with <tt>throw()</tt> to indicate to the compiler
24899that calls to the function can safely be assumed not to throw in order
24900to allow it to generate efficient code at the call site without also
24901having to define the functions the same way and causing the compiler
24902to generate suboptimal code for the function definition. That is, the
24903function is declared with <tt>throw()</tt> in a header but it's
24904defined without it in the source file. The <tt>throw()</tt>
24905declaration is suppressed when compiling the definition to avoid
24906compiler errors. This technique, while strictly speaking no permitted
24907by the language, is safe and has been employed in practice. For
24908example, the GNU C library takes this approach. Microsoft Visual C++
24909takes a similar approach by simply assuming that no function with C
24910language linkage can throw an exception unless it's explicitly
24911declared to do so using the language extension <tt>throw(...)</tt>.
24912
24913       </p>
24914       <p>
24915
24916Our answer to point (2) above is that there is no existing practice
24917where C++ Standard Library implementers have opted to make use of the
24918proprietary mechanisms to declare functions that don't throw. The
24919language provides a mechanism specifically designed for this
24920purpose. Avoiding its use in the specification itself in favor of
24921proprietary mechanisms defeats the purpose of the feature. In
24922addition, making use of the empty exception specification
24923inconsistently, in some areas of the standard, while conspicuously
24924avoiding it and making use of the "<i>Throws:</i> Nothing." form in
24925others is confusing to users.
24926
24927       </p>
24928       <p>
24929
24930The answer to point (3) is simply to exercise caution when declaring
24931functions and especially function templates with the empty exception
24932specification. Functions that required not to throw but that may call
24933back into user code are poor candidates for the empty exception
24934specification and should instead be specified using "<i>Throws:</i>
24935Nothing." clause.
24936
24937      </p>
24938
24939<p><i>[
249402009-07 Frankfurt
24941]</i></p>
24942
24943
24944<blockquote>
24945<p>
24946We need someone to do an extensive review.
24947</p>
24948<p>
24949NAD Future.
24950</p>
24951</blockquote>
24952
24953   
24954   <p><b>Proposed resolution:</b></p>
24955       <p>
24956
24957We propose two possible solutions. Our recommendation is to adopt
24958Option 1 below.
24959
24960       </p>
24961       <p>
24962
24963<b>Option 1:</b>
24964
24965       </p>
24966       <p>
24967
24968Except for functions or function templates that make calls back to
24969user-defined functions that may not be declared <tt>throw()</tt>
24970replace all occurrences of the "<i>Throws:</i> Nothing." clause with
24971the empty exception specification. Functions that are required not to
24972throw but that make calls back to user code should be specified to
24973"<i>Throw:</i> Nothing."
24974
24975       </p>
24976       <p>
24977
24978<b>Option 2:</b>
24979
24980       </p>
24981       <p>
24982
24983For consistency, replace all occurrences of the empty exception
24984specification with a "<i>Throws:</i> Nothing." clause.
24985
24986       </p>
24987   
24988
24989
24990
24991<hr>
24992<h3><a name="879"></a>879. Atomic load const qualification</h3>
24993<p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
24994 <b>Submitter:</b> Alexander Chemeris <b>Opened:</b> 2008-08-24  <b>Last modified:</b> 2009-10-26</p>
24995<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>
24996<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
24997<p><b>Discussion:</b></p>
24998<p>
24999The <tt>atomic_address</tt> type and <tt>atomic&lt;T*&gt;</tt> specialization provide atomic
25000updates to pointers.  However, the current specification requires
25001that the types pointer be to non-const objects.  This restriction
25002is unnecessary and unintended.
25003</p>
25004
25005<p><i>[
25006Summit:
25007]</i></p>
25008
25009<blockquote>
25010Move to review.  Lawrence will first check with Peter whether the
25011current examples are sufficient, or whether they need to be expanded to
25012include all cases.
25013</blockquote>
25014
25015<p><i>[
250162009-07 Frankfurt
25017]</i></p>
25018
25019
25020<blockquote>
25021<p>
25022Lawrence will handle all issues relating to atomics in a single paper.
25023</p>
25024<p>
25025LWG will defer discussion on atomics until that paper appears.
25026</p>
25027<p>
25028Move to Open.
25029</p>
25030</blockquote>
25031
25032<p><i>[
250332009-08-17 Handled by
25034<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2925.html">N2925</a>.
25035]</i></p>
25036
25037
25038<p><i>[
250392009-10 Santa Cruz:
25040]</i></p>
25041
25042
25043<blockquote>
25044NAD Editorial.  Solved by
25045<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
25046</blockquote>
25047
25048
25049
25050<p><b>Proposed resolution:</b></p>
25051<p>
25052Add const qualification to the pointer values of the <tt>atomic_address</tt>
25053and <tt>atomic&lt;T*&gt;</tt> specializations.  E.g.
25054</p>
25055
25056<blockquote><pre>typedef struct atomic_address {
25057   void store(<ins>const</ins> void*, memory_order = memory_order_seq_cst) volatile;
25058   void* exchange( <ins>const</ins> void*, memory_order = memory_order_seq_cst) volatile;
25059   bool compare_exchange( <ins>const</ins> void*&amp;, <ins>const</ins> void*,
25060                          memory_order, memory_order) volatile;
25061   bool compare_exchange( <ins>const</ins> void*&amp;, <ins>const</ins> void*,
25062                          memory_order = memory_order_seq_cst ) volatile;
25063   void* operator=(<ins>const</ins> void*) volatile;
25064} atomic_address;
25065
25066void atomic_store(volatile atomic_address*, <ins>const</ins> void*);
25067void atomic_store_explicit(volatile atomic_address*, <ins>const</ins> void*,
25068                          memory_order);
25069void* atomic_exchange(volatile atomic_address*<ins>, const void*</ins>);
25070void* atomic_exchange_explicit(volatile atomic_address*, <ins>const</ins> void*,
25071                              memory_order);
25072bool atomic_compare_exchange(volatile atomic_address*,
25073                            <ins>const</ins> void**, <ins>const</ins> void*);
25074bool atomic_compare_exchange_explicit(volatile atomic_address*,
25075                                     <ins>const</ins> void**, <ins>const</ins> void*,
25076                                     memory_order, memory_order);
25077</pre></blockquote>
25078
25079
25080
25081
25082
25083<hr>
25084<h3><a name="880"></a>880. Missing atomic exchange parameter</h3>
25085<p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
25086 <b>Submitter:</b> Lawrence Crowl <b>Opened:</b> 2008-08-24  <b>Last modified:</b> 2009-10-26</p>
25087<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>
25088<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
25089<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#942">942</a></p>
25090<p><b>Discussion:</b></p>
25091<p>
25092The <tt>atomic_exchange</tt> and <tt>atomic_exchange_explicit</tt> functions seem to
25093be inconsistently missing parameters.
25094</p>
25095
25096<p><i>[
25097Post Summit:
25098]</i></p>
25099
25100
25101<blockquote>
25102<p>
25103Lawrence: Need to write up a list for Pete with details.
25104</p>
25105<p>
25106Detlef: Should not be New, we already talked about in Concurrency group.
25107</p>
25108<p>
25109Recommend Open.
25110</p>
25111</blockquote>
25112
25113<p><i>[
251142009-07 Frankfurt
25115]</i></p>
25116
25117
25118<blockquote>
25119<p>
25120Lawrence will handle all issues relating to atomics in a single paper.
25121</p>
25122<p>
25123LWG will defer discussion on atomics until that paper appears.
25124</p>
25125<p>
25126Move to Open.
25127</p>
25128</blockquote>
25129
25130<p><i>[
251312009-08-17 Handled by
25132<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2925.html">N2925</a>.
25133]</i></p>
25134
25135
25136<p><i>[
251372009-10 Santa Cruz:
25138]</i></p>
25139
25140
25141<blockquote>
25142NAD Editorial.  Solved by
25143<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
25144</blockquote>
25145
25146
25147
25148<p><b>Proposed resolution:</b></p>
25149<p>
25150Add the appropriate parameters.  For example,
25151</p>
25152
25153<blockquote><pre>bool atomic_exchange(volatile atomic_bool*<ins>, bool</ins>);
25154bool atomic_exchange_explicit(volatile atomic_bool*, bool<ins>, memory_order</ins>);
25155</pre></blockquote>
25156
25157
25158
25159
25160
25161<hr>
25162<h3><a name="884"></a>884. shared_ptr swap</h3>
25163<p><b>Section:</b> 20.8.15.2.4 [util.smartptr.shared.mod] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
25164 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2008-09-15  <b>Last modified:</b> 2009-07-13</p>
25165<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
25166<p><b>Discussion:</b></p>
25167<blockquote><pre>#include &lt;memory&gt;
25168#include &lt;cassert&gt;
25169
25170struct A { };
25171struct B : A { };
25172
25173int main()
25174{
25175    std::shared_ptr&lt;A&gt; pa(new A);
25176    std::shared_ptr&lt;B&gt; pb(new B);
25177    std::swap&lt;A&gt;(pa, pb);  // N.B. no argument deduction
25178    assert( pa.get() == pb.get() );
25179    return 0;
25180}
25181</pre></blockquote>
25182
25183<p>
25184Is this behaviour correct (I believe it is) and if so, is it
25185unavoidable, or not worth worrying about?
25186</p>
25187
25188<p>
25189This calls the lvalue/rvalue swap overload for <tt>shared_ptr</tt>:
25190</p>
25191
25192<blockquote><pre>template&lt;class T&gt; void swap( shared_ptr&lt;T&gt; &amp; a, shared_ptr&lt;T&gt; &amp;&amp; b );
25193</pre></blockquote>
25194
25195<p>
25196silently converting the second argument from <tt>shared_ptr&lt;B&gt;</tt> to
25197<tt>shared_ptr&lt;A&gt;</tt> and binding the rvalue ref to the produced temporary.
25198</p>
25199
25200<p>
25201This is not, in my opinion, a <tt>shared_ptr</tt> problem; it is a general issue
25202with the rvalue swap overloads. Do we want to prevent this code from
25203compiling? If so, how?
25204</p>
25205
25206<p>
25207Perhaps we should limit rvalue args to swap to those types that would
25208benefit from the "swap trick".  Or, since we now have <tt>shrink_to_fit()</tt>, just
25209eliminate the rvalue swap overloads altogether.  The original motivation
25210was:
25211</p>
25212
25213<blockquote><pre>vector&lt;A&gt; v = ...;
25214...
25215swap(v, vector&lt;A&gt;(v));
25216</pre></blockquote>
25217
25218<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1690.html#Improved%20swap%20Interface">N1690</a>.
25219
25220<p><i>[
25221Batavia (2009-05):
25222]</i></p>
25223
25224<blockquote>
25225We agree with the proposed resolution.
25226Move to NAD Editorial.
25227</blockquote>
25228
25229
25230<p><b>Proposed resolution:</b></p>
25231<p>
25232Recommend NAD Editorial, fixed by
25233<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>.
25234</p>
25235
25236
25237
25238
25239
25240<hr>
25241<h3><a name="892"></a>892. Forward_list issues...</h3>
25242<p><b>Section:</b> 23.3.3.5 [forwardlist.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
25243 <b>Submitter:</b> Ed Smith-Rowland <b>Opened:</b> 2008-09-15  <b>Last modified:</b> 2009-03-09</p>
25244<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>
25245<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
25246<p><b>Discussion:</b></p>
25247<p>
25248I was looking at the latest draft on <tt>forward_list</tt>.  Especially the splice methods.
25249</p>
25250<p>
25251The first one splices a whole list after a given iterator in <tt>this</tt>.  The name is <tt>splice_after</tt>.
25252I think in 23.3.3.5 [forwardlist.ops] paragraph 40
25253change:
25254</p>
25255<blockquote>
25256<i>Effect:</i> Insert the contents of <tt>x</tt> <del>before</del> <ins>after</ins> <tt>position</tt>, ...
25257</blockquote>
25258
25259<p>
25260A deeper issue involves the complexity.  <tt>forward_list</tt> has no <tt>size</tt> and we
25261don't know when we've reached the end except to walk up to it.  To
25262splice we would need to hook the end of the source list to the item
25263after <tt>position</tt> in this list.  This would involve walking length of the
25264source list until we got to the last dereference-able element in source.
25265There's no way we could do this in O(1) unless we stored a bogus end in
25266<tt>forward_list</tt>.
25267</p>
25268<p>
25269OTOH, the last version of <tt>splice_after</tt> with iterator ranges we could do
25270in O(1) because we know how to hook the end of the source range to ...
25271</p>
25272<p>
25273Unless I'm misconceiving the whole thing.  Which is possible.  I'll look at it again.
25274</p>
25275<p>
25276I'm pretty sure about the first part though.
25277</p>
25278
25279<p><i>[
25280San Francisco:
25281]</i></p>
25282
25283
25284<blockquote>
25285<p>
25286This issue is more complicated than it looks.
25287</p>
25288<p>
25289paragraph 47: replace each <tt>(first, last) with (first, last]</tt>
25290</p>
25291<p>
25292add a statement after paragraph 48 that complexity is O(1)
25293</p>
25294<p>
25295remove the complexity statement from the first overload of splice_after
25296</p>
25297<p>
25298We may have the same problems with other modifiers, like erase_after.
25299Should it require that all iterators in the range (position, last] be
25300dereferenceable?
25301</p>
25302<p>
25303We do, however, like the proposed changes and consider them Editorial.
25304Move to NAD Editorial, Pending. Howard to open a new issue to handle the
25305problems with the complexity requirements.
25306</p>
25307<p>
25308Opened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#897">897</a>.
25309</p>
25310</blockquote>
25311
25312
25313<p><b>Proposed resolution:</b></p>
25314<p>
25315In 23.3.3.5 [forwardlist.ops] paragraph 40
25316change:
25317</p>
25318<blockquote>
25319<i>Effect:</i> Insert the contents of <tt>x</tt> <del>before</del> <ins>after</ins> <tt>position</tt>, ...
25320</blockquote>
25321
25322
25323
25324
25325
25326<hr>
25327<h3><a name="895"></a>895. "Requires:" on std::string::at et al</h3>
25328<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#Dup">Dup</a>
25329 <b>Submitter:</b> James Dennett <b>Opened:</b> 2008-09-16  <b>Last modified:</b> 2009-07-17</p>
25330<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>
25331<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
25332<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625">625</a></p>
25333<p><b>Discussion:</b></p>
25334<p>
25335Per discussion, we need an issue open to cover looking at "Requires"
25336clauses which are not constraints on user code, such as that on
25337<tt>std::basic_string::at</tt>.
25338</p>
25339
25340<p><i>[
253412009-07 Frankfurt
25342]</i></p>
25343
25344
25345<blockquote>
25346 Alan to address in paper.
25347</blockquote>
25348
25349
25350
25351<p><b>Proposed resolution:</b></p>
25352<p>
25353</p>
25354
25355
25356
25357
25358
25359<hr>
25360<h3><a name="897"></a>897. Forward_list issues... Part 2</h3>
25361<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#NAD%20Editorial">NAD Editorial</a>
25362 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2008-09-22  <b>Last modified:</b> 2009-10-20</p>
25363<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
25364<p><b>Discussion:</b></p>
25365<p>
25366This 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.
25367</p>
25368
25369<p><i>[
25370San Francisco:
25371]</i></p>
25372
25373
25374<blockquote>
25375<p>
25376This issue is more complicated than it looks.
25377</p>
25378<p>
25379paragraph 47: replace each <tt>(first, last) with (first, last]</tt>
25380</p>
25381<p>
25382add a statement after paragraph 48 that complexity is O(1)
25383</p>
25384<p>
25385remove the complexity statement from the first overload of splice_after
25386</p>
25387<p>
25388We may have the same problems with other modifiers, like erase_after.
25389Should it require that all iterators in the range (position, last] be
25390dereferenceable?
25391</p>
25392</blockquote>
25393
25394<p>
25395There are actually 3 issues here:
25396</p>
25397
25398<ol>
25399<li>
25400<p>
25401What value should <tt>erase_after</tt> return?  With <tt>list</tt>, code often
25402looks like:
25403</p>
25404<blockquote><pre>for (auto i = l.begin(); i != l.end();)
25405{
25406    // inspect *i and decide if you want to erase it
25407    // ...
25408    if (I want to erase *i)
25409        i = l.erase(i);
25410    else
25411        ++i;
25412}
25413</pre></blockquote>
25414<p>
25415I.e. the iterator returned from <tt>erase</tt> is useful for setting up the
25416logic for operating on the next element.  For <tt>forward_list</tt> this might
25417look something like:
25418</p>
25419<blockquote><pre>auto i = fl.before_begin();
25420auto ip1 = i;
25421for (++ip1; ip1 != fl.end(); ++ip1)
25422{
25423    // inspect *(i+1) and decide if you want to erase it
25424    // ...
25425    if (I want to erase *(i+1))
25426        i = fl.erase_after(i);
25427    else
25428        ++i;
25429    ip1 = i;
25430}
25431</pre></blockquote>
25432<p>
25433In the above example code, it is convenient if <tt>erase_after</tt> returns
25434the element <i>prior</i> to the erased element (range) instead of the element
25435<i>after</i> the erase element (range).
25436</p>
25437<p>
25438Existing practice:
25439</p>
25440<ul>
25441<li>SGI slist returns an iterator referencing the element <i>after</i> the erased range.</li>
25442<li>CodeWarrior slist returns an iterator referencing the element <i>before</i> the erased range.</li>
25443</ul>
25444<p>
25445There is not a strong technical argument for either solution over the other.
25446</p>
25447</li>
25448
25449<li>
25450<p>
25451With all other containers, operations always work on the range
25452<tt>[first, last)</tt> and/or <i>prior to</i> the given <tt>position</tt>.
25453</p>
25454<p>
25455With <tt>forward_list</tt>, operations sometimes work on the range
25456<tt>(first, last]</tt> and/or <i>after</i> the given <tt>position</tt>.
25457</p>
25458<p>
25459This is simply due to the fact that in order to operate on
25460<tt>*first</tt> (with <tt>forward_list</tt>) one needs access to
25461<tt>*(first-1)</tt>.  And that's not practical with
25462<tt>forward_list</tt>.  So the operating range needs to start with <tt>(first</tt>,
25463not <tt>[first</tt> (as the current working paper says). 
25464</p>
25465<p>
25466Additionally, if one is interested in  splicing the range <tt>(first, last)</tt>,
25467then (with <tt>forward_list</tt>), one needs practical (constant time) access to
25468<tt>*(last-1)</tt> so that one can set the <i>next</i> field in this node to
25469the proper value.  As this is not possible with <tt>forward_list</tt>, one must
25470specify the last element of interest instead of one past the last element of
25471interest.  The syntax for doing this is to pass <tt>(first, last]</tt> instead
25472of <tt>(first, last)</tt>.
25473</p>
25474<p>
25475With <tt>erase_after</tt> we have a choice of either erasing the range
25476<tt>(first, last]</tt> <em>or</em> <tt>(first, last)</tt>.  Choosing the latter
25477enables:
25478</p>
25479<blockquote><pre>x.erase_after(pos, x.end());
25480</pre></blockquote>
25481
25482<p>
25483With the former, the above statement is inconvenient or expensive due to the lack
25484of constant time access to <tt>x.end()-1</tt>.  However we could introduce:
25485</p>
25486
25487<blockquote><pre>iterator erase_to_end(const_iterator position);
25488</pre></blockquote>
25489
25490<p>
25491to compensate.
25492</p>
25493
25494<p>
25495The advantage of the former (<tt>(first, last]</tt>) for <tt>erase_after</tt>
25496is a consistency with <tt>splice_after</tt> which uses <tt>(first, last]</tt>
25497as the specified range.  But this either requires the addition of <tt>erase_to_end</tt>
25498or giving up such functionality.
25499</p>
25500
25501</li>
25502
25503<li>
25504As 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,
25505a <tt>splice_after</tt> should work on the source range <tt>(first, last]</tt>
25506if the operation is to be <i>&#927;</i>(1).  When splicing an entire list <tt>x</tt> the
25507algorithm needs <tt>(x.before_begin(), x.end()-1]</tt>.  Unfortunately <tt>x.end()-1</tt>
25508is not available in constant time unless we specify that it must be.  In order to
25509make <tt>x.end()-1</tt> available in constant time, the implementation would have
25510to dedicate a pointer to it.  I believe the design of
25511<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2543.htm">N2543</a>
25512intended a nominal overhead of <tt>foward_list</tt> of 1 pointer.  Thus splicing
25513one <i>entire</i> <tt>forward_list</tt> into another can not be <i>&#927;</i>(1).
25514</li>
25515</ol>
25516
25517<p><i>[
25518Batavia (2009-05):
25519]</i></p>
25520
25521<blockquote>
25522<p>
25523We agree with the proposed resolution.
25524</p>
25525<p>
25526Move to Review.
25527</p>
25528</blockquote>
25529
25530<p><i>[
255312009-07 Frankfurt
25532]</i></p>
25533
25534
25535<blockquote>
25536<p>
25537We may need a new issue to correct splice_after, because it may no
25538longer be correct to accept an rvalues as an argument. Merge may be
25539affected, too. This might be issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1133">1133</a>. (Howard: confirmed)
25540</p>
25541<p>
25542Move this to Ready, but the Requires clause of the second form of
25543splice_after should say "(first, last)," not "(first, last]" (there are
25544three occurrences). There was considerable discussion on this. (Howard: fixed)
25545</p>
25546<p>
25547Alan suggested removing the "foward_last&lt;T. Alloc&gt;&amp;&amp; x"
25548parameter from the second form of splice_after, because it is redundant.
25549PJP wanted to keep it, because it allows him to check for bad ranges
25550(i.e. "Granny knots").
25551</p>
25552<p>
25553We prefer to keep <tt>x</tt>.
25554</p>
25555<p>
25556Beman. Whenever we deviate from the customary half-open range in the
25557specification, we should add a non-normative comment to the standard
25558explaining the deviation. This clarifies the intention and spares the
25559committee much confusion in the future.
25560</p>
25561<p>
25562Alan to write a non-normative comment to explain the use of fully-closed ranges.
25563</p>
25564<p>
25565Move to Ready, with the changes described above. (Howard: awaiting note from Alan)
25566</p>
25567</blockquote>
25568
25569<p><i>[
255702009-10 Santa Cruz:
25571]</i></p>
25572
25573
25574<blockquote>
25575NAD Editorial, addressed by
25576<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2988.pdf">N2988</a>.
25577</blockquote>
25578
25579
25580
25581<p><b>Proposed resolution:</b></p>
25582<p>
25583Wording 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
25584independent of that issue.
25585</p>
25586
25587<p>
25588Change 23.3.3.4 [forwardlist.modifiers]:
25589</p>
25590
25591<blockquote>
25592<pre>iterator erase_after(const_iterator position);
25593</pre>
25594<blockquote>
25595<p>
25596<i>Requires:</i> The iterator following <tt>position</tt> is dereferenceable.
25597</p>
25598<p>
25599<i>Effects:</i> Erases the element pointed to by the iterator following <tt>position</tt>.
25600</p>
25601<p>
25602<i>Returns:</i> <del>An iterator pointing to the element following the one that was erased, or <tt>end()</tt> if no such 
25603element exists</del>
25604<ins>An iterator equal to <tt>position</tt></ins>.
25605</p>
25606</blockquote>
25607
25608
25609<pre>iterator erase_after(const_iterator position, <ins>const_</ins>iterator last);
25610</pre>
25611<blockquote>
25612<p>
25613<i>Requires:</i> All iterators in the range
25614<tt><del>[</del><ins>(</ins>position,last)</tt>
25615are dereferenceable.
25616</p>
25617<p>
25618<i>Effects:</i> Erases the elements in the range
25619<tt><del>[</del><ins>(</ins>position,last)</tt>.
25620</p>
25621<p>
25622<i>Returns:</i>  <ins>An iterator equal to <tt>position</tt></ins> <del><tt>last</tt></del>
25623</p>
25624</blockquote>
25625</blockquote>
25626
25627<p>
25628Change 23.3.3.5 [forwardlist.ops]:
25629</p>
25630
25631<blockquote>
25632<pre>void splice_after(const_iterator position, forward_list&lt;T,Allocator&gt;&amp;&amp; x);
25633</pre>
25634<blockquote>
25635<p>
25636<i>Requires:</i> <tt>position</tt> is <tt>before_begin()</tt> or a
25637dereferenceable iterator in the range <tt>[begin(), end))</tt>. <tt>&amp;x != this</tt>.
25638</p>
25639<p>
25640<i>Effects:</i> Inserts the contents of <tt>x</tt> after <tt>position</tt>, and
25641<tt>x</tt> becomes empty. Pointers and references to 
25642the moved elements of <tt>x</tt> now refer to those same elements but as members of <tt>*this</tt>.
25643Iterators referring to the moved elements will continue to refer to their elements,
25644but they now behave as iterators into <tt>*this</tt>, not into <tt>x</tt>. 
25645</p>
25646<p>
25647<i>Throws:</i> Nothing. 
25648</p>
25649<p>
25650<i>Complexity:</i> <del><i>&#927;</i>(1)</del> <ins><i>&#927;</i>(<tt>distance(x.begin(), x.end())</tt>)</ins>
25651</p>
25652</blockquote>
25653
25654<p>...</p>
25655
25656<pre>void splice_after(const_iterator position, forward_list&lt;T,Allocator&gt;&amp;&amp; x, 
25657                  const_iterator first, const_iterator last);
25658</pre>
25659<blockquote>
25660<p>
25661<i>Requires:</i> <tt>position</tt> is <tt>before_begin()</tt> or a
25662dereferenceable iterator in the range <tt>[begin(), end))</tt>.
25663<tt>(first,last)</tt> is a valid range in
25664<tt>x</tt>, and all iterators in the range
25665<tt>(first,last)</tt> are dereferenceable.
25666<tt>position</tt> is not an iterator in the range <tt>(first,last)</tt>.
25667</p>
25668<p>
25669<i>Effects:</i> Inserts elements in the range <tt>(first,last)</tt>
25670after <tt>position</tt> and removes the elements from <tt>x</tt>.
25671Pointers and references to the moved elements of <tt>x</tt> now refer to
25672those same elements but as members of <tt>*this</tt>. Iterators
25673referring to the moved elements will continue to refer to their
25674elements, but they now behave as iterators into <tt>*this</tt>, not into
25675<tt>x</tt>.
25676</p>
25677<p>
25678<ins><i>Complexity:</i> <i>&#927;</i>(1).</ins>
25679</p>
25680</blockquote>
25681
25682</blockquote>
25683
25684
25685
25686
25687
25688
25689<hr>
25690<h3><a name="901"></a>901. insert iterators can move from lvalues</h3>
25691<p><b>Section:</b> 24.5.2.5 [insert.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
25692 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-24  <b>Last modified:</b> 2009-07-13</p>
25693<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
25694<p><b>Discussion:</b></p>
25695<p><b>Addresses UK 282</b></p>
25696
25697<p>
25698The requires clause on the <tt>const T &amp;</tt> overloads in
25699<tt>back_insert_iterator/front_insert_iterator/insert_iterator</tt> mean that the
25700assignment operator will implicitly move from lvalues of a move-only type.
25701</p>
25702<p>
25703Suggested resolutions are:
25704</p>
25705<ol type="a">
25706<li>
25707Add another overload with a negative constraint on copy-constructible
25708and flag it "= delete".
25709</li>
25710<li>
25711Drop the copy-constructible overload entirely and rely on perfect
25712forwarding to catch move issues one level deeper.
25713</li>
25714<li>
25715This is a fundamental problem in move-syntax that relies on the
25716presence of two overloads, and we need to look more deeply into this
25717area as a whole - do not solve this issue in isolation.
25718</li>
25719</ol>
25720
25721<p><i>[
25722Post Summit, Alisdair adds:
25723]</i></p>
25724
25725
25726<blockquote>
25727<p>
25728Both comment and issue have been resolved by the adoption of
25729<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>
25730(rvalue references safety fix) at the last meeting.
25731</p>
25732
25733<p>
25734Suggest resolve as NAD Editorial with a reference to the paper.
25735</p>
25736</blockquote>
25737
25738<p><i>[
25739Batavia (2009-05):
25740]</i></p>
25741
25742<blockquote>
25743We agree that this has been resolved in the latest Working Draft.
25744Move to NAD.
25745</blockquote>
25746
25747
25748<p><b>Proposed resolution:</b></p>
25749<p>
25750Recommend NAD, addressed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>.
25751</p>
25752
25753
25754
25755
25756
25757<hr>
25758<h3><a name="902"></a>902. Regular is the wrong concept to constrain numeric_limits</h3>
25759<p><b>Section:</b> 18.3.1 [limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
25760 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-09-24  <b>Last modified:</b> 2009-07-16</p>
25761<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#limits">issues</a> in [limits].</p>
25762<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
25763<p><b>Discussion:</b></p>
25764
25765<p><b>Addresses FR 32 and DE 16</b></p>
25766
25767<p>
25768<tt>numeric_limits</tt> has functions specifically designed to return NaNs, which
25769break the model of <tt>Regular</tt> (via its axioms.)  While floating point types
25770will be acceptible in many algorithms taking <tt>Regular</tt> values, it is not
25771appopriate for this specific API and we need a less refined constraint.
25772</p>
25773
25774<p>FR 32:</p>
25775
25776<blockquote>
25777The definition of <tt>numeric_limits&lt;&gt;</tt> as requiring a regular
25778type is both conceptually wrong and operationally illogical. As we
25779pointed before, this mistake needs to be corrected. For example, the
25780template can be left unconstrained. In fact this reflects a much more
25781general problem with concept_maps/axioms and their interpretations. It
25782appears that the current text heavily leans toward experimental academic
25783type theory.
25784</blockquote>
25785
25786<p>DE 16:</p>
25787
25788<blockquote>
25789The class template <tt>numeric_limits</tt> should not specify the Regular concept
25790requirement for its template parameter, because it contains functions
25791returning NaN values for floating-point types; these values violate the
25792semantics of EqualityComparable.
25793</blockquote>
25794
25795<p><i>[
25796Summit:
25797]</i></p>
25798
25799
25800<blockquote>
25801Move to Open.  Alisdair and Gaby will work on a solution, along with the new
25802treatment of axioms in clause 14.
25803</blockquote>
25804
25805
25806
25807<p><b>Proposed resolution:</b></p>
25808<p>
25809</p>
25810
25811
25812
25813
25814
25815<hr>
25816<h3><a name="903"></a>903. <tt>back_insert_iterator</tt> issue</h3>
25817<p><b>Section:</b> 24.5.2.1 [back.insert.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
25818 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2008-09-19  <b>Last modified:</b> 2009-07-16</p>
25819<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
25820<p><b>Discussion:</b></p>
25821<p>
25822I just noticed this; don't know how far the problem(?) extends or
25823whether it's new or existing: <tt>back_insert_iterator</tt>'s <tt>operator*</tt> is not
25824<tt>const</tt>, so you can't dereference a <tt>const</tt> one.
25825</p>
25826
25827<p><i>[
25828Post Summit Daniel adds:
25829]</i></p>
25830
25831
25832<blockquote>
25833<p>
25834If done, this change should be applied for <tt>front_insert_iterator</tt>,
25835<tt>insert_iterator</tt>, <tt>ostream_iterator</tt>, and <tt>ostreambuf_iterator</tt> as well.
25836</p>
25837</blockquote>
25838
25839<p><i>[
25840Batavia (2009-05):
25841]</i></p>
25842
25843<blockquote>
25844<p>
25845Alisdair notes that these all are output iterators.
25846Howard points out that <tt>++*i</tt>
25847would no longer work if we made this change.
25848</p>
25849<p>
25850Move to NAD.
25851</p>
25852</blockquote>
25853
25854<p><i>[
258552009-05-25 Daniel adds:
25856]</i></p>
25857
25858
25859<ol>
25860<li>
25861If <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1009">1009</a> is accepted, <tt>OutputIterator</tt> does no longer support post increment.
25862</li>
25863<li>
25864To support backward compatibility a second overload of <tt>operator*</tt>
25865can be added.
25866Note that the <tt>HasDereference</tt> concept (and the <tt>HasDereference</tt> part of concept
25867<tt>Iterator</tt>) was specifically refactored to cope with optional const
25868qualification and
25869to properly reflect the dual nature of built-in <tt>operator*</tt> as of
2587013.5.8 [over.literal]/6.
25871</li>
25872</ol>
25873
25874
25875<p><b>Proposed resolution:</b></p>
25876
25877
25878
25879
25880
25881<hr>
25882<h3><a name="905"></a>905. Mutex specification questions</h3>
25883<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#Dup">Dup</a>
25884 <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2008-09-18  <b>Last modified:</b> 2009-03-22</p>
25885<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>
25886<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
25887<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a></p>
25888<p><b>Discussion:</b></p>
25889<p>
25890A few questions on the current WP,
25891<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>:
25892</p>
25893<p>
2589430.4.1 [thread.mutex.requirements]/24 says an expression
25895<tt>mut.unlock()</tt> "Throws: Nothing." I'm assuming that, per 17.6.3.11 [res.on.required], errors that violate the precondition "The
25896calling thread shall own the mutex" opens the door for throwing an
25897exception anyway, such as to report unbalanced unlock operations and
25898unlocking from a thread that does not have ownership. Right?
25899</p>
25900<p>
2590130.4.1.1 [thread.mutex.class]/3 (actually numbered paragraph "27"
25902in the WP; this is just a typo I think) says
25903</p>
25904<blockquote>
25905<p>
25906The behavior of a program is undefined if:
25907</p>
25908<ul>
25909<li>it destroys a <tt>mutex</tt> object owned by any thread,</li>
25910<li>a thread that owns a <tt>mutex</tt> object calls <tt>lock()</tt> or <tt>try_lock()</tt> on that object, or</li>
25911<li>a thread terminates while owning a <tt>mutex</tt> object.</li>
25912</ul>
25913</blockquote>
25914
25915<p>
25916As already discussed, I think the second bullet should be removed, and
25917such a <tt>lock()</tt> or <tt>try_lock()</tt> should fail with an
25918exception or returning <tt>false</tt>, respectively.
25919</p>
25920<p>
25921A potential addition to the list would be
25922</p>
25923<ul>
25924<li>a thread unlocks a <tt>mutex</tt> it does not have ownership of.</li>
25925</ul>
25926<p>
25927but without that the status quo text endorses the technique of the
25928program logically transferring ownership of a mutex to another thread
25929with correctness enforced by programming discipline. Was that intended?
25930</p>
25931
25932<p><i>[
25933Summit:
25934]</i></p>
25935
25936
25937<blockquote>
25938<p>
25939Two resolutions: "not a defect" and "duplicate", as follows:
25940</p>
25941<ul>
25942<li>
2594330.4.1 [thread.mutex.requirements]/24: NAD. If the precondition
25944fails the program has undefined behaviour and therefore an
25945implementation may throw an exception already.
25946</li>
25947<li>
2594830.4.1.1 [thread.mutex.class]/3 bullet 2: Already addressed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#893">893</a>.
25949</li>
25950<li>
2595130.4.1.1 [thread.mutex.class]/3 proposed addition: NAD. This is
25952already covered by the mutex requirements, which have ownership as a
25953Precondition.
25954</li>
25955</ul>
25956</blockquote>
25957
25958
25959<p><b>Proposed resolution:</b></p>
25960
25961
25962
25963
25964
25965
25966<hr>
25967<h3><a name="906"></a>906. <tt>ObjectType</tt> is the wrong concept to constrain <tt>initializer_list</tt></h3>
25968<p><b>Section:</b> 18.9 [support.initlist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
25969 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-09-26  <b>Last modified:</b> 2009-07-16</p>
25970<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
25971<p><b>Discussion:</b></p>
25972<p>
25973The currently proposed constraint on <tt>initializer_list</tt>'s element type
25974<tt>E</tt> is that is has to meet <tt>ObjectType</tt>. This is an underspecification,
25975because both core language and library part of <tt>initializer_list</tt>
25976make clear, that it references an implicitly allocated array:
25977</p>
25978<p>
259798.5.4 [dcl.init.list]/4:
25980</p>
25981<blockquote>
25982When an initializer list is implicitly converted to a
25983<tt>std::initializer_list&lt;E&gt;</tt>, the object passed is constructed as if the
25984implementation allocated an array of N elements of type <tt>E</tt>, where
25985N is the number of elements in the initializer list.[..]
25986</blockquote>
25987
25988<p>
2598918.9 [support.initlist]/2.
25990</p>
25991
25992<blockquote>
25993An object of type <tt>initializer_list&lt;E&gt;</tt> provides access to an array of
25994objects of type <tt>const E</tt>.[..]
25995</blockquote>
25996
25997<p>
25998Therefore, <tt>E</tt> needs to fulfill concept <tt>ValueType</tt> (thus excluding
25999abstract class types). This stricter requirement should be added
26000to prevent deep instantiation errors known from the bad old times,
26001as shown in the following example:
26002</p>
26003
26004<blockquote><pre>// Header A: (Should concept-check even in stand-alone modus)
26005
26006template &lt;DefaultConstructible T&gt;
26007requires MoveConstructible&lt;T&gt;
26008void generate_and_do_3(T a) {
26009  std::initializer_list&lt;T&gt; list{T(), std::move(a), T()};
26010  ...
26011}
26012
26013void do_more();
26014void do_more_or_less();
26015
26016template &lt;DefaultConstructible T&gt;
26017requires MoveConstructible&lt;T&gt;
26018void more_generate_3() {
26019  do_more();
26020  generate_and_do_3(T());
26021}
26022
26023template &lt;DefaultConstructible T&gt;
26024requires MoveConstructible&lt;T&gt;
26025void something_and_generate_3() {
26026  do_more_or_less();
26027  more_generate_3();
26028}
26029
26030// Test.cpp
26031
26032#include "A.h"
26033
26034class Abstract {
26035public:
26036  virtual ~Abstract();
26037  virtual void foo() = 0; // abstract type
26038  Abstract(Abstract&amp;&amp;){} // MoveConstructible
26039  Abstract(){} // DefaultConstructible
26040};
26041
26042int main() {
26043  // The restricted template *accepts* the argument, but
26044  // causes a deep instantiation error in the internal function
26045  // generate_and_do_3:
26046  something_and_generate_3&lt;Abstract&gt;();
26047}
26048</pre></blockquote>
26049
26050<p>
26051The proposed stricter constraint does not minimize the aim to
26052support more general containers for which <tt>ObjectType</tt> would be
26053sufficient. If such an extended container (lets assume it's still a
26054class template) provides a constructor that accepts an <tt>initializer_list</tt>
26055only <em>this</em> constructor would need to be restricted on <tt>ValueType</tt>:
26056</p>
26057
26058<blockquote><pre>template&lt;ObjectType T&gt;
26059class ExtContainer {
26060public:
26061  requires ValueType&lt;T&gt;
26062  ExtContainer(std::initializer_list&lt;T&gt;);
26063  ...
26064};
26065</pre></blockquote>
26066
26067<p><i>[
26068Batavia (2009-05):
26069]</i></p>
26070
26071<blockquote>
26072Move to Tentatively Ready.
26073</blockquote>
26074
26075<p><i>[
260762009-07 Frankfurt:
26077]</i></p>
26078
26079
26080<blockquote>
26081Need to look at again without concepts.
26082</blockquote>
26083
26084
26085
26086<p><b>Proposed resolution:</b></p>
26087<ol>
26088<li>
26089In 18.9 [support.initlist]/p.1 replace in "header <tt>&lt;initializer_list&gt;</tt> synopsis"
26090the constraint "<tt>ObjectType</tt>" in the template parameter list by the
26091constraint "<tt>ValueType</tt>".
26092</li>
26093</ol>
26094
26095
26096
26097
26098
26099
26100<hr>
26101<h3><a name="908"></a>908. Deleted assignment operators for atomic types must be volatile</h3>
26102<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#NAD%20Editorial">NAD Editorial</a>
26103 <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2008-09-26  <b>Last modified:</b> 2009-10-26</p>
26104<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>
26105<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
26106<p><b>Discussion:</b></p>
26107
26108<p><b>Addresses US 90</b></p>
26109
26110<p>
26111The deleted copy-assignment operators for the atomic types are not
26112marked as volatile in N2723, whereas the assignment operators from the
26113associated non-atomic types are. e.g.
26114</p>
26115<blockquote><pre>atomic_bool&amp; operator=(atomic_bool const&amp;) = delete;
26116atomic_bool&amp; operator=(bool) volatile;
26117</pre></blockquote>
26118
26119<p>
26120This leads to ambiguity when assigning a non-atomic value to a
26121non-volatile instance of an atomic type:
26122</p>
26123<blockquote><pre>atomic_bool b;
26124b=false;
26125</pre></blockquote>
26126
26127<p>
26128Both assignment operators require a standard conversions: the
26129copy-assignment operator can use the implicit <tt>atomic_bool(bool)</tt>
26130conversion constructor to convert <tt>false</tt> to an instance of
26131<tt>atomic_bool</tt>, or <tt>b</tt> can undergo a qualification conversion in order to
26132use the assignment from a plain <tt>bool</tt>.
26133</p>
26134
26135<p>
26136This 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.
26137</p>
26138
26139<p><i>[
26140Summit:
26141]</i></p>
26142
26143<blockquote>
26144Move to open. Assign to Lawrence. Related to US 90 comment.
26145</blockquote>
26146
26147<p><i>[
261482009-08-17 Handled by
26149<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2925.html">N2925</a>.
26150]</i></p>
26151
26152
26153<p><i>[
261542009-10 Santa Cruz:
26155]</i></p>
26156
26157
26158<blockquote>
26159NAD Editorial.  Solved by
26160<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
26161</blockquote>
26162
26163
26164
26165<p><b>Proposed resolution:</b></p>
26166<p>
26167Add volatile qualification to the deleted copy-assignment operator of
26168all the atomic types:
26169</p>
26170
26171<blockquote><pre>atomic_bool&amp; operator=(atomic_bool const&amp;) <ins>volatile</ins> = delete;
26172atomic_itype&amp; operator=(atomic_itype const&amp;) <ins>volatile</ins> = delete;
26173</pre></blockquote>
26174
26175<p>
26176etc.
26177</p>
26178<p>
26179This will mean that the deleted copy-assignment operator will require
26180<i>two</i> conversions in the above example, and thus be a worse match than
26181the assignment from plain <tt>bool</tt>.
26182</p>
26183
26184
26185
26186
26187
26188<hr>
26189<h3><a name="912"></a>912. Array swap needs to be conceptualized</h3>
26190<p><b>Section:</b> 25.3.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
26191 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-10-01  <b>Last modified:</b> 2009-07-13</p>
26192<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.swap">issues</a> in [alg.swap].</p>
26193<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
26194<p><b>Discussion:</b></p>
26195<p>
26196With the adaption of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809">809</a>
26197we have a new algorithm <tt>swap</tt> for C-arrays, which needs to be conceptualized.
26198</p>
26199
26200<p><i>[
26201Post Summit Daniel adds:
26202]</i></p>
26203
26204
26205<blockquote>
26206Recommend as NAD Editorial: The changes have already been applied to the WP
26207<a href="" ref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>.
26208</blockquote>
26209
26210<p><i>[
26211Batavia (2009-05):
26212]</i></p>
26213
26214<blockquote>
26215Move to NAD; the changes have already been made.
26216</blockquote>
26217
26218
26219<p><b>Proposed resolution:</b></p>
26220<p>
26221Replace in 25.3.3 [alg.swap] before p. 3 until p. 4 by
26222</p>
26223
26224<blockquote><pre>template &lt;<del>class</del> <ins>ValueType</ins> T, size_t N&gt;
26225<ins>requires Swappable&lt;T&gt;</ins>
26226void swap(T (&amp;a)[N], T (&amp;b)[N]);
26227</pre>
26228<blockquote>
26229<p>
26230<del><i>Requires:</i> <tt>T</tt> shall be <tt>Swappable</tt>.</del>
26231</p>
26232<p>
26233<i>Effects:</i> <tt>swap_ranges(a, a + N, b);</tt>
26234</p>
26235</blockquote>
26236</blockquote>
26237
26238
26239
26240
26241
26242
26243<hr>
26244<h3><a name="913"></a>913. Superfluous requirements for replace algorithms</h3>
26245<p><b>Section:</b> 25.3.5 [alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
26246 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-10-03  <b>Last modified:</b> 2009-07-14</p>
26247<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.replace">issues</a> in [alg.replace].</p>
26248<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
26249<p><b>Discussion:</b></p>
26250<p>
26251(A) 25.3.5 [alg.replace]/1:
26252</p>
26253
26254<blockquote>
26255<i>Requires:</i> The expression <tt>*first = new_value</tt> shall be valid.
26256</blockquote>
26257
26258<p>
26259(B) 25.3.5 [alg.replace]/4:
26260</p>
26261
26262<blockquote>
26263<i>Requires:</i> The results of the expressions <tt>*first</tt> and <tt>new_value</tt> shall
26264be writable to the result output iterator.[..]
26265</blockquote>
26266
26267<p>
26268Since conceptualization, the quoted content of these clauses is covered
26269by the existing requirements
26270</p>
26271
26272<p>
26273(A) <tt>OutputIterator&lt;Iter, const T&amp;&gt;</tt>
26274</p>
26275
26276<p>
26277and
26278</p>
26279
26280<p>
26281(B) <tt>OutputIterator&lt;OutIter, InIter::reference&gt; &amp;&amp; OutputIterator&lt;OutIter, const T&amp;&gt;</tt>
26282</p>
26283
26284<p>
26285resp, and thus should be removed.
26286</p>
26287
26288<p><i>[
26289Batavia (2009-05):
26290]</i></p>
26291
26292<blockquote>
26293<p>
26294We agree with the proposed resolution.
26295</p>
26296<p>
26297Move to Tentatively Ready.
26298</p>
26299</blockquote>
26300
26301
26302<p><b>Proposed resolution:</b></p>
26303<ol type="A">
26304<li>
26305<p>
26306Remove 25.3.5 [alg.replace]/1.
26307</p>
26308<blockquote><pre>template&lt;ForwardIterator Iter, class T&gt; 
26309  requires OutputIterator&lt;Iter, Iter::reference&gt; 
26310        &amp;&amp; OutputIterator&lt;Iter, const T&amp;&gt; 
26311        &amp;&amp; HasEqualTo&lt;Iter::value_type, T&gt; 
26312  void replace(Iter first, Iter last, 
26313               const T&amp; old_value, const T&amp; new_value); 
26314
26315template&lt;ForwardIterator Iter, Predicate&lt;auto, Iter::value_type&gt; Pred, class T&gt; 
26316  requires OutputIterator&lt;Iter, Iter::reference&gt; 
26317        &amp;&amp; OutputIterator&lt;Iter, const T&amp;&gt; 
26318        &amp;&amp; CopyConstructible&lt;Pred&gt; 
26319  void replace_if(Iter first, Iter last, 
26320                  Pred pred, const T&amp; new_value);
26321</pre>
26322<blockquote>
26323<del>1 <i>Requires:</i> The expression <tt>*first = new_value</tt> shall be valid.</del>
26324</blockquote>
26325</blockquote>
26326</li>
26327<li>
26328<p>
2632925.3.5 [alg.replace]/4: Remove the sentence "The results of the
26330expressions <tt>*first</tt> and
26331<tt>new_value</tt> shall be writable to the result output iterator.".
26332</p>
26333<blockquote><pre>template&lt;InputIterator InIter, typename OutIter, class T&gt; 
26334  requires OutputIterator&lt;OutIter, InIter::reference&gt; 
26335        &amp;&amp; OutputIterator&lt;OutIter, const T&amp;&gt; 
26336        &amp;&amp; HasEqualTo&lt;InIter::value_type, T&gt; 
26337  OutIter replace_copy(InIter first, InIter last, 
26338                       OutIter result, 
26339                       const T&amp; old_value, const T&amp; new_value);
26340
26341template&lt;InputIterator InIter, typename OutIter,
26342         Predicate&lt;auto, InIter::value_type&gt; Pred, class T&gt; 
26343  requires OutputIterator&lt;OutIter, InIter::reference&gt; 
26344        &amp;&amp; OutputIterator&lt;OutIter, const T&amp;&gt; 
26345        &amp;&amp; CopyConstructible&lt;Pred&gt; 
26346  OutIter replace_copy_if(InIter first, InIter last, 
26347                          OutIter result, 
26348                          Pred pred, const T&amp; new_value);
26349</pre>
26350<blockquote>
263514 <i>Requires:</i> <del>The results of the expressions <tt>*first</tt> and
26352<tt>new_value</tt> shall be writable to the <tt>result</tt> output
26353iterator.</del> The ranges <tt>[first,last)</tt> and <tt>[result,result +
26354(last - first))</tt> shall not overlap.
26355</blockquote>
26356</blockquote>
26357</li>
26358</ol>
26359
26360
26361
26362
26363
26364<hr>
26365<h3><a name="914"></a>914. Superfluous requirement for unique</h3>
26366<p><b>Section:</b> 25.3.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
26367 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-10-03  <b>Last modified:</b> 2009-07-14</p>
26368<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
26369<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
26370<p><b>Discussion:</b></p>
26371<p>
2637225.3.9 [alg.unique]/2: "Requires: The comparison function shall be an
26373equivalence relation."
26374</p>
26375
26376<p>
26377The essence of this is already covered by the given requirement
26378</p>
26379
26380<blockquote><pre>EquivalenceRelation&lt;auto, Iter::value_type&gt; Pred
26381</pre></blockquote>
26382
26383<p>
26384and should thus be removed.
26385</p>
26386
26387<p><i>[
26388Batavia (2009-05):
26389]</i></p>
26390
26391<blockquote>
26392We agree with the proposed resolution.
26393Move to Tentatively Ready.
26394</blockquote>
26395
26396
26397<p><b>Proposed resolution:</b></p>
26398<p>
26399Remove 25.3.9 [alg.unique]/2
26400</p>
26401
26402<blockquote><pre>template&lt;ForwardIterator Iter&gt;
26403  requires OutputIterator&lt;Iter, Iter::reference&gt;
26404        &amp;&amp; EqualityComparable&lt;Iter::value_type&gt;
26405  Iter unique(Iter first, Iter last);
26406
26407template&lt;ForwardIterator Iter, EquivalenceRelation&lt;auto, Iter::value_type&gt; Pred&gt;
26408  requires OutputIterator&lt;Iter, RvalueOf&lt;Iter::reference&gt;::type&gt;
26409        &amp;&amp; CopyConstructible&lt;Pred&gt;
26410  Iter unique(Iter first, Iter last,
26411               Pred pred);
26412</pre>
26413<blockquote>
26414<p>
264151 <i>Effects:</i> ...
26416</p>
26417<p>
26418<del>2 <i>Requires:</i> The comparison function shall be an equivalence relation.</del>
26419</p>
26420</blockquote>
26421</blockquote>
26422
26423
26424
26425
26426
26427<hr>
26428<h3><a name="916"></a>916. Redundant move-assignment operator of <tt>pair</tt> should be removed</h3>
26429<p><b>Section:</b> 20.3.4 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
26430 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-10-04  <b>Last modified:</b> 2009-10-23</p>
26431<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>
26432<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>
26433<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
26434<p><b>Discussion:</b></p>
26435<p><b>see also <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#917">917</a>.</b></p>
26436
26437<p>
26438The current WP provides the following assignment operators for <tt>pair</tt>
26439in 20.3.4 [pairs]/1:
26440</p>
26441
26442<ol>
26443<li>
26444<pre>template&lt;class U , class V&gt;
26445requires HasAssign&lt;T1, const U&amp;&gt; &amp;&amp; HasAssign&lt;T2, const V&amp;&gt;
26446pair&amp; operator=(const pair&lt;U , V&gt;&amp; p);
26447</pre>
26448</li>
26449<li>
26450<pre>requires MoveAssignable&lt;T1&gt; &amp;&amp; MoveAssignable&lt;T2&gt; pair&amp; operator=(pair&amp;&amp; p );
26451</pre>
26452</li>
26453<li>
26454<pre>template&lt;class U , class V&gt;
26455requires HasAssign&lt;T1, RvalueOf&lt;U&gt;::type&gt; &amp;&amp; HasAssign&lt;T2, RvalueOf&lt;V&gt;::type&gt;
26456pair&amp; operator=(pair&lt;U , V&gt;&amp;&amp; p);
26457</pre>
26458</li>
26459</ol>
26460
26461<p>
26462It seems that the functionality of (2) is completely covered by (3), therefore
26463(2) should be removed.
26464</p>
26465
26466<p><i>[
26467Batavia (2009-05):
26468]</i></p>
26469
26470<blockquote>
26471<p>
26472Bill believes the extra assignment operators are necessary for resolving
26473ambiguities, but that does not mean it needs to be part of the specification.
26474</p>
26475<p>
26476Move to Open.
26477We recommend this be looked at in the context of the ongoing work
26478related to the pair templates.
26479</p>
26480</blockquote>
26481
26482<p><i>[
264832009-07 Frankfurt:
26484]</i></p>
26485
26486
26487<blockquote>
26488Leave this open pending the removal of concepts from the WD.
26489</blockquote>
26490
26491<p><i>[
264922009-10 Santa Cruz:
26493]</i></p>
26494
26495
26496<blockquote>
26497Mark as NAD, see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#801">801</a>.
26498</blockquote>
26499
26500
26501
26502<p><b>Proposed resolution:</b></p>
26503<ol type="A">
26504<li>
26505<p>
26506In 20.3.4 [pairs] p. 1, class <tt>pair</tt> and just before p. 13 remove the declaration:
26507</p>
26508
26509<blockquote><pre>requires MoveAssignable&lt;T1&gt; &amp;&amp; MoveAssignable&lt;T2&gt; pair&amp; operator=(pair&amp;&amp; p );
26510</pre></blockquote>
26511</li>
26512
26513<li>
26514Remove p.13+p.14
26515</li>
26516
26517</ol>
26518
26519
26520
26521
26522
26523<hr>
26524<h3><a name="917"></a>917. Redundant move-assignment operator of <tt>tuple</tt> should be removed</h3>
26525<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#NAD">NAD</a>
26526 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-10-04  <b>Last modified:</b> 2009-10-23</p>
26527<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>
26528<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
26529<p><b>Discussion:</b></p>
26530<p><b>see also <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#916">916</a>.</b></p>
26531<p>
26532N2770 (and thus now the WP) removed the
26533non-template move-assignment operator from tuple's class definition,
26534but the latter individual member description does still provide this
26535operator. Is this (a) an oversight and can it (b) be solved as part of an
26536editorial process?
26537</p>
26538
26539<p><i>[
26540Post Summit Daniel provided wording.
26541]</i></p>
26542
26543
26544<p><i>[
26545Batavia (2009-05):
26546]</i></p>
26547
26548<blockquote>
26549<p>
26550We believe that the proposed resolution's part 1 is editorial.
26551</p>
26552<p>
26553Regarding part 2, we either remove the specification as proposed,
26554or else add back the declaration to which the specification refers.
26555Alisdair and Bill prefer the latter.
26556It is not immediately obvious whether the function is intended to be present.
26557</p>
26558<p>
26559We recommend that the Project Editor restore the missing declaration
26560and that we keep part 2 of the issue alive.
26561</p>
26562<p>
26563Move to Open.
26564</p>
26565</blockquote>
26566
26567<p><i>[
265682009-07 Frankfurt:
26569]</i></p>
26570
26571
26572<blockquote>
26573Leave this open pending the removal of concepts from the WD.
26574</blockquote>
26575
26576<p><i>[
265772009-10 Santa Cruz:
26578]</i></p>
26579
26580
26581<blockquote>
26582Mark as NAD, see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#801">801</a>.
26583</blockquote>
26584
26585
26586
26587<p><b>Proposed resolution:</b></p>
26588<ol>
26589<li>
26590<p>
26591In 20.5.2 [tuple.tuple], class <tt>tuple</tt> just before member <tt>swap</tt> please
26592change as indicated:
26593</p>
26594<p><i>[
26595This fixes an editorial loss between N2798 to N2800
26596]</i></p>
26597
26598<blockquote><pre>template &lt;class... UTypes&gt;
26599requires HasAssign&lt;Types, const UTypes&amp;&gt;...
26600<ins>tuple&amp; operator=(const pair&lt;UTypes...&gt;&amp;);</ins>
26601
26602template &lt;class... UTypes&gt;
26603requires HasAssign&lt;Types, RvalueOf&lt;UTypes&gt;::type&gt;...
26604<ins>tuple&amp; operator=(pair&lt;UTypes...&gt;&amp;&amp;);</ins>
26605</pre></blockquote>
26606</li>
26607<li>
26608<p>
26609In 20.5.2.1 [tuple.cnstr], starting just before p. 11 please remove
26610as indicated:
26611</p>
26612
26613<blockquote><pre><del>requires MoveAssignable&lt;Types&gt;... tuple&amp; operator=(tuple&amp;&amp; u);</del>
26614</pre>
26615<blockquote>
26616<p>
26617<del>-11- <i>Effects:</i> Move-assigns each element of <tt>u</tt> to the corresponding
26618element of <tt>*this</tt>.</del>
26619</p>
26620<p>
26621<del>-12- <i>Returns:</i> <tt>*this</tt>.</del>
26622</p>
26623</blockquote>
26624</blockquote>
26625</li>
26626</ol>
26627
26628
26629
26630
26631
26632<hr>
26633<h3><a name="918"></a>918. Swap for tuple needs to be conceptualized</h3>
26634<p><b>Section:</b> 20.5.2.3 [tuple.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
26635 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-10-04  <b>Last modified:</b> 2009-07-13</p>
26636<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
26637<p><b>Discussion:</b></p>
26638<p>
26639Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a> was accepted after <tt>tuple</tt> had been conceptualized,
26640therefore this step needs to be completed.
26641</p>
26642
26643<p><i>[
26644Post Summit Daniel adds
26645]</i></p>
26646
26647
26648<blockquote>
26649This is now NAD Editorial (addressed by
26650<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>)
26651except for item 3 in the proposed wording.
26652</blockquote>
26653
26654<p><i>[
266552009-05-01 Daniel adds:
26656]</i></p>
26657
26658
26659<blockquote>
26660As of the recent WP
26661(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>),
26662this issue is now completely covered by editorial
26663changes (including the third bullet), therefore I unconditionally recommend
26664NAD.
26665</blockquote>
26666
26667<p><i>[
26668Batavia (2009-05):
26669]</i></p>
26670
26671<blockquote>
26672<p>
26673We observed that all the proposed changes have already been applied to the
26674Working Draft, rendering this issue moot.
26675</p>
26676<p>
26677Move to NAD.
26678</p>
26679</blockquote>
26680
26681
26682
26683<p><b>Proposed resolution:</b></p>
26684<ol>
26685<li>
26686<p>
26687In both 20.5.1 [tuple.general]/2 and 20.5.2.9 [tuple.special] change
26688</p>
26689
26690<blockquote><pre>template &lt;<del>class</del> <ins>Swappable</ins>... Types&gt;
26691void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp; y);
26692</pre></blockquote>
26693
26694</li>
26695
26696<li>
26697<p>
26698In 20.5.2 [tuple.tuple], class <tt>tuple</tt> definition and in
2669920.5.2.3 [tuple.swap], change
26700</p>
26701
26702<blockquote><pre><ins>requires Swappable&lt;Types&gt;...</ins>void swap(tuple&amp;);
26703</pre></blockquote>
26704
26705</li>
26706
26707<li>
26708<p>
26709In 20.5.2.3 [tuple.swap] remove the current requires-clause, which says:
26710</p>
26711
26712<blockquote>
26713<del><i>Requires:</i> Each type in <tt>Types</tt> shall be <tt>Swappable</tt></del>
26714</blockquote>
26715</li>
26716
26717</ol>
26718
26719
26720
26721
26722
26723
26724<hr>
26725<h3><a name="919"></a>919. (forward_)list specialized remove algorithms are over constrained</h3>
26726<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#NAD">NAD</a>
26727 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2008-10-06  <b>Last modified:</b> 2009-10-23</p>
26728<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>
26729<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
26730<p><b>Discussion:</b></p>
26731<p>
26732The signatures of <tt>forwardlist::remove</tt> and <tt>list::remove</tt>
26733defined in 23.3.3.5 [forwardlist.ops] before 11 + 23.3.4.4 [list.ops] before 15:
26734</p>
26735
26736<blockquote><pre>requires EqualityComparable&lt;T&gt; void remove(const T&amp; value);
26737</pre></blockquote>
26738
26739<p>
26740are asymmetric to their predicate variants (which only require
26741<tt>Predicate</tt>, <em>not</em> <tt>EquivalenceRelation</tt>) and with the free algorithm
26742remove (which only require <tt>HasEqualTo</tt>). Also, nothing in the
26743pre-concept WP
26744<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
26745implies that <tt>EqualityComparable</tt> should
26746be the intended requirement.
26747</p>
26748
26749<p><i>[
26750Batavia (2009-05):
26751]</i></p>
26752
26753<blockquote>
26754<p>
26755We agree with the proposed resolution,
26756but would like additional input from concepts experts.
26757</p>
26758<p>
26759Move to Review.
26760</p>
26761</blockquote>
26762
26763<p><i>[
267642009-07-21 Alisdair adds:
26765]</i></p>
26766
26767
26768<blockquote>
26769Current rationale and wording for this issue is built around concepts. I
26770suggest the issue reverts to Open status. I believe there is enough of
26771an issue to review after concepts are removed from the WP to re-examine
26772the issue in Santa Cruz, rather than resolve as NAD Concepts.
26773</blockquote>
26774
26775<p><i>[
267762009-10-10 Daniel adds:
26777]</i></p>
26778
26779
26780<blockquote>
26781Recommend NAD: The concept-free wording as of
26782<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2960.pdf">N2960</a>
26783has no longer the
26784over-specified requirement
26785<tt>EqualityComparable</tt> for the remove function that uses <tt>==</tt>. In fact, now
26786the same test conditions exists
26787as for the free algorithm <tt>remove</tt> (25.3.8 [alg.remove]). The error was
26788introduced in the process of conceptifying.
26789</blockquote>
26790
26791<p><i>[
267922009-10 Santa Cruz:
26793]</i></p>
26794
26795
26796<blockquote>
26797NAD, solved by the removal of concepts.
26798</blockquote>
26799
26800
26801
26802<p><b>Proposed resolution:</b></p>
26803<ol type="A">
26804<li>
26805<p>
26806Replace in 23.3.3.5 [forwardlist.ops] before 11 and in 23.3.4.4 [list.ops] before 15
26807</p>
26808
26809<blockquote><pre>requires <del>EqualityComparable&lt;T&gt;</del> <ins>HasEqualTo&lt;T, T&gt;</ins> void remove(const T&amp; value);
26810</pre></blockquote>
26811</li>
26812</ol>
26813
26814
26815
26816
26817
26818
26819<hr>
26820<h3><a name="923"></a>923. atomics with floating-point </h3>
26821<p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
26822 <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2008-10-17  <b>Last modified:</b> 2009-10-26</p>
26823<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>
26824<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
26825<p><b>Discussion:</b></p>
26826<p>
26827Right now, C++0x doesn't have <tt>atomic&lt;float&gt;</tt>. We're thinking of adding
26828the words to support it for TR2 (note: that would be slightly
26829post-C++0x). If we need it, we could probably add the words.
26830</p>
26831<p>
26832<b>Proposed resolutions:</b> Using <tt>atomic&lt;FP&gt;::compare_exchange</tt> (weak or
26833strong) should be either:
26834</p>
26835
26836<ol>
26837<li>
26838ill-formed, or
26839</li>
26840<li>
26841well-defined.
26842</li>
26843</ol>
26844
26845<p>
26846I propose Option 1 for C++0x for expediency. If someone wants to argue
26847for Option 2, they need to say what exactly they want <tt>compare_exchange</tt>
26848to mean in this case (IIRC, C++0x doesn't even assume IEEE 754).
26849</p>
26850
26851<p><i>[
26852Summit:
26853]</i></p>
26854
26855
26856<blockquote>
26857Move to open. Blocked until concepts for atomics are addressed.
26858</blockquote>
26859
26860<p><i>[
26861Post Summit Anthony adds:
26862]</i></p>
26863
26864
26865<blockquote>
26866<p>
26867Recommend NAD. C++0x does have <tt>std::atomic&lt;float&gt;</tt>, and both
26868<tt>compare_exchange_weak</tt> and <tt>compare_exchange_strong</tt> are well-defined in
26869this case. Maybe change the note in 29.6 [atomics.types.operations] paragraph 20 to:
26870</p>
26871
26872<blockquote>
26873<p>
26874[<i>Note:</i> The effect of the compare-and-exchange operations is
26875</p>
26876<blockquote><pre>if (!memcmp(object,expected,sizeof(*object)))
26877    *object = desired;
26878else
26879    *expected = *object;
26880</pre></blockquote>
26881
26882<p>
26883This may result in failed comparisons for values that compare equal if
26884the underlying type has padding bits or alternate representations of
26885the same value. <i>-- end note</i>]
26886</p>
26887</blockquote>
26888
26889</blockquote>
26890
26891<p><i>[
268922009-10 Santa Cruz:
26893]</i></p>
26894
26895
26896<blockquote>
26897NAD Editorial.  Solved by
26898<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
26899</blockquote>
26900
26901
26902
26903<p><b>Proposed resolution:</b></p>
26904<p>
26905Change the note in 29.6 [atomics.types.operations] paragraph 20 to:
26906</p>
26907
26908<blockquote>
26909<p>
26910[<i>Note:</i> The effect of the compare-and-exchange operations is
26911</p>
26912<blockquote><pre>if (<del>*object == *expected</del> <ins>!memcmp(object,expected,sizeof(*object))</ins>)
26913    *object = desired;
26914else
26915    *expected = *object;
26916</pre></blockquote>
26917
26918<p><ins>
26919This may result in failed comparisons for values that compare equal if
26920the underlying type has padding bits or alternate representations of
26921the same value.</ins> <i>-- end note</i>]
26922</p>
26923</blockquote>
26924
26925
26926
26927
26928
26929
26930<hr>
26931<h3><a name="924"></a>924. structs with internal padding</h3>
26932<p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
26933 <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2008-10-17  <b>Last modified:</b> 2009-10-26</p>
26934<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>
26935<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
26936<p><b>Discussion:</b></p>
26937<p>
26938Right now, the <tt>compare_exchange_weak</tt> loop should rapidly converge on the
26939padding contents. But <tt>compare_exchange_strong</tt> will require a bit more
26940compiler work to ignore padding for comparison purposes.
26941</p>
26942<p>
26943Note that this isn't a problem for structs with no padding, and we do
26944already have one portable way to ensure that there is no padding that
26945covers the key use cases: Have elements be the same type. I suspect that
26946the greatest need is for a structure of two pointers, which has no
26947padding problem. I suspect the second need is a structure of a pointer
26948and some form of an integer. If that integer is <tt>intptr_t</tt>, there will be
26949no padding.
26950</p>
26951<p>
26952Related but separable issue: For unused bitfields, or other unused
26953fields for that matter, we should probably say it's the programmer's
26954responsibility to set them to zero or otherwise ensure they'll be
26955ignored by <tt>memcmp</tt>.
26956</p>
26957
26958<p>
26959<b>Proposed resolutions:</b> Using
26960<tt>atomic&lt;struct-with-padding&gt;::compare_exchange_strong</tt> should be either:
26961</p>
26962
26963<ol>
26964<li>
26965ill-formed, or
26966</li>
26967<li>
26968well-defined.
26969</li>
26970</ol>
26971
26972<p>
26973I propose Option 1 for C++0x for expediency, though I'm not sure how to
26974say it. I would be happy with Option 2, which I believe would mean that
26975<tt>compare_exchange_strong</tt> would be implemented to avoid comparing padding
26976bytes, or something equivalent such as always zeroing out padding when
26977loading/storing/comparing. (Either implementation might require compiler
26978support.)
26979</p>
26980
26981<p><i>[
26982Summit:
26983]</i></p>
26984
26985
26986<blockquote>
26987Move to open. Blocked until concepts for atomics are addressed.
26988</blockquote>
26989
26990<p><i>[
26991Post Summit Anthony adds:
26992]</i></p>
26993
26994
26995<blockquote>
26996The resoultion of LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#923">923</a> should resolve this issue as well.
26997</blockquote>
26998
26999<p><i>[
270002009-10 Santa Cruz:
27001]</i></p>
27002
27003
27004<blockquote>
27005NAD Editorial.  Solved by
27006<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
27007</blockquote>
27008
27009
27010
27011<p><b>Proposed resolution:</b></p>
27012<p>
27013</p>
27014
27015
27016
27017
27018
27019<hr>
27020<h3><a name="926"></a>926. Sequentially consistent fences, relaxed operations and modification order</h3>
27021<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#NAD%20Editorial">NAD Editorial</a>
27022 <b>Submitter:</b> Anthony Williams <b>Opened:</b> 2008-10-19  <b>Last modified:</b> 2009-10-26</p>
27023<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>
27024<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
27025<p><b>Discussion:</b></p>
27026<p><b>Addresses UK 313</b></p>
27027
27028<p>
27029There was an interesting issue raised over on comp.programming.threads
27030today regarding the following example
27031</p>
27032
27033<blockquote><pre>// Thread 1:
27034x.store(1, memory_order_relaxed);           // SX
27035atomic_thread_fence(memory_order_seq_cst);  // F1
27036y.store(1, memory_order_relaxed);           // SY1
27037atomic_thread_fence(memory_order_seq_cst);  // F2
27038r1 = y.load(memory_order_relaxed);          // RY
27039
27040// Thread 2:
27041y.store(0, memory_order_relaxed);          // SY2
27042atomic_thread_fence(memory_order_seq_cst); // F3
27043r2 = x.load(memory_order_relaxed);         // RX
27044</pre></blockquote>
27045
27046<p>
27047is the outcome <tt>r1 == 0</tt> and <tt>r2 == 0</tt> possible?
27048</p>
27049<p>
27050I think the intent is that this is not possible, but I am not sure the
27051wording guarantees that. Here is my analysis:
27052</p>
27053<p>
27054Since all the fences are SC, there must be a total order between them.
27055<tt>F1</tt> must be before <tt>F2</tt> in that order since they are in
27056the same thread. Therefore <tt>F3</tt> is either before <tt>F1</tt>,
27057between <tt>F1</tt> and <tt>F2</tt> or after <tt>F2</tt>.
27058</p>
27059<p>
27060If <tt>F3</tt> is <em>after</em> <tt>F2</tt>, then we can apply 29.3 [atomics.order]p5 from
27061<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>:
27062</p>
27063
27064<blockquote>
27065For atomic operations <tt>A</tt> and <tt>B</tt> on an atomic object
27066<tt>M</tt>, where <tt>A</tt> modifies <tt>M</tt> and <tt>B</tt> takes
27067its value, if there are <tt>memory_order_seq_cst</tt> fences <tt>X</tt>
27068and <tt>Y</tt> such that <tt>A</tt> is sequenced before <tt>X</tt>,
27069<tt>Y</tt> is sequenced before <tt>B</tt>, and <tt>X</tt> precedes
27070<tt>Y</tt> in <tt>S</tt>, then <tt>B</tt> observes either the effects of
27071<tt>A</tt> or a later modification of <tt>M</tt> in its modification
27072order.
27073</blockquote>
27074
27075<p>
27076In this case, <tt>A</tt> is <tt>SX</tt>, <tt>B</tt> is <tt>RX</tt>, the
27077fence <tt>X</tt> is <tt>F2</tt> and the fence <tt>Y</tt> is <tt>F3</tt>,
27078so <tt>RX</tt> must see 1.
27079</p>
27080<p>
27081If <tt>F3</tt> is <em>before</em> <tt>F2</tt>, this doesn't apply, but
27082<tt>F3</tt> can therefore be before or after <tt>F1</tt>.
27083</p>
27084<p>
27085If <tt>F3</tt> is <em>after</em> <tt>F1</tt>, the same logic applies, but this
27086time the fence <tt>X</tt> is <tt>F1</tt>. Therefore again, <tt>RX</tt>
27087must see 1.
27088</p>
27089<p>
27090Finally we have the case that <tt>F3</tt> is <em>before</em> <tt>F1</tt>
27091in the SC ordering. There are now no guarantees about <tt>RX</tt>, and
27092<tt>RX</tt> can see <tt>r2==0</tt>.
27093</p>
27094<p>
27095We can apply 29.3 [atomics.order]p5 again. This time,
27096<tt>A</tt> is <tt>SY2</tt>, <tt>B</tt> is <tt>RY</tt>, <tt>X</tt> is
27097<tt>F3</tt> and <tt>Y</tt> is <tt>F1</tt>. Thus <tt>RY</tt> must observe
27098the effects of <tt>SY2</tt> or a later modification of <tt>y</tt> in its
27099modification order.
27100</p>
27101<p>
27102Since <tt>SY1</tt> is sequenced before <tt>RY</tt>, <tt>RY</tt> must
27103observe the effects of <tt>SY1</tt> or a later modification of
27104<tt>y</tt> in its modification order.
27105</p>
27106<p>
27107In order to ensure that <tt>RY</tt> sees <tt>(r1==1)</tt>, we must see
27108that <tt>SY1</tt> is later in the modification order of <tt>y</tt> than
27109<tt>SY2</tt>.
27110</p>
27111<p>
27112We're now skating on thin ice. Conceptually, <tt>SY2</tt> happens-before
27113<tt>F3</tt>, <tt>F3</tt> is SC-ordered before <tt>F1</tt>, <tt>F1</tt>
27114happens-before <tt>SY1</tt>, so <tt>SY1</tt> is later in the
27115modification order <tt>M</tt> of <tt>y</tt>, and <tt>RY</tt> must see
27116the result of <tt>SY1</tt> (<tt>r1==1</tt>). However, I don't think the
27117words are clear on that.
27118</p>
27119
27120<p><i>[
27121Post Summit Hans adds:
27122]</i></p>
27123
27124
27125<blockquote>
27126<p>
27127In my (Hans') view, our definition of fences will always be weaker than
27128what particular hardware will guarantee.  <tt>Memory_order_seq_cst</tt> fences
27129inherently don't guarantee sequential consistency anyway, for good
27130reasons (e.g. because they can't enforce a total order on stores).
27131 Hence I don't think the issue demonstrates a gross failure to achieve
27132what we intended to achieve.  The example in question is a bit esoteric.
27133 Hence, in my view, living with the status quo certainly wouldn't be a
27134disaster either.
27135</p>
27136<p>
27137In any case, we should probably add text along the lines of the
27138following between p5 and p6 in 29.3 [atomics.order]:
27139</p>
27140<blockquote>
27141[Note: <tt>Memory_order_seq_cst</tt> only ensures sequential consistency for a
27142data-race-free program that uses exclusively <tt>memory_order_seq_cst</tt>
27143operations.  Any use of weaker ordering will invalidate this guarantee
27144unless extreme care is used.  In particular, <tt>memory_order_seq_cst</tt> fences
27145only ensure a total order for the fences themselves.  They cannot, in
27146general, be used to restore sequential consistency for atomic operations
27147with weaker ordering specifications.]
27148</blockquote>
27149
27150<p>
27151Also see thread beginning at c++std-lib-23271.
27152</p>
27153
27154</blockquote>
27155
27156<p><i>[
27157Herve's correction:
27158]</i></p>
27159
27160<blockquote>
27161<p>
27162Minor point, and sorry for the knee jerk reaction: I admit to having
27163no knowledge of Memory_order_seq_cst, but my former boss (John Lakos)
27164has ingrained an automatic introspection on the use of "only".   I
27165think you meant:
27166</p>
27167
27168<blockquote>
27169[Note: <tt>Memory_order_seq_cst</tt> ensures sequential consistency only
27170for . . . .  In particular, <tt>memory_order_seq_cst</tt> fences ensure a
27171total order only for . . .
27172</blockquote>
27173<p>
27174Unless, of course, <tt>Memory_order_seq_cst</tt> really do nothing but ensure
27175sequential consistency for a data-race-free program that uses
27176exclusively <tt>memory_order_seq_cst</tt> operations.
27177</p>
27178</blockquote>
27179
27180<p><i>[
271812009-10 Santa Cruz:
27182]</i></p>
27183
27184
27185<blockquote>
27186NAD Editorial.  Solved by
27187<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
27188</blockquote>
27189
27190
27191
27192<p><b>Proposed resolution:</b></p>
27193<p>
27194Add a new paragraph after 29.3 [atomics.order]p5 that says
27195</p>
27196
27197<blockquote>
27198For atomic operations <tt>A</tt> and <tt>B</tt> on an atomic object
27199<tt>M</tt>, where <tt>A</tt> and <tt>B</tt> modify <tt>M</tt>, if there
27200are <tt>memory_order_seq_cst</tt> fences <tt>X</tt> and <tt>Y</tt> such
27201that <tt>A</tt> is sequenced before <tt>X</tt>, <tt>Y</tt> is sequenced
27202before <tt>B</tt>, and <tt>X</tt> precedes <tt>Y</tt> in <tt>S</tt>,
27203then <tt>B</tt> occurs later than <tt>A</tt> in the modifiction order of
27204<tt>M</tt>.
27205</blockquote>
27206
27207
27208
27209
27210
27211<hr>
27212<h3><a name="927"></a>927. <tt>Dereferenceable</tt>  should be <tt>HasDereference</tt></h3>
27213<p><b>Section:</b> X [allocator.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
27214 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2008-10-23  <b>Last modified:</b> 2009-07-13</p>
27215<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
27216<p><b>Discussion:</b></p>
27217<p>
27218X [allocator.concepts] contains a reference to a concept named
27219<tt>Dereferenceable</tt>. No such concept exists.
27220</p>
27221
27222<p><i>[
27223Daniel adds 2009-02-14:
27224]</i></p>
27225
27226
27227<blockquote>
27228The proposal given in the paper
27229<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2829.pdf">N2829</a>
27230would automatically resolve this issue.
27231</blockquote>
27232
27233
27234<p><i>[
27235Batavia (2009-05):
27236]</i></p>
27237
27238<blockquote>
27239<p>
27240This particular set of changes has already been made.
27241There are two related changes later on (and possibly also an earlier Example);
27242these can be handled editorially.
27243</p>
27244<p>
27245Move to NAD Editorial.
27246</p>
27247</blockquote>
27248
27249
27250<p><b>Proposed resolution:</b></p>
27251<p>
27252Change all uses of the concept <tt>Dereferenceable</tt> to
27253<tt>HasDereference</tt> in X [allocator.concepts].
27254</p>
27255
27256
27257
27258
27259
27260<hr>
27261<h3><a name="928"></a>928. Wrong concepts used for <tt>tuple</tt>'s comparison operators</h3>
27262<p><b>Section:</b> 20.5.2.7 [tuple.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
27263 <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2008-10-28  <b>Last modified:</b> 2009-07-13</p>
27264<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>
27265<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
27266<p><b>Discussion:</b></p>
27267<p>
27268In the latest working draft for C++0x, <tt>tuple</tt>'s <tt>operator==</tt> and <tt>operator&lt;</tt>
27269are declared as 
27270</p>
27271
27272<blockquote><pre>template&lt;class... TTypes, class... UTypes&gt; 
27273  requires EqualityComparable&lt;TTypes, UTypes&gt;... 
27274  bool operator==(const tuple&lt;TTypes...&gt;&amp; t, const tuple&lt;UTypes...&gt;&amp; u);
27275</pre></blockquote>
27276
27277<p>
27278and
27279</p>
27280
27281<blockquote><pre>template&lt;class... TTypes, class... UTypes&gt; 
27282  requires LessThanComparable&lt;TTypes, UTypes&gt;... 
27283  bool operator&lt;(const tuple&lt;TTypes...&gt;&amp; t, const tuple&lt;UTypes...&gt;&amp; u);
27284</pre></blockquote>
27285
27286<p>
27287But the concepts <tt>EqualityComparable</tt> and <tt>LessThanComparable</tt> only take one 
27288parameter, not two.  Also, even if <tt>LessThanComparable</tt> could take two 
27289parameters, the definition of <tt>tuple::operator&lt;()</tt> should also require 
27290</p>
27291
27292<blockquote><pre>LessThanComparable&lt;UTypes, TTypes&gt;... // (note the order) 
27293</pre></blockquote>
27294
27295<p>
27296since the algorithm for <tt>tuple::operator&lt;</tt> is the following (pseudo-code)
27297</p>
27298
27299<blockquote><pre>for (size_t N = 0; N &lt; sizeof...(TTypes); ++N) { 
27300    if (get&lt;N&gt;(t) &lt; get&lt;N&gt;(u) return true; 
27301    else if ((get&lt;N&gt;(u) &lt; get&lt;N&gt;(t)) return false; 
27302} 
27303
27304return false; 
27305</pre></blockquote>
27306
27307<p>
27308Similar problems hold for <tt>tuples</tt>'s other comparison operators.
27309</p>
27310
27311<p><i>[
27312Post Summit:
27313]</i></p>
27314
27315
27316<blockquote>
27317Recommend Tentatively Ready.
27318</blockquote>
27319
27320
27321
27322<p><b>Proposed resolution:</b></p>
27323<p>
27324In 20.5.1 [tuple.general] and 20.5.2.7 [tuple.rel] change:
27325</p>
27326
27327<blockquote><pre>template&lt;class... TTypes, class... UTypes&gt;
27328  requires <del>EqualityComparable</del><ins>HasEqualTo</ins>&lt;TTypes, UTypes&gt;...
27329  bool operator==(const tuple&lt;TTypes...&gt;&amp;, const tuple&lt;UTypes...&gt;&amp;);
27330
27331template&lt;class... TTypes, class... UTypes&gt;
27332  requires <del>LessThanComparable</del><ins>HasLess</ins>&lt;TTypes, UTypes&gt;... <ins>&amp;&amp; HasLess&lt;UTypes, TTypes&gt;...</ins>
27333  bool operator&lt;(const tuple&lt;TTypes...&gt;&amp;, const tuple&lt;UTypes...&gt;&amp;);
27334
27335template&lt;class... TTypes, class... UTypes&gt;
27336  requires <del>EqualityComparable</del><ins>HasEqualTo</ins>&lt;TTypes, UTypes&gt;...
27337  bool operator!=(const tuple&lt;TTypes...&gt;&amp;, const tuple&lt;UTypes...&gt;&amp;);
27338
27339template&lt;class... TTypes, class... UTypes&gt;
27340  requires <del>LessThanComparable</del><ins>HasLess</ins>&lt;<del>U</del><ins>T</ins>Types, <del>T</del><ins>U</ins>Types&gt;... <ins>&amp;&amp; HasLess&lt;UTypes, TTypes&gt;...</ins>
27341  bool operator&gt;(const tuple&lt;TTypes...&gt;&amp;, const tuple&lt;UTypes...&gt;&amp;);
27342
27343template&lt;class... TTypes, class... UTypes&gt;
27344  requires <del>LessThanComparable</del><ins>HasLess</ins>&lt;<del>U</del><ins>T</ins>Types, <del>T</del><ins>U</ins>Types&gt;... <ins>&amp;&amp; HasLess&lt;UTypes, TTypes&gt;...</ins>
27345  bool operator&lt;=(const tuple&lt;TTypes...&gt;&amp;, const tuple&lt;UTypes...&gt;&amp;);
27346
27347template&lt;class... TTypes, class... UTypes&gt;
27348  requires <del>LessThanComparable</del><ins>HasLess</ins>&lt;TTypes, UTypes&gt;... <ins>&amp;&amp; HasLess&lt;UTypes, TTypes&gt;...</ins>
27349  bool operator&gt;=(const tuple&lt;TTypes...&gt;&amp;, const tuple&lt;UTypes...&gt;&amp;);
27350</pre></blockquote>
27351
27352
27353
27354
27355
27356<hr>
27357<h3><a name="930"></a>930. Access to std::array data as built-in array type</h3>
27358<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">NAD</a>
27359 <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2008-11-17  <b>Last modified:</b> 2009-10-20</p>
27360<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>
27361<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
27362<p><b>Discussion:</b></p>
27363
27364<p>
27365The Working Draft (N2798) allows access to the elements of
27366<tt>std::array</tt> by its <tt>data()</tt> member function:
27367</p>
27368
27369<blockquote>
27370
27371<h5>23.2.1.4 array::data [array.data]</h5>
27372<pre> T *data();
27373 const T *data() const;
27374</pre>
27375<ol><li>
27376 Returns: elems.
27377</li></ol>
27378</blockquote>
27379
27380<p>
27381Unfortunately, the result of <tt>std::array::data()</tt> cannot be bound
27382to a reference to a built-in array of the type of <tt>array::elems</tt>.
27383And <tt>std::array</tt> provides no other way to get a reference to
27384<tt>array::elems</tt>. 
27385This hampers the use of <tt>std::array</tt>, for example when trying to
27386pass its data to a C style API function:
27387</p>
27388
27389<pre> // Some C style API function. 
27390 void set_path( char (*)[MAX_PATH] );
27391
27392 std::array&lt;char,MAX_PATH&gt; path;
27393 set_path( path.data() );  // error
27394 set_path( &amp;(path.data()) );  // error
27395</pre>
27396
27397 <p>
27398Another example, trying to pass the array data to an instance of another
27399C++ class:
27400</p>
27401
27402<pre> // Represents a 3-D point in space.
27403 class three_d_point {
27404 public:
27405   explicit three_d_point(const double (&amp;)[3]); 
27406 };
27407
27408 const std::array&lt;double,3&gt; coordinates = { 0, 1, 2 };
27409 three_d_point point1( coordinates.data() );  // error.
27410 three_d_point point2( *(coordinates.data()) );  // error.
27411</pre>
27412
27413<p>
27414A user might be tempted to use <tt>std::array::elems</tt> instead, but
27415doing so isn't recommended, because <tt>std::array::elems</tt> is "for
27416exposition only".  Note that Boost.Array users might already use
27417<tt>boost::array::elems</tt>, as its documentation doesn't explicitly
27418state that <tt>boost::array::elems</tt> is for exposition only:
27419http://www.boost.org/doc/libs/1_36_0/doc/html/boost/array.html
27420</p>
27421<p>
27422I can think of three options to solve this issue:
27423</p>
27424<ol><li>
27425Remove the words "exposition only" from the definition of
27426<tt>std::array::elems</tt>, as well as the note saying that "elems is
27427shown for exposition only."
27428</li><li>
27429Change the signature of <tt>std::array::data()</tt>, so that it would
27430return a reference to the built-in array, instead of a pointer to its
27431first element.
27432</li><li>
27433Add extra member functions, returning a reference to the built-in array.
27434</li></ol>
27435<p>
27436Lawrence Crowl wrote me that it might be better to leave
27437<tt>std::array::elems</tt> "for exposition only", to allow alternate
27438representations to allocate the array data dynamically.  This might be
27439of interest to the embedded community, having to deal with very limited
27440stack sizes.
27441</p>
27442<p>
27443The second option, changing the return type of
27444<tt>std::array::data()</tt>, would break backward compatible to current
27445Boost and TR1 implementations, as well as to the other contiguous
27446container (<tt>vector</tt> and <tt>string</tt>) in a very subtle way.
27447For example, the following call to <tt>std::swap</tt> currently swap two
27448locally declared pointers <tt>(data1, data2)</tt>, for any container
27449type <tt>T</tt> that has a <tt>data()</tt> member function. When
27450<tt>std::array::data()</tt> is changed to return a reference, the
27451<tt>std::swap</tt> call may swap the container elements instead.
27452</p>
27453
27454<pre> template &lt;typename T&gt;
27455 void func(T&amp; container1, T&amp; container2)
27456 {
27457   // Are data1 and data2 pointers or references?
27458   auto data1 = container1.data();
27459   auto data2 = container2.data();
27460
27461   // Will this swap two local pointers, or all container elements?
27462   std::swap(data1, data2);
27463 }
27464</pre>
27465
27466<p>
27467The following concept is currently satisfied by all contiguous
27468containers, but it no longer is for <tt>std::array</tt>, when
27469<tt>array::data()</tt>
27470is changed to return a reference (tested on ConceptGCC Alpha 7):
27471</p>
27472
27473<pre> auto concept ContiguousContainerConcept&lt;typename T&gt;
27474 {
27475   typename value_type = typename T::value_type;
27476   const value_type * T::data() const;
27477 }
27478</pre>
27479
27480<p>
27481Still it's worth considering having <tt>std::array::data()</tt> return a
27482reference, because it might be the most intuitive option, from a user's
27483point of view.  Nicolai Josuttis (who wrote <tt>boost::array</tt>)
27484mailed me that he very much prefers this option.
27485</p>
27486<p>
27487Note that for this option, the definition of <tt>data()</tt> would also
27488need to be revised for zero-sized arrays, as its return type cannot be a
27489reference to a zero-sized built-in array.  Regarding zero-sized array,
27490<tt>data()</tt> could throw an exception.  Or there could be a partial
27491specialization of <tt>std::array</tt> where <tt>data()</tt> returns
27492<tt>T*</tt> or gets removed.
27493</p>
27494<p>
27495Personally I prefer the third option, adding a new member function to
27496<tt>std::array</tt>, overloaded for const and non-const access,
27497returning a reference to the built-in array, to avoid those compatible
27498issues. I'd propose naming the function <tt>std::array::c_array()</tt>,
27499which sounds intuitive to me. Note that <tt>boost::array</tt> already
27500has a <tt>c_array()</tt> member, returning a pointer, but Nicolai told
27501me that this one is only there for historical reasons. (Otherwise a name
27502like <tt>std::array::native_array()</tt> or
27503<tt>std::array::builtin_array()</tt> would also be fine with me.) 
27504According to my proposed resolution, a zero-sized <tt>std::array</tt> does not need
27505to have <tt>c_array()</tt>, while it is still required to have
27506<tt>data()</tt> functions.
27507</p>
27508
27509<p><i>[
27510Post Summit:
27511]</i></p>
27512
27513
27514<blockquote>
27515
27516<p>
27517Alisdair: Don't like p4 suggesting implementation-defined behaviour.
27518</p>
27519<p>
27520Walter: What about an explicit conversion operator, instead of adding
27521the new member function?
27522</p>
27523<p>
27524Alisdair: Noodling about:
27525</p>
27526<blockquote><pre>template&lt;size_t N, ValueType T&gt;
27527struct array
27528{
27529  T elems[N];
27530
27531// fantasy code starts here
27532
27533// crazy decltype version for grins only
27534//requires True&lt;(N&gt;0)&gt;
27535//explict operator decltype(elems) &amp; () { return elems; }
27536
27537// conversion to lvalue ref
27538requires True&lt;(N&gt;0)&gt;
27539explict operator T(&amp;)[N] () &amp; { return elems; }
27540
27541// conversion to const lvalue ref
27542requires True&lt;(N&gt;0)&gt;
27543explict operator const T(&amp;)[N] () const &amp; { return elems; }
27544
27545// conversion to rvalue ref using ref qualifiers
27546requires True&lt;(N&gt;0)&gt;
27547explict operator T(&amp;&amp;)[N] () &amp;&amp; { return elems; }
27548
27549// fantasy code ends here
27550
27551explicit operator bool() { return true; }
27552};
27553</pre></blockquote>
27554
27555<p>
27556This seems legal but odd. Jason Merrill says currently a CWG issue 613
27557on the non-static data member that fixes the error that current G++
27558gives for the non-explicit, non-conceptualized version of this. Verdict
27559from human compiler: seems legal.
27560</p>
27561<p>
27562Some grumbling about zero-sized arrays being allowed and supported.
27563</p>
27564<p>
27565Walter: Would this address the issue? Are we inclined to go this route?
27566</p>
27567<p>
27568Alan: What would usage look like?
27569</p>
27570<blockquote><pre>// 3-d point in space
27571struct three_d_point
27572{
27573  explicit three_d_point(const double (&amp;)[3]);
27574};
27575
27576void sink(double*);
27577
27578const std::array&lt;double, 3&gt; coordinates = { 0, 1, 2 };
27579three_d_point point1( coordinates.data() ); //error
27580three_d_point point2( *(coordinates.data()) ); // error
27581three_d_point point3( coordinates ); // yay!
27582
27583sink(cooridinates); // error, no conversion
27584</pre></blockquote>
27585
27586<p>
27587Recommended Open with new wording. Take the required clause and add the
27588explicit conversion operators, not have a <tt>typedef</tt>. At issue still is use
27589<tt>decltype</tt> or use <tt>T[N]</tt>. In favour of using <tt>T[N]</tt>, even though use of
27590<tt>decltype</tt> is specially clever.
27591</p>
27592
27593</blockquote>
27594
27595<p><i>[
27596Post Summit, further discussion in the thread starting with c++std-lib-23215.
27597]</i></p>
27598
27599
27600<p><i>[
276012009-07 post-Frankfurt (Saturday afternoon group):
27602]</i></p>
27603
27604
27605<blockquote>
27606<p>
27607The idea to resolve the issue by adding explicit conversion operators
27608was abandoned, because it would be inconvenient to use, especially when
27609passing the array to a template function, as mentioned by Daniel. So we
27610reconsidered the original proposed resolution, which appeared
27611acceptable, except for its proposed changes to 23.3.1.6 [array.zero], which
27612allowed <tt>c_array_type</tt> and <tt>c_array()</tt> to be absent for a zero-sized array.
27613Alisdair argued that such wording would disallow certain generic use
27614cases. New wording for 23.3.1.6 [array.zero] was agreed upon (Howard: and
27615is reflected in the proposed resolution).
27616</p>
27617<p>
27618Move to Review
27619</p>
27620</blockquote>
27621
27622<p><i>[
276232009-07-31 Alisdair adds:
27624]</i></p>
27625
27626
27627<blockquote>
27628<p>
27629I will be unhappy voting the proposed resolution for 930 past review
27630until we have implementation experience with reference qualifiers. 
27631Specifically, I want to understand the impact of the missing overload
27632for <tt>const &amp;&amp;</tt> (if any.)
27633</p>
27634
27635<p>
27636If we think the issue is important enough it might be worthwhile
27637stripping the ref qualifiers for easy progress next meeting, and opening
27638yet another issue to put them back with experience.
27639</p>
27640
27641<p>
27642Recommend deferring any decision on splitting the issue until we get LWG
27643feedback next meeting - I may be the lone dissenting voice if others are
27644prepared to proceed without it.
27645</p>
27646</blockquote>
27647
27648<p><i>[
276492009-10 Santa Cruz:
27650]</i></p>
27651
27652
27653<blockquote>
27654Mark as NAD. There was not enough consensus that this was sufficiently
27655useful. There are known other ways to do this, such as small inline
27656conversion functions.
27657</blockquote>
27658
27659
27660
27661<p><b>Proposed resolution:</b></p>
27662<p>
27663Add to the template definition of array, 23.3.1 [array]/3:
27664</p>
27665
27666<blockquote>
27667<pre><ins>
27668typedef T c_array_type[N];
27669c_array_type &amp; c_array() &amp;;
27670c_array_type &amp;&amp; c_array() &amp;&amp;;
27671const c_array_type &amp; c_array() const &amp;;
27672</ins>
27673</pre>
27674</blockquote>
27675
27676<p>
27677Add the following subsection to 23.3.1 [array], after 23.3.1.4 [array.data]:
27678</p>
27679
27680<blockquote>
27681<h5><ins>23.2.1.5 array::c_array [array.c_array]</ins></h5>
27682    <pre><ins>
27683c_array_type &amp; c_array() &amp;;
27684c_array_type &amp;&amp; c_array() &amp;&amp;;
27685const c_array_type &amp; c_array() const &amp;;
27686</ins></pre>
27687<blockquote>
27688<p>
27689<ins><i>Returns:</i> <tt>elems</tt>.</ins>
27690</p>
27691</blockquote>
27692
27693</blockquote>
27694
27695
27696
27697<p>
27698Change Zero sized arrays 23.3.1.6 [array.zero]:
27699</p>
27700
27701<blockquote>
27702
27703<p>-2- ...</p>
27704
27705<p><ins>
27706The type <tt>c_array_type</tt> is unspecified for a zero-sized array.
27707</ins></p>
27708
27709<p>
27710-3- The effect of calling <ins><tt>c_array()</tt>,</ins> <tt>front()</tt><ins>,</ins> or
27711<tt>back()</tt> for a zero-sized array is implementation defined.
27712</p>
27713</blockquote>
27714
27715
27716
27717
27718
27719
27720<hr>
27721<h3><a name="933"></a>933. Unique_ptr defect</h3>
27722<p><b>Section:</b> 20.8.14.2.5 [unique.ptr.single.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
27723 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2008-11-27  <b>Last modified:</b> 2009-10-23</p>
27724<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>
27725<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
27726<p><b>Discussion:</b></p>
27727<p>
27728If we are supporting stateful deleters, we need an overload for
27729<tt>reset</tt> that
27730takes a deleter as well.
27731</p>
27732
27733<blockquote><pre>void reset( pointer p, deleter_type d);
27734</pre></blockquote>
27735
27736<p>
27737We probably need two overloads to support move-only deleters, and
27738this
27739sounds uncomfortably like the two constructors I have been ignoring
27740for
27741now...
27742</p>
27743
27744<p><i>[
27745Batavia (2009-05):
27746]</i></p>
27747
27748<blockquote>
27749<p>
27750Howard comments that we have the functionality via move-assigment.
27751</p>
27752<p>
27753Move to Open.
27754</p>
27755</blockquote>
27756
27757<p><i>[
277582009-10 Santa Cruz:
27759]</i></p>
27760
27761
27762<blockquote>
27763Mark as NAD Future.
27764</blockquote>
27765
27766
27767
27768<p><b>Proposed resolution:</b></p>
27769<p>
27770</p>
27771
27772
27773
27774
27775
27776<hr>
27777<h3><a name="935"></a>935. clock error handling needs to be specified</h3>
27778<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#NAD%20Future">NAD Future</a>
27779 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2008-11-24  <b>Last modified:</b> 2009-10-23</p>
27780<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
27781<p><b>Discussion:</b></p>
27782<p>
27783Each of the three clocks specified in Clocks 20.9.5 [time.clock]
27784provides the member function:
27785</p>
27786
27787<blockquote><pre>static time_point now();
27788</pre></blockquote>
27789
27790<p>
27791The semantics specified by Clock requirements 20.9.1 [time.clock.req]
27792make no mention of error handling. Thus the function may throw <tt>bad_alloc</tt>
27793or an implementation-defined exception (17.6.4.11 [res.on.exception.handling]
27794paragraph 4).
27795</p>
27796
27797<p>
27798Some implementations of these functions on POSIX, Windows, and
27799presumably on other operating systems, may fail in ways only detectable
27800at runtime. Some failures on Windows are due to supporting chipset
27801errata and can even occur after successful calls to a clock's <tt>now()</tt>
27802function.
27803</p>
27804
27805<p>
27806These functions are used in cases where exceptions are not appropriate
27807or where the specifics of the exception or cause of error need to be
27808available to the user. See
27809<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2828.html">N2828</a>,
27810<i>Library Support for hybrid error
27811handling (Rev 1)</i>, for more specific discussion of use cases. Thus some change in
27812the interface of now is required.
27813</p>
27814
27815<p>
27816The proposed resolution has been implemented in the Boost version of the
27817chrono library. No problems were encountered.
27818</p>
27819
27820<p><i>[
27821Batavia (2009-05):
27822]</i></p>
27823
27824<blockquote>
27825<p>
27826We recommend this issue be deferred until the next Committee Draft
27827has been issued and the prerequisite paper has been accepted.
27828</p>
27829<p>
27830Move to Open.
27831</p>
27832</blockquote>
27833
27834<p><i>[
278352009-10 Santa Cruz:
27836]</i></p>
27837
27838
27839<blockquote>
27840Mark as NAD future. Too late to make this change without having already
27841accepted the hybrid error handling proposal.
27842</blockquote>
27843
27844
27845
27846<p><b>Proposed resolution:</b></p>
27847<p>
27848Accept the proposed wording of
27849<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2828.html">N2828</a>,
27850<i>Library Support for hybrid error handling (Rev 1)</i>.
27851</p>
27852
27853<p>
27854Change Clock requirements 20.9.1 [time.clock.req] as indicated:
27855</p>
27856
27857<blockquote>
27858<p>
27859-2- In Table 55 <tt>C1</tt> and <tt>C2</tt> denote clock types. <tt>t1</tt> and
27860<tt>t2</tt> are values returned by <tt>C1::now()</tt> where the call 
27861returning <tt>t1</tt> happens before (1.10) the call returning <tt>t2</tt> and
27862both of these calls happen before <tt>C1::time_point::max()</tt>.
27863<ins><tt>ec</tt> denotes an object of type <tt>error_code</tt> 
27864(19.5.2.1 [syserr.errcode.overview]).</ins>
27865</p>
27866
27867<table border="1">
27868<caption>Table 55 -- Clock requirements</caption>
27869<tbody><tr>
27870<th>Expression</th><th>Return type</th><th>Operational semantics</th>
27871</tr>
27872
27873<tr>
27874<td>...</td>
27875<td>...</td>
27876<td>...</td>
27877</tr>
27878
27879<tr>
27880<td><tt>C1::now()</tt></td>
27881<td><tt>C1::time_point</tt></td>
27882<td>Returns a <tt>time_point</tt> object representing the current point in time.
27883</td>
27884</tr>
27885
27886<tr>
27887<td><tt><ins>C1::now(ec)</ins></tt></td>
27888<td><tt><ins>C1::time_point</ins></tt></td>
27889<td><ins>Returns a <tt>time_point</tt> object representing the current point in time.</ins>
27890</td>
27891</tr>
27892</tbody></table>
27893</blockquote>
27894
27895<p>
27896Change Class system_clock 20.9.5.1 [time.clock.system] as indicated:
27897</p>
27898
27899<blockquote><pre>static time_point now(<ins>error_code&amp; ec=throws()</ins>);
27900</pre></blockquote>
27901
27902<p>
27903Change Class monotonic_clock 20.9.5.2 [time.clock.monotonic] as indicated:
27904</p>
27905
27906<blockquote><pre>static time_point now(<ins>error_code&amp; ec=throws()</ins>);
27907</pre></blockquote>
27908
27909<p>
27910Change Class high_resolution_clock 20.9.5.3 [time.clock.hires] as indicated:
27911</p>
27912
27913<blockquote><pre>static time_point now(<ins>error_code&amp; ec=throws()</ins>);
27914</pre></blockquote>
27915
27916
27917
27918
27919
27920
27921<hr>
27922<h3><a name="936"></a>936. Mutex type overspecified</h3>
27923<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#NAD%20Future">NAD Future</a>
27924 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-12-05  <b>Last modified:</b> 2009-10-23</p>
27925<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>
27926<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>
27927<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
27928<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#961">961</a></p>
27929<p><b>Discussion:</b></p>
27930
27931
27932
27933<p>
2793430.4.1 [thread.mutex.requirements] describes the requirements for a type to be
27935a "Mutex type". A Mutex type can be used as the template argument for
27936the <tt>Lock</tt> type that's passed to <tt>condition_variable_any::wait</tt> (although
27937<tt>Lock</tt> seems like the wrong name here, since <tt>Lock</tt> is given a different
27938formal meaning in 30.4.3 [thread.lock]) and, although the WD doesn't quite say
27939so, as the template argument for <tt>lock_guard</tt> and <tt>unique_lock</tt>.
27940</p>
27941
27942<p>
27943The requirements for a Mutex type include:
27944</p>
27945
27946<ul>
27947<li>
27948<tt>m.lock()</tt> shall be well-formed and have [described] semantics, including a return type of <tt>void</tt>.
27949</li>
27950<li>
27951<tt>m.try_lock()</tt> shall be well-formed and have [described] semantics, including a return type of <tt>bool</tt>.
27952</li>
27953<li>
27954<tt>m.unlock()</tt> shall be well-formed and have [described] semantics, including a return type of <tt>void</tt>.
27955</li>
27956</ul>
27957
27958<p>
27959Also, a Mutex type "shall not be copyable nor movable".
27960</p>
27961
27962<p>
27963The latter requirement seems completely irrelevant, and the three
27964requirements on return types are tighter than they need to be. For
27965example, there's no reason that <tt>lock_guard</tt> can't be instantiated with a
27966type that's copyable. The rule is, in fact, that <tt>lock_guard</tt>, etc. won't
27967try to copy objects of that type. That's a constraint on locks, not on
27968mutexes. Similarly, the requirements for <tt>void</tt> return types are
27969unnecessary; the rule is, in fact, that <tt>lock_guard</tt>, etc. won't use any
27970returned value. And with the return type of <tt>bool</tt>, the requirement should
27971be that the return type is convertible to <tt>bool</tt>.
27972</p>
27973
27974<p><i>[
27975Summit:
27976]</i></p>
27977
27978
27979<blockquote>
27980<p>
27981Move to open. Related to conceptualization and should probably be tackled as part of that.
27982</p>
27983<ul>
27984<li>
27985The intention is not only to place a constraint on what types such as
27986<tt>lock_guard</tt> may do with mutex types, but on what any code, including user
27987code, may do with mutex types. Thus the constraints as they are apply to
27988the mutex types themselves, not the current users of mutex types in the
27989standard.
27990</li>
27991<li>
27992This is a low priority issue; the wording as it is may be overly
27993restrictive but this may not be a real issue.
27994</li>
27995</ul>
27996</blockquote>
27997
27998<p><i>[
27999Post Summit Anthony adds:
28000]</i></p>
28001
28002
28003<blockquote>
28004<p>
28005Section 30.4.1 [thread.mutex.requirements] conflates the
28006requirements on a generic Mutex type (including user-supplied mutexes)
28007with the requirements placed on the standard-supplied mutex types in an
28008attempt to group everything together and save space.
28009</p>
28010<p>
28011When applying concepts to chapter 30, I suggest that the concepts
28012<tt>Lockable</tt> and <tt>TimedLockable</tt> embody the requirements for
28013*use* of a mutex type as required by
28014<tt>unique_lock/lock_guard/condition_variable_any</tt>. These should be
28015relaxed as Pete describes in the issue. The existing words in 30.4.1 [thread.mutex.requirements] are requirements on all of
28016<tt>std::mutex</tt>, <tt>std::timed_mutex</tt>,
28017<tt>std::recursive_mutex</tt> and <tt>std::recursive_timed_mutex</tt>,
28018and should be rephrased as such.
28019</p>
28020</blockquote>
28021
28022
28023
28024<p><b>Proposed resolution:</b></p>
28025<p>
28026</p>
28027
28028
28029
28030
28031
28032<hr>
28033<h3><a name="937"></a>937. Atomics for standard typedef types</h3>
28034<p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
28035 <b>Submitter:</b> Clark Nelson <b>Opened:</b> 2008-12-05  <b>Last modified:</b> 2009-05-23</p>
28036<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>
28037<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
28038<p><b>Discussion:</b></p>
28039
28040<p><b>Addresses US 89</b></p>
28041
28042<blockquote>
28043<p>
28044The types in the table "Atomics for standard typedef types" should be
28045typedefs, not classes. These semantics are necessary for compatibility
28046with C.
28047</p>
28048
28049<p>
28050Change the classes to typedefs.
28051</p>
28052</blockquote>
28053
28054<p>
28055<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html">N2427</a>
28056specified different requirements for atomic analogs of fundamental
28057integer types (such as <tt>atomic_int</tt>) and for atomic analogs of <tt>&lt;cstdint&gt;</tt>
28058typedefs (such as <tt>atomic_size_t</tt>). Specifically, <tt>atomic_int</tt> et al. were
28059specified to be distinct classes, whereas <tt>atomic_size_t</tt> et al. were
28060specified to be typedefs. Unfortunately, in applying
28061<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html">N2427</a>
28062to the WD, that distinction was erased, and the atomic analog of every <tt>&lt;cstdint&gt;</tt>
28063typedef is required to be a distinct class.
28064</p>
28065
28066<p>
28067It shouldn't be required that the atomic analog of every <tt>&lt;cstdint&gt;</tt>
28068typedef be a typedef for some fundamental integer type. After all,
28069<tt>&lt;cstdint&gt;</tt> is supposed to provide standard names for extended integer
28070types. So there was a problem in
28071<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html">N2427</a>,
28072which certainly could have been
28073interpreted to require that. But the status quo in the WD is even worse,
28074because it's unambiguously wrong.
28075</p>
28076
28077<p>
28078What is needed are words to require the existence of a bunch of type
28079names, without specifying whether they are class names or typedef names.
28080</p>
28081
28082<p><i>[
28083Summit:
28084]</i></p>
28085
28086
28087<blockquote>
28088<p>
28089Change status to NAD, editorial. See US 89 comment notes above.
28090</p>
28091<p>
28092Direct the editor to turn the types into typedefs as proposed in the
28093comment. Paper approved by committee used typedefs, this appears to have
28094been introduced as an editorial change. Rationale: for compatibility
28095with C.
28096</p>
28097</blockquote>
28098
28099
28100<p><b>Proposed resolution:</b></p>
28101<p>
28102</p>
28103
28104
28105
28106
28107
28108<hr>
28109<h3><a name="941"></a>941. Ref-qualifiers for assignment operators</h3>
28110<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
28111 <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2008-12-18  <b>Last modified:</b> 2009-07-17</p>
28112<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>
28113<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>
28114<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
28115<p><b>Discussion:</b></p>
28116<p>
28117The assignment and equality operators <tt>=</tt> and <tt>==</tt> are easily confused, just
28118because of their visual similarity, and in this case a simple typo can cause
28119a serious bug. When the left side of an <tt>operator=</tt> is an rvalue, it's
28120highly unlikely that the assignment was intended by the programmer:
28121</p>
28122<blockquote><pre>if ( func() = value )  // Typical typo: == intended!
28123</pre></blockquote>
28124<p>
28125Built-in types don't support assignment to an rvalue, but unfortunately,
28126a lot of types provided by the Standard Library do.
28127</p>
28128<p>
28129Fortunately the language now offers a syntax to prevent a certain member
28130function from having an rvalue as <tt>*this</tt>: by adding a ref-qualifier (<tt>&amp;</tt>)
28131to the member function declaration.  Assignment operators are explicitly
28132mentioned as a use case of ref-qualifiers, in "Extending Move Semantics
28133To <tt>*this</tt> (Revision 1)",
28134<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1821.htm">N1821</a> by Daveed
28135Vandevoorde and Bronek Kozicki
28136</p>
28137<p>
28138Hereby I would like to propose adding ref-qualifiers to all appropriate
28139assignment operators in the library.
28140</p>
28141
28142<p><i>[
28143Batavia (2009-05):
28144]</i></p>
28145
28146<blockquote>
28147Move to Open.
28148We recommend this be deferred until after the next Committee Draft.
28149</blockquote>
28150
28151<p><i>[
28152Frankfurt 2009-07:
28153]</i></p>
28154
28155
28156<blockquote>
28157<p>
28158The LWG declined to move forward with
28159<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2819.html">N2819</a>.
28160</p>
28161<p>
28162Moved to NAD.
28163</p>
28164</blockquote>
28165
28166
28167<p><b>Proposed resolution:</b></p>
28168<p>
28169A proposed resolution is provided by the paper on this subject,
28170<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2819.html">N2819</a>,
28171<i>Ref-qualifiers for assignment operators of the Standard Library</i>
28172</p>
28173
28174
28175
28176
28177
28178<hr>
28179<h3><a name="942"></a>942. Atomics synopsis typo</h3>
28180<p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
28181 <b>Submitter:</b> Holger Grund <b>Opened:</b> 2008-12-19  <b>Last modified:</b> 2009-03-22</p>
28182<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>
28183<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
28184<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#880">880</a></p>
28185<p><b>Discussion:</b></p>
28186
28187
28188
28189<p>
28190I'm looking at 29 [atomics] and can't really make sense of a couple of things.
28191</p>
28192<p>
28193Firstly, there appears to be a typo in the <tt>&lt;cstdatomic&gt;</tt> synopsis:
28194</p>
28195
28196<blockquote>
28197<p>
28198The <tt>atomic_exchange</tt> overload taking an <tt>atomic_address</tt>
28199is missing the second parameter:
28200</p>
28201
28202<blockquote><pre>void* atomic_exchange(volatile atomic_address*);
28203</pre></blockquote>
28204
28205<p>
28206should be
28207</p>
28208
28209<blockquote><pre>void* atomic_exchange(volatile atomic_address*<ins>, void*</ins>);
28210</pre></blockquote>
28211
28212<p>
28213Note, that this is <em>not</em> covered by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#880">880</a> "Missing atomic exchange parameter",
28214which only talks about the <tt>atomic_bool</tt>.
28215</p>
28216</blockquote>
28217
28218
28219
28220<p><b>Proposed resolution:</b></p>
28221<p>
28222Change the synopsis in 29 [atomics]/2:
28223</p>
28224
28225<blockquote><pre>void* atomic_exchange(volatile atomic_address*<ins>, void*</ins>);
28226</pre></blockquote>
28227
28228
28229
28230
28231
28232
28233<hr>
28234<h3><a name="944"></a>944. <tt>atomic&lt;bool&gt;</tt> derive from <tt>atomic_bool</tt>?</h3>
28235<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#NAD%20Editorial">NAD Editorial</a>
28236 <b>Submitter:</b> Holger Grund <b>Opened:</b> 2008-12-19  <b>Last modified:</b> 2009-10-26</p>
28237<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>
28238<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
28239<p><b>Discussion:</b></p>
28240<p>
28241I think it's fairly obvious that <tt>atomic&lt;bool&gt;</tt> is supposed to be derived
28242from <tt>atomic_bool</tt> (and otherwise follow the <tt>atomic&lt;integral&gt;</tt> interface),
28243though I think the current wording doesn't support this. I raised this
28244point along with <tt>atomic&lt;floating-point&gt;</tt> privately with Herb and I seem
28245to recall it came up in the resulting discussion on this list. However,
28246I don't see anything on the current libs issue list mentioning this
28247problem.
28248</p>
28249
28250<p>
2825129.5.3 [atomics.types.generic]/3 reads
28252</p>
28253
28254<blockquote>
28255There are full specializations over the integral types on the atomic
28256class template. For each integral type integral in the second column of
28257table 121 or table 122, the specialization <tt>atomic&lt;integral&gt;</tt> shall be
28258publicly derived from the corresponding atomic integral type in the
28259first column of the table. These specializations shall have trivial
28260default constructors and trivial destructors.
28261</blockquote>
28262
28263<p>
28264Table 121 does not include (<tt>atomic_bool</tt>, <tt>bool</tt>),
28265so that this should probably be mentioned explicitly in the quoted paragraph.
28266</p>
28267
28268<p><i>[
28269Summit:
28270]</i></p>
28271
28272
28273<blockquote>
28274Move to open. Lawrence will draft a proposed resolution. Also, ask
28275Howard to fix the title.
28276</blockquote>
28277
28278<p><i>[
28279Post Summit Anthony provided proposed wording.
28280]</i></p>
28281
28282
28283<p><i>[
282842009-10 Santa Cruz:
28285]</i></p>
28286
28287
28288<blockquote>
28289NAD Editorial.  Solved by
28290<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
28291</blockquote>
28292
28293
28294
28295<p><b>Proposed resolution:</b></p>
28296<p>
28297Replace paragraph 3 in 29.5.3 [atomics.types.generic] with
28298</p>
28299
28300<blockquote>
28301-3- There are full specializations over the integral types on the <tt>atomic</tt>
28302class template. For each integral type <tt>integral</tt> in the second column of
28303table 121 or table 122, the specialization <tt>atomic&lt;integral&gt;</tt> shall be
28304publicly derived from the corresponding atomic integral type in the first
28305column of the table.
28306<ins>In addition, the specialization <tt>atomic&lt;bool&gt;</tt>
28307shall be publicly derived from <tt>atomic_bool</tt>.</ins>
28308These specializations shall have trivial default
28309constructors and trivial destructors.
28310</blockquote>
28311
28312
28313
28314
28315
28316<hr>
28317<h3><a name="945"></a>945. <tt>system_clock::rep</tt> not specified</h3>
28318<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#NAD%20Editorial">NAD Editorial</a>
28319 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-12-19  <b>Last modified:</b> 2009-07-13</p>
28320<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>
28321<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
28322<p><b>Discussion:</b></p>
28323<p>
28324In 20.9.5.1 [time.clock.system], the declaration of <tt>system_clock::rep</tt> says "see
28325below", but there is nothing below that describes it.
28326</p>
28327
28328<p><i>[
28329Howard adds:
28330]</i></p>
28331
28332
28333<blockquote>
28334<p>
28335This note refers to:
28336</p>
28337
28338<blockquote>
28339-2- <tt>system_clock::duration::min() &lt; system_clock::duration::zero()</tt> shall be <tt>true</tt>.
28340</blockquote>
28341
28342<p>
28343I.e. this is standardeze for "<tt>system_clock::rep</tt> is signed".
28344Perhaps an editorial note along the lines of:
28345</p>
28346
28347<blockquote>
28348-2- <tt>system_clock::duration::min() &lt; system_clock::duration::zero()</tt>
28349shall be <tt>true</tt>. <ins>[<i>Note:</i> <tt>system_clock::rep</tt> shall be signed. <i>-- end note</i>].</ins>
28350</blockquote>
28351
28352<p>
28353?
28354</p>
28355
28356</blockquote>
28357
28358<p><i>[
28359Batavia (2009-05):
28360]</i></p>
28361
28362<blockquote>
28363We agree with the direction of the proposed resolution.
28364Move to NAD Editorial.
28365</blockquote>
28366
28367
28368
28369<p><b>Proposed resolution:</b></p>
28370<p>
28371Add a note to 20.9.5.1 [time.clock.system], p2:
28372</p>
28373<blockquote>
28374-2- <tt>system_clock::duration::min() &lt; system_clock::duration::zero()</tt>
28375shall be <tt>true</tt>. <ins>[<i>Note:</i> <tt>system_clock::rep</tt> shall be signed. <i>-- end note</i>].</ins>
28376</blockquote>
28377
28378
28379
28380
28381
28382<hr>
28383<h3><a name="946"></a>946. <tt>duration_cast</tt> improperly specified</h3>
28384<p><b>Section:</b> 20.9.3.7 [time.duration.cast] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
28385 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-12-20  <b>Last modified:</b> 2009-07-13</p>
28386<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration.cast">issues</a> in [time.duration.cast].</p>
28387<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
28388<p><b>Discussion:</b></p>
2838920.9.3.7 [time.duration.cast]/3:
28390
28391<blockquote>
28392.... All intermediate computations shall be
28393carried out in the widest possible representation... .
28394</blockquote>
28395
28396<p>
28397So ignoring
28398floating-point types for the moment, all this arithmetic has to be done
28399using the implementation's largest integral type, even if both arguments
28400use int for their representation. This seems excessive. And it's not at
28401all clear what this means if we don't ignore floating-point types.
28402</p>
28403
28404<p>
28405This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#952">952</a>.
28406</p>
28407
28408<p><i>[
28409Howard adds:
28410]</i></p>
28411
28412
28413<blockquote>
28414<p>
28415The intent of this remark is that intermediate computations are carried out
28416using:
28417</p>
28418
28419<blockquote><pre>common_type&lt;typename ToDuration::rep, Rep, intmax_t&gt;::type
28420</pre></blockquote>
28421
28422<p>
28423The Remark was intended to be clarifying prose supporting the rather algorithmic description
28424of the previous paragraph.  I'm open to suggestions.  Perhaps the entire paragraph
284253 (Remarks) would be better dropped?
28426</p>
28427</blockquote>
28428
28429<p><i>[
28430Batavia (2009-05):
28431]</i></p>
28432
28433<blockquote>
28434<p>
28435We view this as a specific case of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#952">952</a>,
28436and should be resolved when that issue is resolved.
28437</p>
28438<p>
28439Move to NAD.
28440</p>
28441</blockquote>
28442
28443
28444
28445<p><b>Proposed resolution:</b></p>
28446<p>
28447</p>
28448
28449
28450
28451
28452
28453<hr>
28454<h3><a name="947"></a>947. duration arithmetic: contradictory requirements</h3>
28455<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#NAD%20Editorial">NAD Editorial</a>
28456 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2008-12-20  <b>Last modified:</b> 2009-10-26</p>
28457<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>
28458<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
28459<p><b>Discussion:</b></p>
28460<p>
28461In 20.9.3.5 [time.duration.nonmember], paragraph 8 says that calling
28462<tt>dur / rep</tt>
28463when <tt>rep</tt> is an instantiation of <tt>duration</tt> requires a diagnostic.
28464That's followed by an <tt>operator/</tt> that takes two durations.
28465So <tt>dur1 / dur2</tt> is legal under the second version,
28466but requires a diagnostic under the first.
28467</p>
28468
28469<p><i>[
28470Howard adds:
28471]</i></p>
28472
28473
28474<blockquote>
28475Please see the thread starting with c++std-lib-22980 for more information.
28476</blockquote>
28477
28478<p><i>[
28479Batavia (2009-05):
28480]</i></p>
28481
28482<blockquote>
28483Move to Open, pending proposed wording (and preferably an implementation).
28484</blockquote>
28485
28486<p><i>[
284872009-07-27 Howard adds:
28488]</i></p>
28489
28490
28491<blockquote>
28492<p>
28493I'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
28494cleans up several places under 20.9.3 [time.duration] which used the
28495phrase "diagnostic required".
28496</p>
28497<p>
28498For clarity's sake, here is an example implementation of the constrained <tt>operator/</tt>:
28499</p>
28500
28501<blockquote><pre>template &lt;class _Duration, class _Rep, bool = __is_duration&lt;_Rep&gt;::value&gt;
28502struct __duration_divide_result
28503{
28504};
28505
28506template &lt;class _Duration, class _Rep2,
28507    bool = is_convertible&lt;_Rep2,
28508                          typename common_type&lt;typename _Duration::rep, _Rep2&gt;::type&gt;::value&gt;
28509struct __duration_divide_imp
28510{
28511};
28512
28513template &lt;class _Rep1, class _Period, class _Rep2&gt;
28514struct __duration_divide_imp&lt;duration&lt;_Rep1, _Period&gt;, _Rep2, true&gt;
28515{
28516    typedef duration&lt;typename common_type&lt;_Rep1, _Rep2&gt;::type, _Period&gt; type;
28517};
28518
28519template &lt;class _Rep1, class _Period, class _Rep2&gt;
28520struct __duration_divide_result&lt;duration&lt;_Rep1, _Period&gt;, _Rep2, false&gt;
28521    : __duration_divide_imp&lt;duration&lt;_Rep1, _Period&gt;, _Rep2&gt;
28522{
28523};
28524
28525template &lt;class _Rep1, class _Period, class _Rep2&gt;
28526inline
28527typename __duration_divide_result&lt;duration&lt;_Rep1, _Period&gt;, _Rep2&gt;::type
28528operator/(const duration&lt;_Rep1, _Period&gt;&amp; __d, const _Rep2&amp; __s)
28529{
28530    typedef typename common_type&lt;_Rep1, _Rep2&gt;::type _Cr;
28531    duration&lt;_Cr, _Period&gt; __r = __d;
28532    __r /= static_cast&lt;_Cr&gt;(__s);
28533    return __r;
28534}
28535</pre></blockquote>
28536
28537<p>
28538<tt>__duration_divide_result</tt> is basically a custom-built <tt>enable_if</tt>
28539that will contain <tt>type</tt> only if <tt>Rep2</tt> is not a <tt>duration</tt>
28540and if <tt>Rep2</tt> is implicitly convertible to
28541<tt>common_type&lt;typename Duration::rep, Rep2&gt;::type</tt>. <tt>__is_duration</tt>
28542is simply a private trait that answers <tt>false</tt>, but is specialized for
28543<tt>duration</tt> to answer <tt>true</tt>.
28544</p>
28545
28546<p>
28547The constrained <tt>operator%</tt> works identically.
28548</p>
28549</blockquote>
28550
28551<p><i>[
285522009-10 Santa Cruz:
28553]</i></p>
28554
28555
28556<blockquote>
28557Mark NAD Editorial, fixed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1177">1177</a>.
28558</blockquote>
28559
28560
28561
28562<p><b>Proposed resolution:</b></p>
28563<p>
28564</p>
28565
28566
28567
28568
28569
28570<hr>
28571<h3><a name="952"></a>952. Various threading bugs #2</h3>
28572<p><b>Section:</b> 20.9.3.7 [time.duration.cast] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
28573 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-07-13</p>
28574<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time.duration.cast">issues</a> in [time.duration.cast].</p>
28575<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
28576<p><b>Discussion:</b></p>
28577<p>
2857820.9.3.7 [time.duration.cast] specifies an implementation and imposes
28579requirements in text (and the implementation doesn't satisfy all of the
28580text requirements). Pick one.
28581</p>
28582
28583<p>
28584This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#946">946</a>.
28585</p>
28586
28587<p><i>[
285882009-05-10 Howard adds:
28589]</i></p>
28590
28591
28592<blockquote>
28593<p>
28594The <i>Remarks</i> paragraph is an English re-statement of the preceeding
28595<i>Returns</i> clause.  It was meant to be clarifying and motivating, not
28596confusing.  I'm not aware with how the <i>Remarks</i> contradicts the <i>Returns</i> clause
28597but I'm ok with simply removing the <i>Remarks</i>.
28598</p>
28599</blockquote>
28600
28601<p><i>[
28602Batavia (2009-05):
28603]</i></p>
28604
28605<blockquote>
28606<p>
28607Pete suggests that this could be resolved
28608by rephrasing the Remarks to Notes.
28609</p>
28610<p>
28611Move to NAD Editorial.
28612</p>
28613</blockquote>
28614
28615
28616<p><b>Proposed resolution:</b></p>
28617<p>
28618</p>
28619
28620
28621
28622
28623
28624<hr>
28625<h3><a name="955"></a>955. Various threading bugs #5</h3>
28626<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#NAD">NAD</a>
28627 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-10-26</p>
28628<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>
28629<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>
28630<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
28631<p><b>Discussion:</b></p>
28632<p>
2863320.9.1 [time.clock.req] requires that a clock type have a member
28634typedef named <tt>time_point</tt> that names an instantiation of the
28635template <tt>time_point</tt>, and a member named <tt>duration</tt> that
28636names an instantiation of the template <tt>duration</tt>. This mixing of
28637levels is confusing. The typedef names should be different from the
28638template names.
28639</p>
28640
28641<p><i>[
28642Post Summit, Anthony provided proposed wording.
28643]</i></p>
28644
28645
28646<p><i>[
286472009-05-04 Howard adds:
28648]</i></p>
28649
28650
28651<blockquote>
28652<p>
28653The reason that the typedef names were given the same name as the class templates
28654was so that clients would not have to stop and think about whether they were
28655using the clock's native <tt>time_point</tt> / <tt>duration</tt> or the class
28656template directly.  In this case, one person's confusion is another person's
28657encapsulation.  The detail that sometimes one is referring to the clock's
28658native types, and sometimes one is referring to an independent type is
28659<em>purposefully</em> "hidden" because it is supposed to be an unimportant
28660detail.  It can be confusing to have to remember when to type <tt>duration</tt>
28661and when to type <tt>duration_type</tt>, and there is no need to require the
28662client to remember something like that.
28663</p>
28664
28665<p>
28666For example, here is code that I once wrote in testing out the usability of
28667this facility:
28668</p>
28669
28670<blockquote><pre>template &lt;class Clock, class Duration&gt;
28671void do_until(const std::chrono::<b>time_point</b>&lt;Clock, Duration&gt;&amp; t)
28672{
28673    typename Clock::<b>time_point now</b> = Clock::now();
28674    if (t &gt; now)
28675    {
28676        typedef typename std::common_type
28677        &lt;
28678            Duration,
28679            typename std::chrono::system_clock::<b>duration</b>
28680        &gt;::type CD;
28681        typedef std::chrono::<b>duration</b>&lt;double, std::nano&gt; ID;
28682
28683        CD d = t - now;
28684        ID us = duration_cast&lt;ID&gt;(d);
28685        if (us &lt; d)
28686            ++us;
28687        ...
28688    }
28689}
28690</pre></blockquote>
28691
28692<p>
28693I see no rationale to require the client to append <tt>_type</tt> to <em>some</em>
28694of those declarations.  It seems overly burdensome on the author of <tt>do_until</tt>:
28695</p>
28696
28697<blockquote><pre>template &lt;class Clock, class Duration&gt;
28698void do_until(const std::chrono::<b>time_point</b>&lt;Clock, Duration&gt;&amp; t)
28699{
28700    typename Clock::<b>time_point<font color="#c80000">_type</font></b> now = Clock::now();
28701    if (t &gt; now)
28702    {
28703        typedef typename std::common_type
28704        &lt;
28705            Duration,
28706            typename std::chrono::system_clock::<b>duration<font color="#c80000">_type</font></b>
28707        &gt;::type CD;
28708        typedef std::chrono::<b>duration</b>&lt;double, std::nano&gt; ID;
28709
28710        CD d = t - now;
28711        ID us = duration_cast&lt;ID&gt;(d);
28712        if (us &lt; d)
28713            ++us;
28714        ...
28715    }
28716}
28717</pre></blockquote>
28718
28719<p>
28720Additionally I'm fairly certain that this suggestion hasn't been implemented.
28721If it had, it would have been discovered that it is incomplete.  <tt>time_point</tt>
28722also has a nested type (purposefully) named <tt>duration</tt>.
28723</p>
28724<blockquote>
28725That is, the current proposed wording would put the WP into an inconsistent state.
28726</blockquote>
28727<p>
28728In contrast,
28729the current WP has been implemented and I've received very favorable feedback
28730from people using this interface in real-world code.
28731</p>
28732
28733</blockquote>
28734
28735<p><i>[
28736Batavia (2009-05):
28737]</i></p>
28738
28739<blockquote>
28740<p>
28741Bill agrees that distinct names should be used for distinct kinds of entities.
28742</p>
28743<p>
28744Walter would prefer not to suffix type names,
28745especially for such well-understood terms as "duration".
28746</p>
28747<p>
28748Howard reminds us that the proposed resolution is incomplete, per his comment
28749in the issue.
28750</p>
28751<p>
28752Move to Open.
28753</p>
28754</blockquote>
28755
28756<p><i>[
287572009-06-07 Howard adds:
28758]</i></p>
28759
28760
28761<blockquote>
28762<p>
28763Not meaning to be argumentative, but we have a decade of positive experience
28764with the precedent of using the same name for the nested type as an external
28765class representing an identical concept.
28766</p>
28767
28768<blockquote><pre>template&lt;class Category, class T, class Distance = ptrdiff_t,
28769         class Pointer = T*, class Reference = T&amp;&gt;
28770struct <b>iterator</b>
28771{
28772    ...
28773};
28774
28775template &lt;BidirectionalIterator Iter&gt;
28776class <b>reverse_iterator</b>
28777{
28778    ...
28779};
28780
28781template &lt;ValueType T, Allocator Alloc = allocator&lt;T&gt; &gt;
28782    requires NothrowDestructible&lt;T&gt;
28783class list
28784{
28785public:
28786    typedef <i>implementation-defined</i>     <b>iterator</b>;
28787    ...
28788    typedef reverse_iterator&lt;iterator&gt; <b>reverse_iterator</b>;
28789    ...
28790};
28791</pre></blockquote>
28792
28793<p>
28794I am aware of <em>zero</em> complaints regarding the use of <tt>iterator</tt>
28795and <tt>reverse_iterator</tt> as nested types of the containers despite these
28796names also having related meaning at namespace std scope.
28797</p>
28798
28799<p>
28800Would we really be doing programmers a favor by renaming these nested types?
28801</p>
28802
28803<blockquote><pre>template &lt;ValueType T, Allocator Alloc = allocator&lt;T&gt; &gt;
28804    requires NothrowDestructible&lt;T&gt;
28805class list
28806{
28807public:
28808    typedef <i>implementation-defined</i>     <b>iterator_type</b>;
28809    ...
28810    typedef reverse_iterator&lt;iterator&gt; <b>reverse_iterator_type</b>;
28811    ...
28812};
28813</pre></blockquote>
28814
28815<p>
28816I submit that such design contributes to needless verbosity which ends up
28817reducing readability.
28818</p>
28819</blockquote>
28820
28821<p><i>[
288222009-10 Santa Cruz:
28823]</i></p>
28824
28825
28826<blockquote>
28827Mark as NAD.  No concensus for changing the WP.
28828</blockquote>
28829
28830
28831
28832<p><b>Proposed resolution:</b></p>
28833<p>
28834Change 20.9 [time]:
28835</p>
28836
28837<blockquote><pre>...
28838template &lt;class Clock, class Duration = typename Clock::duration<ins>_type</ins>&gt; class time_point;
28839...
28840</pre></blockquote>
28841
28842<p>
28843Change 20.9.1 [time.clock.req]:
28844</p>
28845
28846<blockquote>
28847<table border="1">
28848<caption>Table 45 -- Clock requirements</caption>
28849<tbody><tr>
28850<th>Expression</th>
28851<th>Return type</th>
28852<th>Operational semantics</th>
28853</tr>
28854<tr>
28855<td>...</td>
28856<td>...</td>
28857<td>...</td>
28858</tr>
28859<tr>
28860<td><tt>C1::duration<ins>_type</ins></tt></td>
28861<td><tt>chrono::duration&lt;C1::rep, C1::period&gt;</tt></td>
28862<td>The native <tt>duration</tt> type of the clock.</td>
28863</tr>
28864<tr>
28865<td><tt>C1::time_point<ins>_type</ins></tt></td>
28866<td><tt>chrono::time_point&lt;C1&gt;</tt> or <tt>chrono::time_point&lt;C2, C1::duration<ins>_type</ins>&lt;</tt></td>
28867<td>The native <tt>time_point</tt> type of the clock.   Different clocks may  share a <tt>time_point<ins>_type</ins></tt>
28868definition if it is valid to 
28869compare their <tt>time_point<ins>_type</ins></tt>s by 
28870comparing their respective 
28871<tt>duration<ins>_type</ins></tt>s. <tt>C1</tt> and <tt>C2</tt> shall 
28872refer to the same epoch.</td>
28873</tr>
28874<tr>
28875<td>...</td>
28876<td>...</td>
28877<td>...</td>
28878</tr>
28879<tr>
28880<td><tt>C1::now()</tt></td>
28881<td><tt>C1::time_point<ins>_type</ins></tt></td>
28882<td>Returns a <tt>time_point<ins>_type</ins></tt> object 
28883representing the current point 
28884in time.
28885</td>
28886</tr>
28887</tbody></table>
28888</blockquote>
28889
28890<p>
28891Change 20.9.5.1 [time.clock.system]:
28892</p>
28893
28894<blockquote>
28895<p>
28896-1- Objects of class <tt>system_clock</tt> represent wall clock time from the system-wide realtime clock.
28897</p>
28898
28899<blockquote><pre>class system_clock { 
28900public: 
28901  typedef <i>see below</i> rep; 
28902  typedef ratio&lt;<i>unspecified</i>, <i>unspecified</i>&gt; period; 
28903  typedef chrono::duration&lt;rep, period&gt; duration<ins>_type</ins>; 
28904  typedef chrono::time_point&lt;system_clock&gt; time_point<ins>_type</ins>; 
28905  static const bool is_monotonic = <i>unspecified</i> ; 
28906
28907  static time_point<ins>_type</ins> now(); 
28908
28909  // Map to C API 
28910  static time_t to_time_t (const time_point<ins>_type</ins>&amp; t); 
28911  static time_point<ins>_type</ins> from_time_t(time_t t); 
28912};
28913</pre></blockquote>
28914
28915<p>
28916-2- <tt>system_clock::duration<ins>_type</ins>::min() &lt; system_clock::duration<ins>_type</ins>::zero()</tt> shall be <tt>true</tt>.
28917</p>
28918
28919<pre>time_t to_time_t(const time_point<ins>_type</ins>&amp; t);
28920</pre>
28921
28922<blockquote>
28923-3- <i>Returns:</i> A <tt>time_t</tt> object that represents the same
28924point in time as <tt>t</tt> when both values are truncated to the
28925coarser of the precisions of <tt>time_t</tt> and <tt>time_point<ins>_type</ins></tt>.
28926</blockquote>
28927
28928<pre><tt>time_point<ins>_type</ins></tt> from_time_t(time_t t);
28929</pre>
28930
28931<blockquote>
28932-4- <i>Returns:</i> A <tt>time_point<ins>_type</ins></tt> object that represents the same point
28933in time as <tt>t</tt> when both values are truncated to the coarser of the
28934precisions of <tt>time_t</tt> and <tt>time_point<ins>_type</ins></tt>.
28935</blockquote>
28936</blockquote>
28937
28938<p>
28939Change 20.9.5.2 [time.clock.monotonic]:
28940</p>
28941
28942<blockquote><pre>class monotonic_clock { 
28943public: 
28944  typedef <i>unspecified</i>                                rep; 
28945  typedef ratio&lt;<i>unspecified</i> , <i>unspecified</i>&gt;           period; 
28946  typedef chrono::duration&lt;rep, period&gt;              duration<ins>_type</ins>; 
28947  typedef chrono::time_point&lt;<i>unspecified</i> , duration<ins>_type</ins>&gt; time_point<ins>_type</ins>; 
28948  static const bool is_monotonic =                   true; 
28949
28950  static time_point<ins>_type</ins> now();
28951};
28952</pre></blockquote>
28953
28954<p>
28955Change 20.9.5.3 [time.clock.hires]:
28956</p>
28957
28958<blockquote><pre>class high_resolution_clock { 
28959public: 
28960  typedef <i>unspecified</i>                                rep; 
28961  typedef ratio&lt;<i>unspecified</i> , <i>unspecified</i>&gt;           period; 
28962  typedef chrono::duration&lt;rep, period&gt;              duration<ins>_type</ins>; 
28963  typedef chrono::time_point&lt;<i>unspecified</i> , duration<ins>_type</ins>&gt; time_point<ins>_type</ins>; 
28964  static const bool is_monotonic =                   true; 
28965
28966  static time_point<ins>_type</ins> now();
28967};
28968</pre></blockquote>
28969
28970
28971
28972
28973
28974
28975<hr>
28976<h3><a name="958"></a>958. Various threading bugs #8</h3>
28977<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#NAD%20Editorial">NAD Editorial</a>
28978 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-10-23</p>
28979<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>
28980<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>
28981<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
28982<p><b>Discussion:</b></p>
28983<p>
2898430.5.1 [thread.condition.condvar]: the specification for <tt>wait_for</tt>
28985with no predicate has an effects clause that says it calls <tt>wait_until</tt>,
28986and a returns clause that sets out in words how to determine the return
28987value. Is this description of the return value subtly different from the
28988description of the value returned by <tt>wait_until</tt>? Or should the effects
28989clause and the returns clause be merged?
28990</p>
28991
28992<p><i>[
28993Summit:
28994]</i></p>
28995
28996
28997<blockquote>
28998Move to open. Associate with LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a> and any other monotonic-clock
28999related issues.
29000</blockquote>
29001
29002<p><i>[
290032009-08-01 Howard adds:
29004]</i></p>
29005
29006
29007<blockquote>
29008I believe that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a> (currently Ready) addresses this issue, and
29009that this issue should be marked NAD, solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a> (assuming
29010it moves to WP).
29011</blockquote>
29012
29013<p><i>[
290142009-10 Santa Cruz:
29015]</i></p>
29016
29017
29018<blockquote>
29019Mark as NAD Editorial, solved by resolution of Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#859">859</a>.
29020</blockquote>
29021
29022
29023
29024<p><b>Proposed resolution:</b></p>
29025<p>
29026</p>
29027
29028
29029
29030
29031
29032<hr>
29033<h3><a name="961"></a>961. Various threading bugs #11</h3>
29034<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#NAD%20Future">NAD Future</a>
29035 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-10-26</p>
29036<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>
29037<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>
29038<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
29039<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#936">936</a></p>
29040<p><b>Discussion:</b></p>
29041<p>
2904230.4.1 [thread.mutex.requirements] describes required member
29043functions of mutex types, and requires that they throw exceptions under
29044certain circumstances. This is overspecified. User-defined types can
29045abort on such errors without affecting the operation of templates
29046supplied by standard-library.
29047</p>
29048
29049<p><i>[
29050Summit:
29051]</i></p>
29052
29053<blockquote>
29054Move to open. Related to conceptualization and should probably be
29055tackled as part of that.
29056</blockquote>
29057
29058<p><i>[
290592009-10 Santa Cruz:
29060]</i></p>
29061
29062
29063<blockquote>
29064<p>
29065Would be OK to leave it as is for time constraints, could loosen later.
29066</p>
29067
29068<p>
29069Mark as NAD Future.
29070</p>
29071</blockquote>
29072
29073
29074
29075<p><b>Proposed resolution:</b></p>
29076<p>
29077</p>
29078
29079
29080
29081
29082
29083<hr>
29084<h3><a name="969"></a>969. What happened to Library Issue 475?</h3>
29085<p><b>Section:</b> 25.2.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
29086 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2009-01-12  <b>Last modified:</b> 2009-07-13</p>
29087<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>
29088<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
29089<p><b>Discussion:</b></p>
29090<p>
29091Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a> has CD1 status, but the non-normative note in
29092<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2723.pdf">N2723</a>
29093was removed in
29094<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>
29095(25.2.4 [alg.foreach] in both drafts).
29096</p>
29097
29098<p><i>[
29099Batavia (2009-05):
29100]</i></p>
29101
29102<blockquote>
29103Move to NAD Editorial.
29104</blockquote>
29105
29106
29107<p><b>Proposed resolution:</b></p>
29108<p>
29109Restore the non-normative note. It might need to be expressed in terms of concepts.
29110</p>
29111
29112
29113
29114
29115
29116<hr>
29117<h3><a name="971"></a>971. Spurious diagnostic conversion function</h3>
29118<p><b>Section:</b> 19.5.2.5 [syserr.errcode.nonmembers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
29119 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2009-01-19  <b>Last modified:</b> 2009-10-20</p>
29120<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
29121<p><b>Discussion:</b></p>
29122<p>
29123Anthony Williams raised the question in c++std-lib-22987 "why is there
29124<tt>std::make_error_code(std::errc)</tt>? What purpose does this serve?"
29125</p>
29126<p>
29127The function <tt>make_error_code(errc e)</tt> is not required, since
29128<tt>make_error_condition(errc e)</tt> is the function that is needed for <tt>errc</tt>
29129conversions. <tt>make_error_code(errc e)</tt> appears to be a holdover from my
29130initial confusion over the distinction between POSIX and operating
29131systems that conform to the POSIX spec.
29132</p>
29133
29134<p><i>[
29135Post Summit:
29136]</i></p>
29137
29138
29139<blockquote>
29140Recommend Review.
29141</blockquote>
29142
29143<p><i>[
29144Batavia (2009-05):
29145]</i></p>
29146
29147<blockquote>
29148The designer of the facility (Christopher Kohlhoff)
29149strongly disagrees that there is an issue here,
29150and especially disagrees with the proposed resolution.
29151Bill would prefer to be conservative and not apply this proposed resolution.
29152Move to Open, and recommend strong consideration for NAD status.
29153</blockquote>
29154
29155<p><i>[
291562009-05-21 Beman adds:
29157]</i></p>
29158
29159
29160<blockquote>
29161My mistake. Christopher and Bill are correct and the issue should be
29162NAD. The function is needed by users.
29163</blockquote>
29164
29165<p><i>[
291662009-07-21 Christopher Kohlhoff adds rationale for <tt>make_error_code</tt>:
29167]</i></p>
29168
29169
29170<blockquote>
29171<p>
29172Users (and indeed library implementers) may need to use the
29173<tt>errc</tt> codes in portable code. For example:
29174</p>
29175
29176<blockquote><pre>void do_foo(error_code&amp; ec)
29177{
29178#if defined(_WIN32)
29179  // Windows implementation ...
29180#elif defined(linux)
29181  // Linux implementation ...
29182#else
29183  // do_foo not supported on this platform
29184  ec = make_error_code(errc::not_supported);
29185#endif
29186}
29187</pre></blockquote>
29188</blockquote>
29189
29190<p><i>[
291912009 Santa Cruz:
29192]</i></p>
29193
29194
29195<blockquote>
29196Moved to NAD.
29197</blockquote>
29198
29199
29200
29201<p><b>Proposed resolution:</b></p>
29202<p>
29203Change System error support 19.5 [syserr], Header <tt>&lt;system_error&gt;</tt>
29204synopsis, as indicated:
29205</p>
29206
29207<blockquote><pre><del>error_code make_error_code(errc e);</del>
29208error_condition make_error_condition(errc e);
29209</pre></blockquote>
29210
29211<p>
29212Delete from Class error_code non-member functions
2921319.5.2.5 [syserr.errcode.nonmembers]:
29214</p>
29215
29216<blockquote><pre><del>error_code make_error_code(errc e);</del>
29217</pre>
29218<blockquote>
29219<del><i>Returns:</i> <tt>error_code(static_cast&lt;int&gt;(e),
29220generic_category)</tt>.</del>
29221</blockquote>
29222</blockquote>
29223
29224
29225
29226
29227
29228
29229<hr>
29230<h3><a name="972"></a>972. The term "Assignable" undefined but still in use</h3>
29231<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
29232 <b>Submitter:</b> Niels Dekker <b>Opened:</b> 2009-01-07  <b>Last modified:</b> 2009-07-13</p>
29233<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>
29234<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>
29235<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
29236<p><b>Discussion:</b></p>
29237<p>
29238Previous versions of the Draft had a table, defining the Assignable 
29239requirement.  For example 
29240<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>
29241Table 79, "Assignable requirements". But I guess the term "Assignable" 
29242is outdated by now, because the current Committee Draft provides 
29243<tt>MoveAssignable</tt>, <tt>CopyAssignable</tt>, and <tt>TriviallyCopyAssignable</tt> concepts 
29244instead. And as far as I can see, it no longer has a definition of 
29245<tt>Assignable</tt>. (Please correct me if I'm wrong.) Still the word 
29246"Assignable" is used in eight places in the Draft, 
29247<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>.
29248</p>
29249
29250<p>
29251Are all of those instances of "<tt>Assignable</tt>" to be replaced by "<tt>CopyAssignable</tt>"? 
29252</p>
29253
29254<p><i>[
29255Batavia (2009-05):
29256]</i></p>
29257
29258<blockquote>
29259Move to NAD Editorial.
29260</blockquote>
29261
29262
29263<p><b>Proposed resolution:</b></p>
29264
29265<p>
29266Change Exception Propagation 18.8.5 [propagation]:
29267</p>
29268<blockquote>
29269<tt>exception_ptr</tt> shall be <tt>DefaultConstructible</tt>, <tt>CopyConstructible</tt>,
29270<tt><ins>Copy</ins>Assignable</tt> and <tt>EqualityComparable</tt>.
29271</blockquote>
29272
29273<p>
29274Change Class template reference_wrapper 20.7.5 [refwrap]:
29275</p>
29276<blockquote>
29277<tt>reference_wrapper&lt;T&gt;</tt> is a <tt>CopyConstructible</tt> and <tt><ins>Copy</ins>Assignable</tt> wrapper around a reference to an object of type <tt>T</tt>.
29278</blockquote>
29279<p>
29280Change Placeholders 20.7.11.1.4 [func.bind.place]:
29281</p>
29282<blockquote>
29283It is implementation defined whether placeholder types are <tt><ins>Copy</ins>Assignable</tt>. <tt><ins>Copy</ins>Assignable</tt> placeholders' copy assignment operators shall not throw exceptions.
29284</blockquote>
29285<p>
29286Change Class template shared_ptr 20.8.15.2 [util.smartptr.shared]:
29287</p>
29288<blockquote>
29289Specializations of <tt>shared_ptr</tt> shall be <tt>CopyConstructible</tt>, <tt><ins>Copy</ins>Assignable</tt>, and <tt>LessThanComparable</tt>...
29290</blockquote>
29291<p>
29292Change Class template weak_ptr 20.8.15.3 [util.smartptr.weak]:
29293</p>
29294<blockquote>
29295Specializations of <tt>weak_ptr</tt> shall be <tt>CopyConstructible</tt>, <tt><ins>Copy</ins>Assignable</tt>, and <tt>LessThanComparable</tt>...
29296</blockquote>
29297<p>
29298Change traits typedefs 21.2.2 [char.traits.typedefs] (note: including deletion of reference to 23.1!):
29299</p>
29300<blockquote>
29301<i>Requires:</i> <tt>state_type</tt> shall meet the requirements of <tt><ins>Copy</ins>Assignable</tt><del> (23.1)</del>, <tt>CopyConstructible</tt> (20.1.8), and <tt>DefaultConstructible</tt> types.
29302</blockquote>
29303<p>
29304Change Class seed_seq 26.5.7.1 [rand.util.seedseq] (note again: including deletion of reference to 23.1!):
29305</p>
29306<blockquote>
29307In addition to the requirements set forth below, instances of
29308<tt>seed_seq</tt> shall meet the requirements of <tt>CopyConstructible</tt> (20.1.8) and of <tt><ins>Copy</ins>Assignable</tt><del> (23.1)</del>.
29309</blockquote>
29310
29311<p>
29312Note: The proposed resolution of this issue does not deal with the
29313instance of the term "Assignable" in D.10.1 [auto.ptr], as this is dealt
29314with more specifically by LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#973">973</a>, "<tt>auto_ptr</tt> characteristics", submitted
29315by Maarten Hilferink.
29316</p>
29317
29318
29319
29320
29321
29322
29323<hr>
29324<h3><a name="973"></a>973. auto_ptr characteristics</h3>
29325<p><b>Section:</b> D.10.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
29326 <b>Submitter:</b> Maarten Hilferink <b>Opened:</b> 2009-01-21  <b>Last modified:</b> 2009-07-13</p>
29327<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>
29328<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
29329<p><b>Discussion:</b></p>
29330<p>
29331I think that the Note of D.10.1 [auto.ptr], paragraph 3 needs a rewrite 
29332since "Assignable" is no longer defined as a concept. 
29333The relationship of <tt>auto_ptr</tt> with the new <tt>CopyAssignable</tt>, <tt>MoveAssignable</tt>,
29334 and <tt>MoveConstructible</tt> concepts should be clarified.
29335Furthermore, since the use of <tt>auto_ptr</tt> is depreciated anyway,
29336 we can also omit a description of its intended use.
29337</p>
29338
29339<p><i>[
29340Batavia (2009-05):
29341]</i></p>
29342
29343<blockquote>
29344We agree with the intent of the proposed resolution.
29345Move to NAD Editorial.
29346</blockquote>
29347
29348
29349<p><b>Proposed resolution:</b></p>
29350<p>
29351Change D.10.1 [auto.ptr], paragraph 3:
29352</p>
29353
29354<blockquote>
29355The <tt>auto_ptr</tt> provides a semantics of strict ownership. An
29356<tt>auto_ptr</tt> owns the ob ject it holds a pointer to. Copying an
29357<tt>auto_ptr</tt> copies the pointer and transfers ownership to the
29358destination. If more than one <tt>auto_ptr</tt> owns the same ob ject at
29359the same time the behavior of the program is undefined. [<i>Note:</i>
29360The uses of <tt>auto_ptr</tt> include providing temporary
29361exception-safety for dynamically allocated memory, passing ownership of
29362dynamically allocated memory to a function, and returning dynamically
29363allocated memory from a function.
29364<del><tt>auto_ptr</tt> does not meet the
29365<tt>CopyConstructible</tt> and <tt>Assignable</tt> requirements for
29366standard library container elements and thus instantiating a standard
29367library container with an <tt>auto_ptr</tt> results in undefined
29368behavior.</del>
29369
29370<ins>Instances of <tt>auto_ptr</tt> shall
29371meet the <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>
29372requirements, but do not meet the <tt>CopyConstructible</tt> and
29373<tt>CopyAssignable</tt> requirements.</ins>
29374-- <i>end note</i>]
29375</blockquote>
29376
29377
29378
29379
29380
29381<hr>
29382<h3><a name="976"></a>976. Class template std::stack should be movable</h3>
29383<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#NAD%20Editorial">NAD Editorial</a>
29384 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-02-01  <b>Last modified:</b> 2009-10-20</p>
29385<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
29386<p><b>Discussion:</b></p>
29387<p>
29388The synopsis given in 23.3.5.3.1 [stack.defn] does not show up
29389</p>
29390
29391<blockquote><pre>requires MoveConstructible&lt;Cont&gt; stack(stack&amp;&amp;);
29392requires MoveAssignable&lt;Cont&gt; stack&amp; operator=(stack&amp;&amp;);
29393</pre></blockquote>
29394
29395<p>
29396although the other container adaptors do provide corresponding
29397members.
29398</p>
29399
29400<p><i>[
29401Batavia (2009-05):
29402]</i></p>
29403
29404<blockquote>
29405<p>
29406We agree with the proposed resolution.
29407</p>
29408<p>
29409Move to Tentatively Ready.
29410</p>
29411</blockquote>
29412
29413<p><i>[
294142009-07 Frankfurt
29415]</i></p>
29416
29417
29418<blockquote>
29419Moved from Tentatively Ready to Open only because the wording needs to be
29420tweaked for concepts removal.
29421</blockquote>
29422
29423<p><i>[
294242009-08-18 Daniel updates the wording and Howard sets to Review.
29425]</i></p>
29426
29427
29428<p><i>[
294292009-08-23 Howard adds:
29430]</i></p>
29431
29432
29433<blockquote>
29434<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1194">1194</a> also adds these move members using an editorially different
29435style.
29436</blockquote>
29437
29438<p><i>[
294392009-10 Santa Cruz:
29440]</i></p>
29441
29442
29443<blockquote>
29444Mark NAD Editorial, solved by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1194">1194</a>.
29445</blockquote>
29446
29447
29448
29449<p><b>Proposed resolution:</b></p>
29450<p>
29451In the class stack synopsis of 23.3.5.3.1 [stack.defn] insert:
29452</p>
29453
29454<blockquote><pre>template &lt;class T, class Container = deque&lt;T&gt; &gt;
29455class stack {
29456  [..]
29457  explicit stack(const Container&amp;);
29458  explicit stack(Container&amp;&amp; = Container());
29459  <ins>stack(stack&amp;&amp; s) : c(std::move(s.c)) {}</ins>
29460  <ins>stack&amp; operator=(stack&amp;&amp; s) { c = std::move(s.c); return *this; }</ins>
29461  [..]
29462};
29463</pre></blockquote>
29464
29465
29466
29467
29468
29469
29470
29471
29472<hr>
29473<h3><a name="977"></a>977. insert iterators inefficient for expensive to move types</h3>
29474<p><b>Section:</b> 24.5.2 [insert.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
29475 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-02  <b>Last modified:</b> 2009-10-26</p>
29476<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>
29477<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
29478<p><b>Discussion:</b></p>
29479<p>
29480The new concepts for the insert iterators mandate an extra copy when
29481inserting an lvalue:
29482</p>
29483
29484<blockquote><pre>requires CopyConstructible&lt;Cont::value_type&gt;
29485  back_insert_iterator&lt;Cont&gt;&amp; 
29486  operator=(const Cont::value_type&amp; value);
29487</pre>
29488<blockquote>
29489-1- <i>Effects:</i> <tt>push_back(*container, <b>Cont::value_type(</b>value<b>)</b>);</tt>
29490</blockquote>
29491</blockquote>
29492
29493<p>
29494The reason is to convert <tt>value</tt> into an rvalue because the current
29495<tt>BackInsertionContainer</tt> concept only handles <tt>push_back</tt>-ing
29496rvalues:
29497</p>
29498
29499<blockquote><pre>concept BackInsertionContainer&lt;typename C&gt; : Container&lt;C&gt; { 
29500  void push_back(C&amp;, value_type&amp;&amp;); 
29501}
29502</pre></blockquote>
29503
29504<p>
29505Without the conversion of <tt>value</tt> to an rvalue, the assignment operator
29506fails to concept check.
29507</p>
29508
29509<p>
29510A solution is to modify the <tt>BackInsertionContainer</tt> concept so that
29511the client can pass in the parameter type for <tt>push_back</tt> similar to
29512what is already done for the <tt>OutputIterator</tt> concept:
29513</p>
29514
29515<blockquote><pre>concept BackInsertionContainer&lt;typename C, typename Value = C::value_type&amp;&amp;&gt;
29516  : Container&lt;C&gt; { 
29517     void push_back(C&amp;, Value); 
29518}
29519</pre></blockquote>
29520
29521<p>
29522This allows the assignment operator to be adjusted appropriately:
29523</p>
29524
29525<blockquote><pre>requires BackInsertionContainer&lt;Cont, Cont::value_type const&amp;&gt; &amp;&amp;
29526         CopyConstructible&lt;Cont::value_type&gt;
29527  back_insert_iterator&lt;Cont&gt;&amp; 
29528  operator=(const Cont::value_type&amp; value);
29529</pre>
29530<blockquote>
29531-1- <i>Effects:</i> <tt>push_back(*container, value);</tt>
29532</blockquote>
29533</blockquote>
29534
29535<p><i>[
29536We may want to propagate this fix to other concepts such as <tt>StackLikeContainer</tt>.
29537]</i></p>
29538
29539
29540<p><i>[
29541Solution and wording collaborated on by Doug and Howard.
29542]</i></p>
29543
29544
29545<p><i>[
29546Batavia (2009-05):
29547]</i></p>
29548
29549<blockquote>
29550<p>
29551Howard notes that "these operations behaved efficiently until concepts were added."
29552</p>
29553<p>
29554Alisdair is uncertain that the proposed resolution is syntactically correct.
29555</p>
29556<p>
29557Move to Open, and recommend the issue be deferred until after the next
29558Committee Draft is issued.
29559</p>
29560</blockquote>
29561
29562<p><i>[
295632009-10 Santa Cruz:
29564]</i></p>
29565
29566
29567<blockquote>
29568NAD, solved by the removal of concepts.
29569</blockquote>
29570
29571
29572
29573<p><b>Proposed resolution:</b></p>
29574<p>
29575Change  [container.concepts.free]:
29576</p>
29577
29578<blockquote>
29579<pre>concept FrontInsertionContainer&lt;typename C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt;
29580    : Container&lt;C&gt; { 
29581  void push_front(C&amp;, <del>value_type&amp;&amp;</del> <ins>Value</ins>); 
29582
29583  axiom FrontInsertion(C c, <del>value_type</del> <ins>Value</ins> x) { 
29584    x == (push_front(c, x), front(c)); 
29585  } 
29586}
29587</pre>
29588
29589<p>...</p>
29590
29591<pre>concept BackInsertionContainer&lt;typename C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt;
29592    : Container&lt;C&gt; { 
29593  void push_back(C&amp;, <del>value_type&amp;&amp;</del> <ins>Value</ins>); 
29594}
29595</pre>
29596
29597<p>...</p>
29598
29599<pre>concept InsertionContainer&lt;typename C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt;
29600    : Container&lt;C&gt; { 
29601  iterator insert(C&amp;, const_iterator, <del>value_type&amp;&amp;</del> <ins>Value</ins>); 
29602
29603  axiom Insertion(C c, const_iterator position, <del>value_type</del> <ins>Value</ins> v) { 
29604    v == *insert(c, position, v); 
29605  } 
29606}
29607</pre>
29608
29609</blockquote>
29610
29611<p>
29612Change  [container.concepts.member]:
29613</p>
29614
29615<blockquote>
29616<pre>auto concept MemberFrontInsertionContainer&lt;typename C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt;
29617    : MemberContainer&lt;C&gt; { 
29618  void C::push_front(<del>value_type&amp;&amp;</del> <ins>Value</ins>); 
29619
29620  axiom MemberFrontInsertion(C c, <del>value_type</del> <ins>Value</ins> x) { 
29621    x == (c.push_front(x), c.front()); 
29622  } 
29623}
29624</pre>
29625
29626<p>...</p>
29627
29628<pre>auto concept MemberBackInsertionContainer&lt;typename C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt;
29629    : MemberContainer&lt;C&gt; { 
29630  void C::push_back(<del>value_type&amp;&amp;</del> <ins>Value</ins>); 
29631}
29632</pre>
29633
29634<p>...</p>
29635
29636<pre>auto concept MemberInsertionContainer&lt;typename C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt;
29637    : MemberContainer&lt;C&gt; { 
29638  iterator C::insert(const_iterator, <del>value_type&amp;&amp;</del> <ins>Value</ins>); 
29639
29640  axiom MemberInsertion(C c, const_iterator position, <del>value_type</del> <ins>Value</ins> v) { 
29641    v == *c.insert(position, v); 
29642  } 
29643}
29644</pre>
29645</blockquote>
29646
29647<p>
29648Change  [container.concepts.maps]:
29649</p>
29650
29651<blockquote>
29652<pre>template &lt;MemberFrontInsertionContainer C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt; 
29653concept_map FrontInsertionContainer&lt;C<ins>, Value</ins>&gt; { 
29654  typedef Container&lt;C&gt;::value_type value_type;
29655
29656  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)); } 
29657}
29658</pre>
29659
29660<p>...</p>
29661
29662<pre>template &lt;MemberBackInsertionContainer C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt; 
29663concept_map BackInsertionContainer&lt;C<ins>, Value</ins>&gt; { 
29664  typedef Container&lt;C&gt;::value_type value_type;
29665
29666  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)); } 
29667}
29668</pre>
29669
29670<p>...</p>
29671
29672<pre>template &lt;MemberInsertionContainer C<ins>, typename Value = C::value_type&amp;&amp;</ins>&gt; 
29673concept_map InsertionContainer&lt;C<ins>, Value</ins>&gt; { 
29674  typedef Container&lt;C&gt;::value_type value_type;
29675  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) 
29676  { return c.insert(i, static_cast&lt;<del>value_type&amp;&amp;</del> <ins>Value</ins>&gt;(v)); } 
29677}
29678</pre>
29679
29680</blockquote>
29681
29682<p>
29683Change 24.5.2.1 [back.insert.iterator]:
29684</p>
29685
29686<blockquote><pre>template &lt;BackInsertionContainer Cont&gt; 
29687class back_insert_iterator {
29688  ...
29689  requires <ins>BackInsertionContainer&lt;Cont, const Cont::value_type&amp;&gt;</ins>
29690           <del>CopyConstructible&lt;Cont::value_type&gt;</del>
29691    back_insert_iterator&lt;Cont&gt;&amp; 
29692      operator=(const Cont::value_type&amp; value);
29693  ...
29694</pre></blockquote>
29695
29696<p>
29697Change 24.5.2.2.2 [back.insert.iter.op=]:
29698</p>
29699
29700<blockquote>
29701<pre>requires <ins>BackInsertionContainer&lt;Cont, const Cont::value_type&amp;&gt;</ins>
29702         <del>CopyConstructible&lt;Cont::value_type&gt;</del>
29703  back_insert_iterator&lt;Cont&gt;&amp; 
29704    operator=(const Cont::value_type&amp; value);
29705</pre>
29706<blockquote>
29707-1- <i>Effects:</i> <tt>push_back(*container, <del>Cont::value_type(</del>value<del>)</del>);</tt>
29708</blockquote>
29709</blockquote>
29710
29711<p>
29712Change 24.5.2.3 [front.insert.iterator]:
29713</p>
29714
29715<blockquote><pre>template &lt;FrontInsertionContainer Cont&gt; 
29716class front_insert_iterator {
29717  ...
29718  requires <ins>FrontInsertionContainer&lt;Cont, const Cont::value_type&amp;&gt;</ins>
29719           <del>CopyConstructible&lt;Cont::value_type&gt;</del>
29720    front_insert_iterator&lt;Cont&gt;&amp; 
29721      operator=(const Cont::value_type&amp; value);
29722  ...
29723</pre></blockquote>
29724
29725<p>
29726Change 24.5.2.4.2 [front.insert.iter.op=]:
29727</p>
29728
29729<blockquote>
29730<pre>requires <ins>FrontInsertionContainer&lt;Cont, const Cont::value_type&amp;&gt;</ins>
29731         <del>CopyConstructible&lt;Cont::value_type&gt;</del>
29732  front_insert_iterator&lt;Cont&gt;&amp; 
29733    operator=(const Cont::value_type&amp; value);
29734</pre>
29735<blockquote>
29736-1- <i>Effects:</i> <tt>push_front(*container, <del>Cont::value_type(</del>value<del>)</del>);</tt>
29737</blockquote>
29738</blockquote>
29739
29740<p>
29741Change 24.5.2.5 [insert.iterator]:
29742</p>
29743
29744<blockquote><pre>template &lt;InsertionContainer Cont&gt; 
29745class insert_iterator {
29746  ...
29747  requires <ins>InsertionContainer&lt;Cont, const Cont::value_type&amp;&gt;</ins>
29748           <del>CopyConstructible&lt;Cont::value_type&gt;</del>
29749    insert_iterator&lt;Cont&gt;&amp; 
29750      operator=(const Cont::value_type&amp; value);
29751  ...
29752</pre></blockquote>
29753
29754<p>
29755Change 24.5.2.6.2 [insert.iter.op=]:
29756</p>
29757
29758<blockquote>
29759<pre>requires <ins>InsertionContainer&lt;Cont, const Cont::value_type&amp;&gt;</ins>
29760         <del>CopyConstructible&lt;Cont::value_type&gt;</del>
29761  insert_iterator&lt;Cont&gt;&amp; 
29762    operator=(const Cont::value_type&amp; value);
29763</pre>
29764<blockquote>
29765<p>
29766-1- <i>Effects:</i>
29767</p>
29768<blockquote><pre>iter = insert(*container, iter, <del>Cont::value_type(</del>value<del>)</del>); 
29769++iter;
29770</pre></blockquote>
29771</blockquote>
29772</blockquote>
29773
29774
29775
29776
29777
29778
29779<hr>
29780<h3><a name="979"></a>979. Bad example</h3>
29781<p><b>Section:</b> 24.5.3 [move.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
29782 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-02-03  <b>Last modified:</b> 2009-07-13</p>
29783<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
29784<p><b>Discussion:</b></p>
29785<p>
2978624.5.3 [move.iterators] has an incorrect example:
29787</p>
29788
29789<blockquote>
29790<p>
29791-2- [<i>Example:</i>
29792</p>
29793
29794<blockquote><pre>set&lt;string&gt; s; 
29795// populate the set s 
29796vector&lt;string&gt; v1(s.begin(), s.end());          // copies strings into v1 
29797vector&lt;string&gt; v2(make_move_iterator(s.begin()), 
29798                  make_move_iterator(s.end())); // moves strings into v2
29799</pre></blockquote>
29800
29801<p>
29802<i>-- end example</i>]
29803</p>
29804</blockquote>
29805
29806<p>
29807One can not move from a <tt>set</tt> because the iterators return <tt>const</tt>
29808references.
29809</p>
29810
29811<p><i>[
29812Batavia (2009-05):
29813]</i></p>
29814
29815<blockquote>
29816We agree with the proposed resolution. Move to NAD Editorial.
29817</blockquote>
29818
29819
29820
29821<p><b>Proposed resolution:</b></p>
29822<p>
29823Change 24.5.3 [move.iterators]/2:
29824</p>
29825
29826<blockquote>
29827<p>
29828-2- [<i>Example:</i>
29829</p>
29830
29831<blockquote><pre><del>set</del><ins>list</ins>&lt;string&gt; s; 
29832// populate the <del>set</del><ins>list</ins> s 
29833vector&lt;string&gt; v1(s.begin(), s.end());          // copies strings into v1 
29834vector&lt;string&gt; v2(make_move_iterator(s.begin()), 
29835                  make_move_iterator(s.end())); // moves strings into v2
29836</pre></blockquote>
29837
29838<p>
29839<i>-- end example</i>]
29840</p>
29841</blockquote>
29842
29843
29844
29845
29846
29847<hr>
29848<h3><a name="980"></a>980. <tt>mutex lock()</tt> missing error conditions</h3>
29849<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#NAD">NAD</a>
29850 <b>Submitter:</b> Ion Gazta�aga <b>Opened:</b> 2009-02-07  <b>Last modified:</b> 2009-03-22</p>
29851<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>
29852<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>
29853<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
29854<p><b>Discussion:</b></p>
29855<p>
29856POSIX 2008 adds two return values for <tt>pthread_mutex_xxxlock()</tt>:
29857<tt>EOWNERDEAD</tt> (<tt>owner_dead</tt>) and <tt>ENOTRECOVERABLE</tt>
29858(<tt>state_not_recoverable</tt>). In the first case the mutex is locked,
29859in the second case the mutex is not locked.
29860</p>
29861
29862<p>
29863Throwing an exception in the first case can be incompatible with the use
29864of Locks, since the <tt>Lock::owns_lock()</tt> will be <tt>false</tt> when the lock is
29865being destroyed.
29866</p>
29867
29868<p>
29869Consider:
29870</p>
29871
29872<blockquote><pre>//Suppose mutex.lock() throws "owner_dead"
29873unique_lock ul(&amp;mutex);
29874//mutex left locked if "owner_dead" is thrown
29875</pre></blockquote>
29876
29877<p>
29878Throwing an exception with <tt>owner_dead</tt> might be also undesirable if
29879robust-mutex support is added to C++ and the user has the equivalent of
29880<tt>pthread_mutex_consistent()</tt> to notify the user has fixed the corrupted
29881data and the mutex state should be marked consistent.
29882</p>
29883
29884<ol>
29885<li>
29886For <tt>state_not_recoverable</tt> add it to the list of Error conditions:
29887</li>
29888<li>
29889For <tt>owner_dead</tt>, no proposed resolution.
29890</li>
29891</ol>
29892
29893<p><i>[
29894Summit:
29895]</i></p>
29896
29897
29898<blockquote>
29899Not a defect. Handling these error conditions is an implementation
29900detail and must be handled below the C++ interface.
29901</blockquote>
29902
29903
29904
29905<p><b>Proposed resolution:</b></p>
29906
29907<p>
29908Add to 30.4.1 [thread.mutex.requirements], p12:
29909</p>
29910
29911<blockquote>
29912<p>
29913-12- <i>Error conditions:</i>
29914</p>
29915
29916<ul>
29917<li>
29918<tt>operation_not_permitted</tt> -- if the thread does not have the necessary permission to change 
29919the state of the mutex.
29920</li>
29921<li>
29922<tt>resource_deadlock_would_occur</tt> -- if the current thread already owns the mutex and is able 
29923to detect it.
29924</li>
29925<li>
29926<tt>device_or_resource_busy</tt> --  if the mutex is already locked and blocking is not possible.
29927</li>
29928<li>
29929<ins><tt>state_not_recoverable</tt> -- if the state protected by the mutex is not recoverable.</ins>
29930</li>
29931</ul>
29932</blockquote>
29933
29934
29935
29936
29937
29938<hr>
29939<h3><a name="988"></a>988. <tt>Reflexivity</tt> meaningless?</h3>
29940<p><b>Section:</b> X [concept.comparison] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
29941 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-02-24  <b>Last modified:</b> 2009-07-16</p>
29942<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#concept.comparison">issues</a> in [concept.comparison].</p>
29943<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
29944<p><b>Discussion:</b></p>
29945<p>
29946X [concept.comparison] p2:
29947</p>
29948<p>
29949Due to the subtle meaning of <tt>==</tt> inside axioms, the <tt>Reflexivity</tt> axiom does
29950not do anything as written. It merely states that a value is substitutable
29951with itself, rather than asserting a property of the <tt>==</tt> operator.
29952</p>
29953
29954<b>
29955Original proposed resolution:
29956</b>
29957
29958<p>
29959Change the definition of <tt>Reflexivity</tt> in X [concept.comparison]:
29960</p>
29961
29962<blockquote><pre>axiom Reflexivity(T a) { <ins>(</ins>a == a<ins>) == true</ins>; }
29963</pre></blockquote>
29964
29965<p><i>[
29966Post Summit:
29967]</i></p>
29968
29969
29970<blockquote>
29971<p>
29972Alisdair: I was wrong.
29973</p>
29974<p>
29975Recommend NAD.
29976</p>
29977</blockquote>
29978
29979
29980
29981<p><b>Proposed resolution:</b></p>
29982<p>
29983NAD.
29984</p>
29985
29986
29987
29988
29989
29990<hr>
29991<h3><a name="989"></a>989. late_check and library</h3>
29992<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
29993 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-02-24  <b>Last modified:</b> 2009-07-16</p>
29994<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>
29995<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>
29996<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
29997<p><b>Discussion:</b></p>
29998<p>
29999The example in 6.9p2 shows how late_check blocks inhibit concept_map lookup
30000inside a constrained context, and so inhibit concept map adaption by users
30001to meet template requirements.
30002</p>
30003<p>
30004Do we need some text in clause 17 prohibitting use of late_check in library
30005template definitions unless otherwise documented?
30006</p>
30007
30008<p><i>[
30009Doug adds:
30010]</i></p>
30011
30012
30013<blockquote>
30014We need something like this, but it should be a more general statement
30015about implementations respecting the concept maps provided by the
30016user. Use of late_check is one way in which implementations can
30017subvert the concept maps provided by the user, but there are other
30018ways as well ("pattern-based" overloading, tricks with "auto" concept
30019maps and defaulted associated type arguments).
30020</blockquote>
30021
30022<p><i>[
30023Batavia (2009-05):
30024]</i></p>
30025
30026<blockquote>
30027Move to Open, pending proposed wording from Alisdair and/or Doug for further review.
30028</blockquote>
30029
30030
30031<p><b>Proposed resolution:</b></p>
30032
30033
30034
30035
30036
30037<hr>
30038<h3><a name="992"></a>992. Response to UK 169</h3>
30039<p><b>Section:</b> 17.6.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
30040 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2009-03-03  <b>Last modified:</b> 2009-07-22</p>
30041<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#contents">issues</a> in [contents].</p>
30042<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
30043<p><b>Discussion:</b></p>
30044<p><b>Addresses UK 169</b></p>
30045<p>
30046This phrasing contradicts later freedom to implement the C standard
30047library portions in the global namespace as well as std. (17.6.2.3p4)
30048</p>
30049
30050<p><i>[
30051Batavia (2009-05):
30052]</i></p>
30053
30054<blockquote>
30055The proposed wording seems to go too far.
30056Move back to Open.
30057</blockquote>
30058
30059<p><i>[
300602009-07 Frankfurt:
30061]</i></p>
30062
30063
30064<blockquote>
30065<p>
30066Howard to add NB reference to the description of this issue.
30067</p>
30068<p>
30069Move to NAD. This comment is informative and not normative by the use of
30070the word "are" instead of the word "shall."
30071</p>
30072<p>
30073A note linking to Annex D would help clarify the intention, here.
30074</p>
30075<p>
30076Robert to Open a separate issue proposing that the standard C headers be
30077undeprecated, for the purpose of clarifying the standard.
30078</p>
30079</blockquote>
30080
30081<p><i>[
300822009-07-22 Bill modified the proposed wording with a clarifying footnote.
30083]</i></p>
30084
30085
30086
30087
30088<p><b>Proposed resolution:</b></p>
30089<p>
30090Add a footnote to 17.6.1.1 [contents], p2:
30091</p>
30092
30093<blockquote>
30094<p>
30095-2- All library entities except macros, <tt>operator new</tt> and <tt>operator
30096delete</tt> are defined within the namespace <tt>std</tt> or namespaces
30097nested within namespace <tt>std</tt><ins><sup>*</sup></ins>.
30098</p>
30099
30100<p><ins>
30101<sup>*</sup>The C standard library headers D.6 [depr.c.headers] also define
30102names within the global namespace, while the C++ headers for
30103C library facilities 17.6.1.2 [headers] may also define names within
30104the global namespace.
30105</ins></p>
30106</blockquote>
30107
30108
30109
30110
30111
30112
30113<hr>
30114<h3><a name="995"></a>995. Operational Semantics Unclear</h3>
30115<p><b>Section:</b> 17.5.1.3 [structure.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
30116 <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-03-06  <b>Last modified:</b> 2009-07-13</p>
30117<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
30118<p><b>Discussion:</b></p>
30119<p>
30120As a practical matter there's disagreement on the meaning of <i>operational
30121semantics</i>.  If the text in 17.5.1.3 [structure.requirements]p4 isn't
30122clear, it should be clarified.  However, it's not clear whether the
30123disagreement is merely due to people not being aware of the text.
30124</p>
30125
30126<p><i>[
30127Batavia (2009-05):
30128]</i></p>
30129
30130<blockquote>
30131Agree with the recommended NAD resolution.
30132</blockquote>
30133
30134
30135<p><b>Proposed resolution:</b></p>
30136<p>
30137Recommend NAD.  The text in 17.5.1.3 [structure.requirements] is
30138perfectly clear.
30139</p>
30140
30141
30142
30143
30144
30145<hr>
30146<h3><a name="1000"></a>1000. adjacent_find is over-constrained</h3>
30147<p><b>Section:</b> 25.2.8 [alg.adjacent.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
30148 <b>Submitter:</b> Chris Jefferson <b>Opened:</b> 2009-03-09  <b>Last modified:</b> 2009-07-15</p>
30149<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.adjacent.find">issues</a> in [alg.adjacent.find].</p>
30150<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
30151<p><b>Discussion:</b></p>
30152<p>
30153<b>Addresses UK 296</b>
30154</p>
30155
30156<p>
30157<tt>adjacent_find</tt> in C++03 allows an arbitrary predicate, but in C++0x
30158<tt>EqualityComparable/EquivalenceRelation</tt> is required. This forbids a
30159number of use cases, including:
30160</p>
30161<blockquote>
30162<table>
30163<tbody><tr>
30164<td valign="top">
30165<tt>adjacent_find(begin,&nbsp;end,&nbsp;less&lt;double&gt;)</tt>
30166</td>
30167<td>
30168Find the first
30169place where a range is not ordered in decreasing order - in use to check
30170for sorted ranges.
30171</td>
30172</tr>
30173<tr>
30174<td valign="top">
30175<tt>adjacent_find(begin,&nbsp;end,&nbsp;DistanceBiggerThan(6)&nbsp;)&nbsp;)</tt>
30176</td>
30177<td>
30178Find the first
30179place in a range where values differ by more than a given value - in use
30180to check an algorithm which produces points in space does not generate
30181points too far apart.
30182</td>
30183</tr>
30184</tbody></table>
30185</blockquote>
30186
30187<p>
30188A number of books use predicate which are not equivalence relations in
30189examples, including "Thinking in C++" and "C++ Primer".
30190</p>
30191
30192<p>
30193Adding the requirement that the predicate is an <tt>EquivalenceRelation</tt>
30194does not appear to open up any possibility for a more optimised algorithm.
30195</p>
30196
30197
30198
30199<p><b>Proposed resolution:</b></p>
30200<p>
30201Change the definition of adjacent_find in the synopsis of 25 [algorithms]
30202and 25.2.8 [alg.adjacent.find] to:
30203</p>
30204
30205<blockquote><pre>template&lt;ForwardIterator Iter&gt; 
30206  requires <del>EqualityComparable</del><ins>HasEqualTo</ins>&lt;Iter::value_type<ins>, Iter::value_type</ins>&gt;
30207  Iter adjacent_find(Iter first, Iter last);
30208
30209template&lt;ForwardIterator Iter, <del>EquivalenceRelation</del><ins>Predicate</ins>&lt;auto, Iter::value_type<ins>, Iter::value_type</ins>&gt; Pred&gt; 
30210  requires CopyConstructible&lt;Pred&gt; 
30211  Iter adjacent_find(Iter first, Iter last, Pred pred);
30212</pre></blockquote>
30213
30214
30215
30216
30217
30218<hr>
30219<h3><a name="1001"></a>1001. Pointers, concepts and headers</h3>
30220<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
30221 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-10  <b>Last modified:</b> 2009-07-18</p>
30222<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>
30223<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>
30224<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
30225<p><b>Discussion:</b></p>
30226
30227<p><b>Addresses UK 78</b></p>
30228
30229<p>
30230Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1063">1063</a>.
30231</p>
30232
30233<p>
30234This is effectively an extension of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#343">343</a>.
30235</p>
30236<p>
30237We know there is an increasing trend (encouraged by conformance testers and
30238some users) that each library header should supply no more than required to
30239satisfy the synopsis in the standard.  This is typically achieved by
30240breaking larger headers into smaller subsets, and judicious use of forward
30241declarations.
30242</p>
30243<p>
30244If we apply this policy to C++0x (per
30245<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf">N2800</a>)
30246it will be very surprising for
30247people using library algorithms over ranges defined by pointers that they
30248must <tt>#include &lt;iterator_concepts&gt;</tt> for their code to compile again.  That is
30249because pointers do not satisfy any of the iterator concepts without the
30250<tt>concept_map</tt> supplied in this header.
30251</p>
30252<p>
30253Therefore, I suggest we should require all library headers that make use of
30254iterator concepts are specifically required to <tt>#include &lt;iterator_concepts&gt;</tt>.
30255</p>
30256<p>
30257At a minimum, the list of headers would be: (assuming all are constrained by
30258concepts)
30259</p>
30260<blockquote><pre>algorithm
30261array
30262deque
30263forward_list
30264initializer_list
30265iterator
30266locale
30267list
30268map
30269memory          // if <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1029">1029</a> is adopted
30270memory_concepts
30271numeric
30272random
30273regex
30274set
30275string
30276tuple
30277unordered_map
30278unordered_set
30279utility
30280vector
30281</pre></blockquote>
30282
30283<p><i>[
30284Ganesh adds:
30285]</i></p>
30286
30287
30288<blockquote>
30289<p>
30290The same problems exists for <tt>&lt;memory_concepts&gt;</tt> and
30291<tt>&lt;container_concepts&gt;</tt>.
30292</p>
30293<p>
30294In order to compile <tt>&lt;vector&gt;</tt> you just need the
30295definitions of the concepts in <tt>&lt;memory_concepts&gt;</tt>, the
30296concept maps defined there are not necessary. Yet, from the user point
30297of view, if the concept map template for <tt>AllocatableElement</tt> are
30298not in scope, <tt>&lt;vector&gt;</tt> is pretty useless. Same for
30299<tt>&lt;tuple&gt;</tt> and <tt>ConstructibleWithAllocator</tt>.
30300</p>
30301<p>
30302Similarly, <tt>&lt;queue&gt;</tt> is not very useful if the concept map
30303template for <tt>QueueLikeContainer</tt> is not in scope, although the
30304definition of concept alone is theoretically sufficient.
30305</p>
30306<p>
30307There's a pattern here: if a concept has concept maps "attached", they
30308should never be separated.
30309</p>
30310</blockquote>
30311
30312<p><i>[
30313Beman provided the proposed resolution for the May 2009 mailing. He 
30314comments:
30315]</i></p>
30316
30317
30318<blockquote>
30319
30320<p>Initially I tried to specify exactly what header should include what other 
30321headers. This was verbose, error prone, hard to maintain, and appeared to add 
30322little value compared to just stating the general rule.</p>
30323
30324</blockquote>
30325
30326<p><i>[
30327Batavia (2009-05):
30328]</i></p>
30329
30330<blockquote>
30331<p>
30332Pete believes the proposed wording overconstrains implementers.
30333Instead of specifying the mechanism,
30334he prefers a solution that spells out what needs to be declared,
30335rather than how those declarations are to be provided,
30336e.g.,
30337</p>
30338<blockquote>
30339A C++ header shall provide the names
30340that are required to be defined in that header.
30341</blockquote>
30342<p>
30343Bill suggests approaching the wording from a programmer's perspective.
30344We may want to consider promising that certain widely-used headers
30345(e.g., the concept headers) are included when needed by other headers.
30346He feels, however, there is nothing broken now,
30347although we may want to consider "something nicer."
30348</p>
30349<p>
30350Move to Open status.
30351</p>
30352
30353</blockquote>
30354
30355<p><i>[
303562009-06-16 Beman updated the proposed resolution:
30357]</i></p>
30358
30359
30360<blockquote>
30361  <ul>
30362    <li>The mechanism is no longer specified, as requested in Batavia.</li>
30363    <li>The footnote has been removed since it specified mechanism and also did 
30364    not reflect existing practice.</li>
30365    <li>A sentence was added that makes it clear that the existing practice is 
30366    permitted.</li>
30367  </ul>
30368</blockquote>
30369
30370<p><i>[
303712009-07-15 Beman updated the proposed resolution:
30372]</i></p>
30373
30374
30375<p><i>[
303762009-07-17 Beman updated the proposed resolution based on feedback from the LWG in Frankfurt:
30377]</i></p>
30378
30379
30380<blockquote>
30381<ul>
30382<li>Strike two pieces of text considered unnecessary.</li>
30383<li>Change "definitions" to "declarations and definitions" in two places.</li>
30384<li>Wording tightened slightly.</li>
30385</ul>
30386</blockquote>
30387
30388<p><i>[
303892009-07 Frankfurt:
30390]</i></p>
30391
30392
30393<blockquote>
30394<p>
30395Revised Proposed Resolution:
30396</p>
30397<p>
30398A C++ header may include other C++ headers. A C++ header shall provide
30399the declarations and definitions that appear in its synopsis (3.2
30400[basic.def.odr]). A C++ header shown in its synopsis as including other
30401C++ headers shall provide the declarations and definitions that appear
30402in the synopses of those other headers.
30403</p>
30404<p>
30405Alisdair: Does this address the BSI comment?
30406</p>
30407<p>
30408Beman: There were several overlapping comments. I tried to handle them
30409all with one resolution.
30410</p>
30411<p>
30412Alisdair: I'd prefer to see this closed as NAD and have this resolution
30413be the subject of some other, new issue.
30414</p>
30415<p>
30416Move to NAD Concepts. Howard to open a new issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1178">1178</a>) in Ready state with the
30417Proposed Resolution above. Beman will write up a discussion for the new
30418issue.
30419</p>
30420</blockquote>
30421
30422
30423
30424<p><b>Proposed resolution:</b></p>
30425<p><i>Change 17.6.4.2 [res.on.headers], Headers, paragraph 1, as indicated:</i></p>
30426
30427<blockquote>
30428
30429<p>
30430A C++ header may include other C++
30431headers.<del><sup>[footnote]</sup></del> <ins>A C++ header shall provide
30432the declarations and definitions that appear in its synopsis
30433(3.2 [basic.def.odr]). A C++ header shown in its synopsis as including 
30434other C++ headers shall provide the same declarations and definitions as
30435if those other headers were included.</ins>
30436</p>
30437
30438  <p><del><sup>[footnote]</sup> C++ headers must include a C++ header that contains 
30439  any needed definition (3.2).</del></p>
30440</blockquote>
30441
30442
30443
30444
30445
30446
30447<hr>
30448<h3><a name="1002"></a>1002. Response to UK 170</h3>
30449<p><b>Section:</b> 17.6.1.2 [headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
30450 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-15</p>
30451<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#headers">issues</a> in [headers].</p>
30452<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
30453<p><b>Discussion:</b></p>
30454
30455<p><b>Addresses UK 170</b></p>
30456
30457<p>
30458One of goals of C++0x is to make language easier to teach and for
30459'incidental' programmers. The fine-grained headers of the C++ library
30460are valuable in large scale systems for managing dependencies and
30461optimising build times, but overcomplicated for simple development and
30462tutorials. Add additional headers to support the whole library through a
30463single include statement.
30464</p>
30465
30466<p><i>[
30467Batavia (2009-05):
30468]</i></p>
30469
30470<blockquote>
30471We do not all agree that this is an issue,
30472but we agree that if it needs solving this is the right way to do it.
30473Move to Tentatively Ready.
30474</blockquote>
30475
30476<p><i>[
304772009-07-06 Beman notes:
30478]</i></p>
30479
30480
30481<blockquote>
30482<p>
30483This issue
30484adds a header <tt>&lt;std&gt;</tt>.
30485</p>
30486<p>
30487There is a paper to be looked at,
30488<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2905.pdf">N2905</a>
30489Aggregation headers, that adds
30490a header <tt>&lt;std-all&gt;</tt> that is the same thing except it excludes
30491deprecated headers.
30492<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2905.pdf">N2905</a>
30493also proposes a second aggregation header.
30494</p>
30495<p>
30496Seems like this issue should be held in abeyance until the LWG has had
30497a chance to look at <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2905.pdf">N2905</a>.
30498</p>
30499</blockquote>
30500
30501<p><i>[
305022009-07-06 Howard:  I've pulled this issue back to Review.
30503]</i></p>
30504
30505
30506<p><i>[
305072009-07 Frankfurt
30508]</i></p>
30509
30510
30511<blockquote>
30512No consensus for change.
30513</blockquote>
30514
30515
30516
30517<p><b>Proposed resolution:</b></p>
30518<p>
30519Insert a new paragraph in 17.6.1.2 [headers] between p4 and p5
30520</p>
30521<blockquote>
30522An additional header <tt>&lt;std&gt;</tt> shall have the effect of
30523supplying the entire standard library.  [<i>Note:</i> for example, it
30524might be implemented as a file with an <tt>#include</tt> statement for each of the
30525headers listed in tables 13 and 14. <i>-- end note</i>]
30526</blockquote>
30527
30528
30529
30530
30531
30532<hr>
30533<h3><a name="1003"></a>1003. Response to JP 23</h3>
30534<p><b>Section:</b> 17.6.1.3 [compliance] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
30535 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-18</p>
30536<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#compliance">issues</a> in [compliance].</p>
30537<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
30538<p><b>Discussion:</b></p>
30539
30540<p><b>Addresses JP 23</b></p>
30541
30542<p>
30543There is a freestanding implementation including
30544<tt>&lt;type_traits&gt;</tt>, <tt>&lt;array&gt;</tt>,
30545<tt>&lt;ratio&gt;</tt>, lately added to Table 13, C++ library headers.
30546Programmers think them useful and hope that these headers are also added
30547to Table 15, C++ headers for freestanding implementations, that shows
30548the set of headers which a freestanding implementation shall include at
30549least.
30550</p>
30551
30552<p><b>Original proposed resolution</b></p>
30553
30554<p>
30555Add <tt>&lt;type_traits&gt;</tt>, <tt>&lt;array&gt;</tt>,
30556<tt>&lt;ratio&gt;</tt> to Table 15.
30557</p>
30558
30559<p><i>[
30560Summit:
30561]</i></p>
30562
30563
30564<blockquote>
30565<p>
30566 The <tt>&lt;array&gt;</tt> header has far too many dependencies to require for a
30567free-standing implementation.
30568</p>
30569<p>
30570The <tt>&lt;ratio&gt;</tt> header would be useful, has no dependencies, but is not
30571strictly necessary.
30572</p>
30573<p>
30574The <tt>&lt;type_traits&gt;</tt> header is fundamentally a core language facility with a
30575library interface, so should be supported.
30576</p>
30577
30578<p>
30579(it is anticipated the resolution will come via an update to paper
30580<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2814.pdf">N2814</a>)
30581(see also LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#833">833</a>)
30582</p>
30583</blockquote>
30584
30585<p><i>[
30586Batavia (2009-05):
30587]</i></p>
30588
30589<blockquote>
30590Leave in Review status pending a paper on freestanding implementations
30591by Martin Tasker.
30592</blockquote>
30593
30594<p><i>[
305952009-07 Frankfurt:
30596]</i></p>
30597
30598
30599<blockquote>
30600<p>
30601Move this to NAD.
30602</p>
30603<p>
30604We considered all of the listed headers, and found a compelling case
30605only for the inclusion of <tt>&lt;type_traits&gt;</tt> in the list of headers required
30606of a freestanding implementation.
30607</p>
30608<p>
30609See Martin Tasker's paper 
30610<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2932.pdf">Fixing Freestanding</a>
30611which provides the wording to include <tt>&lt;type_traits&gt;</tt> into freestanding
30612implementations.
30613</p>
30614</blockquote>
30615
30616
30617
30618<p><b>Proposed resolution:</b></p>
30619<p>
30620Add <tt>&lt;type_traits&gt;</tt> to Table 15.
30621</p>
30622
30623
30624
30625
30626
30627
30628<hr>
30629<h3><a name="1005"></a>1005. <tt>numeric_limits</tt> partial specializations not concept enabled</h3>
30630<p><b>Section:</b> 18.3.1.1 [numeric.limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
30631 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-15</p>
30632<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
30633<p><b>Discussion:</b></p>
30634
30635<p><b>Addresses JP 26</b></p>
30636
30637<p>
30638<tt>numeric_limits</tt> [partial specializations] does not use concept.
30639</p>
30640
30641<p><i>[
30642Summit:
30643]</i></p>
30644
30645
30646<blockquote>
30647Alisdair will provide a soltion as part of treatment of axioms and LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#902">902</a>.
30648</blockquote>
30649
30650<p><i>[
30651Post Summit:
30652]</i></p>
30653
30654
30655<blockquote>
30656Alisdair recommends NAD as the partial specializations are already
30657constrained by requirements on the primary template.
30658</blockquote>
30659
30660<p><i>[
30661Batavia (2009-05):
30662]</i></p>
30663
30664<blockquote>
30665The Working Draft does not in general repeat a primary template's constraints
30666in any specializations.
30667Move to NAD.
30668</blockquote>
30669
30670<p><i>[
306712009-05-25 Howard adds:
30672]</i></p>
30673
30674
30675<blockquote>
30676A c++std-lib thread starting at c++std-lib-23880 has cast doubt that NAD is the
30677correct resolution of this issue.  Indeed the discussion also casts doubt that
30678the current proposed wording is the correct resolution as well.  Personally I'm
30679inclined to reset the status to Open.  However I'm reverting the status to 
30680that which it had prior to the Batavia recommendation.  I'm setting back to Review.
30681</blockquote>
30682
30683
30684<p><b>Proposed resolution:</b></p>
30685<p>
30686Change 18.3.1.1 [numeric.limits]:
30687</p>
30688
30689<blockquote><pre>template&lt;<del>class</del> <ins>Regular</ins> T&gt; class numeric_limits&lt;const T&gt;;
30690template&lt;<del>class</del> <ins>Regular</ins> T&gt; class numeric_limits&lt;volatile T&gt;;
30691template&lt;<del>class</del> <ins>Regular</ins> T&gt; class numeric_limits&lt;const volatile T&gt;;
30692</pre></blockquote>
30693
30694
30695
30696
30697
30698
30699<hr>
30700<h3><a name="1007"></a>1007. <tt>throw_with_nested</tt> not concept enabled</h3>
30701<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#NAD%20Concepts">NAD Concepts</a>
30702 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-15</p>
30703<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>
30704<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>
30705<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
30706<p><b>Discussion:</b></p>
30707
30708<p><b>Addresses JP 29</b></p>
30709
30710<p>
30711<tt>throw_with_nested</tt> does not use concept.
30712</p>
30713
30714<p><i>[
30715Summit:
30716]</i></p>
30717
30718 
30719<blockquote>
30720Agreed.
30721</blockquote>
30722
30723
30724
30725<p><b>Proposed resolution:</b></p>
30726
30727<p>
30728Alisdair initially proposed wording in
30729<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2619.pdf">N2619</a>.
30730</p>
30731<p>
30732We are awaiting an updated paper based on feedback from the San Francisco
30733review.
30734</p>
30735
30736
30737
30738
30739
30740<hr>
30741<h3><a name="1009"></a>1009. <tt>InputIterator</tt> post-increment dangerous</h3>
30742<p><b>Section:</b> X [iterator.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
30743 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-10-22</p>
30744<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
30745<p><b>Discussion:</b></p>
30746
30747<p><b>Addresses UK 251</b></p>
30748
30749<p>
30750The post-increment operator is dangerous for a general InputIterator.
30751The multi-pass guarantees that make it meaningful are defined as part of
30752the ForwardIterator refinement. Any change will affect only constrained
30753templates that have not yet been written, so should not break existing
30754user iterators which remain free to add these operations. This change
30755will also affect the generalised OutputIterator, although there is no
30756percieved need for the post-increment operator in this case either.
30757</p>
30758
30759<p><i>[
307602009-07-28 Alisdair adds:
30761]</i></p>
30762
30763
30764<blockquote>
30765We still think the issue is relevant, but needs totally rewording in
30766non-concept language.  We would like to see the issue retained as Open,
30767rather than deferred as NAD Concepts.  Review status is no longer
30768appropriate.
30769</blockquote>
30770
30771<p><i>[
307722009-10 Santa Cruz:
30773]</i></p>
30774
30775
30776<blockquote>
30777NAD.  Without concepts we do not feel that input iterator post increment
30778is broken.
30779</blockquote>
30780
30781
30782
30783<p><b>Proposed resolution:</b></p>
30784<p>
30785Change X [iterator.iterators]:
30786</p>
30787
30788<blockquote><pre>concept Iterator&lt;typename X&gt; : Semiregular&lt;X&gt; { 
30789  MoveConstructible reference = typename X::reference; 
30790  <del>MoveConstructible postincrement_result;</del>
30791
30792  <del>requires HasDereference&lt;postincrement_result&gt;;</del>
30793
30794  reference operator*(X&amp;&amp;); 
30795  X&amp; operator++(X&amp;); 
30796  <del>postincrement_result operator++(X&amp;, int);</del>
30797}
30798</pre>
30799
30800<p>...</p>
30801<pre><del>postincrement_result operator++(X&amp; r, int);</del>
30802</pre>
30803
30804<blockquote>
30805<del>-3- <i>Effects:</i> equivalent to <tt>{ X tmp = r; ++r; return tmp; }</tt>.</del>
30806</blockquote>
30807
30808</blockquote>
30809
30810<p>
30811Change 24.2.1 [input.iterators]:
30812</p>
30813
30814<blockquote>
30815<pre>concept InputIterator&lt;typename X&gt; : Iterator&lt;X&gt;, EqualityComparable&lt;X&gt; { 
30816  ObjectType value_type = typename X::value_type; 
30817  MoveConstructible pointer = typename X::pointer; 
30818
30819  SignedIntegralLike difference_type = typename X::difference_type; 
30820
30821  requires IntegralType&lt;difference_type&gt; 
30822        &amp;&amp; Convertible&lt;reference, const value_type &amp;&gt;; 
30823        &amp;&amp; Convertible&lt;pointer, const value_type*&gt;; 
30824
30825  <del>requires Convertible&lt;HasDereference&lt;postincrement_result&gt;::result_type, const value_type&amp;&gt;;</del>
30826
30827  pointer operator-&gt;(const X&amp;); 
30828}
30829</pre>
30830</blockquote>
30831
30832<p>
30833Change 24.2.2 [output.iterators]:
30834</p>
30835
30836<blockquote>
30837<pre>auto concept OutputIterator&lt;typename X, typename Value&gt; { 
30838  requires Iterator&lt;X&gt;; 
30839
30840  typename reference = Iterator&lt;X&gt;::reference; 
30841  <del>typename postincrement_result = Iterator&lt;X&gt;::postincrement_result;</del>
30842  requires SameType&lt;reference, Iterator&lt;X&gt;::reference&gt; 
30843        <del>&amp;&amp; SameType&lt;postincrement_result, Iterator&lt;X&gt;::postincrement_result&gt;</del>
30844        <del>&amp;&amp; Convertible&lt;postincrement_result, const X&amp;&gt;</del>
30845        &amp;&amp; HasAssign&lt;reference, Value&gt; 
30846        <del>&amp;&amp; HasAssign&lt;HasDereference&lt;postincrement_result&gt;::result_type, Value&gt;</del>;
30847}
30848</pre>
30849</blockquote>
30850
30851<p>
30852Change 24.2.3 [forward.iterators]:
30853</p>
30854
30855<p><i>[
30856See <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
30857way.
30858]</i></p>
30859
30860
30861<blockquote>
30862<pre>concept ForwardIterator&lt;typename X&gt; : InputIterator&lt;X&gt;, Regular&lt;X&gt; { 
30863  <del>requires Convertible&lt;postincrement_result, const X&amp;&gt;;</del>
30864
30865  <ins>MoveConstructible postincrement_result;</ins>
30866  <ins>requires HasDereference&lt;postincrement_result&gt;
30867        &amp;&amp; Convertible&lt;HasDereference&lt;postincrement_result&gt;::result_type, const value_type&amp;&gt;;</ins>
30868
30869  <ins>postincrement_result operator++(X&amp;, int);</ins>
30870
30871  axiom MultiPass(X a, X b) { 
30872    if (a == b) *a == *b; 
30873    if (a == b) ++a == ++b; 
30874  } 
30875}
30876</pre>
30877
30878<blockquote>
30879<p>-4- ...</p>
30880</blockquote>
30881
30882<pre><ins>postincrement_result operator++(X&amp; r, int);</ins>
30883</pre>
30884
30885<blockquote>
30886<p>
30887<ins>-5- <i>Effects:</i> equivalent to <tt>{ X tmp = r; ++r; return tmp; }</tt>.</ins>
30888</p>
30889</blockquote>
30890
30891</blockquote>
30892
30893
30894
30895
30896
30897
30898<hr>
30899<h3><a name="1010"></a>1010. <tt>operator-=</tt> should use default in concept</h3>
30900<p><b>Section:</b> 24.2.5 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
30901 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-16</p>
30902<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>
30903<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
30904<p><b>Discussion:</b></p>
30905
30906<p><b>Addresses UK 263</b></p>
30907
30908<p>
30909This requirement on <tt>operator-=</tt> would be better expressed as a default
30910implementation in the concept, with a matching axiom.
30911</p>
30912
30913<p><i>[
30914Batavia (2009-05):
30915]</i></p>
30916
30917<blockquote>
30918The proposed resolution should also remove
30919paragraph 5 and the declaration that precedes it.
30920Further, we should provide an axiom
30921that captures the desired semantics.
30922This may be a broader policy to be applied.
30923Move to Open.
30924</blockquote>
30925
30926
30927<p><b>Proposed resolution:</b></p>
30928<p>
30929Change 24.2.5 [random.access.iterators]:
30930</p>
30931
30932<blockquote><pre>concept RandomAccessIterator&lt;typename X&gt; : BidirectionalIterator&lt;X&gt;, LessThanComparable&lt;X&gt; {
30933  ...
30934  X&amp; operator-=(X&amp; <ins>x</ins>, difference_type <ins>n</ins>)<ins> { return x += -n</ins>;<ins> }</ins>
30935  ...
30936}
30937</pre></blockquote>
30938
30939
30940
30941
30942
30943
30944<hr>
30945<h3><a name="1013"></a>1013. Response to UK 305</h3>
30946<p><b>Section:</b> 25.4.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
30947 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-16</p>
30948<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>
30949<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
30950<p><b>Discussion:</b></p>
30951
30952<p><b>Addresses UK 305</b></p>
30953
30954<p>
30955The negative requirement on <tt>IsSameType</tt> is a hold-over from an earlier
30956draught with a variadic template form of <tt>min/max</tt> algorith. It is no
30957longer necessary.
30958</p>
30959
30960<p><i>[
30961Batavia (2009-05):
30962]</i></p>
30963
30964<blockquote>
30965We agree with the proposed resolution.
30966Move to Tentatively Ready.
30967</blockquote>
30968
30969<p><i>[
309702009-07 Frankfurt
30971]</i></p>
30972
30973
30974<blockquote>
30975We believe this is NAD, but this needs to be reviewed against the
30976post-remove-concepts draft.
30977</blockquote>
30978
30979
30980
30981<p><b>Proposed resolution:</b></p>
30982<p>
30983Change 25 [algorithms]:
30984</p>
30985
30986<blockquote><pre>template&lt;class T, StrictWeakOrder&lt;auto, T&gt; Compare&gt;
30987  <del>requires !SameType&lt;T, Compare&gt; &amp;&amp; CopyConstructible&lt;Compare&gt;</del>
30988  const T&amp; min(const T&amp; a, const T&amp; b, Compare comp);
30989...
30990template&lt;class T, StrictWeakOrder&lt;auto, T&gt; Compare&gt;
30991  <del>requires !SameType&lt;T, Compare&gt; &amp;&amp; CopyConstructible&lt;Compare&gt;</del>
30992  const T&amp; max(const T&amp; a, const T&amp; b, Compare comp);
30993...
30994template&lt;class T, StrictWeakOrder&lt;auto, T&gt; Compare&gt;
30995  <del>requires !SameType&lt;T, Compare&gt; &amp;&amp; CopyConstructible&lt;Compare&gt;</del>
30996  pair&lt;const T&amp;, const T&amp;&gt; minmax(const T&amp; a, const T&amp; b, Compare comp);
30997</pre></blockquote>
30998
30999<p>
31000Change 25.4.7 [alg.min.max], p1, p9 and p17:
31001</p>
31002
31003<blockquote><pre>template&lt;class T, StrictWeakOrder&lt;auto, T&gt; Compare&gt;
31004  <del>requires !SameType&lt;T, Compare&gt; &amp;&amp; CopyConstructible&lt;Compare&gt;</del>
31005  const T&amp; min(const T&amp; a, const T&amp; b, Compare comp);
31006...
31007template&lt;class T, StrictWeakOrder&lt;auto, T&gt; Compare&gt;
31008  <del>requires !SameType&lt;T, Compare&gt; &amp;&amp; CopyConstructible&lt;Compare&gt;</del>
31009  const T&amp; max(const T&amp; a, const T&amp; b, Compare comp);
31010...
31011template&lt;class T, StrictWeakOrder&lt;auto, T&gt; Compare&gt;
31012  <del>requires !SameType&lt;T, Compare&gt; &amp;&amp; CopyConstructible&lt;Compare&gt;</del>
31013  pair&lt;const T&amp;, const T&amp;&gt; minmax(const T&amp; a, const T&amp; b, Compare comp);
31014</pre></blockquote>
31015
31016
31017
31018
31019
31020
31021<hr>
31022<h3><a name="1015"></a>1015. Response to UK 199</h3>
31023<p><b>Section:</b> X [concept.transform] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
31024 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-15</p>
31025<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#concept.transform">issues</a> in [concept.transform].</p>
31026<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
31027<p><b>Discussion:</b></p>
31028
31029<p><b>Addresses UK 199</b></p>
31030
31031<p>
31032The requirement that programs do not supply <tt>concept_maps</tt> should
31033probably be users do not supply their own <tt>concept_map</tt>
31034specializations. The program will almost certainly supply
31035<tt>concept_maps</tt> - the standard itself supplies a specialization
31036for <tt>RvalueOf</tt> references. Note that the term <i>program</i> is
31037defined in 3.5 [basic.link]p1 and makes no account of the
31038standard library being treated differently to user written code.
31039</p>
31040
31041<p><i>[
310422009-05-09 Alisdair adds:
31043]</i></p>
31044
31045
31046<blockquote>
31047<p>
31048The same problem is present in the words added for the
31049<tt>LvalueReference/RvalueReference</tt> concepts last meeting.
31050</p>
31051<p>
31052With three subsections requiring the same constraint, I'm wondering if there
31053is a better way to organise this section.
31054Possible 20.2.1 -&gt; 20.2.3 belong in the fundamental concepts clause in
31055 [concept.support]?  While they can be implemented purely as a
31056library feature without additional compiler support, they are pretty
31057fundamental and we want the same restriction on user-concept maps as is
31058mandated there.
31059</p>
31060</blockquote>
31061
31062<p><i>[
31063Batavia (2009-05):
31064]</i></p>
31065
31066<blockquote>
31067We agree with the issue,
31068but believe the wording needs further improvement.
31069We want to investigate current definitions for nomenclature such as
31070"user" and "program."
31071Move to Open pending the recommended investigation.
31072</blockquote>
31073
31074
31075<p><b>Proposed resolution:</b></p>
31076<p>
31077Change X [concept.transform] p2:
31078</p>
31079
31080<blockquote>
31081-2- A <del>program</del> <ins>user</ins> shall not provide concept maps for
31082any concept in 20.1.1.
31083</blockquote>
31084
31085<p>
31086Change  [concept.true] p2:
31087</p>
31088
31089<blockquote>
31090-2- <i>Requires:</i> a <del>program</del> <ins>user</ins> shall not
31091provide a concept map for the <tt>True</tt> concept.
31092</blockquote>
31093
31094<p>
31095Change  [concept.classify] p2:
31096</p>
31097
31098<blockquote>
31099-2- <i>Requires:</i> a <del>program</del><ins>user</ins> shall not provide concept
31100maps for any concept in this section.
31101</blockquote>
31102
31103
31104
31105
31106
31107
31108<hr>
31109<h3><a name="1016"></a>1016. Response to JP 33</h3>
31110<p><b>Section:</b> X [concept.comparison] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
31111 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-15</p>
31112<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#concept.comparison">issues</a> in [concept.comparison].</p>
31113<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
31114<p><b>Discussion:</b></p>
31115
31116<p><b>Addresses JP 33</b></p>
31117
31118<p>
31119<tt>LessThanComparable</tt> and <tt>EqualityComparable</tt> don't correspond to NaN. 
31120</p>
31121
31122<p><b>Original proposed resolution:</b></p>
31123
31124<p>
31125Apply <tt>concept_map</tt> to these concepts at <tt>FloatingPointType</tt>.
31126</p>
31127
31128<p><i>[
31129Post Summit, Alisdair adds:
31130]</i></p>
31131
31132
31133<blockquote>
31134<p>
31135I don't understand the proposed resolution - there is no such thing as a
31136'negative' concept_map, and these concepts are auto concepts that match
31137float/double etc. Also not clear how we are supposed to match values to
31138concepts.
31139</p>
31140<p>
31141Recommend NAD and treat as a subset of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#902">902</a>.
31142</p>
31143</blockquote>
31144
31145
31146
31147<p><b>Proposed resolution:</b></p>
31148<p>
31149Recommend NAD.
31150</p>
31151
31152
31153
31154
31155
31156<hr>
31157<h3><a name="1017"></a>1017. Response to US 66</h3>
31158<p><b>Section:</b> X [concept.regular] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
31159 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-15</p>
31160<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
31161<p><b>Discussion:</b></p>
31162
31163<p><b>Addresses US 66</b></p>
31164
31165<p>
31166Application of the <tt>Regular</tt> concept to floating-point types appears to be
31167controversial (see long discussion on std-lib reflector). 
31168</p>
31169
31170<p><b>Original proposed resolution:</b></p>
31171
31172<p>
31173State that the <tt>Regular</tt> concept does not apply to floating-point types. 
31174</p>
31175
31176<p><i>[
31177Summit:
31178]</i></p>
31179
31180
31181<blockquote>
31182<p>
31183Recommend that we handle the same as JP 33 / <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1016">1016</a>.
31184</p>
31185</blockquote>
31186
31187<p><i>[
31188Post Summit, Alisdair adds:
31189]</i></p>
31190
31191
31192<blockquote>
31193<p>
31194Recommend Open, and review after resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#902">902</a> and revised axiom
31195feature.
31196</p>
31197</blockquote>
31198
31199
31200
31201<p><b>Proposed resolution:</b></p>
31202
31203
31204
31205
31206
31207<hr>
31208<h3><a name="1018"></a>1018. Response to US 70</h3>
31209<p><b>Section:</b> 20.6 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
31210 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-15</p>
31211<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>
31212<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
31213<p><b>Discussion:</b></p>
31214
31215<p><b>Addresses US 70</b></p>
31216
31217<p>
31218Specifications now expressed via narrative text are more accurately and
31219clearly expressed via executable code.
31220</p>
31221<p>
31222Wherever concepts are available that directly match this section's type
31223traits, express the traits in terms of the concepts instead of via
31224narrative text. Where the type traits do not quite match the
31225corresponding concepts, bring the two into alignment so as to avoid two
31226nearly-identical notions.
31227</p>
31228
31229<p><i>[
31230Summit:
31231]</i></p>
31232
31233
31234<blockquote>
31235<p>
31236We think that this is a good idea, but it requires a lot of work. If someone
31237submits a paper proposing specific changes, we would be happy to review it
31238at the next meeting.
31239</p>
31240</blockquote>
31241
31242
31243
31244<p><b>Proposed resolution:</b></p>
31245
31246
31247
31248
31249
31250<hr>
31251<h3><a name="1020"></a>1020. Response to UK 204</h3>
31252<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#NAD">NAD</a>
31253 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-10-23</p>
31254<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>
31255<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
31256<p><b>Discussion:</b></p>
31257
31258<p><b>Addresses UK 204</b></p>
31259
31260<p>
31261It is not possible to create a variant union based on a parameter pack
31262expansion, e.g. to implement a classic discriminated union template. 
31263</p>
31264
31265<p><b>Original proposed resolutuion:</b></p>
31266
31267<p>
31268Restore <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>. 
31269</p>
31270
31271<p><i>[
31272Summit:
31273]</i></p>
31274
31275
31276<blockquote>
31277Agree. The need for <tt>aligned_union</tt> is compelling enough to reinstate.
31278</blockquote>
31279
31280<p><i>[
31281Post Summit, Alisdair adds:
31282]</i></p>
31283
31284
31285<blockquote>
31286paper
31287<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2843.html">N2843</a>
31288proposes an extension to the <tt>[[align]]</tt> attribute
31289that further diminishes the need for this template.  Recommend NAD.
31290</blockquote>
31291
31292<p><i>[
312932009-10 Santa Cruz:
31294]</i></p>
31295
31296
31297<blockquote>
31298Mark NAD as suggested.
31299</blockquote>
31300
31301
31302
31303<p><b>Proposed resolution:</b></p>
31304
31305
31306
31307
31308
31309<hr>
31310<h3><a name="1022"></a>1022. Response to UK 212</h3>
31311<p><b>Section:</b> 20.8.15.6 [util.dynamic.safety] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
31312 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-03-12</p>
31313<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>
31314<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
31315<p><b>Discussion:</b></p>
31316
31317<p><b>Addresses UK 212</b></p>
31318
31319<p>
31320The pointer-safety API is nothing to do with smart pointers, so does not
31321belong in 20.8.15 [util.smartptr]. In fact it is a set of language
31322support features are really belongs in clause 18 [language.support], with the contents declared in a header that
31323deals with language-support of memory management.
31324</p>
31325
31326<p><i>[
31327Summit:
31328]</i></p>
31329
31330
31331<blockquote>
31332Agree in principle, but not with the proposed resolution. We believe it
31333belongs either a subsection of either 20 [utilities] or 20.8 [memory]
31334as part of the general reorganization of 20 [utilities]. The
31335declaration should stay in
31336<tt>&lt;memory&gt;</tt>.
31337</blockquote>
31338
31339
31340
31341<p><b>Proposed resolution:</b></p>
31342
31343
31344
31345
31346
31347<hr>
31348<h3><a name="1023"></a>1023. Response to DE 22</h3>
31349<p><b>Section:</b> 20.7.15.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
31350 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-13</p>
31351<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
31352<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
31353<p><b>Discussion:</b></p>
31354
31355<p><b>Addresses DE 22</b></p>
31356
31357<p>Related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1114">1114</a>.</p>
31358
31359<p>
31360The conditions for deriving from <tt>std::unary_function</tt> and
31361<tt>std::binary_function</tt> are unclear: The condition would also be satisfied if
31362<tt>ArgTypes</tt> were <tt>std::vector&lt;T1&gt;</tt>, because it (arguably)
31363"contains" <tt>T1</tt>.
31364</p>
31365
31366<p><i>[
31367Summit:
31368]</i></p>
31369
31370
31371<blockquote>
31372Agree. <tt>std::reference_wrapper</tt> has the same structure, and we
31373suggest that <tt>std::function</tt> be presented in the same way as
31374<tt>std::reference_wrapper</tt>.
31375</blockquote>
31376
31377<p><i>[
313782009-05-09 Alisdair adds:
31379]</i></p>
31380
31381
31382<blockquote>
31383Phrasing should be "publicly and
31384unambiguously derived from" and probably back in reference_wrapper too.  Updated
31385wording supplied.
31386</blockquote>
31387
31388<p><i>[
31389Batavia (2009-05):
31390]</i></p>
31391
31392<blockquote>
31393We agree with the proposed wording.
31394Move to NAD Editorial.
31395</blockquote>
31396
31397
31398<p><b>Proposed resolution:</b></p>
31399<p>
31400(no changes to <tt>&lt;functional&gt;</tt> synopsis required)
31401</p>
31402
31403<p>
31404Change synopsis in Class template function 20.7.15.2 [func.wrap.func]:
31405</p>
31406
31407<blockquote><pre>template&lt;Returnable R, CopyConstructible... ArgTypes&gt; 
31408class function&lt;R(ArgTypes...)&gt; 
31409  : public unary_function&lt;T1, R&gt;      // <del><i>iff</i> sizeof...(ArgTypes) == 1 <i>and</i></del> <ins><i>see below</i></ins>
31410                                      <del>// ArgTypes <i>contains</i> T1</del>
31411  : public binary_function&lt;T1, T2, R&gt; // <del><i>iff</i> sizeof...(ArgTypes) == 2 <i>and</i></del> <ins><i>see below</i></ins>
31412                                      <del>// ArgTypes <i>contains</i> T1 <i>and</i> T2</del>
31413{
31414   ...
31415</pre></blockquote>
31416
31417<p>
31418Add new p1/p2 before 20.7.15.2.1 [func.wrap.func.con]:
31419</p>
31420
31421<blockquote>
31422<p><ins>
31423The template instantiation <tt>function&lt;R(T1)&gt;</tt> shall be publicly and
31424unambiguously derived from 
31425<tt>std::unary_function&lt;T1,R&gt;</tt> if and only if the template type parameter
31426is a function type taking one argument of type <tt>T1</tt> and returning <tt>R</tt>.
31427</ins></p>
31428
31429<p><ins>
31430The template instantiation <tt>function&lt;R(T1,T2)&gt;</tt> shall be publicly and
31431unambiguously derived from 
31432<tt>std::binary_function&lt;T1,T2,R&gt;</tt> if and only if the template type
31433parameter is a function type taking two arguments of type <tt>T1</tt> and <tt>T2</tt> and
31434returning <tt>R</tt>.
31435</ins></p>
31436
31437<pre>explicit function();
31438</pre>
31439</blockquote>
31440
31441
31442
31443
31444
31445
31446<hr>
31447<h3><a name="1024"></a>1024. Response to JP 39</h3>
31448<p><b>Section:</b> 20.7.15.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
31449 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-16</p>
31450<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
31451<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
31452<p><b>Discussion:</b></p>
31453
31454<p><b>Addresses JP 39</b></p>
31455
31456<p>
31457There are no requires corresponding to <tt>F</tt> of <tt>std::function</tt>.
31458</p>
31459
31460<p><i>[
314612009-05-01 Daniel adds:
31462]</i></p>
31463
31464
31465<blockquote>
31466<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1070">1070</a> removes the second constructor.
31467</blockquote>
31468
31469<p><i>[
31470Batavia (2009-05):
31471]</i></p>
31472
31473<blockquote>
31474We agree with the proposed resolution.
31475Move to Tentatively Ready.
31476If issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1070">1070</a> is accepted,
31477the changes to the second constructor
31478in this issue are moot.
31479</blockquote>
31480
31481<p><i>[
314822009-07 Frankfurt:
31483]</i></p>
31484
31485
31486<blockquote>
31487Constructors have no definition.
31488</blockquote>
31489
31490
31491
31492<p><b>Proposed resolution:</b></p>
31493<p>
31494Correct as follows in 20.7.15.2 [func.wrap.func] (class definition)
31495</p>
31496
31497<blockquote><pre> template&lt;class F, Allocator Alloc&gt;
31498   <ins>requires ConstructibleWithAllocator&lt;F, Alloc&gt;
31499     &amp;&amp; call=Callable&lt;F, ArgTypes...&gt;
31500     &amp;&amp; Convertible&lt;call::result_type, R&gt;</ins>
31501   function(allocator_arg_t, const Alloc&amp;, F);
31502 template&lt;class F, Allocator Alloc&gt;
31503   <ins>requires ConstructibleWithAllocator&lt;F,Alloc&gt;
31504     &amp;&amp; call=Callable&lt;F, ArgTypes...&gt;
31505     &amp;&amp; Convertible&lt;call::result_type, R&gt;</ins>
31506   function(allocator_arg_t, const Alloc&amp;, F&amp;&amp;);
31507</pre></blockquote>
31508
31509
31510
31511
31512
31513
31514<hr>
31515<h3><a name="1025"></a>1025. Response to UK 208</h3>
31516<p><b>Section:</b> 20.7.16 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
31517 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-03-12</p>
31518<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>
31519<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>
31520<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
31521<p><b>Discussion:</b></p>
31522
31523<p><b>Addresses UK 208</b></p>
31524
31525<p>
31526<tt>std::hash</tt> should be implemented for much more of the standard
31527library. In particular for <tt>pair</tt>, <tt>tuple</tt> and all the
31528standard containers.
31529</p>
31530
31531
31532
31533<p><b>Proposed resolution:</b></p>
31534
31535
31536
31537
31538
31539<hr>
31540<h3><a name="1026"></a>1026. Response to UK 209</h3>
31541<p><b>Section:</b> 20.8 [memory] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
31542 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-15</p>
31543<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#memory">issues</a> in [memory].</p>
31544<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
31545<p><b>Discussion:</b></p>
31546
31547<p><b>Addresses UK 209</b></p>
31548
31549<p>
31550Smart pointers cannot be used in constrained templates.
31551</p>
31552
31553<p><i>[
31554Summit:
31555]</i></p>
31556
31557
31558<blockquote>
31559We look forward to a paper on this topic. We recommend no action until a
31560paper is available. We understand that a paper is forthcoming.
31561</blockquote>
31562
31563<p><i>[
31564Peter Dimov adds:
31565]</i></p>
31566
31567
31568<blockquote>
31569<tt>shared_ptr&lt;T&gt;</tt> and <tt>weak_ptr&lt;T&gt;</tt> support all
31570types <tt>T</tt> for which <tt>T*</tt> is valid. In other words, a
31571possible (partial) resolution is to change class <tt>T</tt> to
31572<tt>PointeeType T</tt> for <tt>shared_ptr</tt>, <tt>weak_ptr</tt> and
31573possibly <tt>enable_shared_from_this</tt>.
31574</blockquote>
31575
31576
31577
31578<p><b>Proposed resolution:</b></p>
31579
31580
31581
31582
31583
31584<hr>
31585<h3><a name="1027"></a>1027. Response to UK 213</h3>
31586<p><b>Section:</b> 20.8.8 [default.allocator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
31587 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-15</p>
31588<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
31589<p><b>Discussion:</b></p>
31590
31591<p><b>Addresses UK 213</b></p>
31592
31593<p>
31594<tt>std::allocator</tt> should be constrained to simplify its use on constrained
31595contexts. This library component models allocation from free store via the
31596new operator so choose constraints to 
31597match. The Allocator concept allows for a wider variety of allocators that
31598users may choose to supply if their allocation model does not require
31599operator new, without impacting the 
31600requirements of this template. 
31601</p>
31602
31603<p>
31604Suggested direction:
31605</p>
31606<p>
31607The primary allocator template should be constrained to require
31608<tt>ObjectType&lt;T&gt;</tt> and <tt>FreeStoreAllocatable&lt;T&gt;</tt>.
31609Further operations to be constrained as required.
31610</p>
31611
31612<p><i>[
31613Summit:
31614]</i></p>
31615
31616
31617<blockquote>
31618Agree as stated. A future paper will address additional related issues.
31619</blockquote>
31620
31621
31622
31623<p><b>Proposed resolution:</b></p>
31624
31625
31626
31627
31628
31629<hr>
31630<h3><a name="1028"></a>1028. Response to UK 214</h3>
31631<p><b>Section:</b> 20.8.10 [storage.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
31632 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-16</p>
31633<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
31634<p><b>Discussion:</b></p>
31635
31636<p><b>Addresses UK 214</b></p>
31637
31638<p>
31639<tt>raw_storage_iterator</tt> needs constraining as an iterator adaptor to be safely
31640used in constrained templates 
31641</p>
31642
31643<p><i>[
31644Summit:
31645]</i></p>
31646
31647
31648<blockquote>
31649We look forward to a paper on this topic. We recommend no action until a
31650paper is available.
31651</blockquote>
31652
31653<p><i>[
31654Post Summit Alisdair provided wording and rationale.
31655]</i></p>
31656
31657
31658
31659
31660<p><b>Proposed resolution:</b></p>
31661<p>
3166220.8 [memory] p2
31663</p>
31664<p>
31665Update the synopsis for <tt>&lt;memory&gt;</tt>
31666</p>
31667<blockquote><pre>// 20.7.8, raw storage iterator:
31668template &lt;<del>class</del> <ins>ForwardIterator</ins> Out<del>put</del>Iter<del>ator</del>, <del>class</del> <ins>ObjectType</ins> T&gt; 
31669  <ins>requires OutputIterator&lt; OutIter, T &gt;</ins>
31670    class raw_storage_iterator;
31671
31672<ins>template &lt;ForwardIterator OutIter, ObjectType T&gt; 
31673  requires OutputIterator&lt; OutIter, T &gt;
31674  concept_map Iterator&lt;raw_storage_iterator&lt; OutIter, T &gt; &gt; { }</ins>
31675</pre></blockquote>
31676
31677
31678<p>
3167920.8.10 [storage.iterator] p1
31680</p>
31681<p>
31682Replace class template definition with:
31683</p>
31684<blockquote><pre>namespace std { 
31685  template &lt;<del>class</del> <ins>ForwardIterator</ins> Out<del>put</del>Iter<del>ator</del>, <del>class</del> <ins>ObjectType</ins> T&gt; 
31686    <ins>requires OutputIterator&lt; OutIter, T &gt;</ins>
31687  class raw_storage_iterator 
31688    : public iterator&lt;output_iterator_tag,void,void,void,void&gt; { 
31689  public: 
31690    explicit raw_storage_iterator(Out<del>put</del>Iter<del>ator</del> x); 
31691
31692    raw_storage_iterator<del>&lt;OutputIterator,T&gt;</del>&amp; operator*(); 
31693    raw_storage_iterator<del>&lt;OutputIterator,T&gt;</del>&amp; operator=(const T&amp; element); 
31694    raw_storage_iterator<del>&lt;OutputIterator,T&gt;</del>&amp; operator++(); 
31695    raw_storage_iterator<del>&lt;OutputIterator,T&gt;</del> operator++(int); 
31696  }; 
31697
31698  <ins>template &lt;ForwardIterator OutIter, ObjectType T&gt; 
31699    requires OutputIterator&lt; OutIter, T &gt;
31700    concept_map Iterator&lt;raw_storage_iterator&lt; OutIter, T &gt; &gt; { }</ins>
31701}
31702</pre></blockquote>
31703
31704
31705<p><b>Rationale:</b></p>
31706<p>
31707<tt>raw_storage_iterator</tt> has to adapt a <tt>ForwardIterator</tt>,
31708rather than just an <tt>InputIterator</tt> for two reasons:
31709</p>
31710
31711<ol type="i">
31712<li>
31713The initial iterator passed by value is expected to remain valid,
31714pointing to the initialized region of memory.
31715</li>
31716<li>
31717to avoid breaking the declaration of post-increment operator which would
31718require some kind of proxy formulation to support generalised InputIterators.
31719</li>
31720</ol>
31721
31722
31723
31724
31725
31726
31727<hr>
31728<h3><a name="1029"></a>1029. Response to UK 210</h3>
31729<p><b>Section:</b> 20.8.13 [specialized.algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
31730 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-16</p>
31731<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#specialized.algorithms">issues</a> in [specialized.algorithms].</p>
31732<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
31733<p><b>Discussion:</b></p>
31734
31735<p><b>Addresses UK 210</b></p>
31736
31737<p>Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#582">582</a></p>
31738
31739<p>
31740Specialized algorithms for memory managenment need requirements to be
31741easily usable in constrained templates.
31742</p>
31743
31744<p><i>[
31745Summit:
31746]</i></p>
31747
31748
31749<blockquote>
31750We look forward to a paper on this topic. We recommend no action until a
31751paper is available.
31752</blockquote>
31753
31754<p><i>[
31755Post Summit Alisdair provided wording.
31756]</i></p>
31757
31758
31759<p><i>[
31760Post Summit:
31761]</i></p>
31762
31763
31764<blockquote>
31765<p>
31766Daniel adds:
31767</p>
31768
31769<blockquote>
31770<ol>
31771<li>
31772I suggest <tt>Size</tt> should require <tt>IntegralLike</tt> and not <tt>UnsignedIntegralLike</tt>,
31773because otherwise simple int-literals could not be provided as arguments
31774and it would conflict with other algorithms that only require <tt>IntegralLike</tt>.
31775</li>
31776<li>
31777<p>
31778The current for-loop-test relies on evaluation in boolean context which is
31779not provided by <tt>ArithmeticLike</tt> and it's refinements. I propose to change the
31780corresponding for-loop-headers to:
31781</p>
31782<ol type="a">
31783<li>
31784for <tt>uninitialized_copy_n</tt>: <tt>for ( ; n &gt; Size(0); ++result, ++first, --n) {</tt>
31785</li>
31786<li>
31787for <tt>uninitialized_fill_n</tt>: <tt>for (; n &gt; Size(0); ++first, --n) {</tt>
31788</li>
31789</ol>
31790</li>
31791</ol>
31792</blockquote>
31793
31794<p>
31795Alisdair adds:
31796</p>
31797<blockquote>
31798For the record I agree with Daniel's suggestion.
31799</blockquote>
31800
31801</blockquote>
31802
31803
31804
31805<p><b>Proposed resolution:</b></p>
31806<p>
3180720.8 [memory] p2
31808</p>
31809<p>
31810Update the synopsis for <tt>&lt;memory&gt;</tt>
31811</p>
31812<blockquote><pre>template &lt;<del>class</del> InputIterator <ins>InIter</ins>,
31813         <del>class ForwardIterator</del> <ins>OutputIterator&lt;auto, InIter::reference&gt; OutIter</ins>&gt; 
31814   <ins>requires ForwardIterator&lt;OutIter&gt;</ins>
31815   <del>ForwardIterator</del> <ins>OutIter</ins>
31816   uninitialized_copy(<del>InputIterator</del> <ins>InIter</ins> first, <del>InputIterator</del> <ins>InIter</ins> last, 
31817                      <del>ForwardIterator</del> <ins>OutIter</ins> result);
31818
31819template &lt;<del>class</del> InputIterator <ins>InIter</ins>,
31820          <del>class</del> <ins>IntegralLike</ins> Size,
31821          <del>class ForwardIterator</del> <ins>OutputIterator&lt;auto, InIter::reference&gt; OutIter</ins>&gt; 
31822  <ins>requires ForwardIterator&lt;OutIter&gt;</ins>
31823  <del>ForwardIterator</del> <ins>OutIter</ins>
31824  uninitialized_copy_n(<del>InputIterator</del> <ins>InIter</ins> first, Size n, 
31825                       <del>ForwardIterator</del> <ins>OutIter</ins> result);
31826
31827template &lt;<del>class</del> ForwardIterator <ins>Iter</ins>, <del>class</del> <ins>ObjectType</ins> T&gt;
31828  <ins>requires Constructible&lt; Iter::value_type, const T&amp; &gt;</ins>
31829  void uninitialized_fill(<del>ForwardIterator</del> <ins>Iter</ins> first, <del>ForwardIterator</del> <ins>Iter</ins> last, 
31830                          const T&amp; x);
31831
31832template &lt;<del>class</del> ForwardIterator <ins>Iter</ins>, <del>class</del> <ins>IntegralLike</ins> Size, <del>class</del> <ins>ObjectType</ins> T&gt; 
31833  <ins>requires Constructible&lt; Iter::value_type, const T&amp; &gt;</ins>
31834  void
31835  uninitialized_fill_n(<del>ForwardIterator</del> <ins>Iter</ins> first, Size n, const T&amp; x);
31836</pre></blockquote>
31837
31838<p>
31839Update as follows:
31840</p>
31841
31842<p>
31843uninitialized_copy 20.8.13.2 [uninitialized.copy]
31844</p>
31845
31846<blockquote><pre>template &lt;<del>class</del> InputIterator <ins>InIter</ins>,
31847         <del>class ForwardIterator</del> <ins>OutputIterator&lt;auto, InIter::reference&gt; OutIter</ins>&gt; 
31848   <ins>requires ForwardIterator&lt;OutIter&gt;</ins>
31849   <del>ForwardIterator</del> <ins>OutIter</ins>
31850   uninitialized_copy(<del>InputIterator</del> <ins>InIter</ins> first, <del>InputIterator</del> <ins>InIter</ins> last, 
31851                      <del>ForwardIterator</del> <ins>OutIter</ins> result);
31852</pre>
31853
31854<blockquote>
31855<p>
31856-1- <i>Effects:</i>
31857</p>
31858<blockquote><pre>for (; first != last; ++result, ++first)  {
31859   new (static_cast&lt;void*&gt;(&amp;*result))
31860       <del>typename iterator_traits&lt;ForwardIterator&gt;</del> <ins>OutIter</ins>::value_type(*first);
31861}
31862</pre></blockquote>
31863
31864<p>
31865-2- <i>Returns:</i> <tt>result</tt>
31866</p>
31867
31868</blockquote>
31869
31870<pre>template &lt;<del>class</del> InputIterator <ins>InIter</ins>,
31871          <del>class</del> <ins>IntegralLike</ins> Size,
31872          <del>class ForwardIterator</del> <ins>OutputIterator&lt;auto, InIter::reference&gt; OutIter</ins>&gt; 
31873  <ins>requires ForwardIterator&lt;OutIter&gt;</ins>
31874  <del>ForwardIterator</del> <ins>OutIter</ins>
31875  uninitialized_copy_n(<del>InputIterator</del> <ins>InIter</ins> first, Size n, 
31876                       <del>ForwardIterator</del> <ins>OutIter</ins> result);
31877</pre>
31878
31879<blockquote>
31880<p>
31881-3- Effects:
31882</p>
31883<blockquote><pre>for ( ; n &gt; <ins>Size(</ins>0<ins>)</ins>; ++result, ++first, --n) {
31884   new (static_cast&lt;void*&gt;(&amp;*result))
31885       <del>typename iterator_traits&lt;ForwardIterator&gt;</del> <ins>OutIter</ins>::value_type(*first);
31886}
31887</pre></blockquote>
31888<p>
31889-4- <i>Returns:</i> result
31890</p>
31891</blockquote>
31892
31893</blockquote>
31894
31895
31896<p>
31897uninitialized_fill 20.8.13.3 [uninitialized.fill]
31898</p>
31899
31900<blockquote><pre>template &lt;<del>class</del> ForwardIterator <ins>Iter</ins>, <del>class</del> <ins>ObjectType</ins> T&gt;
31901  <ins>requires Constructible&lt; Iter::value_type, const T&amp; &gt;</ins>
31902  void uninitialized_fill(<del>ForwardIterator</del> <ins>Iter</ins> first, <del>ForwardIterator</del> <ins>Iter</ins> last, 
31903                          const T&amp; x);
31904</pre>
31905
31906<blockquote>
31907<p>
31908-1- <i>Effects:</i>
31909</p>
31910<blockquote><pre>for (; first != last; ++first) {
31911   new ( static_cast&lt;void*&gt;( &amp;*first) ) 
31912       <del>typename iterator_traits&lt;ForwardIterator&gt;</del> <ins>Iter</ins>::value_type(x);
31913}
31914</pre></blockquote>
31915</blockquote>
31916</blockquote>
31917
31918
31919<p>
31920uninitialized_fill_n 20.8.13.4 [uninitialized.fill.n]
31921</p>
31922
31923<blockquote><pre>template &lt;<del>class</del> ForwardIterator <ins>Iter</ins>, <del>class</del> <ins>IntegralLike</ins> Size, <del>class</del> <ins>ObjectType</ins> T&gt; 
31924  <ins>requires Constructible&lt; Iter::value_type, const T&amp; &gt;</ins>
31925  void
31926  uninitialized_fill_n(<del>ForwardIterator</del> <ins>Iter</ins> first, Size n, const T&amp; x);
31927</pre>
31928
31929<blockquote>
31930<p>
31931-1- <i>Effects:</i>
31932</p>
31933<blockquote><pre>for (; n<del>--</del> <ins>&gt; Size(0)</ins>; ++first<ins>, --n</ins>) {
31934   new ( static_cast&lt;void*&gt;( &amp;*first) ) 
31935       <del>typename iterator_traits&lt;ForwardIterator&gt;</del> <ins>Iter</ins>::value_type(x);
31936}
31937</pre></blockquote>
31938</blockquote>
31939</blockquote>
31940
31941
31942
31943
31944
31945
31946<hr>
31947<h3><a name="1031"></a>1031. Response to US 78</h3>
31948<p><b>Section:</b> 20.8.15.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
31949 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-10-20</p>
31950<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>
31951<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
31952<p><b>Discussion:</b></p>
31953
31954<p><b>Addresses US 78</b></p>
31955
31956<p>
31957There is presently no way to convert directly from a <tt>shared_ptr</tt> to a
31958<tt>unique_ptr</tt>. Add an interface that performs the conversion. 
31959</p>
31960
31961<p><i>[
31962Summit:
31963]</i></p>
31964
31965
31966<blockquote>
31967We look forward to a paper on this topic. We recommend no action until a
31968paper is available. We believe that the shared pointer must use the default
31969deleter for the conversion to succeed.
31970</blockquote>
31971
31972<p><i>[
31973Peter Dimov adds:
31974]</i></p>
31975
31976
31977<blockquote>
31978This is basically a request for <tt>shared_ptr&lt;&gt;::release</tt> in
31979disguise, with all the associated problems. Not a good idea.
31980</blockquote>
31981
31982<p><i>[
319832009-07 post-Frankfurt:
31984]</i></p>
31985
31986
31987<blockquote>
31988<p>
31989The rationale for the omission of a release() member function from shared_ptr is given in:
31990<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>
31991</p>
31992<p>
31993The implementation of such a member is non-trivial (and maybe
31994impossible), because it would need to account for the deleter.
31995</p>
31996</blockquote>
31997
31998<p><i>[
319992009-07-26 Howard sets to Tentatively NAD Future.
32000]</i></p>
32001
32002
32003<blockquote>
32004<p>
32005I took an online poll and got 3 votes for NAD and 3 for NAD Future.  Personally
32006I prefer NAD Future as this does refer to an extension that could conceivably be
32007considered beyond C++0X.
32008</p>
32009
32010<p>
32011However such an extension would need to solve a couple of problems:
32012</p>
32013
32014<ol>
32015<li>What is the interface for such a conversion when the <tt>shared_ptr</tt> does
32016not have unique ownership?  Throw an exception?  Create a null <tt>unique_ptr</tt>?
32017Undefined behavior?
32018</li>
32019
32020<li>
32021<p>
32022How does one handle custom deleters given to the <tt>shared_ptr</tt> constructor?
32023</p>
32024<p>
32025I do not believe it is possible to implement a general answer to this question.
32026The <tt>shared_ptr</tt> deleter is a run time (or construction time) characteristic.
32027The <tt>unique_ptr</tt> deleter is a compile time characteristic.  In general one
32028can not know to what type of <tt>unqiue_ptr</tt> you are converting to.
32029</p>
32030<p>
32031One answer is for the user of the conversion to specify the deleter type and perhaps
32032throw an exception if the specification turns out to be incorrect.
32033</p>
32034<p>
32035Another answer is for the conversion to only be valid when the underlying deleter
32036is <tt>default_delete</tt>.  We would probalby need to specify that this is indeed the
32037underlying deleter of a <tt>shared_ptr</tt> when a custom deleter is not given in
32038the constructor.
32039</p>
32040</li>
32041</ol>
32042
32043<p>
32044At any rate, there are non-trivial design issues which would need to be implemented
32045and tested in the field for usability prior to standardization.
32046</p>
32047</blockquote>
32048
32049<p><i>[
320502009 Santa Cruz:
32051]</i></p>
32052
32053
32054<blockquote>
32055Moved to NAD Future.
32056</blockquote>
32057
32058
32059
32060<p><b>Proposed resolution:</b></p>
32061
32062
32063
32064
32065
32066<hr>
32067<h3><a name="1032"></a>1032. Response to JP 45</h3>
32068<p><b>Section:</b> 20.9 [time] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
32069 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-11  <b>Last modified:</b> 2009-07-16</p>
32070<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#time">issues</a> in [time].</p>
32071<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
32072<p><b>Discussion:</b></p>
32073
32074<p><b>Addresses JP 45</b></p>
32075
32076<p>
32077<tt>Rep</tt>, <tt>Period</tt>, <tt>Clock</tt> and <tt>Duration</tt>
32078don't correspond to concept.
32079</p>
32080<blockquote><pre>template &lt;class Rep, class Period = ratio&lt;1&gt;&gt; class duration; 
32081template &lt;class Clock, class Duration = typename Clock::duration&gt; class time_point; 
32082</pre></blockquote>
32083<p>
32084Make concept for <tt>Rep</tt>, <tt>Period</tt>, <tt>Clock</tt> and <tt>Duration</tt>.
32085Fix 20.9 [time] and <tt>wait_until</tt>
32086and <tt>wait_for</tt>'s template parameter at 30 [thread]. 
32087</p>
32088
32089<p><i>[
32090Summit:
32091]</i></p>
32092
32093
32094<blockquote>
32095We agree that this section needs concepts. We look forward to a paper on
32096this topic. We recommend no action until a paper is available.
32097</blockquote>
32098
32099
32100
32101<p><b>Proposed resolution:</b></p>
32102
32103
32104
32105
32106
32107<hr>
32108<h3><a name="1035"></a>1035. Response to UK 226</h3>
32109<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#NAD">NAD</a>
32110 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-10-20</p>
32111<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>
32112<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>
32113<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
32114<p><b>Discussion:</b></p>
32115
32116<p><b>Addresses UK 226</b></p>
32117
32118<p>
32119<tt>&lt;array&gt;</tt> must be added to this list. In particular it
32120doesn't satisfy: - no <tt>swap()</tt> function invalidates any
32121references, pointers, or iterators referring to the elements of the
32122containers being swapped. and probably doesn't satisfy: - no
32123<tt>swap()</tt> function throws an exception.
32124</p>
32125<p>
32126If <tt>&lt;array&gt;</tt> remains a container, this will have to also
32127reference <tt>array</tt>, which will then have to say which of these
32128points it satisfies.
32129</p>
32130
32131<p><i>[
32132Summit:
32133]</i></p>
32134
32135
32136<blockquote>
32137Agree. The proposed resolution is incomplete. Further work required.
32138</blockquote>
32139
32140<p><i>[
321412009-05-01 Daniel adds:
32142]</i></p>
32143
32144
32145<blockquote>
32146Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1099">1099</a> also suggests
32147adding move constructor to this.
32148</blockquote>
32149
32150<p><i>[
321512009-07 post-Frankfurt:
32152]</i></p>
32153
32154
32155<blockquote>
32156Howard is to draft a note that explains what happens to references.
32157</blockquote>
32158
32159<p><i>[
321602009-10 Santa Cruz:
32161]</i></p>
32162
32163
32164<blockquote>
32165Mark as NAD.  No consensus for change.
32166</blockquote>
32167
32168
32169
32170<p><i>[
321712009-08-01 Howard provided wording.
32172]</i></p>
32173
32174
32175<p><b>Proposed resolution:</b></p>
32176<p>
32177Add a paragraph to 23.3.1.2 [array.special]:
32178</p>
32179
32180<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);
32181</pre>
32182<blockquote>
32183<p>
32184<i>Effects:</i>
32185</p>
32186<blockquote><pre>swap_ranges(x.begin(), x.end(), y.begin());
32187</pre></blockquote>
32188
32189<p><ins>
32190[<i>Note:</i>
32191Outstanding iterators, references and pointers may be invalidated.
32192&#8212; <i>end note</i>]
32193</ins></p>
32194</blockquote>
32195</blockquote>
32196
32197
32198
32199
32200
32201<hr>
32202<h3><a name="1036"></a>1036. Response to UK 231</h3>
32203<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#NAD%20Concepts">NAD Concepts</a>
32204 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-07-15</p>
32205<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</p>
32206<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>
32207<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
32208<p><b>Discussion:</b></p>
32209
32210<p><b>Addresses UK 231</b></p>
32211
32212<p>
32213p9-p11 are redundant now that Concepts define what it means to be an
32214Iterator and guide overload resolution accordingly. 
32215</p>
32216
32217<p><i>[
32218Summit:
32219]</i></p>
32220
32221
32222<blockquote>
32223Agree with issue and change to 23.2.3 [sequence.reqmts]. The
32224changes required to 21 [strings] will be part of the general
32225concept support for that clause.
32226</blockquote>
32227
32228
32229
32230<p><b>Proposed resolution:</b></p>
32231<p>
32232Strike 23.2.3 [sequence.reqmts]p9-11. Make sure <tt>std::basic_string</tt>
32233has constraints similar to
32234<tt>std::vector</tt> to meet this old guarantee. 
32235</p>
32236
32237
32238
32239
32240
32241<hr>
32242<h3><a name="1041"></a>1041. Response to UK 239</h3>
32243<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#NAD%20Future">NAD Future</a>
32244 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-10-20</p>
32245<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
32246<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>
32247<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
32248<p><b>Discussion:</b></p>
32249
32250<p><b>Addresses UK 239</b></p>
32251
32252<p>
32253It is not possible to take a move-only key out of an unordered
32254container, such as (<tt>multi</tt>)<tt>set</tt> or
32255(<tt>multi</tt>)<tt>map</tt>, or the new unordered containers.
32256</p>
32257
32258<p>
32259Add below <tt>a.erase(q)</tt>, <tt>a.extract(q)</tt>, with the following notation:
32260</p>
32261<p>
32262<tt>a.extract(q)&gt;</tt>, Return type <tt>pair&lt;key, iterator&gt;</tt>
32263Extracts the element pointed to by <tt>q</tt> and erases it from the
32264<tt>set</tt>. Returns a <tt>pair</tt> containing the value pointed to by
32265<tt>q</tt> and an <tt>iterator</tt> pointing to the element immediately
32266following <tt>q</tt> prior to the element being erased. If no such
32267element exists,returns <tt>a.end()</tt>.
32268</p>
32269
32270<p><i>[
32271Summit:
32272]</i></p>
32273
32274
32275<blockquote>
32276We look forward to a paper on this topic. We recommend no action until a
32277paper is available. The paper would need to address exception safety.
32278</blockquote>
32279
32280<p><i>[
32281Post Summit Alisdair adds:
32282]</i></p>
32283
32284
32285<blockquote>
32286Would <tt>value_type</tt> be a better return type than <tt>key_type</tt>?
32287</blockquote>
32288
32289<p><i>[
322902009-07 post-Frankfurt:
32291]</i></p>
32292
32293
32294<blockquote>
32295Leave Open. Alisdair to contact Chris Jefferson about this.
32296</blockquote>
32297
32298<p><i>[
322992009-09-20 Howard adds:
32300]</i></p>
32301
32302
32303<blockquote>
32304See the 2009-09-19 comment of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#839">839</a> for an API which
32305accomplishes this functionality and also addresses several other use
32306cases which this proposal does not.
32307</blockquote>
32308
32309<p><i>[
323102009-10 Santa Cruz:
32311]</i></p>
32312
32313
32314<blockquote>
32315Mark as NAD Future. No consensus to make the change at this time.
32316</blockquote>
32317
32318
32319
32320<p><b>Proposed resolution:</b></p>
32321<p>
32322In 23.2.4 [associative.reqmts] Table 85, add:
32323</p>
32324
32325<blockquote>
32326<table border="1">
32327<caption>Table 85 --  Associative container requirements (in addition to container)</caption>
32328<tbody><tr>
32329<th>Expression</th>
32330<th>Return type</th>
32331<th>Assertion/note<br>pre-/post-condition</th>
32332<th>Complexity</th>
32333</tr>
32334<tr><td><tt>a.erase(q)</tt></td>
32335<td>...</td>
32336<td>...</td>
32337<td>...</td>
32338</tr><tr>
32339<td><ins><tt>a.extract(q)</tt></ins></td>
32340<td><ins><tt>pair&lt;key_type, iterator&gt;</tt></ins></td>
32341<td><ins>Extracts the element pointed to by <tt>q</tt> and erases it from the <tt>set</tt>. 
32342Returns a <tt>pair</tt> containing the value pointed to by <tt>q</tt> and an <tt>iterator</tt>
32343pointing to the element immediately following <tt>q</tt> prior to the element being
32344erased. If no such element 
32345exists, returns <tt>a.end()</tt>.</ins></td>
32346<td><ins>amortized constant</ins></td>
32347</tr>
32348</tbody></table>
32349</blockquote>
32350
32351<p>
32352In 23.2.5 [unord.req] Table 87, add:
32353</p>
32354
32355<blockquote>
32356<table border="1">
32357<caption>Table 87 -- Unordered associative container requirements (in addition to container)</caption>
32358<tbody><tr>
32359<th>Expression</th>
32360<th>Return type</th>
32361<th>Assertion/note<br>pre-/post-condition</th>
32362<th>Complexity</th>
32363</tr>
32364<tr><td><tt>a.erase(q)</tt></td>
32365<td>...</td>
32366<td>...</td>
32367<td>...</td>
32368</tr><tr>
32369<td><ins><tt>a.extract(q)</tt></ins></td>
32370<td><ins><tt>pair&lt;key_type, iterator&gt;</tt></ins></td>
32371<td><ins>Extracts the element pointed to by <tt>q</tt> and erases it from the <tt>set</tt>. 
32372Returns a <tt>pair</tt> containing the value pointed to by <tt>q</tt> and an <tt>iterator</tt>
32373pointing to the element immediately following <tt>q</tt> prior to the element being
32374erased. If no such element 
32375exists, returns <tt>a.end()</tt>.</ins></td>
32376<td><ins>amortized constant</ins></td>
32377</tr>
32378</tbody></table>
32379</blockquote>
32380
32381
32382
32383
32384
32385<hr>
32386<h3><a name="1042"></a>1042. Response to UK 244</h3>
32387<p><b>Section:</b> 23.3 [sequences] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
32388 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-10-23</p>
32389<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>
32390<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
32391<p><b>Discussion:</b></p>
32392
32393<p><b>Addresses UK 244</b></p>
32394
32395<p>
32396The validity of the expression <tt>&amp;a[n] == &amp;a[0] + n</tt> is contingent on
32397<tt>operator&amp;</tt> doing the "right thing" (as captured by the <tt>CopyConstructible</tt>
32398requirements in table 30 in C++2003). However this constraint has been
32399lost in the Concepts of C++0x. This applies to <tt>vector</tt> and <tt>array</tt> (it
32400actually applies to <tt>string</tt> also, but that's a different chapter, so I'll
32401file a separate comment there and cross-reference).
32402</p>
32403
32404<p>
32405Suggested solution:
32406</p>
32407
32408<p>
32409Define a <tt>ContiguousStrorage</tt> and apply it to
32410<tt>vector</tt>, <tt>array</tt> and <tt>string</tt>.
32411</p>
32412
32413<p><i>[
32414Summit:
32415]</i></p>
32416
32417
32418<blockquote>
32419Agree with the issue but not the details of the proposed solution. Walter to
32420provide wording for the new concept.
32421</blockquote>
32422
32423<p><i>[
32424Post Summit Alisdair adds:
32425]</i></p>
32426
32427
32428<blockquote>
32429Another LWG subgroup wondered if this concept
32430should extend to <tt>complex&lt;T&gt;</tt>, and so not be built on the container concept at
32431all?
32432</blockquote>
32433
32434<p><i>[
324352009-07 post-Frankfurt:
32436]</i></p>
32437
32438
32439<blockquote>
32440Leave Open, pending a post-Concepts Working Draft.
32441</blockquote>
32442
32443<p><i>[
324442009-10 Santa Cruz:
32445]</i></p>
32446
32447
32448<blockquote>
32449Mark issue 1042 as NAD, in rationale state that this was solved by removal of concepts.
32450</blockquote>
32451
32452
32453
32454<p><b>Proposed resolution:</b></p>
32455<p>
32456Add to <tt>&lt;container_concepts&gt;</tt> synopsis in  [container.concepts]
32457</p>
32458
32459<blockquote><pre><ins>concept&lt; typename C &gt; ContiguousStorageContainer <i>see below</i>;</ins>
32460</pre></blockquote>
32461
32462<p>
32463Add a new section to the end of  [container.concepts]
32464</p>
32465
32466<blockquote>
32467<p>
3246823.1.6.x ContiguousStorageContainer concept [container.concepts.contiguous]
32469</p>
32470
32471<pre>concept ContiguousStorageContainer&lt; typename C &gt;
32472  : Container&lt;C&gt;
32473{
32474  value_type* data(C&amp;);
32475
32476  axiom Contiguity(C&amp; c, size_type i) {
32477    if( i &lt; size(c) ) {
32478         addressof( * (data(c) + i) )
32479      == addressof( * advance(data(c), i) );
32480    }
32481  }
32482}
32483</pre>
32484
32485<p>
32486The <tt>ContiguousStorageContainer</tt> concept describes a container whose elements
32487are allocated in a single region of memory, and are stored sequentially
32488without intervening padding other than to meet alignment requirements.
32489For example, the elements may be stored in a
32490single array of suitable length.
32491</p>
32492
32493<pre>value_type * data( C&amp; );
32494</pre>
32495
32496<blockquote>
32497<i>Returns:</i> a pointer to the first element in the region of storage.
32498Result is unspecified for an empty container.
32499</blockquote>
32500
32501</blockquote>
32502
32503<p>
32504Change 23.3.1 [array] p1:
32505</p>
32506
32507<blockquote>
32508-1- The header <tt>&lt;array&gt;</tt> defines a class template for
32509storing fixed-size sequences of objects. An <tt>array</tt> supports
32510random access iterators. An instance of <tt>array&lt;T, N&gt;</tt>
32511stores <tt>N</tt> elements of type <tt>T</tt>, so that <tt>size() ==
32512N</tt> is an invariant. The elements of an <tt>array</tt> are stored
32513contiguously, meaning that <del>if <tt>a</tt> is</del> an
32514<tt>array&lt;T, N&gt;</tt> <del>then it obeys the identity <tt>&amp;a[n]
32515== &amp;a[0] + n</tt> for all <tt>0 &lt;= n &lt; N</tt></del>
32516<ins>satisfies the concept <tt>ContiguousStorageContainer&lt; array&lt;T,
32517N&gt;&gt;</tt></ins>.
32518</blockquote>
32519
32520<p>
32521Add to the synopsis in 23.3.1 [array]:
32522</p>
32523
32524<blockquote><pre>    ...
32525    T * data(); 
32526    const T * data() const; 
32527  };
32528
32529  <ins>template&lt; typename T, size_t N &gt;</ins>
32530    <ins>concept_map ContiguousStorageContainer&lt; array&lt;T, N&gt;&gt; {};</ins>
32531} 
32532</pre></blockquote>
32533
32534<p>
32535Change 23.3.6 [vector] p1:
32536</p>
32537
32538<blockquote>
32539A <tt>vector</tt> is a sequence container that supports random access
32540iterators. In addition, it supports (amortized) constant time insert and
32541erase operations at the end; insert and erase in the middle take linear
32542time. Storage management is handled automatically, though hints can be
32543given to improve efficiency. The elements of a vector are stored
32544contiguously, meaning that <del>if <tt>v</tt> is</del> a
32545<tt>vector&lt;T, Alloc&gt;</tt> <ins>(</ins>where <tt>T</tt> is some
32546type other than <tt>bool</tt><ins>)</ins><del>, then it obeys the
32547identity <tt>&amp;v[n] == &amp;v[0] + n</tt> for all <tt>0 &lt;= n &lt;
32548v.size()</tt></del> <ins>satisfies the concept <tt>ContiguousStorageContainer&lt;
32549vector&lt; T, Alloc&gt;&gt;</tt></ins>.
32550</blockquote>
32551
32552<p>
32553Add at the end of the synopsis in 23.3.6 [vector] p2:
32554</p>
32555
32556<blockquote><pre><ins>template&lt; typename T, typename A &gt;
32557  requires !SameType&lt; T, bool &gt;
32558  concept_map ContiguousStorageContainer&lt; vector&lt;T, A&gt;&gt; {};</ins>
32559</pre></blockquote>
32560
32561
32562
32563<p><b>Rationale:</b></p>
32564Solved by removal of concepts.
32565
32566
32567
32568
32569
32570<hr>
32571<h3><a name="1043"></a>1043. Response to US 91</h3>
32572<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#NAD%20Editorial">NAD Editorial</a>
32573 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-10-26</p>
32574<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>
32575<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
32576<p><b>Discussion:</b></p>
32577
32578<p><b>Addresses US 91</b></p>
32579
32580<p>
32581It is unclear whether or not a failed <tt>compare_exchange</tt> is a RMW operation
32582(as used in 1.10 [intro.multithread]).
32583</p>
32584
32585<p>
32586Suggested solution:
32587</p>
32588
32589<p>
32590Make failing <tt>compare_exchange</tt> operations <b>not</b> be RMW.
32591</p>
32592
32593<p><i>[
32594Anthony Williams adds:
32595]</i></p>
32596
32597
32598<blockquote>
32599In 29.6 [atomics.types.operations] p18 it says that "These
32600operations are atomic read-modify-write operations" (final sentence).
32601This is overly restrictive on the implementations of
32602<tt>compare_exchange_weak</tt> and <tt>compare_exchange_strong</tt> on platforms without a
32603native CAS instruction.
32604</blockquote>
32605
32606
32607<p><i>[
32608Summit:
32609]</i></p>
32610
32611
32612<blockquote>
32613Group agrees with the resolution as proposed by Anthony Williams in the attached note.
32614</blockquote>
32615
32616<p><i>[
32617Batavia (2009-05):
32618]</i></p>
32619
32620<blockquote>
32621We recommend the proposed resolution be reviewed
32622by members of the Concurrency Subgroup.
32623</blockquote>
32624
32625<p><i>[
326262009-07 post-Frankfurt:
32627]</i></p>
32628
32629
32630<blockquote>
32631This is likely to be addressed by Lawrence's upcoming paper. He will
32632adopt the proposed resolution.
32633</blockquote>
32634
32635<p><i>[
326362009-08-17 Handled by
32637<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2925.html">N2925</a>.
32638]</i></p>
32639
32640
32641<p><i>[
326422009-10 Santa Cruz:
32643]</i></p>
32644
32645
32646<blockquote>
32647NAD Editorial.  Solved by
32648<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
32649</blockquote>
32650
32651
32652
32653<p><b>Proposed resolution:</b></p>
32654<p>
32655Change 29.6 [atomics.types.operations] p18:
32656</p>
32657
32658<blockquote>
32659-18- <i>Effects:</i> Atomically, compares the value pointed to by
32660<tt>object</tt> or by <tt>this</tt> for equality with that in
32661<tt>expected</tt>, and if true, replaces the value pointed to by
32662<tt>object</tt> or by <tt>this</tt> with desired, and if false, updates
32663the value in <tt>expected</tt> with the value pointed to by
32664<tt>object</tt> or by <tt>this</tt>. Further, if the comparison is true,
32665memory is affected according to the value of <tt>success</tt>, and if the
32666comparison is false, memory is affected according to the value of
32667<tt>failure</tt>. When only one <tt>memory_order</tt> argument is
32668supplied, the value of <tt>success</tt> is <tt>order</tt>, and the value
32669of <tt>failure</tt> is <tt>order</tt> except that a value of
32670<tt>memory_order_acq_rel</tt> shall be replaced by the value
32671<tt>memory_order_acquire</tt> and a value of
32672<tt>memory_order_release</tt> shall be replaced by the value
32673<tt>memory_order_relaxed</tt>. <ins>If the comparison is <tt>true</tt>, </ins>
32674<del>T</del><ins>t</ins>hese operations are atomic
32675read-modify-write operations (1.10). 
32676<ins>If the comparison is <tt>false</tt>, these
32677operations are atomic load operations.</ins>
32678</blockquote>
32679
32680
32681
32682
32683
32684
32685<hr>
32686<h3><a name="1046"></a>1046. Response to UK 329</h3>
32687<p><b>Section:</b> 30.6 [futures] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
32688 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-10-26</p>
32689<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#futures">issues</a> in [futures].</p>
32690<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
32691<p><b>Discussion:</b></p>
32692
32693<p><b>Addresses UK 329</b></p>
32694
32695<p>
32696<tt>future</tt>, <tt>promise</tt> and <tt>packaged_task</tt> provide a
32697framework for creating future values, but a simple function to tie all
32698three components together is missing. Note that we only need a *simple*
32699facility for C++0x. Advanced thread pools are to be left for TR2.
32700</p>
32701
32702<p>
32703Simple Proposal:
32704</p>
32705
32706<p>
32707Provide a simple function along the lines of: 
32708</p>
32709<blockquote><pre>template&lt; typename F, typename ... Args &gt;
32710  requires Callable&lt; F, Args... &gt;
32711    future&lt; Callable::result_type &gt; async( F&amp;&amp; f, Args &amp;&amp; ... ); 
32712</pre></blockquote>
32713
32714<p>
32715Semantics are similar to creating a <tt>thread</tt> object with a <tt>packaged_task</tt>
32716invoking <tt>f</tt> with <tt>forward&lt;Args&gt;(args...)</tt>
32717but details are left unspecified to allow different scheduling and thread
32718spawning implementations. 
32719</p>
32720<p>
32721It is unspecified whether a task submitted to async is run on its own thread
32722or a thread previously used for another async task. If a call to <tt>async</tt>
32723succeeds, it shall be safe to wait for it from any thread. 
32724</p>
32725<p>
32726The state of <tt>thread_local</tt> variables shall be preserved during <tt>async</tt> calls. 
32727</p>
32728<p>
32729No two incomplete async tasks shall see the same value of
32730<tt>this_thread::get_id()</tt>. 
32731</p>
32732<p>
32733[<i>Note:</i> this effectively forces new tasks to be run on a new thread, or a
32734fixed-size pool with no queue. If the 
32735library is unable to spawn a new thread or there are no free worker threads
32736then the <tt>async</tt> call should fail. <i>--end note</i>] 
32737</p>
32738
32739<p><i>[
32740Summit:
32741]</i></p>
32742
32743
32744<blockquote>
32745<p>
32746The concurrency subgroup has revisited this issue and decided that it
32747could be considered a defect according to the Kona compromise. A task
32748group was formed lead by Lawrence Crowl and Bjarne Stroustrup to write a
32749paper for Frankfort proposing a simple asynchronous launch facility
32750returning a <tt>future</tt>. It was agreed that the callable must be run on a
32751separate thread from the caller, but not necessarily a brand-new thread.
32752The proposal might or might not allow for an implementation that uses
32753fixed-size or unlimited thread pools.
32754</p>
32755<p>
32756Bjarne in c++std-lib-23121: I think that what we agreed was that to
32757avoid deadlock <tt>async()</tt> would almost certainly be specified to  launch in
32758a different thread from the thread that executed <tt>async()</tt>, but I don't
32759think it was a specific design constraint.
32760</p>
32761</blockquote>
32762
32763<p><i>[
327642009-10 Santa Cruz:
32765]</i></p>
32766
32767
32768<blockquote>
32769Proposed resolution: see
32770<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2996.html">N2996</a>
32771(Herb's and Lawrence's paper on Async). Move state to NAD editorial.
32772</blockquote>
32773
32774
32775
32776<p><b>Proposed resolution:</b></p>
32777
32778
32779
32780
32781
32782<hr>
32783<h3><a name="1047"></a>1047. Response to UK 334</h3>
32784<p><b>Section:</b> 30.6.6 [futures.unique_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
32785 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-10-26</p>
32786<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>
32787<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
32788<p><b>Discussion:</b></p>
32789
32790<p><b>Addresses UK 334</b></p>
32791
32792<p>
32793Behaviour of <tt>get()</tt> is undefined if calling <tt>get()</tt> while
32794not <tt>is_ready()</tt>. The intent is that <tt>get()</tt> is a blocking
32795call, and will wait for the future to become ready.
32796</p>
32797
32798<p><i>[
32799Summit:
32800]</i></p>
32801
32802
32803<blockquote>
32804<p>
32805Agree, move to Review.
32806</p>
32807</blockquote>
32808
32809<p><i>[
328102009-04-03 Thomas J. Gritzan adds:
32811]</i></p>
32812
32813
32814<blockquote>
32815<p>
32816This issue also applies to <tt>shared_future::get()</tt>.
32817</p>
32818
32819<p>
32820Suggested wording:
32821</p>
32822
32823<p>
32824Add a paragraph to  [futures.shared_future]:
32825</p>
32826
32827<blockquote><pre>void shared_future&lt;void&gt;::get() const;
32828</pre>
32829<blockquote>
32830<i>Effects:</i> If <tt>is_ready()</tt> would return <tt>false</tt>, block on the asynchronous 
32831result associated with <tt>*this</tt>.
32832</blockquote>
32833</blockquote>
32834</blockquote>
32835
32836<p><i>[
32837Batavia (2009-05):
32838]</i></p>
32839
32840<blockquote>
32841It is not clear to us that this is an issue,
32842because the proposed resolution's Effects clause seems to duplicate
32843information already present in the Synchronization clause.
32844Keep in Review status.
32845</blockquote>
32846
32847<p><i>[
328482009-10 Santa Cruz:
32849]</i></p>
32850
32851
32852<blockquote>
32853NAD Editorial.  Solved by
32854<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.html">N2997</a>.
32855</blockquote>
32856
32857
32858
32859<p><b>Proposed resolution:</b></p>
32860<p>
32861Add a paragraph to 30.6.6 [futures.unique_future]:
32862</p>
32863
32864<blockquote><pre>R&amp;&amp; unique_future::get(); 
32865R&amp; unique_future&lt;R&amp;&gt;::get(); 
32866void unique_future&lt;void&gt;::get();
32867</pre>
32868<blockquote>
32869<p><i>Note:</i>...</p>
32870<p>
32871<ins><i>Effects:</i> If <tt>is_ready()</tt> would return <tt>false</tt>,
32872block on the asynchronous result associated with <tt>*this</tt>.</ins>
32873</p>
32874<p>
32875<i>Synchronization:</i> if <tt>*this</tt> is associated with a
32876<tt>promise</tt> object, the completion of <tt>set_value()</tt> or
32877<tt>set_exception()</tt> to that <tt>promise</tt> happens before (1.10)
32878<tt>get()</tt> returns.
32879</p>
32880</blockquote>
32881</blockquote>
32882
32883
32884
32885
32886
32887<hr>
32888<h3><a name="1048"></a>1048. Response to UK 335</h3>
32889<p><b>Section:</b> 30.6.6 [futures.unique_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
32890 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-10-26</p>
32891<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>
32892<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
32893<p><b>Discussion:</b></p>
32894
32895<p><b>Addresses UK 335</b></p>
32896
32897<p>
32898<tt>std::unique_future</tt> is <tt>MoveConstructible</tt>, so you can transfer the
32899association with an asynchronous result from one instance to another.
32900However, there is no way to determine whether or not an instance has
32901been moved from, and therefore whether or not it is safe to wait for it.
32902</p>
32903
32904<blockquote><pre>std::promise&lt;int&gt; p;
32905std::unique_future&lt;int&gt; uf(p.get_future());
32906std::unique_future&lt;int&gt; uf2(std::move(uf));
32907uf.wait(); <font color="#c80000">// oops, uf has no result to wait for. </font>
32908</pre></blockquote>
32909
32910<p>
32911Suggest we add a <tt>waitable()</tt> function to <tt>unique_future</tt>
32912(and <tt>shared_future</tt>) akin to <tt>std::thread::joinable()</tt>,
32913which returns <tt>true</tt> if there is an associated result to wait for
32914(whether or not it is ready).
32915</p>
32916
32917<p>
32918Then we can say:
32919</p>
32920
32921<blockquote><pre>if(uf.waitable()) uf.wait();
32922</pre></blockquote>
32923
32924<p><i>[
32925Summit:
32926]</i></p>
32927
32928
32929<blockquote>
32930<p>
32931Create an issue. Requires input from Howard. Probably NAD.
32932</p>
32933</blockquote>
32934
32935<p><i>[
32936Post Summit, Howard thows in his two cents:
32937]</i></p>
32938
32939
32940<blockquote>
32941<p>
32942Here is a copy/paste of my last prototype of <tt>unique_future</tt> which was
32943several years ago.  At that time I was calling <tt>unique_future</tt> <tt>future</tt>:
32944</p>
32945
32946<blockquote><pre>template &lt;class R&gt;
32947class future
32948{
32949public:
32950    typedef R result_type;
32951private:
32952    future(const future&amp;);// = delete;
32953    future&amp; operator=(const future&amp;);// = delete;
32954
32955    template &lt;class R1, class F1&gt; friend class prommise;
32956public:
32957    future();
32958    ~future();
32959
32960    future(future&amp;&amp; f);
32961    future&amp; operator=(future&amp;&amp; f);
32962
32963    void swap(future&amp;&amp; f);
32964
32965    <b>bool joinable() const;</b>
32966    bool is_normal() const;
32967    bool is_exceptional() const;
32968    bool is_ready() const;
32969
32970    R get();
32971
32972    void join();
32973    template &lt;class ElapsedTime&gt;
32974        bool timed_join(const ElapsedTime&amp;);
32975};
32976</pre></blockquote>
32977
32978<p>
32979<tt>shared_future</tt> had a similar interface.  I intentionally reused
32980the <tt>thread</tt> interface where possible to lessen the learning
32981curve std::lib clients will be faced with.
32982</p>
32983</blockquote>
32984
32985<p><i>[
329862009-10 Santa Cruz:
32987]</i></p>
32988
32989
32990<blockquote>
32991NAD Editorial.  Solved by
32992<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.html">N2997</a>.
32993</blockquote>
32994
32995
32996
32997<p><b>Proposed resolution:</b></p>
32998
32999
33000
33001
33002
33003<hr>
33004<h3><a name="1049"></a>1049. Response to UK 339</h3>
33005<p><b>Section:</b> 30.6.5 [futures.promise] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
33006 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-10-26</p>
33007<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>
33008<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
33009<p><b>Discussion:</b></p>
33010
33011<p><b>Addresses UK 339</b></p>
33012
33013<p>
33014Move assignment is goiing in the wrong direction, assigning from
33015<tt>*this</tt> to the passed rvalue, and then returning a reference to
33016an unusable <tt>*this</tt>.
33017</p>
33018
33019<p><i>[
33020Summit:
33021]</i></p>
33022
33023
33024<blockquote>
33025<p>
33026Agree, move to Review.
33027</p>
33028</blockquote>
33029
33030<p><i>[
33031Batavia (2009-05):
33032]</i></p>
33033
33034<blockquote>
33035We recommend deferring this issue until after Detlef's paper (on futures)
33036has been issued.
33037</blockquote>
33038
33039<p><i>[
330402009-10 Santa Cruz:
33041]</i></p>
33042
33043
33044<blockquote>
33045NAD Editorial.  Solved by
33046<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.html">N2997</a>.
33047</blockquote>
33048
33049
33050
33051<p><b>Proposed resolution:</b></p>
33052<p>
33053Strike 30.6.5 [futures.promise] p6 and change p7:
33054</p>
33055
33056<blockquote><pre>promise&amp; operator=(promise&amp;&amp; rhs);
33057</pre>
33058<blockquote>
33059<p>
33060<del>-6- <i>Effects:</i> move assigns its associated state to <tt>rhs</tt>.</del>
33061</p>
33062<p>
33063-7- <i>Postcondition:</i> <del><tt>*this</tt> has no associated
33064state.</del> <ins>associated state of <tt>*this</tt> is the same as the
33065associated state of <tt>rhs</tt> before the call. <tt>rhs</tt> has no
33066associated state.</ins>
33067</p>
33068</blockquote>
33069</blockquote>
33070
33071
33072
33073
33074
33075
33076<hr>
33077<h3><a name="1050"></a>1050. Response to UK 340</h3>
33078<p><b>Section:</b> 30.6.5 [futures.promise] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
33079 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-10-26</p>
33080<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>
33081<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
33082<p><b>Discussion:</b></p>
33083
33084<p><b>Addresses UK 340</b></p>
33085
33086<p>
33087There is an implied postcondition for <tt>get_future()</tt> that the state of the
33088<tt>promise</tt> is transferred into the <tt>future</tt> leaving the <tt>promise</tt> with no
33089associated state. It should be spelled out.
33090</p>
33091
33092<p><i>[
33093Summit:
33094]</i></p>
33095
33096
33097<blockquote>
33098<p>
33099Agree, move to Review.
33100</p>
33101</blockquote>
33102
33103<p><i>[
331042009-04-03 Thomas J. Gritzan adds:
33105]</i></p>
33106
33107
33108<blockquote>
33109<p>
33110<tt>promise::get_future()</tt> must not invalidate the state of the promise object. 
33111</p>
33112<p>
33113A promise is used like this: 
33114</p>
33115<blockquote><pre>promise&lt;int&gt; p; 
33116unique_future&lt;int&gt; f = p.get_future(); 
33117<font color="#c80000">// post 'p' to a thread that calculates a value </font>
33118<font color="#c80000">// use 'f' to retrieve the value. </font>
33119</pre></blockquote>
33120<p>
33121So <tt>get_future()</tt> must return an object that shares the same associated 
33122state with <tt>*this</tt>. 
33123</p>
33124<p>
33125But still, this function should throw an <tt>future_already_retrieved</tt> error 
33126when it is called twice. 
33127</p>
33128<p>
33129<tt>packaged_task::get_future()</tt> throws <tt>std::bad_function_call</tt> if its <tt>future</tt>
33130was already retrieved. It should throw 
33131<tt>future_error(future_already_retrieved)</tt>, too. 
33132</p>
33133<p>
33134Suggested resolution: 
33135</p>
33136<p>
33137Replace p12/p13 30.6.5 [futures.promise]: 
33138</p>
33139<blockquote>
33140<p>
33141-12- <i>Throws:</i> <tt>future_error</tt> if <del><tt>*this</tt> has no associated state</del>
33142<ins>the <tt>future</tt> has already been retrieved</ins>.
33143</p>
33144<p>
33145-13- <i>Error conditions:</i> <tt>future_already_retrieved</tt> if <del><tt>*this</tt>
33146has no associated state</del>
33147<ins>the <tt>future</tt> associated with 
33148the associated state has already been retrieved</ins>.
33149</p>
33150<p>
33151<ins><i>Postcondition:</i> The returned object and <tt>*this</tt> share the associated state.</ins>
33152</p>
33153</blockquote>
33154<p>
33155Replace p14 30.6.10 [futures.task]: 
33156</p>
33157<blockquote>
33158<p>
33159-14- <i>Throws:</i> <tt><del>std::bad_function_call</del> <ins>future_error</ins></tt> if the future <del>associated with
33160the task</del> has already been retrieved.
33161</p>
33162
33163<p><ins>
33164<i>Error conditions:</i> <tt>future_already_retrieved</tt> if the <tt>future</tt> associated with 
33165the task has already been retrieved. 
33166</ins></p>
33167<p>
33168<ins><i>Postcondition:</i> The returned object and <tt>*this</tt> share the associated task.</ins>
33169</p>
33170</blockquote>
33171</blockquote>
33172
33173<p><i>[
33174Batavia (2009-05):
33175]</i></p>
33176
33177<blockquote>
33178Keep in Review status
33179pending Detlef's forthcoming paper on futures.
33180</blockquote>
33181
33182<p><i>[
331832009-10 Santa Cruz:
33184]</i></p>
33185
33186
33187<blockquote>
33188NAD Editorial.  Solved by
33189<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.html">N2997</a>.
33190</blockquote>
33191
33192
33193
33194<p><b>Proposed resolution:</b></p>
33195<p>
33196Add after p13 30.6.5 [futures.promise]:
33197</p>
33198
33199<blockquote><pre>unique_future&lt;R&gt; get_future();
33200</pre>
33201<blockquote>
33202<p>
33203-13- ...
33204</p>
33205<p>
33206<i>Postcondition:</i> <tt>*this</tt> has no associated state.
33207</p>
33208</blockquote>
33209</blockquote>
33210
33211
33212
33213
33214
33215
33216<hr>
33217<h3><a name="1051"></a>1051. Response to UK 279</h3>
33218<p><b>Section:</b> 24.5.1.3.12 [reverse.iter.opindex], 24.5.3.3.12 [move.iter.op.index] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
33219 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-10-24</p>
33220<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
33221<p><b>Discussion:</b></p>
33222
33223<p><b>Addresses UK 279</b></p>
33224
33225<p>
33226The 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
33227reasoning no longer applies as there are at least two ways to get the right
33228return type with the new language facilities added since the previous
33229standard. 
33230</p>
33231
33232<p>
33233Proposal: Specify the return type using either decltype or the Iter concept_map.
33234</p>
33235
33236<p><i>[
33237Summit:
33238]</i></p>
33239
33240
33241<blockquote>
33242<p>
33243Under discussion. This is a general question about all iterator
33244adapters.
33245</p>
33246</blockquote>
33247
33248<p><i>[
33249Howard adds post Summit:
33250]</i></p>
33251
33252
33253<blockquote>
33254I am requesting test cases to demonstrate a position.
33255</blockquote>
33256
33257<p><i>[
332582009-07-24 Daniel adds:
33259]</i></p>
33260
33261
33262<blockquote>
33263<p>
33264I recommend NAD. Without concepts we can no longer
33265restrict this member in a trivial way. Using <tt>decltype</tt> the
33266declaration would be along the lines of
33267</p>
33268<blockquote><pre>static const Iter&amp; __base(); // not defined
33269auto operator[](difference_type n) const -&gt; decltype(__base()[-n-1]);
33270</pre></blockquote>
33271
33272<p>
33273but once <tt>reverse_iterator</tt> is instantiated for some given type
33274<tt>Iter</tt> which cannot form a well-formed expression <tt>__base()[-n-1]</tt>
33275this would cause an ill-formed function declaration, diagnostic
33276required, and no silent SFINAE elimination.
33277</p>
33278
33279</blockquote>
33280
33281<p><i>[
332822009-10 Santa Cruz:
33283]</i></p>
33284
33285
33286<blockquote>
33287Moved to NAD.
33288</blockquote>
33289
33290<p><i>[
332912009-10-22 Daniel adds:
33292]</i></p>
33293
33294
33295<blockquote>
33296<p>
33297IMO, my original comment regarding ill-formedness of the described
33298construction is still correct, but I must add that I should weaken my
33299assertion "Without concepts we can no longer restrict this member in
33300a trivial way".
33301</p>
33302
33303<p>
33304In fact with the existence of default template arguments for function
33305templates it is not too hard to implement this like as follows, which
33306shows that we can indeed simulate to some sense constrained
33307member functions in C++0x.
33308</p>
33309
33310<p>
33311My example does not really proof that the specification is easy, but
33312it should be possible. I assume that the implementation would not
33313be ABI compatible, though.
33314</p>
33315
33316<p>
33317It is now your own decision how to proceed ;-)
33318</p>
33319
33320<blockquote><pre>#include &lt;type_traits&gt;
33321#include &lt;cstddef&gt;
33322
33323template&lt;class T&gt;
33324typename std::add_rvalue_reference&lt;T&gt;::type declval();
33325
33326template&lt;class It&gt;
33327struct reverse_iterator {
33328    It base;
33329    
33330    typedef std::ptrdiff_t difference_type;
33331    
33332    template&lt;class U = It, class Res =
33333     decltype(declval&lt;const U&amp;&gt;()[declval&lt;difference_type&gt;()])
33334    &gt;
33335    Res operator[](difference_type n) const  {
33336        return base[-n-1];
33337    }    
33338};
33339
33340struct MyIter {
33341};
33342
33343int main() {
33344    reverse_iterator&lt;int*&gt; ri;
33345    ri[0] = 2;
33346    reverse_iterator&lt;MyIter&gt; ri2;
33347}
33348</pre></blockquote>
33349
33350<p>
33351The above declaration could be simplified, but the ideal solution
33352</p>
33353
33354<blockquote><pre>template&lt;class U = It&gt;
33355  decltype(declval&lt;const U&amp;&gt;()[declval&lt;difference_type&gt;()])
33356     operator[](difference_type n) const;
33357</pre></blockquote>
33358
33359<p>
33360does not work yet on gcc 4.4.1.
33361</p>
33362
33363</blockquote>
33364
33365
33366
33367
33368<p><b>Proposed resolution:</b></p>
33369
33370
33371
33372
33373
33374<hr>
33375<h3><a name="1053"></a>1053. Response to UK 295</h3>
33376<p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
33377 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-10-23</p>
33378<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>
33379<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>
33380<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
33381<p><b>Discussion:</b></p>
33382
33383<p><b>Addresses UK 295</b></p>
33384
33385<p>
33386There is a level of redundancy in the library specification for many
33387algorithms that can be eliminated with the combination of concepts and
33388default parameters for function templates. Eliminating redundancy simplified
33389specification and reduces the risk of introducing accidental
33390inconsistencies.
33391</p>
33392<p>
33393Proposed resolution: Adopt
33394<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2743.pdf">N2743</a>.
33395</p>
33396
33397<p><i>[
33398Summit:
33399]</i></p>
33400
33401
33402<blockquote>
33403<p>
33404NAD, this change would break code that takes the address of an
33405algorithm.
33406</p>
33407</blockquote>
33408
33409<p><i>[
33410Post Summit Alisdair adds:
33411]</i></p>
33412
33413
33414<blockquote>
33415<p>
33416Request 'Open'.  The issues in the paper go beyond just reducing
33417the number of signatures, but cover unifying the idea of the ordering
33418operation used by algorithms, containers and other library components.  At
33419least, it takes a first pass at the problem.
33420</p>
33421
33422<p>
33423For me (personally) that was the more important part of the paper, and not
33424clearly addressed by the Summit resolution.
33425</p>
33426</blockquote>
33427
33428<p><i>[
334292009-10 Santa Cruz:
33430]</i></p>
33431
33432
33433<blockquote>
33434Too inventive, too late, would really need a paper. Moved to NAD Future.
33435</blockquote>
33436
33437
33438
33439<p><b>Proposed resolution:</b></p>
33440
33441
33442
33443
33444
33445<hr>
33446<h3><a name="1054"></a>1054. <tt>forward</tt> broken</h3>
33447<p><b>Section:</b> 20.3.3 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
33448 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-13  <b>Last modified:</b> 2009-10-26</p>
33449<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>
33450<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
33451<p><b>Discussion:</b></p>
33452
33453<p>
33454This is a placeholder issue to track the fact that we (well I) put the standard
33455into an inconsistent state by requesting that we accept
33456<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html">N2844</a>
33457except for the proposed changes to [forward].
33458</p>
33459
33460<p>
33461There will exist in the post meeting mailing
33462<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2835.html">N2835</a>
33463which in its current state reflects the state of affairs prior to the Summit
33464meeting.  I hope to update it in time for the post Summit mailing, but as I write
33465this issue I have not done so yet.
33466</p>
33467
33468<p><i>[
33469Batavia (2009-05):
33470]</i></p>
33471
33472<blockquote>
33473Move to Open, awaiting the promised paper.
33474</blockquote>
33475
33476<p><i>[
334772009-08-02 Howard adds:
33478]</i></p>
33479
33480
33481<blockquote>
33482<p>
33483My current preferred solution is:
33484</p>
33485
33486<blockquote><pre>template &lt;class T&gt;
33487struct __base_type
33488{
33489   typedef typename remove_cv&lt;typename remove_reference&lt;T&gt;::type&gt;::type type;
33490};
33491
33492template &lt;class T, class U,
33493   class = typename enable_if&lt;
33494       !is_lvalue_reference&lt;T&gt;::value ||
33495        is_lvalue_reference&lt;T&gt;::value &amp;&amp;
33496        is_lvalue_reference&lt;U&gt;::value&gt;::type,
33497   class = typename enable_if&lt;
33498        is_same&lt;typename __base_type&lt;T&gt;::type,
33499                typename __base_type&lt;U&gt;::type&gt;::value&gt;::type&gt;
33500inline
33501T&amp;&amp;
33502forward(U&amp;&amp; t)
33503{
33504   return static_cast&lt;T&amp;&amp;&gt;(t);
33505}
33506</pre></blockquote>
33507
33508<p>
33509This has been tested by Bill, Jason and myself.
33510</p>
33511
33512<p>
33513It allows the following lvalue/rvalue casts:
33514</p>
33515
33516<ol>
33517<li>
33518Cast an lvalue <tt>t</tt> to an lvalue <tt>T</tt> (identity).
33519</li>
33520<li>
33521Cast an lvalue <tt>t</tt> to an rvalue <tt>T</tt>.
33522</li>
33523<li>
33524Cast an rvalue <tt>t</tt> to an rvalue <tt>T</tt> (identity).
33525</li>
33526</ol>
33527
33528<p>
33529It disallows:
33530</p>
33531
33532<ol type="a">
33533<li>
33534Cast an rvalue <tt>t</tt> to an lvalue <tt>T</tt>.
33535</li>
33536<li>
33537Cast one type <tt>t</tt> to another type <tt>T</tt> (such as <tt>int</tt> to <tt>double</tt>).
33538</li>
33539</ol>
33540
33541<p>
33542"a." is disallowed as it can easily lead to dangling references.
33543"b." is disallowed as this function is meant to only change the lvalue/rvalue
33544characteristic of an expression.
33545</p>
33546
33547<p>
33548Jason has expressed concern that "b." is not dangerous and is useful in contexts
33549where you want to "forward" a derived type as a base type.  I find this use case
33550neither dangerous, nor compelling.  I.e. I could live with or without the "b."
33551constraint.  Without it, forward would look like:
33552</p>
33553
33554<blockquote><pre>template &lt;class T, class U,
33555   class = typename enable_if&lt;
33556       !is_lvalue_reference&lt;T&gt;::value ||
33557        is_lvalue_reference&lt;T&gt;::value &amp;&amp;
33558        is_lvalue_reference&lt;U&gt;::value&gt;::type&gt;
33559inline
33560T&amp;&amp;
33561forward(U&amp;&amp; t)
33562{
33563   return static_cast&lt;T&amp;&amp;&gt;(t);
33564}
33565</pre></blockquote>
33566
33567<p>
33568Or possibly:
33569</p>
33570
33571<blockquote><pre>template &lt;class T, class U,
33572   class = typename enable_if&lt;
33573       !is_lvalue_reference&lt;T&gt;::value ||
33574        is_lvalue_reference&lt;T&gt;::value &amp;&amp;
33575        is_lvalue_reference&lt;U&gt;::value&gt;::type,
33576   class = typename enable_if&lt;
33577        is_base_of&lt;typename __base_type&lt;U&gt;::type,
33578                   typename __base_type&lt;T&gt;::type&gt;::value&gt;::type&gt;
33579inline
33580T&amp;&amp;
33581forward(U&amp;&amp; t)
33582{
33583   return static_cast&lt;T&amp;&amp;&gt;(t);
33584}
33585</pre></blockquote>
33586
33587
33588<p>
33589The "promised paper" is not in the post-Frankfurt mailing only because I'm waiting
33590for the non-concepts draft.  But I'm hoping that by adding this information here
33591I can keep people up to date.
33592</p>
33593</blockquote>
33594
33595<p><i>[
335962009-08-02 David adds:
33597]</i></p>
33598
33599
33600<blockquote>
33601<p>
33602<tt>forward</tt> was originally designed to do one thing: perfect forwarding.
33603That is, inside a function template whose actual argument can be a const
33604or non-const lvalue or rvalue, restore the original "rvalue-ness" of the
33605actual argument:
33606</p>
33607
33608<blockquote><pre>template &lt;class T&gt;
33609void f(T&amp;&amp; x)
33610{
33611    // x is an lvalue here.  If the actual argument to f was an
33612    // rvalue, pass static_cast&lt;T&amp;&amp;&gt;(x) to g; otherwise, pass x.
33613    g( forward&lt;T&gt;(x) );
33614}
33615</pre></blockquote>
33616
33617<p>
33618Attempting to engineer <tt>forward</tt> to accomodate uses other than perfect
33619forwarding dilutes its idiomatic meaning.  The solution proposed here
33620declares that <tt>forward&lt;T&gt;(x)</tt> means nothing more than <tt>static_cast&lt;T&amp;&amp;&gt;(x)</tt>,
33621with a patchwork of restrictions on what <tt>T</tt> and <tt>x</tt> can be that can't be
33622expressed in simple English.
33623</p>
33624
33625<p>
33626I would be happy with either of two approaches, whose code I hope (but
33627can't guarantee) I got right.
33628</p>
33629
33630<ol>
33631<li>
33632<p>
33633Use a simple definition of <tt>forward</tt> that accomplishes its original
33634purpose without complications to accomodate other uses:
33635</p>
33636
33637<blockquote><pre>template &lt;class T, class U&gt;
33638T&amp;&amp; forward(U&amp; x)
33639{
33640    return static_cast&lt;T&amp;&amp;&gt;(x);
33641}
33642</pre></blockquote>
33643</li>
33644
33645<li>
33646<p>
33647Use a definition of <tt>forward</tt> that protects the user from as many
33648potential mistakes as possible, by actively preventing <em>all</em> other
33649uses:
33650</p>
33651
33652<blockquote><pre>template &lt;class T, class U&gt;
33653boost::enable_if_c&lt;
33654    // in forward&lt;T&gt;(x), x is a parameter of the caller, thus an lvalue
33655    is_lvalue_reference&lt;U&gt;::value
33656    // in caller's deduced T&amp;&amp; argument, T can only be non-ref or lvalue ref
33657    &amp;&amp; !is_rvalue_reference&lt;T&gt;::value
33658    // Must not cast cv-qualifications or do any type conversions
33659    &amp;&amp; is_same&lt;T&amp;,U&amp;&gt;::value
33660    , T&amp;&amp;&gt;::type forward(U&amp;&amp; a)
33661{
33662    return static_cast&lt;T&amp;&amp;&gt;(a);
33663}
33664</pre></blockquote>
33665</li>
33666</ol>
33667
33668</blockquote>
33669
33670<p><i>[
336712009-09-27 Howard adds:
33672]</i></p>
33673
33674
33675<blockquote>
33676A paper,
33677<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2951.html">N2951</a>,
33678is available which compares several implementations (including David's) with respect to several
33679use cases (including Jason's) and provides wording for one implementation.
33680</blockquote>
33681
33682<p><i>[
336832009-10 Santa Cruz:
33684]</i></p>
33685
33686
33687<blockquote>
33688NAD Editorial.  Solved by
33689<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2951.html">N2951</a>.
33690</blockquote>
33691
33692
33693
33694<p><b>Proposed resolution:</b></p>
33695
33696
33697
33698
33699
33700<hr>
33701<h3><a name="1055"></a>1055. Response to UK 98</h3>
33702<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#NAD%20Editorial">NAD Editorial</a>
33703 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-10-26</p>
33704<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>
33705<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
33706<p><b>Discussion:</b></p>
33707
33708<p><b>Addresses UK 98</b></p>
33709
33710<p>
33711It would be useful to be able to determine the underlying
33712type of an arbitrary enumeration type. This would allow
33713safe casting to an integral type (especially needed for
33714scoped enums, which do not promote), and would allow
33715use of <tt>numeric_limits</tt>. In general it makes generic
33716programming with enumerations easier.
33717</p>
33718
33719<p><i>[
33720Batavia (2009-05):
33721]</i></p>
33722
33723<blockquote>
33724Pete observes (and Tom concurs)
33725that the proposed resolution seems to require compiler support
33726for its implementation,
33727as it seems necessary to look at the range of values
33728of the enumerated type.
33729To a first approximation,
33730a library solution could give an answer based on the size of the type.
33731If the user has specialized <tt>numeric_limits</tt> for the enumerated type,
33732then the library might be able to do better,
33733but there is no such requirement.
33734Keep status as Open
33735and solicit input from CWG.
33736</blockquote>
33737
33738<p><i>[
337392009-05-23 Alisdair adds:
33740]</i></p>
33741
33742
33743<blockquote>
33744Just to confirm that the BSI originator of this comment assumed it did
33745indeed imply a compiler intrinsic.  Rather than request a Core extension, it
33746seemed in keeping with that the type traits interface provides a library API
33747to unspecified compiler features - where we require several other traits
33748(e.g. <tt>has_trivial_*</tt>) to get the 'right' answer now, unlike in TR1.
33749</blockquote>
33750
33751<p><i>[
33752Addressed in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2947.html">N2947</a>.
33753]</i></p>
33754
33755
33756<p><i>[
337572009-10 Santa Cruz:
33758]</i></p>
33759
33760
33761<blockquote>
33762NAD Editorial.  Solved by
33763<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2984.html">N2984</a>.
33764</blockquote>
33765
33766
33767
33768<p><b>Proposed resolution:</b></p>
33769<p>
33770Add a new row to the table in 20.6.7 [meta.trans.other]:
33771</p>
33772
33773<blockquote>
33774<table border="1">
33775<caption>Table 41 -- Other transformations</caption>
33776<tbody><tr>
33777<th>Template</th>
33778<th>Condition</th>
33779<th>Comments</th>
33780</tr>
33781<tr>
33782<td>
33783<tt>template&lt;&nbsp;class&nbsp;T&nbsp;&gt; struct enum_base;</tt>
33784</td>
33785<td>
33786<tt>T</tt> shall be an enumeration type (7.2 [dcl.enum])
33787</td>
33788<td>
33789The member typedef <tt>type</tt> shall name the underlying type
33790of the enum <tt>T</tt>.
33791</td>
33792</tr>
33793</tbody></table>
33794</blockquote>
33795
33796
33797
33798
33799
33800<hr>
33801<h3><a name="1057"></a>1057. <tt>RandomNumberEngineAdaptor</tt></h3>
33802<p><b>Section:</b> 26.5 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
33803 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-07-15</p>
33804<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>
33805<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
33806<p><b>Discussion:</b></p>
33807
33808<p>
33809The <tt>RandomNumberEngineAdaptor</tt> concept breaks precedent in the
33810way the library has been specified by grouping requirements into a
33811concept that is never actually used in the library.
33812</p>
33813<p>
33814This is undoubtedly a very helpful device for documentation, but we are not
33815comfortable with the precedent - especially as we have rejected national
33816body comments on the same grounds.
33817</p>
33818<p>
33819Suggest either removing the concept, or providing an algorithm/type that
33820requires this concept in their definition (such as a factory function to
33821create new engines).
33822</p>
33823<p>
33824The preference is to create a single new algorithm and retain the value of
33825the existing documentation.
33826</p>
33827
33828<p><i>[
33829Batavia (2009-05):
33830]</i></p>
33831
33832<blockquote>
33833<p>
33834Walter points out that it is unlikely that any algorithm would ever
33835require this concept, but that the concept nonetheless is useful as
33836documentation, and (via concept maps) as a means of checking specific adapters.
33837</p>
33838<p>
33839Alisdair disagrees as to the concept's value as documentation.
33840</p>
33841<p>
33842Marc points out that the <tt>RandomNumberDistribution</tt>
33843is also a concept not used elsewhere in the Standard.
33844</p>
33845<p>
33846Pete agrees that a policy of not inventing concepts
33847that aren't used in the Standard is a good starting point,
33848but should not be used as a criterion for rejecting a concept.
33849</p>
33850<p>
33851Move to Open.
33852</p>
33853</blockquote>
33854
33855
33856<p><b>Proposed resolution:</b></p>
33857
33858
33859
33860
33861
33862<hr>
33863<h3><a name="1058"></a>1058. New container issue</h3>
33864<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#NAD%20Editorial">NAD Editorial</a>
33865 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-12  <b>Last modified:</b> 2009-07-13</p>
33866<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</p>
33867<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>
33868<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
33869<p><b>Discussion:</b></p>
33870
33871<p>
33872Sequence containers 23.2.3 [sequence.reqmts]:
33873</p>
33874
33875<p>
33876The return value of new calls added to table 83 are not specified.
33877</p>
33878
33879<p><i>[
33880Batavia (2009-05):
33881]</i></p>
33882
33883<blockquote>
33884<p>
33885We agree with the proposed resolution.
33886</p>
33887<p>
33888Move to NAD Editorial.
33889</p>
33890</blockquote>
33891
33892
33893<p><b>Proposed resolution:</b></p>
33894<p>
33895Add after p6 23.2.3 [sequence.reqmts]:
33896</p>
33897
33898<blockquote>
33899<p>
33900-6- ...
33901</p>
33902<p><ins>
33903The iterator returned from <tt>a.insert(p,rv)</tt> points to the copy of <tt>rv</tt>
33904inserted into <tt>a</tt>.
33905</ins></p>
33906<p><ins>
33907The iterator returned from <tt>a.emplace(p, args)</tt> points to the new
33908element constructed from <tt>args</tt> inserted into <tt>a</tt>.
33909</ins></p>
33910</blockquote>
33911
33912
33913
33914
33915
33916<hr>
33917<h3><a name="1059"></a>1059. Usage of no longer existing FunctionType concept</h3>
33918<p><b>Section:</b> 20.7.15.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
33919 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-03-13  <b>Last modified:</b> 2009-07-16</p>
33920<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</p>
33921<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
33922<p><b>Discussion:</b></p>
33923<p>
33924Due to a deliberate core language decision, the earlier called
33925"foundation" concept <tt>std::FunctionType</tt> had been removed in
33926<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2773.pdf">N2773</a>
33927shortly
33928before the first "conceptualized" version of the WP
33929(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf">N2798</a>)
33930had been
33931prepared. This caused a break of the library, which already used this
33932concept in the adapted definition of <tt>std::function</tt>
33933(20.7 [function.objects]/2, header <tt>&lt;functional&gt;</tt> synopsis and
3393420.7.15.2 [func.wrap.func]).
33935</p>
33936<p>
33937A simple fix would be to either (a) make <tt>std::function</tt>'s primary template
33938unconstrained or to (b) add constraints based on existing (support) concepts.
33939A more advanced fix would (c) introduce a new library concept.
33940</p>
33941<p>
33942The big disadvantage of (a) is, that users can define templates which
33943cause compiler errors during instantiation time because of under-constrainedness
33944and would thus violate the basic advantage of constrained
33945code.
33946</p>
33947<p>
33948For (b), the ideal constraints for <tt>std::function</tt>'s template parameter would
33949be one which excludes everything else but the single provided partial
33950specialization that matches every "free function" type (i.e. any function
33951type w/o cv-qualifier-seq and w/o ref-qualifier).
33952Expressing such a type as as single requirement would be written as
33953</p>
33954<blockquote><pre>template&lt;typename T&gt;
33955requires ReferentType&lt;T&gt; // Eliminate cv void and function types with cv-qual-seq
33956                         //   or ref-qual (depending on core issue #749)
33957      &amp;&amp; PointeeType&lt;T&gt;  // Eliminate reference types
33958      &amp;&amp; !ObjectType&lt;T&gt;  // Eliminate object types
33959</pre></blockquote>
33960<p>
33961Just for completeness approach (c), which would make sense, if the
33962library has more reasons to constrain for free function types:
33963</p>
33964<blockquote><pre>auto concept FreeFunctionType&lt;typename T&gt;
33965  : ReferentType&lt;T&gt;, PointeeType&lt;T&gt;, MemberPointeeType&lt;T&gt;
33966{
33967  requires !ObjectType&lt;T&gt;;
33968}
33969</pre></blockquote>
33970<p>
33971I mention that approach because I expect that free function types belong
33972to the most natural type categories for every days coders. Potential
33973candidates in the library are <tt>addressof</tt> and class template <tt>packaged_task</tt>.
33974</p>
33975
33976<p><i>[
33977Batavia (2009-05):
33978]</i></p>
33979
33980<blockquote>
33981<p>
33982Alisdair would prefer to have a core-supported <tt>FunctionType</tt> concept
33983in order that any future changes be automatically correct
33984without need for a library solution to catch up;
33985he points to type traits as a precedent.
33986Further, he believes that a published concept can't in the future
33987be changed.
33988</p>
33989<p>
33990Bill feels this category of entity would change sufficiently slowly
33991that he would be willing to take the risk.
33992</p>
33993<p>
33994Of the discussed solutions, we tend toward option (c).
33995We like the idea of having a complete taxonomy of native types,
33996and perhaps erred in trimming the set.
33997</p>
33998<p>
33999We would like to have this issue reviewed by Core and would like
34000their feedback.  Move to Open.
34001</p>
34002</blockquote>
34003
34004
34005<p><b>Proposed resolution:</b></p>
34006<ol>
34007<li>
34008<p>
34009Change in 20.7 [function.objects]/2, Header <tt>&lt;functional&gt;</tt> synopsis:
34010</p>
34011<blockquote><pre>// 20.6.16 polymorphic function wrappers:
34012class bad_function_call;
34013template&lt;<del>FunctionType</del><ins>ReferentType F</ins>&gt;
34014<ins>requires PointeeType&lt;F&gt; &amp;&amp; !ObjectType&lt;F&gt;</ins>
34015class function; // undefined
34016</pre></blockquote>
34017</li>
34018<li>
34019<p>
34020Change in 20.7.15.2 [func.wrap.func]:
34021</p>
34022<blockquote><pre>namespace std {
34023template&lt;<del>FunctionType</del><ins>ReferentType F</ins>&gt;
34024<ins>requires PointeeType&lt;F&gt; &amp;&amp; !ObjectType&lt;F&gt;</ins>
34025class function; // undefined
34026</pre></blockquote>
34027</li>
34028</ol>
34029
34030
34031
34032
34033
34034<hr>
34035<h3><a name="1060"></a>1060. Embedded nulls in NTBS</h3>
34036<p><b>Section:</b> 17.5.2.1.4.1 [byte.strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
34037 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-13  <b>Last modified:</b> 2009-07-13</p>
34038<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
34039<p><b>Discussion:</b></p>
34040
34041<p>
34042Definition of null-terminated sequences allow for embedded nulls. This is
34043surprising, and probably not supportable with the intended use cases.
34044</p>
34045
34046<p><i>[
34047Batavia (2009-05):
34048]</i></p>
34049
34050<blockquote>
34051We agree with the issue, but believe this can be handled editorially.
34052Move to NAD Editorial.
34053</blockquote>
34054
34055
34056
34057<p><b>Proposed resolution:</b></p>
34058
34059
34060
34061
34062
34063<hr>
34064<h3><a name="1061"></a>1061. Bad indexing for tuple access to pair (Editorial?)</h3>
34065<p><b>Section:</b> 20.3.5 [pair.astuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
34066 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-13  <b>Last modified:</b> 2009-07-13</p>
34067<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
34068<p><b>Discussion:</b></p>
34069
34070<p>
34071The definition of <tt>get</tt> implies that <tt>get</tt> must return the second element if
34072given a negative integer.
34073</p>
34074
34075<p><i>[
34076Batavia (2009-05):
34077]</i></p>
34078
34079<blockquote>
34080Move to NAD Editorial.
34081</blockquote>
34082
34083
34084
34085<p><b>Proposed resolution:</b></p>
34086<p>
3408720.3.5 [pair.astuple] p5:
34088</p>
34089
34090<blockquote><pre>template&lt;<del>int</del> <ins>size_t</ins> I, class T1, class T2&gt; 
34091  requires True&lt;(I &lt; 2)&gt; 
34092  const P&amp; get(const pair&lt;T1, T2&gt;&amp;);
34093</pre>
34094</blockquote>
34095
34096
34097
34098
34099
34100
34101<hr>
34102<h3><a name="1062"></a>1062. Missing insert_iterator for stacks/queues</h3>
34103<p><b>Section:</b> 24.5.2 [insert.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
34104 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-13  <b>Last modified:</b> 2009-10-20</p>
34105<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>
34106<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
34107<p><b>Discussion:</b></p>
34108
34109<p>
34110It is odd that we have an iterator to insert into a <tt>vector</tt>, but not an
34111iterator to insert into a <tt>vector</tt> that is adapted as a <tt>stack</tt>. The standard
34112container adapters all have a common interface to <tt>push</tt> and <tt>pop</tt> so it should
34113be simple to create an iterator adapter to complete the library support.
34114</p>
34115
34116<p>
34117We should provide an <tt>AdaptedContainer</tt> concept supporting <tt>push</tt> and <tt>pop</tt>
34118operations. Create a new insert iterator and factory function that inserts
34119values into the container by calling <tt>push</tt>.
34120</p>
34121
34122<p><i>[
34123Batavia (2009-05):
34124]</i></p>
34125
34126<blockquote>
34127<p>
34128Walter recommends NAD Future.
34129</p>
34130<p>
34131Move to Open, and recommend deferring the issue until after the next
34132Committee Draft is issued.
34133</p>
34134</blockquote>
34135
34136<p><i>[
341372009-07-29 Howard moves to Tentatively NAD Future.
34138]</i></p>
34139
34140
34141<blockquote>
34142A poll on the LWG reflector voted unanimously to move this issue to Tentatively NAD Future.
34143</blockquote>
34144
34145<p><i>[
341462009 Santa Cruz:
34147]</i></p>
34148
34149
34150<blockquote>
34151Moved to NAD.  The intent of these adapters are to restrict the interfaces.
34152</blockquote>
34153
34154
34155
34156<p><b>Proposed resolution:</b></p>
34157
34158
34159
34160
34161
34162<hr>
34163<h3><a name="1063"></a>1063. 03 iterator compatibilty</h3>
34164<p><b>Section:</b> X [iterator.backward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
34165 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-15  <b>Last modified:</b> 2009-07-16</p>
34166<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
34167<p><b>Discussion:</b></p>
34168
34169<p>
34170Which header must a user <tt>#include</tt> to obtain the library-supplied
34171<tt>concept_maps</tt> declared in this paragraph?
34172</p>
34173
34174<p>
34175This is important information, as existing user code will break if this
34176header is not included, and we should make a point of mandating this header
34177is <tt>#include</tt>-d by library headers likely to make use of it, notably
34178<tt>&lt;algorithm&gt;</tt>.  See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1001">1001</a> for more details.
34179</p>
34180
34181<p><i>[
34182Batavia (2009-05):
34183]</i></p>
34184
34185<blockquote>
34186We agree with the direction of the proposed resolution.
34187Move to Tentatively Ready.
34188</blockquote>
34189
34190<p><i>[
341912009-07 Frankfurt
34192]</i></p>
34193
34194
34195<blockquote>
34196We believe this is NAD Concepts, but this needs to be reviewed against the
34197post-remove-concepts draft.
34198</blockquote>
34199
34200
34201<p><b>Proposed resolution:</b></p>
34202<p><i>Change  [depr.lib.iterator.primitives], Iterator primitives, as
34203indicated:</i></p>
34204
34205<blockquote>
34206  <p>To simplify the use of iterators and provide backward compatibility with
34207  previous C++ Standard Libraries,
34208  the library provides several classes and functions. <ins>Unless otherwise
34209  specified, these classes and functions shall be defined in header <tt>&lt;iterator&gt;</tt>.</ins></p>
34210</blockquote>
34211<p><i>Change X [iterator.backward], Iterator backward compatibility, as
34212indicated:</i></p>
34213<blockquote>
34214  <p>The library provides concept maps that allow iterators specified with
34215  <tt>iterator_traits</tt> to interoperate with
34216  algorithms that require iterator concepts. <ins>These concept maps shall be
34217  defined in the same header that defines the iterator.</ins> [<i>Example:</i></p>
34218</blockquote>
34219
34220
34221
34222
34223
34224<hr>
34225<h3><a name="1064"></a>1064. Response to UK 152</h3>
34226<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#NAD">NAD</a>
34227 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-15  <b>Last modified:</b> 2009-10-23</p>
34228<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
34229<p><b>Discussion:</b></p>
34230
34231<p><b>Addresses UK 152</b></p>
34232
34233<p>
34234Object state is using a definition of object (instance of a class) from
34235outside the standard, rather than the 'region of storage' definiton in
342361.8 [intro.object]p1
34237</p>
34238
34239<p><i>[
34240Summit:
34241]</i></p>
34242
34243<blockquote>
34244We think we're removing this; See X [func.referenceclosure.cons].
34245</blockquote>
34246
34247<p><i>[
342482009-10 Santa Cruz:
34249]</i></p>
34250
34251
34252<blockquote>
34253Mark as NAD.  This will not affect user or implementer code
34254</blockquote>
34255
34256
34257
34258<p><b>Proposed resolution:</b></p>
34259<p>
34260</p>
34261
34262
34263
34264
34265
34266<hr>
34267<h3><a name="1067"></a>1067. simplified wording for inner_product</h3>
34268<p><b>Section:</b> 26.7 [numeric.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
34269 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-17  <b>Last modified:</b> 2009-07-14</p>
34270<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
34271<p><b>Discussion:</b></p>
34272
34273<p>
34274One of the motivating examples for introducing requirements-aliases was to
34275simplify the wording of the <tt>inner_product</tt> requirements.  As the paper
34276adopting the feature and constrained wording for the library went through in
34277the same meeting, it was not possible to make the change at the time.  The
34278simpler form should be adopted now though.  Similarly, most the other
34279numerical algorithms can benefit from a minor cleanup.
34280</p>
34281<p>
34282Note that in each case, the second more generalised form of the algorithm
34283does not benefit, as there are already named constraints supplied by the
34284template type parameters.
34285</p>
34286
34287<p><i>[
342882009-05-02 Daniel adds:
34289]</i></p>
34290
34291
34292<blockquote>
34293<p>
34294one part of the suggested resolution suggests the removal of the
34295<tt>MoveConstructible&lt;T&gt;</tt> requirement from
34296<tt>inner_product</tt>. According to 26.7.2 [inner.product]
34297</p>
34298
34299<blockquote>
34300Computes its result by initializing the accumulator <tt>acc</tt> with the
34301initial value <tt>init</tt>
34302</blockquote>
34303
34304<p>
34305this step requires at least <tt>MoveConstructible</tt>.
34306</p>
34307
34308<p>
34309Therefore I strongly suggest to take this removal back (Note also
34310that the corresponding overload with a functor argument still has
34311the same <tt>MoveConstructible&lt;T&gt;</tt> requirement).
34312</p>
34313</blockquote>
34314
34315<p><i>[
34316Batavia (2009-05):
34317]</i></p>
34318
34319<blockquote>
34320<p>
34321We agree with the proposed resolution as amended by Daniel's suggestion
34322to restore <tt>MoveConstructible</tt>,
34323reflected in the updated proposed resolution below.
34324</p>
34325<p>
34326Move to Tentatively Ready.
34327</p>
34328</blockquote>
34329
34330
34331<p><b>Proposed resolution:</b></p>
34332<p>
34333Change in 26.7 [numeric.ops] and 26.7.1 [accumulate]:
34334</p>
34335
34336<blockquote><pre>template &lt;InputIterator Iter, MoveConstructible T&gt;
34337 requires <ins>add =</ins> HasPlus&lt;T, Iter::reference&gt;
34338       &amp;&amp; HasAssign&lt;T, <del>HasPlus&lt;T, Iter::reference&gt;</del> <ins>add</ins>::result_type&gt;
34339 T accumulate(Iter first, Iter last, T init);
34340</pre></blockquote>
34341
34342<p>
34343Change in 26.7 [numeric.ops] and 26.7.2 [inner.product]:
34344</p>
34345
34346<blockquote><pre>template &lt;InputIterator Iter1, InputIterator Iter2, MoveConstructible T&gt;
34347  requires <ins>mult =</ins> HasMultiply&lt;Iter1::reference, Iter2::reference&gt;
34348        &amp;&amp; <ins>add =</ins> HasPlus&lt;T, <del>HasMultiply&lt;Iter1::reference, Iter2::reference&gt;</del> <ins>mult</ins>::result_type&gt;
34349        &amp;&amp; HasAssign&lt; 
34350             T,
34351             <del>HasPlus&lt;T,
34352                     HasMultiply&lt;Iter1::reference, Iter2::reference&gt;::result_type&gt;</del> <ins>add</ins>::result_type&gt;
34353  T inner_product(Iter1 first1, Iter1 last1, Iter2 first2, T init);
34354</pre></blockquote>
34355
34356<p>
34357Change in 26.7 [numeric.ops] and 26.7.3 [partial.sum]:
34358</p>
34359
34360<blockquote><pre>template &lt;InputIterator InIter, OutputIterator&lt;auto, const InIter::value_type&amp;&gt; OutIter&gt;
34361  requires <ins>add =</ins> HasPlus&lt;InIter::value_type, InIter::reference&gt;
34362        &amp;&amp; HasAssign&lt;InIter::value_type,
34363                     <del>HasPlus&lt;InIter::value_type, InIter::reference&gt;</del> <ins>add</ins>::result_type&gt;
34364        &amp;&amp; Constructible&lt;InIter::value_type, InIter::reference&gt;
34365  OutIter partial_sum(InIter first, InIter last, OutIter result);
34366</pre></blockquote>
34367
34368<p>
34369Change in 26.7 [numeric.ops] and 26.7.4 [adjacent.difference]:
34370</p>
34371
34372<blockquote><pre>template &lt;InputIterator InIter, OutputIterator&lt;auto, const InIter::value_type&amp;&gt; OutIter&gt;
34373  requires <ins>sub =</ins> HasMinus&lt;InIter::value_type, InIter::value_type&gt;
34374        &amp;&amp; Constructible&lt;InIter::value_type, InIter::reference&gt;
34375        &amp;&amp; OutputIterator&lt;OutIter, <del>HasMinus&lt;InIter::value_type, InIter::value_type&gt;</del> <ins>sub</ins>::result_type&gt;
34376        &amp;&amp; MoveAssignable&lt;InIter::value_type&gt;
34377  OutIter adjacent_difference(InIter first, InIter last, OutIter result);
34378</pre></blockquote>
34379
34380
34381
34382
34383
34384
34385<hr>
34386<h3><a name="1072"></a>1072. Is std::hash a constrained template or not?</h3>
34387<p><b>Section:</b> 20.7.16 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
34388 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-19  <b>Last modified:</b> 2009-07-16</p>
34389<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>
34390<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>
34391<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
34392<p><b>Discussion:</b></p>
34393
34394<p>
34395Is <tt>std::hash</tt> a constrained template or not?
34396</p>
34397<p>
34398According to Class template hash 20.7.16 [unord.hash], the definition is:
34399</p>
34400
34401<blockquote><pre>template &lt;class T&gt;
34402struct hash : public std::unary_function&lt;T, std::size_t&gt; {
34403  std::size_t operator()(T val) const;
34404};
34405</pre></blockquote>
34406
34407<p>
34408And so unconstrained.
34409</p>
34410<p>
34411According to the <tt>&lt;functional&gt;</tt> synopsis in p2 Function objects
3441220.7 [function.objects] the template is declared as:
34413</p>
34414
34415<blockquote><pre>template &lt;ReferentType T&gt; struct hash;
34416</pre></blockquote>
34417
34418<p>
34419which would make hash a constrained template.
34420</p>
34421
34422<p><i>[
344232009-03-22 Daniel provided wording.
34424]</i></p>
34425
34426
34427<p><i>[
34428Batavia (2009-05):
34429]</i></p>
34430
34431<blockquote>
34432<p>
34433Alisdair is not certain that Daniel's proposed resolution is sufficient,
34434and recommends we leave the hash template unconstrained for now.
34435</p>
34436<p>
34437Recommend that the Project Editor make the constrained declaration consistent
34438with the definition in order to make the Working Paper internally consistent,
34439and that the issue then be revisited.
34440</p>
34441<p>
34442Move to Open.
34443</p>
34444</blockquote>
34445
34446
34447<p><b>Proposed resolution:</b></p>
34448
34449<p>
34450[To the editor: This resolution is merge-compatible to the
34451resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1078">1078</a>]
34452</p>
34453
34454<ol>
34455<li>
34456<p>
34457In 20.7 [function.objects]/2, header <tt>&lt;functional&gt;</tt> synopsis, change as indicated:
34458</p>
34459
34460<blockquote><pre>// 20.6.17, hash function base template:
34461template &lt;ReferentType T&gt; struct hash; <ins>// undefined</ins>
34462</pre></blockquote>
34463</li>
34464<li>
34465<p>
34466In 20.7.16 [unord.hash]/1 change as indicated:
34467</p>
34468<blockquote><pre>namespace std {
34469 <del>template &lt;class T&gt;
34470 struct hash : public std::unary_function&lt;T, std::size_t&gt; {
34471 std::size_t operator()(T val) const;
34472 };</del>
34473 <ins>template &lt;ReferentType T&gt; struct hash; // undefined</ins>
34474}
34475</pre></blockquote>
34476</li>
34477<li>
34478<p>
34479In 20.7.16 [unord.hash]/2 change as indicated:
34480</p>
34481
34482<blockquote>
34483-2-  <ins>For all library-provided specializations, the template
34484instantiation <tt>hash&lt;T&gt;</tt>
34485  shall provide a public <tt>operator()</tt> with return type <tt>std::size_t</tt> to
34486satisfy the concept
34487  requirement <tt>Callable&lt;const hash&lt;T&gt;, const T&amp;&gt;</tt>. If <tt>T</tt> is an object
34488type or reference to
34489  object, <tt>hash&lt;T&gt;</tt> shall be publicly derived from
34490<tt>std::unary_function&lt;T, std::size_t&gt;</tt>.
34491  </ins> The return value of <tt>operator()</tt> is unspecified, except that
34492equal arguments
34493  shall yield the same result. <tt>operator()</tt> shall not throw exceptions.
34494</blockquote>
34495</li>
34496<li>
34497<p>
34498In 18.7 [support.rtti]/1, header <tt>&lt;typeinfo&gt;</tt> synopsis change as indicated:
34499</p>
34500<blockquote><pre>namespace std {
34501  class type_info;
34502  class type_index;
34503  template &lt;<del>class</del><ins>ReferentType</ins> T&gt; struct hash;
34504</pre></blockquote>
34505</li>
34506</ol>
34507
34508
34509
34510
34511
34512<hr>
34513<h3><a name="1074"></a>1074. concept map broken by N2840</h3>
34514<p><b>Section:</b> X [allocator.element.concepts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
34515 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-03-19  <b>Last modified:</b> 2009-07-13</p>
34516<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
34517<p><b>Discussion:</b></p>
34518
34519<p>
34520p7 Allocator-related element concepts X [allocator.element.concepts]
34521</p>
34522
34523<p>
34524The changes to the <tt>AllocatableElement</tt> concept mean this <tt>concept_map</tt>
34525specialization no longer matches the original concept:
34526</p>
34527
34528<blockquote><pre>template &lt;Allocator Alloc, class T, class ... Args&gt;
34529  requires HasConstructor&lt;T, Args...&gt;
34530    concept_map AllocatableElement&lt;Alloc, T, Args&amp;&amp;...&gt; {
34531      void construct_element(Alloc&amp; a, T* t, Args&amp;&amp;... args) {
34532        Alloc::rebind&lt;T&gt;(a).construct(t, forward(args)...);
34533      }
34534    }
34535</pre></blockquote>
34536
34537<p><i>[
345382009-03-23 Pablo adds:
34539]</i></p>
34540
34541
34542<blockquote>
34543Actually, this is incorrect,
34544<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">N2840</a>
34545says. "In section 
34546X [allocator.element.concepts] paragraph 8, modify the definition of the
34547<tt>AllocatableElement</tt> concept and eliminate the related concept map:" but
34548then neglects to include the red-lined text of the concept map that was
34549to be eliminated. Pete also missed this, but I caught it he asked me to
34550review his edits.  Pete's updated WP removes the concept map entirely,
34551which was the original intent.  The issue is, therefore, moot.  Note, as
34552per my presentation of
34553<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">N2840</a>
34554in summit, <tt>construct()</tt> no longer has a
34555default implementation.  This regrettable fact was deemed (by David
34556Abrahams, Doug, and myself) to be preferable to the complexity of
34557providing a default implementation that would not under-constrain a more
34558restrictive allocator (like the scoped allocators).
34559</blockquote>
34560
34561<p><i>[
345622009-05-01 Daniel adds:
34563]</i></p>
34564
34565<blockquote>
34566<p>
34567it seems to me that #1074 should be resolved as a NAD, because the
34568current WP has already removed the previous AllocatableElement concept map.
34569It introduced auto concept AllocatableElement instead, but as of
34570X [allocator.element.concepts]/7 this guy contains now
34571</p>
34572<blockquote><pre>requires FreeStoreAllocatable&lt;T&gt;;
34573void Alloc::construct(T*, Args&amp;&amp;...);
34574</pre></blockquote>
34575</blockquote>
34576
34577<p><i>[
34578Batavia (2009-05):
34579]</i></p>
34580
34581<blockquote>
34582<p>
34583The affected code is no longer part of the Working Draft.
34584</p>
34585<p>
34586Move to NAD.
34587</p>
34588</blockquote>
34589
34590
34591<p><b>Proposed resolution:</b></p>
34592<p>
34593Change X [allocator.element.concepts]:
34594</p>
34595
34596<blockquote><pre>template &lt;Allocator Alloc, class T, class ... Args&gt;
34597  requires HasConstructor&lt;T, Args...&gt;
34598    concept_map AllocatableElement&lt;Alloc, T, Args&amp;&amp;...&gt; {
34599      void construct_element(<del>Alloc&amp; a,</del> T* t, Args&amp;&amp;... args) {
34600        Alloc::rebind&lt;T&gt;(a).construct(t, forward(args)...);
34601      }
34602    }
34603</pre></blockquote>
34604
34605
34606
34607
34608
34609
34610<hr>
34611<h3><a name="1075"></a>1075. Response to US 65, US 74.1</h3>
34612<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#NAD%20Editorial">NAD Editorial</a>
34613 <b>Submitter:</b> Alan Talbot <b>Opened:</b> 2009-03-20  <b>Last modified:</b> 2009-10-26</p>
34614<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>
34615<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
34616<p><b>Discussion:</b></p>
34617<p><b>Addresses US 65 and US 74.1</b></p>
34618
34619<p>US 65:</p>
34620
34621<blockquote>
34622Scoped allocators and allocator propagation traits add a small amount of
34623utility at the cost of a great deal of machinery. The machinery is user
34624visible, and it extends to library components that don't have any
34625obvious connection to allocators, including basic concepts and simple
34626components like <tt>pair</tt> and <tt>tuple</tt>.
34627
34628<p>Suggested resolution:</p>
34629
34630<p>
34631Sketch of proposed resolution: Eliminate scoped allocators, replace
34632allocator propagation traits with a simple uniform rule (e.g. always
34633propagate on copy and move), remove all mention of allocators from
34634components that don't explicitly allocate memory (e.g. pair), and adjust
34635container interfaces to reflect this simplification.
34636</p>
34637<p>
34638Components that I propose eliminating include HasAllocatorType,
34639is_scoped_allocator, allocator_propagation_map, scoped_allocator_adaptor,
34640and ConstructibleAsElement.
34641</p>
34642</blockquote>
34643
34644<p>US 74.1:</p>
34645
34646<blockquote>
34647<p>
34648Scoped allocators represent a poor trade-off for standardization, since
34649(1) scoped-allocator--aware containers can be implemented outside the
34650C++ standard library but used with its algorithms, (2) scoped
34651allocators only benefit a tiny proportion of the C++ community
34652(since few C++ programmers even use today's allocators), and (3) all C++
34653users, especially the vast majority of the C++ community that won't ever
34654use scoped allocators are forced to cope with the interface complexity
34655introduced by scoped allocators.
34656</p>
34657<p>
34658In essence, the larger community will suffer to support a very small
34659subset of the community who can already implement their own
34660data structures outside of the standard library. Therefore, scoped
34661allocators should be removed from the working paper.
34662</p>
34663<p>
34664Some evidence of the complexity introduced by scoped allocators:
34665</p>
34666<blockquote>
34667<p>
3466820.3.4 [pairs], 20.5 [tuple]: Large increase in the
34669number of pair and tuple constructors.
34670</p>
34671<p>
3467223 [containers]: Confusing "AllocatableElement" requirements throughout.
34673</p>
34674</blockquote>
34675<p>Suggested resolution:</p>
34676
34677<p>
34678Remove support for scoped allocators from the working paper. This
34679includes at least the following changes:
34680</p>
34681
34682<blockquote>
34683<p>
34684Remove X [allocator.element.concepts]
34685</p>
34686<p>
34687Remove 20.8.9 [allocator.adaptor]
34688</p>
34689<p>
34690Remove 20.8.12 [construct.element]
34691</p>
34692<p>
34693In Clause 23 [containers]: replace requirements naming the
34694<tt>AllocatableElement</tt> concept with requirements naming <tt>CopyConstructible</tt>,
34695<tt>MoveConstructible</tt>, <tt>DefaultConstructible</tt>, or <tt>Constructible</tt>, as
34696appropriate.
34697</p>
34698</blockquote>
34699
34700</blockquote>
34701
34702<p><i>[
34703Post Summit Alan moved from NAD to Open.
34704]</i></p>
34705
34706
34707<p><i>[
347082009-05-15 Ganesh adds:
34709]</i></p>
34710
34711
34712<blockquote>
34713<p>
34714The requirement <tt>AllocatableElement</tt> should not be replaced with
34715<tt>Constructible</tt> on the <tt>emplace_xxx()</tt> functions as suggested. In the
34716one-parameter case the <tt>Constructible</tt> requirement is not satisfied when
34717the constructor is explicit (as per  [concept.map.fct], twelfth
34718bullet) but we do want to allow explicit constructors in emplace, as the
34719following example shows:
34720</p>
34721
34722<blockquote><pre>vector&lt;shared_ptr&lt;int&gt;&gt; v;
34723v.emplace_back(new int); <font color="#c80000">// should be allowed</font>
34724</pre></blockquote>
34725
34726<p>
34727If the issue is accepted and scoped allocators are removed, I suggest to
34728add a new pair of concepts to  [concept.construct], namely:
34729</p>
34730
34731<blockquote><pre>auto concept HasExplicitConstructor&lt;typename T, typename... Args&gt; {
34732 explicit T::T(Args...);
34733}
34734
34735auto concept ExplicitConstructible&lt;typename T, typename... Args&gt;
34736 : HasExplicitConstructor&lt;T, Args...&gt;, NothrowDestructible&lt;T&gt;
34737{ }
34738</pre></blockquote>
34739
34740<p>
34741We should then use <tt>ExplicitConstructible</tt> as the requirement for all
34742<tt>emplace_xxx()</tt> member functions.
34743</p>
34744<p>
34745For coherence and consistency with the similar concepts
34746<tt>Convertible/ExplicitlyConvertible</tt>, we might also consider changing
34747<tt>Constructible</tt> to:
34748</p>
34749
34750<blockquote><pre>auto concept Constructible&lt;typename T, typename... Args&gt;
34751 : HasConstructor&lt;T, Args...&gt;, ExplicitConstructible&lt;T, Args...&gt;
34752{ }
34753</pre></blockquote>
34754
34755<p>
34756Moreover, all emplace-related concepts in  [container.concepts]
34757should also use <tt>ExplicitConstructible</tt> instead of <tt>Constructible</tt> in the
34758definitions of their axioms. In fact the concepts in  [container.concepts] should be
34759corrected even if the issue is not accepted.
34760</p>
34761<p>
34762On the other hand, if the issue is not accepted, the scoped allocator
34763adaptors should be fixed because the following code:
34764</p>
34765
34766<blockquote><pre>template &lt;typename T&gt; using scoped_allocator = scoped_allocator_adaptor&lt;allocator&lt;T&gt;&gt;;
34767
34768vector&lt;shared_ptr&lt;int&gt;, scoped_allocator&lt;shared_ptr&lt;int&gt;&gt;&gt; v;
34769v.emplace_back(new int); <font color="#c80000">// ops! doesn't compile</font>
34770</pre></blockquote>
34771
34772<p>
34773doesn't compile, as the member function <tt>construct()</tt> of the scoped
34774allocator requires non-explicit constructors through concept
34775<tt>ConstructibleWithAllocator</tt>. Fixing that is not difficult but probably
34776more work than it's worth and is therefore, IMHO, one more reason in
34777support of the complete removal of scoped allocators.
34778</p>
34779</blockquote>
34780
34781<p><i>[
347822009-06-09 Alan adds:
34783]</i></p>
34784
34785
34786<blockquote>
34787<p>
34788I reopened this issue because I did not think that these National Body
34789comments were adequately addressed by marking them NAD. My understanding
34790is that something can be marked NAD if it is clearly a misunderstanding
34791or trivial, but a substantive issue that has any technical merit
34792requires a disposition that addresses the concerns.
34793</p>
34794<p>
34795The notes in the NB comment list (US 65 &amp; US 74.1) say that:
34796</p>
34797<ol type="a">
34798<li>
34799this issue has not introduced any new arguments not previously discussed,
34800</li>
34801<li>
34802the vote (4-9-3) was not a consensus for removing scoped allocators,
34803</li>
34804<li>
34805the issue is resolved by
34806<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2840.pdf">N2840</a>.
34807</li>
34808</ol>
34809<p>
34810My opinion is:
34811</p>
34812<ol type="a">
34813<li>
34814there are new arguments in both comments regarding concepts (which were
34815not present in the library when the scoped allocator proposal was voted
34816in),
34817</li>
34818<li>
34819the vote was clearly not a consensus for removal, but just saying there
34820was a vote does not provide a rationale,
34821</li>
34822<li>
34823I do not believe that N2840 addresses these comments (although it does
34824many other things and was voted in with strong approval).
34825</li>
34826</ol>
34827
34828<p>
34829My motivation to open the issue was to ensure that the NB comments were
34830adequately addressed in a way that would not risk a "no" vote on our
34831FCD. If there are responses to the technical concerns raised, then
34832perhaps they should be recorded. If the members of the NB who authored
34833the comments are satisfied with N2840 and the other disposition remarks
34834in the comment list, then I am sure they will say so. In either case,
34835this issue can be closed very quickly in Frankfurt, and hopefully will
34836have helped make us more confident of approval with little effort. If in
34837fact there is controversy, my thought is that it is better to know now
34838rather than later so there is more time to deal with it.
34839</p>
34840</blockquote>
34841
34842<p><i>[
348432009-10 Santa Cruz:
34844]</i></p>
34845
34846
34847<blockquote>
34848NAD Editorial.  Addressed by
34849<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>.
34850</blockquote>
34851
34852
34853
34854<p><b>Proposed resolution:</b></p>
34855
34856
34857<p><b>Rationale:</b></p>
34858Scoped allocators have been revised significantly.
34859
34860
34861
34862
34863
34864<hr>
34865<h3><a name="1077"></a>1077. Nonesense <tt>tuple</tt> declarations</h3>
34866<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#NAD%20Editorial">NAD Editorial</a>
34867 <b>Submitter:</b> Pete Becker <b>Opened:</b> 2009-03-20  <b>Last modified:</b> 2009-07-13</p>
34868<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>
34869<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
34870<p><b>Discussion:</b></p>
34871<p>
34872Class template tuple 20.5.2 [tuple.tuple]:
34873</p>
34874
34875<blockquote><pre>template &lt;class... UTypes&gt;
34876  requires Constructible&lt;Types, const UTypes&amp;&gt;...
34877template &lt;class... UTypes&gt;
34878  requires Constructible&lt;Types, RvalueOf&lt;UTypes&gt;::type&gt;...
34879</pre></blockquote>
34880
34881<p>
34882Somebody needs to look at this and say what it should be.
34883</p>
34884
34885<p><i>[
348862009-03-21 Daniel provided wording.
34887]</i></p>
34888
34889
34890<p><i>[
34891Batavia (2009-05):
34892]</i></p>
34893
34894<blockquote>
34895The resolution looks correct; move to NAD Editorial.
34896</blockquote>
34897
34898
34899<p><b>Proposed resolution:</b></p>
34900<p>
34901In 20.5.2 [tuple.tuple], class <tt>tuple</tt>, change as indicated:
34902</p>
34903
34904<blockquote><pre>template &lt;class... UTypes&gt;
34905  requires Constructible&lt;Types, const UTypes&amp;&gt;...
34906  <ins>tuple(const pair&lt;UTypes...&gt;&amp;);</ins>
34907template &lt;class... UTypes&gt;
34908  requires Constructible&lt;Types, RvalueOf&lt;UTypes&gt;::type&gt;...
34909  <ins>tuple(pair&lt;UTypes...&gt;&amp;&amp;);</ins>
34910</pre></blockquote>
34911
34912<p>
34913[NB.: The corresponding prototypes do already exist in 20.5.2.1 [tuple.cnstr]/7+8]
34914</p>
34915
34916
34917
34918
34919
34920<hr>
34921<h3><a name="1078"></a>1078. DE-17: Remove class type_index</h3>
34922<p><b>Section:</b> 20.11 [type.index] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
34923 <b>Submitter:</b> Doug Gregor <b>Opened:</b> 2009-03-20  <b>Last modified:</b> 2009-07-16</p>
34924<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
34925<p><b>Discussion:</b></p>
34926
34927<p><b>Addresses DE 17</b></p>
34928
34929<p>
34930DE-17: 
34931</p>
34932<p>
34933The class <tt>type_index</tt> should be removed; it provides no additional
34934functionality beyond providing appropriate concept maps.
34935</p>
34936
34937<p><i>[
349382009-03-31 Peter adds:
34939]</i></p>
34940
34941
34942<blockquote>
34943<p>
34944It is not true, in principle, that <tt>std::type_index</tt> provides no  utility
34945compared to bare <tt>std::type_info*</tt>.
34946</p>
34947<p>
34948<tt>std::type_index</tt> can avoid the lifetime issues with <tt>type_info</tt> when  the
34949DLL that has produced the <tt>type_info</tt> object is unloaded. A raw
34950<tt>type_info*</tt> does not, and cannot, provide any protection in this  case.
34951A <tt>type_index</tt> can (if the implementor so chooses) because it  can wrap a
34952smart (counted or even cloning) pointer to the <tt>type_info</tt>  data that is
34953needed for <tt>name()</tt> and <tt>before()</tt> to work.
34954</p>
34955</blockquote>
34956
34957
34958
34959<p><b>Proposed resolution:</b></p>
34960<p>Modify the header &lt;typeinfo&gt; synopsis in 
34961  18.7 [support.rtti]p1 as follows:</p>
34962
34963<blockquote><pre>namespace std { 
34964  class type_info; 
34965  <del>class type_index;</del>
34966  template &lt;class T&gt; struct hash;
34967  template&lt;&gt; struct hash&lt;<del>type_index</del><ins>const type_info *</ins>&gt; : public std::unary_function&lt;<del>type_index</del><ins>const type_info *</ins>, size_t&gt; {
34968    size_t operator()(<del>type_index</del><ins>const type_info *</ins> <del>index</del><ins>t</ins>) const;
34969  }<ins>;</ins>
34970  <ins>concept_map LessThanComparable&lt;const type_info *&gt; <i>see below</i></ins>
34971  class bad_cast; 
34972  class bad_typeid;
34973}
34974</pre></blockquote>
34975
34976<p>Add the following new subsection</p>
34977<blockquote>
34978<p>
34979<ins>18.7.1.1 Template specialization <code>hash&lt;const type_info *&gt;</code>
34980[type.info.hash]</ins></p>
34981
34982<pre><ins>size_t operator()(const type_info *x) const;</ins>
34983</pre>
34984<ol>
34985<li><ins><i>Returns</i>: <code>x-&gt;hash_code()</code></ins></li>
34986</ol>
34987</blockquote>
34988
34989 <p>Add the following new subsection</p>
34990 <blockquote>
34991<p><ins>18.7.1.2 <code>type_info</code> concept map [type.info.concepts]</ins></p>
34992
34993
34994<pre><ins>concept_map LessThanComparable&lt;const type_info *&gt; {</ins>
34995  <ins>bool operator&lt;(const type_info *x, const type_info *y) { return x-&gt;before(*y); }</ins>
34996  <ins>bool operator&lt;=(const type_info *x, const type_info *y) { return !y-&gt;before(*x); }</ins>
34997  <ins>bool operator&gt;(const type_info *x, const type_info *y) { return y-&gt;before(*x); }</ins>
34998  <ins>bool operator&gt;=(const type_info *x, const type_info *y) { return !x-&gt;before(*y); }</ins>
34999<ins>}</ins>
35000</pre>
35001<ol>
35002  <li><ins><i>Note</i>: provides a well-defined ordering among
35003  <code>type_info const</code> pointers, which makes such pointers
35004  usable in associative containers (23.4).</ins></li>
35005</ol>
35006</blockquote>
35007
35008<p>Remove section 20.11 [type.index]</p>
35009
35010
35011
35012
35013
35014<hr>
35015<h3><a name="1080"></a>1080. Concept ArithmeticLike should provide explicit boolean  conversion</h3>
35016<p><b>Section:</b> X [concept.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
35017 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-03-21  <b>Last modified:</b> 2009-07-15</p>
35018<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
35019<p><b>Discussion:</b></p>
35020<p>
35021Astonishingly, the current concept ArithmeticLike as specified in
35022X [concept.arithmetic] does not provide explicit conversion
35023to <tt>bool</tt> although this is a common property of arithmetic types
35024(4.12 [conv.bool]). Recent proposals that introduced such types
35025(integers of arbitrary precision,
35026<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2143.pdf">n2143</a>,
35027decimals
35028<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2732.pdf">n2732</a>
35029indirectly
35030via conversion to <tt>long long</tt>) also took care of such a feature.
35031</p>
35032<p>
35033Adding such an explicit conversion associated function would also
35034partly solve a currently invalid effects clause in library, which bases
35035on this property, 24.2.5 [random.access.iterators]/2:
35036</p>
35037<blockquote><pre>{ difference_type m = n;
35038 if (m &gt;= 0) while (m--) ++r;
35039 else while (m++) --r;
35040 return r; }
35041</pre></blockquote>
35042
35043<p>
35044Both while-loops take advantage of a contextual conversion to <tt>bool</tt>
35045(Another problem is that the &gt;= comparison uses the no
35046longer supported existing implicit conversion from <tt>int</tt> to <tt>IntegralLike</tt>).
35047</p>
35048
35049<b>Original proposed resolution:</b>
35050<ol>
35051<li>
35052<p>
35053In X [concept.arithmetic], add to the list of less refined
35054concepts one further concept:
35055</p>
35056
35057<blockquote><pre>concept ArithmeticLike&lt;typename T&gt;
35058  : Regular&lt;T&gt;, LessThanComparable&lt;T&gt;, HasUnaryPlus&lt;T&gt;, HasNegate&lt;T&gt;,
35059    HasPlus&lt;T, T&gt;, HasMinus&lt;T, T&gt;, HasMultiply&lt;T, T&gt;, HasDivide&lt;T, T&gt;,
35060    HasPreincrement&lt;T&gt;, HasPostincrement&lt;T&gt;, HasPredecrement&lt;T&gt;,
35061    HasPostdecrement&lt;T&gt;,
35062    HasPlusAssign&lt;T, const T&amp;&gt;, HasMinusAssign&lt;T, const T&amp;&gt;,
35063    HasMultiplyAssign&lt;T, const T&amp;&gt;,
35064    HasDivideAssign&lt;T, const T&amp;&gt;<ins>, ExplicitlyConvertible&lt;T, bool&gt;</ins> {
35065</pre></blockquote>
35066</li>
35067<li>
35068<p>
35069In 24.2.5 [random.access.iterators]/2 change the current effects clause
35070as indicated [The proposed insertion fixes the problem that the previous
35071implicit construction from integrals has been changed to an explicit
35072constructor]:
35073</p>
35074<blockquote><pre>{ difference_type m = n;
35075 if (m &gt;= <ins>difference_type(</ins>0<ins>)</ins>) while (m--) ++r;
35076 else while (m++) --r;
35077 return r; }
35078</pre></blockquote>
35079</li>
35080</ol>
35081
35082<p><i>[
35083Batavia (2009-05):
35084]</i></p>
35085
35086<blockquote>
35087<p>
35088We agree that arithmetic types ought be convertible to <tt>bool</tt>,
35089and we therefore agree with the proposed resolution's paragraph 1.
35090</p>
35091<p>
35092We do not agree that the cited effects clause is invalid,
35093as it expresses intent rather than specific code.
35094</p>
35095<p>
35096Move to Review, pending input from concepts experts.
35097</p>
35098</blockquote>
35099
35100
35101
35102<p><b>Proposed resolution:</b></p>
35103<p>
35104In X [concept.arithmetic], add to the list of less refined
35105concepts one further concept:
35106</p>
35107
35108<blockquote><pre>concept ArithmeticLike&lt;typename T&gt;
35109  : Regular&lt;T&gt;, LessThanComparable&lt;T&gt;, HasUnaryPlus&lt;T&gt;, HasNegate&lt;T&gt;,
35110    HasPlus&lt;T, T&gt;, HasMinus&lt;T, T&gt;, HasMultiply&lt;T, T&gt;, HasDivide&lt;T, T&gt;,
35111    HasPreincrement&lt;T&gt;, HasPostincrement&lt;T&gt;, HasPredecrement&lt;T&gt;,
35112    HasPostdecrement&lt;T&gt;,
35113    HasPlusAssign&lt;T, const T&amp;&gt;, HasMinusAssign&lt;T, const T&amp;&gt;,
35114    HasMultiplyAssign&lt;T, const T&amp;&gt;,
35115    HasDivideAssign&lt;T, const T&amp;&gt;<ins>, ExplicitlyConvertible&lt;T, bool&gt;</ins> {
35116</pre></blockquote>
35117
35118
35119
35120
35121
35122<hr>
35123<h3><a name="1081"></a>1081. Response to UK 216</h3>
35124<p><b>Section:</b> 21 [strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
35125 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22  <b>Last modified:</b> 2009-07-15</p>
35126<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#strings">issues</a> in [strings].</p>
35127<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
35128<p><b>Discussion:</b></p>
35129<p><b>Addresses UK 216, JP 46, JP 48</b></p>
35130
35131<p>
35132All the containers use concepts for their iterator usage, exect for
35133<tt>basic_string</tt>. This needs fixing.
35134</p>
35135
35136<p>
35137Use concepts for iterator template parameters throughout the chapter.
35138</p>
35139
35140<p><i>[
35141Summit:
35142]</i></p>
35143
35144<blockquote>
35145NB comments to be handled by Dave Abrahams and Howard Hinnant with
35146advice from PJP: UK216 (which duplicates) JP46, JP48. JP46 supplies
35147extensive proposed wording; start there.
35148</blockquote>
35149
35150
35151<p><b>Proposed resolution:</b></p>
35152
35153
35154
35155
35156
35157<hr>
35158<h3><a name="1082"></a>1082. Response to JP 49</h3>
35159<p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
35160 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22  <b>Last modified:</b> 2009-07-15</p>
35161<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#localization">issues</a> in [localization].</p>
35162<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
35163<p><b>Discussion:</b></p>
35164<p><b>Addresses JP 49</b></p>
35165
35166<p>
35167<tt>codecvt</tt> does not use concept. For example, create <tt>CodeConvert</tt>
35168concept and change as follows.
35169</p>
35170
35171<blockquote><pre>template&lt;CodeConvert Codecvt, class Elem = wchar_t&gt;
35172  class wstring_convert {
35173</pre></blockquote>
35174
35175<p><i>[
35176Summit:
35177]</i></p>
35178
35179<blockquote>
35180To be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plauger.
35181</blockquote>
35182
35183
35184<p><b>Proposed resolution:</b></p>
35185
35186
35187
35188
35189
35190<hr>
35191<h3><a name="1083"></a>1083. Response to JP 52, 53</h3>
35192<p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
35193 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22  <b>Last modified:</b> 2009-07-15</p>
35194<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#localization">issues</a> in [localization].</p>
35195<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
35196<p><b>Discussion:</b></p>
35197<p><b>Addresses JP 52, JP 53</b></p>
35198
35199<p>
35200<tt>InputIterator</tt> does not use concept.
35201</p>
35202
35203<p>
35204<tt>OutputIterator</tt> does not use concept.
35205</p>
35206
35207<p>
35208Comments include proposed wording.
35209</p>
35210
35211<p><i>[
35212Summit:
35213]</i></p>
35214
35215<blockquote>
35216To be handled by Howard Hinnant, Dave Abrahams, Martin Sebor, PJ Plauger.
35217</blockquote>
35218
35219
35220<p><b>Proposed resolution:</b></p>
35221
35222
35223
35224
35225
35226<hr>
35227<h3><a name="1084"></a>1084. Response to UK 250</h3>
35228<p><b>Section:</b> 24.2.3 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
35229 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22  <b>Last modified:</b> 2009-07-16</p>
35230<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward.iterators">issues</a> in [forward.iterators].</p>
35231<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
35232<p><b>Discussion:</b></p>
35233<p><b>Addresses UK 250</b></p>
35234
35235<p>
35236A default implementation should be supplied for the post-increment
35237operator to simplify implementation of iterators by users.
35238</p>
35239
35240<p>
35241Copy the Effects clause into the concept description as the default
35242implementation. Assumes a default value for postincrement_result
35243</p>
35244
35245<p><i>[
35246Summit:
35247]</i></p>
35248
35249<blockquote>
35250Howard will open an issue.
35251</blockquote>
35252
35253<p><i>[
352542009-06-07 Daniel adds:
35255]</i></p>
35256
35257
35258<blockquote>
35259This issue cannot currently be resolved as suggested, because
35260that would render auto-detection of the return type
35261<tt>postincrement_result</tt> invalid, see  [concept.map.assoc]/4+5. The
35262best fix would be to add a default type to that associated type, but
35263unfortunately any default type will prevent auto-deduction of types of
35264associated functions as quoted above. A corresponding core issue
35265is in preparation.
35266</blockquote>
35267
35268
35269<p><b>Proposed resolution:</b></p>
35270<p><i>[
35271This wording assumes the acceptance of UK 251 / <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1009">1009</a>.  Both
35272wordings change the same paragraphs.
35273]</i></p>
35274
35275
35276<p>
35277Change 24.2.3 [forward.iterators]:
35278</p>
35279
35280<blockquote>
35281<pre>concept ForwardIterator&lt;typename X&gt; : InputIterator&lt;X&gt;, Regular&lt;X&gt; { 
35282
35283  MoveConstructible postincrement_result;
35284  requires HasDereference&lt;postincrement_result&gt;
35285        &amp;&amp; Convertible&lt;HasDereference&lt;postincrement_result&gt;::result_type, const value_type&amp;&gt;;
35286
35287  postincrement_result operator++(X&amp; r, int)<del>;</del> <ins>{
35288     X tmp = r;
35289     ++r;
35290     return tmp;
35291  }</ins>
35292
35293  axiom MultiPass(X a, X b) { 
35294    if (a == b) *a == *b; 
35295    if (a == b) ++a == ++b; 
35296  } 
35297}
35298</pre></blockquote>
35299
35300
35301
35302
35303
35304
35305<hr>
35306<h3><a name="1085"></a>1085. Response to UK 258</h3>
35307<p><b>Section:</b> 24.2.4 [bidirectional.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
35308 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22  <b>Last modified:</b> 2009-07-16</p>
35309<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>
35310<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
35311<p><b>Discussion:</b></p>
35312<p><b>Addresses UK 258</b></p>
35313
35314<p>
35315A default implementation should be supplied for the post-decrement
35316operator to simplify implementation of iterators by users.
35317</p>
35318
35319<p>
35320Copy the Effects clause into the concept description as the default
35321implementation. Assumes a default value for postincrement_result
35322</p>
35323
35324<p><i>[
35325Summit:
35326]</i></p>
35327
35328<blockquote>
35329Howard will open an issue.
35330</blockquote>
35331
35332<p><i>[
353332009-06-07 Daniel adds:
35334]</i></p>
35335
35336
35337<blockquote>
35338This issue cannot currently be resolved as suggested, because
35339that would render auto-detection of the return type
35340<tt>postdecrement_result</tt> invalid, see <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1084">1084</a>.
35341</blockquote>
35342
35343
35344<p><b>Proposed resolution:</b></p>
35345
35346<p>
35347Change 24.2.4 [bidirectional.iterators]:
35348</p>
35349
35350<blockquote>
35351<pre>concept BidirectionalIterator&lt;typename X&gt; : ForwardIterator&lt;X&gt; { 
35352  MoveConstructible postdecrement_result; 
35353  requires HasDereference&lt;postdecrement_result&gt; 
35354        &amp;&amp; Convertible&lt;HasDereference&lt;postdecrement_result&gt;::result_type, const value_type&amp;&gt; 
35355        &amp;&amp; Convertible&lt;postdecrement_result, const X&amp;&gt;; 
35356  X&amp; operator--(X&amp;); 
35357  postdecrement_result operator--(X&amp; <ins>r</ins>, int)<del>;</del> <ins>{
35358     X tmp = r;
35359     --r;
35360     return tmp;
35361  }</ins>
35362}
35363</pre></blockquote>
35364
35365
35366
35367
35368
35369
35370<hr>
35371<h3><a name="1086"></a>1086. Response to UK 284</h3>
35372<p><b>Section:</b> 24.6 [stream.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
35373 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22  <b>Last modified:</b> 2009-07-15</p>
35374<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
35375<p><b>Discussion:</b></p>
35376<p><b>Addresses UK 284</b></p>
35377
35378<p>
35379The stream iterators need constraining with concepts/requrires clauses.
35380</p>
35381
35382<p><i>[
35383Summit:
35384]</i></p>
35385
35386<blockquote>
35387We agree. To be handled by Howard, Martin and PJ.
35388</blockquote>
35389
35390
35391<p><b>Proposed resolution:</b></p>
35392
35393
35394
35395
35396
35397<hr>
35398<h3><a name="1087"></a>1087. Response to UK 301</h3>
35399<p><b>Section:</b> 25.3.5 [alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
35400 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22  <b>Last modified:</b> 2009-07-15</p>
35401<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.replace">issues</a> in [alg.replace].</p>
35402<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
35403<p><b>Discussion:</b></p>
35404<p><b>Addresses UK 301</b></p>
35405
35406<p>
35407<tt>replace</tt> and <tt>replace_if</tt> have the requirement: <tt>OutputIterator&lt;Iter,
35408Iter::reference&gt;</tt> Which implies they need to copy some values in the
35409range the algorithm is iterating over. This is not however the case, the
35410only thing that happens is <tt>const T&amp;</tt>s might be copied over existing
35411elements (hence the <tt>OutputIterator&lt;Iter, const T&amp;&gt;</tt>.
35412</p>
35413
35414<p>
35415Remove <tt>OutputIterator&lt;Iter, Iter::reference&gt;</tt> from <tt>replace</tt>
35416and <tt>replace_if</tt>.
35417</p>
35418
35419<p><i>[
35420Summit:
35421]</i></p>
35422
35423<blockquote>
35424We agree. To be handled by Howard.
35425</blockquote>
35426
35427
35428<p><b>Proposed resolution:</b></p>
35429<p>
35430Change in  [algorithms.syn] and 25.3.5 [alg.replace]:
35431</p>
35432
35433<blockquote><pre>template&lt;ForwardIterator Iter, class T&gt; 
35434  requires <del>OutputIterator&lt;Iter, Iter::reference&gt; 
35435        &amp;&amp;</del> OutputIterator&lt;Iter, const T&amp;&gt; 
35436        &amp;&amp; HasEqualTo&lt;Iter::value_type, T&gt; 
35437  void replace(Iter first, Iter last, 
35438               const T&amp; old_value, const T&amp; new_value); 
35439
35440template&lt;ForwardIterator Iter, Predicate&lt;auto, Iter::value_type&gt; Pred, class T&gt; 
35441  requires <del>OutputIterator&lt;Iter, Iter::reference&gt; 
35442        &amp;&amp;</del> OutputIterator&lt;Iter, const T&amp;&gt; 
35443        &amp;&amp; CopyConstructible&lt;Pred&gt; 
35444  void replace_if(Iter first, Iter last,
35445                  Pred pred, const T&amp; new_value);
35446</pre></blockquote>
35447
35448
35449
35450
35451
35452<hr>
35453<h3><a name="1088"></a>1088. Response to UK 342</h3>
35454<p><b>Section:</b> 30.6.5 [futures.promise] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
35455 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-03-22  <b>Last modified:</b> 2009-10-26</p>
35456<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>
35457<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
35458<p><b>Discussion:</b></p>
35459<p><b>Addresses UK 342</b></p>
35460
35461<p>
35462<tt>std::promise</tt> is missing a non-member overload of <tt>swap</tt>. This is
35463inconsistent with other types that provide a <tt>swap</tt> member function.
35464</p>
35465
35466<p>
35467Add a non-member overload <tt>void swap(promise&amp;&amp; x,promise&amp;&amp; y){ x.swap(y); }</tt>
35468</p>
35469
35470<p><i>[
35471Summit:
35472]</i></p>
35473
35474<blockquote>
35475Create an issue. Move to review, attention: Howard. Detlef will also
35476look into it.
35477</blockquote>
35478
35479<p><i>[
35480Post Summit Daniel provided wording.
35481]</i></p>
35482
35483
35484<p><i>[
354852009-10 Santa Cruz:
35486]</i></p>
35487
35488
35489<blockquote>
35490NAD Editorial.  Solved by
35491<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.html">N2997</a>.
35492</blockquote>
35493
35494
35495
35496<p><b>Proposed resolution:</b></p>
35497<ol>
35498<li>
35499<p>
35500In 30.6.5 [futures.promise], before p.1, immediately after class template
35501promise add:
35502</p>
35503<blockquote><pre><ins>
35504template &lt;class R&gt;
35505void swap(promise&lt;R&gt;&amp; x, promise&lt;R&gt;&amp; y);
35506</ins>
35507</pre></blockquote>
35508</li>
35509<li>
35510<p>
35511Change 30.6.5 [futures.promise]/10 as indicated (to fix a circular definition):
35512</p>
35513<blockquote>
35514<p>
35515-10- <i>Effects:</i> <del>swap(*this, other)</del><ins>Swaps the associated state
35516of <tt>*this</tt> and <tt>other</tt></ins>
35517</p>
35518<p>
35519<ins><i>Throws:</i> Nothing.</ins>
35520</p>
35521</blockquote>
35522</li>
35523<li>
35524<p>
35525After the last paragraph in 30.6.5 [futures.promise] add the following
35526prototype description:
35527</p>
35528<blockquote><pre><ins>
35529template &lt;class R&gt;
35530void swap(promise&lt;R&gt;&amp; x, promise&lt;R&gt;&amp; y);
35531</ins></pre>
35532<blockquote>
35533<p>
35534<ins><i>Effects:</i> <tt>x.swap(y)</tt></ins>
35535</p>
35536<p>
35537<ins><i>Throws:</i> Nothing.</ins>
35538</p>
35539</blockquote>
35540</blockquote>
35541</li>
35542
35543</ol>
35544
35545
35546
35547
35548
35549
35550<hr>
35551<h3><a name="1091"></a>1091. Multimap description confusing</h3>
35552<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#NAD">NAD</a>
35553 <b>Submitter:</b> LWG <b>Opened:</b> 2009-03-22  <b>Last modified:</b> 2009-10-20</p>
35554<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
35555<p><b>Discussion:</b></p>
35556
35557<p><b>Addresses UK 246</b></p>
35558<p>
35559The content of this sub-clause is purely trying to describe in words the
35560effect of the requires clauses on these operations, now that we have
35561Concepts. As such, the description is more confusing than the signature
35562itself. The semantic for these functions is adequately covered in the
35563requirements tables in 23.2.4 [associative.reqmts].
35564</p>
35565
35566<p><i>[
35567Beman adds:
35568]</i></p>
35569
35570
35571<blockquote>
35572Pete is clearly right that
35573this one is technical rather than editorial.
35574</blockquote>
35575
35576<p><i>[
35577Batavia (2009-05):
35578]</i></p>
35579
35580<blockquote>
35581<p>
35582We agree with the proposed resolution.
35583</p>
35584<p>
35585Move to Review.
35586</p>
35587</blockquote>
35588
35589<p><i>[
355902009-10 Santa Cruz:
35591]</i></p>
35592
35593
35594<blockquote>
35595Mark as NAD, solved by removing concepts.
35596</blockquote>
35597
35598
35599
35600<p><b>Proposed resolution:</b></p>
35601<p>
35602Strike 23.4.2.2 [multimap.modifiers] entirely
35603(but do NOT strike these signatures from the class template definition!).
35604</p>
35605
35606
35607
35608
35609
35610<hr>
35611<h3><a name="1092"></a>1092. Class template <tt>integral_constant</tt> should be a  constrained template</h3>
35612<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#NAD%20Concepts">NAD Concepts</a>
35613 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-03-22  <b>Last modified:</b> 2009-07-15</p>
35614<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>
35615<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
35616<p><b>Discussion:</b></p>
35617<p>
35618A first step to change the type traits predicates to constrained templates is to
35619constrain their common base template <tt>integral_constant</tt>. This can be done,
35620without enforcing depending classes to be constrained as well, but not
35621vice versa
35622without brute force <tt>late_check</tt> usages. The following proposed resolution depends
35623on the resolution of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1019">1019</a>.
35624</p>
35625
35626<p><i>[
35627Batavia (2009-05):
35628]</i></p>
35629
35630<blockquote>
35631Move to Open, pending a paper that looks at constraints
35632for the entirety of the type traits
35633and their relationship to the foundation concepts.
35634We recommend this be deferred
35635until after the next Committee Draft is issued.
35636</blockquote>
35637
35638
35639<p><b>Proposed resolution:</b></p>
35640<ol>
35641<li>
35642<p>
35643In 20.6.2 [meta.type.synop], Header <tt>&lt;type_traits&gt;</tt>
35644synopsis change as indicated:
35645</p>
35646<blockquote><pre>namespace std {
35647// 20.5.3, helper class:
35648template &lt;<del>class</del><ins>IntegralConstantExpressionType</ins> T, T v&gt; struct integral_constant;
35649</pre></blockquote>
35650</li>
35651<li>
35652<p>
35653In 20.6.3 [meta.help] change as indicated:
35654</p>
35655<blockquote><pre>template &lt;<del>class</del><ins>IntegralConstantExpressionType</ins> T, T v&gt;
35656struct integral_constant {
35657  static constexpr T value = v;
35658  typedef T value_type;
35659  typedef integral_constant&lt;T,v&gt; type;
35660  constexpr operator value_type() { return value; }
35661};
35662</pre></blockquote>
35663</li>
35664</ol>
35665
35666
35667
35668
35669
35670<hr>
35671<h3><a name="1096"></a>1096. unconstrained rvalue ref parameters</h3>
35672<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
35673 <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-03-21  <b>Last modified:</b> 2009-07-16</p>
35674<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>
35675<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>
35676<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
35677<p><b>Discussion:</b></p>
35678<p>
35679TODO: Look at all cases of unconstrained rvalue ref parameters and check
35680that concept req'ts work when <tt>T</tt> deduced as reference.
35681</p>
35682
35683<p>
35684 We found some instances where that was not done correctly and we figure
35685   the possibility of deducing <tt>T</tt> to be an lvalue reference was probably
35686   overlooked elsewhere.
35687</p>
35688
35689<p><i>[
35690Batavia (2009-05):
35691]</i></p>
35692
35693<blockquote>
35694Move to Open, pending proposed wording from Dave for further review.
35695</blockquote>
35696
35697
35698<p><b>Proposed resolution:</b></p>
35699<p>
35700</p>
35701
35702
35703
35704
35705
35706<hr>
35707<h3><a name="1101"></a>1101. <tt>unique</tt> requirements</h3>
35708<p><b>Section:</b> 25.3.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
35709 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-04-25  <b>Last modified:</b> 2009-07-13</p>
35710<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
35711<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
35712<p><b>Discussion:</b></p>
35713<p>
35714From Message c++std-core-14160 Howard wrote:
35715</p>
35716
35717<blockquote>
35718It was the intent of the rvalue reference proposal for unique to only require MoveAssignable:
35719<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1860.html#25.2.9%20-%20Unique">N1860</a>.
35720</blockquote>
35721
35722<p>
35723And Pete replied:
35724</p>
35725
35726<blockquote>
35727That was overridden by the subsequent changes made for concepts in
35728<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2573.pdf">N2573</a>,
35729which reimposed the C++03 requirements.
35730</blockquote>
35731
35732<p>
35733My impression is that this overwrite was a simple (unintentional) mistake.
35734Wording below to correct it.
35735</p>
35736
35737<p><i>[
35738Batavia (2009-05):
35739]</i></p>
35740
35741<blockquote>
35742<p>
35743Howard notes this issue resolves a discrepancy between the synopsis
35744and the description.
35745</p>
35746<p>
35747Move to NAD Editorial.
35748</p>
35749</blockquote>
35750
35751
35752<p><b>Proposed resolution:</b></p>
35753<p>
35754Change 25.3.9 [alg.unique]:
35755</p>
35756
35757<blockquote><pre>template&lt;ForwardIterator Iter&gt; 
35758  requires OutputIterator&lt;Iter, <ins>RvalueOf&lt;</ins>Iter::reference<ins>&gt;::type</ins>&gt; 
35759        &amp;&amp; EqualityComparable&lt;Iter::value_type&gt; 
35760  Iter unique(Iter first, Iter last); 
35761
35762template&lt;ForwardIterator Iter, EquivalenceRelation&lt;auto, Iter::value_type&gt; Pred&gt; 
35763  requires OutputIterator&lt;Iter, RvalueOf&lt;Iter::reference&gt;::type&gt; 
35764        &amp;&amp; CopyConstructible&lt;Pred&gt; 
35765  Iter unique(Iter first, Iter last, Pred pred);
35766</pre></blockquote>
35767
35768<p>
35769Note that the synopsis in  [algorithms.syn] is already correct.
35770</p>
35771
35772
35773
35774
35775
35776
35777<hr>
35778<h3><a name="1102"></a>1102. <tt>std::vector</tt>'s reallocation policy still unclear</h3>
35779<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#NAD">NAD</a>
35780 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-04-20  <b>Last modified:</b> 2009-10-20</p>
35781<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>
35782<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
35783<p><b>Discussion:</b></p>
35784<p>
35785I have the impression that even the wording of current draft
35786<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf">N2857</a>
35787does insufficiently express the intent of <tt>vector</tt>'s
35788reallocation strategy. This has produced not too old library
35789implementations which release memory in the <tt>clear()</tt> function
35790and even modern articles about C++ programming cultivate
35791the belief that <tt>clear</tt> is allowed to do exactly this. A typical
35792example is something like this:
35793</p>
35794
35795<blockquote><pre>const int buf_size = ...;
35796std::vector&lt;T&gt; buf(buf_size);
35797for (int i = 0; i &lt; some_condition; ++i) {
35798  buf.resize(buf_size);
35799  write_or_read_data(buf.data());
35800  buf.clear(); // Ensure that the next round get's 'zeroed' elements
35801}
35802</pre></blockquote>
35803<p>
35804where still the myth is ubiquitous that <tt>buf</tt> might be
35805allowed to reallocate it's memory *inside* the <tt>for</tt> loop.
35806</p>
35807<p>
35808IMO the problem is due to the fact, that
35809</p>
35810
35811<ol type="a">
35812<li>
35813the actual memory-reallocation stability of <tt>std::vector</tt>
35814is explained in 23.3.6.2 [vector.capacity]/3 and /6 which
35815are describing just the effects of the <tt>reserve</tt>
35816function, but in many examples (like above) there
35817is no explicit call to <tt>reserve</tt> involved. Further-more
3581823.3.6.2 [vector.capacity]/6 does only mention <em>insertions</em>
35819and never mentions the consequences of erasing
35820elements.
35821</li>
35822<li>
35823<p>
35824the effects clause of <tt>std::vector</tt>'s <tt>erase</tt> overloads in
3582523.3.6.4 [vector.modifiers]/4 is silent about capacity changes. This
35826easily causes a misunderstanding, because the counter
35827parting insert functions described in 23.3.6.4 [vector.modifiers]/2
35828explicitly say, that
35829</p>
35830<blockquote>
35831Causes reallocation if the new size is greater than the
35832old capacity. If no reallocation happens, all the iterators
35833and references before the insertion point remain valid.
35834</blockquote>
35835<p>
35836It requires a complex argumentation chain about four
35837different places in the standard to provide the - possibly
35838weak - proof that calling <tt>clear()</tt> also does <em>never</em> change
35839the capacity of the <tt>std::vector</tt> container. Since <tt>std::vector</tt>
35840is the de-facto replacement of C99's dynamic arrays this
35841type is near to a built-in type and it's specification should
35842be clear enough that usual programmers can trust their
35843own reading.
35844</p>
35845</li>
35846</ol>
35847
35848<p><i>[
35849Batavia (2009-05):
35850]</i></p>
35851
35852<blockquote>
35853<p>
35854Bill believes paragraph 1 of the proposed resolution is unnecessary
35855because it is already implied (even if tortuously) by the current wording.
35856</p>
35857<p>
35858Move to Review.
35859</p>
35860</blockquote>
35861
35862<p><i>[
358632009-10 Santa Cruz:
35864]</i></p>
35865
35866
35867<blockquote>
35868Mark as NAD. Rationale: there is no consensus to clarify the standard,
35869general consensus that the standard is correct as written.
35870</blockquote>
35871
35872
35873
35874<p><b>Proposed resolution:</b></p>
35875<p><i>[
35876This is a minimum version. I also
35877suggest that the wording explaining the allocation strategy
35878of <tt>std::vector</tt> in 23.3.6.2 [vector.capacity]/3 and /6 is moved into
35879a separate sub paragraph of 23.3.6.2 [vector.capacity] <em>before</em>
35880any of the prototype's are discussed, but I cannot provide
35881reasonable wording changes now
35882]</i></p>
35883
35884
35885<ol>
35886<li>
35887<p>
35888Change 23.3.6.2 [vector.capacity]/6 as follows:
35889</p>
35890<blockquote>
35891It is guaranteed that no reallocation takes place during
35892insertions <ins>or erasures</ins> that happen after a call
35893to <tt>reserve()</tt> until the time when an insertion would make
35894the size of the vector greater than the value of <tt>capacity()</tt>.
35895</blockquote>
35896</li>
35897<li>
35898<p>
35899Change 23.3.6.4 [vector.modifiers]/4 as follows:
35900</p>
35901<blockquote>
35902<i>Effects:</i> <ins>The capacity shall remain unchanged and no reallocation shall
35903happen.</ins>
35904Invalidates iterators and references at or after the point
35905of the erase.
35906</blockquote>
35907</li>
35908</ol>
35909
35910
35911
35912
35913
35914<hr>
35915<h3><a name="1105"></a>1105. Shouldn't <tt>Range</tt> be an <tt>auto concept</tt></h3>
35916<p><b>Section:</b> X [iterator.concepts.range] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
35917 <b>Submitter:</b> David Abrahams <b>Opened:</b> 2009-04-23  <b>Last modified:</b> 2009-07-15</p>
35918<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
35919<p><b>Discussion:</b></p>
35920
35921<p><i>[
359222009-04-26 Herb adds:
35923]</i></p>
35924
35925
35926<blockquote>
35927<p>
35928Here's a common example: We have many ISV customers who have built lots of
35929in-house STL-like containers. Imagine that, for the past ten years, the user
35930has been happily using his <tt>XYZCorpContainer&lt;T&gt;</tt> that has <tt>begin()</tt> and <tt>end()</tt>
35931and an iterator typedef, and indeed satisfies nearly all of <tt>Container</tt>,
35932though maybe not quite all just like <tt>valarray</tt>. The user upgrades to a
35933range-enabled version of a library, and now <tt>lib_algo( xyz.begin(), xyz.end());</tt>
35934no longer works -- compiler error.
35935</p>
35936<p>
35937Even though <tt>XYZCorpContainer</tt> matches the pre-conceptized version of the
35938algorithm, and has been working for years, it appears the user has to write
35939at least this:
35940</p>
35941<blockquote><pre>template&lt;class T&gt; concept_map Range&lt;XYZCorpContainer&lt;T&gt;&gt; {};
35942
35943template&lt;class T&gt; concept_map Range&lt;const XYZCorpContainer&lt;T&gt;&gt; {};
35944</pre></blockquote>
35945<p>
35946Is that correct?
35947</p>
35948<p>
35949But he may actually have to write this as we do for initializer list:
35950</p>
35951<blockquote><pre>template&lt;class T&gt;
35952concept_map Range&lt;XYZCorpContainer&lt;T&gt;&gt; {
35953   typedef T* iterator;
35954   iterator begin(XYZCorpContainer&lt;T&gt; c) { return c.begin(); }
35955   iterator end(XYZCorpContainer&lt;T&gt; c) { return c.end(); }
35956};
35957
35958template&lt;class T&gt;
35959concept_map Range&lt;const XYZCorpContainer&lt;T&gt;&gt; {
35960   typedef T* iterator;
35961   iterator begin(XYZCorpContainer&lt;T&gt; c) { return c.begin(); }
35962   iterator end(XYZCorpContainer&lt;T&gt; c) { return c.end(); }
35963};
35964</pre></blockquote>
35965
35966</blockquote>
35967
35968<p><i>[
359692009-04-28 Alisdair adds:
35970]</i></p>
35971
35972
35973<blockquote>
35974<p>
35975I recommend NAD, although remain concerned about header organisation.
35976</p>
35977<p>
35978A user container will satisfy the <tt>MemberContainer</tt> concept, which IS auto.
35979There is a concept_map for all <tt>MemberContainers</tt> to <tt>Container</tt>, and then a
35980further concept_map for all <tt>Container</tt> to <tt>Range</tt>, so the stated problem is not
35981actually true.  User defined containers will automatically match the <tt>Range</tt>
35982concept without explicitly declaring a concept_map.
35983</p>
35984<p>
35985The problem is that they should now provide an additional two headers,
35986<tt>&lt;iterator_concepts&gt;</tt> and <tt>&lt;container_concepts&gt;</tt>.
35987 The only difference from
35988making <tt>Range</tt> an auto concept would be this reduces to a single header,
35989<tt>&lt;iterator_concepts&gt;</tt>.
35990</p>
35991<p>
35992I am strongly in favour of any resolution that tackles the issue of
35993explicitly requiring concept headers to make these concept maps available.
35994</p>
35995</blockquote>
35996
35997<p><i>[
35998Batavia (2009-05):
35999]</i></p>
36000
36001<blockquote>
36002<p>
36003We observe there is a recent paper by Bjarne that overlaps this issue.
36004</p>
36005<p>
36006Alisdair continues to recommend NAD.
36007</p>
36008<p>
36009Move to Open, and recommend the issue be deferred until after the next
36010Committee Draft is issued.
36011</p>
36012</blockquote>
36013
36014
36015<p><b>Proposed resolution:</b></p>
36016
36017
36018
36019
36020
36021<hr>
36022<h3><a name="1107"></a>1107. constructor <tt>shared_future(unique_future)</tt> by value?</h3>
36023<p><b>Section:</b> 30.6.7 [future.shared_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
36024 <b>Submitter:</b> Thomas J. Gritzan <b>Opened:</b> 2009-04-03  <b>Last modified:</b> 2009-07-13</p>
36025<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>
36026<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
36027<p><b>Discussion:</b></p>
36028<p>
36029In the <tt>shared_future</tt> class definition in 30.6.7 [future.shared_future]
36030the move constructor 
36031that constructs a <tt>shared_future</tt> from an <tt>unique_future</tt> receives the 
36032parameter by value. In paragraph 3, the same constructor receives it as 
36033const value. 
36034</p>
36035
36036<p>
36037I think that is a mistake and the constructor should take a r-value 
36038reference: 
36039</p>
36040
36041<blockquote><pre>shared_future(unique_future&lt;R&gt;&amp;&amp; rhs);
36042</pre></blockquote>
36043
36044<p><i>[
36045Batavia (2009-05):
36046]</i></p>
36047
36048<blockquote>
36049<p>
36050We agree with the proposed resolution.
36051</p>
36052<p>
36053Move to Tentatively Ready.
36054</p>
36055</blockquote>
36056
36057<p><i>[
360582009-07-05 Daniel notes:
36059]</i></p>
36060
36061
36062<blockquote>
36063The proposed change has already been incorported into the current working draft
36064<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf">N2914</a>.
36065</blockquote>
36066
36067
36068<p><b>Proposed resolution:</b></p>
36069<p>
36070Change the synopsis in 30.6.7 [future.shared_future]:
36071</p>
36072
36073<blockquote><pre>shared_future(unique_future&lt;R&gt;<ins>&amp;&amp;</ins> rhs);
36074</pre></blockquote>
36075
36076<p>
36077Change the definition of the constructor in 30.6.7 [future.shared_future]:
36078</p>
36079
36080<blockquote><pre>shared_future(<del>const</del> unique_future&lt;R&gt;<ins>&amp;&amp;</ins> rhs);
36081</pre></blockquote>
36082
36083
36084
36085
36086
36087
36088<hr>
36089<h3><a name="1109"></a>1109. <tt>std::includes</tt> should require <tt>CopyConstructible</tt> predicate</h3>
36090<p><b>Section:</b> 25.4.5.1 [includes] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
36091 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-04-28  <b>Last modified:</b> 2009-07-13</p>
36092<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#includes">issues</a> in [includes].</p>
36093<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
36094<p><b>Discussion:</b></p>
36095<p>
36096All the set operation algorithms require a <tt>CopyConstructible</tt> predicate, with
36097the exception of <tt>std::includes</tt>.  This looks like a typo as much as anything,
36098given the general library requirement that predicates are copy
36099constructible, and wording style of other set-like operations.
36100</p>
36101
36102<p><i>[
36103Batavia (2009-05):
36104]</i></p>
36105
36106<blockquote>
36107We agree with the proposed resolution.
36108Move to NAD Editorial.
36109</blockquote>
36110
36111
36112<p><b>Proposed resolution:</b></p>
36113<p>
36114Change  [algorithms.syn] and 25.4.5.1 [includes]:
36115</p>
36116
36117<blockquote><pre>template&lt;InputIterator Iter1, InputIterator Iter2,
36118         <del>typename</del> <ins>CopyConstructible</ins> Compare&gt;
36119  requires Predicate&lt;Compare, Iter1::value_type, Iter2::value_type&gt;
36120        &amp;&amp; Predicate&lt;Compare, Iter2::value_type, Iter1::value_type&gt;
36121  bool includes(Iter1 first1, Iter1 last1,
36122                Iter2 first2, Iter2 last2,
36123                Compare comp);
36124</pre></blockquote>
36125
36126
36127
36128
36129
36130<hr>
36131<h3><a name="1111"></a>1111. associative containers underconstrained</h3>
36132<p><b>Section:</b> 23.4 [associative] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
36133 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-04-29  <b>Last modified:</b> 2009-07-16</p>
36134<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative">issues</a> in [associative].</p>
36135<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
36136<p><b>Discussion:</b></p>
36137<p>
36138According to table 87 (n2857) the expression <tt>X::key_equal</tt> for an unordered
36139container shall return a value of type <tt>Pred</tt>, where <tt>Pred</tt> is an equivalence
36140relation.
36141</p>
36142
36143<p>
36144However, all 4 containers constrain <tt>Pred</tt> to be merely a <tt>Predicate</tt>,
36145and not <tt>EquivalenceRelation</tt>.
36146</p>
36147
36148<p><i>[
36149Batavia (2009-05):
36150]</i></p>
36151
36152<blockquote>
36153<p>
36154We agree with the proposed resolution.
36155</p>
36156<p>
36157Move to Review.
36158</p>
36159</blockquote>
36160
36161
36162<p><b>Proposed resolution:</b></p>
36163<p>
36164For ordered containers, replace 
36165</p>
36166<blockquote><pre>Predicate&lt;auto, Key, Key&gt; Compare = less&lt;Key&gt;
36167</pre></blockquote>
36168<p>
36169with 
36170</p>
36171<blockquote><pre>StrictWeakOrder&lt;auto, Key, Key&gt; Compare = less&lt;Key&gt;
36172</pre></blockquote>
36173
36174<p>
36175For unordered containers, replace 
36176</p>
36177<blockquote><pre>Predicate&lt;auto, Key, Key&gt; Compare = less&lt;Key&gt;
36178</pre></blockquote>
36179<p>
36180with 
36181</p>
36182<blockquote><pre>EquivalenceRelation&lt;auto, Key, Key&gt; Compare = less&lt;Key&gt;
36183</pre></blockquote>
36184<p>
36185As in the following declarations:
36186</p>
36187
36188<blockquote>
36189<p>
36190Associative containers 23.4 [associative]
36191</p>
36192<p>
36193 1 Headers &lt;map&gt; and &lt;set&gt;:
36194</p>
36195<p>
36196   Header &lt;map&gt; synopsis
36197</p>
36198<blockquote><pre>   namespace std {
36199     template &lt;ValueType Key, ValueType T,
36200               <del>Predicate</del><ins>StrictWeakOrder</ins>&lt;auto, Key<del>, Key</del>&gt; Compare = less&lt;Key&gt;,
36201               Allocator Alloc = allocator&lt;pair&amp;lt;&lt;b&gt;const Key, T&gt; &gt; &gt;
36202       requires NothrowDestructible&lt;Key&gt; &amp;&amp; NothrowDestructible&lt;T&gt;
36203             &amp;&amp; CopyConstructible&lt;Compare&gt;
36204             &amp;&amp; AllocatableElement&lt;Alloc, Compare, const Compare&amp;&gt;
36205             &amp;&amp; AllocatableElement&lt;Alloc, Compare, Compare&amp;&amp;&gt;
36206     class map;
36207
36208     ...
36209
36210     template &lt;ValueType Key, ValueType T,
36211               <del>Predicate</del><ins>StrictWeakOrder</ins>&lt;auto, Key<del>, Key</del>&gt; Compare = less&lt;Key&gt;,
36212               Allocator Alloc = allocator&lt;pair&amp;lt;&lt;b&gt;const Key, T&gt; &gt; &gt;
36213       requires NothrowDestructible&lt;Key&gt; &amp;&amp; NothrowDestructible&lt;T&gt;
36214             &amp;&amp; CopyConstructible&lt;Compare&gt;
36215             &amp;&amp; AllocatableElement&lt;Alloc, Compare, const Compare&amp;&gt;
36216             &amp;&amp; AllocatableElement&lt;Alloc, Compare, Compare&amp;&amp;&gt;
36217     class multimap;
36218
36219     ...
36220
36221   }
36222</pre></blockquote>
36223
36224<p>
36225   Header &lt;set&gt; synopsis
36226</p>
36227<blockquote><pre>   namespace std {
36228     template &lt;ValueType Key, <del>Predicate</del><ins>StrictWeakOrder</ins>&lt;auto, Key<del>, Key</del>&gt; Compare = less&lt;Key&gt;,
36229               Allocator Alloc = allocator&lt;Key&gt; &gt;
36230       requires NothrowDestructible&lt;Key&gt; &amp;&amp; CopyConstructible&lt;Compare&gt;
36231             &amp;&amp; AllocatableElement&lt;Alloc, Compare, const Compare&amp;&gt;
36232             &amp;&amp; AllocatableElement&lt;Alloc, Compare, Compare&amp;&amp;&gt;
36233     class set;
36234
36235     ...
36236
36237     template &lt;ValueType Key, <del>Predicate</del><ins>StrictWeakOrder</ins>&lt;auto, Key<del>, Key</del>&gt; Compare = less&lt;Key&gt;,
36238               Allocator Alloc = allocator&lt;Key&gt; &gt;
36239       requires NothrowDestructible&lt;Key&gt; &amp;&amp; CopyConstructible&lt;Compare&gt;
36240             &amp;&amp; AllocatableElement&lt;Alloc, Compare, const Compare&amp;&gt;
36241             &amp;&amp; AllocatableElement&lt;Alloc, Compare, Compare&amp;&amp;&gt;
36242     class multiset;
36243
36244     ...
36245
36246   }
36247</pre></blockquote>
36248
36249<p>
36250 23.4.1p2 Class template map [map]
36251</p>
36252<blockquote><pre> namespace std {
36253   template &lt;ValueType Key, ValueType T,
36254             <del>Predicate</del><ins>StrictWeakOrder</ins>&lt;auto, Key<del>, Key</del>&gt; Compare = less&lt;Key&gt;,
36255             Allocator Alloc = allocator&lt;pair&amp;lt;&lt;b&gt;const Key, T&gt; &gt; &gt;
36256     requires NothrowDestructible&lt;Key&gt; &amp;&amp; NothrowDestructible&lt;T&gt;
36257           &amp;&amp; CopyConstructible&lt;Compare&gt;
36258           &amp;&amp; AllocatableElement&lt;Alloc, Compare, const Compare&amp;&gt;
36259           &amp;&amp; AllocatableElement&lt;Alloc, Compare, Compare&amp;&amp;&gt;
36260   class map {
36261     ...
36262   };
36263 }
36264</pre></blockquote>
36265
36266
36267<p>
36268 23.4.2p2 Class template multimap [multimap]
36269</p>
36270<blockquote><pre> namespace std {
36271   template &lt;ValueType Key, ValueType T,
36272             <del>Predicate</del><ins>StrictWeakOrder</ins>&lt;auto, Key<del>, Key</del>&gt; Compare = less&lt;Key&gt;,
36273             Allocator Alloc = allocator&lt;pair&amp;lt;&lt;b&gt;const Key, T&gt; &gt; &gt;
36274     requires NothrowDestructible&lt;Key&gt; &amp;&amp; NothrowDestructible&lt;T&gt;
36275           &amp;&amp; CopyConstructible&lt;Compare&gt;
36276           &amp;&amp; AllocatableElement&lt;Alloc, Compare, const Compare&amp;&gt;
36277           &amp;&amp; AllocatableElement&lt;Alloc, Compare, Compare&amp;&amp;&gt;
36278   class multimap {
36279     ...
36280   };
36281 }
36282</pre></blockquote>
36283
36284
36285<p>
36286 23.4.3p2 Class template set [set]
36287</p>
36288<blockquote><pre> namespace std {
36289   template &lt;ValueType Key, <del>Predicate</del><ins>StrictWeakOrder</ins>&lt;auto, Key<del>, Key</del>&gt; Compare = less&lt;Key&gt;,
36290             Allocator Alloc = allocator&lt;Key&gt; &gt;
36291     requires NothrowDestructible&lt;Key&gt; &amp;&amp; CopyConstructible&lt;Compare&gt;
36292           &amp;&amp; AllocatableElement&lt;Alloc, Compare, const Compare&amp;&gt;
36293           &amp;&amp; AllocatableElement&lt;Alloc, Compare, Compare&amp;&amp;&gt;
36294   class set {
36295     ...
36296   };
36297 }
36298</pre></blockquote>
36299
36300
36301<p>
36302 23.4.4p2 Class template multiset [multiset]
36303</p>
36304<blockquote><pre> namespace std {
36305   template &lt;ValueType Key, <del>Predicate</del><ins>StrictWeakOrder</ins>&lt;auto, Key<del>, Key</del>&gt; Compare = less&lt;Key&gt;,
36306             Allocator Alloc = allocator&lt;Key&gt; &gt;
36307     requires NothrowDestructible&lt;Key&gt; &amp;&amp; CopyConstructible&lt;Compare&gt;
36308           &amp;&amp; AllocatableElement&lt;Alloc, Compare, const Compare&amp;&gt;
36309           &amp;&amp; AllocatableElement&lt;Alloc, Compare, Compare&amp;&amp;&gt;
36310   class multiset {
36311     ...
36312   };
36313 }
36314</pre></blockquote>
36315
36316<p>
36317 23.5 Unordered associative containers [unord]
36318</p>
36319<p>
36320 1 Headers &lt;unordered_map&gt; and &lt;unordered_set&gt;:
36321</p>
36322<p>
36323 Header &lt;unordered_map&gt; synopsis
36324</p>
36325<blockquote><pre> namespace std {
36326   // 23.5.1, class template unordered_map:
36327   template &lt;ValueType Key,
36328             ValueType T,
36329             Callable&lt;auto, const Key&amp;&gt; Hash = hash&lt;Key&gt;,
36330             <del>Predicate</del><ins>EquivalenceRelation</ins>&lt;auto, Key<del>, Key</del>&gt; Pred = equal_to&lt;Key&gt;,
36331             Allocator Alloc = allocator&lt;pair&amp;lt;&lt;b&gt;const Key, T&gt; &gt; &gt;
36332     requires NothrowDestructible&lt;Key&gt; &amp;&amp; NothrowDestructible&lt;T&gt;
36333           &amp;&amp; SameType&lt;Hash::result_type, size_t&gt;
36334           &amp;&amp; CopyConstructible&lt;Hash&gt; &amp;&amp; CopyConstructible&lt;Pred&gt;
36335           &amp;&amp; AllocatableElement&lt;Alloc, Pred, const Pred&amp;&gt;
36336           &amp;&amp; AllocatableElement&lt;Alloc, Pred, Pred&amp;&amp;&gt;
36337           &amp;&amp; AllocatableElement&lt;Alloc, Hash, const Hash&amp;&gt;
36338           &amp;&amp; AllocatableElement&lt;Alloc, Hash, Hash&amp;&amp;&gt;
36339     class unordered_map;
36340
36341   // 23.5.2, class template unordered_multimap:
36342   template &lt;ValueType Key,
36343             ValueType T,
36344             Callable&lt;auto, const Key&amp;&gt; Hash = hash&lt;Key&gt;,
36345             <del>Predicate</del><ins>EquivalenceRelation</ins>&lt;auto, Key<del>, Key</del>&gt; Pred = equal_to&lt;Key&gt;,
36346             Allocator Alloc = allocator&lt;pair&amp;lt;&lt;b&gt;const Key, T&gt; &gt; &gt;
36347     requires NothrowDestructible&lt;Key&gt; &amp;&amp; NothrowDestructible&lt;T&gt;
36348           &amp;&amp; SameType&lt;Hash::result_type, size_t&gt;
36349           &amp;&amp; CopyConstructible&lt;Hash&gt; &amp;&amp; CopyConstructible&lt;Pred&gt;
36350           &amp;&amp; AllocatableElement&lt;Alloc, Pred, const Pred&amp;&gt;
36351           &amp;&amp; AllocatableElement&lt;Alloc, Pred, Pred&amp;&amp;&gt;
36352           &amp;&amp; AllocatableElement&lt;Alloc, Hash, const Hash&amp;&gt;
36353           &amp;&amp; AllocatableElement&lt;Alloc, Hash, Hash&amp;&amp;&gt;
36354     class unordered_multimap;
36355
36356   ...
36357 }
36358</pre></blockquote>
36359
36360<p>
36361 Header &lt;unordered_set&gt; synopsis
36362</p>
36363<blockquote><pre> namespace std {
36364   // 23.5.3, class template unordered_set:
36365   template &lt;ValueType Value,
36366             Callable&lt;auto, const Value&amp;&gt; Hash = hash&lt;Value&gt;,
36367             <del>Predicate</del><ins>EquivalenceRelation</ins>&lt;auto, Value<del>, Value</del>&gt; class Pred = equal_to&lt;Value&gt;,
36368             Allocator Alloc = allocator&lt;Value&gt; &gt;
36369     requires NothrowDestructible&lt;Value&gt;
36370           &amp;&amp; SameType&lt;Hash::result_type, size_t&gt;
36371           &amp;&amp; CopyConstructible&lt;Hash&gt; &amp;&amp; CopyConstructible&lt;Pred&gt;
36372           &amp;&amp; AllocatableElement&lt;Alloc, Pred, const Pred&amp;&gt;
36373           &amp;&amp; AllocatableElement&lt;Alloc, Pred, Pred&amp;&amp;&gt;
36374           &amp;&amp; AllocatableElement&lt;Alloc, Hash, const Hash&amp;&gt;
36375           &amp;&amp; AllocatableElement&lt;Alloc, Hash, Hash&amp;&amp;&gt;
36376     class unordered_set;
36377
36378   // 23.5.4, class template unordered_multiset:
36379   template &lt;ValueType Value,
36380             Callable&lt;auto, const Value&amp;&gt; Hash = hash&lt;Value&gt;,
36381             <del>Predicate</del><ins>EquivalenceRelation</ins>&lt;auto, Value<del>, Value</del>&gt; class Pred = equal_to&lt;Value&gt;,
36382             Allocator Alloc = allocator&lt;Value&gt; &gt;
36383     requires NothrowDestructible&lt;Value&gt;
36384           &amp;&amp; SameType&lt;Hash::result_type, size_t&gt;
36385           &amp;&amp; CopyConstructible&lt;Hash&gt; &amp;&amp; CopyConstructible&lt;Pred&gt;
36386           &amp;&amp; AllocatableElement&lt;Alloc, Pred, const Pred&amp;&gt;
36387           &amp;&amp; AllocatableElement&lt;Alloc, Pred, Pred&amp;&amp;&gt;
36388           &amp;&amp; AllocatableElement&lt;Alloc, Hash, const Hash&amp;&gt;
36389           &amp;&amp; AllocatableElement&lt;Alloc, Hash, Hash&amp;&amp;&gt;
36390     class unordered_multiset;
36391
36392   ...
36393 }
36394</pre></blockquote>
36395
36396<p>
36397 23.5.1p3 Class template unordered_map [unord.map]
36398</p>
36399<blockquote><pre> namespace std {
36400   template &lt;ValueType Key,
36401             ValueType T,
36402             Callable&lt;auto, const Key&amp;&gt; Hash = hash&lt;Key&gt;,
36403             <del>Predicate</del><ins>EquivalenceRelation</ins>&lt;auto, Key<del>, Key</del>&gt; Pred = equal_to&lt;Key&gt;,
36404             Allocator Alloc = allocator&lt;pair&amp;lt;&lt;b&gt;const Key, T&gt; &gt; &gt;
36405     requires NothrowDestructible&lt;Key&gt; &amp;&amp; NothrowDestructible&lt;T&gt;
36406           &amp;&amp; SameType&lt;Hash::result_type, size_t&gt;
36407           &amp;&amp; CopyConstructible&lt;Hash&gt; &amp;&amp; CopyConstructible&lt;Pred&gt;
36408           &amp;&amp; AllocatableElement&lt;Alloc, Pred, const Pred&amp;&gt;
36409           &amp;&amp; AllocatableElement&lt;Alloc, Pred, Pred&amp;&amp;&gt;
36410           &amp;&amp; AllocatableElement&lt;Alloc, Hash, const Hash&amp;&gt;
36411           &amp;&amp; AllocatableElement&lt;Alloc, Hash, Hash&amp;&amp;&gt;
36412   class unordered_map
36413   {
36414     ...
36415   };
36416 }
36417</pre></blockquote>
36418
36419<p>
36420 23.5.2p3 Class template unordered_multimap [unord.multimap]
36421</p>
36422<blockquote><pre> namespace std {
36423   template &lt;ValueType Key,
36424             ValueType T,
36425             Callable&lt;auto, const Key&amp;&gt; Hash = hash&lt;Key&gt;,
36426             <del>Predicate</del><ins>EquivalenceRelation</ins>&lt;auto, Key<del>, Key</del>&gt; Pred = equal_to&lt;Key&gt;,
36427             Allocator Alloc = allocator&lt;pair&amp;lt;&lt;b&gt;const Key, T&gt; &gt; &gt;
36428     requires NothrowDestructible&lt;Key&gt; &amp;&amp; NothrowDestructible&lt;T&gt;
36429           &amp;&amp; SameType&lt;Hash::result_type, size_t&gt;
36430           &amp;&amp; CopyConstructible&lt;Hash&gt; &amp;&amp; CopyConstructible&lt;Pred&gt;
36431           &amp;&amp; AllocatableElement&lt;Alloc, Pred, const Pred&amp;&gt;
36432           &amp;&amp; AllocatableElement&lt;Alloc, Pred, Pred&amp;&amp;&gt;
36433           &amp;&amp; AllocatableElement&lt;Alloc, Hash, const Hash&amp;&gt;
36434           &amp;&amp; AllocatableElement&lt;Alloc, Hash, Hash&amp;&amp;&gt;
36435   class unordered_multimap
36436   {
36437     ...
36438   };
36439 }
36440</pre></blockquote>
36441
36442<p>
36443 23.5.3p3 Class template unordered_set [unord.set]
36444</p>
36445<blockquote><pre> namespace std {
36446   template &lt;ValueType Value,
36447             Callable&lt;auto, const Value&amp;&gt; Hash = hash&lt;Value&gt;,
36448             <del>Predicate</del><ins>EquivalenceRelation</ins>&lt;auto, Value<del>, Value</del>&gt; class Pred = equal_to&lt;Value&gt;,
36449             Allocator Alloc = allocator&lt;Value&gt; &gt;
36450     requires NothrowDestructible&lt;Value&gt;
36451           &amp;&amp; SameType&lt;Hash::result_type, size_t&gt;
36452           &amp;&amp; CopyConstructible&lt;Hash&gt; &amp;&amp; CopyConstructible&lt;Pred&gt;
36453           &amp;&amp; AllocatableElement&lt;Alloc, Pred, const Pred&amp;&gt;
36454           &amp;&amp; AllocatableElement&lt;Alloc, Pred, Pred&amp;&amp;&gt;
36455           &amp;&amp; AllocatableElement&lt;Alloc, Hash, const Hash&amp;&gt;
36456           &amp;&amp; AllocatableElement&lt;Alloc, Hash, Hash&amp;&amp;&gt;
36457   class unordered_set
36458   {
36459     ...
36460   };
36461 }
36462</pre></blockquote>
36463<p>
36464 23.5.4p3 Class template unordered_multiset [unord.multiset]
36465</p>
36466<blockquote><pre> namespace std {
36467   template &lt;ValueType Value,
36468             Callable&lt;auto, const Value&amp;&gt; Hash = hash&lt;Value&gt;,
36469             <del>Predicate</del><ins>EquivalenceRelation</ins>&lt;auto, Value<del>, Value</del>&gt; class Pred = equal_to&lt;Value&gt;,
36470             Allocator Alloc = allocator&lt;Value&gt; &gt;
36471     requires NothrowDestructible&lt;Value&gt;
36472           &amp;&amp; SameType&lt;Hash::result_type, size_t&gt;
36473           &amp;&amp; CopyConstructible&lt;Hash&gt; &amp;&amp; CopyConstructible&lt;Pred&gt;
36474           &amp;&amp; AllocatableElement&lt;Alloc, Pred, const Pred&amp;&gt;
36475           &amp;&amp; AllocatableElement&lt;Alloc, Pred, Pred&amp;&amp;&gt;
36476           &amp;&amp; AllocatableElement&lt;Alloc, Hash, const Hash&amp;&gt;
36477           &amp;&amp; AllocatableElement&lt;Alloc, Hash, Hash&amp;&amp;&gt;
36478   class unordered_multiset
36479   {
36480     ...
36481   };
36482 }
36483</pre></blockquote>
36484
36485</blockquote>
36486
36487
36488
36489
36490
36491
36492<hr>
36493<h3><a name="1116"></a>1116. Literal constructors for tuple</h3>
36494<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#NAD%20Editorial">NAD Editorial</a>
36495 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23  <b>Last modified:</b> 2009-10-26</p>
36496<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>
36497<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
36498<p><b>Discussion:</b></p>
36499<p>
36500It is not currently possible to construct <tt>tuple</tt> literal values,
36501even if the elements are all literal types.  This is because parameters
36502are passed to constructor by reference.
36503</p>
36504<p>
36505An alternative would be to pass all constructor arguments by value, where it
36506is known that *all* elements are literal types.  This can be determined with
36507concepts, although note that the negative constraint really requires
36508factoring out a separate concept, as there is no way to provide an 'any of
36509these fails' constraint inline.
36510</p>
36511<p>
36512Note that we will have similar issues with <tt>pair</tt> (and
36513<tt>tuple</tt> constructors from <tt>pair</tt>) although I am steering
36514clear of that class while other constructor-related issues settle.
36515</p>
36516
36517<p><i>[
365182009-10 Santa Cruz:
36519]</i></p>
36520
36521
36522<blockquote>
36523NAD Editorial.  Solved by
36524<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2994.html">N2994</a>.
36525</blockquote>
36526
36527
36528<p><b>Proposed resolution:</b></p>
36529<p>
36530Ammend the tuple class template declaration in 20.5.2 [tuple.tuple] as
36531follows
36532</p>
36533
36534<blockquote>
36535<p>
36536Add the following concept:
36537</p>
36538
36539<blockquote><pre>auto concept AllLiteral&lt; typename ... Types &gt; {
36540  requires LiteralType&lt;Types&gt;...;
36541}
36542</pre></blockquote>
36543
36544<p>
36545ammend the constructor 
36546</p>
36547
36548<blockquote><pre><ins>template &lt;class... UTypes&gt;
36549  requires AllLiteral&lt;Types...&gt;
36550        &amp;&amp; Constructible&lt;Types, UTypes&gt;...
36551  explicit tuple(UTypes...);</ins>
36552
36553template &lt;class... UTypes&gt;
36554  requires <ins>!AllLiteral&lt;Types...&gt;</ins>
36555        <ins>&amp;&amp;</ins> Constructible&lt;Types, UTypes&amp;&amp;&gt;...
36556  explicit tuple(UTypes&amp;&amp;...);
36557</pre></blockquote>
36558
36559<p>
36560ammend the constructor
36561</p>
36562
36563<blockquote><pre><ins>template &lt;class... UTypes&gt;
36564  requires AllLiteral&lt;Types...&gt;
36565        &amp;&amp; Constructible&lt;Types, UTypes&gt;...
36566  tuple(tuple&lt;UTypes...&gt;);</ins>
36567
36568template &lt;class... UTypes&gt;
36569  requires <ins>!AllLiteral&lt;Types...&gt;</ins>
36570        <ins>&amp;&amp;</ins> Constructible&lt;Types, const UTypes&amp;&gt;...
36571  tuple(const tuple&lt;UTypes...&gt;&amp;);
36572</pre></blockquote>
36573
36574</blockquote>
36575
36576<p>
36577Update the same signatures in 20.5.2.1 [tuple.cnstr], paras 3 and 5.
36578</p>
36579
36580
36581
36582
36583
36584<hr>
36585<h3><a name="1117"></a>1117. tuple copy constructor</h3>
36586<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#NAD%20Editorial">NAD Editorial</a>
36587 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23  <b>Last modified:</b> 2009-10-26</p>
36588<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>
36589<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
36590<p><b>Discussion:</b></p>
36591<p>
36592The copy constructor for the <tt>tuple</tt> template is constrained.  This seems an
36593unusual strategy, as the copy constructor will be implicitly deleted if the
36594constraints are not met.  This is exactly the same effect as requesting an
36595<tt>=default;</tt> constructor.  The advantage of the latter is that it retains
36596triviality, and provides support for <tt>tuple</tt>s as literal types if issue
36597<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1116">1116</a> is also accepted.
36598</p>
36599<p>
36600Actually, it might be worth checking with core if a constrained copy
36601constructor is treated as a constructor template, and as such does not
36602suppress the implicit generation of the copy constructor which would hide
36603the template in this case.
36604</p>
36605
36606<p><i>[
366072009-05-27 Daniel adds:
36608]</i></p>
36609
36610
36611<blockquote>
36612This 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>.
36613</blockquote>
36614
36615<p><i>[
366162009-10 Santa Cruz:
36617]</i></p>
36618
36619
36620<blockquote>
36621NAD Editorial.  Solved by
36622<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2994.html">N2994</a>.
36623</blockquote>
36624
36625
36626<p><b>Proposed resolution:</b></p>
36627<p>
36628Change 20.5.2 [tuple.tuple] and 20.5.2.1 [tuple.cnstr] p4:
36629</p>
36630
36631<blockquote><pre><del>requires CopyConstructible&lt;Types&gt;...</del> tuple(const tuple&amp;)<ins> = default</ins>;
36632</pre></blockquote>
36633
36634
36635
36636
36637
36638<hr>
36639<h3><a name="1120"></a>1120. New type trait - remove_all</h3>
36640<p><b>Section:</b> 20.6 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
36641 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-23  <b>Last modified:</b> 2009-10-26</p>
36642<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>
36643<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
36644<p><b>Discussion:</b></p>
36645<p>
36646Sometimes it is necessary to remove all qualifiers from a type before
36647passing on to a further API.  A good example would be calling the
36648<tt>tuple</tt> query APIs <tt>tuple_size</tt> or <tt>tuple_element</tt>
36649with a deduced type inside a function template.  If the deduced type is
36650cv-qualified or a reference then the call will fail.  The solution is to
36651chain calls to
36652<tt>remove_cv&lt;remove_reference&lt;T&gt;::type&gt;::type</tt>, and
36653note that the order matters.
36654</p>
36655<p>
36656Suggest it would be helpful to add a new type trait,
36657<tt>remove_all</tt>, that removes all top-level qualifiers from a type
36658i.e. cv-qualification and any references.  Define the term in such a way
36659that if additional qualifiers are added to the language, then
36660<tt>remove_all</tt> is defined as stripping those as well.
36661</p>
36662
36663<p><i>[
366642009-10-14 Daniel adds:
36665]</i></p>
36666
36667
36668<blockquote>
36669<tt>remove_all</tt> seems too generic, a possible alternative matching
36670the current naming style could be <tt>remove_cv_reference</tt> or
36671<tt>remove_reference_cv</tt>. It should also be considered whether this
36672trait should also remove 'extents', or pointer 'decorations'. Especially
36673if the latter situations are considered as well, it might be easier to
36674chose the name not in terms of what it <em>removes</em> (which might be
36675a lot), but in terms of it <em>creates</em>. In this case I could think
36676of e.g. <tt>extract_value_type</tt>.
36677</blockquote>
36678
36679<p><i>[
366802009-10 Santa Cruz:
36681]</i></p>
36682
36683
36684<blockquote>
36685NAD Future.
36686</blockquote>
36687
36688
36689
36690<p><b>Proposed resolution:</b></p>
36691
36692
36693
36694
36695
36696<hr>
36697<h3><a name="1122"></a>1122. Ratio values should be constexpr</h3>
36698<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#NAD%20Editorial">NAD Editorial</a>
36699 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-25  <b>Last modified:</b> 2009-10-26</p>
36700<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>
36701<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
36702<p><b>Discussion:</b></p>
36703<p>
36704The values <tt>num</tt> and <tt>den</tt> in the <tt>ratio</tt> template
36705should be declared <tt>constexpr</tt>.
36706</p>
36707
36708<p><i>[
367092009-10 Santa Cruz:
36710]</i></p>
36711
36712
36713<blockquote>
36714NAD Editorial.  Solved by
36715<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2994.html">N2994</a>.
36716</blockquote>
36717
36718
36719<p><b>Proposed resolution:</b></p>
36720<p>
3672120.4.1 [ratio.ratio]
36722</p>
36723
36724<blockquote><pre>namespace std {
36725  template &lt;intmax_t N, intmax_t D = 1&gt;
36726  class ratio {
36727  public:
36728    static const<ins>expr</ins> intmax_t num;
36729    static const<ins>expr</ins> intmax_t den;
36730  };
36731}
36732</pre></blockquote>
36733
36734
36735
36736
36737
36738
36739<hr>
36740<h3><a name="1124"></a>1124.  Invalid definition of concept RvalueOf</h3>
36741<p><b>Section:</b> X [concept.transform] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
36742 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-05-28  <b>Last modified:</b> 2009-07-15</p>
36743<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#concept.transform">issues</a> in [concept.transform].</p>
36744<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
36745<p><b>Discussion:</b></p>
36746<p>
36747A recent news group
36748<a href="http://groups.google.de/group/comp.std.c++/browse_frm/thread/8eb92768a19fb46f">article</a>
36749points to several defects in the
36750specification of reference-related concepts.
36751</p>
36752<p>
36753One problem of the concept <tt>RvalueOf</tt> as currently defined in
36754X [concept.transform]:
36755</p>
36756
36757<blockquote><pre>concept RvalueOf&lt;typename T&gt; {
36758 typename type = T&amp;&amp;;
36759 requires ExplicitlyConvertible&lt;T&amp;,type&gt; &amp;&amp; Convertible&lt;T&amp;&amp;,type&gt;;
36760}
36761
36762template&lt;typename T&gt; concept_map RvalueOf&lt;T&amp;&gt; {
36763 typedef T&amp;&amp; type;
36764}
36765</pre></blockquote>
36766
36767<p>
36768is that if <tt>T</tt> is an lvalue-reference, the requirement
36769<tt>Convertible&lt;T&amp;&amp;,type&gt;</tt> isn't satisfied for
36770lvalue-references, because after reference-collapsing in the concept
36771definition we have <tt>Convertible&lt;T&amp;,type&gt;</tt> in this case,
36772which isn't satisfied in the concept map template and also is not the
36773right constraint either. I think that the reporter is right that
36774<tt>SameType</tt> requirements should do the job and that we also should
36775use the new <tt>RvalueReference</tt> concept to specify a best matching
36776type requirement.
36777</p>
36778
36779
36780<p><b>Proposed resolution:</b></p>
36781<p>
36782In X [concept.transform] before p. 4 change as indicated:
36783</p>
36784
36785<blockquote><pre>auto concept RvalueOf&lt;typename T&gt; {
36786  <del>typename</del><ins>RvalueReference</ins> type = T&amp;&amp;;
36787  requires <del>ExplicitlyConvertible&lt;T&amp;, type&gt; &amp;&amp; Convertible&lt;T&amp;&amp;, type&gt;</del><ins>SameType&lt;T&amp;, type&amp;&gt;</ins>;
36788}
36789</pre></blockquote>
36790
36791
36792
36793
36794
36795<hr>
36796<h3><a name="1127"></a>1127. rvalue references and iterator traits</h3>
36797<p><b>Section:</b> 24.4.1 [iterator.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
36798 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-28  <b>Last modified:</b> 2009-07-15</p>
36799<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.traits">issues</a> in [iterator.traits].</p>
36800<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
36801<p><b>Discussion:</b></p>
36802<p>
36803The deprecated support for <tt>iterator_traits</tt> and legacy (unconstrained)
36804iterators features the (exposition only) concept:
36805</p>
36806
36807<blockquote><pre>concept IsReference&lt;typename T&gt; { } // exposition only
36808template&lt;typename T&gt; concept_map IsReference&lt;T&amp;&gt; { }
36809</pre></blockquote>
36810<p>
36811Now this looks exactly like the <tt>LvalueReference</tt> concept recently added to
36812clause 20, so I wonder if we should use that instead?
36813Then I consider the lack of rvalue-reference support, which means that
36814<tt>move_iterator</tt> would always flag as merely supporting the <tt>input_iterator_tag</tt>
36815category.  This suggests we retain the exposition concept, but add a second
36816concept_map to support rvalue references.
36817</p>
36818<p>
36819I would suggest adding the extra concept_map is the right way forward, but
36820still wonder if the two exposition-only concepts in this clause might be
36821worth promoting to clause 20.  That question might better be answered with a
36822fuller investigation of type_trait/concept unification though.
36823</p>
36824
36825
36826<p><b>Proposed resolution:</b></p>
36827<p>
36828In Iterator traits 24.4.1 [iterator.traits] para 4 add:
36829</p>
36830
36831<blockquote><pre>concept IsReference&lt;typename T&gt; { } // exposition only
36832template&lt;typename T&gt; concept_map IsReference&lt;T&amp;&gt; { }
36833<ins>template&lt;typename T&gt; concept_map IsReference&lt;T&amp;&amp;&gt; { }</ins>
36834</pre></blockquote>
36835
36836
36837
36838
36839
36840
36841<hr>
36842<h3><a name="1128"></a>1128. Missing definition of <tt>iterator_traits&lt;T*&gt;</tt></h3>
36843<p><b>Section:</b> X [iterator.syn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
36844 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-28  <b>Last modified:</b> 2009-07-16</p>
36845<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
36846<p><b>Discussion:</b></p>
36847<p>
36848The <tt>&lt;iterator&gt;</tt> header synopsis declares a partial specialization of
36849<tt>iterator_traits</tt> to support pointers, X [iterator.syn].  The implication
36850is that specialization will be described in D10, yet it did not follow the
36851rest of the deprecated material into this clause.
36852</p>
36853<p>
36854However, this is not as bad as it first seems!
36855There are partial specializations of <tt>iterator_traits</tt> for types that satisfy
36856the various Iterator concepts, and there are concept_maps for pointers to
36857explicitly support the <tt>RandomAccessIterator</tt> concept, so the required
36858template will be present - just not in the manner advertised.
36859</p>
36860<p>
36861I can see two obvious solutions:
36862</p>
36863
36864<ol type="i">
36865<li>
36866Restore the <tt>iterator_traits&lt;T*&gt;</tt> partial specialization in D.10
36867</li>
36868<li>
36869Remove the declaration of <tt>iterator_traits&lt;T*&gt;</tt> from 24.3 synopsis
36870</li>
36871</ol>
36872<p>
36873I recommend option (ii) in the wording below
36874</p>
36875<p>
36876Option (ii) could be extended to strike all the declarations of deprecated
36877material from the synopsis, as it is effectively duplicating D.10 anyway.
36878This is the approach taken for deprecated library components in the 98/03
36879standards.  This is probably a matter best left to the Editor though.
36880</p>
36881
36882
36883<p><b>Proposed resolution:</b></p>
36884<p>
36885In X [iterator.syn] strike:
36886</p>
36887
36888<blockquote><pre><del>template&lt;class T&gt; struct iterator_traits&lt;T*&gt;;</del>
36889</pre></blockquote>
36890
36891
36892
36893
36894
36895
36896<hr>
36897<h3><a name="1129"></a>1129. <tt>istream(buf)_iterator</tt> should support literal sentinel value</h3>
36898<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#NAD%20Editorial">NAD Editorial</a>
36899 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-05-30  <b>Last modified:</b> 2009-10-26</p>
36900<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
36901<p><b>Discussion:</b></p>
36902<p>
36903<tt>istream_iterator</tt> and <tt>istreambuf_iterator</tt> should support literal sentinel
36904values.  The default constructor is frequently used to terminate ranges, and
36905could easily be a literal value for <tt>istreambuf_iterator</tt>, and
36906<tt>istream_iterator</tt> when iterating value types.  A little more work using a
36907suitably sized/aligned char-array for storage (or an updated component like
36908<tt>boost::optional</tt> proposed for TR2) would allow <tt>istream_iterator</tt> to support
36909<tt>constexpr</tt> default constructor in all cases, although we might leave this
36910tweak as a QoI issue.  Note that requiring <tt>constexpr</tt> be supported also
36911allows us to place no-throw guarantees on this constructor too.
36912</p>
36913
36914<p><i>[
369152009-06-02 Daniel adds:
36916]</i></p>
36917
36918
36919<blockquote>
36920<p>
36921I agree with the usefulness of the issue suggestion, but we need
36922to ensure that <tt>istream_iterator</tt> <em>can</em> satisfy be literal if needed.
36923Currently this is not clear, because 24.6.1 [istream.iterator]/3 declares
36924a copy constructor and a destructor and explains their semantic in
3692524.6.1.1 [istream.iterator.cons]/3+4.
36926</p>
36927<p>
36928The prototype semantic specification is ok (although it seems
36929somewhat redundant to me, because the semantic doesn't say
36930anything interesting in both cases), but for support of trivial class
36931types we also need a trivial copy constructor and destructor as of
369329 [class]/6. The current non-informative specification of these
36933two special members suggests to remove their explicit declaration
36934in the class and add explicit wording that says that if <tt>T</tt> is
36935trivial a default constructed iterator is also literal, alternatively it
36936would be possible to mark both as defaulted and add explicit
36937(memberwise) wording that guarantees that they are trivial.
36938</p>
36939<p>
36940Btw.: I'm quite sure that the <tt>istreambuf_iterator</tt> additions to
36941ensure triviality are not sufficient as suggested, because the
36942library does not yet give general guarantees that a defaulted
36943special member declaration makes this member also trivial.
36944Note that e.g. the atomic types do give a general statement!
36945</p>
36946<p>
36947Finally there is a wording issue: There does not exist something
36948like a "literal constructor". The core language uses the term
36949"constexpr constructor" for this.
36950</p>
36951<p>
36952Suggestion:
36953</p>
36954<ol>
36955<li>
36956<p>
36957Change 24.6.1 [istream.iterator]/3 as indicated:
36958</p>
36959<blockquote><pre><ins>constexpr</ins> istream_iterator();
36960istream_iterator(istream_type&amp; s);
36961istream_iterator(const istream_iterator<del>&lt;T,charT,traits,Distance&gt;</del>&amp; x)<ins> = default</ins>;
36962~istream_iterator()<ins> = default</ins>;
36963</pre></blockquote>
36964</li>
36965<li>
36966<p>
36967Change 24.6.1.1 [istream.iterator.cons]/1 as indicated:
36968</p>
36969<blockquote><pre><ins>constexpr</ins> istream_iterator();
36970</pre>
36971<blockquote>
36972-1- <i>Effects:</i> Constructs the end-of-stream iterator. <ins>If <tt>T</tt> is a literal type,
36973then this constructor shall be a constexpr constructor.</ins>
36974</blockquote>
36975</blockquote>
36976</li>
36977<li>
36978<p>
36979Change 24.6.1.1 [istream.iterator.cons]/3 as indicated:
36980</p>
36981<blockquote><pre>istream_iterator(const istream_iterator<del>&lt;T,charT,traits,Distance&gt;</del>&amp; x)<ins> = default</ins>;
36982</pre>
36983<blockquote>
36984-3- <i>Effects:</i> Constructs a copy of <tt>x</tt>. <ins>If <tt>T</tt> is a literal type, then
36985this constructor shall be a trivial copy constructor.</ins>
36986</blockquote>
36987</blockquote>
36988</li>
36989<li>
36990<p>
36991Change 24.6.1.1 [istream.iterator.cons]/4 as indicated:
36992</p>
36993
36994<blockquote><pre>~istream_iterator()<ins> = default</ins>;
36995</pre>
36996<blockquote>
36997-4- <i>Effects:</i> The iterator is destroyed. <ins>If <tt>T</tt> is a literal type, then
36998this destructor shall be a trivial
36999destructor.</ins>
37000</blockquote>
37001</blockquote>
37002</li>
37003<li>
37004<p>
37005Change 24.6.3 [istreambuf.iterator] before p. 1 as indicated:
37006</p>
37007
37008<blockquote><pre><ins>constexpr</ins> istreambuf_iterator() throw();
37009<ins>istreambuf_iterator(const istreambuf_iterator&amp;)  throw() = default;</ins>
37010<ins>~istreambuf_iterator()  throw() = default;</ins>
37011</pre></blockquote>
37012</li>
37013<li>
37014<p>
37015Change 24.6.3 [istreambuf.iterator]/1 as indicated:
37016</p>
37017<blockquote>
37018[..] The default constructor <tt>istreambuf_iterator()</tt> and the constructor
37019<tt>istreambuf_iterator(0)</tt> both
37020construct an end of stream iterator object suitable for use as an
37021end-of-range. <ins>All
37022specializations of <tt>istreambuf_iterator</tt> shall have a trivial copy
37023constructor, a constexpr default
37024constructor and a trivial destructor.</ins>
37025</blockquote>
37026</li>
37027</ol>
37028</blockquote>
37029
37030<p><i>[
370312009-10 Santa Cruz:
37032]</i></p>
37033
37034
37035<blockquote>
37036NAD Editorial.  Solved by
37037<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2994.html">N2994</a>.
37038</blockquote>
37039
37040
37041
37042<p><b>Proposed resolution:</b></p>
37043<p>
3704424.6.1 [istream.iterator] para 3
37045</p>
37046
37047<blockquote><pre><ins>constexpr</ins> istream_iterator();
37048</pre></blockquote>
37049
37050<p>
3705124.6.1.1 [istream.iterator.cons]
37052</p>
37053
37054<blockquote><pre><ins>constexpr</ins> istream_iterator();
37055</pre>
37056<blockquote>
37057-1- <i>Effects:</i> Constructs the end-of-stream iterator.
37058<ins>If <tt>T</tt> is a literal type, then this constructor shall
37059be a literal constructor.</ins>
37060</blockquote>
37061</blockquote>
37062
37063<p>
3706424.6.3 [istreambuf.iterator]
37065</p>
37066
37067<blockquote><pre><ins>constexpr</ins> istreambuf_iterator() throw();
37068</pre></blockquote>
37069
37070
37071
37072
37073
37074
37075<hr>
37076<h3><a name="1132"></a>1132. JP-30: nested exceptions</h3>
37077<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#NAD">NAD</a>
37078 <b>Submitter:</b> Seiji Hayashida <b>Opened:</b> 2009-06-01  <b>Last modified:</b> 2009-10-23</p>
37079<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>
37080<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>
37081<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
37082<p><b>Discussion:</b></p>
37083<p><b>Addresses JP 30</b></p>
37084
37085<p>
37086C++0x <tt>nested_exception</tt> cannot handle a structured exception well. The
37087following codes show two types of tree structured exception handling.
37088</p>
37089<p>
37090The first one is based on <tt>nested_exception</tt> in C++0x,
37091while the second one is based on my library <tt>trickerr.h</tt> (in Japanese).
37092<a href="http://tricklib.com/cxx/dagger/trickerr.h">http://tricklib.com/cxx/dagger/trickerr.h</a>
37093</p>
37094<p>
37095Assume that Function <tt>A()</tt> calls two sub functions <tt>A_a()</tt> and <tt>A_b()</tt>, both might
37096throw tree structured exceptions, and <tt>A_b()</tt> must be called even if <tt>A_a()</tt>
37097throws an exception.
37098</p>
37099<p>
37100List A (code of tree structured exception handling based on nested_exception
37101in C++0x)
37102</p>
37103
37104<blockquote><pre>void A()
37105{
37106    try
37107    {
37108        std::vector&lt;exception_ptr&gt; exception_list;
37109        try
37110        {
37111            // A_a() does a similar processing as A().
37112            A_a();
37113        }
37114        catch(...)
37115        {
37116            exception_list.push_back(current_exception());
37117        }
37118
37119        // ***The processing A() has to do even when A_a() fails. ***
37120        try
37121        {
37122            // A_b() does a similar processing as A().
37123            A_b();
37124        }
37125        catch(...)
37126        {
37127            exception_list.push_back(current_exception());
37128        }
37129        if (!exception_list.empty())
37130        {
37131            throw exception_list;
37132        }
37133    }
37134    catch(...)
37135    {
37136        throw_with_nested(A_exception("someone error"));
37137    }
37138}
37139void print_tree_exception(exception_ptr e, const std::string &amp; indent ="")
37140{
37141    const char * indent_unit = " ";
37142    const char * mark = "- ";
37143    try
37144    {
37145        rethow_exception(e);
37146    }
37147    catch(const std::vector&lt;exception_ptr&gt; e)
37148    {
37149        for(std::vector&lt;exception_ptr&gt;::const_iterator i = e.begin(); i!=e.end(); ++i)
37150        {
37151            print_tree_exception(i, indent);
37152        }
37153    }
37154    catch(const std::nested_exception  e)
37155    {
37156        print_tree_exception(evil_i(e), indent +indent_unit);
37157    }
37158    catch(const std::exception e)
37159    {
37160        std::cout &lt;&lt; indent &lt;&lt; mark &lt;&lt; e.what() &lt;&lt; std::endl;
37161    }
37162    catch(...)
37163    {
37164        std::cout &lt;&lt; indent &lt;&lt; mark &lt;&lt; "unknown exception" &lt;&lt; std::endl;
37165    }
37166}
37167int main(int, char * [])
37168{
37169    try
37170    {
37171        A();
37172    }
37173    catch()
37174    {
37175        print_tree_exception(current_exception());
37176    }
37177    return EXIT_SUCCESS;
37178}
37179</pre></blockquote>
37180
37181<p>
37182List B ( code of tree structured exception handling based on <tt>trickerr.h</tt>. )
37183"trickerr.h" (in Japanese), refer to:
37184<a href="http://tricklib.com/cxx/dagger/trickerr.h">http://tricklib.com/cxx/dagger/trickerr.h</a>.
37185</p>
37186
37187<blockquote><pre>void A()
37188{
37189    tricklib::error_listener_type error_listener;
37190    // A_a() is like A(). A_a() can throw tree structured exception.
37191    A_a();
37192
37193    // *** It must do process so that A_a() throws exception in A(). ***
37194    // A_b() is like A(). A_b() can throw tree structured exception.
37195    A_b();
37196
37197    if (error_listener.has_error()) // You can write this "if block" in destructor
37198                                    //  of class derived from error_listener_type.
37199    {
37200        throw_error(new A_error("someone error",error_listener.listener_off().extract_pending_error()));
37201    }
37202}
37203void print_tree_error(const tricklib::error_type &amp;a_error, const std::string &amp; indent = "")
37204{
37205    const char * indent_unit = " ";
37206    const char * mark = "- ";
37207
37208    tricklib::error_type error = a_error;
37209    while(error)
37210    {
37211        std::cout &lt;&lt; indent &lt;&lt; mark &lt;&lt; error-&gt;message &lt;&lt; std::endl;
37212        if (error-&gt;children)
37213        {
37214            print_tree_error(error-&gt;children, indent +indent_unit);
37215        }
37216        error = error-&gt;next;
37217    }
37218}
37219int main(int, char * [])
37220{
37221    tricklib::error_thread_power error_thread_power_on; // This object is necessary per thread.
37222
37223    try
37224    {
37225        A();
37226    }
37227    catch(error_type error)
37228    {
37229        print_tree_error(error);
37230    }
37231    catch(...)
37232    {
37233        std::cout &lt;&lt; "- unknown exception" &lt;&lt; std::endl;
37234    }
37235    return EXIT_SUCCESS;
37236}
37237</pre></blockquote>
37238
37239<p>
37240Prospect
37241</p>
37242<p>
37243We will focus on the method A() since the other methods, also main(), occur
37244only once respectively.
37245</p>
37246
37247<ul>
37248<li>
37249 In the List A above (of the nested exception handling), it is hard to
37250 find out an active reason to use the nested exception handling at this
37251 scene. Rather, we can take a simpler description by throwing the entire
37252 exception_list directly to the top level.
37253</li>
37254<li>
37255 The code in the same example gives us a kind of redundant impression,
37256 which might have come from the fact that the try-throw-catch framework does
37257 not assume a tree structured exception handling.
37258</li>
37259</ul>
37260
37261<p>
37262According to the above observation, we cannot help concluding that it is not
37263so easy to use the nested_exception handling as a tree structured exception
37264handling mechanism in a practical sense.
37265</p>
37266<p>
37267This text is based on the web page below (in Japanese).
37268<a href="http://d.hatena.ne.jp/wraith13/20081231/1230715424">http://d.hatena.ne.jp/wraith13/20081231/1230715424</a>
37269</p>
37270
37271<p><i>[
372722009-10 Santa Cruz:
37273]</i></p>
37274
37275
37276<blockquote>
37277Mark as NAD. The committee agrees that nested_exception is not a good
37278match for this usage model. The committee did not see a way of improving
37279this within the timeframe allowed.
37280</blockquote>
37281
37282
37283
37284<p><b>Proposed resolution:</b></p>
37285<p>
37286</p>
37287
37288
37289
37290
37291
37292<hr>
37293<h3><a name="1139"></a>1139. Thread support library not concept enabled</h3>
37294<p><b>Section:</b> 30 [thread] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
37295 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-15  <b>Last modified:</b> 2009-07-15</p>
37296<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>
37297<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
37298<p><b>Discussion:</b></p>
37299
37300<p><b>Addresses US 93, JP 79, UK 333, JP 81</b></p>
37301
37302<p>
37303The thread chapter is not concept enabled.
37304</p>
37305
37306
37307
37308<p><b>Proposed resolution:</b></p>
37309
37310
37311
37312
37313
37314<hr>
37315<h3><a name="1140"></a>1140. Numerics library not concept enabled</h3>
37316<p><b>Section:</b> 26 [numerics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
37317 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-15  <b>Last modified:</b> 2009-07-15</p>
37318<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>
37319<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
37320<p><b>Discussion:</b></p>
37321
37322<p><b>Addresses US 84</b></p>
37323
37324<p>
37325The numerics chapter is not concept enabled.
37326</p>
37327
37328<p>
37329The portion of this comment dealing with random numbers was resolved by
37330<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf">N2836</a>,
37331which was accepted in Summit.
37332</p>
37333
37334
37335
37336<p><b>Proposed resolution:</b></p>
37337
37338
37339
37340
37341
37342<hr>
37343<h3><a name="1141"></a>1141. Input/Output library not concept enabled</h3>
37344<p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
37345 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-15  <b>Last modified:</b> 2009-07-15</p>
37346<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</p>
37347<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
37348<p><b>Discussion:</b></p>
37349
37350<p><b>Addresses US 85, JP 67, JP 68, JP 69, JP 72, UK 308</b></p>
37351
37352<p>
37353The input/output chapter is not concept enabled.
37354</p>
37355
37356
37357
37358<p><b>Proposed resolution:</b></p>
37359
37360
37361
37362
37363
37364<hr>
37365<h3><a name="1142"></a>1142. Regular expressions library not concept enabled</h3>
37366<p><b>Section:</b> 28 [re] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
37367 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-15  <b>Last modified:</b> 2009-07-15</p>
37368<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re">issues</a> in [re].</p>
37369<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
37370<p><b>Discussion:</b></p>
37371
37372<p><b>Addresses US 86, UK 309, UK 310</b></p>
37373
37374<p>
37375The regular expressions chapter is not concept enabled.
37376</p>
37377
37378
37379
37380<p><b>Proposed resolution:</b></p>
37381
37382
37383
37384
37385
37386<hr>
37387<h3><a name="1143"></a>1143. Atomic operations library not concept enabled</h3>
37388<p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
37389 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-15  <b>Last modified:</b> 2009-10-26</p>
37390<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>
37391<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
37392<p><b>Discussion:</b></p>
37393
37394<p><b>Addresses US 87, UK 311</b></p>
37395
37396<p>
37397The atomics chapter is not concept enabled.
37398</p>
37399
37400<p>
37401Needs to also consider issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#923">923</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#924">924</a>.
37402</p>
37403
37404<p><i>[
374052009-10 Santa Cruz:
37406]</i></p>
37407
37408
37409<blockquote>
37410NAD Editorial.  Solved by
37411<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
37412</blockquote>
37413
37414
37415
37416<p><b>Proposed resolution:</b></p>
37417
37418
37419
37420
37421
37422<hr>
37423<h3><a name="1145"></a>1145. inappropriate headers for atomics</h3>
37424<p><b>Section:</b> 29 [atomics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
37425 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-16  <b>Last modified:</b> 2009-10-26</p>
37426<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>
37427<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
37428<p><b>Discussion:</b></p>
37429
37430<p><b>Addresses UK 312</b></p>
37431
37432<p>
37433The contents of the <tt>&lt;stdatomic.h&gt;</tt> header are not listed anywhere,
37434and <tt>&lt;cstdatomic&gt;</tt> is listed as a C99 header in chapter 17.
37435If we intend to use these for compatibility with a future C standard,
37436we should not use them now.
37437</p>
37438
37439<p><i>[
374402009-10 Santa Cruz:
37441]</i></p>
37442
37443
37444<blockquote>
37445NAD Editorial.  Solved by
37446<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
37447</blockquote>
37448
37449
37450
37451<p><b>Proposed resolution:</b></p>
37452<p>
37453Remove <tt>&lt;cstdatomic&gt;</tt> from the C99 headers in table 14.
37454Add a new header <tt>&lt;atomic&gt;</tt> to the headers in table 13.
37455Update chapter 29 to remove reference to <tt>&lt;stdatomic.h&gt;</tt>
37456and replace the use of <tt>&lt;cstdatomic&gt;</tt> with <tt>&lt;atomic&gt;</tt>.
37457</p>
37458<p><i>[
37459If and when WG14 adds atomic operations to C
37460we can add corresponding headers to table 14 with a TR.
37461]</i></p>
37462
37463
37464
37465
37466
37467
37468<hr>
37469<h3><a name="1146"></a>1146. "lockfree" does not say enough</h3>
37470<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#NAD%20Editorial">NAD Editorial</a>
37471 <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2009-06-16  <b>Last modified:</b> 2009-10-26</p>
37472<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
37473<p><b>Discussion:</b></p>
37474
37475<p><b>Addresses US 88</b></p>
37476
37477<p>
37478The "lockfree" facilities do not tell the programmer enough.
37479</p>
37480
37481<p>
37482There are 2 problems here.
37483First, at least on x86,
37484it's less important to me whether some integral types are lock free
37485than what is the largest type I can pass to atomic and have it be lock-free.
37486For example, if <tt>long long</tt>s are not lock-free,
37487<tt>ATOMIC_INTEGRAL_LOCK_FREE</tt> is probably 1,
37488but I'd still be interested in knowing whether longs are always lock-free.
37489Or if long longs at any address are lock-free,
37490I'd expect <tt>ATOMIC_INTEGRAL_LOCK_FREE</tt> to be 2,
37491but I may actually care whether I have access to
37492the <code>cmpxchg16b</code> instruction.
37493None of the support here helps with that question.
37494(There are really 2 related questions here:
37495what alignment requirements are there for lock-free access;
37496and what processor is the program actually running on,
37497as opposed to what it was compiled for?)
37498</p>
37499
37500<p>
37501Second, having <tt>atomic_is_lock_free</tt> only apply to individual objects
37502is pretty useless
37503(except, as Lawrence Crowl points out,
37504for throwing an exception when an object is unexpectedly not lock-free).
37505I'm likely to want to use its result to decide what algorithm to use,
37506and that algorithm is probably going to allocate new memory
37507containing atomic objects and then try to act on them.
37508If I can't predict the lock-freedom of the new object
37509by checking the lock-freedom of an existing object,
37510I may discover after starting the algorithm that I can't continue.
37511</p>
37512
37513<p><i>[
375142009-06-16 Jeffrey Yasskin adds:
37515]</i></p>
37516
37517
37518<blockquote>
37519<p>
37520To solve the first problem, I think 2 macros would help:
37521<tt>MAX_POSSIBLE_LOCK_FREE_SIZE</tt> and <tt>MAX_GUARANTEED_LOCK_FREE_SIZE</tt>,
37522which expand to the maximum value of <tt>sizeof(T)</tt> for which atomic may
37523(or will, respectively) use lock-free operations.
37524Lawrence points out that this
37525"relies heavily on implementations
37526using word-size compare-swap on sub-word-size types,
37527which in turn requires address modulation."
37528He expects that to be the end state anyway, so it doesn't bother him much.
37529</p>
37530
37531<p>
37532To solve the second,
37533I think one could specify that equally aligned objects of the same type
37534will return the same value from <tt>atomic_is_lock_free()</tt>.
37535I don't know how to specify "equal alignment".
37536Lawrence suggests an additional function, <tt>atomic_is_always_lock_free()</tt>.
37537</p>
37538</blockquote>
37539
37540<p><i>[
375412009-10-22 Benjamin Kosnik:
37542]</i></p>
37543
37544
37545<blockquote>
37546<p>
37547In the evolution discussion of N2925, "More Collected Issues with
37548Atomics," there is an action item with respect to
37549LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1146">1146</a>, US 88
37550</p>
37551
37552<p>
37553This is stated in the paper as:
37554</p>
37555<p>
37556Relatedly, Mike Sperts will create an issue to propose adding a traits
37557mechanism to check the compile-time properties through a template
37558mechanism rather than macros
37559</p>
37560
37561<p>
37562Here is my attempt to do this. I don't believe that a separate trait is
37563necessary for this, and that instead <tt>atomic_integral::is_lock_free</tt> can
37564be re-purposed with minimal work as follows.
37565</p>
37566
37567<p><i>[
37568Howard: Put Benjamin's wording in the proposed wording section.
37569]</i></p>
37570
37571
37572</blockquote>
37573
37574<p><i>[
375752009-10-22 Alberto Ganesh Barbati:
37576]</i></p>
37577
37578
37579<blockquote>
37580<p>
37581Just a thought... wouldn't it be better to use a scoped enum instead of
37582plain integers? For example:
37583</p>
37584
37585<blockquote><pre>enum class is_lock_free
37586{
37587    never = 0, sometimes = 1, always = 2;
37588};
37589</pre></blockquote>
37590
37591<p>
37592if compatibility with C is deemed important, we could use an unscoped
37593enum with suitably chosen names.  It would still be more descriptive
37594than 0, 1 and 2.
37595</p>
37596
37597</blockquote>
37598
37599<p><i>[
376002009-10 Santa Cruz:
37601]</i></p>
37602
37603
37604<blockquote>
37605NAD Editorial.  Solved by
37606<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
37607</blockquote>
37608
37609
37610
37611<p><b>Proposed resolution:</b></p>
37612<p>
37613Header <tt>&lt;cstdatomic&gt;</tt> synopsis  [atomics.synopsis]
37614</p>
37615
37616<p>
37617Edit  as follows:
37618</p>
37619
37620<blockquote><pre>namespace std {
37621...
37622// 29.4, lock-free property
37623<del>#define ATOMIC_INTEGRAL_LOCK_FREE unspecified</del>
37624<ins>#define ATOMIC_CHAR_LOCK_FREE unspecified
37625#define ATOMIC_CHAR16_T_LOCK_FREE unspecified
37626#define ATOMIC_CHAR32_T_LOCK_FREE unspecified
37627#define ATOMIC_WCHAR_T_LOCK_FREE unspecified
37628#define ATOMIC_SHORT_LOCK_FREE unspecified
37629#define ATOMIC_INT_LOCK_FREE unspecified
37630#define ATOMIC_LONG_LOCK_FREE unspecified
37631#define ATOMIC_LLONG_LOCK_FREE unspecified</ins>
37632#define ATOMIC_ADDRESS_LOCK_FREE unspecified
37633</pre></blockquote>
37634
37635<p>
37636Lock-free Property 29.4 [atomics.lockfree]
37637</p>
37638
37639<p>
37640Edit the synopsis as follows.
37641</p>
37642
37643<blockquote><pre>namespace std {
37644   <del>#define ATOMIC_INTEGRAL_LOCK_FREE unspecified</del>
37645   <ins>#define ATOMIC_CHAR_LOCK_FREE unspecified
37646   #define ATOMIC_CHAR16_T_LOCK_FREE unspecified
37647   #define ATOMIC_CHAR32_T_LOCK_FREE unspecified
37648   #define ATOMIC_WCHAR_T_LOCK_FREE unspecified
37649   #define ATOMIC_SHORT_LOCK_FREE unspecified
37650   #define ATOMIC_INT_LOCK_FREE unspecified
37651   #define ATOMIC_LONG_LOCK_FREE unspecified
37652   #define ATOMIC_LLONG_LOCK_FREE unspecified</ins>
37653   #define ATOMIC_ADDRESS_LOCK_FREE unspecified
37654}
37655</pre></blockquote>
37656
37657<p>
37658Edit paragraph 1 as follows.
37659</p>
37660
37661<blockquote>
37662The <ins>ATOMIC_...._LOCK_FREE</ins> macros <del>ATOMIC_INTEGRAL_LOCK_FREE and ATOMIC_ADDRESS_LOCK_FREE</del> indicate the general lock-free
37663property of <del>integral and address atomic</del> <ins>the corresponding atomic integral</ins> types<ins>, with the
37664signed and unsigned variants grouped together</ins>.
37665<del>The properties also apply to the corresponding specializations of the atomic template.</del>
37666A value of 0
37667indicates that the types are never lock-free. A value of 1
37668indicates that the types are sometimes lock-free. A value of 2
37669indicates that the types are always lock-free.
37670</blockquote>
37671
37672<p>
37673Operations on Atomic Types 29.6 [atomics.types.operations]
37674</p>
37675
37676<p>
37677Edit as follows.
37678</p>
37679
37680<blockquote><pre><del>void</del> <ins>static constexpr bool</ins> A::is_lock_free() const volatile;
37681</pre>
37682<blockquote>
37683<i>Returns:</i> True if the <del>object's</del> <ins>types's</ins> operations are lock-free, false
37684otherwise.
37685<ins>
37686[<i>Note:</i> In the same way that <tt>&lt;limits&gt;</tt>
37687<tt>std::numeric_limits&lt;short&gt;::max()</tt> is related to
37688<tt>&lt;limits.h&gt;</tt> <tt>__LONG_LONG_MAX__</tt>, <tt>&lt;atomic&gt;
37689std::atomic_short::is_lock_free</tt> is related to
37690<tt>&lt;stdatomic.h&gt;</tt> and <tt>ATOMIC_SHORT_LOCK_FREE</tt> &#8212;
37691<i>end note</i>]
37692</ins>
37693</blockquote>
37694</blockquote>
37695
37696
37697
37698
37699
37700
37701<hr>
37702<h3><a name="1147"></a>1147. non-volatile atomic functions</h3>
37703<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#NAD%20Editorial">NAD Editorial</a>
37704 <b>Submitter:</b> Jeffrey Yasskin <b>Opened:</b> 2009-06-16  <b>Last modified:</b> 2009-10-26</p>
37705<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>
37706<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
37707<p><b>Discussion:</b></p>
37708
37709<p><b>Addresses US 90</b></p>
37710
37711<p>
37712The C++0X draft
37713declares all of the functions dealing with atomics (section 29.6 [atomics.types.operations])
37714to take volatile arguments.
37715Yet it also says (29.4-3),
37716</p>
37717
37718<blockquote>
37719<p>
37720[ Note: Many operations are volatile-qualified.
37721The "volatile as device register" semantics have not changed in the standard.
37722This qualification means that volatility is preserved
37723when applying these operations to volatile objects.
37724It does not mean that operations on non-volatile objects become volatile.
37725Thus, volatile qualified operations on non-volatile objects
37726may be merged under some conditions. &#8212;end note ]
37727</p>
37728</blockquote>
37729
37730<p>
37731I was thinking about how to implement this in gcc,
37732and I believe that we'll want to overload most of the functions
37733on volatile and non-volatile.
37734Here's why:
37735</p>
37736
37737<p>
37738To let the compiler take advantage of the permission
37739to merge non-volatile atomic operations and reorder atomics in certain,
37740we'll need to tell the compiler backend
37741about exactly which atomic operation was used.
37742So I expect most of the functions of the form atomic_&lt;op&gt;_explicit()
37743(e.g. atomic_load_explicit, atomic_exchange_explicit,
37744atomic_fetch_add_explicit, etc.)
37745to become compiler builtins.
37746A builtin can tell whether its argument was volatile or not,
37747so those functions don't really need extra explicit overloads.
37748However, I don't expect that we'll want to add builtins
37749for every function in chapter 29,
37750since most can be implemented in terms of the _explicit free functions:
37751</p>
37752
37753<pre><code>class atomic_int {
37754  __atomic_int_storage value;
37755 public:
37756  int fetch_add(int increment, memory_order order = memory_order_seq_cst) volatile {
37757    // &amp;value has type "volatile __atomic_int_storage*".
37758    atomic_fetch_add_explicit(&amp;value, increment, order);
37759  }
37760  ...
37761};
37762</code></pre>
37763
37764<p>
37765But now this <em>always</em> calls
37766the volatile builtin version of atomic_fetch_add_explicit(),
37767even if the atomic_int wasn't declared volatile.
37768To preserve volatility and the compiler's permission to optimize,
37769I'd need to write:
37770</p>
37771
37772<pre><code>class atomic_int {
37773  __atomic_int_storage value;
37774 public:
37775  int fetch_add(int increment, memory_order order = memory_order_seq_cst) volatile {
37776    atomic_fetch_add_explicit(&amp;value, increment, order);
37777  }
37778  int fetch_add(int increment, memory_order order = memory_order_seq_cst) {
37779    atomic_fetch_add_explicit(&amp;value, increment, order);
37780  }
37781  ...
37782};
37783</code></pre>
37784
37785<p>
37786But this is visibly different from the declarations in the standard
37787because it's now overloaded.
37788(Consider passing &amp;atomic_int::fetch_add as a template parameter.)
37789</p>
37790
37791<p>
37792The implementation may already have permission to add overloads
37793to the member functions:
37794</p>
37795
37796<blockquote>
37797<p>
3779817.6.4.5 [member.functions] An implementation may declare additional non-virtual
37799member function signatures within a class:<br>
37800...
37801</p>
37802<ul>
37803<li>by adding a member function signature for a member function name.</li>
37804</ul>
37805</blockquote>
37806
37807<p>
37808but I don't see an equivalent permission to add overloads to the free functions.
37809</p>
37810
37811<p><i>[
378122009-06-16 Lawrence adds:
37813]</i></p>
37814
37815
37816<blockquote>
37817<p>
37818I recommend allowing non-volatile overloads.
37819</p>
37820</blockquote>
37821
37822<p><i>[
378232009-10 Santa Cruz:
37824]</i></p>
37825
37826
37827<blockquote>
37828NAD Editorial.  Solved by
37829<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html">N2992</a>.
37830</blockquote>
37831
37832
37833
37834<p><b>Proposed resolution:</b></p>
37835
37836
37837
37838
37839
37840<hr>
37841<h3><a name="1148"></a>1148. Wrong argument type of I/O stream manipulators <tt>setprecision()</tt>
37842and <tt>setw()</tt></h3>
37843<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#NAD">NAD</a>
37844 <b>Submitter:</b> Marc Steinbach <b>Opened:</b> 2009-06-20  <b>Last modified:</b> 2009-10-20</p>
37845<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>
37846<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
37847<p><b>Discussion:</b></p>
37848<p>
37849The header <tt>&lt;iomanip&gt;</tt> synopsis in 27.7 [iostream.format] specifies
37850</p>
37851<blockquote><pre>T5 setprecision(int n);
37852T6 setw(int n);
37853</pre></blockquote>
37854
37855<p>
37856The argument types should be streamsize, as in class <tt>ios_base</tt>
37857(see 27.5.2 [ios.base]):
37858</p>
37859<blockquote><pre>streamsize precision() const;
37860streamsize precision(streamsize prec);
37861streamsize width() const;
37862streamsize width(streamsize wide);
37863</pre></blockquote>
37864
37865<p>
37866(Editorial: 'wide' should probably be renamed as 'width', or maybe just 'w'.)
37867</p>
37868
37869<p><i>[
378702009-07-29 Daniel clarified wording.
37871]</i></p>
37872
37873
37874<p><i>[
378752009 Santa Cruz:
37876]</i></p>
37877
37878
37879<blockquote>
37880<p>
37881No concensus for this change.  There was some interest in doing the opposite
37882fix:  Change the <tt>streamsize</tt> in <tt>&lt;ios&gt;</tt> to <tt>int</tt>.
37883But ultimately there was no concensus for that change either.
37884</p>
37885</blockquote>
37886
37887
37888
37889<p><b>Proposed resolution:</b></p>
37890<ol>
37891<li>
37892<p>
37893In 27.7 [iostream.format], header <tt>&lt;iomanip&gt;</tt> synopsis change as indicated:
37894</p>
37895
37896<blockquote><pre>T5 setprecision(<del>int</del><ins>streamsize</ins> n);
37897T6 setw(<del>int</del><ins>streamsize</ins> n);
37898</pre></blockquote>
37899</li>
37900
37901<li>
37902<p>
37903In 27.7.3 [std.manip], just before p. 6 change as indicated:
37904</p>
37905
37906<blockquote><pre>unspecified setprecision(<del>int</del><ins>streamsize</ins> n);
37907</pre></blockquote>
37908</li>
37909
37910<li>
37911<p>
37912In 27.7.3 [std.manip], just before p. 7 change as indicated:
37913</p>
37914
37915<blockquote><pre>unspecified setw(<del>int</del><ins>streamsize</ins> n);
37916</pre></blockquote>
37917</li>
37918</ol>
37919
37920
37921
37922
37923
37924
37925
37926
37927<hr>
37928<h3><a name="1149"></a>1149. Reformulating NonemptyRange axiom</h3>
37929<p><b>Section:</b> 26.5.2.2 [rand.concept.urng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
37930 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2009-06-25  <b>Last modified:</b> 2009-07-15</p>
37931<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
37932<p><b>Discussion:</b></p>
37933<p>
37934In 26.5.2.2 [rand.concept.urng], we have the following:
37935</p>
37936<blockquote><pre>concept UniformRandomNumberGenerator&lt;typename G&gt; : Callable&lt;G&gt; {
37937  ...
37938  axiom NonemptyRange(G&amp; g) {
37939    G::min() &lt; G::max();
37940  }
37941  ...
37942}
37943</pre></blockquote>
37944
37945<p>
37946Since the parameter <tt>G</tt> is in scope throughout the concept, there is no
37947need for the axiom to be further parameterized, and so the axiom can be
37948slightly simplified as:
37949</p>
37950
37951<blockquote><pre>axiom NonemptyRange()  {
37952  G::min() &lt; G::max();
37953}
37954</pre></blockquote>
37955
37956<p>
37957We can further reformulate so as to avoid any axiom machinery as:
37958</p>
37959
37960<blockquote><pre>requires True&lt; G::min() &lt; G::max() &gt;;
37961</pre></blockquote>
37962
37963<p>
37964This is not only a simpler statement of the same requirement, but also
37965forces the requirement to be checked.
37966</p>
37967
37968
37969<p><b>Proposed resolution:</b></p>
37970<p>
37971In 26.5.2.2 [rand.concept.urng], replace the <tt>NonemptyRange</tt> axiom by:
37972</p>
37973
37974<blockquote><pre><del>axiom NonemptyRange(G&amp; g) { 
37975   G::min() &lt; G::max(); 
37976}</del>
37977<ins>requires True&lt; G::min() &lt; G::max() &gt;;</ins>
37978</pre></blockquote>
37979
37980
37981
37982
37983
37984
37985<hr>
37986<h3><a name="1150"></a>1150. wchar_t, char16_t and char32_t filenames</h3>
37987<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#NAD%20Future">NAD Future</a>
37988 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-10-20</p>
37989<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
37990<p><b>Discussion:</b></p>
37991<p><b>Addresses JP 73</b></p>
37992
37993   <p><b>Description</b></p>
37994        <p>It is a problem
37995        from C++98, <tt>fstream</tt> cannot appoint a filename of wide
37996        character string(<tt>const wchar_t</tt> and <tt>const wstring&amp;</tt>).</p>
37997<p><b>Suggestion</b></p>
37998        <p>Add
37999        interface corresponding to <tt>wchar_t</tt>, <tt>char16_t</tt> and <tt>char32_t</tt>.</p>
38000
38001<p><i>[
380022009-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
38003in-depth rationale.
38004]</i></p>
38005
38006
38007<p><i>[
380082009-09-21 Daniel adds:
38009]</i></p>
38010
38011
38012<blockquote>
38013I suggest to mark this issue as NAD Future with the intend to
38014solve the issue with a single file path c'tor template assuming
38015a provision of a TR2 filesystem library.
38016</blockquote>
38017
38018<p><i>[
380192009 Santa Cruz:
38020]</i></p>
38021
38022
38023<blockquote>
38024NAD Future.  This is a duplicate of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#454">454</a>.
38025</blockquote>
38026
38027
38028
38029<p><b>Proposed resolution:</b></p>
38030
38031
38032
38033
38034
38035<hr>
38036<h3><a name="1155"></a>1155. Reference should be to C99</h3>
38037<p><b>Section:</b> C.2 [diff.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
38038 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-10-23</p>
38039<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>
38040<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
38041<p><b>Discussion:</b></p>
38042
38043<p><b>Addresses FR 38</b></p>
38044
38045<p><b>Description</b></p>
38046        <p>What is ISO/IEC 1990:9899/DAM
38047        1? My guess is that's a typo for ISO/IEC
38048        9899/Amd.1:1995 which I'd
38049        have expected to be referenced here (the tables
38050        make reference to things
38051        which were introduced by Amd.1).</p>
38052<p><b>Suggestion</b></p>
38053        <p>One need probably a reference
38054        to the document which introduce <tt>char16_t</tt> and
38055        <tt>char32_t</tt> in C (ISO/IEC TR 19769:2004?).</p>
38056<p><b>Notes</b></p>
38057<p>Create issue. Document in question should be C99, not C90+amendment1. The 
38058    rest of the section requires careful review for completeness. Example &lt;cstdint&gt; 
38059    18.4.1 [cstdint.syn]. Assign to C liasons.</p>
38060
38061<p><i>[
380622009-10 Santa Cruz:
38063]</i></p>
38064
38065
38066<blockquote>
38067NAD Editorial. Already fixed.
38068</blockquote>
38069
38070
38071
38072<p><b>Proposed resolution:</b></p>
38073
38074
38075
38076
38077
38078<hr>
38079<h3><a name="1160"></a>1160. <tt>future_error</tt> public constructor is 'exposition only'</h3>
38080<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#NAD%20Editorial">NAD Editorial</a>
38081 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-10-26</p>
38082<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
38083<p><b>Discussion:</b></p>
38084
38085<p><b>Addresses UK 331</b></p>
38086
38087<p><b>Description</b></p>
38088        <p>Not clear what
38089        it means for a public constructor to be 'exposition only'.
38090        If the intent is purely to support the library calling this
38091        constructor then it can be made private and accessed
38092        through friendship. Otherwise it should be documented for
38093        public consumption.</p>
38094<p><b>Suggestion</b></p>
38095        <p>Declare the constructor as private with a
38096        note about intended friendship, or remove the
38097        exposition-only comment and document the semantics.</p>
38098<p><b>Notes</b></p>
38099<p>Create an issue. Assigned to Detlef. Suggested resolution probably makes 
38100    sense.</p>
38101
38102<p><i>[
381032009-07 Frankfurt
38104]</i></p>
38105
38106
38107<blockquote>
38108Pending a paper from Anthony Williams / Detleff Volleman.
38109</blockquote>
38110
38111<p><i>[
381122009-10-14 Pending paper:
38113<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2967.html">N2967</a>.
38114]</i></p>
38115
38116
38117<p><i>[
381182009-10 Santa Cruz:
38119]</i></p>
38120
38121
38122<blockquote>
38123NAD Editorial.  Solved by
38124<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.html">N2997</a>.
38125</blockquote>
38126
38127
38128
38129<p><b>Proposed resolution:</b></p>
38130
38131
38132
38133
38134
38135<hr>
38136<h3><a name="1161"></a>1161. Unnecessary <tt>unique_future</tt> limitations</h3>
38137<p><b>Section:</b> 30.6.6 [futures.unique_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
38138 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-10-26</p>
38139<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>
38140<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
38141<p><b>Discussion:</b></p>
38142
38143<p><b>Addresses UK 336</b></p>
38144
38145<p><b>Description</b></p>
38146
38147        <p>It is possible
38148        to transfer ownership of the asynchronous result from one
38149        unique_future instance to another via the move-constructor.
38150        However, it is not possible to transfer it back, and nor is
38151        it possible to create a default-constructed unique_future
38152        instance to use as a later move target. This unduly limits
38153        the use of <tt>unique_future</tt> in code. Also, the lack of a
38154        move-assignment operator restricts the use of <tt>unique_future</tt>
38155        in containers such as <tt>std::vector</tt> - <tt>vector::insert</tt> requires
38156        move-assignable for example.</p>
38157<p><b>Suggestion</b></p>
38158        <p>Add a default constructor with the
38159        semantics that it creates a <tt>unique_future</tt> with no
38160        associated asynchronous result. Add a move-assignment
38161        operator which transfers ownership.</p>
38162<p><b>Notes</b></p>
38163<p>Create an issue. Detlef will look into it.</p>
38164
38165<p><i>[
381662009-07 Frankfurt
38167]</i></p>
38168
38169
38170<blockquote>
38171Pending a paper from Anthony Williams / Detleff Volleman.
38172</blockquote>
38173
38174<p><i>[
381752009-10-14 Pending paper:
38176<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2967.html">N2967</a>.
38177]</i></p>
38178
38179
38180<p><i>[
381812009-10 Santa Cruz:
38182]</i></p>
38183
38184
38185<blockquote>
38186NAD Editorial.  Solved by
38187<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.html">N2997</a>.
38188</blockquote>
38189
38190
38191
38192<p><b>Proposed resolution:</b></p>
38193
38194
38195
38196
38197
38198<hr>
38199<h3><a name="1162"></a>1162. <tt>shared_future</tt> should support an efficient move constructor</h3>
38200<p><b>Section:</b> 30.6.7 [future.shared_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
38201 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-10-26</p>
38202<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>
38203<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
38204<p><b>Discussion:</b></p>
38205
38206<p><b>Addresses UK 337</b></p>
38207
38208<p><b>Description</b></p>
38209        <p><tt>shared_future</tt>
38210        should support an efficient move constructor that can avoid
38211        unnecessary manipulation of a reference count, much like
38212        <tt>shared_ptr</tt></p>
38213<p><b>Suggestion</b></p>
38214        <p>Add a move constructor</p>
38215<p><b>Notes</b></p>
38216<p>Create an issue. Detlef will look into it.</p>
38217
38218<p><i>[
382192009-07 Frankfurt
38220]</i></p>
38221
38222
38223<blockquote>
38224Pending a paper from Anthony Williams / Detleff Volleman.
38225</blockquote>
38226
38227<p><i>[
382282009-10-14 Pending paper:
38229<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2967.html">N2967</a>.
38230]</i></p>
38231
38232
38233<p><i>[
382342009-10 Santa Cruz:
38235]</i></p>
38236
38237
38238<blockquote>
38239NAD Editorial.  Solved by
38240<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.html">N2997</a>.
38241</blockquote>
38242
38243
38244
38245<p><b>Proposed resolution:</b></p>
38246
38247
38248
38249
38250
38251<hr>
38252<h3><a name="1163"></a>1163. <tt>shared_future</tt> is inconsistent with <tt>shared_ptr</tt></h3>
38253<p><b>Section:</b> 30.6.7 [future.shared_future] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
38254 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-10-26</p>
38255<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>
38256<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
38257<p><b>Discussion:</b></p>
38258
38259<p><b>Addresses UK 338</b></p>
38260
38261<p><b>Description</b></p>
38262
38263        <p><tt>shared_future</tt> is currently
38264        CopyConstructible, but not CopyAssignable. This is
38265        inconsistent with <tt>shared_ptr</tt>, and will surprise users.
38266        Users will then write work-arounds to provide this
38267        behaviour. We should provide it simply and efficiently as
38268        part of shared_future. Note that since the shared_future
38269        member functions for accessing the state are all declared
38270        const, the original usage of an immutable shared_future
38271        value that can be freely copied by multiple threads can be
38272        retained by declaring such an instance as "<tt>const
38273        shared_future</tt>".</p>
38274<p><b>Suggestion</b></p>
38275        <p>Remove "=delete"
38276        from the copy-assignment operator of shared_future. Add a
38277        move-constructor <tt>shared_future(shared_future&amp;&amp;
38278        rhs)</tt>, and a move-assignment operator <tt>shared_future&amp;
38279        operator=(shared_future&amp;&amp; rhs)</tt>. The postcondition
38280        for the copy-assignment operator is that <tt>*this</tt> has the same
38281        associated state as <tt>rhs</tt>. The postcondition for the
38282        move-constructor and move assignment is that <tt>*this</tt> has the
38283        same associated as <tt>rhs</tt> had before the
38284        constructor/assignment call and that <tt>rhs</tt> has no associated
38285        state.</p>
38286<p><b>Notes</b></p>
38287<p>Create an issue. Detlef will look into it.</p>
38288
38289<p><i>[
382902009-07 Frankfurt
38291]</i></p>
38292
38293
38294<blockquote>
38295Pending a paper from Anthony Williams / Detleff Volleman.
38296</blockquote>
38297
38298<p><i>[
382992009-10-14 Pending paper:
38300<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2967.html">N2967</a>.
38301]</i></p>
38302
38303
38304<p><i>[
383052009-10 Santa Cruz:
38306]</i></p>
38307
38308
38309<blockquote>
38310NAD Editorial.  Solved by
38311<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.html">N2997</a>.
38312</blockquote>
38313
38314
38315
38316<p><b>Proposed resolution:</b></p>
38317
38318
38319
38320
38321
38322<hr>
38323<h3><a name="1164"></a>1164. <tt>promise::swap</tt> should pass by rvalue reference</h3>
38324<p><b>Section:</b> 30.6.5 [futures.promise] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
38325 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-07-17</p>
38326<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>
38327<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
38328<p><b>Discussion:</b></p>
38329
38330<p><b>Addresses UK 341</b></p>
38331
38332<p><b>Description</b></p>
38333<p><tt>promise::swap</tt> accepts its parameter by lvalue reference. This is
38334inconsistent with other types that provide a swap member function,
38335where those swap functions accept an rvalue reference</p>
38336
38337<p><b>Suggestion</b></p>
38338<p>Change <tt>promise::swap</tt> to take an rvalue reference.</p>
38339
38340<p><b>Notes</b></p>
38341<p>Create an issue. Detlef will look into it. Probably ready as it.</p>  
38342
38343<p><i>[
383442009-07 Frankfurt
38345]</i></p>
38346
38347
38348<blockquote>
38349NAD, by virtue of the changed rvalue rules and swap signatures from Summit.
38350</blockquote>
38351
38352
38353
38354<p><b>Proposed resolution:</b></p>
38355
38356
38357
38358
38359
38360<hr>
38361<h3><a name="1165"></a>1165. Unneeded promise move constructor</h3>
38362<p><b>Section:</b> 30.6.5 [futures.promise] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
38363 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-10-26</p>
38364<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>
38365<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
38366<p><b>Discussion:</b></p>
38367
38368<p><b>Addresses UK 343</b></p>
38369
38370<p><b>Description</b></p>
38371        <p>The move constructor of a std::promise
38372        object does not need to allocate any memory, so the
38373        move-construct-with-allocator overload of the constructor
38374        is superfluous.</p>
38375<p><b>Suggestion</b></p>
38376        <p>Remove the
38377        constructor with the signature <tt>template &lt;class
38378        Allocator&gt; promise(allocator_arg_t, const Allocator&amp;
38379        a, promise&amp; rhs);</tt></p>
38380<p><b>Notes</b></p>
38381<p>Create an issue. Detlef will look into it. Will solicit feedback from Pablo. 
38382    Note that &#8220;rhs&#8221; argument should also be an rvalue reference in any case.</p>
38383
38384<p><i>[
383852009-07 Frankfurt
38386]</i></p>
38387
38388
38389<blockquote>
38390Pending a paper from Anthony Williams / Detleff Volleman.
38391</blockquote>
38392
38393<p><i>[
383942009-10 Santa Cruz:
38395]</i></p>
38396
38397
38398<blockquote>
38399NAD Editorial.  Solved by
38400<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2997.html">N2997</a>.
38401</blockquote>
38402
38403
38404
38405<p><b>Proposed resolution:</b></p>
38406
38407
38408
38409
38410
38411<hr>
38412<h3><a name="1166"></a>1166. Allocator-specific move/copy break model of move-constructor and
38413        move-assignment</h3>
38414<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#NAD%20Editorial">NAD Editorial</a>
38415 <b>Submitter:</b> LWG <b>Opened:</b> 2009-06-28  <b>Last modified:</b> 2009-10-26</p>
38416<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
38417<p><b>Discussion:</b></p>
38418
38419<p><b>Addresses US 77</b></p>
38420
38421<p><b>Description</b></p>
38422        <p>Allocator-specific move and copy behavior for containers
38423        (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>) complicates a little-used and already-complicated
38424        portion of the standard library (allocators), and breaks
38425        the conceptual model of move-constructor and
38426        move-assignment operations on standard containers being
38427        efficient operations. The extensions for allocator-specific
38428        move and copy behavior should be removed from the working
38429        paper.</p>
38430        <p>With the
38431        introduction of rvalue references, we are teaching
38432        programmers that moving from a standard container (e.g., a
38433        <tt>vector&lt;string&gt;</tt>) is an efficient, constant-time
38434        operation. The introduction of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a> removed that
38435        guarantee; depending on the behavior of four different
38436        traits (20.8.4), the complexity of copy and move operations
38437        can be constant or linear time. This level of customization
38438        greatly increases the complexity of standard containers,
38439        and benefits only a tiny fraction of the C++ community.</p>
38440<p><b>Suggestion</b></p>
38441
38442        <p>Remove 20.8.4.</p>
38443        
38444        <p>Remove 20.8.5.</p>
38445        
38446        <p>Remove all references to the facilities in
38447        20.8.4 and 20.8.5 from clause 23.</p>
38448
38449
38450<p><i>[
384512009-10 Santa Cruz:
38452]</i></p>
38453
38454
38455<blockquote>
38456NAD Editorial.  Addressed by
38457<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>.
38458</blockquote>
38459
38460
38461
38462<p><b>Proposed resolution:</b></p>
38463
38464
38465
38466
38467
38468<hr>
38469<h3><a name="1167"></a>1167. <tt>pair&lt;T,U&gt;</tt> doesn't model <tt>LessThanComparable</tt> in unconstrained code even if
38470      <tt>T</tt> and <tt>U</tt> do.</h3>
38471<p><b>Section:</b> 20.3.4 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Concepts">NAD Concepts</a>
38472 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2009-07-01  <b>Last modified:</b> 2009-07-16</p>
38473<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>
38474<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>
38475<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Concepts">NAD Concepts</a> status.</p>
38476<p><b>Discussion:</b></p>
38477<p>
38478<tt>LessThanComparable</tt> requires (and provides default
38479             implementations for) &lt;=,&gt;, and &gt;=.  However, the defaults
38480             don't take effect in unconstrained code.
38481</p>
38482<p>
38483Still, it's a problem to have types acting one way in
38484constrained code and another in unconstrained code, except in cases of
38485syntax adaptation.  It's also inconsistent with the containers, which
38486supply all those operators.
38487</p>
38488<p>
38489Totally Unbiased
38490Suggested Resolution:
38491</p>
38492<p>
38493accept the exported concept maps proposal and
38494                    change the way this stuff is handled to use an
38495                    explicit exported concept map rather than nested
38496                    function templates
38497</p>
38498<p>
38499e.g., remove from the body of <tt>std::list</tt>
38500</p>
38501<blockquote><pre>template &lt;LessThanComparable T, class Allocator&gt; 
38502bool operator&lt; (const list&lt;T,Allocator&gt;&amp; x, const list&lt;T,Allocator&gt;&amp; y); 
38503template &lt;LessThanComparable T, class Allocator&gt; 
38504bool operator&gt; (const list&lt;T,Allocator&gt;&amp; x, const list&lt;T,Allocator&gt;&amp; y); 
38505template &lt;LessThanComparable T, class Allocator&gt; 
38506bool operator&gt;=(const list&lt;T,Allocator&gt;&amp; x, const list&lt;T,Allocator&gt;&amp; y); 
38507template &lt;LessThanComparable T, class Allocator&gt; 
38508bool operator&lt;=(const list&lt;T,Allocator&gt;&amp; x, const list&lt;T,Allocator&gt;&amp; y); 
38509</pre></blockquote>
38510<p>
38511and add this concept_map afterwards:
38512</p>
38513<blockquote><pre>template &lt;LessThanComparable T, class Allocator&gt; 
38514export concept_map LessThanComparable&lt;list&lt;T,Allocator&gt; &gt;
38515{
38516    bool operator&lt;(const list&lt;T,Allocator&gt;&amp; x, const list&lt;T,Allocator&gt;&amp; y);
38517}
38518</pre></blockquote>
38519<p>
38520do similarly for <tt>std::pair</tt>.  While you're at it, do the same for
38521<tt>operator==</tt> and <tt>!=</tt> everywhere, and seek out other such opportunities.
38522</p>
38523<p>
38524Alternative Resolution: keep the ugly, complex specification and add the
38525                       missing operators to <tt>std::pair</tt>.
38526</p>
38527
38528
38529<p><b>Proposed resolution:</b></p>
38530
38531
38532
38533
38534
38535<hr>
38536<h3><a name="1168"></a>1168. Odd wording for bitset equality operators</h3>
38537<p><b>Section:</b> 20.3.7.2 [bitset.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
38538 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-07-02  <b>Last modified:</b> 2009-07-27</p>
38539<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.members">issues</a> in [bitset.members].</p>
38540<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
38541<p><b>Discussion:</b></p>
38542<p>
38543The following wording seems a little unusual to me:
38544</p>
38545<p>
38546p42/43 20.3.7.2 [bitset.members]
38547</p>
38548
38549<blockquote>
38550<pre>bool operator==(const bitset&lt;N&gt;&amp; rhs) const;
38551</pre>
38552<blockquote>
38553-42- <i>Returns:</i> A nonzero value if the value of each bit in
38554<tt>*this</tt> equals the value of the corresponding bit in
38555<tt>rhs</tt>.
38556</blockquote>
38557<pre>bool operator!=(const bitset&lt;N&gt;&amp; rhs) const;
38558</pre>
38559<blockquote>
38560-43- <i>Returns:</i> A nonzero value if <tt>!(*this == rhs)</tt>.
38561</blockquote>
38562</blockquote>
38563
38564<p>
38565"A nonzero value" may be well defined as equivalent to the literal '<tt>true</tt>'
38566for Booleans, but the wording is clumsy.  I suggest replacing "A nonzero value"
38567with the literal '<tt>true</tt>' (in appropriate font) in each case.
38568</p>
38569
38570<p><i>[
385712009-07-24 Alisdair recommends NAD Editorial.
38572]</i></p>
38573
38574
38575<p><i>[
385762009-07-27 Pete adds:
38577]</i></p>
38578
38579
38580<blockquote>
38581It's obviously editorial. There's no need for further discussion.
38582</blockquote>
38583
38584<p><i>[
385852009-07-27 Howard sets to NAD Editorial.
38586]</i></p>
38587
38588
38589
38590
38591<p><b>Proposed resolution:</b></p>
38592<p>
38593Change 20.3.7.2 [bitset.members] p42-43:
38594</p>
38595
38596<blockquote>
38597<pre>bool operator==(const bitset&lt;N&gt;&amp; rhs) const;
38598</pre>
38599<blockquote>
38600-42- <i>Returns:</i> <del>A nonzero value</del> <ins><tt>true</tt></ins> if the value of each bit in
38601<tt>*this</tt> equals the value of the corresponding bit in
38602<tt>rhs</tt>.
38603</blockquote>
38604<pre>bool operator!=(const bitset&lt;N&gt;&amp; rhs) const;
38605</pre>
38606<blockquote>
38607-43- <i>Returns:</i> <del>A nonzero value</del> <ins><tt>true</tt></ins> if <tt>!(*this == rhs)</tt>.
38608</blockquote>
38609</blockquote>
38610
38611
38612
38613
38614
38615
38616<hr>
38617<h3><a name="1172"></a>1172. <tt>select_on_container_(copy|move)_construction</tt> over-constrained</h3>
38618<p><b>Section:</b> X [allocator.concepts.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
38619 <b>Submitter:</b> Alberto Ganesh Barbati <b>Opened:</b> 2009-07-08  <b>Last modified:</b> 2009-10-26</p>
38620<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
38621<p><b>Discussion:</b></p>
38622<p>
38623I believe the two functions
38624<tt>select_on_container_(copy|move)_construction()</tt> are over-constrained. For
38625example, the return value of the "copy" version is (see
38626X [allocator.concepts.members]/21):
38627</p>
38628<blockquote>
38629<i>Returns:</i> <tt>x</tt> if the allocator should propagate from the existing
38630container to the new container on copy construction, otherwise <tt>X()</tt>.
38631</blockquote>
38632<p>
38633Consider the case where a user decides to provide an explicit concept
38634map for Allocator to adapt some legacy allocator class, as he wishes to
38635provide customizations that the <tt>LegacyAllocator</tt> concept map template
38636does not provide.  Now, although it's true that the legacy class is
38637required to have a default constructor, the user might have reasons to
38638prefer a different constructor to implement
38639<tt>select_on_container_copy_construction()</tt>. However, the current wording
38640requires the use of the default constructor.
38641</p>
38642<p>
38643Moreover, it's not said explicitly that <tt>x</tt> is supposed to be the
38644allocator of the existing container. A clarification would do no harm.
38645</p>
38646
38647<p><i>[
386482009-10 Santa Cruz:
38649]</i></p>
38650
38651
38652<blockquote>
38653NAD Editorial.  Addressed by
38654<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>.
38655</blockquote>
38656
38657
38658
38659<p><b>Proposed resolution:</b></p>
38660<p>
38661Replace X [allocator.concepts.members]/21 with:
38662</p>
38663
38664<blockquote><pre>X select_on_container_copy_construction(const X&amp; x);
38665</pre>
38666<p>
38667-21- <i>Returns:</i> <del><tt>x</tt> if the allocator should propagate from the existing
38668container to the new container on copy construction, otherwise <tt>X()</tt>.</del>
38669<ins>an allocator object to be used by the new container on copy
38670construction. [<i>Note:</i> <tt>x</tt> is the allocator of the existing container that
38671is being copied. The most obvious choices for the return value are <tt>x</tt>, if
38672the allocator should propagate from the existing container, and <tt>X()</tt>.
38673<i>&#8212; end note</i>]</ins>
38674</p>
38675</blockquote>
38676
38677<p>
38678Replace X [allocator.concepts.members]/25 with:
38679</p>
38680
38681<blockquote><pre>X select_on_container_move_construction(X&amp;&amp; x);
38682</pre>
38683<p>
38684-25- <i>Returns:</i> <del><tt>move(x)</tt> if the allocator should propagate from the existing
38685container to the new container on move construction, otherwise <tt>X()</tt>.</del>
38686<ins>an allocator object to be used by the new container on move
38687construction. [<i>Note:</i> <tt>x</tt> is the allocator of the existing container that
38688is being moved. The most obvious choices for the return value are <tt>move(x)</tt>, if
38689the allocator should propagate from the existing container, and <tt>X()</tt>.
38690<i>&#8212; end note</i>]</ins>
38691</p>
38692</blockquote>
38693
38694
38695
38696
38697
38698
38699<hr>
38700<h3><a name="1174"></a>1174. type property predicates</h3>
38701<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#NAD%20Editorial">NAD Editorial</a>
38702 <b>Submitter:</b> Jason Merrill <b>Opened:</b> 2009-07-16  <b>Last modified:</b> 2009-10-26</p>
38703<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>
38704<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>
38705<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
38706<p><b>Discussion:</b></p>
38707<p>
38708I've been implementing compiler support for <tt>is_standard_layout</tt>, and
38709noticed a few nits about 20.6.4.3 [meta.unary.prop]:
38710</p>
38711
38712<ol>
38713<li>
38714There's no trait for "trivially copyable type", which is now the
38715property that lets you do bitwise copying of a type, and therefore seems
38716useful to be able to query.  <tt>has_trivial_assign</tt> &amp;&amp;
38717<tt>has_trivial_copy_constructor</tt> &amp;&amp; <tt>has_trivial_destructor</tt>
38718is similar, but
38719not identical, specifically with respect to const types.
38720</li>
38721<li>
38722<tt>has_trivial_copy_constructor</tt> and <tt>has_trivial_assign</tt> lack the "or an
38723array of such a class type" language that most other traits in that
38724section, including <tt>has_nothrow_copy_constructor</tt> and <tt>has_nothrow_assign</tt>,
38725have; this seems like an oversight.
38726</li>
38727</ol>
38728
38729<p><i>[
38730See the thread starting with c++std-lib-24420 for further discussion.
38731]</i></p>
38732
38733
38734<p><i>[
38735Addressed in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2947.html">N2947</a>.
38736]</i></p>
38737
38738
38739<p><i>[
387402009-10 Santa Cruz:
38741]</i></p>
38742
38743
38744<blockquote>
38745NAD Editorial.  Solved by
38746<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2984.html">N2984</a>.
38747</blockquote>
38748
38749
38750
38751<p><b>Proposed resolution:</b></p>
38752<p>
38753</p>
38754
38755
38756
38757
38758
38759<hr>
38760<h3><a name="1179"></a>1179. Probably editorial in [structure.specifications]</h3>
38761<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#NAD%20Editorial">NAD Editorial</a>
38762 <b>Submitter:</b> Robert Klarer <b>Opened:</b> 2009-07-21  <b>Last modified:</b> 2009-10-20</p>
38763<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>
38764<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
38765<p><b>Discussion:</b></p>
38766<p>
38767While reviewing <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#971">971</a> I noted that 17.5.1.4 [structure.specifications]/7 says:
38768</p>
38769
38770<blockquote>
38771-7- Error conditions specify conditions where a function may fail. The
38772conditions are listed, together with a suitable explanation, as the <tt>enum
38773class errc</tt> constants (19.5) that could be used as an argument to
38774function <tt>make_error_condition</tt> (19.5.3.6).
38775</blockquote>
38776
38777<p>
38778This paragraph should mention <tt>make_error_code</tt> or the text "that
38779could be used as an argument to function <tt>make_error_condition</tt>
38780(19.5.3.6)" should be deleted.  I believe this is editorial.
38781</p>
38782
38783<p><i>[
387842009-07-21 Chris adds:
38785]</i></p>
38786
38787
38788<blockquote>
38789<p>
38790I'm not convinced there's a problem there, because as far as the "Error
38791conditions" clauses are concerned, make_error_condition() is used by a
38792user to test for the condition, whereas make_error_code is not. For
38793example:
38794</p>
38795
38796<blockquote><pre>void foobar(error_code&amp; ec = throws());
38797</pre></blockquote>
38798
38799<p>
38800 Error conditions:
38801</p>
38802<blockquote>
38803permission_denied - Insufficient privilege to perform operation.
38804</blockquote>
38805
38806<p>
38807When a user writes:
38808</p>
38809
38810<blockquote><pre>error_code ec;
38811foobar(ec);
38812if (ec == errc::permission_denied)
38813   ...
38814</pre></blockquote>
38815
38816<p>
38817the implicit conversion <tt>errc-&gt;error_condition</tt> makes the if-test
38818equivalent to:
38819</p>
38820
38821<blockquote><pre>if (ec == make_error_condition(errc::permission_denied))
38822</pre></blockquote>
38823
38824<p>
38825On the other hand, if the user had written:
38826</p>
38827
38828<blockquote><pre>if (ec == make_error_code(errc::permission_denied))
38829</pre></blockquote>
38830
38831<p>
38832the test is now checking for a specific error code. The test may
38833evaluate to <tt>false</tt> even though <tt>foobar()</tt> failed due to the documented
38834error condition "Insufficient privilege".
38835</p>
38836</blockquote>
38837
38838<p><i>[
388392009 Santa Cruz:
38840]</i></p>
38841
38842
38843<blockquote>
38844<p>
38845NAD Editorial.
38846</p>
38847<p>
38848What the WP says right now is literally true: these codes can be used as
38849an argument to <tt>make_error_condition</tt>. (It is also true that they can be
38850used as an argument to <tt>make_error_code</tt>, which the WP doesn't say.) Maybe
38851it would be clearer to just delete "that could be used as an argument to
38852function <tt>make_error_condition</tt>", since that fact is already implied by
38853other things that we say. We believe that this is editorial.
38854</p>
38855</blockquote>
38856
38857
38858
38859<p><b>Proposed resolution:</b></p>
38860<p>
38861</p>
38862
38863
38864
38865
38866
38867<hr>
38868<h3><a name="1184"></a>1184. Feature request: dynamic bitset</h3>
38869<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#NAD%20Future">NAD Future</a>
38870 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-07-29  <b>Last modified:</b> 2009-10-26</p>
38871<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>
38872<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
38873<p><b>Discussion:</b></p>
38874<p>
38875Opened at Alisdair's request, steming from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#96">96</a>.
38876Alisdair recommends NAD Future.
38877</p>
38878
38879<p><i>[
388802009-10 Santa Cruz:
38881]</i></p>
38882
38883
38884<blockquote>
38885NAD Future.  We want a heap allocated bitset, but we don't have one today and
38886don't have time to add one.
38887</blockquote>
38888
38889
38890
38891<p><b>Proposed resolution:</b></p>
38892
38893
38894
38895
38896
38897<hr>
38898<h3><a name="1195"></a>1195. "Diagnostic required" wording is insufficient to  prevent UB</h3>
38899<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
38900 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-08-18  <b>Last modified:</b> 2009-10-20</p>
38901<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>
38902<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>
38903<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
38904<p><b>Discussion:</b></p>
38905<p>
38906Several parts of the library use the notion of "Diagnostic required"
38907to indicate that
38908in the corresponding situation an error diagnostic should occur, e.g.
3890920.8.14.1.1 [unique.ptr.dltr.dflt]/2
38910</p>
38911<blockquote><pre>void operator()(T *ptr) const;
38912</pre>
38913
38914<blockquote>
38915<i>Effects:</i> calls <tt>delete</tt> on <tt>ptr</tt>. A diagnostic is required if <tt>T</tt> is an
38916incomplete type.
38917</blockquote>
38918</blockquote>
38919
38920<p>
38921The problem with this approach is that such a requirement is
38922insufficient to prevent
38923undefined behavior, if this situation occurs. According to 1.3.3 [defns.diagnostic]
38924a <i>diagnostic message</i> is defined as
38925</p>
38926
38927<blockquote>
38928a message belonging to an implementation-defined subset of the
38929implementation's output messages.
38930</blockquote>
38931
38932<p>
38933which doesn't indicate any relation to an ill-formed program. In fact,
38934"compiler warnings"
38935are a typical expression of such diagnostics. This means that above
38936wording can be interpreted
38937by compiler writers that they satisfy the requirements of the standard
38938if they just produce
38939such a "warning", if the compiler happens to compile code like this:
38940</p>
38941
38942<blockquote><pre>#include &lt;memory&gt;
38943
38944struct Ukn; // defined somewhere else
38945Ukn* create_ukn(); // defined somewhere else
38946
38947int main() {
38948 std::default_delete&lt;Ukn&gt;()(create_ukn());
38949}
38950</pre></blockquote>
38951
38952<p>
38953In this and other examples discussed here it was the authors intent to
38954guarantee that the
38955program is ill-formed with a required diagnostic, therefore such
38956wording should be used instead.
38957According to the general rules outlined in 1.4 [intro.compliance] it
38958should be sufficient
38959to require that these situations produce an ill-formed program and the
38960"diagnostic
38961required" part should be implied. The proposed resolution also
38962suggests to remove
38963several <i>redundant</i> wording of "Diagnostics required" to ensure that
38964the absence of
38965such saying does not cause a misleading interpretation.
38966</p>
38967
38968<p><i>[
389692009 Santa Cruz:
38970]</i></p>
38971
38972
38973<blockquote>
38974<p>
38975Move to NAD.
38976</p>
38977<p>It's not clear that there's any important difference between
38978"ill-formed" and "diagnostic required". From 1.4 [intro.compliance],
389791.3.5 [defns.ill.formed], and 1.3.15 [defns.well.formed] it appears
38980that an ill-formed program is one
38981that is not correctly constructed according to the syntax rules and
38982diagnosable semantic rules, which means that... "a conforming
38983implementation shall issue at least one diagnostic message." The
38984author's intent seems to be that we should be requiring a fatal error
38985instead of a mere warning, but the standard just doesn't have language
38986to express that distinction. The strongest thing we can ever require is
38987a "diagnostic".
38988</p>
38989<p>
38990The proposed rewording may be a clearer way of expressing the same thing
38991that the WP already says, but such a rewording is editorial.
38992</p>
38993</blockquote>
38994
38995<p><i>[
389962009 Santa Cruz:
38997]</i></p>
38998
38999
39000<blockquote>
39001Considered again.  Group disagrees that the change is technical, but likes
39002it editorially.  Moved to NAD Editorial.
39003</blockquote>
39004
39005
39006
39007<p><b>Proposed resolution:</b></p>
39008<ol>
39009<li>
39010<p>
39011Change 20.4 [ratio]/2 as indicated:
39012</p>
39013
39014
39015
39016<blockquote>
39017Throughout this subclause, the template argument types R1 and R2 shall
39018be specializations of the ratio
39019template<ins>, else the program is ill-formed</ins>.<del> Diagnostic required.</del>
39020</blockquote>
39021</li>
39022
39023<li>
39024<p>
39025Change 20.4.1 [ratio.ratio]/1 as indicated:
39026</p>
39027
39028<p>
39029The template argument <tt>D</tt> shall not be zero, and the absolute values of
39030the template arguments <tt>N</tt> and <tt>D</tt> shall
39031be representable by type <tt>intmax_t</tt><ins>, else the program is ill-formed</ins>.<del> Diagnostic required.</del> [..]
39032</p>
39033
39034
39035</li>
39036
39037<li>
39038<p>
39039Change 20.4.2 [ratio.arithmetic]/1 as indicated:
39040</p>
39041
39042<blockquote>
39043Implementations may use other algorithms to compute these values.
39044If overflow <ins>would</ins> occur<del>s</del>, <del>a diagnostic shall
39045be issued</del><ins>the program shall be ill-formed</ins>.
39046</blockquote>
39047
39048</li>
39049
39050<li>
39051<p>
39052Change 20.4.3 [ratio.comparison]/2 as indicated:
39053</p>
39054
39055<blockquote>
39056[...] Implementations may use other algorithms to compute this relationship
39057to avoid overflow. If
39058overflow <del>occurs, a diagnostic is required</del><ins> would occur,
39059the program shall be
39060ill-formed</ins>.
39061</blockquote>
39062
39063
39064</li>
39065
39066<li>
39067<p>
39068Change 20.8.14.1.1 [unique.ptr.dltr.dflt]/2 as indicated:
39069</p>
39070
39071<blockquote>
39072<p>
39073<i>Effects:</i> calls <tt>delete</tt> on <tt>ptr</tt>.<del> A diagnostic is required if <tt>T</tt> is an
39074incomplete type.</del>
39075</p>
39076
39077<p>
39078<ins><i>Remarks:</i> The program shall be ill-formed, if <tt>T</tt> is an incomplete type.</ins>
39079</p>
39080</blockquote>
39081
39082
39083</li>
39084
39085<li>
39086<p>
39087Change 20.8.14.1.2 [unique.ptr.dltr.dflt1]/1 as indicated:
39088</p>
39089
39090<blockquote>
39091<p>
39092<tt>operator()</tt> calls <tt>delete[]</tt> on <tt>ptr</tt>.<del> A diagnostic is required if <tt>T</tt>
39093is an incomplete type.</del>
39094</p>
39095
39096<p>
39097<ins><i>Remarks:</i> The program shall be ill-formed, if <tt>T</tt> is an incomplete type.</ins>
39098</p>
39099</blockquote>
39100</li>
39101
39102<li>
39103<p>
39104Accept <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#932">932</a>.
39105</p>
39106
39107<p><i>[This is a bullet here to confirm that this list is
39108an exhaustive review of this issue.]</i></p>
39109
39110</li>
39111
39112<li>
39113<p>
39114Accept <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#950">950</a>.
39115</p>
39116
39117<p><i>[This is a bullet here to confirm that this list is
39118an exhaustive review of this issue.]</i></p>
39119
39120</li>
39121
39122<li>
39123<p>
39124Change 20.8.14.3 [unique.ptr.runtime]/1 as indicated:
39125</p>
39126
39127<blockquote>
39128[..]
39129-- Conversions among different types of <tt>unique_ptr&lt;T[], D&gt;</tt> or to or
39130from the non-array forms of
39131<tt>unique_ptr</tt> <del>are disallowed (diagnostic required)</del>
39132<ins>produce an ill-formed program</ins>.
39133[..]
39134</blockquote>
39135
39136
39137</li>
39138
39139<li>
39140<p>
39141Change 20.9.3 [time.duration]/2 as indicated:
39142</p>
39143
39144<blockquote>
39145<i>Requires:</i> <tt>Rep</tt> shall be an arithmetic type or a class emulating an
39146arithmetic type. <del>If a program
39147instantiates <tt>duration</tt> with a <tt>duration</tt> type for the template argument
39148<tt>Rep</tt> a diagnostic is required.</del>
39149<ins><i>Remarks:</i> The program shall be ill-formed, if <tt>duration</tt> is
39150instantiated with a <tt>duration</tt> type for the template argument <tt>Rep</tt>.</ins>
39151
39152</blockquote>
39153
39154
39155</li>
39156
39157<li>
39158<p>
39159Change 20.9.3 [time.duration]/3+4 as indicated:
39160</p>
39161
39162<blockquote>
39163<p>
391643 <del><i>Requires</i></del><ins><i>Remarks</i></ins>: <tt>Period</tt> shall be a
39165specialization of <tt>ratio</tt>, <del>diagnostic
39166required</del><ins>else the program shall be ill-formed</ins>.
39167</p>
39168
39169<p>
391704 <del><i>Requires</i></del><ins><i>Remarks</i></ins>: <tt>Period::num</tt> shall be
39171positive,  <del>diagnostic
39172required</del><ins>else the program shall be ill-formed</ins>.
39173</p>
39174</blockquote>
39175
39176
39177</li>
39178
39179<li>
39180<p>
39181Accept <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1177">1177</a> bullet 1.
39182</p>
39183
39184<p><i>[This is a bullet here to confirm that this list is
39185an exhaustive review of this issue.]</i></p>
39186
39187
39188</li>
39189
39190<li>
39191<p>
39192Accept <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1177">1177</a> bullet 2.
39193</p>
39194
39195<p><i>[This is a bullet here to confirm that this list is
39196an exhaustive review of this issue.]</i></p>
39197
39198
39199</li>
39200
39201<li>
39202<p>
39203Accept <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1177">1177</a> bullet 3.
39204</p>
39205
39206<p><i>[This is a bullet here to confirm that this list is
39207an exhaustive review of this issue.]</i></p>
39208
39209
39210</li>
39211
39212<li>
39213<p>
39214Change 20.9.4 [time.point]/2 as indicated:
39215</p>
39216
39217<blockquote>
39218<tt>Duration</tt> shall be an instance of <tt>duration</tt><ins>, else the
39219program shall be ill-formed</ins>. <del>Diagnostic required.</del>
39220</blockquote>
39221</li>
39222
39223<li>
39224<p>
39225Change 20.9.4.1 [time.point.cons]/3 as indicated:
39226</p>
39227
39228<blockquote>
39229<p>
39230<del><i>Requires:</i> <tt>Duration2</tt> shall be implicitly convertible to <tt>duration</tt>.
39231Diagnostic required.</del>
39232</p>
39233
39234<p>
39235<ins><i>Remarks:</i> <tt>Duration2</tt> shall be implicitly convertible to <tt>duration</tt>,
39236else this constructor shall
39237not participate in overload resolution.</ins>
39238</p>
39239</blockquote>
39240
39241<p><i>[This suggestion seems more in sync to the several suggested changes
39242of <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#950">950</a>, etc.]</i></p>
39243
39244</li>
39245
39246<li>
39247<p>
39248Accept <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1177">1177</a> bullet 4.
39249</p>
39250
39251<p><i>[This is a bullet here to confirm that this list is
39252an exhaustive review of this issue.]</i></p>
39253
39254
39255</li>
39256
39257</ol>
39258
39259
39260
39261
39262
39263
39264<hr>
39265<h3><a name="1196"></a>1196. move semantics undefined for priority_queue</h3>
39266<p><b>Section:</b> 23.3.5.2.1 [priqueue.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
39267 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-08-19  <b>Last modified:</b> 2009-10-20</p>
39268<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
39269<p><b>Discussion:</b></p>
39270<p>
39271The class template <tt>priority_queue</tt> declares signatures for a move
39272constructor and move assignment operator in its class definition.
39273However, it does not provide a definition (unlike <tt>std::queue</tt>, and
39274proposed resolution for <tt>std::stack</tt>.) Nor does it provide a text clause
39275specifying their behaviour.
39276</p>
39277
39278<p><i>[
392792009-08-23 Daniel adds:
39280]</i></p>
39281
39282
39283<blockquote>
39284<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1194">1194</a> provides wording that solves this issue.
39285</blockquote>
39286
39287<p><i>[
392882009-10 Santa Cruz:
39289]</i></p>
39290
39291
39292<blockquote>
39293Mark NAD Editorial, solved by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1194">1194</a>.
39294</blockquote>
39295
39296
39297
39298<p><b>Proposed resolution:</b></p>
39299
39300
39301
39302
39303
39304<hr>
39305<h3><a name="1203"></a>1203. More useful rvalue stream insertion</h3>
39306<p><b>Section:</b> 27.7.2.9 [ostream.rvalue], 27.7.1.6 [istream.rvalue] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
39307 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-09-06  <b>Last modified:</b> 2009-10-20</p>
39308<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
39309<p><b>Discussion:</b></p>
39310<p>
3931127.7.2.9 [ostream.rvalue] was created to preserve the ability to insert
39312into (and extract from 27.7.1.6 [istream.rvalue]) rvalue streams:
39313</p>
39314
39315<blockquote><pre>template &lt;class charT, class traits, class T&gt;
39316  basic_ostream&lt;charT, traits&gt;&amp;
39317  operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os, const T&amp; x);
39318</pre>
39319<blockquote>
39320<p>
393211 <i>Effects:</i> <tt>os &lt;&lt; x</tt>
39322</p>
39323<p>
393242 <i>Returns:</i> <tt>os</tt>
39325</p>
39326</blockquote>
39327</blockquote>
39328
39329<p>
39330This is good as it allows code that wants to (for example) open, write to, and
39331close an <tt>ofstream</tt> all in one statement:
39332</p>
39333
39334<blockquote><pre>std::ofstream("log file") &lt;&lt; "Some message\n";
39335</pre></blockquote>
39336
39337<p>
39338However, I think we can easily make this "rvalue stream helper" even easier to
39339use.  Consider trying to quickly create a formatted string.  With the current
39340spec you have to write:
39341</p>
39342
39343<blockquote><pre>std::string s = static_cast&lt;std::ostringstream&amp;&gt;(std::ostringstream() &lt;&lt; "i = " &lt;&lt; i).str();
39344</pre></blockquote>
39345
39346<p>
39347This will store "<tt>i = 10</tt>" (for example) in the string <tt>s</tt>.  Note
39348the need to cast the stream back to <tt>ostringstream&amp;</tt> prior to using
39349the member <tt>.str()</tt>.  This is necessary because the inserter has cast
39350the <tt>ostringstream</tt> down to a more generic <tt>ostream</tt> during the
39351insertion process.
39352</p>
39353
39354<p>
39355I believe we can re-specify the rvalue-inserter so that this cast is unnecessary.
39356Thus our customer now has to only type:
39357</p>
39358
39359<blockquote><pre>std::string s = (std::ostringstream() &lt;&lt; "i = " &lt;&lt; i).str();
39360</pre></blockquote>
39361
39362<p>
39363This is accomplished by having the rvalue stream inserter return an rvalue of
39364the same type, instead of casting it down to the base class.  This is done by
39365making the stream generic, and constraining it to be an rvalue of a type derived
39366from <tt>ios_base</tt>.
39367</p>
39368
39369<p>
39370The same argument and solution also applies to the inserter.  This code has been
39371implemented and tested.
39372</p>
39373
39374<p><i>[
393752009 Santa Cruz:
39376]</i></p>
39377
39378
39379<blockquote>
39380NAD Future.  No concensus for change.
39381</blockquote>
39382
39383
39384
39385<p><b>Proposed resolution:</b></p>
39386<p>
39387Change 27.7.1.6 [istream.rvalue]:
39388</p>
39389
39390<blockquote><pre>template &lt;class <del>charT, class traits</del> <ins>Istream</ins>, class T&gt;
39391  <del>basic_istream&lt;charT, traits&gt;&amp;</del> <ins>Istream&amp;&amp;</ins>
39392  operator&gt;&gt;(<del>basic_istream&lt;charT, traits&gt;</del> <ins>Istream</ins>&amp;&amp; is, T&amp; x);
39393</pre>
39394<blockquote>
39395<p>
393961 <i>Effects:</i> <tt>is &gt;&gt; x</tt>
39397</p>
39398<p>
393992 <i>Returns:</i> <tt><ins>std::move(</ins>is<ins>)</ins></tt>
39400</p>
39401<p><ins>
394023 <i>Remarks:</i> This signature shall participate in overload resolution if
39403and only if <tt>Istream</tt> is not an lvalue reference type and is derived from
39404<tt>ios_base</tt>.
39405</ins></p>
39406</blockquote>
39407</blockquote>
39408
39409<p>
39410Change 27.7.2.9 [ostream.rvalue]:
39411</p>
39412
39413<blockquote><pre>template &lt;class <del>charT, class traits</del> <ins>Ostream</ins>, class T&gt;
39414  <del>basic_ostream&lt;charT, traits&gt;&amp;</del> <ins>Ostream&amp;&amp;</ins>
39415  operator&lt;&lt;(<del>basic_ostream&lt;charT, traits&gt;</del> <ins>Ostream</ins>&amp;&amp; os, const T&amp; x);
39416</pre>
39417<blockquote>
39418<p>
394191 <i>Effects:</i> <tt>os &lt;&lt; x</tt>
39420</p>
39421<p>
394222 <i>Returns:</i> <tt><ins>std::move(</ins>os<ins>)</ins></tt>
39423</p>
39424<p><ins>
394253 <i>Remarks:</i> This signature shall participate in overload resolution if
39426and only if <tt>Ostream</tt> is not an lvalue reference type and is derived from
39427<tt>ios_base</tt>.
39428</ins></p>
39429</blockquote>
39430</blockquote>
39431
39432
39433
39434
39435
39436
39437<hr>
39438<h3><a name="1217"></a>1217. Quaternion support</h3>
39439<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#NAD%20Future">NAD Future</a>
39440 <b>Submitter:</b> Ted Shaneyfelt <b>Opened:</b> 2009-09-26  <b>Last modified:</b> 2009-10-26</p>
39441<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>
39442<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
39443<p><b>Discussion:</b></p>
39444<p>
39445Concerning mathematically proper operation of the type:
39446</p>
39447
39448<blockquote><pre>complex&lt;complex&lt;T&gt; &gt;
39449</pre></blockquote>
39450
39451<p>
39452Generally accepted mathematical semantics of such a construct correspond
39453to quaternions through Cayly-Dickson construct
39454</p>
39455
39456<blockquote><pre>(w+xi) + (y+zi) j
39457</pre></blockquote>
39458
39459<p>
39460The proper implementation seems straightforward by adding a few
39461declarations like those below. I have included operator definition for
39462combining real scalars and complex types, as well, which seems
39463appropriate, as algebra of complex numbers allows mixing complex and
39464real numbers with operators. It also allows for constructs such as
39465<tt>complex&lt;double&gt; i=(0,1),  x = 12.34 + 5*i;</tt>
39466</p>
39467
39468<p>
39469Quaternions are often used in areas such as computer graphics, where,
39470for example, they avoid the problem of Gimbal lock when rotating objects
39471in 3D space, and can be more efficient than matrix multiplications,
39472although I am applying them to a different field.
39473</p>
39474
39475<pre>/////////////////////////ALLOW OPERATORS TO COMBINE REAL SCALARS AND COMPLEX VALUES /////////////////////////
39476template&lt;typename T,typename S&gt; complex&lt;T&gt; operator+(const complex&lt;T&gt; x,const S a) {
39477    complex&lt;T&gt; result(x.real()+a, x.imag());
39478    return result;
39479}
39480template&lt;typename T,typename S&gt; complex&lt;T&gt; operator+(const S a,const complex&lt;T&gt; x) {
39481    complex&lt;T&gt; result(a+x.real(), x.imag());
39482    return result;
39483}
39484template&lt;typename T,typename S&gt; complex&lt;T&gt; operator-(const complex&lt;T&gt; x,const S a) {
39485    complex&lt;T&gt; result(x.real()-a, x.imag());
39486    return result;
39487}
39488template&lt;typename T,typename S&gt; complex&lt;T&gt; operator-(const S a,const complex&lt;T&gt; x) {
39489    complex&lt;T&gt; result(a-x.real(), x.imag());
39490    return result;
39491}
39492template&lt;typename T,typename S&gt; complex&lt;T&gt; operator*(const complex&lt;T&gt; x,const S a) {
39493    complex&lt;T&gt; result(x.real()*a, x.imag()*a);
39494    return result;
39495}
39496template&lt;typename T,typename S&gt; complex&lt;T&gt; operator*(const S a,const complex&lt;T&gt; x) {
39497    complex&lt;T&gt; result(a*x.real(), a*x.imag());
39498    return result;
39499}
39500
39501/////////////////////////PROPERLY IMPLEMENT QUATERNION SEMANTICS/////////////////////////
39502template&lt;typename T&gt; double normSq(const complex&lt;complex&lt;T&gt; &gt;q) {
39503    return q.real().real()*q.real().real()
39504         + q.real().imag()*q.real().imag()
39505         + q.imag().real()*q.imag().real()
39506         + q.imag().imag()*q.imag().imag();
39507}
39508template&lt;typename T&gt; double norm(const complex&lt;complex&lt;T&gt; &gt;q) {
39509    return sqrt(normSq(q));
39510}
39511/////// Cayley-Dickson Construction
39512template&lt;typename T&gt; complex&lt;complex&lt;T&gt; &gt; conj(const complex&lt;complex&lt;T&gt; &gt; x) {
39513    complex&lt;complex&lt;T&gt; &gt; result(conj(x.real()),-x.imag());
39514    return result;
39515}
39516template&lt;typename T&gt; complex&lt;complex&lt;T&gt; &gt; operator*(const complex&lt;complex&lt;T&gt; &gt; ab,const complex&lt;complex&lt;T&gt; &gt; cd) {
39517    complex&lt;T&gt; re(ab.real()*cd.real()-conj(cd.imag())*ab.imag());
39518    complex&lt;T&gt; im(cd.imag()*ab.real()+ab.imag()*conj(cd.real()));
39519    complex&lt;complex&lt;double&gt; &gt; q(re,im);
39520    return q;
39521}
39522//// Quaternion division
39523template&lt;typename S,typename T&gt; complex&lt;complex&lt;T&gt; &gt; operator/(const complex&lt;complex&lt;T&gt; &gt; q,const S a) {
39524    return q * (1/a);
39525}
39526template&lt;typename S,typename T&gt; complex&lt;complex&lt;T&gt; &gt; operator/(const S a,const complex&lt;complex&lt;T&gt; &gt; q) {
39527    return a*conj(q)/normSq(q);
39528}
39529template&lt;typename T&gt; complex&lt;complex&lt;T&gt; &gt; operator/(const complex&lt;complex&lt;T&gt; &gt; n, const complex&lt;complex&lt;T&gt; &gt; d) {
39530    return n * (conj(d)/normSq(d));
39531}
39532</pre>
39533
39534<p><i>[
395352009-10 Santa Cruz:
39536]</i></p>
39537
39538
39539<blockquote>
39540NAD Future.  There is no consensus or time to move this into C++0X.
39541</blockquote>
39542
39543
39544
39545<p><b>Proposed resolution:</b></p>
39546
39547
39548
39549
39550
39551<hr>
39552<h3><a name="1229"></a>1229. <tt>error_code operator=</tt> typo</h3>
39553<p><b>Section:</b> 19.5.2.3 [syserr.errcode.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
39554 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2009-10-08  <b>Last modified:</b> 2009-10-26</p>
39555<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
39556<p><b>Discussion:</b></p>
39557<p>
39558<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2960.pdf">N2960</a>
3955919.5.2.1 [syserr.errcode.overview] and 19.5.2.3 [syserr.errcode.modifiers] say:
39560</p>
39561
39562<blockquote><pre> 
39563template &lt;class ErrorCodeEnum&gt;
39564  typename enable_if&lt;is_error_code_enum&lt;ErrorCodeEnum&gt;::value&gt;::type&amp;
39565    operator=(ErrorCodeEnum e);
39566</pre></blockquote>
39567
39568<p>
39569They should say:
39570</p>
39571
39572<blockquote><pre> 
39573template &lt;class ErrorCodeEnum&gt;
39574  typename enable_if&lt;is_error_code_enum&lt;ErrorCodeEnum&gt;::value, error_code&gt;::type&amp;
39575    operator=(ErrorCodeEnum e);
39576</pre></blockquote>
39577
39578<p>
39579Or (I prefer this form):
39580</p>
39581 
39582<blockquote><pre> 
39583template &lt;class ErrorCodeEnum&gt;
39584  typename enable_if&lt;is_error_code_enum&lt;ErrorCodeEnum&gt;::value, error_code&amp;&gt;::type
39585    operator=(ErrorCodeEnum e);
39586</pre></blockquote>
39587
39588<p>
39589This is because <tt>enable_if</tt> is declared as (20.6.7 [meta.trans.other]):
39590</p>
39591 
39592<blockquote><pre> 
39593template &lt;bool B, class T = void&gt; struct enable_if;
39594</pre></blockquote>
39595
39596<p>
39597So, the current wording makes <tt>operator=</tt> return
39598<tt>void&amp;</tt>, which is not good.
39599</p>
39600
39601<p> 
3960219.5.2.3 [syserr.errcode.modifiers]/4 says
39603</p>
39604
39605<blockquote>
39606<i>Returns:</i> <tt>*this</tt>.
39607</blockquote>
39608<p>
39609which is correct.
39610</p>
39611
39612<p>
39613Additionally,
39614</p>
39615
39616<p>
3961719.5.3.1 [syserr.errcondition.overview]/1 says:
39618</p>
39619 
39620<blockquote><pre> 
39621template&lt;typename ErrorConditionEnum&gt;
39622  typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;, error_code&gt;::type &amp;
39623    operator=( ErrorConditionEnum e );
39624</pre></blockquote>
39625
39626<p>
39627Which contains several problems (<tt>typename</tt> versus <tt>class</tt>
39628inconsistency, lack of <tt>::value</tt>, <tt>error_code</tt> instead of
39629<tt>error_condition</tt>), while 19.5.3.3 [syserr.errcondition.modifiers] says:
39630</p>
39631 
39632<blockquote><pre> 
39633template &lt;class ErrorConditionEnum&gt;
39634  typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;::value&gt;::type&amp;
39635    operator=(ErrorConditionEnum e);
39636</pre></blockquote>
39637
39638<p>
39639Which returns <tt>void&amp;</tt>.  They should both say:
39640</p>
39641 
39642<blockquote><pre> 
39643template &lt;class ErrorConditionEnum&gt;
39644  typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;::value, error_condition&gt;::type&amp;
39645    operator=(ErrorConditionEnum e);
39646</pre></blockquote>
39647
39648<p>
39649Or (again, I prefer this form):
39650</p>
39651
39652<blockquote><pre> 
39653template &lt;class ErrorConditionEnum&gt;
39654  typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;::value, error_condition&amp;&gt;::type
39655    operator=(ErrorConditionEnum e);
39656</pre></blockquote>
39657
39658<p>
39659Additionally, 19.5.3.3 [syserr.errcondition.modifiers] lacks a
39660"<i>Returns:</i> <tt>*this</tt>." paragraph, which is presumably
39661necessary.
39662</p>
39663
39664<p><i>[
396652009-10-18 Beman adds:
39666]</i></p>
39667
39668
39669<blockquote>
39670The proposed resolution for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1237">1237</a> makes this issue
39671moot, so it should become NAD.
39672</blockquote>
39673
39674<p><i>[
396752009-10 Santa Cruz:
39676]</i></p>
39677
39678
39679<blockquote>
39680NAD, solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1237">1237</a>.
39681</blockquote>
39682
39683
39684
39685<p><b>Proposed resolution:</b></p>
39686
39687<p>
39688Change 19.5.2.1 [syserr.errcode.overview] and 19.5.2.3 [syserr.errcode.modifiers]:
39689</p>
39690
39691<blockquote><pre>template &lt;class ErrorCodeEnum&gt;
39692  typename enable_if&lt;is_error_code_enum&lt;ErrorCodeEnum&gt;::value<ins>, error_code&amp;</ins>&gt;::type<del>&amp;</del>
39693    operator=(ErrorCodeEnum e);
39694</pre></blockquote>
39695
39696<p>
39697Change 19.5.3.1 [syserr.errcondition.overview]:
39698</p>
39699
39700<blockquote><pre>template&lt;<del>typename</del> <ins>class</ins> ErrorConditionEnum&gt;
39701  typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;<ins>::value</ins>, error_co<ins>ndition</ins><del>de</del><ins>&amp;</ins>&gt;::type<del> &amp;</del>
39702    operator=( ErrorConditionEnum e );
39703</pre></blockquote>
39704
39705<p>
39706Change 19.5.3.3 [syserr.errcondition.modifiers]:
39707</p>
39708
39709<blockquote><pre>template &lt;class ErrorConditionEnum&gt;
39710  typename enable_if&lt;is_error_condition_enum&lt;ErrorConditionEnum&gt;::value<ins>, error_condition&amp;</ins>&gt;::type<del>&amp;</del>
39711    operator=(ErrorConditionEnum e);
39712</pre>
39713<blockquote>
39714<p>
39715<i>Postcondition:</i> <tt>*this == make_error_condition(e)</tt>.
39716</p>
39717<p><ins>
39718<i>Returns:</i> <tt>*this</tt>.
39719</ins></p>
39720<p>
39721<i>Throws:</i> Nothing.
39722</p>
39723</blockquote>
39724</blockquote>
39725
39726
39727
39728
39729
39730
39731<hr>
39732<h3><a name="1230"></a>1230. <tt>mem_fn</tt> and variadic templates</h3>
39733<p><b>Section:</b> 20.7.14 [func.memfn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
39734 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2009-10-09  <b>Last modified:</b> 2009-10-23</p>
39735<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.memfn">issues</a> in [func.memfn].</p>
39736<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
39737<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#920">920</a></p>
39738<p><b>Discussion:</b></p>
39739
39740
39741
39742<p>
39743Since we have removed the entry in B [implimits] for the
39744library-specific limit for number of arguments passed to
39745<tt>function</tt>/<tt>tuple</tt>/etc. I believe we need to update the
39746spec for <tt>mem_fn</tt> to reflect this.
39747</p>
39748
39749<p>
39750The "<i>Remarks:</i> Implementations may implement <tt>mem_fn</tt> as a set of
39751overloaded function templates." no longer holds, as we cannot create an
39752arbitrary number of such overloads.  I believe we should strike the
39753remark and add a second signature:
39754</p>
39755
39756<blockquote><pre>template&lt;class R, class T, typename ... ArgTypes&gt;
39757  unspecified mem_fn(R (T::*pm)(ArgTypes...));
39758</pre></blockquote>
39759
39760<p>
39761I believe we need two signatures as pointer-to-data-member and
39762pointer-to-member-function-taking-no-args appear to use subtly different
39763syntax.
39764</p>
39765
39766<p><i>[
39767<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#920">920</a> as a similar proposed resolution.
39768]</i></p>
39769
39770
39771
39772<p><b>Proposed resolution:</b></p>
39773Add to 20.7 [function.objects] and 20.7.14 [func.memfn]:
39774
39775
39776<blockquote><pre>template&lt;class R, class T&gt; <i>unspecified</i> mem_fn(R T::* pm)
39777
39778<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...));</ins>
39779<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const);</ins>
39780<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile);</ins>
39781<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile);</ins>
39782
39783<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...)&amp;);</ins>
39784<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const&amp;);</ins>
39785<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile&amp;);</ins>
39786<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile&amp;);</ins>
39787
39788<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...)&amp;&amp;);</ins>
39789<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const&amp;&amp;);</ins>
39790<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile&amp;&amp;);</ins>
39791<ins>template&lt;class R, class T, class ...Args&gt; <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile&amp;&amp;);</ins>
39792</pre></blockquote>
39793
39794<p>
39795Strike 20.7.14 [func.memfn], p5:
39796</p>
39797
39798<blockquote>
39799<del><i>Remarks:</i> Implementations may implement <tt>mem_fn</tt> as a set
39800of overloaded function templates.</del>
39801</blockquote>
39802
39803
39804
39805
39806<hr>
39807<h3><a name="1232"></a>1232. Still <tt>swap</tt>'s with rvalue-references</h3>
39808<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
39809 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-10-11  <b>Last modified:</b> 2009-10-29</p>
39810<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>
39811<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>
39812<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
39813<p><b>Discussion:</b></p>
39814<p>
39815The current library contains still rvalue reference-swaps that seem to be
39816overlooked in the process of switching back to lvalue-ref swaps.
39817</p>
39818
39819<p><i>[
398202009-10 Santa Cruz:
39821]</i></p>
39822
39823
39824<blockquote>
39825Editor accepts as NAD Editorial.
39826</blockquote>
39827
39828
39829
39830<p><b>Proposed resolution:</b></p>
39831<ol>
39832<li>
39833<p>
39834Change 20.3.4 [pairs]/1 as indicated:
39835</p>
39836
39837<blockquote><pre>template &lt;class T1, class T2&gt;
39838struct pair {
39839  ...
39840  void swap(pair&amp;<del>&amp;</del> p);
39841};
39842</pre></blockquote>
39843</li>
39844
39845<li>
39846<p>
39847Change 20.3.4 [pairs] before p. 17 as indicated:
39848</p>
39849
39850<blockquote><pre>void swap(pair&amp;<del>&amp;</del> p);
39851</pre></blockquote>
39852
39853</li>
39854
39855<li>
39856
39857<p>
39858Change 20.3.4 [pairs] before p. 21 as indicated:
39859</p>
39860
39861<blockquote><pre>template&lt;class T1, class T2&gt; void swap(pair&lt;T1, T2&gt;&amp; x, pair&lt;T1, T2&gt;&amp; y);
39862<del>template&lt;class T1, class T2&gt; void swap(pair&lt;T1, T2&gt;&amp;&amp; x, pair&lt;T1, T2&gt;&amp; y);</del>
39863<del>template&lt;class T1, class T2&gt; void swap(pair&lt;T1, T2&gt;&amp; x, pair&lt;T1, T2&gt;&amp;&amp; y);</del>
39864</pre></blockquote>
39865
39866</li>
39867
39868<li>
39869<p>
39870Change 20.5.1 [tuple.general]/2, header <tt>&lt;tuple&gt;</tt> synopsis, as indicated:
39871</p>
39872
39873<blockquote><pre>// 20.5.2.9, specialized algorithms:
39874template &lt;class... Types&gt;
39875void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp; y);
39876<del>template &lt;class... Types&gt;
39877void swap(tuple&lt;Types...&gt;&amp;&amp; x, tuple&lt;Types...&gt;&amp; y);
39878template &lt;class... Types&gt;
39879void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp;&amp; y);</del>
39880</pre></blockquote>
39881
39882</li>
39883
39884<li>
39885<p>
39886Change 20.5.2 [tuple.tuple] as indicated:
39887</p>
39888
39889<blockquote><pre>// 20.5.2.3, tuple swap
39890void swap(tuple&amp;<del>&amp;</del>)
39891</pre></blockquote>
39892
39893</li>
39894
39895<li>
39896<p>
39897Change 20.5.2.3 [tuple.swap] before 1 as indicated:
39898</p>
39899
39900<blockquote><pre>void swap(tuple&amp;<del>&amp;</del> rhs);
39901</pre></blockquote>
39902
39903</li>
39904
39905<li>
39906<p>
39907Change 20.7 [function.objects]/2, header <tt>&lt;functional&gt;</tt> synopsis, as indicated:
39908</p>
39909
39910<blockquote><pre>template&lt;class R, class... ArgTypes&gt;
39911void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
39912<del>template&lt;class R, class... ArgTypes&gt;
39913void swap(function&lt;R(ArgTypes...)&gt;&amp;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
39914template&lt;class R, class... ArgTypes&gt;
39915void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&amp;&amp;);</del>
39916</pre></blockquote>
39917
39918</li>
39919
39920<li>
39921<p>
39922Change 20.7.15.2 [func.wrap.func], as indicated:
39923</p>
39924
39925<blockquote><pre>// 20.7.15.2.2, function modifiers:
39926void swap(function&amp;<del>&amp;</del>);
39927template&lt;class F, class A&gt; void assign(F, const A&amp;);
39928
39929[..]
39930
39931// 20.7.15.2.7, specialized algorithms:
39932template &lt;class R, class... ArgTypes&gt;
39933void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
39934<del>template &lt;class R, class... ArgTypes&gt;
39935void swap(function&lt;R(ArgTypes...)&gt;&amp;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
39936template &lt;class R, class... ArgTypes&gt;
39937void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;&amp;);</del>
39938</pre></blockquote>
39939
39940</li>
39941
39942<li>
39943<p>
39944Change 20.7.15.2.7 [func.wrap.func.alg] before 1 as indicated:
39945</p>
39946
39947<blockquote><pre>template&lt;class R, class... ArgTypes&gt;
39948void swap(function&lt;R(ArgTypes...)&gt;&amp; f1, function&lt;R(ArgTypes...)&gt;&amp; f2);
39949<del>template&lt;class R, class... ArgTypes&gt;
39950void swap(function&lt;R(ArgTypes...)&gt;&amp;&amp; f1, function&lt;R(ArgTypes...)&gt;&amp; f2);
39951template&lt;class R, class... ArgTypes&gt;
39952void swap(function&lt;R(ArgTypes...)&gt;&amp; f1, function&lt;R(ArgTypes...)&gt;&amp;&amp; f2);</del>
39953</pre></blockquote>
39954
39955</li>
39956
39957<li>
39958<p>
39959Change 20.8.15.2 [util.smartptr.shared]/1 as indicated:
39960</p>
39961
39962<blockquote><pre>// 20.8.12.2.4, modifiers:
39963void swap(shared_ptr&amp;<del>&amp;</del> r);
39964
39965[..]
39966
39967// 20.8.12.2.9, shared_ptr specialized algorithms:
39968template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp; b);
39969<del>template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp;&amp; a, shared_ptr&lt;T&gt;&amp; b);
39970template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp;&amp; b);</del>
39971</pre></blockquote>
39972
39973</li>
39974
39975<li>
39976<p>
39977Change 21.3 [string.classes]/1, header <tt>&lt;string&gt;</tt> synopsis, as indicated:
39978</p>
39979
39980<blockquote><pre>// 21.4.8.8: swap
39981template&lt;class charT, class traits, class Allocator&gt;
39982void swap(basic_string&lt;charT,traits,Allocator&gt;&amp; lhs, basic_string&lt;charT,traits,Allocator&gt;&amp; rhs);
39983<del>template&lt;class charT, class traits, class Allocator&gt;
39984void swap(basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; lhs, basic_string&lt;charT,traits,Allocator&gt;&amp; rhs);
39985template&lt;class charT, class traits, class Allocator&gt;
39986void swap(basic_string&lt;charT,traits,Allocator&gt;&amp; lhs, basic_string&lt;charT,traits,Allocator&gt;&amp;&amp; rhs);</del>
39987</pre></blockquote>
39988
39989</li>
39990
39991<li>
39992<p>
39993Change 23.3 [sequences]/1, header <tt>&lt;deque&gt;</tt> synopsis, as indicated:
39994</p>
39995
39996<blockquote><pre>template &lt;class T, class Allocator&gt;
39997void swap(deque&lt;T,Allocator&gt;&amp; x, deque&lt;T,Allocator&gt;&amp; y);
39998<del>template &lt;class T, class Allocator&gt;
39999void swap(deque&lt;T,Allocator&gt;&amp;&amp; x, deque&lt;T,Allocator&gt;&amp; y);
40000template &lt;class T, class Allocator&gt;
40001void swap(deque&lt;T,Allocator&gt;&amp; x, deque&lt;T,Allocator&gt;&amp;&amp; y);</del>
40002</pre></blockquote>
40003
40004</li>
40005
40006<li>
40007<p>
40008Change 23.3 [sequences]/1, header <tt>&lt;list&gt;</tt> synopsis, as indicated:
40009</p>
40010
40011<blockquote><pre>template &lt;class T, class Allocator&gt;
40012void swap(list&lt;T,Allocator&gt;&amp; x, list&lt;T,Allocator&gt;&amp; y);
40013<del>template &lt;class T, class Allocator&gt;
40014void swap(list&lt;T,Allocator&gt;&amp;&amp; x, list&lt;T,Allocator&gt;&amp; y);
40015template &lt;class T, class Allocator&gt;
40016void swap(list&lt;T,Allocator&gt;&amp; x, list&lt;T,Allocator&gt;&amp;&amp; y);</del>
40017</pre></blockquote>
40018
40019</li>
40020
40021<li>
40022<p>
40023Change 23.3 [sequences]/1, header <tt>&lt;queue&gt;</tt> synopsis, as indicated:
40024</p>
40025
40026<blockquote><pre>template &lt;class T, class Allocator&gt;
40027void swap(queue&lt;T, Container&gt;&amp; x, queue&lt;T, Container&gt;&amp; y);
40028<del>template &lt;class T, class Container&gt;
40029void swap(queue&lt;T, Container&gt;&amp;&amp; x, queue&lt;T, Container&gt;&amp; y);
40030template &lt;class T, class Container&gt;
40031void swap(queue&lt;T, Container&gt;&amp; x, queue&lt;T, Container&gt;&amp;&amp; y);</del>
40032
40033template &lt;class T, class Container = vector&lt;T&gt;, class Compare = less&lt;typename Container::value_type&gt; &gt;
40034class priority_queue;
40035template &lt;class T, class Container, class Compare&gt;
40036void swap(priority_queue&lt;T, Container, Compare&gt;&amp; x, priority_queue&lt;T, Container, Compare&gt;&amp; y);
40037<del>template &lt;class T, class Container, class Compare&gt;
40038void swap(priority_queue&lt;T, Container, Compare&gt;&amp;&amp; x, priority_queue&lt;T, Container, Compare&gt;&amp; y);
40039template &lt;class T, class Container, class Compare&gt;
40040void swap(priority_queue&lt;T, Container, Compare&gt;&amp; x, priority_queue&lt;T, Container, Compare&gt;&amp;&amp; y);</del>
40041</pre></blockquote>
40042
40043</li>
40044
40045<li>
40046<p>
40047Change 23.3 [sequences]/1, header <tt>&lt;stack&gt;</tt> synopsis, as indicated:
40048</p>
40049
40050<blockquote><pre>template &lt;class T, class Container&gt;
40051void swap(stack&lt;T, Container&gt;&amp; x, stack&lt;T, Container&gt;&amp; y);
40052<del>template &lt;class T, class Container&gt;
40053void swap(stack&lt;T, Container&gt;&amp;&amp; x, stack&lt;T, Container&gt;&amp; y);
40054template &lt;class T, class Container&gt;
40055void swap(stack&lt;T, Container&gt;&amp; x, stack&lt;T, Container&gt;&amp;&amp; y);</del>
40056</pre></blockquote>
40057
40058</li>
40059
40060<li>
40061<p>
40062Change 23.3 [sequences]/1, header <tt>&lt;vector&gt;</tt> synopsis, as indicated:
40063</p>
40064
40065<blockquote><pre>template &lt;class T, class Allocator&gt;
40066void swap(vector&lt;T,Allocator&gt;&amp; x, vector&lt;T,Allocator&gt;&amp; y);
40067<del>template &lt;class T, class Allocator&gt;
40068void swap(vector&lt;T,Allocator&gt;&amp;&amp; x, vector&lt;T,Allocator&gt;&amp; y);
40069template &lt;class T, class Allocator&gt;
40070void swap(vector&lt;T,Allocator&gt;&amp; x, vector&lt;T,Allocator&gt;&amp;&amp; y);</del>
40071</pre></blockquote>
40072
40073</li>
40074
40075<li>
40076<p>
40077Change 23.3.2 [deque]/2 as indicated:
40078</p>
40079
40080<blockquote><pre>iterator erase(const_iterator position);
40081iterator erase(const_iterator first, const_iterator last);
40082void swap(deque&lt;T,Allocator&gt;&amp;<del>&amp;</del>);
40083void clear();
40084
40085[..]
40086
40087// specialized algorithms:
40088template &lt;class T, class Allocator&gt;
40089void swap(deque&lt;T,Allocator&gt;&amp; x, deque&lt;T,Allocator&gt;&amp; y);
40090<del>template &lt;class T, class Allocator&gt;
40091void swap(deque&lt;T,Allocator&gt;&amp;&amp; x, deque&lt;T,Allocator&gt;&amp; y);
40092template &lt;class T, class Allocator&gt;
40093void swap(deque&lt;T,Allocator&gt;&amp; x, deque&lt;T,Allocator&gt;&amp;&amp; y);</del>
40094</pre></blockquote>
40095
40096</li>
40097
40098<li>
40099<p>
40100Change 23.3.2.4 [deque.special] as indicated:
40101</p>
40102
40103<blockquote><pre>template &lt;class T, class Allocator&gt;
40104void swap(deque&lt;T,Allocator&gt;&amp; x, deque&lt;T,Allocator&gt;&amp; y);
40105<del>template &lt;class T, class Allocator&gt;
40106void swap(deque&lt;T,Allocator&gt;&amp;&amp; x, deque&lt;T,Allocator&gt;&amp; y);
40107template &lt;class T, class Allocator&gt;
40108void swap(deque&lt;T,Allocator&gt;&amp; x, deque&lt;T,Allocator&gt;&amp;&amp; y);</del>
40109</pre></blockquote>
40110
40111</li>
40112
40113<li>
40114<p>
40115Change 23.3.3 [forwardlist]/2 as indicated:
40116</p>
40117
40118<blockquote><pre>iterator erase_after(const_iterator position);
40119iterator erase_after(const_iterator position, iterator last);
40120void swap(forward_list&lt;T,Allocator&gt;&amp;<del>&amp;</del>);
40121
40122[..]
40123
40124// 23.3.3.6 specialized algorithms:
40125template &lt;class T, class Allocator&gt;
40126void swap(forward_list&lt;T,Allocator&gt;&amp; x, forward_list&lt;T,Allocator&gt;&amp; y);
40127<del>template &lt;class T, class Allocator&gt;
40128void swap(forward_list&lt;T,Allocator&gt;&amp;&amp; x, forward_list&lt;T,Allocator&gt;&amp; y);
40129template &lt;class T, class Allocator&gt;
40130void swap(forward_list&lt;T,Allocator&gt;&amp; x, forward_list&lt;T,Allocator&gt;&amp;&amp; y);</del>
40131</pre></blockquote>
40132
40133</li>
40134
40135<li>
40136<p>
40137Change 23.3.3.6 [forwardlist.spec] as indicated:
40138</p>
40139
40140<blockquote><pre>template &lt;class T, class Allocator&gt;
40141void swap(forward_list&lt;T,Allocator&gt;&amp; x, forward_list&lt;T,Allocator&gt;&amp; y);
40142<del>template &lt;class T, class Allocator&gt;
40143void swap(forward_list&lt;T,Allocator&gt;&amp;&amp; x, forward_list&lt;T,Allocator&gt;&amp; y);
40144template &lt;class T, class Allocator&gt;
40145void swap(forward_list&lt;T,Allocator&gt;&amp; x, forward_list&lt;T,Allocator&gt;&amp;&amp; y);</del>
40146</pre></blockquote>
40147
40148</li>
40149
40150<li>
40151<p>
40152Change 23.3.4 [list]/2 as indicated:
40153</p>
40154
40155<blockquote><pre>iterator erase(const_iterator position);
40156iterator erase(const_iterator position, const_iterator last);
40157void swap(list&lt;T,Allocator&gt;&amp;<del>&amp;</del>);
40158void clear();
40159
40160[..]
40161
40162// specialized algorithms:
40163template &lt;class T, class Allocator&gt;
40164void swap(list&lt;T,Allocator&gt;&amp; x, list&lt;T,Allocator&gt;&amp; y);
40165<del>template &lt;class T, class Allocator&gt;
40166void swap(list&lt;T,Allocator&gt;&amp;&amp; x, list&lt;T,Allocator&gt;&amp; y);
40167template &lt;class T, class Allocator&gt;
40168void swap(list&lt;T,Allocator&gt;&amp; x, list&lt;T,Allocator&gt;&amp;&amp; y);</del>
40169</pre></blockquote>
40170
40171</li>
40172
40173<li>
40174<p>
40175Change 23.3.4.5 [list.special] as indicated:
40176</p>
40177
40178<blockquote><pre>template &lt;class T, class Allocator&gt;
40179void swap(list&lt;T,Allocator&gt;&amp; x, list&lt;T,Allocator&gt;&amp; y);
40180<del>template &lt;class T, class Allocator&gt;
40181void swap(list&lt;T,Allocator&gt;&amp;&amp; x, list&lt;T,Allocator&gt;&amp; y);
40182template &lt;class T, class Allocator&gt;
40183void swap(list&lt;T,Allocator&gt;&amp; x, list&lt;T,Allocator&gt;&amp;&amp; y);</del>
40184</pre></blockquote>
40185
40186</li>
40187
40188<li>
40189<p>
40190Change 23.3.5.1.1 [queue.defn] as indicated:
40191</p>
40192
40193<blockquote><pre>void swap(queue&amp;<del>&amp;</del> q) { c.swap(q.c); }
40194
40195[..]
40196
40197template &lt;class T, class Container&gt;
40198void swap(queue&lt;T, Container&gt;&amp; x, queue&lt;T, Container&gt;&amp; y);
40199<del>template &lt;class T, class Container&gt;
40200void swap(queue&lt;T, Container&gt;&amp;&amp; x, queue&lt;T, Container&gt;&amp; y);
40201template &lt;class T, class Container&gt;
40202void swap(queue&lt;T, Container&gt;&amp; x, queue&lt;T, Container&gt;&amp;&amp; y);</del>
40203</pre></blockquote>
40204
40205</li>
40206
40207<li>
40208<p>
40209Change 23.3.5.1.3 [queue.special] as indicated:
40210</p>
40211
40212<blockquote><pre>template &lt;class T, class Container&gt;
40213void swap(queue&lt;T, Container&gt;&amp; x, queue&lt;T, Container&gt;&amp; y);
40214<del>template &lt;class T, class Container&gt;
40215void swap(queue&lt;T, Container&gt;&amp;&amp; x, queue&lt;T, Container&gt;&amp; y);
40216template &lt;class T, class Container&gt;
40217void swap(queue&lt;T, Container&gt;&amp; x, queue&lt;T, Container&gt;&amp;&amp; y);</del>
40218</pre></blockquote>
40219
40220</li>
40221
40222<li>
40223<p>
40224Change 23.3.5.2 [priority.queue]/1 as indicated:
40225</p>
40226
40227<blockquote><pre>void swap(priority_queue&amp;<del>&amp;</del>);
40228
40229// no equality is provided
40230template &lt;class T, class Container, class Compare&gt;
40231void swap(priority_queue&lt;T, Container, Compare&gt;&amp; x, priority_queue&lt;T, Container, Compare&gt;&amp; y);
40232<del>template &lt;class T, class Container, class Compare&gt;
40233void swap(priority_queue&lt;T, Container, Compare&gt;&amp;&amp; x, priority_queue&lt;T, Container, Compare&gt;&amp; y);
40234template &lt;class T, class Container, class Compare&gt;
40235void swap(priority_queue&lt;T, Container, Compare&gt;&amp; x, priority_queue&lt;T, Container, Compare&gt;&amp;&amp; y);</del>
40236</pre></blockquote>
40237
40238</li>
40239
40240<li>
40241<p>
40242Change 23.3.5.2.3 [priqueue.special] as indicated:
40243</p>
40244
40245<blockquote><pre>template &lt;class T, class Container, Compare&gt;
40246void swap(priority_queue&lt;T, Container, Compare&gt;&amp; x, priority_queue&lt;T, Container, Compare&gt;&amp; y);
40247<del>template &lt;class T, class Container, Compare&gt;
40248void swap(priority_queue&lt;T, Container, Compare&gt;&amp;&amp; x, priority_queue&lt;T, Container, Compare&gt;&amp; y);
40249template &lt;class T, class Container, Compare&gt;
40250void swap(priority_queue&lt;T, Container, Compare&gt;&amp; x, priority_queue&lt;T, Container, Compare&gt;&amp;&amp; y);</del>
40251</pre></blockquote>
40252
40253</li>
40254
40255<li>
40256<p>
40257Change 23.3.5.3.1 [stack.defn] as indicated:
40258</p>
40259
40260<blockquote><pre>void swap(stack&amp;<del>&amp;</del> s) { c.swap(s.c); }
40261
40262[..]
40263
40264template &lt;class T, class Allocator&gt;
40265void swap(stack&lt;T,Allocator&gt;&amp; x, stack&lt;T,Allocator&gt;&amp; y);
40266<del>template &lt;class T, class Allocator&gt;
40267void swap(stack&lt;T,Allocator&gt;&amp;&amp; x, stack&lt;T,Allocator&gt;&amp; y);
40268template &lt;class T, class Allocator&gt;
40269void swap(stack&lt;T,Allocator&gt;&amp; x, stack&lt;T,Allocator&gt;&amp;&amp; y);</del>
40270</pre></blockquote>
40271
40272
40273</li>
40274
40275<li>
40276<p>
40277Change 23.3.5.3.3 [stack.special] as indicated:
40278</p>
40279
40280<blockquote><pre>template &lt;class T, class Container&gt;
40281void swap(stack&lt;T, Container&gt;&amp; x, stack&lt;T, Container&gt;&amp; y);
40282<del>template &lt;class T, class Container&gt;
40283void swap(stack&lt;T, Container&gt;&amp;&amp; x, stack&lt;T, Container&gt;&amp; y);
40284template &lt;class T, class Container&gt;
40285void swap(stack&lt;T, Container&gt;&amp; x, stack&lt;T, Container&gt;&amp;&amp; y);</del>
40286</pre></blockquote>
40287
40288</li>
40289
40290<li>
40291<p>
40292Change 23.3.6 [vector]/2 as indicated:
40293</p>
40294
40295<blockquote><pre>void swap(vector&lt;T,Allocator&gt;&amp;<del>&amp;</del>);
40296void clear();
40297
40298[..]
40299
40300// specialized algorithms:
40301template &lt;class T, class Allocator&gt;
40302void swap(vector&lt;T,Allocator&gt;&amp; x, vector&lt;T,Allocator&gt;&amp; y);
40303<del>template &lt;class T, class Allocator&gt;
40304void swap(vector&lt;T,Allocator&gt;&amp;&amp; x, vector&lt;T,Allocator&gt;&amp; y);
40305template &lt;class T, class Allocator&gt;
40306void swap(vector&lt;T,Allocator&gt;&amp; x, vector&lt;T,Allocator&gt;&amp;&amp; y);</del>
40307</pre></blockquote>
40308
40309</li>
40310
40311<li>
40312<p>
40313Change 23.3.6.2 [vector.capacity] before p. 8 as indicated:
40314</p>
40315
40316<blockquote><pre>void swap(vector&lt;T,Allocator&gt;&amp;<del>&amp;</del> x);
40317</pre></blockquote>
40318
40319</li>
40320
40321<li>
40322<p>
40323Change 23.3.6.5 [vector.special] as indicated:
40324</p>
40325
40326<blockquote><pre>template &lt;class T, class Allocator&gt;
40327void swap(vector&lt;T,Allocator&gt;&amp; x, vector&lt;T,Allocator&gt;&amp; y);
40328<del>template &lt;class T, class Allocator&gt;
40329void swap(vector&lt;T,Allocator&gt;&amp;&amp; x, vector&lt;T,Allocator&gt;&amp; y);
40330template &lt;class T, class Allocator&gt;
40331void swap(vector&lt;T,Allocator&gt;&amp; x, vector&lt;T,Allocator&gt;&amp;&amp; y);</del>
40332</pre></blockquote>
40333
40334</li>
40335
40336<li>
40337<p>
40338Change 23.3.7 [vector.bool]/1 as indicated:
40339</p>
40340
40341<blockquote><pre>iterator erase(const_iterator first, const_iterator last);
40342void swap(vector&lt;bool,Allocator&gt;&amp;<del>&amp;</del>);
40343static void swap(reference x, reference y);
40344</pre></blockquote>
40345
40346</li>
40347
40348<li>
40349<p>
40350Change 23.4 [associative]/1, header <tt>&lt;map&gt;</tt> synopsis as indicated:
40351</p>
40352
40353<blockquote><pre>template &lt;class Key, class T, class Compare, class Allocator&gt;
40354void swap(map&lt;Key,T,Compare,Allocator&gt;&amp; x, map&lt;Key,T,Compare,Allocator&gt;&amp; y);
40355<del>template &lt;class Key, class T, class Compare, class Allocator&gt;
40356void swap(map&lt;Key,T,Compare,Allocator&amp;&amp; x, map&lt;Key,T,Compare,Allocator&gt;&amp; y);
40357template &lt;class Key, class T, class Compare, class Allocator&gt;
40358void swap(map&lt;Key,T,Compare,Allocator&amp; x, map&lt;Key,T,Compare,Allocator&gt;&amp;&amp; y);</del>
40359
40360[..]
40361
40362template &lt;class Key, class T, class Compare, class Allocator&gt;
40363void swap(multimap&lt;Key,T,Compare,Allocator&gt;&amp; x, multimap&lt;Key,T,Compare,Allocator&gt;&amp; y);
40364<del>template &lt;class Key, class T, class Compare, class Allocator&gt;
40365void swap(multimap&lt;Key,T,Compare,Allocator&amp;&amp; x, multimap&lt;Key,T,Compare,Allocator&gt;&amp; y);
40366template &lt;class Key, class T, class Compare, class Allocator&gt;
40367void swap(multimap&lt;Key,T,Compare,Allocator&amp; x, multimap&lt;Key,T,Compare,Allocator&gt;&amp;&amp; y);</del>
40368</pre></blockquote>
40369
40370</li>
40371
40372<li>
40373<p>
40374Change 23.4 [associative]/1, header <tt>&lt;set&gt;</tt> synopsis as indicated:
40375</p>
40376
40377<blockquote><pre>template &lt;class Key, class Compare, class Allocator&gt;
40378void swap(set&lt;Key,Compare,Allocator&gt;&amp; x, set&lt;Key,Compare,Allocator&gt;&amp; y);
40379<del>template &lt;class Key, class T, class Compare, class Allocator&gt;
40380void swap(set&lt;Key,T,Compare,Allocator&amp;&amp; x, set&lt;Key,T,Compare,Allocator&gt;&amp; y);
40381template &lt;class Key, class T, class Compare, class Allocator&gt;
40382void swap(set&lt;Key,T,Compare,Allocator&amp; x, set&lt;Key,T,Compare,Allocator&gt;&amp;&amp; y);</del>
40383
40384[..]
40385
40386template &lt;class Key, class Compare, class Allocator&gt;
40387void swap(multiset&lt;Key,Compare,Allocator&gt;&amp; x, multiset&lt;Key,Compare,Allocator&gt;&amp; y);
40388<del>template &lt;class Key, class T, class Compare, class Allocator&gt;
40389void swap(multiset&lt;Key,T,Compare,Allocator&amp;&amp; x, multiset&lt;Key,T,Compare,Allocator&gt;&amp; y);
40390template &lt;class Key, class T, class Compare, class Allocator&gt;
40391void swap(multiset&lt;Key,T,Compare,Allocator&amp; x, multiset&lt;Key,T,Compare,Allocator&gt;&amp;&amp; y);</del>
40392</pre></blockquote>
40393
40394</li>
40395
40396<li>
40397<p>
40398Change 23.4.1 [map]/2 as indicated:
40399</p>
40400
40401<blockquote><pre>iterator erase(const_iterator first, const_iterator last);
40402void swap(map&lt;Key,T,Compare,Allocator&gt;&amp;<del>&amp;</del>);
40403void clear();
40404
40405[..]
40406
40407// specialized algorithms:
40408template &lt;class Key, class T, class Compare, class Allocator&gt;
40409void swap(map&lt;Key,T,Compare,Allocator&gt;&amp; x, map&lt;Key,T,Compare,Allocator&gt;&amp; y);
40410<del>template &lt;class Key, class T, class Compare, class Allocator&gt;
40411void swap(map&lt;Key,T,Compare,Allocator&amp;&amp; x, map&lt;Key,T,Compare,Allocator&gt;&amp; y);
40412template &lt;class Key, class T, class Compare, class Allocator&gt;
40413void swap(map&lt;Key,T,Compare,Allocator&amp; x, map&lt;Key,T,Compare,Allocator&gt;&amp;&amp; y);</del>
40414</pre></blockquote>
40415
40416</li>
40417
40418<li>
40419<p>
40420Change 23.4.1.5 [map.special] as indicated:
40421</p>
40422
40423<blockquote><pre>template &lt;class Key, class T, class Compare, class Allocator&gt;
40424void swap(map&lt;Key,T,Compare,Allocator&gt;&amp; x, map&lt;Key,T,Compare,Allocator&gt;&amp; y);
40425<del>template &lt;class Key, class T, class Compare, class Allocator&gt;
40426void swap(map&lt;Key,T,Compare,Allocator&gt;&amp;&amp; x, map&lt;Key,T,Compare,Allocator&gt;&amp; y);
40427template &lt;class Key, class T, class Compare, class Allocator&gt;
40428void swap(map&lt;Key,T,Compare,Allocator&gt;&amp; x, map&lt;Key,T,Compare,Allocator&gt;&amp;&amp; y);</del>
40429</pre></blockquote>
40430
40431</li>
40432
40433<li>
40434<p>
40435Change 23.4.2 [multimap]/2 as indicated:
40436</p>
40437
40438<blockquote><pre>iterator erase(const_iterator first, const_iterator last);
40439void swap(multimap&lt;Key,T,Compare,Allocator&gt;&amp;<del>&amp;</del>);
40440void clear();
40441
40442[..]
40443
40444// specialized algorithms:
40445template &lt;class Key, class T, class Compare, class Allocator&gt;
40446void swap(multimap&lt;Key,T,Compare,Allocator&gt;&amp; x, multimap&lt;Key,T,Compare,Allocator&gt;&amp; y);
40447<del>template &lt;class Key, class T, class Compare, class Allocator&gt;
40448void swap(multimap&lt;Key,T,Compare,Allocator&amp;&amp; x, multimap&lt;Key,T,Compare,Allocator&gt;&amp; y);
40449template &lt;class Key, class T, class Compare, class Allocator&gt;
40450void swap(multimap&lt;Key,T,Compare,Allocator&amp; x, multimap&lt;Key,T,Compare,Allocator&gt;&amp;&amp; y);</del>
40451</pre></blockquote>
40452
40453</li>
40454
40455<li>
40456<p>
40457Change 23.4.2.4 [multimap.special] as indicated:
40458</p>
40459
40460<blockquote><pre>template &lt;class Key, class T, class Compare, class Allocator&gt;
40461void swap(multimap&lt;Key,T,Compare,Allocator&gt;&amp; x, multimap&lt;Key,T,Compare,Allocator&gt;&amp; y);
40462<del>template &lt;class Key, class T, class Compare, class Allocator&gt;
40463void swap(multimap&lt;Key,T,Compare,Allocator&gt;&amp;&amp; x, multimap&lt;Key,T,Compare,Allocator&gt;&amp; y);
40464template &lt;class Key, class T, class Compare, class Allocator&gt;
40465void swap(multimap&lt;Key,T,Compare,Allocator&gt;&amp; x, multimap&lt;Key,T,Compare,Allocator&gt;&amp;&amp; y);</del>
40466</pre></blockquote>
40467
40468</li>
40469
40470<li>
40471<p>
40472Change 23.4.3 [set]/2 and 23.4.3.2 [set.special] as indicated: (twice!)
40473</p>
40474
40475<blockquote><pre>// specialized algorithms:
40476template &lt;class Key, class Compare, class Allocator&gt;
40477void swap(set&lt;Key,Compare,Allocator&gt;&amp; x, set&lt;Key,Compare,Allocator&gt;&amp; y);
40478<del>template &lt;class Key, class Compare, class Allocator&gt;
40479void swap(set&lt;Key,Compare,Allocator&amp;&amp; x, set&lt;Key,Compare,Allocator&gt;&amp; y);
40480template &lt;class Key, class Compare, class Allocator&gt;
40481void swap(set&lt;Key,Compare,Allocator&amp; x, set&lt;Key,Compare,Allocator&gt;&amp;&amp; y);</del>
40482</pre></blockquote>
40483
40484</li>
40485
40486<li>
40487<p>
40488Change 23.4.4 [multiset]/2 as indicated:
40489</p>
40490
40491<blockquote><pre>iterator erase(const_iterator first, const_iterator last);
40492void swap(multiset&lt;Key,Compare,Allocator&gt;&amp;<del>&amp;</del>);
40493void clear();
40494
40495[..]
40496
40497// specialized algorithms:
40498template &lt;class Key, class Compare, class Allocator&gt;
40499void swap(multiset&lt;Key,Compare,Allocator&gt;&amp; x, multiset&lt;Key,Compare,Allocator&gt;&amp; y);
40500<del>template &lt;class Key, class Compare, class Allocator&gt;
40501void swap(multiset&lt;Key,Compare,Allocator&amp;&amp; x, multiset&lt;Key,Compare,Allocator&gt;&amp; y);
40502template &lt;class Key, class Compare, class Allocator&gt;
40503void swap(multiset&lt;Key,Compare,Allocator&amp; x, multiset&lt;Key,Compare,Allocator&gt;&amp;&amp; y);</del>
40504</pre></blockquote>
40505
40506</li>
40507
40508<li>
40509<p>
40510Change 23.4.4.2 [multiset.special] as indicated:
40511</p>
40512
40513<blockquote><pre>template &lt;class Key, class Compare, class Allocator&gt;
40514void swap(multiset&lt;Key,Compare,Allocator&gt;&amp; x, multiset&lt;Key,Compare,Allocator&gt;&amp; y);
40515<del>template &lt;class Key, class Compare, class Allocator&gt;
40516void swap(multiset&lt;Key,Compare,Allocator&gt;&amp;&amp; x, multiset&lt;Key,Compare,Allocator&gt;&amp; y);
40517template &lt;class Key, class Compare, class Allocator&gt;
40518void swap(multiset&lt;Key,Compare,Allocator&gt;&amp; x, multiset&lt;Key,Compare,Allocator&gt;&amp;&amp; y);</del>
40519</pre></blockquote>
40520
40521</li>
40522</ol>
40523
40524
40525
40526
40527
40528<hr>
40529<h3><a name="1235"></a>1235. Issue with C++0x random number proposal</h3>
40530<p><b>Section:</b> 26.5.2.5 [rand.concept.dist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
40531 <b>Submitter:</b> Matthias Troyer <b>Opened:</b> 2009-10-12  <b>Last modified:</b> 2009-10-26</p>
40532<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
40533<p><b>Discussion:</b></p>
40534<p>
40535There exist optimized, vectorized vendor libraries for the creation of
40536random number generators, such as Intel's MKL [1] and AMD's ACML [2]. In
40537timing tests we have seen a performance gain of a factor of up to 80
40538(eighty) compared to a pure C++ implementation (in Boost.Random) when
40539using these generator to generate a sequence of normally distributed
40540random numbers. In codes dominated by the generation of random numbers
40541(we have application codes where random number generation is more than
4054250% of the CPU time) this factor 80 is very significant.
40543</p>
40544
40545<p>
40546To make use of these vectorized generators, we use a C++ class modeling
40547the <tt>RandomNumberEngine</tt> concept and forwarding the generation of random
40548numbers to those optimized generators. For example:
40549</p>
40550
40551<blockquote><pre>namespace mkl {
40552 class mt19937 {.... };
40553}
40554</pre></blockquote>
40555
40556<p>
40557For the generation of random variates we also want to dispatch to
40558optimized vectorized functions in the MKL or ACML libraries. See this
40559example:
40560</p>
40561
40562<blockquote><pre>mkl::mt19937 eng;
40563std::normal_distribution&lt;double&gt; dist;
40564
40565double n = dist(eng);
40566</pre></blockquote>
40567
40568<p>
40569Since the variate generation is done through the <tt>operator()</tt> of the
40570distribution there is no customization point to dispatch to Intel's or
40571AMD's optimized functions to generate normally distributed numbers based
40572on the <tt>mt19937</tt> generator. Hence, the performance gain of 80 cannot be
40573achieved.
40574</p>
40575
40576<p>
40577Contrast this with TR1:
40578</p>
40579
40580<blockquote><pre>mkl::mt19937 eng;
40581std::tr1::normal_distribution&lt;double&gt; dist;
40582std::tr1::variate_generator&lt;mkl::mt19937,std::tr1::normal_distribution&lt;double&gt; &gt; rng(eng,dist);
40583double n = rng();
40584</pre></blockquote>
40585
40586<p>
40587This - admittedly much uglier from an aestethic point of view - design
40588allowed optimization by specializing the <tt>variate_generator</tt> template for
40589<tt>mkl::mt19937</tt>:
40590</p>
40591
40592<blockquote><pre>namespace std { namespace tr1 {
40593
40594template&lt;&gt;
40595class variate_generator&lt;mkl::mt19937,std::tr1::normal_distribution&lt;double&gt; &gt; { .... };
40596
40597} }
40598</pre></blockquote>
40599
40600<p>
40601A similar customization point is missing in the C++0x design and
40602prevents the optimized vectorized version to be used.
40603</p>
40604
40605<p>
40606Suggested resolution:
40607</p>
40608
40609<p>
40610Add a customization point to the distribution concept. Instead of the
40611<tt>variate_generator</tt> template this can be done through a call to a
40612free function <tt>generate_variate</tt> found by ADL instead of
40613<tt>operator()</tt> of the distribution:
40614</p>
40615
40616<blockquote><pre>template &lt;RandomNumberDistribution, class RandomNumberEngine&gt;
40617typename RandomNumberDistribution ::result_type
40618generate_variate(RandomNumberDistribution const&amp; dist, RandomNumberEngine&amp; eng);
40619</pre></blockquote>
40620
40621<p>
40622This function can be overloaded for optimized enginges like
40623<tt>mkl::mt19937</tt>.
40624</p>
40625
40626<p><i>[
406272009-10 Santa Cruz:
40628]</i></p>
40629
40630
40631<blockquote>
40632NAD Future.  No time to add this feature for C++0X.
40633</blockquote>
40634
40635
40636
40637<p><b>Proposed resolution:</b></p>
40638
40639
40640
40641
40642
40643<hr>
40644<h3><a name="1236"></a>1236. reserved identifiers in programs not using the library</h3>
40645<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
40646 <b>Submitter:</b> Sean Hunt <b>Opened:</b> 2009-10-13  <b>Last modified:</b> 2009-10-20</p>
40647<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>
40648<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>
40649<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
40650<p><b>Discussion:</b></p>
40651<p>
40652I wasn't sure whether to consider this a library or a language issue,
40653because the issue is I think it's incorrectly categorized as being part
40654of the library, so I thought I'd send a message to both of you and let
40655you sort it out.
40656</p>
40657
40658<p>
40659Most reserved identifiers are treated as unilaterally available to the
40660implementation, such as to implement language extensions, or provide
40661macros documenting its functionality. However, the requirements for
40662reserved identifers are in 17.6.3.3 [reserved.names], which are a
40663subsection of 17.6.3 [constraints]. 17.6.3.1 [constraints.overview] appears only to apply to "C++ programs
40664that use the facilities of the C++ standard library", meaning that, in
40665theory, all implementations are erroneous in having any non-standard
40666identifiers predefined for programs that do not, at some point, include
40667a standard library header.
40668</p>
40669
40670<p>Furthermore, it's unclear whether the use of certain identifiers is
40671UB
40672or results in an ill-formed program. In particular, 17.6.3.3.1
40673[macro.names] uses a "shall not", where 17.6.3.3.2 [global.names] says
40674that names are "reserved to the
40675implementation". 17.6.3.3 [reserved.names] seems only to cover the
40676instance of a name being described as "reserved", so are
40677implementations
40678required to diagnose a program that performs, as an example, "<tt>#undef
40679get</tt>"?
40680</p>
40681
40682<p><i>[
406832009 Santa Cruz:
40684]</i></p>
40685
40686
40687<blockquote>
40688Move to NAD. There may in theory be multiple interpretations possible,
40689but there's no evidence that this causes any genuine problems or
40690uncertainty about what implementations are allowed to do. We do not
40691believe this rises to the level of a defect.
40692</blockquote>
40693
40694
40695
40696<p><b>Proposed resolution:</b></p>
40697
40698
40699
40700
40701
40702<hr>
40703<h3><a name="1242"></a>1242. Enable SCARY iterators</h3>
40704<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
40705 <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2009-10-21  <b>Last modified:</b> 2009-10-21</p>
40706<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>
40707<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>
40708<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
40709<p><b>Discussion:</b></p>
40710<p>
40711See
40712<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2980.pdf">N2980</a>.
40713</p>
40714
40715
40716<p><b>Proposed resolution:</b></p>
40717
40718
40719
40720
40721
40722<hr>
40723<h3><a name="1243"></a>1243. Missing <tt>operator+= (initializer_list&lt;T&gt;)</tt> for <tt>valarray</tt></h3>
40724<p><b>Section:</b> 26.6.2.6 [valarray.cassign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
40725 <b>Submitter:</b> Daniel Kr�gler <b>Opened:</b> 2009-10-22  <b>Last modified:</b> 2009-10-26</p>
40726<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cassign">issues</a> in [valarray.cassign].</p>
40727<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
40728<p><b>Discussion:</b></p>
40729<p><b>Addresses JP 64</b></p>
40730
40731<p>
40732During the additions of <tt>initializer_list</tt> overloads
40733<tt>basic_string</tt> added
40734</p>
40735
40736<blockquote><pre>basic_string&amp; operator+=(initializer_list&lt;charT&gt;);
40737</pre></blockquote>
40738
40739<p>
40740but
40741</p>
40742
40743<blockquote><pre>valarray&lt;T&gt;&amp; operator+= (initializer_list&lt;T&gt;);
40744</pre></blockquote>
40745
40746<p>
40747was not defined.
40748</p>
40749
40750<p><i>[
40751Daniel adds on opening:
40752]</i></p>
40753
40754
40755<blockquote>
40756Recommend NAD. The <tt>operator+=</tt> overload of <tt>basic_string</tt>
40757behaves as-if calling <tt>append</tt>, which is completely different in
40758meaning as the existing <tt>operator+=</tt> overloads in
40759<tt>valarray</tt> which just sum the value or values to the existing
40760elements. The suggestion to add a corresponding append function to
40761<tt>valarray</tt> was not considered as appropriate and the request was
40762withdrawn (c++std-lib-24968).
40763</blockquote>
40764
40765<p><i>[
407662009-10 Santa Cruz:
40767]</i></p>
40768
40769
40770<blockquote>
40771Mark as NAD.  Request has been withdrawn by NB.
40772</blockquote>
40773
40774
40775
40776<p><b>Proposed resolution:</b></p>
40777<p>
40778Add to 26.6.2.6 [valarray.cassign]:
40779</p>
40780
40781<blockquote><pre>valarray&lt;T&gt;&amp; operator+= (initializer_list&lt;T&gt;);
40782</pre></blockquote>
40783
40784
40785
40786
40787
40788<hr>
40789<h3><a name="1248"></a>1248. Equality comparison for unordered containers</h3>
40790<p><b>Section:</b> 23.5 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
40791 <b>Submitter:</b> Herb Sutter <b>Opened:</b> 2009-10-25  <b>Last modified:</b> 2009-10-25</p>
40792<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>
40793<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
40794<p><b>Discussion:</b></p>
40795<p>
40796See
40797<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2986.pdf">N2986</a>.
40798</p>
40799
40800
40801<p><b>Proposed resolution:</b></p>
40802
40803
40804
40805
40806
40807</body></html>