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 <<a href="mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>></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->release()" where it clearly must be "Calls 949p.release()". (As it is, it seems to require using 950auto_ptr<>::operator-> 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->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<> 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<>::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<>::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. 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 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<charT, Traits></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 << '[' << setw(10) << right << text << ']'; 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 <tt>T operator[] (size_t) const;</tt><br> 1259<br> 1260why not <br> 1261<br> 1262 <tt>const T& 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 <tt>memcpy(ptr, &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 Instead of</p> 1296 1297<pre> slice_array(const slice_array&); 1298 slice_array& operator=(const slice_array&);</pre> 1299 1300<p>IMHO they have to be</p> 1301 1302<pre> slice_array(const slice_array<T>&); 1303 slice_array& operator=(const slice_array<T>&);</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<const Key, T>. 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 &) 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> 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<class InputIterator> 1427 basic_string& append(InputIterator first, InputIterator last);</pre> 1428 1429<p>return a string, while</p> 1430<pre> template<class InputIterator> 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<valarray<double> >(va[slice(1,4,3)]) * 1486 static_cast<valarray<double> >(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 <class T, class Alloc = allocator<T> > class 1511vector;</tt> defining it as <tt>template <class T, class Alloc = allocator<T>, 1512int N = 1> 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 <class T, class Allocator = allocator<T>, int N = 1> 1537 class __vector 1538 { ... }; 1539 template <class T, class Allocator = allocator<T> > 1540 class vector: public __vector<T, Allocator> 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. The example is already 1625illegal. See 17.6.4.5 [member.functions] paragraph 2.</p> 1626 1627 1628 1629 1630<hr> 1631<h3><a name="96"></a>96. Vector<bool> 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<bool></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<bool> 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 * Not A Defect.<br> 1657 * Add a note explaining that vector<bool> does not meet 1658Container requirements.<br> 1659 * Remove vector<bool>.<br> 1660 * Add a new category of container requirements which 1661vector<bool> would meet.<br> 1662 * Rename vector<bool>.<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<bool> in the next standard. (2) 1669Remove vector<bool> 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<bool>) 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<bool> 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<bool>: 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<bool> and introduce this functionality under 1693 a different name, e.g. bit_vector. This might make it possible to 1694 remove the vector<bool> 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<bool> 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<bool></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<bool></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&)</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 <, >, <=, >= 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<T></tt>): 1901</p> 1902 1903<blockquote> 1904 <p><tt>vector<T>(v).swap(v); // 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 > 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&, size_t) and (size_t, const T&), 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<size_t> 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<>::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 <bitset> 2159using namespace std; 2160bitset<32> 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<32> 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 <class charT, class traits, class Allocator> 2174explicit bitset (const basic_string<charT, traits, Allocator>& 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 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<wchar_t> 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<char> , 2224ctype<wchar_t>. </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<char> and 2230 ctype<wchar_t> , 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<char> specialization, not the 2236ctype<wchar_t> specialization. </p> 2237 2238 2239<p><b>Proposed resolution:</b></p> 2240<p>Add the ctype<wchar_t> 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 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 << or operator 2264 >> 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> <tt>openmode mode() const</tt>;</p> 2306 2307<p><b> 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<>::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(). </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<charT,traits>(sb) (lib.istream) and 2354basic_ostream<charT,traits>(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<charT,traits>(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<char> 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<char> 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<char> 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<char> as a 2401specialization, because the base class ctype<char> 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<Key, T>::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 return type 2444 pre/post-condition<br> 2445 ------------- ----------- 2446 -------------------<br> 2447 X::value_type T 2448 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<Key, T> ... the value_type is pair<const Key, T>.</p> 2456</blockquote> 2457 2458<p>There's a contradiction here. In particular, `pair<const Key, 2459T>' is not assignable; the `const Key' cannot be assigned 2460to. So, map<Key, T>::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... 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 <time.h> 2550#include <utility> 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 <class Iterator> 2747struct iterator_traits 2748{ 2749 typedef typename Iterator::value_type value_type; 2750}; 2751 2752template <class T> class reverse_iterator; 2753 2754// reverse_iterator operator+ 2755template <class T> 2756reverse_iterator<T> operator+ 2757(typename iterator_traits<T>::difference_type, const reverse_iterator<T>&); 2758 2759template <class T> struct complex {}; 2760 2761// complex operator + 2762template <class T> 2763complex<T> operator+ (const T& lhs, const complex<T>& rhs) 2764{ return complex<T>();} 2765} 2766 2767// request for explicit instantiation 2768template std::complex<float> std::operator+<float>(const float&, 2769 const std::complex<float>&);</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+<float>" 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() & 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 &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& 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<T>::op=(const T&), but fails to provide 2831corresponding versions for the helper classes. Thus making the 2832following illegal:</p> 2833<blockquote> 2834<pre>#include <valarray> 2835 2836int main() 2837{ 2838std::valarray<double> 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. 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. 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(). <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. 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> char place[sizeof(Something)];<br> 3089 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<user-defined type></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: </p> 3171 <pre>const ctype<charT>& ctype = use_facet<ctype<charT> >(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<char> and 3178ctype<wchar_t>. 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<charT> 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<char> 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> Returns: do_widen(low, high, to).</p> 3316 3317<p>to:</p> 3318<p> 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> Returns: do_narrow(low, high, to).</p> 3324 3325<p>to:</p> 3326<p> 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<const int> is 3375not legal, I think:</p> 3376<blockquote> 3377 <pre>map < const int, ... > // 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<<s behaves 3411as if f(s) were called, in is an (instance of) basic_istream then the 3412expression in>>s behaves as if f(s) were called. Where f can be 3413defined as:</p> 3414<pre>ios_base& f(ios_base& 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<<s and in>>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<.</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<> and ordering is established using less<>. Worse, 3464the use of operator<, would cause the following innocent-looking code to have 3465undefined behavior:</p> 3466<blockquote> 3467 <pre>vector<string*> vec; 3468sort(vec.begin(), vec.end());</pre> 3469</blockquote> 3470<p>The use of operator< is not defined for pointers to unrelated objects. If 3471std::sort used less<> to compare elements, then the above code would be 3472well-defined, since less<> 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< 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<.</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<class InputIterator, class T, class BinaryPredicate> 3531 InputIterator find(InputIterator first, InputIterator last, 3532 const T& 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> to:</p> 3539<blockquote> 3540 <p>Returns: The first iterator i in the range [first, last) for which the following 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. 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<char>::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<class Iter, class X> 3600 Iter find(Iter begin, Iter end, const X& x) 3601 { 3602 X x1 = x; // this is the crucial statement 3603 while (begin != end && *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<string> 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<int> 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<int> 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<>::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<int>::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 <class Arg, class Result> 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 <class Arg, class Result> 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 20.3.1 [lib.function.objects] -- unary_function, binary_function 3965 <br> 3966 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 <strstream> 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<>(), 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<>::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 <cstdarg> 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. <cmath> 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 <math.h>: 4332</p> 4333 4334<blockquote><p> 4335 7.13.4 Mathematics <math.h> 4336 <br> 4337 The names of all existing functions declared in the <math.h> 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 sinf(float)</tt> 4345 is reserved. 4346</p> 4347 4348<p> 4349 In the C99 standard, <math.h> 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<>::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<>::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<>::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<>::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& 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& 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->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->()</tt> must return a pointer for 4622<tt>a->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-> 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<>::sentry 4650(27.7.1.1.3 [istream::sentry]) and basic_ostream<>::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<>::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<>::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()->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& operator>> (istream &strm, S &s) 4766{ 4767 ios::iostate err = ios::goodbit; 4768 try { 4769 const istream::sentry guard (strm, false); 4770 if (guard) { 4771 use_facet<num_get<char> >(strm.getloc ()) 4772 .get (istreambuf_iterator<char>(strm), 4773 istreambuf_iterator<char>(), 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& operator>> (istream &strm, S &s) 4800{ 4801 istream::sentry guard (strm, false); 4802 if (guard) { 4803 ios::iostate err = ios::goodbit; 4804 try { 4805 use_facet<num_get<char> >(strm.getloc ()) 4806 .get (istreambuf_iterator<char>(strm), 4807 istreambuf_iterator<char>(), 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& operator>> (istream &strm, S &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<num_get<char> >(strm.getloc ()) 4848 .get (istreambuf_iterator<char>(strm), 4849 istreambuf_iterator<char>(), 4850 strm, err, s.i); 4851 } 4852 } 4853 catch (...) { 4854 if (thrown && state & 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>>( T& ) 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>>()) 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 <exception> 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 <cstdlib> 5072 5073 abs(float), abs(double), abs(long double) in <cmath> 5074 5075 template<class T> T abs(const complex<T>&) in <complex> 5076 5077 template<class T> valarray<T> abs(const valarray<T>&); in <valarray> 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 <cstdlib>, the <tt>float</tt> version if the user 5123 included <cmath>, 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><all></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 <cctype>. 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< T > </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& p += O(1) 5237p++ fpos { P tmp = p; 5238 ++p; 5239 return tmp; } 5240--p fpos& 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()->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()&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()->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<string>, 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 <memory> from within <string>, 5408either directly or indirectly, to bring the declaration of 5409std::allocator into scope. 5410</p> 5411 5412<p> 5413Additionally, however, some implementation also include <istream> and 5414<ostream> at the top of <string> 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<iosfwd>, since strictly speaking, only the declarations and not the 5419full definitions are necessary. 5420</p> 5421 5422<p> 5423Obviously, it is possible to implement <string> 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 <istream> or <ostream>, respectively, it doesn't seem 5434reasonable to also expect it to explicitly include <memory>. 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 <string> 5447 5448extern std::basic_ostream<char> &strm; 5449 5450int main () { 5451 strm << std::string ("Hello, World!\n"); 5452} 5453</pre> 5454 5455<p>or whether one must explicitly include <memory> or 5456<ostream> (or both) in addition to <string> 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 <istream> 5465 5466extern std::basic_iostream<char> &strm; 5467 5468int main () { 5469 strm << "Hello, World!\n"; 5470} 5471</pre> 5472 5473<p> 5474or whether one needs to explicitly include <ostream>, and 5475perhaps even other headers containing the definitions of other 5476required templates:</p> 5477 5478<pre>#include <ios> 5479#include <istream> 5480#include <ostream> 5481#include <streambuf> 5482 5483extern std::basic_iostream<char> &strm; 5484 5485int main () { 5486 strm << "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 <iterator> 5494 5495bool foo (std::istream_iterator<int> a, std::istream_iterator<int> b) 5496{ 5497 return a == b; 5498} 5499 5500int main () { } 5501</pre> 5502 5503<p>or whether one should be required to include <istream>.</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|<algorithm> | | 5548+------------+--------------------+ 5549|<bitset> | | 5550+------------+--------------------+ 5551|<complex> | | 5552+------------+--------------------+ 5553|<deque> |<memory> | 5554+------------+--------------------+ 5555|<exception> | | 5556+------------+--------------------+ 5557|<fstream> |<ios> | 5558+------------+--------------------+ 5559|<functional>| | 5560+------------+--------------------+ 5561|<iomanip> |<ios> | 5562+------------+--------------------+ 5563|<ios> |<streambuf> | 5564+------------+--------------------+ 5565|<iosfwd> | | 5566+------------+--------------------+ 5567|<iostream> |<istream>, <ostream>| 5568+------------+--------------------+ 5569|<istream> |<ios> | 5570+------------+--------------------+ 5571|<iterator> | | 5572+------------+--------------------+ 5573|<limits> | | 5574+------------+--------------------+ 5575|<list> |<memory> | 5576+------------+--------------------+ 5577|<locale> | | 5578+------------+--------------------+ 5579|<map> |<memory> | 5580+------------+--------------------+ 5581|<memory> | | 5582+------------+--------------------+ 5583|<new> |<exception> | 5584+------------+--------------------+ 5585|<numeric> | | 5586+------------+--------------------+ 5587|<ostream> |<ios> | 5588+------------+--------------------+ 5589|<queue> |<deque> | 5590+------------+--------------------+ 5591|<set> |<memory> | 5592+------------+--------------------+ 5593|<sstream> |<ios>, <string> | 5594+------------+--------------------+ 5595|<stack> |<deque> | 5596+------------+--------------------+ 5597|<stdexcept> | | 5598+------------+--------------------+ 5599|<streambuf> |<ios> | 5600+------------+--------------------+ 5601|<string> |<memory> | 5602+------------+--------------------+ 5603|<strstream> | | 5604+------------+--------------------+ 5605|<typeinfo> |<exception> | 5606+------------+--------------------+ 5607|<utility> | | 5608+------------+--------------------+ 5609|<valarray> | | 5610+------------+--------------------+ 5611|<vector> |<memory> | 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 <all> 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<</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< 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 < y.first || (!(y.first < x.first) && x.second < 5698 y.second). 5699</pre> 5700<p>With:</p> 5701<pre> Returns: std::less<T1>()( x.first, y.first ) || 5702 (!std::less<T1>()( y.first, x.first) && 5703 std::less<T2>()( 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< 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<T*>, 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<>::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&() 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&(); }; 5745 std::vector<A> aa; 5746 5747 class B { }; 5748 B* operator&(B&) { return 0; } 5749 std::vector<B> 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<>::address is 5755defined in terms of unadorned operator &. 5756</p> 5757 5758 5759 5760<p><b>Proposed resolution:</b></p> 5761<p> 5762In 20.6.1.1, Change the definition of allocator<>::address from:</p> 5763<blockquote><p> 5764 Returns: &x 5765</p></blockquote> 5766 5767<p>to:</p> 5768 5769<p> 5770 Returns: The value that the built in operator&(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<T>::address(r) 5780 allocator<T>::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& to any type for which 5787 operator& 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 &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 <functional> 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<C, D></tt> to <tt>pair<A, B></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<A, B></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<class U, class V> 5870 pair& operator=(const pair<U, V> &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<class U, class V> 5877 pair& operator=(const pair<U, V> &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. 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 <locale> 5912 #include <iostream> 5913 5914 class my_ctype : public std::ctype<char> 5915 { 5916 typedef std::ctype<char> 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 << "isspace: " << ct.is(std::ctype_base::space, '_') << " " 5932 << "isalpha: " << ct.is(std::ctype_base::alpha, '_') << 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<char>, 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 -> !isalpha. 5988-------- 5989 5990#include <locale> 5991#include <iostream> 5992 5993class my_ctype : public std::ctype<char> 5994{ 5995private: 5996 typedef std::ctype<char> 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<mask>('_')] = both; 6006 } 6007}; 6008 6009int main() 6010{ 6011 using namespace std; 6012 my_ctype ct; 6013 cout << "isspace: " << ct.is(ctype_base::space, '_') << endl; 6014 cout << "isprint: " << ct.is(ctype_base::print, '_') << endl; 6015 6016 // ISO C99, isalpha iff upper | lower set, and !space. 6017 // 7.5, p 193 6018 // -> looks like g++ behavior is correct. 6019 // 356 -> bitmask elements are required for ctype_base 6020 // 339 -> bitmask type required for mask 6021 cout << "isalpha: " << ct.is(ctype_base::alpha, '_') << 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. <cmath> 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<>::do_get (..., void*&) 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<numpunct<charT> >(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<charT,traits>* tie() const; 6201</pre> 6202<p>with</p> 6203<pre> basic_ostream<charT,traits>* tie(); 6204 const basic_ostream<charT,traits>* tie() const; 6205</pre> 6206 6207<p>and replace</p> 6208<pre> basic_streambuf<charT,traits>* rdbuf() const; 6209</pre> 6210<p>with</p> 6211<pre> basic_streambuf<charT,traits>* rdbuf(); 6212 const basic_streambuf<charT,traits>* 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<charT,traits,Allocator>* rdbuf() const; 6268</pre> 6269<p>with</p> 6270<pre> basic_stringbuf<charT,traits,Allocator>* rdbuf(); 6271 const basic_stringbuf<charT,traits,Allocator>* 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<charT,traits>* rdbuf() const; 6277</pre> 6278<p>with</p> 6279<pre> basic_filebuf<charT,traits>* rdbuf(); 6280 const basic_filebuf<charT,traits>* 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() >= 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& operator=(const locale& 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<char> &r0 = std::use_facet<std::ctype<char> >(loc); 6493 loc = std::locale ("en_US"); 6494 const std::ctype<char> &r1 = std::use_facet<std::ctype<char> >(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 <-> 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<my_iterator, 6676my_predicate&></tt>. The question is whether implementation 6677are required to accept this, or whether this is ill-formed because 6678my_predicate& 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<> and the associative containers 6741occasionally reveals artificial and distracting issues with constructs 6742resembling: std::set<std::complex<double> > s; 6743</p> 6744 6745<p> 6746The main reason for the above to fail is the absence of an approriate 6747definition for std::less<std::complex<T> >. That in turn comes from 6748the definition of the primary template std::less<> in terms of 6749operator<. 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< operating on the datatype 6756std::complex<T>. That is fine. However, that reasoning does not carry 6757over to std::less<T> 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< 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<</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 &t 6815returns the address of t (with type T*). This requirement is overly 6816strict, in that it disallows types that overload operator& 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& 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<int> 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& 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 <typename T> T* addressof(T& v) 6844 { 6845 return reinterpret_cast<T*>( 6846 &const_cast<char&>(reinterpret_cast<const volatile char &>(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 &t and &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 <iostream> 6901 #include <fstream> 6902 #include <iterator> 6903 using namespace std; 6904 6905 int main() { 6906 ifstream file1("file1.txt"), file2("file2.txt"); 6907 istreambuf_iterator<char> f1(file1), f2(file2); 6908 cout << "f1 == f2 : " << boolalpha << (f1 == f2) << endl; 6909 cout << "f1 = " << *f1 << endl; 6910 cout << "f2 = " << *f2 << 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<num_put<charT,ostreambuf_iterator<charT,traits> 7026 > > 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<<(int) will 7069set badbit if the disk is full, while operator<<(ostream&, 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<charT, traits>& 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<charT, traits>& 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<charT, traits>& 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<charT, traits>& 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<charT, traits>& 7158 ignore (int, int_type); 7159 </pre> 7160 <pre> basic_istream<charT, traits>& 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<charT, traits>& 7180 get (char_type&); 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<charT, traits>& 7190 get (basic_streambuf<charT, traits>&, char_type); 7191 </pre> 7192 <pre> basic_istream<charT, traits>& 7193 get (basic_streambuf<charT, traits>&); 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<charT> 7247::widen() during any other input operation (say, from within 7248a call to num_get<charT>::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<wchar_t> 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& sb); 7416basic_streambuf& operator=(const basic_streambuf& 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& 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& operator=(const basic_streambuf& 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&); // not defined 7462basic_stringbuf& operator=(const basic_stringbuf&); // 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& sb); 7472basic_stringbuf& operator=(const basic_stringbuf& sb); 7473</pre> 7474 7475<p>27.7.1.1, insert after paragraph 4:</p> 7476 7477<pre>basic_stringbuf(const basic_stringbuf& 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& operator=(const basic_stringbuf& 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&); // not defined 7511 basic_filebuf& operator=(const basic_filebuf&); // 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 >= 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 >= 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 && 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() & exceptions()) == 0, returns. ..." 7774<br> 7775 7776to 7777<br> 7778 7779"If (state & 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<int, my_alloc></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<int, my_alloc> v1(a1); 7825 vector<int, my_alloc> 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> — <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 << 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& operator<<(ostream&, 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<char> 7997 ctype_byname<char> 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<T></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<char,InputIterator> 8086 time_get_byname<char,InputIterator> 8087 time_get<wchar_t,OutputIterator> 8088 time_get_byname<wchar_t,OutputIterator> 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& x) const; 8121 const_iterator find(const key_type& 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&) 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<class Facet> 8192 locale::combine(const locale&) 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<charT,traits>* 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<charT,traits>* open( 8330 const char* s, 8331 ios_base::openmode mode ); 8332 8333basic_filebuf<charT,traits>* 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 >= 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<wchar_t>::narrow (wchar_t wc, char dflt) const 8541 { 8542 const unsigned wi = unsigned (wc); 8543 8544 if (wi > UCHAR_MAX) 8545 return typeid (*this) == typeid (ctype<wchar_t>) ? 8546 dflt : do_narrow (wc, dflt); 8547 8548 if (narrow_ [wi] < 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<charT>::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<charT>::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 <cstdlib> 8670#include <iostream> 8671#include <type_traits> 8672#include <new> 8673 8674class A 8675{ 8676 bool alive_; 8677 A(const A&); 8678 A& operator=(const A&); 8679public: 8680 A() : alive_(true) {std::cout << "A()\n";} 8681 ~A() {alive_ = false; std::cout << "~A()\n";} 8682 void use() 8683 { 8684 if (alive_) 8685 std::cout << "A is alive\n"; 8686 else 8687 std::cout << "A is dead\n"; 8688 } 8689}; 8690 8691void deallocate_resource(); 8692 8693// This is the phoenix singleton pattern 8694A& get_resource(bool create = true) 8695{ 8696 static std::aligned_storage<sizeof(A), std::alignment_of<A>::value>::type buf; 8697 static A* a; 8698 if (create) 8699 { 8700 if (a != (A*)&buf) 8701 { 8702 a = ::new (&buf) A; 8703 std::atexit(deallocate_resource); 8704 } 8705 } 8706 else 8707 { 8708 a->~A(); 8709 a = (A*)&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& a = get_resource(); 8722 std::cout << "Using A " << message << "\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<class Y> operator auto_ptr<Y>() 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 <memory> 8790using std::auto_ptr; 8791 8792struct B {}; 8793struct D : B {}; 8794 8795auto_ptr<D> source(); 8796int sink(auto_ptr<B>); 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<D> 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<class Y> auto_ptr(auto_ptr<Y>& 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<B>()); 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<B>(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<B>, std::string); 8863auto_ptr<B> 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<B>::operator auto_ptr_ref<B>()</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<Y> that holds *this and this is another defect since 8881the type of *this is auto_ptr<X> where X might be different from Y. Several 8882library vendors (e.g. SGI) implement auto_ptr_ref<Y> 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<B>(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<class Y> auto_ptr(auto_ptr<Y> const&) 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<class X> 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&) throw(); 8927 template<class Y> auto_ptr(auto_ptr<Y> const&) throw(); 8928 auto_ptr& operator=(auto_ptr&) throw(); 8929 template<class Y> auto_ptr& operator=(auto_ptr<Y>) throw(); 8930 ~auto_ptr() throw(); 8931 8932 // 20.4.5.2 members: 8933 X& operator*() const throw(); 8934 X* operator->() const throw(); 8935 X* get() const throw(); 8936 X* release() throw(); 8937 void reset(X* p=0) throw(); 8938 8939 private: 8940 template<class U> 8941 auto_ptr(U& rhs, typename 8942unspecified_error_on_const_auto_ptr<U>::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<typename T> struct unspecified_error_on_const_auto_ptr; 8953 8954template<typename T> 8955struct unspecified_error_on_const_auto_ptr<auto_ptr<T> const> 8956{ typedef typename auto_ptr<T>::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<X> from const auto_ptr<Y> 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<class Y> auto_ptr(auto_ptr<Y> const& a) throw();</pre> 8978<p> 4 Requires: Y* can be implicitly converted to X*.</p> 8979<p> 5 Effects: Calls const_cast<auto_ptr<Y>&>(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<class Y> auto_ptr& operator=(auto_ptr<Y> 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& 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&) 9000 // implicit X& operator=(X&) 9001 auto_ptr<D> 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<Y> 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<X> 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<Y> is 9022constructed from auto_ptr<X> 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<class Y> auto_ptr(auto_ptr<Y>&&) throw(); 9068template<class Y> auto_ptr& operator=(auto_ptr<Y>&&) 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 <class Y> struct auto_ptr_ref {};</del> 9101 9102 <ins>// exposition only</ins> 9103 <ins>template <class T> struct constant_object;</ins> 9104 9105 <ins>// exposition only</ins> 9106 <ins>template <class T></ins> 9107 <ins>struct cannot_transfer_ownership_from</ins> 9108 <ins>: constant_object<T> {};</ins> 9109 9110 template <class X> 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&) throw(); 9117 template<class Y> auto_ptr(auto_ptr<Y><ins> const</ins>&) throw(); 9118 auto_ptr& operator=(auto_ptr&) throw(); 9119 template<class Y> auto_ptr& operator=(auto_ptr<Y><del>&</del>) throw(); 9120 <del>auto_ptr& operator=(auto_ptr_ref<X> r) throw();</del> 9121 ~auto_ptr() throw(); 9122 9123 // D.9.1.2 members: 9124 X& operator*() const throw(); 9125 X* operator->() 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<X>) throw();</del> 9132 <del>template<class Y> operator auto_ptr_ref<Y>() throw();</del> 9133 <del>template<class Y> operator auto_ptr<Y>() throw();</del> 9134 9135 <ins>// exposition only</ins> 9136 <ins>template<class U></ins> 9137 <ins>auto_ptr(U& rhs, typename cannot_transfer_ownership_from<U>::error = 0);</ins> 9138 }; 9139 9140 template <> class auto_ptr<void> 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<X></tt> from <tt>const auto_ptr<Y></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<class Y> auto_ptr(auto_ptr<Y><ins> const</ins>& 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<auto_ptr<Y>&>(</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<class Y> auto_ptr& operator=(auto_ptr<Y><del>&</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 <string> 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-> 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->m U& if X is mutable, (*a).m pre: (*a).m is well-defined. 9444 otherwise const U& 9445 9446 r->m U& (*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&, 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<C> 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<int, int, int> *p = new plus<int>; 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 <class Arg, class Result> 9555 struct unary_function { 9556 typedef Arg argument_type; 9557 typedef Result result_type; 9558 }; 9559 9560 template <class Arg1, class Arg2, class Result> 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 <class Arg, class Result> 9570 struct unary_function { 9571 typedef Arg argument_type; 9572 typedef Result result_type; 9573 protected: 9574 ~unary_function() {} 9575 }; 9576 9577 template <class Arg1, class Arg2, class Result> 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<vector<int>, 9646list<double> > 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 <class InputIterator, class T> 9688 InputIterator find(InputIterator first, InputIterator last, 9689 const T& 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 && *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<typename T> 9911 struct allocator{ 9912 template<typename T1> 9913 void construct(pointer T1 const& 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<>::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<T, Allocator>::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<class RandomAccessIterator> 10931void stable_sort(RandomAccessIterat or first, RandomAccessIterator last); 10932 10933template<class RandomAccessIterator, class Compare> 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 Ż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 <anti_spam_email2003@yahoo.com> <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 <, >, <=, >= 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<T*> 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<cv T*>(a, b) gives the same results as less<cv 11045void*>(a, b) which gives the same results as less<cv char*>((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<A>(a,b) returns the same value 11052as comp<B>(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<unsigned long>(</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< class IntType = int, UIntType = unsigned int > 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) … x(-1)</tt> 11578<ins>as if executing</ins></p> 11579 11580<blockquote><pre><ins> 11581linear_congruential<unsigned long, 40014, 0, 2147483563> 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… (<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&). 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< class PSRE > 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<>, 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< class Eng, class InIter, class OutIter > 11749void crypto( Eng& 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< class PSRE > 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<> 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<>::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<int> 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<int> 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 < (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 <= max_size() 12321 6 Throws: length_error if n > 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 <,<=,=>, and > ought to be 12389defined in terms of std::less rather than operator<, 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<0>(t) < get<0>(u)) || 12420 (!(bool)(get<0>(u) < get<0>(t)) && ttail < 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 < 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 < f returns false. 12433 Otherwise, the result is defined as: cmp( get<0>(t), get<0>(u)) || 12434 (!cmp(get<0>(u), get<0>(t)) && ttail < 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<U>()(x,y) 12445</p> 12446 12447<p> 12448 otherwise, if T and U are pointer types, returns less<T>()(x,y) 12449</p> 12450 12451<p> 12452 otherwise, returns (bool)(x < 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 <vector> 12525#include <iterator> 12526#include <iostream> 12527 12528struct foo 12529{ 12530 explicit foo(int) {} 12531}; 12532 12533int main() 12534{ 12535 std::vector<int> v_int; 12536 std::vector<foo> v_foo1(v_int.begin(), v_int.end()); 12537 std::vector<foo> v_foo2((std::istream_iterator<int>(std::cin)), 12538 std::istream_iterator<int>()); 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 <clocale>, 12564<cstddef>, <cstdio>, <cstdlib>, <cstring>, <ctime>, 12565or <cwchar>." This is consistent with the C standard. 12566</p> 12567<p> 12568However, Table 95 in C.2 fails to mention <clocale> and <cstdlib>. 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 <clocale> and <cstdlib> 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<> 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>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<bool></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<bool></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<bool>::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 <> class numeric_limits<bool> { 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><cst<ins>d</ins>bool></tt> by including the header <tt><cstdbool></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><cstdint></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<class charT, class traits, class Allocator> 13055 basic_string<charT,traits,Allocator> operator+( 13056 const charT* lhs, 13057 const basic_string<charT,traits,Allocator>& rhs 13058 ); 13059</pre> 13060<p> 13061Returns: <tt>basic_string<charT,traits,Allocator>(lhs) + rhs</tt>. 13062</p> 13063</blockquote> 13064<p> 13065That leads to the basic_string<charT,traits,Allocator>(lhs, Allocator()) call. 13066Obviously, the right requirement is: 13067</p> 13068<blockquote><p> 13069Returns: <tt>basic_string<charT,traits,Allocator>(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& pool; 13100 13101 public: 13102 explicit stl_allocator(mem_pool& mp) : pool(mp) {} 13103 stl_allocator(const stl_allocator& sa) : pool(sa.pool) {} 13104 template <class U> 13105 stl_allocator(const stl_allocator<U>& sa) : pool(sa.get_pool()) {} 13106 ~stl_allocator() {} 13107 13108 pointer allocate(size_type n, std::allocator<void>::const_pointer = 0) 13109 { 13110 return (n!=0) ? static_cast<pointer>(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<char, char_traits<char>, stl_allocator<char> > 13126 tl_string; 13127mem_pool mp; 13128tl_string s1("abc", stl_allocator<int>(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<mem_pool*>(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&) 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<> and requires the implementation provide two explicit 13245specializations: char_traits<char> and char_traits<wchar_t>. 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&</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<U>::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<void*>(&*i)) 13728 typename iterator_traits<ForwardIterator>::value_type (x) 13729 13730 </pre> 13731 <p> 13732 13733This expression is ill-formed when the type of the subexpression 13734<code>&*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 <InputIterator InIter, OutputIterator OutIter> 13769requires ExplicitConvertible<HasDereference<OutIter::reference>::result, 13770 OutIter::value_type&> 13771 && Convertible<OutIter::value_type*, void*> 13772 && ExplicitConvertible<OutIter::value_type, InIter::reference> 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& outRef = static_cast<value_type&>(*result++); 13782 ::new (static_cast<void*>(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&, this 13799definition probably won't compile. Lifting this limitation while 13800allowing value_type to have an overloaded operator& 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<ForwardIterator>::pointer pointer; 13855typedef typename iterator_traits<ForwardIterator>::value_type value_type; 13856 13857for (; first != last; ++result, ++first) 13858 new (static_cast<void*>(const_cast<pointer>(&*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<ForwardIterator>::pointer pointer; 13871typedef typename iterator_traits<ForwardIterator>::value_type value_type; 13872 13873for (; first != last; ++result, ++first) 13874 new (static_cast<void*>(const_cast<pointer>(&*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<ForwardIterator>::pointer pointer; 13887typedef typename iterator_traits<ForwardIterator>::value_type value_type; 13888 13889for (; n--; ++first) 13890 new (static_cast<void*>(const_cast<pointer>(&*first)) 13891 value_type (*x); 13892 13893 </pre> 13894 <p> 13895 13896In addition, since there is no partial specialization for 13897<code>iterator_traits<volatile T*></code> I propose to add one 13898to parallel such specialization for <const T*>. 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<class T> struct iterator_traits<volatile T*> { 13910typedef ptrdiff_t difference_type; 13911typedef T value_type; 13912typedef volatile T* pointer; 13913typedef volatile T& 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< typename T> 13989T power( T x, int n ); 13990// requires: n >=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&</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&</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&</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<T, N> 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< typename T > 14196 class array< T, 0 > { 14197 14198 .... 14199 14200 iterator begin() 14201 { return iterator( reinterpret_cast< T * >( 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< typename T > 14214 class array< T, 0 > { 14215 14216 T t; 14217 14218 iterator begin() 14219 { return iterator( &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<T*>(0); 14233</pre></blockquote> 14234<p> 14235In this case the value would be unique to the type array<T, 0> but not 14236to the objects (all objects of type array<T, 0> 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 &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&) 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 <array> 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&)</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<array<T, N> >::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()->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()->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()->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()->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&); // 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<charT,traits,Allocator>& str ); 14739 14740basic_string(const basic_string<charT,traits,Allocator>& str , 14741 size_type pos , size_type n = npos, 14742 const Allocator& 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&</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 <cctype>, 14813<cwctype>, <cstring>, <cwchar>, and <cstdlib> (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><array></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<></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<></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>&& 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& 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 <class Y> bool operator<(weak_ptr<Y> const&) const = delete; 15669template <class Y> bool operator<=(weak_ptr<Y> const&) const = delete; 15670template <class Y> bool operator>(weak_ptr<Y> const&) const = delete; 15671template <class Y> bool operator>=(weak_ptr<Y> const&) 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&</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<class Function2> <del>bool</del> <ins>void</ins> operator==(const function<Function2>&); 15711 template<class Function2> <del>bool</del> <ins>void</ins> operator!=(const function<Function2>&); 15712}; 15713</pre></blockquote> 15714 15715<p> 15716Change 20.7.15.2 [func.wrap.func] 15717</p> 15718 15719<blockquote><pre>template<class Function2> <del>bool</del> <ins>void</ins> operator==(const function<Function2>&); 15720template<class Function2> <del>bool</del> <ins>void</ins> operator!=(const function<Function2>&); 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<BidirectionalIterator></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 <class iterator, class charT, class traits> 15845bool regex_search(iterator first, iterator last, 15846 const basic_regex<charT, traits>& 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 <class BidirectionalIterator, class charT, class traits> 15859bool regex_search(BidirectionalIterator first, BidirectionalIterator last, 15860 const basic_regex<charT, traits>& 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 <class <del>iterator</del> <ins>BidirectionalIterator</ins>, class charT, class traits> 15873 bool regex_search(<del>iterator</del> <ins>BidirectionalIterator</ins> first, <del>iterator</del> <ins>BidirectionalIterator</ins> last, 15874 const basic_regex<charT, traits>& 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<<del>iterator</del> 15881<ins>BidirectionalIterator</ins>></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 &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>&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 <std::size_t N> 15963 regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b, 15964 const regex_type& re, 15965 const int (&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>[&submatches, &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 <std::size_t N> 16009 regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b, 16010 const regex_type& re, 16011 const int (&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>[&submatches, &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><random></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 <class UIntType, size_t w<del>}</del>, size_t s, size_t r> 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 <cstddef> 16203 } 16204 16205 static void g() 16206 { 16207# include <stddef.h> 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><functional></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<class Function1, class Function2> 16278void operator==(const function<Function1>&, const function<Function2>&); 16279template<class Function1, class Function2> 16280void operator!=(const function<Function1>&, const function<Function2>&); 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><functional></tt> synopsis (20.7 [function.objects]) 16296</p> 16297 16298<blockquote><pre><del>template<class Function1, class Function2> 16299void operator==(const function<Function1>&, const function<Function2>&); 16300template<class Function1, class Function2> 16301void operator!=(const function<Function1>&, const function<Function2>&);</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. Stroustrup (Section D.4.2.3, pg. 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>>i>>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 >> 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<numpunct<charT> >(<i>loc</i>).grouping()</code>. If they are not consistent then <code>ios_base::failbit</code> is assigned to <code><i>err</i></code>. <ins>Otherwise, the value that was converted in stage 2 is stored in <code><i>val</i></code> and <code>ios_base::goodbit</code> is stored in <code><i>err</i></code>.</ins> 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<wchar_t></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() > 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). — <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<BidirectionalIterator></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><BidirectionalIterator<ins>, charT, traits</ins>></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 <<i>snip</i>> 16955// match_results comparisons 16956 template <class BidirectionalIterator, class Allocator> 16957 bool operator== (const match_results<BidirectionalIterator, Allocator>& m1, 16958 const match_results<BidirectionalIterator, Allocator>& m2); 16959 template <class BidirectionalIterator, class Allocator> 16960 bool operator!= (const match_results<BidirectionalIterator, Allocator>& m1, 16961 const match_results<BidirectionalIterator, Allocator>& 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<class BidirectionalIterator, class Allocator> 17000 bool operator==(const match_results<BidirectionalIterator, Allocator>& m1, 17001 const match_results<BidirectionalIterator, Allocator>& 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<class BidirectionalIterator, class Allocator> 17012 bool operator!=(const match_results<BidirectionalIterator, Allocator>& m1, 17013 const match_results<BidirectionalIterator, Allocator>& 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<class BidirectionalIterator, class Allocator> 17024 void swap(match_results<BidirectionalIterator, Allocator>& m1, 17025 match_results<BidirectionalIterator, Allocator>& 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><system_error></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 <system_error> 17156#include <stdexcept> 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><system_error></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 > -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 & 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| <= 1</tt>, not <tt>x >= 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&</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>&a[i+j] == &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>&a[i] != &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 <class T> struct is_pod; 17644</pre></blockquote> 17645 17646<p> 17647add a new one: 17648</p> 17649 17650<blockquote><pre>template <class T> 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 <class T> 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<class I, class E, class S> 17694struct codecvt : std::codecvt<I, E, S> 17695{ 17696 ~codecvt() 17697 { } 17698}; 17699 17700void main() 17701{ 17702 std::wstring_convert<codecvt<wchar_t, char, std::mbstate_t> > compiles_ok; 17703 17704 std::wstring_convert<std::codecvt<wchar_t, char, std::mbstate_t> > 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<X::result_type>(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<UintType>(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<X::result_type>(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<X::result_type>(</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 <typename T> 17977struct is_seed_seq { static const bool value = false; } 17978</pre></blockquote> 17979<p>and the specialization</p> 17980<blockquote><pre>template <> 17981struct is_seed_seq<seed_seq> { 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 < n <= 18232numeric_limits<IntType>::max() + 1</tt>" makes the implementation 18233unnecessarily complicated, "<tt>0 < n <= numeric_limits<IntType>::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 > 0 be replaced with 0 < 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<double></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>> 0</del></tt> 18322<ins>such that <tt>0 < n <= numeric_limits<IntType>::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 <class InputIteratorB, class InputIteratorW> 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<result_type></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 >= 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<class D, class T> D* get_deleter(shared_ptr<T> const& 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><memory></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<class D, class T> const D* get_deleter(shared_ptr<T> const& 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 <class D, class T> D get_deleter(shared_ptr<T> const&); 18592template <class D, class T> bool has_deleter(shared_ptr<T> const&); 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<test>::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 & ) {} 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<bool></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<bool> members take const bool& 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<bool>, 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<bool>. 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<bool> 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 <class InputIterator, class ForwardIterator> 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<void*>(&*result)) 18954 typename iterator_traits<ForwardIterator>::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<typename... _Args> 19055void 19056push(_Args&&... __args) 19057 { c.push_back(std::forward<_Args>(__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& x) { c.push_back(x); }</del> 19072<del>void push(value_type&& x) { c.push_back(std::move(x)); }</del> 19073<ins>template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(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& x) { c.push_back(x); }</del> 19081<del>void push(value_type&& x) { c.push_back(std::move(x)); }</del> 19082<ins>template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(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& 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<class... Args></ins> void push(<del>value_type</del> <ins>Args</ins>&&<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<Args></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& x) { c.push_back(x); }</del> 19118<del>void push(value_type&& x) { c.push_back(std::move(x)); }</del> 19119<ins>template<class... Args> void push(Args&&... args) { c.push_back(std::forward<Args>(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&& x); 19146</pre></blockquote> 19147 19148<p> 19149instead of: 19150</p> 19151 19152<blockquote><pre>iterator insert(const_iterator position, T&& 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& x); 19167<ins>iterator insert(const_iterator position, T&& x);</ins> 19168void insert(const_iterator position, size_type n, const T& x); 19169<del>void insert(const_iterator position, size_type n, T&& 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 <class... Args> pair<iterator, bool> emplace(Args&&... args); 19274template <class... Args> iterator emplace(const_iterator position, Args&&... 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<B::iterator, B::iterator></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<iterator, iterator></tt>, <tt>equal_range</tt> were to 19353return <tt>pair<local_iterator, local_iterator></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<<ins>local_</ins>iterator,<ins>local_</ins>iterator>; pair<const_<ins>local_</ins>iterator,const_<ins>local_</ins>iterator></tt> for <tt>const b</tt>.</td> 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 Θ<tt>(b.count(k))</tt>. Worst case Θ<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 <vector> 19408 19409int main() 19410{ 19411 std::vector<char *> 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<_Tp>::construct(_Tp*, 19422_Args&& ...) [with _Args = int, _Tp = char*]': 19423.../include/c++/4.3.0/bits/stl_vector.h:707: instantiated from 'void 19424std::vector<_Tp, _Alloc>::push_back(_Args&& ...) [with 19425_Args = int, _Tp = char*, _Alloc = std::allocator<char*>]' 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 <utility> 19450 19451int main() 19452{ 19453 std::pair<char *, char *> 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& x);</ins> 19583<ins>void push_front(T&& x);</ins> 19584<ins>void push_back(const T& x);</ins> 19585<ins>void push_back(T&& x);</ins> 19586template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args); 19587template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... 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& x);</ins> 19595<ins>void push_front(T&& x);</ins> 19596<ins>void push_back(const T& x);</ins> 19597<ins>void push_back(T&& x);</ins> 19598template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args); 19599template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... 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& x);</ins> 19607<ins>void push_front(T&& x);</ins> 19608<ins>void push_back(const T& x);</ins> 19609<ins>void push_back(T&& x);</ins> 19610template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args); 19611template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... 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& x);</ins> 19619<ins>void push_front(T&& x);</ins> 19620<ins>void push_back(const T& x);</ins> 19621<ins>void push_back(T&& x);</ins> 19622template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_front(Args&&... args); 19623template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... 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& x);</ins> 19631<ins>void push_back(T&& x);</ins> 19632template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... 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& x);</ins> 19640<ins>void push_back(T&& x);</ins> 19641template <class... Args> <ins>requires Constructible<T, Args&&...></ins> void push_back(Args&&... 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 <class Mutex> 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 <class Gen> 19803seed(Gen&); 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&)</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 <class RealType = double> 20067class piecewise_constant_distribution 20068{ 20069public: 20070 ... 20071 vector<double> <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<double> <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<class _Fn> 20100 discrete_distribution(result_type _Count, double _Low, double _High, 20101 _Fn& _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<double></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&&</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& parm); 20186</pre></blockquote> 20187 20188<p> 20189insert: 20190</p> 20191 20192 20193<blockquote><pre>template<typename Func> 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<typename Func> 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 > 0, the relation <tt><i>x</i><sub><i>min</i></sub></tt> < <tt><i>x</i><sub><i>max</i></sub></tt> shall hold, and for all sample values 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 ≥ 0, and 0 < 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& parm); 20262</pre></blockquote> 20263 20264<p> 20265insert: 20266</p> 20267 20268 20269<blockquote><pre>template<Callable<auto, double> Func> 20270 requires Convertible<Func::result_type, double> 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<Callable<auto, double> Func> 20281 requires Convertible<Func::result_type, double> 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 > 0, the relation <tt><i>x</i><sub><i>min</i></sub></tt> < <tt><i>x</i><sub><i>max</i></sub></tt> shall hold, and for all sample values 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 ≥ 0, and 0 < 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<class _Fn> 20347 piecewise_constant_distribution(size_t _Count, 20348 _Ty _Low, _Ty _High, _Fn& _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<double></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& parm); 20406</pre></blockquote> 20407<p> 20408insert: 20409</p> 20410<blockquote><pre>template<typename Func> 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<typename Func> 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> < <tt><i>x<sub>max</sub></i></tt>, and 204420 < 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>ρ<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& parm); 20508</pre></blockquote> 20509<p> 20510insert: 20511</p> 20512<blockquote><pre>template<Callable<auto, RealType> Func> 20513 requires Convertible<Func::result_type, double> 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<Callable<auto, RealType> Func> 20526 requires Convertible<Func::result_type, double> 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> < <tt><i>x<sub>max</sub></i></tt>, and 205430 < 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>ρ<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<uint_fast64_t, 48, 5, 12> 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<ranlux48_base, 389, 11> 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 > 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<minstd_rand0, 256> 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 < 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<class InputIterator> 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<InputIterator>::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<class InputIterator<del>, 21155 size_t u = numeric_limits<iterator_traits<InputIterator>::value_type>::digits</del>> 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<InputIterator>::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 = ∑<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$ < 32) 21179 v.push_back($n$); 21180for( ; $n$ > 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<void></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<></tt> helper in 20.3.3 [forward]. I believe this change makes it no 21254longer possible to instantiate <tt>identity<void></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<void></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 <class T> struct identity : unary_function<T, T> { 21308 const T& operator()(const T&) 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 <class T> 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 <class T> struct identity { 21350 typedef T type; 21351 21352 <ins>requires ReferentType<T></ins> 21353 const T& operator()(const T& x) const; 21354 }; 21355</pre></blockquote> 21356<p>...</p> 21357<blockquote><pre> <ins>requires ReferentType<T></ins> 21358 const T& operator()(const T& 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&</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<<</tt> and <tt>operator>></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<char></code> 21747 and (<code>char_traits<wchar_t></code>). However, there are actually 21748 four specializations provided, i.e. in addition to the two above also 21749 <code>char_traits<char16_t></code> and <code>char_traits<char32_t></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< char16/32_t ></tt> 21760should also be added to <tt><ios_fwd></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><iosfwd></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<charT></code>, 21816 and four explicit specializations of it, <code>char_traits<char></code>, 21817 <code>char_traits<char16_t></code>, <code>char_traits<char32_t></code>, and 21818 <code>char_traits<wchar_t></code>, all of which appear in the header 21819 <string> 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><iosfwd></tt> synopsis</b> 21841</p> 21842<pre>namespace std { 21843 template<class charT> class char_traits; 21844 template<> class char_traits<char>; 21845 <ins>template<> class char_traits<char16_t>;</ins> 21846 <ins>template<> class char_traits<char32_t>;</ins> 21847 template<> class char_traits<wchar_t>; 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& get_generic_category();</del> 21988<del>const error_category& get_system_category();</del> 21989 21990<del>static</del> <ins>extern</ins> const error_category<del>&</del><ins>* const</ins> generic_category<del> = get_generic_category()</del>; 21991<del>static</del> <ins>extern</ins> const error_category<del>&</del><ins>* const</ins> <del>native_category</del> system_category<del> = get_system_category()</del>; 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>&</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>&</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>&</del><ins>*</ins> cat); 22050 ... 22051 void assign(int val, const error_category<del>&</del><ins>*</ins> cat); 22052 ... 22053 const error_category<del>&</del><ins>*</ins> category() const; 22054 ... 22055private: 22056 int val_; // exposition only 22057 const error_category<del>&</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>&</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>&</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>&</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>&</del><ins>*</ins> cat); 22118 ... 22119 void assign(int val, const error_category<del>&</del><ins>*</ins> cat); 22120 ... 22121 const error_category<del>&</del><ins>*</ins> category() const; 22122 ... 22123private: 22124 int val_; // exposition only 22125 const error_category<del>&</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>&</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>&</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>&</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()-></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()->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& what_arg); 22194 system_error(error_code ec); 22195 system_error(int ev, const error_category<del>&</del><ins>*</ins> ecat, 22196 const string& what_arg); 22197 system_error(int ev, const error_category<del>&</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>&</del><ins>*</ins> ecat, const string& 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>&</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><initializer_list> <concept> <iterator_concepts> 22273</pre></blockquote> 22274<p> 22275<tt><iterator_concepts></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><functional></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><initializer_list></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 == &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<int, huge_thingy></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<T,Allocator>&& x); 22492void splice(list<T,Allocator>&& x, const_iterator i); 22493void splice(list<T,Allocator>&& 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<T,Allocator>&& x); 22503void splice(const_iterator position, list<T,Allocator>&& x, const_iterator i); 22504void splice(const_iterator position, list<T,Allocator>&& 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<iterator, bool> insert(node_ptr&& nd); 22600iterator insert(const_iterator p, node_ptr&& 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&& nd); 22611iterator insert(const_iterator p, node_ptr&& 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<T, C1, A></tt> 22654to <tt>set<T, C2, A></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->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 <class T1, class T2 <ins>= T1</ins>> 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 <class T1, class T2 <ins>= T1</ins>> 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><stdint.h></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><cstdint></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><cstdint></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><cstdint></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><cstdint></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<root_class></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< class T > struct direct_base_class; 23085template< class T > struct direct_derived_class; 23086template< class T > 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< class T > 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< class T > 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< class T > 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<int> 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<int, 3> 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<typename T, typename... Args> 23170inline array<T, sizeof...(Args)> 23171make_array(Args&&... args) 23172{ return { std::forward<Args>(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<T>(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<ValueType T, ValueType... Args> 23199requires Convertible<Args, T>... 23200array<T, sizeof...(Args)> make_array(Args&&... 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<double>(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<double>(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<Args>(args)... } 23246</pre></blockquote> 23247 23248<p> 23249needs to be replaced by 23250</p> 23251 23252<blockquote><pre>{ static_cast<T>(std::forward<Args>(args))... } 23253</pre></blockquote> 23254 23255<p> 23256which is safe, because we already ensure convertibility via the 23257element-wise <tt>Convertible<Args, T></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<typename... Args> 23270array<typename decay<typename common_type<Args...>::type>::type, 23271sizeof...(Args)> 23272make_array(Args&&... 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<Vi, Ti&&></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<typename... T> { 23293 typename type = typename decay<typename common_type<T...>::type>::type; 23294} 23295</pre></blockquote> 23296 23297<p> 23298where <tt>C</tt> is identical to <tt>DC<Args...>::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<ReferentType... Args> 23316requires ValueType<C> && IdentityOf<Args> && Constructible<C, Args&&>... 23317array<C, sizeof...(Args)> 23318make_array(Args&&... 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<ReferentType... Args> 23335requires ValueType<C> && IdentityOf<Args> && Constructible<C, Args&&>... 23336array<C, sizeof...(Args)> 23337make_array(Args&&... args);</ins> 23338</pre> 23339 23340<blockquote> 23341<p><ins> 23342Let <tt>C</tt> be <tt>decay<common_type<Args...>::type>::type</tt>. 23343</ins></p> 23344<p> 23345<ins><i>Returns:</i> an <tt>array<C, sizeof...(Args)></tt> initialized with 23346<tt>{ static_cast<C>(std::forward<Args>(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<class... Args> 23400 array<<i>CT</i>, sizeof...(Args)> 23401 make_array(Args&&... 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<class... Args> 23418array<<i>CT</i>, sizeof...(Args)> 23419make_array(Args&&... args) 23420</ins></pre> 23421 23422<blockquote> 23423<p> 23424<ins>Let <i>CT</i> be <tt>decay<common_type<Args...>::type>::type</tt>.</ins> 23425</p> 23426<p> 23427<ins><i>Returns:</i> An <tt>array<<i>CT</i>, sizeof...(Args)></tt> initialized with <tt>{ 23428static_cast<<i>CT</i>>(std::forward<Args>(args))... }</tt>.</ins> 23429</p> 23430 23431<p><ins> 23432[<i>Example:</i> 23433</ins></p> 23434<blockquote><pre><ins> 23435int i = 0; int& 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<double, 4> 23443</ins></pre></blockquote> 23444 23445<p><ins> 23446—<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 > 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<T>::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 < 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><cstdint></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<T>::type</tt> 24062 must be one of the signed integer types as defined in 3.9.1. Ditto for 24063 <tt>make_unsigned<T>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 <class T> 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 <class T> 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) && 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> </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> </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->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<result_type>::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 < m</code> and <code>c < 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<RandomAccessIterator>::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<double></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& parm); 24371</pre></blockquote> 24372 24373<p> 24374insert 24375</p> 24376 24377<blockquote><pre>discrete_distribution(initializer_list<double> 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<double> 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<double></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&&</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& parm); 24437</pre></blockquote> 24438 24439<p> 24440insert 24441</p> 24442 24443<blockquote><pre>template<typename Func> 24444piecewise_constant_distribution(initializer_list<RealType> 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<typename Func> 24456piecewise_constant_distribution(initializer_list<RealType> 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 < 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 > 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> < 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>ρ<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& parm); 24547</pre></blockquote> 24548 24549<p> 24550insert 24551</p> 24552 24553<blockquote><pre>template<Callable<auto, RealType> Func> 24554 requires Convertible<Func::result_type, double> 24555piecewise_constant_distribution(initializer_list<RealType> 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<Callable<auto, RealType> Func> 24567 requires Convertible<Func::result_type, double> 24568piecewise_constant_distribution(initializer_list<RealType> 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 < 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 > 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> < 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>ρ<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 <class InputIterator, class ForwardIterator> 24724ForwardIterator 24725uninitialized_copy (InputIterator first, InputIterator last, ForwardIterator res) 24726{ 24727 typedef iterator_traits<ForwardIterator>::value_type ValueType; 24728 24729 ForwardIterator start = res; 24730 24731 try { 24732 for (; first != last; ++first, ++res) 24733 ::new (&*res) ValueType (*first); 24734 } 24735 catch (...) { 24736 for (; start != res; --start) 24737 (&*start)->~ValueType (); 24738 throw; 24739 } 24740 return res; 24741} 24742 24743struct SomeType { 24744 SomeType (const SomeType&) <ins>throw ()</ins>; 24745}</pre> 24746 </blockquote> 24747 <p> 24748 24749compilers are able to emit the following efficient specialization 24750of <tt>std::uninitialized_copy<const SomeType*, SomeType*></tt> 24751(note that the <tt>catch</tt> block has been optimized away): 24752 24753 </p> 24754 <blockquote> 24755 <pre>template <> 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->~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<T>::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<T*></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<T*></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*&, <ins>const</ins> void*, 25060 memory_order, memory_order) volatile; 25061 bool compare_exchange( <ins>const</ins> void*&, <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 <memory> 25168#include <cassert> 25169 25170struct A { }; 25171struct B : A { }; 25172 25173int main() 25174{ 25175 std::shared_ptr<A> pa(new A); 25176 std::shared_ptr<B> pb(new B); 25177 std::swap<A>(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<class T> void swap( shared_ptr<T> & a, shared_ptr<T> && b ); 25193</pre></blockquote> 25194 25195<p> 25196silently converting the second argument from <tt>shared_ptr<B></tt> to 25197<tt>shared_ptr<A></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<A> v = ...; 25214... 25215swap(v, vector<A>(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>Ο</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>Ο</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<T. Alloc>&& 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<T,Allocator>&& 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>&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>Ο</i>(1)</del> <ins><i>Ο</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<T,Allocator>&& 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>Ο</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 &</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<></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<E></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<E></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 <DefaultConstructible T> 26007requires MoveConstructible<T> 26008void generate_and_do_3(T a) { 26009 std::initializer_list<T> list{T(), std::move(a), T()}; 26010 ... 26011} 26012 26013void do_more(); 26014void do_more_or_less(); 26015 26016template <DefaultConstructible T> 26017requires MoveConstructible<T> 26018void more_generate_3() { 26019 do_more(); 26020 generate_and_do_3(T()); 26021} 26022 26023template <DefaultConstructible T> 26024requires MoveConstructible<T> 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&&){} // 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<Abstract>(); 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<ObjectType T> 26059class ExtContainer { 26060public: 26061 requires ValueType<T> 26062 ExtContainer(std::initializer_list<T>); 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><initializer_list></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& operator=(atomic_bool const&) = delete; 26116atomic_bool& 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& operator=(atomic_bool const&) <ins>volatile</ins> = delete; 26172atomic_itype& operator=(atomic_itype const&) <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 <<del>class</del> <ins>ValueType</ins> T, size_t N> 26225<ins>requires Swappable<T></ins> 26226void swap(T (&a)[N], T (&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<Iter, const T&></tt> 26274</p> 26275 26276<p> 26277and 26278</p> 26279 26280<p> 26281(B) <tt>OutputIterator<OutIter, InIter::reference> && OutputIterator<OutIter, const T&></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<ForwardIterator Iter, class T> 26309 requires OutputIterator<Iter, Iter::reference> 26310 && OutputIterator<Iter, const T&> 26311 && HasEqualTo<Iter::value_type, T> 26312 void replace(Iter first, Iter last, 26313 const T& old_value, const T& new_value); 26314 26315template<ForwardIterator Iter, Predicate<auto, Iter::value_type> Pred, class T> 26316 requires OutputIterator<Iter, Iter::reference> 26317 && OutputIterator<Iter, const T&> 26318 && CopyConstructible<Pred> 26319 void replace_if(Iter first, Iter last, 26320 Pred pred, const T& 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<InputIterator InIter, typename OutIter, class T> 26334 requires OutputIterator<OutIter, InIter::reference> 26335 && OutputIterator<OutIter, const T&> 26336 && HasEqualTo<InIter::value_type, T> 26337 OutIter replace_copy(InIter first, InIter last, 26338 OutIter result, 26339 const T& old_value, const T& new_value); 26340 26341template<InputIterator InIter, typename OutIter, 26342 Predicate<auto, InIter::value_type> Pred, class T> 26343 requires OutputIterator<OutIter, InIter::reference> 26344 && OutputIterator<OutIter, const T&> 26345 && CopyConstructible<Pred> 26346 OutIter replace_copy_if(InIter first, InIter last, 26347 OutIter result, 26348 Pred pred, const T& 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<auto, Iter::value_type> 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<ForwardIterator Iter> 26403 requires OutputIterator<Iter, Iter::reference> 26404 && EqualityComparable<Iter::value_type> 26405 Iter unique(Iter first, Iter last); 26406 26407template<ForwardIterator Iter, EquivalenceRelation<auto, Iter::value_type> Pred> 26408 requires OutputIterator<Iter, RvalueOf<Iter::reference>::type> 26409 && CopyConstructible<Pred> 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<class U , class V> 26445requires HasAssign<T1, const U&> && HasAssign<T2, const V&> 26446pair& operator=(const pair<U , V>& p); 26447</pre> 26448</li> 26449<li> 26450<pre>requires MoveAssignable<T1> && MoveAssignable<T2> pair& operator=(pair&& p ); 26451</pre> 26452</li> 26453<li> 26454<pre>template<class U , class V> 26455requires HasAssign<T1, RvalueOf<U>::type> && HasAssign<T2, RvalueOf<V>::type> 26456pair& operator=(pair<U , V>&& 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<T1> && MoveAssignable<T2> pair& operator=(pair&& 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 <class... UTypes> 26599requires HasAssign<Types, const UTypes&>... 26600<ins>tuple& operator=(const pair<UTypes...>&);</ins> 26601 26602template <class... UTypes> 26603requires HasAssign<Types, RvalueOf<UTypes>::type>... 26604<ins>tuple& operator=(pair<UTypes...>&&);</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<Types>... tuple& operator=(tuple&& 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 <<del>class</del> <ins>Swappable</ins>... Types> 26691void swap(tuple<Types...>& x, tuple<Types...>& 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<Types>...</ins>void swap(tuple&); 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<T> void remove(const T& 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<T></del> <ins>HasEqualTo<T, T></ins> void remove(const T& 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<float></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<FP>::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<float></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<struct-with-padding>::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<</tt> 27269are declared as 27270</p> 27271 27272<blockquote><pre>template<class... TTypes, class... UTypes> 27273 requires EqualityComparable<TTypes, UTypes>... 27274 bool operator==(const tuple<TTypes...>& t, const tuple<UTypes...>& u); 27275</pre></blockquote> 27276 27277<p> 27278and 27279</p> 27280 27281<blockquote><pre>template<class... TTypes, class... UTypes> 27282 requires LessThanComparable<TTypes, UTypes>... 27283 bool operator<(const tuple<TTypes...>& t, const tuple<UTypes...>& 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<()</tt> should also require 27290</p> 27291 27292<blockquote><pre>LessThanComparable<UTypes, TTypes>... // (note the order) 27293</pre></blockquote> 27294 27295<p> 27296since the algorithm for <tt>tuple::operator<</tt> is the following (pseudo-code) 27297</p> 27298 27299<blockquote><pre>for (size_t N = 0; N < sizeof...(TTypes); ++N) { 27300 if (get<N>(t) < get<N>(u) return true; 27301 else if ((get<N>(u) < get<N>(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<class... TTypes, class... UTypes> 27328 requires <del>EqualityComparable</del><ins>HasEqualTo</ins><TTypes, UTypes>... 27329 bool operator==(const tuple<TTypes...>&, const tuple<UTypes...>&); 27330 27331template<class... TTypes, class... UTypes> 27332 requires <del>LessThanComparable</del><ins>HasLess</ins><TTypes, UTypes>... <ins>&& HasLess<UTypes, TTypes>...</ins> 27333 bool operator<(const tuple<TTypes...>&, const tuple<UTypes...>&); 27334 27335template<class... TTypes, class... UTypes> 27336 requires <del>EqualityComparable</del><ins>HasEqualTo</ins><TTypes, UTypes>... 27337 bool operator!=(const tuple<TTypes...>&, const tuple<UTypes...>&); 27338 27339template<class... TTypes, class... UTypes> 27340 requires <del>LessThanComparable</del><ins>HasLess</ins><<del>U</del><ins>T</ins>Types, <del>T</del><ins>U</ins>Types>... <ins>&& HasLess<UTypes, TTypes>...</ins> 27341 bool operator>(const tuple<TTypes...>&, const tuple<UTypes...>&); 27342 27343template<class... TTypes, class... UTypes> 27344 requires <del>LessThanComparable</del><ins>HasLess</ins><<del>U</del><ins>T</ins>Types, <del>T</del><ins>U</ins>Types>... <ins>&& HasLess<UTypes, TTypes>...</ins> 27345 bool operator<=(const tuple<TTypes...>&, const tuple<UTypes...>&); 27346 27347template<class... TTypes, class... UTypes> 27348 requires <del>LessThanComparable</del><ins>HasLess</ins><TTypes, UTypes>... <ins>&& HasLess<UTypes, TTypes>...</ins> 27349 bool operator>=(const tuple<TTypes...>&, const tuple<UTypes...>&); 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<char,MAX_PATH> path; 27393 set_path( path.data() ); // error 27394 set_path( &(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 (&)[3]); 27406 }; 27407 27408 const std::array<double,3> 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 <typename T> 27455 void func(T& container1, T& 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<typename T> 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<size_t N, ValueType T> 27527struct array 27528{ 27529 T elems[N]; 27530 27531// fantasy code starts here 27532 27533// crazy decltype version for grins only 27534//requires True<(N>0)> 27535//explict operator decltype(elems) & () { return elems; } 27536 27537// conversion to lvalue ref 27538requires True<(N>0)> 27539explict operator T(&)[N] () & { return elems; } 27540 27541// conversion to const lvalue ref 27542requires True<(N>0)> 27543explict operator const T(&)[N] () const & { return elems; } 27544 27545// conversion to rvalue ref using ref qualifiers 27546requires True<(N>0)> 27547explict operator T(&&)[N] () && { 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 (&)[3]); 27574}; 27575 27576void sink(double*); 27577 27578const std::array<double, 3> 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 &&</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 & c_array() &; 27670c_array_type && c_array() &&; 27671const c_array_type & c_array() const &; 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 & c_array() &; 27684c_array_type && c_array() &&; 27685const c_array_type & c_array() const &; 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& 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& 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& 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><cstdint></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><cstdint></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><cstdint></tt> 28068typedef be a typedef for some fundamental integer type. After all, 28069<tt><cstdint></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>&</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><cstdatomic></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<bool></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<bool></tt> is supposed to be derived 28242from <tt>atomic_bool</tt> (and otherwise follow the <tt>atomic<integral></tt> interface), 28243though I think the current wording doesn't support this. I raised this 28244point along with <tt>atomic<floating-point></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<integral></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<integral></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<bool></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() < 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() < 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() < 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<typename ToDuration::rep, Rep, intmax_t>::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 <class _Duration, class _Rep, bool = __is_duration<_Rep>::value> 28502struct __duration_divide_result 28503{ 28504}; 28505 28506template <class _Duration, class _Rep2, 28507 bool = is_convertible<_Rep2, 28508 typename common_type<typename _Duration::rep, _Rep2>::type>::value> 28509struct __duration_divide_imp 28510{ 28511}; 28512 28513template <class _Rep1, class _Period, class _Rep2> 28514struct __duration_divide_imp<duration<_Rep1, _Period>, _Rep2, true> 28515{ 28516 typedef duration<typename common_type<_Rep1, _Rep2>::type, _Period> type; 28517}; 28518 28519template <class _Rep1, class _Period, class _Rep2> 28520struct __duration_divide_result<duration<_Rep1, _Period>, _Rep2, false> 28521 : __duration_divide_imp<duration<_Rep1, _Period>, _Rep2> 28522{ 28523}; 28524 28525template <class _Rep1, class _Period, class _Rep2> 28526inline 28527typename __duration_divide_result<duration<_Rep1, _Period>, _Rep2>::type 28528operator/(const duration<_Rep1, _Period>& __d, const _Rep2& __s) 28529{ 28530 typedef typename common_type<_Rep1, _Rep2>::type _Cr; 28531 duration<_Cr, _Period> __r = __d; 28532 __r /= static_cast<_Cr>(__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<typename Duration::rep, Rep2>::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 <class Clock, class Duration> 28671void do_until(const std::chrono::<b>time_point</b><Clock, Duration>& t) 28672{ 28673 typename Clock::<b>time_point now</b> = Clock::now(); 28674 if (t > now) 28675 { 28676 typedef typename std::common_type 28677 < 28678 Duration, 28679 typename std::chrono::system_clock::<b>duration</b> 28680 >::type CD; 28681 typedef std::chrono::<b>duration</b><double, std::nano> ID; 28682 28683 CD d = t - now; 28684 ID us = duration_cast<ID>(d); 28685 if (us < 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 <class Clock, class Duration> 28698void do_until(const std::chrono::<b>time_point</b><Clock, Duration>& t) 28699{ 28700 typename Clock::<b>time_point<font color="#c80000">_type</font></b> now = Clock::now(); 28701 if (t > now) 28702 { 28703 typedef typename std::common_type 28704 < 28705 Duration, 28706 typename std::chrono::system_clock::<b>duration<font color="#c80000">_type</font></b> 28707 >::type CD; 28708 typedef std::chrono::<b>duration</b><double, std::nano> ID; 28709 28710 CD d = t - now; 28711 ID us = duration_cast<ID>(d); 28712 if (us < 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<class Category, class T, class Distance = ptrdiff_t, 28769 class Pointer = T*, class Reference = T&> 28770struct <b>iterator</b> 28771{ 28772 ... 28773}; 28774 28775template <BidirectionalIterator Iter> 28776class <b>reverse_iterator</b> 28777{ 28778 ... 28779}; 28780 28781template <ValueType T, Allocator Alloc = allocator<T> > 28782 requires NothrowDestructible<T> 28783class list 28784{ 28785public: 28786 typedef <i>implementation-defined</i> <b>iterator</b>; 28787 ... 28788 typedef reverse_iterator<iterator> <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 <ValueType T, Allocator Alloc = allocator<T> > 28804 requires NothrowDestructible<T> 28805class list 28806{ 28807public: 28808 typedef <i>implementation-defined</i> <b>iterator_type</b>; 28809 ... 28810 typedef reverse_iterator<iterator> <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 <class Clock, class Duration = typename Clock::duration<ins>_type</ins>> 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<C1::rep, C1::period></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<C1></tt> or <tt>chrono::time_point<C2, C1::duration<ins>_type</ins><</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<<i>unspecified</i>, <i>unspecified</i>> period; 28903 typedef chrono::duration<rep, period> duration<ins>_type</ins>; 28904 typedef chrono::time_point<system_clock> 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>& 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() < 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>& 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<<i>unspecified</i> , <i>unspecified</i>> period; 28946 typedef chrono::duration<rep, period> duration<ins>_type</ins>; 28947 typedef chrono::time_point<<i>unspecified</i> , duration<ins>_type</ins>> 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<<i>unspecified</i> , <i>unspecified</i>> period; 28962 typedef chrono::duration<rep, period> duration<ins>_type</ins>; 28963 typedef chrono::time_point<<i>unspecified</i> , duration<ins>_type</ins>> 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& 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><system_error></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<int>(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<T></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<Cont> stack(stack&&); 29392requires MoveAssignable<Cont> stack& operator=(stack&&); 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 <class T, class Container = deque<T> > 29455class stack { 29456 [..] 29457 explicit stack(const Container&); 29458 explicit stack(Container&& = Container()); 29459 <ins>stack(stack&& s) : c(std::move(s.c)) {}</ins> 29460 <ins>stack& operator=(stack&& 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<Cont::value_type> 29485 back_insert_iterator<Cont>& 29486 operator=(const Cont::value_type& 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<typename C> : Container<C> { 29500 void push_back(C&, value_type&&); 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<typename C, typename Value = C::value_type&&> 29516 : Container<C> { 29517 void push_back(C&, 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<Cont, Cont::value_type const&> && 29526 CopyConstructible<Cont::value_type> 29527 back_insert_iterator<Cont>& 29528 operator=(const Cont::value_type& 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<typename C<ins>, typename Value = C::value_type&&</ins>> 29580 : Container<C> { 29581 void push_front(C&, <del>value_type&&</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<typename C<ins>, typename Value = C::value_type&&</ins>> 29592 : Container<C> { 29593 void push_back(C&, <del>value_type&&</del> <ins>Value</ins>); 29594} 29595</pre> 29596 29597<p>...</p> 29598 29599<pre>concept InsertionContainer<typename C<ins>, typename Value = C::value_type&&</ins>> 29600 : Container<C> { 29601 iterator insert(C&, const_iterator, <del>value_type&&</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<typename C<ins>, typename Value = C::value_type&&</ins>> 29617 : MemberContainer<C> { 29618 void C::push_front(<del>value_type&&</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<typename C<ins>, typename Value = C::value_type&&</ins>> 29629 : MemberContainer<C> { 29630 void C::push_back(<del>value_type&&</del> <ins>Value</ins>); 29631} 29632</pre> 29633 29634<p>...</p> 29635 29636<pre>auto concept MemberInsertionContainer<typename C<ins>, typename Value = C::value_type&&</ins>> 29637 : MemberContainer<C> { 29638 iterator C::insert(const_iterator, <del>value_type&&</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 <MemberFrontInsertionContainer C<ins>, typename Value = C::value_type&&</ins>> 29653concept_map FrontInsertionContainer<C<ins>, Value</ins>> { 29654 typedef Container<C>::value_type value_type; 29655 29656 void push_front(C& c, <del>value_type&&</del> <ins>Value</ins> v) { c.push_front(static_cast<<del>value_type&&</del> <ins>Value</ins>>(v)); } 29657} 29658</pre> 29659 29660<p>...</p> 29661 29662<pre>template <MemberBackInsertionContainer C<ins>, typename Value = C::value_type&&</ins>> 29663concept_map BackInsertionContainer<C<ins>, Value</ins>> { 29664 typedef Container<C>::value_type value_type; 29665 29666 void push_back(C& c, <del>value_type&&</del> <ins>Value</ins> v) { c.push_back(static_cast<<del>value_type&&</del> <ins>Value</ins>>(v)); } 29667} 29668</pre> 29669 29670<p>...</p> 29671 29672<pre>template <MemberInsertionContainer C<ins>, typename Value = C::value_type&&</ins>> 29673concept_map InsertionContainer<C<ins>, Value</ins>> { 29674 typedef Container<C>::value_type value_type; 29675 Container<C>::iterator insert(C& c, Container<C>::const_iterator i, <del>value_type&&</del> <ins>Value</ins> v) 29676 { return c.insert(i, static_cast<<del>value_type&&</del> <ins>Value</ins>>(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 <BackInsertionContainer Cont> 29687class back_insert_iterator { 29688 ... 29689 requires <ins>BackInsertionContainer<Cont, const Cont::value_type&></ins> 29690 <del>CopyConstructible<Cont::value_type></del> 29691 back_insert_iterator<Cont>& 29692 operator=(const Cont::value_type& 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<Cont, const Cont::value_type&></ins> 29702 <del>CopyConstructible<Cont::value_type></del> 29703 back_insert_iterator<Cont>& 29704 operator=(const Cont::value_type& 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 <FrontInsertionContainer Cont> 29716class front_insert_iterator { 29717 ... 29718 requires <ins>FrontInsertionContainer<Cont, const Cont::value_type&></ins> 29719 <del>CopyConstructible<Cont::value_type></del> 29720 front_insert_iterator<Cont>& 29721 operator=(const Cont::value_type& 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<Cont, const Cont::value_type&></ins> 29731 <del>CopyConstructible<Cont::value_type></del> 29732 front_insert_iterator<Cont>& 29733 operator=(const Cont::value_type& 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 <InsertionContainer Cont> 29745class insert_iterator { 29746 ... 29747 requires <ins>InsertionContainer<Cont, const Cont::value_type&></ins> 29748 <del>CopyConstructible<Cont::value_type></del> 29749 insert_iterator<Cont>& 29750 operator=(const Cont::value_type& 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<Cont, const Cont::value_type&></ins> 29760 <del>CopyConstructible<Cont::value_type></del> 29761 insert_iterator<Cont>& 29762 operator=(const Cont::value_type& 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<string> s; 29795// populate the set s 29796vector<string> v1(s.begin(), s.end()); // copies strings into v1 29797vector<string> 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><string> s; 29832// populate the <del>set</del><ins>list</ins> s 29833vector<string> v1(s.begin(), s.end()); // copies strings into v1 29834vector<string> 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(&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, end, less<double>)</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, end, DistanceBiggerThan(6) ) )</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<ForwardIterator Iter> 30206 requires <del>EqualityComparable</del><ins>HasEqualTo</ins><Iter::value_type<ins>, Iter::value_type</ins>> 30207 Iter adjacent_find(Iter first, Iter last); 30208 30209template<ForwardIterator Iter, <del>EquivalenceRelation</del><ins>Predicate</ins><auto, Iter::value_type<ins>, Iter::value_type</ins>> Pred> 30210 requires CopyConstructible<Pred> 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 <iterator_concepts></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 <iterator_concepts></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><memory_concepts></tt> and 30291<tt><container_concepts></tt>. 30292</p> 30293<p> 30294In order to compile <tt><vector></tt> you just need the 30295definitions of the concepts in <tt><memory_concepts></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><vector></tt> is pretty useless. Same for 30299<tt><tuple></tt> and <tt>ConstructibleWithAllocator</tt>. 30300</p> 30301<p> 30302Similarly, <tt><queue></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><std></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><std-all></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><std></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><type_traits></tt>, <tt><array></tt>, 30545<tt><ratio></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><type_traits></tt>, <tt><array></tt>, 30556<tt><ratio></tt> to Table 15. 30557</p> 30558 30559<p><i>[ 30560Summit: 30561]</i></p> 30562 30563 30564<blockquote> 30565<p> 30566 The <tt><array></tt> header has far too many dependencies to require for a 30567free-standing implementation. 30568</p> 30569<p> 30570The <tt><ratio></tt> header would be useful, has no dependencies, but is not 30571strictly necessary. 30572</p> 30573<p> 30574The <tt><type_traits></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><type_traits></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><type_traits></tt> into freestanding 30612implementations. 30613</p> 30614</blockquote> 30615 30616 30617 30618<p><b>Proposed resolution:</b></p> 30619<p> 30620Add <tt><type_traits></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<<del>class</del> <ins>Regular</ins> T> class numeric_limits<const T>; 30690template<<del>class</del> <ins>Regular</ins> T> class numeric_limits<volatile T>; 30691template<<del>class</del> <ins>Regular</ins> T> class numeric_limits<const volatile T>; 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<typename X> : Semiregular<X> { 30789 MoveConstructible reference = typename X::reference; 30790 <del>MoveConstructible postincrement_result;</del> 30791 30792 <del>requires HasDereference<postincrement_result>;</del> 30793 30794 reference operator*(X&&); 30795 X& operator++(X&); 30796 <del>postincrement_result operator++(X&, int);</del> 30797} 30798</pre> 30799 30800<p>...</p> 30801<pre><del>postincrement_result operator++(X& 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<typename X> : Iterator<X>, EqualityComparable<X> { 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<difference_type> 30822 && Convertible<reference, const value_type &>; 30823 && Convertible<pointer, const value_type*>; 30824 30825 <del>requires Convertible<HasDereference<postincrement_result>::result_type, const value_type&>;</del> 30826 30827 pointer operator->(const X&); 30828} 30829</pre> 30830</blockquote> 30831 30832<p> 30833Change 24.2.2 [output.iterators]: 30834</p> 30835 30836<blockquote> 30837<pre>auto concept OutputIterator<typename X, typename Value> { 30838 requires Iterator<X>; 30839 30840 typename reference = Iterator<X>::reference; 30841 <del>typename postincrement_result = Iterator<X>::postincrement_result;</del> 30842 requires SameType<reference, Iterator<X>::reference> 30843 <del>&& SameType<postincrement_result, Iterator<X>::postincrement_result></del> 30844 <del>&& Convertible<postincrement_result, const X&></del> 30845 && HasAssign<reference, Value> 30846 <del>&& HasAssign<HasDereference<postincrement_result>::result_type, Value></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<typename X> : InputIterator<X>, Regular<X> { 30863 <del>requires Convertible<postincrement_result, const X&>;</del> 30864 30865 <ins>MoveConstructible postincrement_result;</ins> 30866 <ins>requires HasDereference<postincrement_result> 30867 && Convertible<HasDereference<postincrement_result>::result_type, const value_type&>;</ins> 30868 30869 <ins>postincrement_result operator++(X&, 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& 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<typename X> : BidirectionalIterator<X>, LessThanComparable<X> { 30933 ... 30934 X& operator-=(X& <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<class T, StrictWeakOrder<auto, T> Compare> 30987 <del>requires !SameType<T, Compare> && CopyConstructible<Compare></del> 30988 const T& min(const T& a, const T& b, Compare comp); 30989... 30990template<class T, StrictWeakOrder<auto, T> Compare> 30991 <del>requires !SameType<T, Compare> && CopyConstructible<Compare></del> 30992 const T& max(const T& a, const T& b, Compare comp); 30993... 30994template<class T, StrictWeakOrder<auto, T> Compare> 30995 <del>requires !SameType<T, Compare> && CopyConstructible<Compare></del> 30996 pair<const T&, const T&> minmax(const T& a, const T& 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<class T, StrictWeakOrder<auto, T> Compare> 31004 <del>requires !SameType<T, Compare> && CopyConstructible<Compare></del> 31005 const T& min(const T& a, const T& b, Compare comp); 31006... 31007template<class T, StrictWeakOrder<auto, T> Compare> 31008 <del>requires !SameType<T, Compare> && CopyConstructible<Compare></del> 31009 const T& max(const T& a, const T& b, Compare comp); 31010... 31011template<class T, StrictWeakOrder<auto, T> Compare> 31012 <del>requires !SameType<T, Compare> && CopyConstructible<Compare></del> 31013 pair<const T&, const T&> minmax(const T& a, const T& 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 -> 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><memory></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<T1></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><functional></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<Returnable R, CopyConstructible... ArgTypes> 31408class function<R(ArgTypes...)> 31409 : public unary_function<T1, R> // <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<T1, T2, R> // <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<R(T1)></tt> shall be publicly and 31424unambiguously derived from 31425<tt>std::unary_function<T1,R></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<R(T1,T2)></tt> shall be publicly and 31431unambiguously derived from 31432<tt>std::binary_function<T1,T2,R></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<class F, Allocator Alloc> 31498 <ins>requires ConstructibleWithAllocator<F, Alloc> 31499 && call=Callable<F, ArgTypes...> 31500 && Convertible<call::result_type, R></ins> 31501 function(allocator_arg_t, const Alloc&, F); 31502 template<class F, Allocator Alloc> 31503 <ins>requires ConstructibleWithAllocator<F,Alloc> 31504 && call=Callable<F, ArgTypes...> 31505 && Convertible<call::result_type, R></ins> 31506 function(allocator_arg_t, const Alloc&, F&&); 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<T></tt> and <tt>weak_ptr<T></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<T></tt> and <tt>FreeStoreAllocatable<T></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><memory></tt> 31666</p> 31667<blockquote><pre>// 20.7.8, raw storage iterator: 31668template <<del>class</del> <ins>ForwardIterator</ins> Out<del>put</del>Iter<del>ator</del>, <del>class</del> <ins>ObjectType</ins> T> 31669 <ins>requires OutputIterator< OutIter, T ></ins> 31670 class raw_storage_iterator; 31671 31672<ins>template <ForwardIterator OutIter, ObjectType T> 31673 requires OutputIterator< OutIter, T > 31674 concept_map Iterator<raw_storage_iterator< OutIter, T > > { }</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 <<del>class</del> <ins>ForwardIterator</ins> Out<del>put</del>Iter<del>ator</del>, <del>class</del> <ins>ObjectType</ins> T> 31686 <ins>requires OutputIterator< OutIter, T ></ins> 31687 class raw_storage_iterator 31688 : public iterator<output_iterator_tag,void,void,void,void> { 31689 public: 31690 explicit raw_storage_iterator(Out<del>put</del>Iter<del>ator</del> x); 31691 31692 raw_storage_iterator<del><OutputIterator,T></del>& operator*(); 31693 raw_storage_iterator<del><OutputIterator,T></del>& operator=(const T& element); 31694 raw_storage_iterator<del><OutputIterator,T></del>& operator++(); 31695 raw_storage_iterator<del><OutputIterator,T></del> operator++(int); 31696 }; 31697 31698 <ins>template <ForwardIterator OutIter, ObjectType T> 31699 requires OutputIterator< OutIter, T > 31700 concept_map Iterator<raw_storage_iterator< OutIter, T > > { }</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 > Size(0); ++result, ++first, --n) {</tt> 31785</li> 31786<li> 31787for <tt>uninitialized_fill_n</tt>: <tt>for (; n > 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><memory></tt> 31811</p> 31812<blockquote><pre>template <<del>class</del> InputIterator <ins>InIter</ins>, 31813 <del>class ForwardIterator</del> <ins>OutputIterator<auto, InIter::reference> OutIter</ins>> 31814 <ins>requires ForwardIterator<OutIter></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 <<del>class</del> InputIterator <ins>InIter</ins>, 31820 <del>class</del> <ins>IntegralLike</ins> Size, 31821 <del>class ForwardIterator</del> <ins>OutputIterator<auto, InIter::reference> OutIter</ins>> 31822 <ins>requires ForwardIterator<OutIter></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 <<del>class</del> ForwardIterator <ins>Iter</ins>, <del>class</del> <ins>ObjectType</ins> T> 31828 <ins>requires Constructible< Iter::value_type, const T& ></ins> 31829 void uninitialized_fill(<del>ForwardIterator</del> <ins>Iter</ins> first, <del>ForwardIterator</del> <ins>Iter</ins> last, 31830 const T& x); 31831 31832template <<del>class</del> ForwardIterator <ins>Iter</ins>, <del>class</del> <ins>IntegralLike</ins> Size, <del>class</del> <ins>ObjectType</ins> T> 31833 <ins>requires Constructible< Iter::value_type, const T& ></ins> 31834 void 31835 uninitialized_fill_n(<del>ForwardIterator</del> <ins>Iter</ins> first, Size n, const T& 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 <<del>class</del> InputIterator <ins>InIter</ins>, 31847 <del>class ForwardIterator</del> <ins>OutputIterator<auto, InIter::reference> OutIter</ins>> 31848 <ins>requires ForwardIterator<OutIter></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<void*>(&*result)) 31860 <del>typename iterator_traits<ForwardIterator></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 <<del>class</del> InputIterator <ins>InIter</ins>, 31871 <del>class</del> <ins>IntegralLike</ins> Size, 31872 <del>class ForwardIterator</del> <ins>OutputIterator<auto, InIter::reference> OutIter</ins>> 31873 <ins>requires ForwardIterator<OutIter></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 > <ins>Size(</ins>0<ins>)</ins>; ++result, ++first, --n) { 31884 new (static_cast<void*>(&*result)) 31885 <del>typename iterator_traits<ForwardIterator></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 <<del>class</del> ForwardIterator <ins>Iter</ins>, <del>class</del> <ins>ObjectType</ins> T> 31901 <ins>requires Constructible< Iter::value_type, const T& ></ins> 31902 void uninitialized_fill(<del>ForwardIterator</del> <ins>Iter</ins> first, <del>ForwardIterator</del> <ins>Iter</ins> last, 31903 const T& 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<void*>( &*first) ) 31912 <del>typename iterator_traits<ForwardIterator></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 <<del>class</del> ForwardIterator <ins>Iter</ins>, <del>class</del> <ins>IntegralLike</ins> Size, <del>class</del> <ins>ObjectType</ins> T> 31924 <ins>requires Constructible< Iter::value_type, const T& ></ins> 31925 void 31926 uninitialized_fill_n(<del>ForwardIterator</del> <ins>Iter</ins> first, Size n, const T& x); 31927</pre> 31928 31929<blockquote> 31930<p> 31931-1- <i>Effects:</i> 31932</p> 31933<blockquote><pre>for (; n<del>--</del> <ins>> Size(0)</ins>; ++first<ins>, --n</ins>) { 31934 new ( static_cast<void*>( &*first) ) 31935 <del>typename iterator_traits<ForwardIterator></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<>::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 <class Rep, class Period = ratio<1>> class duration; 32081template <class Clock, class Duration = typename Clock::duration> 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><array></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><array></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 <Swappable T, size_t N> void swap(array<T,N>& x, array<T,N>& 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— <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)></tt>, Return type <tt>pair<key, iterator></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<key_type, iterator></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<key_type, iterator></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>&a[n] == &a[0] + n</tt> is contingent on 32397<tt>operator&</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<T></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><container_concepts></tt> synopsis in [container.concepts] 32457</p> 32458 32459<blockquote><pre><ins>concept< typename C > 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< typename C > 32472 : Container<C> 32473{ 32474 value_type* data(C&); 32475 32476 axiom Contiguity(C& c, size_type i) { 32477 if( i < 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& ); 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><array></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<T, N></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<T, N></tt> <del>then it obeys the identity <tt>&a[n] 32515== &a[0] + n</tt> for all <tt>0 <= n < N</tt></del> 32516<ins>satisfies the concept <tt>ContiguousStorageContainer< array<T, 32517N>></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< typename T, size_t N ></ins> 32530 <ins>concept_map ContiguousStorageContainer< array<T, N>> {};</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<T, Alloc></tt> <ins>(</ins>where <tt>T</tt> is some 32546type other than <tt>bool</tt><ins>)</ins><del>, then it obeys the 32547identity <tt>&v[n] == &v[0] + n</tt> for all <tt>0 <= n < 32548v.size()</tt></del> <ins>satisfies the concept <tt>ContiguousStorageContainer< 32549vector< T, Alloc>></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< typename T, typename A > 32557 requires !SameType< T, bool > 32558 concept_map ContiguousStorageContainer< vector<T, A>> {};</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< typename F, typename ... Args > 32710 requires Callable< F, Args... > 32711 future< Callable::result_type > async( F&& f, Args && ... ); 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<Args>(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<void>::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&& unique_future::get(); 32865R& unique_future<R&>::get(); 32866void unique_future<void>::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<int> p; 32905std::unique_future<int> uf(p.get_future()); 32906std::unique_future<int> 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 <class R> 32947class future 32948{ 32949public: 32950 typedef R result_type; 32951private: 32952 future(const future&);// = delete; 32953 future& operator=(const future&);// = delete; 32954 32955 template <class R1, class F1> friend class prommise; 32956public: 32957 future(); 32958 ~future(); 32959 32960 future(future&& f); 32961 future& operator=(future&& f); 32962 32963 void swap(future&& 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 <class ElapsedTime> 32974 bool timed_join(const ElapsedTime&); 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& operator=(promise&& 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<int> p; 33116unique_future<int> 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<R> 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& __base(); // not defined 33269auto operator[](difference_type n) const -> 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 <type_traits> 33321#include <cstddef> 33322 33323template<class T> 33324typename std::add_rvalue_reference<T>::type declval(); 33325 33326template<class It> 33327struct reverse_iterator { 33328 It base; 33329 33330 typedef std::ptrdiff_t difference_type; 33331 33332 template<class U = It, class Res = 33333 decltype(declval<const U&>()[declval<difference_type>()]) 33334 > 33335 Res operator[](difference_type n) const { 33336 return base[-n-1]; 33337 } 33338}; 33339 33340struct MyIter { 33341}; 33342 33343int main() { 33344 reverse_iterator<int*> ri; 33345 ri[0] = 2; 33346 reverse_iterator<MyIter> 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<class U = It> 33355 decltype(declval<const U&>()[declval<difference_type>()]) 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 <class T> 33487struct __base_type 33488{ 33489 typedef typename remove_cv<typename remove_reference<T>::type>::type type; 33490}; 33491 33492template <class T, class U, 33493 class = typename enable_if< 33494 !is_lvalue_reference<T>::value || 33495 is_lvalue_reference<T>::value && 33496 is_lvalue_reference<U>::value>::type, 33497 class = typename enable_if< 33498 is_same<typename __base_type<T>::type, 33499 typename __base_type<U>::type>::value>::type> 33500inline 33501T&& 33502forward(U&& t) 33503{ 33504 return static_cast<T&&>(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 <class T, class U, 33555 class = typename enable_if< 33556 !is_lvalue_reference<T>::value || 33557 is_lvalue_reference<T>::value && 33558 is_lvalue_reference<U>::value>::type> 33559inline 33560T&& 33561forward(U&& t) 33562{ 33563 return static_cast<T&&>(t); 33564} 33565</pre></blockquote> 33566 33567<p> 33568Or possibly: 33569</p> 33570 33571<blockquote><pre>template <class T, class U, 33572 class = typename enable_if< 33573 !is_lvalue_reference<T>::value || 33574 is_lvalue_reference<T>::value && 33575 is_lvalue_reference<U>::value>::type, 33576 class = typename enable_if< 33577 is_base_of<typename __base_type<U>::type, 33578 typename __base_type<T>::type>::value>::type> 33579inline 33580T&& 33581forward(U&& t) 33582{ 33583 return static_cast<T&&>(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 <class T> 33609void f(T&& x) 33610{ 33611 // x is an lvalue here. If the actual argument to f was an 33612 // rvalue, pass static_cast<T&&>(x) to g; otherwise, pass x. 33613 g( forward<T>(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<T>(x)</tt> means nothing more than <tt>static_cast<T&&>(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 <class T, class U> 33638T&& forward(U& x) 33639{ 33640 return static_cast<T&&>(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 <class T, class U> 33653boost::enable_if_c< 33654 // in forward<T>(x), x is a parameter of the caller, thus an lvalue 33655 is_lvalue_reference<U>::value 33656 // in caller's deduced T&& argument, T can only be non-ref or lvalue ref 33657 && !is_rvalue_reference<T>::value 33658 // Must not cast cv-qualifications or do any type conversions 33659 && is_same<T&,U&>::value 33660 , T&&>::type forward(U&& a) 33661{ 33662 return static_cast<T&&>(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< class T > 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><functional></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<typename T> 33955requires ReferentType<T> // Eliminate cv void and function types with cv-qual-seq 33956 // or ref-qual (depending on core issue #749) 33957 && PointeeType<T> // Eliminate reference types 33958 && !ObjectType<T> // 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<typename T> 33965 : ReferentType<T>, PointeeType<T>, MemberPointeeType<T> 33966{ 33967 requires !ObjectType<T>; 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><functional></tt> synopsis: 34010</p> 34011<blockquote><pre>// 20.6.16 polymorphic function wrappers: 34012class bad_function_call; 34013template<<del>FunctionType</del><ins>ReferentType F</ins>> 34014<ins>requires PointeeType<F> && !ObjectType<F></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<<del>FunctionType</del><ins>ReferentType F</ins>> 34024<ins>requires PointeeType<F> && !ObjectType<F></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<<del>int</del> <ins>size_t</ins> I, class T1, class T2> 34091 requires True<(I < 2)> 34092 const P& get(const pair<T1, T2>&); 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><algorithm></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><iterator></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<T></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<T></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 <InputIterator Iter, MoveConstructible T> 34337 requires <ins>add =</ins> HasPlus<T, Iter::reference> 34338 && HasAssign<T, <del>HasPlus<T, Iter::reference></del> <ins>add</ins>::result_type> 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 <InputIterator Iter1, InputIterator Iter2, MoveConstructible T> 34347 requires <ins>mult =</ins> HasMultiply<Iter1::reference, Iter2::reference> 34348 && <ins>add =</ins> HasPlus<T, <del>HasMultiply<Iter1::reference, Iter2::reference></del> <ins>mult</ins>::result_type> 34349 && HasAssign< 34350 T, 34351 <del>HasPlus<T, 34352 HasMultiply<Iter1::reference, Iter2::reference>::result_type></del> <ins>add</ins>::result_type> 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 <InputIterator InIter, OutputIterator<auto, const InIter::value_type&> OutIter> 34361 requires <ins>add =</ins> HasPlus<InIter::value_type, InIter::reference> 34362 && HasAssign<InIter::value_type, 34363 <del>HasPlus<InIter::value_type, InIter::reference></del> <ins>add</ins>::result_type> 34364 && Constructible<InIter::value_type, InIter::reference> 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 <InputIterator InIter, OutputIterator<auto, const InIter::value_type&> OutIter> 34373 requires <ins>sub =</ins> HasMinus<InIter::value_type, InIter::value_type> 34374 && Constructible<InIter::value_type, InIter::reference> 34375 && OutputIterator<OutIter, <del>HasMinus<InIter::value_type, InIter::value_type></del> <ins>sub</ins>::result_type> 34376 && MoveAssignable<InIter::value_type> 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 <class T> 34402struct hash : public std::unary_function<T, std::size_t> { 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><functional></tt> synopsis in p2 Function objects 3441220.7 [function.objects] the template is declared as: 34413</p> 34414 34415<blockquote><pre>template <ReferentType T> 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><functional></tt> synopsis, change as indicated: 34458</p> 34459 34460<blockquote><pre>// 20.6.17, hash function base template: 34461template <ReferentType T> 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 <class T> 34470 struct hash : public std::unary_function<T, std::size_t> { 34471 std::size_t operator()(T val) const; 34472 };</del> 34473 <ins>template <ReferentType T> 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<T></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<const hash<T>, const T&></tt>. If <tt>T</tt> is an object 34488type or reference to 34489 object, <tt>hash<T></tt> shall be publicly derived from 34490<tt>std::unary_function<T, std::size_t></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><typeinfo></tt> synopsis change as indicated: 34499</p> 34500<blockquote><pre>namespace std { 34501 class type_info; 34502 class type_index; 34503 template <<del>class</del><ins>ReferentType</ins> T> 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 <Allocator Alloc, class T, class ... Args> 34529 requires HasConstructor<T, Args...> 34530 concept_map AllocatableElement<Alloc, T, Args&&...> { 34531 void construct_element(Alloc& a, T* t, Args&&... args) { 34532 Alloc::rebind<T>(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<T>; 34573void Alloc::construct(T*, Args&&...); 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 <Allocator Alloc, class T, class ... Args> 34597 requires HasConstructor<T, Args...> 34598 concept_map AllocatableElement<Alloc, T, Args&&...> { 34599 void construct_element(<del>Alloc& a,</del> T* t, Args&&... args) { 34600 Alloc::rebind<T>(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<shared_ptr<int>> 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<typename T, typename... Args> { 34732 explicit T::T(Args...); 34733} 34734 34735auto concept ExplicitConstructible<typename T, typename... Args> 34736 : HasExplicitConstructor<T, Args...>, NothrowDestructible<T> 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<typename T, typename... Args> 34751 : HasConstructor<T, Args...>, ExplicitConstructible<T, Args...> 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 <typename T> using scoped_allocator = scoped_allocator_adaptor<allocator<T>>; 34767 34768vector<shared_ptr<int>, scoped_allocator<shared_ptr<int>>> 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 & 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 <class... UTypes> 34876 requires Constructible<Types, const UTypes&>... 34877template <class... UTypes> 34878 requires Constructible<Types, RvalueOf<UTypes>::type>... 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 <class... UTypes> 34905 requires Constructible<Types, const UTypes&>... 34906 <ins>tuple(const pair<UTypes...>&);</ins> 34907template <class... UTypes> 34908 requires Constructible<Types, RvalueOf<UTypes>::type>... 34909 <ins>tuple(pair<UTypes...>&&);</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 <typeinfo> 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 <class T> struct hash; 34967 template<> struct hash<<del>type_index</del><ins>const type_info *</ins>> : public std::unary_function<<del>type_index</del><ins>const type_info *</ins>, size_t> { 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<const type_info *> <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<const type_info *></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->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<const type_info *> {</ins> 34995 <ins>bool operator<(const type_info *x, const type_info *y) { return x->before(*y); }</ins> 34996 <ins>bool operator<=(const type_info *x, const type_info *y) { return !y->before(*x); }</ins> 34997 <ins>bool operator>(const type_info *x, const type_info *y) { return y->before(*x); }</ins> 34998 <ins>bool operator>=(const type_info *x, const type_info *y) { return !x->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 >= 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 >= 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<typename T> 35058 : Regular<T>, LessThanComparable<T>, HasUnaryPlus<T>, HasNegate<T>, 35059 HasPlus<T, T>, HasMinus<T, T>, HasMultiply<T, T>, HasDivide<T, T>, 35060 HasPreincrement<T>, HasPostincrement<T>, HasPredecrement<T>, 35061 HasPostdecrement<T>, 35062 HasPlusAssign<T, const T&>, HasMinusAssign<T, const T&>, 35063 HasMultiplyAssign<T, const T&>, 35064 HasDivideAssign<T, const T&><ins>, ExplicitlyConvertible<T, bool></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 >= <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<typename T> 35109 : Regular<T>, LessThanComparable<T>, HasUnaryPlus<T>, HasNegate<T>, 35110 HasPlus<T, T>, HasMinus<T, T>, HasMultiply<T, T>, HasDivide<T, T>, 35111 HasPreincrement<T>, HasPostincrement<T>, HasPredecrement<T>, 35112 HasPostdecrement<T>, 35113 HasPlusAssign<T, const T&>, HasMinusAssign<T, const T&>, 35114 HasMultiplyAssign<T, const T&>, 35115 HasDivideAssign<T, const T&><ins>, ExplicitlyConvertible<T, bool></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<CodeConvert Codecvt, class Elem = wchar_t> 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<typename X> : InputIterator<X>, Regular<X> { 35282 35283 MoveConstructible postincrement_result; 35284 requires HasDereference<postincrement_result> 35285 && Convertible<HasDereference<postincrement_result>::result_type, const value_type&>; 35286 35287 postincrement_result operator++(X& 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<typename X> : ForwardIterator<X> { 35352 MoveConstructible postdecrement_result; 35353 requires HasDereference<postdecrement_result> 35354 && Convertible<HasDereference<postdecrement_result>::result_type, const value_type&> 35355 && Convertible<postdecrement_result, const X&>; 35356 X& operator--(X&); 35357 postdecrement_result operator--(X& <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<Iter, 35408Iter::reference></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&</tt>s might be copied over existing 35411elements (hence the <tt>OutputIterator<Iter, const T&></tt>. 35412</p> 35413 35414<p> 35415Remove <tt>OutputIterator<Iter, Iter::reference></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<ForwardIterator Iter, class T> 35434 requires <del>OutputIterator<Iter, Iter::reference> 35435 &&</del> OutputIterator<Iter, const T&> 35436 && HasEqualTo<Iter::value_type, T> 35437 void replace(Iter first, Iter last, 35438 const T& old_value, const T& new_value); 35439 35440template<ForwardIterator Iter, Predicate<auto, Iter::value_type> Pred, class T> 35441 requires <del>OutputIterator<Iter, Iter::reference> 35442 &&</del> OutputIterator<Iter, const T&> 35443 && CopyConstructible<Pred> 35444 void replace_if(Iter first, Iter last, 35445 Pred pred, const T& 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&& x,promise&& 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 <class R> 35505void swap(promise<R>& x, promise<R>& 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 <class R> 35530void swap(promise<R>& x, promise<R>& 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><type_traits></tt> 35644synopsis change as indicated: 35645</p> 35646<blockquote><pre>namespace std { 35647// 20.5.3, helper class: 35648template <<del>class</del><ins>IntegralConstantExpressionType</ins> T, T v> 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 <<del>class</del><ins>IntegralConstantExpressionType</ins> T, T v> 35656struct integral_constant { 35657 static constexpr T value = v; 35658 typedef T value_type; 35659 typedef integral_constant<T,v> 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<ForwardIterator Iter> 35758 requires OutputIterator<Iter, <ins>RvalueOf<</ins>Iter::reference<ins>>::type</ins>> 35759 && EqualityComparable<Iter::value_type> 35760 Iter unique(Iter first, Iter last); 35761 35762template<ForwardIterator Iter, EquivalenceRelation<auto, Iter::value_type> Pred> 35763 requires OutputIterator<Iter, RvalueOf<Iter::reference>::type> 35764 && CopyConstructible<Pred> 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<T> buf(buf_size); 35797for (int i = 0; i < 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<T></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<class T> concept_map Range<XYZCorpContainer<T>> {}; 35942 35943template<class T> concept_map Range<const XYZCorpContainer<T>> {}; 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<class T> 35952concept_map Range<XYZCorpContainer<T>> { 35953 typedef T* iterator; 35954 iterator begin(XYZCorpContainer<T> c) { return c.begin(); } 35955 iterator end(XYZCorpContainer<T> c) { return c.end(); } 35956}; 35957 35958template<class T> 35959concept_map Range<const XYZCorpContainer<T>> { 35960 typedef T* iterator; 35961 iterator begin(XYZCorpContainer<T> c) { return c.begin(); } 35962 iterator end(XYZCorpContainer<T> 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><iterator_concepts></tt> and <tt><container_concepts></tt>. 35987 The only difference from 35988making <tt>Range</tt> an auto concept would be this reduces to a single header, 35989<tt><iterator_concepts></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<R>&& 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<R><ins>&&</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<R><ins>&&</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<InputIterator Iter1, InputIterator Iter2, 36118 <del>typename</del> <ins>CopyConstructible</ins> Compare> 36119 requires Predicate<Compare, Iter1::value_type, Iter2::value_type> 36120 && Predicate<Compare, Iter2::value_type, Iter1::value_type> 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<auto, Key, Key> Compare = less<Key> 36167</pre></blockquote> 36168<p> 36169with 36170</p> 36171<blockquote><pre>StrictWeakOrder<auto, Key, Key> Compare = less<Key> 36172</pre></blockquote> 36173 36174<p> 36175For unordered containers, replace 36176</p> 36177<blockquote><pre>Predicate<auto, Key, Key> Compare = less<Key> 36178</pre></blockquote> 36179<p> 36180with 36181</p> 36182<blockquote><pre>EquivalenceRelation<auto, Key, Key> Compare = less<Key> 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 <map> and <set>: 36194</p> 36195<p> 36196 Header <map> synopsis 36197</p> 36198<blockquote><pre> namespace std { 36199 template <ValueType Key, ValueType T, 36200 <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>, 36201 Allocator Alloc = allocator<pair&lt;<b>const Key, T> > > 36202 requires NothrowDestructible<Key> && NothrowDestructible<T> 36203 && CopyConstructible<Compare> 36204 && AllocatableElement<Alloc, Compare, const Compare&> 36205 && AllocatableElement<Alloc, Compare, Compare&&> 36206 class map; 36207 36208 ... 36209 36210 template <ValueType Key, ValueType T, 36211 <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>, 36212 Allocator Alloc = allocator<pair&lt;<b>const Key, T> > > 36213 requires NothrowDestructible<Key> && NothrowDestructible<T> 36214 && CopyConstructible<Compare> 36215 && AllocatableElement<Alloc, Compare, const Compare&> 36216 && AllocatableElement<Alloc, Compare, Compare&&> 36217 class multimap; 36218 36219 ... 36220 36221 } 36222</pre></blockquote> 36223 36224<p> 36225 Header <set> synopsis 36226</p> 36227<blockquote><pre> namespace std { 36228 template <ValueType Key, <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>, 36229 Allocator Alloc = allocator<Key> > 36230 requires NothrowDestructible<Key> && CopyConstructible<Compare> 36231 && AllocatableElement<Alloc, Compare, const Compare&> 36232 && AllocatableElement<Alloc, Compare, Compare&&> 36233 class set; 36234 36235 ... 36236 36237 template <ValueType Key, <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>, 36238 Allocator Alloc = allocator<Key> > 36239 requires NothrowDestructible<Key> && CopyConstructible<Compare> 36240 && AllocatableElement<Alloc, Compare, const Compare&> 36241 && AllocatableElement<Alloc, Compare, Compare&&> 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 <ValueType Key, ValueType T, 36254 <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>, 36255 Allocator Alloc = allocator<pair&lt;<b>const Key, T> > > 36256 requires NothrowDestructible<Key> && NothrowDestructible<T> 36257 && CopyConstructible<Compare> 36258 && AllocatableElement<Alloc, Compare, const Compare&> 36259 && AllocatableElement<Alloc, Compare, Compare&&> 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 <ValueType Key, ValueType T, 36272 <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>, 36273 Allocator Alloc = allocator<pair&lt;<b>const Key, T> > > 36274 requires NothrowDestructible<Key> && NothrowDestructible<T> 36275 && CopyConstructible<Compare> 36276 && AllocatableElement<Alloc, Compare, const Compare&> 36277 && AllocatableElement<Alloc, Compare, Compare&&> 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 <ValueType Key, <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>, 36290 Allocator Alloc = allocator<Key> > 36291 requires NothrowDestructible<Key> && CopyConstructible<Compare> 36292 && AllocatableElement<Alloc, Compare, const Compare&> 36293 && AllocatableElement<Alloc, Compare, Compare&&> 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 <ValueType Key, <del>Predicate</del><ins>StrictWeakOrder</ins><auto, Key<del>, Key</del>> Compare = less<Key>, 36306 Allocator Alloc = allocator<Key> > 36307 requires NothrowDestructible<Key> && CopyConstructible<Compare> 36308 && AllocatableElement<Alloc, Compare, const Compare&> 36309 && AllocatableElement<Alloc, Compare, Compare&&> 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 <unordered_map> and <unordered_set>: 36321</p> 36322<p> 36323 Header <unordered_map> synopsis 36324</p> 36325<blockquote><pre> namespace std { 36326 // 23.5.1, class template unordered_map: 36327 template <ValueType Key, 36328 ValueType T, 36329 Callable<auto, const Key&> Hash = hash<Key>, 36330 <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Key<del>, Key</del>> Pred = equal_to<Key>, 36331 Allocator Alloc = allocator<pair&lt;<b>const Key, T> > > 36332 requires NothrowDestructible<Key> && NothrowDestructible<T> 36333 && SameType<Hash::result_type, size_t> 36334 && CopyConstructible<Hash> && CopyConstructible<Pred> 36335 && AllocatableElement<Alloc, Pred, const Pred&> 36336 && AllocatableElement<Alloc, Pred, Pred&&> 36337 && AllocatableElement<Alloc, Hash, const Hash&> 36338 && AllocatableElement<Alloc, Hash, Hash&&> 36339 class unordered_map; 36340 36341 // 23.5.2, class template unordered_multimap: 36342 template <ValueType Key, 36343 ValueType T, 36344 Callable<auto, const Key&> Hash = hash<Key>, 36345 <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Key<del>, Key</del>> Pred = equal_to<Key>, 36346 Allocator Alloc = allocator<pair&lt;<b>const Key, T> > > 36347 requires NothrowDestructible<Key> && NothrowDestructible<T> 36348 && SameType<Hash::result_type, size_t> 36349 && CopyConstructible<Hash> && CopyConstructible<Pred> 36350 && AllocatableElement<Alloc, Pred, const Pred&> 36351 && AllocatableElement<Alloc, Pred, Pred&&> 36352 && AllocatableElement<Alloc, Hash, const Hash&> 36353 && AllocatableElement<Alloc, Hash, Hash&&> 36354 class unordered_multimap; 36355 36356 ... 36357 } 36358</pre></blockquote> 36359 36360<p> 36361 Header <unordered_set> synopsis 36362</p> 36363<blockquote><pre> namespace std { 36364 // 23.5.3, class template unordered_set: 36365 template <ValueType Value, 36366 Callable<auto, const Value&> Hash = hash<Value>, 36367 <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Value<del>, Value</del>> class Pred = equal_to<Value>, 36368 Allocator Alloc = allocator<Value> > 36369 requires NothrowDestructible<Value> 36370 && SameType<Hash::result_type, size_t> 36371 && CopyConstructible<Hash> && CopyConstructible<Pred> 36372 && AllocatableElement<Alloc, Pred, const Pred&> 36373 && AllocatableElement<Alloc, Pred, Pred&&> 36374 && AllocatableElement<Alloc, Hash, const Hash&> 36375 && AllocatableElement<Alloc, Hash, Hash&&> 36376 class unordered_set; 36377 36378 // 23.5.4, class template unordered_multiset: 36379 template <ValueType Value, 36380 Callable<auto, const Value&> Hash = hash<Value>, 36381 <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Value<del>, Value</del>> class Pred = equal_to<Value>, 36382 Allocator Alloc = allocator<Value> > 36383 requires NothrowDestructible<Value> 36384 && SameType<Hash::result_type, size_t> 36385 && CopyConstructible<Hash> && CopyConstructible<Pred> 36386 && AllocatableElement<Alloc, Pred, const Pred&> 36387 && AllocatableElement<Alloc, Pred, Pred&&> 36388 && AllocatableElement<Alloc, Hash, const Hash&> 36389 && AllocatableElement<Alloc, Hash, Hash&&> 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 <ValueType Key, 36401 ValueType T, 36402 Callable<auto, const Key&> Hash = hash<Key>, 36403 <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Key<del>, Key</del>> Pred = equal_to<Key>, 36404 Allocator Alloc = allocator<pair&lt;<b>const Key, T> > > 36405 requires NothrowDestructible<Key> && NothrowDestructible<T> 36406 && SameType<Hash::result_type, size_t> 36407 && CopyConstructible<Hash> && CopyConstructible<Pred> 36408 && AllocatableElement<Alloc, Pred, const Pred&> 36409 && AllocatableElement<Alloc, Pred, Pred&&> 36410 && AllocatableElement<Alloc, Hash, const Hash&> 36411 && AllocatableElement<Alloc, Hash, Hash&&> 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 <ValueType Key, 36424 ValueType T, 36425 Callable<auto, const Key&> Hash = hash<Key>, 36426 <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Key<del>, Key</del>> Pred = equal_to<Key>, 36427 Allocator Alloc = allocator<pair&lt;<b>const Key, T> > > 36428 requires NothrowDestructible<Key> && NothrowDestructible<T> 36429 && SameType<Hash::result_type, size_t> 36430 && CopyConstructible<Hash> && CopyConstructible<Pred> 36431 && AllocatableElement<Alloc, Pred, const Pred&> 36432 && AllocatableElement<Alloc, Pred, Pred&&> 36433 && AllocatableElement<Alloc, Hash, const Hash&> 36434 && AllocatableElement<Alloc, Hash, Hash&&> 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 <ValueType Value, 36447 Callable<auto, const Value&> Hash = hash<Value>, 36448 <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Value<del>, Value</del>> class Pred = equal_to<Value>, 36449 Allocator Alloc = allocator<Value> > 36450 requires NothrowDestructible<Value> 36451 && SameType<Hash::result_type, size_t> 36452 && CopyConstructible<Hash> && CopyConstructible<Pred> 36453 && AllocatableElement<Alloc, Pred, const Pred&> 36454 && AllocatableElement<Alloc, Pred, Pred&&> 36455 && AllocatableElement<Alloc, Hash, const Hash&> 36456 && AllocatableElement<Alloc, Hash, Hash&&> 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 <ValueType Value, 36468 Callable<auto, const Value&> Hash = hash<Value>, 36469 <del>Predicate</del><ins>EquivalenceRelation</ins><auto, Value<del>, Value</del>> class Pred = equal_to<Value>, 36470 Allocator Alloc = allocator<Value> > 36471 requires NothrowDestructible<Value> 36472 && SameType<Hash::result_type, size_t> 36473 && CopyConstructible<Hash> && CopyConstructible<Pred> 36474 && AllocatableElement<Alloc, Pred, const Pred&> 36475 && AllocatableElement<Alloc, Pred, Pred&&> 36476 && AllocatableElement<Alloc, Hash, const Hash&> 36477 && AllocatableElement<Alloc, Hash, Hash&&> 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< typename ... Types > { 36540 requires LiteralType<Types>...; 36541} 36542</pre></blockquote> 36543 36544<p> 36545ammend the constructor 36546</p> 36547 36548<blockquote><pre><ins>template <class... UTypes> 36549 requires AllLiteral<Types...> 36550 && Constructible<Types, UTypes>... 36551 explicit tuple(UTypes...);</ins> 36552 36553template <class... UTypes> 36554 requires <ins>!AllLiteral<Types...></ins> 36555 <ins>&&</ins> Constructible<Types, UTypes&&>... 36556 explicit tuple(UTypes&&...); 36557</pre></blockquote> 36558 36559<p> 36560ammend the constructor 36561</p> 36562 36563<blockquote><pre><ins>template <class... UTypes> 36564 requires AllLiteral<Types...> 36565 && Constructible<Types, UTypes>... 36566 tuple(tuple<UTypes...>);</ins> 36567 36568template <class... UTypes> 36569 requires <ins>!AllLiteral<Types...></ins> 36570 <ins>&&</ins> Constructible<Types, const UTypes&>... 36571 tuple(const tuple<UTypes...>&); 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<Types>...</del> tuple(const tuple&)<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<remove_reference<T>::type>::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 <intmax_t N, intmax_t D = 1> 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<typename T> { 36758 typename type = T&&; 36759 requires ExplicitlyConvertible<T&,type> && Convertible<T&&,type>; 36760} 36761 36762template<typename T> concept_map RvalueOf<T&> { 36763 typedef T&& type; 36764} 36765</pre></blockquote> 36766 36767<p> 36768is that if <tt>T</tt> is an lvalue-reference, the requirement 36769<tt>Convertible<T&&,type></tt> isn't satisfied for 36770lvalue-references, because after reference-collapsing in the concept 36771definition we have <tt>Convertible<T&,type></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<typename T> { 36786 <del>typename</del><ins>RvalueReference</ins> type = T&&; 36787 requires <del>ExplicitlyConvertible<T&, type> && Convertible<T&&, type></del><ins>SameType<T&, type&></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<typename T> { } // exposition only 36808template<typename T> concept_map IsReference<T&> { } 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<typename T> { } // exposition only 36832template<typename T> concept_map IsReference<T&> { } 36833<ins>template<typename T> concept_map IsReference<T&&> { }</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<T*></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><iterator></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<T*></tt> partial specialization in D.10 36867</li> 36868<li> 36869Remove the declaration of <tt>iterator_traits<T*></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<class T> struct iterator_traits<T*>;</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& s); 36961istream_iterator(const istream_iterator<del><T,charT,traits,Distance></del>& 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><T,charT,traits,Distance></del>& 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&) 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<exception_ptr> 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 & indent ="") 37140{ 37141 const char * indent_unit = " "; 37142 const char * mark = "- "; 37143 try 37144 { 37145 rethow_exception(e); 37146 } 37147 catch(const std::vector<exception_ptr> e) 37148 { 37149 for(std::vector<exception_ptr>::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 << indent << mark << e.what() << std::endl; 37161 } 37162 catch(...) 37163 { 37164 std::cout << indent << mark << "unknown exception" << 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 &a_error, const std::string & 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 << indent << mark << error->message << std::endl; 37212 if (error->children) 37213 { 37214 print_tree_error(error->children, indent +indent_unit); 37215 } 37216 error = error->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 << "- unknown exception" << 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><stdatomic.h></tt> header are not listed anywhere, 37434and <tt><cstdatomic></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><cstdatomic></tt> from the C99 headers in table 14. 37454Add a new header <tt><atomic></tt> to the headers in table 13. 37455Update chapter 29 to remove reference to <tt><stdatomic.h></tt> 37456and replace the use of <tt><cstdatomic></tt> with <tt><atomic></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><cstdatomic></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><limits></tt> 37687<tt>std::numeric_limits<short>::max()</tt> is related to 37688<tt><limits.h></tt> <tt>__LONG_LONG_MAX__</tt>, <tt><atomic> 37689std::atomic_short::is_lock_free</tt> is related to 37690<tt><stdatomic.h></tt> and <tt>ATOMIC_SHORT_LOCK_FREE</tt> — 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. —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_<op>_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 // &value has type "volatile __atomic_int_storage*". 37758 atomic_fetch_add_explicit(&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(&value, increment, order); 37777 } 37778 int fetch_add(int increment, memory_order order = memory_order_seq_cst) { 37779 atomic_fetch_add_explicit(&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 &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><iomanip></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><ios></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><iomanip></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<typename G> : Callable<G> { 37937 ... 37938 axiom NonemptyRange(G& g) { 37939 G::min() < 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() < 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< G::min() < G::max() >; 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& g) { 37975 G::min() < G::max(); 37976}</del> 37977<ins>requires True< G::min() < G::max() >;</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&</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 <cstdint> 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&& 38278 rhs)</tt>, and a move-assignment operator <tt>shared_future& 38279 operator=(shared_future&& 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 <class 38378 Allocator> promise(allocator_arg_t, const Allocator& 38379 a, promise& 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 “rhs” 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<string></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<T,U></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) <=,>, and >=. 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 <LessThanComparable T, class Allocator> 38502bool operator< (const list<T,Allocator>& x, const list<T,Allocator>& y); 38503template <LessThanComparable T, class Allocator> 38504bool operator> (const list<T,Allocator>& x, const list<T,Allocator>& y); 38505template <LessThanComparable T, class Allocator> 38506bool operator>=(const list<T,Allocator>& x, const list<T,Allocator>& y); 38507template <LessThanComparable T, class Allocator> 38508bool operator<=(const list<T,Allocator>& x, const list<T,Allocator>& y); 38509</pre></blockquote> 38510<p> 38511and add this concept_map afterwards: 38512</p> 38513<blockquote><pre>template <LessThanComparable T, class Allocator> 38514export concept_map LessThanComparable<list<T,Allocator> > 38515{ 38516 bool operator<(const list<T,Allocator>& x, const list<T,Allocator>& 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<N>& 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<N>& 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<N>& 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<N>& 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& 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>— 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&& 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>— 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> && 38717<tt>has_trivial_copy_constructor</tt> && <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& 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->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 <memory> 38943 38944struct Ukn; // defined somewhere else 38945Ukn* create_ukn(); // defined somewhere else 38946 38947int main() { 38948 std::default_delete<Ukn>()(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<T[], D></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 <class charT, class traits, class T> 39316 basic_ostream<charT, traits>& 39317 operator<<(basic_ostream<charT, traits>&& os, const T& x); 39318</pre> 39319<blockquote> 39320<p> 393211 <i>Effects:</i> <tt>os << 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") << "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<std::ostringstream&>(std::ostringstream() << "i = " << 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&</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() << "i = " << 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 <class <del>charT, class traits</del> <ins>Istream</ins>, class T> 39391 <del>basic_istream<charT, traits>&</del> <ins>Istream&&</ins> 39392 operator>>(<del>basic_istream<charT, traits></del> <ins>Istream</ins>&& is, T& x); 39393</pre> 39394<blockquote> 39395<p> 393961 <i>Effects:</i> <tt>is >> 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 <class <del>charT, class traits</del> <ins>Ostream</ins>, class T> 39414 <del>basic_ostream<charT, traits>&</del> <ins>Ostream&&</ins> 39415 operator<<(<del>basic_ostream<charT, traits></del> <ins>Ostream</ins>&& os, const T& x); 39416</pre> 39417<blockquote> 39418<p> 394191 <i>Effects:</i> <tt>os << 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<complex<T> > 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<double> 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<typename T,typename S> complex<T> operator+(const complex<T> x,const S a) { 39477 complex<T> result(x.real()+a, x.imag()); 39478 return result; 39479} 39480template<typename T,typename S> complex<T> operator+(const S a,const complex<T> x) { 39481 complex<T> result(a+x.real(), x.imag()); 39482 return result; 39483} 39484template<typename T,typename S> complex<T> operator-(const complex<T> x,const S a) { 39485 complex<T> result(x.real()-a, x.imag()); 39486 return result; 39487} 39488template<typename T,typename S> complex<T> operator-(const S a,const complex<T> x) { 39489 complex<T> result(a-x.real(), x.imag()); 39490 return result; 39491} 39492template<typename T,typename S> complex<T> operator*(const complex<T> x,const S a) { 39493 complex<T> result(x.real()*a, x.imag()*a); 39494 return result; 39495} 39496template<typename T,typename S> complex<T> operator*(const S a,const complex<T> x) { 39497 complex<T> result(a*x.real(), a*x.imag()); 39498 return result; 39499} 39500 39501/////////////////////////PROPERLY IMPLEMENT QUATERNION SEMANTICS///////////////////////// 39502template<typename T> double normSq(const complex<complex<T> >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<typename T> double norm(const complex<complex<T> >q) { 39509 return sqrt(normSq(q)); 39510} 39511/////// Cayley-Dickson Construction 39512template<typename T> complex<complex<T> > conj(const complex<complex<T> > x) { 39513 complex<complex<T> > result(conj(x.real()),-x.imag()); 39514 return result; 39515} 39516template<typename T> complex<complex<T> > operator*(const complex<complex<T> > ab,const complex<complex<T> > cd) { 39517 complex<T> re(ab.real()*cd.real()-conj(cd.imag())*ab.imag()); 39518 complex<T> im(cd.imag()*ab.real()+ab.imag()*conj(cd.real())); 39519 complex<complex<double> > q(re,im); 39520 return q; 39521} 39522//// Quaternion division 39523template<typename S,typename T> complex<complex<T> > operator/(const complex<complex<T> > q,const S a) { 39524 return q * (1/a); 39525} 39526template<typename S,typename T> complex<complex<T> > operator/(const S a,const complex<complex<T> > q) { 39527 return a*conj(q)/normSq(q); 39528} 39529template<typename T> complex<complex<T> > operator/(const complex<complex<T> > n, const complex<complex<T> > 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 <class ErrorCodeEnum> 39564 typename enable_if<is_error_code_enum<ErrorCodeEnum>::value>::type& 39565 operator=(ErrorCodeEnum e); 39566</pre></blockquote> 39567 39568<p> 39569They should say: 39570</p> 39571 39572<blockquote><pre> 39573template <class ErrorCodeEnum> 39574 typename enable_if<is_error_code_enum<ErrorCodeEnum>::value, error_code>::type& 39575 operator=(ErrorCodeEnum e); 39576</pre></blockquote> 39577 39578<p> 39579Or (I prefer this form): 39580</p> 39581 39582<blockquote><pre> 39583template <class ErrorCodeEnum> 39584 typename enable_if<is_error_code_enum<ErrorCodeEnum>::value, error_code&>::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 <bool B, class T = void> struct enable_if; 39594</pre></blockquote> 39595 39596<p> 39597So, the current wording makes <tt>operator=</tt> return 39598<tt>void&</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<typename ErrorConditionEnum> 39622 typename enable_if<is_error_condition_enum<ErrorConditionEnum>, error_code>::type & 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 <class ErrorConditionEnum> 39634 typename enable_if<is_error_condition_enum<ErrorConditionEnum>::value>::type& 39635 operator=(ErrorConditionEnum e); 39636</pre></blockquote> 39637 39638<p> 39639Which returns <tt>void&</tt>. They should both say: 39640</p> 39641 39642<blockquote><pre> 39643template <class ErrorConditionEnum> 39644 typename enable_if<is_error_condition_enum<ErrorConditionEnum>::value, error_condition>::type& 39645 operator=(ErrorConditionEnum e); 39646</pre></blockquote> 39647 39648<p> 39649Or (again, I prefer this form): 39650</p> 39651 39652<blockquote><pre> 39653template <class ErrorConditionEnum> 39654 typename enable_if<is_error_condition_enum<ErrorConditionEnum>::value, error_condition&>::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 <class ErrorCodeEnum> 39692 typename enable_if<is_error_code_enum<ErrorCodeEnum>::value<ins>, error_code&</ins>>::type<del>&</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<<del>typename</del> <ins>class</ins> ErrorConditionEnum> 39701 typename enable_if<is_error_condition_enum<ErrorConditionEnum><ins>::value</ins>, error_co<ins>ndition</ins><del>de</del><ins>&</ins>>::type<del> &</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 <class ErrorConditionEnum> 39710 typename enable_if<is_error_condition_enum<ErrorConditionEnum>::value<ins>, error_condition&</ins>>::type<del>&</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<class R, class T, typename ... ArgTypes> 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<class R, class T> <i>unspecified</i> mem_fn(R T::* pm) 39777 39778<ins>template<class R, class T, class ...Args> <i>unspecified</i> mem_fn(R (T::* pm)(Args...));</ins> 39779<ins>template<class R, class T, class ...Args> <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const);</ins> 39780<ins>template<class R, class T, class ...Args> <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile);</ins> 39781<ins>template<class R, class T, class ...Args> <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile);</ins> 39782 39783<ins>template<class R, class T, class ...Args> <i>unspecified</i> mem_fn(R (T::* pm)(Args...)&);</ins> 39784<ins>template<class R, class T, class ...Args> <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const&);</ins> 39785<ins>template<class R, class T, class ...Args> <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile&);</ins> 39786<ins>template<class R, class T, class ...Args> <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile&);</ins> 39787 39788<ins>template<class R, class T, class ...Args> <i>unspecified</i> mem_fn(R (T::* pm)(Args...)&&);</ins> 39789<ins>template<class R, class T, class ...Args> <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const&&);</ins> 39790<ins>template<class R, class T, class ...Args> <i>unspecified</i> mem_fn(R (T::* pm)(Args...) volatile&&);</ins> 39791<ins>template<class R, class T, class ...Args> <i>unspecified</i> mem_fn(R (T::* pm)(Args...) const volatile&&);</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 <class T1, class T2> 39838struct pair { 39839 ... 39840 void swap(pair&<del>&</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&<del>&</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<class T1, class T2> void swap(pair<T1, T2>& x, pair<T1, T2>& y); 39862<del>template<class T1, class T2> void swap(pair<T1, T2>&& x, pair<T1, T2>& y);</del> 39863<del>template<class T1, class T2> void swap(pair<T1, T2>& x, pair<T1, T2>&& y);</del> 39864</pre></blockquote> 39865 39866</li> 39867 39868<li> 39869<p> 39870Change 20.5.1 [tuple.general]/2, header <tt><tuple></tt> synopsis, as indicated: 39871</p> 39872 39873<blockquote><pre>// 20.5.2.9, specialized algorithms: 39874template <class... Types> 39875void swap(tuple<Types...>& x, tuple<Types...>& y); 39876<del>template <class... Types> 39877void swap(tuple<Types...>&& x, tuple<Types...>& y); 39878template <class... Types> 39879void swap(tuple<Types...>& x, tuple<Types...>&& 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&<del>&</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&<del>&</del> rhs); 39901</pre></blockquote> 39902 39903</li> 39904 39905<li> 39906<p> 39907Change 20.7 [function.objects]/2, header <tt><functional></tt> synopsis, as indicated: 39908</p> 39909 39910<blockquote><pre>template<class R, class... ArgTypes> 39911void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&); 39912<del>template<class R, class... ArgTypes> 39913void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&); 39914template<class R, class... ArgTypes> 39915void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)&&);</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&<del>&</del>); 39927template<class F, class A> void assign(F, const A&); 39928 39929[..] 39930 39931// 20.7.15.2.7, specialized algorithms: 39932template <class R, class... ArgTypes> 39933void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&); 39934<del>template <class R, class... ArgTypes> 39935void swap(function<R(ArgTypes...)>&&, function<R(ArgTypes...)>&); 39936template <class R, class... ArgTypes> 39937void swap(function<R(ArgTypes...)>&, function<R(ArgTypes...)>&&);</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<class R, class... ArgTypes> 39948void swap(function<R(ArgTypes...)>& f1, function<R(ArgTypes...)>& f2); 39949<del>template<class R, class... ArgTypes> 39950void swap(function<R(ArgTypes...)>&& f1, function<R(ArgTypes...)>& f2); 39951template<class R, class... ArgTypes> 39952void swap(function<R(ArgTypes...)>& f1, function<R(ArgTypes...)>&& 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&<del>&</del> r); 39964 39965[..] 39966 39967// 20.8.12.2.9, shared_ptr specialized algorithms: 39968template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>& b); 39969<del>template<class T> void swap(shared_ptr<T>&& a, shared_ptr<T>& b); 39970template<class T> void swap(shared_ptr<T>& a, shared_ptr<T>&& b);</del> 39971</pre></blockquote> 39972 39973</li> 39974 39975<li> 39976<p> 39977Change 21.3 [string.classes]/1, header <tt><string></tt> synopsis, as indicated: 39978</p> 39979 39980<blockquote><pre>// 21.4.8.8: swap 39981template<class charT, class traits, class Allocator> 39982void swap(basic_string<charT,traits,Allocator>& lhs, basic_string<charT,traits,Allocator>& rhs); 39983<del>template<class charT, class traits, class Allocator> 39984void swap(basic_string<charT,traits,Allocator>&& lhs, basic_string<charT,traits,Allocator>& rhs); 39985template<class charT, class traits, class Allocator> 39986void swap(basic_string<charT,traits,Allocator>& lhs, basic_string<charT,traits,Allocator>&& rhs);</del> 39987</pre></blockquote> 39988 39989</li> 39990 39991<li> 39992<p> 39993Change 23.3 [sequences]/1, header <tt><deque></tt> synopsis, as indicated: 39994</p> 39995 39996<blockquote><pre>template <class T, class Allocator> 39997void swap(deque<T,Allocator>& x, deque<T,Allocator>& y); 39998<del>template <class T, class Allocator> 39999void swap(deque<T,Allocator>&& x, deque<T,Allocator>& y); 40000template <class T, class Allocator> 40001void swap(deque<T,Allocator>& x, deque<T,Allocator>&& y);</del> 40002</pre></blockquote> 40003 40004</li> 40005 40006<li> 40007<p> 40008Change 23.3 [sequences]/1, header <tt><list></tt> synopsis, as indicated: 40009</p> 40010 40011<blockquote><pre>template <class T, class Allocator> 40012void swap(list<T,Allocator>& x, list<T,Allocator>& y); 40013<del>template <class T, class Allocator> 40014void swap(list<T,Allocator>&& x, list<T,Allocator>& y); 40015template <class T, class Allocator> 40016void swap(list<T,Allocator>& x, list<T,Allocator>&& y);</del> 40017</pre></blockquote> 40018 40019</li> 40020 40021<li> 40022<p> 40023Change 23.3 [sequences]/1, header <tt><queue></tt> synopsis, as indicated: 40024</p> 40025 40026<blockquote><pre>template <class T, class Allocator> 40027void swap(queue<T, Container>& x, queue<T, Container>& y); 40028<del>template <class T, class Container> 40029void swap(queue<T, Container>&& x, queue<T, Container>& y); 40030template <class T, class Container> 40031void swap(queue<T, Container>& x, queue<T, Container>&& y);</del> 40032 40033template <class T, class Container = vector<T>, class Compare = less<typename Container::value_type> > 40034class priority_queue; 40035template <class T, class Container, class Compare> 40036void swap(priority_queue<T, Container, Compare>& x, priority_queue<T, Container, Compare>& y); 40037<del>template <class T, class Container, class Compare> 40038void swap(priority_queue<T, Container, Compare>&& x, priority_queue<T, Container, Compare>& y); 40039template <class T, class Container, class Compare> 40040void swap(priority_queue<T, Container, Compare>& x, priority_queue<T, Container, Compare>&& y);</del> 40041</pre></blockquote> 40042 40043</li> 40044 40045<li> 40046<p> 40047Change 23.3 [sequences]/1, header <tt><stack></tt> synopsis, as indicated: 40048</p> 40049 40050<blockquote><pre>template <class T, class Container> 40051void swap(stack<T, Container>& x, stack<T, Container>& y); 40052<del>template <class T, class Container> 40053void swap(stack<T, Container>&& x, stack<T, Container>& y); 40054template <class T, class Container> 40055void swap(stack<T, Container>& x, stack<T, Container>&& y);</del> 40056</pre></blockquote> 40057 40058</li> 40059 40060<li> 40061<p> 40062Change 23.3 [sequences]/1, header <tt><vector></tt> synopsis, as indicated: 40063</p> 40064 40065<blockquote><pre>template <class T, class Allocator> 40066void swap(vector<T,Allocator>& x, vector<T,Allocator>& y); 40067<del>template <class T, class Allocator> 40068void swap(vector<T,Allocator>&& x, vector<T,Allocator>& y); 40069template <class T, class Allocator> 40070void swap(vector<T,Allocator>& x, vector<T,Allocator>&& 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<T,Allocator>&<del>&</del>); 40083void clear(); 40084 40085[..] 40086 40087// specialized algorithms: 40088template <class T, class Allocator> 40089void swap(deque<T,Allocator>& x, deque<T,Allocator>& y); 40090<del>template <class T, class Allocator> 40091void swap(deque<T,Allocator>&& x, deque<T,Allocator>& y); 40092template <class T, class Allocator> 40093void swap(deque<T,Allocator>& x, deque<T,Allocator>&& 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 <class T, class Allocator> 40104void swap(deque<T,Allocator>& x, deque<T,Allocator>& y); 40105<del>template <class T, class Allocator> 40106void swap(deque<T,Allocator>&& x, deque<T,Allocator>& y); 40107template <class T, class Allocator> 40108void swap(deque<T,Allocator>& x, deque<T,Allocator>&& 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<T,Allocator>&<del>&</del>); 40121 40122[..] 40123 40124// 23.3.3.6 specialized algorithms: 40125template <class T, class Allocator> 40126void swap(forward_list<T,Allocator>& x, forward_list<T,Allocator>& y); 40127<del>template <class T, class Allocator> 40128void swap(forward_list<T,Allocator>&& x, forward_list<T,Allocator>& y); 40129template <class T, class Allocator> 40130void swap(forward_list<T,Allocator>& x, forward_list<T,Allocator>&& 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 <class T, class Allocator> 40141void swap(forward_list<T,Allocator>& x, forward_list<T,Allocator>& y); 40142<del>template <class T, class Allocator> 40143void swap(forward_list<T,Allocator>&& x, forward_list<T,Allocator>& y); 40144template <class T, class Allocator> 40145void swap(forward_list<T,Allocator>& x, forward_list<T,Allocator>&& 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<T,Allocator>&<del>&</del>); 40158void clear(); 40159 40160[..] 40161 40162// specialized algorithms: 40163template <class T, class Allocator> 40164void swap(list<T,Allocator>& x, list<T,Allocator>& y); 40165<del>template <class T, class Allocator> 40166void swap(list<T,Allocator>&& x, list<T,Allocator>& y); 40167template <class T, class Allocator> 40168void swap(list<T,Allocator>& x, list<T,Allocator>&& 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 <class T, class Allocator> 40179void swap(list<T,Allocator>& x, list<T,Allocator>& y); 40180<del>template <class T, class Allocator> 40181void swap(list<T,Allocator>&& x, list<T,Allocator>& y); 40182template <class T, class Allocator> 40183void swap(list<T,Allocator>& x, list<T,Allocator>&& 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&<del>&</del> q) { c.swap(q.c); } 40194 40195[..] 40196 40197template <class T, class Container> 40198void swap(queue<T, Container>& x, queue<T, Container>& y); 40199<del>template <class T, class Container> 40200void swap(queue<T, Container>&& x, queue<T, Container>& y); 40201template <class T, class Container> 40202void swap(queue<T, Container>& x, queue<T, Container>&& 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 <class T, class Container> 40213void swap(queue<T, Container>& x, queue<T, Container>& y); 40214<del>template <class T, class Container> 40215void swap(queue<T, Container>&& x, queue<T, Container>& y); 40216template <class T, class Container> 40217void swap(queue<T, Container>& x, queue<T, Container>&& 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&<del>&</del>); 40228 40229// no equality is provided 40230template <class T, class Container, class Compare> 40231void swap(priority_queue<T, Container, Compare>& x, priority_queue<T, Container, Compare>& y); 40232<del>template <class T, class Container, class Compare> 40233void swap(priority_queue<T, Container, Compare>&& x, priority_queue<T, Container, Compare>& y); 40234template <class T, class Container, class Compare> 40235void swap(priority_queue<T, Container, Compare>& x, priority_queue<T, Container, Compare>&& 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 <class T, class Container, Compare> 40246void swap(priority_queue<T, Container, Compare>& x, priority_queue<T, Container, Compare>& y); 40247<del>template <class T, class Container, Compare> 40248void swap(priority_queue<T, Container, Compare>&& x, priority_queue<T, Container, Compare>& y); 40249template <class T, class Container, Compare> 40250void swap(priority_queue<T, Container, Compare>& x, priority_queue<T, Container, Compare>&& 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&<del>&</del> s) { c.swap(s.c); } 40261 40262[..] 40263 40264template <class T, class Allocator> 40265void swap(stack<T,Allocator>& x, stack<T,Allocator>& y); 40266<del>template <class T, class Allocator> 40267void swap(stack<T,Allocator>&& x, stack<T,Allocator>& y); 40268template <class T, class Allocator> 40269void swap(stack<T,Allocator>& x, stack<T,Allocator>&& 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 <class T, class Container> 40281void swap(stack<T, Container>& x, stack<T, Container>& y); 40282<del>template <class T, class Container> 40283void swap(stack<T, Container>&& x, stack<T, Container>& y); 40284template <class T, class Container> 40285void swap(stack<T, Container>& x, stack<T, Container>&& 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<T,Allocator>&<del>&</del>); 40296void clear(); 40297 40298[..] 40299 40300// specialized algorithms: 40301template <class T, class Allocator> 40302void swap(vector<T,Allocator>& x, vector<T,Allocator>& y); 40303<del>template <class T, class Allocator> 40304void swap(vector<T,Allocator>&& x, vector<T,Allocator>& y); 40305template <class T, class Allocator> 40306void swap(vector<T,Allocator>& x, vector<T,Allocator>&& 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<T,Allocator>&<del>&</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 <class T, class Allocator> 40327void swap(vector<T,Allocator>& x, vector<T,Allocator>& y); 40328<del>template <class T, class Allocator> 40329void swap(vector<T,Allocator>&& x, vector<T,Allocator>& y); 40330template <class T, class Allocator> 40331void swap(vector<T,Allocator>& x, vector<T,Allocator>&& 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<bool,Allocator>&<del>&</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><map></tt> synopsis as indicated: 40351</p> 40352 40353<blockquote><pre>template <class Key, class T, class Compare, class Allocator> 40354void swap(map<Key,T,Compare,Allocator>& x, map<Key,T,Compare,Allocator>& y); 40355<del>template <class Key, class T, class Compare, class Allocator> 40356void swap(map<Key,T,Compare,Allocator&& x, map<Key,T,Compare,Allocator>& y); 40357template <class Key, class T, class Compare, class Allocator> 40358void swap(map<Key,T,Compare,Allocator& x, map<Key,T,Compare,Allocator>&& y);</del> 40359 40360[..] 40361 40362template <class Key, class T, class Compare, class Allocator> 40363void swap(multimap<Key,T,Compare,Allocator>& x, multimap<Key,T,Compare,Allocator>& y); 40364<del>template <class Key, class T, class Compare, class Allocator> 40365void swap(multimap<Key,T,Compare,Allocator&& x, multimap<Key,T,Compare,Allocator>& y); 40366template <class Key, class T, class Compare, class Allocator> 40367void swap(multimap<Key,T,Compare,Allocator& x, multimap<Key,T,Compare,Allocator>&& y);</del> 40368</pre></blockquote> 40369 40370</li> 40371 40372<li> 40373<p> 40374Change 23.4 [associative]/1, header <tt><set></tt> synopsis as indicated: 40375</p> 40376 40377<blockquote><pre>template <class Key, class Compare, class Allocator> 40378void swap(set<Key,Compare,Allocator>& x, set<Key,Compare,Allocator>& y); 40379<del>template <class Key, class T, class Compare, class Allocator> 40380void swap(set<Key,T,Compare,Allocator&& x, set<Key,T,Compare,Allocator>& y); 40381template <class Key, class T, class Compare, class Allocator> 40382void swap(set<Key,T,Compare,Allocator& x, set<Key,T,Compare,Allocator>&& y);</del> 40383 40384[..] 40385 40386template <class Key, class Compare, class Allocator> 40387void swap(multiset<Key,Compare,Allocator>& x, multiset<Key,Compare,Allocator>& y); 40388<del>template <class Key, class T, class Compare, class Allocator> 40389void swap(multiset<Key,T,Compare,Allocator&& x, multiset<Key,T,Compare,Allocator>& y); 40390template <class Key, class T, class Compare, class Allocator> 40391void swap(multiset<Key,T,Compare,Allocator& x, multiset<Key,T,Compare,Allocator>&& 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<Key,T,Compare,Allocator>&<del>&</del>); 40403void clear(); 40404 40405[..] 40406 40407// specialized algorithms: 40408template <class Key, class T, class Compare, class Allocator> 40409void swap(map<Key,T,Compare,Allocator>& x, map<Key,T,Compare,Allocator>& y); 40410<del>template <class Key, class T, class Compare, class Allocator> 40411void swap(map<Key,T,Compare,Allocator&& x, map<Key,T,Compare,Allocator>& y); 40412template <class Key, class T, class Compare, class Allocator> 40413void swap(map<Key,T,Compare,Allocator& x, map<Key,T,Compare,Allocator>&& 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 <class Key, class T, class Compare, class Allocator> 40424void swap(map<Key,T,Compare,Allocator>& x, map<Key,T,Compare,Allocator>& y); 40425<del>template <class Key, class T, class Compare, class Allocator> 40426void swap(map<Key,T,Compare,Allocator>&& x, map<Key,T,Compare,Allocator>& y); 40427template <class Key, class T, class Compare, class Allocator> 40428void swap(map<Key,T,Compare,Allocator>& x, map<Key,T,Compare,Allocator>&& 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<Key,T,Compare,Allocator>&<del>&</del>); 40440void clear(); 40441 40442[..] 40443 40444// specialized algorithms: 40445template <class Key, class T, class Compare, class Allocator> 40446void swap(multimap<Key,T,Compare,Allocator>& x, multimap<Key,T,Compare,Allocator>& y); 40447<del>template <class Key, class T, class Compare, class Allocator> 40448void swap(multimap<Key,T,Compare,Allocator&& x, multimap<Key,T,Compare,Allocator>& y); 40449template <class Key, class T, class Compare, class Allocator> 40450void swap(multimap<Key,T,Compare,Allocator& x, multimap<Key,T,Compare,Allocator>&& 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 <class Key, class T, class Compare, class Allocator> 40461void swap(multimap<Key,T,Compare,Allocator>& x, multimap<Key,T,Compare,Allocator>& y); 40462<del>template <class Key, class T, class Compare, class Allocator> 40463void swap(multimap<Key,T,Compare,Allocator>&& x, multimap<Key,T,Compare,Allocator>& y); 40464template <class Key, class T, class Compare, class Allocator> 40465void swap(multimap<Key,T,Compare,Allocator>& x, multimap<Key,T,Compare,Allocator>&& 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 <class Key, class Compare, class Allocator> 40477void swap(set<Key,Compare,Allocator>& x, set<Key,Compare,Allocator>& y); 40478<del>template <class Key, class Compare, class Allocator> 40479void swap(set<Key,Compare,Allocator&& x, set<Key,Compare,Allocator>& y); 40480template <class Key, class Compare, class Allocator> 40481void swap(set<Key,Compare,Allocator& x, set<Key,Compare,Allocator>&& 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<Key,Compare,Allocator>&<del>&</del>); 40493void clear(); 40494 40495[..] 40496 40497// specialized algorithms: 40498template <class Key, class Compare, class Allocator> 40499void swap(multiset<Key,Compare,Allocator>& x, multiset<Key,Compare,Allocator>& y); 40500<del>template <class Key, class Compare, class Allocator> 40501void swap(multiset<Key,Compare,Allocator&& x, multiset<Key,Compare,Allocator>& y); 40502template <class Key, class Compare, class Allocator> 40503void swap(multiset<Key,Compare,Allocator& x, multiset<Key,Compare,Allocator>&& 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 <class Key, class Compare, class Allocator> 40514void swap(multiset<Key,Compare,Allocator>& x, multiset<Key,Compare,Allocator>& y); 40515<del>template <class Key, class Compare, class Allocator> 40516void swap(multiset<Key,Compare,Allocator>&& x, multiset<Key,Compare,Allocator>& y); 40517template <class Key, class Compare, class Allocator> 40518void swap(multiset<Key,Compare,Allocator>& x, multiset<Key,Compare,Allocator>&& 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<double> 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<double> dist; 40582std::tr1::variate_generator<mkl::mt19937,std::tr1::normal_distribution<double> > 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<> 40595class variate_generator<mkl::mt19937,std::tr1::normal_distribution<double> > { .... }; 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 <RandomNumberDistribution, class RandomNumberEngine> 40617typename RandomNumberDistribution ::result_type 40618generate_variate(RandomNumberDistribution const& dist, RandomNumberEngine& 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<T>)</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& operator+=(initializer_list<charT>); 40737</pre></blockquote> 40738 40739<p> 40740but 40741</p> 40742 40743<blockquote><pre>valarray<T>& operator+= (initializer_list<T>); 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<T>& operator+= (initializer_list<T>); 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>